ARQUITETURAS E PADRÕES DE SOFTWARE VI

Prévia do material em texto

Arquiteturas e 
Padrões de Software
Responsável pelo Conteúdo:
Prof. Me. Wilson Vendramel
Revisão Textual:
Prof.ª M.ª Sandra Regina Fonseca Moreira
Requisitos, Design e Documentação de 
Arquitetura de Software – Estudo de Caso
Requisitos, Design e Documentação 
de Arquitetura de Software – 
Estudo de Caso
 
• Apresentar um estudo de caso contemplando a especificação dos requisitos arquiteturais, a 
análise e design arquitetural e a documentação de uma arquitetura de software.
OBJETIVOS DE APRENDIZADO 
• Requisitos Arquiteturais;
• Análise e Design Arquitetural;
• Modelagem e Documentação Arquitetural;
• Implementação da Arquitetura.
UNIDADE Requisitos, Design e Documentação de 
Arquitetura de Software – Estudo de Caso
Requisitos Arquiteturais
A fim de recordar brevemente a ênfase de cada uma das unidades anteriores, a des-
tacamos a relevância da arquitetura para o desenvolvimento de sistemas de software de 
qualidade e apresentou o Processo Unificado, ressaltamos a análise e projeto orientado 
a objetos e a relação de visões do modelo 4+1 com diagramas UML para documentar 
arquiteturas de software, demos também enfoque ao reuso de software e padrões de 
projeto GoF, a completamos determinados estilos e padrões arquiteturais, contextuali-
zamos o projeto de arquitetura de software, descrevendo conceitos a fim de estabelecer 
relações entre os principais elementos estruturais do software, padrões arquiteturais e 
padrões de projeto, que de forma conjunta, possam cumprir os requisitos exigidos para 
o produto de software e as restrições que afetam a maneira como sua arquitetura será 
implementada, além de trazer representações da arquitetura lógica e física com o suporte 
visual das notações UML.
Esta unidade, por sua vez, tem o propósito de aplicar conceitos abordados à prática, 
contextualizando um estudo de caso. Para tal, são previstas atividades que visem o de-
senvolvimento do software a partir de uma arquitetura reproduzida com base no modelo 
de requisitos, inclusive atributos de qualidade, desse modo, ajudando a representar tangi-
velmente o modelo de projeto, além de incluir a aplicação de conceitos de design e o uso 
de padrões de software durante o processo de desenvolvimento. Diante desse cenário, 
são previstas quatro atividades enfatizando a arquitetura do software:
• Definição dos requisitos arquiteturais;
• Análise e Design arquitetural;
• Modelagem e Documentação arquitetural;
• Implementação da arquitetura.
Além das atividades mencionadas, é importante frisar que esta unidade vai seguir a 
abordagem de projeto baseado em padrões, contemplada na Unidade anterior.
Importante!
O público está mais acostumado com projetos ruins do que com projetos bons. Ele está, 
de fato, condicionado a preferir projetos ruins, pois é com isso que convive. O novo re-
presenta uma ameaça, o antigo um sentimento de tranquilidade (PRESSMAN; MAXIM, 
2016, p. 245).
Por que é importante especificar, analisar, projetar e documentar a arquitetura no decorrer 
do desenvolvimento de sistemas de software?
Nos dias atuais, o software caminha em direção a sistemas cada vez maiores e mais 
complexos. Uma das causas que influenciam essa tendência é o fato de que os compu-
tadores estão se tornando mais potentes a cada ano, elevando assim a expectativa da 
8
9
comunidade usuária em relação a eles. Outro fator que influencia esse caminho é o uso 
crescente da Internet para troca de todos os tipos de informação. Diante desse cenário, 
o desejo por um software cada vez mais sofisticado aumenta conforme tomamos co-
nhecimento de como um produto de software pode ser aprimorado em suas sucessivas 
versões. A busca por software crescentemente adaptado às necessidades dos usuários 
implica em um software progressivamente mais complexo. Resumindo, a comunidade 
usuária deseja cada vez mais do software (PRESSMAN; MAXIM, 2016).
Assim, qual a relação do desejo de um produto de software sofisticado com sua 
arquitetura?
As arquiteturas de software são extraídas dos requisitos das organizações e seus 
modelos de negócio, da experiência dos arquitetos da organização, bem como das pró-
prias técnicas de projeto (design) predominantes naquele ambiente. Técnicas que visem 
o projeto, construção e avaliação de arquiteturas são importantes para compreender 
os atributos de qualidade no contexto de uma arquitetura, como também para cons-
truir arquiteturas que satisfaçam a esses atributos de qualidade (BASS; CLEMENTS; 
KAZMAN, 2003).
Vale recordar que o enfoque do processo de projeto (design) é a obtenção de uma 
arquitetura de software que permita representar a estrutura completa do software, iden-
tificando componentes arquiteturais e suas interdependências. Essa arquitetura é retrata-
da a partir das informações do domínio de negócio e dos estilos e padrões arquiteturais.
Eis aqui uma indagação: há diferença entre os termos arquitetura e projeto (design)?
Há uma diferença marcante entre os termos arquitetura e projeto. Projeto 
é uma instância de uma arquitetura, da mesma forma que um objeto é 
uma instância de uma classe. Considere, por exemplo, a arquitetura clien-
te/servidor. Podemos projetar um sistema de software centralizado em 
redes de várias formas diferentes por meio dessa arquitetura, usando a 
plataforma Java (Java EE) ou a plataforma Microsoft (.NET framework). 
Existe uma arquitetura, porém vários projetos podem ser criados basea-
dos nela. Consequentemente, não podemos confundir “arquitetura” com 
“projeto”. (PRESSMAN; MAXIM, 2016, p. 254)
Embora um projeto de software seja uma instância de um estilo de arquitetura espe-
cífico, cabe frisar que os elementos e estruturas definidos como parte de uma arquite-
tura são a raiz de todo o projeto. Enfim, um projeto começa com uma consideração de 
arquitetura (PRESSMAN e MAXIM, 2016).
Links para diversos sites sobre arquitetura de software, disponível em: https://bit.ly/2LCS3Tf
Referente ao estudo de caso abordado nesta unidade, o Quadro 1 descreve um resumo 
do produto de software a ser construído. Trata-se um sistema baseado na Web para 
gerenciar vendas on-line (E-commerce).
9
UNIDADE Requisitos, Design e Documentação de 
Arquitetura de Software – Estudo de Caso
Quadro 1 – Descrição do software
Estudo de Caso: 
Aplicação Web de 
E-commerce
Para a primeira release do projeto será necessário construir uma 
aplicação Web de comércio eletrônico para realização de vendas 
on-line, devendo ser possível cadastrar o cliente, visualizar um 
catálogo de produtos, adicionar ou remover itens do carrinho de 
compra, além de finalizar o pedido. Deve ser possível realizar o 
cálculo de frete de acordo com o endereço de entrega. Além disso, 
é possível realizar o pagamento em boleto ou cartão de crédito, 
aplicando um desconto de 5% quando o pagamento for realizado 
via boleto. Ademais, os dados dos cartões podem ser armazena-
dos para compras futuras.
Dada a visão geral do estudo de caso, o Quadro 2 elenca os requisitos funcionais 
exigidos para esta aplicação Web e suas respectivas descrições. Ao todo, foram identifi-
cados sete requisitos dessa natureza.
Quadro 2 – Requisitos Funcionais
RF01 O sistema deve manter os dados do cliente.
RF02 O sistema deve exibir o catálogo de produtos à venda.
RF03 O sistema deve permitir adicionar e remover produtos do carrinho de compra.
RF04 O sistema deve propiciar o controle da finalização do pedido.
RF05 O sistema deve realizar o cálculo de frete de acordo com o ende-reço de entrega.
RF06
O sistema deve possibilitar o pagamento por meio de boleto ou 
cartão de crédito. No caso do pagamento ser via boleto, há um 
desconto de 5% no valor do pedido.
RF07 O sistema deve permitir o armazenamento dos dados do cartão de crédito.
Além dos requisitos funcionais, precisamos identificar os atributos de qualidade (re-
quisitos não funcionais) relacionados a essas funcionalidades. A Tabela 1 apresenta os 
atributos de qualidade identificados para cada requisito funcional. Esses atributosde qua-
lidade foram extraídos da classificação de Bass, Clements e Kazman (2003), abordada 
em Unidade anterior. Esses atributos ditam o desempenho do sistema, disponibilidade, 
segurança, compatibilidade com outros sistemas e a capacidade de acomodar modifica-
ções durante a vida útil do software. O desejo de implementar esses requisitos na cons-
trução do software influenciam as decisões de projeto (design) a serem tomadas pelo 
arquiteto de software. Vale salientar que o atributo de qualidade de Interoperabilidade 
(Interoperability) passou a fazer parte da classificação desses autores de forma explí-
cita posteriormente. Esse atributo corresponde à integração da aplicação de software 
com outros sistemas, algo bastante comum em sistemas de software baseados na Web 
(BASS; CLEMENTS; KAZMAN, 2003).
10
11
Tabela 1 – Atributos de Qualidade
Requisito 
Funcional
Atributos de 
Qualidade Descrição
RF01 Modificabilidade Devido à possibilidade de alteração dos dados do cliente mediante evolução do sis-tema, a modificabilidade é importante para que essa alteração ocorra facilmente.
RF02 DesempenhoDisponibilidade
O catálogo de produtos é extremamente importante, logo é necessário que sem-
pre tenha um ótimo desempenho e alta disponibilidade para o cliente encontrar o 
produto que deseja.
RF03 Usabilidade A usabilidade é importante para adicionar ou remover produtos do carrinho, para que o cliente tenha uma melhor experiência de uso. 
RF04 SegurançaDisponibilidade
Finalizar pedido significa concretizar uma venda, desse modo, é crucial que esta 
operação tenha uma alta disponibilidade e segurança.
RF05 TestabilidadeModificabilidade
O cálculo de frete deve ser testável de maneira a validar se o cálculo está correto 
e, considerando que esse cálculo pode ser alterado futuramente, é importante a 
modificabilidade para as regras atreladas.
RF06
Testabilidade
Modificabilidade
Interoperabilidade
O pagamento ocorrerá por meio de um serviço externo (gateway de pagamento), 
logo, é importante que seja testável e interoperável. Além disso, o cálculo de des-
conto poderá ser alterado no futuro, com isso a modificabilidade é importante.
RF07 Segurança Garantir a segurança de informações sensíveis de cartões que serão armazenados.
A junção entre os requisitos funcionais e os atributos de qualidade de forma significativa 
para a arquitetura podem resultar em requisitos arquiteturais. Por exemplo, o pagamento 
de um pedido por meio de boleto ou cartão de crédito pode ser relativamente complexo 
para ser implementado, desse modo, pode ser considerado um requisito arquitetural.
A Figura 1 apresenta o Diagrama de Casos de Uso (DCU) da aplicação Web, exibindo 
os atores e os casos de uso identificados para o primeiro release do sistema.
Administrador
E-commerce
Gateway do Pagamento
UC01 – Manter Cliente
UC02 – Recuperar
Catálogo
UC03 – Adicionar ou
Remover Produto
no Carrinho
UC04 – Finalizar Pedido
UC06 – Realizar
Pagamento
UC05 – Calcular Frete
UC07 – Salvar
Informações do Cartão
Cliente
<<extends>>
<<extends>>
<<include>>
<<include>>
Figura 1 – DCU da Aplicação
Uma abordagem visando identificar requisitos arquiteturais pode ser encontrada no artigo 
de Peter Eeles, disponível em: https://ibm.co/3jFMP5J
11
UNIDADE Requisitos, Design e Documentação de 
Arquitetura de Software – Estudo de Caso
Análise e Design Arquitetural
Como já mencionado, uma das decisões arquiteturais que devemos fazer é quanto à 
estrutura do sistema do software, ou seja, como os elementos arquiteturais (subsistemas, 
componentes, interfaces, persistência, conectores, dispositivos físicos) estarão organizados 
para implementar os requisitos exigidos para o produto de software e as restrições que 
interferem na maneira como essa arquitetura será implementada utilizando uma plata-
forma de desenvolvimento, que para esta unidade, será a plataforma Java.
Os requisitos arquiteturais analisados para este estudo de caso denotam a possibi-
lidade de desenvolver uma aplicação Web de E-commerce a partir de uma arquitetura 
de software baseada nos estilos arquiteturais cliente-servidor, em camadas e no padrão 
arquitetural MVC. Por conta da adoção de forma conjunta de estilos e padrões distintos, 
a arquitetura para esta aplicação se caracteriza como uma arquitetura de software he-
terogênea. Vale recordar que esses estilos e padrões arquiteturais foram abordados em 
Unidade anterior.
A abordagem de projeto baseado em padrões, vista anteriormente, permite identifi-
car e reusar padrões de software existentes e aplicá-los de forma personalizada na cons-
trução do sistema. Além disso, uma tabela pode ser criada para classificar e organizar 
os padrões, desse modo, a Tabela 2, adaptada para esta unidade, apresenta os padrões 
selecionados para este estudo de caso, organizados de acordo com os problemas a se-
rem resolvidos (dados/conteúdo, interface do usuário, componentes e arquitetura) e os 
tipos dos padrões (padrão de projeto GoF, padrão de projeto JEE, padrão arquitetural, 
padrão de protocolo).
Tabela 2 – Tabela de organização dos padrões selecionados
Problema a ser resolvido/ 
Tipo do padrão
Padrão de 
Projeto GoF
Padrão de 
Projeto JEE
Padrão 
Arquitetural
Padrão de 
Protocolo
Dados/Conteúdo – – – –
Construção de objetos Factory Method – – –
Interface do Usuário – – – –
Entregar as views 
aos requisitantes
– Front Controller – –
Fornecer funções 
e dados para a view
– View Helper – –
Componentes – – – –
Controlar a lógica de 
execução dos serviços 
de negócio
Mediator – – –
Comunicação com 
o gateway de pagamento
– – – HTTP
Comunicação com 
banco de dados
– – – ODBC
Arquitetura – – – –
Interface única 
para o subsistema
Façade – – –
12
13
Problema a ser resolvido/ 
Tipo do padrão
Padrão de 
Projeto GoF
Padrão de 
Projeto JEE
Padrão 
Arquitetural
Padrão de 
Protocolo
Estrutura do sistema – –
MVC, Arquitetura 
em camadas,
Cliente-Servidor
–
Estratégias de 
cálculo de desconto
Strategy – – –
Comunicação com o 
gateway de pagamento
Adapter – – –
Persistência dos 
objetos de entidades
– DAO – –
• Você pode consultar um catálogo de padrões de projeto GoF. 
Disponível em: https://bit.ly/2Z2drVh
• Um catálogo de padrões JEE, disponível em: https://bit.ly/3a7e1Y7
• Uma relação de padrões e linguagens de padrões, disponível em: https://bit.ly/3q5gkAo
Modelagem e Documentação Arquitetural
Assim como foi visto em Unidades anteriores, os diagramas UML permitem a repre-
sentação arquitetural de um sistema de software, desse modo, esses modelos visuais 
ajudam a justificar e validar a arquitetura projetada antes de ser implementada, avaliando 
seus componentes e respectivas interfaces, e aferindo se essa arquitetura está coesa e 
bem planejada.
No que tange à arquitetura lógica, a Figura 2 exibe o diagrama de pacotes represen-
tando as quatro camadas lógicas da aplicação Web abordada neste estudo de caso.
Apresentação
Aplicação
Domínio
Infraestrutura
Figura 2 – Camadas Lógicas da Aplicação
13
UNIDADE Requisitos, Design e Documentação de 
Arquitetura de Software – Estudo de Caso
Ainda sobre a Figura 2, cada camada lógica é representada por um pacote, sendo 
que esse último pode possuir classes e/ou sub-pacotes. Neste caso, esta arquitetura lógica 
tem as seguintes camadas: apresentação, aplicação, domínio e infraestrutura.
Na camada de apresentação, estão alocadas as classes responsáveis pelas interfaces 
gráficas de usuário. A Figura 3 ilustra as classes View alocadas na camada de apresentação.
Apresentação
ClienteView CarrinhoView
ProdutoView PedidoView
Figura 3 – Camada de Apresentação
A camada de aplicação é uma camada intermediária entre a camada de apresentação 
e a lógica de negócio presente na camada seguinte de domínio, portanto, as classes alo-
cadas nesta camada fazem a mediação entre as classes das outras camadas. A Figura 4 
exibe as classes de controle alocadas na camada de aplicação.
Aplicação
ClienteController CarrinhoController
ProdutoControllerPedidoController
UsuarioAutenticacao
UsuarioAutorizacao
Figura 4 – Camada de Aplicação
Ainda com base na Figura 4, vale destacar que é na camada de aplicação onde se 
encontram as classes responsáveis por realizar a autenticação (verificar se o usuário está 
cadastrado no sistema) e a autorização (se o usuário tem permissão para realizar uma 
determinada operação).
Na camada de domínio, estão concentradas as classes de negócio, onde as regras de 
negócio, identificadas nos casos de uso, existem e são executadas. A Figura 5 ilustra a 
camada de domínio dividida em dois subsistemas representados como pacotes, assim 
sendo: Serviços de Negócio e Model.
14
15
Domínio
Serviços de Negócio Model
Figura 5 – Camada de Domínio
No caso do pacote Model, estão agrupadas as classes responsáveis pelos objetos de en-
tidade do sistema, ou seja, classes Produto, Cliente e demais, conforme exibe a Figura 6.
Model
Cliente Carrinho
Produto Pedido
Cartao
Figura 6 – Pacote Model
Já o pacote de Serviços de Negócio contém as classes responsáveis pela lógica de 
execução dos casos de uso e as regras de negócio atreladas a esses, conforme ilustra a 
Figura 7. A classe ServiceFacade foi utilizada para estabelecer uma interface única para 
esse subsistema, aplicando dessa forma o padrão de projeto Façade.
Serviços de Negócio
ClienteService
+ cadastro(cliente: Cliente): Cliente
+ recuperar(cliente: Cliente): Cliente
+ salvar(cartao: Cartao): Cartao
+ recuperar(cartao: Cartao): Cartao
+ salvar(produto: Produto): Produto
+ recuperarCatalog(): List<Produto>
+ �nalizar(pedido: Pedido): Pedido
+ recuperar(pedido: Pedido): Pedido
+ adicionarProduto(carrinho: Carrinho, produto: Produto): void
+ removerProduto(carrinho: Carrinho, produto: Produto): void
+ recuperarProduto(carrinho: Carrinho): Carrinho
+ criar(carrinho: Carrinho): Carrinho
CartaoService ServiceFacade
ProdutoServicePedidoServiceCarrinhoService
Figura 7 – Pacote de Serviços de Negócio com Padrão Façade
Referente ao caso de uso “Finalizar Pedido” há uma classe denominada PedidoService
designada para executar o serviço de finalização do pedido. Quanto ao desconto pre-
visto para o pagamento do pedido via boleto, um conjunto de estratégias de cálculo foi 
adotado, dessa forma, o padrão de projeto Strategy foi aplicado, conforme mostra a 
Figura 8. Neste caso, esse padrão possibilita a adição de novos meios de pagamento, 
bastando para isso que a classe adicionada implemente a interface DescontoStrategy 
para realizar o cálculo desse novo meio de pagamento.
15
UNIDADE Requisitos, Design e Documentação de 
Arquitetura de Software – Estudo de Caso
PedidoService <<Interface>>
DescontoStrategy
+ calcular(pedido: Pedido): BigDecimal
+ calcular(pedido: Pedido): BigDecimal + calcular(pedido: Pedido): BigDecimal
BoletoDescontoStrategy CartaoDescontoStrategy
- descontoStrategy: DescontoStrategy
+ �nalizar(pedido: Pedido, adapter: GatewayPagamentoAdapter): void
Figura 8 – Padrão Strategy para Cálculo de Desconto
Na camada de infraestrutura estão concentrados os serviços técnicos da aplicação, 
portanto, é nesta camada que foram alocados o subsistema de persistência dos objetos 
e o subsistema de comunicação com os sistemas externos de pagamento. Esses sub-
sistemas também foram representados como pacotes. A Figura 9 exibe a camada de 
infraestrutura do sistema.
Infraestrutura
Persistência Pagamento
Figura 9 – Camada de Infraestrutura
O pacote de persistência contém as classes responsáveis por persistir os dados do 
sistema em um banco de dados, sendo assim, há uma classe responsável por persistir os 
dados de cada objeto de entidade do pacote Model, como ilustra a Figura 10. 
Persistência
CarrinhoDao ProdutoDao
PedidoDao CartaoDao
ClienteDao
Figura 10 – Pacote de Persistência
Nesta camada consta também o pacote de pagamento, que conterá as classes para 
comunicação com um gateway de pagamento externo a fim de confirmar o pagamento 
do pedido. A Figura 11 exibe o pacote de pagamento com suas devidas classes. Neste 
caso, o padrão de projeto Adapter foi aplicado, permitindo assim adaptar os dados do 
pagamento para o formato esperado pelo o serviço de pagamento externo. As classes 
BoletoGatewayPagamentoAdapter e CartaoGatewayPagamentoAdapter realizam, res-
pectivamente, a comunicação com o gateway de pagamento para realizar o pagamento 
utilizando boleto e cartão de crédito.
16
17
Pagamento
PedidoService
+ �nalizar(pedido: Pedido, adapter: GatewayPagamentoAdapter): void
+ realizarPagamento(pedido: Pedido): void+ realizarPagamento(pedido: Pedido): void
+ realizarPagamento(pedido: Pedido): void
<<Interface>>
GatewayPagamentoAdapter
BoletoGatewayPagamentoAdapter CartaoGatewayPagamentoAdapter
Figura 11 – Pacote de Pagamento com Padrão Adapter
No que se refere à representação dos componentes arquiteturais a serem mapeados 
para elementos físicos, inclusive arquivos, a Figura 12 ilustra o diagrama de compo-
nentes que faz parte da arquitetura do sistema. Observe que além da identificação dos 
componentes, as interfaces de comunicação entre eles também foram estabelecidas.
<<component>>
NavegadorWeb
<<component>>
web-appvendas.jar
<<component>>
SGBD
<<component>>
Pagamento Cartao
<<component>>
Pagamento Boleto
Figura 12 – Diagrama de Componentes
Ainda sobre a Figura 12, os componentes representados são descritos assim:
• NavegadorWeb: este componente representa o navegador pelo qual o cliente acessará 
a aplicação de E-commerce, enviando requisições ao componente webapp-vendas.jar;
• Webapp-vendas.jar: componente de aplicação responsável pelas principais classes 
do sistema e que abrangerá as camadas lógicas de apresentação, aplicação e domí-
nio, representando assim uma aplicação de software monolítica, portanto, este com-
ponente .jar contém as views, controllers, models, serviços de negócios e todos os 
recursos que compõem o sistema;
• SGBD: componente de infraestrutura responsável pelas classes de conexão ao 
banco de dados;
• Pagamento Cartão: componente de infraestrutura responsável por realizar a co-
municação do sistema com o gateway de pagamento para realizar o pagamento 
por meio de cartão de crédito;
• Pagamento boleto: componente de infraestrutura responsável por realizar a comu-
nicação do sistema com o gateway de pagamento para realizar o pagamento por 
meio de boleto.
17
UNIDADE Requisitos, Design e Documentação de 
Arquitetura de Software – Estudo de Caso
Em relação à arquitetura física, o diagrama de implantação exibe a estrutura física do 
sistema, assim é importante ilustrar os nós de processamento e as conexões existentes 
entre eles. Além disso, os componentes representados na Figura 12 foram alocados em 
seus devidos nós de processamento, como mostra a Figura 13. 
Estação do usuário
<<HTTP>>
<<HTTP>>
<<ODBC>>
SGBD
Pagamento cartão
Pagamento boleto
NavegadorWeb
Servidor de Aplicação
Gateway de Pagamento
Servidor de banco de Dados
web-appvendas.jar
Figura 13 – Diagrama de Implantação
“Ter uma arquitetura é uma coisa; uma descrição útil é outra” (LARMAN, 2007, p. 650). 
No que diz respeito à documentação da arquitetura a partir das visões de arquiteturais do 
modelo 4+1 e dos diagramas UML, assunto este abordado na Unidade “Projeto Orienta-
do a Diagramas Arquiteturais UML”, o Quadro 3 apresenta as relações entre as visões de 
arquitetura e os respectivos diagramas UML contemplados nesta unidade. 
Quadro 3 – Visões arquiteturais e diagramas UML
Visão Lógica
• Diagrama de Pacotes;
• Diagrama de Classes;
Visão de Processo • Diagrama de Classes;
Visão Física • Diagrama de Implantação;
Visão de 
Desenvolvimento
• Diagrama de Pacotes;
• Diagrama de Componentes;
Visão de Caso de Uso • Diagrama de Casos de Uso.
Importante!
Uma visão arquitetural é uma ferramenta de comunicação, educação ou raciocínio; ela é 
expressa em texto e em diagramas UML (LARMAN, 2007, p. 650).
Uma documentação da arquitetura de software com base no modelo 4+1 e os diagramas 
UML pode ser consultadano capítulo 39 do livro “Utilizando UML e padrões: uma intro-
dução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo”, de 
Craig Larman, na Biblioteca Virtual da Universidade, disponível em: https://bit.ly/3rFzWeJ
18
19
Implementação da Arquitetura 
Para a implementação da arquitetura do sistema, o arquiteto deve tomar decisões 
referentes às tecnologias que serão utilizadas no desenvolvimento do software, como 
linguagem de programação, ferramentas e frameworks. Para o sistema de E-commerce
do estudo de caso, temos as seguintes decisões técnicas e arquiteturais:
• A linguagem de programação utilizada será Java;
• Para a arquitetura do sistema foi escolhido o padrão MVC, podendo assim fazer uso 
de frameworks, como o Spring MVC, que facilita a criação de Views, Controllers
e Models para o sistema;
• Para uma arquitetura em camadas e cliente-servidor, o Spring MVC também su-
porta perfeitamente esse tipo de aplicação e será bastante útil na implementação.
Spring possui uma documentação bastante rica com diversos tutoriais. 
Disponível em: https://bit.ly/3jBLs88
Na camada de apresentação estão alocadas as Views do sistema e podemos imple-
mentá-las de forma conjunta com os Controllers, assim utilizando o padrão de projeto 
Front Controller, ou seja, para cada ação do Controller retorna um endereço físico para 
um arquivo contendo o HTML da página a ser apresentada na requisição.
Para construção das Views, o Spring fornece o uso de templates HTML, podendo-se 
criar um novo ou utilizar um já existente, uma vez que o Spring faz a integração. Um 
exemplo bastante comum é o Thymeleaf, que é um gerenciador de templates de fácil 
utilização e que suporta diversas estruturas de dados e de linguagem de programação, 
como laços de repetição.
O template Thymeleaf possui diversas funcionalidades, disponível em: https://bit.ly/3a7gjXe
No que diz respeito às classes Controllers do sistema, no tópico “Modelagem e Docu-
mentação Arquitetural” desta unidade foram definidos os Controllers do sistema, sendo que 
estes foram alocados na camada de aplicação para realizar o controle lógico da View com 
os serviços de negócio. Para isto, podemos indicar ao Spring as classes que terão a respon-
sabilidade de Controller, anotando-as com @Controller e com @RequestMapping, sendo 
essa última necessária para indicar o endereço de acesso para um Controller em específico.
Referente à autenticação e autorização, o Spring disponibiliza um conjunto de classes 
no pacote Spring Security para a realização da autenticação e de autorização de usuários 
no sistema. Para tal é necessário implementar algumas classes e sobrescrever algumas 
implementações padrões do Spring de maneira a habilitar o uso dessa funcionalidade.
Documentação referente ao Spring Security, disponível em: https://bit.ly/3p9ENDc
No que tange à camada de domínio, podemos seguir o mesmo padrão dos Controllers
e ter uma classe de serviço de negócio para cada entidade do sistema, incluindo o cartão.
19
UNIDADE Requisitos, Design e Documentação de 
Arquitetura de Software – Estudo de Caso
O Spring utiliza o padrão Services do Domain-Driven Design (DDD) para a constru-
ção dessas classes de serviços de negócio, portanto, para indicar as classes de serviços 
ao Spring, elas devem ser anotadas com @Service. Já para as classes de entidade com 
a anotação @Entity, o Spring interpreta essas classes através do conceito de reflexão 
(reflection do Java) para realizar a persistência dos dados contidos nas instâncias dessas 
classes, utilizando o pacote de persistência por meio das classes de repositório.
Spring disponibiliza uma documentação de suas classes contendo uma descrição de uso 
dessas, disponível em: https://bit.ly/3jDf1Gv
Como também foi visto no tópico “Modelagem e Documentação Arquitetural” desta 
unidade, a camada de infraestrutura é responsável pelos serviços técnicos da aplicação, 
portanto, é nela que podemos alocar as classes de persistência dos dados e de comuni-
cação com sistemas externos.
O sistema precisará realizar a persistência dos dados relacionados aos objetos de entida-
de. No Spring, podemos criar classes de persistência utilizando a anotação @Repository, 
herdando ou implementando a interface CrudRepository. Esta, por sua vez, indica ao 
Spring as operações Create, Read, Update e Delete (CRUD). A Figura 14 exibe as in-
terfaces Repository criadas para o sistema.
<<interface>>
CrudRepository
<<interface>>
CartaoRepository
<<interface>>
ProdutoRepository
<<interface>>
PedidoRepository
<<interface>>
ClienteRepository
<<interface>>
CarrinhoRepository
Figura 14 – Interfaces Repository
Além disso, o Spring utiliza o padrão de projeto Factory Method para construir ins-
tâncias das classes de entidade quando, por exemplo, realizamos uma busca no banco 
de dados utilizando as classes Repository.
Documentação do Spring Data, disponível em: https://bit.ly/3qkUHvS
Por fim, para realizar o pagamento dos pedidos, o sistema se comunicará com um 
gateway de pagamento e, para isto, é necessário implementar classes que realizarão essa 
comunicação, devendo estar alocadas na camada de infraestrutura. Dessa forma, essas 
classes devem estar anotadas com @Component, o que indica ao Spring que esta classe é 
um componente e poderá detectá-la e incluí-la no container de injeção de dependências, 
de maneira a ser utilizada por outras classes, como a de serviços de negócio.
20
21
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Sites
Thymeleaf
https://bit.ly/3a7gjXe
 Leitura
Software Architecture Links
https://bit.ly/2LCS3Tf
Capturing Architectural Requirements
https://ibm.co/3jFMP5J
O Catálogo dos Padrões de Projeto
https://bit.ly/2Z2drVh
Core J2EE Pattern Catalog
https://bit.ly/3a7e1Y7
Serving Web Content with Spring MVC
https://bit.ly/3jBLs88
Securing a Web Application
https://bit.ly/3p9ENDc
Annotation Type Service
https://bit.ly/3jDf1Gv
Spring Data
https://bit.ly/3qkUHvS
The Hillside Group
https://bit.ly/3q5gkAo
21
UNIDADE Requisitos, Design e Documentação de 
Arquitetura de Software – Estudo de Caso
Referências
BASS, L.; CLEMENTS, P.; KAZMAN, R. Software architecture in practice. 2.ed. 
Addison-Wesley, 2003.
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. 
22