Analise e Desenvolvimento de S

CENTRO UNIVERSITRIO
LEONARDO DA VINCI
Rodovia BR 470, Km 71, n 1.040, Bairro Benedito
89130-000 - INDAIAL/SC
www.uniasselvi.com.br
ANLISE E DESENVOLVIMENTO DE SISTEMAS EM FOCO

UNIASSELVI 2016
Organizao
Greisse Moser Badalotti
Autoria
Edemilson Bay
Elton Giovani Gretter
Greisse Moser Badalotti
Neli Miglioli Sabadin
Pedro Sidnei Zanchett
Simone Cristina Alssio
Reitor da Uniasselvi
Prof. Hermnio Kloch
Pr-Reitora de Ensino de Graduao a Distncia

Prof. Francieli Stano Torres
Pr-Reitor Operacional de Graduao a Distncia

Prof. Hermnio Kloch
Editor-Chefe
Prof. Evandro Andr de Souza
Diagramao e capa
Djenifer Luana Kloehn
Reviso Final
Joice Carneiro Werlang
Jos Roberto Rodrigues
Propriedade do Centro Universitrio Leonardo da Vinci
Anlise e desenvolvimento de sistemas em Foco

Ficha catalogrfica
Elaborada na fonte pela Biblioteca Dante Alighieri UNIASSELVI Indaial.
005.102
B356a Moser; Greisse
Anlise e desenvolvimento de sistemas em foco/ Greisse Moser;

Neli Miglioli Sabadin; Pedro Zanchett (Orgs.) : UNIASSELVI, 2016.
144 p. : il.
ISBN 978-85-7830-988-6
1.Engenharia de software.
I. Centro Universitrio Leonardo Da Vinci.

PREFCIO
Caro leitor, voc est prestes a iniciar a leitura do livro Anlise e

Desenvolvimento de Sistemas em Foco I, que apresentamos a voc com grande
satisfao. O presente livro envolve assuntos vinculados rea de atuao do
analista e desenvolvedor de sistemas. O objetivo explorar temas que permitam
instig-lo sobre os diversos assuntos aqui tratados, fazendo conexes pertinentes
ao contexto tecnolgico.
Constantemente somos avaliados em provas, concursos e, em grande

parte, precisamos de um guia rpido para nos apoiar na reviso dos conhecimentos
adquiridos no decorrer do curso. Com base nesta necessidade, consideramos de
extrema importncia a reviso dos assuntos e, como resultado, prepar-lo ainda
mais para obter o sucesso nestas atividades.
Vale salientar que os textos reunidos nesta publicao so frutos das

problematizaes e estudos realizados pela equipe de professores, e organizados
pela coordenadora do Curso de Anlise e Desenvolvimento de Sistemas da
UNIASSELVI, pois o mesmo reflete a base conceitual da profisso.
Esperamos que voc faa uma tima leitura!
Me. Greisse Moser Badalotti

Coordenadora do Curso Superior de Anlise e Desenvolvimento de Sistemas

SUMRIO
TPICO 1 - INTRODUO ENGENHARIA DE SOFTWARE ..................... 1
1 INTRODUO .............................................................................................. 1
2 METODOLOGIA DE DESENVOLVIEMENTO DE SISTEMAS ..................... 3
2.1 RUP ............................................................................................................ 4
3 FASES DE DESENVOLVIMENTO DE SOFTWARE .................................... 4
4 PROCESSOS DE ENGENHARIA DE SOFTWARE ..................................... 5
5 CICLO DE VIDA DE DESENVOLVIMENTO DE SOFTWARE ...................... 5
6 REQUISITO DE SOFTWARE ....................................................................... 7
7 ESTIMATIVAS E MTRICAS DE PROJETOS DE SOFTWARE .................. 7
8 QUALIDADE DE SOFTWARE ...................................................................... 12
9 PADRES, NORMAS E MODELOS DE QUALIDADE DE SOFTWARE ..... 16
10 MTODOS GEIS ...................................................................................... 19
10.1 SCRUM .................................................................................................... 20
10.2 EXTREME PROGRAMMING ................................................................... 22
11 TESTES DE SOFTWARE ........................................................................... 23
TPICO 2 - PROGRAMAO ORIENTADA A OBJETOS ............................. 27

1 CONCEITOS DA PROGRAMAO ORIENTADA A OBJETOS ................. 27
2 PROJETO ORIENTADO A OBJETOS .......................................................... 30
3 OBJETIVOS DA MODELAGEM ................................................................... 31
4 VANTAGENS DO PROJETO OO ................................................................. 31
5 DIAGRAMAS ESTRUTURAIS ...................................................................... 32
6 DIAGRAMAS COMPORTAMENTAIS ........................................................... 33
7 PADRO DE PROJETOS ............................................................................. 33
8 VANTAGENS DO USO DE PADRES ......................................................... 34
9 OS PADRES MAIS UTILIZADOS .............................................................. 37
TPICO 3 - LGICA, ALGORITMOS E ESTRUTURA DE DADOS ............... 39

1 LGICA DE PROGRAMAO .................................................................... 39
1.1 ESTRUTURAS DE SELEO .................................................................. 40
1.1.1 Se-ento-seno ................................................................................... 41
1.1.2 Seleo Encadeada ............................................................................... 42

1.2 ESTRUTURAS DE REPETIO ............................................................... 44
1.2.1 Enquanto-faa ......................................................................................... 44
1.2.2 Para-faa ................................................................................................. 45
1.2.3 Repita-at ................................................................................................ 46
1.3 VETORES UNIDIMENSIONAIS ................................................................. 46
1.4 MATRIZES .................................................................................................. 48
1.5 LISTAS ENCADEADAS .............................................................................. 50
1.6 PILHAS ....................................................................................................... 52
1.7 FILAS ......................................................................................................... 54
1.8 ANLISE E TCNICAS DE ALGORITMOS ............................................... 55
1.8.1 Diviso e Conquista ................................................................................ 55
1.8.2 Mtodo Guloso ........................................................................................ 57
1.8.3 Programao Dinmica ........................................................................... 60
TPICO 4 - BANCO DE DADOS RELACIONAL ........................................... 63

1 INTRODUO AO BANCO DE DADOS RELACIONAL ............................. 63
2 CONCEITOS DO MODELO ENTIDADE-RELACIONAMENTO ................... 67
3 CARDINALIDADE DE RELACIONAMENTOS ............................................. 68
4 GRAUS DE RELACIONAMENTOS .............................................................. 69
5 TIPOS DE ENTIDADES ................................................................................ 71
6 PADRO SQL PARA BANCO DE DADOS RELACIONAL ......................... 73
7 SELECIONANDO DADOS: DQL - DATA QUERY LANGUAGE .................. 74
8 FUNES EM SQL ...................................................................................... 77
9 COMBINAO DE CONSULTAS ................................................................ 78
TPICO 5 - ARQUITETURA E REDES DE COMPUTADORES ..................... 81

1 PRINCIPAIS TIPOS DE ARQUITETURAS COMPUTACIONAIS ................. 81
2 COMPONENTES FSICOS DO SISTEMA COMPUTACIONAL ................... 84
3 TIPOS DE MEMRIAS E GERENCIAMENTO ............................................. 90
4 TIPOS DE REDES ........................................................................................ 94
5 TOPOLOGIAS DE REDES ........................................................................... 96
6 ENDEREOS IPV4 E IPV6 ........................................................................... 97
7 SISTEMA DNS .............................................................................................. 100
TPICO 6 - PROGRAMAO WEB ............................................................... 103

1 INTRODUO .............................................................................................. 103

TPICO 7 - GESTO DE PROJETO .............................................................. 115
1 INTRODUO .............................................................................................. 115
2 PARTES INTERESSADAS E PMO .............................................................. 117
3 OS GRUPOS DE PROCESSOS DE GERENCIAMENTO DE PROJETOS ..... 120
4 REAS DE CONHECIMENTO ..................................................................... 123
5 ESCOPO ....................................................................................................... 125
6 TEMPO .......................................................................................................... 125
7 CUSTO .......................................................................................................... 127
8 QUALIDADE ................................................................................................. 127
9 RECURSOS HUMANOS ............................................................................... 128
10 COMUNICAES ....................................................................................... 129
11 RISCOS ....................................................................................................... 130
12 AQUISIES .............................................................................................. 132
13 GERENCIAMENTO DAS PARTES INTERESSADAS ............................... 133
REFERNCIAS ................................................................................................ 135

-------- [ TPICO 1 - INTRODUO ENGENHARIA DE SOFTWARE ] --------
Caro(a) acadmico(a), neste captulo vamos relembrar alguns dos principais

conceitos relacionados aos temas de Engenharia de Software e Qualidade de
Software. Apresentaremos esses assuntos de forma sintetizada. Ressaltamos que, em
caso de dvida, voc pode buscar o detalhamento do assunto no caderno da disciplina.
Apresentaremos um resumo do que consideramos os principais tpicos

do tema apresentado, que so: Introduo Engenharia de Software, Metodologia
de Desenvolvimento de Sistemas, RUP, Scrum, Extreme Programming e Testes
de Software.
Vamos ento iniciar os estudos, empregando o mximo de ateno e foco

para que os resultados sejam os melhores possveis, contribuindo para o incremento
e fixao dos seus conhecimentos!
Prof. Pedro Sidnei Zanchett

1
1 INTRODUO
Segundo Ian Sommerville (2011), a Engenharia de Software uma disciplina

da engenharia de sistemas que se ocupa de todos os aspectos da produo de
software, desde os estgios iniciais de levantamento e especificao de requisitos
at a implantao e manuteno, ou seja, que entrou em operao. um conjunto
de atividades, parcialmente ou totalmente ordenadas, com a finalidade de obter
um produto de software de qualidade e cumprir corretamente os contratos de
desenvolvimento. Segundo Roger Pressman (2006), a Engenharia de Software
poder ser mais bem entendida como uma tecnologia em camadas ou nveis,
conforme pode ser vista na Figura 1.

FIGURA 1 - CAMADAS DA ENGENHARIA DE SOFTWARE
FONTE: Disponvel em: <http://3.bp.blogspot.com/_CMoqSGzMYOg/SkrJEy3nGeI/AAAAAAAAAAk/

Ee1ZgJBwMdM/s320/Figura+2.1.Engenharia+de+Software+em+Camadas.gif>. Acesso em:
6 jul. 2015.
Na base da figura, formando a camada foco na qualidade, d-se nfase

preocupao de qualquer disciplina de engenharia, que qualidade. A qualidade na
Engenharia de Software baseada nos conceitos de gerenciamento de qualidade
total (TQM Total Quality Management) para a melhoria contnua dos processos para
obter sucesso em longo prazo atravs da satisfao dos clientes (HIRAMA, 2011).
2
De acordo com Hirama (2011), as camadas so divididas em:
A camada de processo permite integrar as camadas de mtodos e de

ferramentas para que se possa desenvolver um software nos prazos acordados e
de maneira adequada. Um processo que permite que se planeje e se controle o
projeto de software.
A camada de mtodos prov as abordagens e as atividades necessrias

para a construo de um software. Os mtodos abrangem um conjunto amplo
de tarefas que incluem anlise de requisitos, projeto, implementao, testes e
manuteno. Os mtodos de Engenharia de Software so baseados em um
conjunto de princpios que governam cada rea de tecnologia e incluem atividades
de modelagem e tcnicas descritivas.
A camada de ferramentas prov apoio automatizado ou semiautomatizado

para processos e mtodos. As ferramentas da rea de Engenharia de Software so
conhecidas como CASE (Engenharia de Software Apoiada por Computador, do
termo em ingls Computer-Aided Software Engeneering).

2 METODOLOGIA DE DESENVOLVIEMENTO DE SISTEMAS
Segundo Fernandes (1999), metodologia de sistemas se define como um

conjunto de normas, procedimentos, tcnicas e ferramentas de anlise que definem o
padro desejado por uma empresa para o desenvolvimento de projetos de sistemas.
A ausncia de uma metodologia de desenvolvimento de sistemas pode

levar ao caos, na medida em que cada indivduo procura aplicar em seu projeto as
melhores solues dentro das limitaes de sua experincia profissional. Mesmo
que suas solues sejam timas e que os resultados individuais sejam melhores,
dificilmente, no conjunto de todas as aplicaes de uma corporao, haver a
harmonia desejada. A produtividade e a eficincia que so esperadas de um
departamento de sistemas no podem ser obtidas sem critrios, sem regras e sem
anlise contnua das ferramentas de trabalho postas disposio dos profissionais
de sistemas (PRESSMAN, 2006).
Fernandes (1999) nos diz que, para que uma metodologia de desenvolvimento
de sistemas seja consistente, oferecendo maior produtividade e qualidade, dever
atender a alguns requisitos fundamentais: 3
Padronizao: executar as atividades de maneira idntica, fazendo com que

haja aperfeioamento do processo.
Flexibilidade: a capacidade de se adaptar s mudanas.
Documentao: manter informaes sobre o produto e garantir rapidez diante
das mudanas.
Modularizao: consiste em dividir um conjunto de atividades em vrios conjuntos
menores, objetivando melhor visualizao e acompanhamento por parte de todos
os interessados no resultado final.
Planejamento: forma madura de administrar o tempo programar o futuro em
relao s metas e aos objetivos a serem alcanados.

2.1 RUP
Segundo Kroll e Kruchten (2003), o Rational Unified Process, de sigla RUP,

uma maneira de desenvolvimento de software que iterativa, centrada arquitetura
e guiada por casos de uso. um processo de engenharia de software bem definido
e bem estruturado. Ele define claramente quem responsvel pelo que, como as
coisas devem ser feitas e quando faz-las. O RUP tambm prov uma estrutura
bem definida para o ciclo de vida de um projeto, articulando claramente os marcos
essenciais e pontos de deciso e, por fim, tambm um produto de processo que
oferece uma estrutura de processo customizvel para a engenharia de software.
O RUP utiliza a linguagem de modelagem unificada para especificar, modelar

e documentar artefatos. Por ser flexvel e configurvel, ele pode ser utilizado em
projetos de pequeno, mdio e grande porte. Com o RUP possvel obter qualidade
de software, produtividade no desenvolvimento, operao e manuteno de software,
controle sobre o desenvolvimento dentro de custos, prazos e nveis de qualidade
desejados, sem deixar de levar em conta a estimativa de prazos e custo com maior
preciso (BOENTE, 2016).
4
3 FASES DE DESENVOLVIMENTO DE SOFTWARE
Atualmente, muitas so as metodologias de desenvolvimento de softwares.

Existem as clssicas (antigas), que so mais estveis de serem executadas atravs
de diversos ciclos de vida prescritivo, seguindo um nico caminho de trabalho, e
aquelas metodologias geis, que possuem diversas formas dinmicas de execuo,
exigindo maior experincia dos envolvidos.
Para capturar a dimenso do tempo de um projeto, o processo de Engenharia

de Software se divide em quatro fases que indicam a nfase que dada no projeto
em um dado instante:
Fase de Iniciao: nfase no escopo.

Fase de Elaborao: nfase na anlise.
Fase de Construo: nfase no desenvolvimento.
Fase de Transio: nfase na implantao.

4 PROCESSOS DE ENGENHARIA DE SOFTWARE
No momento em que se decide construir um software, fundamental

tambm decidir qual processo ser seguido. A criao de um projeto de software
uma atividade intelectual de alto nvel de complexidade, necessitando melhor
visibilidade na sua construo, sabendo-se de incio quais so as etapas do projeto.
Um processo de software composto por mtodos (aquilo que diz o que,

em uma determinada tarefa), por ferramentas (que do suporte automatizado aos
mtodos) e procedimentos (que fazem o elo de ligao entre os mtodos e as
ferramentas). Uma organizao que possui um processo de engenharia de software
dever levar muito a srio estes trs princpios de processo, a fim de que seus projetos
de software sejam de sucesso, ou seja, equipes produtivas e softwares bem feitos.
5 CICLO DE VIDA DE DESENVOLVIMENTO DE SOFTWARE
O ciclo de vida de um software descreve as fases pelas quais o software 5

passa desde a sua concepo at ficar sem uso algum, determinando os passos a
serem seguidos no desenvolvimento de sistemas, mantendo uma padronizao de
trabalho e determinando as etapas de validao do projeto. As fases do ciclo de vida
so constitudas de planejamento (iniciao), anlise e especificao de requisitos,
projeto (elaborao), implementao (construo), testes, entrega e implantao
(transio) e, por fim, operao e manuteno, passando desde a sua concepo
at ficar sem uso algum aps o trmino do projeto.
De maneira geral, as fases do ciclo de vida de um software so constitudas

de planejamento, anlise e especificao de requisitos, projeto, implementao,
testes, entrega e implantao, operao e manuteno.
Os modelos de processo de ciclo de vida durante o desenvolvimento do

software podem ser linear, incremental ou iterativo, logo, compreend-los poder
auxiliar na adoo de um dos modelos mais adequados realidade e necessidade
da organizao.

Para cada uma destas categorias de ciclos de vida de software h um ou
mais modelos formais disponveis para adoo, e os modelos mais conhecidos so:
Modelo cascata ou sequencial, possui um ciclo de vida clssico, em que todas

as fases de desenvolvimento possuem incio e fim bem definidos, e no avana
sem estar com a fase anterior 100% concluda.
O objetivo das tecnologias de prototipao produzir uma representao visual
das funcionalidades que o sistema ter depois de pronto, permitindo ao usurio
e equipe de desenvolvimento avaliar as caractersticas antes que ele seja
efetivamente implementado e entregue. Inicialmente, o modelo de prototipao
desenvolve uma viso da sua interface e depois reaproveita as telas para
configurar e programar o restante do produto de software, trazendo maior rapidez
na construo do projeto e aceitao dos usurios.
O modelo espiral traz uma abordagem orientada gesto de riscos ao invs de
apenas orientar a documentao e codificao, como nos casos dos modelos
cascata e de prototipao. Tambm no modelo espiral, medida que o projeto
de software avana, so incorporados novos requisitos de forma evolutiva, com
sobreposio de atividades em cada fase do projeto, aumentando a qualidade
6
do planejamento em cada ciclo e dando maior visibilidade gerncia.
O modelo iterativo e incremental permite dividir o escopo do projeto em
partes gradativas do desenvolvimento, evoluindo o projeto em verses de novas
funcionalidades at o sistema estar completo. O modelo iterativo pode desenvolver
os mdulos ou funcionalidade de forma independente e liberar o projeto em
partes; j o modelo incremental poder desenvolver em mdulos, porm h
dependncia de funcionalidades entre estes mdulos para um prximo mdulo
ser implementado, permitindo a liberao aps o acrscimo de funcionalidades
feitas nas iteraes anteriores.
O modelo baseado em componentes permite agrupar rotinas relacionadas de
forma a montar componentes que podem ser reutilizados em diversos mdulos
do sistema. A partir do momento em que sobe o requisito do cliente, feita uma
busca na biblioteca de componentes, que trata sobre este requisito, e se j existir
e estiver completo, faz-se o seu reso; caso contrrio, criar um novo componente
e fazer sua integrao biblioteca, liberando o produto pronto ao cliente.
O foco do modelo em V d nfase nas atividades de testes durante a anlise, implementao
e homologao do sistema, primeiramente validando-os antes do desenvolvimento,
garantindo maior entendimento do problema e evitando enganos e retrabalhos.

Modelo RAD (Rapid Application Development) prope um ciclo de vida rpido
de desenvolvimento utilizando um processo incremental entre as etapas de
modelagem e codificao durante um perodo de at 90 dias. J o modelo de
quarta gerao trata dos modelos de ltima gerao, utilizando ferramentas de
alto nvel atravs da inteligncia computacional, explorando os paradigmas da
ontologia e semntica das aplicaes, ou seja, prxima linguagem natural.
6 REQUISITO DE SOFTWARE
A partir do momento em que for decidido iniciar um processo de construo

de um software, deve-se definir o escopo do projeto atravs de uma lista de
funcionalidades que se deseja disponibilizar para seus usurios no sistema, no qual
estas necessidades identificadas so denominadas de requisito. Portanto, requisito
uma definio formal e detalhada de uma funo do sistema.
A extrao de requisitos o processo de transformar o conhecimento tcito,

que est na mente dos usurios, em conhecimento explcito via documentao 7
formal. Essa transformao s possvel atravs da determinao dos objetivos
do produto e das restries para a sua operacionalidade, atravs de uma anlise
do problema e documentao dos resultados. A sada do processo de extrao de
requisitos um documento de especificao do sistema que deve dizer o que o
produto a ser desenvolvido dever fazer, e no como deve ser feito.
Diversas atividades de requisitos de software ocorrem ao longo de todo o

ciclo de vida do software, um trabalho que consiste na anlise de requisitos para
identificar, quantificar, definir, especificar, documentar, rastrear, priorizar e classificar
os principais problemas que o futuro software deve resolver.
Existem duas categorias de requisitos: os requisitos de negcio, que iro

detalhar quais servios e restries so esperados do sistema, e os requisitos de
sistemas, que iro detalhar as funes e restries operacionais do sistema; a primeira
atividade executada pelo analista de negcios e, a segunda, pelo analista de sistemas.

Os requisitos de negcio ou de sistemas podem ser realizados por trs tipos:
os requisitos funcionais, que definem o comportamento do sistema; os requisitos
no funcionais, que incluem restries impostas pelas normas ou tecnologias; e os
requisitos inversos, que iro informar tudo o que no dever contemplar no sistema.
7 ESTIMATIVAS E MTRICAS DE PROJETOS DE SOFTWARE
Estimar software significa determinar quanto de dinheiro, esforo, recursos

e tempo sero necessrios para criar um sistema, ou seja, o gerente e a equipe de
desenvolvimento devem estimar o trabalho a ser realizado, os recursos necessrios,
o tempo de durao e, por fim, o custo do projeto.
A estimativa de custo faz parte do planejamento de qualquer projeto de

engenharia. A diferena que na engenharia de software o custo principal o
esforo, ou seja, o custo de mo de obra; assim, para se calcular o custo de software
necessrio dimensionar o trabalho para desenvolv-lo. Em geral, esse trabalho
8 expresso pelo nmero de pessoas trabalhando numa unidade de tempo, tal como
pessoas-ms ou pessoa-ano. O trabalho que uma pessoa consegue fazer num ms
pode ser traduzido em nmeros de horas de trabalho num ms.
Mtricas de Software um assunto discutido h mais de 20 anos na

engenharia de software, e, no entanto, no verificada sua utilizao, na prtica, pela
grande maioria dos projetos de construo de software. rea que possibilita realizar
uma das atividades mais fundamentais do processo de gerenciamento de projetos: o
planejamento. A partir desse, pode-se identificar a quantidade de esforo, de custo e
das atividades que sero necessrias para a realizao do projeto (ZANCHETT, 2015).
Ainda segundo o autor, uma mtrica de software a medio de um atributo

(propriedades ou caractersticas) de uma determinada entidade (produto, processo
ou recursos). Como exemplo podemos citar: o tamanho do produto de software em
nmero de linhas de cdigo; nmero de pessoas necessrias para programar um
caso de uso; nmero de defeitos encontrados por fase de desenvolvimento; esforo
para a realizao de uma tarefa; tempo para a realizao de uma tarefa; custo para
a realizao de uma tarefa; grau de satisfao do cliente etc.

A partir do uso das mtricas de software, uma empresa desenvolvedora de
sistemas poder entender e aperfeioar o processo de desenvolvimento, melhorar
a gerncia de projetos e o relacionamento com clientes, reduzir frustraes e
presses de cronograma, gerenciar contratos de software, indicar a qualidade de
um produto de software, avaliar a produtividade do processo, avaliar os benefcios
(em termos de produtividade e qualidade) de novos mtodos e ferramentas de
engenharia de software, avaliar retorno de investimento, identificar as melhores
prticas de desenvolvimento de software, embasar solicitaes de novas ferramentas
e treinamento, avaliar o impacto da variao de um ou mais atributos do produto ou
do processo na qualidade e/ou produtividade, formar uma baseline para estimativas,
melhorar a exatido das estimativas, oferecer dados qualitativos e quantitativos ao
gerenciamento de desenvolvimento de software, de forma a realizar melhorias em
todo o processo de desenvolvimento de software etc. (ZANCHETT, 2015).
Existem vrios mtodos que podem ser utilizados para se estimar o custo do
desenvolvimento e a vida til de um sistema. Em geral, representa o custo monetrio
ou o esforo necessrio para desenvolver e manter um sistema.
Para se estabelecer essas estimativas, podem-se utilizar tcnicas de
9
decomposio do produto e utilizar a opinio de especialistas que, baseados em
experincias de projetos anteriores, so capazes de estimar o esforo e o tempo
de desenvolvimento do projeto. Podem-se considerar dois tipos de decomposio:
(1) decomposio do produto para estimar o nmero de linhas de cdigo utilizando
tcnicas como pontos por funo, caso de uso etc.; (2) decomposio do processo
considerando-se as atividades de cada etapa de engenharia de software,
dependendo do paradigma utilizado.
A seguir so apresentados mtodos ou tcnicas para estimativa de software,

que so: Linhas de Cdigo (LOC); Pontos de Histria; Anlise de Pontos de
Funo, Anlise de Pontos de Caso de Uso, COCOMO II e estimativa para projetos
Orientados a Objeto.
Linha de Cdigo (LOC): mtrica orientada ao tamanho do software, consiste em

estimar o nmero de linhas que um programa dever ter. Para sua definio so
considerados trs valores, o LOC otimista, o LOC pessimista e o LOC esperado,
e a partir dos dados coletados seus valores so aplicados na frmula: KSLOC =
4*KSLOC esperado + KSLOC otimista + KSLOC pessimista)/6.

Pontos de Histria: uma mtrica de estimativa de tempo, pergunta-se equipe
quanto tempo tantas pessoas que se dedicassem a uma histria de usurio
levariam para termin-la, gerando uma verso executvel funcional. Ento,
multiplica-se o nmero de pessoas pelo nmero de dias para chegar ao valor
de pontos de histria.
Anlise de Pontos de Funo (APF): define processos e tcnicas formais e
padronizadas para dimensionamento e estimativa da complexidade de sistema,
ou seja, para medir o tamanho do escopo. Para manter e determinar os
procedimentos de contagem APF observa-se os seguintes passos: (1) Determinar
o tipo de contagem (desenvolvimento, melhoria ou aplicao existente). (2)
Determinar as Fronteiras da aplicao (escopo do sistema). (3) Identificar e
atribuir valor em pontos de funo no ajustados para as transaes sobre dados
(entrada, consultas e sadas externas). (4) Identificar e atribuir valor em pontos
de funo no ajustados (UFPA) para os dados estticos (arquivos internos e
externos). (5) Determinar o valor de ajuste tcnico (VAF). (6) Calcular o nmero
de pontos de funo ajustados (AFP).
Pontos de Caso de Uso (PUC): baseia-se na anlise da qualidade e
complexidade dos atores e casos de uso, o que gera pontos de caso de uso no
10
ajustados. Depois, a aplicao e fatores tcnicos e ambientais levam aos pontos
de caso de uso ajustados. Primeiro deve-se relacionar os atores, classific-
los de acordo com seu nvel de complexidade (simples, mdio ou complexo),
atribuindo respectivamente os pesos 1, 2 ou 3. Em seguida, contar os casos
de uso e atribuir o grau de complexidade, sendo baseada no nmero de classe
e transaes. Utiliza-se a seguinte frmula para calcular PCUs no ajustados:
PCUNA = TPNAA+ TPNAUC, e para chegar ao PUCs ajustado determina-se
o fator de complexidade tcnica, que varia da escala de 0 a 5 para cada grau
de dificuldade do sistema a ser construdo e, por fim, chega-se ao valor PUCs
ajustado utilizando a seguinte frmula: PCUA = PCUNA * Fator de complexidade
tcnica * Fator de complexidade ambiental. E para 8. Calcular a estimativa de
horas de programao, basta multiplicar o PCUs ajustado pelo nmero pessoa
hora por unidade de PCU (ZANCHETT, 2015).
Modelo COCOMO II: um modelo construtivo de custo que trata das seguintes
reas: Modelo de composio de aplicao, Modelo de estgio de incio do projeto
e Modelo de estgio ps-arquitetura.

