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 concorrentee 
pode mudar de estado independentemente. Os diagramas de 
estado para as várias classes combinam num modelo dinâmico 
único através de eventos compartilhados.
Um é algo que ocorre num instante de tempo 
e que não tem duração. Um evento pode preceder ou seguir 
outro evento ou pode não ter relação entre eventos (neste caso, 
são ditos concorrentes). Cada evento é uma ocorrência única; 
entretanto, é possível reagrupá-los em classes de eventos e 
dar a cada uma delas um nome que indica uma estrutura e um 
comportamento comuns. Alguns eventos são simples sinais, 
mas muitos outros têm atributos indicando a informação que 
eles transportam. O tempo no qual o evento ocorre é um 
atributo implícito de todos os eventos. Um evento transporta 
a informação de um objeto a outro; os valores de dados 
transportados por um evento são seus atributos. Os eventos 
incluem as condições de erro e as ocorrências normais.
Um cenário é uma sequência de eventos que ocorre 
durante uma execução particular de um sistema. Ele pode 
incluir todos os eventos do sistema ou apenas eventos gerados 
por certos objetos no sistema. A sequência de eventos e os 
objetos que trocam eventos podem ser mostrados juntos num 
diagrama de 
e o rastro de eventos para uma chamada telefônica.
Um é uma abstração dos valores dos atributos 
do objeto a eventos de entrada. A resposta de um objeto a 
um evento pode incluir uma ação ou uma mudança de estado 
pelo objeto.
Um estado tem uma duração; ele ocupa um intervalo 
se ignorar atributos que não afetam o comportamento 
do objeto. O estado é caracterizado por um nome e uma 
descrição contendo a sequência de eventos que leva ao estado, 
a condição que o caracteriza e os eventos aceitos neste estado 
com a ação que ocorre e o estado futuro. O estado pode 
incluir os valores de suas ligações.
O relaciona estados e eventos. 
A mudança de estado causada por um evento é chamada de 
linha telefônica. Os diagramas de estado podem representar 
ciclos de vida uma-vez (com um estado inicial e um estado 
coleção de diagramas de estado que interagem entre si através 
de eventos compartilhados.
Uma é uma função booleana de valores 
objetos. Condições podem ser usadas como guardas nas 
transições, sendo que uma transição guardada
dispara quando o evento ocorre e que a condição de 
guarda é verdadeira.
Figura 5.1. Cenário e traço de eventos para uma chamada telefônica. Fonte: Acervo pessoal
168
33
1.2
Uma descrição do comportamento de um objeto 
Operações associadas a estados ou transições são realizadas 
em resposta aos estados correspondentes ou a eventos.
Uma é uma operação que leva tempo para se 
completar. Ela é associada a um estado. A notação “do: A” 
dentro de um caixa de estado indica que a atividade A inicia 
na entrada no estado e para na saída.
Uma é uma operação instantânea e é associada a 
um evento. Uma ação representa uma operação cuja duração é 
pequena comparada com a resolução do diagrama de estados. 
Ações podem também representar operações de controle 
interno. A notação para uma ação numa transição é um “/” 
seguido do nome da ação, após o evento que a causa.
1.3 - Diagramas de estado 
aninhados
Os diagramas de estado podem ser estruturados para 
permitir descrições concisas de sistemas complexos. Através 
de uma , é possível expandir, num nível mais 
baixo, adicionando detalhes, uma atividade descrita num 
nível superior . É possível organizar estados e eventos em 
hierarquias, com herança de estrutura e comportamento 
comuns, como no caso da herança de atributos e operações 
em classes de objetos. 
Figura 5.3. Diagrama de estados (generalização). Fonte: Acervo pessoal
A permite quebrar um estado em 
Figura 5.2. Diagrama de estados de uma linha telefônica. Fonte: Acervo pessoal
componentes ortogonais, com interação limitada entre eles, 
da mesma forma como se tem uma hierarquia de agregação de 
(estados concorrentes correspondem geralmente a agregações 
de objetos).
Uma num estado pode ser expandida 
como um diagrama de estados de baixo-nível, cada estado 
representando um degrau da atividade. Atividades aninhadas 
são diagramas de estados uma-vez com transições de entrada 
e saída, de forma similar a sub-rotinas. Um diagrama de 
estados aninhado é uma forma de generalização (relação 
do tipo “or”) sobre os estados . Os estados num diagrama 
(superestado) de um diagrama de alto-nível; a simbologia 
utilizada corresponde a uma caixa arredondada representando 
o superestado e contendo todos seus subestados.
podem também ser expandidos em diagramas 
de estados subordinados. Os eventos podem ser organizados 
numa hierarquia de generalização com herança dos atributos 
de eventos. A hierarquia de eventos permite que diferentes 
níveis de abstração sejam usados em diferentes lugares num 
modelo.
1.4
Um modelo dinâmico descreve um conjunto de objetos 
concorrentes, cada um com seu próprio diagrama de estados. 
Os objetos num sistema são inerentemente concorrentes e 
podem mudar de estados de forma independente. O estado 
do sistema total é o resultado dos estados de todos os seus 
objetos. Um diagrama de estados no caso da junção (assembly) 
de objetos através de agregação (relação “and”) é uma 
coleção de diagrama de estados, concorrentes, um para cada 
169
Análise de Sistemas II 34
componente. Entretanto, em vários casos, os estados dos 
componentes interagem; transições guardadas para um objeto 
podem depender do estado de outro objeto.
A concorrência pode também ocorrer dentro do estado 
de um único objeto, quando o objeto pode ser particionado 
em subconjuntos de atributos ou ligações, cada um com seu 
próprio subdiagrama; na notação adotada, os subdiagramas 
são separados por linhas pontilhadas.
2
O modelo funcional descreve os aspectos do sistema que 
dizem respeito com as transformações de valores: funções, 
mapeamentos, restrições e dependências funcionais. Este 
modelo captura o sistema faz sem levar em conta o 
e o ele faz.
O modelo funcional é representado por vários diagramas 
valores e o cálculo de valores de saída a partir de valores de 
entrada e de funções. O modelo funcional inclui também as 
restrições entre valores no modelo objeto.
2.1
O modelo funcional consiste de múltiplos diagramas de 
a relação funcional dos valores calculados pelo sistema, 
incluindo valores de entrada, saída e armazenamento de 
dados internos.
Um DFD contém que transformam dados, 
que movimentam dados, objetos 
que produzem e consomem dados, objetos 
que estocam os dados.
. Um processo transforma valores de dados. 
Um processo é implementado como um método de uma 
operação de uma classe de objetos. O objeto alvo é usualmente 
objeto alvo é implícito.
ou processo Ele representa um valor de dados intermediário 
dados.
. Um ator é um objeto ativo que conduz o diagrama 
dados. Eles podem ser vistos como fontes e receptores de 
dados.
. Um armazenador de dados 
armazena dados para um acesso futuro. Como no caso de um 
ator, um armazenador não gera operações sobre ele mesmo, 
mas simplesmente responde a pedidos para armazenar e 
acessar dados. O acesso pode ser feito em ordem diferente do 
armazenamento. Destaca- se que atores e armazenadores de 
dados são objetos que se diferenciam pelo seu comportamento 
e uso; atores podem ainda ser implementados como 
dispositivos externos e armazenadores como arquivos.
. Um DFD 
é particularmente útil para mostrar a funcionalidade de alto-
nível de um sistema e sua quebra em unidades funcionais 
menores. Um processo pode ser expandido num outro DFD 
no qual as entradas e saídas dos processos o são também no 
novo diagrama. Eventualmente, o aninhamento de diagramas 
como operações.
. Um DFD não mostra quais 
caminhos são executados e em que ordem. Decisões e 
sequenciamento são questões de controle que fazem parte do 
booleana que indica quando um processo pode ser realizado; 
no DFD, que vai de um processo que gera uma variável 
booleana ao processo a ser controlado) não é um valor de 
entrada para o processo.2.1.1 - Especificando operações
Processos em DFD devem eventualmente ser 
implementados como operações sobre objetos. Para cada 
nível baixo, um processo é uma operação. Processos de nível 
elevado podem também ser considerados operações. Uma 
implementação pode ser organizada de forma diferente da que 
o DFD representa por causa de otimização. Cada operação 
funções matemáticas, tabelas de valores de entrada e saída, 
pós-condições, tabelas de decisão, pseudocódigo (algoritmos) 
e linguagem natural.
3 - Comparações entre modelos
Cada modelo descreve um aspecto do sistema, mas 
contém referencias aos outros modelos. O modelo objeto 
descreve a estrutura de dados sobre a qual os modelos 
dinâmico e funcional operam. As operações no modelo objeto 
correspondem aos eventos no modelo dinâmico e as funções 
no modelo funcional.
O modelo dinâmico descreve a estrutura de controle dos 
funções no diagrama funcional. Os eventos no diagrama de 
estados se tornam as operações no modelo objeto.
O modelo funcional descreve as funções invocadas pelas 
operações no modelo objeto e ações no modelo dinâmico. 
pelo modelo objeto. O modelo funcional mostra ainda as 
restrições sobre os valores objeto.
Seções de estudo
170
35
Vimos que um é caracterizado pelos valores dos 
atributos e pelas ligações mantidas por um o. Um é 
algo que ocorre num instante de tempo e que não tem duração 
e um cenário é uma sequência de eventos que ocorre durante 
uma execução particular de um sistema.
Estudamos nesta seção que o modelo funcional 
descreve os aspectos do sistema que dizem respeito com as 
transformações de valores: funções, mapeamentos, restrições 
e dependências funcionais. Este modelo captura o 
sistema faz sem levar em conta o e o ele faz.
Nesta seção, vimos uma comparação do que foi estudado 
entre os modelos dinâmico e funcional.
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
UNICAMP. Modelagem Dinâmica. Disponível por www 
em: http://www.ic.unicamp.br/~ariadne/mc436/1s2013/
cap5.pdf. Acesso em 10/11/2013
pena acessar
Minhas anotações
171
6ºAula
Projeto orientado a objetos
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
• compreender a importância de se projetar um sistema;
• saber as características de qualidades desejáveis em um projeto;
• entender os conceitos de projeto de sistema e projeto de objetos.
Prezados (as) alunos (as),
Nesta aula, estudaremos alguns conceitos do projeto 
orientado 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!
173
Análise de Sistemas II 38
Seções de estudo
1 – Introdução
2 – Projeto de sistema
3 – Projeto de objeto
1 - Introdução
Uma grande parte dos desenvolvedores de software 
“torcem o nariz” para o trabalho de projeto de software partindo 
uma linguagem de programação que esteja sendo bem 
o que realmente importa, projetar é tempo perdido enquanto 
poderia estar desenvolvendo o programa.
Esta visão romântica e “suicida” hoje em dia não tem mais 
fundamento. Devido ao aumento da complexidade dos projetos 
de software realizar um planejamento profundo do projeto é 
crucial. O cliente precisa entender o que o desenvolvedor 
está fazendo e precisa ter condições de indicar alterações nas 
funcionalidades do projeto. Para isso, é necessário um canal 
de comunicação onde a linguagem usada seja compreensível 
pela equipe de desenvolvimento e pelo cliente. A chave 
para este processo ser bem sucedido é organizar o processo 
de desenvolvimento de forma a envolver programadores, 
analistas e clientes no desenvolvimento do sistema usando uma 
linguagem que seja de fácil entendimento a todos.
O Projeto Orientado a Objetos se dedica a desenvolver 
um modelo orientado a objetos de um sistema de software para 
implementar os requisitos. Os objetivos em um projeto OO 
que está sendo 
resolvido.
Embora a tecnologia orientada a objetos não seja nova, 
o Projeto Orientado a Objetos é uma abordagem inovadora 
para o desenvolvimento do software que, se bem implementada, 
trará benefícios substanciais para o aumento da produtividade 
com qualidade. É necessário, no entanto, que se consiga 
transpor as razões habituais de resistência para adoção de 
novas tecnologias.
Algumas das vantagens do Projeto OO:
• facilidade de manutenção. Objetos podem ser 
entendidos como entidades independentes;
• os objetos são componentes potencialmente 
reutilizáveis;
• para vários sistemas, existe um nítido mapeamento 
entre as entidades do mundo real para objetos do 
sistema.
Se existem vantagens, porque muitas empresas não 
adotaram ainda o projeto orientado a objetos? Alguns dos 
motivos apontados são:
• incerteza;
• falta de pessoas treinadas (know-how);
• ferramentas imaturas
• 
não orientadas a objetos.
Além dos benefícios citados anteriormente, outros 
Deve haver uma maior reutilização do software, acarretando 
ganhos de performance na construção de novos sistemas. 
Todos estes aspectos conduzem a vantagens econômicas. 
A partir da década de 90, as aplicações se tornaram 
mais complexas, demorando mais tempo para serem 
executadas e apresentando um índice proporcionalmente 
maior de falhas. O tempo e o dinheiro necessários para 
a manutenção dessas aplicações também aumentaram 
substancialmente.
A fase de projeto é responsável por incorporar requisitos 
tecnológicos aos requisitos essenciais. Assim, o projetista 
deverá estar atento aos critérios de qualidade que o sistema 
terá que atender.
O projeto OO modela a solução e consiste das atividades 
de criação (como pode ser feito), enquanto que a análise 
modela o problema e consistem das atividades necessárias 
para entender o domínio do problema (o que deve ser feito).
A qualidade do projeto pode ser medida conforme os 
requisitos citados a seguir:
adequação, acurácia, interoperabilidade, segurança de acesso 
e conformidade.
software 
manter seu nível de desempenho, sob condições estabelecidas, 
por um período de tempo. Tem como sub- características: 
maturidade, tolerância a falhas, recuperabilidade e 
conformidade.
refere-se ao esforço necessário para se 
utilizar um produto de software, bem como o julgamento 
individual de tal uso por um conjunto de usuários. Tem 
como sub-características: inteligibilidade, apreensibilidade, 
operacionalidade, atratividade e conformidade.
diz respeito ao relacionamento entre o nível 
de desempenho do software e a quantidade de recursos utilizados 
sob condições estabelecidas. Tem como sub-características: 
comportamento em relação ao tempo, comportamento em 
relação aos recursos e conformidade.
concerne ao esforço necessário 
software. Tem como sub-
testabilidade e conformidade.
software ser 
transferido de um ambiente para outro. Tem como sub-
características: adaptabilidade, capacidade para ser instalado, 
coexistência, capacidade para substituir e conformidade.
174
39
2
O projeto do sistema consiste em tomar decisões de alto 
nível sobre o como o problema será resolvido e a solução 
construída. O projeto de sistemas inclui decisões sobre a 
arquitetura do sistema, sobre a organização do sistema em 
subsistemas, a alocação de subsistemas, a componentes de 
hardware ou de software e sobre a política e a estratégia que 
formam o quadro no qual o projeto detalhado poderá ser 
desenvolvido.
O projetista do sistema deve tomar as seguintes decisões:
 -
