II_Teorico (2)

Prévia do material em texto

Inserir Título Aqui 
Inserir Título Aqui
Arquitetura de Software
Padrões de Projeto e Model-View-Controller (MVC)
Responsável pelo Conteúdo:
Prof. Me. Wilson Vendramel
Revisão Textual:
Prof.ª Dr.ª Luciene Oliveira da Costa Granadeiro 
Nesta unidade, trabalharemos os seguintes tópicos:
• Padrões de Projeto e Model-View-Controller (MVC);
• Model-View-Controller (MVC).
Fonte: iStock/Getty Im
ages
Objetivos
• Aplicar métodos e técnicas de análise e projeto arquitetural no processo de desen--
-volvimento de sistemas de software;
• Entender a importância da utilização de padrões de projeto como uma solução reusável 
e o propósito do padrão de arquitetura MVC.
Caro Aluno(a)!
Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o 
último momento o acesso ao estudo, o que implicará o não aprofundamento no material 
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.
Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você 
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns 
dias e determinar como o seu “momento do estudo”.
No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões 
de materiais complementares, elementos didáticos que ampliarão sua interpretação e 
auxiliarão o pleno entendimento dos temas abordados.
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de 
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de 
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de 
troca de ideias e aprendizagem.
Bons Estudos!
Padrões de Projeto e 
Model-View-Controller (MVC)
UNIDADE 
Padrões de Projeto e Model-View-Controller (MVC)
Contextualização 
As aplicações Web estão cada vez mais presentes no mercado de tecnologia da infor-
mação. Isso é fato! A engenharia de software já reconhece que, para obter um software 
melhor, com entrega rápida e custos mais baixos, é necessário um processo de desenvol-
vimento de software baseado na reutilização de softwares existentes. Nos últimos anos, 
tem ocorrido uma mudança significativa a favor do desenvolvimento de sistemas de 
software baseado em reúso. Padrões de projeto, padrões de arquitetura e engenharia de 
software baseados em componentes são abordagens de reúso de software. Uma arqui-
tetura de software recomendada para aplicações Web é a arquitetura em três camadas, 
pois separa a interface de usuário e o comportamento da aplicação. O padrão de arqui-
tetura MVC permite a separação da camada de apresentação da camada de aplicação, 
trazendo benefícios para uma solução de software baseada na Web. 
6
7
Padrões de Projeto e 
Model-View-Controller (MVC)
Este material teórico apresenta a aplicação de métodos e técnicas de análise e projeto 
arquitetural no processo de desenvolvimento de sistemas de software e a importância 
da utilização de padrões de projeto como uma solução reusável, além do propósito do 
padrão de projeto de arquitetura Model-View-Controller (MVC). Para facilitar a com-
preensão da representação do MVC, serão utilizadas notações da Unified Modeling 
Language (UML), especificamente o diagrama de classes.
Reúso de Software
Ao estudar padrões de projeto, nós estamos estudando o reúso de software. O reúso 
(reutilização) de software existente é uma abordagem de desenvolvimento enfatizada 
pelos atuais modelos de processo de desenvolvimento de sistemas de software. A reu-
tilização de componentes é bastante importante no projeto (design) de arquitetura de 
sistemas de software.
Se pensarmos nos atributos de qualidade de um sistema de software, qual seria o atributo 
mais importante para o software? Funcionalidade? Segurança? Portabilidade? Usabilida-
de? Interoperabilidade? Desempenho? Manutenibilidade? Algum outro atributo?
Já pensaram? Na realidade, todos esses atributos são importantes para a qualidade de um 
sistema de software. Dependendo do propósito do software em relação ao domínio de ne-
gócio, alguns atributos devem ser priorizados enquanto outros são relevados. Desde alguns 
anos, percebemos que a qualidade mais importante para um software é estar pronto. Isso 
mesmo, dissemos “estar pronto”. Um software pronto é um software existente e que já exe-
cuta suas funções com qualidade, podendo incluir um ou mais atributos de qualidade mencio-
nados na pergunta supracitada. Nesse caso, por que você vai desenvolver um software novo 
para atender a alguma exigência, sendo que já existe um software pronto para tal?
A maioria das disciplinas de engenharia de sistemas é projetada pela composição de 
componentes existentes que já foram reutilizados em outros sistemas. A própria enge-
nharia de software reconhece que, para obter um software melhor, de forma mais rá-
pida e com custos menores, é necessário um processo de desenvolvimento de software 
baseado no reúso sistemático de softwares existentes. Dessa forma, nos últimos anos, 
tem ocorrido uma mudança significativa favorável ao desenvolvimento de sistemas de 
software baseado em reúso. 
Dentre os benefícios do reúso de software, alguns são elencados logo abaixo:
• Maior confiabilidade: o software existente foi testado e já está em funcionamento, 
sendo provavelmente mais confiável do que desenvolver um software novo;
• Menor risco de processo: o custo do software existente já é conhecido, pois os 
custos de desenvolvimento são uma questão que envolve julgamento;
7
UNIDADE 
Padrões de Projeto e Model-View-Controller (MVC)
• Uso eficaz de especialistas: a reutilização de software evita a repetição do mesmo tra-
balho e encapsula o conhecimento de especialistas em uma solução de software pronta;
• Conformidade com padrões: alguns padrões podem ser implementados como um 
conjunto de componentes reutilizáveis, como, por exemplo, os padrões de interface 
de usuário. A utilização de interfaces de usuário já conhecidas aumenta a confiança 
dos usuários, pois eles tendem a cometer menos erros quando interagem com in-
terfaces as quais já estão familiarizados;
• Desenvolvimento agilizado: o reúso de um software pronto pode acelerar a cons-
trução do sistema porque tende a reduzir o tempo de desenvolvimento e de validação, 
entregando o sistema de software de forma mais rápida. (SOMMERVILLE, 2011)
A engenharia de software baseada em reúso é uma abordagem de desenvolvimento 
de sistemas de software que visa maximizar o reúso de softwares existentes. O tamanho 
das unidades de software reutilizadas pode variar bastante, por exemplo: 
• Reúso de sistemas de aplicação por inteiro, incorporando-o sem mudanças a outros 
sistemas ou desenvolvendo famílias de aplicações;
• Reúso de componentes de uma aplicação desde os subsistemas até os obje-
tos elementares;
• Reúso de componentes de software que implementam uma função bem definida ou 
objetos (SOMMERVILLE, 2011).
O reúso pode existir independentemente do modelo de processo de desenvolvimen-
to de sistemas de software. A figura 1 apresenta um modelo geral de desenvolvimento 
baseado em reúso, também conhecido como engenharia de software orientada a reú-
so. Apesar de as fases de especificação de requisitos e de validação do sistema serem 
compatíveis com outros modelos de processo de software, as fases intermediárias em 
um modelo orientado a reúso são:
a) Análise de componentes: a partir da especificação de requisitos, é realizada 
uma busca de componentes para implementar essa especificação. Muitas ve-
zes, não há uma correspondência exata, sendo que os componentes podem ser 
usados somente para fornecer alguma funcionalidade necessária;
b) Alterações nos requisitos: os requisitos são analisados com base nas informa-
ções dos componentes encontrados. Em seguida, os requisitos são modificados 
para ser possível reutilizar os componentes disponíveis. Havendo mudanças 
inviáveis nos requisitos, a fase de análise de componentes pode ser realizada 
novamente visando buscarsoluções alternativas;
c) Projeto de sistema com reúso: o framework do sistema é projetado ou algo que 
já existe é reutilizado. Os arquitetos analisam os componentes que serão reusa-
dos e organizam o framework para reúso. O desenvolvimento de algum software 
novo pode ser necessário se não houver componente de software disponível;
d) Desenvolvimento e integração: softwares que não podem ser adquiridos ex-
ternamente são desenvolvidos, sendo que os componentes são integrados para 
construir o novo sistema. A integração de sistemas pode ser parte do processo 
8
9
de desenvolvimento de software, ao invés de uma atividade separada. De for-
ma geral, há três tipos de componentes de software passíveis de utilização em 
um modelo de processo orientado a reúso:
 » Web services: desenvolvidos conforme os padrões de serviço, estando dis-
