Sie sind auf Seite 1von 106

Informtica

3
Anlise e Gerenciamento de Dados

Informtica
Volume 3

Informtica
Anlise e gerenciamento de dados
Gustavo Dibbern piva Wilson Jos de oliveira

so Paulo 2010

Presidente Paulo markun Vice-Presidente Fernando Jos de almeida

GOVERNADOR Jos Serra VICE-GOVERNADOR alberto Goldman SECRETRIO DE DESENVOLVIMENTO Geraldo alckmin

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

Edio de texto: marlene Jaggi Editores assistentes: Celia Demarchi

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

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.

Presidente do Conselho Deliberativo yolanda silvestre Diretora Superintendente Laura Lagan

mirian Ibaez
Consultor tcnico

Victor emmanuel J. s. Vicente

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

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.4.1. objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.4.2. atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.4.3. participantes . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.5. Modelo de ciclo de vida . . . . . . . . . . . . . . . . . . . . . . . . 24 1.5.1. Modelo em cascata ou waterfall. . . . . . . . . . . . . 27 1.5.2. Modelo em cascata evolucionrio ou waterfall evolucionrio . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 1.5.3. Modelo incremental . . . . . . . . . . . . . . . . . . . . . 30 1.5.4. Modelo 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. levantamento 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 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. Metodologia JaD (Joint application Design) . . . . . . . . . . . . . . . . . . . . . . . . . 44
Capa: Nathalia Guarienti, aluna da etec do Centro Paula souza. Foto: eduardo Pozella edio: Deise Bitinas

49 Captulo 2 Modelo de entidade e relacionamento


2.1. Conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.1.1. Estudo de caso . . . . . . . . . . . . . . . . . . . . . . . . . . 62 2.2. normalizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 2.3.fases de um projeto utilizando o modelo Er . . . . . . . 79 2.3.1. Minimundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 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

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. administrao e gerenciamento . . . . . . . . . . . . . . . . 113 3.4.1. Segurana em banco de dados . . . . . . . . . . . . 114 3.4.1.1.Segurana no sistema operacional . . . 114 3.4.1.1.1. Definio de contas de usurio . . . . 115 3.4.1.2. permisses para banco de dados. . . . 116 3.4.1.3. permisses a objetos do banco de dados . . . . . . . . . . . . . . . 120 3.4.2. plano de manuteno de banco de dados . . . 124 3.4.3. uma linguagem verstil: SQl . . . . . . . . . . . . . 129 3.4.3.1. Como utilizar os comandos SQl. . . . 130 3.4.3.2. Categorias da linguagem SQl . . . . . . 130 3.4.3.3 Instrues SQl . . . . . . . . . . . . . . . . . . 130

95 Captulo 3 Banco de dados


3.1. Evoluo dos sistemas de computao . . . . . . . . . . . . 97 3.1.1. abordagem tradicional . . . . . . . . . . . . . . . . . . . . 97 3.1.2. abordagem de sistemas integrados . . . . . . . . . 98 3.1.3. abordagem de bancos de dados . . . . . . . . . . . . 98 3.2. Conceitos e terminologia . . . . . . . . . . . . . . . . . . . . . 101 3.2.1. abstrao de dados . . . . . . . . . . . . . . . . . . . . 101 3.2.2. Instncias e esquemas . . . . . . . . . . . . . . . . . . . 102 3.2.3. Independncia de dados . . . . . . . . . . . . . . . . . 102 3.2.4. linguagem 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. regras de converso do modelo E-r para o modelo relacional . . . . . . . . . . 112

Sumrio
3.4.3.4. Views (Vises) . . . . . . . . . . . . . . . . . . 140 3.4.3.5. Stored procedures (procedimento armazenado). . . . . . . . . . . . . . . . . . . . 143 3.4.3.6. um exemplo completo . . . . . . . . . . . 148 4.2.2. relacionamentos . . . . . . . . . . . . . . . . . . . . . . . 176 4.2.3. Diagramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 4.2.4. adornos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 4.3. os diagramas da uMl . . . . . . . . . . . . . . . . . . . . . . . . 178 4.3.1 Diagrama de casos de uso . . . . . . . . . . . . . . . . 179 4.3.2 Diagrama de classes . . . . . . . . . . . . . . . . . . . . . 185 4.3.3 Diagrama de sequncia . . . . . . . . . . . . . . . . . . 187 4.3.4 Diagrama de comunicao . . . . . . . . . . . . . . . . 190 4.3.5 Diagrama de atividades . . . . . . . . . . . . . . . . . . 190 4.3.6 Diagrama de pacotes . . . . . . . . . . . . . . . . . . . . 192 4.3.7 Diagrama de grficos de estados . . . . . . . . . . . 192 4.3.8 Diagrama de objetos . . . . . . . . . . . . . . . . . . . . 194 4.3.9 Diagrama de componentes . . . . . . . . . . . . . . . 195 4.3.10 Diagrama de implantao . . . . . . . . . . . . . . . . 196 4.3.11 Diagrama de temporizao. . . . . . . . . . . . . . . 197 4.3.12 Diagrama de estrutura composta . . . . . . . . . 200 4.3.13 Diagrama de viso geral de interao . . . . . . 201 4.4. Exemplo de desenvolvimento de projetos utilizando uMl . . . . . . . . . . . . . . . . . . . . 201 204 205 Consideraes finais Referncias bibliogrficas
<< ator >>

155

Captulo 4 Linguagem unificada de modelagem (UML)


4.1. orientao a objetos . . . . . . . . . . . . . . . . . . . . . . . . . 159 4.1.1. abstrao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 4.1.2. Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 4.1.2.1. Mtodo . . . . . . . . . . . . . . . . . . . . . . . . 161 4.1.2.2. responsabilidades . . . . . . . . . . . . . . . 162 4.1.2.3. tipos de relacionamento entre classes 163 4.1.3. objeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 4.1.3.1. Interao entre objetos . . . . . . . . . . . 166 4.1.3.2. Mensagem . . . . . . . . . . . . . . . . . . . . . 167 4.2. as vrias opes da uMl . . . . . . . . . . . . . . . . . . . . . 170 4.2.1. Conceitos da estrutura da uMl . . . . . . . . . . . 172

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). 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. 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).

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.

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.

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.

I.2. Geraes de computadores


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

sHeILa TeRRy/RUTHeRFORD aPPLeTON

HULTON aRCHIVe/GeTTy ImaGes

CeRN/sCIeNCe PHOTO LIBRaRy/LaTINsTOCK

OLeKsIy maKsymeNKO/aLamy/OTHeR ImaGes

as cinco geraes de mquinas


1 1940 - 1958
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

Chega a era do chip, a lmina de silcio que permite a integrao de uma infinidade de circuitos

3 1964 - 1971
Com a srie 360, da IBm, a velocidade dos equipamentos passou para bilionsimos de segundo

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

16

17

DI VU LG a

4 1971 - 1987

2 1958 - 1964

InforMtICa 3

Captulo 1

primeira (1940-1958)
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. 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. 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.

