Arquitetura

Inserir TítulodeAqui
Software
Inserir Título Aqui
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
 Padrões de Projeto e
Model-View-Controller (MVC)

Nesta unidade, trabalharemos os seguintes tópicos:

• Padrões de Projeto e Model-View-Controller (MVC);
• Model-View-Controller (MVC).

Fonte: iStock/Getty Images

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!
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
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
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 buscar soluçõ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
 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).

Especificações Análise de Alterações nos Projeto de sistema

de requisitos componentes requisitos com reúso

Desenvolvimento Validação de
e integração 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
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 Padrões de
projeto arquitetura

Frameworks Linhas de produtos Integração Sistemas

de aplicações de software de COTS de ERP

Aplicações verticais Empacotamento de

configuráveis sistemas legados

Engenharia de software Engenharia Sistemas orientados

baseada em componentes dirigida a modelos a serviços

Desenvolvimento do software Geradores de Bibliotecas de

orientado a aspectos programas programas

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
 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
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
Factory Method Adapter Interpreter
Classe Template Method
Abstract Factory Bridge Chain of Responsibility
Builder Composite Command
Prototype Decorator Iterator
Escopo Singleton Façade Mediator
Objeto Flyweight Memento
Proxy 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
 salvando o estado
Builder da iteração Memento Proxy

Adapter

criando Iterator Bridge

evitando
compostos
histerese

acrescendo enumerando
responsabilidade a usando
filhos
objetos composto Command

Decorator Composite
compartilhando definindo
compostos definindo a cadeia
adicionando percursos
operações
mudando o exterior
versus o interior
Flyweight definindo a Visitor
gramática

compartilhando adicionando
estratégias Interpreter operações Chain of Responsibility

compartilhando
símbolos terminais Mediator administração
Strategy de dependências
compartilhando complexas Observer
estados
State
definindo os
passos do usos frequentes
algorítmo Template Method

Prototype configurar a fábrica Factory Method

dinamicamente
implementa usando
instância Abstract Method
única
Facade
Singleton instância
única

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
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
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 Solicitação de
Seleciona resposta da visão comportamento
(mudança de estado)
Seleção da visão
Requisição
Modelo
Navegador ou dados
Encapsula funcionalidade
do usuário
Encapsula objetos de conteúdo
Dados do
Incorpora todos os estados da WebApp
Cliente modelo
Visão Solicitação de atualização Dados externos
Dados HTNL
Prepara dados do modelo
Solicita atualizações do modelo
Apresenta a visão selecionada
pelo controlador
Servidor

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 Mude o seu

alguma coisa estado
Controlador
Composite Observer

Mude os dados class Player

exibidos Já mudei
Play ( )
OK Rip ( )
burn ( )

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
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 <<parameter>>
+oper 1 (in param: Classe C) Classe C
+oper 2 (in param 1: Classe B, in param 2: Classe C)

<<parameter>>

Classe B
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
 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 Locação Carro

- CPF: String - DataRetirada: Date - Modelo: String
- Nome: String 1 * - HoraRetirada: Time * 1 - Chassi: String
- Telefone: String - DataDevolução: Date - Cor: String
- E-mail: String - HoraDevolução: Time - Km: int
+ getCPF( ): boolean - ValorLocação: Currency - ValorDiária: Currency
+ getValorLocação( ): Currency + getValorDiária( ): Currency

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>>
Controller

<<model>>
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
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.

Locação model
<<model>> <<model>>
Locação Carro
- DataRetirada: Date - Modelo: String
View - HoraRetirada: Time * 1 - Chassi: String
- DataDevolução: Date - Cor: String
- HoraDevolução: Time - Km: int
- ValorLocação: Currency - ValorDiária: Currency
Tela Cliente Tela Locação + getValorLocação( ): Currency + getValorDiária( ): Currency

Cliente model
<<model>>

Controller Locação
- DataRetirada: Date
- HoraRetirada: Time
- DataDevolução: Date
Controle Cliente Controle Locação - HoraDevolução: Time
- ValorLocação: Currency
+ getValorLocação( ): Currency

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
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
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