apostila atividade 3

Prévia do material em texto

- -1
ARQUITETURA DE SOFTWARE
CAPÍTULO 3 - QUAIS SÃO OS PADRÕES 
UTILIZADOS NA IMPLANTAÇÃO DE 
ARQUITETURA DE ?SOFTWARE
Fernando Skackauskas Dias
- -2
Introdução
Elaborar a arquitetura de um tem sido uma tarefa complexa para muitos desenvolvedores de sistemas.software
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 
 e exponencial, com dispositivos móveis possuindo novas funcionalidades e alta integração desoftware hardware
múltiplas plataformas. O que temos são diversos modelos, padrões e estilos de arquitetura de e desoftware
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 se torna uma funçãosoftware
fundamental. Diante desse cenário, temos as seguintes questões: quais são os padrões disponíveis para a
implantação de uma arquitetura de ? Como analisar os fundamentos do projeto da arquitetura? Comosoftware
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 , geralmente, é um conjunto de procedimentos que toma muito tempo, e muitoslevantamento de requisitos
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 ? Para responder a essas questões, precisamos definirweb
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 necessita de uma apenas daquela parte. A seguir,web análise dos requisitos
demonstraremos como são elaborados os projetos de conteúdo de funcional para componentes e aplicativosweb
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 para os objetos de conteúdo e seus representações de projetos
 necessários para efetuar as relações;mecanismos
• em seguida, são criadas as em um determinado objeto de conteúdo, sendo que esta tarefa informações
•
•
- -3
• em seguida, são criadas as em um determinado objeto de conteúdo, sendo que esta tarefa informações
pode ser executada por redatores, e demais pessoas que geram o conteúdo a ser publicado no designers
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.
O projeto de conteúdo identifica o do conteúdo a ser fornecido pelo aplicativo na . Nesseescopo completo web
sentido, o conteúdo pode aparecer na forma de texto, gráficos, imagens, vídeo ou áudio, sendo que ele é o 
 para fornecer uma visão fundamental dos requisitos para o aplicativo. Esses elementoselemento estrutural