Quarta (1971-1987)
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).

Quinta (1987- primeira dcada do sculo 21)


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.

Vantagens e desvantagens das 5 geraes de computadores


Gerao
1 gerao 1940-1958

Componente eletrnico
vlvulas eletrnicas

Vantagens
nicos componentes eletrnicos disponveis menor dimenso produzem menos calor mais rpidos ainda menor dimenso menor produo de calor menor consumo de energia ainda mais rpidos no necessrio ar condicionado conservao mnima alta densidade de componentes maior densidade de componentes reduzido tamanho auto-regenerao grande fiabilidade e velocidade multiprocessamento

Desvantagens
grande dimenso produzem muito calor necessitam de ar condicionado ainda necessitam de constante manuteno necessitam de ar condicionado inicialmente com muitos problemas de fbrica

RID

Le y /G e

TT

yI

ma

Ge

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.

2 gerao 1958-1964

transistores

TIm

3 gerao 1964-1971

circuitos integrados

terceira (1964-1971)
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.

4 gerao 1971-1987

circuitos integrados larga escala

existem ainda computadores com menos potncia em relao a computadores de outras geraes

TIm

L RID

Ge e y/

TT

y Im

e aG

5 gerao 1987-atual

transdutores e circuitos em paralelo

maior complexidade ainda muito caros

18

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).

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. 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.

primeira (1Gl)
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.

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.

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.

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.

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.

Saiba mais sobre as 3Gl


orientada aos negcios): usada em sistemas comerciais, nanceiros 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.

Cobol, sigla para Common business oriented language (linguagem

de iniciantes): criada com ns 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

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 cheada por john W. backus.

Fortran, acrnimo para a expresso ibm mathematical Formula

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 signica C com classes, em portugus), em 1983, no bell labs, como um adicional linguagem C.

Basic, sigla para beginners All-purpose symbolic instruction Code (Cdigo de instruo simblico para todos os propsitos

20

21

InforMtICa 3

Captulo 1

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

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). 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. 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.

1.4. processo de desenvolvimento


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,

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

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.

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.

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.

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. 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 nanceiras 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.

22

23

InforMtICa 3

Captulo 1

1.4.2. atividades
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.

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

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.

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

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

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 confi ana 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.

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.

a sequncia de etapas
1. Definio dos objetivos: nalidade do projeto e sua inscrio dentro de uma estratgia global. 2. Anlise das necessidades e viabilidade: identicao, estudo e formalizao do que o cliente precisa e do conjunto de entraves. 3. Concepo geral: elaborao das especicaes da arquitetura geral do software. 4. Concepo detalhada: denio precisa de cada subconjunto do software. 5. Codificao, aplicao ou programao: traduo em linguagem de programao das funcionalidades denidas nas fases de concepo. 6. Testes unitrios: vericao individual de cada subconjunto do software, aplicados em conformidade com as especicaes. 7. Integrao: certicao e documentao da intercomunicao dos diferentes elementos (mdulos) do software. 8. Qualificao ou receita: checagem da conformidade do software s especicaes 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.

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.

26

27

InforMtICa 3

Captulo 1

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. 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. 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).

Figura 3
O modelo evolucionrio.

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

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

Variveis de Yourdon
Nvel de estabilidade do usurio: se ele instvel ou inexperiente e no sabe denir 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


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). 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.

1.5.4. Modelo iterativo


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. 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 identicveis 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 nal, com denio 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
O modelo espiral.

1.6.1. atividades do gerenciamento de riscos


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.

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 inuenciaram 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 Oce 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.

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. 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.

Figura 6
atividades do processo de gerenciamento de riscos.
Identificao do risco Anlise do risco Planejamento do risco Monitoramento do risco

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).

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.
Planos de contingncia e de tratamento dos riscos

Lista dos riscos potenciais

Lista dos riscos priorizados

Avaliao dos riscos

32

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

grfica, ento alguns SGBDs (Sistemas Gerenciadores de Banco de Dados) tambm fornecem ferramentas para a concepo de telas de entrada e sada de dados. 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. 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.

Figura 7
as fase da prototipagem. Incio

Fi m

uto

Coleta e refinamento dos requisitos

pro

rod

je t

op

or

ia d

pi

h ar

do

En

ge n

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

o e nt a m po fin ti re prot do
avaliao do prottipo pelo cliente

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

34

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.

No ambguo: tem apenas uma interpretao. muito importante prestar ateno na linguagem utilizada para no causar duplo entendimento. 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. Alcanvel: realizvel a um custo definido. Completo: no precisa ser explicado ou aumentado, garantindo capacidade suficiente do sistema. Consistente: no contradiz nem mesmo duplica outro requisito e utiliza os termos na mesma forma que a adotada nos outros requisitos. Ordenvel: tem uma ordem por estabilidade, importncia ou ambos. Aceito: acolhido pelos usurios e desenvolvedores.

diCAs pArA A EsCritA

Caractersticas
Os requisitos tambm so agrupados por suas caractersticas, em uma gama que inclui desde os necessrios aos concisos e completos, entre outros. 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.

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. No funcionais: denem as propriedades e as restries do sistema, podendo especicar, 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 denio correta inuencia diretamente a performance do sistema a ser desenvolvido. De domnio: originam-se do domnio da aplicao do sistema e reetem as suas caractersticas desse domnio. podem ser requisitos funcionais ou no funcionais; requisitos funcionais novos; restries sobre requisitos existentes ou sobre computaes especcas.

tipos

seja qual for o sistema, h vrias formas de atend-lo. dependendo das necessidades que se apresentam existem vrios tipos de requisito: 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. 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 renar os requisitos dos usurios, transformando-os em termos de engenharia de software. 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.

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.

36

37

InforMtICa 3

Captulo 1

Figura 8
Imprimir a Nota Fiscal.

1.8.4. Documentao de requisitos


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). 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. 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. 6. O documento pode ser tanto sucinto e genrico quanto extenso e detalhado.

1. O programa deve imprimir nota fiscal e fazer a integrao com o sistema da Nota Fiscal Paulista e de vendas registradas (figura 8). 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.

ExEmplos dE rEquisitos

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.

1.8.3. Dependncia de requisitos


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. 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.

1.8.5. Mtodos de identificao e coleta


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.

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.

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.

38

39

InforMtICa 3

Captulo 1

objetivos, metas, estilos de comunicao e terminologias adequadas aos diversos nveis culturais dos entrevistados.

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

por questionrio
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. 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.
TaxI/GeTTy ImaGes

nhecimento e habilidade do especialista; percepo de expresses no verbais; sensibilidade s diferenas culturais; cordialidade e cooperao.

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. 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. O relacionamento entre os participantes de uma entrevista deve ser baseado no respeito mtuo e em algumas outras premissas, tais como deferncia ao co40

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
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. 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.

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.

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.;

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.

diCA

requisitos para a documentao


