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 desoftware orien-
tado a objetos, de Erich Gamma, Richard Helm, Ralph Johnson e John Vlissi-
des. Disponível na Minha Biblioteca. 
Ampliando o foco
Para ampliar o seu conhecimento veja o material complementar da Unidade 2, 
disponível na midiateca.
MIDIATECA
Ao realizar a implementação de um software, o desenvolvedor deve utilizar os 
padrões arquiteturais previamente definidos por atender aos requisitos não fun-
cionais do sistema. Por exemplo, com base na linguagem de programação a 
ser utilizada o desenvolvedor deverá ter acesso ao padrão arquitetural associa-
do a ela e deve utilizar os componentes que implementem algumas das suas 
funcionalidades, como o uso da biblioteca “String” quando for necessário ma-
nipular esse tipo de variável no programa a partir de um dos métodos contidos 
na biblioteca. Essa mesma regra serve para as todas as operações implemen-
tadas, tais como: entrada e saída, tratamento de erros etc.
Ao desenvolver um software, utilizar o padrão MVC por ser de grande relevância no 
aspecto arquitetural por restringir a chamada na camada de visão de métodos da 
classe de negócio, além de criar independência entre as camadas possibilitando o 
NA PRÁTICA
54
reúso dos códigos desenvolvidos na camada de negócio. Outro fator importante 
no uso desse padrão está relacionado à segurança, uma vez que os componentes 
utilizados na visão são transferidos para o equipamento do usuário. Assim, ele não 
pode ter acesso a nenhuma informação relacionada ao negócio, razão pela qual o 
uso do controlador como elemento intermediário entre elas torna-se importante. 
Todos os conceitos aplicados no padrão devem ser implementados e documenta-
dos nos diagramas da UML que atendem a representação desses objetivos.
Ao realizar a implementação do software, diversos padrões de projetos podem 
ser utilizados. Para isso, é importante que se saibam os objetivos de cada um 
deles e avalie-se sua aplicação na situação apresentada. Não se esqueça da cria-
ção das classes, interfaces, variáveis e demais recursos que estiverem associa-
dos à solução. Com isso, você conseguirá agilidade no desenvolvimento, pois 
alguns deles simplificam ações que possuem maior complexidade quando são 
implementadas por meio das soluções tradicionais, ou seja, sem uso do padrão.
55
Resumo da Unidade 2
Nesta unidade você estudou algumas das definições de padrões de arquitetura de 
software, que o desenvolvedor deve previamente avaliar e definir para dar início à etapa 
de implementação. Dentro desse contexto, o uso de modelos que implementam a 
interligação de componentes baseados em componentes do software, torna-se um dos 
primeiros fatores a serem definidos. 
CORBA, COM, DCOM são alguns dos frameworks que podem ser selecionados tendo 
como base o ambiente operacional ou a linguagem de programação que será utilizada 
no projeto de desenvolvimento do software. 
Além do padrão arquitetural, torna-se necessário definir se o MVC será o padrão a ser 
utilizado na implementação, pois dessa escolha depende a avaliação e a definição dos 
componentes ou métodos das classes de negócios utilizadas, que poderão ter reúso no 
software a ser desenvolvido. Da mesma forma, o conhecimento dos padrões de projeto 
GRASP e Gof também irá agilizar o seu desenvolvimento, sempre que a implementação 
necessitar de alguns desses recursos. Ao definir o uso destes, o desenvolvedor estará 
apto a iniciar a elaboração de alguns dos diagramas propostos pela UML, que serão apre-
sentados nas próximas unidades. 
56
Referências 
BACCARO, M. Arquitetura baseada em componentes. Disponível em: https://marcobac-
caro.wordpress.com/2010/10/05/arquitetura-baseada-em-componentes/. Acesso em: 
10 jul. 2020.
BRASIL. Secretaria Especial de Cultura – Ministério do Turismo. Arquitetura de compo-
nentes. Brasília, DF: Secretaria Especial de Cultura. Disponível em: http://mds.cultura.gov.
br/core.base_rup/guidances/supportingmaterials/use_component_architectures_CBC-
2F6B5.html . Acesso em: 13 jul. 2020.
BRASIL. Secretaria Especial de Cultura – Ministério do Turismo. Arquitetura de siste-
ma. Brasília, DF: Secretaria Especial de Cultura. Disponível em: http://mds.cultura.gov.
br/core.base_rup/guidances/concepts/system_architecture_5F3B1E17.html. Acesso 
em: 13 jul. 2020.
CELESTINO, André Luís. O conceito e as dúvidas sobre o MVC. Disponível em: https://
www.profissionaisti.com.br/o-conceito-e-as-duvidas-sobre-o-mvc/. Acesso em ju-
lho/2020.
COMPONENTES da arquitetura CORBA. Disponível em: https://www.gta.ufrj.br/
grad/00_2/corba/componentes_arquitetura.html. Acesso em: 10 jul. 2020. LINK, E.; ALE
XANDRE, E. B. P.; WOLF, J. L.; STRZYKALSKI, M. S. Uma introdução ao Corba. Disponível 
em: https://www.inf.pucrs.br/~gustavo/disciplinas/sd/material/Artigo_Corba.pdf. Acesso 
em: 5 jul. 2020.
DEVMEDIA. Breve estudo sobre engenharia de componentes. Disponível em: https://
www.devmedia.com.br/breve-estudo-sobre-engenharia-de-componentes/19139. Aces-
so em: 10 jul. 2020.
DEVMEDIA. Desenvolvimento com qualidade com GRASP. Disponível em: https://www.de-
vmedia.com.br/desenvolvimento-com-qualidade-com-grasp/28704. Acesso em: 5 jul. 2020.
DEVMEDIA, Estudo e aplicação do padrão de projeto Strategy. Disponível em: https://
www.devmedia.com.br/estudo-e-aplicacao-do-padrao-de-projeto-strategy/25856. Aces-
so em: 5 jul. 2020.
https://marcobaccaro.wordpress.com/2010/10/05/arquitetura-baseada-em-componentes/
https://marcobaccaro.wordpress.com/2010/10/05/arquitetura-baseada-em-componentes/
http://mds.cultura.gov.br/core.base_rup/guidances/supportingmaterials/use_component_architectures_CBC2F6B5.html
http://mds.cultura.gov.br/core.base_rup/guidances/supportingmaterials/use_component_architectures_CBC2F6B5.html
http://mds.cultura.gov.br/core.base_rup/guidances/supportingmaterials/use_component_architectures_CBC2F6B5.html
http://mds.cultura.gov.br/core.base_rup/guidances/concepts/system_architecture_5F3B1E17.html
http://mds.cultura.gov.br/core.base_rup/guidances/concepts/system_architecture_5F3B1E17.html
https://www.profissionaisti.com.br/o-conceito-e-as-duvidas-sobre-o-mvc/
https://www.profissionaisti.com.br/o-conceito-e-as-duvidas-sobre-o-mvc/
https://www.gta.ufrj.br/grad/00_2/corba/componentes_arquitetura.html
https://www.gta.ufrj.br/grad/00_2/corba/componentes_arquitetura.html
https://www.inf.pucrs.br/~gustavo/disciplinas/sd/material/Artigo_Corba.pdf
https://www.devmedia.com.br/breve-estudo-sobre-engenharia-de-componentes/19139
https://www.devmedia.com.br/breve-estudo-sobre-engenharia-de-componentes/19139
https://www.devmedia.com.br/desenvolvimento-com-qualidade-com-grasp/28704
https://www.devmedia.com.br/desenvolvimento-com-qualidade-com-grasp/28704
https://www.devmedia.com.br/estudo-e-aplicacao-do-padrao-de-projeto-strategy/25856
https://www.devmedia.com.br/estudo-e-aplicacao-do-padrao-de-projeto-strategy/25856
57
DEVMEDIA. Introdução ao Padrão MVC. Disponível em:https://www.devmedia.com.br/
introducao-ao-padrao-mvc/29308. Acesso em: 19 jul. 2020.
DEVMEDIA. Padronizando seus projetos no mundo corporativo – Parte I. Disponível 
em: https://www.devmedia.com.br/padronizando-seus-projetos-no-mundo-corporativo-
-introducao-parte-i/7158. Acesso em: 10 jul. 2020.
DEVMEDIA. Conheça os padrões de projeto. Disponível em: https://www.devmedia.
com.br/conheca-os-padroes-de-projeto/957. Acesso em: 20 jul. 2020.
KON. F. Padrões de projeto de software orientado a objetos. Disponível em: https://
www.ime.usp.br/~kon/presentations/GoF.ppt. Acesso em: 15 jul. 2020.
GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Padrões de Projeto: Soluções reutili-
záveis de software orientado a objetos. Porto Alegre: Bookman, 2007. ISBN 978-85-7780-
046-9. Minha Biblioteca.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orienta-
dos a objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman, 2007. ISBN 
978-85-7780-047-6. Minha Biblioteca.
LINHA DE CÓDIGO. O Component Object Model. Disponível em: http://www.linhadecodi-
go.com.br/artigo/2864/o-component-object-model.aspx.Acesso em: 10 jul. 2020.
LINHA DE CÓDIGO. O Modelo de Arquitetura Corba. Disponível em: http://www.linhade-
codigo.com.br/artigo/299/o-modelo-de-arquitetura-corba.aspx. Acesso em: 10 jul. 2020.
MASSARI. Jorge. Padrão MVC. Arquitetura Model-View-Controller. Disponível em: 
https://www.portalgsti.com.br/2017/08/padrao-mvc-arquitetura-model-view-controller.
html. Acesso em: 8 jul. 2020.
METSKER, S. J. Padrões de projeto em Java. Porto Alegre: Bookman, 2004.
MICROSOFT. Component Object Model (COM). Disponível em: https://docs.microsoft.
com/en-us/windows/win32/com/component-object-model--com--portal. Acesso em: 
14 ago. 2020.
https://www.devmedia.com.br/introducao-ao-padrao-mvc/29308
https://www.devmedia.com.br/introducao-ao-padrao-mvc/29308
https://www.devmedia.com.br/padronizando-seus-projetos-no-mundo-corporativo-introducao-parte-i/7158
https://www.devmedia.com.br/padronizando-seus-projetos-no-mundo-corporativo-introducao-parte-i/7158
https://www.devmedia.com.br/conheca-os-padroes-de-projeto/957
https://www.devmedia.com.br/conheca-os-padroes-de-projeto/957
https://www.ime.usp.br/~kon/presentations/GoF.ppt
https://www.ime.usp.br/~kon/presentations/GoF.ppt
http://www.linhadecodigo.com.br/artigo/2864/o-component-object-model.aspx
http://www.linhadecodigo.com.br/artigo/2864/o-component-object-model.aspx
http://www.linhadecodigo.com.br/artigo/299/o-modelo-de-arquitetura-corba.aspx
http://www.linhadecodigo.com.br/artigo/299/o-modelo-de-arquitetura-corba.aspx
https://www.portalgsti.com.br/2017/08/padrao-mvc-arquitetura-model-view-controller.html
https://www.portalgsti.com.br/2017/08/padrao-mvc-arquitetura-model-view-controller.html
https://docs.microsoft.com/en-us/windows/win32/com/component-object-model--com--portal
https://docs.microsoft.com/en-us/windows/win32/com/component-object-model--com--portal
58
PRACTICE: desenvolvimento baseado em componentes. Disponível em: https://www.
agtic.ufpr.br/pds-ufpr/ProcessoDemoisellePlugin/guidances/practices/componen-
tes_6A150B73.html. Acesso em: 7 jul. 2020.
VILAS BOAS, L. Padrões GRASP – Padrões de Atribuir responsabilidades. Disponível 
em: https://medium.com/@leandrovboas/padr%C3%B5es-grasp-padr%C3%B5es-de-a-
tribuir-responsabilidades-1ae4351eb204. Acesso em: 20 jul. 2020.
https://www.agtic.ufpr.br/pds-ufpr/ProcessoDemoisellePlugin/guidances/practices/componentes_6A150B73.html
https://www.agtic.ufpr.br/pds-ufpr/ProcessoDemoisellePlugin/guidances/practices/componentes_6A150B73.html
https://www.agtic.ufpr.br/pds-ufpr/ProcessoDemoisellePlugin/guidances/practices/componentes_6A150B73.html
mailto:https://medium.com/@leandrovboas/padr%C3%B5es-grasp-padr%C3%B5es-de-atribuir-responsabilidades-1ae4351eb204
mailto:https://medium.com/@leandrovboas/padr%C3%B5es-grasp-padr%C3%B5es-de-atribuir-responsabilidades-1ae4351eb204
Diagramas estruturais da UML
UNIDADE 3
60
A UML (Unified Modeling Language) é uma linguagem de modelagem utilizada para es-
pecificar, visualizar, construir e documentar artefatos de software. É uma notação gráfica 
padrão para uso em projetos de sistemas desenvolvidos no paradigma da Orientação a 
Objetos. É composta por 13 diagramas, que se dividem em dois grandes grupos: diagra-
mas comportamentais e diagramas estruturais.
Os diagramas comportamentais apresentam como o sistema responde às requisições, 
eventos ou como o mesmo evolui durante o tempo. Já os diagramas estruturais apresen-
tam as características estruturais do sistema. 
Esta unidade aborda três diagramas estruturais: Diagrama de Pacotes, Diagrama de 
Componentes e Diagrama de Objetos. A UML, de acordo com a OMG ( Grupo de 
Gerenciamento de Objetos, uma organização Internacional, fundada em 1889), forne-
ce a arquitetos de sistemas, engenheiros de software e desenvolvedores de software 
ferramentas de análise, design e implementação para sistemas baseados em software 
orientado a objetos. 
INTRODUÇÃO
Nesta unidade você será capaz de:
• Construir a modelagem física de um sistema utilizando os diagramas 
estruturais da UML.
OBJETIVO
61
Diagrama de Pacotes 
O Diagrama de Pacotes faz parte do grupo de diagramas estruturais da UML e tem por 
objetivo representar os pacotes ou pedaços do sistema divididos em agrupamentos lógi-
cos, mostrando as dependências entre eles e as partes que os compõem. 
Os diagramas de pacotes são frequentemente utilizados em conjunto com outros diagra-
mas (classes, componentes, implantação etc.) para demonstrar como esses elementos 
são agrupados.
O Diagrama de Pacotes é um diagrama formado por pacotes (package) e relacionamen-
to entre eles.
Componentes do Diagrama de Pacote:
Nome Símbolo Definição
PACOTE
Package
Attributes
É um mecanismo de agrupamento 
genérico (lógico ou físico).
Um pacote em UML é um mecanismo de agrupamento genérico (lógico ou 
físico), que pode ser formado por classes, interfaces, componentes, diagramas 
ou até outros pacotes.
- Um pacote lógico é um agrupamento lógico de classes e relações entre 
essas classes. 
- Um pacote físico representa uma estrutura física, como: arquivo fonte, 
imagem etc.
Um pacote pode relacionar-se com outros. Os relacionamentos permitidos 
entre pacotes são de dependência, refinamento e generalização (herança). 
Os relacionamentos mais comuns são: dependência de acesso (simples) e 
dependência de importação.
Importante
62
DEPENDÊNCIA
A linha de dependência UML pode ser 
utilizada para mostrar as dependên-
cias entre pacotes ou entre elemen-
tos dos pacotes, ou seja, como um 
pacote depende ou influencia outro.
Fonte: Elaborada pela autora (2020).
Em um pacote podemos agrupar classes, componentes, nós de uma infraestrutura de 
hardware, entre outros. Além disso, um pacote pode conter outros.
O critério para definir os pacotes é subjetivo, ou seja, depende da visão e das necessidades 
do analista ou projetista e, ainda, da particularidade do cenário que se propõe representar. 
Por exemplo, um dos critérios seria utilizar o Diagrama de Pacotes para representar a 
arquitetura do sistema (conforme exemplo a seguir). Outro critério seria representar os 
pacotes que iriam compor uma aplicação (sistema, sistema web ou aplicativo). Como 
terceiro critério, representar os pacotes de classes que serão utilizados na aplicação (sis-
tema, sistema web ou aplicativo).
Conforme já mencionado, um Diagrama de Pacote pode ser utilizado para realizar diver-
sas representações necessárias e úteis na fase de análise e projeto de sistemas.
Exemplo: apresentar a arquitetura do sistema.
Fonte: Elaborado pela autora (2020).
Sistema Administrativo
<<system>>
Apresentacao
<<layer>>
Negocio
<<layer>>
Dados
<<layer>>
63
O Diagrama de Pacotes do exemplo anterior organiza o sistema em um conjunto de 
camadas lógicas (layers). Cada camada (pacote) tem uma função bem definida no siste-
ma. O diagrama também mostra a dependência (relacionamento entre os pacotes) das 
camadas: uma camada somente solicita serviços da camada inferior e fornece serviços 
para a camada superior. 
Vamos entender as “dependências” no Diagrama de Pacotes. 
As dependências, geralmente, são divididas em dois grupos: de acesso e de importação.
1. Dependência de acesso: o pacote A depende, de alguma forma, do pacote B. 
É chamada também, de dependência simples.
No exemplo a seguir, a comunicação depende de segurança.
Fonte: Elaborada pela autora (2020).
2. Dependência de importação («import»): o pacote A importa os elementos 
públicos do pacote B.
No exemplo a seguir o pacote “venda” importa do pacote “dao”.
Fonte: Elaborada pela autora (2020).
comunicacao seguranca
venda <<import>> dao
64
Existem outras categorias de dependência, como: uso, abstração e disponibili-
zação. Essas são menos utilizadas.
Dependência de Uso
Ocorre quando um determinado pacote nomeado requer outro para sua 
definição e implementação completa. 
Exemplo: cliente e fornecedor.
Dependência de Abstração
Relaciona dois pacotes que representam o mesmo conceito em diferen-
tes níveis de abstração no sistema (geralmente uma relaçãoentre cliente 
e fornecedor).
Exemplo: cliente e fornecedor.
Dependência de Disponibilização
Apresenta a implementação de um artefato em um alvo de implementação.
Ampliando o foco
Alguns estereótipos utilizados nos Diagramas de Pacotes:
«system»
Pacote que representa o sistema completo que está sendo 
modelado.
«subsystem»
Pacote que representa uma parte independente do sistema que 
está sendo modelado. Corresponde normalmente a um corte 
“vertical”.
«layer» Pacote que representa uma camada lógica de um sistema.
«framework»
Pacote que representa um conjunto de classes abstratas e con-
cretas concebido para ser estendido, implementando uma fun-
cionalidade específica.
«facade» (fachada)
Pacote sem nenhum elemento (vazio), que representa uma vi-
são sobre outro pacote (não acrescenta funcionalidades, ape-
nas as apresenta de forma diferente).
65
Exemplos 
Exemplo 1: Diagrama de Pacotes.
No exemplo a seguir são apresentados os pacotes, seus elementos e o relacionamento 
entre eles. A linha de dependência UML, neste contexto, é utilizada para apresentar as 
dependências entre os pacotes do diagrama.
Fonte: Campos e Costa (2017).
O Diagrama de Pacote acima apresenta o relacionamento que é necessário existir entre 
os pacotes, viabilizando um mecanismo para propagação das mudanças de forma a 
manter a consistência entre Model e View:
Control
<<interface>>
InterfaceDoViewer
ControleDeObjetos
ControleDeColisao
Model
Bola Bola
Viewer2D
Viewer2D
Viewer3D
Desenhar3DViewer3D
Utilitarios
Util3D
66
Os Controllers recebem a entrada do usuário 
(geralmente eventos).
Após receber a requisição e alterar seu estado interno
o Model notifica todas as Views a ele conectadas.
As Views notificadas recuperam os dados do Model
e atualizam as informações para o usuário.
Eventos são traduzidos em requisições de serviço, 
que são enviadas para o Model ou para a View.
Exemplo 2: Diagrama de Pacotes - Sistema e Subsistemas.
Neste segundo exemplo o Diagrama de Pacotes apresenta um sistema administrativo e 
seus módulos, ou seja, o sistema Administrativo possui os módulos Contabilidade (sub-
sistema), Financeiro (subsistema), RH (subsistema) e Vendas (subsistema). Para apre-
sentar esta lógica, foi utilizado o Diagrama de Pacotes em que cada pacote corresponde 
a um subsistema. 
SistemaAdministrativo
<<system>>
Contabilidade
<<subsystem>>
Financeiro
<<subsystem>>
RH
<<subsystem>>
Vendas
<<subsystem>>
67
Diagrama de Componentes
O Diagrama de Componentes especifica um conjunto de componentes que podem ser 
usados para definir sistemas de software. Os diversos componentes podem ter relacio-
namentos entre si e esses relacionamentos podem ser de qualquer tipo: dependência, 
generalização, associação ou realização.
Cabe destacar que existe uma diferença na definição de componente da 
UML 1.x para a UML 2.x.
Na UML 1.x, um componente representa uma estrutura física (arquivo). Como exemplos, 
podemos citar:
• Arquivo executável.
• Biblioteca de classes ou funções.
• Arquivo de dados. 
• Banco de dados.
• Tabela do banco de dados.
• Arquivo de configuração.
• Imagem; documento.
• Arquivo-fonte etc.
Atualmente, na UML 2.x, o Diagrama de Componentes tem por objetivo apresentar os com-
ponentes, especificando quais são suas interfaces, permitindo que outros componentes 
possam acessar seus serviços sem que para isso precisem conhecer seu conteúdo.
O componente é uma unidade modular com interfaces bem definidas e subs-
tituíveis dentro do seu ambiente. Em outras palavras, um componente é uma 
parte reusável e substituível do software.
Com relação ao relacionamento, os componentes de um diagrama não funcio-
nam sozinhos, pois existem diferentes níveis de colaboração entre eles. Grafi-
camente, o relacionamento é representado por linhas de tipos diferentes para 
cada tipo de relacionamento.
Importante
68
Para que sejam componentes reusáveis e substituíveis eles devem estar fracamente aco-
plados, ou seja, a dependência entre eles deve ser fraca. Quando a dependência é fraca, 
conseguimos substituir um componente (artefato) sem afetar os demais. Nesse sentido, 
os componentes devem interagir uns com os outros sempre por meio de interfaces. 
Componentes do Diagrama de Componentes:
Nome Símbolo Definição
COMPONENTE
<<componentent>>
AcessoSistema
<<componentent>>
Banco de dados SQLite
É representado como um retângulo, 
é utilizado o estereótipo
<<component>> seguido do nome 
do referido componente. 
Atenção: também pode ser incluído, 
no canto direito, um ícone (um retân-
gulo com duas tabs sobrepostas) 
similar à representação antiga. 
INTERFACE 
PROVIDA
É o serviço ou informação provida ou 
oferecida por um componente. Pode 
ser representado por uma “bola”.
INTERFACE 
REQUERIDA
É o serviço ou informação que o 
componente necessita para realizar 
o seu trabalho. Pode ser representa-
do por um “soquete”.
DEPENDÊNCIA
A linha de dependência UML pode 
ser utilizada para mostrar as de-
pendências entre os componentes, 
ou seja, a ligação entre a interface 
provida e a requerida também é 
definida com o relacionamento de 
dependência.
Fonte: Elaborado pela autora (2020).
Um componente é um elemento abstrato e não necessariamente uma única clas-
se. Deve ser entendido como um artefato (caixa preta) reusável e substituível.
Importante
69
Algumas ferramentas UML permitem a ligação direta da bola com o soquete, 
sem a necessidade da dependência.
Importante
Alguns estereótipos utilizados nos Diagramas de Componentes:
«file» Arquivo: é um arquivo de dados do sistema.
«libray» Biblioteca: é uma biblioteca de código.
«document» Documento: é um documento de sistema.
«executable» Executável: é um arquivo executável
«table» Tabela: é uma tabela de um banco de dados
Fonte: Elaborado pela autora (2020).
Exemplos
Exemplo 1: Diagrama de Componentes.
Para refletir
Para que servem os diagramas?
Eles são construídos para planejar, discutir os possíveis componentes, validar e 
depois documentar a aplicação (programa) construída.
70
O componente Compressor
usa o serviço provido pelo
componente Loader
CompressorLoader <<interface>>
FileLoader
+ load (path: String): File
<<interface>>
FileCompressor
+ compress (path: String): CompressedFile
Fonte: Elaborada pela autora (2020).
No exemplo 1 a ligação entre a interface provida e a requerida também é definida com o 
relacionamento de dependência (seta pontilhada).
Para explicitar exatamente quais serviços estão disponíveis em uma interface podemos 
adotar a notação utilizada no exemplo 1:
Fonte: Elaborada pela autora (2020).
Nesse caso, é possível visualizar os métodos disponíveis, seus parâmetros e tipo de re-
torno. Ainda, nessa notação podemos utilizar os estereótipos << provided interface>> e << 
required interface>> para identificar as interfaces providas e requeridas.
O componente Loader
disponibiliza o método
load a partir da
interface FileLoader
<<interface>>
FileLoader
+ load (path: String): File
71
Para quem for utilizar essa notação, em que as interfaces são descritas no 
diagrama, é importante conhecer a sintaxe das interfaces. 
Importante
Exemplo 2: Diagrama de Componentes. 
Fonte: Melo (2011, p. 215).
No exemplo 2, o Diagrama de Componentes mostra o componente de acesso ao sistema 
associado a três interfaces, duas interfaces provida (“IvalidaUsuario” e “IValidaSenha”) e 
uma interface requerida (“IConexao”).
Outra forma de representar o Diagrama de Componentes do exemplo 2:
Fonte: Melo (2011, p. 215).
<<component>>
AcessoSistema
IValidaUsauario IValidaSenha
IConexao
<<component>>
AcessoSistema
<<provided interface>> + IValidaUsuario
<<provided interface>> + IValidaSenha
<<required interface>> + IConexao
72
Diagrama de Objetos
O Diagrama de Objetos é um refinamento realizado no Diagrama de Classes. Os elemen-
tos do Diagrama de Objetos são especificações de instâncias, ou seja, fornecem uma 
visão dos valores armazenados pelos objetos de um Diagrama de Classe (modelo de 
domínio) emum determinado momento da execução de um processo — fato que explica 
a associação dos dois diagramas.
O Diagrama de Objeto, também chamado de Diagrama de Instância, apresenta um 
arranjo de objetos e seus relacionamentos no tempo. 
De acordo com o exposto, podemos entender o Diagrama de Objetos como uma instân-
cia do Diagrama de Classe no qual temos para cada classe um objeto (instância) em um 
determinado ponto do tempo. Logo, é necessário chamar a atenção para o seguinte fato: 
Só devemos criar objetos que tenham relevância dentro da modelagem. 
Dessa forma, na hora de criarmos o Diagrama de Objetos, só vamos criar objetos para o con-
junto de classes complexas, ou seja, para modelagem de estruturas complexas de dados.
Para criar um Diagrama de Objeto basta pegar o Diagrama de Classes (domí-
nio), identificar as classes complexas que necessitam ser modeladas e substi-
tuí-las por objetos e seus relacionamentos. Deve-se, ainda, utilizar anotações e 
cores diferenciadas para chamar a atenção no diagrama.
Importante
73
Exemplo 1
Diagrama de Classe.
Fonte: Melo (2011, p. 138).
No Diagrama de Classe anterior a “Classe Funcionário” é uma classe abstrata, ou seja, 
não poderá haver instâncias diretas dessa classe. Neste caso, precisamos compreender 
o relacionamento das subclasses da “Classe Funcionário”> Para tal utilizamos o Diagra-
ma de Objetos a seguir, a fim de mapear apenas as subclasses com a “Classe Projeto”.
FuncionarioTerceirizado
inicioContrato: date
terminoContrato: date
prestadoraServicos: string
taxaAdministracao: real
1..” 1
1 0..1
trabalha
gerencia
FuncionarioContratado
carteiraProfissional: string
dataAdmissao: date
Funcionario
nome: string
cargo: string
salario: real
Projeto
descricao: string
inicio: date
fim: date
custo: real
74
Diagrama de Objeto.
Fonte: Melo (2011, p. 139).
P1: Projeto
descricao = “Desenvolvimento do Sistema SCMK1”
inicio = “01/06/2000”
fim = “31/12/2000”
custo = 6000,00
F2: FuncionarioContratado
nome = “Maria Santos”
cargo = “Analista de Sistemas”
salario = 3800,00
carteiraProfissional = “0987-5”
dataAdmissao = 01/02/1995
F1: FuncionarioContratado
nome = “Joao Silva”
cargo = “Analista de Sistemas”
salario = 3500,00
carteiraProfissional = “012345-0”
dataAdmissao = 01/06/1997
F3: FuncionarioTerceirizado
nome = “Antonio Souza”
cargo = “Analista de Sistemas”
salario = 2500,00
inicioContrato = 01/05/1999
terminoContrato = 30/04/2001
prestadoraServicos = “CA Terc”
taxaAdmissao = 6
Devemos utilizar o Diagrama de Objeto sempre que for necessário compreender 
o relacionamento de uma classe com outra. Ou seja, quando houver complexi-
dade no relacionamento de determinada classe.
Importante
75
Exemplo 2:
O Diagrama de Objetos a seguir mapeia o relacionamento da Classe Pedido, Classe Item 
Pedido e a classe Produto.
Vamos analisar uma parte do Diagrama de Classe a seguir.
Diagrama de Classe.
Fonte: Bezerra (2015).
No exemplo 2 precisamos compreender o relacionamento da classe Pedido, Item Pedido 
e Produto. Para tal, utilizamos o Diagrama de Objeto para criar instâncias e entendermos 
de forma clara o relacionamento das três classes.
Nesse caso, criamos as instâncias pedido e item pedido e seus produtos, conforme o 
Diagrama de Objeto a seguir:
Cliente
nome
endereço
Pedido
data
hora
obterTotal()
ItemPedido
quantidade
obterTotal()
Produto
nome
descrição
preçoUnitário
desconto
obterValor()
1
*
1 * * 1
76
Diagrama de Objeto.
Fonte: Bezerra (2015).
produto20: Produto
nome = “Caderno M”
descrição = “Caderno em espiral tamanho médio”
preçoUnitário = 4,50
desconto = 15
nome = “Caneta ESF”
descrição = “Caneta esferográfica 5mm” 
preçoUnitário = 1,20
desconto = 2
produto12: Produto
quantidade = 6
item1: ItemPedido
data = 13/09/2002
hora = 10:00am
pedido1: Pedido
quantidade = 20
item2: ItemPedido
nome = “Esquadro”
descrição = “Esquadro de acrílico 20cm” 
preçoUnitário = 2,35
desconto = 10
produto07: Produto
quantidade = 1
item3: ItemPedido
77
Componentes do Diagrama de Objeto.
Nome Símbolo Definição 
Objetos
carro1: Carro
+Ano: int = 2010
+Marca: string = “VW”
+Modelo: string = “Fox Trend”
+Quilometragem: double = 2353190
+ValorDiaria: double = 94.00
+Cor: string = “Preto”
A representação gráfica de um 
objeto é similar à de uma classe. 
É representado por um retângulo 
com dois compartimentos. O pri-
meiro mostra o nome do objeto 
e o segundo apresenta os atribu-
tos, um em cada linha, com seus 
respectivos valores.
É possível, ainda, omitir o nome 
do objeto representando um ob-
jeto anônimo ou omitir o nome 
da classe. Em ambos os ca-
sos se mantêm os dois pontos 
e o sublinhado
Links
É a instância de uma associa-
ção. O nome da associação pode 
ser mostrado na terminação 
dos links.
Fonte: Elaborada pela autora (2020).
78
Ampliando o foco
Os diferentes diagramas que compõem a UML são classificados em três ca-
tegorias: Diagramas Estruturais, Diagramas Comportamentais e Diagramas 
de Interação.
Diagramas Estruturais
Priorizam a descrição estática de estruturas de um sistema, como clas-
ses, atributos e operações dessas classes, além de prováveis relaciona-
mentos entre tais construções.
Diagramas Comportamentais
Detalham o comportamento de partes de um sistema ou processos de 
negócio relacionados à aplicação que se deseja modelar.
Diagramas de Interação
É um subgrupo dos diagramas comportamentais, sendo normalmente 
utilizado na representação de interações entre objetos de uma aplicação.
79
Para ampliar o seu conhecimento veja o material complementar da Unidade 3, 
disponível na midiateca.
MIDIATECA
Vamos imaginar a seguinte situação:
A loja K&K vende eletrodomésticos e, atualmente, está precisando de um siste-
ma para ajudar a gerenciar suas vendas e principalmente a calcular as comis-
sões a serem pagas aos seus vendedores. 
Nessa empresa o valor das comissões varia de acordo com os produtos e ain-
da existe a necessidade de saber algumas informações, como: 
Qual vendedor obteve o maior número de vendas?
Quais são os produtos mais vendidos?
Qual é o produto menos vendido?
Suponha que você seja o analista responsável pelo desenvolvimento do siste-
ma anterior e precisa explicar para a sua equipe como é o relacionamento do 
vendedor com os produtos vendidos. Qual diagrama você usaria para explicar o 
relacionamento da Classe produto com a classe Vendedor?
Nesse caso, você deveria utilizar um Diagrama de Objetos. Quando utilizamos 
o Diagrama de Objetos passamos a analisar dados reais, que auxiliam na com-
preensão, esclarecendo dúvidas relacionadas ao domínio do negócio.
NA PRÁTICA
80
Diagrama de Objeto.
Fonte: Melo (2011, p. 140).
Analisando o Diagrama de Objetos anterior entendemos como é o relaciona-
mento da Classe vendedor com a classe produto. Assim, temos:
• Vendedores que não vendem nada.
• Vendedores que vendem vários produtos.
• Um produto não vendido.
• Um produto vendido por vários vendedores.
De acordo com o exposto, verificamos que o Diagrama de Objetos apresentou 
as diferentes relações que podem existir entre as classes “Vendedor” e “Produ-
to”, pois foi possível trabalhar com suposições reais, representadas no diagra-
ma. Já o Diagrama de Classe mostra apenas as classes Vendedor” e “Produto 
e o relacionamento entre essas classes. 
V2: Vendedor
nome = “Carla”
P2: Produto
descricao = “Geladeira”
V3: Vendedor
nome = “Amelia”
P3: Produto
descricao = “Freezer”
V1: Vendedor
nome = “Carlos”
P1: Produto
descricao = “ TV 14” ”
81
Resumo da Unidade 3
Nesta unidade conhecemos três diagramas estruturais da UML: Diagrama de Pacote, 
Diagrama de Componentes e Diagrama de Objeto. Vimos também quando devemos uti-
lizar esses diagramas e a importância de cada um deles.
Assim, pudemos compreender que um Diagrama de Pacote descreve as dependências 
entre diferentes pacotes que compõem uma aplicação. Já um Diagrama de Componen-
tes apresenta diferentes componentes de um sistema, além de possíveis dependênciasentre tais componentes e elementos desses componentes, enquanto um Diagrama de 
Objeto apresenta uma determinada estrutura de objeto em tempo de execução. 
82
Referências 
BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. 3. ed. Rio de Ja-
neiro: Campus-Elsevier, 2015. ISBN – 978-85-352-2626-3. ISBN (versão digital) 978-85-
352-2627-0. Minha Biblioteca.
GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Padrões de Projeto: soluções reutilizá-
veis de software Orientado a Objetos. 2. ed. Porto Alegre: Bookman, 2000. Minha Biblioteca.
LARMAN, C. Utilizando UML e Padrões: uma Introdução à Análise e Projeto Orientado a 
Objetos e ao Desenvolvimento Iterativo. 3. ed. Porto Alegre: Bookman, 2007. ISBN 978-
85-7780-047-6. Biblioteca Virtual.
MEDEIROS, E.S. Desenvolvendo software com UML 2.0 definitivo. São Paulo: Pearson, 
2004. ISBN 978-85-346-1529-7. Biblioteca Virtual.
MELO, A. C. Desenvolvendo aplicações com UML 2.2: do conceitual à implementação. 
3. ed. Rio de Janeiro: Brasport, 2011. 
Diagramas de implantação 
de um software
UNIDADE 4
84
Nesta unidade vamos abordar os três diagramas da UML utilizados para apresentar os 
detalhes da implantação de um software. Esses diagramas são: Diagrama de Implemen-
tação, Diagrama de Perfil e Diagrama de Implantação. 
Todos compõem o grupo dos diagramas estruturais da UML, e têm por objetivo apresen-
tar a visão física da aplicação que está sendo projetada do ponto de vista do engenheiro, 
em que o foco é a topologia dos componentes de software, hardware e a comunicação 
entre esses componentes. 
INTRODUÇÃO
Nesta unidade você será capaz de:
• Construir os diagramas da UML utilizados na fase de implantação de um sistema.
OBJETIVO
85
Diagrama de Implementação
Os diagramas de implementação compõem o grupo dos diagramas estruturais da UML. 
A função do Diagrama de Implementação é mostrar a visão física da aplicação sob o pon-
to de vista do engenheiro, em que o foco é a topologia dos componentes de software, 
a comunicação entre esses componentes e a distribuição física do processamento.
Os diagramas de implementação, que geralmente são desenvolvidos e analisados du-
rante a fase de codificação (implementação), apresentam a organização física dos nós, 
artefatos, componentes e outros elementos, que compõem um sistema distribuído. Os 
artefatos geralmente são armazenados em um nó. Já os nós representam dispositivos 
de hardware, como servidores, sensores e impressoras, bem como outros dispositivos. 
Por exemplo: os dispositivos que suportam o ambiente de tempo de execução de um sis-
tema, os caminhos de comunicação e relacionamentos de implementação que mostram 
suas conexões.
O Diagrama de Implementação — também chamado de Diagrama de Implantação no 
Nível de Especificação — apresenta a combinação entre os dispositivos de hardware e 
os componentes de software, sem especificar as instâncias dos nós. Esse diagrama co-
meça a ser criado na fase de elaboração e é finalizado na fase de construção, tendo por 
objetivo especificar, documentar e apresentar a visão física do software. 
Um Diagrama de Implementação deve ser criado quando é necessário ana-
lisar ou criar sistemas incorporados, ou seja, que utilizam um hardware que 
é controlado por estímulo externo. Por exemplo: sistemas cliente/servidor 
e sistemas distribuídos. Ambos os sistemas possuem vários servidores e 
podem hospedar várias versões de artefatos de software.
A função dos diagramas de implementação é focar na configuração dos nós de proces-
samento de tempo de execução e de seus componentes e artefatos no nível da especifi-
cação, sem fazer referências a instâncias específicas de artefatos ou nós. Nesse sentido, 
é possível utilizar esse tipo de diagrama para avaliar as implicações da distribuição e de 
alocações de recursos.
86
Nome Símbolo Definição
Nós Servidor da 
Aplicação
Nós: podem ser de dois tipos.
Dispositivos de hardware: 
representam recursos com-
putacionais físicos (servi-
dores, dispositivos móveis, 
notebooks, sensores, impres-
soras, roteadores, câmeras, 
leitores biométricos etc.).
Ambientes de execução 
de softwares: representam 
recursos computacionais 
lógicos que oferecem um 
ambiente de execução para 
componentes específicos 
(sistemas operacionais, ser-
vidores web, servidores de 
aplicação, SGBDs etc.).
Associação
Caminhos de comunicação: 
associações entre nós que 
permitem a comunicação, 
ou seja, a troca de dados, 
sinais e mensagens entre 
esses nós.
DEPENDÊNCIA
A linha de dependência UML 
pode ser utilizada para mos-
trar as dependências entre 
pacotes ou entre elementos 
destes, ou seja, como um 
pacote depende ou influên-
cia outro.
87
Nó (contêiner)
<<device>>
:UserClient
<<device>>
:Browser
<<artifact>>
HTML5
Nó que contém outro nó em 
seu interior, que por sua vez 
possui componentes e/ou 
artefatos.
COMPONENTE <<component>>AcessoSistema
Representado como um re-
tângulo, é utilizado o este-
reótipo <<component>> se-
guido do nome do referido 
componente.
ESTEREÓTIPOS <<database>>vendas
É utilizado com um nome 
entre dois sinais de menor 
em sequência e dois sinais 
de maior, também em se-
quência (<< >>). Geralmente 
é predefinido pela UML.
INTERFACE
É o serviço ou informação 
provida ou oferecida por um 
componente. Pode ser re-
presentado por uma “bola”.
ESPECIFICAÇÃO DE 
IMPLEMENTAÇÃO
<<deployment spec>>
DeploymentSpecification1
É basicamente um arqui-
vo de configuração, como 
um documento XML ou um 
arquivo de texto, que espe-
cifica as propriedades que 
definem como um artefato 
é implementado em um nó.
O exemplo a seguir traz o Diagrama de Implementação para apresentar a visão física 
de uma aplicação de controle bancário sendo acessada a partir de um caixa eletrôni-
co. Para tal, foi observado e analisado tudo que era necessário em relação a hardwares 
88
(dispositivos) e componentes de comunicação para o funcionamento da aplicação. Por 
exemplo, o primeiro nó, “Caixa Eletrônico”, precisa ter o monitor, dispensador de dinheiro, 
impressora de recibos, leitor de cartões, teclado numérico e dispositivo de log para fun-
cionar. É necessária, ainda, uma interface de rede com uma conexão para conectar-se a 
um servidor da rede de “Caixas Eletrônicos”. 
Após a identificação dos nós é preciso analisar e verificar o que é necessário em termos 
de artefatos dentro de cada nó. Por exemplo, o Nó Caixa Eletrônico, precisa ter um con-
trolador de dispositivos e ainda uma interface para o usuário interagir com o caixa, além 
da interface de rede responsável pela comunicação. 
De acordo com o exposto, o diagrama a seguir apresenta uma visão geral da implementa-
ção de nós (dispositivo e seus subcomponentes), sem fazer referência a instâncias espe-
cíficas de artefatos ou nós, que deverá ser analisada e detalhada em momento posterior.
Fonte: http://denan.com.br/documentos/DiagramaImplantacao.pdf.
No exemplo, o Diagrama de Implementação de Nível de Especificação (também chamado 
de Nível de Tipo) apresenta uma visão geral da implementação de nós (dispositivo e seus 
subcomponentes), sem fazer referência a instâncias específicas de artefatos ou nós. 
Impressora
de recibos
Leitor de
cartões
Teclado
numérico
Interface
de rede
Interface
de rede
Servidor da
rede de caixas
eletrônicos
preventivo
Caixa eletrônico principal
Interface do cliente
Interface da rede de caixas eletrônicos
Controlador de dispositivos
Processador:
 Pentium 200 Mhz