funções do sistema, dividindo a função principal em 
sub-funções, que pode ser horizontal, mostrando 
sub-funções no mesmo nível, ou vertical dividindo 
cada função em funções menores.
 -
um mesmo problema e como estas tarefas deverão 
 -
Determinar quais equipamentos e programas serão 
alocados para cada partedo sistema como um todo.
 -
Escolher o tipo de metodologia e estruturas de 
dados serão utilizadas para os bancos de dados.
 -
disponibilizados para seus usuários e como será o 
gerenciamento destes acessos;
 -
utilização, solicitações e alterações.
 -
Preparar o sistema e as pessoas para tratar com 
as situações limites, ou seja, situações e valores 
que exigirão do sistema uma validação correta e 
um tratamento adequado quando o as funções 
processamento normal.
 -
Estabelecer que tarefas deverão ser executadas 
primeiro, baseados na necessidade da empresa e nas 
solicitações do usuário.
3
completas das classes e associações utilizadas na 
implementação, bem como as interfaces e os algoritmos 
dos métodos utilizados para por em prática as operações. 
Nesta fase, são adicionados objetos internos para a 
implantação e otimizadas as estruturas de dados e os 
algoritmos. O projetista deverá escolher entre várias formas 
de implementação, levando em conta questões como 
minimização do tempo de execução, da memória e outras 
medidas de custo. A otimização do projeto deve ainda levar 
em conta as facilidades de implementação, manutenção e 
expansão.
Durante o projeto do objeto, o projetista deve realizar os 
passos seguintes:
• combinar os três modelos para obter as operações 
sobre as classes;
• projetar os algoritmos para realizar as operações;
• otimizar os caminhos de acesso aos dados;
• implementar o controle para as interações 
externas;
• ajustar a estrutura de classes para adicionar a 
herança;
• realizar o projeto das associações;
• determinar a representação do objeto;
• empacotar classes e associações nos módulos;
• documentar as decisões de projeto.
Retomando a aula
Todo sistema precisa ser construído baseado em um 
projeto, para que tenha um mínimo de qualidade.
No Projeto Orientado a Objetos é desenvolvido um 
modelo orientado a objetos de um sistema de software para 
implementar os requisitos. Os objetivos em um projeto OO 
resolvido.
sistema; a organização do sistema em subsistemas; a alocação 
de subsistemas; componentes de hardware ou de software; a 
política e a estratégia que formam o quadro no qual o projeto 
detalhado poderá ser desenvolvido.
das classes e associações utilizadas na implementação, assim 
como as interfaces e os algoritmos dos métodos utilizados 
para por em prática as operações.
175
Análise de Sistemas II 40
Vale a pena
DEVMEDIA. Análise e projeto orientado a objetos. 
Disponível por www em http://www.devmedia.com.br/
curso/analise-e-projeto-orientado-a-objetos/336. Acesso 
em 10/10/2013.
UNESP. Projeto orientado a objetos. Disponível por www 
em http://www.dcce. ibilce.unesp.br/~ines/cursos/eng_
soft/2006/aula11_ProjetoOrientadoObjeto.pdf. Acesso 
em 10/10/2013.
pena acessar
Minhas anotações
176
7ºAula
UML Linguagem de Modelagem 
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
• entender os objetivos da UML;
• conhecer a importância da linguagem UML;
• estudar os principais diagramas pertencentes a esta linguagem;
• compreender para quê serve cada um dos diagramas que fazem parte da linguagem.
Prezados (as) alunos (as),
Nesta sétima aula, estudaremos a UML, uma linguagem de 
modelagem unificada, que foi criada para facilitar o trabalho de 
modelagem do sistema de forma padronizada.
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!
177
Análise de Sistemas II 42
Seções de estudo
1 – O que é UML?
2 – Diagramas
1
O desenvolvimento de sistemas de software de grande 
porte é suportado por métodos de análise e projeto que 
modelam esse sistema de modo a fornecer para toda a equipe 
envolvida (cliente, analista, programador, etc.) uma 
compreensão única do projeto.
A UML ( ) é o sucessor de 
um conjunto de métodos de análise e projeto orientados a 
padronização pela OMG (Object Management Group).
A UML foi criada por três grandes desenvolvedores 
de sistemas orientados a objetos: Grady Booch, James 
Rumbaugh, e Ivar Jacobson, que já haviam criado outras 
notações de desenvolvimento de software. A UML se baseia 
de abstração. O desenvolvimento de um sistema em UML 
divide-se em cinco fases: análise de requisitos, análise, 
projeto (design), implementação (programação) e testes. UML 
grupos de desenvolvimento de software interpretem de uma 
maneira correta e sem ambiguidades modelos gerados por 
outros analistas ou grupos de desenvolvimento.
A UML é um modelo de linguagem, não um método. Um 
método pressupõe um modelo de linguagem e um processo. 
O modelo de linguagem é a notação que o método usa para 
descrever o projeto. Os processos são os passos que devem 
ser seguidos para se construir o projeto.
O modelo de linguagem é uma parte muito importante 
do método. Corresponde ao ponto principal da comunicação. 
Se uma pessoa quer conversar sobre o projeto, como outra 
pessoa, é através do modelo de linguagem que elas se 
entendem. Nessa hora, o processo não é utilizado.
vistos no modelo (retângulo, setas, o texto, etc.), é a sintaxe 
do modelo de linguagem. A notação do diagrama de classe 
associação e multiplicidade.
maneira mais rigorosa a notação.
Neste capítulo, apresentaremos a notação UML através 
2 - Diagramas
em uma visão do sistema, sendo esta visão chamada de 
modelo.
A UML consiste de um certo número de elementos 
UML é uma linguagem, ela possui regras para combinar estes 
elementos nos diversos diagramas.
Podemos dizer que um modelo UML pode ser visto 
como um conjunto de diagramas que podem ser examinados 
sistema de software.
Os diagramas utilizados pela UML são compostos de 
nove tipos: diagrama de use-case, de classes, de objeto, de estado, 
de sequência, de colaboração, de atividade, de componente e 
o de execução.
Todos os sistemas possuem uma estrutura estática e 
um comportamento dinâmico. A UML suporta modelos 
estático (estrutura estática), dinâmico (comportamento 
dinâmico) e funcional. A Modelagem estática é suportada 
pelo diagrama de classes e de objetos, que consiste nas 
classes e seus relacionamentos. Os relacionamentos podem 
ser de associações, herança (generalização), dependência ou 
diagramas de estado, sequência, colaboração e atividade. 
E a modelagem funcional é suportada pelos diagramas de 
componente e execução.
Abordaremos rapidamente cada um desses tipos de 
diagrama:
2.1 - Diagrama Use-Case
A modelagem de um diagrama use-case (caso de uso) é 
funcionais de um sistema. Eles são escritos em termos de 
atores externos, use-cases e o sistema modelado.
Os componentes do diagrama Use-Case são:
– é quem solicita ações e eventos do sistema e tem 
o retorno dos resultados destas ações. Um mesmo ator pode 
participar de vários casos de uso;
– é um documento narrativo que descreve 
a sequência dos eventos solicitados ou retornados a um ator;
– o sistema em si que está sendo modelado.
Os atores representam o papel de uma entidade externa 
ao sistema como um usuário, um hardware, ou outro sistema 
que interage com o sistema modelado. Ivan Jacobson (2005)
“documento narrativo que descreve 
a sequência de eventos de um ator que usa um sistema para completar 
um processo”.
seguintes perguntas:
 -
 -
 -
 -
