Prévia do material em texto

- -1
ENGENHARIA DE SOFTWARE II
CAPÍTULO 2 – PADRÕES DE PROJETOS, O 
QUE SÃO E QUANDO UTILIZÁ-LOS?
Aline Izida
- -2
Introdução
Na medida em que a Engenharia de foi evoluindo, os métodos e técnicas foram se desenvolvendo cadaSoftware
vez mais, para abranger a necessidade de cada tipo de projeto e facilitar o trabalho dos profissionais envolvidos.
Se seu projeto é grande ou pequeno, não importa, você vai precisar conhecer, ao menos, algumas técnicas
comuns à Engenharia de .Software
Um padrão é um modelo com um conjunto de regras que devem ser seguidas em vista a contribuir para trazer
benefícios nessa utilização.
Para que um padrão seja consolidado, ele passa por testes e avaliações, então, já é o começo do caminho pronto
para alavancar os passos seguintes. Já imaginou que iniciar um projeto sem entender qual padrão pode auxiliá-
lo, provavelmente lhe fará perder muito tempo e dinheiro? E se você não gerenciar as mudanças, versões e 
, ao longo do ciclo de vida do desenvolvimento do seu ? Você conhece as consequências dessasreleases software
atitudes?
Neste capítulo, você vai compreender o porquê de se utilizar padrões de projeto e a importância de gerenciar a
configuração ao longo do ciclo de vida do desenvolvimento dos sistemas de .software
Vamos, também, abordar o conceito de integração de sistemas, advindo de uma necessidade do mercado de
integrar todos os sistemas da empresa em apenas um, para facilitar não só a utilização, como também o
desenvolvimento e manutenção, tornando os processos da empresa mais ágeis e produtivos.
Acompanhe o conteúdo com dedicação! Bons estudos!
2.1 Projeto de arquitetura
Em um primeiro momento, antes de entendermos o que é um projeto de arquitetura, precisamos saber o que é
um projeto de . Desse modo, você pode fazer uma analogia do projeto de com os projetos feitossoftware software
por arquitetos ou engenheiros civis, por exemplo, nos quais os requisitos são traduzidos em uma “planta” para
construir o , em um processo iterativo, isto é, em que é possível ir e voltar nas fases desoftware
desenvolvimento, procurando sempre corrigir erros e melhorar os resultados antes que o processo termine e
restem muitos problemas que só poderiam ser resolvidos tardiamente. Essa fase de projeto é quando o
profissional deve colocar a criatividade, os conhecimentos e a experiência em prática.
Assim, o profissional, conhecido como arquiteto de , deve considerar os requisitos que foram analisadossoftware
e especificados, para então formular um produto, isto é, o .software
Você quer saber mais sobre o tema? Clique nas setas abaixo e confira!
Se, na fase de requisitos foram modeladas as funções e comportamentos necessários, ou seja, “o que” é para ser
implementado, agora, o projeto de arquitetura deve criar um modelo de , que vai representar o “como”software
fazer. Nessa fase será destacada e detalhada essa arquitetura, as estruturas de dados, as interfaces e
VOCÊ SABIA?
O termo projeto, em inglês significa e, nas engenharias em geral, é uma fase que édesign
apresentada de forma semelhante (engenharia civil, naval, química, matemática). Na
engenharia de , o termo é utilizado para estabelecer como os requisitos levantadossoftware
devem ser implementados na construção do .software
- -3
fazer. Nessa fase será destacada e detalhada essa arquitetura, as estruturas de dados, as interfaces e
componentes que serão essenciais para, na próxima fase, implementar o .software
A importância de se projetar um corretamente, se dá pelo fato de que essa fase é de extrema relevânciasoftware
para que o produto final seja de qualidade, pois se o modelo de arquitetura não representar um software
adequado e esperado, o código que for gerado na implementação não corresponderá ao que foi requerido e,
consequentemente, resultará em um de má qualidade.software
Portanto, o projeto de abrange a representação do software a ser desenvolvido e, com isso, pode contersoftware
atividades diferentes, de acordo com objetivo de desejado. Sommerville (2011) e Pressman (2011)software
apontam as quatro atividades que podem ser parte do processo de projeto de sistemas de : projeto desoftware
arquitetura, de interface, de componente e de banco de dados.
Neste momento, nos interessa o projeto de arquitetura, que define a estrutura geral do sistema, os componentes
principais (subsistemas ou módulos), seus relacionamentos, como esses componentes são distribuídos e,
também, define as restrições que afetam o modo pelo qual a arquitetura pode ser implementada, representando,
assim, a organização da solução técnica de um , que é derivada de um modelo de requisitos.software
Dessa maneira, o projeto de arquitetura ganha destaque, ao passo em que representa a estrutura de dados e os
componentes de programa que são necessários para construir o . Afinal, quando se constrói uma casa, osoftware
ideal é ter uma planta em mãos, certo? Também devemos partir de um contexto geral da casa e, depois, nos
preocupar com detalhes, como o encanamento ou sistema elétrico, acabamentos e assim por diante.
Uma arquitetura é muito mais que uma estrutura física, ela é a forma como diversos componentes de uma casa
são integrados para formar um todo coeso. Isso também inclui se integrar ao ambiente e vizinhança para, enfim,
tratar de detalhes como cores, texturas, iluminação, piso, etc., para, então, formar a casa completa (PFLEEGER,
2004).
Clique nas abas abaixo e veja mais sobre o tema.
Estilo de
arquitetura
Esse mesmo raciocínio deve ser seguido quando arquitetamos um . O arquiteto dosoftware
sistema começa escolhendo um estilo de arquitetura que seja coerente com o resultado da
análise de requisitos. Desse modo, podemos afirmar que a arquitetura não se trata do 
 que se pode operar, mas de uma representação. Ela vai permitir que analisemos se osoftware
