Fundamentos Da Engenharia De Software-1

Prévia do material em texto

Fundamentos daFundamentos da
Engenharia de SoftwareEngenharia de Software
AUTORIA
Ricardo Bortolo Vieira
Bem vindo(a)!
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
desenvolvimento de software.
Na primeira unidade você irá estudar os conceitos básicos da engenharia de
software, 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.
Depois, na terceira unidade, falaremos sobre os processos da qualidade, aprendendo
sobre os conceitos básicos da qualidade e as técnicas de revisão de código e
artefatos. 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! 
Unidade 1
Introdução da Engenharia
de Software
AUTORIA
Ricardo Bortolo Vieira
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
de�niçã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
essencialmente todo o processo de software deve ter, que são as 4 atividades
principal: Especi�caçã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 Uni�cada (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 desenvolvimento. 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 e�ciente e reutilizável. 
Então vamos lá! 
Bons estudos! 
Introdução a Engenharia
de Software
AUTORIA
Ricardo Bortolo Vieira
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 �nal 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 �nal. Para o estudo deste conceito, apresentamos a engenharia
de software (PRESSMAN, 2011). 
Mas o que seria um
Software?
AUTORIA
Ricardo Bortolo Vieira
"Software de computador é o produto que pro�ssionais de software desenvolvem e
ao qual dão suporte no longo prazo. Abrange programas executáveis em um
computador de qualquer porte ou arquitetura, conteúdos (apresentados à 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 de�nição, a engenharia de software pode de�nir processos
abrangentes, métodos (práticas) e um leque de ferramentas que possibilitam aos
pro�ssionais 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 �nal, 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;
3. A maioria dos softwares continuaa 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
documentação associada. E os produtos de software podem ser desenvolvidos para
um cliente especí�co ou para o mercado em geral. Assim, produtos de software que
podem ser classi�cados 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.
Engenharia de Software
AUTORIA
Ricardo Bortolo Vieira
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
desenvolvimento 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 con�á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 desa�os 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
signi�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
decisõ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 especi�caçã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 con�ável, econômica e rápida;
2. Em longo prazo, é mais barato usar métodos e técnicas de engenharia de
software para sistema de software.
Uma das primeiras de�nições da Engenharia de Software foi dada por Fritz Bauer no
�nal dos anos 60: “a de�nição e utilização de princípios de engenharia sólidos, de
modo a desenvolver software econômico, con�ável e que trabalha e�cientemente
em máquinas reais. Inclui um conjunto de métodos, de ferramentas e de
procedimentos” (BAUER, 1971, p. 524).
Outra de�niçã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
quanti�cado 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
�m ou da complexidade, o que diferencia são as técnicas utilizadas para chegar ao
objetivo �nal (SOMMERVILLE, 2011).
A engenharia de software é importante porque ela nos capacita para o
desenvolvimento 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 é
pro�ssional, com um propósito especí�co 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 especi�cação, projeto e evolução de
programas.
Quando falamos na engenharia de software, estamos falando também de toda
documentação envolvida e con�gurações necessárias para o bom funcionamento
do programa (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. Con�anç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 Qualidade,
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
desenvolver o software.
Por �m, 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.
Ferramentas
Métodos
Processo
Foco na qualidade
Fonte: Pressman (2011)
Modelos de Processo de
Software
AUTORIA
Ricardo Bortolo Vieira
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
de�nir qual o seu processo de software.
Esta engenharia é realizada por pessoas (como engenheiros de software e gerentes)
de amplo conhecimento que precisam adaptar um processo de software de acordo
com as demandas do mercado de modo que �que 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, signi�ca 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 de�nido que produz um resultado
tangível (PRESSMAN, 2011).
Uma ação pode ser de�nida como um conjunto de tarefas que resultam num
artefato de software fundamental (PRESSMAN, 2011). 
Segundo Pressman (2011),a metodologia de processo é o alicerce para um processo
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
Software. 
Especi�cação de Software: É necessário que o cliente de�na as funcionalidades do
software que será desenvolvido, e que o software tenha suas restrições operacionais
bem levantadas;
Projeto e Implementação de software: O software deve ser produzido de acordo
com as especi�cações;
Validação de Software: Depois de produzido, o software deve ser validado para
garantir que a demanda do cliente tenha sido atendida;
Evolução do Software: As funcionalidades de�nidas 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
desenvolvimento 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
julgamentos, 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 �exível seria o mais indicado (SOMMERVILLE, 2011).
Mas o que acontece é que nem sempre as empresas aproveitam as boas técnicas 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. 
Princípios que orientam a
prática dos modelos de
processo de software
AUTORIA
Ricardo Bortolo Vieira
Todos os modelos de processos de software podem acomodar as atividades
essenciais descritas no tópico anterior, porém cada um deles dá uma ênfase
diferente a essas atividades e de�ne um �uxo 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
progresso é 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 re�etir as necessidades de
mudanças dos clientes. (SOMMERVILLE, 2011). 
Cada abordagem é indicada para diferentes tipos de software, e é necessário
encontrar um equilíbrio entre eles.
A Figura 2 mostra as diferenças entre as abordagens dirigidas a planos e ágil para a
especi�caçã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 processo, então os requisitos evoluem e depois será produzida uma especi�caçã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 - Especi�cações dirigidas a planos e ágil.
Desenvolvimento baseado em planos
Desenvolvimento ágil
Engenharia
de requisitos
Engenharia
de requisitos
Projeto e
implementação
Projeto e
implementação
Especificação
de requisitos
Solicitação de mudança
de requisitos
Fonte: Sommerville (2011)
Existem vários tipos de modelos de processos de software, e inclusive os artigos
cientí�cos 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 especi�cação, desenvolvimento,
validação, e evolução, fundamentais ao processo e as representa como fases
separadas;
Desenvolvimento Incremental: Intercala as atividades de especi�cação,
desenvolvimento e validação. Um sistema é rapidamente desenvolvido através
de especi�cações abstratas e a partir dele várias versões são entregues com
re�namento contínuo;
Modelo Espiral: Processo dirigido a riscos, onde cada volta da espiral
representa 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 de�ne os requisitos, e assim
por diante.
Modelos de
desenvolvimento dirigidos
a plano
AUTORIA
Ricardo Bortolo Vieira
Modelo Cascata 
Modelo de processo prescritivo, proposto para trazer ordem ao caos existente no
desenvolvimento de software, fornecendo um roteiro razoavelmente e�caz 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 de�nidos (PRESSMAN, 2011). 
Figura 3: Modelo Cascata.
Requerimento
Projeto
Especificação
de requisitos
Especificação
de requisitos
Especificação
de requisitos
Fonte: Adaptado de Sommerville (2011)
Modelo Incremental 
Também é um modelo prescritivo, em que os requisitos iniciais são razoavelmente
bem de�nidos, no entanto, um processo puramente linear não é usado. O
fornecimento de partes do sistema ao usuário é necessário para que se possa re�nar
e expandir suas funcionalidades em versões posteriores (PRESSMAN, 2011). 
Figura 4 - Modelo Incremental.
Comunicação
Incremento n
Fu
nc
io
na
lid
ad
es
 e
 c
ar
ac
te
rí
st
ic
as
 d
o 
pr
oj
et
o
Tempo do projeto
Incremento 2
Incremento 1
Entrega n
Entrega 2
Entrega 1
núcleo do produto
Planejamento
Modelagem
Construção
Implantação
Comunicação
Planejamento
Modelagem
Construção
Implantação
Comunicação
Planejamento
Modelagem
Construção
Implantação
Fonte: Adaptado de Sommerville (2011)
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.
Determinar
objetivos
Planejar próxima
interação
Desenvolver
e testar
Identificar e
resolver riscos
Fonte: Adaptado de Sommerville (2011)
Existe também o chamado processo uni�cado, que é uma metodologia para
engenharia de software orientada a objetos usando a UML e reúne as melhores
práticas dos modelos já existentes (PRESSMAN, 2011).  
Modelos de
desenvolvimento ágil
AUTORIA
Ricardo Bortolo Vieira
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, é exatamente 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, con�ável e e�ciente de desenvolver
softwares na indústria de tecnologia. Até aquele momento — e até
2005 —, a maior parte do desenvolvimento 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
paraOs consumidores ou usuários. O processo 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ência 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 ultrapassado em uma escala
desastrosa. 
Para superar essas falhas, inventei, em 1993, um novo jeito de fazer as
coisas: o Scrum. Trata-se de uma mudança radical em relação às
metodologias prescritivas e hierarquizadas empregadas na gerência de
projetos no passado. 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étodos á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
codi�cação com ênfase menor nos processos formais de desenvolvimento e
com uma maior disciplina de engenharia ágil de software para codi�cação e
testes. Tem como valores a comunicação, a simplicidade, o feedback, a
coragem e o respeito. O XP valoriza a automatização de testes, sendo estes
criados antes, durante e depois da codi�cação. É �exível para a mudanças de
requisitos, valorizando o feedback com o usuário e a qualidade do código-fonte
�nal. 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
desenvolvimento, 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 chamado sprint. O trabalho realizado dentro de um sprint é adaptado
ao problema em questão e de�nido, e muitas vezes modi�cado em tempo real,
pela equipe Scrum. O �uxo geral do processo Scrum é ilustrado na Figura 7
(PRESSMAN, 2011).
Figura 6 - Modelo Extreme Programming.
Planning/Feedback Loops
Release Plan
Code
Interation plan
Months
Weeks
Days
One day
Hours
Minutes
Seconds
Acceptance Test
Stand Up Meeting
Pair Negotiation
Pair programming
Unit Test
Fonte: Teles (2017)
Figura 7 - Modelo SCRUM.
SCRUM
feedback
Incremento
Potencialmente
Estragável
Product
Owner
Quadros
de tarefas
Objetivos
da sprint
Time Scrum
Sprint
( 1 - 4 semanas)
Product Backlog Objetivo da
Sprint
Ações de
melhoria
Sprint
Backlog
Planejamento da Sprint
Refinamento
ideias Clientes Mercado Inovações
Product
Backlog
Gestores CompetidoresResultados
Retrospectiva
Reunião diária
Scrum
Master
Time de
Desenvolvimento
Clientes, gestores, stakeholders...
Fonte: Adaptado de Sutherland (2016)
UML e orientação a objetos
AUTORIA
Ricardo Bortolo Vieira
A UML (Uni�ed Modeling Language ou Linguagem de Modelagem Uni�cada) é
uma linguagem grá�ca, 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
computaçã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í�cas; palavras-
chave permitem que se modi�que a semântica de elementos da linguagem;
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 é
independente de processo de software, podendo ser utilizada em modelo cascata,
desenvolvimento evolucionário, ou qualquer outro processo que esteja sendo
utilizado para o desenvolvimento de software.
Esta linguagem utiliza diversos símbolos grá�cos, e possui uma semântica bem
de�nida 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 informações corporativos, serviços bancários e �nanceiros, 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 �uxo de trabalho no
sistema legal, a estrutura e o comportamento 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étodo
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): 
Em sua última versão vigente, 2.5, a UML possui 14 diagramas vigentes apresentados
na Figura 8. 
1. Encapsulamento; 
2. Ocultação de informação e Implementações;
3. Retenção de Estado;
4. Identidade de Objeto;
5. Mensagens;
6. Classes;
7. Herança;
8. Polimor�smo; e 
9. Generalização.
Figura 8 - Organograma da UML 2.5.
Diagrama de
classes
Diagrama de
perfil
Diagrama de
sequência
Diagrama de
comunicação
Diagrama de
tempo
Diagrama de
implantação
Diagrama de
pacotes
Diagrama de
interação
Diagrama de
estruturas
compostas
Diagrama de
visão geral
de interação
Diagrama de
máquina de
estados
Diagrama de
componentes
Diagrama de
objetivos
Diagrama de
atividades
Diagrama de
casos de uso
Diagrama de
comportamentos
Diagrama de
estruturas
Diagrama
Fonte: Adaptado de Pereira (2011)
Ferramentas Case
AUTORIA
Ricardo Bortolo Vieira
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 fasesdo
processo de desenvolvimento de software, incluindo a manutenção”.
Outra de�nição, dada por Silva e Videira (2011, p. 326) é:
"Um conjunto de técnicas e ferramentas informáticas que auxiliam o
engenheiro de software no desenvolvimento de aplicações, com o
objetivo de diminuir o respectivo esforço e complexidade, de melhorar
o controle do projeto, de aplicar sistematicamente um processo
uniformizado e de automatizar algumas atividades e veri�cação da
consistência e qualidade do produto �nal e geração de artefatos." 
Para a modelagem de sistemas usando a UML, normalmente usamos as
ferramentas CASE, as mais conhecidas são descritas a seguir: 
Astah Community é um software para modelagem UML (Uni�ed Modeling
Language – Linguagem de Modelagem Uni�cada) 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. 
Rational Rose é uma ferramenta CASE, mais especi�camente, uma ferramenta UML
que auxilia nos processos de construção de um software pro�ssional. Hoje em dia
essa ferramenta tem um peso no mercado sendo usada por diversos pro�ssionais e
grandes 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 9 - Logotipo do Software Astah Community
Fonte: ASTAH (2006)
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) 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 Description Language -
Linguagem de Descrição de Serviços Web) e XML (Extensible Markup Language).
Figura 10 - Logotipo do Software Rational Rose
Fonte: IBM (2001)
Figura 11 - Logotipo do Software Enterprise Architect
Fonte: SPARK (2000)
Visual Paradigm for UML é uma ferramenta CASE com várias opções de
modelagem com os diagramas da UML 2.0 e que também oferece suporte a
diagramas de requisitos 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í�cas 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)
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 �caram 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 signi�cativo e, consequentemente,
não fora detectada. Na Guerra do Golfo, entretanto, a bateria de mísseis
Patriot em Dhahran �cou operando por mais de 100 horas
ininterruptas. Isso fez com que a discrepância de tempo acumulado se
tornasse su�cientemente grande para fazer com que o sistema se
tornasse impreciso. 
Durante a Guerra do Golfo, os Estados Unidos enviaram mísseis Patriot
a Israel 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 consultoria especializada em treinamentos e métodos em
engenharia de software 
Nesta primeira unidade foram apresentados alguns conceitos básicos sobre
engenharia de software que serão utilizados no decorrer de todo o livro, por isso, é
muito importante que esses conceitos �quem 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 propuseram 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á!      
Conclusão - Unidade 1
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 e�ciência dos software e além disso, se tornam
cada vez mais dependentes dos aplicativos e programas.   
ACESSAR
Livro
Filme
Leitura complementar
Acesse o link
https://www.researchgate.net/publication/221554200_A_view_of_20th_and_21st_century_software_engineering
Referências 
ASTAH (2006). Astah Community - Free UML Modeling tool I Astah.net.
http://astah.net/editions/community, <acessado em 18/07/2019> 
BAUER, F. L. (1971). Appendix SOFTWARE ENGINEERING. 
https://link.springer.com/content/pdf/bbm%3A978-3-540-37502-9%2Fl.pdf, <acessado 
em 12/07/2019>. 
GUEDES, G. T. A. UML: Uma abordagem prática. 2. ed.: Novatec, 2011. 
IBM (2001). Modelo Rational Rose. 
https://www.ibm.com/su pport/knowledgecenter/pt-
br/SS4J E2_ 7.5.5/com.i bm.xtools.sa m ple.rose.model.doc/topics/sa m ple_rose_i ntro.htm 1 
<acessado em 18/07/2019> 
MELLOR, Peter. CAD: computer-aided disaster. HIGH INTEGR SYST, v. l, n. 2, p.101-156, 
1994. 
PAGE-JONES, M. Fundamentosdo Desenho Orientado a Objeto com UML. São 
Paulo: Makron, 2001. 
PEREIRA, L. A. de M. Análise e Modelagem de Sistemas com UML. Rio de Janeiro, 
2011. 
POTTS, C. Software-Engineering Research Revisited. IEEE Software, v. 10, n. 5, p. 19-
28.1993. 
PRESSMAN, R. S. Engenharia de Software: Uma Abordagem Profissional. 7. ed. Porto 
Alegre: Me Graw Hill, 2011. 
SILVA, A.; VIDEIRA, C. UML Metodologias e Ferramentas CASE. Lisboa: Centro 
Atlântico, 2001 
SOMMERVILLE, 1. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011. 
SPARK Systems Pty Ltd. (2000). Enterprise Architect Downloads I Sparx Systems.
https://spa rxsystems.com/prod ucts/ea/down loads.htm 1 <acessado em 18/07 /2019> 
SUTHERLAND, Jeff. Scrum: a arte de fazer o dobro do trabalho na metade do 
tempo. Leya, 2016. 
TELES, Vinícius Manhães. Extreme Programming: Aprenda como encantar seus 
usuários desenvolvendo software com agilidade e alta qualidade. Novatec Editora, 
2017. 
TERRY, B. LOGEE, D. Terminology for Software Engineering and Computer-Aided 
Software Engineering. Software Engineering Notes, 1990. 
VISUAL-PARADIGM (2002). Ideal Modeling & Diagramming Tool for Agile Team 
Collaboration. https://www.visual-paradigm.com/ <acessado em 18/07/2019> 
WILDT, Daniel et ai. extreme Programming: Práticas para o dia a dia no 
desenvolvimento ágil de software. Editora Casa do Código, 2015. 
Unidade 2
Projetos de Software
AUTORIA
Ricardo Bortolo Vieira
Introdução
Olá Caro(a) aluno(a)! Neste capítulo meu objetivo é introduzir os conceitos de projeto
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
organizar 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
diferentes 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
componente;
Que o projeto de interface busca identi�car 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 é focado
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! 
Projeto de arquitetura de
software
AUTORIA
Ricardo Bortolo Vieira
Introdução (H1)
É um processo criativo no qual de�ne-se uma organização de um sistema para
satisfazer aos requisitos funcionais e não funcionais. Aspectos que in�uenciam a
arquitetura:
Tipo de sistema a ser desenvolvido;
Experiência do arquiteto de sistemas;
Requisitos especí�cos 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 identi�ca 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 exempli�car 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.
Figura 1 - Exemplo de arquitetura de um sistema de repositório de código fonte.
Tradutor
de projeto
Editores
UML
Geradores
de código
Gerador
de relatório
Repositório do projeto
Analisador 
de projeto
Editores
java
Editor
Python
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 signi�cam 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 de�nida para a descrição de arquitetura.  
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
visã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 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
conceitualmente mais aceitas como válidas. São elas:
1. A visão lógica, que mostra as abstrações fundamentais do sistema como
objetos 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
disponibilidade.
3. A visão de desenvolvimento, que mostra como o software é decomposto para
o desenvolvimento, ou seja, apresenta a distribuição do software em
componentes 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 aspectos do sistema são discu tidos, outras visões também
podem ser desenvolvidas, mas não há necessidade de uma descriçãocompleta 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). 
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 
MVC 
Repositório
Tabela 1 - O padrão modelo-visão-controle (MVC).
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 de�ne 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
interagir 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. 
Fonte: Sommerville (2011)
Cliente-Servidor 
Tabela 2 - O padrão Repositório.
Nome Característica
Descrição
Todos os dados em um sistema são gerenciados em um
repositório central, acessível a todos os componentes do
sistema. Os componentes não interagem diretamente,
apenas por meio do repositório. 
Quando é
usado
Você deve usar esse padrão quando tem um sistema no
qual grandes volumes de informações são gerados e
precisam ser armazenados por um longo tempo. Você
também pode usá-lo em sistemas dirigidos a dados, nos
quais a inclusão dos dados no repositório dispara uma
ação ou ferramenta. 
Vantagens
Os componentes podem ser independentes — eles não
precisam saber da existência de outros componentes. As
alterações feitas a um componente podem propagar-se
para todos os outros. Todos os dados podem ser
gerenciados de forma consistente (por exemplo, backups
feitos ao mesmo tempo), pois tudo está em um só lugar. 
Desvantagens
0 repositório é um ponto único de falha, assim, problemas
no repositório podem afetar todo o sistema. Pode haver
ine�ciências na organização de toda a comunicação
através do repositório. Distribuir o repositório através de
vários computadores pode ser difícil. 
Fonte: Sommerville (2011)
Tabela 3 - O padrão Cliente-Servidor.
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 suscetível a
ataques de negação de serviço ou de falha do servidor. O
desempenho, bem como o sistema, pode ser imprevisível
pois depende da rede. Pode haver problemas de
gerenciamento se os servidores forem propriedade de
diferentes organizações. 
Fonte: Sommerville (2011)
Projeto de componentes de
software
AUTORIA
Ricardo Bortolo Vieira
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 con�gura çã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 e�caz, orientada ao reúso, de desenvolver
novos sistemas corporativos. 
Ainda segundo Sommerville (2011), a engenharia de software baseada em
componentes (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 projetistas, 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í�cas 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 signi�cava que era necessário ter o código-
fonte do componente, o que signi� cava que vender ou distribuir objetos como
componentes reusáveis individuais era praticamente impossível.
Os fundamentos da engenharia de software baseada em componentes, segundo
Sommerville (2011), são:
1. Os componentes independentes que são completamente especi�cados por
suas interfaces. Deve haver uma se paração clara entre a interface de
componente e sua implementação. Isso signi�ca 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 de�nem, no mínimo,
como interfaces de componentes devem ser especi�cadas e como os
componentes se comunicam. Alguns modelos vão muito mais longe e
de�nem 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
componentes. 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 e�ciê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 componentes 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 de�nidas. Se
essas interfaces forem mantidas, um componente poderá ser substituído por
outro, que forneça funcionalidade adicional ou aumentada.
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. 
Modelo de Componentes 
ParaSommerville (2011), a Tabela 4 mostra o que deve ser considerado como
característica para um componentes seguindo os preceitos da CBSE.
Tabela 4 - Característica de um componente.
Característica
do
componente
Descrição
Padronizado
A padronização de componentes signi�ca que um
componente usado em um processo CBSE precisa
obedecer a um modelo de componentes padrão. Esse
modelo pode de�nir as interfaces de componentes,
metadados de componente, documentação, composição
e implantação. 
Independente
Um componente deve ser independente, deve ser
possível compor e implantá-lo sem precisar usar outros
componentes especí�cos. Nessas situações, em que o
componente precisa dos serviços prestados
externamente, estes devem ser explicitamente de�nidos
em uma especi�cação de interface 'requires'. 
Passível de
composição
Para um componente ser composto, todas as interações
externas devem ter lugar por meio de interfaces
publicamente de�nidas. 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 signi�ca que o
componente é 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 especi�cadas. 
Fonte: Sommerville (2011)
Os componentes têm duas interfaces relacionadas, como mostrado na Figura 14.
Essas interface re�etem os serviços que o componente fornece e os serviços de que
o componente necessita para funcionar corretamente:
A interface 'provides' de�ne os serviços prestados pelo componente. Essa
interface, essencialmente, é uma API (Application Programming Interface -
Interface de Programação de Aplicativo) de componente. Ela de�ne os
métodos que podem ser chamados por um usuário do componente. 
A interface 'requires' especi�ca 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
compromete a independência ou a capacidade de implantação de um
componente, pois a interface 'requires' não de�ne como esses serviços deverão
ser prestados.
Figura 14 - Interface de componentes.
Interface ‘requires’
Define os serviços
que são requeridos
e que deveriam ser
fornecidos por
outros componentes
Interface ‘provides’
Componentes
Define os serviços
que são providos pelo
componente para
outros 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 de�nem a utilização e a processo de implantação
(SOMMERVILLE, 2011).
1. Interfaces. Os componentes são de�nidos pela especi�cação de suas
interfaces. O modelo de componente especi�ca como as interfaces devem ser
de�nidas e os elementos, como nomes de operação, parâmetros e exceções,
que devem ser incluídos na de�nição de interface. O modelo também deve
especi�car a linguagem usada para de�nir as interfaces de componente.
Alguns modelos de componentes exigem interfaces especí �cas que devem ser
de�nidas 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 identi�cador 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 Identi�er).
Figura 15 - Elementos básicos de um modelo de componentes.
Composição Convençãode nomes Customização
Modelos de componentes
Documentação
Definição
de interfaces
Interfaces
específicas
Interfaces Informaçõesde uso
Implantação
e uso
Acesso a
metadados
Suporte a
evoluçãoEmbalagem
Fonte: Sommerville (2011)
Processos CBSE
Os processos CBSE são processos de software que oferecem suporte a engenharia
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
desenvolvimento 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 e�ciente
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 de componente,
gerenciamento de componente e certi�cação de componente. 
Figura 16 - Processos CBSE.
CBSE
para reúso
Certificação
de componentes
Repositório
de componentes
myri
Aquisição de
componentes
CBSE
com reúso
Analista de domínio,
Projetista,
Implementador,
Mantenedor,
Analista de mercado.
Certificador
local ou externo
Bibliotecário
Fonte externa
Bibliotecário,
Vendedor,
Agente
Especificador,
projetista,
Integrador,
Mantenedor
PROCESSOS CBSE
Fonte: Sommerville (2011)
Projeto de interface de
usuário
AUTORIA
Ricardo Bortolo Vieira
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 �xar 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á�cos, 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
signi�cante de outra coisa qualquer.
Segundo Mandel (1997) as três regras de ouro dos projetos de interface deusuá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. 
Usuário no Comando 
A maioria das restrições de interface impostas por um designer tem a intenção de
simpli�car o modo de interação. Mas para quem?
Como designer, você pode se sentir tentado a introduzir restrições e limitações para
simpli�car a implementação da interface. O resultado pode ser uma interface fácil
de construir, mas frustrante de usar. Mandel (1997) de�ne vários princípios de design
que permitem ao usuário manter este controle tão desejado:
De�na 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 �exível. Como usuários diferentes têm diferentes
preferê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.  
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) de�ne 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;
Estabeleça defaults signi�cativos;
De�na 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. 
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 de�nidos e
implementados de maneira consistente. 
Mandel (1997) de�ne 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 signi�cativo. 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.
Padrões de projeto
AUTORIA
Ricardo Bortolo Vieira
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
contexto de projetos de software.
Segundo Pressman (2011), O projeto baseado em padrões cria uma nova aplicaçã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
problema 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í�co. À medida que cada padrão é aplicado, são integradas soluções,
e a aplicação a ser construída se aproxima cada vez mais de um projeto completo.
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
desenvolvimento de software, a tecnologia industrial tem usado projeto baseado em
padrões há décadas, talvez há séculos. Catálogos de mecanismos e con�gurações
padronizadas fornecem elementos de projeto que são usados para criar automóveis,
aeronaves, máquinas-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. 
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 in�uenciadas 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 realizado e 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 contexto e identi�ca 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. 
Figura 17 - Contexto do projeto baseado em padrões.
Modelo de
requisitos
Considerar
conceitos
de projeto
Iniciar tarefas de
projeto baseado
em padrões
Modelo de
projeto
Aplicar outros
métodos e
notações de
projeto
Extrair contexto
das forças e
do problema
Considerar
atributos
de qualidade
do projeto
Tratado pelo
padrão?
O projeto é iniciado
Sim Não
Fonte: Pressman (2011)
Consequentemente, devemos aplicar técnicas comprovadas para traduzir as
abstraçõ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 depararmos 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 signi�ca aplicar uma abordagem de projeto baseado
em padrões. 
Padrões de Projeto de Arquitetura 
Conforme Pressman (2011), os padrões de arquitetura para software de�nem uma
abordagem especí�ca para tratar alguma característica do sistema e de�nem 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
funcionalidade fornecidos por uma aplicação é limitado a usuários �nais
especi�camentede�nidos. 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 executarem 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 considerados 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 processo
que o criou. Os dados persistentes armazenados em um banco de dados ou arquivo
podem ser lidos ou modi�cados por outros processos posteriormente. Em
ambientes orientados 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 Management 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.
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
especi�ca. 
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 especi�caçõ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í�co 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í�ca dentro deste site.
SearchArea. Os usuários precisam encontrar uma página Web.
SearchTips. Os usuários precisam saber como controlar o mecanismo de
busca.
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í�cas.
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. 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 5. 
Tabela 5 - Tipos de Padrões de Projeto de Interface de Usuário.
Padrão Descrição Detalhes
TopLevelNavigation
Usada quando um
site ou uma aplicação
implementa uma
série de funções
principais. Oferece
um menu de alto
nível, geralmente
acoplado a um logo
ou imagem
identi�cadora, 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 listadas 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í�cas
relacionadas com um
recurso ou função
deve ser selecionada
em ordem aleatória.
Dá a aparência de
uma pilha de �chas
indexadoras, cada
uma delas
selecionável com um
clique de mouse e
cada qual
representando
subfunções ou
categorias de
conteúdo especí�cas.
As �chas indexadoras são
uma metáfora bem
compreendida e fácil para
o usuário manipular. Cada
�cha indexadora
(separador) pode ter um
formato ligeiramente
diverso. Alguns poderão
exigir entrada de dados e
possuir botões ou outros
mecanismos de
navegação. Poderiam ser
combinados com outros
padrões como
DropDownList e Fill-in-
the-Blanks.
Fill-in-the-Blanks Possibilita que dados
alfanuméricos sejam
introduzidos em uma
“caixa de texto.”
Os dados poderiam ser
introduzidos em uma
caixa de texto e são
validados e processados
após a seleção de algum
indicador de texto ou
grá�co (por exemplo, um
botão contendo “avançar”,
“submeter”, “próximo”).
Em muitos casos, esse
padrão pode ser
“combinado com uma
lista suspensa ou outros
padrões (por exemplo,
SEARCH <drop down list>
FOR <�ll-in-the-blanks
text box>).
SortableTable
Mostra uma longa
lista de registros que
podem ser ordenados
através da seleção de
um mecanismo
comutador para
qualquer rótulo de
coluna.
Cada linha da tabela
representa um registro
completo. Cada coluna
representa um campo no
registro. Cada título de
coluna é um botão
selecionável que pode ser
comutado para iniciar
uma ordem crescente ou
decrescente para todos os
registros exibidos. Em
geral a tabela é
redimensionável e poderá
ter um mecanismo de
rolagem caso o número
de registros seja maior
que o espaço de janela
disponível.
BreadCrumbs
Fornece um caminho
de navegação
completo quando o
usuário está
trabalhando com
uma hierarquia de
páginas ou telas
complexa.
É atribuído um
identi�cador exclusivo a
cada página ou tela. O
caminho de navegação
para O local atual é
especi�cado em um local
prede�nido para qualquer
tela. O caminho assume a
forma: homepage>página
de tópico
principal>página de
subtópico>página
especí�ca>página atual.
EditinPlace Fornece um recurso
de edição simples
para certos tipos de
conteúdo no local em
que é exibido.
O usuário vê o conteúdo
na tela que deve ser
alterado. Um clique duplo
com o mouse sobre o
conteúdo indica ao
Uma discussão completa para interfaces do usuário vai além do escopo deste livro,
assim, recomendo os seguintes livros para mais informações: Borchers (2001) e
Duyne (2002). 
Nenhuma
necessidade de o
usuário introduzir
explicitamente uma
função ou modo de
edição de texto.
sistema que se deseja
editar. O conteúdo é
realçado para signi�car
que o modo de edição
está disponível e o usuário
faz as mudanças
apropriadas.
SimpleScarch
Oferece a capacidade