22 - ENGENHARIA DE SOFTWARE

Prévia do material em texto

Professor Me. Ricardo Bortolo Vieira
 
• Graduação em Ciência da Computação pela Universidade Estadual de Maringá 
(2003). 
• Especialização de Engenharia de Software pela Universidade Estadual de Lon-
drina (2007). 
• MBA em Gestão em Saúde Suplementar pela São Marcos (2009). 
• Especialização de Gerência de Projetos pela Fundação Getúlio Vargas (2011). 
• Mestre em Desenvolvimento de Tecnologias pelo Instituto LACTEC.(2017)
• Doutorando em Informática para PUCPR . 
• Gerente de Desenvolvimento de software e profissional do mercado de TI a 
mais de 12 anos.
• Professor de nível superior da Faculdade Cidade Verde de Maringá (FCV), 
Universidade Federal do Paraná (UFPR), Faculdade de Engenharia e Inovação 
Tecnológica (FEITEP), Fundação Getúlio Vargas (FGV) e Pontifícia Universida-
de Católica (PUC).
• Experiência na área de Ciência da Computação, com ênfase em Sistemas de 
Computação e Automação e Robótica, além de experiência em Administração 
com ênfase em Gerenciamento de Projetos.
Lattes: http://lattes.cnpq.br/5731213234468142
AUTOR
http://lattes.cnpq.br/5731213234468142 
Seja muito bem-vindo(a)!
Olá prezado(a) aluno(a), este é o livro Fundamentos de Engenharia de Software, 
sou o professor Ricardo Vieira, autor deste material, e o assunto que abordarei no decorrer 
do nosso estudo poderá auxiliá-lo em sua carreira e abrir caminho para o mundo dos negó-
cios, mostrando-lhe um lado mais gerenciar do processo de desenvolvimento de software. 
Com o passar do tempo, você irá se adaptar aos jargões.
 
Meu objetivo principal com este livro é apresentar os conceitos mais importantes da 
engenharia de software e discutir técnicas para gerenciar o processo de desenvolvimento 
de software. Este processo vai auxiliar você a levantar as necessidade de cada empresa 
e produto e analisar cada necessidade apresentada e escolher o melhor processo. Além 
disso, pretendo deixar claro que o uso correto dos conceitos de engenharia de software 
podem ajudá-lo a alcançar os objetivos estratégicos de sua empresa ou auxiliá-lo a colocar 
em prática uma nova ideia. 
Este livro está organizado em quatro unidades, além da apresentação e conclusão. 
Cada uma delas correspondendo a uma das partes importante do processo de desenvolvi-
mento de software.
Na primeira unidade você irá estudar os conceitos básicos da engenharia de sof-
tware, revisar um pouco da história desta engenharia tão recente em relação às demais e 
introduzir os processos de software que serão detalhados em outras unidades. 
Já na unidade II você poderá constatar que a ela está totalmente focada em 
projetos, e assim estudaremos desde o projeto arquitetural, passando pelos projetos de 
componentes, interface de usuário, e WebApps e não deixando de discutir um pouco sobre 
padrões de projetos.
APRESENTAÇÃO DO MATERIAL
Depois, na terceira unidade, falaremos sobre os processos da qualidade, apren-
dendo sobre os conceitos básicos da qualidade e as técnicas de revisão de código e arte-
fatos. Além disso, vamos discutir sobre a garantia da qualidade de software e apresentar 
estratégias de teste de software, que devem se adaptar ao processo criado para cada 
necessidade discutida na unidade I. Na última unidade, vamos entender melhor sobre o 
gerenciamento de projetos e as métricas de processo e projeto. Pois sem indicadores não 
é possível gerenciar. Vamos também discutir sobre estimativas de projeto de software e 
manutenção e reengenharia como processos necessários em alguns projetos.
Agora, mãos à obra! Tenha uma boa e agradável leitura!
SUMÁRIO
UNIDADE I ...................................................................................................... 6
Introdução da Engenharia de Software
UNIDADE II ................................................................................................... 31
Projetos de Software
UNIDADE III .................................................................................................. 57
Qualidade e Técnicas de Revisão
UNIDADE IV .................................................................................................. 81
Gerenciamento de Projetos
6
Plano de Estudo:
• Introdução e Objetivos da Engenharia de Software
• Modelos de Processo
• Princípios que Orientam a Prática
• Desenvolvimento Dirigido a plano e desenvolvimento Ágil
Objetivos de Aprendizagem:
• Capacitar o aluno a desenvolver habilidades manuais corriqueiras do dia a dia do 
profissional da área de Tecnologia da Informação;
• Proporcionar competências e habilidades para que o aluno adquira as habilidades 
básicas a respeito da Engenharia de Software, como um instrumento para modelagem de 
sistemas, no auxílio ao Planejamento de Software
UNIDADE I
Introdução da Engenharia de Software
Professor Mestre Ricardo Bortolo Vieira
7UNIDADE I Introdução da Engenharia de Software
INTRODUÇÃO
Caro(a) aluno(a), neste capítulo, trataremos de assuntos iniciais importantes paro 
o bom entendimento dos demais capítulos desta apostila. Para tanto, conceitos genéricos 
serão explicados (como software, dados, informações, engenharia de software), fornecendo 
uma visão geral, do funcionamento do processo até chegar a definição de engenharia de 
software propriamente dito e as atividades que são essenciais para esse processo, desde 
a engenharia de requisitos até os testes e evolução do software. 
Vamos estudar também o modelo de processo de software e discutir o que es-
sencialmente todo o processo de software deve ter, que são as 4 atividades principal: 
Especificação de Software, Projeto e Implementação de software, Validação de Software e 
Evolução do Software. Neste tópico vamos também trabalhar o conceito de cada um deles.
No tópico sobre desenvolvimento dirigido a plano, estudaremos a sequência de 
atividades que cada um dos modelos que seguem esse conceito trabalham. Os modelos 
estudados neste tópico serão: Modelo Cascata, modelo espiral e modelo incremental. 
Já no tópico sobre desenvolvimento ágil iremos estudar o manifesto que deu origem 
a todos estes tipos de processo o chamado manifesto ágil. Neste tópico iremos estudar 2 
modelos: o modelo XP (eXtreme Programming) e o modelo SCRUM.
Além disso, será apresentado a Linguagem de Modelagem Unificada (UML) que 
representa uma linguagem visual extremamente poderosa e não ambígua. Esta linguagem 
é muito importante para o engenheiro de software pois assim ele pode desenhar o processo 
de software baseado nas regras de negócio, independente da linguagem de desenvolvi-
mento. Ainda neste tópico conheceremos alguns exemplos de software CASE baseadas 
em UML para apoiar o processo da engenharia de software e torná-la mais eficiente e 
reutilizável. 
Então vamos lá! 
Bons estudos!
8UNIDADE I Introdução da Engenharia de Software
1 INTRODUÇÃO A ENGENHARIA DE SOFTWARE 
A maior parte dos serviços e infraestruturas são controladas atualmente por software 
(SOMMERVILLE, 2011). Ele é importante porque afeta quase todos os aspectos da nossa 
vida e está incorporado no comércio, na cultura e nas atividades cotidianas (PRESSMAN, 
2011). Por isso o mundo moderno não poderia existir sem o software (SOMMERVILLE, 
2011). 
O Software, produto final e objeto principal de todo o trabalho desenvolvimento 
dentro da engenharia de software, cada dia mais é indispensável a qualquer atividade, 
seja ela industrial, comercial ou até pessoal. As atividades que ainda não tem nenhum ou 
pouco tipo de automação de software, estão em vias de fazê-lo. Para essa atividade de 
desenvolver o produto, aplica-se o mesmo paradigma para um produto bem-sucedido da 
indústria, ou seja, adaptar o processo e torná-lo ágil para conduzir a um resultado de alta 
qualidade, atendendo as necessidades do cliente e do usuário final. Para o estudo deste 
conceito, apresentamos a engenharia de software (PRESSMAN, 2011). 
9UNIDADE I Introdução da Engenharia de Software
2 MAS O QUE SERIA UM SOFTWARE?
“Software de computadoré o produto que profissionais de software desenvol-
vem e ao qual dão suporte no longo prazo. Abrange programas executáveis 
em um computador de qualquer porte ou arquitetura, conteúdos (apresenta-
dos à medida que os programas são executados), informações descritivas 
tanto na forma impressa como na virtual, abrangendo praticamente qualquer 
mídia eletrônica.” (PRESSMAN, 2011, p.29) 
Com base nessa definição, a engenharia de software pode definir processos abran-
gentes, métodos (práticas) e um leque de ferramentas que possibilitam aos profissionais 
desenvolverem software de altíssima qualidade.
Outra questão que é importante ressaltar é que, do ponto de vista de um engenheiro 
de software, o software é um conjunto de programas, conteúdo (dados) e outros artefatos. 
Porém, do ponto de vista do usuário, o artefato consiste em informações resultantes que, 
de alguma forma, tornam a vida dele melhor.
Ainda segundo Pressman (2011), software consiste em: 
1 - Instruções (programas de computador), que, durante sua execução, podem 
fornecem características, funções e desempenho desejados;
2 - Estruturas de dados que permitem aos programas buscar e alterar informações 
da forma como os programas precisam; e 
3 - Informação descritiva, tanto na forma impressa como na virtual, e tanto para o 
foco técnico como para o usuário final, descrevendo a operação e o uso dos programas.
O software distribui basicamente informação. Ele transforma dados de modo que 
possam ser mais úteis num determinado contexto, gerencia informações comerciais para 
aumentar a competitividade, fornece um portal para redes mundiais de informação e os 
meios para obter informações de todas as formas (PRESSMAN, 2011).
Os sistemas de software são abstratos e intangíveis, não há limites naturais para 
o potencial do software, sejam pelas propriedades naturais, leis da física ou processos da 
manufatura (SOMMERVILLE, 2011).
Segundo Pressman (2011), software é mais um elemento lógico do que físico. 
Desta maneira há algumas características que o diferencia de hardware:
1. Software é desenvolvido ou passa por um processo de engenharia, ele não é 
fabricado no sentido clássico.
2. Software não se desgasta, ele não é suscetível aos males ambientais que fazem 
com que o hardware se desgaste. Não existem peças de reposição de software, 
cada defeito indica um erro no projeto;
hp
Realce
hp
Realce
10UNIDADE I Introdução da Engenharia de Software
3. A maioria dos softwares continua a ser construído de forma personalizada.
Todo projeto de software se inicia por alguma necessidade de negócios, seja ela de 
corrigir algum defeito de uma aplicação já existente, a necessidade de estender as funções 
e ou recursos ou a de criar um novo produto, serviço ou sistema (PRESSMAN, 2011).
Para Sommerville (2011), um software é um programa de computador e a docu-
mentação associada. E os produtos de software podem ser desenvolvidos para um cliente 
específico ou para o mercado em geral. Assim, produtos de software que podem ser clas-
sificados em dois tipos:
1. Produtos genéricos: existem sistemas que são feitos e colocados no mercado 
para qualquer cliente que esteja interessado em comprá-los.
2. Produto sob-encomenda: diferente dos genéricos, estes são encomendados 
por um cliente em particular de acordo com suas necessidades.
3 ENGENHARIA DE SOFTWARE
Fazer software não é uma tarefa fácil, software de qualidade é ainda mais difícil. 
Todavia, mesmo apresentando baixa qualidade, o interesse das organizações pelo desen-
volvimento de sistemas tem aumentado. Isso porque as organizações reconhecem que 
software é fonte de importantes vantagens competitivas (SILVA; VIDEIRA, 2001).
Segundo Sommerville (2011), os diversos relatos de software que deram errado e 
resultaram em “falhas de software” são conseqüências de dois fatores:
1. Aumento da demanda: Os sistemas devem ser construídos e entregues mais 
rapidamente e esses sistemas são maiores e até mais complexos. A engenharia 
de software não consegue lidar com isso, novas técnicas de engenharia de 
software precisam ser criadas para atender essas novas demandas.
2. Expectativas baixas: As empresas eram obrigadas a desenvolver software 
à medida que suas necessidades continuavam aumentando. O que torna seu 
software menos confiável e mais caro do que devia ser. Por isso é necessário 
educação e treinamento em engenharia de software para solucionar esses 
problemas.
Segundo Pressman (2011), existem inúmeros desafios que os desenvolvedores de 
software devem estar preparados para enfrentar no século XXI, por exemplo:
• Software tornou-se incorporado em todos os sentidos da nossa vida, o número 
de pessoas interessadas no que o software pode oferecer tem crescido signifi-
hp
Realce
hp
Realce
hp
Realce
11UNIDADE I Introdução da Engenharia de Software
cantemente;
• Os requisitos da tecnologia da informação demandados estão cada vez mais 
complexos;
• Pessoas, governos e negócios dependem cada vez mais de software para deci-
sões estratégicas e táticas;
• Software deve ser passível de manutenção para tolerar as mudanças necessá-
rias.
A engenharia de software é uma disciplina da engenharia que tem foco desde 
os estágios iniciais da especificação de um sistema até a manutenção de um software. A 
engenharia de software é importante por dois motivos, segundo (SOMMERVILLE, 2011):
1. Cada vez mais os indivíduos dependem de software avançado. Por isso eles 
devem ser produzidos de forma confiável, econômica e rápida;
2. Em longo prazo, é mais barato usar métodos e técnicas de engenharia de sof-
tware para sistema de software.
Uma das primeiras definições da Engenharia de Software foi dada por Fritz Bauer 
no final dos anos 60: “a definição e utilização de princípios de engenharia sólidos, de modo 
a desenvolver software econômico, confiável e que trabalha eficientemente em máquinas 
reais. Inclui um conjunto de métodos, de ferramentas e de procedimentos” (BAUER, 1971, 
p. 524).
Outra definição, mais comumente usado foi proposta por Potts na IEEE em 1993: 
“a Engenharia de Software é a aplicação de um processo sistemático, disciplinado e quan-
tificado ao desenvolvimento, operação e manutenção de software, ou seja, e Engenharia 
de Software é a aplicação de técnicas da Engenharia de Software” (POTTS, 1993, p. 20). 
Todos os tipos de sistemas precisam da engenharia de software, independente do 
fim ou da complexidade, o que diferencia são as técnicas utilizadas para chegar ao objetivo 
final (SOMMERVILLE, 2011).
A engenharia de software é importante porque ela nos capacita para o desen-
volvimento de sistemas complexos, dentro do prazo e com alta qualidade, atendendo 
as necessidades daqueles que usarão o produto. Necessidade essa que normalmente é 
expressa no início de qualquer projeto com uma simples conversa entre as partes (cliente 
e desenvolvedor) (PRESSMAN, 2011).
De acordo com Sommerville (2011), a maior parte do desenvolvimento de software 
é profissional, com um propósito específico de negócio e é normalmente criado, mantido e 
alterado por equipes. A engenharia de software busca apoiar esse desenvolvimento com 
técnicas que auxiliam na especificação, projeto e evolução de programas.
12UNIDADE I Introdução da Engenharia de Software
Quando falamos na engenharia de software, estamos falando também de toda 
documentação envolvida e configurações necessárias para o bom funcionamento do pro-
grama (SOMMERVILLE, 2011).
Segundo Sommerville (2011) existem fundamentos da engenharia de software que 
se aplica independentemente do tipo de sistema de software:
1. Devem ser desenvolvidos em um processo gerenciado e compreendido;
2. Confiança e desempenho são importantes para todos os tipos de sistema;
3. É importante entender o que os clientes esperam do sistema;
4. Deve-se fazer o melhor uso possível dos recursos existentes.
A engenharia de software é dividida em camadas, cada uma delas é descrita por 
Pressman(2011) da seguinte maneira: 
A peça fundamental que sustenta a Engenharia de Software é o Foco na Qualida-
de, qualquer abordagem de engenharia deve estar fundamentada em um comprometimento 
organizacional de qualidade.
 Em seguida, a Camada de Processos mantém as camadas de tecnologia coesas 