projeto vai atender aos requisitos especificados e se vai considerar alternativas de
arquitetura, caso seja necessário realizar mudanças no projeto, para reduzir o trabalho e os
riscos atrelados à implementação do .software
Decisões
Nessa fase, portanto, é preciso tomar muitas decisões, das grandes às pequenas. Os
componentes representam entidades funcionais ou de processamento, podendo ser pacotes,
classes, objetos, procedimentos, funções, métodos, etc. Para representar os relacionamentos
entre eles, utiliza-se os conectores, que podem passar dados e controle, compartilhar dados,
dentre outros (PRESSMAN, 2011).
Para exemplificar essa representação, vamos considerar um modelo abstrato de arquitetura de um sistema de
controle robotizado de empacotamento, que é proposto, de acordo com a figura a seguir.
- -4
Figura 1 - Exemplo de representação da arquitetura de um sistema de controle robotizado de empacotamento.
Fonte: Elaborada pela autora, adaptada de SOMMERVILLE, 2011, p. 104.
Esse sistema robotizado mostra como é possível embalar tipos diferentes de objetos, usando um componente de
visão para selecionar objetos em uma esteira. Esse mesmo componente também identifica o tipo de objeto e
seleciona o tipo correto de empacotamento. Logo depois, o sistema retira os objetos da esteira de entrega para
serem empacotados, e, então, o sistema coloca os objetos empacotados em outra esteira. Esse é um exemplo de
modelo de arquitetura que mostra os componentes e os relacionamentos entre eles.
Em geral, é possível modelar arquiteturas de um modo simples, com blocos que representam componentes, que
podem estar dentro de caixas, que acoplam subcomponentes. As setas representam a comunicação dos dados de
controle entre os componentes, conforme a direção da seta.
Os blocos nem sempre são tão simples ou podem ser representativos do componente, como um banco de dados,
um computador, dentre outros, isto é, podem ter formas e características diferentes, o banco de dados, por
muitas vezes, é representado por um cilindro, o computador por uma imagem, etc. O importanteé que ele seja
claro, facilite a discussão do projeto entre os e seja útil para documentar um projeto de arquitetura stakeholders
com seus componentes, interfaces e conexões (SOMMERVILLE, 2011).
Portanto, a importância da arquitetura de software é vistam na medida em que contribui diretamente para o
desempenho, robustez, capacidade de distribuição e manutenibilidade de um sistema de .software
2.1.1 Padrões de arquitetura
De acordo com Sommerville (2011), a partir do momento em que são identificados os principais componentes
do sistema de e suas interfaces, é possível organizar os componentes, utilizando um padrão desoftware 
arquitetura, tal como um modelo cliente-servidor, ou em camadas. Inicialmente, os padrões de arquitetura foram
- -5
arquitetura, tal como um modelo cliente-servidor, ou em camadas. Inicialmente, os padrões de arquitetura foram
propostos como estilos de arquitetura, termo que ainda é usado por Pressman (2011). De modo geral, um
padrão de arquitetura representa, de fato, um estilo adotado para projetar a arquitetura de um .software
Desse modo, os padrões são formas de apresentar, compartilhar e reusar o conhecimento sobre sistemas de
software, conforme afirma Sommerville (2011). Esse padrão se trata de uma descrição abstrata, estilizada, de
boas práticas experimentadas e testadas em diferentes ambientes e sistemas e, por isso, para se tornar um
padrão, significa que essa arquitetura foi bem-sucedida em sistemas já implementados. Certamente, esse padrão
deve descrever quando ele é mais adequado e outros detalhes que abordem pontos fracos e fortes.
2.1.2 Arquitetura cliente-servidor
Essa arquitetura é utilizada para sistemas distribuídos, conforme a descrição do quadro a seguir.
CASO
Você contratou um arquiteto para projetar sua futura casa. Como será possível relacionar os
seus desejos com as especificidades das técnicas de e padrões arquiteturais? Primeiro, édesign
preciso haver uma comunicação entre você e o arquiteto. Você precisa dar uma ideia de como a
casa será. Algo como: casa moderna, de dois andares, com o pé direito alto. Você pode dar
todos os detalhes que você deseja, de modo que vocês tenham um “estilo” do que deve ser
feito.
É assim que o arquiteto, com seus conhecimentos e experiência, vai entender o padrão de casa
que você deseja, e vai aliar com outros parâmetros, tais como custos, área do terreno, etc.
Portanto, as suas ideias pré-definidas são úteis como um para que sua casa seja template
construída. O mesmo acontece com os padrões de arquitetura de projeto de , devendosoftware
haver, inicialmente, uma comunicação entre cliente e analistas de sistemas, para, então, alinhar
tudo o que é possível, da melhor forma.
Em se tratando de padrão de arquitetura, isso vai ser fundamental para que o projeto siga
sendo implementado da forma como ele deve, e o desejo do cliente seja transformado em 
, isto é, deixe de ser uma representação e passe a ser algo concreto. Do mesmo modo,software
se o arquiteto projetar sua casa com algum detalhe equivocado, quando ficar pronta, pode ser
um enorme problema corrigir essa falha.
- -6
Quadro 1 - Descrição e detalhamento de como o padrão cliente-servidor funciona, com vantagens e desvantagens 
em utilizá-lo.
Fonte: SOMMERVILLE, 2011, p. 113.
Sendo assim, entendemos que essa arquitetura é organizada como um conjunto de serviços e servidores que são
atrelados e clientes que acessam e usam esses serviços. Na arquitetura cliente-servidor, temos três principais
componentes, segundo Sommerville (2011), que listamos a seguir, confira clicando nos itens.
• 
Um conjunto de servidores que proporcionam serviços para outros componentes, tais como
servidores de impressão, de arquivos e de compilação de linguagens de programação.
• 
Um conjunto de clientes que chamam os serviços oferecidos pelos servidores, que utilizam
instâncias de programas em computadores diferentes e de modo simultâneo.
• 
Uma rede que possibilita que os clientes acessem esses serviços, implementados como sistemas
distribuídos, que são conectados por meio de protocolos de internet.
Acompanhe, na figura abaixo, uma arquitetura cliente-servidor para uma biblioteca de filmes e fotos.
•
•
•
- -7
Figura 2 - Uma arquitetura cliente-servidor para uma biblioteca de filmes e fotos.
Fonte: Elaborada pela autora, baseada em SOMMERVILLE, 2011, p. 114.
O exemplo do sistema baseado no modelo cliente-servidor é multiusuário e conta com a conexão com a internet,
para fornecimento de uma biblioteca de filmes e fotos. Diversos servidores funcionam como gerenciadores e
apresentam os diferentes tipos de mídia. Como os vídeos podem ser compactados e descompactados em
diferentes formatos e as fotos devem continuar em alta resolução, é plausível que sejam mantidos em servidores
separados. Já o programa cliente se trata apenas de uma interface de usuário integrada constituída de um
navegador de internet que dá acesso aos serviços.
O fato de ser uma arquitetura distribuída, permite que a utilização seja feita por sistemas em rede com vários
processadores distribuídos. Isso facilita a alteração de quantidades de servidores, bem como a integração e
atualização, feita de forma simples, de modo que não atrapalhe outras partes do sistema.
VOCÊ QUER LER?
Pressman (2011) elenca também as arquiteturas de fluxo de dados, as centralizadas em dados,
as de chamadas e retornos e a orientada a objetos. Já Sommerville (2011) descreve também a
arquitetura de repositório e a arquitetura de duto e filtro. É importante a leitura dessas
arquiteturas, pois, de acordo com o seu projeto, a arquitetura cliente-servidor ou em camadas,
descritas aqui, podem não se adequar.
- -8
2.1.3. Arquitetura em camadas
Como já mencionado, organizamos os componentes conforme padrões de arquitetura. Descrevemos a
arquitetura cliente-servidor e, agora, abordamos sobre a arquitetura em camadas. A figura a seguir demonstra
um exemplo da arquitetura em quatro camadas.
Figura 3 - Exemplo de um modelo de arquitetura representado em quatro camadas.
Fonte: Elaborada pela autora, baseada em SOMMERVILLE, 2011, p. 111.
Na camada mais baixa, temos um de apoio, que, geralmente, se trata dos bancos de dados e dossoftware
sistemas operacionais. A camada imediatamente acima conta com os componentes com relação às
funcionalidades da aplicação e os componentes utilitários que são utilizados por outros componentes da
aplicação. A próxima camada trata do gerenciamento de interface com o usuário, proporcionando a autenticação
e autorização de usuário, enquanto a camada superior fornece recursos de interface com o usuário.
Esse número de camadas é específico para determinados sistemas como, por exemplo, um sistema de bibliotecas
exemplificado na figura a seguir. Dessa forma, é possível que camadas sejam subdivididas em subcamadas,
conforme a necessidade.
- -9
Figura 4 - Modelo de arquitetura de um sistema de biblioteca, chamado LIBSYS, exemplificando a adição de 
subcamadas.
Fonte: Elaborada pela autora, baseada em SOMMERVILLE, 2011, p. 111.
O sistema LIBSYS de biblioteca permite o controle do acesso eletrônico de um grupo de bibliotecas universitárias
aos materiais com direitos autorais. A camada inferior se refere aos bancos de dados de cada biblioteca.
A arquitetura em camadas, conforme afirma Sommerville (2011), permite a separação e independência,
facilitando as alterações de forma individual, pois as camadas são separadamente organizadas e uma camada
depende apenas dos recursos e serviços que são oferecidos pela camada imediatamente abaixo. Isso significa
que é possível desenvolver o sistema de forma incremental, pois, ao passo que uma camada é desenvolvida,
algumas funções e serviços oferecidos por essa camada podem ser validados pelos usuários. O padrão de
arquitetura em camadas pode ser apresentado de acordo com o quadro a seguir.
VOCÊ SABIA?A partir do momento que o arquiteto ou engenheiro de conhece os requisitos e assoftware
restrições do sistema de , é possível realizar uma combinação de padrões desoftware
arquitetura que melhor se adequa ao resultado da análise dos requisitos. Além disso, nada
impede que o profissional adapte os padrões, de modo a melhor se encaixar em um projeto
específico, como um todo.
- -10
Quadro 2 - Descrição e detalhamento do padrão de arquitetura em camadas, com vantagens e desvantagens.
Fonte: Elaborado pela autora, baseada em SOMMERVILLE, 2011, p.110.
Seguindo o mesmo raciocínio de padrões de arquitetura, a seguir, vamos estudar os padrões de projeto,
ressaltando a importância deles para deixar o desenvolvimento do mais eficiente e eficaz, considerandosoftware
as características para resolução de problemas.
2.2 Padrões de projeto
Se projetar um e orientado a objetos já não é uma tarefa trivial, projetar um que seja reutilizávelsoftwar software
é ainda mais complexo. É preciso identificar objetos adequados ao projeto, fatorá-los em classes no nível correto
de granularidade, definir as interfaces das classes, as hierarquias de herança e estabelecer as relações-chave
entre eles (GAMMA , 2000).et al.
A primeira ideia de padrão de projeto surgiu com o pesquisador Christopher Alexander, que definiu que cada
padrão descreve um problema em nosso ambiente e o cerne da sua solução, de tal forma que seja possível
utilizar essa solução muitas outras vezes, porém de formas diferentes, isto é, em contextos diferentes
(ALEXANDER , 1977 apud SOMMERVILLE, 2011).et al.
- -11
2.2.1 Problemas e padrões de projeto
A ideia dos padrões de projeto é, justamente, reaproveitar os planejamentos e as soluções, de forma que
problemas que já ocorreram em projetos anteriores, sejam resolvidos por meio de soluções já conhecidas. Por
isso, o projeto deve ser específico para o problema a se resolver, mas, também, precisa ser genérico o bastante
para atender problemas e requisitos futuros.
O paradigma-alvo na utilização de padrões de projeto é a orientação a objetos, de forma que esses objetos sejam
fundamentais para a decomposição de um sistema em objetos. Como devemos considerar encapsulamento,
granularidade, dependência, flexibilidade, desempenho, reutilização, evolução e etc., essa tarefa não trivial
(GAMMA , 2000).et al.
Os melhores projetistas não resolvem os problemas a partir de princípios básicos, ou do zero, pois o ideal é
aproveitar, isto é, reutilizar soluções que foram utilizadas anteriormente e funcionaram pra projetos anteriores,
com características semelhantes, por vezes, idênticas (GAMMA ., 2000). No entanto, para que um projetoet al
possa ser reaproveitado, ele deve ser devidamente compreendido e documentado.
Prêmio Tsutomu Kanai (2003), Medalha John von Neumann IEEE (2015).
Portanto, um padrão de projeto é uma solução utilizada com frequência para um problema em um determinado
contexto, mesmo que os projetos sejam em áreas diferentes. Desse modo, um contexto quer dizer um ambiente,
uma circunstância no mundo real. O problema é o que precisa ser analisado e investigado para se chegar na
solução, ou seja, na resposta ao problema. Tenha em mente que um padrão se constitui na medida e, que é
reutilizado nessas condições, pois se ele não puder, não será um padrão.
2.2.2 Elementos essenciais em standard de projeto
Além da qualidade de ser reutilizável, para um padrão se firme, precisa-se de quatro elementos essenciais, por
meio de Gamma . (2000). Para conhecê-los, clique nas abas abaixo.et al
Nome
Dar nome aos padrões, em uma ou duas palavras, permite que se crie uma referência para descrever o problema
do projeto, suas soluções e as consequências. Torna mais fácil a comunicação sobre tudo que envolve o projeto e
entre todas as pessoas envolvidas.
VOCÊ O CONHECE?
O programador James Gosling é o criador da linguagem de programação Java. Gosling ficou
conhecido como o pai da linguagem Java e por essa criação, foi eleito para a Academia Nacional
de Engenharia dos Estados Unidos A linguagem de programação Java é uma das mais
utilizadas atualmente. Ela proporciona a criação de projetos simples, porém robustos,
portáteis e dinâmicos. Com isso os projetos podem obter alto desempenho.
- -12
Problema
Explica o problema no seu devido contexto, para que seja possível aplicar o padrão, o que pode incluir uma lista
de condições a serem satisfeitas para que justifique a aplicação do padrão.
Solução
Descreve os elementos que compõe o padrão de projeto, seus relacionamentos, suas responsabilidades e
colaborações. Isso significa que descreve um padrão, tal como um gabarito que possibilita a aplicação em muitas
situações diferentes e não a uma implementação em específico. Especifica como um arranjo geral de classes e
objetos resolve o problema.
Consequências
São os resultados e análises das vantagens e desvantagens da aplicação do padrão. Elas são muito importantes
para que sejam avaliadas as alternativas de projetos e para a compreensão dos custos e benefícios da aplicação
do padrão. Essa avaliação inclui aspectos sobre flexibilidade, extensibilidade ou portabilidade do sistema.
É importante ressaltar que padrões de projeto não são projetos em si, isto é, padrões não são listas e tabelas que
podem ser codificadas em classes e reutilizadas assim como estão, eles servem de base para o seu projeto que
será mais específico (GAMMA ., 2000). Também não significa que os padrões são projetos complexos, deet al
domínio específico para uma aplicação inteira ou subsistema. “Um padrão de projeto aborda descrições de
objetos e classes comunicantes que precisam ser personalizadas para resolver um problema geral de projeto
num contexto particular” (GAMMA, 2000, p. 20). Assim, o padrão identifica as classes e instâncias participantes,
seus papéis, colaborações e a distribuição de responsabilidades, focando em um problema de projeto orientado a
objetos e descrevendo em que situação pode ser aplicado, considerando as restrições e consequências, os custos,
benefícios e inclusive, os exemplos de código.
2.2.3 Principais padrões de projetos
Adotar padrões de projeto torna a reutilização mais fácil, uma vez que os projetos e arquiteturas reutilizadas
tenham sido testadas, avaliadas e bem-sucedidas, trazendo eficiência e qualidade para a construção do software.
Existe um catálogo de padrões, conforme define Gamma (et al., 2000), divididos em categorias de criação, de
estrutura e comportamentais. Como profissional, você pode reutilizar esses padrões conforme a necessidade e,
inclusive, adaptá-los. Os 23 padrões e respectivas intenções são apresentados no quadro a seguir.
- -13
- -14
- -15
Quadro 3 - O catálogo de padrões de projeto oferece opções de padrões de projeto para serem utilizados 
conforme necessidade.
Fonte: GAMMA et al., 2000, p. 24.
Assim sendo, a importância da existência dos padrões se dá pelo fato de que são soluções testadas e aprovadas,
uma vez que os catálogos incluem somente padrões já devidamente testados e bem-sucedidos em vários
projetos.
Sendo o padrão consolidado, significa que ele foi descrito e documentado adequadamente para permitir sua fácil
reutilização. Entretanto, os padrões não auxiliam nas estratégias, isto é, não te diz porquê, ou quando utilizar,
mas sim, com o que, e como utilizar. Isso reforça a ideia de que você, como profissional, deve entender quando, e
por que escolher determinado padrão para utilizar especificamente em seu projeto.
VOCÊ QUER LER?
Para entender detalhes de cada padrão, consulte Gamma et al. (2000), a partir do capítulo três.
Os autores detalham cada padrão, descrevendo a intenção, a motivação, a aplicabilidade, a
estrutura, as colaborações, as consequências, a implementação, um exemplo de código, usos
conhecidos e padrões relacionados.
- -16
2.3 Gerenciamento de Configuração
As mudanças não são apenas duranteo desenvolvimento do software, como também estão em uso pelos
usuários. As mudanças podem ocorrer por vários motivos, como podemos ver na lista de Sommerville (2011),
clicando nas setas.
 