poníveis para invocação remota;
 » Coleções de objetos: desenvolvidas como um pacote a ser integrado com 
um framework de componentes (.NET, JEE, ...);
 » Sistemas de software stand alone: configurados para uso em um ambiente 
específico (SOMMERVILLE, 2011).
Projeto de sistema 
com reúso
Alterações nos 
requisitos
Análise de 
componentes
Especi�cações 
de requisitos
Desenvolvimento 
e integração
Validação de 
sistema
Figura 1 – Engenharia de software orientada a reúso
Apenas para exemplificar uma forma simples de reutilização de software, a figura 2 
mostra as diferentes formas de implementação de um componente em diversas situações 
de software, sendo que, em cada uma delas, a classe cliente está sendo implementada 
de forma diferente, adaptando-se a cada projeto e situação. Uma forma implementa a 
relação de generalização (herança), outra implementa a relação de agregação, enquanto 
a terceira implementa a relação de dependência não estrutural.
Figura 2 – Implementação de um componente em diversas situações
Apesar de o reúso de software geralmente ser lembrado apenas no reúso de compo-
nentes, existem várias abordagens de reúso distintas que podem ser usadas. Um ponto 
interessante é que o reúso é possível em vários níveis, desde funções mais simples até 
mesmo a reutilização de aplicações de software completas. A figura 3 mostra um pa-
norama do reúso de software apresentando diversas abordagens que apoiam o reúso. 
9
UNIDADE 
Padrões de Projeto e Model-View-Controller (MVC)
Observe nesta figura que padrões de projeto, padrões de arquitetura e engenharia de 
software baseados em componentes são formas de reutilização de software.
Padrões de 
projeto
Padrões de 
arquitetura
Aplicações verticais 
con
guráveis
Empacotamento de 
sistemas legados
Engenharia de software 
baseada em componentes
Engenharia 
dirigida a modelos
Sistemas orientados 
a serviços
Desenvolvimento do software 
orientado a aspectos
Geradores de 
programas
Bibliotecas de 
programas
Frameworks 
de aplicações
Linhas de produtos 
de software
Integração 
de COTS
Sistemas 
de ERP
Figura 3 – Panorama do reúso de software
E quanto aos padrões de projeto e aos padrões de arquitetura de software que tanto 
nos interessam? É o que vamos estudar nas próximas seções deste material.
Padrões de Projeto
Quando nós estudamos padrões de projeto (design patterns), é muito difícil não elen-
car o importante livro Padrões de projeto: soluções reutilizáveis de software orientado 
a objetos de Gamma et al. (2000), originalmente publicada sob o título Design Patterns: 
Elements of Reusable Object-Oriented Software (1994). Os autores do referido livro são 
conhecidos como Gangue dos Quatro, do inglês Gang of Four, portanto, os padrões de pro-
jeto descritos por esses autores são chamados de padrões GoF (Gang of Four). Autores de 
livros de Engenharia de Software e de Desenvolvimento de Software, incluindo Sommerville 
(2011), Bezerra (2015) e Kerievsky (2008) citam os referidos autores em suas obras.
Por que adotar padrões de projeto é uma tarefa importante no desenvolvimento de 
sistemas de software? Por que o arquiteto de software tem interesse na adoção de pa-
drões em suas soluções?
Todos sabem o valor da experiência de projeto. Muitas vezes, já passou pela sua cabeça 
aquele sentimento de que já solucionou um problema semelhante anteriormente, mes-
mo não sabendo exatamente onde e quando. Se você conseguisse lembrar os detalhes do 
problema anterior e de que forma o resolveu, você poderia reutilizar a experiência ao invés 
de redescobrir a solução adotada, não é verdade? Contudo, houve uma falha considerável, 
pois essa solução não foi registrada para possibilitar uma reutilização futura por parte de 
outros arquitetos em novos projetos de software.
10
11
Projetar sistema de software orientado a objetos é uma tarefa complicada, mas pro-
jetar software reutilizável orientado a objetos é ainda mais complicado, pois é necessário 
identificar objetos pertinentes, refatorar esses objetos em classes no nível certo de gra-
nularidade, definir as interfaces das classes, as hierarquias de generalização e especia-
lização (herança) e as relações existentes entre esses conceitos. O projeto de software 
deve ser específico o suficiente para resolver o problema em questão, porém, genérico 
o suficiente para resolver problemas e atender a requisitos exigidos no futuro. 
Arquitetos de software experientes realizam bons projetos de software, ao passo 
que arquitetos inexperientes são sobrecarregados pelas diversas alternativas disponíveis, 
com tendência de adotar técnicas não orientadas a objetos. Normalmente, um profis-
sional de desenvolvimento de software leva um tempo para compreender o que é um 
bom projeto de software orientado a objetos. Algo que os arquitetos experientes sabem 
é que não se deve resolver cada problema a partir de princípios elementares ou do zero. 
Ao invés disso, eles reutilizam soluções que já funcionaram no passado. Ao encontrar 
uma boa solução, eles a utilizam por repetidas vezes, possibilitando a identificação de 
padrões de classes e de comunicação entre objetos que surgem com frequência na maio-
ria dos sistemas de software orientados a objetos. Esses padrões solucionam problemas 
específicos de projeto (design), tornando o projeto orientado a objetos mais flexível e, 
principalmente, reutilizável, possibilitando aos arquitetos desenvolverem novos projetos, 
reusando projetos bem-sucedidos a partir da experiência anterior. Um arquiteto habitua-
do com tais padrões pode aplicá-los de imediato em diferentes problemas de projeto, 
sem necessidade de descobrir os mesmos novamente. (GAMMA et al., 2000)
Afinal, o que são padrões de projeto (design patterns)? “Padrões de projeto são des-
crições de objetos e classes comunicantes que precisam ser personalizadas para resolver 
um problema geral de projeto num contexto particular”. (GAMMA et al., 2000, p. 20)
Um padrão de projeto é uma forma de reusar conhecimento abstrato sobre um pro-
blema e sua solução, descrevendo o problema e a essência da sua solução. Para tal, um 
padrão de projeto precisa ser abstrato o suficiente para ser reutilizado em configurações 
distintas. Normalmente, os padrões fazem uso de características orientadas a objetos, 
como herança e polimorfismo. (SOMMERVILLE, 2011)
Os padrões de projeto facilitam o reúso de projetos e arquiteturas bem-sucedidas. Técnicas 
testadas, aprovadas e registradas tornam as soluções mais acessíveis aos novos desenvol-
vedores de software. Os padrões de projeto auxiliam a selecionar alternativas de projeto 
que fazem um software ser mais reusável e a evitar alternativas que comprometam o reú-
so, além de melhorar a documentação e a manutenção de sistemas de software ao forne-
cer uma especificação visível de interações de classes e objetos e o seu propósito implícito. 
Resumindo, os padrões de projeto ajudam um arquiteto de software a obter um projeto 
adequado de forma mais rápida. (GAMMA et al., 2000)
Gamma et al. (2000) elaboraram um catálogo de padrões de projeto, classificando 
os mesmos a partir de dois critérios. O primeiro critério corresponde àfinalidade do 
11
UNIDADE 
Padrões de Projeto e Model-View-Controller (MVC)
padrão, ou seja, o que o padrão faz. Os padrões podem ser de finalidade de criação, 
estrutural, ou comportamental. Os padrões de criação enfatizam o processo de criação 
dos objetos; os padrões estruturais trabalham com montagem da estrutura das classes, 
ou objetos; os padrões comportamentais descrevem as formas pelas quais as classes ou 
objetos interagem e distribuem responsabilidades. O segundo critério corresponde ao 
escopo do padrão, ou seja, especifica se o padrão é aplicável principalmente no escopo 
de classes ou de objetos. Os padrões para classes visam aos relacionamentos entre clas-
ses e suas subclasses, definidos por meio de herança, sendo, portanto, estáticos, pois 
trabalham em tempo de compilação, enquanto os padrões para objetos se preocupam 
com relacionamentos entre objetos que podem mudar em tempo de execução, sendo, 
portanto, mais dinâmicos. 
A tabela 1 mostra o catálogo dos padrões de projeto da Gang of Four (GoF), organi-
zado conforme os dois critérios explicados anteriormente. Ao todo, são 23 padrões de 
projeto, sendo 5 de criação, 7 estruturais e 11 comportamentais.
Tabela 1 – Padrões de Projeto GoF
Finalidade
De criação Estrutural Comportamental
Escopo
Classe Factory Method Adapter InterpreterTemplate Method
Objeto
Abstract Factory
Builder
Prototype
Singleton
Bridge
Composite
Decorator
Façade
Flyweight
Proxy
Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
Fonte: Adaptado de Gamma et al. (2000, p. 26)
Os padrões de projeto de criação para classes deixam alguma parte da criação de 
objetos para subclasses, enquanto os padrões de criação para objetos deixam a constru-
ção para outro objeto. Os padrões estruturais para classes usam a herança para com-
por classes, já os padrões estruturais de objetos descrevem formas de compor objetos. 
Os padrões comportamentais para classe utilizam herança para especificar algoritmos 
e fluxo de controle, enquanto os padrões comportamentais para objetos definem como 
um grupo de objetos colabora para executar uma tarefa que um objeto não pode execu-
tar isoladamente. (GAMMA et al., 2000)
Uma alternativa de organizar os padrões de projeto GoF é de acordo com as relações 
existentes entre eles. A figura 4 mostra essa forma de organização. Apesar de não ser uma 
figura complexa, a visão dos relacionamentos entre padrões de projeto é interessante.
12
13
ProxyMemento
Adapter
Builder
BridgeIterator
Command
Observer
Chain of Responsibility
Composite
Mediator
Flyweight Visitor
Decorator
Strategy
State
evitando 
histerese
salvando o estado 
da iteração
criando 
compostos
enumerando 
�lhos
acrescendo 
responsabilidade a 
objetos
usando 
composto
de�nindo 
percursos
de�nindo 
a cadeia
adicionando 
operações
de�nindo a 
gramática
compartilhando 
símbolos terminais
compartilhando 
compostos
administração 
de dependências 
complexas
Interpreter
Factory MethodPrototype
Singleton
Facade
adicionando 
operações
mudando o exterior 
versus o interior
compartilhando 
estratégias
compartilhando 
estados
Template Method
usos frequentes
de�nindo os 
passos do 
algorítmo
Abstract Method
implementa usando
instância 
única
instância 
única
con�gurar a fábrica 
dinamicamente
Figura 4 – Relacionamentos entre padrões de projeto
Para maiores detalhes sobre os padrões GoF, você também pode explorar o livro Padrões 
de projeto: soluções reutilizáveis de software orientado a objetos, de Gamma et al. (2000), 
disponibilizado na Biblioteca Virtual Pearson, disponível em: https://goo.gl/g72tci
13
UNIDADE 
Padrões de Projeto e Model-View-Controller (MVC)
Model-View-Controller (MVC)
O Model-View-Controller (MVC) é um padrão de arquitetura de software que especi-
fica a interação entre objetos de interface com o usuário e os demais objetos de uma apli-
cação. Esse padrão arquitetural é comumente utilizado para separar as responsabilidades 
entre a lógica da apresentação e a lógica da aplicação. O ideal da camada de apresentação 
é não possuir inteligência, mas apenas a implementação da lógica da apresentação, como 
preenchimento de controles com dados oriundos das camadas da aplicação, habilitação de 
controles, definição de cores etc. Inicialmente, esse padrão de arquitetura foi apresentado 
na linguagem de programação Smalltalk-80, sendo que, ao longo do tempo, surgiram 
variações dessa arquitetura. Esse padrão de arquitetura apresenta três componentes:
• Model: esse componente representa a parte da aplicação que contém os dados e 
suas validações. Esse componente corresponde ao estado, à estrutura e ao compor-
tamento dos dados, sendo visualizados e manipulados pelo usuário do sistema por 
meio de interface gráfica. O objeto-modelo apresenta operações em sua interface 
para que o restante do sistema possa manipular seus dados;
• View: um sistema de software pode apresentar aos usuários diversas visões de um 
mesmo objeto-modelo. Um exemplo é haver uma interface gráfica para editar as 
notas de um estudante de uma turma e outra interface gráfica para visualizar essas 
notas. Esse componente representa cada uma das possíveis formas de mostrar uma 
informação vinda do objeto-modelo;
• Controller: cada objeto-visão tem a ele associado um objeto controlador, que ajuda 
na implementação de sua interface gráfica (BEZERRA, 2015).
Fique atento(a) com o conceito de interface! Quando o termo é utilizado para objeto-visão, 
o conceito se refere à interface gráfica (de usuário), porém, quando o conceito é utilizado 
para objeto-modelo, o termo é utilizado para interface de objeto.
Vale ressaltar que o MVC não é um padrão GoF. Na verdade, o MVC é um padrão 
de arquitetura de software desenvolvido para a linguagem de programação orientada a 
objetos chamada Smalltalk, podendo ser usado para qualquer sistema de software inte-
rativo. Muitos frameworks de desenvolvimento adotaram o referido padrão arquitetural, 
principalmente os frameworks de desenvolvimento de aplicações Web.
Para maiores informações sobre a linguagem de programação Smalltalk, você também 
pode explorar a partir do link https://goo.gl/7TTRxa
Uma arquitetura de software recomendada para aplicações Web é a arquitetura em 
três camadas porque separa a interface da navegação e o comportamento da aplicação. 
Essa separação simplifica a implementação e aumenta a reutilização. O padrão MVC 
permite a separação da interface de usuário da funcionalidade e do conteúdo informa-
cional de uma aplicação Web. (PRESSMAN e MAXIM, 2016)
A figura 5 apresenta a arquitetura do padrão MVC, mostrando seus três compo-
nentes: View (Visão), Controller (Controlador) e Model (Modelo). As solicitações são 
14
15
manipuladas pelo controlador que também seleciona o objeto-visão aplicável, conforme 
a solicitação do usuário. Uma vez identificado o tipo de solicitação, uma solicitação de 
comportamento é enviada ao objeto-modelo que implementa a funcionalidade ou recu-
pera o conteúdo necessário para atender à solicitação. O objeto-modelo acessa os dados 
armazenados em um banco de dados. Os dados gerados pelo objeto-modelo devem ser 
formatados e organizados pelo objeto-visão apropriado e enviados do servidor de aplica-
ções de volta para o navegador para exibição no computador do usuário.
Um dos conjuntos mais completos da Web em termos de padrões e linguagens de padrões 
pode ser encontrado em: https://goo.gl/W4Nf4o
Controlador
Gerencia solicitções do usuário
Seleciona compostamento do modelo
Seleciona resposta da visão
Visão
Prepara dados do modelo
Solicita atualizações do modelo
Apresenta a visão selecionada 
pelo controlador
Modelo
Encapsula funcionalidade
Encapsula objetos de conteúdo
Incorpora todos os estados da WebApp
Navegador
Seleção da visão
Solicitação de atualização Dados externos
Servidor
Dados do 
modelo
Solicitação de 
comportamento 
(mudança de estado)
Requisição 
ou dados 
do usuário
Cliente
Dados HTNL
Figura 5– A arquitetura do MVC
O padrão de projeto de arquitetura MVC reúne padrões de projeto GoF como o 
padrão estrutural Composite e o padrão comportamental Observer. A figura 6 ilustra 
as comunicações existentes entre os três componentes do MVC, utilizando o padrão 
Composite entre os componentes Visão e Controlador e o padrão Observer entre os 
componentes Controlador e Modelo.
O usuáro fez 
alguma coisa
Mude o seu 
estado
Mude os dados 
exibidos Já mudei
Composite Observer
Controlador
class Player
Play ( )
Rip ( )
burn ( )
OK
Figura 6 – Relação entre o MVC e outros padrões de projeto
Outras informações sobre a utilização do padrão arquitetural MVC podem ser encontradas 
em: https://goo.gl/QO4O5P
15
UNIDADE 
Padrões de Projeto e Model-View-Controller (MVC)
Representação do MVC em um Diagrama de Classes
Antes de representar o MVC em um diagrama de classes, nós vamos falar sobre o 
conceito de dependência, já que o referido conceito é modelado em um diagrama de 
classes de projeto. Assim, aproveitamos para explicar um pouco mais do refinamento do 
diagrama de classes de análise para o diagrama de classes de projeto.
O relacionamento de dependência indica que uma classe depende dos serviços 
(operações) fornecidos por outra classe. Na visão de análise, é utilizada apenas a 
dependência estrutural (também chamada de dependência por atributo), na qual a classe 
dependente possui um atributo que é uma referência para a outra classe. A implementação 
padrão de um relacionamento de associação é por dependência estrutural. 
De qualquer forma, há também as dependências não estruturais:
• Dependência por variável global: um objeto de escopo global é referenciado em 
algum método da classe dependente;
• Dependência por variável local: um objeto recebe outro como retorno de um método, 
ou possui uma referência para o outro objeto como uma variável local em algum método;
• Dependência por parâmetro: um objeto recebe outro como parâmetro em um 
método (BEZERRA, 2015).
As dependências não estruturais também são representadas na UML, relacionan-
do as classes envolvidas. O sentido é da classe dependente (cliente) para a classe da 
qual ela depende (fornecedora). São utilizados três tipos de estereótipos predefinidos: 
<<global>>, << local>>, << parameter>>. Cada estereótipo representa um tipo de 
dependência não estrutural. A figura 7 exibe um exemplo de utilização de dependência 
não estrutural por parâmetro. Observe que o objeto da classe A depende dos objetos das 
classes B e C, recebendo estes como parâmetros nas operações (métodos).
Para maiores detalhes sobre dependências, você também pode explorar o livro Utilizan-
do UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao desen-
volvimento iterativo, de Larman (2007), disponibilizado na Biblioteca Virtual Pearson, 
disponível em: https://goo.gl/g72tci
Classe A
+oper 1 (in param: Classe C)
+oper 2 (in param 1: Classe B, in param 2: Classe C)
Classe B
Classe C
<<parameter>>
<<parameter>>
Figura 7 – Exemplo de uso de dependência não estrutural
Em qual relacionamento entre classes você deve utilizar dependência estrutural? E a de-
pendência não estrutural?
16
17
Bezerra (2005) entende que, ao longo do projeto de classes, é preciso avaliar, para 
cada relação de associação existente, se é possível transformá-la em uma dependência 
não estrutural. A dependência não estrutural aumenta o encapsulamento de cada classe 
e diminui o acoplamento entre elas, em contrapartida, o desempenho tende a ser menor. 
A dependência por atributo é uma forma mais forte de dependência, diminuindo o encap-
sulamento e aumentando o acoplamento, porém, o desempenho tende a ser maior.
Analisando as vantagens e desvantagens de cada tipo de dependência, é recomendável 
utilizar dependências estruturais entre as classes de modelo. Por outro lado, é recomendá-
vel utilizar dependências não estruturais entre as classes de controle e as classes de modelo.
Vamos, agora, exemplificar uma possibilidade de representação do padrão de ar-
quitetura MVC em um diagrama de classes da UML. Para tal, vamos trabalhar com o 
diagrama de classes de projeto apresentado na Unidade 1 desta disciplina. Para você se 
lembrar do diagrama o qual estamos mencionando, o mesmo é mostrado na figura 8.
Cliente
- CPF: String
- Nome: String
- Telefone: String
- E-mail: String
+ getCPF( ): boolean
1 *
Locação
- DataRetirada: Date
- HoraRetirada: Time
- DataDevolução: Date
- HoraDevolução: Time
- ValorLocação: Currency
+ getValorLocação( ): Currency
Carro
- Modelo: String
- Chassi: String
- Cor: String
- Km: int
- ValorDiária: Currency
+ getValorDiária( ): Currency
* 1
Figura 8 – Diagrama de Classes de Análise
As três classes existentes no diagrama de classes de projeto são classificadas como 
classes de modelo, pois correspondem à parte da aplicação que contém os objetos do 
domínio de negócio. Nesse caso, estão faltando as classes de visão para permitir ao 
usuário do sistema visualizar e manipular os dados e as classes controladoras que auxi-
liam na implementação das classes de visão.
As classes podem ser definidas por meio de estereótipos ou notações MVC. Para 
você associar melhor, a tabela 2 mostrevista uma correspondência entre os estereótipos 
e as notações.
Tabela 2 – Correspondência entre estereótipos e notações MVC
Estereótipo Notação MVC
<<view>>
View
Controller
Model
<<controller>>
<<model>>
Fonte: Adaptado de Bezerra, 2015
A figura 10 apresenta uma representação do MVC em um diagrama de classes 
de projeto. As classes de modelo foram alocadas em dois pacotes Model. As classes 
17
UNIDADE 
Padrões de Projeto e Model-View-Controller (MVC)
controladoras foram alocadas no pacote Controller, enquanto as classes de visão foram 
agrupadas no pacote View. Observe, na figura, que as classes de modelo estão relacio-
nadas por meio de dependência estrutural. Por outro lado, os pacotes estão relaciona-
dos por meio de dependência não estrutural. Como tivemos o interesse de mostrar as 
propriedades das classes, definimos as classes de modelo com a notação convencional 
de classe, utilizando o estereótipo <<model>>. Já as classes de controle e de visão foram 
definidas com as notações típicas do MVC.
Tela Locação
Controle LocaçãoControle Cliente
Tela Cliente
<<model>>
Locação
- DataRetirada: Date
- HoraRetirada: Time
- DataDevolução: Date
- HoraDevolução: Time
- ValorLocação: Currency
+ getValorLocação( ): Currency
<<model>>
Carro
- Modelo: String
- Chassi: String
- Cor: String
- Km: int
- ValorDiária: Currency
+ getValorDiária( ): Currency
* 1
Locação model
<<model>>
Locação
- DataRetirada: Date
- HoraRetirada: Time
- DataDevolução: Date
- HoraDevolução: Time
- ValorLocação: Currency
+ getValorLocação( ): Currency
Cliente model
View
Controller
Figura 9 – Representação do MVC em um diagrama de classes
O diagrama de classes de projeto apresentado na figura 9 é relativamente simples 
por conta do número de classes utilizadas no exemplo. Mesmo assim, é possível verifi-
car uma forma do padrão MVC ser representada em um diagrama de classes. Não se 
preocupe com o conceito de pacote, pois o mesmo será abordado na próxima unidade 
desta disciplina.
Para maiores detalhes sobre a UML, você também pode explorar o livro UML Essencial: um 
breve guia para a linguagem-padrão de modelagem de objetos de Fowler (2005), disponi-
bilizado na Biblioteca Virtual Pearson, em: https://goo.gl/g72tci
18
19
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Sites
The Hillside Group
https://goo.gl/W4Nf4o
Bibliotecas do Grupo Cruzeiro do Sul
https://goo.gl/g72tci
 Leitura