e possibilita o desenvolvimento de software de forma racional e dentro do prazo. Para que 
isso ocorra, uma metodologia é estabelecida, com uma base de controle de gerenciamento 
de projetos, gerenciamento de mudanças e controle de qualidade, para entrega efetiva dos 
produtos concebidos na engenharia de software (PRESSMAN, 2011).
Os Métodos fornecem as informações técnicas, com uma gama de tarefas, como 
comunicação, análise de requisitos, construção do programa, teste e suporte, para desen-
volver o software.
Por fim, as Ferramentas dão suporte automatizado ou semiautomatizado para os 
processos e métodos.
O posicionamento das camadas descritas anteriormente é ilustrado na Figura 1.
Figura 1 - Camadas da Engenharia de Software. 
Fonte: Pressman (2011)
hp
Realce
hp
Realce
13UNIDADE I Introdução da Engenharia de Software
3 MODELOS DE PROCESSO DE SOFTWARE
Um software não pode ser desenvolvido de qualquer jeito, sem seguir critérios, sem 
que se saiba qual o próximo passo a ser dado. Por isso que os conceitos relacionados à 
engenharia de software devem ser utilizados. Hoje em dia, a empresa precisa definir qual 
o seu processo de software.
Esta engenharia é realizada por pessoas (como engenheiros de software e geren-
tes) de amplo conhecimento que precisam adaptar um processo de software de acordo com 
as demandas do mercado de modo que fique apropriado aos produtos desenvolvidos e com 
suas necessidades (PRESSMAN, 2011).
Processo é um conjunto de atividades, ações e tarefas realizadas na criação de 
algum produto (PRESSMAN, 2011; SOMMERVILLE, 2011). Essas atividades podem ser 
a partir do zero em determinada linguagem de programação, ou por meio de alterações/
incrementos em sistemas já existentes (SOMMERVILLE, 2011).
 No contexto de engenharia de software, esse processo não é uma “receita” rígida 