Falhas nos sistemas de softwares.
 
Requisitos que mudam ao longo do desenvolvimento, ou que devem ser acrescentados posteriormente, mesmo
que o já esteja em uso.software
 
Necessidade de adaptação do , devido a atualizações de e plataformas.software hardware
 
A concorrência melhora seu software, então você precisa se adaptar ao mercado.
O Gerenciamento de Configuração (GC) não trabalha apenas com o conceito de mudanças, mas, sim, com as
políticas, processos e ferramentas para o gerenciamento de diversos tipos de mudanças nos sistemas de software
. Os são desenvolvidos em versões e cada versão deve ser gerenciada conforme o evolui esoftwares software
várias versões estão em uso e suscetíveis a mudanças. É preciso saber como gravar e processar propostas de
mudanças, em como definir quais componentes precisam ser alterados, em como gerenciar as diversas versões
em desenvolvimento e em uso e em como serão distribuídas aos clientes. Não controlar os processos e versões,
pode trazer grandes problemas, tal como modificar a versão errada do sistema ou, mesmo, perder informações
importantes sobre as versões corretas. Além disso, as informações são úteis para comunicação entre os
desenvolvedores que podem estar em locais diferentes (SOMMERVILLE, 2011).
Existem várias ferramentas que auxiliam nesse processo de GC, pois é preciso trabalhar com muitas informações
ao mesmo tempo. Essas ferramentas auxiliam desde a acompanhar as falhas, até conjuntos de ferramentas
integradas que auxiliam em todas as atividades em GC. São exemplos dessas ferramentas: Bugzilla, Trac, Jira e
IBM Rational ClearQuest. Todo esse processo de GC faz parte do gerenciamento de qualidade, pois esses dois
processos dependem um do outro.
2.3.1 Gerenciamento de versões
As versões devem ter um processo de acompanhamento para serem gerenciadas junto com as versões dos
componentes do e os sistemas aos quais esses componentes pertencem. Cada versão não devesoftware
interferir na outra, e o cuidado para essa questão deve demandar uma atenção maior quando às mudanças que
VOCÊ QUER VER?
Quer aprender a usar o padrão de projeto chamado Estratégia? Com ele, você pode trocar os
algoritmos de uma classe em tempo de execução, criando flexibilidade e facilidade de
manutenção ao seu código. Acesse o vídeo (NORMANDES JUNIOR, 2015) para saber mais sobre
isso: < >.https://www.youtube.com/watch?v=rC296hM-S4g
- -17
componentes do e os sistemas aos quais esses componentes pertencem. Cada versão não devesoftware
interferir na outra, e o cuidado para essa questão deve demandar uma atenção maior quando às mudanças que
são feitas por diferentes desenvolvedores, pois, se João está modificando um componente C1 e C2, enquanto
Joana modifica C2 e C3, primeiro que ambos estão modificando algo em C2, aumentando a probabilidade de
acontecer um problema no código, segundo, que pode ser que C3 tenha impacto em C1. Dessa forma, é possível
pensar no processo de gerenciamento de versões de acordo com e s, como apresenta a figura acodelines baseline
seguir.
Figura 5 - Representação de codelines e baselines na composição de um sistema e suas versões.
Fonte: SOMMERVILLE, 2011, p. 482.
De acordo com Sommerville (2011), um baseline representa um conjunto de componentes que foram
devidamente aprovados, que compõe o sistema. Já os representam implementações de novascodelines
funcionalidades por diferentes profissionais em paralelo, independentemente, e representa um conjunto de
versões de um componente e outros itens de configuração dos quais esse componente depende. Essas codelines
são encaminhadas para cada projeto e diversos desenvolvedores, sendo que a primeira é a ,codeline mainline
que é uma sequência de que representam diferentes versões do sistema.baselines
O sistema de controle de versões possibilita que os componentes do sistema de software sejam evoluídos de uma
forma disciplinada, concorrente e distribuída. Assim, evitam-se perdas e sobreposições de mudanças durante o
desenvolvimento ou manutenção do componente. São exemplos de ferramentas que chamamos de sistemas de
gerenciamento de versões: Subversion, Microsoft Visual Source Safe, CVS e IBM Rational ClearCase. Esses
sistemas fornecem vários recursos, tais como a identificação de versão e , gerenciamento derelease
armazenamento, registro de histórico de alterações, desenvolvimento independente e suporte a projetos
(SOMMERVILLE, 2011).
2.3.2 Gerenciamento de mudanças
Devido às necessidades de mudanças já citadas anteriormente, é preciso garantir que essas mudanças sejam
aplicadas ao sistema de uma forma organizada, que permita um controle e isso é possível com o uso de
ferramentas. Assim, o gerenciamento de mudanças garante que a evolução do sistema seja um processo
organizado e supervisionado, de modo que as prioridades das mudanças sejam respeitadas.
Segundo Sommerville (2011), o gerenciamento de mudanças prevê uma análise de custos e benefícios das
- -18
organizado e supervisionado, de modo que as prioridades das mudanças sejam respeitadas.
Segundo Sommerville (2011), o gerenciamento de mudanças prevê uma análise de custos e benefícios das
mudanças que são solicitadas. Dessa maneira, é preciso aprovar essas mudanças de acordo com critérios
estabelecidos, que incluem custos e análise de viabilidade. Assim, esse processo de gerenciamento de mudanças
se dá ao passo que um cliente (qualquer stakeholder que não seja parte da equipe de desenvolvimento)
preenche e envia uma descrição de uma solicitação de mudança (do inglês, ou apenas CR). AChange Request
figura a seguir mostra o fluxo do processo de gerenciamento de mudanças.
Figura 6 - – O funcionamento do processo de gerenciamento de mudanças desde a solicitação até a 
implementação da mudança e fechamento do chamado.
Fonte: SOMMERVILLE, 2011, p. 478.
Essa solicitação pode ser tanto um relatório de falha como a solicitação de adição ou alteração de uma
funcionalidade. É preenchido, então, um formulário de solicitação de alteração, em que são registradas todas as
decisões tomadas em cada estágio do processo, sendo o da mudança registrado nesse formulário. Alémstatus
disso, o formulário registra as recomendações pertinentes à mudança, a estimativa de custos e as datas de
quando a mudança foi solicitada, aprovada, implementada e validada. O desenvolvedor também tem um espaço
nesse formulário para registrar como a alteração será realizada. O quadro a seguir, mostra um exemplo de
formulário.
- -19
Figura 7 - Formulário de solicitação de mudança parcialmente concluído.
Fonte: SOMMERVILLE, 2011, p. 479.
Os fatores que Sommerville (2011) descreve como importantes para avaliar a aprovação, ou não, de uma
mudança estão elencados na sequência. Clique nos itens e confira.
• 
As consequências de não fazer a mudança
Se for uma solicitação de mudança devido a uma falha, deve ser considerada a gravidade dessa
falha, se ela causa interrupção do sistema, por exemplo, é grave. Por outro lado, se estiver
relacionada a alguma cor não especificada, a correção dessa falha pode ser adiada.
• 
Os benefícios da mudança
Analisar a quem a mudança vai beneficiar, pois, às vezes, pode ser benefício somente para quem
solicitou a mudança. A mudança deve, em prioridade, atender a todos os usuários.
• 
O número de usuários afetados pela alteração
É necessário ponderar se parte dos usuários serão afetados negativamente com as mudanças
solicitadas.
• 
Os custos de se fazer a mudança
Uma mudança que afeta muitos componentes, por exemplo, pode ocasionar muitas outras
mudanças e, consequentemente, custos que podem não ser assumidos no momento.
• 
O ciclo de release de produto
Caso uma versão seja liberada recentemente, aquela mudançaque acaba de ser requerida, deve
ser analisada e possivelmente implementada somente no próximo release planejado.
Embora as solicitações de mudanças sejam reportadas pelos clientes, por meio de páginas web ou , pore-mail
exemplo, os formulários são preenchidos e as mudanças solicitadas pela equipe de suporte. Por vezes, esse
processo de solicitação de mudança, em um projeto menor, pode ser menos burocrático, no entanto, deve
•
•
•
•
•
- -20
processo de solicitação de mudança, em um projeto menor, pode ser menos burocrático, no entanto, deve
sempre se registrado.
2.3.3 Gerenciamento de releases
Conforme descreve Sommerville (2011), um do sistema de nada mais é do que uma versãorelease software
pronta, que é distribuída para o cliente, conforme planejamento. Eles podem ser classificados como principais,
que disponibilizam novas funcionalidades importantes e também como menores, ao passo que aplicam
melhorias, ou ainda, os de revisão, que apenas corrigem falhas, isto é, aplicam mudanças. As versões dereleases
sistemas operacionais que são disponibilizados são, na verdade, . Por exemplo, Windows XP, Windows 7,releases
Windows 10.
Para conhecer outros aspectos relacionados a esse tema, clique nas setas abaixo.
Softwares customizados, sistemas embutidos, estes devem ter atenção especial, pois pode ser produzidos um 
 diferente para cada cliente em específico.release