Respondendo a estas quatro perguntas poderemos 
perceber quais são os atores de um sistema. Os atores iniciam 
a comunicação com o sistema através dos use-cases, onde o 
use-case representa uma sequência de ações executadas pelo 
sistema e recebe do ator que lhe utiliza dados tangíveis de 
um tipo ou formato já conhecido, e o valor de resposta da 
execução de um use-case (conteúdo) também já é de um tipo 
178
43
através de texto de documentação.
A notação usada pelo Diagrama “Use Case” é:
Atores e use-cases são classes. Um ator é conectado 
a um ou mais use- cases através de associações, e tanto 
atoresquanto use-cases podem possuir relacionamentos de 
herança em superclasses especializadas em subclasses.
O uso de use-cases em colaborações é muito importante, 
onde estas são a descrição de um contexto, mostrando classes/
como as classes/objetos interagem para executar uma 
por diagramas de atividades e um diagrama de colaboração.
Figura 7.1. Exemplo de diagrama de use-case. Fonte: Acervo pessoal
use-case é implantado, a responsabilidade 
operações necessárias dentro destas classes juntamente com 
instância de um use-case, ou de uma colaboração, mostrando 
importante exemplo de um use-case ou de uma colaboração. 
use-case, apenas a interação entre 
o ator externo e o use-case é vista, mas já observando em nível 
de uma colaboração, todas as interações e passos da execução 
O diagrama de use-case acima demonstra as funções 
de um ator externo de um sistema de controle bancário de 
o administrador do banco poderá desempenhar. Pode-
se perceber que não existe nenhuma preocupação com a 
implementação de cada uma destas funções, já que este 
diagrama apenas se resume a determinar que funções deverão 
ser suportadas pelo sistema modelado.
Use-cases são interações entre os atores e o sistema. 
Existem ações do ator e ações do sistema, mas os atores são 
sempre quem iniciam a ação.
Num exemplo prático, vamos supor que precisamos 
modelar o diagrama de use-case para um sistema de venda de 
uma loja de roupas com um terminal de caixa.
Neste exemplo os atores seriam: o e o Terminal 
do Caixa. Devemos ter em mente que um ator é sempre 
alguém ou algo que interage com o sistema não faz parte 
dele, o ator é sempre externo ao sistema, portanto o próprio 
sistema nunca pode ser um ator dele mesmo, em casos em 
que ações pareçam ser iniciadas pelo sistema, na verdade 
usaremos atores como Gerente ou Administrador.
À ação de realizar a compra de um item nós chamaremos 
de 
atualizar preço, cadastrar cliente, etc.), este será nosso use-case.
Figura 7.2. Diagrama use-case - Compra Item. Fonte: Acervo pessoal 
Precisaremos fazer uma descrição textual do caso de uso 
, onde atuam os atores cliente e caixa, como 
veremos no exemplo a seguir:
Use-case: 
Atores: 
Descrição: O 
Este é um exemplo de caso de uso sem detalhamento 
(detalhar) este diagrama, separando as diversas ações que 
envolvem a ação de Comprar item, conforme foi citado na 
descrição acima.
2.2 - Diagrama de Classes
O diagrama de classes demonstra a estrutura estática 
das classes de um sistema em que essas classes representam 
as “coisas” que são gerenciadas pela aplicação modelada. 
Classes podem se relacionar com outras através de diversas 
maneiras: associação (conectadas entre si), dependência (uma 
classe depende ou usa outra classe), especialização (uma 
classe é uma especialização de outra classe), ou em pacotes 
(classes agrupadas por características similares). Todos esses 
relacionamentos são mostrados no diagrama de classes 
juntamente com as suas estruturas internas, que são os 
atributos e operações. O diagrama de classes é considerado 
estático já que a estrutura descrita é sempre válida em qualquer 
ponto do ciclo de vida do sistema. Um sistema normalmente 
possui alguns diagramas de classes, já que não são todas as 
classes que estão inseridas em um único diagrama e uma certa 
179
Análise de Sistemas II 44
classe pode participar de vários diagramas de classes.
Figura 7.3. Diagrama de Classes – Uma simples representação de uma empresa 
de aluguel de veículos. Fonte: Acervo pessoal
Uma classe num diagrama pode ser diretamente colocada 
em prática utilizando-se uma linguagem de programação 
orientada a objetos que tenha suporte direto para construção 
de classes. Para criar um diagrama de classes, as classes têm 
2.3
O diagrama de objetos é uma variação do diagrama de 
classes e utiliza quase a mesma notação. A diferença é que o 
diagrama de objetos mostra os objetos que foram instanciados 
sistema em um certo momento de sua execução. A mesma 
notação do diagrama de classes é utilizada com 2 exceções: os 
objetos são escritos com seus nomes sublinhados e todas as 
instâncias num relacionamento são mostradas. Os diagramas 
de objetos não são tão importantes como os diagramas de 
complexos de classes ajudando muito em sua compreensão. 
Diagramas de objetos também são usados como parte dos 
diagramas de colaboração, onde as colaborações dinâmicas 
entre os objetos do sistema são mostradas.
Figura 7.4. Diagrama de Objetos. Fonte: Acervo pessoal
se relaciona de 
1 para n com , por isso, um objeto da 
classe cliente pode ter 1 ou vários contratos.
2.4 - Diagrama de Estado
O diagrama de estado é tipicamente um complemento 
para a descrição das classes. Este diagrama mostra todos os 
estados possíveis que objetos de uma certa classe podem se 
encontrar e mostra também quais são os eventos do sistemas 
que provocam tais mudanças. Os diagramas de estado não 
são escritos para todas as classes de um sistema, mas apenas 
conhecidos e onde o comportamento das classes é afetado e 
Diagramas de estado capturam o ciclo de vida dos 
objetos, subsistemas e sistemas. Eles mostram os estados 
que um objeto pode possuir e como os eventos (mensagens 
recebidas, timer, erros, e condições sendo satisfeitas) afetam 
estes estados ao passar do tempo.
Diagramas de estado possuem um ponto de início e 
inicial) é mostrado como um círculo todo preenchido, e um 
círculo em volta de um outro círculo menor preenchido. 
Um estado é mostrado como um retângulo com cantos 
arredondados. Entre os estados estão as transições, mostradas 
A transição pode ser nomeada com o seu evento causador. 
outro é executada ou disparada.
Figura 7.5. Diagrama de Estados – Diagrama de estados de um elevador. Fonte: 
Acervo pessoal
Uma transição de estado normalmente possui um evento 
ligado a ela. Se um evento é anexado a uma transição, esta será 
executada quando o evento ocorrer. Se uma transição não 
possuir um evento ligado a ela, a mesma ocorrerá quando a 
ação interna do código do estado for executada (se existir ações 
desenvolvedor). Então, quando todas as ações forem executadas 
pelo estado, a transição será disparada e serão iniciadas as 
atividades do próximo estado no diagrama de estados.
2.5 
O diagrama de sequência mostra a interação entre os 
objetos ao longo do tempo, apresentando os objetos que 
participam da interação e a sequência de mensagens trocadas.
Esse diagrama mostra a colaboração dinâmica entre os 
vários objetos de um sistema. O mais importante aspecto 
desse diagrama é que a partir dele percebe-se a sequência de 
mensagens enviadas entre os objetos. Ele mostra a interação 
entre os objetos, alguma coisa que acontecerá em um ponto 
consiste em um número de objetos mostrados em linhas 
verticais. O decorrer do tempo é visualizado observando-
se o diagrama no sentido vertical de cima para baixo. As 
mensagens enviadas por cada objeto são simbolizadas por 
180
45
setas entre os objetos que se relacionam.
Diagramas de sequência possuem dois eixos: o eixo 
vertical, que mostra o tempo e o eixo horizontal, que mostra os 
objetos envolvidos na seqüência de uma certa atividade. Eles 
certa atividade do sistema.
No eixo horizontal estão os objetos envolvidos na 
sequência. Cada um é representado por um retângulo de 
objeto (similar ao diagrama de objetos) e uma linha vertical 
pontilhada chamada de linha de vida do objeto, indicando 
a execução do objeto durante a sequência, como exemplo 
citamos: mensagens recebidas ou enviadas e ativação de 
objetos. A comunicação entre os objetos é representada como 
linha com setas horizontais simbolizando as mensagens entre 
é síncrona, assíncrona ou simples. As mensagens podem 
possuir também números sequenciais, que são utilizados para 
tornar mais explícitas as sequências no diagrama.
Em alguns sistemas, objetos rodam concorrentemente, 
cada um com sua linha de execução (thread). Se o sistema 
usa linhas concorrentes de controle, isso é mostrado como 
ativação, mensagensassíncronas, ou objetos assíncronos.
Figura 7.6. Diagrama de Seqüência – Servidor de Impressão. Fonte: Acervo 
pessoal
Os diagramas de sequência podem mostrar objetos que 
são criados ou destruídos como parte do cenário documentado 
pelo diagrama. Um objeto pode criar outros objetos através 
de mensagens. A mensagem que cria ou destrói um objeto é 
geralmente síncrona, representada por uma seta sólida.
2.6 - Diagrama de Colaboração
Um diagrama de colaboração mostra de maneira 
semelhante ao diagrama de sequência, a colaboração dinâmica 
entre os objetos. Normalmente pode-se escolher entre utilizar 
o diagrama de colaboração ou o diagrama de sequência.
No diagrama de colaboração, além de mostrar a troca de 
mensagens entre os objetos, percebe-se também os objetos 
com os seus relacionamentos. A interação de mensagens é 
mostrada em ambos os diagramas. Se a ênfase do diagrama 
for o decorrer do tempo, é melhor escolher o diagrama de 
sequência, mas se a ênfase for o contexto do sistema, é melhor 
dar prioridade ao diagrama de colaboração.
O diagrama de colaboração é desenhado como 
um diagrama de objeto, em que os diversos objetos são 
mostrados juntamente com seus relacionamentos. As 
setas de mensagens são desenhadas entre os objetos para 
nomeadas, que entre outras coisas mostram a ordem em 
que as mensagens são enviadas. Também podem mostrar 
condições, interações, valores de resposta, entre outros. O 
diagrama de colaboração também pode conter objetos ativos, 
que executam paralelamente com outros.
Figura 7.7. Diagrama de Colaboração – Servidor de Impressão. Fonte: Acervo 
pessoal
2.7 - Diagrama de Atividade
Diagramas de atividade capturam ações e seus resultados. 
Eles focam o trabalho executado na realização de uma 
operação (método), e suas atividades numa instância de um 
objeto. O diagrama de atividade é uma variação do diagrama 
de estado e possui um propósito um pouco diferente do 
diagrama de estado, que é o de capturar ações (trabalho e 
atividades que serão executados) e seus resultados em termos 
das mudanças de estados dos objetos.
Os estados no diagrama de atividade mudam para um 
próximo estágio quando uma ação é executada (sem ser 
de estado). Outra diferença entre o diagrama de atividade e 
o de estado é que podem ser colocadas como “swimlanes”. 
Uma swimlane agrupa atividades, com respeito a quem é 
responsável e onde estas atividades residem na organização, e 
é representada por retângulos que englobam todos os objetos 
que estão ligados a ela (swimlane).
Um diagrama de atividade é uma maneira alternativa de 
se mostrar interações, com a possibilidade de expressar como 
as ações são executadas, o que elas fazem (mudanças dos 
estados dos objetos), quando elas são executadas (sequência 
das ações), e onde elas acontecem (swimlanes).
Um diagrama de atividade pode ser usado com diferentes 
propósitos inclusive:
• Para capturar os trabalhos que serão executados 
quando uma operação é disparada (ações). Este é o 
uso mais comum para o diagrama de atividade.
• Para capturar o trabalho interno em um objeto.
• Para mostrar como um grupo de ações relacionadas 
pode ser executado, e como elas vão afetar os 
objetos em torno delas.
• Para mostrar como uma instância pode ser executada 
em termos de ações e objetos.
• Para mostrar como um negócio funciona em 
organização, e objetos (fatores físicos e intelectuais 
usados no negócio).
181
Análise de Sistemas II 46
das atividades é normalmente utilizado para demonstrar as 
de uma atividade a ser desempenhada por uma operação 
do sistema. Decisões e condições, como execução paralela, 
também podem ser mostradas no diagrama de atividade. O 
enviadas e recebidas como partes de ações executadas.
Figura 7.8. Diagrama de Atividade – Servidor de Impressão. Fonte: Acervo pessoal
2.8 - Diagrama de Componente
Um componente pode ser tanto um código em 
linguagem de programação como um código executável já 
compilado. Por exemplo, em um sistema desenvolvido em 
Java, cada arquivo .java ou .class é um componente do sistema, 
e será mostrado no diagrama de componentes que os utiliza.
Figura 7.9. Exemplos de componentes. Fonte: Acervo pessoal
O diagrama de componente e o de execução são 
diagramas que mostram o sistema por um lado funcional, 
expondo as relações entre seus componentes e a organização 
de seus módulos durante sua execução.
O diagrama de componente descreve os componentes de 
software e suas dependências entre si, representando a estrutura 
do código gerado. Os componentes são a implementação na 
na arquitetura lógica (classes, objetos e seus relacionamentos). 
Eles são tipicamente os arquivos realizados no ambiente de 
desenvolvimento.
Um componente é mostrado em UML como um 
retângulo com uma elipse e dois retângulos menores do seu 
lado esquerdo. O nome do componente é escrito abaixo ou 
dentro de seu símbolo.
A dependência entre componentes pode ser mostrada 
como uma linha tracejada com uma seta, simbolizando que 
completa. Por exemplo, com o diagrama de componentes é 
facilmente visível detectar que arquivos .dll são necessários 
para executar a aplicação.
para outros componentes. As interfaces podem ser tanto 
interfaces binárias usadas em run-time (tempo de execução). 
Uma interface é mostrada como uma linha, partindo do 
componente e com um círculo na outra extremidade. O nome 
entre componentes podem então apontar para a interface do 
componente que está sendo usada.
Figura 7.10. Diagrama de Componentes. Fonte: Acervo pessoal
2.9
O diagrama de execução mostra a arquitetura física do 
hardware e do software no sistema. Pode mostrar os atuais 
computadores e periféricos, juntamente com as conexões 
que eles estabelecem entre si e pode mostrar também os 
tipos de conexões entre esses computadores e periféricos. 
objetos que são alocados para mostrar quais unidades de 
software são executados e em quais destes computadores são 
executados.
Figura 7.11. Diagrama de Execução – Associações entre Nodes. Fonte: Acervo 
pessoal
O diagrama de execução demonstra a arquitetura run-
time de processadores, componentes físicos (devices), e de 
software que rodam no ambiente onde o sistema desenvolvido 
será utilizado. É a última descrição física da topologia do 
sistema, descrevendo a estrutura de hardware e software que 
executam em cada unidade.
O diagrama de execução é composto por componentes 
que possuem a mesma simbologia dos componentes do 
diagrama de componentes, nodes
físicos que fazem parte do sistema, podendo ser uma máquina 
cliente numa rede local (LAN), uma máquina servidora, uma 
impressora, um roteador, etc., e conexões entre estes nodes e 
182
47
componentes que juntos compõem toda a arquitetura física 
do sistema.
Retomando a aula
A UML, como resultado da fusão de conceitos dos 
de modelagem simples, comum e largamente utilizável por 
usuários destes e de outros métodos. A UML não é um 
processo, nem uma ferramenta, nem uma linguagem de 
programação. Seu objetivo principal é gerar a modelagem dos 
objetos do mundo real garantindo a interoperabilidade dos 
recursos envolvidos no processo de desenvolvimento.
Um Diagrama é uma visão do modelo, apresentado 
da perspectiva de um observador em particular. Fornece 
uma representação parcial do sistema e é semanticamente 
consistente com outras visões.
Os modelos dinâmicos são suportados pelos diagramas 
de estado, sequência, colaboração e atividade. E a modelagem 
funcional é suportada pelos diagramas de componente e 
execução.
Vale a pena
BOOCH, Grady, JACOBSON, Ivar; RUMBAUGH, 
James. UML – guia do usuário. Elsevier, Rio de Janeiro. 
2005.
SOMMERVILLE, I. Engenharia de Software. 8ª Edição. 
Addison Wesley, 2007.
pena ler
Minhas anotações
183
8ºAula
Reusabilidade: Frameworks e 
Design Patterns
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
• entender a importância do conceito de reusabilidade;
• conhecer o que são os Frameworks;
• entender os Design Patterns.
Prezados(as) alunos(as),
Nestaoitava e última aula, estudaremos os conceitos de 
reusabilidade através das estruturas de Frameworks e Design 
Patterns.
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!
185
Análise de Sistemas II 50
Seções de estudo
1 – Frameworks
2 – Patterns
3 – Principais diferenças entre Frameworks e Design Patterns
1 - Frameworks
requisitos do sistema a ser desenvolvido tem como 
consequência direta a garantia de boa qualidade do serviço e 
satisfação do pessoal envolvido.
Observando os requisitos de vários sistemas, percebemos 
que muitas aplicações de propósitos semelhantes possuem 
muitas características que são comuns entre elas e ao mesmo 
feitos para um mesmo ramo de atividade. Por exemplo, um 
sistema de vídeo locadora tem uma série de características 
que são usadas da mesma forma em todas as vídeo 
locadoras, porém, muitas particularidades serão sugeridas 
pelo cliente (responsável pela contratação do serviço) e estas 
particularidades nem sempre serão aceitas em outras lojas.
Visando facilitar o trabalho da equipe responsável 
pelo sistema, pode- se projetar uma arquitetura genérica do 
sistema desejado com uma estrutura de classes que poderá 
ser implantada em qualquer loja. A esta arquitetura genérica 
chamamos de framework.
Um framework é então uma arquitetura genérica que 
implementa a arquitetura da solução para uma categoria 
de problema (ou domínio de aplicação). Ele deve ser visto 
como uma “caixa preta”, onde seus componentes podem ser 
utilizados sem que se saiba como foi feita sua implementação. 
Um conjunto de classes abstratas pode ser usado para 
expressar um projeto abstrato. Um framework é um conjunto 
de classes cooperantes que modelam um projeto reutilizável 
software.
framework, ainda, como uma estrutura 
de suporte que pode ser usada em vários projetos de software. 
Um framework pode incluir programas de suporte, scripts, 
bibliotecas de funções e outros softwares para auxiliar no 
desenvolvimento.
frameworks são 
somente bibliotecas de classes, quando na verdade são mais 
do que isto.
O objetivo é criar um esqueleto resultante da análise 
de um domínio particular de aplicação, representada por 
classes genéricas. Uma vez criado o esqueleto, reutiliza-se as 
framework
que está sendo trabalhada. Portanto, as classes genéricas 
contidas no framework 
2 - Patterns
Todas as arquiteturas de software orientado a objetos bem 
estruturadas estão cheias de padrões. A reusabilidade de 
software tem sido cada vez mais procurada, sendo considerada 
até como fator para medição da qualidade do software que está 
sendo projetado, ou seja, qual o grau de atenção que foi dada 
Apesar de ser citado por muitos autores como o tópico 
mais procurado na comunidade de orientação a objetos, 
o Padrão ainda é muito pouco conseguido, pois para ser 
várias vezes, conservando a arquitetura das classes 
padronizadas.
Os Patterns (Padrões) ajudam a criar uma linguagem 
compartilhada para troca de informações entre os problemas 
e suas soluções. Formando uma linguagem comum de 
Patterns para converter as estruturas e mecanismos de nossas 
arquiteturas, estaremos compreendendo a razão para utilizá-
los.
Cada padrão é uma regra de três partes, que expressam 
o relacionamento entre determinado contexto, um certo 
sistema de forças que ocorrem repetidamente neste contexto 
software que possibilita que 
estas forças trabalhem sobre o contexto. Em outras palavras, 
expressa o relacionamento entre o contexto, o problema e a 
solução.
Um pattern é um processo que gera uma solução, mas ele 
pode gerar qualquer uma de um grande número de soluções 
(considerando que não ocorra a mesma solução duas vezes). 
O elemento humano de patterns é o que certamente contribui 
para suas variações e adaptações, e geralmente requer um alto 
grau de criatividade na sua aplicação e combinação. Então, da 
mesma forma que os processos de arquitetura e projeto são 
esforços criativos, a aplicação do pattern também é.
Então, podemos ver que o Pattern envolve uma 
descrição geral de uma solução para um problema que ocorre 
periodicamente com várias metas. Mas ele faz mais do que 
solução é necessária.
Patterns, eles devem prover os 
seguintes:
• resolver o problema: Patterns capturam soluções, 
não apenas abstraem princípios ou estratégias;
• a solução não é óbvia: Muitas técnicas de solução de 
problemas tentam derivar as soluções dos primeiros 
princípios. O melhor Pattern gera uma solução 
para um problema indiretamente, uma passagem 
necessária para os problemas mais difíceis do 
projeto;
• ele descreve um relacionamento; Patterns não 
descrevem apenas módulos, mas descrevem 
profundamente estruturas de sistemas e mecanismos;
• o Pattern 
todos os softwares procuram fornecer conforto 
humano e qualidade de vida; o melhor Padrão 
186
51
explicitamente direciona para a estética e utilidade.
2.1 - Design Patterns 
Um Design Pattern 
dos subsistemas ou componentes de um software, ou o 
relacionamento entre eles. Comumente descreve a estrutura 
recorrente dos componentes de comunicação que resolvem 
um problema genérico de projeto num contexto particular.
Cada pattern deve ser formulado como uma regra que 
estabelece um relacionamento entre o contexto, um sistema 
faz com que estas forças resolvam-no neste contexto.
Um pattern, em geral, tem alguns elementos essenciais, 
a saber:
• o nome do pattern
palavra ou frase curta, que descreve um problema 
de projeto, suas soluções e consequências. Bons 
nomes de patterns formam um vocabulário para 
discussão das abstrações conceituais. Às vezes um 
pattern pode ter mais do que um nome reconhecível 
ou comumente usado na literatura. Neste caso 
é um hábito comum documentar estes apelidos, 
ou sinônimos, com o cabeçalho Alias ou Também 
conhecido como;
• o problema, que descreve quando o pattern deve 
ser aplicado, explica o problema e o contexto; uma 
estrutura do problema que descreve sua intenção: as 
metas e objetivos desejados;
• o , que descreve as pré-condições sobre 
que problema e que solução parecem ocorrer 
periodicamente e em que solução se deseja chegar. 
Ele nos informa a aplicabilidade do pattern;
• a , que descreve os elementos que compõem 
o projeto, seus relacionamentos, responsabilidades 
e colaborações. Relacionamentos estáticos e regras 
dinâmicas descrevem como produzir o efeito 
desejado. Isto é muitas vezes equivalente a obter 
instruções que descrevem como construir os 
produtos de trabalho necessários. A descrição pode 
do pattern, seus participantes e seus colaboradores, 
para mostrar como os problemas são resolvidos. 
A solução pode não descrever somente estruturas 
estáticas, mas também comportamentos dinâmicos. 
A estrutura estática nos diz a forma e organização do 
pattern, entretanto, é o comportamento dinâmico 
que faz o pattern tornar-se vivo. Algumas vezes, 
possíveis variações ou especializações da solução 
são também descritas;
• os 
inicial; como os patterns são aplicados e como 
transformam o contexto; e o contexto resultante 
deixado no seu rastro. Os exemplos ajudam o leitor 
a entender o uso e a aplicabilidade dos patterns. 
Exemplos visuais e analogias podem, entretanto, 
dar uma ajuda especial. Um exemplo pode ser 
suplementado por uma implementação de amostra 
para mostrar de uma vez que a solução pode ser 
realizada;
• e as , que são resultados, vantagens 
e desvantagens da aplicação do pattern.
2.2 - Patterns relacionados
O relacionamento estático e dinâmico entre este pattern 
e outros e a mesma linguagem ou sistema padrão. Patterns 
relacionados podem, entretanto, compartilhar forças. Ele 
também tem frequentemente um contexto inicial ou resultante 
que é compatível com o contexto inicial ou resultante de 
outro pattern.
2.3 - Idiomas
Um idioma é um Patternuma linguagem de programação. Um idioma descreve como 
implementar aspectos particulares dos componentes ou 
os relacionamentos entre eles usando as características da 
linguagem obtida.
2.4 - Qualidades de um Pattern
Um Pattern bem escrito pode exibir muitas qualidades 
desejáveis. A seguir vamos ver uma descrição detalhada destas 
qualidades.
2.5 - Encapsulamento e Abstração
Cada Pattern 
solução em um domínio particular. Patterns podem prover 
ondulações, fronteiras livres que ajudam a cristalizar o espaço 
do problema e da solução, parcelando-o em fragmentos 
distintos interconectados. Eles também servem como 
do domínio e podem ocorrer variando de níveis hierárquicos 
do domínio conceitual.
2.6 - Como escrever Patterns
Escrever bons Patterns é muito difícil. Patterns não podem 
prover fatos somente (como se fosse um manual de referência 
ou um guia do usuário), mas pode contar uma história que 
captura a experiência que eles estão tentando conduzir. Um 
Pattern pode ajudar seus usuários a: compreender o sistema 
existente; customizar o sistema para as necessidades do 
usuário; e construir novos sistemas. O processo de busca 
de Patterns para documentação é chamado de “mineração de 
Patterns
reversa).
Como reconhecer um pattern quando cruzar por um? 
É necessário anotar algumas coisas que você pensa que são 
patterns. Mas será preciso descartar algumas delas que não 
são pattern como um todo, ou elas são somente pedaços 
de patterns, ou simplesmente bons princípios ou regras de 
manuseio que podem formar partes de um pattern particular. 
É importante lembrar que a solução onde não há força 
presente, não é um pattern.
A melhor forma de aprender como reconhecer e 
documentar patterns úteis é aprendendo com outros que já o 
187
Análise de Sistemas II 52
descrevem patterns e tentar ver se você pode reconhecer todos 
os componentes necessários de um pattern e as qualidades 
ser um pattern, pergunte-se: Porque ele é bom?
3
Frameworks de Design Patterns
Design patterns são mais abstratos do que os frameworks. 
código. Um forte do framework é que ele pode ser escrito em 
linguagens de programação e não somente estudado, mas 
executado e reusado diretamente. Em contraste, Design 
Patterns precisam ser implementados cada vez que eles são 
usados. Design Patterns também expõem a intenção e as 
consequências de um projeto;
Design Patterns têm elementos de arquitetura menores 
que nos frameworks. Um framework típico contém muitos design 
patterns, mas o contrário nunca acontece;
Design Patterns são menos especializados do que 
frameworks. Frameworks sempre têm um domínio de aplicação 
particular. Em contraste, design patterns podem ser usados em 
quase todos os tipos de aplicações. Enquanto muitos design 
patterns especializados são certamente possíveis, estes não 
podem igualmente impor uma arquitetura de aplicação.
3.1 - Conclusões sobre a 
comparação
Os Patterns não garantem a reutilização do software ou 
alta produtividade, aliás, eles não garantem nada, não fazem 
nada que possa tirar a pessoa do processo criativo. Ele 
meramente traz esperança de fortalecimento para uma pessoa 
possivelmente inexperiente, porém capaz e criativa
Patterns são apenas mais uma arma no arsenal do 
desenvolvedor. Atribuir muito mais a ele é contra produtivo.
A utilização de Patterns acelera o processo criativo do 
métodos que são idênticos em muitos outros sistemas com a 
mesma aplicação.
A utilização de Patterns e Frameworks deverá se tornar um 
software
quem os está utilizando, ou seja, a criatividade e a percepção do 
como um todo deverá estar bem organizada para que se possa 
utilizar adequadamente estes dois recursos e assim aproveitar 
o máximo que eles oferecem.
Retomando a aula
 1 – 
