Projeto de Software - Parte I

Prévia do material em texto

4ºAula
Projeto de software – Parte I
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
•	 entender a importância do Projeto de Software;
•	 saber quais são os modelos que compõem o Projeto de Software;
•	 entender o que é arquitetura de sistema;
•	 conhecer as principais arquiteturas de software.
Olá, pessoal, tudo bem? 
Estamos avançando os nossos estudos sobre a Engenharia 
de Requisitos. Agora, vamos aprender como transformar os 
requisitos do usuário em um sistema programável. Estamos 
falando do Projeto de Software, que trata de maturar o sistema, 
visando à criação de um sistema de boa qualidade.
Nossos estudos sobre Projeto de Software se dividem em 
três aulas. Nesta, veremos como funciona o Projeto de Software 
e o Projeto de Arquitetura. Em seguida, veremos como 
funciona o Projeto de Componentes, Projeto de Interfaces e, 
na aula seguinte, Padrões de Projeto.
Sempre lembrando que estamos a sua disposição para 
eventuais dúvidas.
Vamos lá?
Bons estudos!
Engenharia de Requisitos 26
Seções de estudo
1	-	Definição	de	Projeto	de	Software
2 - Conceitos de Projeto de Software
3 - Modelo de Projeto de Software
4 - Projeto de Arquitetura
1	-	Definição	de	Projeto	de	Software
Nas duas últimas aulas, vocês aprenderam como fazer a 
modelagem dos requisitos do software, criando um modelo 
que tanto os programadores e engenheiros de software os 
stakeholders do sistema entendem. Em alguns casos, o 
modelo de software já pode ser usado para embasar a 
programação do sistema.
Mas, para criarmos um software de qualidade, podemos 
incorporar aspectos técnicos a esse projeto, visando preparar 
o cenário para a construção do sistema, criando um sistema de 
qualidade para todos os envolvidos.
Assim, podemos entender projeto de software (também 
chamado por alguns autores de design de software) como 
o processo de aplicar várias técnicas e princípios com o 
propósito	de	definir	um	processo	ou	sistema,	com	detalhes	
suficientes	 para	 permitir	 sua	 realização	 física.	 Tendo	 como	
meta traduzir requisitos em uma representação de software. 
(PORTELLA, s.d.)
Pressman	 e	 Maxim	 (2016)	 afirmam	 que	 o	 projeto	
de software é um processo interativo por meio do qual os 
requisitos são traduzidos em uma “planta” para a construção 
de software, criando uma representação detalhada do sistema, 
com níveis de abstração cada vez mais baixos a cada nova 
interação.
A imagem a seguir descreve como o projeto de software 
está inserido no contexto de desenvolvimento de software.
Figura 1 - Contexto do projeto de software no procedimento de desenvolvimento 
de software. Fonte: MaSiErO, s.d.
Vamos, agora, descrever como medir a qualidade de um 
projeto de software.
1.1 - qualidade de projeto de 
software
Ao longo das etapas da elaboração do projeto, é feita 
uma revisão da qualidade do projeto, que é avaliada por meio 
de revisões técnicas. McGlaughlin (1991 apud PRESSMAN; 
MAXIM,	2016)	afirma	existir	três	características	(metas)	que	
devem ser levadas em conta para considerar se um projeto é 
bom ou não:
•	 o projeto deve implementar todos os requisitos 
explícitos contidos no modelo de requisitos e deve 
acomodar todos os requisitos implícitos desejados 
pelos envolvidos;
•	 o projeto deve ser um guia legível e compreensível 
para aqueles que geram código e para aqueles 
que testam e, subsequentemente, dão suporte ao 
software;
•	 o projeto deve dar uma visão completa do 
software, tratando os domínios de dados, 
funcional e comportamental do ponto de vista da 
implementação.
Além disso, Pressman e Maxim (2016) citam oito 
diretrizes de qualidade que devem ser levados em conta para 
verificar	se	o	projeto	é	bom	ou	não,	e	alcançáveis	por	meio	
da aplicação de princípios de projeto fundamentais (com 
metodologia sistemática e revisão):
•	 Um projeto deve exibir uma arquitetura que foi 
criada usando estilos ou padrões de arquitetura 
reconhecíveis, seja composta por componentes 
que apresentam boas características de projeto e 
possa ser implementada de uma forma evolutiva, 
facilitando a implantação e testes;
•	 Um projeto deve ser modular; ou seja, o software 
deve ser dividido logicamente em elementos ou 
subsistemas, de modo que seja testar e manter;
•	 Um projeto deve conter representações distintas de: 
dados, arquitetura, interfaces e componentes;
•	 Um projeto deve levar a estruturas de dados 
adequadas às classes a serem implementadas e 
baseadas em padrões de dados reconhecíveis;
•	 Um projeto deve levar a componentes que 
apresentem características funcionais independentes 
(baixo acoplamento);
•	 Um projeto deve levar a interfaces que reduzam a 
complexidade das conexões entre os componentes 
e o ambiente externo (encapsulamento);
•	 Um projeto deve ser obtido usando-se um método 
repetível, isto é, dirigido por informações obtidas 
durante a análise de requisitos de software;
•	 Um projeto deve ser representado usando-se 
uma	 notação	 que	 comunique	 seu	 significado	
eficientemente.
1.2 - Tarefas do processo de projeto 
de software
Durante os nossos estudos, veremos várias técnicas 
que são utilizadas para fazer a transformação de um modelo 
para um projeto de software. Mas, genericamente, as técnicas 
seguem algumas características comuns:
•	 um mecanismo para a transformação do modelo de 
requisitos para uma representação do projeto;
•	 uma notação para representar componentes 
27
funcionais e suas interfaces;
•	 uma	heurística	para	refinamento	e	divisão	e	diretrizes	
para a avaliação de qualidade.
Além disso, os autores Pressman e Maxim (2016) elencam 
uma série de tarefas genéricas que devem ser seguidas para um 
projeto de software:
1. examinar o modelo de domínio de informação e 
projetar estruturas de dados apropriadas para os 
objetos de dados e seus atributos;
2. usar o modelo de análise, selecionar um estilo de 
arquitetura (padrão) apropriado ao software;
3. dividir o modelo de análise em subsistemas de 
projeto e alocá-los na arquitetura:
•	 Certificar-se	 de	 que	 cada	 subsistema	 seja	
funcionalmente coeso;
•	 Projetar interfaces de subsistemas;
•	 Alocar classes ou funções de análise para cada 
subsistema.
4. Criar um conjunto de classes ou componentes de 
projeto:
•	 Transformar a descrição de classes de análise 
para uma classe de projeto;
•	 Verificar	cada	classe	de	projeto	em	relação	aos	
critérios de projeto, considerando questões de 
herança;
•	 Definir	métodos	e	mensagens	associadas	a	cada	
classe de projeto;
•	 Avaliar e selecionar padrões de projeto para 
uma classe ou um subsistema de projeto;
•	 Rever as classes de projeto e revisar quando 
necessário.
5. Projetar qualquer interface necessária para sistemas 
ou dispositivos externos.
6. Projetar a interface do usuário:
•	 Revisar os requisitos da análise de tarefas;
•	 Especificar	 a	 sequência	 de	 ações	 baseando-se	
nos cenários de usuário;
•	 Criar um modelo comportamental da interface;
•	 Definir	objetos	da	 interface	 e	mecanismos	de	
controle;
•	 Rever o projeto de interfaces e revisar quando 
necessário.
7. Conduzir o projeto de componentes:
•	 Especificar	todos	os	algoritmos	em	um	nível	de	
abstração relativamente baixo;
•	 Refinar	a	interface	de	cada	componente;
•	 Definir	estruturas	de	dados	dos	componentes;
•	 Revisar cada componente e corrigir todos os 
erros descobertos.
8. Desenvolver um modelo de implantação.
A seguir, vamos apresentar alguns conceitos de projeto.
2 - Conceitos de Projeto de Software
Nessa seção, vamos apresentar alguns conceitos que são 
empregados no processo de projeto de software.
Abstração
É a capacidade de abstrair detalhes inerentes ao sistema. 
Uma abstração em alto nível tem a maioria dos seus detalhes 
omitidos, se preocupando em apenas o que fazer.Porém, 
uma abstração em baixo nível se preocupa dos detalhes 
da operação a ser feita. Um modelo de software, criado na 
Análise de Requisitos, possui um nível de abstração de alto 
a médio, enquanto que o projeto de software tem um nível 
baixo de abstração.
Em projeto de software, existem dois tipos de abstração: 
Abstração procedural, que aborda uma sequência de 
instruções	que	possuem	uma	função	específica	ou	 limitada,	
ou seja, é apenas a abstração de uma função ou método do 
sistema. Já a abstração de dados é o conjunto de dados com 
o nome que descreve um objeto de dados. Assim, podemos 
dizer que um objeto porta se refere à abstração de dados de 
uma porta e uma função abrir seria uma abstração procedural.
Arquitetura
É a estrutura ou a organização dos componentes de 
programa (módulos), a maneira como esses componentes 
interagem e a estrutura de dados que são utilizados por esses 
componentes. (PRESSMAN; MAXIM, 2016)
Padrões
Durante vários projetos de software, pesquisadores 
encontraram situações de arquitetura que podem resolver 
muitos problemas de software. Essas situações são 
denominadas de Padrões de Projeto. Brad Appleton (apud 
PRESSMAN;	MAXIM,	2016,	p.	233)	define:	“Padrão	é	parte	
do conhecimento consolidado já existente que transmite 
a essência de uma solução comprovada para um problema 
recorrente em certo contexto, em meio a preocupações 
concorrentes”.
Separação por interesses (afinidades)
É um conceito de projeto que prega a divisão de um 
problema complexo em vários trechos a serem resolvidos de 
uma forma independente. É um conceito que se desmembra 
em outros conceitos que veremos a seguir.
Modularidade
Considerado um sinônimo do conceito anterior, é o 
processo da divisão do software em módulos independentes 
do sistema, com o intuito de reduzir a complexidade e os 
custos do sistema.
A modularidade visa um sistema mais fácil de gerenciar, 
mas deve ser usado com parcimônia. Pesquisas recentes 
afirmam	 que	 quanto	 mais	 módulos	 são	 criados,	 o	 custo	
de desenvolvimento diminui, mas o custo para realizar a 
integração desses módulos aumenta, aumentando o custo 
total do software. 
Engenharia de Requisitos 28
Figura 2 - Modularidade e custo de software. Fonte: PrESSMan; MaXiM, 2016, p. 235.
Encapsulamento
É a técnica que faz com que detalhes internos do 
funcionamento dos métodos de uma classe permaneçam 
ocultos para os objetos. Assim, o conhecimento a respeito 
da implementação interna da classe é irrelevante do ponto 
de vista do objeto, pois isso é papel dos módulos (métodos) 
internos da classe. (BALBO, s.d.)
Independência Funcional
Conceito que é obtido pelo resultado direto da separação 
por interesses, da modularidade, dos conceitos de abstração e 
encapsulamento de informações, se refere ao desenvolvimento 
de módulos com uma função “única” (coesão) e com aversão 
à interação excessiva com outros módulos do sistema 
(relacionado ao acoplamento dos módulos do sistema).
Refinamento
É	uma	estratégia	de	projeto,	consistindo	no	refinamento	
sucessivo de níveis de detalhes procedurais, iniciando de um 
nível de abstração mais alto, colocando os detalhes da operação 
da função, chegando a um nível de abstração mais baixo. Em 
outras palavras, consiste na colocação de detalhes do projeto.
Aspectos
É uma representação de um interesse em comum no 
sistema. Esses interesses podem ser separados ou podem 
se	 entrelaçar,	 dependendo	 dos	 requisitos	 que	 definem	 os	
aspectos do sistema.
Para entendermos esse conceito, veja a imagem a seguir. 
As caixas azuis representam as entidades de um hipotético 
sistema de vendas. Nesse sistema, existe a necessidade de 
armazenar todos os objetos (persistência) e do armazenamento 
de um log das operações feitas para auditoria (segurança). 
Esses dois conceitos são aspectos do sistema (representados 
pelos blocos verticais da imagem).
Figura 3 - interesses entre cortantes em um sistema. Fonte: aLLET, s.d.
Como há a necessidade de implantar isso em todas as 
classes do sistema, temos interesses entre cortantes, que ligam 
várias classes do sistema. Normalmente, esses interesses 
seriam implantados em cada classe do sistema, aumentando o 
retrabalho. O ideal seria implantar esses aspectos em métodos 
separados.
Pesquisadores já criaram um novo paradigma para lidar 
com essas situações. É a Programação Orientada a Aspectos 
(POA). Alguns links de apresentação a esse paradigma se 
encontram	no	final	desta	aula.
Refatoração
É o aperfeiçoamento contínuo do sistema, sendo o 
processo de alterar o código fonte de uma maneira que não 
altere seu comportamento externo e ainda melhore a sua 
estrutura interna. É uma técnica disciplinada de limpar e 
organizar o código, e por consequência minimizar a chance de 
introduzir novos defeitos no sistema. É mais intrinsecamente 
ligada a fase de programação do sistema.
Classes de Projeto
Das classes de análise que formam o modelo de classes, 
podemos transformar em um projeto de software. Nesse caso, 
são transformadas em classes de projeto do sistema. Durante 
esse processo de conversão, vários detalhes relacionados à 
implantação são inseridos, criando uma infraestrutura para a 
solução do problema de negócio.
Pressman	e	Maxim	(2016)	classificam	as	classes	de	análise	
em cinco tipos, por meio de seus papéis que desempenham:
•	 Classes de interfaces de usuário:	 define	 as	
abstrações necessárias para o sistema;
•	 Classes de domínio de negócio:	 identificam	os	
atributos e os serviços necessários para implementar 
algum elemento do domínio	 de	 negócio	 definido	
por uma ou mais classes de análise;
•	 Classes de processos: implementam as abstrações 
de baixo nível necessárias para a gestão das classes 
de domínio de negócio;
•	 Classes persistentes: representam repositórios de 
dados que serão utilizados pelo sistema;
•	 Classes de sistema: implementa funções de 
gerenciamento e controle do software que permitem 
ao sistema operar e comunicar com o mundo 
exterior.
Além disso, Arlow e Neustadt (2002 apud PRESSMAN; 
MAXIM, 2016) sugerem que as classes devem ser revistas para 
garantir se estão bem estruturadas. Vejamos esses critérios a 
seguir:
•	 Completa e suficiente: a classe deve ter todos os 
métodos necessários para o seu funcionamento. 
Uma classe Carro, por exemplo, deve ter todos os 
elementos necessários para caracterizar um carro no 
contexto do sistema;
•	 Primitivismo: um serviço implementado por uma 
classe deve ser oferecido por apenas um método, 
exclusivamente;
•	 Alta coesão: para ser considerado como uma classe 
29
coesa, deve ter um conjunto de responsabilidades 
pequeno e focado, e aplica atributos e métodos para 
implementar isso;
•	 Baixo acoplamento: as classes de projeto devem 
se colaborar em um mínimo aceitável, tendo um 
conhecimento limitado das outras classes. Ou 
seja, uma classe deve ter um mínimo possível de 
interações com outras classes. Um sistema com 
acoplamento alto (ou seja, com interações elevadas 
com outras classes) é difícil de construir, testar e 
manter. Na Engenharia de Software existe a Lei de 
Demeter, padrão criado em 1987 por Ian Holland, 
que prega: “Converse apenas com os seus amigos”, 
ou seja, um método deve enviar apenas mensagens 
para classes vizinhas. (ALONSO, 2016)
Projeto para Teste
Pressman	e	Maxim	(2016)	afirmam	que	o	projeto	deve	
ser desenvolvido com partes que sejam possíveis inserir testes 
no sistema, para que seja possível testar e manter o software.
Na próxima seção, vamos apresentar como funciona o 
modelo de projeto de software.
3 - Modelo de Projeto de Software
Assim, vamos a partir de agora, entrar no estudo dos 
componentes de um projeto de software. Ao todo são cinco 
componentes que fazem parte dessa etapa:
•	 Projeto de Dados: cria o modelo de dados em 
umnível	de	abstração	elevado,	sendo	refinado	para	
um modelo que pode ser implementado em um 
computador.	O	projeto	de	dados	tem	influência	na	
arquitetura de software;
•	 Projeto de Arquitetura: representa os dados e 
os componentes de programa necessários para 
construir o sistema. É como se fosse uma planta de 
um software;
•	 Projeto de componentes: descreve completamente 
todos os detalhes internos de um componente de 
software.	Assim,	define	as	estruturas	de	dados	dos	
objetos locais e detalhes dos algoritmos que serão 
executados nos módulos do sistema;
•	 Projeto de Interface:	 se	 encarrega	 de	 definir	 as	
interfaces. Nesse caso não somente as interfaces 
de usuário, incluindo também as interfaces para 
outros sistemas ou elementos externos ao sistema 
e interfaces internas para vários componentes de 
projeto (muito ligado ao projeto de componentes 
de software);
•	 Projeto de Implantação: Indica como os 
subsistemas e a funcionalidade do software serão 
alocados no ambiente computacional físico que 
irá alocar o software. São usados diagramas de 
implantação para descrever o ambiente pela UML.
Agora que você teve um panorama geral dos elementos 
de um projeto de software, vamos estudar o Projeto de 
Arquitetura.
4 - Projeto de Arquitetura
Nós falamos aqui que o projeto de arquitetura de software 
serve para representar a estrutura dos componentes e dos 
dados do sistema a ser programado. Pressman e Maxim (2016) 
complementam	essa	definição:
A arquitetura não é o software operacional. 
É uma representação que nos permite 
(1) analisar a efetividade do projeto no 
atendimento dos requisitos declarados, (2) 
considerar alternativas de arquitetura em um 
estágio em que fazer mudanças de projeto 
ainda é relativamente fácil e (3) reduzir os 
riscos associados à construção do software 
(PRESSMAN; MAXIM, 2016, p. 254)
Sommerville	(2011)	afirma	que	“o	projeto	de	arquitetura	
está preocupado com a compreensão de como o sistema deve 
ser	organizado	e	com	a	estrutura	geral	do	sistema”.	Afirma	que	
essa	etapa	identifica	os	principais	componentes	estruturais	de	
um sistema e os relacionamentos entre eles.
Mas então, por que devo fazer a arquitetura de software? 
Bass	(2003	apud	PRESSMAN;	MAXIM,	2016)	identificaram	
três motivos:
•	 a arquitetura de software fornece uma representação 
que facilita a comunicação entre todos os envolvidos;
•	 a arquitetura destaca desde o início das decisões de 
projeto que terão um profundo impacto no trabalho 
de engenharia de software que se segue;
•	 a arquitetura constitui um modelo relativamente 
pequeno e intelectualmente compreensível de como 
o sistema é estruturado e como seus componentes 
trabalham em conjunto.
4.1 - Estilos de Arquitetura
Existem vários tipos muito utilizados de arquitetura 
que são empregados em muitos projetos de software. Nessa 
seção, vamos detalhar alguns deles.
Arquitetura em Camadas
Esse estilo consiste em organizar o sistema em um 
conjunto de camadas (ou máquinas abstratas para oferecer 
um conjunto de sistemas. É uma maneira de obter separação 
e independência no sistema. Nesse sistema, cada camada 
só depende dos recursos e serviços oferecidos pela camada 
imediatamente abaixo dela.
Essa estratégia apoia o desenvolvimento integral de 
sistemas, pois, quando uma camada é desenvolvida, alguns 
dos serviços podem ser disponibilizados para os usuários do 
sistema.
A seguir, reproduziremos uma imagem com um exemplo 
de arquitetura em camadas, representando um sistema para 
compartilhar arquivos com direitos autorais, e uma tabela 
com algumas notas sobre esse estilo, fornecido por Ian 
Sommerville.
Engenharia de Requisitos 30
Tabela 1 - Situações de uso da arquitetura em camadas
nome arquitetura em Camadas
Descrição organiza o sistema em camadas com a 
funcionalidade relacionada associada a cada 
camada. uma camada fornece serviços à 
camada acima dela; assim, os níveis mais 
baixos de camadas representam os principais 
serviços suscetíveis de serem usados em 
todo o sistema.
Exemplo um modelo em camadas de um sistema 
para compartilhar documentos com direitos 
autorais, em bibliotecas diferentes.
Quando é usado É usado na construção de novos recursos 
em cima de sistemas existentes; quando o 
desenvolvimento está espalhado por várias 
equipes, com a responsabilidade de cada 
equipe em uma camada de funcionalidade; 
quando há um requisito de proteção 
multinível.
Vantagens Desde que a interface seja mantida, permite 
a substituição de camadas inteiras. Recursos 
redundantes (por exemplo, autenticação) 
podem ser fornecidos em cada camada para 
aumentar	a	confiança	do	sistema.
Desvantagens Na prática, costuma ser difícil proporcionar 
uma clara separação entre as camadas, e uma 
camada de alto nível pode ter de interagir 
diretamente com camadas de baixo nível, 
em vez de através da camada imediatamente 
abaixo dela. o desempenho pode ser um 
problema	por	causa	dos	múltiplos	níveis	de	
interpretação de uma solicitação de serviço, 
uma vez que são processados em cada 
camada.
Fonte: SOMMErViLLE, 2011, p. 110.
Figura 4 - arquitetura genérica em camadas. Fonte: SOMMErViLLE, 2011, p. 111.
Figura 5 - Exemplo de arquitetura em Camadas, implantado em um sistema para 
bibliotecas. Fonte: SOMMErViLLE, 2011, p. 111.
Arquitetura de Repositório
Esse é um estilo que funciona em sistemas que tem como 
intuito compartilhar grandes quantidades de dados. Ele organiza 
todos os sistemas em torno de um grande repositório de dados. 
Sommerville (2011) relata que esse estilo pode ser usado por 
aplicações de comando e controle, sistemas CAD e ambientes 
de desenvolvimento de software (contexto a qual representa o 
exemplo	 reproduzido	na	Figura	X).	Assim,	podemos	definir	
essa arquitetura como “um conjunto de componentes que 
podem compartilhar dados”. (SOMMERVILLE, 2011, p. 111)
Porém, apesar das vantagens, o mesmo autor relata que 
certas restrições devem ser tomadas: 
A organização de ferramentas em torno 
de um repositório constitui uma maneira 
eficiente	de	compartilhar	grandes	quantidades	
de dados. Não há necessidade de transmitir 
dados explicitamente de um componente para 
outro. No entanto, os componentes devem 
operar em torno de um modelo aprovado de 
repositório de dados. Inevitavelmente, esse 
é um compromisso entre as necessidades 
específicas	de	cada	ferramenta,	e	pode	ser	difícil	
ou impossível integrar novos componentes 
se seus modelos de dados não se adequam 
ao esquema acordado. Na prática, pode ser 
difícil distribuir o repositório por meio de 
uma série de máquinas. Embora seja possível 
a distribuição de um repositório logicamente 
centralizado, pode haver problemas com 
a redundância e inconsistência de dados. 
(SOMMERVILLE, 2011, p. 112)
Tabela 1 - Situações de uso da arquitetura de repositório
nome arquitetura de repositório
Descrição Todos os dados em um sistema são 
gerenciados em um repositório central, 
acessível a todos os componentes do sistema. 
os componentes não interagem diretamente, 
apenas por meio do repositório.
31
Exemplo um iDE em que os componentes usam um 
repositório de informações sobre projetos de 
sistema. Cada ferramenta de software gera 
informações	 que	 ficam	 disponíveis	 para	 uso	
por outras ferramentas.
Quando é usado Você deve usar esse padrão quando tem 
um sistema no qual grandes volumes de 
informações são gerados e precisam ser 
armazenados por um longo tempo. Você 
também pode usá-lo em sistemas dirigidos 
a dados, nos quais a inclusão dos dados no 
repositório dispara uma ação ou ferramenta.
Vantagens os componentes podem ser independentes 
— eles não precisam saber da existência de 
outros componentes. As alterações feitas a 
um componente podem propagar-se para 
todos os outros. Todos os dados podem 
ser gerenciados de forma consistente(por 
exemplo, backups feitos ao mesmo tempo), 
pois tudo está em um só lugar.
Desvantagens O	 repositório	 é	 um	 ponto	 único	 de	 falha,	
assim, problemas no repositório podem afetar 
todo	 o	 sistema.	 Pode	 haver	 ineficiências	 na	
organização de toda a comunicação através do 
repositório. Distribuir o repositório através de 
vários computadores pode ser difícil.
Fonte: SOMMErViLLE, 2011, p. 112. adaptado.
Figura 6 - Exemplo de arquitetura de repositório, voltado para um sistema iDE. 
Fonte: SOMMErViLLE, 2011, p. 112.
Arquitetura Cliente-Servidor
Enquanto que a arquitetura de repositório se preocupa 
com a estrutura estática, a arquitetura cliente-servidor 
preocupa com a organização em tempo de execução do 
sistema. Ela consiste nos seguintes elementos:
•	 um conjunto de servidores oferece serviços para 
outros componentes do sistema. Podemos citar 
como exemplo, um servidor Web, que disponibiliza 
uma página para ser acessada via internet ou um 
servidor de Banco de Dados;
•	 um conjunto de clientes podem usar os serviços 
dos servidores, executando várias instâncias de 
um programa cliente em vários computadores 
diferentes. Para acessar os servidores, os clientes 
podem ter que saber os nomes ou os IPs dos 
servidores, mas o servidor não precisa conhecer a 
identidade do cliente na maioria dos casos;
•	 ligando os clientes aos servidores, temos uma 
rede. Geralmente sistemas que funcionam nessa 
arquitetura funcionam através de protocolos de 
Internet (HTTP, por exemplo).
•	 basicamente, um cliente solicita uma requisição ao 
servidor e aguarda a resposta. Às vezes, o cliente e o 
servidor podem ser a mesma máquina.
Sommerville (2011) relata que a principal vantagem dessa 
arquitetura é que é uma arquitetura distribuída. Podemos 
integrar novos servidores no sistema e atualizá-los de forma 
transparente. O exemplo que descreve essa arquitetura 
descreve	um	sistema	para	biblioteca	de	filmes.
Tabela 3 - Situações de uso da arquitetura cliente-servidor
nome arquitetura Cliente-Servidor
Descrição Em uma arquitetura cliente-servidor, a 
funcionalidade do sistema está organizada 
em serviços — cada serviço é prestado por 
um servidor. os clientes são os usuários 
desses serviços e acessam os servidores para 
fazer uso deles.
Exemplo A	figura	7	é	um	exemplo	de	uma	biblioteca	de	
filmes	e	vídeos/DVDs,	organizados	como	um	
sistema cliente-servidor.
Quando é usado É usado quando os dados em um banco de 
dados compartilhado precisam ser acessados 
a partir de uma série de locais. Como os 
servidores podem ser replicados, também 
pode ser usado quando a carga em um 
sistema é variável
Vantagens A principal vantagem desse modelo é que os 
servidores podem ser distribuídos através 
de uma rede. A funcionalidade geral (por 
exemplo, um serviço de impressão) pode 
estar disponível para todos os clientes e 
não precisa ser implementada por todos os 
serviços.
Desvantagens Cada	 serviço	 é	 um	 ponto	 único	 de	 falha	
suscetível a ataques de negação de serviço 
ou de falha do servidor. o desempenho, bem 
como o sistema, pode ser imprevisível, pois 
depende da rede. Pode haver problemas 
de gerenciamento se os servidores forem 
propriedade de diferentes organizações.
Fonte: SOMMErViLLE, 2011, p. 113. adaptado.
Figura 7 - Exemplo de arquitetura cliente-servidor, aplicado a um sistema de 
biblioteca de vídeos. Fonte: SOMMErViLLE, 2011, p. 114.
Engenharia de Requisitos 32
Arquitetura de Duto e Filtro
É um modelo de organização em tempo de execução 
de um sistema, na qual transformações funcionais processam 
suas entradas e produzem saídas. É como se fosse uma 
sequência de processamento a ser aplicada nos dados. Nessa 
arquitetura o processamento pode ser feito de forma paralela 
ou sequencial, processando um item por vez ou em lote. Seu 
nome veio do sistema operacional UNIX, cujos comandos 
digitados na linha de comando podem ser concatenados e 
processados, criando comandos mais complexos.
Tabela 4	-	Situações	de	uso	de	duto	e	filtro
nome arquitetura de Duto e Filtro
Descrição o processamento dos dados em um sistema 
está organizado de modo que cada componente 
de	processamento	(filtro)	seja	discreto	e	realize	
um tipo de transformação de dados. os dados 
fluem	(como	em	um	duto)	de	um	componente	
para outro para processamento.
Exemplo Sistema de processamento de faturas.
Quando é 
usado
Comumente, é usado em aplicações de 
processamento de dados (tanto as baseadas 
em lotes como as baseadas em transações) em 
que as entradas são processadas em etapas 
separadas para gerarem saídas relacionadas.
Vantagens o reuso da transformação é de fácil compreensão 
e	 suporte.	 Estilo	 de	 workflow	 corresponde	 à	
estrutura de muitos processos de negócios. 
Evolução por adição de transformações é 
simples. Pode ser implementado tanto como um 
sistema sequencial quanto concorrente.
Desvantagens o formato para transferência de dados tem 
de ser acordado entre as transformações de 
comunicação. Cada transformação deve analisar 
suas entradas e gerar as saídas para um formato 
acordado. isso aumenta o overhead do sistema 
e	pode	significar	a	impossibilidade	de	reúso	de	
transformações funcionais que usam estruturas 
incompatíveis de dados.
Fonte: SOMMErViLLE, 2011, p. 114. adaptado.
Figura 8 - Exemplo de arquitetura duto e filtro, aplicado a um sistema de 
processamento de faturas. Fonte: SOMMErViLLE, 2011, p. 114.
de partida para o projeto.
•	 Como um checklist de projeto. Se você desenvolveu um projeto 
de arquitetura para um sistema aplicativo, é possível compará-lo 
com	a	arquitetura	de	aplicação	genérica.	Você	pode	verificar	se	seu	
projeto é compatível com a arquitetura genérica. 
•	 Como forma de organizar o trabalho da equipe de 
desenvolvimento.	 As	 arquiteturas	 de	 aplicação	 identificam	
características estruturais estáveis das arquiteturas do sistema, e, 
em muitos casos, é possível desenvolvê-las em paralelo. Você pode 
distribuir o trabalho aos membros da equipe para implementação 
dos diferentes componentes dentro da arquitetura.
•	 Como uma forma de avaliar os componentes para reuso. Se você 
tem componentes que possam ser reusados, você pode compará-
los com as estruturas genéricas para ver se existem componentes 
comparáveis na arquitetura da aplicação.
•	 Como um vocabulário para falar sobre os tipos de aplicações. Se 
você	está	discutindo	uma	aplicação	específica	ou	tentando	comparar	
as aplicações do mesmo tipo, então, pode usar os conceitos 
identificados	na	arquitetura	genérica	para	falar	sobre	as	aplicações.
Sommerville	(2011,	p.	116)	afirma	que	você	pode	usar	os	modelos	
de arquiteturas de software para diferentes usos no projeto de 
arquitetura. Eles serão relatados a seguir:
•	 Como ponto de partida para o processo de projeto de arquitetura. 
Se você não estiver familiarizado com o tipo de aplicação que está 
desenvolvendo, pode basear seu projeto inicial em uma arquitetura 
genérica de aplicação. Naturalmente, ela precisará ser especializada 
para	o	sistema	específico	a	ser	desenvolvido,	mas	é	um	bom	ponto	
Na próxima subseção, você verá como funciona o 
padrão MVC.
4.2 - Padrão Model-View-Controller 
(MVC)
É um padrão de arquitetura que separa os módulos do 
software em três partes, a saber:
•	 model: representa as entidades do sistema. abriga 
toda a lógica de manipulação, leitura, escrita e 
validação de dados;
•	 view: abriga a camada de interação do usuário. são 
as classes e/ou arquivos com a interface do sistema;
•	 controller: recebe todas as requisições do usuário, 
controlando qual model usar e qual view a ser 
exibida (RAMOS, 2015).
Esse padrão é muito utilizado nas páginas Web, 
para organizar a lógica distribuída entre a linguagem do 
interpretador (Java, PHP, ASP etc.) dos arquivos HTML, CSS 
e	JavaScript,	que	definem	a	interação	como	usuário	na	página.
Figura 9 - Exemplo de interação em um sistema com arquitetura MVC. Fonte: 
raMOS, 2015.
33
4.3 - Passos para criar uma 
arquitetura do sistema
Vamos agora descrever de uma forma sucinta os passos 
que são empregados para criar a arquitetura do sistema. A 
primeira coisa que devemos fazer é a definição do contexto. 
Por meio do modelo de requisitos, todas as entidades externas 
(outros sistemas, dispositivos e pessoas) que interagem com 
o sistema são descobertos. Depois disso, identificamos um 
conjunto de arquétipos arquiteturais,	como	definido	por	
Pressman e Maxim: 
Em seguida, criamos um diagrama de contexto 
arquitetural (ACD) para modelar a interação do software 
com as suas fronteiras. Cada entidade externa é representada 
em um lado do sistema, dependendo do seu contexto, que 
pode ser:
•	 sistemas superiores: sistemas que usa o sistema-
alvo (ou seja o sistema em si) como parte de algum 
esquema de processamento de nível mais alto;
•	 sistema subordinados: sistemas que são 
utilizados pelo sistema-alvo e fornecem dados 
ou processamento necessários para completar a 
funcionalidade oferecida por esse sistema;
•	 sistemas de mesmo nível (também denominado 
como pares): sistemas que interagem com a base 
par-a-par (ou seja as informações são geradas e 
consumidas por ambas as partes.
•	 atores: entidades que interagem com o sistema, por 
meio do consumo ou fornecimento de informações. 
Podem ser pessoas ou dispositivos.
Figura 10 - Exemplo de diagrama ACD. Fonte: PRESSMAN; MAXIM, 2016, p. 268.
No sistema da locadora, vemos que a única interface 
possível é o funcionário, que é um ator. Representaremos na 
figura	a	seguir	em	um	ACD	específico	para	esse	sistema.
Figura 11 - Diagrama aCD para o sistema da locadora. Fonte: acervo pessoal.
Após isso, criamos uma lista dos arquétipos do 
sistema, por meio das classes de análise do sistema e dos 
requisitos listados. Nessa situação, um arquétipo é uma classe 
ou padrão que representa uma abstração que é crítica para o 
sistema alvo.
Para o sistema da Locadora, foram detectados os 
seguintes arquétipos:
•	 cadastro de carro;
•	 cadastro de locação;
•	 cadastro de cliente;
•	 cadastro de funcionário.
Depois, podemos fazer o refinamento da arquitetura 
em componentes. Por meio dos requisitos e do domínio 
da infraestrutura, detectamos componentes de alto nível 
que são necessários para a execução do sistema em si. Nesse 
caso, detectamos a necessidade da criação de arquétipos 
para	a	apresentação	da	interface	gráfica	para	o	usuário	e	de	
um sistema que gerencia o login de usuários. Mas atenção, 
detalhes referentes à modularização (ou seja, quais atributos 
e	métodos	 serão	 empregados)	 somente	 serão	 definidos	 no	
projeto de componentes.
Em	 seguida,	 o	 modelo	 de	 arquitetura	 é	 refinado	
novamente, para chegar ao nível de detalhes necessário e 
suficiente	para	o	sistema.
No caso da locadora, foi adotada uma arquitetura em 
camadas, do ponto de vista interno do sistema. A seguir, 
reproduzimos o diagrama de componentes, representando a 
arquitetura para esse sistema.
Figura 12 - Diagrama de componentes, representando a arquitetura do sistema 
da Locadora. As flechas indicam que um arquétipo depende do outro. Fonte: 
acervo pessoal.
Com	 isso,	 finalizamos	 a	 nossa	 aula.	 Na	 próxima,	
estudaremos projeto de componentes e de interfaces. No 
final	 desta	 aula,	 disponibilizamos	 vários	 links	 que	 possam	
ser interessantes nos seus estudos. Não deixe de visitá-los. 
Lembre-se também de fazer as atividades e utilizar os recursos 
que estão disponíveis em sua área do aluno.
Retomando a aula
Chegamos	ao	final	da	quarta	aula.	Vamos	recordar	os	
pontos principais?
1 - Definição de Projeto de Software
Entendemos o conceito de Projeto de Software como 
o processo de aplicar várias técnicas e princípios com o 
propósito	de	definir	um	processo	ou	sistema,	com	detalhes	
suficientes	 para	 permitir	 sua	 realização	 física.	 Tendo	 como	
meta traduzir requisitos em uma representação de software.
Engenharia de Requisitos 34
2 - Conceitos de Projeto de Software
Nesta seção, você viu vários conceitos que devem ser 
levados em conta ao fazer um projeto de software, como 
Abstração, Arquitetura, Padrões, Separação por Interesses, 
Modularidade, Encapsulamento, Independência Funcional, 
Refinamento,	Aspectos	 e	Refatoração.	Você	 viu	 também	a	
definição	de	Classes	de	Projeto	e	como	fazer	projetos	visando	
testes.
3 - Modelo de Projeto de Software
O modelo de Projeto de Software pode ser dividido em 
quatro componentes: Projeto de Dados (criando um modelo 
de	 dados),	 Projeto	 de	 Arquitetura	 (define	 a	 arquitetura	 do	
sistema), Projeto de Componentes (que descreve os detalhes 
internos de um componente de software), Projeto de Interface 
(cuida	da	definição	das	interfaces)	e	Projeto	de	Implantação	
(cuida dos detalhes computacionais do ambiente do sistema).
4 - Projeto de Arquitetura
O projeto de Arquitetura é uma representação que nos 
permite analisar a efetividade do projeto no atendimento dos 
requisitos declarados, considerar alternativas de arquitetura 
em um estágio em que fazer mudanças de projeto ainda é 
relativamente fácil e reduzir os riscos associados à construção 
do software.
Você viu também os principais modelos de projeto 
existentes na Engenharia de Software, como a arquitetura de 
duto	e	filtro,	arquitetura	em	camadas,	etc.
Vale a pena
DEBASTIANI, Carlos Alberto. Definindo Escopo em 
Projetos de Software. São Paulo: Novatec, 2015.
ENGHOLM JR, Hélio. Engenharia de Software na Prática. 
São Paulo: Novatec, 2010.
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia 
de Software:	Uma	abordagem	profissional.	8	ed.	Porto	Alegre:	
Bookman, 2016. 
SOMMERVILLE, Ian. Engenharia de Software. 9 ed. São 
Paulo: Pearson, 2011.
Vale a pena ler
ALONSO, Vinícius. Aplicando a Lei de Demeter em nossos 
códigos. [S.l.]: Medium, 2016. Disponível em: <https://
medium.com/lets-grow/aplicando-a-lei-de-demeter-em-
nossos-c%C3%B3digos-5e2c0d70efd4>. Acesso em: 10 
mar. 2018.
Vale a pena acessar
ALLET, André. Introdução a Orientação a Aspecto. [S.l.]: 
DevMedia, s.d. Disponível em: <https://www.devmedia.
com.br/introducao-a-orientacao-a-aspecto/27759>. 
Acesso em: 10 mar. 2018.
BATISTA NETO, João. Elementos do Design de Software. 
[S.l.]: iMasters, 2015. Disponível em: <https://imasters.
com.br/desenvolvimento/elementos-do-design-de-softw
are/?trace=1519021197&source=single>. Acesso em: 10 
mar. 2017.
BALBO, Wellington. Conceitos - Encapsulamento. 
Disponível em: <https://www.devmedia.com.br/
conceitos-encapsulamento-programacao-orientada-a-
objetos/18702>. Acesso em: 10 mar. 2018.
BACELO, Ana Paula Terra. Arquitetura de Software: 
Conceitos e Tendências. FACIN-PUCRS, 2010. 
Disponível em: <https://www.inf.pucrs.br/jornada.facin/
jafacin_2010/palestras/ArquiteturaDeSoftware.pdf>. 
Acesso em: 10 mar. 2018.
BIRD, Jim. O que é e o que não é refatoração. [S.l.]: 
IBM, 2013. Disponível em: <https://www.ibm.com/
developerworks/community/blogs/fd26864d-cb41-49cf-
b719-d89c6b072893/entry/o_que__C3_A9_e_o_que_n_
C3_A3o__C3_A9_refatora_C3_A7_C3_A3o_de_acordo_
com_kent_beck_e_martin_fowler?lang=en>. Acesso em: 
10 mar. 2018.
IBM. Diagramas de Componentes. [S.l.]: IBM, s.d. Disponível 
em: <https://www.ibm.com/support/knowledgecenter/
pt-br/SS4JE2_7.5.5/com.ibm.xtools.modeler.doc/topics/
ccompd.html>. Acesso em: 11 mar. 2018.
KAMAKURA, Felipe. O que é design de software? 
[S.l.]: Kama On Dev, 2013. Disponível em: <https://
kamaondev.wordpress.com/2013/09/09/o-que-e-design-
de-software/>. Acesso em: 10 mar. 2018.
MASIERO, Paulo C. Projeto de Software. [S.l.]: USP, 
s.d. Disponível em: <https://edisciplinas.usp.br/
pluginfile.php/24117/mod_resource/content/1/Aula_5-
ProjetoSoftware.pdf>. Acesso em:11 mar. 2018
MENDES, Antônio. Arquitetura de Software: 
Desenvolvimento voltado para a arquitetura. [S.l.]: 
DevMedia, s.d. Disponível em: <https://www.devmedia.
com.br/arquitetura-de-software-desenvolvimento-
orientado-para-arquitetura/8033>. Acesso em: 10 mar. 
2018.
NOBRE, André. Princípios de OOP: A lei de Demeter 
(LoD). [S.l.]: s.n., 2009. Disponível em: <https://weblogs.
asp.net/andrenobre/princ-237-pios-de-oop-a-lei-de-
demeter-lod>. Acesso em: 11 mar. 2018.
PORTELLA, Cristiano R. R. Projeto de Software. Campinas: 
PUC, s.d. Disponível em: <http://www.cesarkallas.
net/arquivos/faculdade/engenharia_de_software/13-
Projeto%20de%20Software/Projeto%20de%20Software.
pdf>. Acesso em: 10 mar. 2018.
RAMOS, Allan. O que é MVC?. [S.l.]: Tableless, 2015. 
Disponível	 em:	 <https://tableless.com.br/mvc-afinal-e-o-
que/>. Acesso em: 10 mar. 2018.
RIBEIRO, Antônio Mendes. Diagrama de Componentes. 
Disponível em: <http://homepages.dcc.ufmg.
br/~amendes/GlossarioUML/glossario/conteudo/
35
componentes/diagrama_de_componentes.htm>. Acesso 
em: 10 mar. 2018.
SAAB, Felipe N. Introdução a Refatoração. [S.l.]: 
DevMedia, s.d. Disponível em: <https://www.devmedia.
com.br/introducao-a-refatoracao/21377>. Acesso em: 10 
mar. 2018.
SCARPA, João Matheus. Padrões de arquitetura 
de software: Você sabe do que estamos falando?. 
[S.l.]: Medium, 2016. Disponível em: <https://blog.
designa.com.br/padr%C3%B5es-de-arquitetura-de-
software-voc%C3%AA-sabe-do-que-estamos-falando-
4858967c4054>. Acesso em: 11 mar. 2018.
TEDESCO, Kennedy. Padrões de projeto: o que são e o que 
resolvem. [S.l.]: Treinaweb, 2016. Disponível em: <https://
www.treinaweb.com.br/blog/padroes-de-projeto-o-que-
sao-e-o-que-resolvem/>. Acesso em: 11 mar. 2018.
VALLE, Mauro do. Introdução à programação orientada 
a aspectos - Conceitos. [S.l.]: DevMedia, s.d. Disponível 
em: <https://www.devmedia.com.br/introducao-a-
programacao-orientada-a-aspectos-conceitos/3062>. 
Acesso em: 10 mar. 2018.
SOARES, Ismael. A Lei de Demeter. Disponível 
em: <https://www.youtube.com/watch?v=MgL_
sOWFE1A>. Acesso em: 10 mar. 2018.
Vale a pena assistir
Minhas anotações