Unidade 3

26/03/2023, 14:21 Arquitetura de Software
ARQUITETURA DE SOFTWARE
CAPÍTULO 3 - QUAIS SÃO OS PADRÕES
UTILIZADOS NA IMPLANTAÇÃO DE
ARQUITETURA DE SOFTWARE ?
Fernando Skackauskas Dias
INICIAR
Introdução
Elaborar a arquitetura de um software tem sido uma tarefa complexa para muitos
desenvolvedores de sistemas. Dependendo do tamanho e do objetivo do sistema,
são desenvolvidas milhares de linhas de código, centenas de componentes e
conectores, várias bibliotecas, integração com sistemas legados, servidores de
aplicações, tabelas de banco de dados, segurança de acesso, alta disponibilidade e
vários requisitos funcionais e não funcionais que elevam a complexidade da
arquitetura. Além disto, nos últimos anos, houve uma evolução tecnológica de
software e hardware exponencial, com dispositivos móveis possuindo novas
funcionalidades e alta integração de múltiplas plataformas. O que temos são
diversos modelos, padrões e estilos de arquitetura de software e de projetos que
foram criados e evoluídos para atenderem às novas tecnologias. Estes modelos e
padrões devem ser aplicados conforme o cenário e o objetivo do sistema.
Nesse sentido, saber escolher de forma correta os padrões de arquitetura de
software se torna uma função fundamental. Diante desse cenário, temos as
seguintes questões: quais são os padrões disponíveis para a implantação de uma
https://student.ulife.com.br/ContentPlayer/Index?lc=k1V6c06BOXSd7UyznB4EtA%3d%3d&l=WFN7eT7UggcFAXDQz%2fEAfA%3d%3d&cd=97… 1/29
arquitetura de software? Como analisar os fundamentos do projeto da arquitetura?

Como descrever as atividades e as funcionalidades de um determinado padrão de
arquitetura?
Neste capítulo, veremos como distinguir projeto de conteúdo de projeto funcional e
saberemos identificar a fronteira entre conteúdo e função. Apresentaremos,
também, a forma de descrever a engenharia de domínio e analisar os tipos de
padrões de arquitetura. Por fim, descreveremos o funcionamento do projeto
baseado em padrões e distinguiremos padrões de arquitetura, de componentes e de
interfaces do usuário.
Desejamos um excelente estudo.
3.1 Análise de projetos de conteúdo e

projeto funcional
O levantamento de requisitos, geralmente, é um conjunto de procedimentos que
toma muito tempo, e muitos desenvolvedores o executam de maneira superficial ou
simplesmente não o fazem. Isso pode trazer graves consequências, pois resolver
problemas de requisitos após o desenvolvimento pode custar muito mais tempo.
Como resolver problemas de levantamento de requisitos? Qual o nível de análise é
necessário para levantá-los? Como criar projetos de requisitos para aplicativos na
web? Para responder a essas questões, precisamos definir o tamanho e a
complexidade do incremento do aplicativo e a quantidade de interessados, para
poder identificar requisitos conflitantes.
Pressman (2016, p. 197) nos explica que, “embora seja uma boa ideia analisar o
problema antes de começar o projeto, não é verdade que toda análise deva
preceder todo o projeto”. Ou seja, o projeto de uma parte específica de um aplicativo
na web necessita de uma análise apenas dos requisitos daquela parte. A seguir,
demonstraremos como são elaborados os projetos de conteúdo de funcional para
componentes web e aplicativos móveis.
3.1.1 Projeto de conteúdo e funcional para componentes

Pressman (2016, p. 381) descreve: “A arquitetura de conteúdo focaliza a maneira
pela qual objetos de conteúdo (ou objetos compostos como página Web) são
estruturados para apresentação e navegação”.
O projeto de conteúdo engloba duas tarefas de projetos distintos, sendo cada uma
delas manipuladas por pessoas com um determinado conjunto de habilidades
distintas:
inicialmente, são desenvolvidas representações de projetos para os

objetos de conteúdo e seus mecanismos necessários para efetuar as
relações;
em seguida, são criadas as informações em um determinado objeto de
conteúdo, sendo que esta tarefa pode ser executada por redatores,
designers e demais pessoas que geram o conteúdo a ser publicado no
aplicativo.
Um objeto de conteúdo possui atributos com informações específicas de um

conteúdo e os atributos de implantação, que são exclusivos e especificados como
parte do projeto.
VOCÊ SABIA?
Com o crescimento rápido de computação em nuvem, tem aumentado a preocupação com a
necessidade de serviços oferecidos. Um grande desafio é implementar um ambiente tolerante a
falhas. Para combatê-las, muitas técnicas são projetadas para reduzir os erros. O que acontece é que
gestores pagos oferecem esse tipo de suporte, mas aqueles chamados open source não fornecem
elementos que permitam tolerar falhas e deixam os usuários vulneráveis às falhas de um ambiente
de tecnologia. Veja a dissertação de Martins (2014) e saiba
mais: <https://repositorio.unesp.br/bitstream/handle/11449/127619/000843909.pdf?
sequence=1&isAllowed=y
(https://repositorio.unesp.br/bitstream/handle/11449/127619/000843909.pdf?
sequence=1&isAllowed=y)>.
O projeto de conteúdo identifica o escopo completo do conteúdo a ser fornecido

pelo aplicativo na web. Nesse sentido, o conteúdo pode aparecer na forma de texto,
gráficos, imagens, vídeo ou áudio, sendo que ele é o elemento estrutural para
fornecer uma visão fundamental dos requisitos para o aplicativo. Esses elementos
compreendem os objetos de conteúdo e todas as classes de análise, cujas