viso geral do sistema e dos benefcios decorrentes do seu desenvolvimento. Glossrio explicativo dos termos tcnicos utilizados. denio dos servios ou dos requisitos funcionais do sistema. denio das propriedades do sistema (requisitos no funcionais), como viabilidade, segurana etc. restries operao do sistema e ao processo de desenvolvimento. denio do ambiente em que o sistema operar e as mudanas previstas nesse ambiente. Especicaes detalhadas, incluindo modelos e outras ferramentas.

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

Questionrio bem-feito
Evitar palavras ambguas ou vagas que tenham signicados diferentes para pessoas distintas. redigir itens especcos, claros e concisos e descartar palavras supruas. incluir apenas uma ideia por item. 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 demogrcos que identiquem os entrevistados.

42

43

InforMtICa 3

Captulo 1

desenhos 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.

Figura 10
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 2. Especicao do objetivo da entrevista 3. seleo do entrevistado 4. marcao da entrevista 5. preparao das questes ou do roteiro 6. Entrevista propriamente dita 7. documentao da entrevista, incluindo as informaes obtidas 8. validao com o entrevistado da transcrio da entrevista 9. Correo da transcrio 10. Aceitao por parte do entrevistado 11. Arquivamento

44

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, identicando-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. 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 condenciais 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 identicar 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 nal, 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.

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).

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. 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.

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.

50

51

InforMtICa 3

Captulo 2

Figura 12
No possvel encontrar um s livro em ambiente desorganizado.

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. 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).
ROBeRT W. GINN/aLamy/OTHeR ImaGes

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.

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

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


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 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

Donald D. Chamberlin

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

Dr. Peter Chen

FOTOs: DIVULGaO

52

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.

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.

Figura 13
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

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.

AtEno

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 defi nies 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 refi nados at que se chegue ao modelo fi nal 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

54

55

InforMtICa 3

Captulo 2

atributo
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.

Figura 16
Chave primria.

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.

dataDemissao

Funcionario

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.

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: 1. Atributo composto: representa a estrutura das informaes que sero armazenadas no atributo, por exemplo:

Figura 17
Relacionamento.

Pertence

primeiroNome sobrenome rua nome

complemento numero
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. Figura 18
auto-relacionamento.

Endereco
N Subordinado Funcionario E_Chefe

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. 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

1
Chefe

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. Vendedor

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. Figura 22
n n

Relacionamento com campos. Produto

Cliente

Compra

cod_Cliente cod_produto codigo nome

quantidade valor_unitario codigo nome

1
Atende

Resumindo:
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.
n

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. 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). Figura 23

1
Pertence Departamento

Funcionario

1
Funcionario Gerencia

1
Departamento

Relacionamentos 1 para 1 .

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
Relacionamento N para N.
n n

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

Cliente

Compra

Produto

1
Pertence Departamento

Funcionario

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

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
Restrio. Funcionario
(1, n) n

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).
cod_Depto

Figura 27
Diagrama de entidade e relacionamento.
n

1
Pertence
(0,1)

Departamento

Funcionario

1
Pertence Departamento
(1:1)

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.

(0:n)

codigo nome dataadmissao

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
n n

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. Vale, agora, propor um roteiro de passos para a elaborao do modelo de entidade e relacionamento e a criao do diagrama que o representar.

Compra

Produto

Atende

1
Funcionario

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.

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

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, carFigura 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.

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. 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
Chegamos ento a uma lista final de quatro entidades: Produto Funcionrio Carto Fornecedor

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

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.

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
Fornecedor.

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
Carto compra produto.

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). 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 7 Desenhar o diagrama de entidade e relacionamento

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. 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.

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

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. 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: 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.

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. 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. 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.

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

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. 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

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

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) 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.

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) 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. 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

obsErvAEs

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

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.

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.

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 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 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

Entidade funcionario
Funcionario(codigo,nome,funcao)

74

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.

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 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. 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.

Entidade compra
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: 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.

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

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

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.

FUNCIONARIO
Codigo 1 2 3 Nome Sr. Joo laercio da Silva 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).

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 1 2 3 Rua Complemento Bairro Jd. Boa Esperana Centro Jd. Cachoeira Cidade Campinas Hortolndia Caldas Estado CEP Sp Sp MG 12123-123 12123-123 04321-789 Contato Telefone Celular Cardoso alimentos rua 2 n 32 Maria Doceria pedro parede rua 34 n 123 atrs da Igreja rua 4 n 120 Sr. Cardoso 99-3234-0000 99-9999-0000 D. Maria Sr. pedro 99-9999-8976 87-9999-0000

Figura 33
Roteiro para criar uma soluo informatizada.

FORNECE
numero_nota 1 2 4 cod_fornecedor 3 2 6 data 21/05/2009 21/05/2009 23/05/2009 valor_total 123,12 34,20 48,90

ITEMFORNECE
numero_nota 1 1 cod_produto 2 3 quantidade 120 2 valor_unitario 1,00 1,56

PRODUTO
Codigo 2 3 15 Nome leite B. achocolatado em p leite condensado Preo_Venda Saldo 1,89 32 3,45 13 2,11 54 estoque_Minimo 4 2 12

78

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). 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.

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.

2.3.3. anlise de requisitos


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.

diCA

2.3.1. Minimundo
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.

2.3.4. requisitos de dados


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.

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


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 Figura 34
as vrias operaes do negcio padaria.

2.3.2. levantamento de requisitos


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. 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. 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 me-

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.

diCA

80

81

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). 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. 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: 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.

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. 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.

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.
Aqui temos que: funcionrio anota a quantidade, o tipo de produto e seu preo em um pedao de papel e o entrega ao cliente.

Em resumo: O cliente solicita uma quantidade de um certo produto ao funcionrio. 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.

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.

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

82

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.

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. indica a forma como o atributo ser armazenado (data, texto, nmero, etc.). 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. define se este atributo tem de ser preenchido para que se possa incluir uma informao nesta entidade ou no. o atributo deve ser definido como nico, quando seus valores no puderem ser repetidos. atributo ou conjunto de atributos que definem um nico registro (tupla) em uma entidade. 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. indica se o atributo tem um valor padro de preenchimento. 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.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.

Tipo

Tamanho

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.

Obrigatrio

Diagrama de entidade e relacionamento da padaria do sr. Joo

nico Chave primria

Chave estrangeira

Valor default Regra de validao

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.

FORNECEDOR
nome codigo nome rua tipo de dados IntEGEr VarCHar VarCHar VarCHar VarCHar VarCHar VarCHar VarCHar VarCHar VarCHar tamanho 4 50 50 50 40 40 2 8 10 10 obrigatorio Sim Sim Sim no no Sim Sim Sim no no unico Sim no no no no no no no no no chave chave valor primaria estrangeira default Sim no no no no no no no no no no no no no no no no no no no no no no no no no no no no no regra de validacao no no no no no no no no no no

CARTAO
nome codigo dt_Inicio_uso dt_fim_uso tipo de dados IntEGEr DatE DatE tamanho 8 8 8 obrigatorio Sim Sim no unico Sim no no chave chave valor primaria estrangeira default Sim no no no no no no no no regra de validacao no no no