É preciso saber gerenciar todos os . Há a possibilidade também de que um release opere no cliente porreleases
muito tempo e, quando é preciso ser recriado e melhorado no futuro, será necessário que haja uma
documentação consistente.
E quando falamos em documentação, não se trata apenas de comentar códigos-fonte, mas também gravar as
versões dos componentes dos códigos-fonte, manter cópias dos arquivos de código-fonte executáveis
correspondentes e todos os dados e arquivos de configuração.
Também é necessário gravar as versões do sistema operacional, bibliotecas, compiladores e outras ferramentas
eventualmente utilizadas durante a construção do (SOMMERVILLE, 2011).software
O planejamento da distribuição dos deve ser bem organizado, não só quanto à qualidade, como tambémreleases
em questão de tempo e custos.
Sommerville (2011) elenca alguns fatores que influenciam na decisão de quando lançar um novo release de um
sistema, conforme vemos na tabela a seguir.
- -21
Quadro 4 - É importante observar os diferentes fatores que influenciam o planejamento de release de sistema.
Fonte: SOMMERVILLE, 2011, p. 489.
Ao compreender esses fatores, também devemos entender que um não se trata somente de um código release
executável, ele pode incluir arquivos guias de como o deve ser configurado para poder ser instalado;release
arquivos de dados contendo, por exemplo, mensagens de erro; um programa de instalação para auxiliar a
instalação do sistema no -alvo; uma documentação eletrônica e em papel, que descreve o sistema; e umhardware
planejamento de publicidade para esse (SOMMERVILLE, 2011).release
- -22
2.4 Integração de sistemas
Com o decorrer do tempo e com o avanço tecnológico, diversas empresas passaram a adquirir vários sistemas
com o objetivo de atender às necessidades técnicas e informatizadas do seu negócio. Isso motivou o mercado de
TI a desenvolver novos conceitos, metodologias e direcionados a integrar sistemas. Integrar sistemas, significa
que um ou mais sistemas compartilham o mesmo código, a mesma interface ou, até, o mesmo banco de dados. No
entanto, cada módulo ou parte do sistema pode funcionar como uma solução, mas que ao serem integrados,
juntos, se tornam um único sistema, com uma visão unificada com todos serviços e funcionalidades (CARVALHO,
2001).
2.4.1 Integração de sistemas
Na prática, uma empresa pode contratar diferentes para atender as suas necessidades. Por exemplo,softwares
um para o departamento de tecnologia, outro para departamento de pessoas e outro parasoftware
departamento de processos, conforme a figura a seguir.
Figura 8 - Sistemas integrados relacionam pessoas, processos, informações e tecnologias.
Fonte: arka38, Shutterstock, 2018.
Confira, a seguir, um caso prático que demonstra a importância da integração de sistemas, os benefícios e a
agilidade que isso pode trazer dentro de uma organização.
https://cdnapisec.kaltura.com/p/1972831/sp/197283100/embedIframeJs/uiconf_id/30443981/partner_id
/1972831?iframeembed=true&playerId=kaltura_player_1547283172&entry_id=1_ofr33omi
No entanto, para facilitar e padronizar sua utilização, a integração desses sistemas se faz necessário com o
objetivo de unificar seu sistema para atender a todos seus usuários em um único sistema. Com isso, caso a
empresa necessite futuramente de uma nova funcionalidade sistêmica, ela pode adquirir ou até desenvolver
internamente um componente e integrar com o sistema já existente. Com os sistemas integrados, os ganhos
estão diretamente relacionados com a produtividade, reuso, colaboração, agilidade e unificação de todo o
- -23
estão diretamente relacionados com a produtividade, reuso, colaboração, agilidade e unificação de todo o
processo e operação sistêmica. A integração também é uma das alternativas responsáveis por otimizar e
simplificar a gestão e compartilhamento de informações dentro de uma organização (SUMMER, 2004).
Vale ressaltar que, para garantir uma integração funcional e que atenda aos requisitos de negócio, é importante
planejar quais os meios que serão necessários para realizar a comunicação entre os sistemas que serão
integrados.
2.4.2 Meios de integração
Sabemos que integrar os sistemas é de suma importância para as empresas, no entanto, por onde começar? O
que devemos fazer? Podemos integrar todo tipo de sistemas? Quais são os meios de integração? Clique na aba
abaixo e confira a resposta para essas questões.
Integração
Atualmente, o maior desafio para integração de sistemas está na maneira como estes foram
desenvolvidos. Para isso, é necessário entender a arquitetura do sistema, seu projeto, sua
implementação e definir metodologias e padrões, afim de tornar possível a integração. Muitos
sistemas podem possuir restrições para uma simples integração, no entanto, softwares
desenvolvidos com uma mesma linguagem, podem possuir maior facilidade de integração
(HOHPE; WOOLF, 2003).
Existem diversos meios, técnicas e ferramentas de integração de sistemas. Para decidir qual o melhor meio e
estratégia de integração, se faz necessária uma equipe especializada de integradores de sistemas. Esses
profissionais devem estudar, planejar e implementar a melhor forma de integração sistêmica, de acordo com as
especificações e limitações de cada componente integrado.
2.4.3 Arquitetura e projetos de integração
Como vimos, não existe a melhor ferramenta ou técnica de integração, mas sim, qual mais se adequa ao negócio,
à arquitetura e ao projeto de integração, definido pelos profissionais responsáveis pela integração entre os
sistemas.
Durante a análise da integração, o profissional deverá observar qual a arquitetura de cada componente
sistêmico, para definir quais técnicas são mais compatíveis com o planejamento de integração.
A arquitetura e o projeto de integração podem ser definidos seguindo alguns níveis de integração (HOHPE;
WOOLF, 2003). Clique nas abas abaixo e confira quais são eles.
•
Primeiro nível
Acontece por meio da entrada de dados dos processos humanos, por isso é com funcionalidade
menor e mais propícia a erros de integração.
•
Segundo nível
Uma ferramenta intermedia a comunicação entre um ou mais sistemas.
•
Terceiro nível
Um sistema se comunica com o outro, em que um exporta os dados e o outro exporta.
•
•
•
•
•
- -24
Quarto nível
Os softwares de ERP são um exemplo, utilizados para planejar os recursos das empresas e que
compartilham a mesma base de dados, nesse caso, podem ser dois ou mais sistemas.•
Quinto nível
Os sistemas trocam informações por meio de rotinas proporcionadas pelo sistema de requisição,
integrando os sistemas de modo translúcido, em geral, por meio de uma API.
Com isso, é possível perceber que o trabalho do profissional de TI, em conjunto com a equipe técnica e de gestão,
deve estar em constante comunicação, para que tudo seja analisado da melhor forma, para que os sistemas sejam
integrados para realmente beneficiar o negócio organizacional.
Síntese
Agora que você pôde estudar o que é um projeto de arquitetura, padrões de projeto e gerenciamento de
configuração, você está apto a analisar o quanto esses métodos beneficiam o desenvolvimento de um sistema de 
. Também pudemos constatar que a integração de sistemas é uma realidade no mercado e que tambémsoftware
traz diversos benefícios, não só para a equipe de desenvolvimento, mas principalmente, para os negócios da
empresa.
Neste capítulo, você teve a oportunidade de:
• avaliar a utilidade de adotar padrões de projeto existentes como base, para o desenvolvimento do seu 
projeto, evitando perda de tempo e dinheiro, ao tentar criar algum padrão do zero;
• entender a importância de utilizar métodos de gerenciamento de configurações, a fim de evitar que, ao 
longo do seu ciclo de desenvolvimento, haja desperdício de tempo para corrigir os mais variados tipos de 
erros, que podem ocasionar o insucesso do projeto;
• conhecer o conceito de integração de sistemas, entendendo o quão complexo pode ser integrar sistemas, 
contudo, analisando o quanto pode ser benéfico para todos os envolvidos.
Bibliografia
CARVALHO, J. M. : On & Offline. Lisboa: Edições Sílabo, 2001.e-Business & e-Commerce
GAMMA, E.; : soluções reutilizáveis de orientado a objetos. et al. Padrões de projeto software Porto Alegre:
Bookman, 2000.
HOHPE G.; WOOLF, B. : Designing, Building, and Deploying MessagingEnterprise Integration Patterns
Solutions. Boston: Addison Wesley, 2003.
NORMANDES JUNIOR. Padrão de projeto Strategy - Aula prática. Canal algaworks, YouTube, publicado em 1 de
set. de 2015. Disponível em: . Acesso em: 13/12/2018.<https://www.youtube.com/watch?v=rC296hM-S4g >
PFLEEGER, S. L. Engenharia de software - Teoria e Prática. 2. ed. São Paulo: Pearson Addison Wesley, 2004.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7. ed. Porto Alegre: AMGH, 2011.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Addison Wesley, 2011.
SUMMER, M. Enterprise Resource Planning. Upper Saddle River (NJ): Prentice Hall, 2004.
•
•
•
•
	Introdução
	2.1 Projeto de arquitetura
	2.1.1 Padrões de arquitetura
	2.1.2 Arquitetura cliente-servidor
	2.1.3. Arquitetura em camadas
	2.2 Padrões de projeto
	2.2.1 Problemas e padrões de projeto
	2.2.2 Elementos essenciais em standard de projeto
	Nome
	Problema
	Solução
	Consequências
	2.2.3 Principais padrões de projetos
	2.3 Gerenciamento de Configuração
	2.3.1 Gerenciamento de versões
	2.3.2 Gerenciamento de mudanças
	2.3.3 Gerenciamento de releases
	2.4 Integração de sistemas
	2.4.1 Integração de sistemas
	2.4.2 Meios de integração
	2.4.3 Arquitetura e projetos de integração
	Primeiro nível
	Segundo nível
	Terceiro nível
	Quarto nível
	Quinto nível
	Síntese
	Bibliografia