Para requerer informaes de tamanho como parte da hierarquia do projeto
h disponveis trs diferentes opes: pontos de objeto, pontos de funo e linhas
de cdigo-fonte.
A contagem de pontos de objeto ento determinada multiplicando-se o nmero

original de instncias de objeto pelo fator de peso e somando para obter o total
da contagem de pontos de objeto. Quando deve ser aplicado desenvolvimento
baseado em componentes ou reutilizao de software em geral, estimada a
porcentagem de reutilizao (% reso) e ajustada a contagem de pontos de
objeto: NOP = (pontos de objeto) * [(100 - % reso)/100]. Em que NOP definido
como novos pontos de objeto.
Para derivar uma estimativa de esforo com base no valor calculado para NOP,
deve ser derivada uma taxa de produtividade. O quadro abaixo apresenta a
taxa de produtividade: PROD = (NOP)/pessoa-ms. Para diferentes nveis de
experincia do desenvolvedor e maturidade do ambiente de desenvolvimento.
Uma vez determinada a taxa de produtividade, calcula-se a estimativa de esforo
do projeto: Esforo estimado = NOP/PROD.
11
QUADRO 1 FATORES DE AJUSTES
FONTE: Pressman (2011)
Estimativa para projetos Orientados a Objeto: utilize qualquer mtodo anterior

para decomposio de esforo, valendo-se da modelagem UML atravs da PCU,
determine o nmero de classes-chave e classifique o tipo de interface para a
aplicao, desenvolva um multiplicador para classes e multiplique o nmero
das classes-chave pelo multiplicador para obter uma estimativa do nmero de
classes de apoio. Multiplique o nmero total das classes (classes-chave + classe
de apoio) pelo nmero mdio de unidades de trabalho por classe.

8 QUALIDADE DE SOFTWARE
Em desenvolvimento de software, a qualidade deve ser entendida nos

aspectos da correta compreenso dos requisitos do cliente, quando se desenvolve
o projeto com zero defeito, quando se obtm aumento de produtividade e reduo
de custos e, por fim, uma boa usabilidade do sistema. A qualidade est fortemente
relacionada conformidade com os requisitos, ou seja, atender ao que o usurio
pede formalmente. Na rea de Engenharia de Software, segundo Roger Pressman
(2011) a qualidade definida como sendo a conformidade a requisitos funcionais e de
desempenho explicitamente declarados, a padres de desenvolvimento claramente
documentados e a caractersticas implcitas que so esperadas de todo software
profissionalmente desenvolvido.
A Organizao Internacional de Padronizao (International Organization

for Standardization - ISO), atravs da ISO 9000, define qualidade como a totalidade
das caractersticas de uma entidade que lhe confere a capacidade de satisfazer
s necessidades explcitas e implcitas. Necessidades explcitas so as condies
e objetivos propostos por aqueles que produzem o software. As necessidades
12 implcitas so necessidades subjetivas dos usurios, tambm chamadas de fatores
externos, e podem ser percebidas tanto pelos desenvolvedores quanto pelos
usurios (ISO, 2015).
Qualidade de software est relacionada a entregar ao cliente o produto

final que satisfaa suas expectativas, dentro daquilo que foi acordado inicialmente
por meio dos requisitos do projeto. Nesse contexto, qualidade de software que
objetiva garantir essa qualidade pela definio de processos de desenvolvimento
(ENGHOLM JR., 2010).
Para produzir um produto de software com qualidade deve-se possuir

processos formais que visem preveno e deteco de defeitos durante o
desenvolvimento de software. A origem do produto se d pela implementao de
um processo consistente e em constante melhoria contnua.

FIGURA 2 DESENVOLVIMENTO DE PRODUTO DE SOFTWARE
FONTE: O autor
Vrias tcnicas so utilizadas para identificar defeitos nos produtos de

trabalho. Esses defeitos so eliminados atravs de retrabalho, que tem efeito
imediato na produtividade do projeto. Defeitos tambm so encontrados em
atividades de teste e podem ser analisados, a fim de se identificar suas causas. 13
A partir dessa anlise, lies aprendidas podem ser usadas para criar futuros
produtos e prevenir futuros defeitos e, dessa forma, ter impacto positivo na
qualidade do produto e na produtividade do projeto.
Todo processo de software deve possuir, junto ao plano de projeto, uma

documentao especfica da qualidade, denominada como plano de qualidade,
que deve compreender informaes sobre como a equipe de qualidade ir
garantir o cumprimento da poltica de qualidade, no contexto do programa ou
projeto a ser desenvolvido, quais mtodos, tcnicas, mtricas, treinamentos
e padres devam ser utilizados ao longo de todo o ciclo de vida do projeto.
O plano deve oferecer a base do gerenciamento dos riscos, dos testes, das
inspees, das auditorias e como devero ocorrer os reportes de problemas e
aes corretivas.
FONTE: Disponvel em: <http://www.infoclad.com.br/apostilas/Engenharia%20de%20Software/
Apostila%20de%20Engenharia%20de%20Software/Cap%EDtulos/UNIDADE%20
II/CAP%CDTULO%2015%20DA%20APOSTILA_QUALIDADE%20DE%20
SOFTWARE_2%AA%20%20PARTE.doc>. Acesso em: 8 maio 2016.

Pode-se citar, entre tantos outros exemplos, que a tcnica de preveno
de defeitos em um processo de desenvolvimento de software se d pelo uso de
instrues de procedimentos (padres formais), treinamentos, documentao,
modelagem e reengenharia; j as tcnicas de deteco de defeitos podem ser pela
anlise de cdigo; reviso por pares; testes, auditorias, verificaes e validaes.
Na gesto da qualidade de software existem diversas atividades voltadas

garantia da qualidade e ao controle de qualidade de software. A primeira para a
definio padronizada das atividades voltadas preveno de defeitos e problemas,
que podem surgir nos produtos de trabalho. rea que define padres, metodologias,
tcnicas e ferramentas de apoio ao desenvolvimento tendo como entrada o plano
de qualidade de software e os resultados de medies de qualidade. A segunda
voltada para o monitoramento de resultados especficos do projeto, ou seja, a
deteco de defeitos, executada atravs do uso de tcnicas que incluem revises
por pares, teste e anlise de tendncias, entre outras. Observe o quadro com as
principais diferenas entre elas (VASCONCELOS et al., 2006).
14

QUADRO 2 GARANTIA DE QUALIDADE X CONTROLE DE QUALIDADE
Garantia da Qualidade Controle da Qualidade

1. Garantia da qualidade garante que 1. As atividades de controle da
o processo definido e apropriado. qualidade focam na descoberta de
2. Metodologia e padres de defeitos especficos.
desenvolvimento so exemplos de 2. Um exemplo de controle da
garantia da qualidade. qualidade poderia ser: "Os requisitos
3. Garantia da qualidade orientada definidos so os requisitos certos?".
ao processo. 3. Controle da qualidade orientado a
4. Garantia da qualidade orientada produto.
preveno. 4. Controle da qualidade orientado
5. Foco em monitorao e melhoria de deteco.
processo. 5. Inspees e garantia de que o
6. As atividades so focadas no produto de trabalho atenda aos
incio das fases no ciclo de vida de requisitos especificados.
desenvolvimento de software. 6. As atividades so focadas no
7. Garantia da qualidade garante que final das fases no ciclo de vida de
voc est fazendo certo as coisas e desenvolvimento de software.
15
da maneira correta. 7. Controle da qualidade garante que
os resultados do seu trabalho so os
esperados, conforme requisitos.
FONTE: Disponvel em: <http://slideplayer.com.br/slide/3692245/>. Acesso em: 20 set. 2015.
Roger Pressmann (2011) definiu que a Engenharia de Software composta

em uma tecnologia em camadas com Foco em Qualidade, em que se d nfase
preocupao da disciplina, padronizao e satisfao do cliente.
Foco em Processo, em que se d nfase no planejamento das atividades

e no controle do projeto de software. Foco em Mtodos, em que se d nfase s
abordagens e s atividades necessrias para a construo de um software. Foco
em Ferramentas, em que se d nfase ao apoio automatizado ou semiautomatizado
para processos e mtodos.

A engenharia de software pode ser considerada uma tecnologia, com
mtodos e ferramentas prprios, estruturada em camadas, do ponto de vista
sistmico. A abordagem sistmica da engenharia de software deve se apoiar num
compromisso organizacional com a qualidade que leve cultura de um processo
contnuo de aperfeioamento, e essa cultura que, em ltima anlise, leva ao
desenvolvimento de abordagens cada vez mais efetivas. A camada de base em
que a engenharia de software se apoia o foco na qualidade, e o adesivo que
mantm unidas as camadas, estruturadas segundo a viso sistmica, o processo
(ZANCHETT, 2015).
As dimenses da qualidade de software: Qualidade do processo, qualidade

das pessoas, tecnologia de desenvolvimento, custo, tempo e cronograma.
9 PADRES, NORMAS E MODELOS DE QUALIDADE DE SOFTWARE
Entre os principais objetivos da qualidade de software est a definio

16 de tcnicas e ferramentas para serem utilizadas durante o ciclo de vida do
projeto, PADRONIZANDO a forma de realizar as atividades, um guia de trabalho
proporcionando assertividade no projeto, evitando erros humanos.
Diversos padres e normas de qualidade de software vm sendo propostos

ao longo dos anos. Essas normas tm sido fortemente adotadas nos processos
de software das organizaes em todo o mundo. As normas da International
Organization for Standardization (ISO, 2015) so padres internacionais que
especificam requisitos para um sistema gerencial de qualidade de uma organizao.
Com o crescimento substancial das indstrias de software e levando-se

em conta que a produo de software apresenta caractersticas peculiares, a ISO
tem trabalhado na definio de vrias normas que podem ser utilizadas como
guias e padres para diversas reas de atuao dentro do contexto da cincia da
computao.
As principais normas ISO aplicadas qualidade de produto ou processo

de software so:

Norma ISO/IEC 9000: um conjunto de documentos que engloba pontos
referentes garantia da qualidade em projeto, desenvolvimento, produo,
instalao e servios associados; objetivando a satisfao do cliente pela
preveno de no conformidades em todos os estgios envolvidos no ciclo da
qualidade da empresa.
Norma ISO/IEC 12207: o estabelecimento de uma estrutura comum utilizada
como referncia para os processos de ciclo de vida de software considerando
que o desenvolvimento e a manuteno de software devem ser conduzidos da
mesma forma que a disciplina de engenharia.
Norma ISO/IEC 15504: possui um conjunto de nove documentos que endeream
avaliao de processo, assessoria de treinamento e competncia, determinao
da capacidade e melhoria de processo e est se tornando um modelo de
referncia para outros padres, como o CMMI.
Norma ISO/IEC 9126: estabelece um modelo de qualidade para o produto de
software que avaliado conforme seis categorias bsicas, que so subdivididas em
algumas caractersticas que so importantes para cada categoria: funcionalidade,
confiabilidade, eficincia, usabilidade, manutenibilidade e portabilidade.
Norma ISO/IEC 27000: trata sobre a rea de segurana da informao atravs
17
de Requisitos do SGSI; Controles de Segurana; Diretrizes de Implementao;
Medio; Gesto de Risco e Auditoria de Segurana.
Norma ISO/IEC 15939: define um processo de medio aplicvel a sistemas,
engenharia de software e disciplinas de gesto.
Os modelos de qualidade mais difundidos nas indstrias de software no

Brasil so o CMMI e MPS.BR.
O principal propsito do CMMI (Capability Maturity Model Integration ou

Integrao dos Modelos de Capacitao e Maturidade de Sistemas) fornecer
diretrizes baseadas em melhores prticas para a melhoria dos processos e habilidades
organizacionais, cobrindo o ciclo de vida de produtos e servios completos, nas fases
de concepo, desenvolvimento, aquisio, entrega e manuteno.
O CMMI um dos modelos mais aceitos para a melhoria da qualidade

e do processo de software em todo o mundo e define os princpios e prticas
que devem ser aplicados a uma organizao para atingir estgios evolutivos de
maturidade em seu processo de software. Os cinco nveis de maturidade so: (1)

Inicial: processo imprevisvel e sem controle. (2) Repetvel: processo disciplinado. (3)
Definido: processo consistente e padronizado. (4) Gerenciado: processo previsvel
e controlado e (5) Otimizao: processo aperfeioado continuamente.
O MPS. BR (Melhoria de Processo de Software Brasileiro) um programa

que foi criado para melhorar a capacidade de desenvolvimento de software nas
empresas brasileiras voltados para mdias e pequenas empresas e com baixo
custo de implantao.
MPS.BR possui as seguintes metas: (1) definir e implementar o Modelo de

Referncia para Melhoria de Processos de Software (MR mps); (2) criar cursos em
diversos locais do pas para capacitar e formar consultores do modelo; (3) credenciar
instituies e centros tecnolgicos capacitados a implementar e avaliar o modelo
com foco em grupo de empresas.
Os sete nveis de maturidade do MPS.Br so: (G) Parcialmente gerenciado:

inicia o gerenciamento de requisitos e projetos; (F) Gerenciado: inclui medies,
gerncia de configuraes e garantia de qualidade; (E) Parcialmente definido: inclui
18
treinamento, adaptao de processos para gerncia de projetos; (D) Largamente
definido: envolve teses e integrao de produto; (C) Definido: gerncia de riscos; (B)
Gerenciado quantitativamente: avalia o desempenho dos processos e a gerncia
quantitativa dos mesmos; e (A) em otimizao: preocupao com a inovao e
anlise de causas (ZANCHETT, 2015).
Segundo Franciscani e Pestili (2015), existem medies entre os modelos,

e as comparaes entre eles podem ser visualizadas no quadro a seguir.
QUADRO 3 COMPARATIVO ENTRE OS MODELOS CMMI E MPS.BR
CMMI MPS.BR
O modelo de Qualidade CMMI O MPS.BR mais conhecido
reconhecido internacionalmente. nacionalmente e na Amrica Latina.
O modelo CMMI envolve um grande
No MPS.BR o custo da certificao
custo na avaliao e certificao do
mais acessvel.
modelo.

No CMMI necessrio investir tempo,
geralmente para se chegar aos nveis No MPS.BR as avaliaes so bienais.
de maturidade mais altos.
O CMMI tem foco global voltado para MPS.BR um modelo criado em funo
empresas de maior porte. das mdias e pequenas empresas.
O CMMI possui cinco nveis de MPS.BR possui sete nveis de
maturidade por estgio e seis na maturidade, onde a implementao
contnua. mais gradual.
O CMMI aceito como maturidade O MPS.BR o aceito como maturidade
para licitaes. para licitaes.
O CMMI torna as empresas O MPS.BR no torna as empresas
competitivas internacionalmente. competitivas internacionalmente.
No MPS.BR pode acontecer contrato
O CMMI no utiliza contrato conjunto
cooperado em grupo de empresas que
de empresas.
queiram a certificao.
Implementao mais complexa. Implementao mais simples.
Desenvolvido pelo Software Desenvolvido por algumas instituies
Engineering Institute SEI em 1992. brasileiras em 2003. 19
FONTE: Franciscani e Pestili (2015)
10 MTODOS GEIS
As Metodologias geis de Desenvolvimento de Software so indicadas como

sendo uma opo s abordagens tradicionais para desenvolver softwares: produzem
pouca documentao, recomendado documentar somente o que ser til. Em
essncia, as Metodologias geis foram desenvolvidas com o objetivo de vencer
as fraquezas percebidas e reais da Engenharia de Software (PRESSMAN, 2010).
Segundo Souza (2015), os 12 princpios do Manifesto gil so:
1. Garantia da satisfao do consumidor com entrega rpida e contnua de softwares

funcionais.
2. Mudanas de requisitos, mesmo no fim do desenvolvimento, ainda so bem-
vindas.

3. Frequentemente so entregues softwares funcionais (semanas, ao invs de
meses).
4. Desenvolvedores e pessoas relacionadas aos negcios devem trabalhar, em
conjunto, at o fim do projeto.
5. Construir projetos com indivduos motivados, dar-lhes ambiente e suporte
necessrios e confiar que faro seu trabalho.
6. Uma conversa face a face o mtodo mais eficiente e efetivo de transmitir
informaes para e dentro de uma equipe de desenvolvimento.
7. Software em funcionamento a principal medida de progresso.
8. Desenvolvimento sustentvel, de modo a manter um ritmo constante
indefinidamente.
9. Ateno contnua para com a excelncia tcnica e para com bons projetos
aumenta a agilidade.
10. Simplicidade a arte de maximizar a quantidade de trabalho no efetuado
essencial.
11. As melhores arquiteturas, requisitos e projetos emergem de equipes auto-
organizveis.
12. Em intervalos regulares, a equipe deve refletir sobre como se tornar mais
20
eficiente.
Entre todos os mtodos geis podem-se citar como exemplo o Scrum e o

Extreme Programming.
10.1 SCRUM
Scrum um mtodo gil de desenvolvimento de software criado por Jeff

Sutherland e sua equipe no incio de 1990. O Scrum considera uma abordagem mais
humana ao solucionar os problemas existentes no desenvolvimento de software.
Ao invs de desperdiar tempo criando documentaes extensas e detalhadas que
as pessoas acabam no lendo minuciosamente, no Scrum as equipes trabalham
com Sprints. So realizadas reunies curtas onde o time verifica quais as decises
que devem ser tomadas e os recursos do product backlog que entram nos sprints.
Elas tambm decidem quem trabalha nos sprints e quanto tempo dura cada tarefa
(DIMES, 2014).

O Scrum serve como fundamento para um projeto complexo, no ditando regras
que devem ser estritamente seguidas, mas que podem ser personalizadas conforme a
necessidade da equipe, servindo como base para uma gerncia de sucesso.
O Scrum um mtodo orientado a iteraes, sendo elas chamadas

de Sprints. As entradas de sprints ocorrem normalmente uma vez por ms. Os
requisitos e funcionalidades a serem desenvolvidas em um determinado projeto
so armazenados em uma lista conhecida como Product Backlog. Ao iniciar-se um
Sprint, realizada uma reunio de planejamento, na qual o Product Owner dita quais
as principais funcionalidades a serem implementadas e equipe as atividades que
ser capaz de produzir. As funcionalidades que sero implementadas em um Sprint
so removidas do Product Backlog e alocadas no Sprint Backlog.
A cada dia realizada uma reunio, analisando o que foi produzido no dia
anterior e o que ser produzido no dia atual. Essa reunio chamada de Daily
Scrum e acontece normalmente no incio da manh.
Ao fim de um Sprint, a equipe apresenta os requisitos e funcionalidades

21
desenvolvidas em uma Sprint Review Meeting. Aps uma retrospectiva, a equipe
de desenvolvimento passa para o planejamento do prximo Sprint.
A diviso de tarefas no Scrum baseia-se em Sprints e Reunies Dirias. O

Sprint o ciclo em que diversas atividades precisam ser feitas e entregues no final
para que possam ser entregues para o cliente, possuem durao fixa, normalmente
de duas a quatro semanas, mas podem ser adaptadas de acordo com a necessidade
da empresa, desde que mantenha a entrega constante.
Para ajudar a manter o time atualizado, comum no Scrum que todos os

dias, no mesmo horrio, seja realizada uma breve reunio em p, que consiste em
trs pequenas perguntas: O que fiz ontem em relao ao projeto?, O que vou
fazer hoje em relao ao projeto?, Existe algum impedimento para que a meta do
Sprint seja alcanada?. Ao responder estas perguntas, o time saber como est
indo o andamento do projeto.

10.2 EXTREME PROGRAMMING
A metodologia de desenvolvimento Extreme Programming (XP) uma

metodologia baseada em comportamentos e atitudes, tem foco em agilidade de
equipes e qualidade de projetos.
Sommerville (2011) afirma que nesse mtodo a diferena est na forma

como o sistema testado. No existe especificao do sistema que possa ser usada
por uma equipe de teste externa. Para evitar problemas nos testes, a abordagem
XP enfatiza a importncia dos testes do programa, incluindo um foco de testes que
reduz as chances de erros no identificados na verso atual do sistema.
A Programao Extrema valoriza o trabalho em equipe, desenvolvedores,

administradores e clientes so todos iguais e todos precisam estar dispostos
a ajudar quando necessrio. Portanto, sua principal caracterstica a
PROGRAMAO EM PARES.
Baseia-se em cinco princpios fundamentais: comunicao, simplicidade,

22 feedback, respeito e coragem e em diversas regras simples, alm das j definidas
pelo desenvolvimento gil: o cdigo deve ser escrito usando a tcnica de
programao em par, todo cdigo deve ter testes unitrios, o tempo deve ter um bom
espao para trabalhar, um novo teste ser criado quando um bug for encontrado,
entre outras regras especficas.
Conforme destacado por Souza (2015), o Extreme Programming utiliza a

Orientao ao Objeto como paradigma de desenvolvimento, onde inclui um conjunto
de regras e prticas com base nas seguintes atividades: Planejamento, Projeto,
Codificao e Teste. No planejamento realizada a criao de um conjunto de
histrias de usurios descrevendo as caractersticas e funcionalidades requeridas
pelo software que ser construdo, estas histrias (semelhantes aos casos de uso)
so escritas pelos clientes e colocadas em cartes de indexao, ento o cliente
atribui uma prioridade a cada histria e os desenvolvedores analisam cada histria e
atribuem um custo a cada uma delas, com base em nmero de semanas necessrias
para o seu desenvolvimento. Se a histria precisar de mais de trs semanas para
desenvolvimento, solicitado ao cliente que ela seja dividida em histrias menores
e, por fim, com o avano do projeto, o cliente pode adicionar novas histrias, mudar
a sua prioridade, subdividi-las e elimin-las.
11 TESTES DE SOFTWARE
Sommerville (2011) destaca que o teste de software serve para evidenciar

que o programa faz o que ele realmente deve fazer e para evidenciar os defeitos
que existem antes do uso. No processo de teste existem dois objetivos distintos,
que so: demonstrar que o software atende seus requisitos e descobrir em que
situao o software se comporta de forma incorreta.
O teste busca descobrir a maior quantidade de defeitos possvel,

importante saber onde os defeitos podem estar. Saber como os defeitos so criados
nos d pistas sobre onde procur-los durante o teste do sistema (PFLEEGER, 2004).
A tarefa de efetuar testes, em software, foi considerada secundria por

muito tempo. Geralmente, era vista como castigo para o programador ou como uma
tarefa, onde no se deveria gastar muito tempo e investimentos. O tema esteve
relegado a segundo plano e, at alguns anos atrs, no se encontrava muita literatura
sobre o assunto. Este um paradigma que vem mudando no mundo moderno de
desenvolvimento de software. Um dos testes, que ajudou a mudar este paradigma,
o teste de aceitao, que tem como principal caracterstica verificar o sistema, em 23
relao aos seus requisitos originais e s necessidades atuais do usurio.
O teste de software constitui-se em uma etapa importante no ciclo de

desenvolvimento de software. Uma das caractersticas mais importantes de um
conjunto de testes de software, adequadamente planejados, ter alta probabilidade
de detectar erros no programa sob teste (ZANCHETT, 2015).
Os testes de software so executados usando os procedimentos e

documentos de script de teste. Para que a fase de execuo de teste seja realizada
com sucesso deve(m) ser executado(s) os casos de teste.
A validao verificar se o software tem todos os itens necessrios para

atender ao cliente. O sistema que ser entregue ao cliente vai ajud-lo e o mesmo
vai ficar contente. Para a validao a pergunta : "Fizemos o software correto?"
A verificao fica escondida do usurio final, em comparao validao.

Os encarregados devem buscar e prever erros entre os requisitos. Verificar se todas

as etapas de desenvolvimento conforme planejado foram realizadas e da melhor
forma. Para a verificao a pergunta : "Fizemos o software corretamente?".
Realizar os testes nada mais que entrar com vrios dados de maneira
diferente e analisar os dados de sada e seu comportamento. Aqui so realizados
vrios tipos de teste, como, por exemplo, teste de interface, de regras de negcio
e de carga. Para testar a pergunta : "O software tem defeito?".
Teste de software o processo que visa sua execuo de forma controlada,

com o objetivo de avaliar o seu comportamento baseado no que foi especificado.
A execuo dos testes considerada um tipo de validao.
Na rea de testes, os tipos de Teste Caixa Preta, que visam verificar a

funcionalidade e a aderncia aos requisitos, em uma tica externa ou do usurio, sem
se basear em qualquer conhecimento do cdigo e da lgica interna do componente
testado, e os de Teste Caixa, que visam avaliar as clusulas de cdigo, a lgica
interna do componente codificado, as configuraes e outros elementos tcnicos.
24
Os tipos de testes conforme seus nveis so:
Teste de Unidade: o teste realizado em cada componente do programa

isoladamente, no qual se verifica se ele funciona de forma adequada aos tipos
de entradas esperadas.
Teste de Integrao: tem o objetivo de provocar falhas associadas s interfaces
entre os mdulos quando esses so integrados para construir a estrutura do
software que foi estabelecida na fase de projeto.
Teste de Sistema: avalia o software em busca de falhas utilizando o mesmo como
se fosse um usurio final.
Teste de Aceitao: realizado em conjunto com os clientes e nele o sistema
verificado em comparao com a descrio dos requisitos do cliente.
Segundo Zanchett (2015), as prticas de desenvolvimento na rea de

testes so:
TDD Test - Driven Development: o Desenvolvimento Guiado a Testes; se

escreve primeiramente os testes para posteriormente escrever o cdigo, o

processo aborda os parmetros Red, Green e Refactor: (1) Escrever um teste,
mesmo sem ter escrito o cdigo real a ser testado; (2) Executar os testes e
acompanhar a falha (Red); (3) Escrever a funcionalidade do sistema que ir
ser testada; (4) Testar novamente, agora para passar (Green); (5) Refatorar a
funcionalidade e escrever por completo (Refactor); (6) Prxima estria ou caso
de uso e iniciar novo teste.
DDD Domain - Driven Design: no desenvolvimento guiado ao domnio o
foco no Domnio do Software, no propsito que o software deve atender, a
automatizao de um processo de negcio. O DDD traz abordagens de como fazer
isto, como atender um domnio complexo de informaes. Qualquer abordagem
de DDD muito bem aceita numa metodologia gil.
BDD Behavior - Driven Development: o desenvolvimento guiado por
comportamento, associa os benefcios de uma documentao formal,
escrita e mantida pelo negcio, com testes de unidade que demonstram que
essa documentao efetivamente vlida. Na prtica, isso garante que a
documentao deixa de ser um registro esttico, que se converte em algo
gradualmente ultrapassado, em um artefato vivo que reflete constantemente o
estado atual de um projeto.
25
ATDD - Acceptance Test - Driven Development: o desenvolvimento guiado por
testes de aceitao; o trabalho ocorre em resposta a testes de aceitao. O ATDD
pode ser considerado como anlogo ao TDD.
FDD - Feature Driven Development: desenvolvimento guiado por funcionalidades,
serve para gerenciar e desenvolver projetos de software atravs de um conjunto
de atividades simplificadas, de maneira a estimular o compartilhamento do
conhecimento acerca do software e da criao de bons cdigos.