e restrita de como desenvolver um software. É uma abordagem adaptável que possibilita 
a equipe de software realizar o trabalho de solucionar o conjunto apropriado de ações e 
tarefas. Ou seja, significa a abordagem adotada conforme um software é elaborado pela 
engenharia que pode estabilizar e organizar uma atividade que pode ser bastante caótica 
(PRESSMAN, 2011).
Tarefa é um objetivo pequeno, porém bem definido que produz um resultado tangí-
14UNIDADE I Introdução da Engenharia de Software
vel (PRESSMAN, 2011).
Uma ação pode ser definida como um conjunto de tarefas que resultam num arte-
fato de software fundamental (PRESSMAN, 2011).
Segundo Pressman (2011), a metodologia de processo é o alicerce para um pro-
cesso de engenharia de software completo. 
Para Sommerville (2011), existem muitos processos de software diferentes, mas 
todos eles incluem pelo menos quatro atividades fundamentais para a Engenharia de Sof-
tware.
1. Especificação de Software: É necessário que o cliente defina as funcionalida-
des do software que será desenvolvido, e que o software tenha suas restrições 
operacionais bem levantadas;
2. Projeto e Implementação de software: O software deve ser produzido de 
acordo com as especificações;
3. Validação de Software: Depois de produzido, o software deve ser validado 
para garantir que a demanda do cliente tenha sido atendida;
4. Evolução do Software: As funcionalidades definidas pelo cliente durante o 
desenvolvimento podem mudar e o software deve evoluir para atender tanto as 
necessidades de mudança do cliente, como do mercado.
Essas atividades genéricas podem ser usadas para o desenvolvimento de sistemas 
simples até os mais complexos. Para muitos projetos de software, essas atividades são 
aplicadas repetidamente conforme as iterações do projeto (PRESSMAN, 2011).
Diversas outras atividades apóiam as atividades fundamentais para o desenvol-
vimento de um software, são elas: controle e acompanhamento do projeto, administração 
de riscos, garantia de qualidade de software, gerenciamento da usabilidade, entre outras 
(PRESSMAN, 2011).
Em geral, os processos de software incluem atividades complexas, que como todo 
processo intelectual e criativo, depende de pessoas para tomar decisões e fazer julga-
mentos, desta maneira, não existe processo ideal, as empresas os adaptam conforme sua 
necessidade (SOMMERVILLE, 2011). Para alguns sistemas, como os críticos, é necessário 
um processo de desenvolvimento bem estruturado, já para um sistema de negócios, com 
requisitos que se alteram constantemente, um processo menos formal e mais flexível seria 
o mais indicado (SOMMERVILLE, 2011).
Mas o que acontece é que nem sempre as empresas aproveitam as boas técni-
cas da engenharia de software em seu desenvolvimento de software. E, normalmente, o 
software não atende aos requisitos do usuário, acaba demorando mais tempo para ser 
desenvolvido do que o previsto, aumentando assim, o valor do custo do software.
15UNIDADE I Introdução da Engenharia de Software
4 PRINCÍPIOS QUE ORIENTAM A PRÁTICA DOS MODELOS DE PROCESSO 
DE SOFTWARE
Todos os modelos de processos de software podem acomodar as atividades essen-
ciais descritas no tópico anterior, porém cada um deles dá uma ênfase diferente a essas 
atividades e define um fluxo de processo que invoca essas atividades de diferentes formas 
(PRESSMAN, 2011).
Os processos de software podem ser categorizados como modelo dirigido a plano 
ou como um modelo ágil. Todas as atividades planejadas com antecedência e que o pro-
gresso é avaliado por comparação com o projeto inicial se caracterizam por um modelo 
dirigido a plano. Já em um modelo ágil, o planejamento é gradativo, e por isso é mais 
fácil alterar o processo de maneira a refletir as necessidades de mudanças dos clientes. 
(SOMMERVILLE, 2011). 
Cada abordagem é indicada para diferentes tipos de software, e é necessário en-
contrar um equilíbrio entre eles.
A Figura 2 mostra as diferenças entre as abordagens dirigidas a planos e ágil para 
a especificação do sistema. Na primeira maneira, ocorrem interações nas atividades com 
documentos formais, usados para estabelecer a comunicação entre os estágios do proces-
so, então os requisitos evoluem e depois será produzida uma especificação de requisitos, 
que é entrada para o projeto e implementação. Em uma abordagem ágil, iterações ocorrem 
em todas as atividades, portanto, os requisitos e o projeto são produzidos em conjunto 
(SOMMERVILLE, 2011).
Figura 2 - Especificações dirigidas a planos e ágil. 
Fonte: Sommerville (2011)
16UNIDADE I Introdução da Engenharia de Software
Existem vários tipos de modelos de processos de software, e inclusive os artigos 
científicos continuam a propor novas adaptações. Vamos apresentar aqui, três tipos de 
modelos baseados no conceito dirigidos a plano e segundo Sommerville (2011):
• Modelo Cascata: Considera as atividades de especificação, desenvolvimento, 
validação, e evolução, fundamentais ao processo e as representa como fases 
separadas;
• Desenvolvimento Incremental: Intercala as atividades de especificação, de-
senvolvimento e validação. Um sistema é rapidamente desenvolvido através 
de especificações abstratas e a partir dele várias versões são entregues com 
refinamento contínuo;
• Modelo Espiral: Processo dirigido a riscos, onde cada volta da espiral represen-
ta uma fase do processo de software. Estas voltas são concêntricas e partem 
do centro para a marginal. A espiral mais interna pode ser o processo de estudo 
de viabilidade do software e a próxima define os requisitos, e assim por diante.
17UNIDADE I Introdução da Engenharia de Software
5 MODELOS DE DESENVOLVIMENTO DIRIGIDOS A PLANO 
 
