Análise e Projeto de Sistemas de Informação II

Prévia do material em texto

ANÁLISE E PROJETO 
DE SISTEMAS E 
INFORMAÇÕES II
ANÁLISE E PROJETO 
DE SISTEMAS E 
INFORMAÇÕES II
Copyright © UVA 2020
Nenhuma parte desta publicação pode ser reproduzida por qualquer 
meio sem a prévia autorização desta instituição.
Texto de acordo com as normas do Novo Acordo Ortográfico 
da Língua Portuguesa.
AUTORIA DO CONTEÚDO
Claudio Ribeiro da Silva
Camilla Lobo Paulino
REVISÃO
Janaina Vieira
Lydianna Lima
PROJETO GRÁFICO
UVA
DIAGRAMAÇÃO
UVA
S586 Silva, Claudio Ribeiro da.
 Análise e projetos de sistemas e informações II [recurso eletrônico] / 
 Claudio Ribeiro da Silva. – Rio de Janeiro: UVA, 2021. 
 
 1 recurso digital (3092 KB)
 Formato: PDF
 ISBN 978-65-5700-095-3
 
 1. Análise de sistemas. 2. Projeto de sistemas. 3. Arquitetura de software. I. 
 Universidade Veiga de Almeida. II. Título. 
 
 
 CDD – 004.21