------------ [ TPICO 2 - PROGRAMAO ORIENTADA A OBJETOS ] ------------
Caro(a) acadmico(a), vamos dar incio ao estudo do tema Programao

Orientada a Objetos, assunto de extrema importncia no cenrio atual. Abordaremos
os seguintes assuntos: Conceitos da Programao Orientada a Objetos, Projeto
Orientado a Objetos, Objetivos da Modelagem, Vantagens do Projeto OO, Diagramas
Estruturais, Diagramas Comportamentais, Padro de Projetos, Vantagens do uso
de padres e quais so os padres mais utilizados.
Iniciaremos os estudos empregando o mximo de ateno e foco para que

os resultados sejam os melhores possveis. Vale ressaltar que os assuntos aqui
abordados esto listados de forma resumida, e em caso de dvidas, o caderno
da disciplina deve ser consultado. Esperamos que esse resumo contribua para o
incremento e fixao dos seus conhecimentos!
Prof. Simone Cristina Alssio
27
1 CONCEITOS DA PROGRAMAO ORIENTADA A OBJETOS
Orientao a objetos uma tecnologia que visualiza os sistemas como um

conjunto de objetos. Foi desenvolvida pensando na reutilizao de componentes,
utilizando-se de conceitos como abstrao, hierarquizao, modularizao,
relacionamento e persistncia.
Um modelo orientado a objetos composto por quatro elementos bsicos:

Objeto: um conjunto de mtodos que gravam e recuperam dados de
operaes. Um objeto possui todas as informaes de si mesmo. Executa operaes
de acordo com mensagens recebidas. Um objeto pode enviar mensagens para
outros objetos e o resultado da operao depende diretamente do estado do objeto
quando o mesmo recebe a mensagem.
Mensagem: so solicitaes/requisies enviadas ao objeto receptor com
o intuito de obter um resultado.
Mtodos: procedimento executado pelo objeto na busca por um resultado,
quando recebe uma mensagem.
Atributos: definem as caractersticas do objeto.
Classe: pode ser entendida como um conjunto de atributos que definem
as caractersticas de um objeto.
Encapsulamento: viso do objeto no estado interno, incluindo suas
mensagens e mtodos.
Polimorfismo: permite que a mesma mensagem seja enviada por mais
de um objeto.
Herana: uma caracterstica importantssima, pois permite que as
subclasses herdem componentes da classe pai. Permite a criao de novas classes
sem ocasionar redundncia de cdigo.
A Programao Orientada a Objetos surgiu como uma evoluo da
programao procedural e da programao modular.
A possibilidade de reutilizar componentes a sua principal contribuio.
Isso possvel atravs das propriedades herana e polimorfismo.
O alicerce da orientao a objetos so os objetos e a troca de mensagens
que ocorre entre os mesmos.
A instanciao pode ser entendida como a criao de um objeto tendo
como origem uma classe. As classes tm nome, atributos e mtodos.
28
A linguagem de programao Java uma das linguagens mais utilizadas
no desenvolvimento orientado a objetos. multiplataforma, pois sua compilao
executada por uma mquina virtual, que separa detalhes do sistema operacional.
A plataforma Java se divide basicamente em quatro grandes grupos:

JavaSE utilizado para desenvolvimento de aplicaes desktop.
JavaEE utilizado para aplicaes em ambientes distribudos, multitarefa e
complexos.
JavaME usado para dispositivos menores, como cartes, telefones, microchips
etc.
JavaFX permite a criao de RIA em Java. Pertence Oracle.
Aplicaes Java disponibilizam alguns recursos particulares que garantem

a sua otimizao. Logo, tende a ser mais rpida que o desenvolvimento em C e
C++, em determinadas situaes.
Os atributos representam as informaes de uma classe. Exemplo: Classe

CARRO atributos: marca, cor, modelo. Cada atributo deve ser tipado, pois a linguagem

usa amplamente o conceito de tipagem. A tipagem consiste em atribuir um tipo de dado
para o atributo (se ele do tipo texto ou numrico, por exemplo). Nesta linguagem o
nome dos atributos comea com letra maiscula. Se um atributo tiver dois nomes, o
primeiro comea com letra maiscula e os demais ficam todos em minsculo.
Os mtodos so as operaes invocadas pelos objetos, cujo retorno pode

ser 0 ou 1 como retorno. O retorno pode ser de qualquer tipo, inclusive classes.
Caso no retorne nada, utiliza-se a palavra void. Mtodos comeam com um verbo
no infinitivo seguido de um substantivo. Exemplo: calcularSalario(). Parmetros
podem ser passados aos mtodos para que executem suas operaes, usando-os
como filtros. Estes podem ser de qualquer tipo de dados, ou podem ser classes.
Porm, determina-se um nmero mximo de cinco parmetros por mtodo segundo
as boas prticas da linguagem JAVA.
Instanciar uma classe significa que ela um objeto em memria que j

pode ser usado no programa. Somente neste momento os valores so associados
aos atributos, e os mtodos esto liberados para serem invocados. Do contrrio, o
compilador coloca o programa na sesso de excees.
29
Os valores dos atributos representam o estado deste objeto, e os mtodos,

o seu comportamento.
A herana permite o relacionamento entre classes, onde uma superclasse

fornece o estado e comportamento que sero herdados por outras classes. As
classes inferiores no relacionamento so conhecidas subclasses. Uma classe
me tem vrias filhas. Mas uma classe filha pode estar associada somente a uma
classe me. Hierarquias de herana devem ter no mximo dois ou trs nveis, sendo
que no existe herana mltipla em JAVA.
possvel passar atributos ou mtodos para classes filhas utilizando-se o

modificador protected, mas ambos ficam privados para outros pacotes.
Uma desvantagem da herana que ela quebra o encapsulamento. Uma

alternativa o uso da composio, onde uma classe possui um atributo do tipo
classe e que pode ser reutilizado. A composio permite a reutilizao de cdigos
e componentes de outras classes sem violar o encapsulamento.

2 PROJETO ORIENTADO A OBJETOS
Projeto orientado a objetos apenas uma das etapas do processo de

desenvolvimento de software orientado a objetos.
No projeto orientado a objetos os desenvolvedores pensam nas coisas, nos

objetos, em vez de se focar nas suas funcionalidades.
uma arquitetura voltada para os servios ofertados pelos objetos.
Objetos representam algo do mundo real e so autogerenciveis.
Objetos so independentes entre si e encapsulam representaes de informao
e estado.
As reas de dados compartilhados entre os objetos so eliminadas.
A troca de mensagens faz a comunicao entre os objetos.
O projeto orientado a objetos divide-se em trs etapas distintas:

Anlise OO prope o desenvolvimento de um modelo O.O focado no domnio
do aplicativo a ser desenvolvido. A identificao dos objetos relaciona-se com a
realidade da situao-problema a ser resolvida.
30 Projeto OO prope a criao de um modelo O.O para implementar os requisitos
do problema que dever ser resolvido.
Programao OO a execuo das etapas acima, implementada por uma
linguagem de programao O.O.
A modelagem a base da tecnologia de orientao a objetos. Suas

categorias principais so:
A dimenso estrutural dos objetos define a identidade de cada objeto, sua
classificao, seu encapsulamento e seus relacionamentos.
A dimenso dinmica do comportamento dos objetos a representao
dos estados vlidos dos objetos e a especificao dos eventos que causam a
transio desses estados.
A modelagem orientada a objetos uma forma de pensar sobre problemas reais
usando a UML para represent-los.

3 OBJETIVOS DA MODELAGEM
Permitir uma visualizao do sistema mais prxima da realidade.

Permitir especificar arquitetura e comportamento de todas as funcionalidades do
sistema.
Fornecer padres para desenvolver o sistema de forma organizada.
Documentar as decises tomadas durante o processo de desenvolvimento.
Aps concluda a fase da anlise orientada a objetos, d-se incio fase do

projeto propriamente dito, cujo planejamento e execuo obedece algumas etapas,
conforme os itens definidos abaixo:
Compreender e definir o contexto e os modos de utilizao do sistema.

Projetar a arquitetura do sistema.
Identificar os principais objetos do sistema.
Descrever os modelos de projeto.
Especificar as interfaces dos objetos.
31
4 VANTAGENS DO PROJETO OO
Facilidade de manuteno: torna mais rpida as atividades de programao e

manuteno de sistemas de informao.
Os modelos gerados permitem maior compreenso.
A reutilizao do cdigo mais eficiente.
A comunicao mais segura e rpida.
Percebe-se uma maior estabilidade e flexibilidade nas construes.
Modelos de objetos servem para especificar objetos e suas classes, e

tambm, seus distintos relacionamentos. O modelo nada mais do que o desenho
do projeto em si. o modelo que contm a informao entre o que necessrio no
sistema, e como isso ser alcanado.
Por isso, os mesmos devem ser abstratos, no se importando com detalhes

desnecessrios ou secundrios. O nvel de detalhamento do projeto, alis, deve

ir at o ponto de favorecer o claro entendimento dos programadores, para que os
mesmos decidam de forma assertiva pelas melhores formas de implementao.
Dentre vrios modelos, voc ter que decidir qual ser o mais vivel e lhe
permitir o maior nvel de detalhamento para o seu projeto. Para isso, voc dever
ter em mente que tipo de projeto/sistema est construindo, pois, cada sistema tem
suas necessidades especficas e pode apontar para modelos distintos.
Poucos sistemas utilizam-se de todos os modelos. Reduzir o nmero

de modelos implica em economia de tempo, recursos financeiros e humanos no
desenvolvimento.
S para lembrar, existem dois tipos de modelos: estticos e dinmicos. Para

a gerao dos modelos utiliza-se atualmente a UML que se utiliza de diagramas na
composio. A verso 2.0 da UML traz consigo 13 diagramas, divididos em quatro grupos:
diagramas estruturais;
diagramas comportamentais;
32
diagramas de interao;
diagramas de implementao.
5 DIAGRAMAS ESTRUTURAIS
De Classe: Este diagrama fundamental e o mais utilizado na UML e serve de

apoio aos outros diagramas. O Diagrama de Classe mostra o conjunto de classes
com seus atributos e mtodos e os relacionamentos entre classes.
De Objeto: O Diagrama de Objeto est relacionado com o diagrama de classes e
praticamente um complemento dele. Fornece uma viso dos valores armazenados
pelos objetos de um Diagrama de Classe em um determinado momento da
execuo do processo do software.
De Componentes: Est associado linguagem de programao e tem por
finalidade indicar os componentes do software e seus relacionamentos.
De Implantao: Determina as necessidades de hardware e caractersticas
fsicas do sistema.

De Pacotes: Representa os subsistemas englobados de forma a determinar
partes que o compem.
De Estrutura: Descreve a estrutura interna de um classificador.
6 DIAGRAMAS COMPORTAMENTAIS
De Caso de Uso (Use Case): Geral e informal para fases de levantamento e

anlise de Requisitos do Sistema.
De Mquina de Estados: Procura acompanhar as mudanas sofridas por um
objeto dentro de um processo.
De Atividades: Descreve os passos a serem percorridos para a concluso de
uma atividade.
De Interao: Dividem-se em:
o De sequncia: Descreve a ordem temporal em que as mensagens so trocadas

entre os objetos.
o Geral interao: Variao dos diagramas de atividades que fornece viso geral 33
dentro do sistema ou processo do negcio.
o De comunicao: Associado ao diagrama de sequncia, complementando-o e
concentrando-se em como os objetos esto vinculados.
o De tempo: Descreve a mudana de estado ou condio de uma instncia de
uma classe ou seu papel durante o tempo.
7 PADRO DE PROJETOS
UML: Linguagem de modelagem unificada que permite padronizar a

representao de um sistema. No uma metodologia de desenvolvimento. Presta
auxlio para facilitar o entendimento da comunicao entre os objetos. Permite
a visualizao do sistema em diagramas padronizados, alm de especificar,
documentar e estruturar um sistema para uma pr-visualizao.

Padres de projeto de software so utilizados para prover solues
reutilizveis para problemas que ocorrem com frequncia no processo de
desenvolvimento de software. necessrio empenho e estudo para entender a
correta aplicao dos padres. O objetivo dos padres documentar e codificar
conhecimentos para que estes possam ser aplicados em cenrios distintos. Padres
ajudam na padronizao e tambm na aprendizagem. necessrio que se tenha
conhecimento sobre os limites e estrutura da soluo, bem como os frameworks
que serviro de suporte ao domnio.
Frameworks so necessrios para preencher os requisitos funcionais. Eles

so elaborados aps a definio da estrutura da soluo. Os frameworks permitem
compreender os objetos e suas relaes no alicerce do problema. Essa compreenso
a primeira etapa na criao dos frameworks.
Padres impem um vocabulrio comum a todos os envolvidos no

desenvolvimento de aplicativos computacionais. Todo padro deve ter um nome,
problema, soluo, consequncia e exemplo de utilizao ou aplicao.
34
No desenvolvimento de software os padres no so as classes, nem os
objetos. Eles so utilizados para construir padres de classes e objetos.
8 VANTAGENS DO USO DE PADRES
Facilitam a construo de softwares confiveis atravs de arquitetura validada

e testada.
Promovem a reutilizao dos modelos em projetos futuros.
Ajudam a perceber erros comuns no desenvolvimento de sistemas.
Facilitam o desenvolvimento dos aplicativos independentemente da tecnologia
utilizada.
Encurtam a fase do projeto no processo de desenvolvimento do software.
Os padres esto divididos em trs categorias: estrutural, comportamental e

de criao. necessrio observar os requisitos da soluo, sua estrutura arquitetural e os
modelos de anlise para cada uma das categorias antes de iniciar a construo do framework.

No total, a literatura apresenta hoje 23 padres, conforme a Figura 1.
FIGURA 1 PADRES DE PROJETO
35
FONTE: Disponvel em: <http://www2.ic.uff.br/~viviane.silva/2010.1/es1/util/aula12.pdf>. Acesso em:

23 maio 2015.
Os padres atuais foram amplamente testados e validados. So bem

definidos e documentados, facilitando a elaborao das solues de diversos
problemas quando so aplicados corretamente.
Em 1979 surgiu a primeira verso do padro MVC, que divide uma aplicao
em trs partes distintas e define a interao entre elas (controller, model, view). Ele
separa a representao da informao da interao do usurio.
Umcontrolador(controller): trata a entrada dos dados fazendo a converso de

comandos para o modelo e a viso.

Um modelo(model): o modelo armazena os dados da aplicao. Representa a
lgica e as regras do negcio.
Aviso(view): a sada dos dados, que pode ser representada de qualquer
forma, inclusive por tabelas.
Os padres so classificados em duas categorias distintas: finalidade e

escopo.
Os padres so divididos em cinco grupos: Padres de criao; Padres

estruturais; Padres comportamentais; Padres para classes; e Padres para
objetos.
Nenhum padro ir descrever um projeto novo ou que ainda no foi validado.
A soluo deve ser especfica para o problema a ser resolvido, e genrica

e abstrata o suficiente para ser replicada ou reutilizada na soluo de problemas
futuros e de tecnologias distintas.
36
Padres devem ser considerados e usados como guias ou mapas, jamais
como estratgia de soluo.
Padres no devem ser considerados como um meio definitivo na soluo.
Padres ajudam apenas a melhorar a implementao aps a definio de

todos os recursos necessrios ao desenvolvimento do projeto.
Antipadro nada mais do que fazer uso dos padres de forma errada ou
exagerada. Isso pode ser constatado pela utilizao de padres imprprios para
um determinado contexto, ou uso inadequado em determinada situao.
Para viabilizar um Projeto de Software Orientado a Objeto primordialmente

necessrio definir como vai ocorrer a comunicao entre o usurio e o sistema, e as
principais funcionalidades que o sistema disponibilizar para o mesmo.

9 OS PADRES MAIS UTILIZADOS
O Padro Singleton: garante a existncia de apenas uma instncia de

umaclasse, mantendo um ponto global de acesso aoobjeto.
O Padro Factory Method:permite s classes delegar para subclasses
decidirem. O factory method permite delegar a instanciao para as subclasses.
O Padro Abstract Factory: define uma interface para criar famlias de
objetos sem especificar suas classes concretas.
O Padro Composite: utilizado para representar um objeto que constitudo
pela composio de objetos similares a ele.
O Padro Decorator: permite adicionar um comportamento a um objeto j

existente em tempo de execuo.
O Padro Faade: relaciona-se ao uso de bibliotecas; reduz as dependncias
em relao s caractersticas internas de uma biblioteca, trazendo flexibilidade
no desenvolvimento do sistema.
O Padro Iterator: umpadropara percorrer listas, conjuntos, mapas etc.,
como se fosse um cursor.
O Padro Observer: permite que objetos interessados sejam avisados da 37
mudana de estado.
O Padro Template Method: monta o esqueleto de um algoritmo de uma forma
abstrata, deixando que subclasses completem algumas das etapas.
Novos padres de projeto surgem a todo momento. Padres para reas

especficas, como padres de interface, padres de persistncia, padres de
arquitetura etc.

------- [ TPICO 3 - LGICA, ALGORITMOS E ESTRUTURA DE DADOS ] -------

conceitos relacionados a uma das disciplinas essenciais ao nosso curso de Anlise
e Desenvolvimento de Sistema, a disciplina de Lgica, Algoritmos e Estrutura de
Dados. Apresentaremos de forma condensada os temas que so os pilares desse
assunto que introduz os alunos lgica. Reforamos que esse material visa oferecer
ao acadmico um contedo importante para sua vida acadmica e profissional.
Iniciaremos os estudos empregando o mximo de ateno e foco para

que os resultados sejam os melhores possveis, contribuindo para o incremento e
fixao dos seus conhecimentos!
Prof. Elton Giovani Gretter

Prof. Greisse Moser Badalotti
39
1 LGICA DE PROGRAMAO
Dentre as disciplinas essenciais para a formao do profissional da rea

de Anlise e Desenvolvimento de Sistemas destaca-se a Lgica, a qual, segundo
Bastos (1991), a disciplina que trata das formas de pensamento, da linguagem
descritiva do pensamento, das leis da argumentao e raciocnios corretos, dos
mtodos e dos princpios que regem o pensamento humano.
De maneira geral, a palavra lgica encontra-se relacionada a uma forma

distinta de raciocinar, a fim de justificar determinada situao, podendo ser
classificada em Lgica Aristotlica, de Argumentao, Matemtica, Proposicional e
de Programao, sendo esta ltima a de maior relevncia para os nossos estudos
neste momento.
A lgica de programao essencial no desenvolvimento dos programas

e sistemas informticos (pois ela define o encadeamento lgico para esse
desenvolvimento), os quais so denominados de algoritmos e consistem em uma
sequncia lgica de instrues para que a funo seja executada.
FIGURA 1 EXEMPLO DE LGICA DE PROGRAMAO
FONTE: O autor
Segundo o Dicionrio Aurlio (2010), algoritmo : Sequncia de raciocnios

ou operaes que oferece a soluo de certos problemas. Nesse sentido, um
algoritmo pode ser entendido como uma sequncia de passos ou instrues, que
40 tm por objetivo resolver determinado problema, desde situaes mais rotineiras do
cotidiano, como a receita para fazer um bolo, at situaes mais complexas, como
o desenvolvimento de um sistema computacional. Todavia, independentemente
dos objetivos que se busca alcanar, para atingi-los h uma cadeia de passos que
devem ser executados em uma sequncia bem definida.
Tomaremos por base que voc, acadmico, j detm os conhecimentos

bsicos sobre o desenvolvimento dos algoritmos e, portanto, abordaremos um
contedo mais avanado, como: Estruturas de Seleo; Estruturas de Repetio;
Funes Recursivas; Matrizes Multidimensionais; Listas Encadeadas; Pilhas, Filas
e Pesquisa Binria.
1.1 ESTRUTURAS DE SELEO
As estruturas de seleo permitem que um algoritmo tome caminhos

distintos conforme determinada situao, e esses caminhos podero executar
as mais variadas instrues. Segundo Kochanski e Andrietti (2005, p. 49): [...] a

estrutura de seleo permite a definio de uma condio para que um conjunto
de instrues seja ou no executado. Por esse motivo, as estruturas de seleo
tambm so conhecidas como estruturas condicionais.
1.1.1 Se-ento-seno
O comando SE-ENTO com base no resultado de uma condio, que

pode retornar um valor Verdadeiro ou Falso, ir definir o fluxo do algoritmo, ou seja,
estabelece qual bloco de instrues deve ou no ser executado. Este comando
pode se apresentar de duas formas distintas, no entanto, sua funo a mesma:
decidir por uma ou por outra alternativa.
SE(condio) ENTO
Instrues a serem executadas quando a condio for VERDADEIRA
SENO
Instrues a serem executadas quando a condio for FALSA> 41
FIM-SE
Importante ressaltar que o bloco de cdigo SENO opcional, sendo

muito comum encontrarmos instrues de deciso apenas com SE-ENTO,
sem o bloco SENO.
Vejamos a utilizao do comando em um caso prtico.

algoritmo CalculaMedia;
var
n1; n2; media : real;
inicio
escreva (Informe a primeira nota: );
leia (n1);
escreva (Informe a segunda nota: );
leia (n2);
media := (n1 + n2) / 2
SE (media >= 7) ENTO
escreva (O aluno est aprovado)
SENO
escreva (O aluno est reprovado)
FIM_SE
fim.
42
1.1.2 Seleo Encadeada
No exemplo visto no item anterior precisvamos verificar apenas duas situaes:

se o aluno havia sido Aprovado ou Reprovado com base na mdia obtida pelo mesmo.
Todavia, existem casos em que haver mais situaes para serem analisadas, como,
por exemplo, se o aluno est Aprovado, em Exame ou Reprovado, ocasio em
que ser necessria a utilizao de uma Seleo Encadeada, ou seja, um comando
SE-ENTO subordinado a outro comando SE-ENTO.
Vamos estabelecer as regras e verificar como ficaria a estrutura deste

algoritmo:
Se a mdia for maior ou igual a 6.5, o aluno est aprovado.

Se a mdia for maior ou igual a 5.0 e menor que 6.5, o aluno est em exame.
Se a mdia for menor do que 5.0, o aluno est reprovado.

1 algoritmo CalculaMedia;
2 var
3 n1; n2; media : real;
4 inicio
5 escreva (Informe a primeira nota: );
6 leia (n1);
7 escreva (Informe a segunda nota: );
8 leia (n2);
9 media := (n1 + n2) / 2
0 SE (media >= 6.5) ENTO
1 escreva (O aluno est aprovado)
2 SENO
3 SE (media >= 5) ENTO
4 escreva (O aluno est em exame)
5 SENO
6 escreva (O aluno est reprovado)
7 FIM_SE
8 FIM_SE 43
9 fim.
Sempre que um bloco de instrues dentro de uma estrutura de seleo

for executado, os demais blocos sero desconsiderados. Vejamos um exemplo:
Se a mdia for 8.0, ou seja, maior do que 6.5, ser executado o bloco da linha 11.
Depois de executar esse bloco, a execuo do algoritmo passar para a linha 18,
ou seja, os blocos das linhas 12 a 17 no sero executados.
Vejamos outras situaes:
Se a mdia for 5.5: Ao verificar a condio SE (media >= 6.5) obteremos

como resultado o valor falso, situao em que ser executado o primeiro SENO
(linha 12). Ao executar o bloco de instrues deste SENO, haver uma nova
condio a ser verificada, SE (media >= 5). Nesse caso, o resultado ser verdadeiro,
devendo executar o bloco de instrues logo abaixo, exibindo a mensagem O aluno
est em exame.

Se a mdia for 4,0: Ao verificar a condio SE (media >= 6,5) o resultado
ser falso, situao em que ser executado o primeiro SENO (linha 12). Ao executar
o bloco de instrues deste SENO, haver uma nova condio a ser verificada,
SE (media >= 5), onde, novamente, o resultado ser falso. A execuo avanar
para o prximo SENO (linha 15), que executar o bloco de instrues, exibindo a
mensagem O aluno est reprovado.
1.2 ESTRUTURAS DE REPETIO
As estruturas de repetio, tambm conhecidas por laos ou looping,

possibilitam que uma sequncia de comandos seja executada reiteradas vezes,
at que determinada condio de interrupo seja atendida. Dentre os tipos de
estruturas de repetio destacam-se: Enquanto-faa; Para-faa e Repita-at, os
quais sero aprofundados na sequncia.
44
1.2.1 Enquanto-faa
Essa estrutura de repetio tambm conhecida por loop pr-testado, pois

a condio para sua execuo verificada logo no incio, ou seja, se a condio
resultar falso, as instrues que esto dentro do bloco no sero executadas
nenhuma vez.
Ressalta-se que nessa estrutura de repetio, toda vez que a execuo

chegar ao fim do bloco, retornar para o incio da prpria estrutura e verificar
novamente se a condio verdadeira. Se for, executa novamente o referido bloco
de instrues.
Vamos a um exemplo, onde o bloco de instrues ser executado diversas

vezes, at que o usurio informe que no deseja mais continuar.

1 Algoritmo EnquantoFaca;
2 var
3 continuar: Caractere;
4 Inicio
5 Escreva (Informe s para continuar ou outro caractere para sair: );
6 Leia (continuar);
7 Enquanto (continuar = s) faa
8 Inicio
9 Escreva (Voc quis continuar!);
0 Escreva (Informe s para continuar ou outro caractere para sair: );
1 Leia (continuar);
2 Fim
3 Escreva (Voc no quis continuar!);
4 Fim.
45
1.2.2 Para-faa
A estrutura Para-faa a mais simples das estruturas de repetio, uma vez

que permite que um bloco de instrues seja executado reiteradas vezes, conforme
quantidade predeterminada. Portanto, deve-se saber o nmero de vezes que o bloco
de instrues ser executado, definindo-se um limite inferior e outro superior, alm
da varivel de controle, a qual ser incrementada ou decrementada, conforme a
necessidade. Vejamos um exemplo:
1 Algoritmo ParaFaca;
2 var
3 i: Inteiro;
4 Inicio
5 Para i := 1 at 10 faa
6 Inicio
7 Escreva (i);
8 Fim
9 Fim.

1.2.3 Repita-at
uma estrutura de repetio que tem por funo repetir um determinado

bloco de comandos at que a condio se torne verdadeira. Ao contrrio das demais
estruturas de repetio, o Repita-at testa a condio somente ao final, executando,
desta forma, pelo menos uma vez o bloco de instrues nele contido.
Vejamos um exemplo:
1 Algoritmo RepitaAte;
2 var
3 Idade : Inteiro;
4 Inicio
5 Repita
6 Escreva (Qual a sua idade: );
7 Leia(Idade);
8 Escreva(A idade informada : , Idade);
9 At (Idade = 0);
0 Fim.
46
1.3 VETORES UNIDIMENSIONAIS
Como se sabe, a varivel um local na memria do computador, que

recebe um nome e possibilita o armazenamento de um valor por vez. Contudo,
algumas situaes exigem o armazenamento de vrios valores concomitantemente,
ocasio em que o desenvolvedor poder fazer uso dos vetores, ou seja, uma varivel
dividida em vrios compartimentos, onde cada compartimento identificado por
meio de um nmero, referente posio de uma determinada informao no vetor
em questo, sendo que o nmero de cada posio denominado de ndice.
Vejamos a representao visual de como estruturado um vetor. Para

tanto, tomaremos como exemplo um vetor que possibilite o armazenamento de
vrios Nomes.