5.1 Modelo Cascata 
Modelo de processo prescritivo, proposto para trazer ordem ao caos existente no 
desenvolvimentode software, fornecendo um roteiro razoavelmente eficaz para as equipes 
de desenvolvimento de software. O modelo cascata sugere uma abordagem seqüencial e 
sistemática, começando com levantamento de requisitos com o cliente e passando pelas 
fases de planejamento, modelagem, construção e entrega. É normalmente utilizado quando 
os requisitos são bem compreendidos ou quando adaptações ou aperfeiçoamento são bem 
definidos (PRESSMAN, 2011). 
Figura 3: Modelo Cascata. 
Fonte: Adaptado de Sommerville (2011)
5.2 Modelo Incremental 
Também é um modelo prescritivo, em que os requisitos iniciais são razoavelmente 
bem definidos, no entanto, um processo puramente linear não é usado. O fornecimento 
de partes do sistema ao usuário é necessário para que se possa refinar e expandir suas 
funcionalidades em versões posteriores (PRESSMAN, 2011). 
18UNIDADE I Introdução da Engenharia de Software
Figura 4 - Modelo Incremental. 
Fonte: Adaptado de Sommerville (2011)
5.3 Modelo Espiral 
O software é desenvolvido de maneira que possa evoluir ao longo do tempo. Acopla 
iteratividade e prototipação com os aspectos sistemáticos e controlados do modelo cascata 
(PRESSMAN, 2011). 
Figura 5 - Modelo Espiral.
Fonte: Adaptado de Sommerville (2011)
19UNIDADE I Introdução da Engenharia de Software
Existe também o chamado processo unificado, que é uma metodologia para enge-
nharia de software orientada a objetos usando a UML e reúne as melhores práticas dos 
modelos já existentes (PRESSMAN, 2011). 
6 MODELOS DE DESENVOLVIMENTO ÁGIL 
Em 2001, Kent Beck e outros dezesseis renomados desenvolvedores, autores e 
consultores da área de software assinaram o “Manifesto para o Desenvolvimento Ágil de 
Software”. Normalmente, um manifesto é associado a um movimento político emergente: 
atacando a velha guarda e sugerindo uma mudança revolucionária. De certa forma, é exa-
tamente do que trata o desenvolvimento ágil (PRESSMAN, 2011).
Por que Scrum? Criei o Scrum, junto com Ken Schwaber, há vinte anos, como 
um jeito mais rápido, confiável e eficiente de desenvolver softwares na indús-
tria de tecnologia. Até aquele momento — e até 2005 —, a maior parte do de-
senvolvimento de softwares era executada com base no método em cascata, 
de acordo com o qual um projeto era concluído em etapas distintas e levado 
passo a passo até o lançamento para Os consumidores ou usuários. O pro-
cesso era lento, imprevisível, e muitas vezes não resultava em um produto 
que as pessoas quisessem ou pelo qual se dispusessem a pagar. Atrasos 
de meses, ou até mesmo anos, eram endêmicos. Os antigos planos passo a 
passo, confortavelmente detalhados em diagramas de Gantt, davam à gerên-
cia uma sensação de que se tinha total controle sobre o desenvolvimento de 
um projeto. No entanto, na maioria esmagadora dos casos, em pouco tempo 
os atrasos em relação ao cronograma começavam e o orçamento era ultra-
passado em uma escala desastrosa.
Para superar essas falhas, inventei, em 1993, um novo jeito de fazer as coi-
sas: o Scrum. Trata-se de uma mudança radical em relação às metodologias 
prescritivas e hierarquizadas empregadas na gerência de projetos no pas-
sado. Ao contrário delas, o Scrum se assemelha a sistemas evolucionários, 
adaptativos e autocorretivos. Desde seu nascimento, a estrutura do Scrum se 
tornou a maneira como o setor de tecnologia cria novos softwares e produtos. 
Porém, apesar de ter obtido muito sucesso no gerenciamento de projetos de 
software e hardware no Vale do Silício, o Scrum permanece relativamente 
desconhecido no mundo dos negócios em geral.” (SUTHERLAND, 2016)
Embora as ideias básicas que norteiam o desenvolvimento ágil já existam a muitos 
anos, só a duas décadas que se consolidaram como um “movimento”. Dentre estes méto-
dos ágeis, existentes na literatura, vou abordar aqui, de forma sucinta, somente duas delas:
• Modelo eXtreming Programming (XP): Representa uma metodologia ágil de 
desenvolvimento de software voltada para times de pequeno a médio porte, no 
qual os requisitos são vagos e mudam frequentemente. Desenvolvido por Kent 
Beck, Ward Cunningham e Ron Jeffries. O XP tem como principal tarefa a codifi-
cação com ênfase menor nos processos formais de desenvolvimento e com uma 
maior disciplina de engenharia ágil de software para codificação e testes. Tem 
como valores a comunicação, a simplicidade, o feedback, a coragem e o respei-
20UNIDADE I Introdução da Engenharia de Software
to. O XP valoriza a automatização de testes, sendo estes criados antes, durante 
e depois da codificação. É flexível para a mudanças de requisitos, valorizando 
o feedback com o usuário e a qualidade do código-fonte final. A ideia principal 
do XP é a criação de software de alta qualidade, e orientada explicitamente às 
pessoas. Seu método é melhor apresentado na Figura 6 (WILDT, 2015); 
• Modelo SCRUM: O nome provém de uma atividade que ocorre durante a partida 
de ‘rugby’. Este método foi criado por Jeff Sutherland e sua equipe de desen-
volvimento, conforme relato dele no início deste tópico. Os princípios do Scrum 
são baseados no manifesto ágil e são usados para orientar as atividades de 
desenvolvimento dentro de um processo que incorpora as seguintes atividades 
estruturais: requisitos, análise, projeto, evolução e entrega. Em cada atividade 
metodológica, ocorrem tarefas a realizar dentro de um padrão de processo cha-
mado sprint. O trabalho realizado dentro de um sprint é adaptado ao problema 
em questão e definido, e muitas vezes modificado em tempo real, pela equipe 
Scrum. O fluxo geral do processo Scrum é ilustrado na Figura 7 (PRESSMAN, 
2011).
Figura 6 - Modelo Extreme Programming. 
Fonte: Teles (2017)
21UNIDADE I Introdução da Engenharia de Software
Figura 7 - Modelo SCRUM.
Fonte: Adaptado de Sutherland (2016)
7 UML E ORIENTAÇÃO A OBJETOS
A UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) é 
uma linguagem gráfica, utilizada para a elaboração da estrutura de projetos de software. 
Constrói modelos concisos, precisos, completos e sem ambiguidades, tendo, de maneira 
geral, as seguintes características, segundo Pereira (2011):
• Modela os aspectos estruturais (estáticos) e comportamentais (dinâmicos) do 
sistema. Em outras palavras, a UML provê elementos de notação para modelar 
dados, funções de transformação dos dados e as restrições aplicáveis aos 
dados e às funções;
• Provê uma linguagem que permite o entendimento e a utilização por humanos 
e a leitura por máquinas; 
• Provê elementos de notação para modelar todos os tipos de sistemas de com-
putação;
• Permite a modelagem do conceito ao artefato executável, utilizando técnicas 
Orientadas a Objeto (OO);
• A linguagem é extensível e adaptável a necessidades específicas; palavras-
-chave permitem que se modifique a semântica de elementos da linguagem;
22UNIDADE I Introdução da Engenharia de Software
• Contempla as necessidades de produção de modelos pequenos e simples a 
grandes e complexos;
• Modela processos manuais ou automatizados, estes independentemente da 
tecnologia que usam;
• É uma linguagem para visualização do modelo, facilitando o entendimento pelas 
equipes de análise de negócio, desenvolvimento de sistemas e pelos clientes;
• Serve para construir código de computador, embora não seja uma linguagem de 
programação de computadores;
• Está em evolução, mesmo após mais de dez anos da publicação da versão 
inicial.
De acordo com Guedes (2011), a UML é uma linguagem de modelagem e é in-
dependente de processo de software, podendo ser utilizada em modelo cascata, desen-
volvimento evolucionário, ou qualquer outro processo que esteja sendo utilizado para o 
desenvolvimento de software.
Esta linguagem utiliza diversos símbolos gráficos, e possui uma semântica bem 
definida para cada um deles, sendo possível elaborar diversos modelos. A UML tem sido 
empregada de maneira efetiva em sistemas cujos domínios abrangem: sistemas de infor-
mações corporativos,serviços bancários e financeiros, transportes, serviços distribuídos 
baseados na Web entre outros. Porém, a UML, não se limita à modelagem de software, 
podendo modelar sistemas como o fluxo de trabalho no sistema legal, a estrutura e o com-
portamento de sistemas de saúde e o projeto de hardware. 
Ela surgiu da junção de 3 grandes métodos: Método Booch de Grady Boock, Méto-
do OMT (Object Modeling Technique) de Rumbaugh e do método OOSE (Object-Oriented 
Software Engineering) de Jacobson. Esses eram, até meados da década de 1990, as três 
metodologias de modelagem orientada a objetos mais populares entre os engenheiros de 
software (GUEDES, 2011).
A UML é baseada no paradigma de orientação a objetos (OO), que está ligado a 
nove conceitos (JONES, 2001):
• Encapsulamento; 
• Ocultação de informação e Implementações;
• Retenção de Estado;
• Identidade de Objeto;
• Mensagens;
• Classes;
• Herança;
23UNIDADE I Introdução da Engenharia de Software
• Polimorfismo; e 
• Generalização.
Em sua última versão vigente, 2.5, a UML possui 14 diagramas vigentes apresen-
tados na Figura 8.
Figura 8 - Organograma da UML 2.5. 
Fonte: Adaptado de Pereira (2011)
24UNIDADE I Introdução da Engenharia de Software
FERRAMENTAS CASE
Uma ferramenta CASE (Computer-Aided Software Engineering - Engenharia de 
Software Auxiliada por Computador) é um software que, de alguma forma, colabora na 
realização de uma ou mais atividades da engenharia de software.
Ou segundo Terry (1990, p. 349), “CASE designa um conjunto de ferramentas que 
auxiliam um programador ou gestor de projetos durante uma ou mais fases do processo de 
desenvolvimento de software, incluindo a manutenção”.
Outra definição, dada por Silva e Videira (2011, p. 326) é:
“Um conjunto de técnicas e ferramentas informáticas que auxiliam o enge-
nheiro de software no desenvolvimento de aplicações, com o objetivo de di-
minuir o respectivo esforço e complexidade, de melhorar o controle do proje-
to, de aplicar sistematicamente um processo uniformizado e de automatizar 
algumas atividades e verificação da consistência e qualidade do produto final 
e geração de artefatos.” 
Para a modelagem de sistemas usando a UML, normalmente usamos as ferramen-
tas CASE, as mais conhecidas são descritas a seguir:
25UNIDADE I Introdução da Engenharia de Software
Astah Community é um software para modelagem UML (Unified Modeling Lan-
guage – Linguagem de Modelagem Unificada) com suporte a UML 2, desenvolvido pela 
Change Vision, Inc e disponível para sistemas operacionais Windows 64 bits. Anteriormente 
conhecido por JUDE, um acrônimo de Java and UML Developers Environment (Ambiente 
para Desenvolvedores UML e Java).
Astah Community disponibiliza para desenvolvimento, os diagramas de Classes, 
Casos de Uso, Sequência, Comunicação, Máquina de Estados, Atividade, Componentes, 
Implantação e Diagrama de Estrutura Composta.
Figura 9 - Logotipo do Software Astah Community 
Fonte: ASTAH (2006)
Rational Rose é uma ferramenta CASE, mais especificamente, uma ferramenta 
UML que auxilia nos processos de construção de um software profissional. Hoje em dia 
essa ferramenta tem um peso no mercado sendo usada por diversos profissionais e gran-
des empresas. Foi criada pela Rational que, posteriormente foi adquirida pela IBM em 20 
de fevereiro de 2003 e a ferramenta não é gratuita. Permite a modelagem com os quatorze 
diagramas da UML. Permite também a construção de modelos de Dados com possibilidade 
de exportação para construção da base de dados ou realização de engenharia reversa de 
uma base de dados existente. Dá suporte ao Visual Studio (pacote de programas para 
desenvolvimento de software da Microsoft). Foi sucedido pelo IBM Rational Architect.
Figura 10 - Logotipo do Software Rational Rose 
Fonte: IBM (2001)
Enterprise Architect é uma ferramenta paga com recursos de ponta e um rico 
conjunto de recursos para ajudar a gerenciar informações e inovar no ambiente complexo 
e exigente de hoje. Em conjunto com o UML 2.0 é possivel modelar, projetar e construir um 
software ou projeto comercial. Ele suporta MDA (Model-Driven Architecture) e geração de 
códigos em linguagem Java, C#, C++, VB.NET, VB, Python e DLL (Dynamic-Link Library) 
https://pt.wikipedia.org/wiki/Ferramenta_CASE
https://pt.wikipedia.org/wiki/Ferramenta_UML
https://pt.wikipedia.org/wiki/Ferramenta_UML
https://pt.wikipedia.org/wiki/Engenharia_de_software
https://pt.wikipedia.org/wiki/Software
https://pt.wikipedia.org/wiki/IBM
https://pt.wikipedia.org/wiki/20_de_fevereiro
https://pt.wikipedia.org/wiki/20_de_fevereiro
https://pt.wikipedia.org/wiki/2003
https://pt.wikipedia.org/wiki/UML
https://pt.wikipedia.org/wiki/Modelos_de_Dados
https://pt.wikipedia.org/wiki/Banco_de_dados
https://pt.wikipedia.org/wiki/Engenharia_reversa
26UNIDADE I Introdução da Engenharia de Software
para um movimento rápido da análise para o projeto e construção. Além disso, é possível 
criar relatórios, gerenciar testes, recursos e muito mais. Enterprise Architect suporta o ciclo 
de vida UML 2.0 com ótimos recursos de fóruns de discussão, construção, execução de 
códigos, suporte a MOF (Microsoft Operations Framework), WSDL (Web Services Des-
cription Language - Linguagem de Descrição de Serviços Web) e XML (Extensible Markup 
Language).
Figura 11 - Logotipo do Software Enterprise Architect 
Fonte: SPARK (2000)
Visual Paradigm for UML é uma ferramenta CASE com várias opções de modela-
gem com os diagramas da UML 2.0 e que também oferece suporte a diagramas de requi-
sitos SysML e a diagramas ER (Entidade Relacionamento). A ferramenta possui um bom 
ambiente de trabalho, o que facilita a visualização e manipulação do projeto de modelagem. 
É uma ferramenta comercial e também oferece suporte a transformações específicas para 
códigos-fonte de algumas linguagens de programação como, por exemplo, C++ e Java.
Figura 12 - Logotipo do Software Visual Paradigm 
Fonte: VISUAL-PARADIGM (2002)
27UNIDADE I Introdução da Engenharia de Software
SAIBA MAIS
Segundo Mellor (1994), na Guerra do Golfo, em 1991, um míssil Scud 
passou pelo escudo antimísseis Patriot e atingiu um acampamento militar próximo 
de Dhahran, na Arábia Saudita. Ao todo, morreram 28 soldados americanos e 98 
ficaram feridos. O software para o míssil Patriot continha uma falha de contagem de 
tempo acumulativa. O Patriot havia sido projetado para operar apenas por algumas 
horas por vez, após o que o contador de tempo era reiniciado. Como resultado, a 
falha jamais havia tido um efeito significativo e, consequentemente, não fora detec-
tada. Na Guerra do Golfo, entretanto, a bateria de mísseis Patriot em Dhahran ficou 
operando por mais de 100 horas ininterruptas. Isso fez com que a discrepância de 
tempo acumulado se tornasse suficientemente grande para fazer com que o sistema 
se tornasse impreciso. 
Durante a Guerra do Golfo, os Estados Unidos enviaram mísseis Patriot a Is-
rael para proteção contra mísseis Scud. As forças israelenses detectaram o problema 
da contagem de tempo apenas após 8 horas e relataram o problema imediatamente 
para o fabricante nos Estados Unidos. O fabricante corrigiu a falha o mais rápido 
possível, porém, tragicamente, o novo software chegou somente um dia depois de o 
acampamento ter sido atingido pelo Scud (MELLOR, 1994). 
Esta é uma das várias situações relatadas pelo autor Peter Mellor em seu 
artigo “computer-aided disaster” publicado em 1994. Peter é professor na University 
of Northampton, em Londres. Este e muitos outros relatos de tragédias com falhas 
de software nos mostram como é importante investir tempo e dinheiro em engenharia 
de software para minimizar estes impactos que as falhas de software trazem para as 
operações das empresas e para nossas vidas. 
REFLITA
“As pessoas apostam seus empregos, seu conforto, sua segurança, sua diversão, 
suas decisões e suas próprias vidas nos softwares de computadores. Eles precisam 
estar certos”. 
Roger S. Pressman- Presidente da R. S. Pressman & Associates, Inc., uma consul-
toria especializada em treinamentos e métodos em engenharia de software.
28UNIDADE I Introdução da Engenharia de Software
Nesta primeira unidade foram apresentados alguns conceitos básicos sobre en-
genharia de software que serão utilizados no decorrer de todo o livro, por isso, é muito 
importante que esses conceitos fiquem bem claros para você.
A engenharia de software foi proposta para tentar levar a precisão da engenharia 
para o desenvolvimento de software, pois até aquela época, desenvolver um software era 
algo que não podia ser mensurado, nem em relação ao custo, levando-se, normalmente, 
muito mais tempo do que o previsto. E o que acontecia era que não se tinha uma regra, uma 
sequência de atividades para o desenvolvimento. Você vai ver nas próximas unidades que, 
para tentar solucionar esse problema, os estudiosos da engenharia de software propuse-
ram vários modelos de processos de software, sendo que a empresa pode escolher o que 
melhor se adequa a ela. Isso tem ajudado muito o desenvolvimento de software. Você vai 
perceber isso durante o estudo deste livro.
Não se preocupe, pois estaremos juntos nas próximas unidades.
Até lá!
CONSIDERAÇÕES FINAIS
29UNIDADE I Introdução da Engenharia de Software
Leitura Complementar
A “View of 20th and 21st Century Software Engineering” consiste de uma visão do 
passado e do futuro da engenharia de software. É uma ótima referência para traçar um 
paralelo entre a origem da engenharia de software e como ela está se renovando e se 
adaptando a uma sociedade que cada vez mais exige eficiência dos software e além disso, 
se tornam cada vez mais dependentes dos aplicativos e programas. 
Disponível em:
<https://www.researchgate.net/publication/221554200_A_view_of_20th_an-
d_21st_century_software_engineering>
30UNIDADE I Introdução da Engenharia de Software
Material Complementar
LIVRO 
• Título: Engenharia de Software Essencial
• Autor: Leandro Costa.
• Editora: Amazon Digital Services.
• Sinopse: Você está começando no mundo da Engenharia de 
Software e quer garantir que os prazos sejam cumpridos, com a 
qualidade das entregas e com o time comprometido de verdade? 
Você quer entregar valor para seus clientes, desenvolvendo so-
luções e não criando pilhas de documentos que ninguém irá ler? 
Você se identificou? Então esse livro é para você.
FILME/VÍDEO 
• Título: O que um Engenheiro de Software faz?
• Ano: 2018.
• Sinopse: Nesse vídeo responderemos a esta pergunta que cla-
ma por uma resposta mais clara e direta! Será que conseguimos? 
De uma vez por todas: O que faz um Engenheiro de Software?
• Link do vídeo:
https://www.youtube.com/watch?v=wdU9L3DqU2w
https://www.youtube.com/watch?v=wdU9L3DqU2w
31
Plano de Estudo:
• Projeto da Arquitetura
• Projeto de Componentes
• Projeto de Interface do Usuário
• Projeto Baseado em Padrões
Objetivos de Aprendizagem:
• Esta unidade estará focada em apresentar os conceitos de Projeto de software e tornar 
o aluno familiarizado como os termos, jargões e processos dessa fase da engenharia de 
software;
• Proporcionar competências e habilidades para que o aluno desenvolva um bom projeto 
em todas as áreas apresentadas: Arquitetura, Componentes, Interface e Padrões de 
projeto.
UNIDADE II
Projetos de Software
Professor Mestre Ricardo Bortolo Vieira
32UNIDADE II Projetos de Software
INTRODUÇÃO
Olá Caro(a) aluno(a)! Neste capítulo meu objetivo é introduzir os conceitos de pro-
jeto de software, proporcionando as seguintes discussões:
• Decisões necessárias sobre a arquitetura de sis tema durante o processo de 
projeto de arquitetura;
• Os padrões de arquitetura, bem como as maneiras já experimentadas de or-
ganizar as arquiteturas de siste ma, que podem ser reusadas em projetos de 
sistemas;
• Conhecerá os padrões de arquiteturas que muitas vezes são usados em dife-
rentes tipos de sistemas de aplicações, incluindo sistemas de processamento 
de transações e os sistemas de processamento de linguagens;
• Que a engenharia de software baseada em componen tes está preocupada com 
o desenvolvimento dos componentes padronizados baseados em modelos de 
componentes, além da composição destes em sistemas de aplicações;
• compreenderá o que se entende por um componente e um mo delo de compo-
nente;
• Que o projeto de interface busca identificar objetos e ações em interfaces e criar 
um layout de tela adaptado a essa necessidade. Este processo é baseado em 
protótipo;
• Que o desenvolvimento de software baseado em padrão de projetos é foca-
do em encontrar problemas e apresentar propostas a este tipo de problema 
(solução). Assim, os padrões são apresentado conforme novos problemas são 
encontrados durante o desenvolvimento e o levantamento da arquitetura do 
sistema. 
Além disso, será apresentado a importância de cada um destes projetos, bem como 
os processos e artefatos necessários para o desenvolvimento destes projetos. 
Então vamos lá! Bons estudos!
33UNIDADE II Projetos de Software
1 PROJETO DE ARQUITETURA DE SOFTWARE
É um processo criativo no qual define-se uma organização de um sistema para sa-
tisfazer aos requisitos funcionais e não funcionais. Aspectos que influenciam a arquitetura:
• Tipo de sistema a ser desenvolvido;
• Experiência do arquiteto de sistemas;
• Requisitos específicos para o sistema.
O projeto de arquitetura está preocupado com a compreensão de como um sistema 
deve ser organizado e com a estrutura geral desse sistema. No modelo do processo de 
desenvolvimento de software, o projeto de arquitetura é o primeiro estágio no processo de 
projeto de software. Este projeto é o elo crítico entre o projeto e a engenharia de requisitos, 
pois identifica os principais componentes estruturais de um sistema e os relacionamentos 
entre eles. Os produtos dessa fase do projeto de arquitetura serão dois artefatos: o modelo 
de arquitetura, que descreve como o sistema está organizado, e o conjunto de componentes 
de comunicação (SOMMERVILLE, 2011). 
Para exemplificar a arquitetura que estou descrevendo aqui apresento a Figura 13 
que mostra a arquitetura de repositório de uma determinada IDE (Integrated Development 
Environment - Ambiente de Desenvolvimento Integrado) . Este tipo de arquitetura é usada 
para sistemas com grandes volumes de dados a serem armazenados ou em sistemas 
baseados em informação, pois quando algo é adicionado ou removido do repositório uma 
ação ou tarefa pode ser realizada. 
34UNIDADE II Projetos de Software
Figura 13 - Exemplo de arquitetura de um sistema de repositório de código fonte. 
Fonte: Adaptado de Sommerville, 2011)
Em geral, as arquiteturas de sistema são modeladas por meio de diagramas de 
blocos simples, como na Figura 13. No diagrama, cada caixa representa um componente. 
Caixas dentro de caixas indicam que o componente foi decomposto em sub-componentes. 
As setas significam que os dados e/ou sinais de controle são passados de um componente 
a outro na direção das setas. 
Diagramas de bloco são uma forma adequada de, durante o processo de projeto, 
descrever a arquitetura do sistema. Estes diagramas representam uma boa maneira de 
apoiar a comunicação entre as pessoas envolvidas no processo. Em muitos projetos, eles 
são a única documentação de arquitetura que existe. No entanto, se a arquitetura de um 
sistema deve ser bem documen tada, é melhor usar uma notação com semântica bem defi-
nida para a descrição de arquitetura. 
1.1 Visão da arquitetura
Os modelos de arquitetura de um sistema de software podem ser usados para focar 
a discussão sobre os requisitos de software ou de projeto. Além disso, podem ser usados 
para documentar um projeto para que este possa ser usado como base para um projeto e 
uma implementação mais detalhados e para a futura evolução do sistema. 
É impossível representar todas as informações relevantes sobre a arquitetura de 
um sistema em um único mo delo de arquitetura,pois cada modelo mostra apenas uma vi-
são ou perspectiva do sistema. Pode mostrar como um sistema é decomposto em módulos, 
como os processos de run-time interagem, ou as diferentes formas como são distribuídos 
35UNIDADE II Projetos de Software
os componentes do sistema através de uma rede. Tudo isso é útil em momentos diferentes, 
por tanto, para ambos, projeto e documentação, geralmente é preciso apresentar múltiplas 
visões da arquitetura de software.
Existem 4 visões de arquitetura discutidas no livro de Sommerville (2011) e concei-
tualmente mais aceitas como válidas. São elas:
1. A visão lógica, que mostra as abstrações fundamentais do sistema como ob-
jetos ou classes de objetos. Nessa visão, deveria ser possível relacionar os 
requisitos de sistema com as entidades.
2. A visão de processo, que mostra como, no tempo de execução, o sistema é 
composto de processos interativos. Essa visão é útil para fazer julgamentos 
sobre as características não funcionais do sistema, como desempenho e dispo-
nibilidade.
3. A visão de desenvolvimento, que mostra como o software é decomposto para 
o desenvolvimento, ou seja, apresenta a distribuição do software em componen-
tes que são implementados por um único desenvolvedor ou por uma equipe de 
desenvolvimento. Essa visão é útil para gerentes de software e programadores.
4. Uma visão física, que mostra o hardware do sistema e como os componentes 
de software são distribuídos en tre os processadores. Essa visão é útil para os 
engenheiros de sistemas que estão planejando uma implantação do sistema. 
Na prática, as visões conceituais são, quase sempre, desenvolvidas durante o 
processo de projeto e são usadas para apoiar a tomada de decisões de arquitetura. Elas 
são uma maneira de comunicar a essência de um sistema para os diferentes stakeholders 
(as partes envolvidas no projeto). Durante o processo de projeto, quando diferentes as-
pectos do sistema são discu tidos, outras visões também podem ser desenvolvidas, mas 
não há necessidade de uma descrição completa de todas as perspectivas. Também pode 
ser possível associar os padrões de arquitetura, com as diferentes visões de um sistema 
(SOMMERVILLE, 2011).
36UNIDADE II Projetos de Software
1.2 Padrões de arquitetura
Um padrão de arquitetura é uma descrição genérica de uma organização do sistema:
• Estrutura dos Padrões;
• Nome;
• Descrição;
• Quando é usado;
• Vantagens;
• Desvantagem.
Iremos estudar 3 tipos de arquiteturas: MVC, Repositório e Cliente-Servidor
1.2.1 MVC
Tabela 01 - O padrão modelo-visão-controle (MVC). 
Fonte: Sommerville (2011)
Nome Característica
Descrição Acrônimo para Model View and Controller. Separa a apresentação 
e a interação dos dados do sistema. O sistema é estruturado em 
três componentes lógicos que interagem entre si. O componente 
Modelo gerencia o sistema de dados e as operações associadas 
a esses dados. 0 componente Visão define e gerencia como os 
dados são apresentados ao usuário. O componente Controlador 
gerencia a interação do usuário (por exemplo, teclas, cliques do 
mouse etc.) e passa essas interações para a Visão e o Modelo. 
Quando é usado É usado quando existem várias maneiras de se visualizar e inte-
ragir com dados. Também quando são desconhecidos os futuros 
requisitos de interação e apresentação de dados. 
Vantagens Permite que os dados sejam alterados de forma independente 
de sua representação, e vice-versa. Apoia a apresentação dos 
mesmos dados de maneiras diferentes, com as alterações feitas 
em uma representação aparecendo em todas elas. 
Desvantagens Quando o modelo de dados e as interações são simples, pode 
envolver código adicional e complexidade de código. 
37UNIDADE II Projetos de Software
1.2.2 Repositório
Tabela 02 - O padrão Repositório. 
Fonte: Sommerville (2011)
Nome Característica
Descrição Todos os dados em um sistema são gerenciados em um reposi-
tório central, acessível a todos os componentes do sistema. Os 
componentes não interagem diretamente, apenas por meio do 
repositório. 
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. To-
dos os dados podem ser gerenciados de forma consistente (por 
exemplo, backups feitos ao mesmo tempo), pois tudo está em um 
só lugar. 
Desvantagens 0 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. 
1.2.3 Cliente-Servidor
Tabela 03 - O padrão Cliente-Servidor. 
Fonte: Sommerville (2011)
Nome Característica
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. 
Quando é usado é usado quando os dados em um banco de dados compartilhado 
precisam ser acessados apartir 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 falhas uscetí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. 
38UNIDADE II Projetos de Software
2 PROJETO DE COMPONENTES DE SOFTWARE
Caro(a) aluno(a), neste tópico, irei descrever uma abordagem sobre o reúso de 
software baseado na composição de componentes reusáveis, padro nizados. E segundo 
Sommerville (2011), muitos novos sistemas de negócios são desenvolvidos pela configura-
ção de sistemas disponíveis no mercado. No entanto, quando uma empresa não pode usar 
um “sistema de pratelei ra”, porque eles não atendem a seus requisitos, o software de que 
necessitam precisa ser especialmente desenvolvido. Para o desenvolvimento de software 
customizado, a engenharia de software baseada em componentes é uma forma eficaz, 
orientada ao reúso, de desenvolver novos sistemas corporativos. 
Ainda segundo Sommerville (2011), a engenharia de software baseada em com-
ponentes (CBSE, do inglês component-based software engineering) surgiu na década de 
1990 como uma abordagem para softwares de desenvolvimento de sistemas com base no 
reúso de compo nentes de softwares. Sua criação foi motivada pela frustração de proje-
tistas, pois o desenvolvimento orientado a objetos não levou a um amplo reúso, como se 
havia sugerido. As classes de objetos foram muito detalhadas e específicas e muitas vezes 
precisavam ser associadas com uma aplicação em tempo de compilação. Era preciso ter 
conhecimento detalhado das classes para usá-las e isso geralmente significava que era 
necessário ter o código-fonte do componente, o que signifi cava que vender ou distribuir 
objetos como componentes reusáveis individuais era praticamente impossível. 
39UNIDADE II Projetos de Software
Os fundamentos da engenharia de software baseada em componentes, segundo 
Sommerville (2011), são:
1. Os componentes independentes que são completamente especificados por suas 
interfaces. Deve haver uma se paração clara entre a interface decomponente 
e sua implementação. Isso significa que a implementação de um componente 
pode ser substituída por outra, sem que se alterem outras partes do sistema.
2. Os padrões de componentes que facilitam a integração destes. Essas normas 
são incorporadas a um modelo de componentes. Eles definem, no mínimo, como 
interfaces de componentes devem ser especificadas e como os componentes 
se comunicam. Alguns modelos vão muito mais longe e definem as interfaces 
que devem ser imple mentadas por todos os componentes. Se os componentes 
estão em conformidade com os padrões, sua operação é independente de sua 
linguagem de programação. Componentes escritos em linguagens diferentes 
podem ser integrados ao mesmo sistema.
3. O middleware que fornece suporte de software para a integração de componen-
tes. Para tornar independentes, os componentes distribuídos trabalham juntos; 
você precisa de suporte de middleware que lide com as comunicações de 
componentes. O middleware para suporte ao componente lida, com eficiência, 
com questões de nível inferior e permite que você se concentre nos problemas 
relacionados com a aplicação. Além disso, o middleware para su porte de com-
ponentes pode fornecer suporte para alocação de recursos, gerenciamento de 
transações, proteção e concorrência.
4. Um processo de desenvolvimento que é voltado para a engenharia de software 
baseada em componentes. Você precisa de um processo de desenvolvimento 
que permita que os requisitos evoluam, dependendo da funcionalida de dos 
componentes disponíveis. 
A CBSE apoia-se nos seguintes princípios de projeto na construção de softwares 
compreensíveis e passíveis de manutenção:
1. Componentes são independentes, então eles não interferem na operação 
uns dos outros. Detalhes de implemen tação são ocultados. Implementação dos 
componentes pode ser alterada sem afetar o restante do sistema.
2. Os componentes comunicam-se por meio de interfaces bem definidas. Se 
essas interfaces forem mantidas, um componente poderá ser substituído por 
outro, que forneça funcionalidade adicional ou aumentada.
40UNIDADE II Projetos de Software
3. As infraestruturas dos componentes oferecem uma gama de servi-
ços-padrão que podem ser usados em sistemas de aplicações, o 
que reduz a quantidade de códigos novos a serem desenvolvidos. 
 
