Professional Documents
Culture Documents
Informtica
Informtica
Volume 3
Informtica
Anlise e gerenciamento de dados
Gustavo Dibbern Piva Wilson Jos de Oliveira
So Paulo 2010
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
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.
Mirian Ibaez
Consultor tcnico
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
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
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
INFORMTICA 3
Captulo 1
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.
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.
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).
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
existem ainda computadores com menos potncia em relao a computadores de outras geraes
TI
ID MR
/G E LE Y
TT
G IMA
ES
5 gerao 1987-atual
18
19
INFORMTICA 3
CAPTULO 1
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.
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).
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.
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.
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
INFORMTICA 3
CAPTULO 1
a que se inicia a etapa de declnio total do sistema, na qual o nvel de inovao baixo e tudo deixa a desejar. Na fase da burocracia, ou velhice, o sistema perde a funcionalidade e a elasticidade. Com isso, ningum mais tem confiana nele. Muitos percebem a situao, mas ningum faz nada, culpando o sistema por todos os erros e falhas na organizao. O declnio se intensifica e, mesmo que permanea em uso por alguns anos, a decadncia prossegue, at a morte do sistema (ADIZES, 1999). As agendas ficam superlotadas, comea-se a perder o controle de prazos e de qualidade. Ao mesmo tempo que se assume muitos compromissos, comete-se falhas. Por isso, deve-se ficar atento s reclamaes dos clientes e tentar, de qualquer maneira, atender s necessidades percebidas.
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: finalidade do projeto e sua inscrio dentro de uma estratgia global. 2. Anlise das necessidades e viabilidade: identificao, estudo e formalizao do que o cliente precisa e do conjunto de entraves. 3. Concepo geral: elaborao das especificaes da arquitetura geral do software. 4. Concepo detalhada: definio precisa de cada subconjunto do software. 5. Codificao, aplicao ou programao: traduo em linguagem de programao das funcionalidades definidas nas fases de concepo. 6. Testes unitrios: verificao individual de cada subconjunto do software, aplicados em conformidade com as especificaes. 7. Integrao: certificao e documentao da intercomunicao dos diferentes elementos (mdulos) do software. 8. Qualificao ou receita: checagem da conformidade do software s especificaes iniciais. 9. Documentao: registro das informaes necessrias para a utilizao do software e para desenvolvimentos anteriores. 10.Produo: colocao do sistema em operao para o cliente. 11.Manuteno: aes corretivas (manuteno corretiva) e evolutivas (manuteno evolutiva) no software.
26
27
INFORMTICA 3
CAPTULO 1
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.
Variveis de Yourdon
Nvel de estabilidade do usurio: se ele instvel ou inexperiente e no sabe definir suas reais necessidades, preciso usar uma abordagem mais radical. Nvel de urgncia na produo de resultados tangveis e imediatos: se o prazo curto, por questes polticas ou outras presses externas, justifica-se assumir uma abordagem radical. Nesse caso, prefervel ter 90% do sistema completo na data especificada do que 100% das etapas de anlise e projeto. Exigncias para a produo de cronogramas, oramentos, estimativas etc.: a maior parte dos grandes projetos requer estimativas de pessoal, recursos de computao e outros detalhes, e tudo isso depende de levantamento e anlise. Portanto, quanto mais detalhadas e precisas forem as estimativas, provvel que seja necessria uma abordagem conservadora.
29
INFORMTICA 3
CAPTULO 1
Desenvolvimento
2. lista de controle de projeto Implementao descrever todas as atividades para a obteno do sistema final, com definio testes de tarefas a realizar a cada iterao gerenciar o desenvolvimento Implantao inteiro para medir, em determinado nvel, o quo distante se est da ltima iterao 3. iteraes do modelo retirar cada atividade da lista de controle de projeto com a realizao de trs etapas: projeto, implementao e anlise esvaziar a lista completamente
30
31
INFORMTICA 3
CAPTULO 1
Figura 5
O modelo espiral.
Barry W. Boehm considerado um guru da Universidade do Sul da Califrnia, da qual professor emrito, e tem lugar garantido entre os estudiosos que mais influenciaram o pensamento econmico a respeito de software nos ltimos 40 anos. Ele se graduou em Harvard em 1957, mestre e Ph.D. em Matemtica e foi diretor do Software and Computer Technology Office do Departamento de Defesa dos Estados Unidos. Desde 1964 Boehm escreveu seis livros, entre eles Software Risk Manager, publicado pela IEEE Computer Society Press em 1989.
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
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.
Figura 7
As fase da prototipagem. Incio
Fi m
uto
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
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.
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: definem as propriedades e as restries do sistema, podendo especificar, por exemplo, quais linguagens de programao, bancos de dados e mtodos de desenvolvimento sero utilizados. So mais crticos do que os requisitos funcionais, pois sua definio correta influencia diretamente a performance do sistema a ser desenvolvido. De domnio: originam-se do domnio da aplicao do sistema e refletem as suas caractersticas desse domnio. Podem ser requisitos funcionais ou no funcionais; requisitos funcionais novos; restries sobre requisitos existentes ou sobre computaes especficas.
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 refinar 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. 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.
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.
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,
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
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 significados diferentes para pessoas distintas. Redigir itens especficos, claros e concisos e descartar palavras suprfluas. 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 demogrficos que identifiquem 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.
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. Especificao 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
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
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
Donald D. Chamberlin
Computao, publicou, tambm na revista ACM, o artigo The EntityRelationship Model-Toward a Unified View of Data (O modelo de entidade e relacionamento, uma viso unificada dos dados).
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.
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
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
Cliente
Compra
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
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).
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
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
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 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.
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.
OBSERVAES
Sempre que for preciso desmembrar uma entidade, isso deve ser feito de maneira que seja possvel retornar forma anterior, evitando, com isso, a perda de informaes. Sempre que se fizer o desmembramento de uma entidade, as tabelas resultantes devem ser submetidas novamente s formas normais para se ter certeza de que esto corretamente normalizadas.
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
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.
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.
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.
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.
tipo
tamanho
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
Chave estrangeira
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
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
Definir qual Sistema Gerenciador de Banco de Dados devemos adotar em uma soluo informatizada nem sempre fcil. Precisamos levar em conta seu preo, sua forma de comercializao, seus custos adicionais (valor da manuteno anual, preo por usurio etc.), estrutura de hardware que a soluo demandar (rede, stand-alone, internet), grau de segurana, tipos de acesso, formas de gerenciamento de informaes. Todos esses fatores tm de ser considerados, para chegar melhor soluo.
86
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
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.
8 10 10,2
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));
CREATE TABLE Fornece( numero_Nota INTEGER NOT NULL PRIMARY KEY, cod_Fornecedor INTEGER NOT NULL REFERENCES Fornecedor(codigo), data DATE NOT NULL, valor_Total DECIMAL(10,2) NOT NULL), PRIMARY KEY (numero_Nota,cod_Fornecedor)); CREATE TABLE ItemFornece ( numero_Nota INTEGER NOT NULL REFERENCES Fornece(numero_Nota), cod_Produto INTEGER NOT NULL REFERENCES Fornecedor(codigo), quantidade DECIMAL(5,2) NOT NULL, valor_Unitario DECIMAL(10,2) NOT NULL, PRIMARY KEY (numero_Nota,cod_Produto));
CREATE TABLE compra( numero INTEGER NOT NULL PRIMARY KEY, cod_Cartao INTEGER NOT NULL REFERENCES Cartao(codigo), data DATE NOT NULL, forma_Pagto VARCHAR(10) NOT NULL, valor_Total_Compra DECIMAL(10,2) NOT NULL, cod_Func_Caixa INTEGER NOT NULL REFERENCES Funcionario(codigo));
CREATE TABLE ItemCompra ( numero_Nota INTEGER NOT NULL REFERENCES Compra(numero), cod_Produto INTEGER NOT NULL REFERENCES Fornecedor(codigo), quantidade DECIMAL(5,2) NOT NULL, valor_Unitario DECIMAL(10,2) NOT NULL, PRIMARY KEY (numero_Nota,cod_Produto));
90
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.
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
egundo Ramez Elmasri, autor de vrios livros sobre informtica, o primeiro Sistema Gerenciador de Banco de Dados (SGBD) surgiu no final de 1960, com base nos primitivos sistemas de arquivos disponveis na poca, incapazes de controlar o acesso concorrente por vrios usurios ou processos. Assim, os SGBDs evoluram de sistemas de arquivos para armazenamento em disco, quando foram criadas novas estruturas de dados com o objetivo de armazenar informaes. Os SGBDs evoluram ao longo do tempo, com a introduo de diferentes formas de representao, ou modelos de dados, para descrever a estrutura das informaes neles contidas. Os bancos de dados se tornaram um componente essencial e indispensvel em nosso dia a dia. Geralmente no nos damos conta disso, mas sem eles no conseguiramos mais fazer atividades corriqueiras como depsitos, saques ou quaisquer outras formas de movimentao bancria, reservas em hotel, pesquisa em bibliotecas informatizadas, compras em supermercados ou lojas, aquisio de passagens areas. Tais atividades so exemplos clssicos de aplicaes que utilizam bancos de dados para manipular textos, valores, imagens etc (figura 37). Figura 37
Banco de dados.
aquisio de passagens areas
movimentao bancria
Ba n de co da do s
compras em lojas
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
InfOrmtIca 3
caPtulO 3
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.
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.
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.
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).
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 ]
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
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 } ]
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.
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-
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
[, MAXSIZE = tamanho_maximo] [, FILEGROWTH = taxa_crescimento] } [, n] [LOG ON { (NAME = nome_logico_arquivo. FILENAME = caminho_e_nome_arquivo [, SIZE = tamanho]) } [, ..n] ]
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.
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.
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
InfOrmtIca 3
caPtulO 3
banco de dados que estiver em mais de um arquivo s expandido depois que o ltimo arquivo se completar.
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.
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.
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.
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
Para vermos o resultado, devemos dar um SELECT em nossa VIEW. SELECT * FROM EMPMEDIA
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
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:
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.
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)
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).
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.
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.
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.
154
155
Captulo 4
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:
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
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.
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.
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 (figura 86).
162
163
InfOrmtIca 3
caPtulO 4
Figura 88
Exemplo de associao entre classes UML.
trabalha para4 trabalhador empregador
Figura 89
empresa
empresa * - nome : String - ramoAtividade : String - cnpj : String
1..*
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.
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
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:
l
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.
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).
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 filha). 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 fizemos, ento, foi garantir que o segredo, que tambm chamamos de regra de negcio, no faz parte da interface pblica da classe, isto , da forma com que as outras classes vo utiliz-la. Com o mtodo encapsulado na classe, seu cdigo est mais protegido de eventual cpia ou reproduo de como foi implementado, pois uma classe externa nem sabe de sua existncia. Logo, da forma como projetamos sua implementao nenhuma outra classe saber que para andar necessrio mexer a perna e muito menos como isso feito. Essa a vantagem do encapsulamento no desenvolvimento de software orientado a objetos. O mesmo princpio foi usado ao encapsular o mtodo articularPalavra.
l Poliformismo: Palavra de origem grega que significa vrias formas. No paradigma de orientao a objetos polimorfismo aparece em trs formas diferentes:
triangulo - lado1 : double - lado2 : double - lado3 : double + calculaArea() : double + calculaPerimetro() : double
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.
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.
170
171
InfOrmtIca 3
caPtulO 4
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
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).
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 definio detalhada de cada um, mostrando ainda seu uso e suas principais funcionalidades. Para podermos combinar os blocos de construo da UML devemos observar as cinco regras que essa linguagem prope, de forma que os modelos gerados contenham uma definio clara e precisa para a criao de boas solues de software. As regras nome, escopo, visibilidade, integridade, execuo sugerem que, ao inserir um item em um diagrama, voc tem de se preocupar com cinco caractersticas que devem ficar claras medida que cada um dos itens inserido. As regras devem ser observadas para que possam ser criados modelos que os autores da UML chamam de bem formados, isto , consistentes e harmnicos com todos os demais modelos que se relacionam com ele. Entenda as cinco regras: Nome: sempre devemos lembrar que o nome de um item deve deixar claras sua formao, suas aes e responsabilidades. No devemos nos esquecer tambm de que esse nome nico dentro de um modelo. Escopo: todo item inserido em um modelo deve mostrar claramente quais so seus limites, o que implementa e quando pode ser utilizado. Visibilidade: indica que necessrio tambm que fique claro quando um item estar disponvel para ser utilizado e que aes estaro disponveis por seu intermdio. Integridade: tambm importante levar em conta na criao de um item a definio clara de como este se relaciona e a consistncia de tal relacionamento. 176
Figura 109 Execuo: deve estar evidente ainda, o que o modelo representa e/ou simula. O que queremos observar com a criao desse modelo.
Diagramas definidos pela UML 2.0.
4.2.4. adornos
Alm dos trs blocos de construo, a UML oferece componentes, denominados adornos, que podem ser utilizados tanto para melhorar o entendimento dos modelos criados quanto para estender o uso da UML em situaes onde no existem componentes definidos. So eles: Esteretipos: componentes de uso geral, servem para estender o significado de determinado item em um diagrama. Por serem de propsito geral, podem ser utilizados em qualquer item da UML onde for necessria uma definio mais clara de seu papel no modelo. A UML j traz uma srie de esteretipos predefinidos como interface, ator, realizao, mas permite que o projetista defina outros mais, sempre que surgir a necessidade. Sua representao pode ser apresentada de duas formas: uma palavra entre os smbolos de menor e maior ou um desenho do prprio esteretipo que representa. Veja o exemplo da figura 110. 177
InfOrmtIca 3
caPtulO 4
Figura 110
Exemplo de esteretipo.
<< ator >>
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.
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.
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
validar senha
validar 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 <<
>> ude
validar login
<< i n
Usuario
clu
e <<
de >>
validar senha
n xte
> d>
nd >>
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
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.
Dono
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
<<include>>
Caixa
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.
<<include>>
<<include>>
<<include>>
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.
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
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
2: MensagemSincrona() : tipoDaResposta
tempo de vida
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
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
4: confirmaCompra()
3: registraProduto()
2: registraCartao()
1: login()
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
2: verificaCartao(nroCartao) : boolean
4: ItemCompra(produto,quantidade,precoUnitarioVenda,funcionario) : boolean
:ItemCompra
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
logar no Sistema
Funcionrio
login vlido
Solicitar carto do Cliente
Produto
no existe
existe
ItemCompra
existe
Compra
193
InfOrmtIca 3
caPtulO 4
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
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.
recebeProduto() quantidadeEstoque + quantidadeEntrada > pontoEncomenda ativo (1) pagaCompra() quantidadeEstoque <= pontoEncomenda Ponto de encomenda (2)
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
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.
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}
<<HTTP>>
10
booleancartaoEncontrado
CodigoCartao
{0.. 1s}
itemCompra
criandoitemCompra
<<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.
Figura 127
Diagrama de estrutura composta.
Receber_Produto
Produto
<<ator>> Fornecedor
ItemFornece
Fornece
Caixa
200
201
InfOrmtIca 3
caPtulO 4
sd registra_Compra_Balanca
Balanca
:Funcionario
:Produto
:Cliente
1 :login()
1.1 :funcoK=verificaFuncionario
(String:cpf,String:senha):boolean
1 :login()
loop [clienteoK==false]
2 :leCartao()
2.1 :clienteoK=verificaCartao
(Cartao:cartao):boolean
loop [precoPorquilo=0]
loop [enquantohouverproduto]
loop[valorUnitario==0]
3 :leProduto()
3 :leProduto()
4 :confirmaCompra()
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>>
: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)
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