FIGURA 2 REPRESENTAO GRFICA DO VETOR UNIDIMENSIONAL
FONTE: O autor (2016)
Conforme representado no exemplo acima, temos uma nica caixa,

denominada Nomes com vrios compartimentos numerados, sendo que cada um
permite apenas a insero de um nico elemento, mas que devero ser do mesmo 47
tipo de dados, ou seja, se a varivel vetor for do tipo Caractere, cada compartimento
receber apenas valores do tipo Caractere, se a varivel for do tipo Inteiro, todos
os compartimentos devero receber valores do tipo Inteiro.
A utilizao de vetores em nossos algoritmos implicar consequentemente

na utilizao de estruturas de repetio, com vistas a possibilitar a navegao, tanto
para a leitura quanto para a insero dos elementos em cada compartimento do
vetor. Vejamos um exemplo:

1 Algoritmo Vetor_ParaFaca;
2 var
3 Nomes : Vetor [1..4] de Caractere;
4 i : Inteiro;
5 Incio
6 Para i := 1 at 4 faa
7 Incio
8 Escreva (Informe o ,i, nome: );
9 Leia(Nomes[i]);
0 Fim
1 Fim.
1.4 MATRIZES
Matriz (array multidimensional) um vetor de vetores. No nosso exemplo

48 anterior, imagine uma matriz para armazenar quatro notas para cada um dos nomes.
Ou seja, um vetor de quatro posies, e em cada posio do vetor h outro vetor
com quatro posies, sendo que cada item do vetor (matriz) acessado por um
nmero chamado de ndice.
Para a melhor compreenso do conceito de matrizes, veja o algoritmo

abaixo, o qual tem por finalidade permitir a incluso de quatro nomes e de quatro
notas para cada nome e, ao final, apresentar a mdia de cada um.