2.1 Modelo de Componentes 
Para Sommerville (2011), a Tabela 4 mostra o que deve ser considerado como 
característica para um componentes seguindo os preceitos da CBSE.
Tabela 04 - Característica de um componente. 
Fonte: Sommerville (2011)
Característica do 
componente
Descrição
Padronizado A padronização de componentes significa que um componente 
usado em um processo CBSE precisa obedecer a um modelo de 
componentes padrão. Esse modelo pode definir as interfaces de 
componentes, metadados de componente, documentação, com-
posição e implantação. 
Independente Um componente deve ser independente, deve ser possível compor 
e implantá-lo sem precisar usar outros componentes específicos. 
Nessas situações, em que o componente precisa dos serviços 
prestados externamente, estes devem ser explicitamente defini-
dos em uma especificação de interface ‘requires’. 
Passível de com-
posição
Para um componente ser composto, todas as interações externas 
devem ter lugar por meio de interfaces publicamente definidas. 
Além disso, ele deve proporcionar acesso externo a informações 
sobre si próprio, como seus métodos e atributos. 
Implantável Para ser implantável, um componente dever ser autocontido. 
Deve ser capaz de operar como uma entidade autônoma em uma 
plataforma de componentes que forneça uma implementação do 
modelo de componentes, o que geralmente significa que o com-
ponente é binário e não tem como ser compilado antes de ser 
implantado. Se um componete é implantado como um serviço, ele 
não precisa ser implantado por um usuário de um componente. 
Pelo contrário, é implantado pelo prestador do serviço. 
Documentado Os componentes devem ser completamente documentados para 
que os potenciais usuários possam decidir se satisfazem a suas 
necessidades. A sintaxe e, idealmente, a semântica de todas as 
interfaces de componentes devem ser especificadas. 
 