complemento bairro cidade estado cep telefone

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 codigo nome preco_venda saldo tipo de dados IntEGEr VarCHar DECIMal DECIMal tamanho 5 40 10,2 10,2 10,2 obrigatorio Sim Sim Sim Sim Sim unico Sim no no no no chave chave valor primaria estrangeira default Sim no no no no no no no no no no no no 0 0 regra de validacao no no Valor > 0 Valor >=0 Valor >=0

celular

estoque_minimo DECIMal

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.

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

FUNCIONARIO
nome codigo nome funo tipo de dados IntEGEr VarCHar VarCHar tamanho 4 50 30 obrigatorio Sim Sim Sim unico Sim no no chave chave valor primaria estrangeira default Sim no no no no no no no no regra de validacao no no no

FORNECE
nome numero_nota cod_fornecedor tipo de dados IntEGEr IntEGEr tamanho 7 4 obrigatorio Sim Sim unico Sim no chave chave valor primaria estrangeira default Sim Sim no Sim no no regra de validacao no fornecedor j deve ser cadastrado data valor_total DatE DECIMal 8 10,2 Sim no FORNECE Sim no no no no no no no no Soma dos itens de itemfornece para esta nota.

O melhor SGBD

denir 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

87

InforMtICa 3

Captulo 2

ITEMFORNECE
nome numero_nota cod_produto tipo de dados IntEGEr IntEGEr tamanho 7 5 obrigatorio Sim Sim unico Sim no chave chave valor primaria estrangeira default Sim Sim Sim Sim no no regra de validacao no produto j deve ser cadastrado quantidade DECIMal 5,2 10,2 Sim Sim no no no no no no no no no >0 valor_unitario DECIMal

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.

diCA

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;

COMPRA
nome numero cod_cartao tipo de dados IntEGEr IntEGEr tamanho 7 8 obrigatorio Sim Sim unico Sim no chave chave valor primaria estrangeira default Sim no no Sim no no regra de validacao autonumerao Carto j deve ser cadastrado no no Soma dos valores dos itens de itemcompra para esta compra funcionrio deve ser cadastrado

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.

data forma_pagto valor_total_ compra

DatE VarCHar DECIMal

8 10 10,2

Sim Sim Sim

no no no

no no no

no no no

no no no

CREATE TABLE Cartao ( codigo INTEGER NOT NULL PRIMARY KEY, dt_inicio_uso DATE NOT NULL, dt_fim_uso DATE);

cod_func_ caixa

IntEGEr

Sim

no

no

Sim

no

ITEMCOMPRA
nome numero_nota cod_produto tipo de dados IntEGEr IntEGEr tamanho 7 5 obrigatorio Sim Sim unico Sim no chave chave valor primaria estrangeira default Sim Sim no Sim no no regra de validacao no produto j deve ser cadastrado quantidade DECIMal 5,2 10,2 Sim Sim no no no no no no no no no Valor do campo preco_ venda da tabela produto quando da incluso da nota. valor_unitario DECIMal

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,

88

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));

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.

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));

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

90

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.

Informtica, psicologia, administrao


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.

Figura 36 execuo de um projeto.

TeTRa ImaGes/CORBIs/LaTINsTOCK

92

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.

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

3.1.1. abordagem tradicional


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. 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

movimentao bancria

Ba n de co da do s
compras em lojas

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.

reservas em hotel

compras em pesquisa em supermercados bibliotecas informatizadas

96

InformtIca 3

captulo 3

Figura 38
a abordagem tradicional: para cada usurio, um ou mais aplicativos.

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. 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.2. abordagem de sistemas integrados


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.

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.

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
Desenvolvimento exvel e produtivo Integrao dos dados em nvel empresarial Transparncia dos dados s aplicaes maior controle sobre a integridade dos dados maiores controles de segurana dos dados

REQUISITOS
aquisio e utilizao de um sGBD Utilizao de dicionrio de dados Centralizao da definio de dados Centralizao do projeto das bases de 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
Interrelacionamento entre os nveis de abstrao.

3.2.4. linguagem de definio de dados


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.

Henry Korth autor de vrios livros clssicos da informtica.

3.2.5. linguagem de manipulao de dados


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.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).

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: 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.

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

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.

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.

3.2.3. Independncia de dados


Independncia de dados a habilidade de modificar a defi nio de um esquema em um nvel, sem afetar sua defi nio 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.

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

102

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.

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.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.

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.

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.

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

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

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.

104

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).

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 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 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. Definio de viso de dados: fazer operaes relacionais de juno, criar vises de partes do modelo de dados. Manipulao de dados: permitir criar, alterar, consultar e deletar conjuntos de dados. Restries de integridade: possibilitar que sua sublinguagem controle as restries especficas de uma tabela ou de valores aceitveis para uma determinada coluna. Autorizaes: definir limites de acesso a tabelas por usurio, inclusive em nvel de coluna. Limites 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 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 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 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

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 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 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 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.

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.

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. 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.

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.

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

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. 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.

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. 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
Matricula 1234 5678 9191 9287 9388 Nome Wilson oliveira lucas Sirtori andra oliveira amanda cristina priscila oliveira Depto 25 15 10 10 25

DEPARTAMENTO
Numero 10 25 15 Nome contabilidade Sistemas rH

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.

2) Chaves candidatas
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.

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
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 110

regra de integridade de identidade


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


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; Ser totalmente nula. Isso significa que uma ligao lgica est desativada. 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.4. administrao e gerenciamento


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:

Definir 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.

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

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
segurana em banco de dados.

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.

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. 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. 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.

pErmissEs Ao usurio AdministrAdor

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).

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.

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 usurios 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

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.

Exemplo 1 Garantir para o login SERVIDOR\wilson a permisso de criar novos bancos de dados: USE Master GRANT CREATE DATABASE TO [SERVIDOR\wilson]

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:

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. Exemplo 2 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 Atribuir as permisses CREATE TABLE, CREATE RULE e CREATE VIEW, para os usurios SERVIDOR\grupo1 e SERVIDOR \grupo2, no Banco de Dados Exemplo1. USE Exemplo1 GRANT CREATE TABLE, CREATE RULE, CREATE VIEW TO [SERVIDOR \grupo1], [SERVIDOR \grupo2]

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

Create Table (Criar Tabela). Create View (Criar Consulta). Create SP (Criar Stored Procedure). Create Default (Criar Default). Create Rule (Criar Regra),

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

rEstriEs Ao usurio dE ContA limitAdA

Create Function (Criar Funo). Backup DB (Backup do Banco de Dados). Backup Log (Backup do Log de transaes).

Para atribuir as permisses, utilizamos o comando GRANT, com a seguinte sintaxe: GRANT { ALL | statement [ ,...n ] } TO security_account [ ,...n ]

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). 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. J as principais permisses de objetos do banco de dados so estas: SELECT: Tabelas, views e colunas. INSERT: Tabelas e views. DELETE: Tabelas e views. UPDATE: Tabelas, views e colunas. EXECUTE: Stored Procedures. Exemplo Atribuir todas as permisses para o usurio SERVIDOR\andrea, no banco de dados Exemplo1. USE Exemplo1 GRANT ALL TO [SERVIDOR\andrea]

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. USE Exemplo1 REVOKE CREATE TABLE, CREATE RULE, CREATE VIEW TO [SERVIDOR\wilson] 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. 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

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