1 Algoritmo Media
2 var
3 nomes: vetor [1..4] de caractere;
4 notas: vetor [1..4,1..4] de real;
5 medias: vetor [1..4] de real;
6 i, j: inteiro
7 Inicio
8
9 //Leitura dos nomes e das notas
0 Para i := 1 ate 4 faa
1 Inicio
2 Escreva (Informe o nome da posio , i, : );
3 Leia (nomes[i]);
4 Para j := 1 ate 4 faa
5 Inicio
6 Escreva (Informe a nota , j, " para o nome ", nomes[i], : );
7 Leia (notas[i, j])
8 Fim 49
9
0 //Clculo das mdias
1 medias[i] := (notas[i, 1] + notas[i, 2] + notas[i, 3] + notas[i, 4]) / 4
2 Fim
3
4 //Apresentao dos resultados
5 Para i := 1 ate 5 faa
6 Inicio
7 SE medias[i] >= 6 ENTAO
8 ESCREVA (O aluno , nomes[i], foi aprovado com as notas (, notas[i 1],
9 ", ", notas[i, 2], ", ", notas[i, 3], ", ", notas[i, 4], ") e mdia: ", medias[i])
0 SENAO
1 ESCREVA (O aluno , nomes[i], foi reprovado com as notas (, notas[i, 1],
2 ", ", notas[i, 2], ", ", notas[i, 3], ", ", notas[i, 4], ") e mdia: ", medias[i])
3 Fim
4 Fim.

1.5 LISTAS ENCADEADAS
Na lista encadeada, cada elemento inserido na estrutura ser alocado de

forma dinmica na memria. Consequentemente, o espao total de memria utilizado
pela estrutura ser proporcional ao nmero de elementos nela armazenados,
diferentemente do que ocorre em um vetor, que reservar o espao fsico na
memria, independentemente do nmero de elementos inseridos.
De acordo com Deitel e Deitel (2003, p. 62):
Criar e manter estruturas de dados dinmicas exige alocao

dinmica de memria a capacidade de um programa obter
mais espao de memria durante a execuo para armazenar
novos nodos e liberar espao no mais necessrio. [...] O limite
para alocao dinmica de memria pode ser to grande quanto
quantidade de memria fsica disponvel no computador ou
a quantidade de espao disponvel em disco em um sistema
de memria virtual. Frequentemente, os limites so muito
menores, porque a memria disponvel do computador deve
ser compartilhada entre muitos aplicativos.
50 Outra caracterstica interessante do processo de alocao dinmica que

no podemos afirmar que os elementos armazenados na lista ocuparo um espao
de memria contguo, isto quer dizer um ao lado do outro. Logo, no h possibilidade
de acesso direto aos elementos da lista. Para que seja possvel percorrer todos
os elementos da lista, devemos explicitamente armazenar o encadeamento dos
elementos. Desta forma, armazena-se a informao de cada elemento juntamente
com um ponteiro para o prximo elemento da lista.
A figura a seguir ilustra o arranjo da memria de uma lista encadeada.

FIGURA 3 REPRESENTAO DO ARRANJO DA MEMRIA DE UMA LISTA ENCADEADA
FONTE: O autor
A estrutura consiste numa sequncia encadeada de elementos, comumente

denominada de ns da lista. A lista representada por um ponteiro para o primeiro
elemento (ou n), a partir do qual se pode ascender ao segundo, seguindo o
encadeamento, e assim por diante. O ltimo elemento da lista aponta para NULL,
indicando que no h mais elementos na lista.
Para exemplificar a implementao de listas encadeadas em Java, vamos

considerar um exemplo simples em que queremos armazenar o nome e o peso
de uma pessoa numa lista encadeada. O n da lista pode ser representado pela
estrutura a seguir:
FIGURA 4 ESTRUTURA EM JAVA REPRESENTANDO O N DA LISTA ENCADEADA 51
FONTE: O autor
A classe PessoaLista trata-se de uma estrutura autorreferenciada, pois, alm

dos campos que armazenam as informaes (nome e peso), h o atributo (prox)
que um ponteiro para uma prxima estrutura do mesmo tipo. Normalmente, o
acadmico fica confuso em relao a isso, como se esse cdigo fosse gerar um lao
infinito, ou uma recurso infinita. No entanto, no o caso, j que a declarao do
atributo prox apenas uma referncia, que no cria uma instncia de PessoaLista
na memria, apenas criando uma referncia referida classe j instanciada!
FIGURA 5 - REPRESENTAO DA LISTA DE PESSOAS
FONTE: O autor
Importante destacar que, embora a figura acima represente as pessoas

uma ao lado da outra, na memria, provavelmente elas estejam em regies bem
distintas, contudo, cada uma delas sabe dizer em que local se encontra a prxima
pessoa, j que h a referncia ao prximo pelo atributo prox.
O cdigo-fonte exibido acima no a melhor forma de implementar uma

lista, tendo em vista que h uma confuso de responsabilidades, onde a classe
PessoaLista, alm de armazenar informaes sobre uma pessoa, armazena tambm
uma lista de pessoas. Logo, manipul-la pode ficar estranho e muito trabalhoso, j
52 que h a necessidade de manter constantemente uma referncia para a primeira
pessoa na memria em algum outro lugar, o que tambm pode ser confuso, alm
de violar o conceito de coeso.
Ademais, sendo necessrio criar uma lista encadeada de produtos, por

exemplo, ao invs de reaproveitar o cdigo existente, prtica comum na programao
orientada a objetos, ser necessrio criar uma nova classe, denominada
ProdutoLista, semelhante com a PessoaLista. Neste sentido, para criar uma estrutura
mais funcional, utiliza-se uma classe separada como ns, evitando mesclar a
classe de dados (Pessoa) da nossa estrutura.
1.6 PILHAS
A estrutura de dados denominada pilha admite a remoo e insero de

novos elementos de forma dinmica na memria, sujeitando-se seguinte regra
de operao: o elemento a ser removido ser sempre o que est na estrutura h
menos tempo.
A pilha uma verso limitada de uma lista encadeada novos
nodos podem ser adicionados a uma pilha e removidos de uma
pilha apenas na parte superior (topo). Por essa razo, a pilha
conhecida como uma estrutura de dados ltimo a entrar, primeiro
a sair (last-in, first-out - LIFO). O membro de link do nodo inferior
(isto , o ltimo) da pilha configurado como nulo para indicar
a base da pilha (DEITEL; DEITEL, 2003, p. 56).
Neste sentido, as pilhas tm muitas aplicaes interessantes, principalmente

na anlise de expresses e sintaxe, como no caso das calculadoras que utilizam a
Notao Polonesa Reversa, que implementam a estrutura de dados de pilha para
expressar seus valores, podendo ser representadas de forma prefixa, ps-fixa ou
infixa, ou ainda, os compiladores de muitas linguagens de programao ao realizar
a anlise sinttica de expresses e blocos de programas.
Existem duas funes que se aplicam a todas as pilhas: PUSH, que insere
um dado no topo da pilha, e POP, que remove o item no topo da pilha, conforme
exemplo que segue abaixo.
FIGURA 6 REPRESENTAO GRFICA DE UMA PILHA 53
FONTE: O autor

1.7 FILAS
No dia a dia, estamos acostumados com as filas em diversos lugares:

nos bancos, nos mercados, nos hospitais, nos cinemas, entre outros. As filas
so importantes, pois elas determinam a ordem de atendimento das pessoas.
As pessoas so atendidas conforme a posio delas na fila. O prximo

a ser atendido o primeiro da fila. Quando o primeiro da fila chamado para
ser atendido a fila anda, ou seja, o segundo passa a ser o primeiro, o terceiro
passa a ser o segundo e assim por diante at a ltima pessoa.
Normalmente, para entrar em uma fila, uma pessoa deve se colocar na

ltima posio, ou seja, no fim da fila. Desta forma, quem chega primeiro tem
prioridade. Assim como Listas e Pilhas, as Filas so estruturas de dados que
armazenam os elementos de maneira sequencial.
As estruturas de dados denominadas Filas so estruturas do tipo FIFO

54 (first-in, first-out), ou seja, o primeiro elemento a ser inserido ser o primeiro a
ser retirado, assim sendo, adiciona-se itens no fim e remove-se do incio.
FONTE: Caelum (2014, p. 2)
A fila semelhante a uma fila de caixa em um supermercado a

primeira pessoa na fila atendida primeiro e os outros clientes
entram na fila apenas no final e esperam ser atendidos. Os
nodos da fila so removidos apenas do incio (ou cabea) da
fila e so inseridos somente no final (ou cauda) da fila (DEITEL;
DEITEL, 2003, p. 72).
Segundo Deitel e Deitel (2003), as filas podem ser usadas em diversas

aplicaes computacionais, haja vista que a maioria dos computadores tem apenas
um nico processador, logo, apenas um aplicativo pode ser atendido por vez. Desta
forma, os pedidos dos outros aplicativos so colocados em uma fila, onde cada
pedido avana gradualmente para o incio da fila medida que os aplicativos vo
sendo atendidos.

So exemplos de uso de fila em um sistema:
Controle de documentos para impresso (spool de impresso).

Troca de mensagem entre computadores numa rede (pacotes de informaes).
Solicitaes de acesso a arquivos em uma rede.
1.8 ANLISE E TCNICAS DE ALGORITMOS
1.8.1 Diviso e Conquista
A tcnica de diviso e conquista consiste em trs passos bsicos, quais

sejam:
1. Diviso: Dividir o problema original em subproblemas menores.

2. Conquista: Resolver cada subproblema recursivamente.
3. Combinao: Combinar as solues encontradas, compondo uma soluo nica
55
para o problema original.
Para que a estratgica de diviso e conquista possa ser utilizada com

sucesso deve ser possvel decompor uma instncia em subinstncias; a combinao
dos resultados deve ser eficiente e as subinstncias devem ser mais ou menos do
mesmo tamanho.
A utilizao da referida tcnica adequada em problemas que apresentam

um grupo de operaes que so correlacionadas ou repetidas, como, por exemplo,
na multiplicao de matrizes ou, ainda, problemas em que uma deciso deve ser
tomada e, uma vez tomada, quebra o problema em peas disjuntas. Em especial, a
abordagem por diviso e conquista interessante quando algumas partes passam
a ser irrelevantes (TOFFOLO, 2012).

Algoritmo Genrico
1 DivisaoeConquista(x)
2 SE x pequeno ou simples ENTO
3 Resolver (x)
4 SENO
5 Decompor x em conjuntos menores x0; x1 ... xn
6 PARA i := 0 at n FAA
7 y1 := DivisaoeConquista(x1)
8 i := 1+i
9 Combinar yis
0 Imprime (y)
Exemplo: O problema consiste em localizar o maior elemento de um vetor

A [1..n]
Soluo Simples Soluo com Diviso e Conquista
56
Max (A [1..n]) Max (A [x..y])
Maior := A [1] Se x y >= 1 ento
Para i := 2 at n faa Imprime max (A[x], A[y])
Se A [j] > maior ento Seno
Maior := A[i] m := x+y / 2
Imprime (maior) v1 := Max (A [x..m])
v2 := Max (A [m + 1 .. y]
Imprime Max (v1, v2)
Dentre os algoritmos que adotam o paradigma da diviso e conquista, temos

a Busca Binria, o Algoritmo da Mediana, o Algoritmo de Karatsuba e Ofman, o
Mergesort e o Quicksort, sendo estes dois ltimos os mais conhecidos e utilizados.
QuickSort: O algoritmo, publicado pelo professor C.A.R. Hoare

em 1962, baseia-se na ideia simples de partir um vetor (ou lista
a ser ordenada) em dois subvetores, de tal maneira que todos
os elementos do primeiro vetor sejam menores ou iguais a
todos os elementos do segundo vetor. Estabelecida a diviso,
o problema estar resolvido, pois aplicando recursivamente

a mesma tcnica a cada um dos subvetores, o vetor estar
ordenado ao se obter um subvetor de apenas um elemento
(LAUREANO, 2008, p. 111).
MergeSort: um algoritmo de ordenao por intercalao.

Cria uma sequncia ordenada a partir de duas outras tambm
ordenadas. Para isso, o algoritmo divide a sequncia original em
pares de dados, ordena-as; depois as agrupa em sequncias de
quatro elementos, e assim por diante, at ter toda a sequncia
dividida em apenas duas partes (LAUREANO, 2008, p. 112).
1.8.2 Mtodo Guloso
Consiste em iniciar uma busca local a partir de vrias solues geradas

aleatoriamente, com a expectativa de que haja um caminho de melhoria de custo
partindo de uma dessas solues at uma soluo tima ou prxima do timo
(CUNHA; TAKAHASHI; ANTUNES, 2012).
Os algoritmos gulosos so aqueles que, a cada deciso, sempre escolhem

57
a alternativa que parece mais promissora naquele momento, sendo que aps a
deciso tomada no a reconsidera, sendo que para realizar a escolha que parece ser
a melhor a cada iterao, a escolha realizada de acordo com um critrio guloso,
ou ainda, soluo tima.
A construo da melhor soluo pressupe a existncia de um conjunto

ou lista de candidatos, dos quais so acumulados um conjunto de candidatos
considerados e escolhidos, e o outro de candidatos considerados e rejeitados.
Posteriormente h uma funo que verifica se um conjunto particular de candidatos
produz uma soluo (sem considerar otimalidade no momento).
Outra funo verifica se um conjunto de candidatos vivel, tambm sem

se preocupar com a otimalidade, uma funo de seleo indica a qualquer momento
quais dos candidatos restantes o mais promissor e, por fim, uma funo objetiva
fornecer o valor da soluo encontrada.

A funo de seleo geralmente relacionada com a funo objetivo, sendo
que, se o objetivo maximizar, provavelmente escolher o candidato restante que
proporcione o maior ganho individual; se for minimizar, ento ser escolhido o
candidato restante de menor custo.
Normalmente, algoritmos gulosos so utilizados para resolver problemas

de otimizao que funcionem atravs de uma sequncia de passos, como, por
exemplo, o problema da mochila fracionria (ROMAN, 2013).
O problema da mochila fracionria pode ser resolvido por um algoritmo

guloso muito eficiente, conforme segue abaixo:
Dados os vetores (x1,x2,,xn) e (p1,p2,,pn), denotaremos por x p o

produto escalar de x por p. Portanto, x p = x1p1 + x2p2 + + xnpn . Diremos que
um vetor (x1,x2,,xn) racional se todos os seus componentes forem nmeros
racionais e natural se todos os seus componentes forem nmeros naturais.
Dados os vetores naturais (p1, p2, , pn), (v1, v2, , vn) e um nmero
58
natural c encontrar um vetor racional (x1, x2, , xn) que maximize x v sob as
restries x p c e 0 xi 1 para todo i. Diremos que (p1,,pn) o vetor de
pesos, que (v1,,vn) o vetor de valores e que c a capacidade do problema.
Diremos que uma mochila fracionria vivel qualquer vetor racional (x1,,xn) tal
que x p c e 0 xi 1 para todo i. O valor de uma mochila x o nmero x v.
Nosso problema encontrar uma mochila vivel de valor mximo.
Motivao: Imagine que tenho n objetos que eu gostaria de colocar em uma

mochila de capacidade c. Cada objeto i tem peso pi e valor vi. Posso escolher uma
frao (entre 0% e 100%) de cada objeto para colocar na mochila. Quero fazer isso
de modo a respeitar a capacidade da mochila e maximizar o seu valor.
Exemplo: Suponha c = 50 e n = 4. A figura abaixo d os valores de p e v.

Mais abaixo, temos uma soluo x do problema da mochila fracionria. O valor
dessa soluo x v = 1040.

p 40 30 20 10 20
v 840 600 400 100 300
x 1 1/3 0 0 0
O seguinte algoritmo guloso resolve o problema da mochila fracionria. O

algoritmo exige que os dados estejam em ordem crescente de valor especfico (ou
seja, valor por unidade de peso): v1/p1 v2/p2 vn/pn (se pi=0 ento vi/pi
infinito). nesta ordem mgica que est o segredo do funcionamento do algoritmo.
Mochila-Fracionria (p, v, n, c)
1 jn
2 enquanto j 1 e pj c faa
3 xj 1
4 c c pj
5 jj1
6 se j 1 ento
7 xj c/pj
8 para i j1 decrescendo at 1 faa 59
9 xi 0
0 devolva
Eis uma organizao mais compacta do cdigo:
Mochila-Fracionria (p, v, n, c)
1 para j n decrescendo at 1 faa
2 se pj c ento xj 1
3 c c pj
4 seno xj c/pj
5 c0
6 devolva x

O algoritmo guloso porque, em cada iterao, abocanha o objeto de
maior valor especfico dentre os disponveis, sem se preocupar com o que vai
acontecer depois. O algoritmo jamais se arrepende do valor atribudo a um
componente de x.
Por que o algoritmo d a resposta correta? evidente que o algoritmo

produz uma mochila fracionria vivel; o difcil provar que ela tem valor mximo.
A prova se apoia no seguinte par de propriedades:
1 Se vn/pn vi/pi para todo i, ento existe uma mochila vivel de valor mximo
(x1,,xn) tal que xn = min(1, c/pn).
2 Se (x1,,xn) uma mochila vivel de valor mximo para a instncia dada

do problema, ento (x1,,xn1) uma mochila vivel de valor mximo para
a instncia definida pelos parmetros n1 e c xnpn.
FONTE: Norton T. Roman (2013)
60
1.8.3 Programao Dinmica
A Programao Dinmica (PD) pode ser caracterizada como um

processo sequencial de tomada de decises, onde uma deciso tima global
pode ser obtida atravs da otimizao de subproblemas (ou timos locais)
individuais, seguindo o princpio de otimalidade de Bellman (DIAS et al., 2010).
Na Programao Dinmica resolvem-se os problemas de pequena dimenso e
guardam-se as solues em tabelas dinmicas, a fim de evitar redundncia de
clculo, ou seja, uma soluo parcial obtida somente calculada uma nica vez.
Este procedimento importante porque, diferentemente da tcnica de diviso
e conquista, aqui cada subproblema dependente de pelo menos um outro. A
soluo final obtida combinando as solues dos problemas menores (ROSA,
2011). Pode-se dizer que a Programao Dinmica uma maneira esperta de
transformar recurso em iterao, da ser chamada de Otimizao Recursiva.

Aplica-se quando uma estratgia tima para resolver um problema continua a
ser tima quando este subproblema de um problema maior, ou seja, somente
solues timas dos subproblemas podem compor uma soluo tima do
problema original (RIBEIRO, 1999).
FONTE: Disponvel em: <http://www.flf.edu.br/revista-flf.edu/volume08/Vol8_Artigo1.pdf>. Acesso em:

30 maio 2016.
61

-------------- [ TPICO 4 - BANCO DE DADOS RELACIONAL ] --------------

conceitos relacionados ao tema de Banco de dados relacional. Os mesmos sero
apresentados de forma sintetizada, porm no menos elucidativa, visando oferecer
ao acadmico um contedo importante para sua vida acadmica e profissional.
O desenvolvimento deste captulo ser feito em forma de tpicos e

relambraremos os seguintes itens: Introduo ao banco de dados relacional,
conceitos do modelo entidade-relacionamento, cardinalidade de relacionamentos,
graus de relacionamentos, tipos de entidade, padro SQL para banco de dados
relacional, selecionando dados: DQL - data query language, funes em SQL e
combinao de consultas.
Vamos ento iniciar os estudos, empregando o mximo de ateno e foco

para que os resultados sejam os melhores possveis, contribuindo para o incremento
e fixao dos seus conhecimentos!
63
Prof. Neli Miglioli Sabadin
1 INTRODUO AO BANCO DE DADOS RELACIONAL
Um banco de dados relacional um banco de dados percebido por

seus usurios como uma coleo de variveis de relaes, ou, falando de uma
maneira mais informal, tabelas, que so formadas por linhas e colunas. Rezende
(2006) afirma que um banco de dados uma coleo de dados inter-relacionados,
representando informaes sobre um domnio especfico, ou seja, sempre que for
possvel agrupar informaes que se relacionam e tratam de um mesmo assunto,
temos ento um banco de dados.
Da mesma forma que na matemtica podem ser efetuadas operaes entre

dois ou mais conjuntos, em outras palavras, o modelo relacional representa uma
tentativa de descrever um banco de dados atravs de conceitos matemticos simples
e conhecidos (lgebra relacional). A lgebra relacional contm oito operadores,

agrupadas em dois grupos. O grupo de operadores tradicionais (Unio, Interseo,
Diferena e Produto Cartesiano) e os relacionais especiais de restrio (Restrio,
Projeo, Juno e Diviso).
Para maiores informaes, veja DATE, C. J. captulo 6 ou no

site <https://pt.scribd.com/doc/280907670/10-Capitulo-
6-A-Algebra-Relacional>
Um banco de dados deve proporcionar uma viso abstrata para o usurio.

Uma preocupao que o usurio no deve ter qual unidade de armazenamento
foi utilizada para guardar seus dados, contanto que os mesmos estejam disponveis
no momento em que ele precisar.
Modelo conceitual: o primeiro nvel de abstrao, onde se ir descrever

quais informaes devem ser armazenadas no banco de dados. Durante essa
64 fase so apresentadas as relaes, sem se preocupar em descrever como elas
efetivamente sero armazenadas. A abordagem Entidade-Relacionamento (ER)
a tcnica mais utilizada para essa documentao.
No prximo tpico detalharemos um pouco mais.
FIGURA 1 - EXEMPLO DE MODELO CONCEITUAL
FONTE: Disponvel em: <http://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-

dados/1649>. Acesso em: 27 mar. 2016.

Modelo lgico: Esta fase mais prxima do especialista em BD, neste
momento j se deve saber do Sistema de Gerenciamento de Banco de Dados
(SGBD) que ser utilizado. E a documentao feita de forma mais descritiva, com
o nome e a definio das colunas que formam sua estrutura.
Forma de representao do modelo lgico:

Aluno (Nro_mat_aluno, nom_aluno, end_aluno)
Turma (cod_turma, nro_sala, perodo_aula).
Modelo fsico: Nesta fase o modelo j est diretamente ligado escolha

do SGBD, que foi escolhido pelo profissional responsvel. J se encontra o
detalhamento fsico das estruturas dos dados, como o tipo dos dados, tamanhos
dos campos que sero armazenados no banco de dados.
Exemplo: CREATE TABLE ALUNO

(NRO_MAT_ALUNO NUMBER(5) PRIMARY KEY,
NOM_ALUNO VARCHAR2(50),
END_ALUNO VARCHAR2(50));
65

FIGURA 2 - MODELO DE DADOS CONCEITUAL DE ALTO NVEL E PROJETO DE BASE DADOS
66
FONTE: Takai et al. (2005, p. 22)

2 CONCEITOS DO MODELO ENTIDADE-RELACIONAMENTO
O objeto bsico que o MER representa a Entidade. Uma entidade algo

do mundo real que possui uma existncia independente, pode ser um objeto com
uma existncia fsica, como uma pessoa, ou pode ser um objeto com existncia
conceitual, como um curso universitrio.
Cada entidade tem propriedades particulares, chamadas Atributos, que a

descrevem. Por exemplo, uma entidade pessoa pode ser descrita pelo seu nome,
a sua data de nascimento, endereo e filiao. Uma entidade em particular ter um
valor para cada um de seus atributos. Em alguns casos, alguns atributos podem ser
divididos em subpartes com significados independentes, chamados de atributos
compostos (TAKAI et al., 2005, p. 24).
As chaves, em relao ao modelo lgico, correspondem aos atributos

identificadores. Eles permitem dar uma identificao a cada ocorrncia de instncia
em uma tabela, e garantir que elas sejam nicas. H outras funcionalidades, sendo
que, alm de ter a funo de identificar uma linha de uma tabela, elas ajudam a
estabelecer o relacionamento entre as tabelas de um banco de dados relacional. 67
Basicamente existem trs tipos de chaves em um banco de dados relacional: CHAVE
PRIMRIA, CHAVE ESTRANGEIRA e CHAVE NICA.
A chave primria ou primary key (PK) uma coluna ou conjunto de

colunas que identificam unicamente (ou seja, no se repete) um registro dentro de
uma tabela, ela pode ser simples ou composta. Os campos que pertencem chave
primria so obrigatrios, no admitindo valor vazio ou NULL.
A chave estrangeira ou foreign key (FK) uma coluna ou conjunto de

colunas que se referem necessariamente a uma chave primria de outra tabela ou
dela mesma no caso de recursividade, estabelecendo um relacionamento entre as
tabelas. Este relacionamento garante a integridade dos dados relacionados, pois
apenas sero permitidos valores que atendam ao relacionamento.
Chave nica ou chave alternativa - em alguns casos, mais de uma coluna

ou grupo de colunas da tabela servem para identificar unicamente um registro. Neste
caso, uma das chaves criada como chave primria e a outra como alternativa
(tambm conhecida como Chave nica UK).
3 CARDINALIDADE DE RELACIONAMENTOS
o nmero mximo e mnimo de ocorrncias de uma entidade que esto

associadas s ocorrncias de outra entidade que participa do relacionamento.
Ou seja, a cardinalidade importante para ajudar a definir o relacionamento,
pois ela define o nmero de ocorrncias em um relacionamento.
UM-PARA-UM (1 : 1): uma entidade A (nesse caso, paciente) est associada

no mximo a uma entidade em B (pronturio) e uma entidade em B est
associada no mximo a uma entidade em A. Nesse exemplo, um paciente
s pode ter um pronturio e um pronturio s pode pertencer a um paciente.
FIGURA 3 - RELACIONAMENTO 1:1
FONTE: Disponvel em: <http://cae.ucb.br/conteudo/programar/banco2/banco2_mer.html>>. Acesso

em: 4 abr. 2016.
68
MUITOS-PARA-UM (N : 1): uma entidade em A (nesse caso, venda) est

associada no mximo a uma entidade em B (cliente), enquanto uma entidade
em B est associada a qualquer nmero de entidades em B. Nesse exemplo,
uma venda s pode ser realizada para um nico cliente, mas um cliente pode
participar de vrias vendas.
MUITOS-PARA-MUITOS: Uma entidade em A est associada a qualquer nmero

de entidades em B, e uma entidade em B est associada a qualquer nmero de
entidades em A.
FIGURA 4 - RELACIONAMENTO M:M

FIGURA 5 - RELACIONAMENTO M: 1
FONTE: Disponvel em: <http://cae.ucb.br/conteudo/programar/banco2/banco2_mer.html>. Acesso em:

4 abr. 2016.
4 GRAUS DE RELACIONAMENTOS
Pode ser classificado como BINRIO (associao entre duas entidades),

como apresentado na Figura 7, ou TERNRIO (associao entre duas ou mais
entidades).
FIGURA 6 - RELACIONAMENTO TERNRIO

69

4 abr. 2016.

AGREGAO: Uma limitao do modelo E-R que no possvel
expressar relacionamentos entre relacionamentos. Agregao uma abstrao
atravs da qual relacionamentos so tratados como entidades de nvel superior.
GENERALIZAO E ESPECIALIZAO: Existem casos em que um

conjunto-entidade pode ser dividido em categorias, cada qual com atributos
especficos.
FIGURA 7 - AGREGAO
70
FIGURA 8 ESPECIALIZAO OU GENERALIZAO

4 abr. 2016.

AUTORRELACIONAMENTO: Este tipo de relacionamento ocorre toda
vez que temos uma ocorrncia de uma entidade que est associada a uma ou
mais ocorrncias da mesma entidade. Ou seja, temos uma entidade onde suas
ocorrncias possuem relacionamentos entre si.
Os autorrelacionamentos so, na verdade, uma forma de representarmos

relaes de hierarquia entre ocorrncias de uma mesma entidade.
Por exemplo, vamos considerar uma entidade EMPREGADO,

sendo que no modelo conceitual devemos representar o conceito de que um
empregado possui um gerente. Ou seja, existe um relacionamento entre as
ocorrncias da entidade EMPREGADO que estabelece que um empregado
gerente de outro empregado.
FIGURA 9 - AUTORRELACIONAMENTO
71

4 abr. 2016.
5 TIPOS DE ENTIDADES
Um modelo de dados contm diferentes tipos de entidades que so

diferenciadas pelo formato dos identificadores. A classificao de cada
uma dessas entidades pelo tipo ajudar voc a definir quais perguntas
devem ser feitas.

ENTIDADE TIPO: Representa um conceito independente em um
modelo de dados e est em primeiro lugar na mente do cliente. As entidades
tipo so independentes e, com frequncia, constituem o ponto de partida
de um modelo de dados. As entidades tipo muitas vezes esto conectadas
a outras entidades tipo por meio de um relacionamento 1:m ou m:m. Para
exemplificar, podemos considerar um sistema acadmico onde as entidades
aluno e curso so entidades tipo, pois a entidade aluno, se no existisse
a entidade curso, poderia existir da mesma forma.
ENTIDADE FRACA OU DEPENDENTE: Uma entidade fraca (ou

dependente) precisa de outra entidade para garantir a sua existncia. A
entidade fraca depende de uma entidade TIPO e esta relao de dependncia
uma relao obrigatria. O identificador de uma entidade fraca possui em
sua composio o(s) atributo(s) identificador(es) da entidade TIPO qual a
entidade fraca est associada. Como exemplo, podemos considerar um sistema
de gesto de recursos humanos onde a entidade dependente uma entidade
fraca em relao entidade funcionrio. Pois se a entidade Funcionrios no
72 existisse, a entidade dependente consequentemente no existiria.
ENTIDADE ASSOCIATIVA: As entidades associativas so o

resultado de relacionamentos m:m. Em geral, as entidades associativas
so encontradas entre entidades tipo. Muitas das vezes, as entidades
associativas tm nomes bvios, pois ocorrem no mundo real. Por exemplo,
a entidade associativa do relacionamento disciplinas e alunos, objetivando
o lanamento de notas, chama-se avaliao. Deve-se sempre procurar pelo
nome adequado, pois esse ir aumentar a clareza do modelo de dados.
ENTIDADE AGREGADA: Cria-se uma entidade agregada quando

temos um conjunto de atributos que aparecem em mais de uma entidade do
modelo de dados. Ou seja, quando vrias entidades distintas tm atributos
em comum. Nestes casos devemos criar uma entidade agregada contendo
os atributos que se repetem em mais de uma entidade. Por exemplo,
como os atributos de um endereo podem ocorrer em entidades diferentes
(CLIENTES E FORNECEDORES, por exemplo), pode-se criar uma entidade
agregada ENDEREOS para armazenar detalhes de todos os endereos.

ENTIDADE SUBORDINADA: Uma entidade representa uma
especializao de entidade no modelo de dados onde uma entidade
supertipo possui vrias entidades subordinadas que so especializadas
com atributos especficos. Devemos usar entidades subordinadas toda vez
que tivermos entidades que compartilham conceitos semelhantes, mas
que possuem caractersticas prprias. Por exemplo, podemos ter uma
entidade supertipo CLIENTE contendo os atributos codigo, nome, endereco
e telefone e duas entidades subordinadas PESSOA FISICA e PESSOA
JURIDICA contendo atributos especficos respectivamente nro_cpf e
nro_cnpj. Tanto PESSOA FISICA como PESSOA JURIDICA compartilham
conceitos semelhantes, ambas possuem um nome e endereco, mas
possuem tambm caractersticas prprias, pois PESSOA FISICA possui
nro_cpf e PESSOA JURIDICA possui nro_cnpj.
FONTE: Disponvel de: <https://sites.google.com/site/uniplibancodedados1/aulas/aula-8---tipos-de-

entidade>. Acesso em: 4 abr. 2016.
73
6 PADRO SQL PARA BANCO DE DADOS RELACIONAL

difcil desvincular a histria da linguagem SQL (Structured Query
Language) da histria do banco de dados relacional. Atravs dos comandos SQL os
usurios podem montar consultas poderosas, sem a necessidade da criao de um
programa, podendo utilizar ferramentas front-end para a montagem de relatrios. A
linguagem SQL adotada por praticamente todos os SGBDs relacionais existentes
no mercado, alm de ser uma linguagem padronizada (ANSI). uma linguagem
utilizada para banco de dados relacionais, baseada e inspirada em lgebra relacional.
Utiliza como subconjuntos principais o DML, DDL, DCL, DTL e DQL.
DML - Data Manipulation Language (Linguagem de Manipulao de Dados):

utilizado para realizar incluses, consultas, excluses e alteraes de dados.
Utiliza os comandos INSERT, SELECT, UPDATE e DELETE.
DDL - Data Definition Language (Linguagem de Definio de Dados): Permite

definir tabelas e elementos associados. Utiliza como comandos principais o CREATE
e o DROP, alguns sistemas de banco de dados utilizam o ALTER.
Ex.: CREATE TABLE nome_tabela (nome_campo tipo_do campo).
DCL - Data Control Language (Linguagem de Controle de Dados): Controla

os aspectos de autorizao de dados e a utilizao de licenas por usurios. Os
principais comandos so GRANT e REVOKE.
DTL - Data Transaction Language (Linguagem de Transao de Dados):

Utilizado pelos desenvolvedores em transaes. Os principais comandos so
COMMIT e ROLLBACK.
DQL - Data Query Language (Linguagem de Consulta de Dados): O mais

importante dentre estes, pois consultas so realizadas a todo instante. O comando
que utilizado pelo DQL o SELECT. Em algumas literaturas, o SELECT tambm
aparece como um comando.
Na linguagem SQL so empregados os termos tabela, coluna, linha, para

designar, respectivamente, relao, atributo e tupla.
74
7 SELECIONANDO DADOS: DQL - DATA QUERY LANGUAGE
Podemos selecionar colunas especficas de uma tabela, segundo o modelo:

SELECT <lista_de_colunas> FROM <nome_tabela>
Para recuperar todas as colunas de uma tabela substitui-se por *, conforme
apresentado:
SELECT * FROM <nome_tabela>;
Nos modelos de seleo apresentados acima estamos selecionando todos
os registros da tabela. Mas tambm podemos selecionar apenas alguns registros
da tabela, utilizando o comando WHERE:
SELECT <lista_de_colunas> FROM <nome_tabela> WHERE <condio_
de_seleo>;
A clusula WHERE tem a seguinte forma: WHERE <nome_da_coluna>
<operador> <valor> .

Vale ressaltar que o <operador> pode ser substitudo por ( = igual, <> ou
!= diferente, < menor que, > maior que, >= maior ou igual a,<= menor ou igual a),
e temos tambm os operadores Lgicos AND (conjuno) OR (disjuno) NOT
(negao).
Operadores Lgicos: IS NULL

BETWEEN
IN
LIKE
EXISTS
UNIQUE
ALL and ANY
Exemplos:
SELECT * FROM EMPREGADOS
WHERE PAGAMENTO
BETWEEN 100 AND 150;
75
SELECT NOME, PAGAMENTO, EID
FROM EMPREGADOS
WHERE EID IN ('1111', '2222', '3333');
Outra forma de juntar os dados atravs dos comandos: INNER, CROSS,
LEFT, RIGTH E FULL JOINS.
OUTER JOIN ou FULL JOIN: este retorna todos os registros de ambas

as tabelas.
CROSS JOIN: Quando queremos juntar duas ou mais tabelas por

cruzamento. A juno cross join ir juntar todos os registros da tabela marcas
com todos os registros da tabela carros, formando um produto cartesiano.
select m.nome, c.modelo from marcas as m cross join carros as c
INNER JOIN: Quando queremos juntar duas ou mais tabelas por

coincidncia. Esse um formato comum de join, que retorna dados apenas
quando as duas tabelas tm chaves correspondentes na clusula ON do

join. A juno inner join ir juntar os registros da tabela marca que tiver um
correspondente na tabela carros. Essa correspondncia feita pelos campos
marca que esto presentes nas duas tabelas. Embora no esteja explcito, mas
o campo marca seria a chave primria (na tabela marcas) e chave estrangeira
(na tabela carros).
select m.nome, c.modelo from marcas as m inner join carros as c on
c.marca = m.marca
LEFT JOIN: um dos formatos mais usados de join, que retorna a

Tabela A inteira e apenas os registros que coincidirem com a igualdade do join
na Tabela B (ou campos nulos para os campos sem correspondncia). O left
join ir fazer a juno das duas tabelas dando preferncia aos registros da
tabela marcas. Assim, todos os registros da tabela marcas sero mostrados,
independentemente de haver correspondncia na tabela carros. Quando no
houver correspondncia na tabela carros, ser mostrado o valor NULL ou nulo.
select m.nome, c.modelo from marcas as m left join carros as c on
c.marca = m.marca
76
RIGHT JOIN: A juno right join funciona de forma inversa ao left join.
Aplica-se o mesmo conceito, porm, de forma invertida. Com o right join sero
mostrados todos os carros, mesmo aqueles que no estejam associados a
nenhum registro da tabela marcas.
select m.nome, c.modelo from marcas as m right join carros as c on
c.marca = m.marca;
FONTE: Disponvel em: <http://www.devmedia.com.br/explorando-os-tipos-de-join-do-sql/2507>. Acesso

em: 5 abr. 2016.

8 FUNES EM SQL
So funes que permitem agregar valores, ou seja, agregando numa

nica linha o contedo de vrios registros, e retornam um valor baseado na
funo solicitada.
QUADRO 1 - FUNES DE GRUPO
FONTE: Oracle (2004, p. 198) 77
Exemplos:
SELECT AVG (PAGAMENTO) FROM EMPREGADOS;
SELECT COUNT (*) FROM EMPREGADOS;
AGRUPANDO A INFORMAO SELECIONADA (GROUP BY): Existem

ocasies em que desejamos aplicar uma FUNO DE AGREGAO no somente
a um conjunto de tuplas, mas tambm organizar a informao em determinadas
categorias. Isto possvel atravs do uso da clusula GROUP BY. Voc pode usar
o Group by para dividir as linhas de uma tabela em grupos. Lembrando que depois
de usar as funes de grupo para retornar informaes sumariadas de cada grupo.
A Clusula HAVING: s vezes temos que definir condies e aplic-las aos

grupos ao invs de faz-lo a cada linha separadamente. Por exemplo, suponha que
desejemos listar todos os pedidos que possuam mais de um item. Esta condio no
se aplica a uma nica linha separadamente, mas a cada grupo definido pela clusula
GROUP BY. Para exprimir tal consulta, usamos a clusula HAVING. A condio

da clusula HAVING aplicada aps a formao dos grupos; logo, podemos usar
funes de agregao na construo das condies da clusula HAVING.
SELECT column1, column2, ...

FROM table1, table2, ...
[ WHERE column1 = 'value1'
AND column2 = 'value2'
OR (column1 = 'value3'
AND column2 = 'value4')]
[GROUP BY column1, column2, ...]
[HAVING function = 'value']
[ORDER BY column1, column2, ...];
ORDENANDO OS DADOS: SELECT <lista_de_colunas> FROM <nome_

tabela> WHERE <condio_de_seleo> ORDER BY {<nome_coluna>|<num_col>
[ASC|DESC]}
Lembrando que as clusulas ASC e DESC denotam ordenao ascendente

78
e descendente, respectivamente. A forma ascendente de ordenao assumida
caso nenhuma opo seja informada explicitamente.
9 COMBINAO DE CONSULTAS
O SQL disponibiliza trs operadores que permitem, a partir de dois conjuntos,

produzir um terceiro. Estes operadores atuam sobre as colunas das tabelas
de origem, produzindo uma Juno Vertical: UNIO (UNION), INTERSECO
(INTERSECT) e DIFERENA (EXCEPT).
Estes operadores permitem obter um nico conjunto resultado a partir de

dois conjuntos iniciais. So teis na juno de diferentes consultas que se refiram
a tabelas diferentes, mas que tenham colunas com o mesmo tipo de dados. A sua
utilizao observa as seguintes regras:

As duas instrues SELECT tm que selecionar o mesmo nmero de colunas.
As colunas correspondentes tm que ser do mesmo tipo de dados.
As linhas duplicadas so eliminadas pelo operador UNION. Se usarmos UNION
ALL os duplicados no so eliminados, o que poupa uma operao de SORT.
Os nomes de coluna da primeira consulta aparecem no resultado.
A clusula ORDER BY aparece no fim da instruo. Se as colunas correspondentes
dos diferentes SELECTs tiverem nomes diferentes, a referncia (s) coluna(s)
dever ser feita por nmero de posio.
As instrues SELECT so executadas de cima para baixo.
Se forem utilizados vrios operadores de conjunto possvel usar parnteses
para definir prioridades de execuo.
UNION (UNIO): O operador UNION permite obter a reunio de dois

conjuntos. O comando a seguir apresenta os nomes e salrios dos empregados
das tabelas EMP e EMPLOYEES. So duas consultas unidas numa nica.
select ename, sal

from emp
79
UNION
select first_name, salary
from employees;
O comando UNION elimina automaticamente as linhas repetidas. Se

pretendermos que estas apaream, teremos que utilizar UNION ALL:
select job from emp

UNION ALL
select job_id from employees;
INTERSECT (INTERSECO): O operador INTERSECT permite obter a

interseco entre dois conjuntos: O comando a seguir permite listar os salrios que
existem em EMP e em EMPLOYEES:
select sal from emp

INTERSECT
select salary from employees;

MINUS (DIFERENA): O operador MINUS permite obter a diferena entre
dois conjuntos. O comando permite listar os salrios que esto em EMP e no esto
em EMPLOYEES:
select sal from emp

MINUS
select salary from employees;
Veja mais em: <http://aserlorenzo.com/manSQL/Oracle/

toc.htm#DML>
80

----------- [ TPICO 5 - ARQUITETURA E REDES DE COMPUTADORES ] -----------

conceitos relacionados aos temas Arquitetura de Computadores e Redes de
Computadores. Os mesmos sero apresentados de forma sintetizada, porm no
menos elucidativa, visando oferecer ao acadmico um contedo importante para
sua vida acadmica e profissional.
O desenvolvimento deste captulo feito em forma de itens, e vamos

rever nos itens 2 at 4 os Principais Tipos de Arquiteturas Computacionais, os
Componentes Bsicos do Computador e os Tipos de Memrias e Gerenciamento.
J nos itens 5 at 8 sero revistos os Tipos de Redes, as Topologias de Redes, os
Endereos IPv4 e IPv6, e o Sistema DNS.
Iniciaremos os estudos empregando o mximo de ateno e foco para que

os resultados sejam os melhores possveis, contribuindo para o incremento e fixao
dos seus conhecimentos!
81
Prof. Edemilson Bay
1 PRINCIPAIS TIPOS DE ARQUITETURAS COMPUTACIONAIS
Caro(a) acadmico(a), neste item vamos relembrar os principais tipos de

arquiteturas de computadores. A arquitetura computacional proposta pelo engenheiro
John por von Neumann composta pela CPU, memria principal e sistema de E/S
(Entrada/Sada). A CPU possui uma arquitetura interna formada pela UC (Unidade de
Controle), pela ULA (Unidade Lgica-Aritmtica) e pela UE (Unidade de Execuo)
na qual se encontram os registradores. A Figura 1 apresenta os blocos da arquitetura
von Neumann.

FIGURA 1 ARQUITETURA VON NEUMANN
82
FONTE: Paixo (2014, p. 183)

O funcionamento baseado no conceito de programa armazenado, na
execuo sequencial das instrues deste programa e na existncia de apenas um
percurso entre a CPU e a memria. A arquitetura de Von Neumann tem os seguintes
ciclos de mquina para seu funcionamento, que so executados de forma cclica
repetitiva at o final do programa:
Fetch (Busca) neste ciclo de busca da instruo executada a transferncia da

instruo, que se encontra em determinado endereo de memria, para a CPU.
O endereo de memria informado ou apontado pelo registrador PC (Program
Counter), ou contador de programa em portugus.
Decode (Decodificao) neste ciclo feita a decodificao da instruo pela
EU, enviando de forma adequada para ser executada pela ULA.
Execute (Execuo) neste ciclo a instruo efetivamente executada pela ALU
em conjunto com a EU, sendo o gerenciamento feito pela UC.
Os computadores PCs (Personal Computers), que usamos nas residncias e

na maioria das empresas, tm sua arquitetura baseada em Von Neumann. Conforme
Paixo (2014), alguns autores defendem que nas arquiteturas com processadores
83
com mais de um ncleo no se pode dizer que sua arquitetura siga Von Neumann;
por outro lado, tambm existem autores que afirmam serem as mquinas com
processadores com mais de um ncleo baseadas em Von Neumann porque
compartilham um sistema de memria RAM nico.
Outra arquitetura a chamada Harvard, que possui barramentos independentes

para os dados e para as instrues trafegarem entre a memria e a CPU. Essa
arquitetura foi desenvolvida na Universidade de Harvard, nos Estados Unidos.
A principal vantagem dessa arquitetura que a leitura de instrues e de

alguns tipos de dados pode ser feita ao mesmo tempo em que outra instruo esteja
sendo executada, fazendo com que o sistema seja mais rpido. Esse processo
chamado pipeline, ou seja, enquanto uma instruo executada, a prxima instruo
j est sendo lida.
Na arquitetura Harvard existem bem menos instrues disponveis do

que na arquitetura Von Neumann, e para tornar a arquitetura ainda mais veloz,
suas instrues so executadas em somente um nico ciclo de clock (relgio),

diferentemente de Von Neumann, que utiliza trs ou mais ciclos de clock. A
arquitetura Harvard normalmente utilizada em microcontroladores, que so os
processadores utilizados em sistemas embarcados ou sistemas especialistas, como
os existentes em geladeiras, mquinas de lavar, alarmes, sistemas anti-incndio,
elevadores, entre outros.
Para finalizar, vamos rever os conceitos de CISC (Complex Instruction Set

Computer) e RISC (Reduced Instruction Set Computer). Os computadores baseados
em CISC possuem um conjunto de instrues grandes, facilitando a programao
de aplicaes pelos desenvolvedores, e utilizam arquitetura Von Neumann. J os
computadores baseados em RISC possuem um conjunto reduzido de instrues,
tornando a programao de aplicaes no to simples, mas fazendo com que o
desempenho da CPU seja bastante melhorado, tornando o equipamento bem rpido,
e utilizam arquitetura Harvard.
84 2 COMPONENTES FSICOS DO SISTEMA COMPUTACIONAL
Um sistema computacional, ou simplificando, um computador, tem seu

funcionamento viabilizado quando existem hardware e software perfeitamente
instalados e configurados. Quando falamos em arquitetura de computadores,
estamos nos referindo principalmente ao hardware dos mesmos, que constitudo
pelos componentes fsicos internos, pelo prprio gabinete (ou chassis) do
computador e pelos perifricos, que so os componentes ou equipamentos externos
ao computador.
Existe uma diversidade muito grande de perifricos, conforme a aplicao

ou utilizao que o usurio dar ao seu computador. No entanto, uma configurao
de perifricos mnima necessria, como teclado, monitor de vdeo e, para facilitar
a utilizao pelo usurio, um mouse.
No caso da configurao de hardware interna mnima necessrio que

tenhamos uma fonte de alimentao, uma placa-me, um processador, memria
RAM (Random Access Memory), que memria principal do computador juntamente
com a memria ROM (Read Only Memory), portas de I/O (Entrada/Sada), e, por fim,

um acionador de disco rgido, que a memria de massa ou memria secundria
do computador.
Com relao ao hardware externo do computador, como falamos

anteriormente, temos alguns perifricos que so essenciais para utilizao do
mesmo. Por outro lado, muitos perifricos so opcionais e dependero da utilizao
ou aplicao para a qual o usurio designar seu computador. Como exemplos
de perifricos temos impressora, scanner, pen drive, HD externo ou disco rgido
externo, entre outros.
Como falamos anteriormente tambm, em relao ao hardware interno

do computador, necessrio que exista uma configurao mnima, mas existem
diversos componentes internos que podem ser utilizados dependendo da
necessidade e aplicao do usurio. Na Figura 2 so mostrados os principais itens
do hardware interno que compem um computador.
FIGURA 2 HARDWARE INTERNO DO COMPUTADOR
85

Vamos falar sobre alguns componentes, os principais, vistos na figura
anterior. A placa-me, chamada motherboard em ingls, uma placa de circuito
impresso, e de acordo com Cunha e Junior (2012), um dos principais componentes
do computador, haja vista que responsvel por interligar todos os dispositivos
internos e externos de um computador. Nesta placa encontramos o processador,
o chipset, os soquetes para memria, os conectores e slots para I/Os, placas de
expanso e alimentao.
A interconexo entre os diversos dispositivos e placas com a placa-me

feita a partir dos barramentos, que so as vias, ou caminhos, por onde circulam
os sinais eltricos. Para cada tipo de processador, ou famlia de processadores,
projetada uma placa-me especfica, por isso deve-se primeiro definir qual
processador desejamos utilizar, para depois escolher a placa-me adequada.
A memria RAM (Random Access Memory) um tipo de memria que

permite leitura e escrita de forma aleatria, ou seja, o sistema pode ler ou gravar
dados em qualquer posio da memria em qualquer tempo. No necessrio,
por exemplo, ler em sequncia, ou seja, para acessar o contedo da posio cujo
86
endereo 100 no preciso ler as posies anteriores primeiro. Trata-se do
principal sistema de memria do computador, porque, para o processador poder
executar qualquer programa, este deve estar carregado juntamente com os dados
necessrios na RAM, nem que seja de forma temporria. O usurio deve verificar
as especificaes da placa-me e do processador para somente ento optar pela
memria RAM correta, j que existem diversos tipos com capacidades distintas e
tempos de leitura e escrita distintos tambm. Vamos rever outros tipos de memrias
e relembrar um pouco mais da RAM.
Quanto CPU (Central Processing Unit), ou UCP (Unidade Central de

Processamento) em portugus, o componente mais importante do computador,
o seu crebro. Ela possui as funes de processar as instrues e tratar os dados
conforme determinado pelo programa que est sendo executado. A CPU tambm
tem a funo de gerar o endereamento do sistema, sendo responsvel pela
capacidade mxima de armazenamento na memria RAM, e ainda deve controlar
os perifricos existentes.

A CPU tambm pode ser chamada de processador, porm, observamos
que no se deve utilizar o termo CPU para tratar do computador ou gabinete, como
acontece entre usurios menos experientes. Os dois mais conhecidos fabricantes
de CPUs para computadores pessoais so a Intel e a AMD.
A arquitetura externa de uma CPU, normalmente baseada na arquitetura

Von Neumann, mostrada na Figura 3, apresenta barramentos interligando a CPU
com a memria e com os dispositivos de I/O.
FIGURA 3 ARQUITETURA EXTERNA DA CPU
87
Os barramentos so os meios, ou caminhos, pelos quais feita a transferncia

dos sinais eltricos que carregam as informaes entre a CPU, a memria e os
dispositivos de I/O. As informaes que podem trafegar nos barramentos so
classificadas em trs tipos: dados, endereos, ou sinais de controle. Fisicamente,
um barramento composto por vias condutoras de eletricidade, sendo que cada
via transmite um bit. Dessa forma, se um barramento tem 32 vias, poder transmitir
32 bits ao mesmo tempo. Dependendo do tipo de informao a ser conduzida, os
barramentos podem ser:

Unidirecionais neste caso as informaes trafegam em somente um sentido.
o caso das informaes de endereo, que trafegam no sentido da CPU para
a memria, ou para aos dispositivos de I/O.
Bidirecionais neste caso as informaes trafegam em dois sentidos. o caso
das informaes de dados e das informaes de controle, que trafegam entre a
CPU e a memria ou I/O, e entre memria e I/O.
Os barramentos so nomeados conforme o tipo de informao que vo

conduzir, como Barramento de dados (Data Bus), Barramento de endereos
(Address Bus) e Barramento de controle (Control Bus). O barramento de dados
tem a funo de conduzir as instrues e os dados que sero tratados pela CPU,
vindos da memria e/ou de dispositivos de I/O, alm de conduzir tambm os dados
que j foram tratados e precisam ser enviados para algum lugar, como memrias
ou dispositivos de I/O. A quantidade de vias do barramento de dados depende da
CPU, e normalmente uma CPU que trabalha internamente com 32 bits tem um
barramento de dados com 64 bits, enquanto que uma CPU com 64 bits tem um
barramento de dados com 128 bits.
88
O barramento de endereos tem por funo conduzir os endereos gerados
pela CPU para acessar determinadas posies desejadas nas memrias RAM,
no disco rgido, em controladoras de vdeo e placas de rede etc. por meio deste
barramento que o processador informa os endereos nos quais esto armazenados
os dados e instrues que deseja utilizar para um determinado processamento, ou
os endereos nos quais deseja gravar ou enviar determinados dados resultantes
de um processamento. Dessa forma, o barramento de endereos vital para que a
CPU possa efetuar leitura de dados ou instrues em memrias, ou leitura e escrita
de dados em memrias e dispositivos de I/O.
O barramento de endereos composto por diversas vias tambm, e se,

por exemplo, tiver 32 vias, poder informar um endereo de 32 bits que permite uma
quantidade mxima de 4 G (4.294.967.296) endereos distintos. Neste exemplo, o
valor obtido fazendo o clculo de 2 elevado a 32 bits (232).
O barramento de controle muito importante, porque atravs dele que

a CPU recebe e/ou envia os sinais que vo controlar a comunicao e troca de
informao com todos os outros componentes e dispositivos do computador. Existem

algumas vias deste barramento que s enviam sinais e outras s recebem, mas no
todo podemos dizer que o barramento bidirecional. Atravs deste barramento a
CPU informa se o procedimento ser de leitura ou escrita (via R/W) no componente,
se deve ser executado um reset (via RESET), se vai ocorrer uma interrupo (via
INTR ou NMI), se o dispositivo sendo selecionado uma memria ou I/O (via M/IO),
se um dispositivo est ocupado (via BUSY), se um dispositivo deve manter o estado
ou informao atual (via HOLD), se o dispositivo deve parar seu funcionamento (via
HALT), entre outros controles.
Com relao arquitetura interna da CPU, como j visto anteriormente,

podemos dizer que ela composta por trs grandes blocos, que so a UC (Unidade
de Controle), a ULA (Unidade Lgica-Aritmtica) e a UE (Unidade de Execuo),
nas quais se encontram os registradores.
A Unidade de Controle (UC) tem como responsabilidade gerenciar e

controlar a sincronia das transferncias de dados e instrues dos programas que
so tratados pela CPU. Pode ser dividida em trs partes, que so: o registrador
de instrues, que armazena a instruo a ser executada; o decodificador, cuja
89
funo decodificar a instruo recebida, e passar para a unidade de controle
propriamente dita, que vai gerar os sinais eltricos de controle internos e externos.
A Unidade Lgica-Aritmtica (ULA), segundo Cunha e Junior (2012), um

aglomerado de circuitos lgicos eletrnicos simples que esto integrados e conseguem
efetivamente realizar as seguintes operaes aritmticas com os dados binrios:
Adio, subtrao, multiplicao e diviso.

Complemento 2, incremento e decremento.
Operaes lgicas AND, OR e Exclusive OR.
Rotaes de bits esquerda e direita (importantes para processamento rpido
de informaes).
A Unidade de Execuo (EU) contm os registradores internos, e estes so

pequenas memrias temporrias, com capacidades que variam de 8 a 256 bits.
Quando dito que um processador tem tecnologia de 64 bits, por exemplo, isso
quer dizer que os registradores internos conseguem trabalhar com palavras de at
64 bits. Uma CPU possui vrios registradores internamente, sendo que alguns so

usados para armazenar dados de uso geral, e outros so usados para armazenar
dados especficos para o funcionamento da CPU. No falaremos especificamente
sobre cada registrador.
3 TIPOS DE MEMRIAS E GERENCIAMENTO
As memrias tm a funo de guardar informaes, de forma definitiva

ou temporria, e podem ser construdas com diversos materiais distintos. Num
computador podem existir vrios tipos de memrias, o quadro a seguir apresenta
alguns deles.
QUADRO 1 TIPOS DE MEMRIAS
90
Os tipos de memrias apresentados no quadro acima podem ser separados

em blocos de acordo com o meio de armazenamento: ptico (CD e DVD), magntico
(Disco Rgido) e estado slido (DRAM, SRAM, Flash).
As memrias de estado slido, tambm chamadas de memrias de

semicondutores porque so feitas de um material como o silcio (Si), so as usadas
na memria principal do computador (RAM), e tambm na memria Cache, CMOS
e BIOS. Elas podem ser classificadas em volteis (perdem a informao caso exista
interrupo da energia eltrica), e no volteis (no perdem a informao, mesmo
que a energia eltrica seja interrompida).

As memrias no volteis so representadas pelas memrias ROM e suas
derivaes, enquanto que as memrias volteis so representadas pela memria
RAM, tipo esttica ou dinmica, sendo que esta ltima precisa que seus dados sejam
reescritos periodicamente por um circuito externo chamado refresh. Na Figura 4 so
apresentadas as memrias semicondutoras no volteis e volteis.
FIGURA 4 MEMRIAS SEMICONDUTORAS
91
A memria RAM esttica, ou SRAM (Static RAM), possui alta performance

e baixa capacidade de armazenamento, por isso utilizada como memria cache
junto aos discos rgidos ou em sistemas de caches L1, L2 e L3, que so sistemas
normalmente integrados ao processador para ajudar na melhoria da sua performance.
J a memria RAM dinmica, ou DRAM (Dynamic RAM), possui alta

capacidade de armazenamento e por isso utilizada principalmente como memria
principal do computador, sendo conectada placa-me atravs de pentes de
memria encaixados nos slots especficos. No entanto, as DRAM tambm so
encontradas em outros dispositivos, como nas modernas placas de vdeo grficas.
Como o volume de dados e instrues envolvidos na execuo de

programas muito grande, geralmente necessrio que exista uma organizao
da memria principal do computador, que utilizada para que efetivamente ocorra
o processamento. Assim, deve existir um gerenciamento da memria e controle de
acesso mesma, e isso executado pelo sistema operacional.
Segundo Junior e Gross (2013), o gerenciamento de memria crtico para
o sistema e, como as instrues a serem executadas devem estar na memria
principal, torna-se necessrio que o sistema operacional mantenha na memria
o maior nmero possvel de processos (tarefas em execuo), evitando queda de
desempenho do sistema computacional. Assim, vamos ver a seguir algumas formas
de alocao de memria.
A alocao simples, tambm chamada alocao contgua de nico usurio,

funciona dividindo a memria, ficando uma parte reservada para o programa ou
aplicativo do usurio e ficando outra parte da memria reservada para o sistema
operacional. O endereo limite entre as duas partes da memria informado por
um registrador. O programa no pode ser maior que o espao destinado ao mesmo,
e caso o programa seja menor, tambm no pode esse espao vazio ser utilizado.
Somente um programa pode ser executado pela CPU.
A alocao esttica, tambm chamada alocao particionada fixa, foi

viabilizada, conforme Junior e Gross (2013), quando as memrias passaram a ter maior
capacidade, permitindo dividir a mesma em parties. Dessa forma, diversas tarefas
92
(programas) podem ser alocadas na memria em parties nas quais caibam, podendo
ser executadas pela CPU quando exigidas. No entanto, existem dois problemas nessa
soluo: o primeiro que as parties so declaradas na inicializao do sistema,
dificultando alteraes, e o segundo que um programa somente pode executar na
sua partio, pois o endereo alocado definido na hora de sua compilao. Mesmo
com vrias parties de tamanhos distintos, os programas devem ser armazenados
inteiros na memria e de forma contnua, l ficando at o fim da sua execuo.
A alocao particionada dinmica, de acordo com Junior e Gross (2013),

permite que as tarefas definam antecipadamente o tamanho de partio que
precisam, sendo alocadas parties conforme a necessidade de cada programa,
reduzindo a fragmentao na hora da alocao. Mas, na hora em que os programas
terminam e so retirados da memria, ficam muitas parties livres entre programas,
o que no aconselhvel. Existem duas solues possveis:
Relocao de parties parties vazias so relocadas eliminando os espaos

entre elas, gerando assim uma grande rea livre que pode ser reparticionada
para novos programas, conforme pode ser visto na Figura 5.

FIGURA 5 RELOCAO DE PARTIES
FONTE: Junior e Gross (2013, p. 45)

93
Juno de parties adjacentes - parties adjacentes vazias so juntadas numa

nica partio, permitindo alocao de novos programas em funo do aumento
do espao disponvel. Na Figura 6 pode-se notar que o programa B terminou de
executar e foi feita a juno.

FIGURA 6 JUNO DE PARTIES ADJACENTES
94 FONTE: Junior e Gross (2013, p. 45)
Aqui terminamos nossa reviso sobre assuntos importantes relativos

arquitetura de computadores, e na sequncia vamos rever conceitos de redes de
computadores.
4 TIPOS DE REDES
As redes de computadores podem ser classificadas de vrias maneiras

diferentes, mas a mais utilizada a classificao do tipo de rede conforme a sua
abrangncia. De acordo com Dantas (2010), as redes se classificam em redes
pessoais (PAN-Personal Area Networks), redes locais (LAN-Local Area Networks),
redes metropolitanas (MAN-Metropolitan Area Networks) e redes de longa distncia
(WAN-Wide Area Networks).

Nesse sentido, fala-se mais comumente nas redes LAN e WAN, e segundo
Dantas (2010): Uma rede local (LAN) uma facilidade de comunicao que prov
uma conexo de alta velocidade entre processadores, perifricos, terminais e
dispositivos de comunicao de uma forma geral em um nico prdio (ou campus).
Ou seja, a LAN uma rede de abrangncia pequena, restrita.
J as redes WAN, segundo Amaral (2012), possuem o conceito de redes

de longa distncia, porque sua abrangncia geogrfica pode ser muito grande,
podendo interligar continentes, pases e regies atravs de enlaces mais longos
por meio de tecnologias com satlites ou fibras ticas (terrestres ou submarinas).
As redes WAN fornecem taxas de transmisso menores que as redes LAN,

mas chegam a dezenas de Gbps. O custo do servio nessas velocidades altas
bastante grande. As WANs possuem uma latncia maior (tempo que a informao
leva dentro da rede para sair da origem e chegar no destino) que as LANs, e tambm
uma taxa de erro um pouco maior. As redes WAN e LAN usam, geralmente, a fibra
ptica como meio fsico de transmisso, e, assim, acabam tendo caractersticas
parecidas, sendo a principal diferena entre elas a distncia abrangida pelas
95
mesmas. Na Figura 7 podemos observar uma rede WAN interligando quatro redes
LAN situadas em quatro cidades distintas.
FIGURA 7 REDE WAN
FONTE: Latzke e Gross (2013, p. 148)

5 TOPOLOGIAS DE REDES
A topologia de uma rede de computadores definida atravs da topologia

fsica e da topologia lgica dessa rede. A topologia fsica compreende a forma
como os meios de transmisso (cabos metlicos, fibras pticas etc.) conectam os
elementos da rede entre si, como computadores, switches e roteadores, por exemplo.
Por outro lado, a topologia lgica trata da maneira como os elementos da rede se
comunicam, utilizando os meios de transmisso da mesma, ou seja, refere-se ao
modo como os dados circulam entre os elementos da rede.
Vamos rever algumas topologias. Comeamos pela topologia em barramento

(Bus), que mais antiga e na qual os computadores ficam todos conectados ao
mesmo backbone, ou barramento, constitudo por um cabo tipo coaxial. Essa
topologia j foi substituda pela topologia estrela, porque caso acontea algum
problema no backbone, todos os computadores deixam de comunicar-se.
A topologia em estrela tem como caracterstica principal a conexo

independente de cada computador a um equipamento central, chamado de
96 concentrador, que atualmente o switch (significa comutador). No passado, essa
funo de concentrador era feita pelos hubs, mas por questes de desempenho
foram substitudos pelos switches, que possuem diversas vantagens. Como
vantagens principais, a topologia estrela prov uma manuteno da rede simplificada,
possui baixo custo, j que o cabo utilizado o par tranado, e caso acontea o
rompimento de um cabo, somente o computador daquele cabo deixar de funcionar.
Na topologia em anel, cada computador da rede conectado a dois ns

(computadores) adjacentes em crculo, formando um anel fechado. A comunicao
entre os computadores normalmente feita numa determinada direo, mas em
topologias mais modernas, como as utilizadas em redes de telecomunicaes, essa
direo poder ser alterada no caso de alguma falha, mantendo o funcionamento
da rede. Normalmente o meio fsico de interligao a fibra ptica.
A topologia em malha define que todos os ns da rede esto interconectados

uns aos outros, formando um desenho semelhante a uma malha. Essa topologia
somente usada para conexo de equipamentos de rede, como roteadores numa
rede de comunicao de uma operadora de telecomunicaes, devido ao alto custo
de implementao, mas fornece confiabilidade extrema.
Na Figura 8 vemos diversas topologias de rede, inclusive barramento,
estrela, anel e malha, que foram revistas acima.
FIGURA 8 TOPOLOGIAS DE REDES
FONTE: Disponvel em: <http://www.teleco.com.br/tutoriais/tutorialrsdh/pagina_3.asp>. Acesso em: 30

maio 2016. 97
6 ENDEREOS IPV4 E IPV6
Como sabemos, dentro de uma rede de computadores cada dispositivo,

para se comunicar com outro e realizar o encaminhamento dos pacotes, necessita
obrigatoriamente de um endereo IP, que provido atravs do protocolo IPv4, muito
utilizado em redes locais e protocolo nativo da internet. O endereamento IP verso
4 (IPv4) explicado por Kurose (2010, p.252), como segue:
Cada endereo IP tem o comprimento de 32 bits (equivalente

a 4 bytes). Portanto, h um total de 232 endereos IP possveis.
Fazendo uma aproximao de 210 por 103, fcil ver que h cerca
de 4 bilhes de endereos IP possveis. Esses endereos so
escritos em notao decimal separada por pontos, na qual cada
byte do endereo escrito em sua forma decimal e separado dos
outros bytes do endereo por um ponto. Por exemplo, considere o
endereo IP 193.32.216.9. O 193 o nmero decimal equivalente
aos primeiros 8 bits do endereo; o 32 o decimal equivalente

ao segundo conjunto de 8 bits do endereo e assim por diante.
Por conseguinte, o endereo 193.32.216.9, em notao binria
11000001 00100000 11011000 00001001.
Os endereos IPv4 so divididos em cinco classes (A, B, C, D, E), conforme

apresentado na Figura 9. Para cada classe de endereo existe uma mscara padro.
FIGURA 9 CLASSES IPV4
98 As mscaras de rede so responsveis por determinar a quantidade de

hosts possveis dentro da rede ou da sub-rede. A mscara quem descreve o incio
e o fim de uma rede. Uma rede sempre pertencer a uma classe de endereos.
Esta classe ter uma mscara de rede padro. Mas isso no rgido, porque
uma mscara de uma classe de rede poder ser usada em outra classe caso
haja necessidade. Dessa forma, pode-se encontrar redes classe A, em grandes
empresas ou organizaes, configuradas com mscara classe B devido ao grande
nmero de hosts (computadores com um endereo IP) por rede.
Com a grande utilizao da internet em nvel mundial, o endereamento IPv4

comeou a ficar escasso, ou seja, estava comeando a faltar endereos para todas as
mquinas existentes e conectadas em rede. Em 2011, praticamente j no existiam mais
endereos IPv4 disponveis para novas redes, e como soluo temporria foi desenvolvida
a tcnica de endereamento no vlido para a internet, aplicvel quando os computadores
seriam usados somente em redes internas. Isso foi implementado reservando faixas de
endereos IP invlidos para a internet em cada classe de endereamento.

O mecanismo NAT (Network Address Translation) responsvel por efetuar
a troca entre os endereos vlidos e no vlidos, e foi definido pela RFC 3022,
atuando na conexo das redes internas internet. A Figura 10 mostra as faixas de
endereos IP que foram reservadas para uso em redes exclusivamente internas
atravs da RFC 3022.
FIGURA 10 ENDEREOS RESERVADOS PARA USO INTERNO
99
Como o endereamento IPv4 no conseguiu suprir a demanda mundial de

endereos IP por possuir somente 32 bits (4 octetos), foi desenvolvido um novo
protocolo, chamado IPv6. Neste protocolo, que atualmente est sendo implantado
gradualmente nas redes locais e na internet, a quantidade de bits de endereo
passou a ser 128 bits, que possibilita um total de 340.282.366.920.938.463.463.74
.607.431.768.211.456 endereos IPs. Isso mesmo, impressionante.
A representao de um endereo IPv6 divide o mesmo em oito grupos de 16

bits, separando-os por ":" (dois pontos), e escritos com dgitos hexadecimais (0-F).
Veja um exemplo: 2001:0DB8:AD1F:25E2:CADE:CAFE:F0CA:84C1
No endereo IPv6 permitido utilizar tanto caracteres maisculos quanto

minsculos. Tambm podem ser aplicadas regras de abreviao visando facilitar
a escrita de alguns endereos muito extensos. Assim, permitido omitir os
zeros esquerda de cada bloco de 16 bits, alm de substituir uma sequncia

longa de zeros por "::" (dois sinais de dois pontos). Dessa forma, o endereo
2001:0DB8:0000:0000:130F:0000:0000:140B pode ser escrito das seguintes
maneiras:
a) 2001:DB8:0:0:130F::140B
b) 2001:DB8::130F:0:0:140B
Como caractersticas e recursos adicionais do protocolo IPv6, alm da

grande capacidade de endereamento proporcionada pelos 128 bits, podemos
relacionar:
Simplificao do cabealho IP.

Autoconfigurao.
Mecanismos de segurana.
Mecanismos de Qualidade de Servio (QoS).
Capacidade de adicionar futuras implementaes.
100
7 SISTEMA DNS
O DNS (Domain Name System) um dos protocolos existentes na camada

de aplicao do modelo de referncia OSI. Como existem muitos endereos IPs
numa rede e principalmente considerando a internet, ficaria impossvel lembrar de
todos os endereos para poder acessar os servios disponveis. Para solucionar
esse inconveniente, foram atribudos nomes aos servios visando facilitar o acesso,
surgindo o DNS, cuja funo realizar a converso de nomes em endereos IP, e
vice-versa. Tanenbaum (2003, p. 617) explica:
A essncia do DNS a criao de um esquema hierrquico de

atribuio de nomes baseado no domnio e de um sistema de
bancos de dados distribudos para implementar esse esquema
de nomenclatura. Ele usado principalmente para mapear
nomes de hosts e destinos de mensagens de correio eletrnico
em endereos IP, mas tambm pode ser usado para outros
objetivos. O DNS definido nas RFCs 1034 e 1035.

Existem muitos servidores DNS espalhados pelo mundo, e para que possam
realizar a converso corretamente foi desenvolvida uma abordagem de anncios,
onde cada servidor DNS se comunica com outro servidor DNS para realizar a
propagao de suas informaes. Dessa forma, ao registrar um domnio na internet,
necessrio adquirir um servidor para que o mesmo possa ser responsvel pela
converso desse determinado nome em um IP. Este servidor ir se comunicar com
os servidores DNS da organizao que regulamenta a internet na localidade para
realizar a conferncia do nome adquirido. No Brasil, o Registro.br o rgo que
regulamenta, e os seus servidores DNS iro realizar a propagao desse anncio
para os servidores Raiz, ou seja, os servidores DNS mundiais, que so os detentores
das classes de IP de todo o mundo.
A estrutura do DNS , portanto, hierarquizada e distribuda em nvel mundial,

tendo vrios servidores razes. Na Figura 11 podemos observar um exemplo de
parte da estrutura DNS, mostrando alguns servidores.
FIGURA 11 ESTRUTURA HIERRQUICA DO DNS
101

De acordo com Latzke e Gross (2013), algumas caractersticas e conceitos
do sistema DNS podem ser resumidas como:
O DNS uma base de dados.

As bases de dados DNS esto distribudas pelo mundo conforme reas
geogrficas e pases.
Cada pas necessita ter um rgo responsvel pela sua estrutura DNS, e no
Brasil o Registro.br.
Cada empresa, organizao, escola, universidade precisa possuir a sua base
de dados DNS na internet.
Um domnio formado por um nome e um conjunto de registros referentes aos
servios/sites disponveis para acesso neste domnio.
Dessa forma finalizamos este captulo, onde pudemos rever conceitos

importantes relacionados a temas diversos das disciplinas de Fundamentos da
Computao, Arquitetura de Computadores e Redes de Computadores. Desejamos
excelentes estudos.
102

----------------------- [ TPICO 6 - PROGRAMAO WEB ] -----------------------
Caro(a) acadmico(a), vamos dar incio ao estudo do tema Programao

Web. Assunto de extrema importncia no cenrio atual. Neste livro abordaremos
assuntos referentes a conceitos de Web e construo de pginas, alm de assuntos
pertinentes ao tema. Vamos ento iniciar os estudos empregando o mximo de
ateno e foco, para que os resultados sejam os melhores possveis. Vale ressaltar
que os assuntos aqui abordados esto listados de forma resumida, e em caso de
dvidas o caderno da disciplina deve ser consultado. Esperamos que esse resumo
contribua para o incremento e fixao dos seus conhecimentos!
Prof. Simone Cristina Alssio
1 INTRODUO
Internet: a maior rede de computadores do mundo; segue padres e 103

regras para compartilhar informaes atravs de e-mails, transferncia de arquivos
etc. Os padres so conhecidos como protocolos.
Web: sua primeira nomenclatura foi World Wide Web (www). uma
tecnologia que permite aos computadores ficarem em rede para compartilhar
informaes. Utiliza links de hipertexto e um protocolo chamado HTTP (hiper text
transfer protocol), que corresponde s quatro primeiras letras de todos os endereos
de sites da internet.
Internet Histrico: a internet surgiu na chamada Guerra Fria, na dcada

de 1960. A partir de 1970, comeou a ser usada tambm no meio acadmico. Em
1990 ganhou alcance geral e passou a ser usada comercialmente.
Internet no Brasil: teve seu incio difundido no meio acadmico, sendo

inicialmente restrito a professores e acadmicos. Em 1995 a internet passou a ser
de domnio pblico.

Cliente/Servidor: uma nomenclatura para definir uma arquitetura
onde um computador cliente e o outro o servidor das informaes. Pode-se
entender servidor como o software que permite a um computador se comunicar
com outros. O servidor aguarda solicitaes de informaes, para reter e reenvi-
las o mais rapidamente possvel aos solicitantes. Existem tambm os servidores
web ou servidores HTTP. Para todo computador e dispositivo (modem, roteador,
smartphone, carros etc.) conectados internet atribudo um nico endereo IP
(Internet Protocol) numrico.
Navegao: o software que realiza as solicitaes chamado de cliente; o

software que responde o servidor. Vrias so as formas utilizadas para navegao
na Web: desktop, navegadores mveis e outras tecnologias, como leitores de telas,
sendo que o servidor retorna o arquivo ou documento para o navegador para ser
exibido. Tanto a requisio quanto a resposta so manipuladas pelo protocolo de
comunicao HTTP. Os documentos se apresentam em vrios formatos: imagens,
texto, filmes, arquivos com som, scripts, entre outros.
Server-side/ Client-side: indicam o lado do cliente ou lado do servidor.

104
Client-side esto na mquina do cliente (solicitante). Server-side representam o lado
do servidor, que envia as respostas s requisies. Para navegar na internet so
necessrios os navegadores grficos, que so as janelas que exibem as pginas.
Exemplos: Internet Explorer, Chrome, Firefox, Safari e Opera. Atualmente existem
navegadores para pessoas com deficincias, onde, por exemplo, pessoas com
problemas de viso ouvem o contedo das pginas da internet atravs dos leitores
de tela. A ergonomia tem evoludo muito neste sentido. Mesmo em navegadores
desktop, pginas podem parecer e funcionar de maneira diferente de navegador
para navegador.
Intranets e Extranets: so duas redes de computadores com caractersticas

distintas. Intranets so restritas ao uso interno em grande parte das organizaes.
Funcionam como uma rede normal, porm, preocupam-se muito mais com a
segurana das informaes. Utilizam-se de firewall para inibir o acesso externo,
limitando a rede ao crculo de negcios e colaboradores. As Extranets tambm s
podem ser acessadas por pessoas que tenham permisso, porm, o acesso feito
de fora da organizao. Exemplo: uma empresa permite que seus fornecedores
acessem as informaes da empresa, mas de forma limitada.

URLs: o endereo de cada pgina da internet e significa Uniform Resource
Locator (Localizador). O tamanho e estilo da URL variam de acordo com a pgina a
ser pesquisada. Nas redesTCP/IP, um URL completo possui a seguinte estrutura:
esquema://domnio:porta/caminho/recurso?query_string#fragmento
Oesquema oprotocolo (HTTP,HTTPS,FTP)etc.
O domnio o endereo da mquina: especifica oservidorque ir

disponibilizar a informao que foi solicitada pelo cliente.
Aportaexecuta a conexo com o servidor.
Ocaminhoindica o local do servidor, onde a informao se encontra.
Aquery string umastringenviada ao servidor para que seja possvel filtrar

ou mesmo criar o recurso. opcional.
Ofragmento uma parte ou posio do recurso.

105
Logo, o esquema que diz ao computador qual linguagem dever usar para
realizar a comunicao; o domnio mostra a localizao do outro computador e os
outros componentes demonstram o restante das informaes solicitadas.
Anatomia de Uma Pgina Web: As pginas web mais simples so

compostas por trs arquivos separados: Um documento HTML (index.html), uma folha
de estilos e grficos. So geralmente geradas por documentos de textos simples,
formados por marcas (tags) especiais (indicadas pelos sinais < e >) que descrevem
cada elemento da pgina. Adicionar tags descritivas a um documento conhecido
como marcar o documento Pginas Web utilizam uma linguagem de marcao
conhecida como HyperText Markup Language (HTML), que foi criada especialmente
para documentos com links de hipertexto. O HTML apresenta inmeros elementos
de texto para compor documentos, como cabealhos, pargrafos, texto e os links.
Tambm permite incrementar a informao do documento atravs de componentes
para criao de formulrios, imagens, mdias.

Documentos HTML: So vrias as verses HTML existentes atualmente.
A verso atual HTML5. O HTML uma linguagem para estruturar e apresentar
contedos de pginas web. A verso 5 traz novas funcionalidades muito importantes,
relacionadas semntica e acessibilidade. Acoplou recursos que antes s poderiam
ser usados atravs da adoo de outras tecnologias. O HTML5 traz tags de vdeo
e udio, inexistentes em verses anteriores.
As etiquetas HTML socase sensitive. Ou seja, no h diferena nas formas

de escrita:<HTML>,<Html>,<html>ou<HtMl>. Todas so reconhecidas.
As etiquetas bsicas de HTML presentes nas pginas so:
<html>: determina o incio de um documento HTML;

<head>: especifica o cabealho de um documento HTML;
<body>: o corpo do documento HTML.
O cabealho apresenta os seguintes componentes:
106
<title>: mostra o ttulo da pgina;
<style type="text/css">: define o formato CSS;
<script type="text/javascript">: permite a adio de funes deJavaScript;
<link>: liga a pgina com outros arquivos, comofeeds,CSS,scripts etc.;
<meta>: faz a descrio da pgina,autor, etc.
Os campos citados so usados pormecanismos de busca(como

o Google, Yahoo!, Bing) e servem de filtro para calcular a similaridade dos
documentos e oferecer ao usurio um resultado mais prximo de suas reais
necessidades. Para o Google, apenas<title>e a meta<description>so usadas
para descrever a pgina indexada numa busca.
As etiquetas<style>e<script>servem para invocar cdigos de arquivos

externos.
Dentro do corpo existem vrias etiquetas para modelar a pgina:

<h1>,<h2>, ...<h6>: para cabealhos e ttulos;
<p>: novo pargrafo;
<br />: quebra de linha;
<table>: cria uma tabela. Os cabealhos das colunas so criados com as
etiquetas<THead><TH>e os rodaps com<TFooter><TR><TD>);
<div>: determina divises na pgina;
<b>,<i>,<u>e<s>: negrito, itlico, sublinhado e riscado;
<img />: imagem;
<a>: ligao para uma pgina, ume-mailou outro servio;
<textarea>: caixa de texto (com mais de uma linha);
<abbr>: abreviao;
<cite>: citao;
<address>:Endereo.
Exemplo de cdigo HTML
<!DOCTYPE html>
<html lang="pt-br">
107
<head>
<meta charset="UTF-8" />
<title>Testando a pgina</title>
</head>
<body>
<h1>Teste </h1>
<p>Outro teste de pgina</p>
<p><i>Texto sublinhado</i></p>
</body></html>
Inserindo Imagens: Arquivos HTML no contm imagens. Elas ficam em