Os componentes têm duas interfaces relacionadas, como mostrado na Figura 14. Essas in-
terface refletem os serviços que o componente fornece e os serviços de que o componente 
necessita para funcionar corretamente:
41UNIDADE II Projetos de Software
• A interface ‘provides’ define os serviços prestados pelo componente. Essa inter-
face, essencialmente, é uma API (Application Programming Interface - Interface 
de Programação de Aplicativo) de componente. Ela define os métodos que 
podem ser chamados por um usuário do componente. 
• A interface ‘requires’ especifica quais serviços devem ser fornecidos por outros 
componentes no sistema se um componente deve funcionar corretamente. Se 
eles não estiverem disponíveis, o componente não funcionará. Isso não compro-
mete a independência ou a capacidade de implantação de um componente, pois 
a interface ‘requires’ não define como esses serviços deverão ser prestados. 
Figura 14 - Interface de componentes. 
Fonte: Sommerville (2011)
Os elementos básicos de um modelo ideal de componentes são apresentados na 
Figura 15, em um diagrama que mostra os elementos de um modelo de componentes e 
domo eles definem a utilização e a processo de implantação (SOMMERVILLE, 2011).
1. Interfaces. Os componentes são definidos pela especificação de suas interfaces. 
O modelo de componente especifica como as interfaces devem ser definidas e 
os elementos, como nomes de operação, parâmetros e exceções, que devem 
ser incluídos na definição de interface. O modelo também deve especificar a 
linguagem usada para definir as interfaces de componente. Alguns modelos de 
componentes exigem interfaces especí ficas que devem ser definidas por um 
componente. Esses modelos são usados para compor o componente com a 
infraestrutura de modelo de componente, que fornece serviços padronizados, 
como gerenciamento de proteção e transação.
2. Uso. Para que componentes sejam distribuídos e acessados remotamente, eles 
precisam ter um nome exclu sivo ou identificador associado a eles. Isso deve ser 
globalmente exclusivo — por exemplo, no EJB, um nome hierárquico é gerado 
com a raiz baseada em um nome de domínio de Internet. Os serviços têm um 
único URI (Uniform Resource Identifier).
42UNIDADE II Projetos de Software
 