TO [SERVIDOR\andrea]

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. 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. UPDATE: Tabelas, views e colunas. EXECUTE: Stored procedures. 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: 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 ] [ WITH GRANT OPTION ] [ AS { group | role } ]

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] Quando o login for um usurio do Windows, o nome deve vir entre colchetes, como no exemplo: [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. USE Exemplo1 GRANT ALL ON Clientes TO [SERVIDOR\andrea]

120

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 [ GRANT OPTION FOR ] { ALL [ PRIVILEGES ] | permission [ ,...n ] } { [ ( column [ ,...n ] ) ] ON { table | view } | ON { table | view } [ ( column [ ,...n ] ) ] | ON { stored_procedure | extended_procedure } | ON { user_defined_function } } { TO | FROM } security_account [ ,...n ] [ CASCADE ] [ AS { group | role } ]

USE Exemplo1 REVOKE SELECT, UPDATE, DELETE ON Clientes TO [SERVIDOR\wilson]

Exemplo 3 Retirar todas as permisses atribudas ao usurio SERVIDOR\ andrea, na tabela Clientes do Banco de Dados Exemplo1. USE Exemplo1 REVOKE ALL ON Clientes TO [SERVIDOR\andrea]

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 ]

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. 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.

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

122

InformtIca 3

captulo 3

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]

Figura 43
a tela inicial do assistente.

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] 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. Nessa 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. Agora 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.

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.

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. Na 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. Entre as opes que surgirem na tela, clique no sinal +, ao lado da opo Management, para que sejam mostradas novas opes.

124

125

InformtIca 3

captulo 3

specific databases j vem marcada por padro. Na lista de bancos de dados selecionamos os que queremos incluir no plano de manuteno. 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.

Figura 45
aceitando as configuraes padro.

13. Clique 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. 16. Nessa 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

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.

126

127

InformtIca 3

captulo 3

Figura 46
Finalizando a criao do plano de manuteno.

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. 22. Nessa 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. Ser 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. Uma 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. Agora 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. Agora voc poder definir uma conta conhecida como Proxy Account. Se for configurada uma conta como esta, as tarefas sero executadas no con-

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. 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

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.

128

InformtIca 3

captulo 3

3.4.3.1. como utilizar os comandos SQl


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.

[, MAXSIZE = tamanho_maximo] [, FILEGROWTH = taxa_crescimento] } [, n] [LOG ON { (NAME = nome_logico_arquivo. FILENAME = caminho_e_nome_arquivo [, SIZE = tamanho]) } [, ..n] ]

3.4.3.2. categorias da linguagem SQl


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

DDL (Declaraes de Definio de Dados): parte da linguagem com


comandos para criao de estruturas de dados como tabelas, colunas, etc. Exemplo: CREATE TABLE. Onde:

DML (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. mandos para definir usurios e controlar seus acessos aos dados. Exemplo: GRANT.

Nome_bancodedados: o nome do banco de dados que se deseja criar. Nome_logico_arquivo: um nome usado para referenciar o arquivo em
quaisquer comandos SQL executados depois que o banco de dados tiver sido criado.

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

PRIMARY: 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. estamos criando. O arquivo deve necessariamente estar na mesma mquina que o servidor SQL, mas pode estar em uma unidade de disco diferente. co de dados. O valor mnimo de 1MB, mas o padro 3MB para arquivos de dados e 1MB para arquivos de log.

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 : CREATE DATABASE nome_bancodedados [ON { [PRIMARY] (NAME = nome_logico_arquivo, FILENAME = caminho_e_nome_arquivo [, SIZE = tamanho] 130

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

SIZE: especifica o tamanho em megabytes que queremos alocar para o ban-

MAXSIZE: permite especificar o tamanho mximo que o arquivo pode

atingir. O padro possibilita que o arquivo cresa at que o disco fique cheio. 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

FILEGROWTH: especifica a taxa de crescimento do arquivo. Esse ajuste

InformtIca 3

captulo 3

banco de dados que estiver em mais de um arquivo s expandido depois que o ltimo arquivo se completar.

Instruo CrEatE taBlE


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

LOG 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.

CREATE TABLE Nome_Tabela ( Nom_Coluna_1 Tipo [CONSTRAINT PRIMARY| KEY| NOT NULL ]

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.

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 : INSERT [INTO] nome_tabela (colunas ) Figura 48
Retorno do myadmin.

VALUES ( valores ) Figura 49


Criando uma tabela.

132

133

InformtIca 3

captulo 3

Figura 50
a tabela criada.

Figura 52
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: INSERT INTO Cliente (codigo, nome, endereco) VALUES (123, WILSON, CAIXA POSTAL: 155 ITU). Como ilustra a figura 51. Figura 51
Uso do INseRT.

Figura 54
Registro do cliente Wilson.

Clusula UPDATE
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

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

InformtIca 3

captulo 3

Onde: 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 update.

Figura 57
O nome do cliente completo na tabela.

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. 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
Para confirmar o comando DeLeTe.

Comando SELECT
O Comando SELECT busca informaes de um banco de dados. A sintaxe : SELECT [DISTINCT] {*, coluna [alias], ...} FROM tabela; 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. 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. Exemplo: SELECT codigo, nome FROM departamento; Exemplo com alias: SELECT nome Nome, salario*12 Salrio Anual FROM empresas;

Figura 60
O retorno depois do delete.

Figura 61
O seLeCT para verificar o registro.

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
O comando seLeCT.

Figura 65
Verificao dos registros includos.

Figura 66 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.
O resultado da verificao.

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: Uma 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. 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

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

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.

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 Outro exemplo: 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: CREATE VIEW EMPMEDA (MAIOR, MENOR, MEDIA) AS

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: CREATE PROCEDURE BUSCACLIENTE @nomebusca varchar(50) As SELECT codcliente, Nome from CLIENTE WHERE Nome LIKE %+@nomebusca+% 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

142

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).

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:

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: 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 :

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) )

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 On ItemNotaFiscal for insert As If not exists (select * from Inserted, NotaFiscal 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)

CREATE TRIGGER ExclusaoNota On NotaFiscal for delete As Delete from ItemNotaFiscal Where NumeroNota in (select NumeroNota from deleted)

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

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

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. 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: 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.

Figura 69
Instruo a partir do phpmyadmin.

Figura 70
Instruo bem sucedida.

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

INSERT INTO Cliente (codigo, nome, endereco) VALUES (145, ANDREA SIRTORI OLIVEIRA, CAIXA POSTAL: 135 ITU); 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
Instruo usando phpmyadmin.

Figura 73
Instruo a partir do phpmyadmin.

Observe na figura 73 como ser a instruo a partir do phpMyAdmin. O sucesso da instruo pode ser conferido na figura 74. Figura 74
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: Select * from Cliente. Figura 72
sucesso da instruo.

Vamos agora listar os clientes com cdigo menor que 200. A instruo para isto a demonstrada a seguir: Select * from cliente where codigo < 200 Na figura 75, podemos observar como ser a instruo empregando-se o phpMyAdmin. Figura 75
Listagem de clientes com cdigo menor que 200.

150

151

InformtIca 3

captulo 3

Figura 76
Instruo bem sucedida.

Figura 78
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: 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 Figura 77
Instruo para o nome completo.

Na figura 79, mostramos como ser a instruo, outra vez utilizando o phpMyAdmin. Figura 79
a instruo para listar cliente de cdigo 123.

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


Realizada a alterao do cliente.

152

153

InformtIca 3

captulo 3

Figura 81
O comando DeLeTe para o cliente de cdigo 123.

Figura 83
Listagem dos clientes para comprovar excluso.

Figura 84 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. O cliente de cdigo 123 foi eliminado.

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 especcas para cada banco de dados disponvel no mercado, como, por exemplo, sql server, oracle, mysql e Cache.

154

155

Captulo 4

Linguagem unicada 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. 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.

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:

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
DIVULGaO

1969
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. 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.
aP PHOTO/ImaGePLUs

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. 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.

DIVULGaO

Ivan Sutherland
158

Krysten Nygaard

Alan Curtis Kay

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.

Figura 85
Carro - nomeFabricante : String - nomeModelo : String - cor : String - numeroPortas : int - anoFabricao : int - velocidadeMaxima : double + abrirPortas() : void + fecharPortas() : void + ligar() : void + desligar() : void + acelerar() : void + frear() : void + trocarMarcha() : void Responsabilidades - Se locomover na velocidade e direo indicados pelo usurio. - Acelerar quando solicitado. - Frear quando solicitado.

Nome da classe Atributos

Definio da classe segundo UmL 2.

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.

Mtodos

Responsabilidades

4.1.2. classe
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. 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).

4.1.2.1. mtodo
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

1985-1989
DIVULGaO

Bertrand meyer lana a linguagem eifel, orientada a objetos. 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. 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 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.

1994-1995
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

Bertrand Meyer

James Gosling

160

161

InformtIca 3

captulo 4

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.

Figura 86
Carro - nomeFabricante : String - nomeModelo : String - cor : String - numeroPortas : int - anoFabricao : int - velocidadeMaxima : double + abrirPortas() : void + fecharPortas() : void + ligar() : void + desligar() : void + acelerar() : void + frear() : void + trocarMarcha() : void

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.

Outra forma de representar uma classe em UmL 2.0. Carro

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
Janela - largura : double - altura : double + abri() : void + fechar() : void + tratarEvento() : void Evento - nome : String + start() : void Representao de uma dependncia em UmL 2.0.

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.

Assinatura: 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.

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.

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 (fi gura 86).

162

163

InformtIca 3

captulo 4

Figura 88
exemplo de associao entre classes UmL.
Trabalha para trabalhador empregador

Figura 89
Empresa
Empresa * - nome : String - ramoatividade : String - cnpj : String

Pedido - numero : int - data : Date - valortotal : double

Funcionario - salario : double - nroCarteiraprofissional : String

1..*

- nome : String - ramoatividade : String - cnpj : String

esquerda representao da agregao entre classes UmL 2.0.

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. 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.
*

1
*

Figura 90
Representao de uma composio UmL 2.0.

ItemdePedido - descrio : String - quantidade : int - precounitario : double

Departamento - nome : String

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 # nome : String # cpf : String + andar() : void + falar() : void Especializao

Representao de herana utilizando UmL.

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 signicado de 0..*. n multiplicidade n, onde n deve ser trocado por um nmero que representar o nmero exato de objetos relacionados quela classe.

Funcionario - salario : double - nroCarteiraprofissional : String + trabalhar() : void Generalizao

164

165

InformtIca 3

captulo 4

Figura 92
Classe e objeto. O molde que dar origem ao produto.

4.1.3.2. mensagem
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:

Encapsulamento: Propriedade de uma classe de restringir o acesso a seus 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: 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.

eQUIPe eesC-UsP FRmULa sae

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.

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).

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 + andar() : void + falar() : void - mexerperna() : void - articularpalavra() : void exemplo de visibilidade de atributos e mtodos. UmL 2.0.

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

167

InformtIca 3

captulo 4

Figura 94
exemplo de polimorfismo de mtodo dito sobrecarga. Pessoa - numero1 : double - numero2 : double - resultado : double + soma() : void + soma(valor1 : int, valor2 : int) : int + soma(valor1 : double, valor2 : double) : double

- 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. 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. - 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). 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 fi lha). Sempre que uma subclasse referenciada como a superclasse, tambm temos polimorfismo.

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 fi zemos, 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.

Poliformismo: Palavra de origem grega que significa vrias formas. No paradigma de orientao a objetos polimorfismo aparece em trs formas diferentes:

anlise e projeto de software orientado a objetos


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. 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.

Poligono # nrolados : int + calculaarea() : double + calculaperimetro() : double

Circulo - raio : double + calculaarea() : double + calculaperimetro() : double

Triangulo - lado1 : double - lado2 : double - lado3 : double + calculaarea() : double + calculaperimetro() : double

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.

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.

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. 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.

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.

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

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 defi nies criadas pelos blocos de construo. Estes, por sua vez, so de trs tipos: itens, relacionamentos e diagramas.
Conexo + abrir() : void + testar() : void + fechar() : void

Figura 98
Classe implementando uma interface de entrada definida.
iEntrada

iConexo

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.

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

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 Figura 97
as duas formas de representar uma interface.
<< interface>> iConexo + abrir() : void + testar() : void + fechar() : void iConexo

Controle de Estoque

Solicitar Preo

exemplo ( esquerda) de colaborao.

Figura 100
exemplo de caso de uso.

172

173

InformtIca 3

captulo 4

Figura 101
exemplo de componente.
FormCliente EmEspera <<artefato>> Cliente.class

Figura 105
exemplo de mquina de estados.

Figura 102
exemplo de artefato.

todo. So representados por um retngulo com o smbolo da UML para componentes (figura 101). 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

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
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.
solicita Senha

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
Esta classe faz a conexo entre o software aplicativo e o sistema operacional

exemplo de pacote.

Controle

Figura 108
exemplo de nota.

174

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 defi nio 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 defi nio 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 >>

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.

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.

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

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.

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.

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. Normalmente todos os diagramas so desenvolvidos com auxilio de um software. 178

uml Guia do usurio, vale a pena consultar


o livro uml Guia do usurio integra um conjunto de obras constitudo ainda pelos ttulos the unied modeling language reference manual second Edition (2005) e the unied 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 denies 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.

179

InformtIca 3

captulo 4

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. 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.

Figura 112
Validar retina

Relao de Generalizao especializao.

Validar senha

Validar digital

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.

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 <<

> de >

Validar usuario digitado

Validar login

<< i n
Usuario