Memória
 64 MB
conexão da
rede T-1
Nó no caixa 
eletrônico
preventivo
Dispositivo
de log
Dispensador 
de dinheiro
Monitor
http://denan.com.br/documentos/DiagramaImplantacao.pdf
89
Diagrama de Perfil
Os diagramas de perfil compõem o grupo dos diagramas estruturais da UML. É o diagra-
ma mais recente da UML, foi criado na UML 2.2. 
O objetivo do Diagrama de Perfil é produzir perfis que adequem a UML a 
plataformas e tecnologias atuais para os quais a UML não foi projetada.
O Diagrama de Perfil possui um conjunto de perfis que contém estereótipos,definições 
(valores atribuídos), restrições e novos tipos de dados, ou seja, por meio da criação de 
perfis é possível criar novos estereótipos ou metaclasses personalizados com valores 
e restrições. 
Conforme vimos nas unidades anteriores, a UML disponibiliza estereótipos padrões, 
como: <<interface>>, <<file>, <<extends>>, <<include>>, <<database>> e etc. 
• Metaclasse: é uma classe em que suas instâncias também são classes e não 
objetos. Assim como as classes definem o comportamento de certos objetos, 
as metaclasses definem o comportamento de certas classes e suas instâncias.
• Estereótipo: permite adequar os modelos com construções específicas para 
um domínio, plataformas tecnológicas ou método de desenvolvimento parti-
cular. Os estereótipos devem ser criados com um nome entre dois sinais de 
menor em sequência e dois sinais de maior, também em sequência (<< >>). 
Existem dois tipos de estereótipos: predefinidos pela linguagem ou definidos 
pela equipe de desenvolvimento.
Ampliando o foco
90
• Componentes do Diagrama de Pacotes:
Nome Símbolo Definição
Estereótipo (criado / 
perfil)
<<metaclass>>
Actor
<<stereotype>>
InternetActor
<<Perfil>>
EJB
Permitem adaptar ou perso-
nalizar modelos com cons-
truções específicas para 
um domínio, plataforma ou 
método de desenvolvimen-
to particular; é utilizado com 
um nome entre dois sinais 
de menor em sequência e 
dois sinais de maior, tam-
bém em sequência (<< >>).
Associação
Caminhos de comunicação: 
associações entre nós que 
permitem a comunicação, 
ou seja, a troca de dados, 
sinais e mensagens entre 
esses nós.
O Diagrama de Perfil utiliza a mesma notação do Diagrama de Pacotes com a adição da 
palavra <<perfil>> apresentada anteriormente ao nome do pacote, conforme o Exemplo 1.
Exemplos:
Exemplo 1
Apresenta um estereótipo criado para especificar o contêiner de um servidor de aplicação. 
Neste caso é o Enterprise JavaBeans (EJB), um componente da plataforma Java EE, ou 
seja, houve a necessidade de especificar o tipo do componente (pacote) a ser utilizado.
<<Perfil>>
EJB
Fonte: O autor (2020).
91
Exemplo 2
<<Metaclass>>
Connector
<<stereotype>>
ServiceChannel
Fonte: O autor (2020).
O Diagrama de Perfil do exemplo 2 apresenta uma metaclasse “Connector” e um estereó-
tipo para representar o serviço (canal de serviço) a ser utilizado.
92
Diagrama de Implantação
O Diagrama de Implantação da UML tem por objetivo revelar quais partes do software 
são executadas em quais partes do hardware. Esse diagrama foca na estrutura sobre a 
qual o software será implantado e executado em termos de hardware ou combinando 
hardware e software. O Diagrama de Implantação define, ainda, como os dispositivos 
de hardware estarão conectados e por meio de quais protocolos elas se comunicarão. 
Também é chamado de Diagrama de Instalação.
O Diagrama de Implantação é de grande utilidade quando o sistema é projetado para ser 
executado em múltiplos nós, facilitando, dessa forma, a compreensão de todo o funcio-
namento da aplicação (sistema) sobre a sua visão física.
Componentes do Diagrama de Implantação:
Nome Símbolo Definição
Artefatos
<<device>>
Servidor de
Aplicação I
<<artifact>>
Módulo Gerenciador de Login
Representam elementos fí-
sicos concretos (arquivos 
executáveis, bibliotecas, ar-
quivos de configuração etc.).
Associação
Caminhos de comunicação: 
associações entre nós que 
permitem a comunicação, 
ou seja, a troca de dados, 
sinais e mensagens entre 
esses nós.
93
Nós Servidor da 
Aplicação
Nós podem ser de dois tipos:
Dispositivos de hardware: 
representam recursos com-
putacionais físicos (servi-
dores, dispositivos móveis, 
notebooks, sensores, impres-
soras, roteadores, câmeras, 
leitores biométricos etc.).
Ambientes de execução 
de softwares: representam 
recursos computacionais 
lógicos que oferecem um 
ambiente de execução para 
componentes específicos 
(sistemas operacionais, ser-
vidores web, servidores de 
aplicação, SGBDs etc.).
Associação
Caminhos de comunicação: 
associações entre nós que 
permitem a comunicação, 
ou seja, a troca de dados, 
sinais e mensagens entre 
esses nós.
DEPENDÊNCIA
A linha de dependência UML 
pode ser utilizada para mos-
trar as dependências entre 
pacotes ou entre elementos 
destes, ou seja, como um 
pacote depende ou influên-
cia outro.
94
Nó (contêiner)
<<server>>
Servidor de Aplicações
<<executionEnvironment>>
Servidor JSP
AppVenda
Nó que contém outro nó em 
seu interior, que por sua vez 
possui componentes e/ou 
artefatos.
COMPONENTE <<component>>AcessoSistema
Representado como um re-
tângulo, é utilizado o este-
reótipo <<component>> se-
guido do nome do referido 
componente. 
ESTEREÓTIPOS <<database>>vendas
É utilizado com um nome 
entre dois sinais de menor 
em sequência e dois sinais 
de maior, também em se-
quência (<< >>). Geralmente 
é predefinido pela UML.
INTERFACE
É o serviço ou informação 
provida ou oferecida por um 
componente. Pode ser re-
presentado por uma “bola”.
ESPECIFICAÇÃO DE 
IMPLEMENTAÇÃO
<<deployment spec>>
DeploymentSpecification1
É basicamente um arqui-
vo de configuração, como 
um documento XML ou um 
arquivo de texto, que espe-
cifica as propriedades que 
definem como um artefato 
é implementado em um nó.
INSTÂNCIA DE NÓ Node4Instance : Node4
É um elemento de modelo 
que representa uma instan-
ciação de um nó existente, 
ou seja, representa um nó 
definido e específico no am-
biente do sistema.
95
Assim como os demais diagramas da UML, o Diagrama de Implantação pode representar 
a arquitetura do sistema sob diversas perspectivas. As três perspectivas mais comuns são:
• Diagrama de Arquitetura de Rede: apresenta os dispositivos de hardware e os 
links de comunicação entre eles. Também chamado de Diagrama de Perfil, confor-
me já detalhado no Tópico 2 desta unidade.
• Diagrama de Implantação no Nível de Especificação: apresenta a combinação 
entre os dispositivos de hardware e os componentes de software, sem especificar 
as instâncias dos nós. Também chamado de Diagrama de Implementação, confor-
me já detalhado no Tópico 1 desta unidade.
• Diagrama de Implantação no Nível de Instância: apresenta a combinação entre 
os dispositivos de hardware e os componentes de software, especificando as ins-
tâncias nos nós.
Exemplo 1
O Diagrama de Implantação a seguir apresenta uma visão geral da implementação de 
nós (dispositivo e seus subcomponentes), detalhando as referências das instâncias espe-
cíficas dos artefatos e nós do sistema (aplicação) que está sendo construído. O modelo 
foca na visão física da aplicação apresentada, detalhando todos os componentes neces-
sários para o seu funcionamento.
Fonte: Larman (2007).
webstore.war
Notação alternati-
va para um artefato
<<estação de trabalho do cliente>>
: PCGenérico
<<artefato>>
MinhaIGURucaDoCliente.exe
<<estação de trabalho do cliente>>
: PCGenérico
<<navegador>>
:NavegadorWeb
<<servidor>>
: Dell Power Edge 3400
<<SO>>
: Red Hat Enterprise Linux 4}
<<banco de dados>>
: PostgreSQL 10
<<servidor>>
:Dell Power Edge 3600
{SO = Red Hat Enterprise Linux 4}
Ajpv13
<<container de servelet>>
: Tomcat 6
{ JVM = sun Hotspot 2,0 }
<<artefato>>
webstore.war
<<aglomerado de 
servidores Web>>
: Apache 2.1
{contagem 
DoAglomerado = 4}
Nó de ambiente 
de execução
Nó do dispositivo
Um caminho de 
comunicação pode 
indicar o protocolo
SOAP/HTTP
HTTP
SQL
96
Para ampliar o seu conhecimento veja o material complementar da Unidade 4, 
disponível na midiateca.
MIDIATECA
Analise o estudo de caso a seguir:
Uma empresa de venda de bebidas (cervejas artesanais) tem um catálogo com 
cerca de 20 produtos e pouco mais de 100 vendedores. Cada vendedor visita, 
por dia, aproximadamente 50 clientes distribuídos por toda a cidade do Rio de 
Janeiro, Baixada Fluminense e Niterói. O roteiro de visita de cada vendedor é 
fixo por dia da semana. A empresa gostaria de desenvolver um sistema que 
permitisse aos vendedores coletar eletronicamente os pedidos dos clientes 
paraque, ao final do dia, esses pedidos fossem faturados e entregues no dia 
seguinte. Toda a transmissão de dados deve ser feita de forma segura, ou seja, 
criptografada. Os vendedores trabalham distribuídos por toda a cidade, ou seja, 
não existe um local único de onde os vendedores partam ou cheguem ao final 
do dia. Nas localidades de muitos clientes, principalmente os mais afastados, 
não há sinal de telefonia celular disponível ou o sinal é muito fraco.
Vamos supor que você é o responsável por desenvolver esse sistema para co-
letar e processar pedidos. Mais ainda, suponhamos que você precise explicar 
como a solução vai funcionar na prática para todos os envolvidos no projeto 
de desenvolvimento desse novo sistema. Para tal, você deve criar a solução 
arquitetural, ou seja, um Diagrama de Implantação para explicar todo o funcio-
namento estrutural sobre o qual o software será implantado e executado em 
termos de hardware e software utilizados.
NA PRÁTICA
97
SOLUÇÃO:
Diagrama de Implantação:
Fonte: O autor (2020).
Este diagrama apresenta como vai funcionar o sistema a ser desenvolvido.
1. Smartphone (nó), a aplicação será desenvolvida para rodar em plataforma 
Android. Dentro do nó Smartphone existe o nó do sistema operacional Android, 
que por sua vez possui os seguintes componentes: aplicativo de vendas, base 
de dados e um serviço para enviar os pedidos para o servidor de aplicação. 
2. O nó <<app server>> é um servidor que disponibiliza um ambiente para insta-
lação e execução de aplicações, que por sua vez possui um nó Sistema opera-
cional Linux, que possui um servidor apache Tomcat (é um servidor web Java, 
mais especificamente um container de servlets) e um serviço para enviar os 
pedidos para a base de dados.
3. O nó << database server>> é um servidor de banco de dados que usa um 
aplicativo de banco de dados e que fornece serviços de banco de dados. O 
<< database server>> possui o nó Sistema operacional Linux, que possui um 
banco de dados MySQL (artefato) e uma base de dados (artefato) faturamento.
4. O diagrama apresenta, ainda, o tipo de comunicação utilizada entre os nós. Exem-
plo: entre o smartphone e o servidor de aplicação utiliza-se WI, entre os demais nós 
uma comunicação Ethernet. (É uma arquitetura de interconexão para redes locais 
— Rede de Área Local — baseada no envio de pacotes. Define cabeamento e sinais 
elétricos para a camada física, em formato de pacotes e protocolos.) 
98
Resumo da Unidade 4
Nesta unidade aprendemos sobre os diagramas de implantação, que são classificados 
como Diagramas de Implementação, Diagramas de Perfil (que é um tipo de um diagra-
ma de implantação) e Diagramas de Implantação. Esses diagramas são utilizados para 
descrever a topologia dos componentes de hardware e software que fazem parte do 
sistema. Assim como os demais diagramas da UML, o Diagrama de Implantação pode 
representar a arquitetura do sistema sob diversas perspectivas.
As três perspectivas comuns são:
• Diagrama de Implementação: também chamado de Diagrama de Implantação no 
nível de especificação, apresenta a combinação entre os dispositivos de hardware e 
os componentes de software, sem especificar as instâncias dos nós.
• Diagrama de Perfil: apresenta os dispositivos de hardware e os links de comuni-
cação entre eles.
• Diagrama de Implantação no Nível de Instância: apresenta a combinação entre os 
dispositivos de hardware e os componentes de software, especificando as instân-
cias nos nós.
99
Referências 
BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. 3. ed. Rio de Janei-
ro: Campus-Elsevier, 2015. ISBN: 978-85-352-2626-3/ISBN (versão digital): 978-85-352-
2627-0. Minha Biblioteca.
GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Padrões de Projeto: soluções reutilizá-
veis de Software Orientado a Objetos. 2. ed. Porto Alegre: Bookman, 2000. Minha Biblioteca.
LARMAN, C. Utilizando UML e Padrões: uma introdução à análise e projeto Orientado a 
Objetos e ao Desenvolvimento Iterativo. 3. ed. Porto Alegre: Bookman, 2007. ISBN: 978-
85-7780-047-6. Biblioteca Virtual.
MEDEIROS, E. S. Desenvolvendo software com UML 2.0 definitivo. São Paulo: Pearson 
Makron Books, 2004. ISBN: 978-85-346-1529-7. Biblioteca Virtual.
MELO, A. C. Desenvolvendo aplicações com UML 2.2: do conceitual à implementação. 
3. ed. Rio de Janeiro: Brasport, 2011.