Conteúdo da Unidade-8

Prévia do material em texto

Fundamentos 
de Sistemas de 
Informação
1ª edição
2017
Fundamentos 
de Sistemas de Informação
3
8Unidade 8
Conceitos de Projeto
Para iniciar seus estudos
Caro aluno, seja bem-vindo à oitava e última unidade do nosso curso!
Você certamente já teve a oportunidade de ver o projeto de uma casa ou 
de uma construção semelhante. Toda a estrutura do imóvel está lá repre-
sentada: as divisões dos cômodos, o posicionamento de portas e janelas, 
a escada e por aí vai. Em dias atuais, inclusive, é possível até passear pela 
casa usando a ferramenta computacional certa, sem que uma parede 
sequer tenha sido erguida.
O projeto é a base de tudo e sua elaboração é feita por profissionais pre-
parados. Sem ele em mãos, o executor da obra não terá parâmetros ade-
quados para cumprir seu trabalho, mesmo que tenha boa noção do que 
deverá ser construído.
Os pontos de semelhança da Engenharia Civil com os processos relacio-
nados aos Sistemas de Informação passam longe da mera coincidência. 
Tanto lá como cá, a criação do desenho da solução é condição fundamen-
tal para que ela se torne realidade e um projeto bem feito abre portas para 
a construção de um sistema de igual qualidade.
Não por acaso, dedicamos toda esta unidade ao estudo do projeto de sof-
tware, desde seus conceitos fundamentais até a geração do artefato que 
sintetiza os objetivos dessa fase tão importante da Engenharia de Software.
Fique conosco, bom estudo e parabéns por ter chegado até aqui.
4
Objetivos de Aprendizagem
O aluno será capaz de compreender sobre conceitos de projeto e modelo 
do projeto (dados, arquitetura, interface, componentes e implantação).
5
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Tópicos de estudo
Acreditamos que uma forma bastante eficiente de iniciar a compreensão de um novo tema é por meio da com-
paração com outro, já estudado e bem sedimentado. Afinal, aprender as coisas novas a partir das já sabidas faz 
tudo parecer mais familiar e fácil de entender.
Nesse sentido, um parâmetro bastante apropriado para nossa iniciação no mundo do projeto de software é o 
que já sabemos sobre requisitos. Se os requisitos revelam aos analistas “o que” deve ser feito para que se obtenha 
determinado produto, o projeto revela “como” ele deverá ser elaborado. Durante a fase de requisitos, o enge-
nheiro busca informações do cliente para delimitar funções e estabelecer comportamentos do futuro sistema. 
Diz-se, portanto, que ao final da fase de requisitos, já temos a solução pelo ponto de vista do cliente/usuário. 
É na fase de projeto, por sua vez, que se planeja a arquitetura do produto, além do estabelecimento das interfaces 
com outros sistemas e das estruturas de dados.
Há muito assunto interessante a ser abordado nesta unidade e sua dedicação não será em vão. Preparado? Ini-
ciemos então pelos conceitos fundamentais de projeto de software.
8.1 Conceitos fundamentais de projeto de software
Elaborar um projeto faz parte da primeira etapa de desenvolvimento de qualquer produto ou sistema de enge-
nharia. No universo dos Sistemas de Informação, é a etapa que se inicia após a validação dos requisitos e sua 
meta é produzir um modelo ou uma representação do produto a ser construído. Para atingir tal objetivo, o pro-
jetista deve lançar mão de sua experiência, intuição, de metodologias e heurística. Modelos ou representações 
podem ser analisados quanto à sua qualidade e são base para as etapas seguintes do ciclo de vida do produto, 
quais sejam, codificação, teste, validação e manutenção.
Conceitualmente, projeto é o processo pelo qual os requisitos são traduzidos em uma representação do software. 
Qualquer que seja a metodologia escolhida para a criação do produto, o projeto será desenvolvido.
Sommerville (2010) define projeto como a descrição da estrutura de software a ser implementada, dos dados que 
são parte do sistema, das interfaces entre os componentes do sistema e, às vezes, dos algoritmos usados.
É comum o entendimento de que o nível de detalhamento da solução que se aplica em um projeto deve ser sufi-
cientemente elevado a ponto de permitir a realização física do produto. Refinamentos sucessivos levam a uma 
representação próxima ao código-fonte e estima-se que, quanto mais detalhado for o projeto, mais imediata 
será a transição para a efetiva solução do problema.
Se é verdade que quanto mais se detalha os itens de um projeto, mais fácil será a implemen-
tação do produto, qual seria o limite razoável para esse detalhamento? Haveria um ponto em 
que o tempo investido na pormenorização de uma função não compensaria seus benefícios? 
6
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Quando estudamos o Extreme Programming, ficamos conhecendo, entre outras coisas, os princípios da metodo-
logia, e os alçamos à condição de pilares de todas as práticas do modelo. Pois bem, a fase de projeto de software 
também tem suas bases e, embora muitos conceitos relacionados ao tema tenham evoluído, esses paradigmas 
têm resistido ao tempo. Fique ciente de que os conceitos que analisaremos na sequência nos servirão quando da 
abordagem do processo de projeto.
8.1.1 Abstração
A solução modular leva a vários níveis de abstração. Abstrair é concentrar-se em certos aspectos relevantes ao 
ambiente do problema. Cada passo da Engenharia de Software diminui o nível de abstração em direção à solução 
do problema. O nível mais baixo de abstração é o código-fonte.
Abstração procedimental: ensinam Pressman e Maxim (2016) que a abstração procedimental (ou procedural) 
refere-se a uma sequência de instruções que possui uma função específica e limitada. O nome de uma abstração 
procedural indica sua função, mas sem os detalhes específicos.
Tomemos o esboço de uma aplicação tipo CAD como exemplo e dela consideraremos três níveis de abstração 
procedimental:
Abstração 1 - Descrição geral do produto
O software terá uma interface gráfica que possibilitará acesso à função de desenhos de linhas retas e curvas. Os 
desenhos serão armazenados em uma pasta de desenhos.
Abstração 2 - Tarefas do software CAD
• início tarefa
• interação com o usuário
• criação de desenhos
• exibição de gráficos
• gerenciamento de arquivos de desenho
• fim tarefa
7
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Abstração 3 - Procedimento de criação de desenho bidimensional
repetir ate que <tarefa de criação termine>
enquanto <ocorrer interação > faça
tarefa de interface
determinar pedido de desenho
tarefa de desenho de linha
fim enquanto
fim repetir
Observe que, no nível de abstração mais baixo, o detalhamento da solução aumenta e torna-se mais próximo da 
realização do código-fonte.
Abstração de dados: trata-se da descrição de um objeto por meio dos seus dados. Aqui, podemos tomar como 
exemplo a composição de um contracheque – ou holerite, como também é conhecido. Embora possa haver 
pequenas variações, a descrição dos dados desse objeto deve incluir nome do beneficiado, quantia bruta, quan-
tia líquida, horas normais trabalhadas, horas extras trabalhadas, desconto de Imposto de Renda e de INSS, entre 
outros. Nesse caso, referencia-se o conjunto de dados pelo nome da abstração (contracheque).
Arquitetura de software
De acordo com que ensinam Pressman e Maxim (2016), arquitetura é a estrutura ou a organização dos com-
ponentes do programa, a maneira como esses componentes interagem e a estrutura de dados que são usados 
pelos componentes. 
De uma forma simples e objetiva, a arquitetura do sistema pode ser representada por um diagrama de blocos 
que ilustra a organização do sistema e as interfaces com outros sistemas. Observe a figura a seguir; ela mostra a 
arquitetura de um sistema (não trivial e de porte considerável) de controle de tráfego aéreo.
8
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Figura 8.1: Arquitetura de um sistema de tráfegoaéreo.
Banco de dados
de planos de
Sistema de
simulação da
aeronave
Sistema de
mapa de clima
Sistema de
relatórios
Sistema de registro 
de atividades
Sistema de 
informações 
do controlador
Consoles do
controlador
Back-up do
processador de
comunicação
Processador 
de 
comunicação
Back-up do
processador
de posição
Processador 
de posição
Sistema 
de radar
Sistema de
transponder
Sistema de
comunicação
de dados
Sistema de
comunicação
da aeronave
Sistema
telefônico
Legenda: O sistema de controle de tráfego aéreo não se resume a uma única 
aplicação. O fluxo de informações entre os subsistemas é mostrado por setas.
Fonte: Sommerville (2010, p. 22).
Pressman e Maxim (2016) descrevem três motivos para que a arquitetura do software seja considerada absoluta-
mente indispensável em um projeto: 
• A arquitetura de software fornece uma representação que facilita a comunicação entre todos os envol-
vidos. Como as conexões entre módulos e demais elementos do produto estão esclarecidas, o entendi-
mento da interação entre os desenvolvedores dos módulos acaba ficando facilitado também. No mesmo 
sentido, as divisões de trabalho certamente serão realizadas com base real.
• Desde a fase de projeto, a arquitetura coloca em evidência aquelas decisões de projeto que terão um 
profundo impacto no trabalho de engenharia de software que se segue.
• Já que a modularização serve para dividir um problema grande em vários outros menores, a arquitetura 
constitui um modelo relativamente pequeno e intelectualmente compreensível de como o sistema é 
estruturado e de como seus componentes trabalham em conjunto.
Os mesmos autores destacam que, assim como na arquitetura convencional, aquela que representa um produto 
de software também tem seus estilos. Cada estilo descreve uma categoria de sistema e especializa-se em um 
aspecto seu, incluindo um conjunto de componentes (um banco de dados, por exemplo), um conjunto de conec-
tores que, por exemplo, possibilita a comunicação do sistema, as restrições que estabelecem como os compo-
nentes podem ser integrados e outros. Analisemos dois desses estilos:
9
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Arquiteturas centralizadas em dados: este estilo de arquitetura é fortemente baseado em um banco de dados 
ou arquivo. Os componentes que atualizam, incluem ou excluem dados nessa base também têm destaque na 
representação. A figura a seguir ilustra esse estilo.
Figura 8.2: Arquitetura centralizada em dados.
Software
cliente
Software
cliente
Software
cliente
Software
cliente
Software
cliente
Software
cliente
Software
cliente
Software
cliente
Armazenamento
de dados (repositório
ou “quadro-negro”)
Legenda: A representação de um repositório de dados em posição central e os 
componentes que acessam esse repositório caracterizam a arquitetura centralizada em dados.
Fonte: Pressman e Maxim (2016, p. 259).
Em alguns casos o repositório de dados é passivo, isto é, o software cliente acessa os dados mesmo que estes 
sofram alterações ou ações de outros softwares clientes. Uma variação dessa abordagem faz com o que o reposi-
tório se transforme em uma espécie de “quadro-negro”. Ele envia notificações ao software cliente quando ocor-
rem modificações nos dados que são do seu interesse.
Arquiteturas de chamadas e retornos: este estilo de representação permite uma adequada visualização da hie-
rarquia entre programas chamadores e subprogramas chamados. A figura a seguir ilustra o estilo de chamadas e 
retornos, especificamente as ocorridas entre programas e subprogramas.
10
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Figura 8.3: Arquitetura de chamadas e retornos.
Programa principal
Subprograma
controlador
Subprograma
controlador
Subprograma
de aplicação
Subprograma
de aplicação
Subprograma
de aplicação
Subprograma
de aplicação
Subprograma
de aplicação
Subprograma
de aplicação
Subprograma
de aplicação
Subprograma
controlador
Legenda: O estilo de chamadas e retornos permite a visualização 
da hierarquia entre os subprogramas que compõem o produto.
Fonte: Pressman e Maxim (2016, p. 260).
A literatura ainda nos oferece os estilos de arquiteturas de fluxos de dados, arquiteturas orientadas a objetos e 
arquiteturas em camadas.
Embora o termo “arquitetura” remeta à organização dos módulos do sistema, ele também está associado a inter-
faces com outros sistemas e a estrutura de dados, por exemplo. No item dedicado ao processo de projeto, trata-
remos desses assuntos em detalhes.
Modularidade
Por causa da comum complexidade dos sistemas atuais, não é possível conceber a solução de um problema de 
maneira monolítica, sem as devidas divisões. Modularizar um software é “quebrar” seu projeto em partes meno-
res, mais facilmente administráveis e de realização mais simples.
Nenhuma dúvida resta sobre a necessidade de modularizar um sistema em sua fase de concepção, já que a 
complexidade embutida nos controles do programa e na quantidade de variáveis tornaria o trabalho pratica-
mente impossível. No entanto, ainda nos resta uma reflexão: se a subdivisão do problema em módulos menores 
é mesmo necessária, em quantas partes devemos dividi-lo? A relação “mais divisões, menos complexidade” fun-
ciona sempre? 
Para respondermos a essas questões, devemos considerar o custo (ou esforço) para a construção do módulo e 
para sua integração com os demais. Observe o gráfico a seguir; ele nos revela que o custo da integração aumenta 
conforme aumenta a quantidade de módulos a serem construídos. Outro fato relevante é que o custo por módulo 
é reduzido conforme sua quantidade aumenta. Em outras palavras, um módulo grande e complexo custa mais 
para ser construído que um pequeno e que acomoda uma função apenas (trataremos de módulos com uma só 
função nas próximas linhas).
11
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
O gráfico então aponta para um ponto central, identificado como “M”, em que a quantidade de módulos e o 
custo para produzi-los equilibram-se mutuamente.
Gráfico 8.1: Modularidade e custo de integração
Região de
custo mínimo
Custo total do software
Custo de integração
Custo /módulo
Número de módulos
M
Legenda: O crescimento do número de módulos tende a tornar o projeto mais custoso, seja por 
causa da elaboração de mais módulos, seja pela necessidade de integrá-los todos.
Fonte: Pressman e Maxim (2016, p. 235).
A decisão sobre a quantidade de módulos sempre será influenciada também por decisões 
de projeto relacionadas a certas facilidades que se deseja conferir ao sistema. O grau de sim-
plicidade para absorver alterações e a facilidade para receber testes e manutenções futuras 
serão igualmente decisivos nessa escolha. 
Embora esse modelo nos auxilie a estabelecer parâmetros sobre quantos módulos construir, ele pouco nos diz 
sobre como construí-los. O conceito de independência funcional, explorado na sequência, lançará alguma luz 
sobre esta questão.
Independência funcional
Módulos construídos idealmente com uma só função e sem interações excessivas com outros módulos são fun-
cionalmente independentes. A busca por essa característica justifica-se pela facilidade com que se empreende o 
desenvolvimento e a manutenção do produto de software. 
Para compreender esse fato, imagine um módulo que tenha muitas dependências com outros módulos. O pla-
nejamento e a execução de testes nesse módulo seriam ações bastante trabalhosas. 
12
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
O mesmo raciocínio estende-se às ações de manutenção. Segundo Pressman e Maxim (2016), módulos inde-
pendentes são mais fáceis de serem mantidos e testados, já que possíveis consequências das modificações no 
projeto serão limitadas e a propagação de erros será reduzida. Acrescente-se a esses benefícios a possibilidade 
de criação de módulos reutilizáveis, o que diminuiráo tempo de criação de programas futuros.
É possível avaliar a independência dos módulos por meio de dois critérios ligados à qualidade do processo: a 
coesão e o acoplamento. Um módulo coeso é aquele que acomoda uma função com um só propósito. Busca-se, 
portanto, módulos com alta coesão.
O acoplamento é a medida da dependência de um módulo em relação aos demais. Um módulo deve depender o 
menos possível de outro módulo, o que torna o baixo acoplamento o ideal a ser buscado pelo projetista.
A coesão que se busca durante a criação dos módulos leva o nome de coesão funcional. No entanto, alguns 
outros tipos de coesão também foram criados e colocados em uma hierarquia.
Como pior caso de coesão a ser considerado, temos a coesão coincidental. Aqui, não há nenhuma relação entre 
os elementos colocados no módulo, daí dizer que foram escolhidos por coincidência ou ao acaso.
Conforme já citado, o melhor caso de coesão é a funcional. Aqui, as operações descritas no módulo estão dispos-
tas, idealmente, em uma única frase, e ainda assim permanecem coerentes.
Entre esses dois tipos de coesão, temos a lógica, a temporal, a procedural, a de comunicação e a sequencial.
Uma visão bastante interessante e recheada de exemplos sobre acoplamento e coesão em 
módulos e funcionalidades pode ser obtida no texto disponível em <http://www.ateomo-
mento.com.br/acoplamento-e-coesao-em-modulos-e-funcionalidades/> (Acesso em: 3 
fev. 2018). Acesse também <https://www.devmedia.com.br/entendendo-coesao-e-aco-
plamento/18538> (Acesso em: 3 fev. 2018) e conheça aspectos práticos de coesão e aco-
plamento aplicados em programação orientada a objetos. 
Os conceitos e princípios de projeto não se limitam a esses que abordamos. Na literatura, é comum encontra-
mos, entre outras, menções a padrões aplicados aos projetos, refinamento gradual da solução e a aplicação de 
refatoração em projetos já prontos em parte ou no todo. Este texto, no entanto, deverá limitar-se ao estudo dos 
mais comuns e importantes deles. 
Nosso estudo segue agora com a abordagem do processo de um projeto, uma tentativa de estruturar e dar um 
método à atividade de projeto. Sigamos em frente!
http://www.ateomomento.com.br/acoplamento-e-coesao-em-modulos-e-funcionalidades/
http://www.ateomomento.com.br/acoplamento-e-coesao-em-modulos-e-funcionalidades/
https://www.devmedia.com.br/entendendo-coesao-e-acoplamento/18538
https://www.devmedia.com.br/entendendo-coesao-e-acoplamento/18538
13
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
8.2 O processo de projeto de software
Criar um projeto de software não é trabalho que se realiza em uma única etapa. O modelo final de projeto também 
não é fruto de uma única versão, sem prévio refinamento. Ao contrário, produzir um projeto é tarefa que envolve 
várias interações e a divisão do trabalho em vários subprojetos ou atividades específicas. No mesmo sentido, é 
comum que o processo de projeto acabe gerando inúmeros modelos do sistema, em níveis de abstração distintos.
A figura a seguir esclarece como um projeto segue seus passos até a composição final. Observe que as setas dia-
gonais tornam a saída de cada atividade uma especificação para o próximo estágio do processo. Não por acaso, a 
última etapa remete à especificação do algoritmo do sistema, artefato mais próximo da solução antes dela própria. 
Figura 8.4: Modelo geral do processo de projeto.
Especificação
de requisitos
Projeto de
arquitetura
Especificação
abstrata
Projeto de
interface
Projeto de
componente
Projeto de
estrutura de
dados
Projeto de
algoritmo
Arquitetura
de sistema
Especificação
de software
Especificação
de interface
Especificação
de componente
Especificação
de estrutura 
de dados
Especificação
de algoritmo
Atividades de projeto
Produtos de projeto
Legenda: As atividades próprias do processo de projeto usam as 
especificações geradas como subsídio de entrada para o próximo estágio.
Fonte: Sommerville (2010, p. 51).
Trataremos sucintamente de algumas das atividades do projeto nas próximas linhas e começaremos pelo projeto 
de dados.
8.2.1 Projeto de dados
Com base nos requisitos especificados, nesta etapa, busca-se criar um modelo de dados. Em um primeiro 
momento, esse modelo adota nível elevado de abstração para que o cliente ou usuário possa compreendê-lo. 
Depois, por meio de refinamentos sucessivos, o modelo torna-se mais adequado para a efetiva implementação 
dos dados em um programa. 
É natural imaginarmos que a arquitetura dos dados terá influência sobre o projeto de arquitetura do software.
14
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
8.2.2 Projeto de arquitetura
Esta etapa do processo funciona como uma forte ligação entre os processos de requisito e de projeto propria-
mente dito. Aqui, buscam-se o desenvolvimento e a manutenção de um framework básico em que estejam repre-
sentados os módulos do produto e as conexões entre eles.
Framework - Muitas são as definições que se aplicam ao termo framework. Em nosso contexto, 
podemos caracterizá-lo como um conjunto de símbolos, parâmetros e controles capaz de 
representar a arquitetura de um sistema. 
Glossário
Pressman e Maxim (2016) comparam o projeto de arquitetura com a planta baixa de uma casa. Ali, está disposta 
a distribuição dos cômodos e as ligações entre eles e, assim como a planta baixa nos fornece uma visão geral da 
casa, os elementos do projeto de arquitetura nos dão uma visão geral do software.
8.2.3 Projeto de interface
Ainda no contexto de comparação entre um projeto de software e um projeto de casa, o projeto da interface tem 
relação com portas, janelas e corredores de uma casa. Afinal, são esses elementos que explicitam os caminhos 
para entrar, sair e transitar pela casa.
O projeto de interfaces para software representa fluxos de informação que entram e saem de um sistema e como 
são transmitidos entre os componentes definidos como parte da arquitetura. Existem três elementos de projeto 
de interfaces: interface do usuário; interfaces externas para outros sistemas, dispositivos, redes ou outros produ-
tores ou consumidores de informação; e interfaces internas entre vários componentes do projeto (PRESSMAN; 
MAXIM, 2016).
8.2.4 Projeto de componentes
Podemos imaginar os componentes como a fiação, a localização de tomadas, interruptores, ralos, armários e 
vários outros detalhes associados a um cômodo.
No âmbito dos Sistemas de Informação, a comparação aproxima-se do conceito de uma peça de reposição.
Componente é um bloco construtivo modular para software de computador. Mais formalmente, 
a Especificação da Linguagem de Modelagem Unificada define componente como uma parte 
modular, possível de ser implantada e substituível de um sistema que encapsula implementação 
e expõe um conjunto de interfaces (PRESSMAN; MAXIM, 2016, p. 286).
15
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Por causa da variadade de aplicações e contextos em que é usado, o real significado do termo componente irá 
variar em função do ponto de vista do engenheiro que o utiliza. O que não muda é o fato de que os componentes 
situam-se no âmbito da arquitetura do software e devem comunicar-se e colaborar com outros componentes, 
quais sejam, pessoas, meios de armazenamento ou outros sistemas.
O projeto de componentes de software descreve completamente os detalhes internos de cada componente de 
software. Para tanto, o projeto no nível de componente define estruturas de dados para todos os objetos de 
dados locais e detalhes algorítmicos para todo o processamento que ocorre em um componente e uma interface 
que dá acesso a todas as operações de componentes (PRESSMAN; MAXIM, 2016).
Projeto de implantação
Implantar um software, na maioria das vezes, não significa apenas instalar o programa no servidor ou nas máqui-
nas que o executarão. É necessário também que se descreva como o sistema será alocado no que se chamade 
ambiente computacional em que ele atuará. Pode-se ter um produto, por exemplo, que deva ser configurado em 
um servidor local e alguns dos seus componentes em uma máquina remota.
Bem, era isso que tinhamos a compartilhar sobre projeto de software. Não tenha dúvida de que o assunto é vasto 
e a frequência com que as informações são atualizadas é bastante elevada. Por isso, mantenha-se antenado em 
artigos, reportagens e obras relacionadas ao tema e torne-se uma boa referência no assunto.
Boa sorte e até a próxima!
16
Considerações finais
Nesta unidade, tratamos do projeto de software, com abordagens espe-
cíficas de conceitos de projeto e processo de projeto. Em resumo, estuda-
mos os seguintes assuntos:
Conceitos fundamentais de projeto de software
Projeto é o processo pelo qual os requisitos são traduzidos em uma repre-
sentação do software. Qualquer que seja a metodologia escolhida para a 
criação do produto, o projeto será desenvolvido. O nível de detalhamento 
da solução que se aplica em um projeto deve ser suficientemente elevado 
a ponto de permitir a realização física do produto. 
Os principais fundamentos da fase de projeto incluem:
• Abstração: abstrair é concentrar-se em certos aspectos relevantes 
ao ambiente do problema. Cada passo da Engenharia de Software 
diminui o nível de abstração em direção à solução do problema. O 
nível mais baixo de abstração é o código-fonte.
• Arquitetura de software: é a estrutura ou a organização dos com-
ponentes do programa, a maneira como esses componentes inte-
ragem e a estrutura de dados que são usados pelos componentes.
• Modularidade: modularizar um software é “quebrar” seu projeto 
em partes menores, mais facilmente administráveis e de realiza-
ção mais simples. A correta modularização deve levar em conta 
o custo para desenvolver e integrar módulos pequenos. Construir 
poucos módulos, por sua vez, também poderá acarretar em difi-
culdades nos testes e na manutenção futura do sistema.
• Independência funcional: módulos construídos idealmente com 
uma só função e sem interações excessivas com outros módulos 
são funcionalmente independentes. A busca por essa caracterís-
tica justifica-se pela facilidade com que se empreende o desen-
volvimento e a manutenção do produto de software. 
17
O processo de projeto de software
Criar um projeto de software não é trabalho que se realiza em uma única 
etapa. Ao contrário, produzir um projeto é tarefa que envolve várias inte-
rações e a divisão do trabalho em vários subprojetos ou atividades espe-
cíficas. O processo de um projeto inclui as seguintes etapas:
• Projeto de dados: com base nos requisitos especificados, nesta 
etapa, busca-se criar um modelo de dados. De um nível elevado 
de abstração no início, o projeto tende a receber refinamentos 
sucessivos para chegar a uma forma próxima à implementação. 
• Projeto de arquitetura: aqui, buscam-se o desenvolvimento e a 
manutenção de um framework básico em que sejam representa-
dos os módulos do produto e as conexões entre eles.
• Projeto de interface: representa os fluxos de informação que 
entram e saem de um sistema e como são transmitidos entre os 
componentes definidos como parte da arquitetura.
• Projeto de componentes: descreve completamente os detalhes 
internos de cada componente de software.
• Projeto de implantação: trata-se da descrição de como o sistema 
será alocado no que se chama de ambiente computacional em 
que ele atuará.
Referências bibliográficas
18
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem 
profissional. 8. ed. Porto Alegre: Amgh, 2016.
SOMMERVILLE, I. Engenharia de Software. 8. ed. São Paulo: A. Wesley 
publishing company, 2010.
	_Hlk505856755
	_Hlk505856893