Bibliotecária Adriana R. C. de Sá CRB 7 – 4049.
Ficha Catalográfica elaborada pelo Sistema de Bibliotecas da UVA.
SUMÁRIO
Apresentação
Autores
6
7
Padrões de arquitetura de software 30
• Arquitetura baseada em componentes
• Padrão Model-View-Control (MVC)
• Padrão de projeto de software
UNIDADE 2
9
• A modelagem física de um sistema
• Mapeamento do projeto lógico para o físico
• A modularização de um sistema
A modelagem física de um sistema
UNIDADE 1
SUMÁRIO
Diagramas de implantação de um software 83
• Diagrama de Implementação
• Diagrama de Perfil
• Diagrama de Implantação
UNIDADE 4
59
• Diagrama de Pacotes
• Diagrama de Componentes
• Diagrama de Objetos
Diagramas estruturais da UML
UNIDADE 3
6
Desenvolver softwares é a capacidade que o profissional de Tecnologia de Informação 
(TI) possui de transformar pensamentos abstratos (apenas ideias), de quem precisa da 
informação, em algo concreto. Ao longo do tempo esse tem sido um dos principais de-
safios para o desenvolvedor de software “entregar exatamente aquilo que foi pedido”. 
Diversas metodologias surgiram para fazer com que essa transformação seja mais pa-
dronizada, definindo procedimentos aplicáveis para a maioria das soluções e que sejam 
compreendidos pelos profissionais que os conhecem. Essas metodologias evoluíram e, 
atualmente, os conceitos da Orientação a Objetos aplicados aos diagramas da lingua-
gem UML (Unified Modeling Language) vêm sendo os mais utilizados.
No passado era comum dividir o desenvolvimento de um software em duas etapas: o de-
senvolvimento conceitual, ou lógico, e o desenvolvimento físico. Embora o termo não seja 
tão utilizado no meio acadêmico, nós o faremos como referência para reunir um conjunto 
de ações que são realizadas no projeto de desenvolvimento de um sistema a partir da se-
guinte distinção: a modelagem conceitual é aquela em que não são observados aspectos 
relacionados à tecnologia. Ou seja, não importa qual a linguagem de programação a ser 
utilizada, arquitetura de software ou frameworks, o que importa são as funcionalidades que 
ela terá que possuir, a relação entre os dados que a aplicação irá manipular etc. A forma 
como a tecnologia pode evoluir, sejam “mil anos”, o seu modelo conceitual permanecerá o 
mesmo, desde que não tenha havido mudanças em suas regras de negócio ou nos resul-
tados esperados. 
O processo de construção dos diagramas utilizados para essa visão é apresentado em 
Análise e Projeto de Sistemas de Informação I, tais como a modelagem dos casos de usos, 
classes de negócios etc. Já no desenvolvimento do modelo físico ocorre exatamente o 
oposto: aspectos tecnológicos estão presentes e irão impactar diretamente o processo de 
construção do software até sua implantação. Daí a separação em duas grandes etapas — 
na primeira não se olha para tecnologias e na segunda elas são consideradas.
Assim, nesta disciplina olharemos um pouco mais para fatores tecnológicos que irão im-
pactar a elaboração do modelo físico de um sistema, com base nos diagramas estrutu-
rais e comportamentais da UML, para o desenvolvimento de soluções a serem utilizadas 
na implementação de um software.
APRESENTAÇÃO
7
CLAUDIO RIBEIRO DA SILVA
Claudio Ribeiro da Silva é doutor em Engenharia de Sistemas e Computação pelo Insti-
tuto Alberto Luiz Coimbra de Pós-Graduação e Pesquisa de Engenharia da Universidade 
Federal do Rio de Janeiro – COPPE/UFRJ, mestre em Ciência da Informação pela UFRJ, 
Pós-Graduado em Análise e Desenvolvimento de Sistemas pela Pontifícia Universidade 
Católica do Rio de Janeiro – PUC-RJ e graduado em Ciências Contábeis pela Faculdade 
de Administração São Paulo Apóstolo – Faspa. Professor dos cursos de graduação nas 
modalidades presencial e a distância na área de Gestão de Tecnologia da Informação, 
Sistema da Informação e Análise e Desenvolvimento de Sistemas. Experiência em gestão 
de cursos de graduação e pós-graduação em instituições universitárias e como gerente 
de equipes de desenvolvimento de sistemas. Tecnologista da Informação em autarquia 
federal de médio porte, tendo atuado na área de desenvolvimento, realizando atividades 
de desenvolvimento de software e gerenciamento de projetos nessa área.
AUTORES
8
CAMILLA LOBO PAULINO
Mestra em Educação pela Universidade Estácio de Sá – Unesa, especialista em Docência 
do Ensino Superior; especialista em Análise, Projeto e Gerência de Sistemas pela Unesa, 
graduada em Ciências da Computação pela Universidade Veiga de Almeida – UVA, certi-
ficada pela APMG US em COBIT 5 e ITIL v3 e certificada pela Escola de Design Thinking 
em Business Design. Coordenadora de Polos da Universidade Federal do Estado do Rio 
de Janeiro - Unirio (2008 -2009), coordenadora de Midiatização e professora (presencial 
e EAD) da Universidade Castelo Branco – UCB (2007 -2009). Desde 2002 professora da 
UVA, conteudista da Educação a Distância e consultora de Tecnologia e Inovação. 
Experiência de 23 anos na área coorporativa, atuando em projetos de TI em empresas de 
grande e médio porte. Suporte BackOffice, administração e gerenciamento de usuários, 
perfis, ajustes, customização e parametrização dos módulos do sistema (ERP), desen-
volvimento e manutenção de relatórios; projetos de implantação e reestruturação; treina-
mentos e capacitação; mapeamento, levantamento e automatização de processos; expe-
riência em Regra (Plano) de Negócios, gerenciamento de projetos, liderança de equipes 
de desenvolvimento Scrum. Gerência de projetos, ERPs, ITIL, Cobit5 e Design Thinking. 
Experiência acadêmica de 18 anos.
AUTORES
A modelagem física de um sistema
UNIDADE 1
10
Desenvolver um software não representa apenas “sentar à frente do computador e progra-
mar”. Iniciando pelo levantamento de seus requisitos até a implantação do produto, muitas 
etapas são realizadas para que possa ser respondida a seguinte pergunta: o que o usuário 
quer? Esta é a grande resposta que o profissional de TI precisa buscar, sendo ela obtida a 
partir de diversas atividades nas quais, inicialmente, os requisitos funcionais são identifica-
dos para que seja iniciado o desenvolvimento do sistema por meio do uso de alguns dos 
diagramas da UML nas etapas iniciais. 
Com a conclusão dessas primeiras etapas é iniciado o processo de elaboração do projeto 
físico, que consiste em identificar os componentes e características físicas a serem utiliza-
dos no desenvolvimento do software que atenderá às demandas do sistema.Nessa etapa 
devemos transformar todas as necessidades identificadas em funcionalidades do softwa-
re a partir de um conjunto de ações que utilizarão mais alguns dos diagramas propostos 
pela UML. Logo, o objetivo desta unidade é relacionar as ações que devem ser realizadas 
para identificar as principais características físicas a serem utilizadas na construção e im-
plantação do software.
INTRODUÇÃO
Nesta unidade você será capaz de:
• Identificar os elementos utilizados para a elaboração da modelagem física para 
a construção de um sistema de informação.
OBJETIVO
11
Aspectos de um modelo físico
Estamos quase iniciando o momento de “programar” o Sistema de Informação. Para al-
guns profissionais de TI essa etapa é a mais importante do processo de desenvolvimen-
to de software. No entanto, ela é apenas mais uma das várias etapas desse processo. 
Isso porque, antes de iniciar a programação dos métodos que irão compor o sistema, é 
necessário organizar a infraestrutura que será utilizada.
Quais os padrões de desenvolvimento que serão empregados? Qual a arquitetura do 
sistema? E até mesmo, em alguns casos, qual a linguagem de programação mais ade-
quada, considerando-se os requisitos não funcionais previamente definidos? Estas são 
algumas das muitas perguntas que devem ser respondidas antes de se começar a 
produzir o sistema.
Para refletir
Antes de iniciarmos a explicação do porquê tudo isso é necessário, vamos refletir: 
Quais as consequências que podem surgir, caso não seja feito um planeja-
mento prévio? 
Imagine que você começa algo e percebe que um dos itens de que necessita 
não está disponível? 
Façamos uma analogia: a cozinheira vai preparar o arroz, refoga o alho a ce-
bola e, na hora que seria a de colocar o arroz na panela, descobre que esse 
ingrediente acabou. O que pode acontecer? 
O problema tecnológico pode ser muito semelhante.
Algumas instalações possuem seu próprio padrão de desenvolvimento, arquitetura, 
padrão de interface etc., e o desenvolvedor sabe o que vai usar. Nesse caso, a etapa de 
“construção prévia” é curta ou até mesmo inexistente. Entretanto, pode haver situações 
em que a empresa utiliza diferentes arquiteturas e padrões de desenvolvimento, sendo 
necessária uma avaliação prévia sobre as opções existentes para realizar a escolha, 
levando um pouco mais tempo para essa avaliação. 
12
Pode também surgir a situação em que seja necessário algo novo, como o uso da nova 
versão de algum componente da arquitetura. Nesse caso, esse componente deve ser 
buscado, instalado, testado para depois ser disponibilizado para uso no desenvolvimen-
to. Assim, para que haja tal disponibilidade, poderá haver uma demora não prevista no 
cronograma, que poderá impactar o prazo final da entrega. Todas essas avaliações de-
vem estar disponíveis quando o primeiro método é entregue ao desenvolvedor para 
sua construção. Caso contrário pode ocorrer de ele interromper a construção pela indis-
ponibilidade de algum desses recursos ou utilizar um padrão ou versão e depois ter que 
refazer tudo utilizando novos. Lembra do exemplo da cozinheira?
Segundo Cleison Carlos (2020), incertezas e riscos no desenvolvimento de softwa-
re estão associadas às mudanças tecnológicas. Para isso “um estudo antecipado 
evitaria esse tipo de problema. Imagina construir uma aplicação e no mês seguinte 
ela ser atualizada para uma nova versão não compatível com a anterior”.
Outro item importante para definição prévia em um projeto de construção do software 
está relacionada à interface da aplicação, pois a utilização de alguns recursos pode im-
pactar o uso do site, como: 
• Fontes pequenas.
• Excesso de “cliques”. 
• Dificuldade de navegação.
Não podemos esquecer das di-
ferentes plataformas e browsers 
que uma aplicação web pode uti-
lizar, devendo ser previstos o uso 
e testes em cada uma delas.
São muitos os aspectos que de-
vem ser analisados antes que 
seja iniciada a etapa de desen-
volvimento do software. Como 
foi dito em parágrafo anterior, os 
requisitos necessários para esse 
início podem variar de acordo 
com as características e maturi-
dade da instalação.
Diferentes recursos que impactam o desenvolvimento.
13
A elaboração do projeto para a construção do software consiste em identificar e tor-
nar disponíveis os recursos tecnológicos que serão utilizados para sua construção. 
Os requisitos identificados na etapa de levantamento do sistema serão transformados 
em componentes de software, mas, para isso, existem fortes influências tecnológicas 
que irão impactar o produto a ser entregue.
Como, porém, decidir quais recursos tecnológicos serão utilizados? Ao verificar a figura 
a seguir observamos que existem muitas opções que podem ser avaliadas para diversos 
aspectos relacionados à construção do software.
Como decidir quais recursos tecnológicos serão utilizados.
Alguns dos aspectos que devem ser previamente avaliados:
Arquitetura do sistema – Define os componentes que farão parte do software, especifi-
cando suas interfaces, relacionamento com outros softwares e propriedades. A arquite-
tura utilizada varia de acordo com o padrão de interface, ambiente operacional ou nave-
gabilidade. Segundo a empresa DevMedia (2020), no artigo intitulado Atividades básicas 
ao processo de desenvolvimento de software:
14
[...] a arquitetura de um sistema tem diversos elementos como: 
• Elementos utilitários.
• Elementos de interação. 
• Elementos que fazem parte do domínio do problema.
• Elementos de conexão.
• Elementos de persistência etc.
Padrões de desenvolvimento – Representa a arquitetura da aplicação, ou seja, a forma 
como ela será construída. O uso de um padrão depende da linguagem de programação 
por utilizar recursos que devem estar disponíveis na linguagem. 
Ferramentas a serem utilizadas – Devem ser definidas algumas ferramentas ou am-
bientes que serão utilizadas para a construção do software. Algumas dessas informa-
ções são identificadas como requisitos não funcionais, tais como: 
• A linguagem de programação utilizada no desenvolvimento.
• Ambiente de desenvolvimento.
• Sistema operacional.
• Servidor de aplicação.
• Servidor de Banco de Dados.
• Framework de acesso ao banco de dados.
• Ferramenta de construção de relatório etc. 
Algumas dessas ferramentas podem ser padrão, como o ambiente de dados quando a 
empresa utiliza um único SGBD.
Algumas empresas possuem padrão de desenvolvimento ou componentes da 
arquitetura previamente definidos. Nesse caso, essa etapa é simplificada, no 
entanto é importante observar que frequentemente novas versões dos compo-
nentes são lançadas e novas tecnologias surgem. Nessas situações, é impor-
tante que essas tecnologias sejam avaliadas. Assim, será possível identificar 
os eventuais impactos que as inovações podem provocar quando utilizadas de 
forma concomitante com versões anteriores. 
Importante
15
O uso de arquiteturas aplicadas à Engenharia de Software também pode ser definido 
nesse momento como Arquitetura Orientado a Serviço (SOA) ou Arquitetura de MicroSer-
viços, ambas fazendo parte da arquitetura do sistema. 
A definição das estratégias para o desenvolvimento, testes e implantação devem ser de-
finidas nesse momento. Essas estratégias permitem que o gerente do projeto de desen-
volvimento do software consiga previamente definir as ações que devem ser realizadas 
em cada uma das etapas a seguir. 
• A estratégia de desenvolvimento pode ser definida por meio da escolha do modelo 
de desenvolvimento, sendo alguns deles os modelos incremental, ágil ou cascata. 
• A estratégia dos testes deve ser criada especificando-se os modelos de testes 
que serão realizados, o momento em que eles irão ocorrer e as pessoas envolvidas. 
• Para a implantação do sistema, definir como será realizado; se houver migração 
dos dados definir a estratégia para a migração. 
Todas as ações descritas devem ser elaboradas na etapa de construção do projeto físico 
do software. Os componentes devem ser disponibilizados para queseja iniciada a etapa 
de implementação do software na qual os componentes do produto são produzidos, tes-
tados e posteriormente implantados.
16
Mapeamento do projeto lógico para o físico
Atualmente, a área de desenvolvimento possui profissionais que vêm se especializando 
em cada uma das diferentes etapas do processo de construção de um software. Isso 
significa que é recomendado que cada etapa do projeto de desenvolvimento de um sis-
tema seja construída por profissionais especialistas nas tarefas nelas desempenhadas. 
Ou seja, um engenheiro de requisitos deve ser utilizado na etapa de levantamento de 
requisitos por ser essa a sua especialidade, da mesma forma que o desenvolvedor na 
linguagem Java deve ser utilizado na etapa de implementação. 
Tendo como base as etapas comuns aos processos de desenvolvimento de software, 
apresentado no artigo Atividades básicas ao processo de desenvolvido de software, da 
empresa DevMedia (2020), podemos dividir esse processo em seis etapas :
1 Levantamento de requisitos – Quando são identificados, entre outras infor-mações, os requisitos funcionais, não funcionais, regras de negócios etc.
2 Análise de Requisitos – Quando é construída a solução sistêmica para o atendimento dos requisitos funcionais identificados na etapa anterior. 
3
Projeto de construção do software – Quando são identificadas as soluções 
tecnológicas para tornar disponíveis os requisitos levantados na primeira eta-
pa — sendo esse o objetivo desta disciplina.
4
Implementação – Consiste no desenvolvimento de soluções de software 
com o uso do ambiente de programação e componentes identificados na 
etapa anterior. Esse objetivo é atendido com o uso das disciplinas voltadas 
para a linguagem de programação.
5
Testes – Implementação de diversas atividades que têm como objetivo ava-
liar a qualidade do software produzido. Para isso, diversas técnicas podem 
ser utilizadas, não sendo esse o objetivo desta disciplina.
6
Implantação – Instalação do software no ambiente do usuário, disponibi-
lizando diferentes tipos de manuais voltados para ele. Após a implantação 
toda a documentação produzida até então deve ser disponibilizada para con-
sulta futura.
17
Cabe esclarecer que não existe um padrão sobre essas etapas, sendo possível en-
contrar outras formas de representação na literatura, no entanto utilizando-as como 
referência. Vamos dividir as “duas metades” do processo, antes de iniciada a etapa de 
implementação.
1 – Na primeira metade o engenheiro de requisito é acionado utilizando as técnicas 
indicadas para identificar os requisitos funcionais, não funcionais e regras de negócios, 
atores envolvidos, entre outros. A partir do levantamento dos requisitos, inicia-se a etapa 
de Análise dos Requisitos em que os profissionais especializados na construção do 
modelo conceitual do sistema começam suas atividades, construindo alguns dos dia-
gramas da UML utilizados para sua modelagem. Nesse momento a estrutura lógica do 
sistema está concluída, dando início a uma nova etapa em que todas as funcionalidades 
identificadas na primeira etapa começam a transformar-se em algo “visível” para o usuá-
rio: o Sistema de Informação solicitado por ele.
2 – Ao concluir a “primeira metade”, esse grupo de especialistas “sai de cena” dando lugar 
àqueles que passam a olhar o Sistema de Informação com uma visão tecnológica. Nes-
sa nova etapa o sistema começa a ter características de um projeto físico pela inserção 
de aspectos tecnológicos. Algumas transformações e ações preparatórias começam a 
ser realizadas para que possa ser iniciada a etapa de implementação do software, ou 
seja, inicia-se o desenvolvimento dos métodos ou outros componentes utilizando-se 
um ambiente de desenvolvimento e uma linguagem de programação.
Podemos afirmar que, se não houver nenhuma mudança nas funcionalidades 
do sistema, a primeira metade do desenvolvimento poderá existir por muito 
tempo. Entretanto, o dinamismo da segunda metade é muito maior, em razão 
das novas versões ou tecnologias que surgem a cada dia, fazendo com que o 
software necessite ser atualizado, sempre que necessário, para evitar que fique 
defasado tecnologicamente.
Importante
Destacamos, então, que um projeto de desenvolvimento de sistemas envolve profis-
sionais de TI especializados em cada uma das etapas do desenvolvimento. O enge-
nheiro de requisitos na etapa de levantamento de requisitos, o administrador de banco 
de dados na etapa de construção da base de dados, o desenvolvedor Java quando 
houver o desenvolvimento na linguagem e assim por diante, cada um sendo utilizado 
no momento correto.
18
O projeto de desenvolvimento de um sistema pode ser comparado a um pro-
jeto para construir uma casa. Você chama o engenheiro para fazer o projeto, 
chama os operários para realizarem a construção, o pintor para fazer a pintura 
dos cômodos e assim por diante. Ou seja, conforme a obra é realizada, novos 
especialidades de profissionais são utilizadas de acordo com a fase da obra.
Exemplo
Segundo o artigo Atividades básicas ao processo de desenvolvimento de software, 
publicado pela DevMedia (2020):
[...] um processo de desenvolvimento de software pode ser visto como 
um conjunto de atividades organizadas, usadas para definir, desenvolver, 
testar e manter um software. A seguir, alguns objetivos do processo de 
desenvolvimento:
• Definição das atividades a serem executadas.
• Quando determinada atividade deve ser executada.
• Pessoa ou grupo a executar tais atividades.
• Padronização no processo de desenvolvimento.
Considerando os objetivos propostos pelo usuário para o desenvolvimento de um sis-
tema, observa-se que:
• A definição das atividades a serem executas representa o conjunto de ações 
que devem ser realizadas para a construção do sistema, desde a etapa do levanta-
mento até a implantação.
• Determinar as atividades que devem ser executadas está relacionada às etapas 
de desenvolvimento e o que deve ser produzido em cada uma delas.
• As pessoas ou grupo a executar tais atividades define a equipe de desenvolvi-
mento com suas diferentes especialidades, que deve atuar nas etapas apropriadas.
• A padronização no processo de desenvolvimento representa o uso dos diagra-
mas da UML apropriados para cada uma dessas etapas.
O processo de mapeamento do projeto lógico em físico representa algumas ações que 
serão realizadas para iniciar-se o desenvolvimento do software. Após a definição dos 
componentes estruturais que serão utilizados, algumas ações devem ser realizadas para 
viabilizar e agilizar o início desse processo.
19
Apesar de a UML propor padrão para seus diagramas, o uso de cada um deles, 
assim como os procedimentos realizados para produzir a documentação de 
um sistema, varia de acordo com a empresa e tamanho de sua equipe de pro-
fissionais de TI. Algumas empresas valorizam a documentação, por entender 
que facilita o entendimento do projeto quando houver necessidade de mudan-
ças futuras. Outras entendem que é “perda de tempo” e que o mais importante 
é produzir. Não busque uma verdade absoluta sobre isso, pois não existe. Avalie 
os prós e contras e chegue à sua conclusão.
Importante
Definições prévias para iniciar a etapa de implementação 
de software 
Vamos relacionar alguns dos itens que devem ser previamente definidos antes de iniciar 
a etapa de desenvolvimento do software. A definição prévia evita interrupções ou retra-
balho durante essa etapa.
• Criar a estrutura da base de dados do sistema – Realizar o mapeamento dos atribu-
tos e relacionamentos descritos no Diagrama de Classe, permitindo a construção da es-
trutura da base de dados a ser utilizada pela aplicação. Se a empresa possuir um banco 
de dados que implementa o modelo relacional, serão necessárias algumas adaptações 
representadas pela transformação do modelo orientado a objeto para o relacional. 
• Definir um padrão de interface – Caso a empresa não possua um padrão institucio-
nal para as interfaces dos softwares que utiliza — conhecidocomo a identidade da em-
presa —, o desenvolvedor deve criar protótipos para que sejam avaliados pelo usuário. 
Devem ser identificados previamente os recursos que serão considerados para a cons-
trução, para que sejam avaliados no protótipo, tais como usabilidade, navegabilidade 
etc. Também serão definidos os padrões de qualidade a serem avaliados nas interfaces 
e verificados se contemplam as informações necessárias solicitadas pelo usuário. 
A definição de padrões para os tipos dos componentes que farão parte das inter-
faces, como tamanho, tipo de fonte, posicionamento das ações mais comuns, são 
alguns dos exemplos do que deve ser previamente definido para evitar mudanças, 
principalmente quando o desenvolvimento for realizado por uma equipe. Imagine 
uma aplicação em que cada interface tem um padrão diferente!
20
• Propor o modelo de navegação do sistema – Deve ser proposta a estrutura de 
navegação e acesso aos diferentes módulos que compõem o sistema. Esse mode-
lo é comum quando estruturas de menu e submenu de acesso são utilizadas para 
definir o acesso às diferentes funcionalidades. A forma como a estrutura das funcio-
nalidades será organizada faz parte desta definição.
• Definir a sequência de desenvolvimento – Devem ser relacionadas todas as fun-
cionalidades que serão implementadas. Elas devem ser organizadas em módulos 
que caracterizam as possíveis entregas que podem ser feitas. Em cada módulo de-
ve-se realizar a sequência como os componentes serão desenvolvidos. O objetivo 
dessa etapa é relacionar os procedimentos que serão desenvolvidos e a ordem em 
que serão realizados. 
• Especificar a política de testes do software – Organizar como será realizada a 
etapa de testes dos componentes ou métodos do software, conforme forem desen-
volvidos. Elaborar o plano de testes, definir a equipe, o tipo de teste, os recursos 
que serão utilizados etc. são alguns dos itens que devem planejados. 
• Montagem do ambiente para a construção do software – Quando o software 
estiver concluído e validado (etapa de implantação), ele será instalado em um am-
biente conhecido como “ambiente de produção”, em que estão presentes todos os 
sistemas utilizados no dia a dia da empresa. Na etapa de implementação ele está 
sendo construído, utilizando-se um ambiente conhecido como “ambiente de desen-
volvimento”. Antes de ser disponibilizado ao usuário, o sistema será migrado para 
um ambiente conhecido como “ambiente de homologação”, para que as funciona-
lidades possam ser validadas e seja verificada a compatibilidade com as demais 
aplicações. Os ambientes de desenvolvimento e homologação devem estar dispo-
níveis para que possa ser iniciado o desenvolvimento do software.
Após a validação do software, ou de uma parte dele, será feita sua implantação. Nessa eta-
pa outras ações podem ser previamente realizadas, como o registro das ações de migra-
ção de uma versão para outra, os procedimentos para mudança da estrutura de uma base 
de dados etc. A definição dessas ações varia de acordo com a característica do desenvol-
vimento que está sendo feito e deve ser elaborada nas etapas de projeto e implementação.
Todas as ações realizadas ao longo de todo o projeto de desenvolvimento de um softwa-
re devem ser documentadas, exigindo que sejam produzidos documentos que irão gerar 
a documentação do sistema, que precisa ser validado e aceito pelo usuário que solicitou 
seu desenvolvimento.
21
A modularização de um sistema
O conceito de modularidade pode ser aplicado em várias situações, seja na área empre-
sarial ou industrial. Se você analisar um móvel feito em madeira, por exemplo, observará 
que ele é desmontável na maioria das vezes e sua montagem é feita por meio de para-
fusos de tamanho previamente definido. Esses mesmos parafusos podem ser utilizados 
em diferentes móveis que possuem o mesmo tamanho para encaixe. Ao utilizar o mes-
mo componente em diferentes produtos você otimiza sua produção, reduzindo o custo.
Seguindo essa mesma linha de raciocínio, imagine uma companhia aérea que possui 
200 aeronaves de 50 tipos diferentes. Ela terá que ter componentes para a manutenção 
para todos esses tipos. No entanto, se as 200 aeronaves forem de cinco tipos diferentes, 
a compra de material de manutenção será em maior quantidade, o que reduzirá o custo 
de aquisição, podendo um componente ser utilizado em diferentes aeronaves. Este con-
ceito é aplicável em diversas áreas industriais, podendo ser observado na maioria dos 
produtos que utilizamos no nosso dia a dia.
O que isso até a ver com desenvolvimento de software?
A resposta é simples: tudo!
No momento em que desenvolvemos o código de um software, temos que ter 
sempre em mente a preocupação com a prática de reúso desses códigos. Em 
desenvolvimento de software essa prática é conhecida como “componenti-
zação”, em que um pequeno módulo (componente) é construído e acoplado 
a outro, que é incorporado a outro e assim por diante, até que o software seja 
construído como um todo.
Importante
22
Vamos analisar a figura composta de diversos componentes que fazem parte, por exem-
plo, do motor de um veículo. Esses componentes, de forma isolada, não possuem nenhu-
ma utilidade, ou seja, não agregam valor ao motor ou ao veículo, pois somente produzem 
esse valor se combinados a outros componente. Um componente de um software, quando 
analisado de forma isolada, representa exatamente essa situação. Ele tem um objetivo es-
pecífico, mas de forma isolada não produz valor para o usuário. 
Por exemplo, um módulo que realiza o cálculo da área de uma região só tem valor se 
estiver associado a outro módulo que, por sua vez, possua as medidas e a característica 
da região cuja área será calculada, fazendo uso do resultado obtido. Essa situação pode 
ser observada na figura do motor completo, em que mesmos componentes representa-
dos na figura anterior aparecem integrados para alcançar um objetivo maior, que seria o 
funcionamento do motor.
Componentes do motor de um veículo.
Motor completo.
23
O que nós fazemos apenas com o motor de um veículo? Se você deseja um veículo, são 
necessários outros componentes, tais como: carroceria, pneus, sistema elétrico etc. Na 
maioria dos casos, o que produz valor ao usuário não é um componente, mas sim o produ-
to acabado, ou seja, o veículo completo.
Segundo Moura et al. (2017), “Modularidade é um conceito-chave em projetos 
de software complexos. Com a modularização, o software ou sistema é dividi-
do em partes distintas, contribuindo com o aumento da produtividade desde o 
desenvolvimento inicial até a fase de teste”.
Ampliando o foco
Observe que a construção de um software representa esta situação: voltando ao exem-
plo anterior, o módulo que calcula a área de uma região, se acoplado a outro módulo que 
forneça os dados para esses cálculos, produz um resultado. Porém, se incorporarmos 
todos os módulos a um software que produz o desenho de um projeto de engenharia 
eles estarão integrados a um componente maior. Por exemplo, esse software desenha 
os diversos cômodos de uma construção e, “com um clique”, calcula a área de cada um 
deles, ou seja, ele atendeu ao seu objetivo (calcular a área) dentro de um objetivo maior 
(desenhar os cômodos da construção). 
Ainda neste exemplo, verificamos que existem vários outros componentes, como o que 
faz a metragem do espaço para o cálculo, outro que identifica a figura do cômodo e 
assim por diante. Em resumo, o software de engenharia possui todos os componentes 
necessários sem a percepção do usuário.
Caso queira desenvolver outro software com objetivo diferente, mas que necessite reali-
zar desenhos, calcular área etc., basta utilizar esses componentes sem precisar reescre-
vê-los. Observou como agilizou o tempo de desenvolvimento? Não foi necessário desen-
volver todos os componentes, bastou usá-los.
Componentes de software representam unidades independentes, que podem 
ser interligadas a outros componentes formando sistemas mais complexos e 
cada umadelas deve encapsular um objetivo específico e único.
Importante
24
Ao construir um componente de software, ele deve possuir as seguintes características: 
• Deve encapsular a sua implementação.
• Deve possuir interface e objetivo bem definidos.
• Deve ser utilizado independente de outros módulos.
• Deve fornecer recursos suficientes para que possa ser reutilizável.
• Deve deixar explícitos os conceitos das dependências e conexões entre os 
componentes.
• Deve possuir documentação clara e precisa sobre o seu uso.
Como modularizar um sistema? 
A modularização pode ser iniciada com a identificação dos métodos relacionados no 
Diagrama de Classe e construir, a partir dele, o que seria o principal componente do 
software: as suas classes de negócio. Lembrando que uma das principais característi-
cas da orientação a objeto é o reúso do código ao criar um componente que encapsula 
todos os métodos e atributos da classe de negócio. Assim, você poderá incorporá-los a 
novos programas sempre que essa classe for utilizada. A partir dessa construção, cada 
um dos métodos deve ser observado de forma isolada, identificando procedimentos 
que podem ser reutilizáveis.
Lembre-se de que pode haver método que seja específico a uma classe. Como 
exemplo, temos aquele que consulta uma informação na base de dados a partir 
de uma identificação, como a consulta dos dados de um aluno a partir da sua 
matrícula em que, nesse caso, esse componente/método deve fazer parte do 
componente maior associado à classe de negócio. 
No entanto, outras situações podem surgir aplicáveis a diferentes classes de 
negócios. Por exemplo, o método de verificação de um dígito verificado, como 
a validação de um CPF, que pode ser utilizado em qualquer classe que possua 
esse atributo. Nesse caso, esse componente/método não deve estar associado 
a nenhuma dessas classes de negócio, mas sim vinculado a uma classe gené-
rica de uso comum ou deve ser utilizado de forma isolada.
Exemplo
25
Seleção
Buscar e selecionar os componentes disponíveis que possuem 
potencial para utilização na construção do sistema.
Qualificação
Verificar se o componente adequa-se ao modelo de arquitetura 
utilizada pelo software.
Adaptação
Verificar a necessidade de adaptação do componente ao soft-
ware, podendo ser necessária a criação de uma nova versão, 
caso ele esteja sendo utilizado.
Composição
Realizar a integração do componente ao sistema a partir de 
suas interfaces.
A partir da próxima unidade você conhecerá alguns dos padrões de desenvolvimento 
utilizados e os principais diagramas propostos pela UML, que permitem os registros 
dessas informações.
A partir da definição dos componentes, deve ser elaborada a sequência para o seu de-
senvolvimento, conforme as etapas descritas a seguir :
26
Para ampliar o seu conhecimento veja o material complementar, disponível na 
midiateca na Unidade 1.
MIDIATECA
O desenvolvimento de um software é composto por diversas etapas. As primei-
ras têm a preocupação de identificar seus objetivos, sem ter como referência 
fatores tecnológicos como linguagem de programação, SGBD etc. Ao concluir 
essa etapa, será necessário iniciar a implementação do software em que de-
vem ser identificadas as respostas para algumas das perguntas abaixo:
• Qual será o ambiente operacional? Windows, Android, Linux, vários?
• Qual o ambiente de programação que será utilizado? Dot.Net, Eclipse, 
Netbeans?
• Qual a plataforma? Web, Desktop?
• Qual o padrão de arquitetura de desenvolvimento? MVC, Cliente-Servidor, 
Sistema distribuído? 
• Qual SGBD será utilizado? Oracle, Postgree, SQL-Server?
• Qual o volume de transações? De dados? De usuários? 
• Qual a rapidez no tempo de resposta?
• Quais as linguagens utilizadas na interface? CSS, HTML, JS?
• Quais os padrões de interface? Componentes da interfaces e seus 
formatos?
Estas e muitas outras perguntas precisam ser respondidas para que seja co-
nhecido o ambiente operacional, recursos tecnológicos, versões etc. que serão 
utilizados para o desenvolvimento do software. As ações apresentadas nesta 
unidade são realizadas pelos profissionais que respondem a estas perguntas e 
produzem a documentação necessária para registrar os recursos e componen-
tes tecnológicos utilizados para a construção do software.
NA PRÁTICA
27
Resumo da Unidade 1
Nesta unidade você estudou as ações que devem ser realizadas para iniciar-se a etapa 
de implementação de um software. Para que o início ocorra de forma segura devem ser 
definidos os componentes tecnológicos que serão utilizados na construção do software, 
deixando-os disponíveis e previamente testados sem que haja o risco de interromper 
ou cancelar o desenvolvimento por inadequações técnicas. Eliminando os riscos, será 
possível transformar os requisitos identificados em funcionalidades do software. Em re-
sumo, a construção do Sistema de Informação.
Podemos dividir as etapas de desenvolvimento de um sistema em duas grandes meta-
des. Na primeira os profissionais envolvidos estão focados em identificar os requisitos 
funcionais junto aos usuários, preparando os diagramas que irão compor a análise do 
sistema, não havendo nenhuma influência de tipos ou componentes tecnológicos. “A tec-
nologia não interessa”, é o que poderiam afirmar os profissionais que atuaram até esse 
momento no desenvolvimento do sistema. Já na segunda metade os requisitos tecno-
lógicos tornam-se necessários, pois eles irão orientar a maneira como o software será 
construído. As ações devem ser documentadas para que possam produzir as documen-
tações do sistema que serão úteis em atualizações futuras, uma vez que as evoluções 
tecnológicas ocorrem de maneira frequente. Por este motivo, para facilitar mudanças 
futuras a partir de diagramas e padrões de desenvolvimento, o registro dos elementos 
tecnológicos utilizados, suas versões e características devem estar sempre disponíveis.
28
Referências 
ATIVIDADES básicas ao processo de desenvolvimento de software. DevMedia. Dispo-
nível em: https://www.devmedia.com.br/atividades-basicas-ao-processo-de-desenvolvi-
mento-de-software/5413. Acesso em: 10 jul. 2020.
CLEISON, C. Incertezas e riscos no desenvolvimento de software. Disponível em: ht-
tps://medium.com/trainingcenter/incertezas-e-riscos-no-desenvolvimento-de-software-
-6eabbeedb055. Acesso em: 5 jul. 2020.
INTRODUÇÃO ao padrão MVC. DevMedia. Disponível em: https://www.devmedia.com.
br/introducao-ao-padrao-mvc/29308. Acesso em: 5 jul. 2020. 
ESCUELA TECNOLÓGICA INSTITUTO TÉCNICO CENTRAL. Guía metodológica desar-
rollo de sistema de información. Disponível em: http://www.itc.edu.co/archives/calidad/
GIC-GU-01.pdf. Acesso em: 10 jul. 2020.
PERITO, J. A importância da documentação de software. Disponível em: https://blog.
geekhunter.com.br/qual-e-a-importancia-da-documentacao-de-software/. Acesso em: 
5 jul. 2020.
MODULARIDADE. In: WIKIPEDIA: the free encyclopedia. [San Francisco, CA: Wikimedia 
Foundation, 2010]. Disponível em: http://en.wikipedia.org/wiki/Modularidade. Acesso em: 
10 jul. 2020.
MOURA, L. F.; MARTINS, R. G.; SILVA, L. L. Modularidade de Sistemas de Software. VII 
Seminário de Iniciação Científica e Inovação Tecnológica do IFTM. Uberaba, 8 de junho de 
2017. Disponível em: https://iftm.edu.br/ERP/MPES/EVENTOS/arquivos/030517150836_
resumo_sin_lucas_moura.pdf. Acesso em: 5 jul. 2020.
PRÁTICA: desenvolvimento baseado em componentes. Demoiselle Framework. Dispo-
nível em: http://demoiselle.sourceforge.net/process/ds/1.2.3-BETA1/ProcessoDemoisel-
lePlugin/guidances/practices/componentes_6A150B73.html?nodeId=e61bad17. Acesso 
em: 10 jul. 2020.
https://www.devmedia.com.br/atividades-basicas-ao-processo-de-desenvolvimento-de-software/5413
https://www.devmedia.com.br/atividades-basicas-ao-processo-de-desenvolvimento-de-software/5413
https://medium.com/trainingcenter/incertezas-e-riscos-no-desenvolvimento-de-software-6eabbeedb055
https://medium.com/trainingcenter/incertezas-e-riscos-no-desenvolvimento-de-software-6eabbeedb055
https://medium.com/trainingcenter/incertezas-e-riscos-no-desenvolvimento-de-software-6eabbeedb055https://www.devmedia.com.br/introducao-ao-padrao-mvc/29308
https://www.devmedia.com.br/introducao-ao-padrao-mvc/29308
http://www.itc.edu.co/archives/calidad/GIC-GU-01.pdf
http://www.itc.edu.co/archives/calidad/GIC-GU-01.pdf
https://blog.geekhunter.com.br/qual-e-a-importancia-da-documentacao-de-software/
https://blog.geekhunter.com.br/qual-e-a-importancia-da-documentacao-de-software/
http://en.wikipedia.org/wiki/Modularidade
https://iftm.edu.br/ERP/MPES/EVENTOS/arquivos/030517150836_resumo_sin_lucas_moura.pdf
https://iftm.edu.br/ERP/MPES/EVENTOS/arquivos/030517150836_resumo_sin_lucas_moura.pdf
http://demoiselle.sourceforge.net/process/ds/1.2.3-BETA1/ProcessoDemoisellePlugin/guidances/practices/componentes_6A150B73.html?nodeId=e61bad17
http://demoiselle.sourceforge.net/process/ds/1.2.3-BETA1/ProcessoDemoisellePlugin/guidances/practices/componentes_6A150B73.html?nodeId=e61bad17
Padrões de arquitetura 
de software
UNIDADE 2
30
O desenvolvimento de um software consiste na aplicação de recursos tecnológicos para 
sua construção. A escolha desses recursos deve ser feita antes de iniciada sua imple-
mentação para que possam ser previamente avaliados e testados, estando validados 
e disponíveis no momento da utilização. Alguns dos recursos utilizados no desenvolvi-
mento da programação do software estão relacionados aos padrões de arquitetura que 
serão usados em sua construção. Em alguns casos, são dependentes dos ambientes 
operacionais ou das linguagens de programação a serem utilizados. 
A escolha dos componentes que serão utilizados no software, o padrão de projeto e o 
padrão de desenvolvimento são alguns dos padrões arquiteturais que devem ser previa-
mente avaliados para serem utilizados na fase de implementação do software. Assim, 
o objetivo desta unidade é apresentar três padrões arquiteturais: a arquitetura baseada 
em componentes, o padrão MVC e o padrão de projeto Gof, que representam diferentes 
formas de arquiteturas utilizadas para a construção de um software.
INTRODUÇÃO
Nesta unidade você será capaz de:
• Aplicar os padrões de arquitetura de software para a construção de um Sistema 
de Informação. 
OBJETIVO
31
Arquitetura baseada em componentes 
O que é arquitetura baseada em componentes?
De forma simples, podemos dizer que a arquitetura baseada em componentes represen-
ta um dos modelos utilizados na arquitetura de software, que realiza o modelo de desen-
volvimento arquitetural de um software a partir do uso de componentes.
O que é arquitetura de software?
Segundo a Secretaria Nacional de Cultura, “a arquitetura de software representa a(s) estru-
tura(s) do sistema, que consiste nos componentes de software, nas propriedades externa-
mente visíveis desses componentes e nos relacionamentos entre eles”. Essa arquitetura 
tem como principal característica a modelagem e o projeto do software, considerando os 
aspectos tecnológicos e estruturais. Dessa forma, é possível definir diferentes formas de 
projetos, os módulos de um software e suas comunicações que estejam relacionadas ao 
desenvolvimento, como sistemas distribuídos, web, cliente servidor etc.
A arquitetura baseada em componentes possui a visão do desenvolvedor no que se refere 
à componentização do software, ou seja, sobre como podemos definir os componentes 
necessários para sua construção. Isso é realizado a partir da definição das propriedades 
externas desses componentes e seus relacionamentos com outros softwares no modelo 
de implementação. Em uma forma mais ampla, a arquitetura baseada em componentes 
define situações em que pequenos componentes integram-se a outros, formando um 
maior que, ao ser integrado, produz componentes cada vez mais robustos e com objeti-
vos mais abrangentes. Dessa forma, permite construir sistemas de informação utilizando 
módulos com quantidades menores de linhas de programação.
A arquitetura de software foi apresentada por Macilory em 1968, em um trabalho 
que tinha uma proposta de desenvolvimento de componentes reutilizáveis para a 
construção de um software, no qual o desenvolvedor escolheria qual componen-
te seria utilizado de acordo com suas necessidades. Em 1976, DeRenner propôs 
que fosse construído um conjunto de módulos independentes para serem depois 
interligados. Com o surgimento da programação orientada a objetos a ideia de 
componentização e reutilização em software tornou-se mais popular. 
Ampliando o foco
32
Existem diversos termos similares que levam a soluções ou propostas próximas. Como 
exemplo, os termos: Engenharia de Software baseada em componentes, Desenvolvimen-
to baseado em componentes ou Arquitetura baseada em componentes, da mesma forma 
que Arquitetura de software ou Arquitetura de sistemas ou Arquitetura de componentes, 
são alguns dos que tratam de forma muito próxima cada um dos objetivos. Em alguns 
casos, existem diferenças entre eles que variam na forma como são implementados ou 
em seu alcance como projeto. Entretanto, existem situações que possuem o mesmo 
objetivo, sendo apenas tratadas com nomenclatura diferente.
Um exemplo que aproxima-se ao que foi apresentado está relacionado à definição de 
Arquitetura de componentes, atribuída à Secretaria Nacional de Cultura, que refere-se 
a esta arquitetura como sendo: “A Prática de Desenvolver e Utilizar Arquiteturas de 
Componentes ajuda a gerenciar a complexidade e encoraja a reutilização, porque as 
Arquiteturas de Componentes baseiam-se em componentes independentes, substituí-
veis e modulares.”
A integração de diferentes componentes que compõem a arquitetura de um sistema, tais como: 
ambiente, segurança, dispositivos, interface, arquitetura etc.
33
Diferenças entre componentes e objetos
A similaridade entre componentes e objetos pode levar o desenvolvedor a pensar que 
ambos possuem os mesmos objetivos, porém isso não é verdade. Vamos ver algu-
mas diferenças:
Itens comparativos Componentes Métodos
Metodologia de 
desenvolvimento
Pode ser implementado por 
linguagem de programação 
que utilize qualquer tipo de 
metodologia.
A implementação é feita por 
linguagens de programação 
que utilizam a metodologia de 
orientação a objeto.
Granularidade
Pode possuir granularidade 
que envolva vários objetos 
e métodos, até mesmo de 
diferentes classes.
Deve ter um objetivo específico 
restrito à classe a que pertence. 
Flexibilidade 
de uso
Não está associado a uma 
classe de negócio, poden-
do ser compartilhado por 
várias delas. 
Um método está restrito à clas-
se de negócio a que pertence.
Exemplo
O componente que calcu-
la o dígito verificador do 
CPF pode ser utilizado em 
qualquer classe de negócio 
que manipula este atributo, 
podendo ser desenvolvido 
em qualquer linguagem e 
anexado ao programa.
O método que realiza a cria-
ção de uma instância de uma 
classe de negócio está restrito 
apenas a esta classe e deve ser 
implementado em uma lingua-
gem orientada a objeto.
Considerando que existem diferenças entre métodos e componentes, para que um des-
ses componentes sejam criados alguns critérios devem ser considerados, conforme des-
critos abaixo:
• Reúso: possibilidade de usar o componente em diferentes aplicações.
• Encapsulamento: para usar o componente devem ser conhecidas apenas as 
suas interfaces.
34
• Independência: um componente não pode ser dependente de outro que não es-
teja encapsulado.
• Documentação: deve ser bem documentado, deixando de forma clara seus obje-
tivos e interfaces.
Atendendo aos critérios acima, o desenvolvedor tem como resultado:
• Redução do custo e tempo: o reúso de componentes evita que haja novas imple-
mentações, reduzindo o tempo total do desenvolvimento.
• Facilidade de desenvolvimento: quanto menor o componente, menor o tempo 
para desenvolvimento e teste, agilizando a entrega do produto.
Arquiteturas que implementam a integração de componen-
tes, disponíveis nos atuais ambientes operacionais
• CMM (CORBA Component Model): desenvolvido pela OMG (Object Management 
Group), Consiste em um framework utilizadopara que componentes desenvolvi-
dos em diferentes plataformas ou ambientes operacionais possam interagir. Como 
exemplo, o desenvolvimento de uma aplicação desenvolvida para o sistema opera-
cional Windows e linguagem JSP que utilize componentes desenvolvidos em outras 
linguagens de programação e sistema operacional Unix.
Componentes que formam a estrutura da família CORBA.
Fonte: www.gta.ufrj.br.
INTERFACE
REPOSITORY
CLIENT
ORB CORE
IDL
COMPILER
OBJ
REF
DII
DSI
ORB
INTERFACE
GIOP/IIOP
IDL
STUBS
STANDARD INTERFACE STANDARD LANGUAGE MAPPING
ORB-SPECIFIC INTERFACE STANDARD PROTOCOL
IDL
SKELETON
IMPLEMENTATION
REPOSITORY
OBJECT
(SERVANT)
operation()
in args
out args + return value
DSI
https://www.gta.ufrj.br/grad/00_2/corba/componentes_arquitetura.html
35
• COM/COM+ (Component Object Model): desenvolvido pela Microsoft, o COM 
consiste em um padrão de interface binária, que permite o acoplamento entre apli-
cações independentemente da linguagem desenvolvida. O COM+ é uma evolução 
desse padrão utilizado em sistemas distribuídos, ou seja, as aplicações podem estar 
em diferentes equipamentos. Segundo a Microsoft, “é um sistema independente de 
plataforma, distribuído e orientado a objetos para a criação de componentes biná-
rios de software que podem interagir”. 
• DCOM (Distributed Component Obejct): desenvolvido pela Microsoft, o DCOM 
representa uma estrutura de programação que permite que um computador exe-
cute programas em outro pela rede, como se estivesse sendo executado local-
mente. DCOM é um componente de software de propriedade da Microsoft que 
permite que objetos COM comuniquem-se pela rede. Essa arquitetura representa 
uma evolução da COM/COM+, sendo que a diferença entre elas é que a DCOM 
atua em sistemas distribuídos. 
Arquitetura DCOM.
Fonte: datahousecorp.com.
Web clients
MS SQL Server MSMQ
TCP clients
MTS
IIS
/S
A
P
DC
O
M
Local 
data
Local 
data
ASP
Q
ue
ry
Application 
logic
COM
IUnknown
http://datahousecorp.com/eng/technology/dcom.htm
36
• JavaBeans e Entreprise JavaBeans – EJB: desenvolvido pela Sun, tem como ob-
jetivo permitir que unidades independentes e reutilizáveis possam ser manipuladas 
pelos desenvolvedores a partir do ambiente de desenvolvimento da linguagem Java. 
Dessa forma, ao utilizar um dos ambientes de desenvolvimento da linguagem (Ne-
tbeans ou Eclipse, por exemplo) é possível compartilhar suas próprias bibliotecas 
(classes de negócios compartilhadas) ou bibliotecas do sistema (sql, swing, io etc).
Arquitetura JBS em uma aplicação.
Fonte: netbeans.org.
Model
Sessions Beans
(EJB)
Entity Classes
(JPA)
Request
Response
Database
Controller
(servlet)Client
(browser)
View
(JSP pages)
https://netbeans.org/kb/docs/javaee/ecommerce/entity-session_pt_BR.html
37
Padrão Model-View-Control (MVC) 
Segundo a empresa DEVMEDIA, o padrão MVC (Model-View-Control) é um dos padrões 
arquiteturais mais antigos. Ele apresenta uma arquitetura em três camadas, que atuam 
de forma independente na construção de um software. São elas:
• Model (Modelo): essa camada representa as classes de negócio tratadas pela 
aplicação, sendo disponibilizados os métodos desenvolvidos e definidos no Diagra-
ma de Classe.
• View (Visão): representa as interfaces definidas para a aplicação.
• Control (Controle): camada que realiza a interligação entre as outras duas camadas.
Embora não exista um padrão para esta construção, no que se refere às características 
dos métodos que devem ser colocados em cada uma delas, há o consenso de que de-
vem ser construídas de forma independente, para que o reúso ou manutenção possa ser 
feito sem que haja impactos nas demais. 
A arquitetura padrão do modelo MVC.
38
Vamos entender o que significam as três camadas que representam o padrão MVC, de-
talhando cada uma delas, seguindo a sequência que representa a execução de um pro-
grama. Ou seja, o usuário fornece um dado, este sofre algum tipo de processamento pela 
aplicação e o resultado é devolvido.
Camada de visão
As interações entre o usuário e a aplicação são feitas por meio do que chamamos de 
interface, normalmente representada por telas, por onde os dados são fornecidos pelo 
usuário e por onde as informações são apresentadas a ele. Quando um dado é forneci-
do e uma operação é acionada (calcular, salvar etc.) a partir de um link, botão ou outro 
componente, é iniciada uma sequência de procedimentos para atender a essa operação.
Observe que, até o momento, houve apenas o fornecimento dos dados. Por esse motivo, 
todas as operações que estejam relacionadas a esse dado devem ser definidas na pró-
pria interface. Por exemplo, para verificar se um campo foi preenchido ou não deve ser 
criada uma rotina para realizar esse teste. Outro exemplo: se um valor preenchido para 
uma variável numérica deve ter seu conteúdo maior do que o valor zero, também deve 
ser criado um procedimento para fazer essa validação na própria interface. 
As principais motivações para que essas ações sejam realizadas desse modo são:
• Evita que haja continuidade na operação com uma informação incorreta.
• Haverá perda de tempo e recursos, caso a validação seja feita “mais para a frente”.
• Em termos estruturais, a interface está disponível no equipamento do cliente. 
Assim, o método utilizado já está disponível, não sendo necessário “buscá-lo” em 
outras camadas.
O padrão MVC foi desenvolvido em 1979 por Trygve Reenskaug para que fosse 
uma arquitetura de software utilizada em aplicações desktop. Atualmente, esse 
padrão tem sido mais utilizado em aplicações web, embora seja possível utili-
zá-lo em todos os tipos de implementação.
Ampliando o foco
39
Camada de controle
Essa camada tem função “gerencial” na aplicação. Os procedimentos definidos têm o 
objetivo de identificar a ação acionada na interface e de identificar o método da classe 
de negócio que deve ser executado. 
Em uma situação em que o usuário digita os dados e escolhe a opção “salvar” na tela de 
entrada de dados da classe “Cliente”, a camada de controle identifica essa ação e aciona 
o método correspondente dessa classe. Apenas isso que ela deve fazer? Sim!
Nessa camada não devem ser definidos métodos que estejam relacionados a validação 
de dados ou a ações de negócios que facilitem o seu reúso quando necessário, manten-
do a independência em relação às camadas de visão e de negócio em relação a ela. 
Camada de negócio
Nessa camada são definidos os métodos associados às classes de negócio. Os méto-
dos mais comuns implementados nessa camada são: 
• As regras de negócio vinculados à classe.
• As operações que manipulam os atributos da classe de negócio.
• Os métodos de validação e armazenamento dos dados.
Quando o Diagrama de Classe do sistema é construído são descritas as classes de ne-
gócios por ele manipuladas com seus atributos, métodos e relacionamentos. Esses 
métodos são implementados e “empacotados” como componentes para que possam 
ser utilizados por outras aplicações, sem que haja a necessidade de reescrevê-los, garan-
tindo assim sua independência em relação às demais camadas.
Para comprovar a teoria de que o que for referente a dados deve ser tratado na 
interface, as linguagens disponibilizam componentes que já realizam validação 
de formato. Por exemplo, se precisamos informar uma data deve ser utilizado 
o componente próprio para variáveis do tipo “data”, pois automaticamente será 
feita a validação de formato e conteúdo, não sendo necessário criar métodos 
que verifiquem se foi informada no formato dia, mês e ano e se ela é válida.
Importante
40
Por exemplo, no Diagrama de Classe de um sistema, foi definida a classe “Cliente” com 
seus atributos e métodos. Essa classe foi implementada e disponibilizada em uma bi-
blioteca de classes para que as outras aplicações que também a utilizem apenas a “im-
portem”. Esse tipo de operação é semelhante às importações realizadas nas linguagens 
de programação, como importar a biblioteca com os métodos de manipulação de string,sempre que necessitamos utilizar um deles.
A implementação na prática
Vamos fazer um passo a passo do que acontece quando fornecemos um conjunto de da-
dos em uma aplicação e mandamos gravá-los na tabela correspondente da base de dados.
1 - Camada de visão 
O usuário fornece os dados na interface e escolhe a opção “Salvar”.
2 - Camada de controle 
O método vinculado a esta interface identifica que esta opção foi acionada e aciona o 
método correspondente a esta operação da camada de negócio.
3 - Camada de negócio 
Recebe o controle da aplicação, realiza a operação e retorna este controle para que a 
camada de visão informe ao usuário que a ação foi concluída.
E de onde retiramos a independência entre as camadas?
Vamos imaginar a seguinte situação:
Para uma aplicação web a empresa deseja alterar o padrão de interface utilizado. As 
funcionalidades são as mesmas, apenas aspectos relacionados à navegabilidade ou 
layout serão alterados. Nesta situação surge a primeira questão: será que os métodos 
da classe de negócios utilizados sofrerão algum tipo de alteração em razão do novo 
padrão de interface? 
41
Se a resposta for não, significa que nenhuma alteração deve ser feita nesses métodos, 
ou seja, a camada de negócio não deve sofrer alteração, representando apenas uma 
mudança de interface. Neste caso, basta ser definido o novo padrão, refeitas as interfa-
ces envolvidas adotando-se o novo padrão, e por último, substituir uma pela outra. Ou 
seja, serão feitas mudanças apenas na camada de interface, sem preocupar-se com as 
demais. Simples, não? A camada de visão configura-se independentemente das demais.
Se a mudança for em alguma regra de negócio, o pensamento é o mesmo. Se não hou-
ver necessidade de mudança na interface, deve-se apenas alterar o método impactado 
e substituí-lo na biblioteca da classe de negócio à qual pertence. Ou seja, deve-se alterar 
o método, testá-lo e substituir a versão anterior pela nova, sem que seja necessário fazer 
qualquer tipo de mudança nas demais camadas. Outra independência!
A exceção pode ocorrer se uma nova operação for necessária em uma interface. Por exem-
plo, se uma nova operação de “consulta” for inserida na interface por meio de um novo 
componente representado por um botão, devem ser realizadas as seguintes operações: 
• Na interface, para realizar a nova operação, incluindo o novo componente.
• No controle, para identificar esse novo componente e vincular ao método que irá 
executá-lo.
• Na camada de negócio, introduzindo esse novo método ou alterando algum já 
existente. 
Caso a resposta à pergunta acima seja sim, significa que não se trata apenas 
de uma mudança de interface. Se outros métodos estão sendo adicionados, 
alterados ou removidos, significa que houve mudanças nas funcionalidades 
previstas nos casos de uso, ou seja, o software está sofrendo manutenção por 
alguma razão, não sendo apenas por mudança na interface. 
Importante
42
As camadas do Modelo MVC.
Fonte: www.portalgsti.com.br. Adaptada.
Avaliando a figura anterior, observamos as trocas de mensagens existentes entre as ca-
madas. A camada de controle recebe a requisição a partir do HTTP e, a partir dela, realiza 
a interação entre as camadas de visão e modelo para o seu atendimento.
Para que possa continuar havendo independência entre as camadas e tendo como base 
as características tecnológicas utilizadas, é comum identificar aplicações que dividem a 
camada de negócio em outras duas:
• A camada de implementação das regras de negócios em que são definidos os 
métodos que tratam essas regras.
• A camada de acesso ao banco de dados em que são definidos os comandos de 
acesso aos dados armazenados (comandos SQL). Essa camada, conhecida como 
DAO (Data Access Object), contém apenas os métodos associados, a conexão ao 
Banco de Dados e os comandos SQL. Logo, são criados métodos apenas com os 
comandos SQLs sem qualquer tipo de implementação. A principal vantagem do uso 
Observe que NÃO existem interações entre a visão e o modelo, ou seja, por 
questão de segurança a visão não pode acionar métodos da camada de negó-
cio, conforme representado na figura anterior.
Importante
request
response
envia dados
demand dados
HTTP
Html, XML,
Controller
Model
View
https://www.portalgsti.com.br/2017/08/padrao-mvc-arquitetura-model-view-controller.html
43
dessa quarta camada é percebida nas situações de mudança de SGBD, pois, nesse 
caso, é necessário apenas avaliar e alterar esses métodos, adaptando-os às regras 
do novo SGBD, não havendo nenhuma alteração nos demais métodos.
Dessa forma, o padrão MVC passaria a ser:
1. Visão.
2. Controle.
3. Negócio.
4. Acesso a dados.
Massari (2020), no portal GSTI, relacionou ações que devem ser implementadas em cada 
uma das camadas, das quais algumas delas são:
• Camada de Visão
→ Exibe a representação dos dados.
→ Camada de interface com usuário, realizando entrada e exibição dos dados.
→ Responsável por usar as informações modeladas para produzir interfaces de 
apresentação conforme a necessidade.
• Camada de Modelo
→ Camada que contém a estrutura de dado atrás de uma parte específica da 
aplicação.
→ Responsável pela leitura, manipulação e implementação das regras de negócios.
→ Notifica a visão e o controle associados quando há mudança em seu estado.
• Camada de Controle
→ Exerce o controle sobre o modelo e a visão que serão utilizados.
→ Manipula e roteia as requisições dos usuários.
→ Realiza o gerenciamento das demais camadas.
→ Avalia as ações realizadas pelo usuário e as transfere em comandos para as 
classes de modelo e/ou visão.
→ Realiza a validação das ações dos usuários conforme as regras de autentica-
ção e autorização definidas pela aplicação.
• Camada de Dados
→ Implementa os métodos associados aos procedimentos de conexão e acesso 
aos dados, tais como as consultas e operações de atualização.
44
Padrão de projeto de software 
Segundo Christopher Alexander, citado em DEVMEDIA (2020): 
Cada padrão descreve um problema que ocorre repetidamente em nos-
so ambiente, e então descreve o núcleo da solução para esse problema, 
de forma que você possa usar essa solução um milhão de vezes, sem 
nunca o fazer da mesma forma duas vezes. 
Analisando a definição acima entendemos que na área de desenvolvimento de software 
deparamo-nos com problemas comuns em diversas oportunidades. Considerando que 
para o mesmo problema é possível que seja aplicada a mesma solução, a proposta dos 
padrões de projetos é apresentar soluções previamente avaliadas e aceitas para proble-
mas recorrentes. Cada padrão é implementado de acordo com a situação identificada na 
etapa de implementação do software. Assim, seu uso está diretamente relacionado ao 
uso de linguagens de programação que implementem a orientação a objeto.
A técnica de design pattern (padrão de projeto) surgiu em 1970, por meio da apresenta-
ção de algumas soluções de desenvolvimento para problema comuns, ou seja, soluções 
padronizadas para problemas previamente conhecidos, sendo atualmente considerada 
como boa prática para a programação orientada a objeto. 
Com a publicação do livro dos autores Gamma, Helm, Johnson e Vlissides, 
conhecidos como a “Gangue dos Quatro” (Gang of Four) ou GoF, em 1995 foi 
proposto um catálogo de soluções para implementação em projeto de desen-
volvimento de software, passando a ser uma das principais referência para pa-
drão de projeto. Em 1997, com a publicação do livro de Craig Larman, intitulado 
Utilizando UML e Padrões – Uma introdução à análise e ao projeto orientado 
a objetos e ao desenvolvimento iterativo, foi apresentado o padrão GRASP 
(General Responsibility Assignment Software Patterns), que utiliza o conceito 
de atribuição de responsabilidades a classes e objetos para o desenvolvimento 
de um software.
Ampliando o foco
45
O uso de padrões de projeto vem apresentando diversos benefícios, tais como:
• Criação de um vocabulário comum para conversar sobre projetos de software.
• Limitação de espaço paraas soluções.
• Identificação, a partir de nomes, de soluções previamente conhecidas.
• Necessidade de definir padrões de projetos reutilizáveis.
• Uso das melhores práticas na solução de um dado problema.
• São utilizados em conjunto com outras soluções para resolver problemas de 
grande porte.
Os padrões devem possuir um formato previamente definido, facilitando a produção de 
sua documentação e aprendizado. Devem conter: 
• Nome: para que haja uma referência de fácil identificação.
• Problema: para o entendimento do contexto ao qual ele se aplica.
• Solução: para o entendimento da solução proposta ao problema.
• Consequência/Forças: deve apresentar as vantagens e desvantagens do uso do pa-
drão a partir da descrição de suas forças e restrições aplicadas e como elas interagem.
Com base na documentação produzida, a seleção de um padrão de projeto deve atender 
aos seguintes critérios:
• Deve solucionar problemas de projeto e deve ser implementado para atender de 
forma objetiva a tal problema.
• Verificar o comportamento do padrão e de sua implementação quando relacio-
nados a outros.
• Deve atender às necessidades do software sem que seja necessário adaptá-lo ao 
padrão utilizado.
• Avaliar o melhor padrão a ser utilizado, considerando suas características e os 
fatores positivos e negativos dessa escolha.
O uso de cada um dos padrões deve estar associado ao problema identificado 
na etapa de implementação do software e ao objetivo de cada um deles. O 
uso do padrão correto é importante para o desenvolvimento exato do software. 
Para isso é importante conhecer o objetivo de cada um deles e a maneira como 
devem ser implementados na linguagem de programação orientada à objeto.
Importante
46
O padrão orientado a objeto GRASP 
O padrão GRASP relaciona a responsabilidade que os objetos possuem entre si, ou seja, 
para definir a responsabilidade de um objeto deve-se considerar o que ele irá fazer ou 
saber, assim descritas, conforme DEVMEDIA (2020):
As responsabilidades relativas ao que um objeto faz incluem:
• A execução de ações que condizem com o papel desempenhado por tal objeto.
• A criação de outros objetos dos quais a instância (objeto) inicial depende.
• A coordenação de atividades envolvendo vários outros objetos.
Quanto ao que um objeto sabe, é possível citar:
• O conhecimento sobre os outros objetos relacionados.
• O conhecimento dos dados privados, que o objeto em questão encapsula.
• O conhecimento a respeito de coisas que serão calculadas ou derivadas a partir 
de um elemento principal.
Assim, um objeto deve identificar as responsabilidades e atribuições atribuídas a ele e 
aqueles que enxerga, como uma instância de uma nota fiscal, que deve visualizar todas 
as informações relacionadas aos itens que compõem essa nota em uma implementação 
de Composição do Diagrama de Classe.
Para fazer uso de um padrão, você deve conhecer o seu objetivo, avaliar a sua 
aplicação na situação que se apresenta e verificar se ele realmente atende ao 
que deseja. Para alguns deles, não existe uma relação direta e objetiva que pos-
sa associar o problema ao padrão. Com a prática, essa identificação vai se 
tornando mais clara pois, em alguns casos, é possível mapear algo concreto 
próximo dessa relação. Em outros casos, no entanto, essa associação é con-
ceitual e abstrata, não havendo um exemplo objetivo fora do contexto da imple-
mentação de uma aplicação.
Importante
47
O GRASP apresenta nove padrões, a saber:
Padrões GRASP
Creator 
(Criador)
Define qual classe será responsável pela criação da ins-
tância de seus objetos.
Information Expert 
(Especialista na Informação)
Determina a atribuição da responsabilidade à classe 
que tenha a informação necessária.
Low Coupling 
(Baixo Acoplamento)
Atribui responsabilidades de modo que o acoplamento 
entre os objetos seja baixo. Quanto menos dependên-
cias houver entre as classes, melhor.
High Cohesion 
(Alta Coesão)
Define que as classes devem tratar exclusivamente de 
suas responsabilidades. 
Controller 
(Controlador)
Atribui as responsabilidades de manipular eventos do 
sistema.
Polymorphism 
(Polimorfismo)
Atribui responsabilidades a abstrações, possibilitando 
que possam variar de acordo com a necessidade.
Pure Fabrication 
(Fabricação/Invenção Pura)
Classe artificial, que não representa um domínio do pro-
blema. Atua como uma classe prestadora de serviços 
para obter baixo acoplamento e alta coesão.
Indirection 
(Indireção)
Ajuda a manter baixo acoplamento entre dois elemen-
tos, atribuindo a um objeto intermediário a responsabili-
dade de ser o mediador entre eles.
Protected Variations 
(Variações Protegidas)
Protege os elementos do sistema das variações de outros.
Para conhecer mais profundamente os conceitos sobre padrões de projeto 
GRASP, consulte o livro Utilizando UML e Padrões: uma introdução à análise 
e ao projeto orientados a objetos e ao desenvolvimento iterativo, de Craig 
Larman. Disponível na Minha Biblioteca.
Ampliando o foco
48
O padrão de projeto GoF
O padrão Gof é dividido em três categorias, que, por sua vez, incluem 23 padrões de 
projetos propostos como as melhores práticas de soluções para as situações a que se 
propõem resolver. Segundo Gamma et al. (2007) as três categorias são:
• Padrões de criação: “os padrões de criação abstraem o processo de instancia-
ção. Eles ajudam a tornar um sistema, independentemente de como seus objetos 
são criados, compostos e representados. Um padrão de criação de classe usa a 
herança para variar a classe que é instanciada, enquanto um padrão de criação de 
objeto delegará a instanciação para outro objeto.”
• Padrões estruturais: “os padrões estruturais se preocupam com a forma como 
classes e objetos são compostos para formar estruturas maiores. Os padrões es-
truturais de classes utilizam a herança para compor interfaces ou implementações.”
• Padrões comportamentais: “os padrões comportamentais se preocupam com 
algoritmos e a atribuição de responsabilidades entre objetos. Os padrões compor-
tamentais não descrevem apenas padrões de objetos ou classes, mas também os 
padrões de comunicação entre eles. Esses padrões caracterizam fluxos de controle 
difíceis de seguir em tempo de execução. Eles afastam o foco do fluxo de controle 
para permitir que você se concentre somente na maneira como os objetos são in-
terconectados.”
Divisão dos padrões de acordo com o escopo.
Propósito
1. Criação 2. Estrutura 3. Comportamento
Escopo Classe Factory Method Class Adapter Interpreter Template Method
Objeto
Abstract Factory
Builder
Prototype
Singleton
Object Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Chain of 
Responsability
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
Fonte: sites.google.com.
https://sites.google.com/site/metodosavancadoprogramacao/padroes
49
Os padrões de criação
Os autores do padrão Gof classificam e definem os padrões a seguir como sendo de criação. 
Segundo Gamma et al. (2007):
• Factory Method: “definir uma interface para criar um objeto, mas deixar as sub-
classes decidirem qual classe instanciar. O Factory Method permite adiar a instan-
ciação para subclasses.” Dessa forma, os objetos são instanciados e suas subclas-
ses decidem que outros objetos devem ser criados no momento que necessitarem. 
• Abstract Factory: “fornecer uma interface para criação de famílias de objetos re-
lacionados ou dependentes sem especificar suas classes concretas.” Logo, permite 
a criação de objetos sem especificar as classes concretas.
• Builder: “separar a construção de um objeto complexo da sua representação de 
modo que o mesmo processo de construção possa criar diferentes representações.” 
Dessa forma, o padrão realiza o encapsulamento da construção do produto, além de 
permitir sua construção em etapas.
• Prototype: “especificar os tipos de objetos a serem criados usando uma instân-
cia-protótipo e criar objetos a partir dele.” Com o uso desse padrão é possível criar 
novas instancias copiando deoutras já existentes.
• Singleton: “garantir que uma classe tenha somente uma instância fornecendo 
um ponto global de acesso a ela.” Ou seja, garante que apenas um objeto de uma 
determinada classe seja criada na aplicação.
Os padrões estruturais
Os autores do padrão Gof classificam e definem os padrões a seguir como sendo es-
truturais. Segundo Gamma et al. (2007):
• Adapter (Class/Object): “converter a interface de uma classe em outra interface, 
esperada pelos clientes. permitindo que classes com interfaces incompatíveis tra-
balhem em conjunto.” Utilizado quando necessitamos “adaptar” duas interfaces di-
ferentes criando um método intermediário, que realiza a compatibilização entre elas.
• Bridge: “desacoplar uma abstração da sua implementação, de modo que as duas 
possam variar independentemente.” Assim, forma uma ponte construída para que a 
implementação torne-se independente de suas abstrações.
• Composite: compor objetos em estruturas de árvore para representar hierarquias 
partes-todo. Esse padrão permite aos clientes tratar de maneira uniforme objetos 
individuais e composições de objetos”, devendo ser utilizado em implementações 
dessas estruturas, tratando seus objetos de maneira uniforme.
50
• Decorator: “dinamicamente, agregar responsabilidades adicionais a um objeto. 
Eles fornecem alternativa flexível ao uso de subclasses para extensão de funciona-
lidades.” Desse modo, ele permite que o objeto “decorador” crie ou incorpore suas 
funcionalidades em tempo de execução. 
• Facade: “fornecer uma interface unificada para um conjunto de interfaces em um 
subsistema. Define uma interface de nível mais alto que torna o subsistema mais 
fácil de ser usado.” Com o uso desse padrão é possível simplificar um sistema com-
plexo a partir do uso de uma classe com uma interface mais simples.
• Flyweight: “usar compartilhamento para suportar eficientemente grandes quan-
tidades de objetos de granularidade fina.” Esse padrão visa reduzir a quantidade de 
recursos utilizados pela aplicação minimizando o consumo de memória.
• Proxy: “fornece um substituto (surrogate) ou marcador da localização de outro 
objeto para controlar o acesso a esse objeto.” Assim, forma a classe “proxy” e per-
mite a conexão a qualquer objeto, passando o controle a esse objeto.
Os padrões comportamentais
Os autores do padrão Gof classificam e definem os padrões adiante como sendo com-
portamentais. Segundo Gamma et al. (2007):
• Interpreter: “dada uma linguagem, definir uma representação para a sua gra-
mática juntamente com um interpretador que usa a representação para interpretar 
sentenças dessa linguagem”, sendo o seu uso comum quando necessita fazer a 
conversão de um modelo para outro, como transformar uma data de um formato 
para outro.
• Template Method: “definir o esqueleto de um algoritmo em uma operação, pos-
tergando alguns passos para as subclasses. Template Method permite que subclas-
ses redefinam certos passos de um algoritmo sem mudar a sua estrutura.” Desse 
modo, o padrão é utilizado quando uma subclasse decide em tempo de execução 
como realizar a lógica da aplicação.
• Chain of Responsability: “evitar o acoplamento do remetente de uma solicitação 
ao seu receptor ao dar a mais de um objeto a oportunidade de tratar a solicitação. 
Encadear os objetos receptores, passando a solicitação ao longo da cadeia até que 
um objeto a trate.” Esse padrão permite que o método avalie a solicitação, executan-
do-a ou repassando-a para outro.
• Command: “encapsular uma solicitação como um objeto, desta forma permitindo 
parametrizar clientes com diferentes solicitações, enfileirar ou fazer o registro (log) 
de solicitações e suportar operações que podem ser desfeitas.” Esse padrão define 
como criar objetos de comandos que realizam solicitações para alguns objetos.
51
• Iterator: “fornecer um meio de acessar, sequencialmente, os elementos de um 
objeto agregado sem expor a sua representação subjacente.” Assim, o padrão tem 
como objetivo encapsular uma interação a partir da interface definida na aplicação.
• Mediator: “definir um objeto que encapsula a forma como um conjunto de obje-
tos interage. O Mediator promove o acoplamento fraco ao evitar que os objetos se 
refiram uns aos outros explicitamente e permite variar suas interações independen-
temente.” Esse padrão permite a intermediação entre dois objetos que não se comu-
nicam de forma direta, ou seja, caso o objeto A não possa comunicar-se diretamente 
com o objeto B ele se comunica com o Mediator e este faz a comunicação com o B.
• Memento: “sem violar o encapsulamento, capturar e externalizar um estado in-
terno de um objeto, de maneira que o objeto possa ser restaurado para esse estado 
mais tarde.” Logo, sempre que for necessário restaurar o objeto à situação original, 
como se fosse a opção “Desfazer” ou “Cancelar”, é indicado o uso desse padrão.
• Observer: “definir uma dependência um-para-muitos entre objetos de maneira 
que quando um objeto muda de estado todos os seus dependentes são notificados 
e atualizados automaticamente”, devendo ser utilizado sempre que houver neces-
sidade de fazer algum tipo de notificação para alguém ou algum objeto, quando 
ocorrer mudança do estado de uma instância da classe.
• State: “permite a um objeto alterar seu comportamento quando o seu estado in-
terno muda.” Dessa forma, quando um objeto possui diferentes comportamentos 
de acordo com o seu estado, esse padrão promove a execução do comportamento 
vinculado ao estado atual. Por exemplo, as ações que devem ser implementadas 
para uma instância da classe “AssentoAviao” variam se esse assento está disponí-
vel, reservado ou ocupado.
• Strategy: “definir uma família de algoritmos, encapsular cada uma delas e tor-
ná-las intercambiáveis. Strategy permite que o algoritmo varie independentemente 
dos clientes que o utilizam.” Deve ser utilizado quando a aplicação possui um con-
junto de classes com lógicas semelhantes, porém objetivos distintos. Nesse caso, o 
padrão permite a criação de uma superclasse que contemple as diferentes lógicas 
aplicadas às subclasses criadas.
• Visitor: “representar uma operação a ser executada nos elementos de uma estru-
tura de objetos. Visitor permite definir uma nova operação sem mudar as classes 
dos elementos sobre os quais opera.” Desse modo forma um novo método agrega-
do a um objeto em tempo de execução.
A figura a seguir, sobre “Classificação dos padrões de acordo com o foco” apresenta 
outro modelo de classificação dos padrões, tendo como ênfase o seu foco de atuação 
associado ao problema a ser solucionado. Segundo Metsker (2004), “o objetivo de um 
padrão de projeto em geral é facilmente expresso com a necessidade de ir além das 
52
características comuns embutidas em Java”. A classificação apresentada por Metsker é 
definida da seguinte forma:
• Interfaces: quando o padrão declara os métodos implementados por uma classe.
• Responsabilidade: quando o padrão atribui a responsabilidade a outras entida-
des ou sistemas.
• Construção: quando o padrão cria mecanismos para instanciar a classe.
• Operação: quando o padrão implementa um método com características diferen-
tes à execução comum de um método, como o encapsulamento de procedimentos 
de diferentes classes.
• Extensão: representa o acréscimo de uma classe, interface, método ou subclasse 
conforme as características do padrão. 
Classificação dos padrões de acordo com o foco.
Intenção Padrões
1. Interfaces Adapter, Facade, Composite, Bridge.
2. Responsabilidade Singleton, Observer, Mediator, Proxy, Chain of Responsability, Flyweight.
3. Construção Builder, Factory Method, Abstract Factory, Prototype, Memento.
4. Operações Tempate Method, State, Strategy, Command, Interpreter.
5. Extensões Decorator, Iterator, Visitor.
Fonte: sites.google.com.
https://sites.google.com/site/metodosavancadoprogramacao/padroes
53
Para conhecer mais profundamente os conceitos sobre padrões de projeto Gof, 
consulte o livro Padrões de Projeto: soluções reutilizáveis de