Figura 15 - Elementos básicos de um modelo de componentes. 
Fonte: Sommerville (2011)
2.2 Processos CBSE
Os processos CBSE são processos de software que oferecem suporte a engenha-
ria de software baseada em componentes. Consideram as possibilidades de reúso e as 
diferentes atividades do processo envolvidas no de senvolvimento e uso de componentes 
reusáveis. A Figura 16 apresenta uma visão geral dos processos CBSE. 
• Desenvolvimento para reúso. Esse processo está interessado no desenvolvi-
mento de componentes ou serviços que serão reusados em outras aplicações. 
Esse processo geralmente envolve generalizar os componentes exis tentes.
• Desenvolvimento com reúso. Esse é o processo de desenvolvimento de novas 
aplicações usando componentes e serviços existentes. 
Esses processos têm objetivos diferentes e, portanto, incluem atividades diferentes. 
No desenvolvimento por processo de reúso, o objetivo é produzir um ou mais componentes 
reusáveis. Você conhece os com ponentes com os quais trabalhará, além de ter acesso 
a seu código-fonte para generalizá-lo. Em desenvol vimento com reúso, você não sabe 
quais componentes estão disponíveis, por isso você precisa descobrir esses componentes 
e projetar seu sistema para fazer o uso mais eficiente deles. Você não pode ter acesso ao 
código-fonte do componente.
Na Figura 16, você pode ver que os processos básicos CBSE com e para reúso 
apoiam os processos que estão preocupados com a aquisição decomponente, gerencia-
mento de componente e certificação de componente. 
43UNIDADE II Projetos de Software
Figura 16 - Processos CBSE.
Fonte: Sommerville (2011)
44UNIDADE II Projetos de Software
3 PROJETO DE INTERFACE DE USUÁRIO
Caro(a) aluno(a), neste capítulo, iremos discutir sobre a Interface com o Usuário e 
a importância dela para os softwares e aplicativos da atualidade. 
Conforme PFLEIGER (2004), o tipo de projeto Interface de Usuário, produz uma 
parte fundamental de um software. Ele é a parte do sistema visível para o usuário, através 
da qual, ele se comunica para realizar suas tarefas. Pode se tornar uma fonte de motivação 
e até, dependendo de suas características, uma grande ferramenta para o usuário, ou 
então, se mal projetada, pode se transformar em um ponto decisivo na rejeição de um 
sistema. 
As interfaces atuais têm como objetivo fornecer uma interação pessoa-computador 
o mais “amigável” possível (pois na verdade não são). Dessa forma, ela deve ser fácil 
de ser usada pelo usuário, fornecendo seqüências simples e consistentes de interação, 
mostrando claramente as alternativas disponíveis a cada passo da interação sem confundir 
nem deixar o usuário inseguro. Ela deve passar despercebida para que o usuário possa se 
fixar somente no problema que deseja resolver utilizando o sistema. 
Visando tornar a interação com o usuário mais natural e menos hostil, às interfaces 
passaram a ser constituídas, entre outros itens, por elementos gráficos, onde imagens 
representando dados e tarefas disponíveis são manipuladas diretamente pelo usuário. Na 
realidade, tais itens não constituem os dados nem as tarefas; são apenas seus signos, isto 
é tudo que possa ser assumido como um substituto significante de outra coisa qualquer.
45UNIDADE II Projetos de Software
Segundo Mandel (1997) as três regras de ouro dos projetos de interface de usuário 
são:
1. Deixar o usuário no comando;
2. Reduzir a carga de memória do usuário;
3. Tornar a interface consistente.
Essas regras formam, na verdade, a base para um conjunto de princípio para o 
projeto de interface do usuário que orienta esse importante aspecto do projeto de software.
3.1 Usuário no Comando
A maioria das restrições de interface impostas por um designer tem a intenção de 
simplificar o modo de interação. Mas para quem?
Como designer, você pode se sentir tentado a introduzir restrições e limitações 
para simplificar a implementação da interface. O resultado pode ser uma interface fácil 
de construir, mas frustrante de usar. Mandel (1997) define vários princípios de design que 
permitem ao usuário manter este controle tão desejado:
• Defina os modos de interação de uma maneira que não force o usuário a ações 
desnecessárias ou indesejadas;
• Providencie interação flexível. Como usuários diferentes têm diferentes prefe-
rências de interação, as opções devem ser fornecidas;
• Permitir que a interação do usuário seja interrompível e que possa ser desfeita;
• Agilize a interação à medida que os níveis de habilidade avançam e permitem 
que a interação seja personalizada;
• Ocultar internos técnicos do usuário casual. A interface do usuário deve mover 
o usuário para o mundo virtual do aplicativo; 
• Design para interação direta com objetos que aparecem na tela. 
3.2 Reduzir a carga de memória do usuário 
Quanto mais um usuário tiver de se lembrar, mais sujeita a erros será a interação 
com o sistema. É por essa razão que uma interface do usuário bem desenhada não exaure 
a memória do usuário. Sempre que possível, o sistema deve “se lembrar” de informações 
pertinentes e auxiliar o usuário em um cenário de interação que o ajude a recordar-se. 
Mandel (1997) define princípios de projeto que possibilitam a uma interface reduzir a carga 
de memória do usuário:
• Reduza a demanda de memória recente;
46UNIDADE II Projetos de Software
• Estabeleça defaults significativos;
• Defina atalhos intuitivos;
• O layout visual da interface deve se basear na metáfora do mundo real;
• Revele as informações de maneira progressiva. A interface deve ser organizada 
hierarquicamente. 
 