MVC
https://goo.gl/QO4O5P
Smalltalk
https://pt.wikipedia.org/wiki/Smalltalk
19
UNIDADE 
Padrões de Projeto e Model-View-Controller (MVC)
Referências
BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. 3.ed. São 
Paulo: Elsevier, 2015.
BRAUDE, E. Projeto de software – da programação à arquitetura:uma abordagem 
baseada em Java. São Paulo: Bookman, 2005.
FOWLER. M. UML Essencial: um breve guia para a linguagem-padrão de modelagem 
de objetos. 3.ed. Porto Alegre: Bookman, 2005.
FREEMAN, E.; FREEMAN, E. Use a cabeça! Padrões de projetos. 2.ed. São Paulo: 
Alta Books, 2007.
GAMMA, E.; HELM, R.; RALPH, J.; VLISSIDES, J. Padrões de projeto: soluções 
reutilizáveis de software orientado a objetos. Porto Alegre: Bookman, 2000.
KERIEVSKY, J. Refatoração para padrões. Porto Alegre: Bookman, 2008.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto 
orientados a objetos e ao desenvolvimento iterativo. 3.ed. Porto Alegre: Bookman 2007.
PRESSMAN, R. S.; MAXIM. B. R. Engenharia de software. 8.ed. Porto Alegre: 
AMGH, 2016
SOMMERVILLE, I. Engenharia de software. 9.ed. São Paulo: Pearson, 2011.
20