clu

te ex <<
de >>
Validar senha

> nd >
nd >>

Validar senha digitada

xte <<e

Validar digital

<<exten d>>

Validar retina

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 Registrar Pagamento Compra

Funcionario

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. Observe que esse diagrama j possui muitas informaes, talvez at mais do

Figura 114
Caso de uso Registrar compra produtos.

Atendente Registrar Compra Produtos

Dono

Registrar compra produtos

Cliente

Verificar data e hora atuais <<include>> <<include>> Registrar cliente <<include>> Funcionario <<include>> Registrar funcionario <<include>> Validar funcionario <<include>> Validar Login <<include>> Validar senha Registrar produto <<include>> Validar do produto <<include>> <<include>> Verificar existncia do produto Validar carto <<include>> Verificar data fim de uso Verificar existncia

Gerenciar Produtos Registrar Entrada Produtos Fornecedor <<include>>

<<include>>

Caixa

Registrar data e hora atuais

Figura 113
Diagrama de casos de uso do sistema de controle da padaria do senhor Joo.

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. 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. 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. O prximo passo ser criar um diagrama para cada caso de uso listado, mostrando mais detalhadamente seu funcionamento.

Registrar compra produtos Cliente

<<include>>

<<include>>

Registrar quantidade comprada do produto

Validar saldo produto

<<include>>

Verificar saldo do produto

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. Nome: o nome do caso de uso, geralmente iniciando por um verbo. Atores envolvidos: listar os atores e os papis executados por eles no atual caso de uso. 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. Extenses: A entrada do produto e da quantidade pode ser feita pela balana quando se tratar de produtos pesados na padaria. Observaes: No h.

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. 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

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.

InformtIca 3

captulo 4

execuo desses casos de uso (veja figura 115). As classes que no participam deles so apresentadas apenas como seus atributos. 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

entre Compra/ItemCompra e Fornece/ItemFornece, alm de uma classe de associao ItemCompra. Podemos incluir a multiplicidade nos relacionamentos, se quisermos analisar esse requisito, para, por exemplo, projetarmos o banco de dados relativo a soluo. 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. 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.

Figura 115
Diagrama de classes.

Fornece ItemFornece
- produto : produto - quantidade : double - valorunitario : double - dataEntrada : date - nronf : int - valortotal : double - lancadopor : funcionario - datalancamento : date - horalancamento : time - fornecedor : fornecedor

Fornecedor
- codigo : int - nome : String - cnpj : String

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 mensa-

Produto Cliente
- nroCarto : int - datainiciouso : date - datafimuso : date + verificaCartao(nroCaetao : int) : boolean - codigo : int - descricao : String - quantidadeEstoque : double - vlunitarioVenda : double - estoqueMinimo : double - situacao : int + verificaproduto9produto : produto, quantidade : double) : double

Funcionario
- cpf : String - nome : String - nroCarteiraprofissional : int - dataadmissao : date - dataDemissao : date - senha : String + verificafuncionario(cpf : String, senha : String) : boolean

ItemCompra

ItemCompra
- quantidade : double - dataregistro : date - horaregistro : time - atendidopor : funcionario - cliente : Cliente + atualizatotalCompra(valortotalItem : double) : boolean

Atendente
- salarioHora : double

Caixa
- salarioMensal : double

Figura 116
opt [confirmacao ==falso] Representao de um foco de controle.

Compra
- dataCompra : date - valortotal : double - terminada : boolean - recebidopor : funcionario

Dono
- prolabore : double

Operao

Condio

186

187

InformtIca 3

captulo 4

Figura 117
<<create>> 1: produto
5: atualizatotalCompra(valortotalItem) : boolean

Figura 118
Funcionario produto:Produto
Compra

Troca de mensagens e tempo de vida em um diagrama de sequncia.

Diagrama de sequncia do caso de uso Registrar compra produtos.

2: MensagemSincrona() : tipoDaresposta
Tempo de vida

2.1: Mensagem de resposta 3: receberesposta = MesagemSincrona() : tipoDaresposta 4: Mensagemassincrona() <<destroy>> 5: MensagemDestroi()


Produto ItemCompra Cliente FTelaRegistraproduto

A figura 117 mostra os quatro tipos de mensagem em um diagrama que representa a troca de mensagens entre Funcionario e Produto. 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. Vamos agora analisar o diagrama de sequncia que trata do caso de uso Registrar compra produtos (figura 118). 188

3.1: valorunitario = verificaproduto(produto,qualidade) : double

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.

Funcionario

Ioop [enquanto houver produto]

4: confirmaCompra()

3: registraproduto()

2: registraCartao()

1: login()

<<create>> 4.1: ItemCompra(produto,quantidade,precounitarioVenda,funcionario)

1.1: verificafuncionario(cpf,senha) : boolean

2.1: verificaCartao(nroCartao) : boolean

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 Produto

2: verificaCartao(nroCartao) : boolean

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. 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. Vamos analisar um diagrama de comunicao tomando por base o caso de uso Registrar compra produtos (figura 119). 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. 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. 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. 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. Existem tambm as aes que so representadas por um retngulo de bordas arredondadas, tendo em seu interior o nome da ao executada. 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. 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. Principais componentes: atividades, decises, fluxos. Veja na figura 120 o exemplo do diagrama de atividades gerado pelo caso de uso Registrar compra produtos. 191 Figura 119
Diagrama de comunicao do caso de uso Registrar compra de produtos.

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

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 Sistema

Diagrama de atividades do caso de uso Registrar compra produtos.

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.
login invlido

Verificar Login, Senha

Logar no Sistema

Funcionrio

login vlido
Solicitar carto do Cliente

Verificar Carto do Cliente

Carto Passar cdigo de Barra do carto do cliente

carto invlido carto vlido

Verificar Existncia do Produto

Produto

Passar cdigo de Barra de Produto

no existe

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). 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
Digitar a quantidade comprada do Produto

existe

Verificar Saldo do Produto

ItemCompra

no possui saldo suficiente

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


Classes de Projeto
Funcionario

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).
Caixa

GUI

FLoguin

Dono

Atendente

FManutencaoCompra ItemCompra FManutencaoFornece Compra Fornece

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.

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. Podemos assim analisar as relaes entre os objetos em um determinado ponto da execuo do sistema. 194

Produto Variao do atributo situao


recebeproduto() quantidadeEstoque + quantidadeEntrada > pontoEncomenda

recebeproduto() quantidadeEstoque + quantidadeEntrada > pontoEncomenda Ativo (1) pagaCompra() quantidadeEstoque <= pontoEncomenda Ponto de encomenda (2)

pagaCompra() quantidadeEstoque == 0 Em falta (3) recebeproduto() quantidadeEstoque <= pontoEncomenda

195

InformtIca 3

captulo 4

prod:Produto cart:Cartao
- nroCartao=123 - datainiciouso=23/12/2008 - datafimuso=null - codigo :1 - descricao=leite tipo a - quantidadeEstoque=38 - vlunitarioVenda=2.63 - estoqueMinimo=30.00 - situacao=1

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. 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
- dataCompra=27/10/2009 - valortotal=12.80 -terminada=true - recebidopor=func