entidades são visíveis aos usuários que foram criadas ou manipuladas, na
proporção em que o usuário interage com o aplicativo.
Segundo descrito por Pressman (2016, p. 199), “O conteúdo pode ser desenvolvido
antes da implementação da Webapp, enquanto a Webapp está sendo construída ou
bem depois de estar em funcionamento”. Nesse caso, os objetos de conteúdo
podem ser tanto uma descrição textual de um produto quanto uma foto, uma
animação etc. Eles podem ser guardados como arquivos diversos, sendo
incorporados diretamente em páginas da web ou também obtidos de forma direta e
dinâmica em um banco de dados. Quer dizer, um objeto de conteúdo significa
qualquer informação que seja coesa e que deve ser apresentada ao usuário final.
Portanto, os objetos de conteúdo podem ser obtidos a partir dos casos de uso,
analisando a descrição do cenário para obter as referências diretas e indiretas ao
conteúdo. Assim, o projeto de conteúdo tem como objetivo fazer a descrição do
conteúdo componente. Em algumas situações, uma lista dos objetos de conteúdo
com uma descrição sucinta dos objetos já é suficiente para se definir os requisitos
para os conteúdos que serão projetados. Porém, em alguns casos, o projeto de
conteúdo pode ser obtido a partir de uma análise que demonstre, graficamente, os
relacionamentos entre os objetos de conteúdo e a hierarquia do conteúdo do
aplicativo.
VOCÊ QUER VER?

O filme A rede social (SORKIN; MEZRICH, 2010) retrata a história de Mark Zuckerberg e da evolução do
Facebook, uma verdadeira revolução na sociedade moderna. O longa-metragem mostra o início da rede
desenvolvida por Mark, dentro da Universidade de Harvard, e as desavenças entre Zuckerberg e os outros
fundadores, inclusive com o brasileiro Eduardo Saverin.
Podemos criar uma árvore de dados com a elaboração para qualquer conteúdo
composto de vários objetos de conteúdo e cujo objetivo é tentar demonstrar as
relações hierárquicas entre os objetos de conteúdo, oferecer uma maneira de
revisar o conteúdo para que as omissões e inconsistências sejam mostradas antes
do início do projeto e servir de base para o projeto de conteúdo.
Na figura a seguir, demonstraremos uma árvore de conteúdo para um componente

de um sistema de vendas. Neste exemplo, temos a decomposição de um
determinado componente mecânico em suas descrições e podemos observar que
há uma relação hierárquica. Entre as descrições, temos tanto elementos técnicos
(esquema e descrição técnica) quanto elementos comerciais (preço e descrição de
marketing).
Figura 1 - Modelo de uma árvore de conteúdo para um componente e seus relacionamentos de um sistema
de vendas. Fonte: Elaborada pelo autor, baseado em PRESSMAN, 2016.
#PraCegoVer: ilustra o modelo de uma árvore de conteúdo para um componente e

seus relacionamentos de um sistema de vendas. A imagem contém um modelo em
que um componente possui atributos como por exemplo: número da peça, nome da
peça, tipo da peça, descrição e preço. Alguns destes atributos possuem
subatributos, como o atributo preço que possui os subatributos preço no atacado e
preço no varejo e, o atributo descrição que possui os subatributos: descrição de
marketing, fotografia, descrição técnica, esquema, vídeo, preço no atacado e, preço
no varejo.
Portanto, a partir do momento que todos os objetos de conteúdo forem modelados,

as informações que os objetos devem fornecer necessitam passar por um processo
de autoria e formatação, tendo como objetivo melhor atender aos requisitos
estabelecidos pelo cliente do projeto.

Apesar da possibilidade de serem criadas arquiteturas personalizadas, no projeto de
arquitetura de conteúdo temos quatro tipos mais usuais, os quais, segundo
Pressman (2016, p. 381, grifos nossos), são:
Estruturas lineares: são encontradas quando uma sequência interações previsível é

comum.
Estruturas em grade: é uma opção arquitetural que pode ser organizada em
categorias de duas ou mais dimensões.
Estruturas hierárquicas: é uma estrutura que pode ser projetada para
possibilitar o fluxo de controle horizontal ao longo das ramificações
verticais da estrutura.
Estrutura em rede: os componentes da estrutura são projetados de modo
que possam passar o controle para qualquer outro componente do sistema.
Na figura a seguir, apresentaremos a configuração das estruturas linear, em grade,

hierárquica e em rede.
Figura 2 - Modelos de projeto de arquitetura de conteúdo mostrando as estruturas lineares, em grade,

hierárquica e em rede. Fonte: Elaborada pelo autor, baseado em PRESSMAN, 2016.
#PraCegoVer: Ilustra os Modelos de projeto de arquitetura de conteúdo mostrando

as estruturas lineares, em grade, hierárquica e em rede. Estas estruturas são
representadas na imagem por desenho de prédios, organizados conforme cada
estrutura.
Por outro lado, segundo Sommerville (2011), muitos aplicativos móveis podem
oferecer várias funções computacionais e manipuladoras, as quais podem ser
associadas diretamente ao conteúdo e são a meta principal de interação com o
usuário. Nesse sentido, o projeto funcional se associa com dois elementos de
processamento de aplicativos, com diferentes níveis de abstração procedural
(SOMMERVILLE, 2011, p. 201):
Funcionalidade observável pelo usuário fornecida pelo aplicativo aos

usuários finais.
As operações contidas nas classes de análise que implementam
comportamentos associados à classe.
Desse modo, a funcionalidade que é observável compreende qualquer função de

processamento iniciada pelo usuário, ou seja, as funções podem ser
implementadas usando operações dentro das classes de análise. Mas, do ponto de
vista do usuário, a função é o resultado que é visível. Quando se vai para um nível de
abstração procedural mais baixo, o modelo de requisitos demonstra o
processamento que será realizado nas operações de classe de análise. O diagrama
de atividades Unified Modeling Language (UML, em português Linguagem de
Modelagem Unificada) pode ser utilizado para representar os detalhes do
processamento.
Sommerville (2011) fornece o exemplo a seguir, intitulado “controlar câmeras”, em
que temos o diagrama de atividades, a operação assumircontroledacamera(), que
faz parte da classe de análise Camera(), usada no caso de uso ControlaCameras().
Figura 3 - Modelo de diagrama de atividades para a operação assumirControleCamera(), mostrando o fluxo