3.3 Tornar a interface consistente
A interface deve apresentar e obter informações de forma consistente. Isso implica: 
1. Todas as informações visuais são organizadas de acordo com regras de projeto 
mantidas ao longo de todas as exibições de telas; 
2. Mecanismos de entrada são restritos a um conjunto limitado que é usado de 
forma consistente por toda a aplicação;
3. Mecanismos de navegação para passar de uma tarefa a outra são definidos e 
implementados de maneira consistente. 
Mandel (1997) define um conjunto de princípios de projeto que ajudam a tornar a 
interface consistente:
• Permita ao usuário inserir a tarefa atual em um contexto significativo. Muitas 
interfaces implementam camadas de interações complexas com dezenas de 
imagens de tela;
• Mantenha a consistência ao longo de uma família de aplicações;
• Se modelos interativos anteriores tiverem criado expectativa nos usuários, não 
faça alterações a menos que haja uma forte razão para isso. 
47UNIDADE II Projetos de Software
4 PADRÕES DE PROJETO
Caro(a) aluno(a), neste capítulo, trataremos de padrões de projeto. Este assunto 
trata sobre soluções gerais para um problema que ocorre com frequência dentro do contex-
to de projetos de software.
Segundo Pressman (2011), O projeto baseado em padrões cria uma nova apli-
cação através da busca de um conjunto de soluções comprovadas para um conjunto de 
problemas claramente delineados. Cada problema é descrito por um padrão de projeto 
que foi catalogado e investigado por outros engenheiros de software que depararam com 
o problema e implementaram a solução ao projetarem outras aplicações. Cada padrão de 
projeto nos oferece uma abordagem comprovada para parte do problema a ser resolvido.
Ainda segundo Pressman (2011), um engenheiro de software examina cada pro-
blema que surge para uma nova aplicação e tenta encontrar uma solução relevante por 
meio de pesquisa em um ou mais repositórios de padrões. Ao usarmos padrões de projeto, 
podemos encontrar uma solução comprovada para um problema específico. À medida que 
cada padrão é aplicado, são integradas soluções, e a aplicação a ser construída se aproxi-
ma cada vez mais de um projeto completo.
48UNIDADE II Projetos de Software
Os melhores projetistas, de qualquer área, têm uma habilidade excepcional de 
visualizar padrões que caracterizam um problema e padrões correspondentes que podem 
ser combinados para criar a solução. 
Embora o projeto baseado em padrões seja relativamente novo no campo de de-
senvolvimento de software, a tecnologia industrial tem usado projeto baseado em padrões 
há décadas, talvez há séculos. Catálogos de mecanismos e configurações padronizadas 
fornecem elementos de projeto que são usados para criar automóveis, aeronaves, máqui-
nas-ferramenta e robôs. A aplicação de projeto baseado em padrões ao desenvolvimento 
de software promete os mesmos benefícios para o software como os já proporcionados à 
tecnologia industrial: previsibilidade, redução de riscos e maior produtividade.
4.1 Contexto do projeto baseado em padrões
Ao longo do processo de projeto, e segundo Pressman (2011), devemos buscar 
toda oportunidade de aplicar padrões de projeto existentes em vez de criar novos.
O projeto baseado em padrões não é utilizado isoladamente. Os conceitos e as 
técnicas discutidas para projeto da arquitetura, de componentes e para interfaces do usuá-
rio são usados em conjunto com uma abordagem baseada em padrões. O conjunto de 
diretrizes e atributos de qualidade serve como base para todas as decisões de projeto de 
software. As próprias decisões são influenciadas por um conjunto de conceitos de projeto 
fundamentais que são atingidos usando-se heurística que evoluiu ao longo de várias dé-
cadas e práticas melhores propostas para fazer com que o projeto seja mais fácil de ser 
realizadoe mais efetivo como base para a construção (PRESSMAN, 2011).
O papel do projeto baseado em padrões está ilustrado na Figura 17. Um projetista 
de software inicia com um modelo de requisitos que apresenta uma representação abstrata 
do sistema. O modelo de requisitos descreve o conjunto de problemas, estabelece o con-
texto e identifica o sistema de forças que exerce domínio. Talvez sugira o projeto de maneira 
abstrata, mas o modelo de requisitos faz pouco para representar o projeto explicitamente.
Ao iniciar seu trabalho como projetista, é sempre importante manter os atributos 
de qualidade como foco principal. Esses atributos estabelecem uma maneira de avaliar a 
qualidade do software, mas pouco fazem para ajudar a atingi-lo efetivamente.
49UNIDADE II Projetos de Software
Figura 17 - Contexto do projeto baseado em padrões.
Fonte: Pressman (2011)
Consequentemente, devemos aplicar técnicas comprovadas para traduzir as abs-
trações contidas no modelo de requisitos de maneira mais concreta que é o projeto de 
software. Para tanto, usaremos os métodos e as ferramentas de modelagem disponíveis 
para projeto da arquitetura, de componentes e para interfaces. Mas apenas quando de-
pararmos com um problema, um contexto e um sistema de forças que ainda não foram 
resolvidos anteriormente. Se já existir uma solução, devemos usá-la, e isso significa aplicar 
uma abordagem de projeto baseado em padrões.
4.2 Padrões de Projeto de Arquitetura
Conforme Pressman (2011), os padrões de arquitetura para software definem uma 
abordagem específica para tratar alguma característica do sistema e definem uma série 
de domínios de padrões de arquitetura. Exemplos representativos são apresentados por 
Pressman (2011):
Controle de acesso. Há várias situações em que o acesso a dados, recursos e 
50UNIDADE II Projetos de Software
funcionalidade fornecidos por uma aplicação é limitado a usuários finais especificamente 
definidos. Do ponto de vista da arquitetura, o acesso a alguma parte da arquitetura de 
software deve ser rigorosamente controlado.
Concorrência. Muitas aplicações têm de tratar múltiplas tarefas em um modo que 
simule paralelismo (isso ocorre sempre que vários componentes ou tarefas “paralelas” são 
administradas por um único processador). Há uma série de maneiras diferentes com a qual 
uma aplicação pode tratar a concorrência, e cada uma delas pode ser apresentada por um 
padrão de arquitetura distinto. Por exemplo, uma abordagem é usar um padrão Operating 
System Process Management (Sistema Operacional de Gerenciamento de processos) que 
fornece recursos embutidos no sistema operacional que permitem aos componentes exe-
cutarem de forma concorrente. O padrão também incorpora funcionalidade que gerencia a 
comunicação entre processos, agendamento e outras capacidades exigidas para alcançar 
a concorrência. 
Distribuição. O problema da distribuição trata a maneira pela qual os sistemas ou 
componentes nos sistemas se comunicam entre si em um ambiente distribuído. São consi-
derados dois subproblemas: (1) a maneira pela qual as entidades se conectam entre si e (2) 
a natureza da comunicação que ocorre. O padrão de arquitetura mais comum estabelecido 
para tratar o problema de distribuição é o padrão Broker (agente). Um agente atua com um 
“intermediário” entre o componente-cliente e o componente-servidor. O cliente envia uma 
mensagem ao agente (contendo todas as informações apropriadas para a comunicação a 
ser efetuada) e o agente completa a conexão.
Persistência. Os dados persistem se sobreviverem depois da execução do pro-
cesso que o criou. Os dados persistentes armazenados em um banco de dados ou arquivo 
podem ser lidos ou modificados por outros processos posteriormente. Em ambientes orien-
tados a objetos, a ideia de um objeto persistente estende um pouco mais o conceito de 
persistência. Os valores de todos os atributos do objeto, o estado geral do objeto e outras 
informações complementares são armazenados para recuperação e uso futuro. Em geral, 
usam-se dois padrões de arquitetura para obter a persistência — o padrão Database Ma-
nagement System (sistema de gerenciamento de bancos de dados), que aplica o recurso 
de armazenamento e recuperação de um DBMS à arquitetura da aplicação, ou o padrão 
Application Level-Persistence (persistência no nível de aplicação) que constrói recursos de 
persistência na arquitetura da aplicação.
51UNIDADE II Projetos de Software
Antes que qualquer um dos padrões de arquitetura citados anteriormente possa ser 
escolhido, ele deve ser avaliado em termos de sua adequação para a aplicação e estilo de 
arquitetura geral, bem como o contexto e o sistema de forças que ele especifica.
4.3 Padrões de Projeto de Componentes
Ainda conforme Pressman (2011), os padrões de projeto de componentes nos 
dão soluções comprovadas que tratam um ou mais subproblemas extraídos do modelo de 
requisitos. Em muitos casos, os padrões de projeto desse tipo se concentram em algum 
elemento funcional de um sistema. Por exemplo, em uma aplicação web temos o seguinte 
subproblema de projeto: Como podemos obter especificações de um determinado produto 
e suas informações relacionadas para um site de vendas?
Tendo enunciado o subproblema que deve ser resolvido, devemos considerar agora 
o contexto e o sistema de forças que afetam uma solução. Assim, podemos perceber que a 
solução para o subproblema envolve uma pesquisa. Como pesquisar é um problema muito 
comum, não deve ser nenhuma surpresa a existência de muitos padrões relacionados à 
pesquisa. Pressman (2011) apresenta alguns destes padrões: 
• AdvancedSearch. Os usuários precisam encontrar um item específico em um 
grande conjunto de itens.
• HelpWizard. Os usuários precisam de ajuda sobre certo tópico relativo ao site 
ou quando eles precisam encontrar uma página específica dentro deste site.
• SearchArea. Os usuários precisam encontrar uma página Web.
• SearchTips. Os usuários precisam saber como controlar o mecanismo de bus-
ca.
• SearchResults. Os usuários têm de processar uma lista de resultados de uma 
busca.
• SearchBox. Os usuários têm de encontrar um item ou informações específicas.
4.4 Padrões de Projeto de Interface de Usuário
Foram propostas centenas de padrões para interfaces do usuário nos últimos anos. 
A maior parte deles cai em uma das seguintes categorias de padrões apresentados a seguir. 
52UNIDADE II Projetos de Software
Toda a Interface com o Usuário fornece orientação para estrutura de alto nível e navegação 
por toda a interface. Pressman (2011) apresenta algumas categorias de padrões na Tabela 
05.
Tabela 05 - Tipos de Padrões de Projeto de Interface de Usuário. 
Fonte: Pressman (2011)
Padrão Descrição Detalhes
TopLevelNavigation Usada quando um site ou 
uma aplicação implementa 
uma série de funções prin-
cipais. Oferece um menu de 
alto nível, geralmente aco-
plado a um logo ou imagem 
identificadora, que possibilita 
a navegação direta para 
qualquer uma das principais 
funções do sistema.
Funções principais (em geral 
limitadas a quatro a sete 
nomes de função) são lista-
das na parte superior da tela 
(possível também formatos 
de colunas verticais) em uma 
linha horizontal de texto. Cada 
nome fornece um link para uma 
fonte de informações ou função 
apropriada. Geralmente, usada 
com o padrão BreadCrumbs 
discutido mais à frente.
CardStack Usado quando uma série de 
subfunções ou categorias de 
conteúdo específicas rela-
cionadas com um recurso ou 
função deve ser selecionada 
em ordem aleatória. Dá a 
aparência de uma pilha de fi-
chas indexadoras, cada uma 
delas selecionável com um 
clique de mouse e cada qual 
representando subfunções 
ou categorias de conteúdo 
específicas.
As fichas indexadoras são uma 
metáfora bem compreendida e 
fácil para o usuário manipular. 
Cada ficha indexadora (se-
parador) pode ter um formato 
ligeiramente diverso. Alguns 
poderão exigir entrada de da-
dos e possuir botões ou outros