arquivos separados e so colocadas entre o texto atravs do elemento IMAGE do
HTML. O elemento IMAGE indica ao navegador a URL da imagem (endereo para
exibio). Ao encontrar o elemento IMG, o navegador faz uma nova solicitao ao
servidor, para retornar a imagem. O mesmo acontece com vdeos e outros arquivos de
mdias distintas. Embora elaborada e montada em partes, ela retorna completa e de
forma rpida. Em conexes mais lentas os textos podem aparecer antes das imagens.

Estilos: No incio da pgina encontram-se os links que apontam para o
documento de folhas de estilo, que indica como a pgina aparecer no navegador.
Apresenta instrues escritas em CSS (Cascading Style Sheets) que permitem aos
designers das telas elaborarem o estilo visual da pgina, atravs do texto de marcao.
Adicionando Comportamento: alm de definir a estrutura e a cara da

pgina, tambm possvel definir o comportamento da mesma, atravs da linguagem
Javascript. O comportamento definido e alterado atravs da programao.
Web Sites x Web Apps: atualmente no h consenso sobre onde termina

um website e comea um web app. Antes dos apps os sites web forneciam interaes
avanadas aos usurios usando softwares previamente instalados. Exemplo:
webmail, Google maps etc. A web apps permite experincias mais ricas e satisfatrias
dos usurios, possibilitando acesso avanado aos navegadores. Um web app
sempre voltado para tarefas, para fazer alguma coisa. Em celulares, por exemplo,
podemos citar a localizao de um txi, restaurante ou a prpria realizao de uma
chamada telefnica. Para entender melhor: websites so lidos. Web apps so para
leitura e escrita. Websites so consumidos. Web apps permitem criar.
108
Rich Internet Application (RIA): significa aplicao de internet rica.