de ações. Fonte: Elaborada pelo autor, baseado em PRESSMAN, 2016.
#PraCegoVer: Ilustra o modelo de diagrama de atividades para a operação

assumirControleCamera(), mostrando o fluxo de ações. O diagrama retratado na
imagem, inicia por um losango que representa uma estrutura de decisão entre a
câmera estar ou não sendo usada no momento. Se a câmera estiver sendo usada,
então é invocado o método obsterUsuarioAtualCamera() e então é informado ao
usuário que a câmera que bloqueada no momento para ele. Se a câmera não estiver
sendo usada, então é invocado o método solicitarBloqueioCamera(), que então
aciona uma estrutura de decisão entre bloqueio disponível e bloqueio indisponível.
Se for bloqueio disponível, então será executada a ação: Informar câmera que está
sendo usada e o nome do atual usuário. Se a decisão for bloqueio indisponível,
então será executada a ação: Informar câmera indisponível.
Neste exemplo, a interação é relativamente simples, mas existe um risco de

funcionalidade complexa, pois a operação requer comunicação complexa com os
dispositivos localizados remotamente e acessíveis pela internet.
As aplicações mais recentes oferecem funções de processamento cada vez com

maior grau de sofisticação, executando processamento para gerar recursos de
navegação de forma dinâmica, fornecendo recursos apropriados para o campo de
aplicação, disponibilizando consultas de forma sofisticada e, por fim, estabelecendo
interfaces de dados com sistemas externos.
3.2 Desenvolvimento baseado em

componentes
Componentes de softwares comerciais são desenvolvidos para serem oferecidos
como produto e são disponibilizados com a funcionalidade desejada pelo usuário e
pelas interfaces amigáveis, permitindo que o componente seja integrado ao software
que será desenvolvido. O modelo de desenvolvimento baseado em componentes
demanda uma abordagem iterativa para o desenvolvimento do software,
incorporando características do modelo espiral, ou seja, desenvolve aplicações a
partir de componentes pré-empacotados.
Conforme descrito por Pressman (2016), as atividades de modelagem e construção
se iniciam com a identificação de candidatos a componentes. Por sua vez, estes
componentes podem ser projetados como módulos convencionais, classes
orientadas a objeto ou pacotes de classes. Pressman (2016, p. 69) nos diz que,
independentemente da tecnologia utilizada para criar os componentes, este modelo
incorpora as seguintes etapas:
Produtos baseados sem componentes disponíveis são pesquisados e

avaliados para o campo de aplicação.
Itens de integração de componentes são considerados.
Uma arquitetura de software é projetada para acomodar os componentes.
Os componentes são integrados na arquitetura.
Testes completos são realizados para assegurar funcionalidade adequada.
Este modelo baseado em componentes leva ao reuso, o que proporciona uma série
de benefícios aos engenheiros de software, como a redução no tempo de ciclo de
vida de desenvolvimento e no custo do projeto. Mas, para ocorrer, isso deve ser um
procedimento da cultura do grupo de desenvolvedores.
3.2.1 Engenharia de domínio

A engenharia de domínio é um processo que tem como objetivo desenvolver
diversas aplicações que podem ser reusáveis em um domínio particular de
problema. Nesse caso, de forma geral, ela compreende as fases de:
análise: é a primeira fase e é realizado o levantamento dos requisitos do

domínio em questão;
projeto: é a fase intermediária e os modelos de análise realizados na fase
anterior são refinados, com o objetivo de construir uma arquitetura do
domínio;
implementação: é a fase final e tem o objetivo de gerar o código-fonte
para a arquitetura gerada na fase anterior.
A análise de domínio compreende um fluxo processual no qual a informação que foi

utilizada no desenvolvimento de um determinado sistema possa servir como
referência para o desenvolvimento de outros sistemas. É necessário que seja
identificada a possibilidade de utilização do sistema como parâmetro e que as
informações sejam recuperadas e organizadas para o determinado fim.
A reutilização é realizada em um nível de abstração mais elevado, no qual existem
soluções mais gerais para um dado problema, que podem ser aplicadas em
contextos semelhantes. Portanto, é preciso, primeiramente, definir o domínio,
analisá-lo, desenvolver sua arquitetura e, por fim, construir seus componentes.
3.2.2 Qualificação, adaptação e composição de componentes

Componentes são abstrações de nível mais alto que os objetos individuais de um
software e são definidos por suas interfaces, sem que os detalhes de implementação
sejam encapsulados de outros componentes. A engenharia de software baseada em
componentes é, de forma geral, pouco acoplada aos sistemas, sendo que o fluxo do
processo compreende a definição, implementação e integração de componentes
independentes.
CASO
Utilizar corretamente um padrão de projeto pata desenvolvimento de sistemas acarreta uma série de
benefícios para tornar mais ágil e eficiente toda a estrutura de tecnologia de uma corporação. Uma
grande empresa de tecnologia implantou, há alguns anos, os chamados ‘serviços inteligentes’. Na
época, estes sistemas tinham como objetivo diminuir as chamadas perdidas por meio dos serviços
‘siga-me’, ‘caixa-postal’ e ‘desvio de chamada’. Os serviços – sistemas – não foram implantados todos
de uma vez e foi estipulado um determinado padrão para a implantação do primeiro serviço, o qual
foi utilizado para a implantação dos outros. Houve uma redução de 30% de desenvolvimento e
implantação dos sistemas posteriores, pois a utilização do mesmo padrão agregou a experiência do
primeiro sistema nos demais. Isso é chamado de ‘curva de experiência’.
Outro conceito fundamental na engenharia de componentes é um modelo de

componente-padrão, que pode ser implantado de forma independente e sem
modificações, de acordo com um padrão de composição. Essa definição é baseada
em padrões, pois uma unidade de software que esteja em conformidade com esses
padrões é um componente.
Por fim, um componente pode ser definido como uma unidade de composição com
interfaces contratualmente especificadas e que tenha dependências de contexto
explícitas. O que temos é que um componente de software é implantado,
independentemente do sistema, e tem a possibilidade de ser composto por outros
componentes.
VOCÊ QUER LER?