compreendem os objetos de conteúdo e todas as , cujas entidades são visíveis aos usuáriosclasses de análise
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 oupáginas da web
também obtidos de forma direta e dinâmica em um . Quer dizer, um objeto de conteúdo significabanco de dados
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 . Em algumas situações, uma lista dos objetos de conteúdo com umaconteúdo componente
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Ê 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 nãoopen source
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
https://repositorio.unesp.br/bitstream/handle/11449/127619/000843909.pdf?sequence=1&isAllowed=y
- -4
Podemos criar uma com a elaboração para qualquer conteúdo composto de vários objetos de árvore de dados
conteúdo e cujo objetivo é tentar demonstrar as entre os objetos de conteúdo, oferecerrelações hierárquicas
uma maneira de para que as omissões e inconsistências sejam mostradas antes do início dorevisar o conteúdo
projeto e servir de para o projeto de conteúdo.base 
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.
Portanto, a partir do momento que todos os objetos de conteúdo forem modelados, as informações que os
VOCÊ QUER VER?
O filme (SORKIN; MEZRICH, 2010) retrata a história de Mark Zuckerberg e daA rede social
evolução do Facebook, uma verdadeira revolução na sociedade moderna. O longa-metragem
mostra o início darede desenvolvida por Mark, dentro da Universidade de Harvard, e as
desavenças entre Zuckerberg e os outros fundadores, inclusive com o brasileiro Eduardo
Saverin.
- -5
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 , tendo como objetivo autoria e formatação
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.
•
•
•
•
- -6
- -7
- -8
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.
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 iniciada peloprocessamento
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 ( , em português Linguagem de Unified Modeling Language UML
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().
•
•
- -9
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.
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 comerciais são desenvolvidos para serem oferecidos como produto e sãosoftwares 
disponibilizados com a funcionalidade desejada pelo usuário e pelas interfaces amigáveis, permitindo que o
componente seja integrado ao que será desenvolvido. O modelo de desenvolvimento baseado emsoftware 
componentes demanda uma abordagem iterativa para o desenvolvimento do , incorporandosoftware
características do , ou seja, desenvolve aplicações a partir de componentes pré-empacotados.modelo espiral
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 
. Pressman (2016, p. 69) nos dizmódulos convencionais, classes orientadas a objeto ou pacotes de classes
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•
- -10
• 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 é projetada para acomodar os componentes.software 
• 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 , como a redução no tempo de ciclo de vida de desenvolvimento e no custo do projeto. Mas, parasoftware
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 para o desenvolvimento de outrosreferência 
sistemas. É necessário que seja identificada a possibilidade de como parâmetro e que asutilização do sistema 
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 parasoluções mais gerais
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 de nível mais alto que os objetos individuais de um e são definidos porabstrações software 
suas interfaces, sem que os detalhes de implementação sejam encapsulados de outros componentes. A
engenharia de baseada em componentes é, de forma geral, pouco acoplada aos sistemas, sendo que osoftware 
fluxo do processo compreende a definição, implementação e integração de componentes independentes.
•
•
•
•
•
•
•
•
- -11
Outro conceito fundamental na engenharia de componentes é um modelo de , que pode sercomponente-padrão
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 que esteja em conformidade com esses padrões ésoftware 
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.
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 maneirasde compô-los. Mostraremos, na figura a
seguir, a representação da , a e a , decomposição sequencial composição hierárquica composição aditiva
acordo com Sommerville (2011).
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’.
VOCÊ QUER LER?
Na arquitetura de , a reutilização de modelos é considerada uma das estratégias comsoftware
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 , construirsoftware
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
- -12
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.
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 , e simnão chamam uns aos outros
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 ‘ ’ e ‘ ’ da composição dependem da funcionalidadeprovides require
combinada de A e B, mas, normalmente, essa não será uma composição de suas interfaces ‘ ’. Esse tipo deprovides
composição pode ser usado com componentes, que são elementos de programa, ou componentes, que são
serviços.
Na composição hierárquica, apresentada no item (b) da figura apresentada anteriormente, acontece quando um
VOCÊ QUER LER?
Uma das boas práticas de engenharia de é a utilização do reuso, acarretando umasoftware
melhoria considerável para a qualidade dos artefatos de . Nesse sentido, pesquisas emsoftware
engenharia de domínio têm proposto métodos e abordagens, objetivando e apoiando o reuso
de . Quer ler mais? Acesse a dissertação de Brandes; Bacelo (2010) em: <software
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
http://repositorio.pucrs.br/dspace/bitstream/10923/6778/1/000460611-Texto%2bCompleto-0.pdf
- -13
Na composição hierárquica, apresentada no item (b) da figura apresentada anteriormente, acontece quando um
os serviços prestados por outro componente. Portanto, a interface ‘componente chama de forma direta 
’ do componente chamado deve ser compatível com a interface ‘ ’ do componente chamador.provides requires
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 ‘ ’ de A e a interface ‘ ’ de B, algum código de conversão pode ser necessário.requires provides
Por fim, na composição aditiva, que corresponde à situação (c) na figura apresentada anteriormente, ocorre
quando para se criar um novo componente, que engloba suasdois ou mais componentes são colocados juntos
funcionalidades. A interface ‘ ’ e a interface ‘ ’ do novo componente é uma combinação dasprovides requires
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 é originado da área da arquitetura. Ésoftwares 
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 . Os padrões são uma forma de reutilizarherança e polimorfismo
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
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”.
•
•
•
- -14
• 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 ‘
’, conforme demonstraremos no quadro a seguir.Observer
•
•
- -15
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.
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.•
- -16
• Dizer a vários objetos que oestado 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 são normalmente usadas para ilustrar as classes derepresentações gráficas
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 ' ' em UML.Observer 
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.
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 são recursos utilizados para melhorar a qualidade deste e têm o objetivo desoftware 
fornecer para problemas encontrados em diversas atividades do desenvolvimento de .boas práticas 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
•
•
•
•
•
- -17
• 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 . É considerado um caso particular dos padrões desoftware
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 , descrevendo o objetivo de cada um.software
•
•
•
•
- -18
- -19
- -20
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.
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 por meio dassoftware 
especificações de cada padrão.
3.4 Projeto de baseado em padrõessoftware 
Qual o objetivo de construirmos projetos de baseando-se em padrões? Fundamentalmente, baseia-sesoftware 
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
, contando que as características de qualidade de uma determinada arquitetura estão descritas noqualidade
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.
- -21
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.
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 , devido à necessidade de estreitar o escopo, a maioria dossoftware
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 costumam ser especificados por meio da descrição textual de seus componentes,software 
relacionamentos e maneiras que relacionam entre si. Segundo Azevedo (2014, p. 30, grifos nossos), as tarefas de
projeto de podem ser classificadas como:software 
• Definição das tarefas que serão executadas;
VOCÊ SABIA?
Nas últimas décadas, o deixou de ser uma parte pequena e de custo baixo dossoftware
sistemas para se tornar parte fundamental e dispendiosa. Hoje em dia, tudo o que se toca tem 
, seja no uso doméstico ou nas organizações. O artigo de Silva Filho (2015) discute asoftware
onipresença do , as mudanças no cotidiano das pessoas e organizações, e asoftware
preocupação com profissionais da área de engenharia de . Leia mais em: <software
>.http://periodicos.uem.br/ojs/index.php/EspacoAcademico/article/view/29122/15124
•
http://periodicos.uem.br/ojs/index.php/EspacoAcademico/article/view/29122/15124
- -22
• 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 é um conjunto estruturado de atividades esoftware 
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 eweb 
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. : uma abordagem baseada em procuraSeleção de padrões para a arquitetura de software
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%
>. Acesso em: 6/6/2018.20completo.pdf?sequence=1&isAllowed=y
BRANDES, E. S.; BACELO, A. P. T. : uma abordagem para a documentação de arquiteturas de referênciaRADA
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%
>. Acesso em: 6/6/2018.2bCompleto-0.pdf
FARIAS, T. M. M. . 2006. 62 f.Aplicação de padrões ao processo de desenvolvimento de software RUP
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
>. Acesso em: 6/6/2018./Monografia_TiagoMoraes.pdf
FONSECA FILHO, C. : o caminho do pensamento e da tecnologia. Porto Alegre: PUC-RS,História da computação
2007.
GALLOTI, G. M. A. . São Paulo: Pearson Education do Brasil, 2016.Arquitetura de software
LAGMANN, D. F. Um estudo de caso sobre a utilização de padrões de projeto na definição de uma
. 2013. 126 f. Trabalho dearquitetura de software voltada ao desenvolvimento de sistemas de gestão
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
•
•
•
•
•
•
•
•
•
http://www.locus.ufv.br/bitstream/handle/123456789/2686/texto%20completo.pdf?sequence=1&isAllowed=y
http://www.locus.ufv.br/bitstream/handle/123456789/2686/texto%20completo.pdf?sequence=1&isAllowed=y
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
http://tcc.ecomp.poli.br/20062/Monografia_TiagoMoraes.pdf
http://tcc.ecomp.poli.br/20062/Monografia_TiagoMoraes.pdf
https://www.univates.br/bdu/bitstream/10737/357/1/DouglasLagemann.pdf
- -23
Exatas e Tecnológicas, Lajeado, 2013. Disponível em: <https://www.univates.br/bdu/bitstream/10737/357/1
>. Acesso em: 6/6/2018./DouglasLagemann.pdf
MARTINS, H. P. . 2014. 83 f.Tolerância a falha em um ambiente de computação em nuvem open source
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?
>. Acesso em: 6/6/2018.sequence=1&isAllowed=y
PRESSMAN, R. : uma abordagem profissional. 8. ed. Porto Alegre: McGraw Hill, 2016.Engenharia de software
QUINTERO, J. B.; DUITAMA MUÑOZ, J. F. Reflexiones acerca de la adopción de enfoques centrados en modelos en
el desarrollo de software. , Bogotá, Pontifícia Universidade Javeriana, v. 15, n.Revista Ingeniería y Universidad
1, p. 219-243, jan.-jul. 2015. Disponível em: <http://revistas.javeriana.edu.co/index.php/iyu/article/view/1131
>. Acesso em: 6/6/2018./810
SILVA FILHO, A. M. Software everywhere: sobre a demanda de software e da Engenharia de Software. Revista
, Maringá, UEM, v. 15, n. 172, p. 1-4, set. 2015. Disponível em: Espaço Acadêmico <http://periodicos.uem.br/ojs
/index.php/EspacoAcademico/article/view/29122/15124>. Acesso em: 6/6/2018.
SOMMERVILLE, I. . 9. ed. São Paulo: Pearson Prentice Hall, 2011.Engenharia de software
SORKIN, A.; MEZRICH, B. . Direção: David Fincher. Produção: CHAFIN, C. et al. Estados Unidos: SonyA rede social
Pictures, 2010.
https://www.univates.br/bdu/bitstream/10737/357/1/DouglasLagemann.pdf
https://www.univates.br/bdu/bitstream/10737/357/1/DouglasLagemann.pdf
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
http://revistas.javeriana.edu.co/index.php/iyu/article/view/1131/810
http://revistas.javeriana.edu.co/index.php/iyu/article/view/1131/810
http://periodicos.uem.br/ojs/index.php/EspacoAcademico/article/view/29122/15124
http://periodicos.uem.br/ojs/index.php/EspacoAcademico/article/view/29122/15124
	Introdução
	3.1 Análise de projetos de conteúdo e projeto funcional
	3.1.1 Projeto de conteúdo e funcional para componentes
	3.2 Desenvolvimento baseado em componentes
	3.2.1 Engenharia de domínio
	3.2.2 Qualificação, adaptação e composição de componentes
	3.3 Padrões de projeto
	3.3.1 Tipos de padrões
	3.4 Projeto de software baseado em padrões
	3.4.1 Contexto do projeto baseado em padrões
	3.4.2 Tarefas de projetos
	Síntese
	Bibliografia