uma aplicao Web que se parece muito com software de aplicao desktop.
Muito utilizada para jogos nos navegadores (sons, vdeos, movimentos, grficos).
concorrente do HTML5.
Computao em Nuvem: a computao em nuvem permite o

armazenamento, acesso e compartilhamento de informaes atravs da internet.
Baseia-se no conceito de informao em qualquer hora e lugar. Os dados
armazenados so acessados a qualquer hora de qualquer lugar do mundo, sem a
necessidade de instalao de tecnologia especfica para isso. O acesso aos dados
remoto, no sendo necessrias as instalaes fsicas. Para acesso, basta que o
computador tenha a configurao mnima de acesso internet.
Web Server: so os servidores de internet. So programas de computador

que interpretam as solicitaes HTTP de computadores clientes, para devolver uma
resposta. So usados para hospedar os sites da Web. Podem tambm ser usados

para armazenar dados, executar aplicativos, e-mail, FTP para transferncia de
arquivos, entre outros. Web servers mais conhecidos:
Apache Tomcat da Apache http://tomcat.apache.org

Internet Information Server (IIS) da Microsoft http://www.iis.net
Google Web Server (GWS) da Google
Glassfish da Oracle
XML(eXtensibleMarkupLanguage): gera linguagens de marcao para

necessidades especiais. Faz parte do conjunto de subtipos do SGML (Standard
Generalized Markup Language). Seu objetivo descrever distintos tipos de dados,
facilitando o compartilhamento dos mesmos atravs da internet. O XHTML uma
das linguagens XML. O XML define o formato de pginas web, criando uma estrutura
nica para vrias linguagens.
Vantagens do uso do XML:

um padro formal de desenvolvimento.
Est associado ao W3C, instituio de padronizao mundialmente reconhecida.
109
Tem como base as experincias de desenvolvimento do SGML.
O texto simples e facilita o entendimento.
Suportao formato Unicode.
Atravs do XML possvel implementar listas, rvores e registros, comuns em
outras linguagens de programao, inclusive a programao estruturada.
Apresenta boa documentao e se autodocumenta, atravs de seu formato.
Os algoritmos XML so mais rpidos e eficientes.
editvel em editores txt antigos. Os editores atuais destacam o XML (tag,
contedo e atributos).
Desvantagens:
Geralmente esto associados a implementaes de menor complexidade,
como vetores e listas, onde os desenvolvedores podem optar por formatos mais
simples, avaliando dentre outros itens como velocidade e editabilidade.
XHTML (eXtensible Hypertext Markup Language), combina astagsde marcao

HTML com regras da XML, permitindo a exibio de uma pgina web em diversos
formatos, como televiso,palmtop,celular, alm de melhorar o acesso ao contedo.

Cascading Style Sheets(CSS) umalinguagem que trabalha com folhas
de estilona apresentao de documentos que so escritos em linguagem de
marcao. Ela separa o formato do contedo.
Os programadores criam links para pginas que contm os estilos ao invs

de incorpor-los no documento. Isso cria um padro para todas as pginas. Para
alterar a aparncia, altera-se apenas um arquivo, facilitando a manuteno.
JAVA: Java uma plataforma que agrega vrias tecnologias para

desenvolvimento web, inclusive a linguagem de que leva o prprio nome Java.
uma tecnologia orientada a objetos que surgiu na dcada de 1990, desenvolvida
pela empresa SUN Microsystems. A linguagem Java compilada por um bytecode
que executado por uma mquina virtual.
Foi projetada para atender aos seguintes critrios:

Ser orientada a objetos.
Ser portvel, ou seja, no ter dependncia da plataforma.
Facilitar a comunicao em rede atravs dos protocolos TCP/IP, HTTPeFTP.
110
Oferecer segurana.
Vantagens:
A escrita do cdigo parecida com as linguagens C e C++.
fcil de ser especificada.
Possui vrias bibliotecas (APIs) que facilitam o desenvolvimento dos aplicativos.
Facilita o desenvolvimento de aplicativos distribudos.
WEB DESIGN: Atravs da web design possvel criar websites e outros

documentos que estaro disponveis em servidores para internet.
Web design multidisciplinar, pois exige conhecimento de vrias reas, alm

dos conhecimentos tcnicos do prprio design. Envolve programao, ergonomia,
arquitetura das informaes, criatividade, inovao, ousadia.
Preocupa-se com a experincia do usurio final no que tange acessibilidade

e ergonomia, para garantir que o mesmo atinja seus objetivos atravs de uma
experincia satisfatria na pgina.

O profissional web designer o responsvel pela parte esttica e funcional
dos sites. Ele deve ter domnio de vrias tecnologias: HTML/XHTML,CSS,JavaScript/
DHTML,Flashetc.
ASP: (Active Server Pages) uma estrutura de bibliotecas. No pode ser

considerada uma linguagem. Processa linguagens de script no servidor. Opera com
linguagens como VBScript,JScript ouPython. Roda em Windows Server atravs do
servio ISS (Internet Information Services). Tambm roda em Linux, com servidor Apache.
PHP: A linguagem PHP foi criada em 1994. Em 1995 seu cdigo-fonte foi
liberado. Seu nome significa Personal Home Page. uma linguagem modularizada,
amplamente utilizada em servidores web. Sua sintaxe muito parecida com as
linguagens C e C++. uma linguagem pblica e de cdigo aberto.
JSP: uma tecnologia usada para criar pginas web em HTML e XML,
permitindo acesso ao banco de dados, alm da manipulao de arquivos texto. Uma
pgina criada nesta tecnologia e instalada em um servidor de aplicao que seja
compatvel com a plataforma Java EE transformada em um Servlet. As pginas
111
so carregadas dentro do servidor e processadas pelo Java EE Web Application.
A sintaxe do JSP uma mistura de dois tipos bsicos de contedo:scriptlet
elementsemark-up. Mark-up um padro do HTML ou XML, sendo que os
elementos scriptlet so blocos de cdigo Java que podem ser unidos com o mark-up.
APACHE: um servidor. Tambm conhecido por HTTP Apache. o mais

conhecido e utilizado servidor para web. Foi desenvolvido em 1995. compatvel
com o protocolo HTTP e suporta mais da metade de todos os sites existentes.
ISS: o servidor web da Microsoft. uma plataforma para a hospedagem

de sites, servios e aplicativos. Integra facilmente as tecnologias: ASP.
NET, FTP, PHP, WCFe o prprio ISS. Permite a gerao de pginas HTML
dinmicas, atravs de tecnologia proprietria (ASP). Sua instalao requer licena
de uso. Reduz o consumo do servidor, aumentando a segurana na rede. Utiliza o
protocolo FTP para que seja possvel carregar e baixar arquivos.
MYSQL: um SGBD (Sistema Gerenciador de Banco de Dados), que utiliza

a linguagem de consulta estruturada (SQL). Tem alta portabilidade, suportando

praticamente todas as plataformas atuais. rpido e estvel. Permite o uso de
triggers, procedures e funes de banco. Tem um eficiente controle de transaes.
amplamente utilizado.
SQL: se divide em dois grupos principais, os comandos destinados

definio de dados (DDL Data Definition Language) e os comandos destinados
manipulao de dados (DML Data Manipulation Language).
O phpMyAdmin a ferramenta de administrao de banco de dados MySQL

disponibilizada no XAMPP, e permite criao dos objetos do banco de dados
sem a necessidade de escrever os comandos DDL.
JEE: a plataforma JAVA para redes. Contm bibliotecas (APIs)

desenvolvidas especificamente para acesso a servidores. Altamente escalvel
(muitos usurios acessando ao mesmo tempo).
JSF: Java Server Faces o framework padro da Java para criao de

sites com tecnologia JEE. Funciona baseado em objetos que so guardados na
112
memria do servidor, responsveis por gerar o cdigo HTML para o navegador.
Pertence arquitetura MVC.
JPA: O JPA pertence tecnologia JAVA EE e fornece um conjunto de

interfaces e classes usadas em aplicativos desenvolvidos em Java. O JPA faz a
persistncia de estado das classes Java. responsvel pela criao das tabelas
na base de dados e mapeamento do objeto relacional (ORM). O JPA permite a
persistncia do estado de qualquer classe Java, bastando para tal colocar as
anotaes obrigatrias. O JPA fica responsvel pela criao das tabelas no banco
de dados e posteriores operaes de mapeamento objeto relacional.
ORM: Tcnica utilizada para tratar as incompatibilidades entre os modelos

relacional e orientados a objetos.
EJB: (Enterprise Java Beans) um componente da plataforma JEE

que roda em containers de servidores de aplicao que encapsula a lgica.
Tem como foco a lgica do problema a ser resolvido. Foi criado para permitir um
desenvolvimento rpido e seguro de aplicativos em Java.

Entity Beans so objetos que persistem em uma base de dados. Os
Session Beans executam tarefas para os clientes (solicitantes). O Message Driven
Beans processa as mensagens entre os EJBs.
CDI: responsvel pela injeo de dependncia quando necessrio manter

baixo nvel de acoplamento entre as distintas partes de um sistema.
STATELESS SESION BEANS: um bean de sesso sem a informao

de estado, pois no mantm comunicao com muitos mtodos para com os
seus clientes.
STATEFULL SESSION BEAN: um bean de sesso com informaes

de estado. Ou seja: controlam o estado do usurio. Do suporte aos processos
de negcio que precisam de vrias solicitaes ou transaes ao mesmo tempo.
SINGLETON BEANS: Pode ser considerado o terceiro tipo de bean. uma

instanciao de uma classe com um nico acesso global.
113

----------------------- [ TPICO 7 - GESTO DE PROJETO ] -----------------------
Caro(a) acadmico(a), neste captulo vamos relembrar os assuntos

referentes rea de Gerncia de Projetos, com suas dez reas de conhecimentos.
Os assuntos sero apresentados de forma sintetizada, atravs dos objetivos e das
principais atividades do Gerente de Projetos, o qual responsvel por planejar e
controlar a execuo de projetos em diversas reas de atuao, entre outros, como,
no nosso caso, odesenvolvimento de software.
Portanto, mostraremos tcnicas, ferramentas e metodologias que

possibilitam ao gestor uma maior padronizao e controle na execuo dos projetos.
Antes de comearmos a nossa reviso, os conceitos so apresentados

segundo o guia PMBOK do PMI (PROJECT MANAGEMENT INSTITUTE, 2013),
lembrando que apresentaremos uma verso reduzida e abordaremos as reas de
conhecimento. Sugerimos que voc aprofunde seus estudos para melhores resultados.
Prof. Neli Miglioli Sabadin 115
1 INTRODUO
Antes de comearmos a nossa reviso, os conceitos so apresentados

segundo o guia PMBOK do PMI (PROJECT MANAGEMENT INSTITUTE, 2013),
lembrando que apresentaremos uma verso reduzida e abordaremos as reas
de conhecimento.
Sugerimos que voc aprofunde seus estudos para melhores

resultados no ENADE. Acesse: <http://escritoriodeprojetos.
com.br/guia-de-gerenciamento-de-projetos.aspx>

Projeto, segundo a definio proposta pelo PMI (2013), um esforo
temporrio aplicado para criar um produto, servio ou resultado nico. O conceito
de temporrio, pois ele tem um comeo e um fim definido, o que no significa
que deva ser obrigatoriamente curto ou longo. O trmino alcanado quando os
objetivos do projeto so atingidos ou quando o projeto encerrado porque os seus
objetivos no sero ou no podem ser alcanados, ou quando a necessidade do
projeto deixar de existir, ou pela solicitao do cliente para o encerramento. Um
projeto pode envolver uma nica pessoa ou muitas pessoas, uma nica organizao
ou mltiplas unidades organizacionais de mltiplas organizaes (PMI, 2013).
GERENCIAMENTO DE PROJETOS a aplicao de conhecimentos,

ferramentas e habilidades para ter sucesso nos projetos (PMI, 2013, p. 4). Ele
normalmente inclui (mas no se limita) a identificao dos requisitos, a abordagem
das diferentes necessidades, preocupaes e expectativas das partes
interessadas no planejamento e execuo do projeto e o estabelecimento,
manuteno e execuo de comunicaes ativas, eficazes e colaborativas
entre as partes interessadas. O gerenciamento das partes interessadas visando
o atendimento aos requisitos do projeto e a criao das suas entregas. Alm
116
do equilbrio das restries conflitantes do projeto, que incluem (mas no se
limitam) o Escopo, Qualidade, Cronograma, Oramento, Recursos e Riscos.
Vale ressaltar que as caractersticas e circunstncias especficas do projeto podem
influenciar as restries nas quais a equipe de gerenciamento do projeto precisa
se concentrar (PMI, 2013).
O Guia PMBOK (que a base desse resumo) tem seu alicerce no plano
PDCA, que, segundo Vaz (2015), tambm chamado de Ciclo de Deming ou Ciclo
de Shewhart, e consiste em uma ferramenta de gesto que objetiva promover a
melhoria contnua dos processos por meio de um circuito de quatro aes: planejar
(Plan), fazer (Do), checar (Check) e agir (Act). O intuito ajudar a entender no s
como um problema surge, mas tambm como deve ser solucionado, focando na
causa e no nas consequncias. Uma vez identificada a oportunidade de melhoria,
hora de colocar em ao atitudes para promover a mudana necessria e, ento,
atingir os resultados desejados com mais qualidade e eficincia. Esse mtodo de
anlise e de mudana de processos parte do pressuposto de que o planejamento
no uma fase estanque ou seja, no acontece uma nica vez, tampouco

absoluta. Por isso, no decorrer do projeto pode ser preciso mudar o planejamento. E
o Ciclo PDCA ajuda a fazer exatamente esse controle, que contnuo, contribuindo
para que cada processo se desenvolva da melhor maneira possvel.
Para maiores informaes, acesse: <http://www.

projectbuilder.com.br/blog-pb/entry/pratica/ciclo-pdca-
uma-ferramenta-imprescindivel-ao-gerente-de-projetos>
Segundo o Guia PMBOK (2013), o gerenciamento de projetos a

aplicao do conhecimento, habilidades, ferramentas e tcnicas s atividades
do projeto para atender aos seus requisitos. Ele realizado atravs da aplicao
e integrao apropriadas dos 47 processos de gerenciamento de projetos,
logicamente agrupados em cinco grupos de processos. Esses cinco grupos de
processos so: Iniciao, Planejamento, Execuo, Monitoramento e Controle,
e Encerramento. Esses cinco grupos, segundo Medeiros (2013), so aplicados
em reas de conhecimento. Uma rea de conhecimento definida por seus 117
requisitos de conhecimentos e descrita em termos dos processos que a compem,
suas prticas, entradas, sadas, ferramentas e tcnicas. Existem nove reas de
conhecimento, so elas: Integrao, Escopo, Tempo, Custos, Qualidade, Recursos
Humanos, Comunicaes, Riscos e Aquisies.
2 PARTES INTERESSADAS E PMO
Um Escritrio de Gerenciamento de Projetos (EGP ou, em ingls, PMO) uma

estrutura organizacional que padroniza os processos de governana relacionados
a projetos, e facilita o compartilhamento de recursos, metodologias, ferramentas e
tcnicas. As responsabilidades de um PMO podem variar, desde o fornecimento de
funes de apoio ao gerenciamento de projetos, at a responsabilidade real pelo
gerenciamento direto de um ou mais projetos. H vrios tipos de estruturas de PMO
nas organizaes, e elas variam em funo do seu grau de controle e influncia
nos projetos da organizao, tais como: SUPORTE, CONTROLE e DIRETIVO
(PMBOK, 2013, p. 10).

As partes interessadas tm diversos nveis de responsabilidade e autoridade
quando participam de um projeto, segundo o Guia PMBOK (2013), os quais podem
mudar ao longo do ciclo de vida do projeto. E a participao das partes interessadas
pode ser efetiva ou pontual, apenas. A identificao das partes interessadas um
processo contnuo em todo o ciclo de vida do projeto, bem como a compreenso
do seu grau relativo de influncia em um projeto e o balanceamento das suas
exigncias, necessidades e expectativas so fundamentais para o sucesso de um
projeto. As partes interessadas do projeto incluem:
STAKEHOLDER - para Bezerra (2014), significa pblico estratgico e

descreve uma pessoa ou grupo que fez um investimento ou tem aes ou interesse
em uma empresa, negcio ou indstria. Em ingls stake significa interesse,
participao, risco; holder significa aquele que possui. Assim, stakeholder tambm
significa parte interessada ou interveniente. uma palavra em ingls muito utilizada
nas reas de comunicao, administrao e tecnologia da informao, cujo objetivo
designar as pessoas e grupos mais importantes para um planejamento estratgico
ou plano de negcios, ou seja, as partes interessadas.
118 PATROCINADOR: uma pessoa ou grupo que fornece recursos

e suporte para o projeto e responsvel pelo sucesso do mesmo.
Ele pode ser externo ou interno em relao organizao do
gerente de projetos, e deve promover o projeto desde a sua
concepo inicial at o seu encerramento. Ele tambm garante
uma transferncia tranquila das entregas do projeto para os
negcios da organizao do solicitante aps o encerramento
do projeto (PMBOK, 2013, p. 31).
GERENTE DE PROJETOS: a pessoa alocada pela

organizao executora para liderar a equipe responsvel por
alcanar os objetivos do projeto, seu papel diferente de um
gerente funcional ou gerente de operaes. Normalmente, o
gerente funcional se concentra em proporcionar a superviso
de gerenciamento de uma unidade funcional ou de negcios, e
os gerentes de operaes so responsveis pela eficincia das
operaes de negcios. Os gerentes de projetos so responsveis
pelo atendimento de necessidades: de tarefas, necessidades de
equipe e necessidades individuais. Como o gerenciamento de
projetos uma disciplina estratgica crtica, o gerente de projetos
torna-se o elo entre a estratgia e a equipe (PMBOK, 2013, p. 15).

CLIENTES E USURIOS: So as pessoas ou organizaes
que aprovaro e gerenciaro o produto, servio ou resultado
do projeto. So eles que usaro o produto, servio ou resultado
do projeto. Da mesma maneira que o patrocinador, eles podem
ser internos ou externos em relao organizao executora, e
tambm podem existir em mltiplos nveis (PMBOK, 2013, p. 31).
VENDEDORES: Fornecedores ou contratadas, so empresas externas que

assinam um contrato para fornecimento de componentes ou servios necessrios
ao projeto (PMBOK, 2013, p. 32).
PARCEIROS DE NEGCIOS: So organizaes externas que tm uma

relao especial com a empresa, s vezes obtida atravs de um processo de
certificao. Os parceiros de negcios fornecem consultoria especializada ou
desempenham um papel especfico, como instalao, personalizao, treinamento
ou suporte (PMBOK, 2013, p. 31).
GRUPOS ORGANIZACIONAIS: So as partes interessadas internas

afetadas pelas atividades da equipe do projeto (PMBOK, 2013, p. 32).
119
GERENTES FUNCIONAIS: So pessoas-chave que desempenham uma
funo gerencial dentro de uma rea administrativa ou funcional do negcio, como
recursos humanos, finanas, contabilidade ou aquisies (PMBOK, 2013, p. 32).
OUTRAS PARTES INTERESSADAS: Como entidades de aquisies,

instituies financeiras, rgos pblicos reguladores, especialistas em reas do
conhecimento, consultores e outros, podem ter um interesse financeiro no projeto,
contribuir com informaes para o projeto, ou ter um interesse no resultado do
mesmo (PMBOK, 2013, p. 32).

3 OS GRUPOS DE PROCESSOS DE GERENCIAMENTO DE PROJETOS
Um grupo de processo um conjunto de processos que suportam o

desenvolvimento do projeto, onde Processo um conjunto de aes (inter-
relacionadas) que levam a um resultado (sadas esperadas de produtos, resultados
ou servios). Os grupos de processos de gerenciamento de projetos esto
vinculados pelas sadas que produzem, eles raramente so eventos distintos ou
que ocorrem uma nica vez; so atividades sobrepostas que ocorrem ao longo
de todo o projeto. A sada de um processo, em geral, torna-se uma entrada
em outro processo ou uma entrega do projeto, subprojeto ou fase do projeto.
As entregas em nvel de projeto ou subprojeto podem ser chamadas de entregas
incrementais. O grupo de processos de planejamento fornece ao grupo de processos
de execuo o plano de gerenciamento do projeto e os documentos do projeto e,
medida que o projeto avana, ele frequentemente cria atualizaes no plano de
gerenciamento e nos documentos do projeto. A Figura 1 ilustra como os grupos de
processos interagem e mostra o nvel de sobreposio em diversas ocasies. Se
o projeto estiver dividido em fases, os grupos de processos interagem dentro de
cada fase (PMBOK, 2013).
120
A seguir esto todos os processos de gerenciamento de projetos do Guia
PMBOK Quinta Edio, agrupados por rea de conhecimento e grupos de processos:

FIGURA 1 - GRUPO DE PROCESSOS DE GERENCIAMENTO DE PROJETOS E MAPEAMENTO DAS
REAS DE CONHECIMENTO
121
FONTE: Adaptado de PMI (2013, p. 61)
Observa-se na Figura 2 que os processos interagem entre si, e quase

que durante todo o projeto. O processo de iniciao, por exemplo, interage com
os processos de planejamento, os processos de planejamento interagem com os
processos de execuo, e assim por diante. Isso significa, por exemplo, que temos
processos de iniciao que geram sadas para os processos de planejamento
(PMBOK, 2013).

FIGURA 2 - INTERAO ENTRE OS PROCESSOS
FONTE: PMBOK (2013, p. 419)
122 Processos de uma mesma rea tambm podem gerar sadas para serem
entradas para processos da mesma rea. Portanto, os processos, de alguma
forma, se relacionam uns com os outros.
A aplicao dos processos tambm pode ser iterativa, ou seja, na

medida em que o projeto vai se desenvolvendo, alteraes vo sendo feitas nos
processos. s vezes, inclusive o planejamento do projeto precisa ser alterado
devido alguma mudana requerida pelo cliente, e isso teria como efeito revisitar
os processos de planejamento, tendo como sada um novo planejamento
do projeto. Assim, verificamos que os mesmos processos so abordados
novamente, isso nos remete a essa iteratividade nos processos.
FONTE: Disponvel em: <http://www.devmedia.com.br/grupos-de-processos-segundo-o-pmbok/27106>.

Acesso em: 3 abr. 2016.

4 REAS DE CONHECIMENTO
Uma rea de conhecimento, segundo o PMI, definida por seus requisitos de

conhecimentos e descrita em termos dos processos que a compem, suas prticas,
entradas, sadas, ferramentas e tcnicas. Existem nove reas de conhecimento,
so elas: INTEGRAO, ESCOPO, TEMPO, CUSTOS, QUALIDADE,
RECURSOS HUMANOS, COMUNICAES, RISCOS E AQUISIES E PARTES
INTERESSADAS (PMBOK, 2013).
4 - INTEGRAO (estes nmeros se referem ao captulo do PMBOK

5 edio)
Colocando de maneira resumida, o Guia PMBOK (2013) afirma que

o gerenciamento da integrao do projeto inclui os processos e as atividades
necessrias para identificar, definir, combinar, unificar e coordenar os vrios
processos e atividades dos grupos de processos de gerenciamento. Nesta rea
de conhecimento, o gerente do projeto age como integrador dos processos e das
pessoas. Descrevem-se os processos que integram elementos do gerenciamento
de projetos, que so identificados, definidos, combinados, unificados e coordenados 123
dentro dos grupos de processos de gerenciamento de projetos. Os processos
dessa rea so:
Desenvolver o termo de abertura do projeto.

Desenvolver o plano de gerenciamento do projeto.
Orientar e gerenciar o trabalho do projeto.
Monitorar e controlar o trabalho do projeto.
Realizar o controle integrado de mudanas.
Encerrar o projeto ou fase.
Apresentaremos uma adaptao do resumo dos processos

realizada pelo site Escritrio de projetos, referente quinta
edio do Guia PMBOK.

O gerenciamento da integrao define onde e quando concentrar
recursos e esforos, tratando problemas antes de se tornarem crticos e
coordenando o trabalho visando sempre o sucesso do projeto. Alguns aspectos
a serem considerados:
Os processos de controle de mudanas esto alinhados com as diretrizes

de controle de mudanas do PMO?
As metas e os objetivos do projeto esto evidenciados no plano do projeto?
Avaliar de maneira integrada qualquer necessidade de replanejamento.
Usar o plano de gerenciamento das comunicaes para garantir informaes
disponveis para as reas necessrias.
Descrevendo os processos do gerenciamento da integrao do projeto:

4.1 Desenvolver o termo de abertura do projeto: Fase em que se deve
autorizar um projeto ou fase e documentar requisitos iniciais.
4.2 Desenvolver o plano de gerenciamento do projeto: Identificar as
124 aes necessrias para definir, preparar, integrar e coordenar planos auxiliares.
4.3 Orientar e gerenciar o trabalho do projeto: realizar trabalho definido
no plano de projeto para atingir os objetivos do projeto.
4.4 Monitorar e controlar o trabalho do projeto: O Gerente vai
acompanhar e revisar o progresso para atender aos objetivos de desempenho
definidos no plano do projeto.
4.5 Realizar o controle integrado de mudanas: Faz-se a reviso das
solicitaes de mudana, a aprovao e gerenciamento de mudanas.
4.6 Encerrar o projeto ou fase: Fase em que se finaliza todas as atividades
de gerenciamento do projeto para terminar o projeto ou a fase.

5 ESCOPO
Esta rea descreve os processos envolvidos na verificao de que o projeto

inclui todo o trabalho necessrio e apenas o trabalho necessrio, para que seja
concludo com sucesso. Durante essa etapa preocupa-se, principalmente, em DEFINIR
E CONTROLAR O QUE EST INCLUSO NO PROJETO E O QUE NO EST.
Descrevendo os processos do gerenciamento do escopo do projeto:

5.1 Planejar o gerenciamento do escopo: Aqui se define e documenta-se
como a equipe do projeto IR DEFINIR, CONTROLAR E VALIDAR O ESCOPO.
5.2 Coletar os requisitos: Fase em que o GP define e documenta as
necessidades das partes interessadas para atingir os objetivos do projeto.
5.3 Definir o escopo: Deve-se desenvolver a descrio detalhada do
projeto e do produto.
5.4 Criar a EAP (Estrutura Analtica do Projeto): Subdivide os produtos do
projeto e o trabalho do projeto em componentes menores e mais gerenciveis. A
EAP fundamental para o projeto, pois fornece uma viso estruturada do que ser
entregue, facilitando o entendimento das partes interessadas em relao ao que
deve ser feito (escopo) no projeto, alm de servir de base para o planejamento das 125
outras reas de conhecimento.
5.5 Validar o escopo: Nesta etapa formaliza-se a aceitao dos produtos
do projeto.
5.6 Controlar o escopo: O GP monitora o status do escopo do projeto e
do produto e gerencia as alteraes na linha de base de escopo.
6 TEMPO
Segundo o Guia PMBOK, o gerenciamento do tempo inclui os

processos requeridos para assegurar a concluso do projeto no prazo previsto.
Esta rea descreve os processos relativos ao trmino do projeto no prazo

correto. Os cinco primeiros processos so de planejamento e apenas o ltimo
de controle. Os processos de planejamento definem as atividades que vo

para o cronograma, a ordem de precedncia das atividades, determinam o tipo
e a quantidade de recursos necessrios, o tempo necessrio para concluir as
atividades, associam as atividades s datas do cronograma e, por fim, verificam
se o andamento dos trabalhos est de acordo com o cronograma.
Descrevendo os processos do gerenciamento do tempo do projeto:

6.1 Planejar o gerenciamento do cronograma: Fase em que se
estabelecem polticas, procedimentos para planejar, desenvolver, gerenciar e
controlar o cronograma.
6.2 Definir as atividades: Identificar as atividades especficas que devem
ser executadas para produzir as entregas do projeto so atividades desenvolvidos
nesta fase.
6.3 Sequenciar as atividades: Fase em que se deve identificar e
documentar as relaes de dependncia entre as atividades.
6.4 Estimar os recursos das atividades: O GP estima o tipo e quantidade
dos recursos necessrios para executar cada atividade.
126 6.5 Estimar as duraes das atividades: Aps estimar os recursos,
deve-se estimar a quantidade de perodos de trabalho que sero necessrios para
completar cada atividade.
6.6 Desenvolver o cronograma: Analisar a sequncia das atividades, sua
durao, seus recursos e suas restries para criar o cronograma do projeto so
atividades que so realizadas nesta etapa.
6.7 Controlar o cronograma: Mudanas sempre ocorrem e o GP deve
controlar as mudanas no cronograma.
Leva nove meses para uma mulher gerar um beb. No se pode gerar
um beb em um ms engravidando nove mulheres.

7 CUSTO
O gerenciamento dos custos do projeto inclui os processos envolvidos

em estimativas, oramentos e controle dos custos, de modo que o projeto possa
ser terminado dentro do oramento aprovado. Onde os primeiros dois processos
so de planejamento, e temos que os processos nesta rea de conhecimento
determinam o custo de cada atividade levando em considerao o recurso alocado
na atividade, alm dos perodos de trabalho que o recurso estar trabalhando na
atividade, determinam que os custos de cada atividade sejam somados a fim de
gerar uma linha de base de custos, e acompanham a execuo para verificar se
as coisas esto ocorrendo conforme o oramento definido.
Descrevendo os processos do gerenciamento dos custos do projeto:

7.1 Planejar o gerenciamento dos custos: Estabelecer as polticas,
procedimentos e documentao para planejar, gerenciar, executar e controlar os
custos do projeto.
7.2 Estimar os custos: Estimar os custos dos recursos necessrios para
executar as atividades do projeto. 127
7.3 Determinar o oramento: Agregar os custos estimados das atividades
para estabelecer uma linha de base.
7.4 Controlar os custos: Monitorar o status do projeto para atualizar o
oramento e gerenciar alteraes na linha de base dos custos.
8 QUALIDADE
O Gerenciamento da Qualidade em Projetos busca assegurar que o

projeto satisfaa as necessidades do cliente e envolve todas as atividades do
projeto por todo o seu ciclo de vida. Ele implementa o sistema de gesto da
qualidade por meio de polticas e procedimentos com atividades de melhoria
contnua de processos. O GP deve conscientizar toda a equipe sobre a
importncia de buscar os objetivos da qualidade, e para isso deve oferecer as
condies necessrias para que o time possa alcan-los.

Descrevendo os processos do gerenciamento da qualidade do projeto:
8.1 Planejar o gerenciamento da qualidade: Identificar os requisitos e/
ou padres da qualidade do projeto e do produto, bem como documentar de que
modo o projeto demonstrar a conformidade.
8.2 Realizar a garantia da qualidade: Processo de auditoria dos requisitos
da qualidade e dos resultados das medies do controle da qualidade para certificar
que os padres da qualidade e definies operacionais apropriadas esto sendo
utilizados.
8.3 Controlar a qualidade: Processo de monitoramento e registro dos
resultados da execuo das atividades da qualidade para avaliar a performance e
recomendar mudanas necessrias.
9 RECURSOS HUMANOS
Segundo o Guia PMBOK, o gerenciamento dos recursos humanos

128 do projeto inclui os processos que organizam e gerenciam a equipe do projeto.
Os processos desta rea de conhecimento tm como objetivo determinar os
tipos e o perfil dos profissionais, alm da hierarquia desses profissionais e
quem responsvel pelo o que no projeto quando ele estiver em execuo;
determinam como mobilizar as pessoas que foram requisitadas no projeto; se
preocupam com o treinamento da equipe, alm da integrao e gerao de
conhecimento, e determinam como resolver conflitos antes que eles afetem o
projeto. A equipe composta por pessoas com funes e responsabilidades
atribudas com foco no trmino do projeto.
Descrevendo os processos do gerenciamento dos recursos humanos do

projeto:
9.1 Planejar o gerenciamento dos recursos humanos: Identificar e
documentar as funes, responsabilidades, competncias necessrias e relaes
hierrquicas. Cria o plano de gerenciamento de RH.
9.2 Mobilizar a equipe do projeto: Obter os recursos humanos necessrios
para o projeto.

9.3 Desenvolver a equipe do projeto: Melhorar as competncias e
interao dos membros da equipe para aprimorar o desempenho do projeto.
9.4 Gerenciar a equipe do projeto: Acompanhar o desempenho da equipe,
fornecer feedback, resolver problemas e coordenar mudanas para melhorar o
desempenho do projeto.
10 COMUNICAES
Esta rea descreve os processos relativos gerao, coleta,

disseminao, armazenamento e destinao final das informaes do projeto de
forma oportuna e adequada. Segundo o Guia PMBOK, o gerenciamento das
comunicaes do projeto inclui os processos necessrios para assegurar que
as informaes do projeto sejam geradas, coletadas, distribudas, armazenadas,
recuperadas e organizadas de maneira oportuna e apropriada. Os processos
desta rea de conhecimento determinam quem est envolvido no projeto, definem
como as comunicaes vo ocorrer quando o projeto iniciar e determinam o tipo 129
de informaes geradas, quem o responsvel, qual o meio, quem receber as
informaes geradas, qual a periodicidade, determinam como sero distribudas
as informaes, como podemos gerenciar as expectativas dos interessados
medindo o grau de satisfao ou insatisfao das pessoas interessadas, e geram
relatrios que permitam o acompanhamento e controle do que est acontecendo
com o tempo, custo, escopo etc.
A comunicao certamente uma das reas de conhecimento mais

importantes para o GP, se no for a mais importante. Ela representa cerca de 90%
do tempo do GP e o elo de ligao entre as pessoas, as ideias e as informaes.
Alm disso, a maioria dos problemas dos projetos oriunda de falha de

comunicao e existe uma forte correlao entre o desempenho do projeto e a
habilidade do GP em administrar as comunicaes.

Descrevendo os processos do gerenciamento das comunicaes do projeto:
10.1 Planejar o gerenciamento das comunicaes: identificar as
necessidades e relevncia de informaes e definir abordagem de comunicao.
10.2 Gerenciar as comunicaes: colocar as informaes necessrias
disposio das partes interessadas conforme planejado. Envolve todo o ciclo de
vida da informao descrito no plano de gerenciamento da comunicao, composto
por gerar, coletar, distribuir, armazenar, recuperar e at descartar a informao.
10.3 Controlar as comunicaes: controlar e monitorar as comunicaes
de modo a garantir que as necessidades de informao das partes interessadas
sejam atendidas.
11 RISCOS
Segundo o Guia PMBOK, o gerenciamento dos riscos do projeto

inclui os processos de planejamento, identificao, anlise, planejamento de
130 respostas, monitoramento e controle de riscos de um projeto. Seu objetivo
maximizar a exposio aos eventos positivos e minimizar a exposio aos
eventos negativos.
Os processos desta rea de conhecimento tm como objetivo determinar

como os riscos sero identificados, analisados e como as respostas sero
planejadas e como o risco ser planejado; criam uma lista de riscos identificados
no projeto com diversas tcnicas que ajudam a gerar essa lista de riscos;
buscam priorizar os riscos com base no grau de criticidade; permitem atribuir
probabilidade numrica aos riscos; definem estratgias e aes para lidar com
os riscos negativos e positivos; monitoram os riscos com novos riscos sendo
identificados, reviso das anlises de riscos, definio de outras prioridades
de riscos etc.
Risco de um projeto um evento com uma probabilidade de ocorrer

no futuro, impactando o projeto de forma negativa (ameaa) ou positiva
(oportunidade). Ele pode ocorrer devido a uma ou mais causas e pode ocasionar
um ou mais impactos positivos ou negativos. importante ressaltar que os

riscos esto relacionados com as demais reas de conhecimento e devem
ser tratados de forma integrada, considerando as melhores prticas de cada
rea de conhecimento.
Os riscos podem ser:

Conhecidos, foram identificados, analisados e considerados no planejamento
do projeto.
Desconhecidos, e nesse caso, quando o evento ocorre, temos um problema
ou questo para o projeto (Issues) e devem ser tratados agilmente.
O GP deve tomar as devidas aes corretivas, identificar as causas e tomar
aes preventivas para que o problema no ocorra novamente.
E ainda, deve documentar todas as decises tomadas, notificar os
responsveis e garantir seu comprometimento na resoluo do mesmo.
Descrevendo os processos do gerenciamento dos riscos do projeto:

11.1 Planejar o gerenciamento dos riscos: definir como conduzir as
atividades de gerenciamento de riscos para o projeto. 131
11.2 Identificar os riscos: determinar quais riscos podem afetar o projeto
e documentar suas caractersticas.
11.3 Realizar a anlise qualitativa dos riscos: avaliar a exposio ao risco
para priorizar os riscos que sero objeto de anlise ou ao adicional.
11.4 Realizar a anlise quantitativa dos riscos: efetuar a anlise numrica
do efeito dos riscos identificados nos objetivos gerais do projeto.
11.5 Planejar as respostas aos riscos: desenvolver opes e aes para
aumentar as oportunidades e reduzir as ameaas aos objetivos do projeto.
11.6 Controlar os riscos: monitorar e controlar os riscos durante o ciclo
de vida do projeto.

12 AQUISIES
Segundo o Guia PMBOK, o gerenciamento das aquisies do projeto

inclui os processos necessrios para comprar ou adquirir produtos, servios ou
resultados externos equipe do projeto, alm dos processos de gerenciamento
de contratos. Os processos desta rea de conhecimento tm como objetivo
determinar o que se quer adquirir, de quem se quer adquirir, receber as respostas
dos fornecedores e selecionar o fornecedor, como se dar o gerenciamento dos
contratos, pagamentos, se as entregas esto de acordo com o que foi estabelecido,
pagar o fornecedor e, por ltimo, formalizar a finalizao do contrato.
O gerenciamento das aquisies do projeto uma das reas de

conhecimento mais importantes dentro das organizaes, principalmente devido
ao aumento constante da terceirizao de servios.
As empresas precisam trabalhar no que elas fazem de melhor e deixar

as demais reas para empresas especializadas. Como afirmou Tom Peters: "Do
what you do best and outsource the rest."
132
Seus principais envolvidos so:

Vendedor = fornecedor, contratada, subcontratada, prestador de servios ou
fornecedor.
Comprador = cliente, contratante, organizao compradora, rgo
governamental, solicitante do servio. Seguindo o Guia PMBOK, sempre
abordar a perspectiva do comprador.
Um dos principais elementos das aquisies o contrato, documento

legal entre comprador e fornecedor que descreve um acordo mtuo gerando
obrigaes entre as partes.
Descrevendo os processos do gerenciamento das aquisies do projeto:

12.1 Planejar o gerenciamento das aquisies: documentar as decises
de compras do projeto, especificando a abordagem e identificando fornecedores
em potencial.

12.2 Conduzir as aquisies: obter as respostas dos fornecedores,
selecionar um fornecedor e redigir o contrato.
12.3 Controlar as aquisies: gerenciar as relaes de aquisio
monitorando o desempenho do contrato e realizando as mudanas e correes
conforme necessrio.
12.4 Encerrar as aquisies: finalizar todas as aquisies do projeto
13 GERENCIAMENTO DAS PARTES INTERESSADAS
O gerenciamento das partes interessadas a nova rea de conhecimento

do Guia PMBOK@ 5 edio, o que refora a importncia das partes interessadas
em nossos projetos. As partes interessadas (tambm chamadas pelo termo
ingls stakeholders) so os indivduos e as organizaes ativamente envolvidos
no projeto, ou seja, quem interessa no seu projeto. O projeto ir atender
necessidades das partes interessadas e elas so responsveis por atender ao
objetivo do projeto. Podem ser positivamente ou negativamente afetados com 133
a execuo do projeto e iro influenciar o projeto e/ou seu resultado.
Descrevendo os processos do gerenciamento das partes interessadas do

projeto:
13.1 Identificar as partes interessadas: e seus interesses, envolvimento
e impacto no sucesso do projeto.
13.2 Planejar o gerenciamento das partes interessadas: desenvolver
estratgias para quebrar as resistncias das partes interessadas e garantir seu
engajamento no projeto.
13.3 Gerenciar o engajamento das partes interessadas: comunicar e
interagir com as partes interessadas para atender suas necessidades e solucionar
as questes quando ocorrem.
13.4 Controlar o engajamento das partes interessadas: monitorar os
relacionamentos entre as partes interessadas e ajustar as estratgias para engajar
as partes interessadas, eliminando resistncias e aumentando o suporte ao projeto.
FONTE: Disponvel em: <http://escritoriodeprojetos.com.br/gerenciamento-da-integracao-do-projeto.
aspx>. Acesso em: 3 abr. 2016.

REFERNCIAS
AMARAL, Allan Francisco Forzza. Redes de Computadores. Colatina: Instituto
Federal do Esprito Santo, 2012.
BASTOS, Cleverson; KELLER, Vicente. Aprendendo Lgica. 1. ed. Rio de

Janeiro, RJ: Vozes, 1991.
BEZERRA, Filipe. Stakeholders - do significado classificao. Disponvel

em: <http://www.portal-administracao.com/2014/07/stakeholders-significado-
classificacao.html>. Acesso em: 24 mar. 2016.
BOENTE, Alfredo Nazareno P.; OLIVEIRA, Fabiano S. G.; ALVES, Joo C. N.

RUP como Metodologia de Desenvolvimento de Software para Obteno
da Qualidade de Software. Disponvel em: <http://www.boente.eti.br/publica/
seget2008rup.pdf>. Acesso em: 26 maio 2016.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usurio.

Rio de Janeiro: Elsevier, 2005.
CAELUM. Algoritmos e estruturas de dados em java. Disponvel em: <http://

www.ime.usp.br/~cosen/verao/alg.pdf>. Acesso em: 10 out. 2014. 135
CUNHA, Gaspar Antonio; TAKAHASHI, Ricardo; ANTUNES, Carlos Henggeler.

Manual de computao evolutiva e meta heurostica. Coimbra: UFMG, 2012.
CUNHA, Judson Michel; JUNIOR, Danton Cavalcanti Franco. Arquitetura de

computadores. Indaial: Uniasselvi, 2012.
DANTAS, Mrio. Redes de comunicao e computadores: abordagem

quantitativa. Florianpolis: Visual Books, 2010.
DEITEL. Harvey M.; DEITEL. Paul J. Java, como programar. Traduo Carlos
Arthur Lang Lisba, 4. ed. Porto Alegre: Bookman, 2003.
DIMES, Troy. Scrum Essencial. Canad: Babelcube Inc., 2014. Disponvel em:
<http://doc.otrs.org/3.2/en/html/>. Acesso em: 30 jun. 2015.
ENGHOLM JR, Hlio. Engenharia de software na prtica. 1. ed. So Paulo:

Editora Novatec, 2010.
ESCRITRIO DE PROJETOS. processos do guia PMBOK. 5. ed. Disponvel

em: <http://escritoriodeprojetos.com.br/gerenciamento-da-integracao-do-projeto.
aspx>. Acesso em: 24 mar. 2016.

FERNANDES, D. B. Metodologia dinmica para o desenvolvimento de
sistemas versteis. So Paulo: rica, 1999.
FERREIRA, Aurlio Buarque de Holanda. Dicionrio da lngua portuguesa. 5.

ed. Curitiba: Positivo, 2010.
FRANCISCANI, Juliana; PESTILI, Ligia C. CMMI e MPS.BR: um estudo

comparativo. [S.1.], [S.1.]. Disponvel em: <http://www.unicerp.edu.br/images/
revistascientificas/3%20-%20 CMMI%20e%20MPS.BR%20Um%20Estudo%20
Comparativo1.pdf>. Acesso em: 27 set. 2015.
GAMMA, E. et al. Padres de projeto: solues reutilizveis de software

orientado a objetos. Porto Alegre, Brasil: Bookman, 2000.
GUIA ORACLE: Banco de dados Oracle 10g: Fundamentos de SQL I Ano 2004.
Disponvel em: <http://docplayer.com.br/1410956-Introducao-ao-oracle-sql-e-pl-
sql-guia-do-estudante-volume-1.html>. Acesso em: 2 mar. 2016.
HIRAMA, K. Engenharia de Software: qualidade e produtividade com

tecnologia. Rio de Janeiro: Elsevier, 2011.
ISO. Standards. Disponvel em: <http://www.iso.org/iso/home.htm>. Acesso em:

20 set. 2015.
136 JUNIOR, Danton Cavalcanti Franco; GROSS, Jan Charles. Sistemas e

Aplicaes Distribudas. Indaial: Uniasselvi, 2013.
KOCHANSKI, D.; ANDRIETTI, O. J. Algoritmos. Indaial: Uniasselvi, 2005.
KROLL, P.; KRUCHTEN, P. The rational unified process made easy: a

practitioners guide to the RUP. Addison Wesley, 2003.
KUROSE, James F.; ROSS, Keith W. Redes de computadores e a Internet:

uma abordagem top-down. 5. ed. So Paulo: Pearson, 2010.
LARMAN, C. Utilizando UML e padres. 3. ed. Porto Alegre: Bookman, 2007.
LATZKE, Carlos Alberto; GROSS, Jan Charles. Infraestrutura de redes de

computadores. Indaial: Uniasselvi, 2013.
LAUREANO, Marcos. Estrutura de dados com algoritmos e C. So Paulo:

Brasport, 2008.
MEDEIROS, Higor. reas de conhecimento segundo o PMBOK. Disponvel

em: <http://www.devmedia.com.br/areas-de-conhecimento-segundo-o-
pmbok/27129>. Acesso em: 24 mar. 2016.
MELO, A. C. Desenvolvendo aplicaes com UML 2.2. 3. ed. Rio de Janeiro:

Brasport, 2006.

MORAES, Alexandre Fernandes de. Redes de computadores. So Paulo: rica,
2014.
PAIXO, Renato Rodrigues. Arquitetura de computadores PCs. So Paulo:

rica, 2014.
PFLEEGER, Shari Lawrence. Engenharia de software, teoria e prtica. 2. ed.

So Paulo: Pearson, 2004.
PIVA, G. D. Anlise e Gerenciamento de Dados. Manual de Informtica Centro

Paula Souza, v. 3, So Paulo, 2010.
PONTUSCHKA, Maurcio Nacib. Modelagem de software orientada a objetos.

Disponvel em: <http://www.pucsp.br/~tuska/2012/MSOO/antigas/Aula02.ppt>.
Acesso em: 5 maio 2016.
PRESSMAN, R. S. Engenharia de Software Uma abordagem profissional. 7.

ed. Porto Alegre: AMGH Editora Ltda., 2011.
PRESSMAN, Roger S. Engenharia de software. 3. ed. So Paulo: McGraw-Hill,

2006.
PRESSMAN, Roger S. Engenharia de software. McGraw Hill, 6. ed. Porto

Alegre: 2010.
137
PROJECT MANAGEMENT INSTITUTE PMI Project. Um guia do
conhecimento em gerenciamento de projetos - Guia PMBOK). 5. ed. USA:
Pennsylvania, 2013.
REZENDE, Ricardo; Conceitos Fundamentais de Banco de Dados. 2006.

Disponvel em <http://www.devmedia.com.br/conceitos-fundamentais-de-banco-
de-dados/1649#ixzz446smOoRh>. Acesso em: 2 mar. 2016.
ROMAN, Norton T. Algoritmos Gulosos. Disponvel em: <http://www.each.usp.

br/digiampietri/SIN5013/13-algoritmosGulosos.pdf>. Acesso em: 5 jul. 2016.
ROSS, Jlio. Redes de computadores. Rio de Janeiro: Almeida e Porto, 2008.
SOMMERVILLE, Ian. Engenharia de Software. 9. ed. So Paulo: Pearson

Addison Wesley, 2011.
SOUZA, Givanaldo Rocha de. Metodologias geis de desenvolvimento de

software. Disponvel em: <http://docente.ifrn.edu.br/givanaldorocha/disciplinas/
engenharia-de-softwarelicenciatura-em-informatica/ESw03MetodologiasAgeis.
pdf>. Acesso em: 27 set. 2015.
TAKAI, Osvaldo Kotaro et al. Introduo a banco de dados. 2005. Disponvel

em: <https://www.ime.usp.br/~jef/apostila.pdf>. Acesso em: 24 mar. 2016.

TANENBAUM, Andrew S. Redes de Computadores. 5. ed. Rio de Janeiro:
Elsevier, 2003.
TORRES, Gabriel. Redes de computadores: curso completo. Rio de Janeiro:

Axcel Books, 2001.
TUFFOLO, Tlio. Algoritmos e Estruturas de Dados I. Disponvel em: <http://

www.decom.ufop.br/toffolo/site_media/uploads/2013-1/bcc202/slides/14._
mergesort.pdf>. Acesso em: 5 jul. 2016.
VASCONCELOS A. M. L. de et al. Introduo engenharia de software e

qualidade de software. UFLA/FAEPE, 2006. 57 p. (Curso de Ps-graduao
Lato Sensu (Especializao) Distncia Melhoria de Processo de Software.
VAZ, Thassia; Ciclo PDCA: uma ferramenta imprescindvel ao gerente de

projetos! Disponvel em: <www.projectbuilder.com.br/blog-pb/entry/pratica/ciclo-
pdca-uma-ferramenta-imprescindivel-ao-gerente-de-projetos>. Acesso em: 24
mar. 2016.
ZANCHETT, Pedro Sidnei. Engenharia e projeto de software. Indaial:

Uniasselvi, 2015.
138

139

Analise e Desenvolvimento de S

Enviado por

Direitos autorais:

Formatos disponíveis

Analise e Desenvolvimento de S

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analise e Desenvolvimento de S

Enviado por

Direitos autorais:

Formatos disponíveis

CENTRO UNIVERSITRIO

ANLISE E DESENVOLVIMENTO DE SISTEMAS EM FOCO

Pr-Reitora de Ensino de Graduao a Distncia

Pr-Reitor Operacional de Graduao a Distncia

Propriedade do Centro Universitrio Leonardo da Vinci

Anlise e desenvolvimento de sistemas em Foco

Anlise e desenvolvimento de sistemas em foco/ Greisse Moser;

Anlise e desenvolvimento de sistemas em Foco

Caro leitor, voc est prestes a iniciar a leitura do livro Anlise e

Constantemente somos avaliados em provas, concursos e, em grande

Vale salientar que os textos reunidos nesta publicao so frutos das

Esperamos que voc faa uma tima leitura!

Me. Greisse Moser Badalotti

Anlise e desenvolvimento de sistemas em Foco

TPICO 2 - PROGRAMAO ORIENTADA A OBJETOS ............................. 27

TPICO 3 - LGICA, ALGORITMOS E ESTRUTURA DE DADOS ............... 39

Anlise e desenvolvimento de sistemas em Foco

TPICO 4 - BANCO DE DADOS RELACIONAL ........................................... 63

TPICO 5 - ARQUITETURA E REDES DE COMPUTADORES ..................... 81

TPICO 6 - PROGRAMAO WEB ............................................................... 103

Anlise e desenvolvimento de sistemas em Foco

Anlise e desenvolvimento de sistemas em Foco

Caro(a) acadmico(a), neste captulo vamos relembrar alguns dos principais

Apresentaremos um resumo do que consideramos os principais tpicos

Vamos ento iniciar os estudos, empregando o mximo de ateno e foco

Prof. Pedro Sidnei Zanchett

Segundo Ian Sommerville (2011), a Engenharia de Software uma disciplina

Anlise e desenvolvimento de sistemas em Foco

FONTE: Disponvel em: <http://3.bp.blogspot.com/_CMoqSGzMYOg/SkrJEy3nGeI/AAAAAAAAAAk/

Na base da figura, formando a camada foco na qualidade, d-se nfase

A camada de processo permite integrar as camadas de mtodos e de

A camada de mtodos prov as abordagens e as atividades necessrias

A camada de ferramentas prov apoio automatizado ou semiautomatizado

Anlise e desenvolvimento de sistemas em Foco

Segundo Fernandes (1999), metodologia de sistemas se define como um

A ausncia de uma metodologia de desenvolvimento de sistemas pode

Padronizao: executar as atividades de maneira idntica, fazendo com que

Anlise e desenvolvimento de sistemas em Foco

Segundo Kroll e Kruchten (2003), o Rational Unified Process, de sigla RUP,

O RUP utiliza a linguagem de modelagem unificada para especificar, modelar

3 FASES DE DESENVOLVIMENTO DE SOFTWARE

Atualmente, muitas so as metodologias de desenvolvimento de softwares.

Para capturar a dimenso do tempo de um projeto, o processo de Engenharia

Fase de Iniciao: nfase no escopo.

Anlise e desenvolvimento de sistemas em Foco

No momento em que se decide construir um software, fundamental

Um processo de software composto por mtodos (aquilo que diz o que,

5 CICLO DE VIDA DE DESENVOLVIMENTO DE SOFTWARE

O ciclo de vida de um software descreve as fases pelas quais o software 5

De maneira geral, as fases do ciclo de vida de um software so constitudas

Os modelos de processo de ciclo de vida durante o desenvolvimento do

Anlise e desenvolvimento de sistemas em Foco

Modelo cascata ou sequencial, possui um ciclo de vida clssico, em que todas

Anlise e desenvolvimento de sistemas em Foco

A partir do momento em que for decidido iniciar um processo de construo

A extrao de requisitos o processo de transformar o conhecimento tcito,

Diversas atividades de requisitos de software ocorrem ao longo de todo o

Existem duas categorias de requisitos: os requisitos de negcio, que iro

Anlise e desenvolvimento de sistemas em Foco