Na arquitetura de software, a reutilização de modelos é considerada uma das estratégias com mais
receptividade nas propostas metodológicas, chegando a envolver de forma exaustiva o conceito de
modelo. Ela promete, na construção de uma aplicação de software, construir modelos e transformá-los de
forma semiautomática no código de um sistema de informação. Ainda existem grandes desafios para se
enfrentar na adoção de enfoques centrados em modelos, como uma grande diversidade de técnicas,
linguagens e ferramentas para transformar modelos. Acesse o artigo publicado por Quintero; Duitama-
Muñoz (2011) e leia mais: <http://revistas.javeriana.edu.co/index.php/iyu/article/view/1131/810
(http://revistas.javeriana.edu.co/index.php/iyu/article/view/1131/810)>.
O processo de composição entre componentes, que tem o objetivo de criar um

sistema ou outro componente, denomina-se integração de componentes, e existem
várias maneiras de compô-los. Mostraremos, na figura a seguir, a representação da
composição sequencial, a composição hierárquica e a composição aditiva, de

acordo com Sommerville (2011).
Figura 4 - Tipos de composição de componente com os diagramas de composição sequencial (a),

composição hierárquica (b) e composição aditiva (c). Fonte: Elaborada pelo autor, baseado em
SOMMERVILLE, 2011.
#PraCegoVer: Ilustra os Tipos de composição de componente com os diagramas de

composição sequencial (a), composição hierárquica (b) e composição aditiva (c). A
imagem contém retângulos para representar os componentes com as respectivas
composições.
Na composição sequencial, apresentada no item (a) da figura apresentada, é criado

um novo componente a partir de dois componentes existentes. Aqui, no entanto, os
componentes não chamam uns aos outros, e sim algum código de ligação extra é
necessário para chamar os serviços de componente na ordem correta e garantir que
os resultados que forem entregues por componente sejam compatíveis com as
entradas esperadas pelo componente.
Segundo Sommerville (2011), as interfaces ‘provides’ e ‘require’ da composição

dependem da funcionalidade combinada de A e B, mas, normalmente, essa não será
uma composição de suas interfaces ‘provides’. Esse tipo de composição pode ser
usado com componentes, que são elementos de programa, ou componentes, que
são serviços.
VOCÊ QUER LER?

Uma das boas práticas de engenharia de software é a utilização do reuso, acarretando uma melhoria
considerável para a qualidade dos artefatos de software. Nesse sentido, pesquisas em engenharia de
domínio têm proposto métodos e abordagens, objetivando e apoiando o reuso de software. Quer ler
mais? Acesse a dissertação de Brandes; Bacelo (2010) em:
<http://repositorio.pucrs.br/dspace/bitstream/10923/6778/1/000460611-Texto%2bCompleto-0.pdf
(http://repositorio.pucrs.br/dspace/bitstream/10923/6778/1/000460611-Texto%2bCompleto-0.pdf)>.
Na composição hierárquica, apresentada no item (b) da figura apresentada

anteriormente, acontece quando um componente chama de forma direta os
serviços prestados por outro componente. Portanto, a interface ‘provides’ do
componente chamado deve ser compatível com a interface ‘requires’ do
componente chamador. Segundo Sommerville (2011), o componente A chama
diretamente o componente B e, se suas interfaces corresponderem, pode não haver
necessidade de código adicional. Mas, se houver uma incompatibilidade entre a
interface ‘requires’ de A e a interface ‘provides’ de B, algum código de conversão
pode ser necessário.
VOCÊ O CONHECE?
Fonseca Filho (2007, p. 101) explica a importância do engenheiro Konrad Zuse para a evolução da Ciência
da Computação: “[...] foi o primeiro engenheiro a criar máquinas de cálculo controladas
automaticamente. Esse engenheiro civil percebeu de forma rápida que um dos aspectos mais onerosos
ao se fazerem longos cálculos com dispositivos mecânicos era guardar os resultados intermediários para
depois utilizá-los nos lugares apropriados nos passos seguintes. Este foi um dos princípios da
computação moderna”.
Por fim, na composição aditiva, que corresponde à situação (c) na figura

apresentada anteriormente, ocorre quando dois ou mais componentes são
colocados juntos para se criar um novo componente, que engloba suas
funcionalidades. A interface ‘provides’ e a interface ‘requires’ do novo componente é
uma combinação das interfaces correspondentes nos componentes A e B. Conforme
descrito por Sommerville (2011, p. 326), “Os componentes são chamados
separadamente por meio da interface externa do componente composto. A e B não
são dependentes e não chamam uns aos outros”. Esse tipo de composição pode ser
usado com componentes.
3.3 Padrões de projeto

O conceito de padrões de projeto para desenvolver sistemas de softwares é originado
da área da arquitetura. É comum arquitetos utilizarem uma série de elementos de
projetos arquitetônicos estabelecidos, como arcos e colunas, ao projetarem
edifícios. Neste sentido, Sommerville (2011, p. 133) descreve:
Os padrões de projeto foram obtidos a partir das ideias apresentadas por

Christopher Alexander [...], que sugeriu haver padrões comuns de projeto de
prédios que eram inerentemente agradáveis e eficazes. O padrão é uma
descrição do problema e da essência de sua solução, de modo que a solução
possa ser reusada em diferentes contextos. O padrão não é uma especificação
detalhada. Em vez disso, você pode pensar nele como uma descrição de
conhecimento e experiência, uma solução já aprovada para um problema
comum.
Sommerville (2011) explica que os padrões de projeto são comumente associados

aos padrões de orientação a objeto, pois consideram características como herança e
polimorfismo. Os padrões são uma forma de reutilizar o conhecimento e a
experiência de outros projetos. Segundo Sommerville (2011, p. 133), os quatro
elementos essenciais dos padrões de projeto são definidos como:
Um nome que seja uma referência significativa para o padrão.

Uma descrição da área de problema que explique quando o modelo pode
ser aplicado.
A descrição da solução das partes da solução de projeto, seus

relacionamentos e suas responsabilidades. Essa não é uma descrição do
projeto concreto; é um modelo para uma solução de projeto que pode ser
instanciado de diferentes maneiras. Costuma ser expresso graficamente e
mostra os relacionamentos entre os objetos e suas classes na solução.
Uma declaração das consequências — os resultados e compromissos — da
aplicação do padrão. Pode ajudar os projetistas a entenderem quando um
padrão pode ou não ser usado em uma situação particular.
Sommerville (2011) explica que, para podermos ilustrar a descrição de padrão,
devemos utilizar o padrão ‘Observer’, conforme demonstraremos no quadro a seguir.
Quadro 1 - Descrição do padrão ‘Observer’, demonstrando suas características, suas descrições, seus
problemas, suas soluções e suas consequências. Fonte: Elaborado pelo autor, baseado em SOMMERVILLE,
2011.
#PraCegoVer: Contém uma tabela com a descrição do padrão ‘Observer’,

demonstrando suas características, suas descrições, seus problemas, suas soluções
e suas consequências. A tabela contém duas colunas. A descrição do padrão
Observer é: separa o display do estado de um objeto a partir do objeto em si e
permite que sejam fornecidos displays alternativos. Quando o estado de um objeto
muda, todos os displays são automaticamente notificados e atualizados para refletir
a mudança. A descrição de um problema que o padrão 'Observer' se propões a
resolver, é: Em muitas situações, você precisa fornecer displays de informações do
estado, como um display gráfico e em tabela. Nem todos eles podem ser conhecidos
quando a informação é especificada. Todas as apresentações alternativas devem
apoiar a interação e, quando o estado é alterado, todos os displays devem ser
atualizados. Esse padrão pode ser usado em todas as situações em que mais de um
formato de displays de informações de estado é necessário, e em que saber sobre os
formatos de display específicos usados não é necessário para o objeto que mantém
as informações do estado. A descrição da solução que o padrão 'Observer' se propõe
é: Trata-se de dois objetos abstratos, Subject e Observer, e dois objetos concretos,
ConcreteSubject e Concrete Observer, que herdam os atributos dos objetos
abstratos relacionados. Os objetos abstratos incluem as operações gerais aplicáveis
em todas as situações. O estado a ser exibido e mantido no ConcreteSubject, que
herda as operações de Subject permitindo adicionar ou remover Observers (cada
Observer corresponde a um display) e emitir uma notificação quando o estado
mudar. O ConcreteObserver mantém uma cópia do estado do ConcreteSubject e
implementa a interface atualizar do Observer, que permite que essas cópias sejam
mantidas nessa etapa. Automaticamente, o ConcreteObserver exibe o estado e
reflete as mudanças sempre que o estado é atualizado. A descrição das
consequências é: O Subject só reconhece o Observer abstrato e não sabe detalhes
da classe concreta. Portanto, há um acompanhamento mínimo entre esses objetos.
Devido a essa falta de conhecimento, as otimizações que melhoram o desempenho
do display são impraticáveis. As alterações no Subject podem causar uma série de
atualizações ligadas aos Observers relacionados para serem geradas, algumas das
quais podem não ser necessárias.
Sommerville explica que, para usar padrões em projetos, é necessário reconhecer

que qualquer problema de projeto pode ter um padrão associado que pode ser
aplicado e expõe esses problemas (2011, p. 134):
Dizer a vários objetos que o estado de algum outro objeto mudou.

Arrumar as interfaces para vários objetos relacionados que, muitas vezes,
foram desenvolvidos de forma incremental.
Fornecer uma forma padronizada de acesso aos elementos de uma coleção,
independentemente de como essa coleção é implementada.
Permitir a possibilidade de estender a funcionalidade de uma classe
existente em run-time (padrão Decorator).
Segundo Sommerville (2011), as representações gráficas são normalmente usadas

para ilustrar as classes de objeto em padrões e seus relacionamentos. Estes
suplementam a descrição do padrão e acrescentam detalhes à descrição da solução.
A figura a seguir demonstra a representação do padrão 'Observer' em UML.
Figura 5 - Demonstração de um modelo UML do padrão 'Observer' mostrando a relação entre as classes.
Fonte: Elaborada pelo autor, baseado em SOMMERVILLE, 2011.
#PraCegoVer: Ilustra a demonstração de um modelo UML do padrão 'Observer'

mostrando a relação entre as classes. A imagem contém um diagrama de classes,
onde as classes Subject e Observer se relacionam. Contém também a classe
ConcreteSubject que herda de Subject e a classe ConcreteObserver que herda de
Observer. A classe Subject contém os métodos Anexar() e Separar() que recebem um
Observer por parâmetro, e também contém o método Notificar(), sem parâmetros. A
classe ConcreteSubject contém o método ObterEstado(). As classes Observer e

ConcreteObserver contêm o método Atualizar().
Por fim, os padrões podem suportar reuso de conceito em alto nível. Ao buscar o
reuso de componentes executáveis, pode acontecer de ter limitações nas decisões
do projeto detalhado feito pelos implementadores: desde os algoritmos particulares
(que são usados para implantar os componentes) até os objetos e a interface de
componentes.
3.3.1 Tipos de padrões

Padrões de projeto de software são recursos utilizados para melhorar a qualidade
deste e têm o objetivo de fornecer boas práticas para problemas encontrados em
diversas atividades do desenvolvimento de software.
Existem algumas topologias que os definem, e os processos de criação dos objetos
são abstraídos dos padrões de projetos. O objetivo, portanto, é que os padrões
façam com que o sistema se torne independente da forma como são seus objetos.
Uma topologia é apresentada por Farias (2006, p. 31, grifos nossos) e descreve que
os padrões podem ser classificados como:
Padrões estruturais: têm como objetivo se ocuparem com a maneira como classes
e objetos são compostos para criar estruturas maiores. Então, as heranças são
utilizadas pelos padrões de classe para que sejam compostas as interfaces ou
implementações. Por outro lado, os objetos descrevem como os objetos devem ser
compostos para as novas.
Padrões comportamentais: têm como foco o algoritmo e as
responsabilidades atribuídas entre os objetos do sistema. Não é objetivo,
portanto, descrever os padrões em si, mas as comunicações que são
realizadas entre os objetos.
Padrões para persistência: têm como objetivo descrever soluções para
problemas de armazenamento de informações.
Padrões para apresentação: têm como objetivo definir as soluções para
problemas comuns no projeto da interface de software. É considerado um
caso particular dos padrões de projeto.
Outra topologia demonstrada por Lagmann (2013, p. 101) descreve que a
[...] utilização de padrões formaliza o método de descrição dos padrões, e o

uso de padrões não limitaria os desenvolvedores às soluções prescritas, mas
garantiria a presença de elementos fundamentais, e a possibilidade de
aperfeiçoa-la através das experiências adquiridas.
No quadro a seguir, apresentaremos os padrões de projeto de software, descrevendo

o objetivo de cada um.
Quadro 2 - Descrições dos padrões de projeto de arquitetura com os principais objetivos de cada um. Fonte:
Elaborado pelo autor, baseado em LAGMANN, 2013.
#PraCegoVer: Ilustra as descrições dos padrões de projeto de arquitetura com os

principais objetivos de cada um. A imagem contém uma tabela com os padrões e
seus respectivos objetivos, listados a seguir. Registry: um objeto conhecido para
localizar outros objetos. Facade: fornece uma interface unificada para um conjunto
de subsistema. Remote Facade: promove uma interface unificada para um conjunto
de subsistemas que são acessados remotamente. Service Layer: define o limite de
uma aplicação com uma camada de serviços que disponibiliza um conjunto de
operações e coordena a resposta a cada operação. Model View Presenter: Define a
aplicação em três regras distintas, a fim de isolar as diferentes responsabilidades em
Model, Vew e Presenter. Layer Supertype: um tipo que atua como um supertipo para
os demais componentes de uma camada. Data Transfer Object: este padrão tem o
objetivo de definir objetos que trafegam entre os processos da aplicação sobre os
quais são efetuadas as operações do sistema. Separated Interface: define a interface
de uma classe em um componente diferente de sua implementação. Gateway: este
padrão tem o objetivo de encapsular em um objeto o acesso a alguns recursos ou
sistema externo. Unit os Work: um objeto que contém a relação de objetos que
foram afetados por uma transação comercial. Query Object: um objeto que
representa uma consulta do banco de dados. Data Mapper: este padrão tem o
objetivo de isolar o mapeamento entre o modelo relacional do banco de dados ao
modelo orientado a objetos. Repository: disponibiliza uma interface para manipular
dados em um formato de coleção de dados. Lazy Load: um objeto que não contém
todos dados necessários, mas sabe como buscá-los. Singleton: este padrão tem o
objetivo de manter existência de apenas uma instância de um objeto, mantendo um
ponto global de acesso. Abstract Factory: permite a criação de objetos por meio de
uma única interface, sem que a classe concreta seja especificada. Dependency
Injection: é utilizado para manter um baixo acoplamento entre os diferentes
componentes de um sistema. Service Locator: este padrão visa encapsular e abstrair
os processos envolvidos na obtenção de um objetivo.
Portanto, por meio da demonstração das topologias, é possível confirmar a

importância em se desenvolver projetos baseados em padrões como forma de
garantir a qualidade interna do software por meio das especificações de cada
padrão.
3.4 Projeto de software baseado em

padrões
Qual o objetivo de construirmos projetos de software baseando-se em padrões?
Fundamentalmente, baseia-se nas boas práticas de reuso de soluções, porém vai
além disso: projetos baseados em padrões auxiliam no entendimento da arquitetura
pelos desenvolvedores, firmam a conformidade entre a arquitetura proposta e
efetivamente implantada e, consequentemente, reduzem o tempo de implantação.
Portanto, quando desenvolvemos projetos de sistemas baseados em padrões,
temos uma prática de uso dos atributos de qualidade, contando que as
características de qualidade de uma determinada arquitetura estão descritas no
próprio padrão.
3.4.1 Contexto do projeto baseado em padrões

Conforme demonstrado por Azevedo (2014, p. 23), as decisões arquiteturais
compreendem decisões estratégicas feitas durante o projeto de arquitetura.

Estas decisões possuem alto impacto sobre o alcance de metas do negócio
que o software se propõe. Estas decisões também possuem impacto
sistêmico, quer dizer, impactam em mudanças na estrutura e no
comportamento de todo o sistema. As decisões tomadas sobre o contexto do
projeto envolvem criação de regras de projeto e de restrições aos
componentes, pois define o que o sistema ou partes dele não poderá realizar
e inclusive como não poderá ser utilizado.
O que temos é que padrões de projeto não possuem, necessariamente, um foco em

preocupações de arquitetura, mas podem ser interpretados de um ponto de vista
arquitetural. Na verdade, vários pesquisadores argumentam que é difícil conhecer
um limite entre padrões arquiteturais e padrões de projeto.
VOCÊ SABIA?
Nas últimas décadas, o software deixou de ser uma parte pequena e de custo baixo dos sistemas para
se tornar parte fundamental e dispendiosa. Hoje em dia, tudo o que se toca tem software, seja no uso
doméstico ou nas organizações. O artigo de Silva Filho (2015) discute a onipresença do software, as
mudanças no cotidiano das pessoas e organizações, e a preocupação com profissionais da área de
engenharia de software. Leia mais em:
<http://periodicos.uem.br/ojs/index.php/EspacoAcademico/article/view/29122/15124
(http://periodicos.uem.br/ojs/index.php/EspacoAcademico/article/view/29122/15124)>.
Podemos incluir, entre os elementos do contexto que devem ser considerados

durante a seleção de uma opção arquitetural, conforme o seguinte quadro:
Quadro 3 - Elementos do
contexto que devem ser considerados durante a seleção de uma opção arquitetural. Fonte: Elaborado pelo
autor, baseado em AZEVEDO, 2014.
#PraCegoVer: Ilustra os Elementos do contexto que devem ser considerados

durante a seleção de uma opção arquitetural. A imagem contém uma tabela com
duas colunas. A primeira coluna contém os seguintes termos: restrições de negócio,
restrições técnicas, atributos de qualidade, domínio da aplicação, e, requisitos
funcionais. O texto da segunda coluna para restrições de negócios é: A quantidade
de recursos disponíveis, as características da indústria, o tempo disponível para
finalização do projeto, entre outros fatores relativos ao negócio que o software
apoia devem ser considerados durante a escolha de uma opção arquitetural. O texto
para restrições técnicas é: Uma arquitetura deve estar em conformidade com
restrições impostas por ações tecnológicas resolvidas de antemão. O texto para
atributos de qualidade é: os atributos de qualidade influenciam as decisões
arquiteturais, uma vez que estes são operacionalizados em boa parte pelo projeto
de arquitetura. O texto para domínio da aplicação é: o fato de o software ser um

sistema para internet, ou um sistema de tempo real, ou um sistema stand-alone
limita as opções arquiteturais disponíveis para escolha. O texto para domínio da
aplicação é: Uma vez que entre os objetivos de se arquitetar figura a necessidade de
criar arquiteturas que possibilitem dividir o trabalho de implementação do software
de maneira razoável, os requisitos funcionais também influenciam na estruturação
da arquitetura de software.
Conforme explicado por Azevedo (2014), mesmo que se compreenda a relevância de

vários fatores de contexto na tomada de decisão em arquitetura de software, devido
à necessidade de estreitar o escopo, a maioria dos projetos restringe-se a considerar
requisitos de qualidade como parâmetros de tomada de decisão.
3.4.2 Tarefas de projetos

Padrões de software costumam ser especificados por meio da descrição textual de
seus componentes, relacionamentos e maneiras que relacionam entre si. Segundo
Azevedo (2014, p. 30, grifos nossos), as tarefas de projeto de software podem ser
classificadas como:
Definição das tarefas que serão executadas;

Momento em que determinada tarefa deverá ser executada;
Responsáveis por executar tais tarefas;
Padronização no processo de desenvolvimento do projeto.
Segundo Sommerville (2011), a tarefa de um projeto de software é um conjunto

estruturado de atividades e resultados que satisfaça um conjunto de objetivos e
padrões. O projeto da arquitetura consiste em descrever as tarefas em um nível mais
elevado, com seus elementos fundamentais e, a seguir, executar o refinamento dos
seus recursos e suas funcionalidades, demonstrando como interagem e efetuando a
decomposição.
Síntese
Concluímos este capítulo compreendendo como distinguir projeto de conteúdo de

projeto funcional e suas fronteiras. Também foi possível compreendermos os
fundamentos de componentes para ambiente web e aplicativos móveis.
Apresentamos como analisar o processo de desenvolvimento baseado em
componentes, a engenharia de domínios e demonstramos os padrões de projeto e
projetos baseados em padrões.
Neste capítulo, você teve a oportunidade de:
conhecer projetos de conteúdo e funcional;
compreender os sistemas baseados em componentes;
diferenciar os tipos de padrões de projeto;
realizar as descrições de padrões;
analisar os projetos baseados em padrões.
Bibliografia
AZEVEDO, R. P. M. Seleção de padrões para a arquitetura de software: uma
abordagem baseada em procura de termos e sinônimos. 2014. 94 f. Dissertação
(Mestrado em Ciência da Computação) – Universidade Federal de Viçosa, Viçosa,
2014. Disponível em:
<http://www.locus.ufv.br/bitstream/handle/123456789/2686/texto%20completo.pd
f?sequence=1&isAllowed=y
(http://www.locus.ufv.br/bitstream/handle/123456789/2686/texto%20completo.pdf
?sequence=1&isAllowed=y)>. Acesso em: 6/6/2018.
BRANDES, E. S.; BACELO, A. P. T. RADA: uma abordagem para a documentação de
arquiteturas de referência através de linguagens de descrição arquiteturais. 2010.
211 f. Dissertação (Mestrado em Ciência da Computação) – Pontifícia Universidade
Católica do Rio Grande do Sul, Faculdade de Informática, Porto Alegre, 2010.
Disponível
em: <http://repositorio.pucrs.br/dspace/bitstream/10923/6778/1/000460611-
Texto%2bCompleto-0.pdf
(http://repositorio.pucrs.br/dspace/bitstream/10923/6778/1/000460611-
Texto%2bCompleto-0.pdf)>. Acesso em: 6/6/2018.
FARIAS, T. M. M. Aplicação de padrões ao processo de desenvolvimento de
software RUP. 2006. 62 f. Trabalho de conclusão de curso (Graduação em
Engenharia de Produção) – Escola Politécnica de Pernambuco, Departamento de
Sistemas Computacionais, Recife, 2006. Disponível em:
<http://tcc.ecomp.poli.br/20062/Monografia_TiagoMoraes.pdf
(http://tcc.ecomp.poli.br/20062/Monografia_TiagoMoraes.pdf)>. Acesso em:
6/6/2018.
FONSECA FILHO, C. História da computação: o caminho do pensamento e da
tecnologia. Porto Alegre: PUC-RS, 2007.
GALLOTI, G. M. A. Arquitetura de software. São Paulo: Pearson Education do Brasil,
2016.
LAGMANN, D. F. Um estudo de caso sobre a utilização de padrões de projeto na
definição de uma arquitetura de software voltada ao desenvolvimento de
sistemas de gestão. 2013. 126 f. Trabalho de conclusão de curso (Graduação em
Sistemas de Informação) – Centro Universitário Univates, Centro de Ciências Exatas
e Tecnológicas, Lajeado, 2013. Disponível em:
<https://www.univates.br/bdu/bitstream/10737/357/1/DouglasLagemann.pdf
(https://www.univates.br/bdu/bitstream/10737/357/1/DouglasLagemann.pdf)>.
Acesso em: 6/6/2018.
MARTINS, H. P. Tolerância a falha em um ambiente de computação em nuvem
open source. 2014. 83 f. Dissertação (Mestrado em Ciência da Computação) –
Universidade Estadual Paulista Júlio de Mesquita Filho, Bauru, 2014. Disponível
em: <https://repositorio.unesp.br/bitstream/handle/11449/127619/000843909.pdf?
sequence=1&isAllowed=y
(https://repositorio.unesp.br/bitstream/handle/11449/127619/000843909.pdf?
sequence=1&isAllowed=y)>. Acesso em: 6/6/2018.
PRESSMAN, R. Engenharia de software: uma abordagem profissional. 8. ed. Porto
Alegre: McGraw Hill, 2016.
QUINTERO, J. B.; DUITAMA MUÑOZ, J. F. Reflexiones acerca de la adopción de
enfoques centrados en modelos en el desarrollo de software. Revista Ingeniería y
Universidad, Bogotá, Pontifícia Universidade Javeriana, v. 15, n. 1, p. 219-243, jan.-
jul. 2015. Disponível

em: <http://revistas.javeriana.edu.co/index.php/iyu/article/view/1131/810
(http://revistas.javeriana.edu.co/index.php/iyu/article/view/1131/810)>. Acesso em:
6/6/2018.
SILVA FILHO, A. M. Software everywhere: sobre a demanda de software e da
Engenharia de Software. Revista Espaço Acadêmico, Maringá, UEM, v. 15, n. 172, p.
1-4, set. 2015. Disponível
em: <http://periodicos.uem.br/ojs/index.php/EspacoAcademico/article/view/29122/
15124
(http://periodicos.uem.br/ojs/index.php/EspacoAcademico/article/view/29122/1512
4)>. Acesso em: 6/6/2018.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Prentice Hall,
2011.
SORKIN, A.; MEZRICH, B. A rede social. Direção: David Fincher. Produção: CHAFIN, C.
et al. Estados Unidos: Sony Pictures, 2010.

Unidade 3

Enviado por

Dados do documentoclique para ver informações do documento

Direitos autorais:

Formatos disponíveis

Unidade 3

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Unidade 3

Enviado por

Direitos autorais:

Formatos disponíveis

26/03/2023, 14:21 Arquitetura de Software

arquitetura de software? Como analisar os fundamentos do projeto da arquitetura?

3.1 Análise de projetos de conteúdo e

3.1.1 Projeto de conteúdo e funcional para componentes

inicialmente, são desenvolvidas representações de projetos para os

Um objeto de conteúdo possui atributos com informações específicas de um

O projeto de conteúdo identifica o escopo completo do conteúdo a ser fornecido

compreendem os objetos de conteúdo e todas as classes de análise, cujas

VOCÊ QUER VER?

Na figura a seguir, demonstraremos uma árvore de conteúdo para um componente

#PraCegoVer: ilustra o modelo de uma árvore de conteúdo para um componente e

Portanto, a partir do momento que todos os objetos de conteúdo forem modelados,

estabelecidos pelo cliente do projeto.

Estruturas lineares: são encontradas quando uma sequência interações previsível é

Na figura a seguir, apresentaremos a configuração das estruturas linear, em grade,

Figura 2 - Modelos de projeto de arquitetura de conteúdo mostrando as estruturas lineares, em grade,

#PraCegoVer: Ilustra os Modelos de projeto de arquitetura de conteúdo mostrando

Funcionalidade observável pelo usuário fornecida pelo aplicativo aos

Desse modo, a funcionalidade que é observável compreende qualquer função de

Figura 3 - Modelo de diagrama de atividades para a operação assumirControleCamera(), mostrando o fluxo

#PraCegoVer: Ilustra o modelo de diagrama de atividades para a operação

Neste exemplo, a interação é relativamente simples, mas existe um risco de

As aplicações mais recentes oferecem funções de processamento cada vez com

3.2 Desenvolvimento baseado em

Produtos baseados sem componentes disponíveis são pesquisados e

3.2.1 Engenharia de domínio

análise: é a primeira fase e é realizado o levantamento dos requisitos do

A análise de domínio compreende um fluxo processual no qual a informação que foi

3.2.2 Qualificação, adaptação e composição de componentes

Outro conceito fundamental na engenharia de componentes é um modelo de

VOCÊ QUER LER?

O processo de composição entre componentes, que tem o objetivo de criar um

composição sequencial, a composição hierárquica e a composição aditiva, de

Figura 4 - Tipos de composição de componente com os diagramas de composição sequencial (a),

#PraCegoVer: Ilustra os Tipos de composição de componente com os diagramas de

Na composição sequencial, apresentada no item (a) da figura apresentada, é criado

Segundo Sommerville (2011), as interfaces ‘provides’ e ‘require’ da composição

VOCÊ QUER LER?

Na composição hierárquica, apresentada no item (b) da figura apresentada

Por fim, na composição aditiva, que corresponde à situação (c) na figura

3.3 Padrões de projeto

Os padrões de projeto foram obtidos a partir das ideias apresentadas por

Sommerville (2011) explica que os padrões de projeto são comumente associados

Um nome que seja uma referência significativa para o padrão.

A descrição da solução das partes da solução de projeto, seus

#PraCegoVer: Contém uma tabela com a descrição do padrão ‘Observer’,

Sommerville explica que, para usar padrões em projetos, é necessário reconhecer

Dizer a vários objetos que o estado de algum outro objeto mudou.

Segundo Sommerville (2011), as representações gráficas são normalmente usadas

#PraCegoVer: Ilustra a demonstração de um modelo UML do padrão 'Observer'

classe ConcreteSubject contém o método ObterEstado(). As classes Observer e

3.3.1 Tipos de padrões

Outra topologia demonstrada por Lagmann (2013, p. 101) descreve que a

[...] utilização de padrões formaliza o método de descrição dos padrões, e o

No quadro a seguir, apresentaremos os padrões de projeto de software, descrevendo

#PraCegoVer: Ilustra as descrições dos padrões de projeto de arquitetura com os

Portanto, por meio da demonstração das topologias, é possível confirmar a

3.4 Projeto de software baseado em

3.4.1 Contexto do projeto baseado em padrões