Um framework é então uma arquitetura genérica que 
implementa a arquitetura da solução para uma categoria de 
problema (ou domínio de aplicação).
2 – 
Um Design Pattern 
dos subsistemas ou componentes de um software, ou o 
relacionamento entre eles. Comumente descreve a estrutura 
recorrente dos componentes de comunicação que resolvem 
um problema genérico de projeto num contexto particular.
e 
Design patterns são mais abstratos do que os frameworks. 
Frameworks patterns 
forte do framework é que ele pode ser escrito em linguagens 
de programação e não somente estudado, mas executado e 
reusado diretamente.
Vale a pena
________. Frameworks: conceitos gerais. Puc-Rio. 
Disponível por www em http:// www.maxwell.lambda.
ele.puc-rio.br/8623/8623_3.PDF. Acesso em 10/08/2013. 
CAVALHEIRO, Gerson. Framework. Universidade Federal 
de Pelotas. Disponível por www em http://
gersonc.anahy.org/reppoo/PooApoio14-Framework.pdf. 
Acesso em 30/08/2013.
pena ler
• LEITE, Alessandre Ferreira. Frameworks e padrões de 
projeto. Disponível por www em http://www.devmedia.
com.br/frameworks-e-padroes-de-projeto/1111. Acesso 
em 15/11/2013.
pena acessar
Referências
BOOCH, Grady, JACOBSON, Ivar; RUMBAUGH, 
James. UML – guia do usuário. Elsevier, Rio de Janeiro. 2005.
CAVALHEIRO, Gerson. Framework. Universidade 
Federal de Pelotas. Disponível por www em http://gersonc.
anahy.org/reppoo/PooApoio14- Framework.pdf. Acesso 
em 30/08/2013.
CAVALHEIRO, Gerson. Frameworks: conceitos gerais. 
188