it1:IlemCompra
- qualidade=3.00 - dataregistro=27/10/2009 - horaregistro=12:05 - atendidopor-func - cliente=cart

it1:IlemFornece
- produto=prod - quantidade=4.00 - valorunitario=2.83

4.3.11. Diagrama de temporizao


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). 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 clasFigura 124
Diagrama de componentes.

fornec:Fornece func:Funcionamento
- cpf=123.456.789-01 - nome=olavo petronio Caz - nroCarteiraprofissional=12345 - dataadimissao=13/05/1991 -dataDemissao=null - senha=******* - dataEntrada : 27/102009 - nronf=123 - valortotal=483.17 - lancadopor=func - datalancamento=27/10/2009 - horalancamento=11:35 - fornecedor=forn

forn:Fornecedor
- codigo=46 - nome=fulano de tal ltda. - cnpj=12.345.678/0009-10

Figura 123
Diagrama de objetos.

4.3.10. Diagrama de implantao


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. Os ns podem representar dispositivos computacionais, como um computador ou um celular, ou um recurso de computao, como um sistema operacional,

Codigo do produto e preo por quilo

Codigo do produto, quantidade comparada e preo por quilo

Produto

Balana

itemCompra

Balancaproduto

BalancaItemCompra

196

197

InformtIca 3

captulo 4

ItemCompra(Cartao:cart,produto:prod,double:quantidade,double:valortotalItem,funcionario:atend)

Figura 126
Diagrama de temporizao.

<< sistema operacional>> :Linux << banco de aplicao>> :Apache <<web container>> :Tomcat << artefato>> : vendeTudo.war
{0..3s}

Computador Cliente << navegador web>> : Internet Explorer

<<Http>>

10

booleancartaoEncontrado

CodigoCartao

{0.. 1s}

itemCompra

criandoitemCompra

<< servidor>> Servidor Web

<<10-t Ethernet>>
<< servidor>> Servidor de Banco de Dados << sistema operacional>> :Windows Server << banco de dados>> :SQLServer << artefato>> : vendeTudoBD
Codigoproduto {0.. 2s}

double:precoporQuilo

retornandoprecoporQuilo

consultaCartao(int:nroCartao):boolean

consultaproduto(int:codigoproduto

Figura 125
exemplo de diagrama de implantao.

aguardandopesagem produtoColocadonaBalanca

verificandoExistenciaCartao

pesquisandoprecoporQuilo

lendonumeroDoCartao

Veja como representamos esse diagrama, na figura 126. Podemos perceber que nosso foco na anlise do tempo gasto nas operaes efetuadas pela balana, sem a interveno do usurio. As operaes em foco so pesagem do produto, obteno do preo por quilo, 198

criandoItemCompra

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.

calculandoEExibindoprecototalproduto

aguardandoDigitaoCodigoproduto

calculandoEExibindopesoproduto

Balanca

produto

processandoConsulta

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.

Cartao

verificandoExistenciaCartao

{0.. 1s}

retornandoExistenciaCartao

{0.. 1s}

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. Sabemos agora que requisitos de tempo bsicos a balana deve realizar para que possa ser utilizada neste sistema.

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. 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


utilizado para exibir as classes, interfaces e relacionamentos criados para implementar uma colaborao. 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. 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-

4.3.13. Diagrama de viso geral 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. 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. Principais componentes: diagramas de sequncia, decises, fluxos. Como utiliza os mesmos blocos de construo do diagrama de atividades, podemos verificar, passo a passo, as interaes das classes em cada uma das sequncias 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). 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.

Figura 127
Diagrama de estrutura composta.

Receber_Produto

Produto

<<ator>> Fornecedor

4.4. Exemplo de desenvolvimento de projetos utilizando uml


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.

ItemFornece

Fornece

Caixa

200

201

InformtIca 3

captulo 4

sd registra_Compra_Balanca

sd registra_Compra :Funcionario loop [funcOK==false] FTelaRegistraProduto Funcionario Cliente Produto


:Atendente loop [funcionarioOK==false]

Balanca

:Funcionario

:Produto

:Cliente

1 :login()

1.1 :funcOK=verificaFuncionario
(String:cpf,String:senha):boolean

1 :login()

1.1 :funcionarioOK=verificaFuncionario (String: CPF,String:senha):boolean 2 :calculaPesoProduto

loop [clienteOK==false]

2 :leCartao()

2.1 :clienteOK=verificaCartao
(Cartao:cartao):boolean
loop [precoPorQuilo=0]

loop [enquantohouverproduto]

loop[valorUnitario==0]

3 :leProduto()

3.1 :valorUnitario=verificaProduto
(Produto:produto,double:quantidade):double <<create>>

3 :leProduto()

3.1 :precoPorQuilo = verificaProduto (String:codProduto) : double

4 :confirmaCompra()

4.1 :ItemCompra(Produto:produto,double:quantidade,
double:precoUnitarioVenda,Funcionario:funcionario

ItemCompra

4 :calculaValorTotalItem()

loop [clienteOK==false]

5 :leCliente()
sd registra_Pagamento :FRegistraPagamento :Caixa :Cliente :ItemCompra

5.1 :clienteOK=verificaCliente(String:nroCartao):boolean

1 :leCartao ()

loop [CartaoOK==false]

1.1 :CartaoOK=IdentificaCartao
(String:nroCartao):boolean (nroCompra is null and dataPagamento is null) 3 :selecionaItensCompra

6 :confirmaCompra()

<<create>>

6.1 :ItemCompra(Funcionario:func, Cliente:cart,Produto:


prod,double:quantidade,double:valorTotal)

:ItemCompra

2 :itens[] = totalizaCompra
(String:nroCartao):ItemCompra[]

4 :exibeTotalCompra()

Figura 128 Comeamos ento a nos preocupar com a interface e com o usurio e escolhemos quais formulrios sero necessrios para o funcionamento de nossa aplicao.
Diagrama de viso geral de interao.

5 :registraPagamento
(double:valorPago,String:formaPagto)

5.1 :calculaTroco() 5.1.1 :abreGaveta() 5.1.1.1 :conectaOperadoraDeCartao


(double:valorPago) : double (formaPagto=cartao)

5.2 :atualizaItemCompra 5.3 :Compra(date:Data,double:totalCompra,


Caixa:caixa,String:formaPagto) (data:DataPagamento,integer:nroCompra) :Compra

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

202

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.

referncias bibliogrficas
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. ELMASRI, S. N.; NAVATHE, B. S. Sistemas de Banco de Dados. 4 edio. So Paulo: Pearson Education, 2005. FOWLER, Chad. The Passionate Programmer: Creating a Remarkable Career in Software Development, 2009. 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.

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.

diCA

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.

Tudo depende do tamanho da aplicao a ser desenvolvida e das dificuldades que encontramos nas fases de anlise e projeto de software. 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.

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

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.

Das könnte Ihnen auch gefallen