3

Anlise e
Gerenciamento
de Dados

Informtica
Habilitao tcnica em

Informtica
Volume 3

Informtica
Anlise e gerenciamento
de dados
Gustavo Dibbern Piva
Wilson Jos de Oliveira

So Paulo
2010

Governador
Jos Serra

Presidente
Paulo Markun
Vice-Presidente
Fernando Jos de Almeida

Ncleo Cultura Educao

Coordenador: Fernando Jos de Almeida
Gerente: Monica Gardelli Franco
Equipe de autoria Centro Paula Souza
Coordenao geral: Ivone Marchi Lainetti Ramos
Coordenao da srie Informtica: Luis Eduardo
Fernandes Gonzalez
Autores: Carlos Eduardo Ribeiro, Evaldo Fernandes

Ru Jnior, Gustavo Dibbern Piva, Joo Paulo Lemos

Escola, Luciene Cavalcanti Rodrigues, Ralfe Della
Croce Filho, Wilson Jos de Oliveira
Reviso tcnica: Anderson Wilker Sanfins, Luis
Claudinei de Moraes, Humberto Celeste Innarelli,
Srgio Furgeri

Equipe de Edio
Coordenao geral

Alfredo Nastari
Coordenao editorial

Mirian Ibaez
Consultor tcnico

Victor Emmanuel J. S. Vicente

Vice-Governador
Alberto Goldman

Edio de texto: Marlene Jaggi

Editores assistentes: Celia Demarchi

e Wagner Donizeti Roque

Secretrio editorial: Antonio Mello
Revisores: Antonio Carlos Marques, Fabiana Lopes
Bernardino, Jos Batista de Carvalho, Lieka Felso
e Miguel Facchini
Direo de arte: Deise Bitinas
Edio de arte: Ana Onofri
Editoras assistentes: Nane Carvalho, Nicia Cecilia
Lombardi e Roberta Moreira
Assistentes: Ana Silvia Carvalho, Claudia Camargo
e Felipe Lamas
Ilustraes: Carlos Grillo
Pesquisa iconogrfica: Completo Iconografia,
Maria Magalhes e Priscila Garofalo
Fotografia: Carlos Piratininga, Eduardo Pozella (fotgrafos)
e Daniela Mller (produtora)
Tratamento de imagens: Sidnei Testa
Impresso em Vitopaper 76g, papel
sinttico de plstico reciclado, da Vitopel,
pela Grfica Ideal.

Dados Internacionais de Catalogao na Publicao (CIP)

(Bibliotecria Silvia Marques CRB 8/7377)

P693
Piva, Gustavo Dibbern

Informtica, anlise e gerenciamento de dados / Gustavo Dibbern
Piva, Wilson Jos de Oliveira ; revisor Humberto Celeste Innarelli ;
coordenador Luis Eduardo Fernandes Gonzalez. -- So Paulo :
Fundao Padre Anchieta, 2010

(Manual de Informtica Centro Paula Souza, v. 3)

ISBN 978-85-61143-47-3

1. Sistemas operacionais (Computadores) 2. Softwares de aplicao
I. Oliveira, Wilson Jos de II. Innarelli, Humberto Celeste, revisor III.
Gonzalez, Luis Eduardo Fernandes, coord. IV. Ttulo
CDD 005.43

Secretrio de Desenvolvimento
Geraldo Alckmin

Presidente do Conselho Deliberativo

Yolanda Silvestre
Diretora Superintendente
Laura Lagan

Vice-Diretor Superintendente
Csar Silva
Chefe de Gabinete da Superintendncia
Elenice Belmonte R. de Castro
Coordenadora da Ps-Graduao, Extenso e
Pesquisa
Helena Gemignani Peterossi
Coordenador do Ensino Superior de Graduao
Angelo Luiz Cortelazzo
Coordenador de Ensino Mdio e Tcnico
Almrio Melquades de Arajo
Coordenador de Formao Inicial e Educao
Continuada
Celso Antonio Gaiote
Coordenador de Infraestrutura
Rubens Goldman
Coordenador de Gesto Administrativa e
Financeira
Armando Natal Maurcio
Coordenador de Recursos Humanos
Elio Loureno Bolzani
Assessora de Avaliao Institucional
Roberta Froncillo
Assessora de Comunicao
Gleise Santa Clara
Procurador Jurdico Chefe
Benedito Librio Bergamo

Sumrio
15 Captulo 1
Introduo ao desenvolvimento de
software

1.1. Conceitos iniciais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.2. Geraes de computadores. . . . . . . . . . . . . . . . . . . . 17

1.3. Geraes de linguagem de programao. . . . . . . . . . 20

1.4. Processo de desenvolvimento. . . . . . . . . . . . . . . . . . . 22

1.8.4. Documentao de requisitos . . . . . . . . . . . . . . 38

1.8.5. Mtodos de identificao e coleta. . . . . . . . . . 39

1.8.5.1. Entrevista. . . . . . . . . . . . . . . . . . . . . . . 39

1.8.5.2. M
 etodologia JAD (Joint Application
Design). . . . . . . . . . . . . . . . . . . . . . . . . 44

49 Captulo 2
Modelo de entidade e relacionamento

1.4.1. Objetivos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.4.2. Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.4.3. Participantes . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2. Normalizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

1.5. Modelo de ciclo de vida. . . . . . . . . . . . . . . . . . . . . . . . 24

2.3.Fases de um projeto utilizando o modelo ER. . . . . . . 79

2.1. Conceitos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.1.1. Estudo de caso. . . . . . . . . . . . . . . . . . . . . . . . . . 62

1.5.1. Modelo em cascata ou waterfall. . . . . . . . . . . . . 27

2.3.1. Minimundo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

1.5.2. Modelo em cascata evolucionrio ou waterfall

2.3.2. Levantamento de requisitos. . . . . . . . . . . . . . . 80

2.3.3. Anlise de requisitos. . . . . . . . . . . . . . . . . . . . . 81

2.3.4. Requisitos de dados. . . . . . . . . . . . . . . . . . . . . . 81

2.3.5. Requisitos funcionais. . . . . . . . . . . . . . . . . . . . . 81

2.3.6. Projeto conceitual. . . . . . . . . . . . . . . . . . . . . . . 84

2.3.7. Projeto lgico . . . . . . . . . . . . . . . . . . . . . . . . . . 84

2.3.8. Projeto fsico. . . . . . . . . . . . . . . . . . . . . . . . . . . 89

evolucionrio. . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.5.3. Modelo incremental . . . . . . . . . . . . . . . . . . . . . 30

1.5.4. M
 odelo iterativo . . . . . . . . . . . . . . . . . . . . . . . . 31

1.5.5. Modelo espiral. . . . . . . . . . . . . . . . . . . . . . . . . . 32

1.6 Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

1.6.1. Atividades do gerenciamento de riscos . . . . . . 33

1.7 Prototipagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

1.8. L evantamento ou especificao de requisitos . . . . . . 35

1.8.1 O que um requisito. . . . . . . . . . . . . . . . . . . . . 35

1.8.2. Como devemos escrever requisitos. . . . . . . . . 37

1.8.3. Dependncia de requisitos. . . . . . . . . . . . . . . . 38

Capa: Nathalia Guarienti,

aluna da Etec do Centro
Paula Souza.
Foto: Eduardo Pozella
Edio: Deise Bitinas

Sumrio

2.3.9. Anlise funcional. . . . . . . . . . . . . . . . . . . . . . . . 91

2.3.10. Projeto de programas de aplicao. . . . . . . . . 91

2.3.11. Implementao da transao. . . . . . . . . . . . . . 93

3.4.1.1.Segurana no sistema operacional . . . 114

3.4.1.1.1. D
 efinio de contas de usurio. . . . 115

3.4.1.2. P
 ermisses para banco de dados. . . . 116

3.4.1.3. P
 ermisses a objetos

95 Captulo 3
Banco de dados

3.4. Administrao e gerenciamento. . . . . . . . . . . . . . . . 113

3.4.1. Segurana em banco de dados . . . . . . . . . . . . 114

do banco de dados. . . . . . . . . . . . . . . 120

3.1. Evoluo dos sistemas de computao. . . . . . . . . . . . 97

3.1.1. Abordagem tradicional. . . . . . . . . . . . . . . . . . . . 97

3.4.2. P
 lano de manuteno de banco de dados . . . 124

3.1.2. Abordagem de sistemas integrados . . . . . . . . . 98

3.4.3. Uma linguagem verstil: SQL . . . . . . . . . . . . . 129

3.1.3. Abordagem de bancos de dados. . . . . . . . . . . . 98

3.4.3.1. C
 omo utilizar os comandos SQL. . . . 130

3.2. Conceitos e terminologia. . . . . . . . . . . . . . . . . . . . . 101

3.4.3.2. Categorias da linguagem SQL. . . . . . 130

3.4.3.3 Instrues SQL. . . . . . . . . . . . . . . . . . 130

3.2.1. Abstrao de dados . . . . . . . . . . . . . . . . . . . . 101

3.2.2. Instncias e esquemas. . . . . . . . . . . . . . . . . . . 102

3.2.3. Independncia de dados. . . . . . . . . . . . . . . . . 102

3.2.4. L inguagem de definio de dados. . . . . . . . . . 103

3.2.5. Linguagem de manipulao de dados. . . . . . . 103

3.2.6. Usurios de banco de dados. . . . . . . . . . . . . . 103

3.3. Abordagem relacional. . . . . . . . . . . . . . . . . . . . . . . . 103

3.3.1. Caractersticas principais. . . . . . . . . . . . . . . . . 104

3.3.2. Princpios da orientao. . . . . . . . . . . . . . . . . 105

3.3.3. As doze regras de Edgar F.Codd. . . . . . . . . . . 105

3.3.4. Chaves e ndices . . . . . . . . . . . . . . . . . . . . . . . 109

3.3.4.1. Regras de integridade. . . . . . . . . . . . . . 111

3.3.4.2. R
 egras de converso do modelo E-R
para o modelo relacional. . . . . . . . . . 112

Sumrio

3.4.3.4. Views (Vises). . . . . . . . . . . . . . . . . . 140

4.2.2. Relacionamentos. . . . . . . . . . . . . . . . . . . . . . . 176

3.4.3.5. S tored Procedures (procedimento

4.2.3. Diagramas. . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

4.2.4. Adornos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

armazenado). . . . . . . . . . . . . . . . . . . . 143

155

3.4.3.6. Um exemplo completo. . . . . . . . . . . 148

4.3. Os diagramas da UML. . . . . . . . . . . . . . . . . . . . . . . . 178

4.3.1 Diagrama de casos de uso. . . . . . . . . . . . . . . . 179

Captulo 4
Linguagem unificada de modelagem (UML)

4.3.2 Diagrama de classes. . . . . . . . . . . . . . . . . . . . . 185

4.3.3 Diagrama de sequncia . . . . . . . . . . . . . . . . . . 187

4.3.4 Diagrama de comunicao. . . . . . . . . . . . . . . . 190

4.1. Orientao a objetos. . . . . . . . . . . . . . . . . . . . . . . . . 159

4.1.1. Abstrao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

4.3.5 Diagrama de atividades . . . . . . . . . . . . . . . . . . 190

4.1.2. Classe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

4.3.6 Diagrama de pacotes. . . . . . . . . . . . . . . . . . . . 192

4.1.2.1. Mtodo. . . . . . . . . . . . . . . . . . . . . . . . 161

4.3.7 Diagrama de grficos de estados. . . . . . . . . . . 192

4.1.2.2. Responsabilidades . . . . . . . . . . . . . . . 162

4.3.8 Diagrama de objetos. . . . . . . . . . . . . . . . . . . . 194

4.1.2.3. Tipos de relacionamento entre classes. 163

4.3.9 Diagrama de componentes . . . . . . . . . . . . . . . 195

4.1.3. Objeto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

4.3.10 Diagrama de implantao. . . . . . . . . . . . . . . . 196

4.1.3.1. Interao entre objetos. . . . . . . . . . . 166

4.3.11 Diagrama de temporizao. . . . . . . . . . . . . . . 197

4.1.3.2. Mensagem . . . . . . . . . . . . . . . . . . . . . 167

4.3.12 Diagrama de estrutura composta . . . . . . . . . 200

4.2. As vrias opes da UML. . . . . . . . . . . . . . . . . . . . . 170

4.3.13 Diagrama de viso geral de interao. . . . . . 201

4.2.1. Conceitos da estrutura da UML. . . . . . . . . . . 172

4.4. E xemplo de desenvolvimento

de projetos utilizando UML. . . . . . . . . . . . . . . . . . . . 201

204

Consideraes finais

205

Referncias bibliogrficas

<< ator >>

Informtica 3

Captulo 1

Introduo ao
desenvolvimento
de software
Conceitos iniciais
Geraes de computadores
Geraes de linguagem
de programao

Processo de desenvolvimento
Modelo de ciclo de vida
Riscos
Prototipagem
Levantamento ou
especificao de requisitos

Informtica 3

captulo 1

O emprego desse trip levou a uma significativa melhoria no desenvolvimento das companhias chamadas inteligentes, aquelas que necessitam de sistemas
tolerantes a falhas e capazes de gerar informaes crticas para o processo de
deciso. Na dcada de 1960 as empresas trabalhavam com o conceito de processamento centralizado de dados e muitos dos seus recursos eram direcionados ao
CPD (Centro de Processamento de Dados). Os sistemas daquela poca rodavam
de forma mecanizada e em batch (processamento em lote).

automao, h algum tempo, tornou-se um diferencial competitivo para as organizaes. Tal modernizao pode ser entendida
como o esforo para transformar as tarefas manuais repetitivas em
processos independentes, realizados por mquinas. Com isso, a gesto passou
por uma verdadeira revoluo: erros que antes eram cometidos por falhas de
clculos agora so quase nulos. As empresas no precisam se voltar tanto para
atividades contnuas e podem se dedicar mais ao foco do seu negcio. Os benefcios disso se estendem por toda a cadeia de valor, desde compra de materiais,
produo e vendas at entrega de produtos para os clientes e ps-venda.
O desenvolvimento de software uma atividade muito complexa. Sim, porque no
existe uma soluo pronta para cada cenrio. O trabalho sempre realizado por
pessoas, o que torna o sucesso do projeto diretamente relacionado competncia
da equipe e maneira como se trabalha. Outra dificuldade considervel o fato de,
muitas vezes, no ser adotado um processo definido para apoiar essa tarefa.
A tecnologia da informao passou por uma grande evoluo nos ltimos anos.
Com isso, h exigncias contnuas e renovadas de aumento na qualificao dos
profissionais da rea, o que, consequentemente, favorece o seu desenvolvimento.
Afinal, esse segmento composto pela trade pessoas, gesto e tecnologia.

As cinco
geraes de
mquinas

Denis Alcides
Rezende autor
de vrios livros
sobre Tecnologia
da Informao,
Sistemas de
Informao e
Engenharia de
Software. Atua
como consultor
em planejamento
de Tecnologia da
Informao.

Atualmente, as organizaes vivem a era da Tecnologia da Informao (TI).

Agora, os sistemas so todos integrados, possibilitando a otimizao dos processos e a diminuio da redundncia de dados. Com isso, possvel melhorar
muito o dempenho da empresa, pois os processos se tornam mais estruturados,
fato que minimiza o retrabalho (REZENDE, 2002).

1.1. Conceitos iniciais

Com a crescente necessidade das empresas de contar com informaes cada vez
mais rpidas e confiveis, foi necessrio desenvolver no apenas sistemas, como
tambm novos hardwares. Era preciso ter mquinas que atendessem s especificaes de softwares de alto desempenho e de grande disponibilidade.

I.2. Geraes de computadores

Vamos conhecer agora as cinco geraes de equipamentos, a tecnologia empregada em cada uma delas, suas vantagens e desvantagens.

Com a srie 360, da IBM, a

velocidade dos equipamentos passou
para bilionsimos de segundo

Divulga

Sheila Terry/Rutherford Appleton

3 1964 - 1971

4 1971 - 1987
Chega a era do chip, a lmina de
silcio que permite a integrao
de uma infinidade de circuitos

Oleksiy Maksymenko/Alamy/Other Images

Univac I: dez vezes mais rpido

e com um dcimo do tamanho
do Eniac, o modelo anterior

IBM 7090: as vlvulas deram

lugar aos transistores e a vida
til dos equipamentos aumentou
Cern/Science Photo Library/Latinstock

Hulton Archive/Getty Images

2 1958 - 1964

1 1940 - 1958

16

Com o passar do tempo, porm, as corporaes perceberam a necessidade e a importncia de se basear em informaes concretas para tomar suas decises e, assim, aprimorar a gesto dos negcios. Ento, abandonaram o padro do tradicional
processamento de dados e passaram a trabalhar com centro de informaes. Nesse
modelo, j havia integrao dos sistemas, mesmo que ainda existissem algumas redundncias, ou seja, dados duplicados que levavam ao retrabalho.

5 1987
Novas tecnologias revolucionam
os conceitos de processamento
paralelo e armazenamento de dados

17

Informtica 3

captulo 1

Primeira (1940-1958)

Quarta (1971-1987)

O primeiro computador digital eletrnico de grande escala foi o Eniac (Electrical Numerical Integrator and Calculator, ou integradora e calculadora numrica eltrica). Comeou a ser desenvolvido em 1943, durante a Segunda
Guerra Mundial, para auxiliar o Exrcito dos Estados Unidos nos clculos de
balstica. Foi lanado em fevereiro de 1946 pelos cientistas norte-americanos
John Presper Eckert e John W. Mauchly, da Electronic Control Company. O
Eniac realizava 5 mil operaes por segundo, velocidade mil vezes superior
das mquinas da poca. No entanto, se comparado com os computadores
atuais, o seu poder de processamento seria menor do que o de uma simples
calculadora de bolso.

A integrao de circuitos teve grandes incrementos, com crescimento de mil

vezes a cada dez anos. Foram introduzidas vrias escalas de incorporao, definidas pelo nmero de conjuntos que podem ser colocados em uma nica lmina
miniaturizada feita de silcio, o famoso chip. Assim, foram surgindo tecnologias consecutivas: em 1970, LSI (Large Scale Integration integrao em larga
escala); em 1975, VLSI (Very Large Scale Integration integrao em muito
larga escala); e, em 1980, ULSI (Ultra Large Scale Integration integrao em
ultralarga escala).

Mas a primeira gerao de mquinas teve como marco histrico o lanamento

do primeiro computador comercial, o Univac I (Universal Automatic Computer
ou computador automtico universal), em 1951. Ele possua cem vezes a capacidade do Eniac, era dez vezes mais rpido e tinha um dcimo de seu tamanho.
O Univac I tinha como componentes entre 10 mil e 20 mil vlvulas eletrnicas,
com durao mdia de oitocentos a mil horas.

A gerao de equipamentos em uso na primeira dcada do sculo 21 surgiu em

1987, com o uso de novas tecnologias, principalmente relacionadas a dispositivos pticos e a telecomunicaes. Houve aumento de processamento paralelo,
diversidade de formato, incremento da capacidade computacional e de armazenamento, assim como difuso do processamento distribudo. Alm disso,
delineou-se a tendncia de convergncia de computadores e aparelhos de comunicao, o que facilitou a interoperabilidade e a universalizao da operao dos
sistemas, assim como a sua normatizao.

T im

R idley
/G etty

I mages

O primeiro modelo do Univac foi construdo pela empresa Eckert-Mauchly

Computer Corporation, adquirida pela Remington Rand pouco depois. Hoje,
os direitos sobre o nome Univac pertencem Unisys, que aponta a Fora Area Americana, o Exrcito e a Comisso de Energia Atmica norte-americanos
como seus primeiros clientes. Inicialmente, o Univac era usado para executar
funes no Escritrio de Censo dos Estados Unidos. Alm de rgos governamentais, eram usurias do computador empresas como a General Electric, a
Metropolitan Life e a Du Pont. Naquela poca, cada uma das 46 unidades fabricadas do Univac custava US$ 1 milho. Em 1953, surgiu o IBM 701 e, em 1954,
o IBM 650. Ambos tiveram muito sucesso de vendas para a poca, chegando a
2 mil unidades em cinco anos.

Segunda (1958-1964)
A fabricao dos computadores foi alterada e as vlvulas deram lugar aos
transistores, cuja vida til era bem maior (90 mil horas). Com isso, as
mquinas ficaram mais rpidas e menores. Pertence a essa segunda gerao
o IBM 7090, que possua 40 mil transistores e 1,2 milho de ncleos magnticos. Ocupava uma rea de 40 m 2 , contra a de 180 m 2 do Eniac.

Terceira (1964-1971)

T im

18

/G etty
R idley

I mages

Em 1964, a IBM anunciou o lanamento da srie 360 com circuito integrado.

Os circuitos impressos so milimtricos e podem conter transistores, resistncias
e condensadores. Para se ter uma ideia, 50 mil desses conjuntos cabem em um
dedal. A novidade permitiu um grande aumento na velocidade de computao
de dados, passando de milionsimos de segundo para bilionsimos de segundo.
Assim, um programa que era executado em uma hora, no modelo de computador de 1951, levava entre trs e quatro segundos para rodar nos equipamentos
da terceira gerao.

Quinta (1987- primeira dcada do sculo 21)

Vantagens e desvantagens das 5 geraes de computadores

Gerao

Componente eletrnico

Vantagens

Desvantagens

1 gerao
1940-1958

vlvulas eletrnicas

nicos componentes
eletrnicos disponveis

grande dimenso
produzem muito calor
necessitam de ar condicionado

2 gerao
1958-1964

transistores

menor dimenso
produzem menos calor
mais rpidos

ainda necessitam de
constante manuteno
necessitam de ar condicionado

3 gerao
1964-1971

circuitos integrados

ainda menor dimenso

menor produo de calor
menor consumo de energia
ainda mais rpidos

inicialmente com muitos

problemas de fbrica

4 gerao
1971-1987

circuitos integrados
larga escala

no necessrio ar condicionado
conservao mnima
alta densidade de componentes

existem ainda computadores

com menos potncia em relao a
computadores de outras geraes

transdutores e circuitos
em paralelo

maior densidade de
componentes
reduzido tamanho
auto-regenerao
grande fiabilidade e velocidade
multiprocessamento

5 gerao
1987-atual

maior complexidade
ainda muito caros

19

Informtica 3

captulo 1

1.3. Geraes de linguagem de programao

importante conhecer as geraes de linguagens de programao, para entender bem o contexto atual (SWEBOK, 2004).

Primeira (1GL)

O Swebok (Software
Engineering Body of
Knowledge, traduzido por
reas do Conhecimento da
Engenharia de Software)
uma iniciativa da Sociedade
da Computao do Instituto
de Engenharia Eltrica e
Eletrnica (IEEE Computer
Society), com o propsito
de criar um consenso sobre
as reas de conhecimento
da engenharia de software.
Publicado em 2004, contou
com a participao da
indstria internacional, de
sociedades de profissionais,
da academia e de diversos
autores consagrados.

A primeira gerao de programao utiliza apenas linguagem de mquina, ou

seja, o sistema binrio de 0 (zero) e 1 (um) para o desenvolvimento dos softwares. Sua desvantagem ser pouco intuitiva, pois no utiliza linguagens mais sofisticadas que permitem a portabilidade do programa, isto , o cdigo utilizado
acaba restrito a um nico tipo de hardware e arquitetura utilizada.

Segunda (2GL)
A linguagem de programao chamada Assembly representa a segunda gerao. Mais prxima do ser humano do que da mquina (como acontecia na
1GL), cada Assembly ainda bastante associada arquitetura do computador,
fazendo com que a 2GL tambm seja pouco portvel entre ambientes.

Terceira (3GL)
A terceira gerao das linguagens de programao est muito prxima do ser
humano, pois facilmente entendida por uma pessoa com pouco ou nenhum
conhecimento de informtica. Isso porque similar comunicao do dia a
dia. Essa gerao representada pelas linguagens Cobol, Fortran, Algol, Basic,
C, C++, entre outras. Para mais informaes sobre a 3GL veja quadro abaixo.

A principal caracterstica das linguagens de quarta gerao descrever o que

deve ser feito, permitindo ao programador visar um resultado imediato. So
consideradas capazes de, por si ss, gerar cdigos, ou seja, os RADs (Rapid
Application Development, ou Desenvolvimento Rpido de Aplicao), com os
quais podem ser criadas aplicaes, mesmo sem se especializar na linguagem.
Tambm nesse grupo esto as linguagens orientadas a objetos.

Quinta (5GL)
A quinta gerao ainda est pouco desenvolvida e engloba as linguagens para
inteligncia artificial. Sua maior representante a LISP, nome originado da
expresso LISt Processing (Processamento em Lista), j que a lista a sua estrutura de dados fundamental.
Para desenvolver um software pode-se utilizar uma gerao de linguagem ou
um conjunto delas. Entretanto, o melhor resultado no projeto final obtido
quando se vence o desafio de adequar a programao aos sistemas de informao
de diversas reas do conhecimento.

Saiba mais sobre as 3GL

Cobol, sigla para COmmon Business Oriented Language (Linguagem
Orientada aos Negcios): usada em sistemas comerciais, financeiros
e administrativos para empresas e governos. Foi criada em 1959,
durante o CODASYL (Conference on Data Systems Language, a
Conferncia de Linguagem de Sistemas de Dados), um dos trs
comits propostos em uma reunio no Pentgono, organizado por
Charles Phillips, do Departamento de Defesa dos Estados Unidos. As
fontes de inspirao so as linguagens FLOW-MATIC, inventada por
Grace Hopper, e COMTRAN, da IBM, inventada por Bob Bemer.
Fortran, acrnimo para a expresso IBM Mathematical FORmula

TRANslation System (Sistema de Traduo de Frmula Matemtica

da IBM): famlia desenvolvida a partir dos anos 1950. Usada,
principalmente, em Cincia da Computao e Anlise Numrica, foi
a primeira linguagem de programao imperativa, criada para o IBM
704, entre 1954 e 1957, por uma equipe chefiada por John W. Backus.

Basic, sigla para Beginners All-purpose Symbolic Instruction

Code (Cdigo de Instruo Simblico para Todos os Propsitos

20

Quarta (4GL)
A linguagem SQL (Structured Query Language, ou Linguagem de Consulta
Estruturada) tornou-se to popular que passou a representar toda a quarta
gerao. Ainda hoje, bastante utilizada como linguagem de manipulao e
consulta de banco de dados, como o SQL-Server da Microsoft, Oracle Database da Oracle e MySQL da Sun.

de Iniciantes): criada com fins didticos, pelos professores

John George Kemeny e Thomas Eugene Kurtz, em 1964, no
Dartmouth College. Tambm o nome genrico de uma extensa
famlia de linguagens de programao derivadas do Basic
original.

C: compilada, estruturada, imperativa, processual, de alto

nvel e padronizada. Foi criada em 1972, por Dennis Ritchie,

no AT&T Bell Labs, como base para o desenvolvimento do
sistema operacional UNIX (escrito em Assembly originalmente).

C++: de alto nvel, com facilidades para o uso em baixo nvel,

multiparadigma e de uso geral. Desde os anos 1990, uma
das linguagens comerciais mais populares, mas disseminada
tambm na academia por seu grande desempenho e base
de utilizadores. Foi desenvolvida por Bjarne Stroustrup
(primeiramente, com o nome C with Classes, que significa
C com classes, em portugus), em 1983, no Bell Labs, como
um adicional linguagem C.

21

Informtica 3

Roger S. Pressman
reconhecido
internacionalmente
como uma das
maiores autoridades
em engenharia de
softwares. Trabalha como
desenvolvedor, professor,
escritor e consultor.

Ana Regina Cavalcanti

da Rocha mestra e
doutora em Informtica;
atua na rea de Cincia
da Computao, com
nfase em Engenharia
de Software.

A terceira edio
do PMBOK - Guia
do Conjunto de
Conhecimentos em
Gerenciamento de
Projetos saiu em 2004.
uma publicao do PMI
(Project Management
Institute, o Instituto
de Gerenciamento de
Projetos, em portugus),
para identificar e
descrever as boas
prticas de projetos que
agreguem valor e sejam
fceis de aplicar.

captulo 1

Roger S. Pressman indica sete reas ou categorias potenciais de aplicao

de softwares em seu livro Engenharia de Software (PRESSMAN, 2006).
Para saber mais sobre essas sete reas, consulte o quadro abaixo.

desde a sua concepo at a sua extino. Logo, necessrio saber quanto tempo
o software ficar em funcionamento e quais os benefcios gerados durante esse
perodo, sempre tendo em mente o retorno do investimento (FOWLER, 2009).

1.4. Processo de desenvolvimento

crucial entender perfeitamente os entraves envolvidos no desenvolvimento de

um software. Embora no exista uma conduta padro, sempre bom partir do
princpio de que se est em busca de solues para os problemas do cliente.

Na rea de tecnologia da informao, desenvolvimento de sistemas significa o

ato de elaborar e implementar um programa, ou seja, entender as necessidades
dos usurios e transform-las em um produto denominado software, de acordo
com a definio de Ana Regina Cavalcanti da Rocha, no seu livro Qualidade
de Software: Teoria e Prtica (DA ROCHA, 2004).
Os processos de desenvolvimento so essenciais para o bom andamento do projeto de um software, assim como a compreenso do sistema como um todo.
Quanto mais aumenta a complexidade dos sistemas, mais difcil se torna a sua
visibilidade e compreenso, portanto, sem um processo bem definido o projeto
tem grande chance de insucesso.
O processo envolve atividades necessrias para definir, desenvolver, testar e
manter um software. Exige inmeras tentativas de lidar com a complexidade
e de minimizar os problemas envolvidos no seu desenvolvimento. E devem ser
levados em considerao fatores crticos: entrega do que o cliente deseja, com a
qualidade, o prazo e o custo acordados (PMI, 2004).
Para assegurar qualidade e padro aos projetos, devem ser seguidos modelos de
desenvolvimento de software: em cascata, iterativo ou incremental e prototipagem. Tambm importante levar em conta o ciclo de vida de um programa,

1.4.1. Objetivos
Definio: alinhar todas as atividades a executar no decorrer de todo o projeto
e, assim, desenvolver tudo o que foi previsto no seu escopo.
Planejamento: definir, em um cronograma, quando, como (quais os recursos
de hardware e de software necessrio) e quem ir realizar determinada tarefa.
Controle: ter sempre meios de saber se o cronograma est sendo cumprido e
criar planos de contingncia caso haja problemas no fluxo.
Padronizao: seguir as mesmas metodologias por todos os envolvidos no projeto para no haver dificuldades de entendimento.

As sete reas, por Pressman

Software bsico ou de sistema: conjunto de programas
desenvolvidos para servir a outros sistemas, como os
operacionais e os compiladores.
Sistemas de tempo real: programas que monitoram,
analisam e controlam eventos reais, no momento em
que ocorrem. Recebem informaes do mundo fsico
e, como resultado de seu processamento, enviam de
volta informaes de controle. Devem ter um tempo
determinado de resposta para evitar efeitos desastrosos.
Sistemas de informao: softwares da maior rea de
aplicao de sistemas, que engloba os programas de
gerenciamento e acesso a bases de dados de informaes
de negcio.

22

Com a definio de objetivos, atividades e participantes, consegue-se a excelncia no desenvolvimento de software, pois h gesto, controle e padronizao
do processo. Tudo isso diminui os riscos de problemas com cronograma, treinamento, qualidade e aceitao do sistema pelos usurios. Vejamos quais so os
objetivos, as atividades e os participantes.

Chad Fowler, autor de

vrios livros, um dos mais
competentes desenvolvedores
de software do mundo.
Trabalhou para vrias
das maiores corporaes
do planeta. Vive na
ndia, onde mantm um
centro internacional de
desenvolvimento.

Software de engenharia ou cientfico: sistemas utilizados em

reas como astronomia, anlise de resistncia de estruturas,
biologia molecular etc.
Sistemas embarcados ou software residente: programas
alojados nas ROM (Read-Only Memory, ou Memria Apenas de
Leitura) e que controlam sistemas de baixo nvel.
Software de quarta gerao: programas como processadores
de texto, planilhas eletrnicas, jogos, aplicaes financeiras e
acesso a bases de dados.
Software de inteligncia artificial (IA): sistemas que utilizam
algoritmos no numricos para resolver problemas complexos,
tambm conhecidos como sistemas baseados em conhecimento.

23

Informtica 3

captulo 1

Figura 1

1.4.2. Atividades

A imagem ao lado
mostra que o ciclo
de vida dos sistemas
informatizados pode
ser comparado ao
dos seres humanos.

Levantamento de requisitos: entender a necessidade do cliente e as regras do

seu negcio ( a fase mais importante do desenvolvimento).
Anlise de requisitos: definir o que fazer sob o ponto de vista de anlise de sistemas.
Projeto: desenvolver o sistema j com cronograma, necessidades e riscos preestabelecidos.
Implementao: comear a usar um novo processo.
Testes: analisar se todas as funcionalidades solicitadas pelo cliente no levantamento de requisitos esto funcionando corretamente.
Implantao: disponibilizar os processos para utilizao pelo usurio final.

1.4.3. Participantes
Gerentes de projeto: entram em contato com o cliente para levantar suas necessidades, assumindo a responsabilidade pelo cumprimento das fases de desenvolvimento e do cronograma.
Ichak Adizes
o criador da
metodologia que
leva seu nome e
visa ao diagnstico
e teraputica
para mudanas
organizacionais e
culturais. O mtodo
est sendo aplicado
com muito sucesso
em organizaes
de 30 mil a 90 mil
empregados de
diversos pases.

Analistas de sistema: elaboram o projeto do sistema, utilizando UML (Unified Modeling Language, ou Linguagem de Modelagem Unificada), ferramentas de modelagem de processos, tcnicas de anlises de sistemas e tcnicas
de projetos de sistemas.
Arquitetos de software: definem a arquitetura em que o sistema funcionar
(web, Windows, Linux etc.), com conhecimento dos pontos fortes e fracos de
cada ambiente de acordo com as necessidades do cliente.
Programadores: codificam, em linguagem de programao, os requisitos do
sistema, elaborados pelo analista de sistemas nos modelos UML.
Clientes: solicitam o desenvolvimento em entrevistas durante as quais sero
definidos os requisitos do sistema.
Avaliadores de qualidade: realizam os testes do sistema, utilizando ou no
ferramentas como o JTest.

1.5. Modelo de ciclo de vida

O ciclo de vida, em sistemas informatizados, tem as mesmas etapas do ciclo de vida
de um ser humano (ADIZES, 1999) (figura 1). O namoro considerado o primeiro
estgio do desenvolvimento, quando o sistema ainda nem nasceu e existe apenas
como uma ideia. Ainda no existe fisicamente, apenas uma possibilidade. Trata-se,
portanto, de um perodo em que se fala muito e se age pouco. O analista de sistemas
tem, nessa etapa, uma funo muito importante: entender o que o cliente deseja e, a
partir da, criar um compromisso com ele.
24

J a fase da infncia, tambm chamada de sistema-criana, conta com poucos

controles formalizados e muitas falhas a serem transformadas em virtudes. Normalmente, o sistema precrio, faltam registros e informaes, h resistncia
das pessoas em fazer reunies de aprimoramento. Alguns chegam a acreditar
que o sistema no vai funcionar.
A adolescncia o estgio do renascimento. Nessa etapa, ainda conforme Adizes, eliminada grande parte dos erros encontrados na fase anterior. Essa transio caracterizada por conflitos e inconsistncias, muitas vezes causados pelos
prprios usurios, os quais ainda no se comprometem a realizar as interaes
pertinentes. Mesmo percebendo a necessidade de delegar autoridade, mudar
metas e liderana, os responsveis enfrentam dificuldades, pois muitos usurios
ainda acreditam que o antigo sistema era melhor.
A estabilidade, ou fase adulta, o incio do estgio de envelhecimento do sistema, ou seja, quando comea a se tornar obsoleto e surgem outros melhores. Um
sintoma bem visvel a perda de flexibilidade. Todos comeam a achar que ele
no funciona to bem, atribuindo-lhe falhas. um estgio marcado pelo fim do
crescimento e incio do declnio.
A aristocracia tambm batizada de meia-idade ou melhor idade a fase da
vaidade, do vestir-se bem e de falar bem. Maria Aparecida Maluche explica que
a nfase est em como as coisas so feitas e no no porqu (MALUCHE, 2000).
25

Informtica 3

captulo 1

a que se inicia a etapa de declnio total do sistema, na qual o nvel de inovao

baixo e tudo deixa a desejar.
Na fase da burocracia, ou velhice, o sistema perde a funcionalidade e a elasticidade. Com isso, ningum mais tem confiana nele. Muitos percebem a
situao, mas ningum faz nada, culpando o sistema por todos os erros e
falhas na organizao. O declnio se intensifica e, mesmo que permanea
em uso por alguns anos, a decadncia prossegue, at a morte do sistema
(ADIZES, 1999).
As agendas ficam superlotadas, comea-se a perder o controle de prazos e de
qualidade. Ao mesmo tempo que se assume muitos compromissos, comete-se
falhas. Por isso, deve-se ficar atento s reclamaes dos clientes e tentar, de qualquer maneira, atender s necessidades percebidas.

A sequncia de etapas
1. Definio dos objetivos: finalidade do projeto e sua inscrio
dentro de uma estratgia global.
2. Anlise das necessidades e viabilidade: identificao, estudo e
formalizao do que o cliente precisa e do conjunto de entraves.
3. Concepo geral: elaborao das especificaes da arquitetura
geral do software.
4. Concepo detalhada: definio precisa de cada subconjunto do
software.
5. Codificao, aplicao ou programao: traduo em linguagem
de programao das funcionalidades definidas nas fases de
concepo.
6. Testes unitrios: verificao individual de cada subconjunto
do software, aplicados em conformidade com as especificaes.

O ciclo de vida de um software (software lifecycle) designa todas as etapas do seu desenvolvimento, da concepo extino. Essa segmentao tem por objetivo definir
pontos intermedirios que permitam checar a conformidade do sistema com as necessidades expressas no escopo do projeto e verificar o processo de desenvolvimento.
Segundo Ana Regina Cavalcanti da Rocha, em geral o ciclo de vida do software
compreende, no mnimo, onze atividades (DA ROCHA, 2004). A sequncia e a
presena de cada uma delas no ciclo de vida dependem da escolha do modelo a ser
adotado pelo cliente e pela equipe de desenvolvimento.
Os modelos de ciclo de vida descrevem as etapas do processo de desenvolvimento
de software, assim como as atividades a serem realizadas em cada uma delas. A
definio desses estgios permite estabelecer pontos de controle para a avaliao
da qualidade e da gesto do projeto. Veja o quadro A sequncia das etapas.

1.5.1. Modelo em cascata ou waterfall

Cascata ou waterfall (em ingls) um dos mais simples e conhecidos modelos
para o desenvolvimento de software. Criado em 1966 e formalizado em 1970,
tem como principais caractersticas (FOWLER, 2009):
Projetos reais raramente seguem um fluxo sequencial.
Assume que possvel declarar detalhadamente todos os requisitos antes do
incio das demais fases do desenvolvimento (podendo ter a propagao de
erros durante as fases do processo).
Uma verso de produo do sistema no estar pronta at que o ciclo de desenvolvimento termine.
As fases so executadas sistematicamente, de maneira sequencial, conforme sugere a figura 2.
Figura 2
As fases
sequenciais
do Modelo
cascata.

7. Integrao: certificao e documentao da intercomunicao

dos diferentes elementos (mdulos) do software.
8. Qualificao ou receita: checagem da conformidade do software
s especificaes iniciais.
9. Documentao: registro das informaes necessrias para
a utilizao do software e para desenvolvimentos anteriores.
10. Produo: colocao do sistema em operao para o cliente.
11. Manuteno: aes corretivas (manuteno corretiva)
e evolutivas (manuteno evolutiva) no software.

26

27

Informtica 3

captulo 1

Figura 3

Requerimento (Anlise e Definio de Requisitos): as funes, as restries e os

objetivos do sistema precisam ser definidos, via consulta aos usurios, para que
sejam elaborados os detalhes especficos.

O modelo
evolucionrio.

Projeto (Sistemas e Software): o processo deve agrupar os requisitos de hardware e software, assim como identificar e descrever as abstraes fundamentais do
sistema e as suas relaes.
Implementao (Testes de Unidade): o projeto posto prova como um conjunto de programas ou de suas partes , com o teste de cada item, para verificar se aquela unidade atende sua especificao.
Verificao (Integrao e Teste de Sistemas): antes da entrega do software ao cliente,
as unidades ou programas individuais so integrados e testados como um sistema
completo, de maneira a assegurar que todos os requisitos estejam contemplados.
Manuteno (Operao): o sistema instalado e colocado em operao, sendo
detectados e corrigidos erros no descobertos antes, o que melhora a implementao e tambm permite descobrir novos requisitos.
O sistema s entregue ao usurio depois que os desenvolvedores observarem
um resultado satisfatrio na fase de verificao, com certo grau de confiana.
Mesmo assim, o software ainda poder ter alteraes, principalmente para correo de falhas que s os usurios conseguem detectar no dia a dia e tambm
para mais bem adapt-lo ao ambiente ou ainda por problemas de desempenho.
Se houver transformaes no negcio da empresa, tambm ser preciso realizar
mudanas. A manuteno do software (ltima etapa proposta pelo modelo em
cascata) pode requerer, portanto, voltar a atividades das fases anteriores do ciclo.
desse jeito que se garante a melhoria contnua do produto.

1.5.2. Modelo em cascata evolucionrio ou waterfall evolucionrio

As metodologias baseadas no modelo waterfall presumem que uma atividade
deve ser concluda antes do incio da prxima. Devido s limitaes, houve reflexes no sentido de utilizar o modelo de maneira mais flexvel. Assim, em uma
situao extrema, aconteceriam simultaneamente todas as atividades do ciclo
de vida em cascata, enquanto em outra circunstncia tambm limite haveria
o uso da abordagem sequencial, ou seja, concluir inteiramente uma fase antes
de partir para a seguinte (FOWLER, 2009). A proposta evoluir com base em
prottipo inicial (figura 3). fundamental que os requisitos sejam muito bem
compreendidos. Mesmo com uma completa viso das especificaes iniciais,
preciso trabalhar com o cliente durante todo o desenvolvimento. Todos os conceitos e ideias vo sendo materializados em requisitos, durante o processo, at
que se chegue ao produto idealizado.
Conceitos e ideias vo sendo materializados, medida que o trabalho evolui, at
chegar ao produto desejado. O objetivo trabalhar com o cliente durante toda
a fase de desenvolvimento, com os requisitos muito bem compreendidos. Entre
as vantagens dessa abordagem esto a possibilidade de antecipar o produto final
para avaliao do cliente, de manter uma comunicao entre os desenvolvedores
28

e usurios para solucionar problemas tcnicos e de comear precocemente o treinamento dos usurios. Isso antes de concluir as suas diferentes verses (inicial,
intermediria e final), com espao para readequaes devidamente avalizadas
pelo usurio. O modelo se baseia, ento, no conceito da implementao inicial,
cujo resultado analisado e comentado pelo usurio. A partir desse feedback,
o sistema aprimorado por meio de muitas verses, at o seu desenvolvimento
completo. A especificao, o desenvolvimento e a validao so executados concomitantemente para possibilitar um retorno rpido.
A abordagem mais radical do ciclo de vida em cascata aquela em que todas
as atividades se desenvolvem paralelamente, desde o incio do projeto. Ao contrrio, a mais conservadora a que preconiza completar toda atividade N antes
de iniciar a prxima N + 1. Mas h um nmero infinito de opes entre esses
extremos. Segundo Edward Yourdon, a escolha entre as diversas possibilidades
disponveis depende de uma srie de variveis como possvel ver no quadro
abaixo, que incluem do nvel de estabilidade do usurio s exigncias de produo (YOURDON, 1995).

Edward Yourdon
desenvolvedor
de metodologias
de engenharia
de software,
alm de autor
de 25 livros sobre
computadores,
incluindo bestsellers.

Variveis de Yourdon
Nvel de estabilidade do usurio: se ele
instvel ou inexperiente e no sabe definir
suas reais necessidades, preciso usar uma
abordagem mais radical.
Nvel de urgncia na produo
de resultados tangveis e imediatos:
se o prazo curto, por questes
polticas ou outras presses externas,
justifica-se assumir uma abordagem
radical. Nesse caso, prefervel ter 90%
do sistema completo na data especificada

do que 100% das etapas de anlise

e projeto.
Exigncias para a produo de
cronogramas, oramentos, estimativas
etc.: a maior parte dos grandes projetos
requer estimativas de pessoal, recursos
de computao e outros detalhes, e tudo
isso depende de levantamento e anlise.
Portanto, quanto mais detalhadas e precisas
forem as estimativas, provvel que seja
necessria uma abordagem conservadora.

29

Informtica 3

captulo 1

1.5.3. Modelo incremental

1.5.4. Modelo iterativo

O modelo incremental resulta da combinao do linear (em cascata) com o de

prottipos (evolutivo). O seu desenvolvimento dividido em etapas, denominadas incrementos, os quais conduzem aos aprimoramentos necessrios, at que
se chegue verso final (FOWLER, 2009). Em cada incremento ocorre todo o
ciclo de desenvolvimento de software, do planejamento aos testes. Por essa razo, ao final de uma etapa, j possvel obter um sistema totalmente funcional,
embora no contemple todos os requisitos do produto final (figura 4).

O mtodo iterativo foi criado tambm com base nas vantagens e limitaes dos
modelos em cascata e evolutivo. Mantm a ideia principal do desenvolvimento
incremental, com o acrscimo de novas capacidades funcionais, a cada etapa,
para a obteno do produto final. No entanto, segundo Fowler, modificaes
podem ser introduzidas a cada passo realizado. Mais informaes sobre o modelo interativo no quadro abaixo.

Entre as vantagens dessa metodologia est justamente a possibilidade de definir melhor os requisitos, que muitas vezes no ficam muito claros no incio
do processo. O primeiro passo trabalhar o ncleo do sistema, ou seja, so
implementados os requisitos bsicos, sem os detalhes. Em seguida o produto
avaliado pelo usurio, para a deteco de problemas iniciais, os quais j podem ser corrigidos, caso contrrio poderiam assumir grandes propores ao
surgirem apenas na verso final. Outro benefcio o fato de o cliente esclarecer os requisitos e as prioridades para os prximos incrementos, alm de poder
contar com as facilidades da verso j produzida. Assim, com a construo de
um sistema menor (sempre muito menos arriscada do que o desenvolvimento
de um sistema grande), se um grave erro cometido, ou se existe uma falha
no levantamento de requisitos, somente o ltimo incremento descartado.
Ganha-se em performance, pois so mnimas as chances de mudanas bruscas
nos requisitos, e em tempo de desenvolvimento.
Figura 4
O modelo
incremental.

Uma iterao de desenvolvimento abrange as atividades que conduzem at uma

verso estvel e executvel do software. Por esse motivo, pode-se concluir que
ela passa pelo levantamento de requisitos, desenvolvimento, implementao e
testes. Ou seja, cada iterao como um miniprojeto em cascata no qual os
critrios de avaliao so estabelecidos quando a etapa planejada, testada e
validada pelo usurio.
Um dos principais ganhos com a adoo desse modelo a realizao de testes em
cada nvel de desenvolvimento (bem mais fcil do que testar o sistema apenas
na sua verso final). Isso pode fornecer ao cliente informaes importantes que
serviro de subsdio para a melhor definio de futuros requisitos do software.

Passos do modelo iterativo

1. implementao inicial
desenvolver um subconjunto
da soluo do problema global
contemplar os principais aspectos
facilmente identificveis em relao
ao problema a ser resolvido

Levantamento
de requisitos

Desenvolvimento

2. lista de controle de projeto

Implementao
descrever todas as atividades
para a obteno do sistema
final, com definio
Testes
de tarefas a realizar
a cada iterao
gerenciar
o desenvolvimento
Implantao
inteiro para medir,
em determinado nvel,
o quo distante se est da ltima iterao
3. iteraes do modelo
retirar cada atividade da lista de controle de projeto
com a realizao de trs etapas: projeto, implementao
e anlise
esvaziar a lista completamente

30

31

Informtica 3

captulo 1

Figura 5

1.6.1. Atividades do gerenciamento de riscos

O modelo espiral.

Barry W. Boehm
considerado um guru
da Universidade do Sul
da Califrnia, da qual
professor emrito,
e tem lugar garantido
entre os estudiosos que
mais influenciaram o
pensamento econmico
a respeito de software
nos ltimos 40 anos. Ele
se graduou em Harvard
em 1957, mestre e Ph.D.
em Matemtica e foi
diretor do Software and
Computer Technology
Office do Departamento
de Defesa dos Estados
Unidos. Desde 1964
Boehm escreveu seis
livros, entre eles Software
Risk Manager, publicado
pela IEEE Computer
Society Press em 1989.

O PMBOK define Gerncia

de Risco como todos os
processos necessrios
para identificar, analisar,
responder, monitorar
e controlar os riscos
de um projeto. E Dalton
Valeriano, no seu livro
Moderno Gerenciamento
de Projetos, refora
o conceito ao afirmar
que essa gesto deve
ser constante durante
todo o projeto, tendo
como objetivos maximizar
a probabilidade de
riscos favorveis e
minimizar os negativos
(VALERIANO, 2005).

32

Segundo o PMBOK, 2004, o processo de gerenciamento de riscos para desenvolvimento de software composto por quatro atividades (figura 6):
1. Identificao dos riscos: reconhecimento do projeto, do produto e dos riscos
de negcio envolvidos no desenvolvimento do software.
2. Anlise dos riscos: estudo das possibilidades e das consequncias da ocorrncia dos riscos, com determinao de valores qualitativos para as possibilidades (muito baixo, baixo, moderado, alto e muito alto) e para as consequncias (insignificante, tolervel, srio e catastrfico).
3. Planejamento do risco: medio de cada risco e desenvolvimento de uma
metodologia de gerenciamento dentre algumas opes: refutar o risco quando
a probabilidade reduzida; minimizar o risco quando h baixo impacto no
projeto de desenvolvimento de software ou no produto final; ou planos de
contingncia para eliminar o risco quando eles se tornarem realidade.
4. Monitoramento do risco: identificao e avaliao regular de cada risco para
tomada de deciso quanto diminuio, estabilidade ou aumento da possibilidade de ocorrncia do evento; assim como discusso em cada reunio de avaliao do progresso do projeto sobre a permanncia efetiva dos esforos para
manter cada risco sob controle.

1.5.5. Modelo espiral

Criado por Barry Boehm, em 1988, o modelo espiral (figura 5) permite que as
ideias e a inovao sejam verificadas e avaliadas constantemente. Isso porque,
a cada interao, existe a volta da espiral que pode ser baseada em um modelo
diferente e pode ter diferentes atividades. Esse padro caracteriza-se, portanto,
pelo desenvolvimento em sequncia, aumentando a complexidade do processo
conforme se chega mais prximo do produto final.

Figura 6
Atividades do
processo de
gerenciamento
de riscos.
Identificao
do risco

Anlise
do risco

Planejamento
do risco

Monitoramento
do risco

Lista dos riscos

potenciais

Lista dos riscos

priorizados

Planos de
contingncia e de
tratamento
dos riscos

Avaliao dos
riscos

Em cada ciclo da espiral, uma srie de atividades realizada em uma determinada ordem, como comunicao com o cliente, planejamento, anlise de riscos
e avaliao dos resultados (FOWLER, 2009).
O modelo espiral cclico. Considerado um metamodelo, abrange diferentes
padres, desde o cascata at vrios tipos de prottipos. Com isso, possvel prever os riscos e analis-los em vrias etapas do desenvolvimento de software.

1.6. Riscos
O risco do projeto um evento ou uma condio incerta que, se ocorrer, ter
um efeito positivo ou negativo sobre, pelo menos, um objetivo do projeto, como
tempo, custo, escopo ou qualidade. E o modelo espiral foi a primeira proposta
de incluso de Gerncia de Risco no ciclo de vida de desenvolvimento de software.
A interatividade e os riscos, portanto, so as suas principais caractersticas
(PMBOK, 2004). Alis, como bem lembra Tom Gilb: Se voc no atacar os
riscos [do projeto] ativamente, ento estes iro ativamente atacar voc.

33

Informtica 3

captulo 1

Para facilitar o
desenvolvimento de um
software, podem ser utilizadas
ferramentas que auxiliem na
construo de modelos, na
integrao do trabalho de
cada membro da equipe, no
gerenciamento do andamento
do desenvolvimento etc. Os
sistemas utilizados para dar
esse suporte so normalmente
chamados de CASE, sigla
em ingls para ComputerAided Software Engineering
(Engenharia de Software de
Suporte Computacional). Alm
dessas ferramentas, outros
instrumentos importantes
so aqueles que fornecem
suporte ao gerenciamento,
como desenvolvimento de
cronogramas de tarefas,
definio de alocaes de
verbas, monitoramento
do progresso e dos gastos,
gerao de relatrios de
gerenciamento etc.

1.7. Prototipagem
Fazer um prottipo de software garante a possibilidade de examinar antecipadamente os requisitos do programa (figura 7). Ou seja, desenvolve-se um exemplar
simplificado, de forma rpida, para que as questes relativas a requisitos sejam entendidas ou esclarecidas. Com ele possvel melhorar muito a comunicao com o
cliente, pois, primeiramente, ele ouvido e, ento, feito um desenho e a construo
do modelo. E s depois de cumpridas essas trs tarefas que se d a validao, o que
aumenta, em muito, as chances de sucesso do projeto (FOWLER, 2009).
Portanto, ao criar um prottipo, previnem-se possveis deficincias no projeto
de desenvolvimento de software. Em um nmero grande de casos, o usurio
fica insatisfeito com o produto acabado. Isso ocorre por no ter havido troca de
informao suficiente entre cliente e desenvolvedor. A comunicao no levantamento de requisitos falha. Um prottipo deve ser utilizado como instrumento
de anlise, com a finalidade de superar as dificuldades de comunicao existentes entre o analista de sistemas e o usurio do sistema.
A prototipagem uma tcnica que pode ser empregada em pequenos ou grandes sistemas, em que os requisitos no esto claramente definidos. Seu uso aconselhavel em
projetos para os quais o usurio no saiba exatamente o que deseja (FOWLER, 2009).
Alguns fatores devem ser levados em conta. Um prottipo um esboo de alguma
parte do sistema e a prototipagem uma tcnica complementar anlise de requisitos,
com o objetivo de assegurar que as demandas foram bem entendidas. J a construo desses prottipos utiliza ambientes com facilidades para a construo de interface

Figura 7
As fase da
prototipagem.

uto

C
do on s t r
pro u
t t o
ipo

En

ge n

do

h ar

pi

ia d

or

op

je t

rod

Pro

Fi m

Coleta e refinamento
dos requisitos

o
e nt
a m po
fin ti
Re prot
do

34

Essa tcnica frequentemente aplicada quando existem dificuldades no entendimento dos requisitos do sistema e/ou quando existem requisitos que precisam
ser mais bem entendidos.
Aps o Levantamento de Requisitos (LR) tema do prximo tpico deste
livro , um prottipo j pode ser construdo e usado na validao. Os usurios
fazem suas crticas e so feitas correes. Esse processo de reviso e refinamento
continua at que o sistema seja aceito pelos usurios. A partir da, descartado
ou utilizado apenas como uma verso inicial do sistema.
Importante: a prototipagem no substitui a construo de modelos do sistema.
Trata-se de uma tcnica complementar. E os erros detectados na sua validao
devem ser utilizados para modificar e refinar o programa.

1.8. Levantamento ou especificao de requisitos

Obter qualidade nos processos e produtos de engenharia de software no uma
tarefa fcil, pois so vrios os fatores que dificultam o alcance desse objetivo.
No entanto, nada mais decepcionante do que desenvolver um sistema que no
satisfaa as necessidades dos clientes. Grandes volumes de recursos so gastos e,
em muitos casos, os clientes sentem-se frustrados com a verso final do software
encomendado. Muitos desses problemas so derivados da falta de ateno na
hora de definir e acompanhar a evoluo dos requisitos durante o processo de
construo do sistema (DA ROCHA, 2004).
Por esse motivo, necessrio realizar o levantamento dos requisitos do sistema. As funcionalidades e os recursos devem ser definidos pelo usurio do
sistema, isto , pela pessoa da empresa que necessita de um programa para
solucionar um determinado problema. Ento, fica claro que o usurio est no
centro de levantamento de requisitos do software. quem conhece as necessidades a serem supridas pelo sistema e, por isso, precisa ser informado de sua
importncia no processo.

Incio

Avaliao do prottipo
pelo cliente

grfica, ento alguns SGBDs (Sistemas Gerenciadores de Banco de Dados) tambm

fornecem ferramentas para a concepo de telas de entrada e sada de dados.

A falta de cuidado com o levantamento dos requisitos de um sistema pode gerar

problemas muito srios, como: resoluo de um problema errado ou de forma
errada; funcionamento diferente do esperado; complexidade na utilizao e entendimento por parte dos usurios e alto custo (SWEBOK, 2004 Guide to the
Software Engineering Body of Knowledge). Tudo isso mostra a importncia de
empregar bem o tempo para entender o problema e seu contexto e obter, assim,
os requisitos certos na primeira vez.

1.8.1. O que um requisito

Requisito a condio ou a capacidade que um sistema deve atender. Segundo
uma das normas padres do IEEE (1220, de 1994), um requisito uma sentena identificando uma capacidade, uma caracterstica fsica ou um fator de
qualidade que limita um produto ou um processo. Isso significa uma condio
35

Informtica 3

captulo 1

ou uma capacitao que um produto (no caso, um software) ou um servio

precisa atender ou ter para satisfazer um contrato, um padro, uma especificao ou outro documento formalmente estabelecido entre as partes.
Os requisitos esto associados aos principais problemas do desenvolvimento de
software, pois, quando no refletem as reais necessidades dos usurios, esto incompletos e/ou inconsistentes. Existem mudanas em requisitos j acordados, e a
dificuldade para conseguir um entendimento entre usurios e executores um dos
principais problemas relatados, capaz de provocar retrabalho e, consequentemente, atrasos no cronograma, custos acima do oramento e insatisfao do cliente
(SWEBOK, 2004). Veja as categorias de requisitos no quadro abaixo.

Verificvel: no vago nem genrico e deve ser quantificado para permitir

a verificao de uma das seguintes formas: inspeo, anlise, demonstrao
ou teste.
Conciso: para no gerar confuso, cada requisito define, de maneira clara e simples, apenas uma nica exigncia a ser desenvolvida. Para ser conciso, o requisito
no inclui explicaes, motivaes, definies ou descries do seu uso. Tais
detalhes podem estar em outros documentos.

Caractersticas

Alcanvel: realizvel a um custo definido.

Os requisitos tambm so agrupados por suas caractersticas, em uma gama que

inclui desde os necessrios aos concisos e completos, entre outros.

Completo: no precisa ser explicado ou aumentado, garantindo capacidade suficiente do sistema.

Necessrio: indica que, se retirado, haver uma deficincia no sistema. Isto

, o programa no atender plenamente s expectativas do usurio. No
deve haver requisitos que seriam apenas interessantes, caso existissem. Ou
o requisito necessrio ou dispensvel. Deve ser levado em considerao
que cada requisito aumenta a complexidade e o custo do projeto, logo, no
podem ser introduzidos de forma espria.

Consistente: no contradiz nem mesmo duplica outro requisito e utiliza os

termos na mesma forma que a adotada nos outros requisitos.

Categorias de requisitos
Funcionais: descrevem as funcionalidades e os servios do
sistema e dependem do tipo de software a ser desenvolvido,
do nmero de usurios esperado e do padro do sistema no
qual o programa ser utilizado. Exemplos: o sistema deve
oferecer diversas maneiras de visualizar os dados, de acordo
com o perfil do usurio; os relatrios devem estar disponveis
para impresso de acordo com o nvel hierrquico de cada
usurio etc.

36

No ambguo: tem apenas uma interpretao. muito importante prestar

ateno na linguagem utilizada para no causar duplo entendimento.

Ordenvel: tem uma ordem por estabilidade, importncia ou ambos.

Aceito: acolhido pelos usurios e desenvolvedores.

Tipos

Seja qual for o sistema, h vrias formas de atend-lo.

Dependendo das necessidades que se apresentam existem vrios
tipos de requisito:

Dicas para
a escrita

Algumas tcnicas para

escrever requisitos de
software:
Preferir sentenas curtas.
Utilizar verbos no futuro.
Para cada requisito, avaliar
se a definio determina
se esse requisito est
pronto ou no.
Garantir que todos
os requisitos podem
ser verificveis e o modo
de fazer essa verificao.
Verificar os requisitos
agregados ou interrelacionados.
Estabelecer sempre
o mesmo nvel de
detalhamento em
todos os requisitos.

Do usurio: a caracterstica ou o comportamento que o usurio

deseja para o software ou para o sistema como um todo. So
descritos pelo prprio usurio ou por um analista de sistemas,
a partir de um levantamento de dados com o cliente.

No funcionais: definem as propriedades e as restries do

sistema, podendo especificar, por exemplo, quais linguagens de
programao, bancos de dados e mtodos de desenvolvimento
sero utilizados. So mais crticos do que os requisitos funcionais,
pois sua definio correta influencia diretamente a performance
do sistema a ser desenvolvido.

Do sistema: comportamento ou caracterstica que se exige

do sistema como um todo, incluindo hardware e software.
So normalmente levantados por engenheiros de software ou
analistas de sistemas, que devem refinar os requisitos dos usurios,
transformando-os em termos de engenharia de software.

De domnio: originam-se do domnio da aplicao do sistema e

refletem as suas caractersticas desse domnio. Podem ser requisitos
funcionais ou no funcionais; requisitos funcionais novos; restries
sobre requisitos existentes ou sobre computaes especficas.

Do software: comportamento ou caracterstica exigido do software.

So normalmente levantados por analistas de sistemas com o
objetivo de comparar todos os requisitos com aqueles que possuem
real relevncia.

37

Informtica 3

captulo 1

Figura 8

1.8.4. Documentao de requisitos

Imprimir a
Nota Fiscal.

A documentao de requisitos uma atividade crucial para a engenharia de

software, pois o documento gerado nessa fase uma descrio oficial dos requisitos do sistema para cliente, usurios e desenvolvedores. Isso significa que
todos os envolvidos no processo se basearo nesse documento para o desenvolvimento do sistema. Tal documento deve trazer muitas designaes: especificao funcional, definio, especificao e responsveis pelo requisito
(FOWLER, 2009).

Exemplos de
requisitos

1. O programa deve
imprimir nota fiscal
e fazer a integrao
com o sistema da
Nota Fiscal Paulista e
de vendas registradas
(figura 8).

Ao documentar um requisito, deve-se ter em mente algumas questes que podem influenciar, em muito, todo o processo de desenvolvimento. necessrio se
preocupar com a boa qualidade do documento, e alguns cuidados precisam ser
observados no modo de escrever.
1. Quem escreve, para quem se escreve e qual o meio utilizado para escrever
so trs fatores diretamente relacionados qualidade da documentao dos
requisitos.

2. O software deve
cadastrar novos
produtos, gerar
relatrios de
vendas etc.
3. O sistema deve
permitir a realizao
de vrios oramentos
e anlise, levando
em considerao
a condio de
pagamento e o
prazo de entrega.

Por exemplo,
impossvel
fazer um relatrio
de vendas sem
registr-las
previamente no
sistema: o requisito
predecessor
ao relatrio de
vendas o registro
das vendas.

38

Quando um requisito for funcional, dever ser tambm:

Independente da implementao: define o que deve ser feito, mas no como
deve ser feito.

1.8.2. Como devemos escrever requisitos

Normalmente as especificaes de requisitos so escritas em linguagem natural (ingls ou portugus, por exemplo). Devem ser utilizadas tcnicas de padronizao para formato, estilo de linguagem e organizao das informaes.
Tudo isso facilita a manipulao desse conjunto de requisitos.

2. A adoo de linguagem natural no tcnica no texto, complementada

por diagramas, tabelas, fotos e imagens, facilita o entendimento daquilo que se
deseja documentar.
3. O grau de detalhamento depende de quem escreve, da organizao das informaes, do propsito da documentao, entre outros quesitos.
4. A documentao serve para comunicar o que se pretende fazer em um
determinado sistema e se ele se dirige a clientes, usurios, gestores e desenvolvedores do sistema.
5. A especificao tem de trazer os servios que o sistema deve prestar, assim
como suas propriedades e restries impostas operao e ao desenvolvimento.

1.8.3. Dependncia de requisitos

6. O documento pode ser tanto sucinto e genrico quanto extenso e detalhado.

Os requisitos no so independentes uns dos outros. E a maioria deles s

pode ser implementada se outros forem implantados antes (eis o conceito de
requisitos predecessores). Uma das atividades mais importantes da gerncia
de requisitos manter esse relacionamento de dependncia, que influenciar
todo o processo de desenvolvimento do sistema. Para isso existem algumas solues possveis, como manter uma tabela de dependncia de requisitos ou manter
um banco de dados de requisitos que inclua relaes de dependncia. Existem
alguns produtos no mercado especializados na gerncia de requisitos que administram essas dependncias.

1.8.5. Mtodos de identificao e coleta

fundamental ter uma atuao constante e muito prxima aos usurios para
que qualquer divergncia em relao a requisitos ou a adaptaes seja facilmente detectada e corrigida. Mas para tanto os usurios precisam estar comprometidos com o desenvolvimento do sistema e se sentirem donos dele. Se
isso no ocorrer, h grandes probabilidades de o sistema no ser um sucesso.

JAD (Joint
Application
Development)
um sistema de
desenvolvimento de
aplicaes em grupo
criado pela IBM. O
objetivo reduzir
custos e aumentar
a produtividade
nesses processos.

Existem duas tcnicas normalmente utilizadas para a identificao e coleta de

requisitos: entrevista e reunies de JAD, aquelas das quais participam usurios e
analistas, para trabalhar na arquitetura de uma determinada aplicao. Ambas
so consideradas as melhores prticas.

1.8.5.1. Entrevista
Entre as tcnicas mais importantes de identificao de requisitos est a entrevista, tambm presente em outras metodologias, pois, quase sempre, a coleta
de informaes exige a comunicao direta com os usurios e interessados. Tem
como finalidade captar o pensamento do cliente para que se entenda o que
necessrio desenvolver. Por essa razo, o entrevistador tem grande responsabilidade. Alm de fazer as entrevistas, cabe a ele integrar diferentes interpretaes,

Existem formas
distintas de
entrevista: por
questionrio,
aberta e
estruturada.

39

Informtica 3

captulo 1

Figura 9

objetivos, metas, estilos de comunicao e terminologias adequadas aos diversos

nveis culturais dos entrevistados.

O sucesso
da entrevista
depende da
escolha da
pessoa certa
para oferecer
as respostas
precisas.

Por questionrio

Uma das principais dificuldades que envolvem esse trabalho o fato de as

palavras possurem significados distintos para pessoas diversas em contextos
diferentes (culturais e educacionais, por exemplo). Em conversaes corriqueiras, tais dificuldades de interpretao so esclarecidas naturalmente, mas, em
entrevistas com questionrios, o treinamento e o mtodo utilizados probem
essa interao. Por outro lado, tudo isso garante menos ambiguidade, uma das
principais vantagens da entrevista por questionrio.

Entrevista aberta
A entrevista aberta supre muitas das lacunas dos questionrios, porm gera
outros problemas. O entrevistador formula uma pergunta e permite ao
entrevistado responder como quiser. Mesmo que o primeiro tenha a liberdade de pedir mais detalhes, no h como determinar exatamente o
escopo da entrevista. Por isso essa tcnica pode gerar dvidas: as perguntas
podem ser de fato respondidas ou a resposta faz parte do repertrio normal
do discurso do entrevistado? Existem muitas coisas que as pessoas sabem
fazer, mas tm dificuldade para descrever, assim como h o conhecimento
tcito, de difcil elucidao.
Os benefcios das entrevistas abertas so a ausncia de restries, a possibilidade
de trabalhar uma viso ampla e geral de reas especficas e a expresso livre do
entrevistado. H desvantagens tambm. A tarefa difcil e desgastante, mas
entrevistador e entrevistado precisam reconhecer a necessidade de mtua colaborao para que o resultado seja eficaz.

40

Taxi/Getty Images

O questionrio muito usado como tcnica de entrevista, principalmente em

pesquisas de mercado e de opinio. Sua preparao exige bastante cuidado,
e alguns aspectos particulares do processo merecem destaque: emprego de
vocabulrio adequado para o pblico entrevistado; incluso de todos os contedos relevantes e de todas as possibilidades de resposta; ateno aos itens
redundantes ou ambguos, contendo mais de uma ideia ou no relacionados
com o propsito da pesquisa; redao clara e execuo de testes de validade e
de confiabilidade da pesquisa.

nhecimento e habilidade do especialista; percepo de expresses no verbais;

sensibilidade s diferenas culturais; cordialidade e cooperao.

Entrevista estruturada
A entrevista estruturada (figura 9) tem por finalidade coletar e organizar as
informaes sobre questes especficas, necessrias para o projeto. fundamental realizar a entrevista com a pessoa certa, ou seja, quem realmente entende e
conhece o negcio e os seus processos. E preparar muito bem o roteiro do que se
quer obter, aprofundando o assunto.
A principal vantagem dessa tcnica a obteno de respostas diretas com
informaes detalhadas. Todavia, como desvantagem, muitas vezes aspectos
relevantes ao projeto de desenvolvimento de software precisam ser identificados antes da realizao da entrevista. De maneira geral, requer muito mais
trabalho prvio e, quanto melhor for feito, maiores sero as chances de realizar
esse trabalho com eficcia.

Preparao

Tambm deve-se levar em conta a falta de procedimentos padronizados para

estruturar as informaes recebidas durante as entrevistas, uma vez que a anlise dos dados obtidos no trivial. difcil ouvir e registrar simultaneamente:
alguns fatos s tomam determinada importncia depois de outros serem conhecidos e, a, o primeiro pode no ter sido registrado. Por isso vale gravar toda a
conversa e transcrev-la, o que facilita a tarefa de selecionar e registrar o que
relevante para validar com o entrevistado posteriormente.

Para tudo que se faz na vida preciso se preparar. Em relao s entrevistas

no diferente. Deve-se elaborar um roteiro coerente ao alcance dos objetivos do projeto e informar ao entrevistado tanto o propsito da conversa
quanto sua importncia no processo. Selecionar o entrevistado outro ponto de ateno, pois somente ao final das entrevistas ser possvel ter uma
viso clara e completa do problema a ser solucionado e das diversas formas
de analisar e resolver.

O relacionamento entre os participantes de uma entrevista deve ser baseado

no respeito mtuo e em algumas outras premissas, tais como deferncia ao co-

A linguagem precisa se adequar ao entrevistado, levando em considerao seu

perfil cultural e tomando muito cuidado com a utilizao de termos tcnicos,
41

Informtica 3

captulo 1

muitas vezes corriqueiros para o entrevistador, mas eventualmente desconhecidos pelo respondente. s vezes, por vergonha, essa pessoa no admite que no
sabe do que se trata e responde de maneira equivocada. Da a importncia da
coerncia das perguntas e de observar, com ateno, o real entendimento dos
entrevistados. Mais um ponto a cuidar: a programao e o cumprimento dos
horrios estabelecidos.

Realizao
O objetivo central de uma entrevista conseguir informaes relevantes do entrevistado. Para isso fundamental fazer com que ele no se limite a falar, mas que
tambm reflita bastante sobre cada uma das suas respostas. Por isso o entrevistador
deve deixar o respondente totalmente vontade, sem pressa para acabar o trabalho.
Veja o quadro Questionrio bem feito.
importante evitar interrupes ocasionadas por fatores externos (telefone, entra-e-sai
de pessoas da sala etc.). Tudo isso pode levar o entrevistado a perder o foco.

Comportamento do entrevistador
O entrevistador deve demonstrar claramente as suas intenes para o entrevistado.
Primeiramente, precisa estar vestido conforme os costumes da empresa para a qual
est trabalhando, de maneira a no causar desconforto aos entrevistados. At h
pouco tempo, consultores e desenvolvedores de software usavam terno, normalmente escuro, intimidando entrevistados no habituados a esse tipo de vesturio.

Requisitos para a documentao

Documentao
Toda entrevista deve ser documentada logo aps sua realizao. Desse
modo, tm-se os dados arquivados e facilmente recuperveis para eventuais necessidades. Esse material deve conter informaes mnimas, podendo ser ampliado, dependendo da necessidade de cada projeto de desenvolvimento:
data, hora e local da entrevista;
nome do entrevistador;
cargo do entrevistador;
nome do entrevistado;
funo do entrevistado e descrio do cargo;
organograma do entrevistado (superior imediato, colegas do mesmo nvel,
subordinados);
objetivo da entrevista;
nomes e ttulos de todos os outros presentes na entrevista;
descrio completa dos fatos tratados e opinies do entrevistado;
transcrio da entrevista (opcional);
concluses tiradas com base nos fatos e nas opinies apresentados;
problemas do negcio levantados durante a entrevista;
exemplos de relatrios, diagramas, documentos etc.;

Viso geral do sistema e dos benefcios decorrentes do seu

desenvolvimento.

Questionrio bem-feito

Glossrio explicativo dos termos tcnicos utilizados.

Evitar palavras ambguas ou vagas que tenham significados

diferentes para pessoas distintas.

Definio dos servios ou dos requisitos funcionais do

sistema.

Redigir itens especficos, claros e concisos e descartar

palavras suprfluas.

Definio das propriedades do sistema (requisitos no

funcionais), como viabilidade, segurana etc.

Incluir apenas uma ideia por item.

Restries operao do sistema e ao processo de

desenvolvimento.
Definio do ambiente em que o sistema operar e as
mudanas previstas nesse ambiente.
Especificaes detalhadas, incluindo modelos e outras
ferramentas.

42

Certos movimentos tambm podem causar desconforto no interlocutor.

Balanar os ps ou bater a caneta na mesa so gestos involuntrios que
podem tirar a ateno do entrevistado e do entrevistador. E, no caso de
entrevistas longas, necessrio fixar um breve intervalo.

Dica

importante que o
desenvolvedor tenha
conhecimentos
do negcio do cliente
e resista a priorizar
a tecnologia
em relao s suas
necessidades.

Evitar itens com categorias de respostas desbalanceadas.

Evitar itens com dupla negao.
Evitar palavras especializadas, jarges, abreviaturas e
anacronismos.
Redigir itens relevantes para a sua pesquisa.
Evitar itens demogrficos que identifiquem
os entrevistados.

43

Informtica 3

captulo 1

Figura 10

d
 esenhos e diagramas elaborados a partir da entrevista (ou durante a
conversa);
comentrios relevantes feitos pelo entrevistado;
todos os nmeros importantes: quantidades, volume de dados etc.

A metodologia
JAD substitui as
entrevistas individuais
por reunies
entre usurios e
desenvolvedores.

Perguntas para concluso

Para finalizar a conversa preciso obter a avaliao do entrevistado sobre a atividade realizada. Essa tarefa exige que ele responda a um formulrio contendo
as seguintes perguntas:
A entrevista cobriu todo o escopo necessrio?
Foram feitas perguntas adequadas?
O entrevistado era realmente a pessoa mais indicada para dar as respostas
solicitadas?

1.8.5.2. Metodologia JAD (Joint Application Design)

Outra tcnica importante de identificao e coleta de requisitos o JAD (iniciais
de Joint Application Design ou, literalmente, desenho de aplicao associada).
Caso o levantamento de requisitos no seja feito de maneira eficiente sem a
identificao das verdadeiras necessidades do usurio , ao entregar o software
o grupo de informtica corre o risco de receber um feedback negativo do cliente.
Isso porque a percepo desse cliente ser de que no recebeu aquilo que solicitou.
Tal problema de comunicao pode ter diversas causas. A adoo de linguagem
tcnica por ambas as partes uma das principais razes de erros no levantamento de
requisitos, pois tanto o usurio quanto o analista de sistemas podem utilizar termos
pertinentes exclusivamente sua rea. Por exemplo, profissionais do departamento
financeiro possuem um conjunto de vocbulos tcnicos (jarges) desconhecidos dos
analistas de sistemas ou que podem levar a um entendimento dbio. O desconhecimento dos desenvolvedores sobre a rea de atuao outro motivo de equvocos.

Recomenda-se, portanto, que esses profissionais tenham conhecimentos sobre o negcio do cliente, para estarem mais integrados ao sistema a ser desenvolvido. Tambm no se deve priorizar a tecnologia em detrimento das necessidades dos usurios
e, consequentemente, da soluo do problema do cliente. Na fase inicial do projeto, a
dificuldade de comunicao entre clientes e equipe de desenvolvimento a principal
causa de defeitos encontrados no produto final (AUGUST, 1993).
Na tentativa de resolver os problemas de comunicao entre desenvolvedores e
clientes (usurios), foram criados, no final da dcada de 1970, diversos mtodos
baseados na dinmica de grupo.

O processo da entrevista
O processo de entrevista no se reduz ao ato em si. Por isso,
necessrio pensar em todas as atividades que antecedem
e sucedem a tarefa:
1. Determinao da necessidade da entrevista

44

6. Entrevista propriamente dita

7. Documentao da entrevista, incluindo as informaes
obtidas

2. Especificao do objetivo da entrevista

8. Validao com o entrevistado da transcrio

da entrevista

3. Seleo do entrevistado

9. Correo da transcrio

4. Marcao da entrevista

10. Aceitao por parte do entrevistado

5. Preparao das questes ou do roteiro

11. Arquivamento

45

Informtica 3

captulo 1

Roteiro para realizao de entrevista

Para a realizao de uma entrevista bem estruturada preciso seguir
um roteiro ou um script. Pode-se utilizar um modelo (template),
retirando-se ou acrescentando-se itens sempre que necessrio. E uma
boa opo estabelecer uma conversa informal antes da entrevista,
para deixar o entrevistado mais vontade. Depois s seguir o roteiro:
1. Apresentar-se ao entrevistado, identificando-se e informando
de qual projeto participa e qual a sua funo (gerente de projetos,
analista de sistemas etc.).
2. Informar ao entrevistado qual o motivo da entrevista e as razes
pelas quais ele foi selecionado: a melhor pessoa para auxiliar no
levantamento de requisitos, por conhecer os procedimentos.

Pela forma tradicional de desenvolvimento de software, os analistas de sistemas

entrevistam usurios um aps outro, rea a rea. Anotam tudo o que dito e,
somente em um segundo momento, as informaes so consolidadas e validadas com os entrevistados. Aps essa verificao, os dados so compilados em
um documento de anlise. J ao se utilizar o JAD, as entrevistas individuais
so substitudas por reunies em grupo nas quais os envolvidos com o processo
(usurios) participam ativamente ao lado da equipe de desenvolvimento.
Quando o mtodo JAD aplicado de forma correta, os resultados so excelentes. Alm de atingir o objetivo de obter informaes dos usurios, criase um ambiente de integrao da equipe onde todos se sentem envolvidos e
responsveis por encontrar solues. Esse comprometimento dos usurios faz
com que eles se sintam proprietrios do sistema e colaboradores no seu
desenvolvimento, gerando, assim, maior aceitao do software quando este for
implementado (AUGUST, 1993).

3. Deixar claro que o conhecimento e as opinies do entrevistado

so de extrema importncia e sero muito teis no processo
de anlise de requisitos.
4. Dizer ao entrevistado o que ser feito com as informaes
levantadas.
5. Informar o entrevistado de que lhe ser fornecida uma transcrio
da entrevista, para que tenha oportunidade de ler e corrigir algum
detalhe eventualmente equivocado e lhe assegurar que nenhuma
informao ser fornecida a outras pessoas at essa validao.
6. Determinar assuntos confidenciais ou restritos a serem tratados
na entrevista.
7. Deixar claro que no haver consequncias negativas em funo
do resultado da entrevista.
8. Solicitar sempre a permisso do entrevistado para gravar a
entrevista.
9. Se o entrevistado autorizar, deve-se iniciar a gravao com um
texto de apresentao, para identificar a entrevista, informando
o assunto e a data.
10. Avisar ao entrevistado quando o tempo estiver se esgotando
e perguntar se ele gostaria de adicionar alguma informao.
11. No final, solicitar ao entrevistado que responda s perguntas
de concluso.
12. Concluir a entrevista de forma positiva, relatando brevemente
o bom resultado alcanado.
13. Se necessrio, marcar outra entrevista.
14. Despedir-se educadamente, agradecendo a ateno e o tempo
dispensado.

46

47

Captulo 2

Modelo de entidade
e relacionamento
Conceitos
Normalizao
Fases de um projeto utilizando ER

Informtica 3

captulo 2

E como a informtica pode ajudar na organizao? Muito e em todo esse processo, que inclui armazenamento, manuteno e consulta de informaes, proporcionando agilidade, uniformidade e segurana em todas as suas fases. Ao
juntarmos o conhecimento preexistente velocidade de processamento e capacidade de armazenamento de informaes que a informtica oferece, chegamos
a modelos extremamente interessantes no que diz respeito facilidade de uso,
velocidade de acesso e de respostas, alm de baixo custo de manuteno.

necessidade de organizar informaes acompanha a humanidade desde o incio dos tempos. O pastor representava ovelhas por
meio de pedras, enquanto os escribas ordenavam os textos nas estantes. Acontece que a populao mundial cresceu, assim como a quantidade de
informaes disponveis, e, desse modo, pesquis-las tornou-se mais complexo,
o que exigiu novas formas de organizao.
Tente achar um livro na biblioteca (figura11) de sua escola sem saber como esto
organizadas as estantes. V procurando estante por estante, livro por livro...
Quanto tempo ir demorar? Agora, pense em fazer a mesma pesquisa na Biblioteca Nacional (do Rio de Janeiro) ou na Biblioteca do Smithsonian Museum,
dos Estados Unidos, que so muito maiores que a de sua escola. Sem uma organizao prvia fica muito demorado e trabalhoso obter as informaes de que
precisamos em nosso dia a dia.

Depois de vrios estudos, chegou-se a uma metodologia para projetar e construir

bancos de dados otimizados, capazes de permitir o acesso mais rpido e consistente s informaes, utilizando espao cada vez menor de armazenamento. sobre
essa metodologia que falaremos neste captulo, o modelo de entidade e relacionamento, que prope definies e regras para projeto e implementao de bancos
de dados, assim como a relao desses dados com as funcionalidades do sistema.
As bases do modelo de entidade e relacionamento comearam a ser lanadas
quando Edgar Frank Codd definiu as principais implementaes necessrias para
o correto funcionamento de um banco de dados relacional usando, para isso, a
teoria dos conjuntos, a lgebra e o clculo relacional. O modelo ganhou mais
corpo quando Donald D. Chamberlin e Raymond F. Boyce desenvolveram uma
linguagem de consulta que facilitava o acesso e a manuteno de bancos de dados
relacionais, oferecendo os recursos necessrios para sua utilizao em larga escala,
o que atendia s necessidades do mercado. A contribuio de Peter Chen foi na
definio de uma metodologia para modelagem de projetos de banco de dados,
utilizando banco de dados relacionais (veja quadro Os nomes por trs da tecnologia).
A linguagem criada por Clamberlin e Boyce ganhou o nome de SQL, e somente
em 1986 foi distribuda e aceita por praticamente todos os bancos de dados, torFigura 11
Se soubermos
como esto
organizadas as
estantes, podemos
encontrar um
livro facilmente,
seja qual for
o tamanho de
uma biblioteca.

50

51

Informtica 3

captulo 2

Figura 12

de dados, a pesquisar, por exemplo, a funo que retorna data atual no SQL.
Mas, com certeza, as diferenas entre elas so atualmente bem menores. Hoje
em dia, o padro ANSI est na verso SQL:2003.

No possvel
encontrar um s
livro em ambiente
desorganizado.

Robert W. Ginn/Alamy/Other Images

Os estudos no pararam por a. O modelo de entidade e relacionamento foi inegavelmente um marco na histria da informtica, utilizado em larga escala, mas
avanou-se bastante depois dele. Hoje, por exemplo, existe a UML (Linguagem
de Modelagem Unificada), outra tcnica de modelagem, baseada na teoria de
Orientao a Objetos (analisada no captulo 4).

nando-se referncia, com o lanamento do SQL padro ANSI. A padronizao

foi necessria porque cada banco de dados, por questo de projeto ou facilidade
de implementao, modificava os comandos da linguagem, a tal ponto que,
hoje, se no fosse a padronizao, provavelmente teramos de reaprend-la a cada
mudana de sistema gerenciador de banco de dados. A linguagem SQL ser um
dos focos do terceiro captulo deste livro.
Infelizmente, a padronizao ainda no gerou uma linguagem com funes totalmente iguais, o que nos obriga, ao trocarmos de sistema gerenciador de banco

2.1. Conceitos
Para podermos utilizar as tcnicas do modelo de entidade e relacionamento, necessitamos predefinir alguns de seus conceitos, de modo a facilitar seu entendimento.

Banco de dados
um conjunto de informaes inter-relacionadas sobre determinado assunto e
armazenadas de forma a permitir acesso organizado por parte do usurio.

Bancos de dados relacional

So conjuntos de dados, relacionados entre si, que implementam as caractersticas do modelo de entidade e relacionamento.

Sistema gerenciador de bancos de dados (SGBD)

um conjunto de programas que permite a implementao de bancos de dados,

Os nomes por trs da tecnologia

52

Relational Model of Data for Large

Shared Data Banks (Modelo de
dados relacional para grandes
bancos de dados compartilhados).
Quatro anos depois, em
maio de 1974, Chamberlin
e Raymond F. Boyce, ambos
engenheiros e cientistas da IBM,
apresentaram o trabalho SEQUEL
A Structured English Query
Language (Linguagem de consulta
estruturada em ingls).
Em maro de 1976, Peter
Chen, engenheiro eltrico
e Ph.D. em Cincia da

Edgar Frank Codd

Computao, publicou,
tambm na revista ACM,
o artigo The EntityRelationship Model-Toward a
Unified View of Data
(O modelo de entidade
e relacionamento, uma viso
unificada dos dados).

Donald D. Chamberlin

Dr. Peter Chen

Fotos: divulgao

Edgar Frank Codd, Donald D.

Chamberlin e Peter Pin Shan
Chen so os pesquisadores
que mais contriburam para a
criao do modelo de entidade
e relacionamento. Em junho de
1970, Codd, matemtico ingls,
que na poca trabalhava no
laboratrio da IBM em San Jos,
na Califrnia, Estados Unidos,
publicou um artigo decisivo
na revista ACM Association
for Computer Machinery
(Associao para Maquinria
da Computao), intitulado

53

Informtica 3

captulo 2

Para a construo
de modelos,
preciso abstrair,
isto , no se
preocupar com
todos os detalhes,
mas apenas com
os que se quer
analisar e/ou sobre
os quais se tem
alguma dvida.

Figura 13

assim como o controle de acesso, o backup, a recuperao de falhas, a manuteno da integridade, a administrao e a segurana dos dados que contm.

Vrios olhares
sobre um
mesmo tema.

Modelo
Podemos definir um modelo como sendo um prottipo, em escala menor, do
produto que queremos implementar ou da soluo que queremos obter.
O modelo nos permite, com um custo muito menor (de tempo, dinheiro e
trabalho), em comparao ao do desenvolvimento do produto final, analisar e
desenvolver alguns aspectos que faro a diferena no produto final. Ou seja, no
modelo podemos criar, testar funcionalidades novas e avaliar o projeto, com um
baixo custo antes de sua implementao.

Abstrao

Ateno

O Modelo ER e os
Sistemas Gerenciadores
de Bancos de Dados
foram criados
primeiramente para
aceitar nomes em ingls,
lngua que no possui
acentos em suas palavras.
Apesar de hoje em dia
a maioria dos SGBDs
aceitarem palavras
acentuadas e at o uso
do caracter espao
entre as palavras que
nomeiam algum de
seus componentes,
por convenso, no
utilizaremos espaos
nem acentos para
nominar os componentes
de nossos modelos
afim de no gerarmos
problemas de
implementao
em qualquer que seja
o SGBD, padronizarermos
a implementao,
evitando dvidas do tipo
Funcionrio com ou sem
acento, sem falar nas
mudanas da lngua.

54

Para exemplificar o que abstrao, vale acompanhar um exemplo bem corriqueiro e que muita gente vivencia. Quando olhamos para uma casa, podemos pensar em seu tamanho, sua localizao, no nmero de quartos que a
integram, na cor das paredes. J um engenheiro civil, ao olhar para a mesma
casa, pensar em como ela foi construda, se o material utilizado de boa qualidade, se sua estrutura foi concebida para suportar seu tamanho. O pedreiro
pensar na quantidade de tijolos, cimento, pedras, areia e ferro que foram
necessrios para constru-la. O jardineiro avaliar sua localizao, o clima e
sua posio em relao ao sol, alm das melhores plantas para o jardim. O
encanador pode refletir sobre qual o tamanho da caixa dgua para garantir
o abastecimento na casa e em quantos metros de encanamento de cada largura
foram necessrios para seu sistema hidrulico. O eletricista talvez pense sobre
a metragem e a bitola dos fios empregados no sistema eltrico. O corretor de
imveis se concentra na metragem da casa, no nmero de cmodos, de vagas
na garagem, na localizao, no preo de aluguel ou venda (figura 13).
Cada um dos personagens do exemplo se fixou em detalhes diferentes sobre um
mesmo projeto, a casa. Olhou para ela pensando em suprir as prprias necessidades, enfatizando as caractersticas mais importantes para atend-las, e desprezou os demais detalhes, os quais, embora tambm faam parte da construo,
no tm relevncia particular.
o que se chama de abstrao: esses vrios pontos de vista, essas diferentes
possiblidades de anlises sobre um mesmo objeto o que se chama de abstrao,
uma caracterstica fundamental para a construo de um bom modelo de entidade e relacionamento.

lidades dos programas da aplicao, para s ento chegar-se a uma soluo

completa de software. H vrios componentes do modelo ER. Vale, portanto, conhecer os principais, entre os quais se alinham: Entidade, Relacionamento, Atributo e Chaves.

Entidades
Entidades so abstraes do mundo real que contm um conjunto de informaes inter-relacionadas e coerentes. Estas informaes so chamadas de atributos. Toda entidade possui um nome que a identifica, geralmente formado por
um substantivo no singular. A representao grfica de uma entidade feita por
um retngulo com seu nome no centro, como mostra a figura 14.
Figura 14
Entidade
Funcionario.

Modelo de entidade e relacionamento

Prope definies e regras para o projeto e a implementao de bancos de
dados, assim como a relao desses dados com as funcionalidades que esse
sistema deve implementar. Sugere que, nas diversas fases de desenvolvimento do projeto, os modelos sejam refinados at que se chegue ao modelo final
que, em modelagem ER, chamamos de projeto fsico. Acrescentando-se a
seguir o projeto fsico do banco de dados, ele se juntar com as funciona-

Funcionario

55

Informtica 3

captulo 2

Figura 16

Atributo

Chave primria.

Atributo cada informao que compe uma entidade. Possui um nome, um

tipo e um tamanho (nmero de caracteres). De modo genrico o tipo, pode ser
nominado como texto, nmero, data, hora, etc. at que se saiba em qual sistema
gerenciador de banco de dados este ser implementado e ento se atribua o tipo
correto, pois cada SGBD possui suas particularidades em relao aos tipos de
dados aceitos. Por exemplo os tipos real ou double.
O atributo pode ser representado no diagrama ER como um crculo, com o
nome ao lado ou como uma elipse com seu nome, o qual representado geralmente por um substantivo. Para evitar problemas de compatibilidade, deve
comear com uma letra e no conter espaos e acentuao, mas pode incluir
caracteres especiais como underline, entre outros (figura 15).
Figura 15
Atributo.

dataDemissao

Funcionario

Funcionario

codigo

4. Chave estrangeira: atributo que implementa o relacionamento entre entidades e permite o controle da integridade referencial, isto , um atributo
que, fazendo parte da chave primria em uma entidade, includo em outra
entidade ou relacionamento, implementando as ligaes entre elas.

Relacionamento
o elemento responsvel por definir as caractersticas das ligaes entre as entidades. Representado graficamente por um losango, seu nome em geral expresso por um verbo ou uma locuo verbal. Por exemplo a figura 17.
Figura 17

H alguns tipos de atributos especiais usados para demonstrar a estrutura das

informaes que eles representam de modo a facilitar a busca dessas informaes ou o relacionamento entre as entidades. So eles:

Relacionamento.

Pertence

1. Atributo composto: representa a estrutura das informaes que sero armazenadas no atributo, por exemplo:

primeiroNome sobrenome

complemento
numero

rua
nome

Auto-relacionamento: indica um relacionamento entre as ocorrncias de um

mesmo relacionamento. Para demonstrar melhor do que se trata, vale definir os
papis de cada um de seus lados, como mostra a figura 18.

Endereco

2. Atributo multivalorado: pode receber mais de um valor ao mesmo tempo.

Um bom exemplo o atributo habilidades de um funcionrio, que ser
preenchido com a lista de suas aptides separadas por vrgulas. Veja um
exemplo de preenchimento: liderana, boa comunicao, bom relacionamento interpessoal. Assim, o atributo habilidades considerado um atributo multivalorado.

Figura 18
Auto-relacionamento.

E_Chefe

1
Chefe

Subordinado
Funcionario

3. Chave primria: atributo ou conjunto de atributos que identifica unicamente uma tupla (registro) em uma entidade. expresso com um crculo
preenchido, como mostra a figura 16.
56

57

Informtica 3

captulo 2

Cardinalidade
Serve para definir o tipo de relacionamento entre as entidades. Existem duas
notaes para identificar a cardinalidade. Uma delas refere-se simplesmente ao
valor mximo que a cardinalidade daquele relacionamento pode alcanar, e
grafada com o nmero 1 (que representa 1 elemento da entidade) ou com a
letra N (que representa muitos ou mais de um elemento da entidade). A outra
expressa o nmero mnimo e o nmero mximo de ocorrncias em um relacionamento. Neste caso, sua notao (1:N), onde 1 representa o nmero mnimo
e N o nmero mximo de ocorrncias. So quatro as cardinalidades:
1. Relacionamentos 1 para N
Indicam que uma ocorrncia na entidade A pode estar relacionada a N ocorrncias da entidade B. No exemplo da figura 19 podemos verificar que um vendedor atende N clientes e que um cliente atendido por apenas 1 vendedor.
Figura 19
Relacionamento
1 para N.

1
Vendedor

Cliente

2. Relacionamentos N para 1
Indicam que uma ocorrncia na entidade B pode estar relacionada com N ocorrncias na entidade A. No exemplo da figura 20, a 1 departamento podem pertencer N funcionrios.
Figura 20
Relacionamento
N para 1.

Funcionario

Pertence

Figura 22
N

Cliente

Compra

cod_Cliente
cod_Produto
codigo

Produto

quantidade
valor_Unitario

nome

codigo

4. Relacionamentos 1 para 1
Indicam que uma ocorrncia da entidade A pode estar relacionada a uma ocorrncia na entidade B e que uma ocorrncia da entidade B pode estar relacionada
a uma ocorrncia da entidade A (figura 23).

Departamento

Figura 23
Funcionario

3. Relacionamentos N para N
Indicam que uma ocorrncia na entidade A pode estar relacionada a N ocorrncias na entidade B e que uma ocorrncia na entidade B pode estar relacionada a N
ocorrncias na entidade A. No exemplo da figura 21 podemos observar que um
cliente compra N produtos e que um produto pode ser comprado por N clientes.
Figura 21
N

Cliente

1
Gerencia

Departamento

Relacionamentos
1 para 1 .

Restrio
Muitas vezes, simplesmente definir um relacionamento no nos garante total entendimento da situao que ele se deve demonstrar, conforme a figura 24.

Compra

Figura 24

Produto

Funcionario

O relacionamento N para N possui uma caracterstica especial. Tambm chamado de relacionamento com campos, sua implementao exige a incluso de
58

nome

Cliente tem os atributos codigo e nome, codigo a chave primria.

Produto tambm tem os atributos codigo e nome, tendo codigo como
chave primria.
Compra tem os atributos cod_produto, cod_cliente, que formam a chave
primria, alm dos atributos quantidade e valor_unitario.

Relacionamento
N para N.

Relacionamento
com campos.

Resumindo:

Atende

atributos (pelo menos na chave primria de cada uma das entidades envolvidas)
e chave primria. Quando acontece a implementao do modelo fsico, este
relacionamento se torna uma tabela, como mostra a figura 22.

Pertence

Departamento

Relacionamento
que no
nos garante
entendimento
da situao.

59

Informtica 3

captulo 2

Esse exemplo nos parece claro quanto ao relacionamento entre funcionrio e departamento, mas e se perguntarmos: pode haver funcionrio sem departamento associado?
Esse questionamento, num primeiro momento, pode parecer sem sentido, mas
imagine uma situao em que os funcionrios passam por treinamento e s so
alocados em departamentos depois de serem avaliados. E, ento, eles no so
funcionrios? Claro que so! E para deixar mais clara esta definio que existe
o conceito de restrio, que expressa quais so o maior e o menor valor do relacionamento. Para o caso proposto a notao ficaria como na figura 25:
Figura 25

Interpretando o diagrama anterior, podemos dizer que um cliente compra N

produtos e atendido por 1 funcionrio e que 1 funcionrio atende N (clientes
que compram produtos).

Diagrama de entidade e relacionamento

Parte do modelo de entidade e relacionamento, o diagrama a representao
grfica dos elementos nele definidos. montado aps a denominao das entidades, dos seus atributos e relacionamentos (figura 27).
Figura 27

cod_Depto

Restrio.

Diagrama de
entidade e
relacionamento.

Funcionario

Pertence
(1, N)

Departamento
(0,1)

Funcionario

Como se deduz que um funcionrio pode pertencer a no mnimo nenhum e no

mximo 1 departamento e 1 departamento possui no mnimo 1 e no mximo N
funcionrios. Essa representao nos ajuda a definir as restries de integridade
de nosso modelo e permite maior compreenso do banco de dados a ser construdo. O que devemos entender que pode haver funcionrios sem departamento,
mas no departamentos sem funcionrio.

1
Departamento

Pertence
(0:N)

codigo nome dataAdmissao

(1:1)

codigo

descricao

Agregao
Outro problema conceitual que preciso definir o relacionamento de uma
entidade com um conjunto de entidades, isto , esse relacionamento s existe se
houver um conjunto de informaes.
Imagine a seguinte situao:
Um cliente compra produtos e atendido por um funcionrio. Veja na figura 26
como exibir graficamente esse caso:
Figura 26
Agregao.

Cliente

Compra

Atende

Produto

possvel identificar nesse pequeno fragmento de diagrama quase todos os elementos do modelo visto at aqui:
Entidades: Funcionario e Departamento.
Relacionamento: Pertence.
Atributos:
da entidade Funcionario: codigo, nome, dataAdmissao, cod_Depto.
da entidade Departamento: codigo, descricao.
Chave primria:
da entidade Funcionario: codigo.
da entidade Departamento: codigo.
Chave estrangeira: o relacionamento Pertence com cardinalidade N para 1 faz
com que seja necessrio criar o campo cod_Depto na entidade Funcionario, que
conter o cdigo do departamento a que cada funcionrio pertence.
Restries de integridade: podemos observar, pelas notaes de restrio de
integridade, que um funcionrio tem de pertencer a um departamento. J um
departamento pode ser cadastrado sem um funcionrio associado.

Funcionario

Vale, agora, propor um roteiro de passos para a elaborao do modelo de entidade e relacionamento e a criao do diagrama que o representar.
60

61

Informtica 3

captulo 2

1. Listar as entidades candidatas a integrar o modelo.

2. Analisar e selecionar as entidades que realmente fazem parte do modelo,
excluindo as demais.
3. Analisar os relacionamentos entre as entidades.
4. Definir a cardinalidade dos relacionamentos.
5. Definir os atributos das entidades e relacionamentos com campos e tambm
as chaves primria e estrangeira (se houver).
6. Definir as restries de integridade dos relacionamentos.
7. Desenhar o diagrama de entidade e relacionamento.

2.1.1. Estudo de caso

Vale imaginar como construir um modelo de entidade e relacionamento para o
dono de uma pequena padaria, que ser chamado de senhor Joo. No final, ser
elaborado o diagrama de entidade e relacionamento.
O senhor Joo vende, alm de pes, vrios outros tipos de produtos, tais como
frios, laticnios, lanches, refrigerantes, sorvetes, balas, chicletes, chocolates, car-

tes telefnicos e artigos diversos expostos no balco do caixa. Vende tambm,

nos fins de semana, frango assado.
Na padaria, trabalham funcionrios que executam as funes de caixa, atendente, auxiliar de limpeza e padeiro (Figura 28).
O senhor Joo quer que cada cliente receba um carto com um cdigo na entrada da padaria e que este carto seja usado para registrar os produtos comprados
pelos clientes. Os preos desses produtos devero ser somados automaticamente
assim que o carto for entregue no caixa, que confirmar o valor total da compra, verificar a forma de pagamento escolhida, receber o pagamento e, se for
o caso, devolver o troco ao cliente.
O senhor Joo tambm deseja controlar dos estoques para que no faltem produtos. Ele tem, portanto, necessidade de informaes sobre:
As vendas, isto , precisa que sejam armazenados todos os dados de todas as
vendas da padaria: quais produtos foram vendidos, em qual quantidade e

Figura 28
O senhor Joo
tem necessidade
de informaes
precisas sobre a
sua padaria.

62

63

Informtica 3

captulo 2

por qual valor, alm de qual empregado registrou a venda e qual recebeu o
pagamento.
O estoque, de modo que cada produto vendido seja debitado no saldo.
A necessidade de reposio de produtos o modelo deve ter capacidade
para gerar a qualquer momento a relao dos itens cujo saldo est abaixo
do estoque mnimo desejvel para facilitar a identificao daqueles que
precisam ser repostos.
A durabilidade e o uso dos cartes.
Seus fornecedores endereos, telefones e o nome do contato na empresa para
efetuar a compra.
Uma observao importante: o senhor Joo j possui um controle fiscal e contbil de toda a movimentao, cujos documentos e registros ele envia semanalmente
para seu contador. Fica, assim, para o modelo a ser proposto apenas o controle
fsico (estoque) e financeiro das transaes.
Vamos pensar no problema proposto pelo senhor Joo, construir um modelo e
demonstr-lo por meio de um diagrama de entidade e relacionamento. Para isso,
preciso dar vrios passos.

Passo 1
Listar as entidades candidatas a integrante do modelo.
Quando recebemos uma solicitao nesse formato, isto , um texto que descreve a situao a ser tratada no modelo, uma prtica bastante usada no prprio
texto fazer a identificao das possveis entidades e relacionamentos, assim como
dos principais atributos, grifando os substantivos e verbos essenciais para depois
analis-los a fim de atribuir-lhes os devidos papis. Vejamos o que podemos selecionar em nosso texto.
No primeiro pargrafo temos os seguintes substantivos: senhor Joo, pes,
produtos, frios, laticnios, lanches, refrigerantes, sorvetes, balas, chicletes, chocolates, cartes telefnicos, produtos, frango assado, balco, caixa.
No segundo pargrafo encontramos: padaria, funcionrios, funes, caixa,
atendente, auxiliar de limpeza e padeiro.
No terceiro pargrafo podemos grifar: senhor Joo, clientes, carto, cdigo,
produtos, padaria, caixa, valor total da compra, forma de pagamento, troco.
No quarto pargrafo identificamos: produto, senhor Joo, fornecedores.

Passo 2
Analisar e selecionar as entidades que realmente fazem parte do modelo, excluindo as demais.
Vamos avaliar os substantivos apenas uma vez, mesmo se eles aparecerem mais
vezes, ou em mais de um pargrafo. Se forem exatamente iguais, ser considerada
a primeira anlise.
Senhor Joo: o dono da padaria e pode ser tratado como informao, pois
tambm atende na padaria e trabalha no caixa. No entidade.
Pes, frios, laticnios, lanches, refrigerantes, sorvetes, balas, chicletes, chocolates, cartes telefnicos: tipos de produtos vendidos na padaria. So informaes relacionadas entidade produto, mas no so entidades.
64

Frango assado: um produto vendido na padaria. No entidade.

Balco: local fsico onde ficam expostas as mercadorias. No informao.
Caixa: local fsico na padaria no qual so registradas e pagas as compras. No
informao.
Produtos: so os itens que o senhor Joo vende em sua padaria. Contm um
conjunto de atributos, tais como descrio, saldo e preo de venda. So uma
entidade.
Padaria: o tipo do estabelecimento que o senhor Joo possui. Tem um conjunto de atributos, como nome, endereo etc. uma entidade.
Funcionrios: so as pessoas que executam algum tipo de servio necessrio ao
bom funcionamento da padaria. Possuem uma srie de atributos que precisam
ser armazenados para facilitar o controle e a consulta de suas informaes. So
uma entidade.
Funes: referem-se qualificao do funcionrio e ao tipo de servio que
ele exerce na padaria, logo, so atributos de funcionrio.
Caixa, atendente, auxiliar de limpeza e padeiro: So os nomes das funes dos funcionrios, informaes que podem se relacionar com o atributo funo.
Clientes: so os agentes de nosso modelo, aqueles que compram os produtos
do senhor Joo. Possuem um conjunto de atributos tais como nome, endereo,
telefone. Constituem uma entidade.
Carto: o item que representar o cliente na padaria. Demanda o controle de sua durabilidade e de seu uso. associado ao registro das vendas
e possui os atributos cdigo, data de incio de uso e data de fim de uso.
uma entidade.
Cdigo: um atributo da entidade carto.
Valor total da compra: informao relevante da compra. E, assim, atributo da
entidade compra.
Forma de pagamento: informao a opo de pagamento do cliente. um
atributo da entidade compra.
Troco: a diferena entre o valor da compra e o valor dado em dinheiro pelo
cliente para o pagamento da compra. Atributo de compra.
Fornecedores: so os responsveis por fornecer ao senhor Joo os produtos que
ele vende. Possuem um conjunto de informaes relevantes, como nome, endereo, telefone para contato. uma entidade.
Assim, listamos como entidades: produtos, padaria, funcionrios, clientes, compra, carto e fornecedores. Como a boa prtica manda nominar as entidades
como substantivos no singular, teremos: produto, padaria, funcionrio, cliente,
carto, forma de pagamento e fornecedor.
Analisando agora as entidades e pensando em sua relevncia, temos que:
A entidade padaria deve ser retirada de nosso modelo. Como a ideia criar o
modelo apenas para uma padaria, essa pode ficar fora de nosso escopo.

Chegamos ento
a uma lista final
de quatro
entidades:
Produto
Funcionrio
Carto
Fornecedor

A entidade cliente tambm pode ser retirada de nosso modelo, pois, entre as
funcionalidades que o senhor Joo nos solicitou, no consta identificar o que
cada cliente comprou. Voc j se cadastrou em alguma padaria em que foi fazer compra? Na maioria dos casos, isso no acontece. Por isso, em nosso caso,
o cliente ser substitudo pelo carto.
65

Informtica 3

captulo 2

Passo 3
Observe que
identificamos
anteriormente compra
como sendo uma
entidade e agora
listamos-a como sendo
um relacionamento.
Por qu? Por se tratar
de um relacionamento
com campos que
quando da criao do
projeto fsico tornase uma tabela, assim
como as entidades.

Analisar os relacionamentos entre as entidades.

Quanto aos relacionamentos entre as entidades listadas, identificamos:
Carto compra Produto
Funcionrio atende (carto compra Produto)
Fornecedor Fornece Produto.

Passo 4
Definir a cardinalidade dos relacionamentos
Para os relacionamentos definidos, h as seguintes cardinalidades:
Carto compra Produto
(Senhor Antonio entra na padaria para comprar um litro de leite. Recebe um
carto, vai ao balco, pega o leite e 100 g de po de queijo.)
Um carto (o carto que senhor Antonio pegou na entrada da padaria) compra
vrios produtos (um litro de leite e 100 g de po de queijo) e um produto (leite)
pode ser comprado por vrios cartes (os da senhora Maria, do senhor Antonio,
do Miro). Logo, a cardinalidade desse relacionamento N para N, sendo necessrio que se definam os atributos do relacionamento compra por se tratar de um
relacionamento com campos.

Figura 29

Portanto, Larcio ir registrar dez pezinhos no carto da senhora Maria, depois

registrar as compras do senhor Joaquim, Mariana, Pedro.
Logo, um funcionrio (Larcio) atende vrios (carto compra produto o carto da senhora Maria x dez pezinhos), mas um (carto compra produto o
carto da senhora Maria x dez pezinhos) s atendido (a cada vez que ela compra um produto na padaria) por um funcionrio (Larcio), logo a cardinalidade
deste relacionamento N para 1.
Fornecedor fornece produto
O senhor Cardoso dono de um atacado que vende bolachas e chocalates com o
melhor preo da cidade. Toda vez que o dono da padaria, o senhor Joo, precisa
comprar bolachas ou chocolates, ele liga para o senhor Cardoso e faz o pedido.
No mximo at o dia seguinte o caminho do senhor Cardoso para em frente
padaria e entrega as mercadorias solicitadas.
Logo, um fornecedor (senhor Cardoso) fornece vrios produtos (bolachas e chocolates), e um produto (chocolate ao leite) pode ser vendido por vrios fornecedores (senhor Cardoso, Maria Doceria, Bazar dos Amigos). Assim, a cardinalidade deste relacionamento N para N.
necessrio que se definam os atributos do relacionamento fornece por se tratar
de um relacionamento com campos.
Figura 31

Carto compra
produto.

Fornecedor.

Funcionrio atende (carto compra Produto)

Imagine a cena: a senhora Maria comprou dez pezinhos e foi atendida pelo funcionrio Larcio. Depois dela, Larcio atendeu o senhor Joaquim, Mariana, Pedro.
Figura 30
Funcionrio
atende.

Passo 5
Definir as restries de integridade dos relacionamentos.
Ao identificar tais restries de integridade, vamos tambm definir o valor mnimo e mximo de cada cardinalidade.
Carto compra produto
As restries de integridade so: um carto pode comprar ao menos 0 (quando o carto acabou de ser posto em uso) e no mximo N produtos (todos os
produtos dos clientes que pegarem aquele carto). J um produto pode ser
comprado por no mnimo 0 (o produto acabou de ser lanado e acabou de ser
colocado na prateleira) e no mximo N cartes (todos os clientes da padaria).

66

67

Informtica 3

captulo 2

Logo, as restries de integridade so (0,N) e (0,N).

Passo 7 Desenhar o diagrama de entidade e relacionamento

Funcionrio atende (carto compra Produto)

Um funcionrio pode atender no mnimo 0 o funcionrio acaba de comear a
trabalhar na padaria do senhor Joo e no mximo N, Senhor Virglio trabalha
h quinze anos na padaria do senhor Joo. A senhora Maria acaba de chegar
padaria e Larcio, que est no balco, vai atend-la. Assim, o cliente pode ser
atendido por no mnimo 1 e no mximo 1 funcionrio. Logo, as restries de
integridade so (0,N) e (1,1).
Fornecedor fornece Produto
Um fornecedor fornece no mnimo 0 (Mrio vende doces mas seus preos so
sempre mais caros) e no mximo N produtos (senhor Cardoso). J um produto
(chocolate ao leite) fornecido por no mnimo 1 e no mximo N fornecedores
(senhor Cardoso, Maria Doceria, Bazar dos Amigos). Logo, as restries de integridade so: (0,N) e (1,N).

Passo 6
Definir os atributos das entidades e relacionamentos com campos e as chaves primria e estrangeira (se houver).
Para definir esses atributos temos de lembrar sempre do conceito de abstrao,
tentando selecionar apenas os aspectos relevantes para o escopo do problema
em foco.
Entidades:
Cartao(codigo,data_inicio_uso,data_fim_uso): o atributo cdigo foi definido
como chave primria, pois precisamos ter a certeza de que no existem dois cartes com o mesmo nmero e compartilharemos a responsabilidade dessa conferncia com o sistema gerenciador de banco de dados.
Produto(codigo,nome,preco_venda,saldo,estoque_minimo): o atributo
cdigo chave primria, pois assim fica mais fcil fazer o controle para impedir que o valor deste atributo (codigo) se repita.
Funcionario(codigo,nome,funcao): com o atributo codigo como chave
primria.
Fornecedor(codigo,nome,rua,complemento,bairro,cidade,estado,cep,
contato,telefone,celular): o atributo codigo chave primria.
Relacionamentos com campos.
Devemos nos lembrar de que um relacionamento com campos deve conter pelo
menos as chaves primrias das entidades envolvidas. Eles podem conter outros
atributos.
Compra(numero,data,forma_pagamento,codigo_produto,codigo_cartao,
quantidade,valor_unitario,valor_total_compra). Aqui as chaves primrias
so os atributos numero, codigo_cartao e codigo_produto e as chaves estrangeiras os atributos codigo_cartao e codigo_produto.
Fornece(numero_nota,data,codigo_fornecedor,codigo_produto,
quantidade, valor_unitario). Nesse caso, as chaves primrias so os atributos
numero_nota, codigo_fornecedor e codigo_produto e as chaves estrangeiras
codigo_fornecedor e codigo_produto.
68

2.2. Normalizao
Normalizao um processo utilizado para acertar possveis problemas estruturais das entidades e relacionamentos com campos criados tambm chamados
de anomalias em um modelo de entidade e relacionamento. Consiste na anlise dos atributos das entidades e relacionamentos com campos, sob o ponto de
vista das regras chamadas formas normais, que descrevem, com base na teoria
de conjuntos, na lgebra e no clculo relacional, o que devemos ou no fazer
nas estruturas das entidades e relacionamentos de nosso modelo, baseados em
conceitos matemticos.

Figura 32
Diagrama de
entidade e
relacionamento
da padaria do
senhor Joo.

Essa anlise pode demonstrar a necessidade de alterarmos a estrutura de nossas

entidades e relacionamentos com campos, dividindo ou agrupando seus atributos
para aprimorar o processo de recuperao das informaes (performance) e seu
armazenamento, de modo a evitar perda, redundncia e distoro da informao.
Sempre que formos obrigados pela aplicao das formas normais em nosso modelo a dividir entidades, temos que garantir que a diviso poder ser revertida,
isto , que, mesmo particionada em duas ou mais entidades, uma entidade poder voltar sua formao original, por meio de operaes de conjuntos.
Mas, antes de tratar das regras de normalizao propriamente ditas, necessrio
entender alguns conceitos da lgebra relacional, que serviram para definir se
nossas entidades e relacionamentos esto ou no em uma forma normal.
Dependncia funcional
Seja R uma relao e X e Y atributos de R. X e Y podem ser atributos simples
ou compostos.
69

Informtica 3

captulo 2

X g Y (o atributo X determina funcionalmente o atributo Y) sempre que duas

tuplas quaisquer de R tiverem o mesmo valor para X, elas possuem tambm o
mesmo valor para Y.

componentes (rua, complemento, bairro, cidade, estado e cep) ou criamos uma

outra entidade com o nome do atributo composto (endereco), tendo como atributos dessa nova entidade rua, complemento, bairro cidade, estado e cep.

Exemplo:
Tendo a entidade funcionario os atributos codigo, nome, cidade e DDD, e sabendo que o codigo a chave primria da entidade funcionario, se analisarmos
esses atributos sob a ptica da dependncia funcional, teremos:

J o campo telefones, por estar no plural, indica que nele poder ser armazenado mais de
um nmero. Pela regra, esse atributo precisa ser separado em outra entidade, que pode
ser chamada de telefone e que conter os diversos nmeros de telefone do fornecedor.

codigo g nome
codigo g cidade
cidade g DDD
Logo, podemos dizer que os atributos nome e cidade dependem do atributo
codigo. J o atributo DDD depende do atributo cidade.
Definida a dependncia funcional, podemos passar agora para a definio das
formas normais.

Primeira Forma Normal (1NF)

Uma entidade est em Primeira Forma Normal, se e somente todos os seus atributos so atmicos, isto , se contm um valor nico (atmico) e no contm
atributos multivalorados.
Exemplo:
Dada a entidade funcionario, definida com os atributos abaixo:
Funcionario(codigo,nome,data_admissao,data_demissao,habilidades)
Vemos que a entidade funcionario possui o campo multivalorado habilidades, o
que no permitido pela Primeira Forma Normal. Devemos ento dividir a tabela funcionario de forma que o campo habilidades se torne uma nova entidade.
Ento teremos:
Funcionario(codigo,nome,data_admissao,data_demissao)
Possui(cod_funcionario,cod_habilidade)
Habilidade(codigo,descricao)
Exemplo:
Fornecedor(codigo,nome,endereco,telefones)
Vemos que a entidade fornecedor tem como atributo composto endereco e como
atributo multivalorado telefones.
Em relao ao atributo composto endereco, sabemos que o mesmo composto, pois nele pressupe-se incluir as informaes de rua, complemento, bairro,
cidade, estado e cep. Ou substitumos o atributo endereco por seus atributos
70

Assim, temos:
Fornecedor(codigo,nome,rua,complemento,bairro,cidade,estado,cep)
Tendo como chave primria o atributo codigo.
Telefone(cod_fornecedor,nro telefone)
Tendo como chave primria os atributos cod_fornecedor e nro_telefone, j que
isso garante que no ser cadastrado o mesmo telefone para o forncedor e como
chave estrangeira o atributo cod_fornecedor.
Fornecedor(codigo,nome)
Tendo como chave primria o atributo cdigo.
Endereco(cod_fornecedor,rua,complemento,bairro,cidade,estado,cep).
Tendo como chave primria o atributo cod_fornecedor e como chave estrangeira o atributo cod_fornecedor.

Segunda Forma Normal (2NF)

Uma entidade encontra-se em Segunda Forma Normal se e somente estiver em
Primeira Forma Normal e no tiver atributos com dependncias parciais. No
caso de uma chave primria composta, isto , que possui mais de um atributo
em sua composio, denominada dependncia parcial a dependncia de um
atributo no chave a apenas uma parte da chave primria.

Toda entidade
que no possuir
chave primria
composta, isto ,
com mais de um
atributo, est em
2 Forma Normal.

Tomemos como exemplo a tabela compra, descrita abaixo:

Compra(nro_nf,cod_fornecedor,cod_produto,data,nome produto,
quantidade,valor_unitario,valor_total_nota)
Tendo como chave primria os atributos: nro_nf, cod_fornecedor, cod_produto
Se analisarmos a dependncia funcional teremos:
nro_nf,cod_fornecedor g data
nro_nf,cod_produto g quantidade
nro_nf,cod_produto g valor_unitario
nro_nf,cod_fornecedor g valor_total_nota
cod_produto g nome_produto
71

Informtica 3

captulo 2

Vemos agora que nem todos os atributos dependem da chave primria. O que
no permitido pela Segunda Forma Normal. Para que essa entidade fique em
2NF, teremos de desmembr-la.
Ela ficar assim:
Compra(nro_nf,cod_fornecedor,data,valor_total_nota)

Forma Normal Boyce-Codd (BCNF)

Uma entidade est em BCNF se e somente estiver em Terceira Forma Normal e
todos os atributos no chave dependerem apenas da chave primria.
Exemplo:
Cliente(cod_cliente,nome_cliente,email_cliente)

Tendo como chave primria os atributos nro_nf cod_fornecedor e como chave

estrangeira o atributo cod_fornecedor.
Item_compra(nro_nf,cod_produto,quantidade,vl_unitario)
Tendo como chave primria os atributos nro_nf e cod_produto e como chaves
estrangeiras os atributos nro_nf e cod_produto.
Produto(codigo,nome)
Tendo como chave primria o atributo codigo.

Terceira Forma Normal (3NF)

Uma entidade est em Terceira Forma Normal se e somente estiver em Primeira
e em Segunda Forma Normal e todos os atributos no chave dependerem funcionalmente da chave primria.
Exemplo:
Ped ido(n ro_ped ido,d at a ,cod _cl iente,nome _cl iente,ema i l _
cliente,valor_total_pedido)
Vamos verificar a dependncia funcional dos atributos:
nro_pedido g data
nro_pedido g cod_cliente
nro_pedido g valor_total_pedido
cod_cliente g nome_cliente
cod_cliente g email_cliente
Verificamos que os atributos nome_cliente e email_cliente no so dependentes
da chave primria e sim do atributo cod_cliente. Ser necessrio ento desmembrar a entidade pedido.
Pedido(nro_pedido,data,cod_cliente,valor_total_pedido)
Que ter como chave primria o atributo nro_pedido.
Cliente(cod_cliente,nome_cliente,email_cliente)
Que ter como chave primria o atributo cod_cliente.
72

Que ter como chave primria o atributo cod_cliente.

cod_cliente g nome_cliente
cod_cliente g email_cliente
Todos os atributos no chave dependem funcionalmente apenas da chave primria. Logo, est em BCNF.
Vamos agora, como mais um exemplo de aplicao das regras de normalizao, aplicar a normalizao nas entidades do modelo da padaria do
senhor Joo.
Ao final da montagem de nosso modelo ficamos com as seguintes entidades:
Cartao(codigo,data_inicio_uso,data_fim_uso). A chave primria
foi definida como sendo o atributo codigo.
Produto(codigo,nome,preco_venda,saldo,estoque_minimo), tendo o atributo codigo como chave primria.
Funcionario(codigo,nome,funcao), tendo o atributo codigo como
chave primria.
Fornecedor(codigo,nome,rua,complemento,bairro,cidade,estado,
cep,contato,telefone,celular), tendo o atributo codigo como chave
primria.

Observaes

Sempre que for

preciso desmembrar
uma entidade, isso
deve ser feito de
maneira que seja
possvel retornar
forma anterior,
evitando, com isso, a
perda de informaes.
Sempre que se fizer
o desmembramento
de uma entidade, as
tabelas resultantes
devem ser submetidas
novamente s formas
normais para se
ter certeza de que
esto corretamente
normalizadas.

Compra(numero,data,forma_pagto,codigo_produto,codigo_cartao, quantidade,valor_unitario,valor_total_compra), tendo como

chave primria os atributos numero, codigo_cartao e codigo_
produto e como chaves estrangeiras os atributos codigo_cartao
e codigo_produto.
Fornece(numero_nota,data,codigo_fornecedor,codigo_produto,
quantidade, valor_unitario), tendo como chave primria os atributos numero_nota, codigo_fornecedor e codigo_produto e como
chaves estrangeiras codigo_fornecedor e codigo_produto.
Cartao(codigo,data_inicio_uso,data_fim_uso) a chave primria
foi definida sendo o atributo codigo.
Agora vamos analisar cada uma das entidades.
73

Informtica 3

captulo 2

Entidade carto
Cartao(codigo,data_inicio_uso,data_fim_uso)
O atributo cdigo foi definido como chave primria.
Est em Primeira Forma Normal, pois todos os seus atributos so atmicos.
A entidade cartao est em Segunda Forma Normal, pois sua chave primria no
composta.
Vamos verificar a dependncia funcional da entidade cartao:
codigogdata_inicio_uso
codigogdata_fim_uso
Logo, a entidade cartao est em Terceira Forma Normal, pois todos os atributos
so dependentes funcionalmente da chave primria.
A entidade cartao est na Forma Normal Boyce-Codd, pois todos os seus atributos no chave dependem unicamente da chave primria.
Cartao(codigo,data_inicio_uso,data_fim_uso)
Tendo o atributo codigo como chave primria.

Entidade Produto
Produto(codigo,nome,preco_venda,saldo,estoque_minimo)
Tendo o campo codigo como chave primria.
Est em Primeira Forma Normal, pois ela no possui atributos multivalorados
e atributos compostos.
A entidade produto est em Segunda Forma Normal, pois sua chave primria
no composta. Analisando sua dependncia funcional, temos:
codigo gnome
codigo gpreco_venda
codigo gsaldo
codigo gestoque_minimo
A entidade produto est em Terceira Forma Normal, pois todos os atributos no
chave dependem funcionalmente da chave primria. A entidade produto est na
Forma Normal Boyce-Codd, pois todos os atributos no chave so dependentes
apenas da chave primria.

Entidade funcionario
Funcionario(codigo,nome,funcao)

74

Tendo o atributo codigo como chave primria.

Est em Primeira Forma Normal, pois no possui atributos multivalorados nem
atributos calculados.
A entidade funcionario est em Segunda Forma Normal, pois no possui chave
primria composta.
Verifiquemos a dependncia funcional da entidade funcionario:
codigo gnome
codigo gfuncao
A entidade funcionario est em Terceira Forma Normal, pois todos os seus atributos no chave so dependentes da chave primria.
A entidade funcionario est na Forma Normal Boyce-Codd, pois todos os atributos no chave dependem apenas da chave primria.
Funcionario(codigo,nome,funcao)
Tendo o campo codigo como chave primria

Entidade Fornecedor
Fornecedor(codigo,nome,rua,complemento,bairro,cidade,estado,cep,
contato,telefone,celular)
Tendo o atributo codigo como chave primria.
Est em Primeira Forma Normal, pois no possui atributos multivalorados nem
atributos calculados.
A entidade fornecedor est em Segunda Forma Normal, pois sua chave primria
simples.
Anlise da dependncia funcional da entidade fornecedor.
codigo g nome
codigo g rua
codigo g complemento
codigo g bairro
codigo g cidade
codigo g estado
codigo g cep
codigo g contato
codigo gtelefone
codigo gcelular
75

Informtica 3

captulo 2

A entidade fornecedor est em Terceira Forma Normal, pois todos os atributos no chave dependem funcionalmente da chave primria.
A entidade fornecedor est na Forma Normal Boyce-Cood, pois todos os
seus atributos no chave dependem apenas da chave primria.

Entidade compra

Tendo como chave primria os atributos numero_nota, codigo_fornecedor e codigo_produto e como chaves estrangeiras codigo_fornecedor e codigo_produto.
A entidade Fornece est em Primeira Forma Normal, pois todos os seus atributos so atmicos. Vale verificar a dependncia funcional dessa entidade.
numero_nota,cod_fornecedor,cod_produto g data
numero_nota,cod_fornecedor,cod_produto g valor_total
numero_nota,cod_produto g quantidade
numero_nota,cod_produto g valor_unitario

Compra(numero,data,forma _ Pag to,codigo_produto,codigo_

cartao,quantidade,valor_unitario,valor_total_compra)
Tendo como chave primria os atributos numero, codigo_cartao e codigo_produto e como chaves estrangeiras os atributos codigo_cartao e codigo_produto.
Est em Primeira Forma Normal, pois todos os seus atributos so atmicos.
Verificando a dependncia funcional da entidade compra, temos:
numero,codigo_cartao,cod_produto g data
numero,codigo_cartao,cod_produto g forma_Pagto
numero,cod_produto g quantidade
numero,cod_produto g valor_unitario
Nem todos os atributos dependem da chave primria, ento, para deixar a
entidade compra em Segunda Forma Normal, devemos desmembr-la (compra e ItemCompra), assim:

Nem todos os atributos no chave dependem completamente da chave, logo

preciso desmembrar seus atributos:
Fornece(numero_nota,cod_fornecedor, data,valor_total)
Ficando como chave primria os atributos numero_nota e cod_fornecedor e
como chave estrangeira o atributo cod_fornecedor.
ItemFornece(numero_nota,cod_produto,quantidade,valor_unitario)
Tendo como chave primria os atributos numero_nota e cod_produto e como
chaves estrangeiras os atributos numero_nota e cod_produto.
A entidade Fornece est em Segunda Forma Normal, pois todos os atributos
no chave dependem completamente da chave.
A entidade ItemFornece est em Segunda Forma Normal, pois todos os
atributos no chave dependem completamente da chave.
A entidade Fornece est em Terceira Forma Normal, pois todos os seu atributos no chave dependem da chave primria
A entidade ItemFornece est em Terceira Forma Normal, pois todos os seus
atributos no chave dependem da chave primria.
A entidade Fornece est na Forma Normal Boyce-Codd, pois todos os atributos no chave dependem unicamente da chave primria.
A entidade ItemFornece est na Forma Normal Boyce-Codd, pois todos os
atributos no chave dependem unicamente da chave primria.

Compra (numero, cod_cartao,data,valor_total_compra,forma_

pagto)
E com a chave primria contendo o atributo numero e a chave estrangeira cod_
cartao.
ItemCompra(numero,cod_produto,quantidade,valor_unitario)
Com chave primria contendo os atributos numero e cod_produto e como chaves estrangeiras os atributos numero e cod_produto.
A entidade Compra encontra-se em Segunda Forma Normal.
A entidade ItemCompra encontra-se em Segunda Forma Normal.
A entidade Compra encontra-se em Terceira Forma Normal, pois como vimos na verificao da dependncia funcional, todos os atributos no chave
dependem da chave.
A entidade Compra est na Forma Normal Boyce-Codd, pois todos os atributos no chave dependem unicamente da chave primria.
A entidade ItemCompra est na forma normal Boyce-Codd, pois todos os
atributos no chave dependem unicamente da chave primria.

Entidade fornece
Fornece (numero_nota, data, codigo_fornecedor,codigo_produto,
quantidade, valor_unitario)
76

H outros passos a serem seguidos at o nosso modelo ser implementado, mas,

s para entendermos o que as entidades representam, vejamos como ficaro as
entidades da padaria do senhor Joo depois de implementadas. Em nossa representao tabela Compra, a primeira linha o nome da tabela (entidade), a segunda
linha os nomes dos campos (atributos) e a partir da terceira linha so as informaes armazenadas que chamamos de registros ou tuplas. Veja como os relacionamentos permitem entender perfeitamente as informaes gravadas nas tabelas.

Compra

numero
132
133
134

cod_cartao
3
2
6

data
21/05/2009
21/05/2009
23/05/2009

forma_pagto
dinheiro
dinheiro
cartao

valor_total compra
10,60
13,60
52,20

77

Informtica 3

captulo 2

Vamos analisar, por exemplo, a tabela ItemCompra. Veja que a soma dos itens
da compra de cdigo 132 (campos quantidade *valor_unitario) o mesmo valor gravado no campo valor_total_compra da tabela compra. Isto integridade
de dados. Aproveite para olhar detalhadamente para as demais tabelas, para
entender como os atributos se transformam em campos e como esses campos
se relacionam, permitindo acesso rpido e eficiente s informaes. Olhe agora
para as tabelas Fornecedor, Fornece e ItemFornece. S de olhar, j sabemos que,
no dia 21/05/2009, o senhor Joo comprou do senhor Pedro Parente 120 litros
de leite B e dois achocolatados em p.

ItemCompra
numero_nota

132

132

cod_produto
2
3

quantidade
2
1

valor_unitario
3,20
4,20

Como sabemos disso? Veja o caminho que fazemos saindo de Fornece indo para
ItemFornece; veja a implementao do relacionamento, pois os campos numero_nota das duas tabelas tem o valor 1 e o cdigo do produto de ItemFornece
equivale aos produtos leite B e achocolatado em p. Vemos agora na prtica o que
definimos na teoria. Preste ateno nas outras tabelas e veja se voc acha mais informaes interessantes. Olhe tambm a importncia dos atributos chave primria e chave estrangeira em nossa implementao. Ainda h muito o que aprender
para que os modelos se transformem em sistemas de qualidade, mas agora j se
sabe como os modelos se transformam em banco de dados de aplicaes.

Fornecedor

Codigo Nome

Rua

Complemento Bairro

Cardoso Alimentos Rua 2 n 32

Cidade Estado cep

Jd. Boa Esperana Campinas

SP

Contato Telefone

Celular

12123-123 Sr. Cardoso 99-3234-0000 99-9999-0000

Maria Doceria

Rua 34 n 123 Atrs da Igreja

Centro

Hortolndia SP

12123-123 D. Maria

Pedro Parede

Rua 4 n 120

Jd. Cachoeira

Caldas

04321-789 Sr. Pedro

MG

FuncionArio
Codigo Nome

1
Sr. Joo

2
Laercio da Silva

3
Maria padilha

Funo
Dono
Padeiro
Atendente

2.3. Fases de um projeto utilizando o modelo ER

No caso fictcio da padaria do senhor Joo, descobrimos, por meio de um relato, como a padaria funcionava e quais eram as expectativas de seu dono em
relao a como passaria a operar e ao tipo de informao que o novo sistema lhe
permitiria obter. Na vida real, dificilmente acontece aquela sequncia de aes
idealizadas para compor o exemplo. Geralmente, o usurio (cliente) no sabe
muito bem do que precisa, quando decide informatizar algum processo do seu
negcio. Ns que devemos nos aproximar dele para reunir elementos que permitam desenvolver a soluo que o atenda da melhor forma. preciso tambm
oferec-la de acordo com o escopo esperado, isto , construda dentro do prazo
solicitado e com o oramento disponvel. Sim, porque para viabilizar um projeto
essa dualidade fundamental: a correta conjuno de tempo combinado e cujo
valor esteja dentro do investimento que o cliente est disposto a fazer.
No , portanto, uma tarefa fcil. Corre-se o risco da perda de foco e de ritmo
de trabalho, se no forem usadas tcnicas que sinalizem corretamente e facilitem
nosso caminho. Felizmente, h um roteiro para a criao de solues informatizadas que utilizam o Modelo de Entidade e Relacionamento, um guia que pode
nos conduzir a um bom resultado final, ou seja, o projeto pronto e instalado na
empresa do cliente (figura 33).

Figura 33
Roteiro para
criar uma soluo
informatizada.

99-9999-8976 87-9999-0000

fornece
numero_nota cod_fornecedor

1
3

2
2

4
6

data
21/05/2009
21/05/2009
23/05/2009

valor_total
123,12
34,20
48,90

Itemfornece
numero_nota cod_produto

1
2

1
3

quantidade
120
2

valor_unitario
1,00
1,56

Produto
Codigo Nome
2
Leite B.
3
Achocolatado em p
15
Leite condensado

78

Preo_Venda Saldo
1,89
32
3,45
13
2,11
54

estoque_Minimo
4
2
12

79

Informtica 3

captulo 2

O roteiro oferece uma srie de indicaes a seguir at que se alcance o produto

final o software implementado. H, porm, algumas hipteses que podem
alterar os rumos do projeto. Durante seu desenvolvimento, podemos concluir,
por exemplo, que a soluo inicialmente imaginada no econmica ou tecnicamente vivel; ficar cara demais, sem proporcionar o resultado esperado, no
prazo estabelecido. Pode-se at concluir que no h necessidade de uma soluo
informatizada para o problema proposto, sugerindo que seja resolvido apenas
por meio de uma simples mudana de procedimento (incluso e/ou alterao de
aes dos usurios no processo).

DICA

80

2.3.3. Anlise de requisitos

Vale, ento, conhecer e analisar em detalhes cada um dos passos sugeridos no

roteiro, para ento aplic-los ao nosso projeto para a padaria do senhor Joo.
Verificaremos, assim, quais pontos devem ser levados em conta em cada passo e
qual ser o produto final para cada fase proposta. Comecemos pelo minimundo.

Entendida a dinmica de funcionamento de nosso minimundo e obtidas as informaes relevantes ao foco da soluo imaginada, hora de analisar essas informaes, separ-las e classific-las de forma podermos continuar a desenvolvla, verificando inclusive se a melhor opo mesmo informatizar, e, em caso
positivo, se haver mesmo condies de satisfazer as necessidades do usurio
no prazo previsto. O primeiro passo, agora, separar os requisitos levantados e
classific-los em requisitos de dados e requisitos funcionais. Mas, antes de tudo,
resta esclarecer bem quais so esses requisitos.

2.3.1. Minimundo

2.3.4. Requisitos de dados

O minimundo geralmente o ponto inicial do trabalho a parte do mundo

real que o foco do projeto ou de nossa anlise. No nosso caso, a padaria do
senhor Joo. Usaremos as tcnicas descritas no captulo 1, para conhecer melhor
o funcionamento da empresa, em especial o foco do problema, de acordo com
os pontos levantados pelo senhor Joo: a dinmica do atendimento ao pblico,
o processo de compra e venda de mercadorias e a necessidade de reposio de
estoques no prazo desejvel.

Trata-se, aqui, de toda e qualquer informao relevante para a soluo em anlise, tanto as geradas quanto as consultadas com o objetivo de concluir determinada tarefa. Por exemplo, a quantidade e o valor do produto comprado, ou seja,
o montante do pagamento, so requisitos de dados que devem ser classificados
para que se possa construir um modelo de dados.

2.3.2. Levantamento de requisitos

So aqueles que descrevem funcionalidades e servios do sistema. Tal definio

depender do tipo do software, dos resultados esperados e do tipo do sistema
em que o software ser aplicado. Exemplos: o sistema deve oferecer diversas
maneiras de visualizar os dados, de acordo com o perfil do usurio; os relatrios

Por meio das tcnicas que estudamos no captulo anterior, vamos levantar os
requisitos para a soluo do problema proposto. Avaliaremos, portanto, o tamanho do problema, o que se espera da soluo, quem so os usurios chave,
quais processos esto envolvidos e o que cada um desses processos oferece de
informao relevante soluo que estamos buscando.

Desde o incio,
as informaes
levantadas no
cliente devem ser
registradas para que
se tornem base de
nosso entendimento
do problema e
referncia para
consulta posteriores.

lhor relao possvel com as pessoas envolvidas no processo, deixando clara sua
importncia para o trabalho, mesmo depois que tivermos encerrado a fase de
levantamento de requisitos.

Quem pode nos dar essas respostas so os usurios e seus procedimentos. Lembre-se de que devemos escolher uma ou mais tcnicas descritas para conhecer
bem o problema.

DICA

Lembre-se: podem
surgir dvidas em
qualquer fase do
desenvolvimento
do projeto e voc
precisar de mais
informaes
e opinies do
usurio at o fim
do processo.

2.3.5. Requisitos funcionais

Figura 34
As vrias
operaes do
negcio padaria.

De incio, podemos recorrer aos mtodos de entrevista para obter informaes

do senhor Joo e seus funcionrios com o objetivo de compreender o funcionamento da padaria. Tambm podemos observar os funcionrios em seu dia-a-dia
para verificar a dinmica do trabalho, suas rotinas, particularidades e informaes geradas nas diferentes operaes. Para cada entrevista, procedimento ou
etapa necessrio produzir uma documentao, isto , anotar de forma clara
e isenta as informaes obtidas e suas fontes (quem nos deu tal informao,
como chegamos a determinada concluso). Este procedimento nos permitir
construir uma base de apoio que poderemos consultar sempre que surgir alguma dvida em relao ao processo ou soluo imaginada. Cada passo tambm
pode nos apontar novas informaes a analisar ou procedimentos a seguir, alm
de meios de sanar dvidas que eventualmente surjam no caminho e indicaes
sobre quem pode nos ajudar a dirimi-las. fundamental, ainda, cultivar a me81

Informtica 3

captulo 2

tm de ficar disponveis para impresso, de acordo com o nvel hierrquico de

cada um deles. Para saber qual esse nvel, necessrio que ele se identifique no
sistema, digamos, por meio de uma rotina de login, em que ele se apresente via
senha, geralmente criada por ele mesmo.
Podemos considerar requisitos funcionais tambm a manuteno, isto ,
incluso/alterao/excluso e consulta de todas as entidades identificadas
na soluo.
Observe que narramos a situao atual da padaria do senhor Joo, isto , sem
a soluo informatizada, e a submetemos s regras de requisitos que definimos
no captulo anterior (necessrio, no-ambguo, verificvel, conciso, alcanvel,
completo, consistente, ordenvel e aceito). Agora, avaliemos as operaes envolvidas nas vendas (figura 34).

Continuando nossa anlise:

3 - Larcio pega o saco de papel adequado a tal quantidade, vai at a cesta de pes
e com o pegador coloca no saco os dez pezinhos. Em seguida, fecha o saco,
coloca-o sobre a balana e digita no equipamento o preo do quilo do po.
Temos de importante aqui que o funcionrio pesa o produto, digitando
o preo do quilo na balana.

Situao
A senhora Maria vai at o balco de pes e solicita dez pezinhos ao funcionrio
Larcio, que est atendendo naquele momento.
Larcio pega o saco de papel adequado a tal quantidade, vai at a cesta de pes
e com o pegador coloca no saco os dez pezinhos. Em seguida fecha o saco,
coloca-o sobre a balana e digita, no equipamento, o preo do quilo do po.
Toma ento um pedao de papel que est sobre o balco no qual anota o peso
dos pes e o valor apresentado na balana, alm da palavra po, e entrega o
pacote e o pedao de papel senhora Maria, perguntando-lhe se vai querer
mais alguma coisa.

4 - Toma, ento, um pedao de papel que est sobre o balco no qual anota o
peso dos pes e o valor apresentado na balana, alm da palavra po; entrega
o pacote e o pedao de papel senhora Maria, perguntando-lhe se vai querer
mais alguma coisa.

Como separar requisitos de dados de requisitos funcionais nesta situao ?

Primeiro, vamos tentar simplificar o problema, selecionando apenas as informaes relevantes. Para isso, vamos reconstruir quadro a quadro a situao,
formulando algumas perguntas:

Em resumo:
O cliente solicita uma quantidade de um certo produto ao funcionrio.

1 - A senhora Maria vai at o balco de pes e solicita dez pezinhos ao funcionrio Larcio, que est no balco neste momento.
Quais so os requisitos importantes para nossa soluo nesta frase?
A senhora Maria se deslocar at o balco de pes no um requisito
relevante, pois no nos interessa, no momento, como ela chegou ao
balco e sim o que fez ao chegar l.

2 - Solicita dez pezinhos ao funcionrio Larcio que est atendendo naquele

momento.
Ou seja, a senhora Maria (a cliente) solicita dez pezinhos (dez unidades do
produto pozinho) para o funcionrio Larcio que est no balco.
Conclumos, aqui, que o cliente solicita uma certa quantidade de um
determinado produto a certo funcionrio.

82

Larcio ser o funcionrio que est no balco no momento, e a senhora Maria

a cliente, so informaes que nos demostram apenas que h um funcionrio
e um cliente envolvidos na ao.

Aqui temos que:

funcionrio anota a quantidade, o tipo de produto
e seu preo em um pedao de papel e o entrega ao cliente.

O funcionrio pesa o produto, digitando o preo do quilo na balana.

O funcionrio anota a quantidade, o produto e seu preo em um pedao de
papel e o entrega ao cliente.
Antes de separarmos os requisitos funcionais dos requisitos de dados, precisamos pensar se as trs aes descritas no resumo fazem parte do escopo de nosso
projeto. Vejamos.
O cliente pedir o produto e o empregado separ-lo no so fatos relevantes na situao, pois so aes que no sero alteradas: o cliente continuar a pedir os produtos
aos funcionrios e os procedimentos a seguir continuaro sendo os mesmos.
O que importa, ento, que o funcionrio anota a quantidade, o produto e
seu preo em um pedao de papel e o entrega ao cliente.

A temos uma ao que ser modificada por nossa soluo, pois sabemos que
o senhor Joo quer que o cliente entregue um carto ao funcionrio, que nele
registrar as compras e o devolver ao cliente.
83

Informtica 3

captulo 2

Os requisitos de dados contidos nesta situao so: funcionrio, quantidade de

produto, valor total de produto, nome do produto e do cliente. J o requisito funcional : anota, pois o funcionrio dever anotar os itens comprados pelo cliente.
Requisitos colhidos at agora.
Ao terminar a anlise dessa parte do problema, teremos:
Requisitos de dados: funcionrio, quantidade comprada, valor total do produto e descrio do produto.
Requisitos funcionais: funcionrio anota itens solicitados pelo cliente, isto
, o funcionrio dever ter um lugar no sistema para anotar as compras
do cliente.

2.3.6. Projeto conceitual

Depois de analisar e classificar todos os requisitos levantados, devemos nos concentrar nos requisitos de dados, agrupando-os em entidades e relacionamentos.
Ao pensarmos nas entidades, devemos verificar quais so as informaes relevantes em vrios aspectos, seguindo os sete passos propostos no tpico Modelo
de entidade e relacionamento, estudado no incio deste captulo, para montar o
diagrama de entidade e relacionamento, que vai retratar nosso modelo conceitual e classificar as entidades geradas segundo as regras de normalizao. Nosso
projeto conceitual ficar como sugere a figura 35.

Depois de escolher o SGBD, devemos verificar quais so os tipos de dados que

este aceita, bem como seus tamanhos, pois tais caractersticas variam muito. Existem quatro tipos bsicos de dados: texto, nmero, data e hora. Para a padaria do
senhor Joo, usaremos o Banco de dados MySQL. Com essa definio, podemos
passar etapa seguinte: fazer o projeto lgico das entidades e relacionamentos com
os campos que usaremos na soluo. preciso definir os atributos de cada entidade, alm de tipo, tamanho e obrigatoriedade ou no de cada atributo, e, ainda,
avaliar se o atributo chave primria ou estrangeira e se nico. Resta conhecer o
significado das classificaes dos atributos (Leia o quadro abaixo).
Significados e dicas
Nome

palavra que indique o atributo no contexto da

entidade; deve-se evitar, o uso de abreviaes e
nmeros.

Tipo

indica a forma como o atributo ser armazenado

(data, texto, nmero, etc.).

Tamanho

expressa o nmero de caracteres que o atributo

ocupar na entidade.
preciso cuidado para definir o tamanho do
atributo para que no se crie problemas difceis de
resolver no futuro, pois alterar o tamanho de um
atributo, depois que o sistema est em produo,
implica alterar todas as telas e relatrios nos quais
tal atributo aparece. Por exemplo, se criarmos o
campo cdigo da tabela cliente com 3 posies,
podero ser cadastrados no mximo 999 clientes,
o que representar uma limitao no sistema.

Obrigatrio

define se este atributo tem de ser preenchido

para que se possa incluir uma informao nesta
entidade ou no.

nico

o atributo deve ser definido como nico, quando

seus valores no puderem ser repetidos.

Chave
primria

atributo ou conjunto de atributos que definem um

nico registro (tupla) em uma entidade.

Chave
estrangeira

atributo ou conjunto de atributos que garante

o relacionamento entre duas ou mais entidades.
Assegura o que chamamos de integridade
referencial, isto , se as tabelas devem ou no
possuir uma informao cadastrada para permitir
seu uso em outra tabela.

Valor default

indica se o atributo tem um valor padro de

preenchimento.

Regra de
validao

demonstra se o atributo possui ou no uma regra

de preenchimento. Por exemplo: o atributo sexo
s pode receber valores M ou F.

2.3.7. Projeto lgico

Figura 35
A aplicao
do diagrama
de entidade e
relacionamento,
na prtica.

Com o projeto conceitual montado, precisamos, agora, definir o Sistema

Gerenciador de Banco de Dados (SGBD) que empregaremos para implementar nossa soluo de software. Existem inmeras opes de SGBD no
mercado, em uma gradao de valor que vai dos gratuitos aos bastante
caros. Todos implicam vantagens e desvantagens, que voc dever analisar
juntamente com os demais participantes do projeto.

Diagrama de entidade e relacionamento da padaria do sr. Joo

84

85

Informtica 3

captulo 2

Tabelas
So inmeras as formas de apresentar as definies alinhadas, e utilizaremos a
mais comum, a tabela. Ento, por meio de tabelas, vamos criar o modelo lgico
das entidades da soluo imaginada para a padaria do senhor Joo. As entidades
e relacionamentos com campos passam a ser chamados de tabelas e seus atributos de campos. Observe o exemplo, na tabela Carto.

cartao


nome

codigo

tipo de
tamanho obrigatorio unico
dados

chave
chave
valor
regra de
primaria estrangeira default validacao

INTEGER

Sim

Sim

Sim

No

No

No

dt_Inicio_uso

DATE

Sim

No

No

No

No

No

dt_fim_uso

DATE

No

No

No

No

No

No

Observao: O campo dt_fim_uso foi definido como no obrigatrio, pois nenhum

dos cartes, quando de seu cadastro, tem data indicando fim de prazo de validade.
Veja as tabelas Produto, Funcionario, Fornecedor, Fornece, ItemFornece e Compra.

Produto
nome

tipo de
tamanho obrigatorio unico
dados

chave
chave
valor
regra de
primaria estrangeira default validacao

codigo

INTEGER

Sim

Sim

Sim

No

No

No

nome

VARCHAR

40

Sim

No

No

No

No

No

preco_venda

DECIMAL

10,2

Sim

No

No

No

No

Valor > 0

saldo

DECIMAL

10,2

Sim

No

No

No

Valor >=0

estoque_minimo DECIMAL

10,2

Sim

No

No

No

Valor >=0

Observao: O campo saldo foi definido com decimal, porque nem sempre os
produtos so vendidos em unidades.

Funcionario
nome

codigo

nome
funo

tipo de
tamanho obrigatorio unico
dados
INTEGER
VARCHAR
VARCHAR

4
50
30

O melhor SGBD

Sim
Sim
Sim

Sim
No
No

chave
chave
valor
regra de
primaria estrangeira default validacao
Sim
No
No

No
No
No

No
No
No

No
No
No

Definir qual Sistema Gerenciador de Banco de Dados devemos adotar em uma soluo informatizada
nem sempre fcil. Precisamos levar em conta seu preo, sua forma de comercializao, seus custos
adicionais (valor da manuteno anual, preo por usurio etc.), estrutura de hardware que a soluo
demandar (rede, stand-alone, internet), grau de segurana, tipos de acesso, formas de gerenciamento
de informaes. Todos esses fatores tm de ser considerados, para chegar melhor soluo.

86

Fornecedor
nome

tipo de
tamanho obrigatorio unico
dados

chave
chave
valor
regra de
primaria estrangeira default validacao

codigo

INTEGER

Sim

Sim

Sim

No

No

No

nome

VARCHAR

50

Sim

No

No

No

No

No

rua

VARCHAR

50

Sim

No

No

No

No

No

complemento VARCHAR

50

No

No

No

No

No

No

bairro

VARCHAR

40

No

No

No

No

No

No

cidade

VARCHAR

40

Sim

No

No

No

No

No

estado

VARCHAR

Sim

No

No

No

No

No

cep

VARCHAR

Sim

No

No

No

No

No

telefone

VARCHAR

10

No

No

No

No

No

No

celular

VARCHAR

10

No

No

No

No

No

No

Observao: Um campo do tipo varchar permite at 255 caracteres, mas o tamanho de campos como rua, por exemplo, deve ir no mximo at 50 caracteres.
Isso porque talvez seja preciso emitir etiquetas de endereamento e como o faremos se o campo rua tiver 255 caracteres? O campo CEP tambm foi colocado
como obrigatrio, para que o usurio se lembre de preench-lo.
Os campos telefone e celular so do tipo varchar, pois o zero esquerda significativo, isto , 01 diferente de 1.

fornece
nome

tipo de
tamanho obrigatorio unico
dados

chave
chave
valor
regra de
primaria estrangeira default validacao

numero_nota

INTEGER

Sim

Sim

Sim

No

No

No

cod_fornecedor INTEGER

Sim

No

Sim

Sim

No

Fornecedor

j deve ser

cadastrado

data

DATE

Sim Fornece
No

No

No

No

No

valor_total

DECIMAL

10,2

Sim

No

No

No

Soma dos

No

itens de

itemfornece

para esta

nota.

87

Informtica 3

captulo 2

ItemFornece
nome

tipo de
tamanho obrigatorio unico
dados

chave
chave
valor
regra de
primaria estrangeira default validacao

numero_nota INTEGER

Sim

Sim

Sim

Sim

No

No

cod_produto INTEGER

Sim

No

Sim

Sim

No

Produto j

deve ser

cadastrado

quantidade

valor_unitario DECIMAL

DECIMAL

5,2

Sim

No

No

No

No

No

10,2

Sim

No

No

No

No

>0

Compra
nome

tipo de
tamanho obrigatorio unico
dados

chave
chave
valor
regra de
primaria estrangeira default validacao

numero
INTEGER
7
Sim
Sim
Sim
No
No

cod_cartao
INTEGER
8
Sim
No
No
Sim
No


data
DATE
8
Sim
No
No
No
No
forma_pagto VARCHAR
10
Sim
No
No
No
No
valor_total_ DECIMAL
10,2
Sim
No
No
No
No
compra

AutoNumerao
Carto j
deve ser
cadastrado
No
No
Soma
dos valores
dos itens de
itemcompra
para esta
compra

cod_func_
INTEGER
Sim
No
No
Sim
No
caixa

Funcionrio
deve ser
cadastrado

ItemCompra
nome

tipo de
tamanho obrigatorio unico
dados

chave
chave
valor
regra de
primaria estrangeira default validacao

numero_nota INTEGER

Sim

Sim

Sim

No

No

No

cod_produto INTEGER

Sim

No

Sim

Sim

No

Produto j

deve ser

cadastrado

No

quantidade

DECIMAL

5,2

Sim

No

No

No

No

valor_unitario DECIMAL
10,2
Sim
No
No
No
No

88

Valor do
campo preco_
venda da
tabela produto
quando da
incluso da
nota.

Observao: Um campo autonumerao um campo numrico, que ter seu valor sequencial preenchido pelo prprio SGBD. Mas importante frisar que nem
todo Sistema Gerenciador de Banco de Dados (SGBD) possui esse campo. Por
isso, preciso verificar essa disponibilidade conforme o sistema adotado. Veja que
o campo cod_func_caixa no estava definido no projeto lgico, mas, ao analisar
as funcionalidades, verificou-se que o senhor Joo quer saber quem recebeu pela
compra e, assim, foi necessrio possibilitar o registro desta informao, a qual
servir tambm para indicar se determinada compra j foi paga ou no.

2.3.8. Projeto fsico

O projeto fsico consiste na traduo do modelo lgico para a linguagem SQL.
Normalmente, feito um script (lista dos comandos de criao do banco de dados e de suas tabelas dentro do SGBD). Os comandos para gerar as tabelas em
SQL sero estudados no prximo captulo, mas como exemplo, vem a seguir o
projeto fsico de nosso estudo de caso para o SGBD MySQL.
CREATE DATABASE Padaria;
USE Padaria;

DICA

A definio das tabelas

do modelo lgico deve
ser feita com muita
ateno e cuidado, pois
podemos facilitar, e
muito, a implementao
da soluo, por exemplo,
incluindo campos
como obrigatrios e
definindo regras de
incluso e alterao.
Dessa forma, colocamos
no SGBD parte da
responsabilidade pela
consistncia dos dados
e aliviamos os programas
que faro a entrada e a
manipulao de dados.

CREATE TABLE Cartao (

codigo INTEGER NOT NULL PRIMARY KEY,
dt_inicio_uso DATE NOT NULL,
dt_fim_uso DATE);

CREATE TABLE Produto (

codigo INTEGER NOT NULL PRIMARY KEY,
nome VARCHAR(40) NOT NULL,
preco_venda DECIMAL(10,2) NOT NULL,
saldo DECIMAL(10,2) NOT NULL,
estoque_minimo DECIMAL(10,2) NOT NULL);

CREATE TABLE Funcionario (

codigo INTEGER NOT NULL PRIMARY KEY,
nome VARCHAR(50) NOT NULL,
funcao VARCHAR(30) NOT NULL);
CREATE TABLE Fornecedor (
codigo INTEGER NOT NULL PRIMARY KEY,
nome VARCHAR(50) NOT NULL,
rua VARCHAR(50) NOT NULL,

89

Informtica 3

captulo 2

complemento VARCHAR(50),
bairro VARCHAR(40),
cidade VARCHAR(40) NOT NULL,
estado VARCHAR(2) NOT NULL,
cep VARCHAR(8) NOT NULL,
telefone VARCHAR(10),
celular VARCHAR(10));

CREATE TABLE Fornece(

numero_Nota INTEGER NOT NULL PRIMARY KEY,
cod_Fornecedor INTEGER NOT NULL REFERENCES
Fornecedor(codigo),
data DATE NOT NULL,
valor_Total DECIMAL(10,2) NOT NULL),
PRIMARY KEY (numero_Nota,cod_Fornecedor));
CREATE TABLE ItemFornece (
numero_Nota INTEGER NOT NULL REFERENCES
Fornece(numero_Nota),
cod_Produto INTEGER NOT NULL REFERENCES
Fornecedor(codigo),
quantidade DECIMAL(5,2) NOT NULL,
valor_Unitario DECIMAL(10,2) NOT NULL,
PRIMARY KEY (numero_Nota,cod_Produto));

CREATE TABLE compra(

numero INTEGER NOT NULL PRIMARY KEY,
cod_Cartao INTEGER NOT NULL REFERENCES
Cartao(codigo),
data DATE NOT NULL,
forma_Pagto VARCHAR(10) NOT NULL,
valor_Total_Compra DECIMAL(10,2) NOT NULL,
cod_Func_Caixa INTEGER NOT NULL REFERENCES
Funcionario(codigo));

CREATE TABLE ItemCompra (

numero_Nota INTEGER NOT NULL REFERENCES
Compra(numero),
cod_Produto INTEGER NOT NULL REFERENCES
Fornecedor(codigo),
quantidade DECIMAL(5,2) NOT NULL,
valor_Unitario DECIMAL(10,2) NOT NULL,
PRIMARY KEY (numero_Nota,cod_Produto));

90

2.3.9. Anlise funcional

Analisando os requisitos funcionais que encontramos na fase de anlise de requisitos, sero escolhidas as rotinas a serem criadas para que todas as funcionalidades de nosso projeto sejam atendidas. Uma rotina do sistema pode automatizar mais de um requisito funcional anteriormente definido. Por exemplo, a
digitao de uma nota fiscal de compra de mercadorias para a padaria do senhor
Joo implementar no apenas as tabelas Fornece e ItemFornece, mas atualizar
o saldo do produto na tabela Produtos, podendo alterar tambm o valor do
campo preo de venda daquele item. Se analisarmos os requisitos funcionais do
sistema proposto para a padaria teremos, pelo menos, as seguintes rotinas:
Manuteno de cartes
Manuteno de funcionrios
Manuteno de fornecedores
Manuteno de produtos
Registro de produto vendido pelos atendentes
Apresentao da somatria da compra, recebimento da compra
e marcao de qual funcionrio recebeu determinada compra
Lanamento da Nota Fiscal de Entrada
Controle de acesso do usurio
Opes de seleo de rotinas disponveis para o usurio
do sistema, de acordo com seu nvel de acesso
Consulta de preos de produtos.
Aps a definio das rotinas e dos requisitos funcionais que elas implementaro,
deve-se separ-las em mdulos de acordo com a caracterstica de cada uma. Assim,
formam-se grupos de rotinas que implementam requisitos semelhantes, a fim de se
criar uma estrutura lgica e funcional de acesso s principais funcionalidades do
sistema, permitindo, tambm, o controle de acesso a tais funcionalidades.
No caso do nosso exemplo fictcio, a padaria do senhor Joo, temos alguns grupos
de requisitos que tratam da manuteno das tabelas cadastrais do sistema as tabelas
de produto, funcionrio, carto e fornecedor. Podemos nominar as funcionalidades
comuns a essas rotinas como, por exemplo, a manuteno de informaes cadastrais.
Pode-se dizer que os requisitos de registrar um produto em um carto, lanar uma
nota fiscal de um fornecedor, ou registrar o pagamento de uma venda descrevem a
movimentao da padaria, logo cabe inclu-los no grupo de rotinas de movimentao
do sistema da padaria. Haver, ainda, grupos para as consultas e relatrios do sistema,
nos quais sero reunidas as rotinas que implementaro essas funcionalidades.
A engenharia de software oferece vrias tcnicas para separar as rotinas do sistema em mdulos, como o Diagrama Hierrquico de Funes ou os Diagramas
de Pacotes e de Componentes, que veremos no captulo 4.

2.3.10. Projeto de programas da aplicao

A partir de agora, vamos utilizar vrios conceitos relacionados ao desenvolvimento de software. Primeiro ser preciso definir a linguagem de programao
que adotaremos para implementar a soluo. Para isto, temos de levar em conta
o ambiente em que o sistema ser implementado, ou seja, o sistema operacional
91

Informtica 3

captulo 2

instalado. Tambm preciso considerar a estrutura de hardware definida para a

soluo: se o programa ser implantado em uma rede de computadores, qual
sua arquitetura e onde ficaro instalados a aplicao e o Sistema Gerenciador de
Banco de Dados (SGDB), tema, alis, que veremos mais adiante.
Definir um padro para a interface com o usurio (isto , das telas a serem exibidas pelo sistema), assim como fontes, cores, formato e tamanho dos elementos das
telas (como botes, barras de menu, caixas de texto etc.), requer o conhecimento
prvio de detalhes da estrutura em que nossa soluo ser implementada. Nem
sempre os diversos ambientes nos permitem trabalhar com todos esses recursos.
interessante definir essa interface com o usurio e para isso geralmente usamos a tcnica de prototipagem, definida no captulo 1. Assim, montamos um pequeno prottipo s com a tela a ser exibida e o apresentamos ao cliente para que ele tenha uma ideia
de como a visualizar e de como poder interagir com as informaes que solicitou.
o momento, ento, de definir o funcionamento de cada programa a ser criado
para a implementao da soluo. Tambm para essa tarefa existem vrias tcnicas, tais como a descrio em portugus estruturado do funcionamento de cada
programa, o uso de diagramas da UML (diagrama de classes, de sequncia, e de
mquina de estados, que sero vistos no captulo 4 deste livro). O que deve ficar
claro como o programa ser construdo para implementar a rotina definida,
em relao interface com o usurio e ao seu prprio funcionamento, a conexo
com o sistema gerenciador de banco de dados e a arquitetura de hardware e
software onde a soluo ser instalada.
Devemos definir tambm o plano de testes a que devem ser submetidos cada um
dos programas em vias de criao, a fim de validar seu correto funcionamento.

2.3.11. Implementao da Transao

Com as definies em mos, partimos para a programao e os testes das rotinas na
linguagem definida. medida em que essas rotinas vo sendo concludas, devemos
elaborar um ambiente de testes que simule o meio do usurio para que se possa
analisar o funcionamento do sistema como um todo, isto , com todos os programas em funcionamento. Nesse momento, importante certificar-se de que todos os
programas esto executando suas tarefas corretamente, de que o banco de dados est
sendo atualizado de forma consistente e de que a estrutura de hardware e software
est permitindo o funcionamento correto do sistema e oferecendo ao usurio as
informaes que ele solicitou, no tempo que precisa delas.
Na fase seguinte, devemos iniciar o treinamento dos usurios, para que possam
operar o sistema. No caso da padaria do senhor Joo, cada atendente tem de
saber como se identificar no sistema e como registrar as compras dos clientes
no balco. Os caixas tm de aprender como se registra o recebimento de uma
compra e como se lana notas fiscais de fornecedores. E, claro, seria preciso
treinar o senhor Joo, quanto a todas as tarefas do sistema. Tanto no exemplo
fictcio como em um projeto real, quando todas as informaes estiverem cadastradas e os cadastros de funcionrios, produtos, cartes e fornecedores estiverem
corretos, hora de estudar a melhor data para a implantao, caso ainda no
tenha sido definida. importante, ainda, estabelecer uma rotina de cpia das
informaes do sistema (backup). O usurio responsvel por essa tarefa tem de
ser treinado e instrudo sobre sua importncia, pois com esse recurso se reduzem
as perdas de informao, no caso de falhas de hardware ou software. Na data
da implantao e nos dias subsequentes fundamental acompanhar o funcionamento do sistema, efetuando pequenos ajustes, caso seja preciso. Terminada
essa fase, podemos concluir que o sistema est entregue.

Voc aprendeu a usar a metodologia para projetar, construir e

implementar um sistema. Tarefa cumprida? Ainda no. O trabalho
s estar completo quando, alm da informtica, voc lanar mo
de seus conhecimentos em psicologia e administrao, para lidar
com as pessoas envolvidas no projeto e suas expectativas
o que, convenhamos, no algo simples. Ao projetar e construir
um sistema, preciso ter sempre em mente que os usurios esto
ansiosos por v-lo funcionando em seu ambiente. possvel usar
diversas ferramentas para que sua execuo seja transparente,
o que ajuda a amenizar as expectativas. Pode-se, por exemplo,
adotar um cronograma que lhes permita acompanhar todas as fases
do projeto, de modo que percebam claramente quais passos j
foram dados e os que viro na sequncia. Esse, porm, apenas
um dos exemplos de ferramentas auxiliares. O importante manter
a disposio de pesquisar outras, para que o desenvolvimento
de nossos projetos se torne cada vez mais rpido e claro.

92

Tetra Images/Corbis/Latinstock

Informtica, psicologia, administrao

Figura 36 Execuo de um projeto.

93

Informtica

Captulo 3

Banco de dados
Evoluo dos sistemas de computao
Conceitos e terminologia
Abordagem relacional
Administrao e gerenciamento

Informtica 3

captulo 3

3.1. Evoluo dos sistemas de computao

Os ltimos anos tm sido prdigos, em termos da tremenda evoluo observada nos sistemas computacionais. O avano nas diversas verses dos sistemas
operacionais permite que haja cada vez mais e mais recursos disponveis e novas
metodologias de acesso, que ampliam a velocidade e a forma de us-los. Entre as
novidades esto os bancos de dados ps-relacionais, tambm chamados de bancos de dados orientados a objetos. Tudo isso tem um grande impacto, tambm,
na construo de sistemas de aplicao. Vale, portanto, analisar as metodologias
empregadas na implantao de sistemas comerciais baseados em computadores.

3.1.1. Abordagem tradicional

egundo Ramez Elmasri, autor de vrios livros sobre informtica, o

primeiro Sistema Gerenciador de Banco de Dados (SGBD) surgiu no
final de 1960, com base nos primitivos sistemas de arquivos disponveis na poca, incapazes de controlar o acesso concorrente por vrios usurios
ou processos. Assim, os SGBDs evoluram de sistemas de arquivos para armazenamento em disco, quando foram criadas novas estruturas de dados com o
objetivo de armazenar informaes. Os SGBDs evoluram ao longo do tempo,
com a introduo de diferentes formas de representao, ou modelos de dados,
para descrever a estrutura das informaes neles contidas.
Os bancos de dados se tornaram um componente essencial e indispensvel em
nosso dia a dia. Geralmente no nos damos conta disso, mas sem eles no conseguiramos mais fazer atividades corriqueiras como depsitos, saques ou quaisquer outras formas de movimentao bancria, reservas em hotel, pesquisa em
bibliotecas informatizadas, compras em supermercados ou lojas, aquisio de
passagens areas. Tais atividades so exemplos clssicos de aplicaes que utilizam bancos de dados para manipular textos, valores, imagens etc (figura 37).
Figura 37
Banco de dados.

aquisio de
passagens areas

movimentao
bancria

Ba
n
de co
da
do
s
compras
em lojas

reservas
em hotel

96

compras em
pesquisa em
supermercados
bibliotecas
informatizadas

Segundo o professor e pesquisador Abraham Silberschatz (1999), a abordagem

tradicional baseada em tcnicas no estruturadas, utilizando a intuio natural
do analista de sistemas, bem como em sua capacidade criativa e vivncia no ambiente do sistema, ou seja, em seu conhecimento de negcios. A principal caracterstica dessa abordagem a orientao intuitiva desses profissionais para desenhar
o sistema, com base em procedimentos executados e descritos pelo usurio em sua
forma pura, sem orientao a dados e otimizaes organizacionais. Nesse perodo
utiliza-se uma mistura de linguagens da terceira gerao e de linguagens procedurais, com necessidade de declarao de dados e identificao fsica da localizao
da informao. Essa abordagem no prioriza a integrao da informao, mas sim
a soluo de problemas setorizados, ou seja, pode gerar retrabalho, pois muitas
vezes haver os mesmos dados em diversos sistemas na organizao.
Assim, sob a abordagem tradicional desenvolvem-se sistemas e aplicaes com
arquivos de propriedade da aplicao e de seus programas, em funo da utilizao de linguagens de terceira gerao, sem se levar em considerao a repetio
dos dados em outros sistemas.
Como consequncia, temos a redundncia de informaes, a qual provoca total
incoerncia e muitas vezes inconsistncia de dados. Os sistemas so elaborados
pensando-se na distribuio fsica dos arquivos (por exemplo, em que pasta ou
diretrio esse arquivo est fisicamente no HD), criando-se, assim, uma dependncia dos arquivos pelos sistemas. Segundo Elmasri (1999), isso significa que
qualquer alterao na base de dados implica a adaptao de grande quantidade
de programas e, portanto, significa enorme esforo de programao. bom
frisar que, sempre que houver grandes alteraes, temos uma forte tendncia
de esquecer alguns procedimentos, ao realizar alguma modificao, o que pode
resultar em erros que muitas vezes demoramos para perceber, pois o sistema
poder continuar gravando as informaes na base de dados anterior.

As principais
caractersticas da
abordagem tradicional
so: cada aplicao
tem seus prprios
arquivos; os dados
so repetitivos;
inconsistncia;
subordinao de
programas a arquivos;
manuteno difcil e
cara; o analista o
dono do sistema;
falta de integridade
e de segurana.

Caso haja muitos programas desenvolvidos dessa maneira, o sistema de tecnologia da informao da organizao ineficiente, pois se trata de uma abordagem
antiga e inadequada ao atual estgio de desenvolvimento de sistemas. Esse tipo
de abordagem pode ser visualizada da seguinte forma: cada usurio utiliza um
aplicativo (ou um conjunto de aplicativos), o qual, por sua vez, usa um arquivo
de dados que muitas vezes no acessado por outro usurio, como sugere a
ilustrao a seguir (figura 38).
97

Informtica 3

captulo 3

Figura 38

uma aplicao. por isso que surgem as dificuldades de manuteno, ocasionadas parcialmente pelo forte acoplamento dos programas aos arquivos. A
abordagem de banco de dados, ainda considerada a mais adequada, surgiu da
necessidade de desenvolvimento de sistemas cada vez mais complexos e flexveis,
integrando os dados de toda a organizao e no mais apenas os sistemas departamentais. Sob esse prisma, a nfase no desenvolvimento de uma aplicao
no mais sobre os processos, e sim sobre os dados. Podemos dizer que, para a
abordagem tradicional e de sistemas integrados, na expresso processamento de
dados a parte mais importante o processamento, enquanto na abordagem de
banco de dados a palavra fundamental dados.

A abordagem
tradicional: para
cada usurio, um ou
mais aplicativos.

3.1.2. Abordagem de sistemas integrados

As principais
caractersticas da
abordagem de sistemas
integrados so: pouco
adaptvel; as alteraes
comprometem vrios
sistemas; aplicaes
estticas com o tempo;
problemas em um sistema
paralisam atividades
de outros; programas
ainda subordinados a
arquivos; viso de usurio
inexistente; integridade e
segurana so fracas.

Elmasri (1999) diz ainda que, por causa das deficincias da abordagem anterior,
criou-se, por volta de 1980, uma nova, a de sistemas integrados, a qual pretendia
resolver as questes de redundncia e integridade de informaes, trazendo uma
viso corporativa de sistemas. Ela se vale da percepo de que existem conjuntos
de arquivos de dados de interesse comum s vrias reas de uma organizao, ou
seja, de que no precisamos redigitar informaes que j foram digitadas por outros
usurios de outros departamentos ou usurios de outros sistemas. A integrao entre
os sistemas mantm um grau acentuado de unicidade da informao dentro dos
sistemas da organizao. Assim, tal abordagem eliminou a redundncia de dados
que caracteriza a anterior. Aqui, os sistemas passam a utilizar uma nica base de
informaes, sem a repetio de arquivos por sistema.
Os sistemas desenvolvidos dessa maneira iniciaram a integrao no universo
corporativo, ficando dependentes uns dos outros por utilizarem a mesma base
de dados. Assim, alteraes em qualquer arquivo de dados implicavam modificaes em programas de mais de um dos sistemas que acessavam a mesma
base, em virtude de utilizar linguagens de alta dependncia de dados (figura
39). Com o crescimento das aplicaes, essa abordagem tambm se tornou ineficiente. Qualquer alterao na base de dados afetava um nmero ainda maior
de sistemas e programas. Com tantas dificuldades relacionadas ao volume de alteraes, as aplicaes acabaram por se tornar praticamente estticas, levando os
departamentos de tecnologia da informao estagnao e a serem considerados
ineficientes pelos gestores das organizaes.

Segundo Elmasri (2002), h duas preocupaes principais, quando trabalhar

com essa abordagem. A primeira, em um nvel mais conceitual, consiste na
definio de um modelo de dados em termos da organizao como um todo,
abordando seus diversos setores. preciso retratar todo o interrelacionamento
entre as diversas reas e departamentos que compem o negcio, bem como todas as necessidades de informao de cada um desses setores. Somente com base
nisso poderemos garantir que as aplicaes desenvolvidas individualmente tero
o comportamento desejado quanto integrao com outros sistemas e, tambm,
que os dados sero os mais confiveis.
A segunda preocupao diz respeito forma de implementao fsica dos dados,
em relao aos programas que iro manipular. Aqui deveremos levar em considerao as linguagens de programao disponveis e qual delas ser adotada,
tendo sempre o cuidado de selecionar a melhor para o tipo de sistema computacional que estamos desenvolvendo. necessrio que os programas tenham uma
viso de alto nvel dos dados, o mais independente possvel dos fatores fsicos
ligados forma de armazenamento desses dados. Assim, nos Sistemas Gerenciadores de Banco de Dados (SGDB), h uma separao entre o local onde se
armazena o banco de dados, bem como a definio fsica dos dados, e aquele no
Figura 39
Abordagem de
sistemas integrados:
dependncia.

3.1.3. Abordagem de bancos de dados

Segundo Elmasri (1999), embora haja diferenas at certo ponto significativas
entre as duas abordagens apresentadas anteriormente, ambas tm em comum
uma caracterstica determinante: a nfase dada aos processos, ao desenvolver
98

99

Informtica 3

captulo 3

qual eles so realmente utilizados. Da se originam, inclusive, os conceitos de

Linguagem de Definio dos Dados e de Linguagem de Manipulao dos Dados. Passa a existir, assim, um repositrio onde so armazenados esses elementos
de mais baixo nvel, de forma que fiquem externos ao cdigo do sistema. Esse
repositrio apresenta-se na forma de um dicionrio de dados com aparncia e
transparncia irrelevantes para o analista de sistemas e os programadores.

3.2. Conceitos e terminologia

Para trabalhar essa abordagem preciso conhecer os conceitos e as terminologias relacionadas a banco de dados, justamente os temas abordados
neste captulo.

3.2.1. Abstrao de dados

Vantagens

Requisitos

Desenvolvimento flexvel e
produtivo

Aquisio e utilizao de
um SGBD

Integrao dos dados em nvel

empresarial

Utilizao de dicionrio de
dados

Transparncia dos dados s

aplicaes

Centralizao da definio
de dados

Maior controle sobre a

integridade dos dados

Centralizao do projeto
das bases de dados

Maiores controles de
segurana dos dados

De acordo com Elmasri (2002), a abstrao de dados a capacidade de modelar

as caractersticas, variveis e constantes, de forma a desprezar os dados que no
interessam (veja quadro Os nveis de abstrao). Um SGBD composto por uma
coleo de arquivos interrelacionados e de um conjunto de programas que permitem aos usurios acessar e modificar os arquivos. Sua proposta maior prover os
usurios de uma viso abstrata dos dados. Ou seja, o sistema omite alguns detalhes de como as informaes so armazenadas e mantidas, mas, para que possa ser
utilizado em projetos bastante complexos, esses dados devem ser recuperados de
maneira eficiente. Como nem sempre os usurios de bancos de dados so treinados em informtica, a complexidade fica encapsulada em diversos nveis de abstrao, para simplificar a interao desses usurios com o sistema (Date, 2000). H
trs nveis de abstrao e seu interrelacionamento ilustrado na figura 41.

Os nveis de abstrao
Tambm devemos avaliar com muita ateno qual arquitetura de hardware
e software ser a mais adequada ao nosso projeto. A abordagem de banco de
dados est ilustrada na figura 40. Trabalhar com ela, no desenvolvimento de
sistemas, exige dos profissionais de tecnologia da informao comprometimento com alguns princpios.
Figura 40
Abordagem de
banco de dados.

Nvel fsico: o mais baixo, no qual se descreve como os

dados so armazenados, onde essas complexas estruturas so
descritas detalhadamente. Assim, os registros de um cliente, de
um fornecedor, de uma conta bancria so descritos como um
bloco de posies consecutivas de armazenamento, como por
exemplo string ou byte.
Nvel conceitual: o prximo nvel de abstrao, em que se
descreve quais dados so armazenados e as relaes existentes
entre eles. Aqui, o banco de dados descrito em termos de
um pequeno nmero de estruturas simples. utilizado pelos
administradores de banco de dados, que podem decidir quais
informaes devem ser mantidas. No nvel conceitual, os registros
de um cliente, de um fornecedor, de uma conta bancria se
interrelacionam.
Nvel visual: o mais alto de abstrao e descreve apenas a
parte do banco de dados. Muitos usurios no esto interessados
em todas as informaes existentes. Sua definio serve para
simplificar a interao deles com o sistema, que pode fornecer
vrias vises diferentes para o mesmo banco de dados.
Por exemplo: cada categoria de funcionrio pode visualizar
determinado grupo de informaes.

100

101

Informtica 3

captulo 3

Figura 41

3.2.4. Linguagem de definio de dados

Interrelacionamento
entre os nveis de
abstrao.

Henry Korth
autor de vrios
livros clssicos
da informtica.

Um esquema de banco de dados especificado por um conjunto de definies,

por meio da chamada linguagem de definio de dados, ou DDL (do ingls,
Data Definition Language). A compilao de comandos DDL um conjunto
de tabelas armazenadas em um arquivo chamado dicionrio (ou diretrio) de
dados. Trata-se de um arquivo que contm metadados (dados sobre dados) e
sempre consultado antes que haja qualquer leitura ou modificao pelo banco
de dados. Os comandos DDL servem para definir esquemas, remover relaes,
criar ndices e modificar esquemas de relao.

3.2.5. Linguagem de manipulao de dados

3.2.2. Instncias e esquemas

Os bancos de dados se alteram, ao longo do tempo, medida que informaes
so inseridas ou deletadas. O conjunto de dados armazenados em determinado
momento conhecido como instncia do banco de dados. J o projeto do banco
de dados chamado de esquema de banco de dados (DATE, 2000).

Independncia fsica:
a habilidade de modificar
o esquema fsico sem que
seja preciso modificar os
programas. Alteraes
no nvel fsico podem ser
necessrias somente
para uma ocasional
melhoria de performance.
Independncia lgica: a
possibilidade de modificar
o esquema conceitual
sem que isso demande
modificao nos
programas. necessria
apenas quando a estrutura
lgica do banco de dados
alterada. Por exemplo, se
forem criadas mais colunas
em uma determinada
tabela do banco de dados.
A independncia lgica
mais difcil de alcanar do
que a independncia fsica,
porm os programas so
bastante dependentes
da estrutura lgica
dos dados que acessam

102

Segundo Korth (1995) o conceito de um esquema de banco de dados corresponde noo de definio de tipo na linguagem de programao. Uma varivel
de um dado tipo tem um valor particular em um determinado instante de tempo. Assim, o conceito de valor de uma varivel na linguagem de programao
corresponde ao conceito de uma instncia de um esquema de banco de dados.
Ainda de acordo com Korth (1995), os sistemas de bancos de dados possuem
diversos esquemas, subdivididos de acordo com os nveis de abstrao descritos
anteriormente. No nvel mais baixo est o esquema fsico, no intermedirio o
esquema conceitual e no mais alto, um subesquema. Em geral, os sistemas de
bancos de dados suportam um esquema fsico, um esquema conceitual e diversos subesquemas.

3.2.3. Independncia de dados

Independncia de dados a habilidade de modificar a definio de um
esquema em um nvel, sem afetar sua definio de esquema em um outro nvel, mais alto. Essa independncia constitui o principal objetivo a ser alcanado no desenvolvimento de um banco de dados, pois permitir a expanso
das atividades da empresa, facilitando o desenvolvimento de novos sistemas.
Tal independncia consiste na capacidade de favorecer que haja evoluo na
descrio de dados, como a criao de uma nova estrutura lgica decorrente
de uma nova aplicao, ou incluso de um dado novo numa estrutura existente, sem que os sistemas ou aplicaes (em ltima anlise, os programas)
tenham de ser alterados. Essa capacidade deve se estender aos casos de mudana na organizao dos arquivos, em consequncia de degradao e perda
de eficincia (DATE, 2000). De acordo com esse conceito, os programas interagem com a viso lgica do banco de dados. A localizao fsica do dado
totalmente transparente.

A DML (do ingls Data Manipulation Language) decorre do fato de os nveis

de abstrao no se aplicarem somente definio ou estruturao de dados,
mas tambm sua manipulao. Isso tem uma srie de significados, no mbito
do banco de dados: como recuperamos a informao armazenada, como
inserimos novas informaes, como deletamos as informaes, como modificar dados armazenados.

3.2.6. Usurios de banco de dados

J sabemos que o objetivo central de um banco de dados prover uma soluo
para armazenamento e busca de informaes por seus usurios. Estes, os que
iro interagir com o banco de dados para realizar essas operaes, podem ser
classificados em cinco tipos, de acordo com o tipo de interao (DALTON,
2008). Confira quais so:

Uma consulta
(tambm chamada de
query) um comando
que requisita o resgate
de uma informao,
com base na lgebra
relacional e no clculo
relacional de tupla.

Profissionais de sistemas informatizados: aqueles que desenvolvem aplicativos desenvolvidos para realizar a interao com os bancos de dados.
Programadores ou desenvolvedores: so os que fazem a interao com os
sistemas, utilizando-se das DML, que so includas nos programas, denominados programas de aplicao.
Usurios avanados: interagem com o sistema sem escrever programas.
Como tm conhecimentos de linguagem de consulta, realizam chamadas
especficas nessa linguagem para atender a suas demandas.
Usurios leigos: s interagem com os sistemas desenvolvidos pelos programadores.
Administradores de banco de dados (DBA, do ingls Data Base Administrator): so os responsveis pela criao, manuteno e bom funcionamento do banco de dados. Avaliam sua performance com frequncia e,
sempre que necessrio, tratam de aprimor-la.

3.3. Abordagem relacional

Em 1969, o pesquisador da IBM Edgar Frank Codd, j mencionado no captulo
2, comeou a pesquisar uma maneira melhor de organizar dados e introduziu
o conceito de banco de dados relacional, que organizado em tabelas simples.
Conforme Elmasri (2002), Codd criou um modelo que permite aos projetistas
dividir suas bases de dados em tabelas separadas, mas relacionadas, de modo
103

Informtica 3

captulo 3

a otimizar a eficincia da execuo, mantendo a mesma aparncia externa do

banco de dados original para os usurios. Por isso considerado o pai do banco
de dados relacional. A maioria dos bancos de dados relacional. Baseia-se no
princpio de que as informaes em uma base de dados podem ser consideradas
como relaes matemticas e so representadas de maneira uniforme. Os objetos manipulados pelos usurios so as linhas (tuplas, na terminologia original)
e as colunas das tabelas. Para fazer isso o usurio conta com um conjunto de
operadores e funes de alto nvel, denominados lgebra relacional.

3.3.1. Caractersticas principais

As principais caractersticas da abordagem relacional baseiam-se em uma srie
de fatores (Korth, 1995), definidos a seguir.
Estrutura de dados tabular: os dados so representados em forma de tabela,
que denominada relao, constituda de linhas ou tuplas, colunas ou atributos e, finalmente, tipos de dados que podem aparecer em uma coluna especfica, chamada domnios. Assim, no existe o conceito de item de grupo, em
um banco de dados relacional. Todos os itens de uma tabela so elementares.
 lgebra relacional: a manipulao das tabelas realizada por operadores
por meio dos quais podemos acessar dados de diversas maneiras, ou seja,
um conjunto de operaes e relaes. Cada operao usa uma ou mais
relaes como seus operandos e produz outra relao como resultado. Dessa
forma, a recuperao das informaes em um SGBD relacional se faz em
conjuntos de registros que comporo uma nova relao.
A chave primria
(Primary Key) serve
para identificar cada
registro numa
tabela. Pode ser um
atributo ou uma
combinao
de atributos.

Dicionrio de dados ativo e integrado: um banco de dados que mantm

as descries dos objetos existentes no sistema da empresa deve ser ativo, no
sentido de estar sempre disponvel para utilizao, e integrado, na medida
em que englobe todas as informaes sobre o sistema, permitindo realizar
referncias cruzadas nos dados.
Consistncia automtica de campos: o prprio sistema tem a funcionalidade de validar os dados nos quesitos de tamanho, formato, tipo e integridade.
Referncia cruzada de dados: permite relacionar linhas e colunas, ou seja,
valores de campos com linhas;
Integridade dos dados: para garantir a qualidade das informaes do banco de
dados, devemos nos preocupar com quatro categorias de integridade dos dados:
1. De entidade: definimos uma linha como exclusiva de determinada tabela,
ou seja, definimos uma chave primria (Primary Key) de uma tabela.

A chave estrangeira
(Foreign Key) pode
ser uma coluna ou
combinao de
colunas usada para
estabelecer links
entre duas tabelas.

104

2. Integridade de domnio: valida entradas de uma coluna especfica, podendo restringir suas relaes em linhas, quando estas so includas ou
excludas. So as chaves estrangeiras (Foreign Key).
3. Integridade referencial: preserva as relaes definidas entre tabelas, permitindo consistncia em todas elas.

4. Integridade definida pelo usurio: o usurio define suas regras de

negcio, quando no se enquadra nas outras categorias de integridade
apresentadas.

3.3.2. Princpios da orientao

O conceito de vises de dados tem a ver com a forma como o usurio os v.
Existe a possibilidade de criar vises de subconjuntos dos dados colocados em
um SGBD. Os usurios podem ter acesso a parte do modelo, independentemente da forma como esto contidos no banco de dados. Tomemos como
exemplo um banco de dados com clientes e pedidos. Podemos montar uma
viso de informaes que mostre os clientes com seus respectivos pedidos,
sem que isso afete as estruturas do modelo de dados implementado ou apresentar uma viso com informaes cadastrais de clientes sem dados financeiros, por exemplo. As vises so formadas conforme a necessidade do usurio.
Para definir essas vises preciso atentar para dois fatores: a transparncia
de dados (como e onde esto os dados torna-se secundrio para o usurio,
irrelevante) e os elos implcitos (colunas comuns nas tabelas, sem restrio a
tipo de relacionamento).

3.3.3. As doze regras de Edgar F. Codd

As bases da abordagem relacional, como sabemos, foram lanadas em 1970 por
Edgar F. Codd. Na poca o pesquisador estabeleceu um conjunto de doze regras
para um banco de dados realmente relacional. Segundo Date (2000), as normas
de Codd, que vamos conhecer a seguir, discutem a fidelidade de um SGBD ao
modelo relacional.

Regra nmero 1 - Representao de valores em tabelas

Toda informao, em um Banco de Dados Relacional, apresentada em
nvel lgico por valores em tabelas.
Os nomes das tabelas, colunas e domnios so representados por sries de caracteres que, por sua vez, devem tambm ser guardadas em tabelas, as quais

Benefcios da abordagem
Independncia dos dados
Vises mltiplas de dados
Melhor comunicao entre o departamento de informtica
e os usurios
Reduo acentuada do desenvolvimento de aplicaes
e do tempo gasto em manuteno de sistemas
Melhoria na segurana de dados
Mais agilidade gerencial de informaes ligadas ao processo
decisrio da empresa

105

Informtica 3

captulo 3

formam o catlogo do sistema, o dicionrio de dados. Portanto, o princpio de

que a informao deve estar sob a forma de tabela extensiva ao dicionrio de
dados. As tabelas so bidimensionais, o que equivale a dizer que no h colunas
repetitivas (Clusula Occurs, por exemplo, no existe).

Regra nmero 2 - Acesso garantido

Todo e cada dado num Banco de Dados Relacional tem a garantia de ser
logicamente acessvel, recorrendo-se a uma combinao do nome da tabela,
um valor de chave primria e o nome da coluna.
Isso significa que a ordem das linhas, assim como a das colunas, irrelevante.
Para obter uma informao especfica, ou seja, o valor de uma coluna em uma
linha de uma tabela, basta informar o nome da tabela, o valor de uma chave
primria (no caso, da linha a ser recuperada) e o nome da coluna da tabela em
questo. Da mesma forma, para saber quais ocorrncias de uma tabela tm
um determinado valor em uma coluna, basta informar o nome da tabela e o
nome da coluna, que o contedo poder ser comparado. Concluso: a regra
especifica que, em um banco de dados efetivamente relacional, no existe informao inacessvel.

Regra nmero 3 - Tratamento sistemtico de valores nulos

Valores nulos so suportados em um SGBD relacional nulo para representar exatamente a informao perdida ou inexistente, inaplicvel.
Para mais bem entender essa regra, vale a pena definir o que valor nulo: aquele utilizado para representar uma informao perdida ou desconhecida. Conceitualmente, um valor inexistente. A inexistncia de contedo em um campo
equivale a dizer que seu valor nulo. Mas ateno: jamais confunda zero(s) ou
espao(s) em branco com strings vazios.
Imagine um pacote de supermercado de papel, desdobrado. Sem toc-lo ou
olhar em seu interior, voc no pode saber se est vazio ou contm algum
produto. Portanto, nesse instante, para voc, o contedo do pacote NULO.
uma informao desconhecida, inexistente. Valores nulos, portanto, so suportados por um SGBD para representar exatamente a informao perdida
ou inexistente, inaplicvel. Para suportar a integridade de identidade preciso
especificar no so permitidos valores nulos em cada coluna da chave primria e em qualquer outra coluna que se considerar como uma restrio de
integridade. Se levarmos em conta que um atributo tem de, obrigatoriamente,
possuir contedo, estaremos especificando que seu valor no pode ser nulo.
Assim, o SGBD precisa reconhecer a informao nula para poder restringi-la
ou aceit-la, se necessrio.

Regra nmero 4 - Catlogo relacional ativo baseado no

modelo relacional
A descrio do banco de dados representada em nvel lgico, da mesma
maneira que seus dados.
Esta regra exige que um SGBD relacional tenha uma mesma linguagem para
acesso e definio dos dados no dicionrio e para a manipulao dos dados do
106

banco e do dicionrio. Por exemplo: um comando para adicionar informaes

em uma tabela da aplicao deve ser o mesmo para acrescentar informaes no
dicionrio de dados.

Regra nmero 5 - Sublinguagem detalhada e dados

Um sistema de banco de dados relacional deve ter uma linguagem cujas
instrues, com sintaxe bem definida, suportem a definio de dados, a
definio de viso de dados, a manipulao de dados, as restries de integridade, as autorizaes e os limites de transao.
Instrues
Definio dos dados: criar ou adicionar tabelas no dicionrio de dados.
D
 efinio de viso de dados: fazer operaes relacionais de juno, criar
vises de partes do modelo de dados.
M
 anipulao de dados: permitir criar, alterar, consultar e deletar conjuntos de dados.
R
 estries de integridade: possibilitar que sua sublinguagem controle
as restries especficas de uma tabela ou de valores aceitveis para uma
determinada coluna.
A
 utorizaes: definir limites de acesso a tabelas por usurio, inclusive em
nvel de coluna.
L
 imites de transao: tornar vivel a delimitao de uma transao lgica de modificao do banco de dados, o que fornece um alto nvel de
segurana da integridade de informaes no banco de dados.

Regra nmero 6 - Atualizao de viso

Todas as vises de dados, que so teoricamente atualizveis, so tambm
atualizveis pelo sistema.
Atualizar significa mais do que simplesmente modificar a informao; abrange
tambm a incluso e/ou excluso de dados. Por exemplo, se definimos uma
viso de dados como um subconjunto horizontal de uma tabela, deve ser possvel adicionar dados a essa viso. Consideremos uma tabela de funcionrios e
que haja vises de funcionrios tcnicos, funcionrias secretrias e funcionrios
administrativos. Atualizar uma dessas vises quer dizer, entre outras possibilidades, adicionar dados para a incluso de uma secretria ou de um tcnico.
Outro exemplo seria criar uma viso de uma tabela de mdicos por especialidade, digamos cem mdicos em uma tabela, dos quais trinta so especializados
em pediatria. Ao criarmos a viso Pediatras, uma seleo de linhas, que conter
somente os mdicos com esta especialidade, cria-se no dicionrio de dados um
sinnimo de mdico, denominado Pediatra, que tem como condio para esse
role (literalmente, papel) o valor da coluna especialidade ser igual a pediatria.
Esta viso deve ter a possibilidade de ser deletada. Se comandarmos DELETAR
PEDIATRIA ou ALTERAR um pediatra especfico, tais atualizaes devem ser
realizadas diretamente na tabela originria da viso.

Regra nmero 7 - Atualizao de alto nvel

No banco relacional, a linguagem de alto nvel se aplica no somente
107

Informtica 3

captulo 3

consulta de dados, mas tambm incluso, alterao e excluso de dados.

Isso quer dizer que as operaes realizadas sobre a base de dados tratam conjuntos de informaes (tabelas), no registro por registro. Isso quer dizer que
a linguagem de alto nvel no procedural, uma caracterstica das linguagens
denominadas de quarta gerao.

Regra nmero 8 - Independncia de dados fsicos

Os programas de aplicao permanecem inalterados sempre que quaisquer modificaes so feitas nas representaes de memria ou nos mtodos de acesso.
Essa regra nos d uma diretriz essencial quanto aos programas de aplicao: esses programas lidam somente com dados lgicos. Se houver qualquer
modificao quanto ao local de armazenamento fsico dos dados ou, ainda,
uma mudana qualquer de ndices de acesso, o programa de aplicao, logicamente estvel, no sofrer nenhuma paralisao nem precisar de alteraes. Por exemplo, se desenvolvermos uma aplicao em um diretrio de
dados e, posteriormente, em consequncia de uma migrao ou expanso
de hardware, essa base de dados for transferida para um outro diretrio de
dados, as aplicaes desenvolvidas originalmente para tal base no sero
afetadas, j que a definio de localizao dos dados deve ser externa linguagem de manipulao de dados.

Regra nmero 9 - Independncia de dados lgicos

Os programas de aplicao tambm permanecem inalterados quando
so feitos nas tabelas, mudanas de qualquer tipo para preservar a
informao.
Aqui a regra implica, por exemplo, que a juno de duas tabelas no afeta os
programas, assim como a criao de novos campos e as operaes de seleo que
dividem uma tabela por linhas ou colunas, desde que se preservem as chaves
primrias. Se, por exemplo, criarmos um novo relacionamento entre duas entidades ou modificarmos a condio de relacionamento entre elas, em hiptese
nenhuma isso afetar as aplicaes existentes.

Regra nmero 10 - Independncia de integridade

As restries de integridade especficas de determinado banco de dados relacional devem ser definveis na sublinguagem e armazenveis no catlogo
do sistema e no nos programas de aplicao.
Restries de domnio e regras para validao de alguns ou todos os atributos tambm devem ser armazenveis no dicionrio de dados. Definies,
por exemplo, do tipo de caractere de um campo se numrico, se inteiro ou
de tamanho varivel devem estar especificadas nele. J quanto ao controle
de sua validade (consistncia), deve haver a possibilidade de ser realizado
pela sublinguagem do SGBD, sem que, para isso, haja necessidade de que
o programa de aplicao o controle. Da mesma forma, a exigncia da existncia de um campo deve ser informada no dicionrio e tambm deve ser
administrada por este, ficando os programas de aplicao desobrigados de
tais controles.
108

Regra nmero 11 - Independncia de distribuio

Um SGBD relacional tem independncia de distribuio quando sua sublinguagem permite que os programas de aplicao permaneam inalterados enquanto os dados so distribudos, tanto na inicializao de um
sistema quanto na ocorrncia de uma redistribuio.
Se um sistema, por sua implementao, tiver arquivos redistribudos em meios
ou mquinas diferentes, a sublinguagem do SGBD far o controle e a ligao
com os programas de aplicao, sem que seja necessrio realizar nenhuma modificao neles.

Regra nmero 12 - No subverso

Se um SGBD relacional tem uma linguagem de baixo nvel ou recursos de
linguagem que permitam processamento em baixo nvel, essa linguagem
no pode ser usada para subverter ou ignorar as regras de integridade ou
restries expressas na linguagem relacional de alto nvel.
Isso quer dizer que, se processarmos registro a registro, isso no poder implicar
a burla de restries especficas dos objetos do banco de dados. Tal regra pode
ser considerada extensiva utilizao de outras linguagens capazes de interagir
com o banco de dados. Por exemplo, a utilizao de uma linguagem de baixo
nvel no poder adicionar um registro sem os atributos definidos, no dicionrio, como obrigatrios para uma determinada tabela.

3.3.4. Chaves e ndices

O modelo relacional emprega o conceito diferenciado entre chaves e ndices.
Um ndice um recurso fsico que visa otimizar a recuperao de uma informao por meio do mtodo de acesso. Seu objetivo est relacionado com o desempenho de um sistema, ou seja, concebidos para aumentar a velocidade de
recuperao dos dados, os ndices devem ser criados para os campos (ou colunas)
pesquisados com mais frequncia. Como em tudo o que desenvolvemos, preciso analisar os prs e os contras, j que a criao de ndices pode gerar algumas
desvantagens, como o tempo que se leva para constru-los; o espao em disco
utilizado para armazen-los; a demora maior para as operaes de modificao
no banco de dados, pois todas as mudanas tm de ser realizadas nos dados e
nos ndices. Esses problemas podem ser minimizados ou at mitigados com o
uso de regras para a criao de campos indexados.

Colunas que devem

ser indexadas: chave
primria; as que
frequentemente so
utilizadas em juno
(chave estrangeira);
as frequentemente
pesquisadas em
faixas de valores; as
geralmente recuperadas
de forma classificada.
Colunas que no
devem ser indexadas:
as que raramente so
referenciadas em uma
consulta; as que contm
poucos valores nicos;
as definidas com os
tipos de dados text,
image ou bit; quando
o desempenho das
atualizaes mais
importante que
o desempenho
das consultas.

A chave designa o conceito de item de busca, ou seja, um dado que ser empregado nas consultas base de dados. um conceito lgico da aplicao.
Podemos dizer que um campo chave se puder ser utilizado para recuperar
linhas de uma tabela. Geralmente, todos os campos de uma tabela so chaves,
mas o modelo relacional preocupa-se com a definio das principais chaves de
uma tabela. Assim, implementa os conceitos de chave primria e chave estrangeira, que se relacionam com duas restries de integridade determinadas por
Codd, quanto ao banco de dados. Vejamos, ento, quais so os tipos de chave
em um modelo relacional.
109

Informtica 3

captulo 3

1) Chave primria
O conceito de chave primria est ligado prpria concepo do modelo relacional. Os dados esto organizados sob a forma de tabelas bidimensionais, com
linhas e colunas, e o princpio nos conduz a termos uma forma de identificar uma
nica linha da tabela por meio de um identificador nico em valor. Trata-se de
um conceito fundamental para entendermos o funcionamento de um banco de
dados. Quando definimos um campo como chave primria, estamos informando ao banco de dados que no pode existir mais algum registro com o mesmo
valor especificado como chave primria, ou seja, os valores das chaves primrias
devem ser nicos. Toda tabela relacional deve possuir esse identificador unvoco,
denominado chave primria. Assim, uma tabela relacional contm um campo
ou conjunto de campos concatenados, permitindo que dela se identifique uma e
somente uma ocorrncia. Mas em uma mesma tabela podem existir mais de um
campo ou coluna com essa propriedade. A estas denominamos chaves candidatas.
Entre essas candidatas a chave primria, temos de escolher uma para ser definida
e utilizada como tal, deixando as demais como chaves alternativas.

Conclui-se, ento, que havendo uma coluna Ca em uma tabela A e uma coluna
Cb, com idntico domnio, em uma tabela B, a qual foi definida como chave
primria de B, ento a coluna Ca uma chave estrangeira em A, j que a tabela
A contm uma outra coluna distinta de Ca, que sua chave primria. No h
limitao para o nmero de chaves estrangeiras em uma tabela. Veja nas tabelas
abaixo exemplos de referncia lgica por chave estrangeira.

FUNCIONaRIO

departamento

Matricula

Nome

Depto

Numero

Nome

A chave primria tambm pode ser formada pela combinao de mais de um

campo, pois h casos em que no se pode atribuir essa funo a um nico
campo, j que este pode conter dados repetidos. Nessa situao, podemos combinar dois ou mais campos para formar nossa chave primria. Quando a chave
primria composta, devemos ficar atentos ao desempenho das consultas, que
inversamente proporcional ao tamanho da chave primria. Quanto maior o
tamanho da chave primria, maior ser o tempo de retorno de uma consulta.

1234

Wilson Oliveira

25

10

Contabilidade

5678

Lucas Sirtori

15

25

Sistemas

9191

Andra Oliveira

10

15

RH

9287

Amanda Cristina

10

2) Chaves candidatas

9388

Priscila Oliveira

25

Uma tabela tambm pode conter alternativas de identificador nico, pois vrias colunas ou concatenaes diferentes de colunas podem ter essa propriedade e, portanto, so candidatas a chave primria. Mas, como somente uma
ser escolhida como chave primria, as restantes passam a ser consideradas
chaves alternativas.

3) Chaves secundrias
O termo chave sempre se refere a um elemento de busca por meio do qual podemos recuperar uma informao ou um conjunto de informaes. E, nas tabelas
do banco de dados relacional, h colunas ou conjuntos de colunas concatenadas
que nos permitem fazer no uma identificao nica, mas de um grupo de
linhas de uma tabela. Chamamos tais colunas ou conjuntos de colunas concatenadas de chaves secundrias. possvel que existam N linhas em uma tabela
com o mesmo valor de chave secundria.

110

a realizao dos comandos ORDER BY e GROUP BY. Quando dizemos que

duas tabelas possuem colunas comuns, devemos observar que, provavelmente,
em uma da tabelas a coluna uma chave primria. Na outra tabela, a coluna
comum ser caracterizada, ento, como o que chamamos de chave estrangeira.
, na realidade, uma referncia lgica de uma tabela outra.

O comando Order
By especifica um
ou mais elementos
que sero usados
para classificar
um conjunto de
resultados e facilitar
a pesquisa.
O Group By serve
para agrupar
dados recuperados
conforme critrios
pr-definidos.

Na tabela Funcionario temos o atributo Matricula_Funcionario como chave

primria e, na tabela Departamento, a chave primria o atributo Numero_Departamento. Assim, nmero do departamento em Funcionario uma
chave estrangeira, uma referncia lgica que estabelece o relacionamento entre
as duas entidades.

3.3.4.1. Regras de integridade

As regras de integridade existem para evitar que uma determinada coluna no
tenha uma relao correspondente. Em funo dos conceitos de chave primria
e chave estrangeira, Codd elaborou as duas regras de integridade de dados do
modelo relacional, a de integridade e a de integridade referencial.

4) Chaves estrangeiras

Regra de integridade de identidade

Um dos conceitos de importncia vital no contexto do modelo relacional o das

chaves estrangeiras. Para mais bem compreender do que se trata, vale analisar as
duas tabelas a seguir (Funcionario e Departamento). Criar ndices para chaves
estrangeiras aumenta a velocidade na execuo das junes e tambm facilita

Esta restrio se refere aos valores das chaves primrias. Se a chave primria, por
definio, identifica uma e somente uma ocorrncia de uma tabela, ento no
poder ter valor NULO porque nulo no identifica nada, representando apenas
a informao desconhecida.
111

Informtica 3

captulo 3

Regra de integridade referencial

3.4. Administrao e gerenciamento

Se determinada tabela A tem uma chave estrangeira que chave primria de

uma tabela B, ento ela deve:
Ser igual a um valor de chave primria existente na tabela B;
S er totalmente nula. Isso significa que uma ligao lgica est desativada.

Um banco de dados (ver definio de Sistema Gerenciador de Banco de Dados

SGDB no captulo 2.5.10) um conjunto de objetos SQL, como tabelas,
funes e triggers, e tem de ser bem administrado para que se possa tirar de seus
recursos o mximo proveito e com a melhor performance possvel para cada
tipo de negcio. Por isso h profissionais capacitados especificamente para essa
funo, conhecidos no mercado como Data Base Administrator (administrador
de banco de dados) ou mesmo pela sigla DBA. Tais profissionais tm de conhecer profundamente as ferramentas de administrao do banco de dados para
utiliz-las de maneira eficiente, pois so eles que desenvolvem e administram
estratgias, procedimentos, prticas e planos para disponibilizar documentao,
alm de compartilhar informaes e dados corporativos necessrios, no momento certo e s pessoas certas, com integridade e privacidade. Veja quais so as
principais funes de um DBA:

Conclui-se que no podemos ter um valor em uma chave estrangeira de uma

tabela e que esse valor no existe como chave primria em alguma ocorrncia da
tabela referenciada. As regras de integridade do modelo relacional representam a
garantia de que as tabelas guardam informaes compatveis. So, portanto, de
extrema importncia para a confiabilidade das informaes do banco de dados.
A manuteno de valor nulo para uma chave estrangeira significa que no existe,
para aquela ocorrncia, ligao lgica com a tabela referenciada.
Utilizamos a integridade referencial para garantir a integridade das informaes
entre as tabelas relacionadas em um banco de dados, evitando assim inconsistncias e repeties desnecessrias.

3.3.4.2. Regras de converso do modelo E-R para o modelo relacional

Um modelo Entidade e Relacionamento pode ser convertido para um modelo
Relacional de banco de dados. preciso, porm, levar em conta as seguintes
regras para cada elemento do sistema:
Entidades: toda entidade torna-se uma tabela carregando todos os seus
atributos. Cada atributo vira um campo da tabela. A chave primria e as
chaves candidatas so projetadas para no permitir ocorrncias mltiplas
nem admitir nulos.
Relacionamento 1:N: a tabela cuja conectividade N carrega o identificador da tabela cuja conectividade 1 (chave estrangeira).
Relacionamento 1:N: (envolvendo autorrelacionamento): a chave primria
da entidade includa na prpria entidade como chave estrangeira, gerando
uma estrutura de acesso a partir dessa chave estrangeira.
Relacionamento 1:1: as tabelas envolvidas nesse relacionamento carregaro
o identificador da outra (uma ou outra ou ambas) conforme a convenincia
do projeto (de acordo com o acesso a essas tabelas).
Relacionamento 1:1: (envolvendo autorrelacionamento): chave primria da
entidade includa na prpria entidade (chave estrangeira) e cria-se uma
estrutura de acesso para ela.
Relacionamento N:N: o relacionamento torna-se uma tabela, carregando
os identificadores das tabelas que ele relaciona e os atributos do relacionamento (se houver).
112

D
 efinir o contedo de informaes do banco de
dados
Por meio de levantamentos de informaes, o profissional deve decidir que
informaes devem ser mantidas no banco de dados da empresa.

Definir a estrutura de armazenamento e a estratgia

de acesso
Aqui o DBA deve indicar como os dados sero armazenados e quais sero
os acessos mais frequentes.

Promover a ligao com os usurios

Isso quer dizer que sua funo garantir a disponibilidade dos dados de
que os usurios precisam, preparando-os ou os auxiliando na montagem
do nvel de vises.

Definir os controles de segurana e integridade

Ou seja, determinar quem tem acesso a que pores do banco de dados e
criar mecanismos que evitem inconsistncias na base de dados.

Definir a estratgia de backup e recuperao

funo do DBA ainda especificar como e quando sero feitos os backup
e desenvolver uma estratgia para recuperar informaes em caso de danos
ao banco de dados.

Monitorar o desempenho e atender s necessidades de

modificaes
O DBA deve organizar o sistema de modo a obter o melhor desempenho
possvel para a empresa.
113

Informtica 3

captulo 3

Figura 42

O conceito de logon est diretamente ligado ao princpio da autenticidade, pois,

antes de liberar o acesso a um recurso, o Windows precisa identificar o usurio
que est tentando fazer o acesso, ou seja, precisa autentificar o usurio.

Segurana em
banco de dados.

3.4.1.1.1. Definio de contas de usurios

Uma conta de usurio sua identidade para o Windows. Em outras palavras:
a maneira do programa identificar cada usurio. A partir do momento em que
possvel identifica-lo por meio do logon, o sistema tambm consegue manter
um ambiente personalizado para ele, bem como um conjunto de permisses
que definem o que ele pode e no pode fazer, a que recursos tem ou no acesso
e em que nvel.

3.4.1. Segurana em banco de dados

Quando falamos de segurana em banco de dados, precisamos ter em mente um
conceito muito simples: o usurio deve acessar somente os dados estritamente
necessrios para realizar seu trabalho no podemos lhe fornecer nenhuma outra permisso. Por exemplo, se a funo do usurio apenas realizar consultas,
no devemos permitir que possa tambm alterar, excluir ou inserir dados no
sistema, mas to somente que faa consultas (figura 42).

3.4.1.1. Segurana no sistema operacional

Antes de falar sobre a segurana em banco de dados, vamos abordar o tema
em relao ao sistema operacional. Vamos saber, por exemplo, como e porque
se deve fazer o logon no Windows ou qualquer outro sistema operacional. E
tambm porque no Windows a conta do usurio usada como se fosse sua
identidade, j que por meio da conta de logon desse sistema que conseguimos
identificar os usurios conectados e carregar configuraes personalizadas para
cada um deles. Alm disso, aprenderemos a criar e a administrar contas de usu
rios e de grupos de usurios para aumentar a segurana de nossos dados.
muito importante que estudemos as contas de usurios e grupos de usurios,
pois elas formam a base da estrutura de segurana no Windows. Para esse
sistema operacional fundamental identificar o usurio que est tentando
acessar determinado recurso, como uma pasta ou impressora compartilhada.
Uma vez identificado o usurio, o Windows pode determinar, com base nas
permisses de acesso, qual seu nvel de acesso e se ele tem ou no permisso
para acessar o recurso em questo. A identificao do usurio feita por meio
do logon, pois, para conectar, ele tem de informar ao sistema qual sua conta
de logon e digitar a respectiva senha. Feito o logon, o usurio est identificado
para o Windows.
114

Se voc est trabalhando em um computador isoladamente ou em uma pequena

rede para a qual no foi definido um domnio e os servidores rodam o Windows
2000 Server ou Windows Server 2003 e o Active Directory, as contas de usurios
so gravadas no prprio computador. Assim, cada computador ter sua lista prpria de contas de usurio, que so chamadas contas locais de usurio, traduo
para local user account. Os usurios de tais contas s podem fazer o logon no
computador em que estas foram criadas e acessar os recursos unicamente dessa
mquina. As contas locais so criadas em uma base de dados chamada base de
dados local de segurana (do ingls local security database). Ao fazer o logon, o
Windows compara o nome do usurio e a senha fornecida com os dados da base
de segurana local. Se os dados forem reconhecidos, o logon se completa. Caso
contrrio, negado e o sistema emite uma mensagem de erro.
J em redes de grande porte, baseadas em servidores Windows Server 2003, normalmente se criam domnios. Em um domnio existe apenas uma lista de contas de
usurios e grupos de usurios, a qual compartilhada por todos os computadores
que o integram. A lista de usurios mantida nos servidores da rede, nos chamados
Controladores de Domnios, ou DCs (do ingls Comain Controllers). Quando um
usurio faz o logon, por meio de uma conta da lista, atravs da rede, o Windows
verifica se ele forneceu nome e senha vlidos para o domnio e s libera a conexo
em caso afirmativo. Contas de domnio so armazenadas na base de segurana dos
servidores do domnio em questo, a qual conhecida como SAM no NT Server
4.0 e como Active Directory no Windows 2000 Server e no Windows Server 2003.

Permisses
ao usurio
administrador

Criar e excluir contas de

usurio no computador.
Criar senhas para
as contas dos outros
usurios no computador.
Alterar nomes, imagens,
senhas e tipos de contas
dos outros usurios.

H dois tipos de conta de usurio disponveis no seu computador: administrador do computador e limitada. Existe tambm uma conta de convidado (guest)
para usurios que no tm conta configurada no equipamento. Vejamos agora
quais so as caractersticas de cada tipo de conta.

Conta administrador
Destina-se ao usurio que pode alterar o sistema, instalar programas e acessar todos os arquivos armazenados. Este, portanto, ter permisso sobre
todos os recursos do computador, inclusive as contas de todos os outros
usurios. Sua nica restrio alterar o tipo de sua prpria conta para conta
limitada, a menos que o computador contenha um outro usurio com conta
de administrador. Tal restrio visa assegurar que haja sempre pelo menos
115

Informtica 3

captulo 3

um usurio com uma conta de administrador, ou seja algum com permisso para instalar novos programas, configurar o Windows e alterar as contas
de usurios.
As informaes so
o principal ativo das
corporaes. Assim,
devemos ter muito
cuidado ao definir
o acesso a seus
bancos de dados,
fazendo permisses
exclusivamente a
pessoas que devem
e podem acesslos e na medida
exata de suas
necessidades de
informao para o
trabalho.

Conta limitada
Como o prprio nome sugere, destina-se ao usurio com restries de permisso para usar os recursos do computador, como alterar a maioria das
configuraes ou excluir arquivos importantes. Esse usurio basicamente
s pode acessar programas j instalados e alterar a imagem de sua prpria
conta, alm de criar, alterar ou excluir sua prpria senha.

3.4.1.2. Permisses para banco de dados

Agora que j sabemos um pouco sobre como funciona a segurana em sistemas operacionais, vamos conhecer a estrutura de segurana em bancos
de dados, que bem similar, a ponto at de herdar algumas de suas caractersticas. Vejamos, primeiramente, alguns dos conceitos de permisses em
banco de dados.
Podemos definir, por exemplo, as seguintes permisses para um banco de dados:

Exemplo 1

Garantir para o login SERVIDOR\wilson a permisso

de criar novos bancos de dados:

USE Master

GRANT CREATE DATABASE TO [SERVIDOR\wilson]

Usamos, primeiro, o comando USE Master, para tornar o Banco de Dados

Master o banco atual, pois isto condio para que o sistema permita a
criao de novos bancos de dados. Na prtica: ao criar um banco de dados,
o usurio precisa gravar os dados nas tabelas do Banco de Dados Master,
que concentra as informaes sobre todo o contedo de uma instncia do
SQL Server.
Quando o login for um usurio do domnio do Windows, o nome deve vir entre
colchetes, como no exemplo: [SERVIDOR\wilson]
Podemos atribuir mais do que uma permisso ao mesmo tempo, para um ou
mais logins ou usurios.

Create Table (Criar Tabela).

Exemplo 2

Create View (Criar Consulta).

Atribuir as permisses CREATE TABLE, CREATE RULE

e CREATE VIEW, para o usurio SERVIDOR\wilson
no banco de dados Exemplo1.

USE Exemplo1

GRANT CREATE TABLE, CREATE RULE, CREATE VIEW

TO [SERVIDOR\wilson]

Exemplo 3

Para atribuir as permisses, utilizamos o comando GRANT, com a seguinte sintaxe:

Atribuir as permisses CREATE TABLE, CREATE RULE

e CREATE VIEW, para os usurios SERVIDOR\grupo1
e SERVIDOR \grupo2, no Banco de Dados Exemplo1.

GRANT { ALL | statement [ ,...n ] }

USE Exemplo1

TO security_account [ ,...n ]

GRANT CREATE TABLE, CREATE RULE, CREATE VIEW

TO [SERVIDOR \grupo1], [SERVIDOR \grupo2]

Create SP (Criar Stored Procedure).

Structured
Quary Language
(Linguagem
de Consulta
Estruturada)
criada no incio
da dcada de
1970, na IBM.

Create Default (Criar Default).

Create Rule (Criar Regra),
Create Function (Criar Funo).

Restries ao
usurio de
conta limitada

Instalar software
ou hardware (drivers)
Alterar o nome ou o tipo
de sua prpria conta (essa
atribuio exclusiva do
usurio com conta
de administrador).

Backup DB (Backup do Banco de Dados).

Backup Log (Backup do Log de transaes).

Agora vamos exemplificar a utilizao do comando GRANT.

116

117

Informtica 3

captulo 3

Abaixo, listamos as principais permisses de banco de dados que o comando

GRANT pode atribuir. Lembre-se de que para atribuirmos todas as permisses,
empregamos a palavra ALL (todos).

Mas, antes, confira a sintaxe para o comando REVOKE:

REVOKE { ALL | statement [ ,...n ] }

FROM security_account [ ,...n ]

Exemplo 1
Retirar a permisso de criar novos Bancos de Dados,
atribuda para o login SERVIDOR\wilson, anteriormente.

USE MASTER

REVOKE CREATE DATABASE TO [SERVIDOR\wilson]

Exemplo 2
Retirar as permisses CREATE TABLE, CREATE RULE
e CREATE VIEW, atribudas para o usurio SERVIDOR\wilson
no Banco de Dados Exemplo1.

J as principais permisses de objetos do banco de dados so estas:

USE Exemplo1
REVOKE CREATE TABLE, CREATE RULE, CREATE VIEW

SELECT: Tabelas, views e colunas.

TO [SERVIDOR\wilson]

INSERT: Tabelas e views.

DELETE: Tabelas e views.

UPDATE: Tabelas, views e colunas.

Exemplo 3
Retirar as permisses CREATE TABLE, CREATE RULE
e CREATE VIEW, atribudas para os usurios SERVIDOR\grupo1
e SERVIDOR\grupo2, no Banco de Dados Exemplo1.

EXECUTE: Stored Procedures.

USE Exemplo1

REVOKE CREATE TABLE, CREATE RULE, CREATE VIEW

TO [SERVIDOR\grupo1], [SERVIDOR\grupo2]

Exemplo 4
Retirar todas as permisses atribudas ao usurio SERVIDOR\
andrea, no Banco de Dados Exemplo1.

USE Exemplo1

REVOKE ALL

TO [SERVIDOR\andrea]

CREATE DATABASE: Banco de Dados master.

CREATE DEFAULT: todos os bancos de dados.

CREATE PROCEDURE: todos os bancos de dados.

CREATE RULE: todos os bancos de dados.

CREATE TABLE: todos os bancos de dados.

CREATE VIEW: todos os bancos de dados.

BACKUP DATABASE: todos os bancos de dados.

BACKUP LOG: todos os bancos de dados.

Exemplo
Atribuir todas as permisses para o usurio SERVIDOR\andrea, no banco de
dados Exemplo1.

USE Exemplo1
GRANT ALL
TO [SERVIDOR\andrea]

J para retirar as permisses de banco de dados, devemos recorrer ao comando

REVOKE. Saiba que podemos retirar mais do que uma permisso ao mesmo
tempo, para um ou mais logins, como mostramos nos exemplos 2 e 3.
118

119

Informtica 3

captulo 3

3.4.1.3. Permisses a objetos do banco de dados

As permisses a objetos aplicam-se aos diversos elementos de um banco de dados. Em uma
tabela, por exemplo, podemos ter permisso de leitura dos dados (SELECT), adio de novos registros (INSERT), excluso de registros (DELETE) e assim por diante. As permisses
a objetos so as que mais diretamente se relacionam com as atividades dirias dos usurios.

Como a sintaxe completa no nada simples, vamos recorrer a alguns exemplos

para ilustrar a utilizao do comando GRANT. Lembre-se de que podemos
atribuir mais do que uma permisso ao mesmo tempo, para um ou mais logins
ou usurios, como mostra o exemplo 2.

Exemplo 1
Para garantir ao usurio SERVIDOR\wilson a permisso de
selecionar novos registros e atualizar os registros existentes,
na tabela Clientes do Banco de Dados Exemplo1:

Use Exemplo1

GRANT SELECT, UPDATE ON Clientes

TO [SERVIDOR\wilson]

UPDATE: Tabelas, views e colunas.

Quando o login for um usurio do Windows, o nome deve

vir entre colchetes, como no exemplo:

EXECUTE: Stored procedures.

[SERVIDOR\wilson]

Exemplo 2
Garantir para os usurios SERVIDOR\wilson e SERVIDOR\andrea
a permisso de selecionar novos registros, atualiz-los
e exclu-los, na tabela Clientes do Banco de Dados Exemplo1:

Use Exemplo1

GRANT SELECT, UPDATE, DELETE ON Clientes

TO [SERVIDOR\wilson], [SERVIDOR\andrea]

Exemplo 3
Atribuir todas as permisses para o usurio SERVIDOR\andrea,
na tabela Clientes do Banco de Dados Exemplo1.

Se determinado usurio utiliza uma aplicao que acessa o banco de dados no servidor
SQL Server e deve ter permisso somente de leitura de dados de uma determinada tabela,
o incluiremos em um role com permisso SELECT na tabela e pronto, ele apenas poder
consultar os dados. A seguir confira quais so as principais permisses a objetos:
SELECT: Tabelas, views e colunas.
INSERT: Tabelas e views.
DELETE: Tabelas e views.

REFERENCES: Tabelas e colunas.

Tambm, para atribuir permisses de objetos do banco de dados devemos utilizar o comando GRANT. Nesse caso, a sintaxe do comando GRANT essa:

120

GRANT

{ ALL [ PRIVILEGES ] | permission [ ,...n ] }

[ ( column [ ,...n ] ) ] ON { table | view }

| ON { table | view } [ ( column [ ,...n ] ) ]

| ON { stored_procedure | extended_procedure }

| ON { user_defined_function }

TO security_account [ ,...n ]

USE Exemplo1

[ WITH GRANT OPTION ]

GRANT ALL ON Clientes

[ AS { group | role } ]

TO [SERVIDOR\andrea]

121

Informtica 3

captulo 3

Observe que, mais uma vez, utilizamos a palavra ALL, para indicar todas as
permisses. Para retirar as permisses de objetos do banco de dados utilizamos
REVOKE. Neste caso, a sintaxe do comando REVOKE a seguinte:

REVOKE SELECT, UPDATE, DELETE ON Clientes

REVOKE [ GRANT OPTION FOR ]

TO [SERVIDOR\wilson]

{ ALL [ PRIVILEGES ] | permission [ ,...n ] }

[ ( column [ ,...n ] ) ] ON { table | view }

Exemplo 3
Retirar todas as permisses atribudas ao usurio SERVIDOR\
andrea, na tabela Clientes do Banco de Dados Exemplo1.

| ON { table | view } [ ( column [ ,...n ] ) ]

USE Exemplo1

| ON { stored_procedure | extended_procedure }

REVOKE ALL ON Clientes

| ON { user_defined_function }

TO [SERVIDOR\andrea]

{ TO | FROM }

security_account [ ,...n ]

[ CASCADE ]

[ AS { group | role } ]

Agora, acompanhe nos exemplos abaixo a utilizao do comando REVOKE.

Nos Exemplos 2 e 3 mostramos que se pode retirar mais do que uma permisso
ao mesmo tempo, para um ou mais usurios.

122

Exemplo 1
Retirar a permisso UPDATE, atribuda para o usurio
SERVIDOR\wilson, anteriormente.

USE Exemplo1

REVOKE UPDATE ON Clientes

TO [SERVIDOR\wilson]

Exemplo 2
Retirar as permisses SELECT, UPDATE E DELETE, atribudas
para o usurio SERVIDOR\wilson na tabela Clientes do Banco
de Dados Exemplo1.

USE Exemplo1

Observe que novamente recorremos palavra ALL para indicar todas as permisses. J para negar as permisses de objetos do banco de dados utilizamos o
comando DENY. Veja qual a sintaxe do comando DENY:

DENY
{ ALL [ PRIVILEGES ] | permission [ ,...n ] }
{
[ ( column [ ,...n ] ) ] ON { table | view }
| ON { table | view } [ ( column [ ,...n ] ) ]
| ON { stored_procedure | extended_procedure }
| ON { user_defined_function }
}
TO security_account [ ,...n ]
[ CASCADE ]

Compreenda melhor essa relativamente complexa sintaxe por meio de trs

exemplos. Os de nmeros 2 e 3 mostram que podemos negar mais do que uma
permisso ao mesmo tempo, para um ou mais usurios.

Exemplo 1
Negar permisso UPDATE, para o usurio SERVIDOR\user1,
na tabela Clientes, do Banco de Dados Exemplo1.

USE Exemplo1
DENY UPDATE ON Clientes

TO [SERVIDOR\wilson]
123

Informtica 3

captulo 3

O Maintenance Plan
Wizard (assistente de
plano de manuteno)
elabora um plano de
manuteno que o
Agente Microsoft SQL
Server pode executar
regularmente. Tais
como tarefas de
administrao de
banco de dados,
backups, verificaes
de integridade de
banco de dados,
atualizao de
estatsticas.

Exemplo 2
Negar as permisses SELECT, UPDATE E DELETE, para o
usurio SERVIDOR\wilson, na tabela Clientes do Banco
de Dados Exemplo1.

USE Exemplo1

DENY SELECT, UPDATE, DELETE ON Clientes

TO [SERVIDOR\wilson]

Exemplo 3
Negar todas as permisses atribudas ao usurio
SERVIDOR\andrea, na tabela Clientes do Banco
de Dados Exemplo1.

USE Exemplo1

DENY ALL ON Clientes

TO [SERVIDOR\andrea]

3.4.2. Plano de manuteno de banco de dados

A partir de uma estratgia adequada de backup e restore, um plano de manuteno define uma srie de tarefas que devem ser executadas no banco de dados
para garantir o seu bom funcionamento e desempenho, bem como a disponibilidade das informaes. No plano de manuteno podemos prever tanto tarefas
de backup para evitar a perda de informaes, quanto de verificao da integridade dos objetos do banco de dados.
possvel criar um plano de manuteno manualmente, mas a maneira mais fcil e
prtica faz-lo por meio do assistente Maintenance Plan Wizard (plano de manuteno assistente). Esse programa capaz de criar e agendar a execuo peridica
de vrios jobs. Cada job realizar uma determinada tarefa que definirmos.
Agora, veremos como se cria um plano de manuteno pelo Wizard. Acompanhe as 24 etapas do passo a passo.
1. Abra o SQL Server Management Studio (Iniciar -> Programas -> Microsoft
SQL Server -> SQL Server Management Studio).
2. N
 a janela Object Explorer, localize a instncia SERVIDOR\SQL e d um
clique no sinal +, a seu lado, para o computador exibir as opes disponveis.
3. E
 ntre as opes que surgirem na tela, clique no sinal +, ao lado da opo
Management, para que sejam mostradas novas opes.

124

Figura 43
A tela inicial
do assistente.

4. Das opes exibidas agora, clique, com o boto direito do mouse, em Maintenance Plans. No menu seguinte, clique em Maintenance Plan Wizard.
5. Surgir agora a tela inicial do assistente, com uma mensagem informando sobre
o que se pode fazer com o programa. Clique ento no boto Next, seguindo
para a prxima etapa. Aparecer na tela uma pgina como a da figura 43.
6. N
 essa etapa voc definir em qual instncia do SQL Server ser criado o
plano de manuteno. Por padro, a instncia dentro da qual estava a opo
Management -> Maintenance Plans, na qual voc clicou com o boto direito
do mouse, j vem selecionada. Vamos aceitar a sugesto, pois exatamente
nesta instncia que queremos criar nosso plano de manuteno. Clique no
boto Next, seguindo para a etapa seguinte do assistente.
7. Nessa fase voc definir quais tarefas integraro o plano. Por padro, todas as
tarefas j vm selecionadas. So elas: Chek database integrity, Shrink database,
Defragment index(es), Re-index, Update statistics, History cleanup, Launxh
SQL Server agent job, Backup database (full), Backup database (Differential) e
Backup database (Transaction Log). Mantenha todas as opes marcadas, com
exceo de Backup database (Differential). Clique ento em Next.
8. A
 gora voc definir a ordem de execuo das tarefas. Para alterar a ordem,
marque uma determinada tarefa e depois clique no boto Move up, para
mov-la para cima na lista, ou Move down, para mov-la para baixo na lista.
No vamos alterar a ordem sugerida. Assim, clique novamente em Next, e
passemos fase seguinte.
9. Abra a lista Select one or more. Aparecero diversas opes. Nesta etapa podemos definir se o plano de manuteno incluir todos os Bancos de Dados
da Instncia (All databases) ou apenas os do sistema (All system databases
master, model, and msdb). E ainda se incluir todos os Bancos de Dados do
Usurio (All user databases all databases other than master, model, and
msdb) ou apenas os selecionados (These specific databases). A opo These

Tarefas que os jobs

criados pelo Database
Maintenance Plan Wizard
podem executar:
Reorganizar os dados nas
pginas de dados e ndices,
por meio da reconstruo
dos ndices com um novo
valor para o parmetro Fill
Factor. Isto garante melhor
distribuio dos dados, com
melhoria no desempenho.
Compactar o banco de
dados, removendo pginas
de dados vazias.
Atualizar uma srie de
informaes (Indexes
Statistics) sobre os ndices
do banco de dados.
Fazer a verificao interna
na consistncia dos dados
para certificar-se de que
esses no esto corrompidos
ou em estado inconsistente.
Agendar o backup do
banco de dados e do log
de transaes.

125

Informtica 3

captulo 3

Figura 45

specific databases j vem marcada por padro. Na lista de bancos de dados

selecionamos os que queremos incluir no plano de manuteno.

Aceitando as
configuraes padro.

10. Clique em OK para fechar a lista de opes e certifique-se de que marcou a

opo Include indexes, para garantir que a otimizao dos ndices do banco
de dados AdventureWorks seja includa no plano. Agora clique em Avanar
para chegar fase seguinte do assistente.
11. Nessa etapa, definiremos para quais bancos de dados sero criadas tarefas
de otimizao. Abra a lista Select one or more, que mostrar diversas opes
j descritas anteriormente. A opo These specific databases j vem selecionada por padro. Na lista de bancos de dados podemos selecionar os que
desejamos incluir no plano de manuteno. Em nosso exemplo, incluiremos
apenas o Banco de Dados AdventureWorks. Certifique-se, assim, de que este
esteja selecionado. Clique em OK para fechar a lista de opes. Ao selecionar
um banco de dados, sero habilitadas as pores de otimizao e recuperao de espao. Aceite as configuraes sugeridas e clique no boto Next para
seguir para a prxima etapa do assistente.
12. Agora podemos definir uma srie de configuraes a respeito da otimizao dos
ndices e das pginas de dados do banco de dados. Nesta fase voc tem trs listas
de opes. Na primeira poder ver quais bancos de dados sero includos no
plano de manuteno, para terem os ndices de suas tabelas e views desfragmentados. Abra a primeira lista (Database(s):) e selecione somente o banco de dados
AdventureWorks. Na segunda lista (Object), selecione a opo Table (para otimizar somente os ndices das tabelas), a opo View (para otimizar somente os
ndices das views) ou a opo Tables and Views (para otimizar tanto os ndices
das tabelas quanto das views). Selecione agora Tables and Views. Automaticamente, sero selecionadas todas as tabelas e views. Se voc selecionar uma opo
individual, como por exemplo Table, na terceira lista, poder marcar somente
determinadas tabelas, para otimizao de ndices. Com as opes selecionadas,
sua janela deve ficar semelhante que mostramos na figura 44.
Figura 44
As opes
tabelas e views.

13. C
 lique agora no boto Next para seguir prxima etapa do assistente.
14. Nessa fase vamos escolher os bancos de dados em que sero criadas tarefas,
as quais, ao serem executadas, recriaro os ndices. As trs primeiras listas
funcionam de modo idntico s trs listas apresentadas na figura 45. Na primeira lista voc marcar um ou mais bancos de dados, na segunda selecionar as opes Table, Views ou Tables and Views e, na terceira, os objetos,
individualmente, dependendo de qual opo foi selecionada na segunda lista.
Para o nosso exemplo, selecione, na primeira lista, o banco de dados AdventureWorks e, na segunda, a opo Tables and Views. Mantenha as demais opes
inalteradas. E clique em Next para seguir adiante.
15. Nessa fase, voc selecionar para quais bancos de dados sero criadas tarefas
para atualizar as estatsticas das tabelas e views. As trs primeiras listas funcionam exatamente como as trs mostradas na figura 46. Marque, na primeira
lista, um ou mais bancos de dados. Na segunda, selecione as opes Table,
Views ou Tables and Views e, na terceira lista, os objetos, individualmente, dependendo de qual opo foi selecionada na segunda lista. Para nosso exemplo,
escolha, na primeira lista, o banco de dados AdventureWorks e, na segunda, a
opo Tables and Views. Mantenha as demais opes inalteradas e clique no
boto Next para passar fase seguinte do assistente.

Esta tela tem uma

srie de opes
avanadas, que
somente um DBA
experiente dever
alterar. Portanto,
somente modifique
essas opes se
souber exatamente
o que est fazendo.

16. N
 essa etapa voc selecionar quais opes de histricos sero limpas quando
as tarefas do plano de manuteno (especficas para limpeza dos histricos)
forem executadas e a periodicidade da execuo. Voc pode marcar as opes Backup and Restory history, SQL Server Agent Job history e Database
Maintenance Plan History. Por padro, as trs opes j vm selecionadas.
Na parte de baixo da janela, voc definir quais dados devem ser excludos
do histrico. Por padro tambm, j vem selecionada a opo 4 Week(s),
significando que sero criadas tarefas, no plano de manuteno, para excluir
126

127

Informtica 3

captulo 3

Figura 46

texto desta conta, que, portanto, dever ter todas as permisses necessrias
para executar as tarefas do plano de manuteno. No vamos configurar
uma conta como Proxy Account em nosso exemplo. Ento, clique novamente em Next.

Finalizando a
criao do plano de
manuteno.

22. N
 essa etapa voc definir em qual pasta ser gravado um relatrio sobre o
plano de manuteno. Por padro, vem selecionada a pasta C:\. Aceite as
configuraes sugeridas e clique em Next.
23. S er exibida agora a tela final do Wizard. Se voc precisar alterar alguma
opo, recorra ao boto Back. Para finalizar o assistente e criar o plano de
manuteno, clique em Finish. O SQL Server mostrar o progresso da criao do plano de manuteno, conforme indica a figura 46.
24. U
 ma vez concluda a criao do plano de manuteno, o sistema exibir
uma janela com o resultado da criao. Clique em Close para fechar a janela. Pronto, o plano de manuteno foi criado.
dados que tenham sido gravados mais de quatro semanas antes nos histricos selecionados. Aceitaremos as configuraes padro. Agora clique em
Next, seguindo adiante.
17. Nessa etapa sero exibidos os jobs j existentes, criados anteriormente.
Voc pode marcar um ou mais jobs para serem executados, tambm como
parte do plano de manuteno. No nosso exemplo, incluiremos todos os
jobs j existentes. Portanto, certifique-se de que todos foram selecionados
e clique em Next.
18. A gora voc definir para quais bancos de dados sero criadas tarefas de
backup, como parte do plano de execuo. Abra a lista Databases e, abaixo da opo These specific databases, marque o banco de dados AdventureWorks e clique em OK. As demais opes sero habilitadas. Voc pode
definir se o backup ser feito em disco ou fita e em qual pasta (no caso de
backup em disco), se os backups j existentes devem ser sobrescritos ou no
e assim por diante. Defina as opes desejadas e clique em Next.
19. Nessa etapa voc pode criar tarefas que faro o backup diferencial de um
ou mais bancos de dados. Vamos incluir um backup diferencial do banco
de dados AdventureWorks como parte do plano de manuteno. Na lista
Database(s): selecione o banco de dados AdventureWorks e clique em OK.
Aceite as demais opes e clique em Next, seguindo fase seguinte.
20. Nessa etapa voc poder criar tarefas que faro o backup do log de transaes de um ou mais bancos de dados. Vamos incluir um backup do log do
banco de dados AdventureWorks, como parte do plano de manuteno. Na
lista Database(s): selecione o banco de dados AdventureWorks e clique em
OK. Aceite as demais opes e siga adiante, clicando em Next.
21. A gora voc poder definir uma conta conhecida como Proxy Account. Se
for configurada uma conta como esta, as tarefas sero executadas no con128

3.4.3. Uma linguagem verstil: SQL

Segundo Oliveira (2000), quando os bancos de dados relacionais estavam em
desenvolvimento, foram criadas linguagens para manipul-los. A SQL (sigla
do ingls Structured Query Language, literalmente Linguagem de Consulta
Estruturada) foi desenvolvida no incio dos anos 1970, no departamento de
pesquisas da IBM, como interface para o sistema de banco de dados relacional
denominado SYSTEM R. Em 1986, o American National Standard Institute
(ANSI) publicou um padro de SQL e essa linguagem acabou se tornando
padro de banco de dados relacional.
A SQL apresenta uma srie de comandos para definir dados, chamada de
DDL (Data Definition Language ou linguagem de definio de dados) a qual
composta, entre outros, pelo Create, que se destina tarefa de criar bancos
de dados. J os comandos da srie DML (Data Manipulation Language ou
linguagem de manipulao de dados), possibilitam consultas, inseres, excluses e alteraes em um ou mais registros de uma ou mais tabelas de maneira simultnea. Uma subclasse de DML, a DCL (Data Control Language
ou linguagem de controle de dados) dispe de comandos de controle, como o
prprio nome diz.
Conforme Oliveira (2000), a grande virtude da linguagem SQL sua capacidade de gerenciar ndices sem a necessidade de controle individualizado de ndice corrente, algo muito comum nas linguagens de manipulao
de dados do tipo registro a registro. Outra caracterstica bastante importante em SQL sua capacidade de construo de vises, ou seja, formas de
visualizar os dados em listagens independentes das tabelas e organizaes
lgicas dos dados.

importante notar
que a linguagem SQL
s pode nos fornecer
tais solues, porque
est baseada em
bancos de dados,
que garantem por
si mesmo a integridade
das relaes existentes
entre as tabelas
e seus ndices.

Tambm interessante na linguagem SQL o fato de permitir o cancelamento de

uma srie de atualizaes ou de grav-las, depois que iniciarmos uma sequncia
de atualizaes. Isto pode ser feito por meio dos comandos Commit e Rollback.
129

Informtica 3

captulo 3

3.4.3.1. Como utilizar os comandos SQL

[, MAXSIZE = tamanho_maximo]

Segundo Oliveira (2001) a linguagem SQL foi desenvolvida para acessar os bancos de dados relacionais. Seu objetivo fornecer um padro de acesso aos bancos
de dados, seja qual for a linguagem usada em seu desenvolvimento. Mas, apesar
da tentativa de torn-la um padro (ANSI), cada fornecedor hoje possui uma
srie de extenses que deixam as vrias verses incompatveis entre si. Alguns
bancos de dados suportam o padro SQL ANSI-92, mais abrangente, o que
representa um esforo para facilitar o processo de tornar transparente a base de
dados utilizada pela aplicao. Entretanto, nem todos os fornecedores j oferecem suporte completo ao SQL ANSI-92 porque para isto teriam de alterar
partes estruturais de seus sistemas gerenciadores.

[, FILEGROWTH = taxa_crescimento]

} [, n]

3.4.3.2. Categorias da Linguagem SQL

De acordo com Oliveira (2001), as instrues SQL podem ser agrupadas em trs
grandes categorias:

D
 DL (Declaraes de Definio de Dados): parte da linguagem com
comandos para criao de estruturas de dados como tabelas, colunas, etc.
Exemplo: CREATE TABLE.

D
 ML (Declaraes de Manipulao de Dados): parte da linguagem com

comandos para acessar e alterar os dados armazenados no banco de dados.

Os principais comandos dessa categoria so: SELECT, UPDATE, INSERT
e DELETE.

D
 CL (Declaraes de Controle de Dados): parte da linguagem com co-

mandos para definir usurios e controlar seus acessos aos dados. Exemplo:
GRANT.

3.4.3.2.1. Instrues SQL

Instruo CREATE DATABASE
De acordo com Oliveira (2000), para gerenciar os bancos de dados com comandos SQL necessrio que se esteja posicionado no banco de dados Master. Podemos criar um banco de dados com o comando SQL, CREATE DATABASE.
A sintaxe completa :

130

CREATE DATABASE nome_bancodedados

[ON {

[PRIMARY] (NAME = nome_logico_arquivo,

[LOG ON

(NAME = nome_logico_arquivo.

FILENAME = caminho_e_nome_arquivo

[, SIZE = tamanho])

} [, ..n]

Onde:

Nome_bancodedados: o nome do banco de dados que se deseja criar.

N
 ome_logico_arquivo: um nome usado para referenciar o arquivo em
quaisquer comandos SQL executados depois que o banco de dados tiver
sido criado.

P
 RIMARY: especifica o grupo de arquivos primwrio. Esse grupo deve conter todas as tabelas de sistema para o banco de dados. Um banco de dados s
pode ter um grupo de arquivo PRIMARY. Se no for especificado algum, o
primeiro listado ser o primrio.

F ILENAME: aqui se deve especificar o caminho e o nome do arquivo que

estamos criando. O arquivo deve necessariamente estar na mesma mquina
que o servidor SQL, mas pode estar em uma unidade de disco diferente.

S IZE: especifica o tamanho em megabytes que queremos alocar para o banco de dados. O valor mnimo de 1MB, mas o padro 3MB para arquivos
de dados e 1MB para arquivos de log.

M
 AXSIZE: permite especificar o tamanho mximo que o arquivo pode

FILENAME = caminho_e_nome_arquivo

[, SIZE = tamanho]

atingir. O padro possibilita que o arquivo cresa at que o disco fique

cheio.

F ILEGROWTH: especifica a taxa de crescimento do arquivo. Esse ajuste

no pode exceder a configurao de MAXSIZE. Um valor zero indica que

no permitido aumento. O padro 10%, significando que cada vez que
o arquivo cresce, ser alocado um espao adicional de 10% para ele. Um
131

Informtica 3

captulo 3

banco de dados que estiver em mais de um arquivo s expandido depois

que o ltimo arquivo se completar.

L OG ON: se aplicam aqui as mesmas definies mostradas anteriormente,

exceto pelo fato de que se criar o arquivo de log de transaes, e no o

arquivo de dados.

Sintaxe simplificada:

CREATE DATABASE [IF NOT EXISTS] nome_banco_de_dados

Ateno: se no especificarmos IF NOT EXISTS, e o banco de dados j existir,

ocorrer um erro.
Exemplo utilizando o MYADMIN:
No exemplo criaremos um banco de dados com o nome banco_teste, como
mostra a figura 47: CREATE DATABASE banco_teste
Digitamos a instruo e clicamos no boto executar, para obter o retorno do
myadmin apresentado na figura 48.
Figura 47
Criando um
banco de dados.

Instruo CREATE TABLE

Como sugere o nome, usada para criar tabelas. Ateno para sintaxe:

CREATE TABLE Nome_Tabela

( Nom_Coluna_1 Tipo [CONSTRAINT PRIMARY| KEY| NOT

NULL ]

Nom_Coluna_n Tipo [CONSTRAINT PRIMARY| KEY| NOT

NULL ])

Exemplo:
CREATE TABLE Cliente (codigo int(7), nome varchar(40), endereco varchar(40)). Observe a figura 49.
Devemos clicar no boto executar, para ter o resultado da criao da tabela que
aparece na figura 50.
Podemos verificar no lado esquerdo da tela que, agora, nosso banco de dados
banco_teste possui uma tabela.

Clusula INSERT
O comando INSERT insere linhas em uma tabela e, sua forma mais simples,
somente uma linha de dados. A sua sintaxe :

Figura 48
Retorno
do myadmin.

132

INSERT [INTO] nome_tabela (colunas )

VALUES ( valores )
Figura 49
Criando uma
tabela.

133

Informtica 3

captulo 3

Figura 52

Figura 50
A tabela criada.

Incluso de um
registro.

Figura 53
Verificando
a incluso.

Onde:
Nome_tabela: o nome da tabela em que se deseja incluir os dados.
Colunas: parte da tabela onde se deseja acrescentar os dados.
Valores: o contedo de cada coluna.
Exemplo no MYSQL:

Figura 54

INSERT INTO Cliente (codigo, nome, endereco) VALUES (123, WILSON,

CAIXA POSTAL: 155 ITU). Como ilustra a figura 51.

Registro do
cliente Wilson.

Figura 51
Uso do INSERT.

Clusula UPDATE

Com esta instruo, iremos incluir um registro, como mostra a figura 52.
Para verificar a incluso, utiliza-se a instruo select, conforme mostra
a figura 53.
Select * from cliente
E teremos o resultado mostrado na figura 54, na qual aparece listado somente o
cliente Wilson.
134

Conforme Oliveira (2001), a clusula UPDATE tem a finalidade de alterar

campos de um conjunto de registros. Ou seja, para modificarmos uma ou
mais linhas existentes, devemos utilizar a declarao UPDATE, cuja sintaxe
a seguinte:

UPDATE tabela

SET coluna=valor

Where condio
135

Informtica 3

captulo 3

Figura 57

Onde:

O nome do cliente
completo na tabela.

Tabela: o nome da tabela a ser atualizada.

Coluna: o nome da coluna a ser atualizada.
Valor: o novo valor para a coluna.
SET: determina os campos que recebero os valores.
Where: determina em quais registros a mudana ocorrer. Na sua ausncia, a
mudana ocorrer em todos os registros da tabela.
Exemplo em MYSQL:

UPDATE Cliente
Set nome = Wilson Oliveira
Where codigo= 123. (figura 55)

Para conferir, vamos fazer um select na tabela:

Select * from cliente. Acompanhe na figura 56.
Podemos observar na figura 57, que o nome do cliente agora aparece como Wilson Oliveira e no mais Wilson, apenas.
Figura 55

Clusula DELETE
Tem a funo de eliminar registros de uma tabela. O comando DELETE exclui
permanentemente uma ou mais linhas, baseado em uma condio. Sintaxe :
DELETE From nome_tabela Where condio
Onde:
Nome_tabela: o nome da tabela em que se deseja excluir os dados.
Where: determina quais registros sero eliminados da tabela.
Condio: a condio para selecionar os dados que se deseja excluir.

Clusula update.

DELETE FROM Cliente Where codigo = 123. Veja a figura 58.

Quando damos o comando DELETE, o mysql solicita a confirmao, para

que no cometamos um erro irreparvel (ou quase, pois teramos que retornar o
backup ou redigitar os dados eliminados), como ilustra a figura 59.
Figura 58
O comando
DELETE.

Figura 56
Select na tabela.

136

137

Informtica 3

captulo 3

Figura 59

Comando SELECT

Para confirmar o
comando DELETE.

O Comando SELECT busca informaes de um banco de dados. A sintaxe :

Se confirmarmos, teremos o retorno, conforme se apresenta na figura 60.

preciso, ento, fazer um select para verificar se o registro foi realmente eliminado
(figura 61).
Podemos observar na figura 62 que, de acordo com o retorno, no h nenhum
registro em nossa tabela.
Figura 60
O retorno
depois do delete.

SELECT [DISTINCT] {*, coluna [alias], ...}

FROM tabela;

Onde:
DISTINCT: elimina as colunas duplicadas da consulta.
*: seleciona todas as colunas da tabela.
Coluna: especifica as colunas desejadas na pesquisa.
alias: fornece s colunas diferentes cabealhos.
FROM: especifica em qual tabela desejamos realizar a consulta.
Tabela: especifica que tabela ser utilizada para pesquisa.

Figura 61
O select para
verificar o registro.

Exemplo:
SELECT codigo, nome
FROM departamento;

Exemplo com alias:

SELECT nome Nome, salario*12 Salrio Anual

FROM empresas;

Vamos fazer algumas incluses para melhor verificao das instrues SELECT:

INSERT INTO Cliente (codigo, nome, endereco) VALUES (123,

WILSON OLIVEIRA, CAIXA POSTAL: 155 ITU);
Figura 62
Sem registro
na tabela.

INSERT INTO Cliente (codigo, nome, endereco) VALUES (145,

ANDREA SIRTORI OLIVEIRA, CAIXA POSTAL: 135 ITU);

INSERT INTO Cliente (codigo, nome, endereco) VALUES (567, LU

CAS OLIVEIRA, CAIXA POSTAL: 111 ITU);

INSERT INTO Cliente (codigo, nome, endereco) VALUES (345,

JOSE FRANCISCO, CAIXA POSTAL: 45 ITU);

INSERT INTO Cliente (codigo, nome, endereco) VALUES (777,

AMANDA SIRTORI, CAIXA POSTAL: 233 ITU);

138

139

Informtica 3

captulo 3

Figura 63

Figura 65

O comando
SELECT.

Verificao
dos registros
includos.

Figura 66
O resultado
da verificao.

Observe a figura 63.

O resultado da incluso aparece na figura 64.
Agora, faamos um select para verificar os registros includos: Select * from cliente (figura 65). Teremos o que aparece na figura 66.

3.4.3.4. Views (Vises)

Uma viso (view) uma forma alternativa de olhar os dados de uma ou mais
tabelas. Para definir uma viso, usa-se um comando SELECT, que faz uma consulta sobre as tabelas. A viso aparece depois, como se fosse uma tabela.
Uma view como uma janela que d acesso aos dados da tabela, mas com restries. Tem, no entanto, uma srie de vantagens:
U
 ma viso pode restringir quais colunas da tabela podem ser acessadas (para
leitura ou modificao), o que til no caso de controle de acesso.
Uma consulta SELECT, usada muito frequentemente, pode ser criada como
viso. Com isso, a cada vez que necessrio fazer uma consulta, basta selecionar dados da viso.
Vises podem conter valores calculados ou valores de resumo, o que simplifica a operao.
Figura 64
O resultado
da incluso.

Criando uma viso com comandos SQL

Para criar uma viso atravs de SQL, usamos o comando CREATE VIEW. Este
comando possui a seguinte sintaxe:

CREATE VIEW nome_visao [(coluna [,...n])]

[WITH ENCRYPTION]

AS

Declarao_select

[WITH CHECK OPTION]

Onde:
Nome_visao: o nome a ser dado viso.
Coluna: o nome a ser usado para uma coluna em uma viso. Nomear uma coluna em CREATE VIEW s necessrio quando uma coluna obtida por uma
140

141

Informtica 3

captulo 3

expresso aritmtica, uma funo, ou quando duas ou mais colunas poderiam

ter o mesmo nome (frequentemente por causa de uma juno), ou ainda quando
a coluna em uma viso recebe um nome diferente do nome da consulta da qual
se originou. Os nomes de colunas tambm podem ser atribudos no comando
SELECT. Caso seja necessrio nomear mais de uma coluna, entre com o nome
de cada uma delas separado por vrgulas.

SELECT MAX(SALARIO), MIN(SALARIO), AVG(SALARIO)

FROM EMPREGADO

WITH ENCRYPTION: criptografa as entradas na tabela syscomments

que contm o texto do comando CREATE VIEW.

WITH CHECK OPTION: fora todas as modificaes de dados executadas

na viso a aderirem os critrios definidos na declarao SELECT. Quando uma
coluna modificada por meio de uma viso WITH CHECK OPTION garante
que os dados permaneam visveis por meio da viso depois que as modificaes
forem efetivadas.
Exemplo:
A seguir, estamos criando uma VIEW que mostrar o CODIGO, NOME e
SALARIO dos funcionrios da tabela empregado, cujos salrios so maiores que
R$ 1.000,00. Esta View ter o nome EMPM1000.

CREATE VIEW empm1000 AS

SELECT CODIGO, NOME, SALARIO
FROM EMPREGADO
WHERE SALARIO > 1000

Nossa View de nome EMPM1000 foi criada, agora iremos dar um

select nela.

SELECT O FROM EMPM1000

E teremos o resultado dos funcionrios com salrio maior que R$ 1.000,00

142

Para vermos o resultado, devemos dar um select em nossa view.

SELECT * FROM EMPMEDIA

3.4.3.5. Stored Procedures (procedimento armazenado)

Um Stored Procedure (procedimento armazenado) um conjunto de comandos
SQL que so compilados e guardados no servidor. Pode ser acionado a partir de
um comando SQL qualquer. Em alguns sistemas de banco de dados, armazenar
procedimentos era uma maneira de pr-compilar parcialmente um plano de
execuo, o qual ento ficava abrigado em uma tabela de sistema. A execuo
de um procedimento era mais eficiente que a execuo de um comando SQL
porque alguns gerenciadores de banco de dados no precisavam compilar um
plano de execuo completamente, apenas tinha que terminar a otimizao do
plano de armazenado para o procedimento. Alm disso, o plano de execuo
completamente compilado para o procedimento armazenado era mantido na
cache dos procedimentos, significando que execues posteriores do procedimento armazenado poderiam usar o plano de execuo pr-compilado.
A vantagem de usar procedimentos armazenados que estes podem encapsular
rotinas de uso frequente no prprio servidor, e estaro disponveis para todas as
aplicaes. Parte da lgica do sistema pode ser armazenada no prprio banco de
dados, e no precisa ser codificada vrias vezes em cada aplicao.

Criando procedimentos armazenados

Para criar um procedimento, devemos utilizar o comando CREATE PROCEDURE. Por exemplo, o procedimento demonstrado a seguir recebe um parmetro (@nome) e mostra todos os clientes cujos nomes contenham a informao:

Outro exemplo:

CREATE PROCEDURE BUSCACLIENTE

Criaremos uma View chamada EMPMEDIA, baseados na tabela EMPREGADO, que mostrar o maior salrio, o menor salrio e a mdia salarial. Utilizaremos o recurso de Alias para mudar os nomes das colunas da View para
MAIOR, MENOR e MEDIA, conforme o exemplo seguinte:

@nomebusca varchar(50)
As

SELECT codcliente, Nome from CLIENTE

WHERE Nome LIKE %+@nomebusca+%

CREATE VIEW EMPMEDA

(MAIOR, MENOR, MEDIA)

AS

Devemos notar que os parmetros so sempre declarados com @, logo aps o

nome do procedimento. Um procedimento pode ter zero ou mais parmetros.
Declara-se o nome do procedimento e a seguir o tipo de dados do parmetro. Ao invs de CREATE PROCEDURE, pode-se utilizar CREATE PROC,
com o mesmo efeito.
143

Informtica 3

captulo 3

Dentro do procedimento pode haver vrios comandos SELECT e o seu resultado ser do procedimento. O corpo do procedimento comea com a palavra AS
e vai at o seu final.
No se pode usar os comandos SET SHOWPLAN_TEXT, e SET SHOWPLAN_ALL dentro de um procedimento armazenado, pois esses devem ser os
nicos comandos de um lote (batch).

Executando procedimentos armazenados

Para executar um procedimento usa-se o comando EXEC (ou EXECUTE).
A palavra EXEC pode ser omitida, se a chamada de procedimento for o primeiro comando em um Script ou vier logo aps um marcador de fim de lote
(a palavra GO).
Por exemplo, podemos executar o procedimento anterior da seguinte forma:
BuscaCliente an
Os resultados sero as linhas da tabela cliente onde o valor de nome contm an
(se existirem tais linhas).
Ao executar um procedimento, podemos informar explicitamente o nome de
cada parmetro, por exemplo:

Exemplo de Gatilhos:
Para utiliz-los, temos que criar antes algumas tabelas que sero usadas como
exemplo. A tabela notafiscal conter os cabealhos de notas fiscais. A tabela item
notafiscal ir conter itens relacionados com as notas fiscais. Execute o Script a
seguir para criar as tabelas:

CREATE TABLE NOTAFISCAL

(NumeroNota numeric(10) primary key,

ValorTotal numeric(10,2) default(0))

GO

CREATE TABLE ITEMNOTAFISCAL

(NumeroNota numeric(10) foreign key references NotaFiscal,

CodProduto int foreign key references Produto,

Quantidade int not null check (Quantidade > 0),

Primary key (NumeroNota, CodProduto)

BuscaCliente @nomeBusca = an
Isso permite passar os parmetros (se houver mais de um) fora da ordem em que
eles foram definidos no procedimento.
EXEC tambm pode executar um procedimento em outro servidor. Para isso,
a sintaxe bsica :

Vamos utilizar Gatilhos para duas finalidades. Primeiro, ao excluirmos uma

nota fiscal, todos os seus itens sero excludos automaticamente. Depois,
quando incluirmos um item, a coluna Valor Total ser atualizada na tabela
NotaFiscal.

Criando os Gatilhos

EXEC

Nome_servidor.nome_banco_de_dados.nome_procedimentos

Triggers (Gatilhos)

Gatilhos so sempre criados vinculados a uma determinada tabela. Se a tabela for excluda, todos os seus Gatilhos sero excludos como consequncia. Ao
criarmos um Gatilho, podemos especificar em qual ou quais operaes ele ser
acionado: INSERT, UPDATE ou DELETE.

Gatilho para insero

Um Gatilho (Triggers) um tipo de Stored Procedure, que executado automaticamente quando ocorre algum tipo de alterao numa tabela. Gatilhos
disparam quando ocorre uma operao INSERT, UPDATE ou DELETE
numa tabela. Geralmente so usados para reforar restries de integridade
que no podem ser tratadas pelos recursos mais simples, como regras, defaults, restries, a opo NOT NULL, etc. Deve-se usar defaults e restries
quando estes fornecem toda a funcionalidade necessria. Um Gatilho tambm pode ser empregado para calcular e armazenar valores automaticamente
em outra tabela.
144

Realiza a incluso de uma ou mais linhas na tabela virtual chamada inserted,

que contm as linhas que sero includas (mas ainda no foram). Essa tabela
tem a mesma estrutura da tabela principal. Podemos consultar dados nela com
o SELECT, da mesma forma que uma tabela real.
Vamos criar um Gatilho, chamado InclusaoItemNota, que ser ativado por uma
operao INSERT na tabela ItemNotaFiscal. Primeiro, ele vai verificar se os
valores que estiverem sendo inseridos possuem uma Nota Fiscal relacionada ou
no. Devemos digitar as instrues a seguir:
145

Informtica 3

captulo 3

CREATE TRIGGER InclusaoItemNota

CREATE TRIGGER ExclusaoNota

On ItemNotaFiscal for insert

On NotaFiscal for delete

As

As

If not exists (select * from

Delete from ItemNotaFiscal

Inserted, NotaFiscal

Where NumeroNota in (select NumeroNota from deleted)

Where inserted.NumeroNota = NotaFiscal.NumeroNota)

Raiserror(Esse item no contm um nmero de nota vlido)

Update NotaFiscal

Set ValorTotal = ValorTotal +

(select i.Quantidade * p.preco from produto p, inserted i

Where p.codProduto = i.CodProduto)

Where NumeroNota = (select NumeroNota from inserted)

Primeiramente, o Gatilho usa as tabelas inserted e NotaFiscal para consultar se

existe o valor de NumeroNota na tabela. Caso no exista, o comando RAISERROR gera um erro de execuo, com uma mensagem que ser retornada para a
aplicao. Esse comando efetivamente cancela o comando INSERT que estiver
sendo executado.
Depois verifica a quantidade que est sendo inserida (inserted.Quantidade)
e multiplica pelo preo do produto (Produto.Preco). Este preo encontrado
na tabela do produto usando como valor de pesquisa o cdigo do produto
(inserted.CodProduto). Ele atualiza a nota fiscal relacionada com o item que
est sendo inserido, para isso verifica Where NumeroNota=(select NumeroNota from inserted).

Gatilhos para excluso

Na excluso, as linhas da tabela so removidas e colocadas na tabela virtual default deleted, que tem a mesma estrutura da tabela principal. Um
Gatilho para excluso pode consultar deleted para saber quais linhas
foram excludas.
Vamos criar um Gatilho na tabela NotaFiscal para que, quando a nota fiscal
for excluda, todos os seus itens de nota relacionados na tabela ItemNotaFiscal,
sejam excludos em cascata. Para isso, devemos utilizar a seguinte sequncia:
146

Gatilhos para atualizao

As tabelas inserted e deleted, como j vimos, so tabelas virtuais que podem ser usadas dentro de um Gatilho. A primeira contm os dados que esto sendo
inseridos na tabela real e a segunda, os dados antigos, que esto sendo includos.
Num Gatilho de atualizao (FOR UPDATE), essas duas tabelas tambm esto
disponveis. No caso, deleted permite acessar os dados como eram antes da
modificao e inserted d acesso aos dados depois da atualizao.
Podemos ento considerar uma atualizao como uma excluso seguida de uma
insero (excluem-se valores antigos e inserem-se valores novos).
Por exemplo, ao mudar a quantidade em um ItemNotaFiscal, o total da Nota
deve ser recalculado. Para isso levada em conta a diferena entre a quantidade
antiga (deleted.Quantidade) e a nova (inserted.Quantidade). Vamos agora criar
um Gatilho em ItemNotaFiscal que faz isso:

CREATE TRIGGER AlteracaoItemNota

On ItemNotaFiscal for update

As

If update(Quantidade) or update(CodProduto)

Begin

Update NotaFiscal

Set ValorTotal = ValorTotal +

(select p.preco * (i.Quantidade d.Quantidade)

From Produto p inner join inserted i

147

Informtica 3

captulo 3

On p.CodProduto = i.CodProduto inner join deleted d

On i.CodProduto = d.CodProduto and i.NumeroNota

= d.NumeroNota)
End

Figura 68
O resultado
da instruo.

Note que o uso de if update(nome_da_coluna), dentro de um Gatilho de

atualizao, permite descobrir se a coluna est sendo alterada ou no. Isso para
evitar trabalho desnecessrio, caso no haja alguma modificao.

3.4.3.6. Um exemplo completo

Vamos construir um exemplo utilizando o phpMyAdmin com o banco de dados
MySQL. Primeiro, vamos criar um banco de dados chamado ERP, onde armazenaremos as tabelas referentes ao nosso sistema de gesto empresarial.

Figura 69
Instruo a partir
do phpMyAdmin.

Para criar esse banco de dados devemos utilizar a seguinte instruo:

CREATE DATABASE erp

Na figura 67, mostramos como ser a instruo utilizando o phpMyAdmin.

O resultado o sucesso da instruo, como se pode observar na figura 68.
Agora, vamos criar uma tabela de clientes. Para isso, utilizaremos a seguinte
instruo:

Figura 70
Instruo
bem sucedida.

CREATE TABLE Cliente (codigo int(7), nome varchar(40), endereco

varchar(40))
Na figura 69 mostramos como ser a instruo utilizando o phpMyAdmin.
Podemos observar o sucesso da instruo na figura 70.
Figura 67
Usando o
phpMyAdmin.

hora de incluir clientes em nossa tabela para conseguirmos realizar algumas

atividades. Utilizaremos as seguintes instrues insert para incluir cinco
registros:
INSERT INTO Cliente (codigo, nome, endereco) VALUES (123,
WILSON OLIVEIRA, CAIXA POSTAL: 155 ITU);
148

149

Informtica 3

captulo 3

Figura 73

INSERT INTO Cliente (codigo, nome, endereco) VALUES (145, ANDREA SIRTORI OLIVEIRA, CAIXA POSTAL: 135 ITU);

Instruo a partir
do phpMyAdmin.

INSERT INTO Cliente (codigo, nome, endereco) VALUES (567, LUCAS OLIVEIRA, CAIXA POSTAL: 111 ITU);
INSERT INTO Cliente (codigo, nome, endereco) VALUES (345,
JOSE FRANCISCO, CAIXA POSTAL: 45 ITU);
INSERT INTO Cliente (codigo, nome, endereco) VALUES (777,
AMANDA SIRTORI, CAIXA POSTAL: 233 ITU);
Veja na figura 71, como ser a instruo utilizando o phpMyAdmin.
Figura 71

Observe na figura 73 como ser a instruo a partir do phpMyAdmin.

O sucesso da instruo pode ser conferido na figura 74.
Figura 74

Instruo usando
phpMyAdmin.

Resultado da
instruo.

Podemos observar na figura 72 o sucesso da instruo.

Vamos agora fazer algumas manipulaes de dados com os registros feitos na
tabela de clientes. Listaremos todos esses registros, aplicando, para isto, a seguinte instruo:

Figura 72
Sucesso da
instruo.

150

Vamos agora listar os clientes com cdigo menor que 200. A instruo para isto
a demonstrada a seguir:

Select * from cliente where codigo < 200

Select * from Cliente.

Na figura 75, podemos observar como ser a instruo empregando-se o
phpMyAdmin.
Figura 75
Listagem de clientes
com cdigo menor
que 200.

151

Informtica 3

captulo 3

Figura 76

Figura 78

Instruo
bem sucedida.

Outra instruo
bem sucedida.

A figura 76 demonstra o sucesso da instruo.

Vamos alterar o cliente de cdigo 123, de nome Wilson Oliveira, para o
nome completo dele, que Wilson Jose de Oliveira. Para isso, utilizaremos
a instruo a seguir:

Na figura 79, mostramos como ser a instruo, outra vez utilizando o

phpMyAdmin.
Figura 79
A instruo
para listar
cliente de
cdigo 123.

UPDATE Cliente
Set nome = Wilson Jose de Oliveira
Where codigo= 123

Na figura 77, indicamos como ser a instruo, novamente aplicando-se o

phpMyAdmin.
Podemos constatar o sucesso da instruo na figura 78.
Vamos listar o cliente de cdigo 123 para verificar se o UPDATE foi bemsucedido. Para isso devemos utilizar esta instruo:

Select * from cliente where codigo = 123

Podemos observar na figura 80 que a alterao do cliente foi feita.

Figura 80

Figura 77
Instruo para o
nome completo.

152

Realizada
a alterao
do cliente.

153

Informtica 3

captulo 3

Figura 83

Figura 81

Listagem dos
clientes
para comprovar
excluso.

O comando
DELETE para
o cliente de
cdigo 123.

Figura 84
O cliente de cdigo
123 foi eliminado.

Agora vamos eliminar o cliente de cdigo 123, utilizando a instruo delete,

com a sintaxe apresentada a seguir:

DELETE FROM Cliente Where codigo = 123

Na figura 81, mostramos como ser a instruo, usando o phpMyAdmin.

Podemos observar que a excluso do cliente foi realizada na figura 82.
Vamos listar todos os clientes para podermos comprovar que a nossa excluso
do cliente foi bem-sucedida. Para isso, devemos utilizar a instruo Select,
com a seguinte sintaxe:

Select * from cliente

Na figura 83, mostramos como ser a instruo, aplicando o phpMyAdmin.

Podemos observar agora que o cliente de cdigo 123 j no aparece na lista,
como mostra a figura 84.
Figura 82
Efetuada a
eliminao.

154

Para aprender mais

A linguagem SQL uma poderosa ferramenta de manipulao de dados. At agora, aprendemos bastante sobre ela,
mas h muito mais que voc precisa saber. Para ter um conhecimento mais amplo, pesquise a linguagem mais detalhadamente e analise, por exemplo, instrues especficas
para cada banco de dados disponvel no mercado, como, por
exemplo, SQL Server, Oracle, MySQL e Cache.

155

Captulo 4

Linguagem unificada
de modelagem (UML)
Orientao a objetos
As vrias opes da UML
O diagrama da UML
Exemplo de desenvolvimento
de projetos utilizando UML

Consideraes finais
Referncias bibliogrficas

informtica 3

captulo 4

Mtodo de Booch, desenvolvido por Grady Booch, da Rational Software Corporation, expressivo principalmente nas fases de projeto e construo de sistemas;
OOSE (Object-Oriented Software Engineering), de Ivar Jacobson, que fornecia excelente suporte para casos de usos como forma de controlar a captura de requisitos, a anlise e o projeto de alto nvel;
OMT (Object Modeling Technique), de James Rumbaught, que era mais
til para anlise e sistemas de informaes com o uso intensivo de dados.

osso objetivo nesse captulo apresentar a UML (Linguagem

Unificada de Modelagem), que possibilita visualizao, especificao, construo e documentao de artefatos de um sistema
complexo de software - o software orientado a objetos. Ou seja, vamos estudar
a linguagem de definio desses softwares. Comearemos por um rpido histrico, mas s entraremos propriamente no estudo da UML aps vermos os
principais conceitos do paradigma orientado a objetos. Alm dos conceitos mais
relevantes do modelo, mostraremos, sempre que for possvel, sua representao
na UML, para que voc v se acostumando linguagem.
Quando vrios autores propunham metodologias para o desenvolvimento de software
orientado a objetos, trs estudiosos se juntaram e criaram uma linguagem unificada de
modelagem, a UML. Estamos falando dos norte-americanos Grady Booch, e James
Rumbaugh e do suo Ivar Jacobson, que, em 1995, lanaram a UML 0.8 , unificando
os respectivos mtodos, os quais, na verdade, estavam confluindo naturalmente:

Mas podemos dizer que essa histria comeou bem antes, nos anos 1960, com
Alan Curtis Kay, na Universidade de Utah, Estados Unidos. Considerado um
dos pais da orientao a objetos com sua analogia algbrico-biolgica, Kay
postulou que o computador ideal deveria funcionar como um organismo vivo,
isto , cada clula, mesmo autnoma, deveria se relacionar com outras a fim de
alcanar um objetivo. As clulas poderiam tambm se reagrupar para resolver
outros problemas ou desempenhar outras funes. Kay, que era pesquisador da
Xerox quando surgiu a linguagem Smalltalk, no centro de pesquisas da empresa, em 1970, foi o primeiro a usar o termo orientao a objetos.
Por oferecer ferramentas que podem ser utilizadas em todas as fases do desenvolvimento de software, a UML acabou se tornando padro de desenvolvimento de
software orientado a objetos.

4.1. Orientao a objetos

A orientao a objetos um projeto antigo na rea de informtica e traz consigo
a idia de aproximar o desenvolvimento de software do mundo real, criando
elementos que tenham dados e funcionalidades em si mesmos. Mas sua implementao plena ainda est por vir, pois ainda hoje so vrias as dificuldades no

Origem e evoluo da UML

1962-1963

Krysten
Nygaard

AP Photo/Imageplus

1963 - Ivan Sutherland desenvolve,

no MIT (Massachusets Institute
of Tecnology), nos Estados Unidos, o Sketchpad,
primeiro editor grfico para desenhos orientado
a objetos. O Sketchpad usava conceitos de
instncia e herana.

Divulgao

Divulgao

1962 - Krysten Nygaard e Ole-Johan Dahl,

pesquisadores do Centro de Computao
da Noruega, em Oslo, criam a linguagem
Simula, derivada do Algol, introduzindo
os primeiros conceitos de orientao a objetos.

Ivan
Sutherland
158

1969

1970-1983
Alan Curtis Kay apresenta sua tese
de doutorado intitulada The
Reative Engine na Universidade
de Utah, na qual prope
uma linguagem (Flex),
que contm conceitos
de orientao
a objetos.

Alan
Curtis Kay

lanada a linguagem de programao

Smalltalk, desenvolvida no centro de pesquisas
da Xerox, em Palo Alto, Estados Unidos.
Essa foi por muito tempo a nica linguagem
100% orientada a objetos.
1980 - Surge a linguagem de programao
C++, que tambm pode ser
orientada a objetos.
1983 - Jean Ichbiah cria a linguagem
ADA a pedido do Departamento
de Defesa dos Estados Unidos,
tambm orientada a objetos.

159

informtica 3

captulo 4

caminho H limitaes de hardware, que se relacionam a problemas de acesso e

armazenamento de dados, e de software, relativas a processos do sistema operacional e a falta de sistemas gerenciadores de banco de dados orientados a objetos.

4.1.1. Abstrao
caracterstica essencial de uma entidade, que a diferencia de todos os outros
tipos de entidades. Uma abstrao define uma fronteira relativa perspectiva do
observador, segundo Booch, Rumbaugh e Jacobson (2005).
Como j dissemos anteriormente, abstrao a capacidade de fixar a ateno
apenas nos detalhes relevantes para a construo da soluo dentro de seu escopo. Isto , quando penso em um cliente, por exemplo, no preciso pensar em
todos os atributos de um cliente, mas apenas nos atributos que interessam para
a soluo do problema em questo. Como tambm vimos no captulo 2, um
cliente pode ser apenas um nmero.

4.1.2. Classe

Figura 85
Nome da classe

Carro
- nomeFabricante : String
- nomeModelo : String
- cor : String
- numeroPortas : int
- anoFabricao : int
- velocidadeMaxima : double

Definio da classe
segundo UML 2.

Atributos

+ abrirPortas() : void
+ fecharPortas() : void
+ ligar() : void
+ desligar() : void
+ acelerar() : void
+ frear() : void
+ trocarMarcha() : void

Mtodos

Responsabilidades

Responsabilidades

- Se locomover na
velocidade e direo
indicados pelo usurio.
- Acelerar quando
solicitado.
- Frear quando solicitado.

4.1.2.1. Mtodo

Nome da classe Cada classe deve ter um nome que a diferencie das outras
classes (Booch, Rumbaugh e Jacobson, 2005).
Atributo uma propriedade nomeada de uma classe, que descreve um intervalo de valores que as instncias da propriedade podem apresentar (Booch,
Rumbaugh e Jacobson, 2005).

a implementao de um servio que pode ser solicitado por um objeto da classe

para modificar o seu comportamento, algo que pode ser feito com um objeto e
que compartilhado por todos os objetos dessa classe (Booch, Rumbaugh
e Jacobson, 2005). Existem alguns mtodos especiais em praticamente todas
as classes, os quais, geralmente, no representamos nos diagramas da UML por
Divulgao

De acordo com Booch, Rumbaugh e Jacobson (2005), classe uma descrio de

um conjunto de objetos que compartilham os mesmos atributos, operaes, relacionamentos e semntica. A representao completa de uma classe tem quatro
divises, conforme conceituamos e mostramos na figura 85.

1989 - criado o OMG (Object

Management Group), que aprova
padres para aplicaes orientadas
a objeto.

1990-1993
Peter Coad e Ed Yourdon lanam
o livro Object-Oriented Analysis,
tambm contendo tcnicas para anlise
e projetos orientados a objeto.
Rebecca Wirfs-Brock, Brian Wilkerson
e Lauren Wiener publicam o livro Designing
Object-Oriented Software, tratando de tcnicas
de modelagem orientada a objetos.
1992 - Ivar Jacobson, Magnus Christerson,
Patrik Jonsson e Gunnar Overgaard
lanam o livro Object-Oriented
Software Engineering: A Use Case Driven

1994-1995
Approach, tambm sobre tcnicas
de orientao a objetos.
D. Embley, B. Kurtz, e S. Woodfield
publicam o livro Object-Oriented
System Analysis. A
Model-Driven Approach.
1993 - Grady Booch
lana seu Booch Method
com tcnicas para
anlise e projeto
orientado a objetos.

James Martin e Jim Odell lanam OOIE

(Object-Oriented Information Engineering).
1995 - Grupo de desenvolvedores da Sun
Microsystems, da Califrnia, Estados Unidos,
chefiado por James Gosling, cria a linguagem
Java. James Rumbaugh publica sua OMT
(Object Modeling Technique).
Os metodologistas Grady Booch, James
Rumbaugh e Ivar Jacobson lanam a UML
0.8 (em 1996, surgir a UML 0.9; em 1997,
a UML 1.0; em 2000, a UML 1.4; e em 2005,
a UML 2.0).

James
Martin
A Prabhakar Rao/The India
Today Group/Getty Images

Divulgao

1988 - Sally Shlaer e Stepen Mellor

publicam o livro Object-Oriented
Systems Analysis: Modeling the World
in Data, que prope uma tcnica
para anlise e projetos orientados
a objeto.

Bertrand
Meyer

160

Bertrand Meyer lana a linguagem

Eifel, orientada a objetos.

Divulgao

1985-1989

James Gosling

161

informtica 3

captulo 4

Figura 86

j terem se tornado senso comum entre os desenvolvedores. Mas, sempre que

voc achar necessrio, poder defini-los dentro da classe.
Voc deve estudar mais
sobre o funcionamento
e a utilizao de
construtores, getters
e setters no livro
Programao de
Computadores, desta
coleo, e nos sites que
abordem a linguagem
Java e linguagem
C#, alm de sua
representao UML.

Os mtodos especiais
Construtor: o mtodo que constri, isto , reserva o espao em memria
onde sero armazenadas as informaes daquele objeto da classe.
Get: o mtodo que apresenta o valor armazenado em determinado atributo de um objeto.
Set: d um valor a um atributo.
Os mtodos get e set so muito teis para preservar os atributos e garantir que sua
alterao seja feita unicamente por intermdio deles. Chamamos isso de encapsulamento dos atributos de uma classe, pois podemos deixar todos eles com visibilidade
privada e s manipul-los utilizando os mtodos get (para retornar o valor que est
no atributo) e set (para atribuir um valor a ele). Geralmente adotamos um mtodo
set e um mtodo get para cada atributo da classe.
Destrutor: destri o objeto criado da memria, liberando o espao de memria alocado na sua criao. No necessrio cri-lo em linguagens orientadas
a objetos que possuam garbage collector, isto , que excluam os objetos que
j no tenham referncia alguma na memria.

O garbage collector
procura o lixo existente
na memria, ou
seja, os objetos que
no so utilizados
e, no entanto,
ocupam espao na
memria. Essa tarefa
pode ser executada
automaticamente
ou programada.

A ssinatura: a primeira linha da definio de um mtodo, no qual podemos

observar sua visibilidade, seu nome, seus parmetros de entrada e de retorno.

Exemplo: + soma(valor1:double,valor2:double):double

A assinatura do mtodo mostrado no exemplo acima indica que:

o smbolo + no incio da assinatura demonstra que se trata de um mtodo pblico, ou seja, que todos os objetos que tiverem acesso classe a que pertencem
tambm podero acess-lo;
o nome do mtodo soma;

Por meio da assinatura do

mtodo podemos obter
vrias informaes sobre
sua utilizao e, em alguns
casos, seu funcionamento.
Portanto, para facilitar
a compreenso sobre
o que o mtodo faz e
como devemos utilizlo, precisamos ter muito
cuidado na definio
dessas assinaturas.

162

o mtodo soma recebe como parmetros de entrada dois valores do tipo

double, chamados valor1 e valor2, e devolve como resultado um nmero
do tipo double.

Outra forma de
representar uma
classe em UML 2.0.

Carro
- nomeFabricante : String
- nomeModelo : String
- cor : String
- numeroPortas : int
- anoFabricao : int
- velocidadeMaxima : double

Carro

+ abrirPortas() : void
+ fecharPortas() : void
+ ligar() : void
+ desligar() : void
+ acelerar() : void
+ frear() : void
+ trocarMarcha() : void

4.1.2.3. Tipos de relacionamento entre classes

Existem basicamente trs tipos de relacionamento entre classes: dependncia,
associao e herana.
1. Dependncia: um relacionamento de utilizao, determinando que um objeto de uma classe use informaes e servios de um objeto de outra classe, mas
no necessariamente o inverso. A dependncia representada graficamente por
uma linha tracejada com uma seta indicando o sentido da dependncia. Como
voc pode observar na figura 87, a classe Janela dependente da classe Evento.
2. Associao: um relacionamento estrutural que especifica objetos de uma
classe conectados a objetos de outra classe. A partir de uma associao, conectando duas classes, voc capaz de navegar do objeto de uma classe at o objeto de
outra classe e vice-versa (Booch, Rumbaugh e Jacobson, 2005). Representada por uma linha interligando as duas classes, uma associao pode definir
papis das classes relacionadas, assim como a multiplicidade de sua associao,
alm de ter um nome. Mas nenhum desses componentes obrigatrio em uma
associao e s devem ser usados para deixar mais clara a sua definio.
Figura 87

4.1.2.2. Responsabilidades
So contratos ou obrigaes de determinada classe. Ao criarmos uma classe,
estamos criando uma declarao de que todos os seus objetos tm o mesmo
tipo de estado e o mesmo tipo de comportamento (Booch, Rumbaugh
e Jacobson, 2005). Dependendo do nvel de detalhe (abstrao) que estamos analisando no diagrama, podemos tambm representar graficamente
uma classe apenas com seu nome ou com nome dos principais atributos e
principais mtodos, conforme o que queremos analisar no momento em que
estamos criando o diagrama. No precisamos, ento, escrever todos os componentes da classe (figura 86).

Janela
- largura : double
- altura : double
+ abri() : void
+ fechar() : void
+ tratarEvento() : void

Evento

Representao de
uma dependncia
em UML 2.0.

- nome : String
+ start() : void

163

informtica 3

captulo 4

Figura 89

Figura 88
Exemplo de
associao entre
classes UML.

Funcionario
- salario : double
- nroCarteiraProfissional : String

Empresa

Trabalha para4

Empresa

trabalhador empregador

1..*

- nome : String
- ramoAtividade : String
- cnpj : String

- nome : String
- ramoAtividade : String
- cnpj : String

J a agregao um tipo de associao entre classes na qual mostrada a relao

todo/parte, nela uma classe far o papel do todo e a outra, da parte. A agregao
entre duas classes representada em UML 2.0 como uma linha ligando duas
classes com um losango na ponta da classe toda para diferenciar o todo da parte.
Veja o exemplo na figura 89.
Observamos nesse diagrama da figura 89, que uma empresa formada por um
conjunto de departamentos, ou seja, tem a multiplicidade (leia o quadro abaixo).
Vemos ainda que um departamento est associado a uma empresa.
A composio, por sua vez, uma forma de agregao com propriedade bem
definida e tempo de vida coincidente das partes pelo todo. As partes com multiplicidade no associada podero ser criadas aps a prpria composio, mas,
uma vez criadas, vivem e morrem com ela. Estas partes s podem ser removidas
explicitamente antes da morte do elemento composto (Booch, Rumbaugh e Jacobson, 2005). Podemos dizer que numa relao de composio s
faz sentido existir a parte se houver o todo. Observe o diagrama da figura 90.

Em relao multiplicidade podemos ter:

0..* multiplicidade de zero a muitos.
1..* multiplicidade de 1 a muitos.
0..1 multiplicidade de 0 a 1.
* multiplicidade de zero a muitos; possui o mesmo significado
de 0..*.
N multiplicidade N, onde N deve ser trocado por um nmero
que representar o nmero exato de objetos relacionados
quela classe.

164

- numero : int
- data : Date
- valorTotal : double

Figura 90

1
No diagrama da figura 88, identificamos uma associao, representada em
UML 2.0 por uma linha interligando as duas classes, de nome Trabalha para,
onde a classe Funcionario representa o papel de trabalhador e a classe Empresa
representa o papel de empregador. Podemos observar pela representao da multiplicidade que cada objeto da classe Empresa tem, como trabalhador, 1 ou mais
objetos da classe Funcionrio e que um objeto da classe Funcionario tem, como
empregador, no mnimo 0 e no mximo vrios objetos empresa.

Pedido

Representao de
uma composio
UML 2.0.

esquerda
representao da
agregao entre
classes UML 2.0.

ItemdePedido

Departamento
- nome : String

- descrio : String
- quantidade : int
- precoUnitario : double

Podemos analisar que s faz sentido existirem os itens de pedido (parte) se existir o pedido (todo).
3. Herana: refere-se ao mecanismo pelo qual classes mais especficas incorporam a estrutura e o comportamento de classes mais gerais (Booch, Rumbaugh e Jacobson, 2005).
Podemos verificar, na figura 91, que a classe Pessoa possui os atributos nome
e cpf e pode executar os mtodos de andar e falar. J a classe Funcionario, por
herdar os atributos e mtodos da classe Pessoa, possui nome, cpf, salrio e nro
Carteira Profissional, podendo executar os mtodos andar, falar e trabalhar. Dizemos que a classe Pessoa a superclasse da classe Funcionario, que sua subclasse, ou
que Pessoa a classe pai de Funcionario e que Funcionario classe filha de Pessoa.
Figura 91
Pessoa

Especializao

# nome : String
# cpf : String

Representao
de herana
utilizando UML.

+ andar() : void
+ falar() : void

Funcionario
- salario : double
- nroCarteiraProfissional : String
+ trabalhar() : void

Generalizao

165

informtica 3

captulo 4

Figura 92

4.1.3.2. Mensagem

Classe e
objeto.
O molde
que dar
origem ao
produto.

Segundo Booch, Rumbaugh e Jacobson (2005), mensagens so a especificao

de uma comunicao entre objetos que contm informaes espera da atividade
que acontecer, isto , as informaes trocadas entre os objetos para que executem
as funes necessrias para o funcionamento do sistema. Para seguir adiante, precisamos compreender tambm certas caractersticas das classes. Vejamos:
l

 ncapsulamento: Propriedade de uma classe de restringir o acesso a seus

E
atributos e mtodos. A possibilidade de definir reas pblicas e privadas
em sua implementao garante mais segurana ao cdigo criado, j que
podemos definir os parmetros de entrada e sada de um mtodo sem revelar como ele implementado.
Visibilidade: Existem quatro tipos de visibilidade de atributos ou mtodos:

Equipe Eesc-USP Frmula Sae

Private (privada): representada por um sinal de menos (), a visibilidade

mais restrita e permite o acesso ao atributo ou mtodo apenas dentro da prpria classe.

4.1.3. Objeto
uma manifestao concreta de uma abstrao; uma entidade com uma fronteira bem definida e uma identidade que encapsula estado e comportamento;
instncia de uma classe (Booch, Rumbaugh e Jacobson, 2005). Podemos imaginar uma classe como sendo o molde e os objetos, os produtos criados
a partir desse molde.
Um bom exemplo pensar nos atributos do carro como sendo: modelo, nmero
de portas, cor, ano de fabricao, tipo de combustvel, velocidade mxima. J
os mtodos do carro podemos definir como: andar, parar, acelerar, entre outros.
Pensando em responsabilidades, podemos dizer que o carro tem a responsabilidade de obedecer aos comandos de seu piloto, conduzindo-o na velocidade e
pelo caminho que ele escolheu, acelerando e freando de acordo com o que foi
sinalizado (figura 92).

4.1.3.1. Interao entre objetos

Agora que ns j definimos e diferenciamos classes e objetos, precisamos saber
como os objetos interagem entre si. De acordo com o paradigma de orientao
a objetos, isso ocorre por meio de trocas de mensagens. Para entendermos como
essas trocas funcionam, estudemos mais alguns conceitos.
166

Protected (protegida): representada por um sustenido (#), permite o acesso

aos mtodos e atributos dentro da prpria classe ou de suas subclasses.
Public (pblica): representada por um sinal de mais (+), permite o acesso
aos mtodos e atributos a todas as classes que tiverem algum tipo de relao
com a classe em que foram criados. a menos restritiva das visibilidades.
Package (pacote): representada por um til (~) permite o acesso aos mtodos
e atributos a todas as classes includas no mesmo pacote.

Mtodos pblicos e privados

Se analisarmos a classe Pessoa, na figura 93, veremos que seus atributos so
privados, mas como faremos para acess-los? Utilizando os mtodos get e set de
cada atributo. uma forma de garantir que os atributos somente sero alterados
pelos mtodos get e set, o que permite maior controle sobre seu uso.
Figura 93
Pessoa
- nome : String
- cpf : String

Exemplo de
visibilidade de
atributos e
mtodos. UML 2.0.

+ andar() : void
+ falar() : void
- mexerPerna() : void
- articularPalavra() : void

167

informtica 3

captulo 4

Figura 94
Exemplo de
polimorfismo
de mtodo dito
sobrecarga.

- Sobrecarga: na mesma classe podemos ter mtodos com o mesmo nome, mas
que recebem parmetros diferentes (assinaturas diferentes) e tm, por isso mesmo, funcionalidades e/ou implementaes diferentes, como mostra a figura 94.

Pessoa
- numero1 : double
- numero2 : double
- resultado : double
+ soma() : void
+ soma(valor1 : int, valor2 : int) : int
+ soma(valor1 : double, valor2 : double) : double

Figura 95
Exemplo de
polimorfismo
sobrescrita.

Veja tambm que os mtodos andar e falar so pblicos, isto , qualquer objeto que tiver acesso classe poder utiliz-los. J os mtodos mexerPerna e
articularPalavra so privados, isto , s podem ser utilizados dentro da classe
Pessoa. Mas qual a vantagem desse tipo de implementao? Claro que para
andar, uma pessoa tem que mexer a perna. O segredo do andar est no modo
como ela mexe a perna. O que fizemos, ento, foi garantir que o segredo, que
tambm chamamos de regra de negcio, no faz parte da interface pblica da
classe, isto , da forma com que as outras classes vo utiliz-la. Com o mtodo
encapsulado na classe, seu cdigo est mais protegido de eventual cpia ou
reproduo de como foi implementado, pois uma classe externa nem sabe de
sua existncia. Logo, da forma como projetamos sua implementao nenhuma
outra classe saber que para andar necessrio mexer a perna e muito menos
como isso feito. Essa a vantagem do encapsulamento no desenvolvimento
de software orientado a objetos. O mesmo princpio foi usado ao encapsular o
mtodo articularPalavra.
l Poliformismo: Palavra de origem grega que significa vrias formas. No paradigma de orientao a objetos polimorfismo aparece em trs formas diferentes:

# nroLados : int

- raio : double
+ calculaArea() : double
+ calculaPerimetro() : double

- lado1 : double
- lado2 : double
- lado3 : double
+ calculaArea() : double
+ calculaPerimetro() : double

Vemos, no exemplo da figura 95, que h uma superclasse chamada Poligono,

que implementa os clculos de rea e permetro para os polgonos que no sejam crculo, tringulo e retngulo, para os quais foram criadas classes filhas,
de acordo com suas frmulas. Esse um exemplo de sobrescrita dos mtodos
calculaArea() e calculaPerimetro(), que, dependendo da classe a que pertence, o
objeto instanciado usar o mtodo implementado por essa classe.
- Polimorfismo de classe: Uma subclasse pode, dentro da aplicao, fazer o
papel da superclasse (classe pai) e da subclasse (classe filha). Sempre que uma
subclasse referenciada como a superclasse, tambm temos polimorfismo.

Anlise e projeto de software orientado a objetos

Para desenvolver softwares orientados a objetos, seguimos as mesmas fases

(anlise, projeto, programao, testes, implantao e manuteno) e tambm
podemos usar as tcnicas de prototipagem. Mas necessrio definir os objetivos de cada fase, principalmente a de anlise e projeto orientados a objeto, que
tm caractersticas um pouco diferentes das vistas at agora.

+ calculaArea() : double
+ calculaPerimetro() : double

Triangulo

- Sobrescrita: em classes associadas por uma hierarquia pode haver mtodos

com a mesma assinatura, mas que efetuam operaes diferentes. Assim, se
optar pela execuo de um ou de outro, dependendo da classe que estiver
instanciada no momento da execuo (figura 95).

Como j vimos no captulo 1, o desenvolvimento de software foi dividido em

fases para facilitar o processo, o que permite reduzir as questes a serem respondidas em cada etapa, e o melhor acompanhamento do projeto.

Poligono

Circulo

Neste exemplo da figura 94, vemos que a classe Calculadora implementa trs
mtodos soma diferentes: o primeiro efetua a soma com os valores dos atributos
numero1 e numero2, colocando o resultado no atributo resultado. J o segundo
mtodo soma recebe como parmetros os nmeros inteiros valor1 e valor2 e
devolve como resultado a soma dos dois. O terceiro mtodo recebe dois valores
de tipo double valor1 e valor2 e retorna como resultado a sua soma. O interpretador de comandos escolher, em tempo de execuo, com base nos tipos e
no nmero de parmetros informados, qual dos mtodos soma ser executado.

Retangulo
- lado1 : double
- lado2 : double
+ calculaArea() : double
+ calculaPerimetro() : double

Anlise orientada a objetos

Nessa fase, fazemos levantamento e anlise de requisitos, conforme as tcnicas
que aprendemos no captulo 1, e definimos o que precisamos criar para satisfazer os requisitos. Resumindo: precisamos identificar quais classes devero ser
implementadas e quais sero seus principais atributos e mtodos para que os
requisitos sejam satisfeitos.
Utilizamos para isso, basicamente, os diagramas de casos de uso e o diagrama

168

169

informtica 3

captulo 4

de classes, que em alguns livros so chamados de diagramas de classes de anlise

porque as definies das classes so ainda incompletas. Isso porque nessa fase queremos apenas definir as classes e seus principais atributos e mtodos e no definir
em detalhes sua implementao. Em alguns casos utiliza-se tambm o diagrama
de objetos para se poder analisar como ficariam as estruturas das classes em determinado ponto do processamento do sistema.
Todos esses diagramas sero vistos ainda nesse captulo, mas daremos por
hora uma viso de como se desenvolvem softwares orientados a objetos.
Como podemos imaginar, o produto final dessa fase so as principais classes a serem desenvolvidas para que nosso software resolva todos os requisitos definidos.

Projeto orientado a objetos

Agora que sabemos quais so as principais classes que comporo nossa soluo de
software para resolver o problema proposto, precisamos definir como os objetos
criados dessas classes interagiro entre si para gerar o resultado final esperado.
Nessa fase devemos projetar todo o funcionamento do software, em detalhes.
Para isso podemos utilizar os demais diagramas da UML, o que nos ajudar a
definir, tambm em detalhes, como funcionar cada um dos itens da soluo,
at, por exemplo, em que estrutura de hardware e software ser implementada e como estaro dispostos seus diversos componentes nos computadores da
rede. Geralmente, nessa fase so criadas novas classes responsveis pela interao
do usurio com o sistema, assim como com outras classes/sistemas definidos e
em funcionamento. Definimos tambm os procedimentos de interao entre
usurio e sistema, alm dos requisitos de segurana de acesso s informaes
utilizadas pelo sistema. A UML nos oferece ferramentas que permitem analisar
em detalhes cada um dos componentes de nossa soluo de software nos mais
diversos aspectos de sua construo e funcionamento.

Ao utilizar a UML,
precisamos de bom
senso, para oferecer
solues adequadas
e no prazo esperado
pelo usurio, criando
modelos apenas para as
partes que realmente
demandam definio
mais aprofundada.

Em resumo, na fase de anlise orientada a objetos devemos nos preocupar com

o que o sistema deve fazer para responder a todos os requisitos, definindo suas
principais classes e funcionalidades. Na fase de projeto temos de pensar em
como as classes devero se comportar para que o sistema funcione de forma a
cumprir todos os seus requisitos, com o tempo de resposta definido e na estrutura de software e hardware proposta.

Esttico aquilo que no muda dentro do software, isto , a estrutura, a definio das classes, a modularizao, as camadas e a configurao do hardware. J a
parte dinmica diz respeito s mudanas de estado que os itens podem sofrer no
decorrer da execuo do software, por exemplo, pelas alteraes ocasionadas pelas
trocas de mensagens entre os itens nesse momento. Utilizamos a UML para criar
modelos em que os diversos aspectos relevantes ao estudo e definio da soluo
de software podem ser observados, para que o programa tenha qualidade e implemente as funcionalidades necessrias, com a performace esperada pelo usurio.
J discutimos em outros captulos as vantagens de se criar modelos no desenvolvimento de software, e a UML nos permite cri-los para todas as fases desse
processo, oferecendo ao desenvolvedor subsdios para chegar a uma soluo de
qualidade, com uma boa viso de cada etapa.
Os autores apontam cinco diferentes vises proporcionadas pela UML durante
a construo de modelos de software. So elas:
Viso de casos de uso: permite melhor compreenso do problema a ser resolvido, ajudando na definio das fronteiras do sistema, seus principais usurios e
as principais funcionalidades a serem implementadas.
Viso de projeto: auxilia na anlise da estrutura e das funcionalidades esperadas
da soluo.
Viso de processo: tambm chamada de viso de interao, foca o fluxo de controle entre os diversos componentes da soluo, permitindo tambm a anlise
de seu desempenho, a sincronizao e a concorrncia entre seus componentes,
necessria para o perfeito funcionamento da soluo.
Viso de implementao: ajuda a definir a estrutura da soluo, isto , os arquivos de instalao, seu controle de verses.
Viso de implantao: trata da estrutura de hardware e software, ou seja, do
ambiente em que a soluo ser implementada (figura 96).
Figura 96
Vises de um projeto
utilizando UML.

4.2. As vrias opes da UML

Como afirmaram seus prprios criadores, a linguagem UML oferece opes
para anlise e definio em todas as fases do desenvolvimento de software
da concepo arquitetura de hardware e software em que a soluo ser implementada, passando pelo detalhamento das funcionalidades, tanto estticas
quanto dinmicas, e fornecendo apoio definio da melhor soluo para o
software orientado a objetos a ser criado.
Deve ficar claro para ns o que esttico e o que dinmico, na viso da UML.

170

171

informtica 3

captulo 4

Figura 98

4.2.1. Conceitos da estrutura da UML

Basicamente, a UML formada por trs componentes: blocos de construo, regras que restringem como os blocos de construo podem ser associados entre si e mecanismos de uso geral, que do mais clareza s definies
criadas pelos blocos de construo. Estes, por sua vez, so de trs tipos:
itens, relacionamentos e diagramas.

Itens
Os itens so a base da UML, as abstraes. J os relacionamentos so as
relaes entre os itens, enquanto os diagramas agrupam itens e relaes, permitindo a anlise de um dos aspectos da soluo a ser criada. Tambm h
diferentes tipos de itens, que so divididos em quatro grupos: estruturais,
comportamentais, de agrupamento e anotacionais. Vamos estudar, a seguir,
cada um dos grupos.

Itens estruturais
Itens estruturais nos permitem definir a estrutura da soluo. So formados
pelas classes, as interfaces, as colaboraes, os casos de uso, os componentes, os
artefatos e os ns. Para comear, vamos a uma breve definio de cada um desses
elementos, que mais adiante sero aprofundados, para mostrar como funcionam
e explicar, por meio de um diagrama, onde so utilizados. Empregaremos tambm as definies j descritas no tpico sobre orientao a objetos desse livro,
que deve ser consultado, caso haja necessidade de uma reviso. Apresentaremos
tambm a notao grfica da UML de cada componente definido.
Classes: so os elementos bsicos da orientao a objetos e, consequentemente,
da UML. (A classe j foi definida no tpico que trata dos conceitos de orientao a objetos, no qual voc encontra inclusive sua notao na UML.)
Interfaces: so as funcionalidades a serem implementadas por uma classe ou
por um componente. Demonstram o comportamento visvel de uma classe, mas
nunca a implementao de tal comportamento, pois contm apenas a assinatura
dos mtodos, e sua implementao feita pelas classes que herdam seu comportamento. Servem para definir comportamentos padronizados para conjuntos de
classes e itens. As interfaces so representadas por um crculo, quando se trata
da interface de uma classe/item, ou por um arco, no caso da interface requerida

Classe implementando
uma interface de
entrada definida.

Conexo

iConexo

+ abrir() : void
+ testar() : void
+ fechar() : void

iEntrada

por uma classe/item. Ambas aparecem ligadas por uma linha classe que as
implementa (figura 97).
Existem, ento, duas formas de representar uma interface em UML. A primeira utiliza o recurso do esteretipo <<interface>> para enfatizar que se trata de
uma interface e mostra as assinaturas dos mtodos que so definidos por ela.
A segunda forma a representao da interface, que no informa detalhes das
funcionalidades que esta define.
Vemos, na figura 98, a representao de uma interface sendo implementada por
uma classe que tambm tem uma definio de sua interface de entrada.
Colaborao: so agrupamentos de classes, relacionamentos e interfaces que
constituem uma unidade do sistema (figura 99). Dizemos que essa unidade
maior que a soma das classes e relacionamentos implementados. So representados por uma elipse tracejada com o nome da colaborao ao centro. A
colaborao serve tambm para nos dar uma viso em nvel mais alto de abstrao, quando no necessrio entrar em todos os detalhes de determinado
item em anlise.
Casos de uso: descrevem uma sequncia de aes a serem executadas pelos
componentes da soluo. So ativados por um ator, servem de base para definir
os comportamentos dos elementos da soluo de software e so realizados por
uma colaborao. So representados por uma elipse com o nome da operao
que implementa no centro (figura 100).
Componentes: so estruturas que instituem uma funcionalidade de uma soluo de software por meio da implementao de uma ou mais interfaces definidas. Podem ser substitudos dentro de uma soluo por outro componente
que implemente todas as suas interfaces, sem prejuzo ao sistema como um
Figura 99

Figura 97
As duas formas
de representar
uma interface.

<< interface>>
iConexo
+ abrir() : void
+ testar() : void
+ fechar() : void

172

iConexo

Controle
de
Estoque

Solicitar
Preo

Exemplo
( esquerda)
de colaborao.

Figura 100
Exemplo de
caso de uso.

173

informtica 3

captulo 4

Figura 101

Figura 105

Exemplo de
componente.

Exemplo de mquina
de estados.

EmEspera
FormCliente

<<artefato>>
Cliente.class

Figura 102
Exemplo
de artefato.

todo. So representados por um retngulo com o smbolo da UML para componentes (figura 101).

Atividade: um comportamento que especifica a sequncia de etapas realizadas

por um processo computacional. representada em UML por um retngulo de
vrtices arredondados (figura 106).
Figura 106

Artefato: um elemento fsico do sistema, que pode ser um programa (fonte ou

executvel), um script do sistema operacional e tudo o mais que pode ser transformado em bits e bytes. representado por um retngulo com o esteretipo
<<artefato>> e o seu nome (figura 102).
N: representa um recurso de computao. Pode ser um servidor, um computador cliente, um switch, um hub etc. Qualquer elemento computacional
que faa parte da arquitetura na qual ser implementada a soluo pode ser
definido como um n. Em UML desenhado como um cubo com seu nome
dentro (figura 103).
Figura 103
Exemplo de n.
Servidor

imprimir
Nota Fiscal

Exemplo
de atividade.

Itens de agrupamento
Servem para agrupar os demais itens da UML, ordenando-os em blocos de modo
a possibilitar melhor organizao do projeto. composto apenas pelo item pacote.
Pacote: permite a incluso de itens em seu interior para organizar o projeto,
tornando-o modular e mais organizado. conceitual, no existindo em tempo
de execuo. representado por uma pasta, que pode receber apenas seu nome
ou a visualizao dos itens que a compem (figura 107).

Item anotacional
Itens comportamentais
So os itens que definem as partes dinmicas dos modelos UML. So tambm chamados de verbos do modelo. Constituem itens: interaes, mquina de estados e atividades.
Interaes: so os conjuntos de troca de mensagens entre objetos, tambm chamados de comportamento. Em UML as mensagens so representadas por uma
seta traada sob seu nome (figura 104).
Mquina de estados: especifica os diversos estados pelo qual pode passar um
objeto ou uma interao em seu ciclo de vida. Sua definio inclui outros componentes como estados, transies, eventos e atividades. Em UML representada por um retngulo com os vrtices arredondados (figura 105).
Figura 104
Exemplo de
mensagem.

174

o componente que permite a insero de comentrios nos modelos, tornandoos mais claros e inteligveis. composto apenas pelo item nota.
Nota: tem como objetivo inserir comentrios em um modelo para deix-lo mais
compeensvel. representado por um retngulo com a ponta superior direita
dobrada para dentro. Em seu interior so inseridos os comentrios pertinentes
ao que se quer explicar melhor dentro do modelo (figura 108). Tambm pode ser
utilizada uma linha tracejada para apontar exatamente a que ponto do modelo
se destina a explicao da nota.
Figura 107

Controle
solicita Senha

Esta classe faz a conexo

entre o software
aplicativo e o sistema
operacional

Exemplo
de pacote.

Figura 108
Exemplo
de nota.

175

informtica 3

captulo 4

4.2.2. Relacionamentos
Definidos os principais itens da UML, trataremos agora dos relacionamentos,
que so outros blocos de construo que permitem a ligao entre os itens da
UML definidos anteriormente. Existem trs tipos de relacionamento em orientao a objetos: dependncia, associao com seus tipos especiais (agregao
e composio) e generalizao (que permite a implementao do conceito de
herana e realizao). Todos foram apresentados quando falamos dos conceitos
bsicos de orientao a objetos. E reforaremos as explicaes sobre seu funcionamento quando os utilizarmos em diagramas, mais adiante.
Se voc tiver alguma dvida, volte a ler os tpicos relativos aos relacionamentos na parte de conceitos de orientao a objetos desse livro.
Assim, o prximo bloco de construo que iremos definir so os diagramas.

4.2.3. Diagramas
Existem 13 diagramas na UML 2.0, os quais so divididos em quatro grupos, de acordo com o tipo de anlise que os modelos gerados por sua utilizao possibilitam. So esses os grupos: diagramas estruturais, diagramas
comportamentais, diagramas de interao e diagramas de implementao
(figura 109).
Trataremos da construo e do uso dos diagramas implementados pela
UML mais frente, quando apresentaremos uma definio detalhada de
cada um, mostrando ainda seu uso e suas principais funcionalidades. Para
podermos combinar os blocos de construo da UML devemos observar as
cinco regras que essa linguagem prope, de forma que os modelos gerados
contenham uma definio clara e precisa para a criao de boas solues de
software. As regras nome, escopo, visibilidade, integridade, execuo
sugerem que, ao inserir um item em um diagrama, voc tem de se preocupar
com cinco caractersticas que devem ficar claras medida que cada um dos
itens inserido. As regras devem ser observadas para que possam ser criados
modelos que os autores da UML chamam de bem formados, isto , consistentes e harmnicos com todos os demais modelos que se relacionam com
ele. Entenda as cinco regras:
Nome: sempre devemos lembrar que o nome de um item deve deixar claras sua
formao, suas aes e responsabilidades. No devemos nos esquecer tambm de
que esse nome nico dentro de um modelo.
Escopo: todo item inserido em um modelo deve mostrar claramente quais so
seus limites, o que implementa e quando pode ser utilizado.
Visibilidade: indica que necessrio tambm que fique claro quando um item estar disponvel para ser utilizado e que aes estaro disponveis por seu intermdio.
Integridade: tambm importante levar em conta na criao de um item a definio clara de como este se relaciona e a consistncia de tal relacionamento.
176

Figura 109
Execuo: deve estar evidente ainda, o que o modelo representa e/ou simula. O
que queremos observar com a criao desse modelo.

Diagramas
definidos
pela UML 2.0.

4.2.4. Adornos
Alm dos trs blocos de construo, a UML oferece componentes, denominados adornos, que podem ser utilizados tanto para melhorar o entendimento dos
modelos criados quanto para estender o uso da UML em situaes onde no
existem componentes definidos. So eles:
Esteretipos: componentes de uso geral, servem para estender o significado de
determinado item em um diagrama. Por serem de propsito geral, podem ser
utilizados em qualquer item da UML onde for necessria uma definio mais
clara de seu papel no modelo. A UML j traz uma srie de esteretipos predefinidos como interface, ator, realizao, mas permite que o projetista defina
outros mais, sempre que surgir a necessidade. Sua representao pode ser apresentada de duas formas: uma palavra entre os smbolos de menor e maior ou um
desenho do prprio esteretipo que representa. Veja o exemplo da figura 110.
177

informtica 3

captulo 4

Figura 110
Exemplo de
esteretipo.
<< ator >>

Restries: so utilizadas para definir regras em modelos, de forma a melhorar sua

compreenso. As regras devem ser inseridas entre chaves ({}) e devem explicitar claramente a restrio. Por exemplo: {valor >=10}.
Podemos ainda criar novos compartimentos em itens da UML, tomando o cuidado
de documentar claramente o que significa o novo compartimento.

A importncia do profissional
A UML oferece diversos subsdios para a criao de modelos
claros que nos auxiliem na construo de solues de software
de qualidade. Permite tambm a criao de modelos que
simulam o comportamento do software em construo em
diversos aspectos. Mas nunca se esquea: sempre caber ao
desenvolvedor a responsabilidade de usar as informaes
de modo a obter solues de qualidade, de acordo com as
expectativas do usurio e capazes de produzir os melhores
resultados possveis.

4.3. Os diagramas da UML

Vamos agora a descrever os diagramas, seus principais componentes, a documentao envolvida. Tambm apresentaremos um exemplo, na medida do possvel, recorreremos ao estudo de caso da padaria do senhor Joo (apresentada no
captulo 2 deste livro), que, voc se lembra, usamos para mostrar como se cria
e implementa um software em uma empresa. Por isso, recomendamos que voc
volte ao tema para rever as definies do problema e, assim, acompanhar com
mais facilidade o prximo passo, a aplicao dos diagramas da UML.
Todos os diagramas da UML so teis para anlise de aspectos importantes do
desenvolvimento de software, mas no necessrio aplicar todos os diagramas
em um mesmo projeto. Escolha apenas os quais o ajudaro a entender melhor
o sistema que est desenvolvendo e a deixar mais claras as solues que ir
implementar. Nunca deixe que os diagramas fiquem grandes e complexos demais. Se perceber que isso est acontecendo, tente separ-los em mais de um,
dividindo suas funcionalidades.

H at mesmo softwares que ajudam a verificar o que podemos ou no fazer em

cada diagrama. H inmeras ferramentas que nos auxiliam nessa tarefa, muitas
com verses gratuitas. Procure a que mais se adapta s suas necessidades e mos
obra. Sugerimos que voc conhea o Jude (www.jude.change-vision.com), que
tem uma verso gratuita em ingls, fcil de utilizar e permite a construo de
quase todos os diagramas da UML. Escolha a que identificar como a mais adequada a seu projeto.

4.3.1 Diagrama de casos de uso

um diagrama que mostra um conjunto de casos de uso, atores e seus relacionamentos. Abrange a viso esttica de caso de uso de um sistema, conforme
descrio de Booch, Rumbaugh e Jacobson (2005), UML Guia do
usurio, livro de uma coleo bastante til para quem quer se aprofundar no
estudo de UML (veja quadro UML Guia do usurio: vale a pena consultar).
O diagrama de casos de uso geralmente o primeiro a que recorremos no incio
da anlise de um projeto que utilize UML. Ele criado aps o levantamento
dos requisitos da soluo imaginada cada caso de uso um de seus requisitos
funcionais.
O diagrama permite visualizar os limites do sistema, sua relao com os demais
sistemas, com seus componentes internos e as funes que deve realizar.
Voc pode criar diagramas de caso de uso para avaliar alguma situao no

Ao utilizar a UML,
precisamos de bom
senso, para oferecer
solues adequadas
e no prazo esperado
pelo usurio, criando
modelos apenas para as
partes que realmente
demandam definio
mais aprofundada.

UML Guia do usurio, vale

a pena consultar
O livro UML Guia do usurio integra um conjunto de obras
constitudo ainda pelos ttulos The Unified Modeling Language
Reference Manual Second Edition (2005) e The Unified Software
Development Process (1999). Escritos pelos autores da linguagem
Grady Booch, James Rumbaugh e Ivar Jacobson e editados pela
Addison-Wesley, esses trs livros trazem as definies e aplicaes
de cada um dos elementos que compem a UML.
Os dois primeiros, que j esto na segunda edio, lanada
em 2005, abordam teoria e prtica, com base na verso 2.0
da UML. J o terceiro descreve de forma completa o processo
de desenvolvimento de software utilizando a linguagem.
O livro UML Guia do usurio tem verso em portugus e, alm do
embasamento terico da UML e seu uso, descreve um processo de
desenvolvimento de software por meio da linguagem, exatamente
como propomos aqui. Adotamos os conceitos por acreditar que, entre
as mais de 50 teorias existentes sobre desenvolvimento de software,
as elaboradas pelos autores do livro so as mais interessantes.

Normalmente todos os diagramas so desenvolvidos com auxilio de um software.

178

179

informtica 3

captulo 4

Figura 112

muito clara identificada nas entrevistas ou para definir como ser a relao dos
diversos agentes de software no sistema, ou ainda para verificar que funcionalidades este dever implementar. O que faremos mapear os requisitos funcionais
do sistema, sua anlise e tambm as relaes que tais requisitos tero com os
demais componentes, internos ou externos ao sistema.
Todo diagrama de caso de uso deve ter um assunto, caso de uso, atores e
relacionamentos.

Validar retina

Validar senha

Relao de Generalizao
Especializao.

Validar digital

Principais componentes: ator, caso de uso, relacionamentos.

Como esses componentes j foram definidos, reforaremos apenas os conceitos
de relacionamento. Se voc tiver alguma dvida sobre os demais itens, releia as
definies formais j apresentadas e reveja os exemplos.
Um relacionamento representa os itens relacionados a um caso de uso e/ou um
ator. Figura tambm que tipo de relao h entre dois itens. Sempre que tivermos um relacionamento entre dois casos de uso, estes devem ser obrigatoriamente um include, um extend ou uma generalizao.
Vamos tratar agora dos relacionamentos include e extend.
O include um relacionamento de dependncia que, como o prprio nome
diz, de incluso, isto , indica que o caso de uso de onde parte o relacionamento sempre inclui/executa o comportamento do outro caso de uso, que
apontado pela seta.
O extend um relacionamento de dependncia que poder ter o comportamento da classe apontada extendido pela classe que aponta, como voc pode
observar na figura 111.
Figura 111
Exemplo da utilizao
de relacionamentos
include/extend.

Como podemos ver na figura 111, a implementao do caso de uso Validar login
implica necessariamente na execuo dos casos de uso Validar usurio digitado
e Validar senha.

incl
<<

>>
ude

Validar
usuario
digitado

Validar login

<< i
n
Usuario

clu

e
<<
de
>>

n
xte

>
d>

xte
<<e
Validar senha

nd >>

<<exten
d>>

Validar senha
digitada

Validar digital

Validar retina

Validar senha
digital

J o caso de uso validar senha pode implicar em um dos trs casos de uso.
Dependendo do tipo de ao efetuada pelo usurio, ser extendido o comportamento do caso de uso Validar senha digitada, validar digital ou validar retina.
Uma caracterstica interessante que a UML nos oferece ser extremamente flexvel, possibilitando que utilizemos os blocos de construo de forma diferente,
conforme a viso que queremos analisar no momento.
Voltemos ao exemplo da figura 111. O caso de uso validar senha, com o foco que
descrevemos no diagrama, nos mostra uma relao extendida com os casos de
uso Validar senha digitada, Validar digital ou Validar retina.
Tambm podemos escrever a relao entre esses casos de uso como se fosse uma
relao de Generalizao/Especializao. Assim, dependendo do enfoque que
quisermos analisar, podemos combinar os elementos UML. Veja na figura 112
como ficaria com essa abordagem o fragmento do diagrama.
Podemos ter diagramas de caso de uso demonstrando diferentes nveis de abstrao do sistema. Por exemplo, possvel ter um diagrama que represente o
sistema como um todo, para poder analisar suas principais funcionalidades,
como elas se agrupam, seus limites e a relao dos atores em cada um dos casos
macro de uso.
Vamos retomar o estudo de caso da padaria do senhor Joo. Veja na figura 113
como ficaria um diagrama de caso de uso que representa as funcionalidades
gerais a serem implementadas pelo sistema pedido.
Observe no diagrama que o retngulo no qual os casos de uso esto inseridos
representa o sistema que estamos estudando. Seus limites so claros.
Os casos de uso representam as funes macro que devem ser implementadas
pelo sistema, de acordo com as solicitaes do senhor Joo.

180

181

informtica 3

captulo 4

Vamos analisar agora o caso de uso Registrar compra produtos (figura 114).
Sistema de controle da padaria do sr. Joo

Gerenciar
Movimento
Financeiro

Nesse diagrama foi feito um detalhamento do caso de uso Registrar compra

produtos. Analisando o diagrama pode-se verificar que, para registrar uma compra, preciso registrar data e hora atuais, registrar o cliente, por intermdio do
nmero do carto, registrar o funcionrio, confirmando seu login e senha, registrar o produto, confirmando sua existncia, e registrar a quantidade vendida,
confirmando se h saldo suficiente para fazer a venda.

Funcionario

Registrar
Pagamento
Compra

Observe que esse diagrama j possui muitas informaes, talvez at mais do

Atendente
Registrar
Compra
Produtos

Cliente

Dono

Verificar data
e hora atuais
<<include>>

<<include>>
Registrar
Entrada
Produtos

Caixa

<<include>>

Registrar data
e hora atuais

<<include>>

Note que os atores podem ser representados isoladamente, como o caso dos
atores Cliente e Fornecedor, ou j indicando uma relao de generalizao/especializao, como no caso da relao entre Funcionario, Caixa, Atendente e Dono.

Veja quantas informaes importantes esse diagrama nos oferece. Mas ficou
claro para voc como cada um desses casos de uso devem ser implementados?
Provavelmente no, porque ainda estamos com uma viso macro do problema e
precisamos descer para outro nvel de abstrao.
nesse momento que devemos ter bom senso para perceber at onde devemos
ir na construo de nveis mais baixos de abstrao, de modo que no empreguemos tempo demais criando diagramas desnecessrios para situaes que j
esto bastante claras.

<<include>>
Verificar data
fim de uso

<<include>>

Registrar
compra
produtos
Cliente

Funcionario
<<include>>

Que outras informaes podemos extrair desse diagrama?

Podemos ver que tanto o Caixa quanto o Atendente e o Dono (senhor Joo)
podem registrar um produto vendido, mas apenas o Caixa e o Dono esto aptos
a registrar entrada de produtos do Fornecedor.

Registrar
funcionario

<<include>>

Verificar
existncia

Validar carto

Registrar
cliente

Fornecedor

Figura 113

Caso de uso Registrar

compra produtos.

Registrar compra produtos

Gerenciar
Produtos

Diagrama de casos
de uso do sistema de
controle da padaria do
senhor Joo.

Figura 114

<<include>>

Validar
funcionario

Validar Login
<<include>>

<<include>>

Registrar
quantidade
comprada do
produto

<<include>>

Validar senha
Registrar
produto

<<include>>

Validar do
produto
<<include>>

<<include>>

Validar saldo
produto

<<include>>

Verificar saldo
do produto

Verificar
existncia
do produto

O prximo passo ser criar um diagrama para cada caso de uso listado, mostrando mais detalhadamente seu funcionamento.
182

183

informtica 3

captulo 4

que deveria. Se em algum momento voc achar que seu diagrama est muito
complexo, diminua nele o nmero de casos de uso.
Neste exemplo poderamos nos limitar aos casos de uso Registrar data e hora
atuais, Registrar cliente, Registrar produto e Registrar funcionrio e, ento, em
um novo nvel, mostrar os casos de uso que implementam cada um deles. Mas
isso no seria necessrio, pois os casos de uso esto claros e o diagrama no est
muito poludo, isto , no possui excesso de componentes que possa atrapalhar e
compreenso.
Como j vimos, cada um dos casos de uso devem ser acompanhados por um descritivo. Existem vrias propostas sobre como deve ser este descritivo. A que apresentaremos
aqui prope divises, nome, atores envolvidos, pr-condies, fluxo bsico e extenses.

Extenses:
A
 entrada do produto e da quantidade pode ser feita pela balana quando se
tratar de produtos pesados na padaria.

Nome: o nome do caso de uso, geralmente iniciando por um verbo.

Observaes:

Atores envolvidos: listar os atores e os papis executados por eles no atual caso
de uso.

No h.

Pr-condies: descrever o que necessrio para que se inicie a execuo do

caso de uso.
Fluxo bsico: os passos a serem seguidos para a finalizao correta do caso de uso.
Extenses: outras possibilidades de execuo.
Observaes: qualquer informao necessria para ajudar a compreender o
funcionamento do caso de uso.
Agora vamos a um exemplo do caso de uso Registrar compra produtos. Veja:
Nome: Registrar compra produtos.
Atores envolvidos:
Funcionrio: ator que far o registro da compra no sistema.
Cliente: o cliente o qual a compra ser registrada.
Pr-condies:
Produto deve estar cadastrado.
Carto deve ser vlido.
Funcionrio deve ter acesso ao sistema.
Funcionrio deve saber seu login e senha.
A data e hora do sistema esto corretos.
Fluxo bsico:
Cliente chega para o funcionrio com o produto e o carto para registrar a
compra.
184

Funcionrio recebe o carto e o produto a ser registrado.

Funcionrio faz o login no sistema.
Funcionrio escolhe a opo de registro de compras no sistema.
Funcionrio passa o leitor de cdigo de barras no carto do cliente.
Funcionrio passa o leitor de cdigo de barras no produto.
Funcionrio digita a quantidade comprada do produto.
Funcionrio confere dados cadastrados digitados.
Funcionrio confirma entrada da compra.

4.3.2. Diagrama de classes

Um diagrama de classes mostra um conjunto de classes, interfaces e colaboraes
e seus relacionamentos. Os diagramas de classes abrangem a viso esttica de
projeto de um sistema. Expem a coleo de elementos declarativos (estticos)
(Booch, Rumbaugh e Jacobson, 2005, UML Guia do usurio.)
Principais componentes: classes, interfaces, relacionamentos.
O diagrama de classes fornece uma viso esttica do modelo a ser criado. Como
as classes so um dos componentes mais importantes da orientao a objetos,
esse diagrama deve constar de todo projeto orientado a objetos.

O Diagrama de classe no
deve faltar em projetos
orientados a objetos.
Devemos prestar muita
ateno ao criar um
diagrama de classes, que
ser a base da nossa soluo.

Identificar uma classe no tarefa das mais simples, mas o caminho procurar
itens que tm as mesmas informaes e comportamentos. Nem sempre uma classe
tem atributos e mtodos. Pode ter apenas mtodos ou apenas atributos.
Tente fazer uma lista do que voc identificou como classes. Acrescente os atores,
que geralmente so tambm classes de seu sistema.
Analise as candidatas a classes e tente achar atributos para elas e, se possvel,
alguma funcionalidade.
Coloque as classes em um diagrama e comece a analisar as relaes entre elas,
de acordo com os tipos de relacionamentos que voc estudou.
Lembre-se de que todos esses componentes foram definidos anteriormente. Se
tiver dvidas, volte a ler as definies sobre o tema.
Vamos agora analisar uma parte do diagrama de classes da padaria do senhor
Joo. Essa parte foi montada com nfase nos casos de uso Registrar compra
e pagar compra. Por isso, sero mostrados somente os mtodos envolvidos na
185

informtica 3

captulo 4

Figura 115

execuo desses casos de uso (veja figura 115). As classes que no participam
deles so apresentadas apenas como seus atributos.

entre Compra/ItemCompra e Fornece/ItemFornece, alm de uma classe de

associao ItemCompra.

Podemos identificar vrios elementos da teoria de orientao a objetos nessa

parte do diagrama. Vemos a exemplos de generalizao/especializao entre
as classes Funcionario, Dono, Atendente e Caixa. E tambm de composio

Podemos incluir a multiplicidade nos relacionamentos, se quisermos analisar esse

requisito, para, por exemplo, projetarmos o banco de dados relativo a soluo.

Diagrama de classes.

Dependendo do foco da anlise, podemos exibir os detalhes desse diagrama de

forma diferente os esteretipos das classes, seus atributos, mtodos, responsabilidades ou apenas uma dessas caractersticas.

Fornece
- dataEntrada : date
- nroNF : int
- valorTotal : double
- lancadoPor : Funcionario
- dataLancamento : date
- horaLancamento : time
- fornecedor : Fornecedor

ItemFornece
- produto : Produto
- quantidade : double
- valorUnitario : double

Produto
Cliente
- nroCarto : int
- datainicioUso : date
- dataFimUso : date

ItemCompra

+ verificaCartao(nroCaetao :
int) : boolean

Fornecedor
- codigo : int
- nome : String
- cnpj : String

Funcionario

- codigo : int
- descricao : String
- quantidadeEstoque : double
- vlUnitarioVenda : double
- estoqueMinimo : double
- situacao : int

- cpf : String
- nome : String
- nroCarteiraProfissional : int
- dataAdmissao : date
- dataDemissao : date
- senha : String

+ verificaProduto9produto : Produto,
quantidade : double) : double

+ verificaFuncionario(cpf : String,
senha : String) : boolean

ItemCompra
- quantidade : double
- dataRegistro : date
- horaRegistro : time
- atendidoPor : Funcionario
- cliente : Cliente
+ atualizaTotalCompra(valorTotalItem :
double) : boolean

Atendente
- salarioHora : double

- dataCompra : date
- valorTotal : double
- terminada : boolean
- recebidoPor : Funcionario

186

4.3.3. Diagrama de sequncia

um diagrama de interao que d nfase ordenao temporal de mensagens.
(Booch, Rumbaugh e Jacobson, 2005).
O diagrama de sequncia permite a anlise e definio da troca de mensagens
entre os objetos e atores da soluo e muito utilizado para definio de parmetros e classes dos mtodos a serem criados.
Devemos estabelecer um diagrama de sequncia para cada caso de uso cujo funcionamento tenhamos dificuldade de entender ou tenhamos dvidas a respeito
de como implement-lo.
Principais componentes: atores, classes, objetos, mensagens e focos de controle.
Foco de controle um componente do diagrama de sequncia que permite a representao de comandos de deciso, de loop e de opo. A ideia que todos os
fluxos que se encontrarem dentro do foco de controle sejam executados quando
ou enquanto a condio exibida for verdadeira. Veja a figura 116.
As mensagens representam a comunicao entre os objetos e atores do diagrama. So simbolizadas graficamente por setas. Existem quatro tipos de mensaFigura 116

Caixa

opt

- salarioMensal : double

Compra

O diagrama de classes oferece inmeras vises de nosso projeto, que vo desde

a viso da relao entre as classes at a das abstraes utilizadas. E pode, at
mesmo, ajudar na criao do banco de dados vinculado soluo.

Representao de
um foco de controle.

[confirmacao ==Falso]

Dono
- proLabore : double

Operao

Condio

187

informtica 3

captulo 4

Figura 118

Troca de mensagens
e tempo de vida
em um diagrama
de sequncia.

<<create>>
1: Produto

produto:Produto

Compra

Funcionario

ItemCompra

2.1: Mensagem de Resposta

3: recebeResposta = MesagemSincrona() : tipoDaResposta
4: MensagemAssincrona()
<<destroy>>
5: MensagemDestroi()

Diagrama de
sequncia do caso de
uso Registrar compra
produtos.

<<create>>
4.1: ItemCompra(produto,quantidade,precoUnitarioVenda,funcionario)

4: confirmaCompra()

3.1: valorUnitario = verificaProduto(produto,qualidade) : double

3: registraProduto()
Ioop [enquanto
houver produto]

2: registraCartao()

2.1: verificaCartao(nroCartao) : boolean

1.1: verificaFuncionario(cpf,senha) : boolean

Funcionario

1: login()

A primeira mensagem a de criao de um objeto da classe Produto. Em seguida, vemos uma mensagem sncrona indicando que o remetente aguarda que o
receptor processe a mensagem antes de continuar seu procedimento.
A mensagem nmero 1 a de criao de um objeto da classe Produto, aquela
que chama o mtodo construtor da classe Produto.
A nmero 2 uma mensagem sncrona, isto , que aguarda o retorno de uma
informao para continuar sua execuo normal. Veja que o retorno pode ser
por meio do final da execuo do prprio mtodo, da definio de um tipoDaResposta, diferente de void ou ainda de uma mensagem de resposta, como a
indicada na figura com o nmero 2.1.
A mensagem nmero 3 tambm sncrona, mas nomeia o retorno pela execuo do mtodo. Isso permite melhor visualizao da execuo, principalmente
quando se trata de retorno que define seu fluxo.
A quarta uma mensagem assncrona. Ou seja, enviada, mas o emissor no
aguarda o retorno da mensagem para continuar seu fluxo de execuo.
A nmero 5 uma mensagem que destri o objeto criado. No exemplo, destri
o objeto produto criado e demonstra a chamada do destrutor da classe.
Podemos ver tambm, na figura 117, que a numerao das mensagens possibilita
a compreenso da ordem em que so executadas.

FTelaRegistraproduto

A figura 117 mostra os quatro tipos de mensagem em um diagrama que representa a troca de mensagens entre Funcionario e Produto.

Funcionario

gens definidas. Mensagens sncronas so as que aguardam o retorno do fim de

seu processamento para continuar a execuo; mensagens assncronas so aquelas que o remetente continua executando sem aguardar resposta; e h tambm
as mensagens de create e destroy, que representam as chamadas dos mtodos
construtor e destrutor das classes.

Cliente

Produto

Tempo de vida

2: MensagemSincrona() : tipoDaResposta

5: atualizaTotalCompra(valorTotalItem) : boolean

Figura 117

Vamos agora analisar o diagrama de sequncia que trata do caso de uso Registrar compra produtos (figura 118).
188

189

informtica 3

captulo 4

Analisando o diagrama, vemos que no incio o funcionrio faz o login no sistema

e informa o nmero do carto do cliente. Quando os dados do produto comprado foram digitados, as mensagens foram inseridas em um foco de controle que
sugere a implementao de um loop, o qual, por sua vez, indica que aquela troca
de mensagens ocorrer enquanto houver produtos a serem lanados para o cliente.
Veja que agora sabemos exatamente quais mtodos as classes envolvidas nesse
caso de uso devem implementar.
Volte agora ao diagrama de classes. Observe que os mtodos criados naquele
diagrama saram deste.
Note que a cada compra confirmada criado um novo objeto itemCompra.
Neste exemplo podemos ver a definio da sequncia de execuo das classes
como tambm da interface grfica (GUI Graphical User Interface), representada pela classe TelaRegistraProduto.
Volte agora ao exemplo do diagrama de classes e reveja os mtodos definidos
para as classes envolvidas no diagrama. Voc perceber que tais mtodos foram
definidos a partir desse diagrama de sequncia.

:Funcionario

1: verificaFuncionario(cpf,senha) : boolean
3: valorUnitario=verificaProduto(produto,quantidade) : double
:Cliente

:FRegistraProduto

2: verificaCartao(nroCartao) : boolean

Produto

4: ItemCompra(produto,quantidade,precoUnitarioVenda,funcionario) : boolean

:ItemCompra

5: atualizaTotalCompra(valorTotalItem : boolean
:Compra

4.3.4. Diagrama de comunicao

um diagrama de interao que d nfase organizao estrutural de objetos
que enviam e recebem mensagens; um diagrama que mostra as interaes
organizadas ao redor de instncias e os vnculos entre elas. (Booch, Rumbaugh e Jacobson, 2005).
Principais componentes: objetos, mensagens.

Por modelar aspectos dinmicos do sistema, esse diagrama permite anlise e documentao da sequncia de atividades envolvidas em um caso de uso ou mesmo em um fluxo de trabalho. Possibilita a viso dos procedimentos efetuados
para execuo de um caso de uso, por exemplo, dando acesso a documentao
dos procedimentos, tanto do sistema quanto das atividades extrassistema.

O diagrama de comunicao mostra a relao entre os objetos, analisando a troca de

mensagens entre eles. Mas no se preocupa necessariamente com a ordem em que elas
ocorrem, e sim com quais objetos as mensagens so trocadas e quais so as mensagens.

Todo diagrama de atividades deve possuir um incio, marcado por um crculo

preenchido, e um fim, representado por um crculo preenchido, porm com um
aro branco na extremidade.

Vamos analisar um diagrama de comunicao tomando por base o caso de uso

Registrar compra produtos (figura 119).

Existem tambm as aes que so representadas por um retngulo de bordas

arredondadas, tendo em seu interior o nome da ao executada.

Veja que ele traz, basicamente, as mesmas informaes do diagrama de sequncia, mas em ordem diferente, dando nfase s mensagens trocadas pelos objetos,
mas no necessariamente quando essas mensagens so trocadas.

A execuo de uma ao pode ser condicional a alguma ocorrncia. Esses desvios condicionais so representados por um losango com as setas partindo para
as aes a serem executadas, seja a condio satisfeita ou no.

Em muitos projetos, usa-se ou o diagrama de sequncia ou o diagrama de comunicao, mas tambm pode-se criar ambos para anlise de alguma situao particular.

Deve-se criar diagrama de atividades para os casos de uso cujo funcionamento

no est claro ou para documentar os procedimentos a serem seguidos para
sua execuo.

4.3.5. Diagrama de atividades

um diagrama que mostra o fluxo de controle e dados de uma atividade para
outra; os diagramas de atividades abrangem a viso dinmica do sistema.
(Booch, Rumbaugh e Jacobson, 2005).
190

Figura 119
Diagrama de
comunicao do
caso de uso Registrar
compra de produtos.

Principais componentes: atividades, decises, fluxos.

Veja na figura 120 o exemplo do diagrama de atividades gerado pelo caso de uso
Registrar compra produtos.
191

informtica 3

captulo 4

Observe que o diagrama de atividades apresenta uma forma simples de documentar as aes executadas em cada caso de uso. , asssim, uma importante ferramenta de documentao do software que est sendo produzido. Note tambm
que voc deve dividir o diagrama com linhas verticais para identificar quem
deve fazer a ao.

Figura 120
Funcionario

Verificar
Login,
Senha

4.3.6. Diagrama de pacotes

O diagrama de pacotes mostra a decomposio do prprio modelo em unidades organizacionais e suas dependncias (Booch, Rumbaugh e Jacobson, 2005).
um diagrama estrutural que permite uma viso da organizao interna da
aplicao que est sendo projetada.
Principais componentes: pacotes.
Como vimos anteriormente, dentro de um pacote podemos inserir quaisquer
componentes da UML. Assim, podemos criar pacotes para estruturar nossa aplicao, usando sua modularizao para organiz-la e facilitar sua compreeenso.
Veja o exemplo da figura 121.
Neste exemplo, usamos pacotes para organizar o projeto, separando as classes de
projeto das de interface com o usurio (telas), tambm conhecidas como GUI
(Graphical User Interface).
Como podemos colocar em pacotes todos os elementos da UML, devemos utiliz-los para organizar e modular nossos projetos, deixando-os mais claros e fceis
de compreender e manter.

Logar no
Sistema

login invlido
Funcionrio

login vlido

Verificar
Carto do
Cliente

Solicitar
carto do
Cliente

Carto
Passar
cdigo de
Barra do
carto do
cliente

Verificar
Existncia
do Produto

carto invlido

Produto

carto vlido
Passar
cdigo de
Barra de
Produto

4.3.7. Diagrama de grficos de estados

Os diagramas de mquinas de estados abrangem a viso dinmica de um sistema (Booch, Rumbaugh e Jacobson, 2005).

Diagrama de
atividades do caso de
uso Registrar compra
produtos.

Sistema

no existe

existe
Digitar a
quantidade
comprada
do Produto

Verificar
Saldo do
Produto

ItemCompra

no possui saldo suficiente

Principais componentes: estado, evento.

Esse diagrama mostra os estados que podem ser assumidos por um objeto em
seu ciclo de vida. Geralmente o utilizamos para entender como tais mudanas
acontecem de modo a podermos definir as trocas de mensagens e os mtodos
que as controlam.
O incio da transio representado por um crculo preenchido e o final, por
um crculo preenchido, porm com um aro pintado de branco.
Utilizaremos como exemplo a classe Produto do estudo de caso da padaria do
senhor Joo, que pode assumir trs estados diferentes: 1 Ativo, 2 Ponto de encomenda e 3 Em falta. Esses valores so aplicados ao atributo situao quando a
execuo do caso de uso Registrar pagamento compra ou do caso de uso Registrar entrada de produtos (veja figura 122).
192

Atualizar
total da
compra
Terminar
registro do
Produto

possui saldo suficiente

no existe
Criar
Compra

existe
Compra

193

informtica 3

captulo 4

4.3.9. Diagrama de componentes

Mostra a organizao e as dependncias existentes em um conjunto de componentes; os diagramas de componentes abrangem a viso esttica de implementao de um sistema (Booch, Rumbaugh e Jacobson, 2005).

Classes de Projeto
Funcionario

GUI

FLoguin

Atendente

Dono

Caixa

FManutencaoCompra
ItemCompra

Compra
Fornece

FManutencaoFornece

FManutencaoPagamentoCompra

Cliente

ItemCompra

Produto

ItemFornece

Figura 121
Diagrama
de pacotes.

Analisando o diagrama podemos ver que a partir de um estado ativo, o produto

poder passar a ponto de encomenda ou em falta, dependendo das suas sadas
e considerando-se que a regra para um produto chegar condio de ponto de
encomenda seu saldo ser menor ou igual indicada nesse campo.
Notamos tambm que s os mtodos pagarCompra e receberProduto alteram
o estado do produto e que a baixa do estoque s efetuada quando se realiza o
pagamento da compra.
Como pudemos observar, esse diagrama nos ajuda a entender e a definir melhor
o funcionamento de nosso sistema quando h mudanas de estado dos objetos.

4.3.8. Diagrama de objetos

Mostra um conjunto de objetos e seus relacionamentos em um ponto do tempo;
os diagramas de objetos abrangem a viso esttica de projeto ou viso esttica
de processo de um sistema (Booch, Rumbaugh e Jacobson, 2005).
Principais componentes: objetos, relacionamentos.
Este diagrama nos d uma viso de como ficaro os objetos em determinado
momento da execuo do sistema. como se tirssemos uma fotografia do sistema em um momento para analisar os dados e os relacionamentos envolvidos,
como voc pode observar na figura 123.
Observe a notao desse diagrama: o objeto possui a mesma estrutura de uma
classe, porm seu nome vem antes do nome da classe. func: Funcionario quer
dizer objeto func da classe funcionrio.

O diagrama de componentes um diagrama estrutural que nos ajuda a analisar

as partes do sistema que podem ser substitudas por outras que implementem as
mesmas interfaces (de entrada e/ou de sada) sem alterar o seu funcionamento.
Principais componentes: componentes, interfaces, classes e relacionamentos.
Todo componente, geralmente, pode ser substitudo por uma classe, que implementa suas interfaces. Por isso bastante difcil separar um do outro. Mas costumamos utilizar o diagrama de componentes quando precisamos documentar
um componente que pode ser substitudo no sistema.
Um claro exemplo de uso de componente e, consequentemente, do diagrama de
componentes no estudo de caso da padaria do senhor Joo, a representao da
balana que pesa os produtos comercializados na padaria.
Como a balana vai interagir com os componentes do software, alimentando o
sistema com informaes sobre o produto vendido, como peso e valor, o senhor
Joo poder substituir a balana apenas por outra que possibilite as mesmas
interfaces, tanto de entrada quanto de sada. Vejamos na figura 124 como representamos essa situao num diagrama de componentes.
Podemos aproveitar e definir as interfaces de entrada e sada da balana e deixlas documentadas nesse diagrama.

Figura 122
Diagrama de grfico
de estados.

Produto
recebeProduto()
quantidadeEstoque + quantidadeEntrada > pontoEncomenda

Variao do atributo situao

recebeProduto()
quantidadeEstoque + quantidadeEntrada > pontoEncomenda
Ativo (1)

pagaCompra()
quantidadeEstoque <= pontoEncomenda

Ponto de encomenda (2)

pagaCompra()
quantidadeEstoque == 0
Em falta (3)
recebeProduto()
quantidadeEstoque <= pontoEncomenda

Podemos assim analisar as relaes entre os objetos em um determinado ponto

da execuo do sistema.
194

195

informtica 3

captulo 4

um sistema gerenciador de banco de dados, um servidor de aplicao ou quaisquer outros softwares que integrem a estrutura da aplicao. Possuem um nome
e podem receber um esteretipo. Um n representado por um cubo. Os ns
executam os artefatos.

prod:Produto
- codigo :1
- descricao=Leite Tipo A
- quantidadeEstoque=38
- vlUnitarioVenda=2.63
- estoqueMinimo=30.00
- situacao=1

cart:Cartao
- nroCartao=123
- datainicioUso=23/12/2008
- dataFimUso=null

Artefatos so os elementos executados pelos ns, geralmente os programas da

soluo criada. Possuem um nome e podem possuir um esteretipo.
Os relacionamentos so utilizados para representar o tipo de ligao entre os
componentes do diagrama. Podem possuir esteretipos.
Veja que, na figura 125, demonstramos em detalhes a arquitetura da soluo
proposta.

comp:Compra

it1:IlemCompra

- dataCompra=27/10/2009
- valorTotal=12.80
-terminada=true
- recebidoPor=func

- qualidade=3.00
- dataRegistro=27/10/2009
- horaRegistro=12:05
- atendidoPor-func
- cliente=cart

func:Funcionamento
- cpf=123.456.789-01
- nome=Olavo Petronio Caz
- nroCarteiraProfissional=12345
- dataAdimissao=13/05/1991
-dataDemissao=null
- senha=*******

Figura 123
Diagrama
de objetos.

it1:IlemFornece

4.3.11. Diagrama de temporizao

- produto=prod
- quantidade=4.00
- valorUnitario=2.83

um diagrama de interao, que mostra os tempos reais em diferentes objetos e

papis, em vez de sequncias de mensagens relativas (Booch, Rumbaugh
e Jacobson, 2005).

fornec:Fornece

forn:Fornecedor

- dataEntrada : 27/102009
- nroNF=123
- valorTotal=483.17
- lancadoPor=func
- dataLancamento=27/10/2009
- horaLancamento=11:35
- fornecedor=forn

- codigo=46
- nome=Fulano de Tal Ltda.
- cnpj=12.345.678/0009-10

4.3.10. Diagrama de implantao

O diagrama de temporizao, como o nome diz, tem seu foco principal no estudo do tempo gasto nas trocas de mensagens entre os componentes do sistema.
um diagrama de interao, pois auxilia o entendimento do processo de troca
de mensagens entre os diversos componentes do sistema. Geralmente utilizado
em projetos de sistemas de tempo real, em que os tempos gastos nas trocas de
mensagens e de estados na execuo da tarefa so essenciais.
Esse um diagrama de uso especfico que no se utiliza em todos os projetos.
Mas trata-se de um recurso que voc deve conhecer caso precise analisar um
sistema no qual o tempo seja um fator crucial.
Principais componentes: classes, linha de tempo, mensagens.
Criaremos um exemplo de diagrama de temporizao para definir os tempos
aceitveis para as operaes executadas pela balana da padaria do senhor Joo.
A balana em questo vai interagir com o sistema, acessando os objetos da clas-

Mostra a configurao dos ns de processamento em tempo de execuo e os

componentes envolvidos. Um diagrama de implantao abrange a viso esttica
de implantao de um sistema (Booch, Rumbaugh e Jacobson, 2005).
Trata-se de um diagrama estrutural que mostra como ser criada a estrutura
de software e hardware onde a soluo ser implementada. Podemos visualizar com esse diagrama toda a arquitetura da soluo desde os servidores,
sistemas operacionais, demais softwares e servios requeridos, alm dos protocolos de comunicao.
Principais componentes: ns, artefatos, relacionamentos.

Codigo do produto
e preo por quilo

Figura 124
Diagrama de
componentes.

Codigo do produto,
quantidade comparada
e preo por quilo

Balana

Produto

BalancaProduto

itemCompra

BalancaItemCompra

Os ns podem representar dispositivos computacionais, como um computador

ou um celular, ou um recurso de computao, como um sistema operacional,
196

197

captulo 4

<< sistema operacional>>

:Linux

8
6

{0.. 1s}

verificandoExistenciaCartao
Cartao

consultaCartao(int:nroCartao):boolean

retornandoprecoPorQuilo
processandoConsulta
Produto

verificandoExistenciaCartao

lendoNumeroDoCartao

criandoItemCompra

consultaProduto(int:codigoProduto

CodigoProduto

calculandoEExibindoPrecoTotalProduto

Podemos perceber que nosso foco na anlise do tempo gasto nas operaes
efetuadas pela balana, sem a interveno do usurio.

Balanca

Veja como representamos esse diagrama, na figura 126.

pesquisandoPrecoPorQuilo

A balana possui um visor das informaes digitadas/calculadas e um teclado numrico por meio do qual o atendente introduz os dados. Como apenas um atendente trabalha na pesagem a cada turno, ele faz o login na balana ao iniciar o trabalho
e, assim, no ter de se identificar toda vez que precisar pesar algum produto.

aguardandoDigitaoCodigoProduto

se produto, para pesquisar o preo por quilo. Depois da pesagem, calcular o

valor do item e instanciar um objeto da classe ItemCompra. exatamente essa
situao que analisaremos no diagrama abaixo, avaliando os tempos aceitveis
para cada operao.

calculandoEExibindoPesoProduto

Figura 125

aguardandoPesagem
produtoColocadoNaBalanca

{0.. 1s}

<< artefato>>
: vendeTudoBD

Exemplo de
diagrama de
implantao.

{0.. 2s}

<< sistema operacional>>

:Windows Server
<< banco de dados>>
:SQLServer

{0..3s}
{0.. 1s}

<< servidor>>
Servidor de Banco de Dados

double:precoPorQuilo

CodigoCartao

<<10-T Ethernet>>

itemCompra

<< artefato>>
: vendeTudo.war

<< navegador web>>

: Internet Explorer

booleancartaoEncontrado

10

<<web container>>
:Tomcat

<< banco de aplicao>>

:Apache

<<HTTP>>

Diagrama de
temporizao.

Computador Cliente

Figura 126

retornandoExistenciaCartao

criandoitemCompra

<< servidor>>
Servidor Web

ItemCompra(Cartao:cart,Produto:prod,double:quantidade,double:valorTotalItem,Funcionario:atend)

informtica 3

As operaes em foco so pesagem do produto, obteno do preo por quilo,

198

199

informtica 3

captulo 4

clculo do preo do item e gerao do registro da compra (criao da instncia da classe ItemCompra). So as nicas operaes para as quais o diagrama
demonstra um tempo mximo as demais, que dependem da interao do
atendente, tm os tempos estimados e apenas grafados na linha de tempo para
podermos ter uma ideia do tempo total gasto com a operao.

borao Receber_Produto. Podemos verificar todas as classes envolvidas com a

implementao dessa colaborao e as relaes entre elas. Isso nos permite analisar cada colaborao em um nvel mais baixo da abstrao, isto , de forma mais
clara e detalhada. Podemos detalhar mais, se for necessrio, incluindo ainda as
classes de interao com o usurio e as mensagens.

Sabemos agora que requisitos de tempo bsicos a balana deve realizar para que
possa ser utilizada neste sistema.

Esse diagrama no muito utilizado, mas pode ser til para a compreenso da
forma de implantar uma colaborao.

4.3.12. Diagrama de estrutura composta

4.3.13. Diagrama de viso geral de interao

utilizado para exibir as classes, interfaces e relacionamentos criados para implementar uma colaborao. Faz parte dos diagramas de interao.

Tem por objetivo analisar as sequncias necessrias para executar determinada

funcionalidade do sistema que estamos projetando. Tal funcionalidade pode ser
uma operao envolvendo vrios casos de uso. Como seu nome diz, este diagrama faz parte dos diagramas de interao.

Principais componentes: classes, relacionamentos e colaboraes.

O diagrama de estrutura composta permite identificao e anlise das classes e
demais componentes que constituem uma colaborao.
Uma colaborao, como j vimos, um agrupamento de classes, relacionamentos e interfaces que constituem uma unidade do sistema.

Figura 127
Diagrama de
estrutura composta.

Vamos analisar o diagrama de estrutura composta (figura 127), que mostra as

classes envolvidas na colaborao Receber produto.
Veja que no diagrama representado na figura 127, estamos analisando a cola-

ItemFornece

Como utiliza os mesmos blocos de construo do diagrama de atividades, podemos verificar, passo a passo, as interaes das classes em cada uma das sequn
cias criadas no diagrama de viso geral de interao.
Vejamos um exemplo desse diagrama, modelando a sequncia de atividades desde o registro at o pagamento da compra (figura 128).

4.4. Exemplo de desenvolvimento

de projetos utilizando UML

<<ator>>
Fornecedor

Fornece

Principais componentes: diagramas de sequncia, decises, fluxos.

Podemos observar passo a passo o registro de produtos comprados pelo cliente, tanto por meio do computador quanto da balana, analisando cada interao at o pagamento, que finaliza o processo.

Receber_Produto

Produto

O diagrama de viso geral tem a mesma estrutura do diagrama de atividades,

trocando as atividades por diagramas de sequncia que mostram as classes, alm
de mensagens envolvidas em cada caso de uso.

Caixa

Geralmente, desenvolvemos os diagramas de casos de uso para agrupar as funcionalidades mais importantes a serem implementadas. Sobre tais funcionalidades criamos o diagrama de classes, que ser a estrutura de nossa aplicao ou
o que chamamos de classes de projeto. No caso da padaria do senhor Joo, as
classes de projeto so as classes de cliente, produto, funcionrio, compra, fornece
e suas classes filhas.
Definimos seus principais atributos e ento fazemos o diagrama de sequncia
para os casos de uso mais relevantes no exemplo da padaria, os casos de uso registrar compra, pagar compra, receber mercadoria. Usamos esse diagrama para
definir os principais mtodos de nossas classes e as trocas de mensagens entre
elas. Com isso definido, voltamos ao diagrama de classes e o complementamos
com os mtodos definidos nos diagramas de sequncia.

200

201

informtica 3

captulo 4

sd registra_Compra_Balanca
Balanca

sd registra_Compra

loop [funcOK==false]

1 :login()

loop [clienteOK==false]

Funcionario

FTelaRegistraProduto

:Funcionario

2 :leCartao()

Cliente

:Funcionario

:Produto

:Cliente

:Atendente

Produto

loop [funcionarioOK==false]

1.1 :funcOK=verificaFuncionario

1 :login()

(String:cpf,String:senha):boolean

1.1 :funcionarioOK=verificaFuncionario
(String: CPF,String:senha):boolean
2 :calculaPesoProduto

2.1 :clienteOK=verificaCartao
(Cartao:cartao):boolean

loop
[enquantohouverproduto]

loop [precoPorQuilo=0]

loop[valorUnitario==0]

3 :leProduto()

4 :confirmaCompra()

3.1 :valorUnitario=verificaProduto
(Produto:produto,double:quantidade):double

3 :leProduto()

<<create>>
4.1 :ItemCompra(Produto:produto,double:quantidade,
double:precoUnitarioVenda,Funcionario:funcionario

3.1 :precoPorQuilo = verificaProduto

(String:codProduto) : double

4 :calculaValorTotalItem()

ItemCompra

loop [clienteOK==false]

5 :leCliente()

5.1 :clienteOK=verificaCliente(String:nroCartao):boolean

sd registra_Pagamento
:FRegistraPagamento
:Caixa

1 :leCartao ()

loop [CartaoOK==false]

:Cliente

:ItemCompra

1.1 :CartaoOK=IdentificaCartao

6 :confirmaCompra()

(String:nroCartao):boolean

2 :itens[] = totalizaCompra
(String:nroCartao):ItemCompra[]

(nroCompra is null and

dataPagamento is null)
3 :selecionaItensCompra

<<create>>

6.1 :ItemCompra(Funcionario:func, Cliente:cart,Produto:

prod,double:quantidade,double:valorTotal)

Figura 128

4 :exibeTotalCompra()

5 :registraPagamento
(double:valorPago,String:formaPagto)

Comeamos ento a nos preocupar com a interface e com o usurio e escolhemos

quais formulrios sero necessrios para o funcionamento de nossa aplicao.
5.1 :calculaTroco()
5.1.1 :abreGaveta()
(formaPagto=cartao)

5.1.1.1 :conectaOperadoraDeCartao
(double:valorPago) : double

5.2 :atualizaItemCompra
(data:DataPagamento,integer:nroCompra)

5.3 :Compra(date:Data,double:totalCompra,
Caixa:caixa,String:formaPagto)

202

:ItemCompra

:Compra

Diagrama de viso
geral de interao.

Com as classes definidas, comeamos a separ-las para melhor organizar a aplicao. Utilizamos para isso o padro MVC. Esse padro, muito utilizado pelos
desenvolvedores orientados a objeto, foi criado com a linguagem de programao Smalltalk80. Consiste basicamente em dividir as classes da aplicao em
trs grupos, que chamamos de model, view e controller. Criamos um pacote
para cada um desses itens. No model, em geral, inserimos as classes de projeto,
seguindo o modelo de nossa aplicao. No view criamos as classes de interface
com o usurio (telas) e no controller inserimos as classes que implementaro as
funcionalidades de cada classe, desde uma simples consistncia at o acesso ao
banco de dados. Essas classes que implementam o acesso ao banco de dados
levam o nome de classes de persistncia muitos desenvolvedores as colocam
em outro pacote.
203

informtica 3

Dentro do view voltamos a separar as classes em pacotes para implementar a

modulao do sistema, criando pacotes para cadastro, movimentao, consultas, relatrios e demais rotinas da execuo do sistema, s quais chamamos de
ferramentas. Com isso organizamos internamente as classes nos mesmos padres utilizados na aplicao.

dica

Voc pode
pesquisar exemplos
de implementao
a partir de MVC
em livros e sites
sobre linguagens
de programao.
Consulte
especificamente
bibliografias
que abordem a
linguagem Java.

Terminada a separao das classes, criamos os diagramas de atividade para os casos

de uso cujo procedimento e funcionamento pretendemos deixar documentados.
Verificamos ento se necessrio documentar as interfaces de algum componente
de software e elaboramos diagramas de componentes para isso.
Se houver classes que mudam de estado no decorrer da execuo do sistema,
desenvolvemos o diagrama de mquinas de estados para demonstrar qual a ideia
da mudana de estado para cada uma delas.
Por fim, se o ambiente de implantao for um ambiente heterogneo, isto ,
que envolve arquitetura com vrios servidores, como servidor de banco de dados e servidor de aplicaes, entre outros, criamos o diagrama de implantao
para demonstrar a arquitetura de software e hardware onde a aplicao dever
ser instalada.
Veja que nessa forma de desenvolvimento utilizamos os diagramas de casos de uso,
os de classes, os de sequncia, os de pacotes, os de atividades, o de mquina de
estados, os de componentes e o de implantao.

Pesquise sobre
padres de projeto
(design patterns).
So 24 padres de
desenvolvimento de
software orientado
a objetos que se
propem a resolver
os problemas mais
comuns nesse
processo.

AUGUST, Judy H. JAD - Joint Application Design. So Paulo: Makron Books,

1993.
Bezerra, E. Princpios de anlise e projetos de sistema com UML. Elsevier,
2007.
Booch, G., Rumbaugh, J. e Jacobson, I. UML Guia do Usurio. 2
edio. Elsevier, 2005.
COSTA, R. L. C. , SQL Guia Prtico, 2 edio. Rio de Janeiro: Brasport,
2006.
DA ROCHA, Ana Regina Cavalcanti et al. (org.). Qualidade de software: Teoria
e prtica. So Paulo: Pearson, 2004.
Dalton, Patrick. Microsoft SQL Server Black Book. 5 edio. The Coriolis
Group, 2008.
DATE, C. J. Introduo a Sistemas de Banco de Dados. 7 edio. Rio de Janeiro:
Campus, 2000.
ELMASRI, S. N.; NAVATHE, B. S. Sistemas de Banco de Dados: Fundamentos
e Aplicaes. 3 edio. Rio de Janeiro: Livros Tcnicos e Cientficos, 2002.

Tudo depende do tamanho da aplicao a ser desenvolvida e das dificuldades que

encontramos nas fases de anlise e projeto de software.

ELMASRI, S. N.; NAVATHE, B. S. Sistemas de Banco de Dados. 4 edio. So

Paulo: Pearson Education, 2005.

comum tambm surgirem alteraes nos modelos na fase de programao

do software. Nesse caso, voltamos ao modelo e inclumos as alteraes que
fizemos na fase de programao e testes. Mesmo depois de implantada a soluo, sempre que for necessrio fazer alguma alterao no sistema, devemos
voltar ao modelo e fazer a incluso, para que o modelo nunca fique diferente
do sistema criado.

FOWLER, Chad. The Passionate Programmer: Creating a Remarkable Career in

Software Development, 2009.

Consideraes finais
Longe da tentativa de esgotar os assuntos aqui abordados, a inteno deste livro
ajud-lo compreender um pouco melhor as fases de um projeto, o Modelo
Relacional, o Modelo de Entidade e Relacionamento, o SGBD, o mtodo orientao a objetos, o SQL e a UML.
Se voc escolheu a rea de informtica para atuar profissionalmente, continue
estudando e aprendendo sempre, pois nesse campo, dinmico, as mudanas so
constantes e quem no se atualiza vai ficando para trs. Esperamos que voc tenha conseguido alcanar uma boa viso sobre os temas aqui abordados e que v
agora em busca de mais informaes para aprofundar seus conhecimentos para
avanar cada vez mais na sua carreira profissional.

204

Referncias bibliogrficas

Korth, Henry F. e Silberschatz. Sistemas de Bancos de Dados, Ed.

Mc.Graw-Hill, SP, 2 edio revisada,1995.
Machado, F. N. R.; Abreu, M. Projeto de Banco de Dados, Uma Viso
Prtica. 2 edio. So Paulo: Editora rica, 1996.
OLIVEIRA, J. Wilson. Oracle 8i & PL/SQL. 1 edio. Santa Catarina: Editora
Visual Books, 2000.
OLIVEIRA, J. Wilson. SQL Server 7 com Delphi. 1 edio. Santa Catarina:
Editora Visual Books, 2001.
Orit, Dubinsky Yael Hazzan. Agile Software Engineering. 1 edio. Springer,
2008.
Project Management Body of Knowledge (PmBok). 3 edio, 2004.

205

informtica 3

PRESSMAN, Roger S. Engenharia de Software. So Paulo: Pearson, 2006.

SILBERSCHATZ, Abraham; KORTH, H. F. ; SUDARSHAN, S. Sistema de
Banco de Dados. 3 edio. So Paulo: Makron Books, 1999.
SOMMERVILLE, Ian. Engenharia de Software. So Paulo: Pearson, 2004.
SWEBOK, Software Engineering Body of Knowledge, 2004.
Larman, C. Utilizando UML e Padres. 3 edio. Bookman, 2007.
WELLING, L. THOMSON L, Tutorial MySQL. 1 edio. Rio de Janeiro:
Editora Cincia Moderna, 2003.
YOURDON, Edward. Declnio e Queda dos Analistas e Programadores. So Paulo: Makron Books, 1995.

206

Excelncia no ensino profissional

Administrador da maior rede estadual de educao profissional do pas, o
Centro Paula Souza tem papel de destaque entre as estratgias do Governo
de So Paulo para promover o desenvolvimento econmico e a incluso
social no Estado, na medida em que capta as demandas das diferentes
regies paulistas. Suas Escolas Tcnicas (Etecs) e Faculdades de Tecnologia (Fatecs) formam profissionais capacitados para atuar na gesto ou na
linha de frente de operaes nos diversos segmentos da economia.
Um indicador dessa competncia o ndice de insero dos profissionais
no mercado de trabalho. Oito entre dez alunos formados pelas Etecs e
Fatecs esto empregados um ano aps conclurem o curso. Alm da excelncia, a instituio mantm o compromisso permanente de democratizar a educao gratuita e de qualidade. O Sistema de Pontuao Acrescida beneficia candidatos afrodescendentes e oriundos da Rede Pblica.
Mais de 70% dos aprovados nos processos seletivos das Etecs e Fatecs
vm do ensino pblico.
O Centro Paula Souza atua tambm na qualificao e requalificao de
trabalhadores, por meio do Programa de Formao Inicial e Educao
Continuada. E ainda oferece o Programa de Mestrado em Tecnologia, recomendado pela Capes e reconhecido pelo MEC, que tem como rea de
concentrao a inovao tecnolgica e o desenvolvimento sustentvel.