adsi-p3

Tecnlogo em

Anlise e Desenvolvimento de Sistemas

Anlise e desenvolvimento

de sistema cliente e servidor

OrganizadorAndr Luiz Perin

1o semestre de 2014 - 1a edio ww

w.m

etod

ista

.br

Coordenador do Curso de Tecnologia em Anlise e Desenvolvimento de SistemasProf. Me. Andr Luiz Perin

OrganizadorProf. Me. Andr Luiz Perin

Professores AutoresProf. Alexandre Atanes de JesusProf. Me. Andr Luiz PerinProf. Cristiano Camilo dos Santos de AlmeidaProf. Esp. Durval de Oliveira Dorta JuniorProf. Me. Leonardo Mairene MunizProf. Rafael Guimares SakuraiProfa. Dra. Silvia Brunini

Assessoria PedaggicaAdriana Barroso de AzevedoCeleste Yanela Millaray Panik Castro Eliana Vieira dos Santos Thais Helena Santinelli

Coordenao EditorialProf. Me. Andr Luiz Perin

Produo de Materiais Didtico-Pedaggicos EADBruno Tonhetti Galasse

Editorao EletrnicaEditora Metodista

Projeto GrficoCristiano Leo

RevisoVictor Hugo Lima Alves

Data desta edio1o semestre de 2014

Dados Internacionais de Catalogao na Publicao (CIP) (Biblioteca Central da Universidade Metodista de So Paulo)

Rua do Sacramento, 230 - Rudge Ramos 09640-000 So Bernardo do Campo - SP

Tel.: 0800 889 2222 - www.metodista.br/ead permitido copiar, distribuir, exibir e executar a obra para uso no comercial, desde que dado crdito ao autor original e Universidade Metodista de So Paulo. vedada a criao de obras derivadas. Para cada novo uso ou distribuio, voc deve deixar claro para outros os termos da licena desta obra.

Universidade Metodista de So PauloDiretor GeralWilson Roberto Zuccherato

Conselho DiretorStanley da Silva Moraes (Presidente), Nelson Custdio Fr (Vice-Presidente), Osvaldo Elias de Almeida (Secretrio). Vogais: Aires Ademir Leal Clavel, Augusto Campos de Rezende, Aureo Lidio Moreira Ribeiro, Jonas Adolfo Sala, Ktia de Mello Santos, Marcos Vinicius Sptizer, Oscar Francisco Alves Jnior. Suplentes: Regina Magna Araujo, Valdecir Barreros

Reitor: Marcio de MoraesPr-Reitora de Graduao: Vera Lcia Gouva StivalettiPr-Reitor de Ps-Graduao e Pesquisa: Fbio Botelho JosgrilbergDireo da Faculdade de Exatas e Tecnologia: Carlos Eduardo SantiCoordenao do NEAD: Adriana Barroso de Azevedo

expe

dien

te Un3a Universidade Metodista de So Paulo Anlise e desenvolvimento de sistema cliente e servidor / Universidade Metodista de So Paulo. Organizao de Andr Luiz Perin. So Bernardo do Campo : Ed. do Autor, 2014. 286 p. (Cadernos didticos Metodista - Campus EAD)

Bibliografia ISBN 978-85-7814-255-1

1. Anlise de sistemas 2. Processamento eletrnico de dados I. Perin, Andr Luiz II. Ttulo.

CDD 004.21

Tecnlogo em

Anlise e Desenvolvimento de Sistemas

1o semestre de 2014 - 1a edio

UMESP

Anlise e desenvolvimento

de sistema cliente e servidor

OrganizadorAndr Luiz Perin

ww

w.m

etod

ista

.br

Palavra do Reitor

Caro(a) aluno(a) do Campus EAD Metodista,

com muita alegria que acolhemos voc na Universidade Metodista de So Paulo!

O Guia de Estudos digital que est recebendo faz parte da nossa preocupao com a edu-cao superior de qualidade da Metodista. Este material foi elaborado pelos professores do seu curso e ser utilizado durante o semestre nas suas atividades de estudos. Nosso desejo que voc aproveite ao mximo o contedo aqui disponibilizado, explorando todas as possibilidades para aprofundamento dos temas tratados.

O Guia uma parte dos esforos que tm marcado as atividades do Campus EAD Meto-dista. Ao longo dos anos, buscamos intensamente o cumprimento do nosso compromisso em propiciar interao professor-aluno, formao continuada da equipe de docentes e tcnicos que atuam na modalidade, qualidade das atividades propostas e estmulo para a construo de conhecimentos. Tudo isso para voc se sentir parte de uma instituio que prima pela qualidade em seus processos formativos.

Temos certeza de que ainda h muito por fazer no processo de aperfeioamento das dife-rentes estratgias de ensino e aprendizagem na modalidade EAD, mas o caminho trilhado sinaliza que temos acertado.

No ano de 2013, concentramos nossos esforos para estabelecimento de parcerias com novos polos em todas as regies do Brasil. Tambm ampliamos nosso portflio de cursos de Ps--Graduao EAD para que voc, aluno de graduao Metodista, possa continuar sua formao com excelncia e qualidade desejadas. Em 2014, o desafio continua: tornar a EAD da Metodista sinnimo de qualidade nacional e internacional, levar a formao cidad e humanizadora a mais pessoas e, por consequncia, valorizar ainda mais seu diploma.

O melhor de tudo isso saber que voc est conosco e, como ns, acredita na Metodista.

Bons estudos e um timo semestre!

Prof. Dr. Marcio de Moraes

Reitor

Universidade Metodista de So Paulo

6

921

47

65

77

101

131

149

165

Mdulo: Modelagem e Documentao de Sistemas

Laboratrio de ModelagemProfessor Alexandre Atanes de Jesus

Modelagem de Banco de Dados Prof. Esp. Durval de Oliveira Dorta Junior

Engenharia de Requisitos Parte 1Prof. Me. Andr Luiz Perin

Engenharia de Requisitos Parte 2Prof. Me. Andr Luiz Perin

Mdulo: Organizao de Dados

Introduo ao Banco de DadosParte 1Prof. Esp. Leonardo Mairene Muniz

Introduo ao Banco de DadosParte 2Prof. Esp. Leonardo Mairene Muniz

Organizao de Dados IProfessora Dra. Silvia Brunini

Organizao de Dados IIProfessora Dra. Silvia Brunini

Organizao de Dados IIIProfessora Dra. Silvia Brunini

sum

rio

Mdulo: Implementao de Sistemas Cliente Servidor

Introduo ao desenvolvimento de interface gr-fica utilizando swingProf. Rafael Guimares Sakurai

Criando aplicaes desktop que gravam informaes em arquivos textoProf. Rafael Guimares Sakurai

Criando uma aplicao Swing com acesso ao banco de dadosProf. Rafael Guimares Sakurai

Conexo com bancos de dados utilizando a Java Database Connectivity.Prof. Cristiano Camilo dos Santos de Almeida

Enumeraes e tipos genricosProf. Cristiano Camilo dos Santos de Almeida

CollectionsProf. Cristiano Camilo dos Santos de Almeida

173

195

209

223

245

261

Laboratrio de Modelagem

Professor Alexandre Atanes de Jesus

Objetivos: Apresentar ao aluno os principais conceitos ligados

modelagem e documentao de sistemas utilizando o paradigma de projeto orientado a objetos em conjunto com

uma metodologia para Modelar e Documentar Sistemas de Informao bastante utilizada pelas empresas que trabalham

com desenvolvimento de sistemas; ajudar o aluno a identificar os principais requisitos dos sistemas e agrup-los em

diagramas que ajudaro no desenvolvimento e na documenta-o final da soluo. Praticar a modelagem e documentao de

sistemas utilizando a notao da UML (Unified Modeling Language) e seus principais diagramas.

Palavras-chave:

Modelagem; Documentao; Unified Modeling Language (UML); Metodologia; Diagramas; Classes; Objetos,

Requisitos; Anlise.

Mdulo

www.metodista.br/ead

Modelagem e Documentao de sistemas

POR quE MODELAR E DOCuMENTAR SOftwAre?

Por que no podemos simplesmente conversar com o nosso cliente e/ou usurio e j sair programando?

Muitos profissionais podem afirmar que conseguem determinar todas as necessidades de um sistema de informao de cabea e que sempre trabalharam assim, mas a concepo de um software, muitas vezes, complexa e demanda um bom tempo para o entendimento do problema a ser solucionado. Neste caso, a documentao dessa soluo deve seguir alguns padres que possam ser entendidos e acompanhados por todos os envolvidos no desenho e na construo da soluo, o que nunca foi uma tarefa fcil.

Mesmo em sistemas simples importante fazermos a sua modelagem e documentao, pois todo sistema est sujeito a novas verses, atualizaes e manutenes e nesses casos que vamos precisar analisar a documentao para verificar como a soluo foi construda e como podemos modific-la.

Hoje em dia os softwares tem uma importncia muito grande para qualquer ramo de atuao e isso faz com que eles tenham uma dinmica muito grande e sejam modificados e atualizados com muita frequncia e sem seus modelos e documentao seria impossvel realizar essa tarefa.

Precisamos documentar e gerenciar todas as solicitaes e necessidades do nosso cliente e/ou usurio para direcionar a soluo de uma forma que atenda da melhor forma possvel essas necessidades, sem perder o foco do objetivo final do sistema e sem criar falsas expectativas em relao ao que deve ser entregue.

Outro ponto importante da documentao est ligado ao custo final dos sistemas, pois quanto mais tarde se descobre um erro maior o custo para consert-lo e as consequncias podem ser irreparveis.

Segundo Pressman (2006), cerca de 60% dos erros ocorrem j na fase de elaborao do projeto, nas atividades exercidas pela engenharia de requisitos e anlise de sistemas. Obviamente esses erros podem ser corrigidos antes do final do projeto. Porm, o custo para a correo desses erros tende a aumentar conforme o sistema vai chegando prximo a sua verso final. Aps a sua entrega, a correo de um defeito pode custar at 1.000 vezes mais que na fase de levantamento dos requisitos.

A imagem abaixo mostra os dados coletados por Boehm (1981) que demostram a relao entre o custo de uma soluo e as etapas de desenvolvimento de um sistema.

Figura 1 Fonte: Boehm (1981)


10

MAS O qUe MODelAgeM?

um recurso de suporte para a sntese da soluo, um modelo ajuda a planejar um sistema antes de cri-lo.

Os modelos tambm podem ajud-lo a se certificar de que o design confivel, que os requisitos foram entendidos e cumpridos por todos os envolvidos no projeto.

Modelos so ferramentas para melhorar o entendimento do sistema, pois apresentam de forma clara e direta as funcionalidades do sistema, quais informaes so manipuladas pelo siste-ma e seu comportamento dinmico.

Um modelo uma simplificao da realidade, eles podem ser estruturais, dando nfase organizao do sistema, ou podem ser comportamentais, dando nfase dinmica do sistema.

Modelos Visuais so essenciais para a comunicao entre os envolvidos no projeto e o cli-ente.

MODELO DE SOftwAre DEFINIO!

Um modelo de software captura a viso de um sistema fsico e faz a abstrao do sistema com certo propsito, como descrever aspectos estruturais ou comportamentais do software. Esse propsito determina o que deve ser includo no modelo e o que considerado irrelevante. Assim, um modelo descreve completamente aqueles aspectos do sistema fsico que so relevantes ao propsito do modelo em um nvel apropriado de detalhe.

Um modelo de software define semntica e notao: informao semntica: descreve o significado ou inteno do sistema; notao: apresentao visual, mostram o modelo de forma facilmente compreensvel e

podem ser apresentados de vrias formas, incluindo texto e diagramas.

Vises de um modelo de Software:

Diferentes pontos de vista devem ser usados para refletir os aspectos desejados.Cada viso mostra um conjunto de aspectos do sistema numa notao adequada sua

compreenso.

A arquitetura de um sistema pode ser refletida em cinco vises distintas:

Figura 2Fonte: Professor Alexandre Atanes

11


Possibilitando aos desenvolvedores analisar o sistema de diferentes perspectivas, so pro-postas as seguintes vises:

Viso de Casos de Uso: descreve o sistema de um ponto de vista externo como um conjunto de interaes entre o sistema e os agentes externos do sistema.

Viso de projeto: enfatiza as caractersticas do sistema.

Viso de implementao: abrange o gerenciamento de verses do sistema.

Viso de implantao: corresponde distribuio fsica do sistema em seus sub-sistemas e conexo entre essas partes.

Viso de processos: enfatiza as caractersticas de concorrncia, sincronismo e de-sempenho do sistema.

PArADIgMA DA OrIentAO A ObJetOS.

O paradigma da orientao a objetos visualiza um sistema de software como uma coleo de agentes interconectados chamados de objetos. Cada objeto responsvel por realizar tarefas especificas. atravs da interao entre objetos que uma tarefa computacional realizada. Sendo uma tcnica para a modelagem que diminui a diferena semntica entre a realidade sendo mod-elada e os modelos construdos.

A orientao a objetos tem sua origem nos anos 60, na Noruega, com Kristen Nygaard e Ole-Johan Dahl, no Centro Noruegus de Computao. Atravs da linguagem Simula 67, foram introduzidos os conceitos de classe e herana.

A orientao a objetos passou a ser mais conceituada e elaborada nos laboratrios da Xe-rox, em Palo Alto, sendo refinada numa sequncia de prottipos da linguagem Smalltalk. O lder desse projeto foi Alan Curtis Kay, considerado um dos criadores do termo programao orien-tada a objetos.

Alan Key estabeleceu alguns princpios bsicos relacionados programao orientada a objetos como:

Qualquer coisa um objeto. Objetos realizam tarefas atravs da requisio de servios a outros objetos. Cada objeto pertence a uma determinada classe. A classe um repositrio para o comportamento associado ao objeto. Classes so organizadas em hierarquia.

ClASSeS e ObJetOS

O mundo real formado por coisas, como carros, pessoas, vendas, casas, etc. Na termino-logia orientada a objetos essas coisas do mundo real so chamadas de objetos. Seres humanos costumam agrupar os objetos. Este processo mental de agrupamento ajuda a gerenciar a com-plexidade de entender as coisas do mundo real. muito fcil entender a ideia de um carro in-dependente das suas variaes e modelos. Na terminologia da orientao a objetos cada ideia denominada classe de objetos ou simplesmente classe. Uma classe uma descrio dos atributos e servios comuns a um grupo de objetos, entende-se uma classe como sendo o molde do qual os objetos so construdos. Nesta terminologia ainda diz-se que um objeto uma instncia de uma classe.


12

A programao Orientada a Objetos traz alguns conceitos importantes como:

MensagensPara que uma operao em um objeto seja executada deve haver um estmulo enviado a esse objeto. Independentemente da origem do estmulo, quando ele ocorre, diz-se que o objeto em questo est recebendo uma mensagem requisi-tando que ele realize alguma operao.

EncapsulamentoObjetos possuem comportamentos. O termo comportamento diz respeito a oper-aes realizadas por um objeto e tambm ao modo pelo qual essas operaes so executadas. O Mecanismo de encapsulamento uma forma de restringir o acesso ao comportamento do objeto. Quando um objeto faz uma requisio a outro ob-jeto ele no precisa saber como o objeto realizar a operao. Ele s precisa saber que o objeto capaz de fazer determinada requisio e ele ser capaz de saber atravs da interface do objeto que diz apenas o que o objeto capaz de fazer, sem dizer como.

Polimorfismo caracterizado quando duas ou mais classes distintas tm mtodos de mesmo nome, de forma que uma funo possa utilizar um objeto de qualquer uma das classes polimrficas, sem necessidade de tratar de forma diferenciada conforme a classe do objeto.

HeranaNa herana, classes semelhantes so agrupadas em hierarquias. Cada classe em um nvel de hierarquia herda as caractersticas das classes nos nveis acima. Esse mecanismo facilita o compartilhamento de comportamento comum entre um con-junto de classes semelhantes.

A MODelAgeM OrIentADA A ObJetOS.

A essncia do desenvolvimento baseado em objetos a identificao e a organizao de conceitos do domnio da aplicao, em vez de sua representao em uma linguagem de pro-gramao.

A viso orientada a objetos evoluiu mais facilmente, pois somos incentivados a usar classes para representar coisas do nosso dia a dia.

Na viso da Orientao a Objetos, o principal bloco de construo de todos os sistemas de softwares o objeto ou a classe, sendo que uma classe a descrio de um conjunto de objetos comuns.

Todos os objetos tm uma identidade (um nome), um estado (normalmente ele possui dados associados a ele) e um comportamento (podemos fazer algo com ele ou ele poder fazer algo com outros objetos).

13


Algumas observaes importantes sobre Modelagem:

A escolha dos modelos a serem criados tem profunda influncia sobre a maneira como um determinado problema atacado e como uma soluo definida;

Cada modelo poder ser expresso em diferentes nveis de preciso; Os melhores modelos so relacionados realidade; Nenhum modelo nico suficiente. Qualquer sistema no trivial ser mais bem investi-

gado por meio de um pequeno conjunto de modelos quase independentes com vrios pontos de vista.

A uML (UnIfIeD MODelIng lAngUAge).

De acordo com o prefcio do livro UML Guia do Usurio, da editora Elsevier, a Linguagem Unificada de Modelagem (UML) uma linguagem grfica para visualizao, especificao, con-struo e documentao de artefatos de sistemas complexos de software. A UML proporciona uma forma padro para a preparao de planos de arquitetura de projetos de sistemas, incluindo aspectos conceituais tais como processos de negcios e funes do sistema, alm de itens con-cretos como as classes escritas em determinada linguagem de programao, esquemas de banco de dados e componentes de softwares reutilizveis.

Figura 3 Fonte: Internet nerdson.com

A UML surgiu da fuso de trs grandes mtodos, do BOOCH, OMT (Rumbaugh) e OOSE (Jacobson). Esta linguagem de modelagem no proprietria de terceira gerao no um mtodo de desenvolvimento. Tem como papel principal auxiliar na visualizao do desenho e na comuni-cao dos objetos. Ela permite que desenvolvedores visualizem os produtos de seu trabalho em diagramas padronizados e muito usada para criar modelos de sistemas de software.

Alm de fornecer a tecnologia necessria para apoiar a prtica de engenharia de software orientada a objetos, a UML poder ser a linguagem de modelagem padro para modelar sistemas


14

concorrentes e distribudos. Utiliza-se de um conjunto de tcnicas de notao grfica para criar modelos visuais de software de sistemas intensivos, combinando as melhores tcnicas de modela-gem de dados, negcios, objetos e componentes. uma linguagem de modelagem nica, comum e amplamente utilizvel.

Embora com a UML seja possvel representar o software atravs de modelos orientados a objetos, ela no demonstra que tipo de trabalho deve ser feito, ou seja, no possui um processo que define como o trabalho tem que ser desenvolvido. O objetivo ento descrever o que fazer, como fazer, quando fazer e porque deve ser feito. necessria a elaborao completa de um dicionrio de dados, para descrever todas as entidades envolvidas, refinando, com isso, os requisitos funcionais do software.

A Linguagem Unificada de Modelagem possui diagramas (representaes grficas do mod-elo parcial de um sistema) que so usados em combinao, com a finalidade de obter todas as vises e aspectos do sistema.

MODelOS, VISeS e DIAgrAMAS DA UMl

Para permitir a aplicao e utilizao da UML em todas as fases do projeto e para possibilitar que todos os diferentes pontos de vista dos especialistas envolvidos no projeto estejam contem-plados no projeto, a UML possui vrios diagramas diferentes!

A imagem abaixo mostra uma parte desses diagramas:

Figura 4Fonte: Internet

15


Os Diagramas da UML esto divididos em:

Diagramas Estruturais

De Classe: este diagrama fundamental e o mais utilizado na UML e serve de apoio aos outros diagramas. O Diagrama de Classe mostra o conjunto de classes com seus atributos e mtodos e os relacionamentos entre classes.De Objeto: o diagrama de objeto esta relacionado com o diagrama de classes e praticamente um complemento dele. Fornece uma viso dos valores armaze-nados pelos objetos de um Diagrama de Classe em um determinado momento da execuo do processo do software.De Componentes: est associado linguagem de programao e tem por fi-nalidade indicar os componentes do software e seus relacionamentos.De implantao: determina as necessidades de hardware e caractersticas fsi-cas do Sistema.De Pacotes: representa os subsistemas englobados de forma a determinar par-tes que o compem.De Estrutura: descreve a estrutura interna de um classificador.

Diagramas Comportamentais

De Caso de uso (Use Case): geral e informal para fases de levantamento e anlise de Requisitos do Sistema.De Mquina de Estados: procura acompanhar as mudanas sofridas por um objeto dentro de um processo.De Atividades: descreve os passos a serem percorridos para a concluso de uma atividade.De Interao: dividem-se em:

De Sequncia: descreve a ordem temporal em que as mensagens so trocadas entre os objetos.Geral interao: variao dos diagramas de atividades que fornece viso geral dentro do sistema ou processo do negcio.De comunicao: associado ao diagrama de Sequncia, comple-mentando-o e concentrando-se em como os objetos esto vinculados.De tempo: descreve a mudana de estado ou condio de uma instn-cia de uma classe ou seu papel durante o tempo.

OS PrInCIPAIS DIAgrAMAS DA UMl

a) Diagrama de Casos de uso (use Cases)

O Diagrama de Casos de Uso tem o objetivo de auxiliar a comunicao entre os analistas e o cliente.

Um diagrama de Caso de Uso descreve um cenrio que mostra as funcionalidades do siste-ma do ponto de vista do usurio.


16

O cliente deve ver no diagrama de Casos de Uso as principais funcionalidades de seu sistema.O diagrama de Caso de Uso representado por:

atores; casos de uso; relacionamentos entre estes elementos.

Estes relacionamentos podem ser:

associaes entre atores e casos de uso; generalizaes entre os atores; generalizaes, extends e includes entre os casos de uso.

Exemplos:

Figura 5 Fonte: Internet

b) Diagrama de Classes

Exibe um conjunto de classes, interfaces e colaboraes, bem como seus relacionamentos. Esses diagramas so encontrados com maior frequncia em sistemas de modelagem orientados a objetos e abrangem uma viso esttica da estrutura do sistema.

Exemplos:


17


c) Diagrama de Objetos

Exibe um conjunto de objetos e seus relacionamentos. Representa retratos estticos de in-stncias de itens encontrados no diagrama de classes sob uma perspectiva de casos reais ou de prottipos.

Exemplos:


d) Diagrama de Sequncia

Tem por objetivo descrever as comunicaes necessrias entre objetos para a realizao dos processos em um sistema computacional. Os diagramas de sequncia tem este nome porque descrevem ao longo de uma linha de tempo a sequncia de comunicaes entre objetos.

Exemplo:



18

Referncias

BOEHM, Barry. Software Engineering Economics. Prentice-Hall, 1981.

GUEDES, Gilleanes T. A. uML 2: uma abordagem prtica, 2. ed. So Paulo: Novatec, 2011.

PRESSMAN, Roger S. Engenharia de Software. 6. ed. Rio de Janeiro: McGrawHill, 2006.

SOMMERVILLE, Ian. Engenharia de Software. 9. ed. So Paulo: Pearson Addison Wesley, 2011.

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

19



20

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

________________________________________

__________________________________________

_________________________________________

________________________________________

________________________________________

_________________________________________

_________________________________________

________________________________________

________________________________________

________________________________________

________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

_________________________________________

________________________________________

__________________________________________

Objetivos:

Apresentar conceitos detalhados de mode-lagem de banco de dados, teoria relacional e

do projeto de banco de dados. Tambm sero apresentados conceitos de modelagem conceitual e lgica de banco de dados,

a partir de requisitos.

Palavras-chave:

Modelo lgico; modelo conceitual; teoria relacional; projeto de banco de dados; banco de dados; entidade; relacionamento; atributo;

cardinalidade.

Modelagem de Banco de Dados

Prof. esp. Durval de Oliveira Dorta Junior

Mdulo



IntrODUOUm dos principais propsitos da tecnologia da informao automatizar processos existen-

tes ou, no caso de processos de alta complexidade, possibilitar a existncia deles. Para atingir este objetivo so desenvolvidos os sistemas de informao. A modelagem de banco de dados um fator importante no desenvolvimento destas solues, considerando que todo processo utiliza e tambm pode criar dados.

Para ilustrar, vamos analisar um ambiente de negcios tpico, em que constatamos a exis-tncia de vrios departamentos de diferentes reas de atuao. Independentemente do nome destes departamentos podemos afirmar que eles so responsveis pelos processos de negcios, por exemplo, Vendas, Compras, Contabilidade, Produo e outros tantos. Estes processos de uma empresa produzem e/ou utilizam dados para desempenhar o seu papel. Por exemplo, no mnimo, o processo de vendas manipula dados dos clientes, dos pedidos e dos produtos, ento podemos afirmar que o sistema Vendas o conjunto dos processos automatizados por programas de com-putador e os dados criados ou alterados por estes.

Conclumos que o conjunto de dados utilizados pelos processos um componente impres-cindvel para o projeto de sistemas. Ao conjunto destes dados armazenados damos o nome de Banco de Dados.

A definio de Banco de dados : Conjunto de dados integrados que tem por objetivo aten-der a uma comunidade de usurios (HEUSER, 2009).

A forma como armazenamos estes dados tem se desenvolvido desde o incio da era da in-formao, criando uma nova rea de conhecimento, que chamamos de Modelagem de Banco de Dados. O seu propsito o estudo das metodologias utilizadas na descrio formal dos tipos de dados que esto armazenados em um banco de dados. A esta descrio chamamos de Modelo de Banco de Dados.

O modelo de dados amplamente utilizado modelo de dados relacional. Por este motivo, o nosso estudo ser focado neste tipo de modelo.

O MODelO De DADOS relACIOnAlO modelo de dados relacional foi introduzido inicialmente por Ted Codd, na poca fun-

cionrio da IBM no ano de 1970, por meio de seu artigo clssico (CODD, 1970; CHEN, 1976) que atraiu grande ateno imediata devido a sua simplicidade e base matemtica. Sua base terica reside na teoria de conjuntos e lgica de predicado de primeira ordem.

O modelo relacional representa o banco de dados como uma reunio de relaes. Cada relao semelhante a uma tabela de valores, ou seja, esta tabela composta de cabealhos de colunas que representam o nome dos dados. Cada uma destas colunas possuem valores, que so os dados, e cada linha desta tabela representa uma ocorrncia da tabela.

Formalmente, os nomes no modelo relacional so os seguintes: a linha chamada Tupla, um cabealho da coluna chamado de Atributo, os valores dos dados na coluna chamado de Domnio e a tabela chamada de Relao.


22

Veja o exemplo abaixo:

Nome CPF Celular Rua Nmero CEP Cidade uF

Joo S. Rios 306.610.243-51 9995-3535 Consolao 2019 09000-430 So Paulo SP

Paula R. Santos 381.620.124-45 8476-9821 Jardim 300 01415-300 So Paulo SP

Barbara Passos 533.690.123-80 NULL Goiabeiras 230 03445-212 So Paulo SP

No modelo de dados relacional, a integrao dos dados vai alm dos atributos agrupados em uma relao, apresentando o relacionamento entre estas relaes. Por exemplo, em uma empresa, em que todo funcionrio trabalha em um departamento, e lembrando que departa-mento outra relao de dados, necessrio representar a informao associando corretamente cada funcionrio ao nico departamento no qual ele trabalha. Esta informao que caracteriza a associao entre as relaes tratada no modelo relacional com o nome de Relacionamento. A representao do conjunto das relaes e de seus relacionamentos chamamos de Esquema de Banco de Dados.

Veja um exemplo de um Diagrama de Esquema de Banco de Dados:

Na figura 2, acima, destaca-se:

Figura 1

Note, neste exemplo, cada coluna um Atributo e cada linha uma Tupla que representa uma ocorrncia da Relao Funcionrio, ou seja, cada Tupla um Funcionrio diferente e, tambm, chamada de uma Ocorrncia da Relao.

Atributos

Tuplas

Nome da Relao

fUnCIOnrIO

A relao que retrata o Funcionrio participa de dois relacionamentos, um com o Departamento ao qual este funcionrio pertence e o outro com a Alocao de suas horas em projetos.

23


A relao Alocao registra as horas que cada funcionrio dedica a um determina-do projeto, e se relaciona com o funcionrio e o projeto para a devida associao do Funcionrio com cada Projeto dos vrios que ele pode trabalhar.

Alm dos valores de dados que cada relao armazena (nome, horas, departa-mento, etc.) o relacionamento entre estas relaes tambm uma informao ge-rada, ou seja, com o relacionamento sabemos a qual departamento o funcionrio pertence e em qual projeto ou projetos trabalha.

PrOJetO De bAnCO De DADOS

O projeto de banco de dados envolve trs fases, descritas a seguir (HEUSER, 2009):

Modelagem Conceitual

a primeira fase. construdo um modelo conceitual na forma de um diagrama entidade-relacionamento, comumente chamado de DER. Este modelo captura as necessidades da organizao em termos de armazenamento de dados e as regras de negcio.

Modelo Lgico

A segunda etapa, tambm chamada de projeto lgico, quando se transforma o modelo conceitual da primeira fase em um modelo lgico. O modelo lgi-co define como o banco de dados ser implementado em um SGBD especfico. Lembrando que o SGBD, o software que gerencia o banco de dados, sua sigla significa Sistema Gerenciador de Banco de dados.

Projeto fsico

Terceira e ltima etapa do projeto de Banco de Dados, o modelo do banco de da-dos transcrito para um script na linguagem SQL e, tambm, enriquecido com detalhes que influenciam no desempenho do banco de dados, mas no interferem em sua funcionalidade. O modelo obtido neste passo o modelo fsico do banco de dados pronto para ser usado no SGDB a fim de se criar o Banco de Dados.

MODelAgeM COnCeItUAl

A modelagem conceitual independente do SGDB a ser utilizado e utilizaremos a aborda-gem Entidade-Relacionamento (E-R), que no contm aspectos tcnicos que poderiam se rela-cionar a um SGDB especfico. O objetivo da utilizao deste tipo de modelagem permitir um foco na captura de necessidades do usurio e suas regras de negcio. O resultado um modelo grfico chamado de Diagrama Entidade-Relacionamento ou mais comumente chamado DER ou MER (Modelo E-R), que por ser uma representao grfica sem detalhes tcnicos facilmente usada tambm na validao com o usurio ou usurios que forneceram as necessidades e regras de negcio.


24

A figura abaixo um exemplo do Diagrama Entidade-Relacionamento (DER):

Figura 3

A seguir, abordaremos cada componente desta tcnica, que foi criada em 1976 por Peter Chen (CHEN, 1976), podendo ser considerada como um padro de fato para a modelagem con-ceitual. Mesmo as tcnicas de modelagem orientada a objetos, que tm surgido nos ltimos anos, como a UML, baseiam-se nos conceitos da abordagem ER (HEUSER, 2009).

PrInCIPAIS eleMentOS DA AbOrDAgeM entIDADe-relACIOnAMentO

entIDADeA entidade um conceito fundamental da abordagem E-R. Segundo Heuser (2009), a enti-

dade o conjunto de objetos da realidade modelada sobre os quais deseja-se manter informaes no banco de dados. Importante observar que, neste texto, o termo objeto possui a conotao que lhe dada na linguagem natural, de coisa, tudo que perceptvel ou manipulvel. No fala-remos, neste texto, do termo objeto como ele usado na Teoria de programao de Orientao a Objetos.

Uma entidade representa um conjunto de objetos da realidade modelada. Como o objetivo de um modelo ER modelar de forma abstrata um BD, interessam-nos somente os objetos sobre os quais deseja-se manter informaes. Por exemplo, em um sistema de informaes para con-trolar os processos de uma escola, alguns exemplos de entidades poderiam ser Alunos, Cursos, Turmas, Avaliaes, Disciplinas e Professores. J em um sistema para controlar os processos de contas a pagar, algumas entidades podem ser os Fornecedores, Boletos, Notas fiscais e Bancos, entre outras.

25


A entidade representada atravs de um retngulo, que contm o nome da entidade. Al-guns exemplos so mostrados abaixo:

Cada retngulo, que cada entidade, representa um conjunto de objetos sobre os quais deseja-se guardar informaes. Assim, no exemplo da Figura 4, o primeiro retngulo designa o conjunto de todos os funcionrios sobre os quais se deseja manter informaes no banco de dados, enquanto o segundo retngulo designa o conjunto de todos os projetos sobre os quais se deseja manter informaes. Caso seja necessrio referir-se a um objeto particular (um deter-minado funcionrio ou um determinado departamento) fala-se em ocorrncia de entidade ou instncia de entidade.

Da forma como est apresentada, o modelo da Figura 4 indica apenas quais os conjuntos de objetos sobre os quais deseja-se manter informaes, mas no quais as informaes que devem ser mantidas para cada objeto. Estas informaes so definidas pelas propriedades das entidades, dadas pelos relacionamentos, atributos e generalizaes/especializaes.

AtrIbUtOO conceito de atributo serve para associar informaes a ocorrncias de entidades ou de re-

lacionamentos. O atributo o elemento que representa um determinado dado de uma ocorrncia de uma entidade ou de um relacionamento.

O atributo pode ser de diferentes tipos.

Um atributo simples tem a seguinte representao:

Nesta figura, acima, nota-se que os atributos cdigo e tipo esto associados por meio de uma linha ligando o crculo que representa o atributo a uma entidade.

Figura 5

Figura 4


26

AtrIbUtO IDentIfICADOr Uma condio que toda entidade possua uma identificao demostrando que cada enti-

dade nica, por exemplo, a entidade projeto, na figura 5, tem o atributo cdigo associado a ela para identificar que um projeto diferente do outro. Este tipo de atributo chamado de atributo identificador com o seu crculo preenchido.

relACIOnAMentOUma das propriedades sobre as quais pode ser desejvel manter informaes a associao

entre objetos. Exemplificando, em um sistema de contas a pagar importante saber-se a qual fornecedor se associa um boleto a ser pago. A propriedade de entidade que especifica as associa-es entre objetos o relacionamento.

O relacionamento associa as ocorrncias de uma entidade outra entidade, conforme co-mentado no pargrafo anterior, por exemplo, cada boleto, que uma ocorrncia da entidade bo-leto, estar associado a um fornecedor especfico que, por sua vez, uma ocorrncia da entidade fornecedor.

O relacionamento representado por um losango, ligado por linhas aos retngulos, que representam as entidades que participam do relacionamento.

A figura 6, a seguir, representa o relacionamento comentado anteriormente:

Neste modelo, vemos que o Fornecedor se associa ao Boleto pelo relacionamento Emite, ou seja, o fornecedor que emite o boleto para pagamento.

Este modelo expressa que o BD mantm informaes sobre:

um conjunto de objetos classificados como Fornecedores (entidade FORNECEDOR);

um conjunto de objetos classificados como Boletos (entidade BOLETO); e

um conjunto de associaes, cada uma ligando um Fornecedor a cada Boleto emi-tido por ele (relacionamento EMITE);

Note os atributos, de fato sem eles a entidade no corretamente representada, pois os dados residem nos atributos da entidade.

Figura 6

27


Quando nos referirmos a associaes especficas em um relacionamento, vamos nos referir a ocorrncias ou instncias de relacionamentos. No caso do relacionamento EMITE, uma ocorrn-cia seria um par especfico, formado por uma determinada ocorrncia da entidade FORNECEDOR e por uma determinada ocorrncia da entidade BOLETO.

Para fins didticos, vamos utilizar um diagrama de ocorrncias (HEUSER, 2009), apresenta-do na Figura 7.

Este diagrama refere-se ao Diagrama ER da Figura 6.

Em um diagrama de ocorrncias, ocorrncias de entidades so representadas por crculos brancos e ocorrncias de relacionamentos por crculos negros. As ocorrncias de entidade partici-pantes de uma ocorrncia de relacionamento so indicadas pelas linhas que ligam o crculo negro representativo da ocorrncia de relacionamento aos crculos brancos representativos das ocorrn-cias de entidades relacionadas. Assim, a Figura acima representa que, entre outras, h uma ocor-rncia de EMITE que liga o fornecedor f1 com o boleto b1. Observe-se que, na forma como est, o modelo da Figura acima no informa quantas vezes uma entidade associada atravs de um relacionamento (veremos como isso pode ser representado mais adiante). O modelo apresentado permite que uma ocorrncia de entidade (por exemplo, o fornecedor f4) no esteja associada a alguma ocorrncia de entidade atravs do relacionamento, e que uma ocorrncia de entidade (por exemplo, o boleto b3) esteja associada a exatamente uma ocorrncia de entidade atravs do relacionamento ou, ainda, que uma ocorrncia de entidade fornecedor (por exemplo, o forncedor f1) esteja associada a mais de uma ocorrncia de entidade boleto atravs do relacionamento.

AUtOrrelACIOnAMentONo obrigatrio um relacionamento associar-se a ocorrncias de entidades diferentes. A

Figura abaixo mostra um DER de um autorrelacionamento, isto , um relacionamento entre ocor-rncias de uma mesma entidade. Neste caso, necessrio um conceito adicional, o de papel da entidade no relacionamento.


28

No caso do relacionamento de superviso, os funcionrios so supervisionados por um chefe que, por sua vez, tambm um funcionrio, uma ocorrncia de funcionrio exerce o papel de chefe e a outra ocorrncia de pessoa exerce o papel de supordinado. Papis so anotados no DER como mostrado na Figura 8. No caso de relacionamentos entre entidades diferentes, como o de FORNECEDOR EMITE BOLETO mostrado na Figura 6 anteriormente, no necessrio indicar os papis das entidades, j que eles so bvios.

A Figura 9 apresenta um diagrama de ocorrncias para o Modelo ER da Figura 8. Observe os papis de chefe e subordinado das ocorrncias da entidade Funcionrio, em cada ocorrncia de relacionamento as linhas que ligam os crculos representativos das ocorrncias Chefecom as ocorrncias representativas de Subordinado.

Figura 8

Figura 9

No diagrama da figura 9, notamos que a relao de superviso para as ocorrncias a se-guinte:

Funcionrio f4 chefe do funcionrio f5 que , por consequncia, subordinado ao f4;

Funcionrio f5 chefe do funcionrio f3 que , por consequncia, subordinado ao f5;

Funcionrio f3 chefe dos funcionrios f1 e f2 que so, por consequncia, subordinados ao f3.

O motivo de se usar a mesma entidade para caracterizar os papis que partimos do princ-pio de que todos so funcionrios. O atributo cargo da entidade cumpre o papel de diferenciao entre os diferentes cargos existentes. O aluno poder pensar em criar uma entidade diferente para

29


cada cargo, mas esta soluo fraca, pois a cada novo cargo ou nvel hierrquico criado haveria a necessidade de alterar fisicamente o banco de dados, o que tornaria o sistema pouco prtico. Tambm existem outros motivos relacionados performance e integridade da informao que tornam a soluo do autorrelacionamento a melhor para o requisito de diferentes papis exerci-dos por uma mesma entidade.

CArDInAlIDADeO conceito de cardinalidade de grande importncia para a modelagem de banco de dados.

Para fins de projeto de banco de dados, a cardinalidade uma caracterstica do relacionamento.

A cardinalidade qualifica quantas ocorrncias de uma entidade se relacionam com as ocor-rncias da entidade a qual est associada no relacionamento. traduziada pela anotao do n-mero mnimo e mximo de ocorrncias relacionadas entre as entidades.

As cardinalidades possveis so as seguintes:

- (0,1) L-se no mnimo Zero ocorrncia e no mximo Uma ocorrncia;

- (1,1) L-se no mnimo Uma ocorrncia e no mximo Uma ocorrncia;

- (0,n) L-se no mnimo Zero ocorrncia e no mximo vrias ocorrncias;

- (1,n) L-se no mnimo Uma ocorrncia e no mximo vrias ocorrncias;

- (n,n) ou (n,m) L-se no mnimo Vrias ocorrncias e no mximo Vrias ou Muitas ocorrncias, (n,n) e (n,m) so equivalentes e tm o mesmo significado. Importante res-saltar que este tipo de cardinalidade existe somente no modelo conceitual e no estar presente no modelo lgico, as demais persistem no modelo lgico.

Agora, vamos para um exemplo prtico, vamos modelar os seguintes requisitos:

Uma empresa composta de empregados que so organizados em departamen-tos no qual trabalham com atividades de uma rea especfica, por exemplo, finanas, vendas, oficina e assim por diante.

Todo empregado trabalha em um nico departamento.

Todo departamento composto de, no mnimo, um empregado.

Departamento pode ter mais de um empregado.

O modelo abaixo atende a estes requisitos:

Figura 10


30

A figura 10 um Diagrama ER, ou seja, um Modelo ER, contendo o relacionamento e as entidades Empregado trabalha no Departamento. Agora, para melhor entendimento da quanti-dade de ocorrncias que se relacionam entre uma entidade e a outra, vamos analisar o Diagrama de Ocorrncias:

No diagrama de ocorrncias da figura 11, podemos analisar os seguintes requisitos:

Figura 11

Todo Empregado trabalha para um departamento e somente um departamento. Neste caso, sabemos que cada ocorrncia da entidade Empregado se relaciona com no m-nimo uma ocorrncia da entidade Departamento e tambm que cada ocorrncia da entidade Empregado se relaciona com mximo uma ocorrncia da entidade Departa-mento.

Todo Departamento composto de um ou mais empregados. Neste caso, sabemos que cada ocorrncia da entidade Departamento se relaciona com no mnimo uma ocorrn-cia da entidade Empregado e tambm que cada ocorrncia da entidade Departamento se relaciona com no mximo vrias ocorrncias da entidade Empregado.

O Modelo ER correspondente aos requisitos acima com as suas cardinalidades representa-das, o seguinte:

31


Na Figura 12, note os nmeros entre parnteses. O primeiro nmero a cardinalidade m-nima e o segundo a mxima. Ao lado da entidade Empregado est a sua cardinalidade (1,N) e o mesmo ocorre com o departamento com a sua cardinalidade (1,1) no relacionamento Trabalha.

A cardinalidade caracterstica de todo relacionamento e sempre haver a indicao da cardinalidade mnima e mxima para cada extremo do relacionamento.

Neste exemplo acima, l-se, cada ocorrncia da entidade Empregado est relacionada com no mnimo uma e no mximo uma ocorrncia da entidade Departamento, e cada ocorrncia en-tidade Departamento est relacionada com no mnimo uma e no mximo vrias ocorrncias da entidade Empregado.

tIPOS De relACIOnAMentO

Os relacionamentos so classificados quanto a sua cardinalidade mxima nos seguintes tipos de relacionamento:

Figura 12

Relacionamento 1:1 ou Relacionamento Um para Um;

Relacionamento 1:n ou Relacionamento Um para Vrios;

Relacionamento n:n (ou n:m) ou Relacionamento Vrios para Vrios ou Vrios para Muitos. As anotaes n:n e n:m so equivalentes e tm o mesmo significado. Importante ressaltar que este tipo de relacionamento existe somente no modelo conceitual e no estar presente no modelo lgico, os demais persistem no mo-delo lgico.


32

A seguir, so apresentados os exemplos dos tipos de Relacionamentos:

Relacionamento 1:1 ou Relacionamento Um para Um

Para entender este relacionamento, sua cardinalidade e tipo, vamos primeiro entender seus requisitos:

- A pessoa pode estar Viva ou Morta, sendo assim pode No ter um Atestado de bito. Por este motivo, a cardinalidade mnima no atestado Zero e somente um atestado pode existir por pessoa quando esta falecer;

- Todo atestado de bito, quando existir, est relacionado a somente uma pessoa no mni-mo e no mximo.

O tipo de relacionamento aqui apresentando do tipo um para um. Note que a cardinalida-de mxima de ambos os extremos do relacionamento denotam esta caracterstica.

Relacionamento 1:n ou Relacionamento Um para Vrios

Figura 14

Figura 13

Este relacionamento da figura 14 atende aos seguintes requisitos:

- O curso pode ter no mnimo nenhum aluno matriculado e no mximo vrios alunos ma-triculados.

- O Aluno para ser aluno deve estar matriculado no mnimo em um curso e em mais ne-nhum outro.

O tipo de relacionamento aqui apresentando do tipo um para vrios. Note que a cardina-lidade mxima de ambos os extremos do relacionamento denotam esta caracterstica.

33


Mais um exemplo deste tipo de relacionamento, agora analisando um exemplo de autor-relacionamento apresentado anteriormente na figura 8 e representado na figura abaixo com as suas cardinalidades:

O relacionamento da figura 15 atende aos seguintes requisitos:

- O funcionrio possui no mnimo nenhum e no mximo vrios funcionrios como subordinados, a cardinalidade mnima igual a zero representa o caso do assistente que no possui Subordinados.

- O funcionrio responde a no mnimo nenhum e no mximo a nico Chefe. Neste caso, a cardinalidade mnima igual a Zero para contemplar ao requisito que h funcionrios que no possuem Chefe, por exemplo, o presidente da empresa no possui Chefe.

O tipo de relacionamento aqui apresentando do tipo um para vrios. Note que a cardina-lidade mxima de ambos os extremos do relacionamento denotam esta caracterstica.

Relacionamento n:n ou Relacionamento Vrios para Vrios

(ou tambm chamado Vrios para Muitos).

Figura 15

Figura 16


34

Este relacionamento da figura 16 representa aos seguintes requisitos:

- O Empregado pode estar alocado ou no em um ou mais projetos;

- O projeto para existir deve ter alocado para ele, um Empregado, e tambm pode ter alo-cado vrios Empregados.

O tipo de relacionamento aqui apresentando do tipo vrios para vrios muitas vezes cha-mado, tambm, de vrios para muitos ou, ainda, muitos para muitos. Note que a cardinalidade mxima de ambos os extremos do relacionamento denotam esta caracterstica.

AtrIbUtO ASSOCIADO A UM relACIOnAMentOUma novidade neste relacionamento da figura 16 o atributo associado a um relacio-

namento. Assim como entidades os relacionamentos podem possuir atributos. No exemplo da figura 16, o atributo Horas Alocadas tem o objetivo de registrar a quantidade de horas que o funcionrio dedicar a cada um dos projetos que pode participar.

Podemos, tambm, alternativamente representar este tipo de relacionamento Vrios para Vrios com dois relacionamentos Um para Vrios, com a mesma funo no Modelo ER, ,alis, esta ser a soluo a ser empregada no modelo lgico que logo mais veremos.

AtrIbUtO MUltIVAlOrADOO Atributo multivalorado representa a informao que ocorre mais de uma vez para uma

mesma entidade.

Analisando o modelo ER acima, conclumos que o Empregado pode ter nenhum, um ou mais telefones, por exemplo, pode ter o telefone residencial e dois telefones Celulares ou mesmo pode no ter telefones. No exemplo da figura 17, este requisito esta representado pela cardinali-dade atribuda ao atributo Telefone, em que podemos ler que o atributo telefone pode no mnimo no existir e no mximo existir vrias vezes para um mesmo Empregado.

AtrIbUtO DerIVADOO Atributo derivado representa a informao que obtida por clculo a partir de outro atri-

buto, o atributo derivado meramente informativo no modelo e no existir no modelo lgico.

Figura 17

35


Neste modelo ER, acima, o atributo idade representado por linhas pontilhadas denotando que este atributo do tipo atributo derivado, o motivo que a idade uma informao obtida por um clculo a partir da informao da data de nascimento e por este motivo o atributo deri-vado idade est ligado ao atributo data de nascimento. Os atributos derivados no constaro no modelo lgico, porque realmente no so armazenados. A sua representao no modelo ER tem por finalidade ajudar ao desenvolvedor, mostrando qual a informao que ser obtida. Neste caso do exemplo da figura 18, o modelo indica que o desenvolvedor dever fazer um clculo com a informao do atributo Data de Nascimento para obter a idade.

AtrIbUtO COMPOStOO Atributo Composto representa a informao agrupada, ou seja, este tipo de atributo

composto por outros atributos.

Figura 18

Figura 19

Na figura 19, apresentando o modelo ER com o atributo Endereo do tipo composto. Todo atributo composto tem em sua estrutura outros ligados a ele. Neste caso, o endereo composto pelos atributos Rua, Nmero, Cidade, Estado e CEP.


36

generAlIZAO e eSPeCIAlIZAOUtilizamos o recurso de generalizao e es-

pecializao quando h subtipos relevantes a se-rem modelados. Com este recurso podemos atri-buir propriedades particulares a um subgrupo de ocorrncias de uma mesma entidade.

MODelO er, DIAgrAMA erAmbos so sinnimos, o Modelo Entidade

Relacionamento (MER) e o Diagrama Entidade Re-lacionamento (DER). comum referir- se com mais frequncia utilizando a abreviatura DER.

eXeMPlO PrtICOO DER da figura abaixo um modelo proposto para um sistema que controla o cadastro de

funcionrios, seus dependentes, departamentos, e os projetos em que os funcionrios trabalham.

Figura 21

Figura 20

37


No DER apresentado na figura 21 podemos verificar vrios conceitos apresentados anterior-mente, agora consolidados em nico DER.

entIDADe frACA chamada de entidade fraca quando no relacionamento a sua cardinalidade mnima Zero,

ou seja, ela opcional no relacionamento. No exemplo da figura 21, observamos uma entidade fraca no relacionamento Empregado Possui Dependente. Neste caso, a entidade fraca Depen-dente, pois para uma ocorrncia de Empregado existir no necessrio existir uma ocorrncia de Dependente, mas para Dependente existir necessrio que exista uma ocorrncia de Empregado. A entidade fraca tambm chamada de entidade opcional.

Tambm pode ser utilizada a opo de representar a entidade fraca no somente pela sua cardinalidade, mas tambm por uma linha mais larga do seu lado do relacionamento.

PrOPrIeDADeS releVAnteS nA MODelAgeM er importante considerar algumas propriedades relevantes na fase de modelagem conceitual

(HEUSER, 2009):

Um modelo ER um modelo formal:

Um modelo ER um modelo formal, preciso, no ambguo. Em outras palavras, diferentes pessoas lendo o mesmo modelo ER devem entender exatamente o mesmo significado.

Modelos ER tm poder de expresso limitado:

Em um modelo ER esto registradas apenas algumas propriedades de um banco de dados, h mais elementos importantes para o projeto do ban-co de dados, principalmente relevantes para a implementao fsica, tais como, restries de integridade entre outras.

Diferentes modelos podem ser equivalentes:

Considerando a finalidade do projeto de banco de dados, dois modelos ER so equivalentes quando ambos geram o mesmo esquema de banco de dados.

COnSIDerAeS SObre O ASPeCtO teMPOrAl DA InfOrMAOO Banco de dados e o seu modelo ER correspondente devem refletir o aspecto temporal

quando exigido no requisito, e, portanto, deve ser considerado na modelagem.

Um exemplo o relacionamento Empregado Trabalha Departamento, que foi representa-do na figura 18. Da forma como foi implementado o modelo nesta figura, no seria possvel re-gistrar historicamente os vrios departamentos em que um Empregado pode trabalhar em uma empresa durante a sua trajetria profissional. Caso o requisito para o sistema exija este registro histrico, o modelo ER que cobre adequadamente esta exigncia o seguinte:


38

Na figura 22 foi adicionada a entidade Lotao. Seu objetivo registrar o histrico dos de-partamentos que o funcionrio trabalhou na empresa durante a sua carreira. A entidade Lotao associa o empregado ao departamento que trabalha ou que trabalhou.

Na entidade Lotao, o seu atributo identificador sendo a data de incio, assegura que haver somente uma lotao por data. Para se consultar onde este funcionrio, atualmente, est trabalhando, basta consultar a ltima ocorrncia da entidade Lotao e, em seguida, consultar a ocorrncia da entidade Departamento que estiver associada a esta ocorrncia especfica da enti-dade Lotao.

Note, ainda, que no exemplo da figura 22, as cardinalidades asseguram que cada ocorrn-cia da entidade Lotao estar associada a uma nica ocorrncia das entidades Departamento e Empregado, e que tambm toda ocorrncia da entidade Empregado e da entidade Departamento poder ter uma ou mais lotaes.

MODelO lgICOEste modelo a representao do Banco de Dados Relacional e geralmente a transforma-

o do modelo ER, que um modelo abstrato.

Adotamos a abordagem de transformao do Modelo ER em Modelo Lgico, sendo esta uma fase do projeto de Banco de Dados Relacional posterior a Modelagem Conceitual na qual obtemos o Diagrama Entidade Relacionamento (DER).

Antes de iniciarmos o estudo dos passos de transformao do Modelo ER para o Modelo Lgico, apresentamos a composio de um Banco de Dados Relacional.

bAnCO De DADOS relACIOnAlO Banco de Dados Relacional composto por tabelas tambm chamadas de relaes. Va-

mos empregar a terminologia tabela que a mais comum e tambm a adotada pelos produtos comerciais de gerenciamento de banco de dados.

tAbelAA tabela um conjunto de linhas (tuplas, na terminologia acadmica). A tabela identifica-

da pelo seu nome.

Cada linha composta por uma srie de campos (valor de atributo, na terminologia acad-mica).

Figura 22

39


Cada campo identificado por um nome de campo (nome do atributo).

O conjunto de campos de um mesmo nome forma a coluna da tabela.

Os valores, que so as informaes armazenadas nos campos da tabela, so atmicos e monovalorados. Atmico significa que o campo no pode ser composto de outros. E mono-valorado significa que o campo possui somente um valor, ele no um campo do tipo vetor (arranjo ou array).

Figura 22

CHAVe um conceito bsico que tem as funes de identificar as linhas e de estabelecer relaes

entre as tabelas.

H trs tipos de chaves: Chave Primria, Chave Estrangeira e Chave Alternativa.

CHAVe PrIMrIAA chave primria uma coluna ou combinao de colunas que tornam cada linha da tabela

nica, ou seja, identifica cada linha da tabela como distinta das demais.

Na figura abaixo, um exemplo de tabela com chave primria composta.

Figura 24


40

Na figura abaixo, um exemplo de tabela com chave primria no composta.

CHAVe eStrAngeIrAA chave estrangeira uma coluna ou combinao de colunas que correspondem aos valo-

res de uma chave primria de outra tabela.

A chave estrangeira o meio pelo qual implementado o relacionamento entre tabelas de um banco de dados relacional.

Na figura abaixo, encontra-se um exemplo de chave estrangeira.

Figura 25

Figura 26

Na Figura 26, a tabela Aluno possui uma chave estrangeira que formada pelo atributo Curso, que tem valores iguais aos valores de uma chave primria de outra tabela chamada Curso. Note que, tambm, possui a chave primria Matrcula para atender ao requisito obrigatrio da modelagem relacional em que toda tabela deve conter uma coluna que identifica cada ocorrn-cia como nica. Neste caso, o nmero da matrcula ser nico mesmo que ocorram alunos com nomes idnticos.

41


Na figura 27, podemos ver o relacionamento entre a chave estrangeira da tabela Aluno e a chave primria da tabela Curso, verificando os valores correspondentes em cada tabela do atribu-to Curso, que contm o cdigo de cada curso.

Figura 27

CHAVe AlternAtIVAH situaes em que h mais de uma coluna ou mais de um conjunto de colunas que pode

perfeitamente indicar a distino de uma linha das demais, uma destas colunas ou conjunto de colunas ser a chave primria e as demais sero as chaves alternativas. As chaves alternativas so muito utilizadas para se encontrar a informao por meio de outras referncias alm da coluna ou colunas que determinam a chave primria.

Figura 28

Na figura acima, h um exemplo de chave alternativa.


42

AS CHAVeS e A reStrIO De IntegrIDADe importante ressaltar que o conceito de chave primria e de chave estrangeria so impor-

tantes restries de integridade, ou seja, existem no somente para identificar as linhas e construir relacionamentos, respectivamente, mas tambm garantem a integridade da informao de forma que somente os valores permitidos possam ser inseridos e / ou alterados nas suas colunas.

eSqUeMA teXtUAl DO bAnCO De DADOS relACIOnAlUma notao compacta de esquema textual bem prtica e de fcil utilizao. A seguir,

mostrado um esquema textual correspondente s tabelas da figura 27.

Figura 29

Na figura 29, o esquema textual utiliza o sublinhado para indicar a chave primria. O nome da tabela est fora dos parnteses enquanto que dentro dos parnteses esto os atributos (colunas).

A chave estrangeira indicada pela seta quando liga a coluna, que chave estrangeira, ao seu correspondente de chave primria na outra tabela. Note que as cardinalidades mnimas e mximas so representadas nos extremos do relacionamento indicado pela seta que une a chave estrangeira com a chave primria.

DIAgrAMAO DO bAnCO De DADOS relACIOnAlExistem diversos esquemas diagramticos

para o modelo relacional. A seguir, um exemplo muito utilizado atualmente:

O diagrama da figura 30 trata os elementos da seguinte forma:

Chave Primria: A coluna ou o conjunto de colunas a que se atribui o papel de chave prim-ria tem ao extremo do lado esquerdo as iniciais PK entre parnteses. Estas iniciais so a traduo de chave primria para a lngua inglesa (Primary Key).

Chave Estrangeira: A coluna ou o conjunto de colunas a que se atribui o papel de chave estran-geira tem ao extremo do lado esquerdo as iniciais FK entre parnteses. Estas iniciais so a traduo de chave estrangeira para a lngua inglesa (Foreign Key) e a seta liga a tabela que contm a chave es-trangeira com a tabela que contm a chave prim-ria correspondente no relacionamento.

Figura 30

43


trAnSfOrMAO entre OS MODelOS er e lgICOA transformao entre os modelos Entidade Relacionamento (ER) e o Modelo Lgico (Ban-

co de dados Relacional) implementada por um processo de passos. A seguir, descrevemos um processo simplificado:

PASSOS DA trAnSfOrMAO

Para toda entidade no Modelo ER cria-se uma tabela para o modelo relacional. Os atributos desta tabela sero os atributos simples da entidade ou compo-nentes simples de atributos compostos. A chave primria desta tabela ser um dos atributos identificadores da entidade. Os atributos compostos sero sempre decompostos em atributos simples.

Para toda entidade fraca, ou seja, com cardinalidade mnima Zero no Modelo ER, cria-se uma nova tabela no modelo relacional. Os atributos desta tabela se-ro os atributos simples da entidade ou componentes simples de atributos com-postos mais a chave primria (como chave estrangeira) da tabela proprietria. A chave primria desta tabela ser a chave primria da tabela proprietria mais o identificador da entidade fraca.

Para todo relacionamento do Um para Um, na chave primria de uma das tabe-las envolvidas no relacionamento (preferencialmente a de cardinalidade mni-ma zero, se houver), inclui-se como chave estrangeira a chave da outra tabela envolvida no relacionamento. Os atributos do relacionamento acompanham a chave estrangeira.

Para todo relacionamento do tipo Um para Vrios pega-se a chave primria da tabela do lado 1 e inclui-se como chave estrangeira na tabela do lado N. Os atri-butos do relacionamento acompanham a chave estrangeira.

Para todo relacionamento do tipo Vrios para Vrios cria-se uma nova tabela. Os atributos desta tabela sero as chaves primrias das tabelas envolvidas, includas como chave estrangeira, mais os atributos do prprio relacionamento. A chave primria desta tabela ser as chaves primrias das tabelas envolvidas.

Para todo atributo multivalorado cria-se uma nova tabela. Os atributos desta ta-bela sero a chave primria da tabela de origem mais o prprio atributo multiva-lorado. A chave primria dessa tabela deve ser composta destes dois atributos.

Preferencialmente, eliminar a especializao utilizando atributos adicionais na entidade generalizada. Estes atributos devem conter como domnio as especia-lizaes. Caso no seja possvel o procedimento acima, optar por incluir nas en-tidades especficas a chave primria da entidade geral como chave estrangeira.


44

eXeMPlO De trAnSfOrMAO entre MODelOSUtilizando o software BR-Modelo, geramos o seguinte Modelo Lgico de um banco de

dados relacional com base na transformao do modelo conceitual, ou seja, o Modelo Entidade Relacionamento do DER da figura 21.

Na figura 31, o modelo produzido com a ferramenta BR-Modelo utiliza a seguinte nomen-clatura:

- Chave Primria Chaves em Amarelo.

- Chave Estrangeira Chaves em Cinza.

- Coluna de uma chave primria composta, que tambm uma chave estrangeira - Chaves em dourado com uma parte em cinza.

- Atributos com nomes e tipos de dados.

- Nome da Tabela no topo do retngulo.

- Relacionamentos so as linhas ligando as entidades e apresentando as cardinalidades mnimas e mximas de cada relacionamento.

Nota-se o seguinte:

- Cada entidade do modelo conceitual se torna uma tabela.

- O relacionamento muitos para muitos, que alocava os Empregados nos Projetos, foi subs-titudo por uma nova tabela e dois relacionamentos um para vrios.

Figura 31

45


- A chave Primria da tabela Alocao criada a partir de um relacionamento do modelo conceitual possui uma chave primria composta de duas colunas e estas duas colunas tambm so chaves estrangeiras cada uma.

- Note que no lugar do atributo multivalorado Telefone foi criada a tabela Telefone.

- Nesta tabela Telefone, a chave primria composta pelo prprio atributo telefone e mais o atributo cdigo do empregado, sendo este ltimo tambm uma chave estrangeira.

Referncias

CHEN, P. P.-S. The entity-relationship modeltoward a unified view of data. ACM Transac-tions on Database Systems (TODS) , 1 (1), 9-36, (1976).

CODD, E. F. A relational model of data for large shared data banks. (P. Banxedale, Ed.) Com-munications of the AMC , 13 (6), (1970), p. 377-387.

DATE, C. J. Introduo a Sistemas de Banco de Dados. Sao Paulo, SP: Editora Campus, (2004).

ELMASRI, R. Sistemas de Banco de Dados. Traduo da 6. ed. americana). So Paulo, SP: Pearson, (2011).

HEUSER, C. Projeto de Banco de Dados. Porto Alegre/RS, Brasil: Bookman, (2009).


46

Mdulo



Engenharia de Requisitos

Parte 1

Prof. Me. Andr luiz Perin

Objetivos:Apresentar a disciplina e definir os conceitos

bsicos de engenharia de software.Apresentar o ciclo de vida de software e os

processos de software.

Palavras-chave: Engenharia de software; engenharia

de requisitos; ciclo de vida de software.


48

IntrODUOSoftware de computador pode ser entendido como o conjunto de programas que podem

ser executados em computadores de qualquer tipo e arquitetura, seu contedo e seus documen-tos, em formato digital ou impresso.

Os profissionais de software so aqueles que constroem e/ou mantm o software ao longo do tempo. Tanto a construo quanto a manuteno do software no seguem os mesmos proces-sos conhecidos de outras reas.

A essncia da engenharia de software envolve algumas etapas que podem ser resumidas nos seguintes itens: compreenso do problema, planejamento da soluo, execuo do plano e verificao do resultado.

Compreenso do ProblemaA Compreenso do Problema a etapa inicial e envolve as tarefas de Comunicao e Anlise.

A fase de Comunicao feita atravs da interao entre as partes interessadas, ou seja, o cliente ou seus representantes e o desenvolvedor ou grupo de desenvolvedores.

Planejamento da soluoAlm das tarefas de gerenciamento de projetos, que so entendidas como as tarefas que

no fazem parte do ciclo de vida de software e podem ser utilizadas por qualquer tipo de produto, envolve as tarefas de Modelagem e Projeto de Software. A tarefa de Modelagem de Software de-fine o conjunto de atividades necessrias para a construo de um ou mais modelos do sistema. O Projeto de Software envolve a elaborao de modelos mais aprofundados e tcnicos, voltados ao programador, com o objetivo de fornecer detalhes tcnicos que, muitas vezes, no so de conhecimento do cliente.

Execuo do PlanoA execuo do plano de projeto envolve a gerao de cdigo, sua transformao em execu-

tvel e alguns testes iniciais.

Verificao do Resultado

Para verificar o resultado so conduzidos testes com os objetivos de achar defeitos ou falhas do software, tanto no processo que o software automatiza quanto na sua aderncia aos desejos e necessidades do cliente.

As atividades de garantia da qualidade do software so estabelecidas com o objetivo de minimizar ou eliminar os defeitos do software durante e aps a sua construo.

engenHArIA De SISteMASA engenharia de sistemas parte do princpio que o software parte de algo maior e os ob-

jetivos do sistema devem ser estabelecidos antes de serem estabelecidos os objetivos do software.

O profissional responsvel pelo sistema, ou engenheiro de sistemas, trabalha com o obje-tivo de entender as necessidades dos sistemas, ou requisitos, atravs da interao com o cliente, os futuros usurios e quaisquer outros interessados.

49


Sistemas baseados em computadorUm sistema baseado em computador pode ser definido como um conjunto ou arranjo de

elementos organizados para atingir alguma meta pr-definida por meio do processamento da informao (PRESSMAN, 2006).

A meta ou objetivo definido pode ser desde a automao, uma simples funo do negcio, at a gerao de um produto completo.

eleMentOS De UM SISteMA bASeADO eM COMPUtADOrUm sistema pode ser composto e utilizar diversos elementos do sistema. So eles:

SoftwarePode ser definido como programas de computador, estruturas de dados e outros produtos

de trabalho necessrios.

HardwareSo os equipamentos ou dispositivos eletrnicos ou eletromecnicos que possuem capa-

cidade computacional (computadores, microcontroladores e conexes de comunicao) e per-mitem o fluxo de informaes e acesso s funes do mundo externo (sensores e atuadores).

PessoalSo as pessoas que utilizam o sistema (usurios) e as pessoas que mantm o sistema (op-

eradores), tanto na parte de hardware quanto de software.

Banco de dados o grande conjunto de informaes organizadas, persistente ao longo do tempo e acessvel

por meio de software.

DocumentaoSo os documentos que descrevem o sistema, o seu uso e a sua operao, tanto para os

operadores quanto para os usurios. Podem tambm incluir os documentos utilizados para a construo do sistema.

ProcedimentosSo as etapas que definem o uso e o contexto de cada elemento especfico do sistema.

HIerArqUIA DA engenHArIA De SISteMASUm sistema complexo pode ser interpretado como um conjunto de elementos que so eles

mesmos outros sistemas.

A hierarquia da engenharia de sistemas envolve um conjunto de procedimentos que trata o sistema a partir de seu nvel mais alto para o mais baixo, chamados de top-down, e outro conjunto que trata o sistema a partir de seu nvel mais baixo para o mais alto, chamados de bottom-up. Ao percorrer a hierarquia do sistema deve-se utilizar tais mtodos.

A Figura 1 mostra um exemplo de hierarquia de sistemas, em que o seu nvel mais alto, chamado de viso de mundo pode ser decomposto em elementos menores, chamados de domnio. Os domnios podem ser sistemas ou conjuntos de sistemas e podem ser divididos em elementos. Os elementos, por sua vez, podem ser divididos em componentes tcnicos (pro-gramas, mdulos, classes ou at mesmo comandos de linguagens de programao).


50

Figura 1 - Hierarquia da Engenharia de SistemasFonte: adaptado de Pressman (2006)

MODelAgeM DO SISteMAA modelagem do sistema define os processos que servem s necessidades da viso con-

siderada. Cada nvel da hierarquia deve ser representado pelo conjunto adequado de modelos. Ela representa o comportamento dos processos e os pressupostos nos quais o comportamento est baseado. Esses pressupostos podem conter alguns fatores restritivos, como por exemplo, os prprios pressupostos, simplificaes, limitaes, restries e preferncias. Os pressupostos po-dem reduzir a quantidade dae possveis variaes do sistema. As simplificaes permitem a cria-o dos modelos nos prazos adequados. As limitaes ajudam a cercar o escopo do sistema. As restries ajudam no direcionamento da criao dos modelos. Por fim, as preferncias indicam as solues de tecnologia, dados, funes e etc. que tm relao direta com a satisfao do cliente.

A definio explcita, tanto as entradas exgenas quanto as endgenas do modelo, tambm faz parte da modelagem. As entradas exgenas so aquelas entradas que ligam uma parte de

51


uma determinada viso a outras partes do mesmo nvel ou de outros nveis. As entradas end-genas so aquelas que ligam componentes individuais de uma parte em uma determinada viso.

A modelagem do sistema tambm representa todas as ligaes (inclusive sadas) que per-mitiro ao engenheiro compreender melhor a viso.

PrOCeSSOS De SOftwAreOs chamados processos de software so os conjuntos de atividades para especificar, pro-

jetar, implementar e testar sistemas de software.

Processo de softwareUma definio mais adequada a um processo de software pode ser dada por um conjunto

estruturado de atividades necessrias para desenvolver um sistema de software.

Um processo de software contm as etapas de especificao, projeto, validao, etc. e pode ser caracterizado por um modelo de processo.

Um modelo de processo de software uma representao abstrata de um processo. Ele apresenta uma descrio de um processo de uma perspectiva particular. Cada organizao pode definir e adotar o seu prprio modelo de processo, porm, a maioria das organizaes adota um modelo genrico e desenvolve adaptaes desse modelo para ajust-lo sua prpria cultura.

MODelOS genrICOS De PrOCeSSO De SOftwAreOs modelos genricos de processo de software foram desenvolvidos para organizar as ativi-

dades de desenvolvimento de software. Existem diversos modelos genricos de processo de soft-ware, por exemplo, o modelo em cascata, o modelo incremental, o desenvolvimento evolutivo, o modelo espiral, etc.

Modelo CascataO modelo cascata de desenvolvimento de software foi o primeiro modelo publicado e teve

sua origem em processos mais gerais da engenharia de sistemas. O modelo cascata apresenta fases separadas encadeadas que representam os principais processos de desenvolvimento de software (Figura 2).

Figura 2 - Modelo cascata de desenvolvimento de softwareFonte: adaptado de Sommerville (2011)


52

fases do modelo cascataA primeira fase a fase de anlise e definio de requisitos, que tem por objetivo definir os

servios, as restries e os objetivos do sistema detalhadamente para serem utilizados como uma especificao do sistema.

Em seguida, a fase de projeto de sistema e de software, que tem como objetivo definir a arquitetura do sistema ou do software.

A etapa de implementao e teste de unidade segue a de projeto e tem a finalidade de gerar os programas ou unidades dos programas assim como de realizar os testes iniciais nessas unidades.

A etapa de integrao e testes do sistema realizada aps a fase de implementao e nela as unidades individuais de programas ou os programas so integrados e testados como um siste-ma completo. Um dos objetivos dessa fase garantir que os requisitos tenham sido atendidos e, aps os testes, o sistema liberado ao cliente ou usurio.

A fase de operao e manuteno a ltima do processo e nela o sistema instalado e colocado em operao. A manuteno descrita nessa fase envolve a correo de erros no encon-trados anteriormente, o aprimoramento das unidades desenvolvidas e na ampliao das funcio-nalidades medida que novos requisitos so encontrados.

Problemas do modelo cascataUma desvantagem do modelo cascata em relao a outros modelos a dificuldade de aco-

modar as mudanas no software aps o processo estar em andamento. Isso devido ao fato de o modelo ter as fases bem definidas e estanques, em que no possvel iniciar uma fase sem a anterior ter terminado. Isso faz com que esse modelo seja apropriado quando os requisitos so bem compreendidos.

DeSenVOlVIMentO eVOlUCIOnrIOO desenvolvimento evolucionrio tem base no desenvolvimento de uma implementao

inicial, que mostrada ao cliente para que ele faa crticas e d sugestes e, ento, o resultado refinado por meio de vrias verses do sistema, que so criadas at que um sistema adequado seja obtido, como pode ser visto na Figura 3. Existem, basicamente, dois tipos de desenvolvim-ento evolucionrio, o desenvolvimento exploratrio e a prototipao.

Figura 3 - Desenvolvimento evolucionrioFonte: adaptado de Sommerville (2011)

53


Desenvolvimento exploratrioEste processo possui o objetivo de trabalhar com clientes para explorar os requisitos e

evoluir para o sistema final a partir de uma especificao inicial. Deve iniciar com requisitos bem compreendidos para as partes iniciais do sistema.

PrototipaoA prototipao possui o objetivo de entender os requisitos do sistema e, a partir disso,

desenvolver uma melhor definio de requisitos do sistema. O prottipo deve se concentrar na experimentao dos requisitos mal compreendidos. O processo deve iniciar com requisitos mal compreendidos.

Problemas do Desenvolvimento EvolucionrioUm dos problemas do desenvolvimento evolucionrio a falta de visibilidade do processo,

pois se as verses so desenvolvidas rapidamente, no economicamente vivel produzir os documentos correspondentes s vrias verses.

Outra desvantagem que os sistemas so mal estruturados devido s contnuas mudanas e cada nova mudana aumenta a dificuldade de introduzir outras mudanas.

DeSenVOlVIMentO bASeADO eM reUSO Este processo baseado no reuso sistemtico de componentes em que os sistemas so

integrados a partir de componentes existentes ou sistemas de prateleira.

As etapas do desenvolvimento baseado em reuso so: anlise de componentes, modifica-o de requisitos, projeto de sistema com reuso, e desenvolvimento e integrao (Figura 4).

Na anlise de componentes, a partir de uma especificao de requisitos dada, feita a bus-ca pelos componentes que sejam adequados especificao, mas no necessariamente exatos.

Na modificao de requisitos, primeiramente, so feitas anlises nos requisitos em funo das informaes dos componentes encontrados. Quando a modificao dos requisitos no pos-svel, novos componentes podem ser buscados.

Na etapa de projeto do sistema com reuso, o framework do sistema projetado ou um framework j existente reusado.

Aps o projeto do sistema com reuso, realizado o desenvolvimento. A integrao se en-carrega de construir o software que no puder ser adquirido externamente, integrar os compo-nentes de prateleira (componentes prontos disponveis no mercado) e testar o sistema completo.

Figura 4 - Desenvolvimento baseado em reusoFonte: adaptado de Sommerville (2011)

PrOCeSSOS IterAtIVOS Os requisitos do sistema sempre evoluem no decorrer de um projeto e, com isso, h mu-

danas no projeto do sistema, principalmente se ele for de grande porte. Um processo iterativo, em que os estgios iniciais so retrabalhados, um processo comum para os sistemas desses sistemas e, inclusive, a iterao pode ser aplicada a qualquer um dos modelos de processos genricos.


54

Normalmente, so tratadas duas abordagens relacionadas, o processo de desenvolvimento incremental e o processo de desenvolvimento em espiral.

Desenvolvimento Incremental O processo de desenvolvimento incremental (Figura 5) se concentra em ao invs de en-

tregar o sistema todo em uma nica entrega, o desenvolvimento e a entrega so divididos em parcelas, chamadas incrementos, com cada incremento entregando uma parte da funcionalidade requerida. Os requisitos do usurio so priorizados e os requisitos de alta prioridade so inclu-dos nos incrementos iniciais. Uma vez que o desenvolvimento de um incremento iniciado, os requisitos so congelados, ou seja, no mudaro neste incremento, embora os requisitos para incrementos posteriores possam continuar a evoluir.

Figura 5 - Processo de desenvolvimento incrementalFonte: adaptado de Sommerville (2011)

Vantagens do Desenvolvimento IncrementalAlgumas vantagens do desenvolvimento incremental em relao a outros processos podem

ser vistas como, por exemplo, a funcionalidade do sistema estar disponvel ao cliente mais cedo ou os incrementos iniciais agirem como um prottipo para ajudar a descobrir requisitos para incrementos posteriores. Outras caractersticas tambm se mostram vantajosas como o menor risco de falha geral do projeto, uma vez que cada iterao envolve testes completos do sistema e tambm porque os servios de sistema de alta prioridade tendem a receber mais testes.

DeSenVOlVIMentO eM eSPIrAl No processo de desenvolvimento em espiral (Figura 6), o processo representado como

uma espiral em vez de uma sequncia de atividades rastreveis. Cada volta na espiral representa uma fase no processo e no existem fases fixas como especificao ou projeto, por isso, as voltas na espiral so escolhidas dependendo do que exigido pelo cliente e os riscos so explicitamente avaliados e resolvidos ao longo do processo.

55


Figura 6 - Processo de desenvolvimento de software em espiralFonte: Sommerville (2011)

AtIVIDADeS DO PrOCeSSO De DeSenVOlVIMentO De SOftwAre

Especificao de Software

A especificao de software o processo de estabelecer quais servios so necessrios e as restries na operao do sistema e do desenvolvimento. Normalmente, definida pelo processo de engenharia de requisitos, que, por sua vez, engloba as fases de estudo de viabilidade, coleta e anlise de requisitos, especificao de requisitos e validao de requisitos.

Projeto e Implementao de Software o processo responsvel pela converso da especificao do sistema em um sistema ex-

ecutvel e envolve as tarefas de projeto de software e programao de software. O projeto de software consiste em projetar uma estrutura de software que atenda especificao e a imple-mentao consiste em traduzir essa estrutura em um programa executvel. As atividades de pro-jeto e implementao esto intimamente relacionadas e podem ser entrelaadas. As atividades do processo de projeto podem ser divididas em: projeto de arquitetura, especificao abstrata, pro-jeto de interface, projeto de componentes, projeto da estrutura de dados, e projeto de algoritmos.

O projeto geralmente documentado como um conjunto de modelos grficos, sendo que os possveis modelos a serem usados so: modelo de fluxo de dados, modelo Entidade-Relacio-namento-Atributo, modelo estrutural, e modelos de objetos.

Programao e depuraoA etapa de programao e depurao consiste em transformar um projeto em um programa

e remover erros desse programa. Nota-se que a programao uma atividade pessoal e no h


56

um processo genrico de programao. Ainda nessa etapa, os programadores realizam alguns testes para descobrir e remover falhas no programa pelo processo de depurao (debugging).

Validao de SoftwareA verificao e a validao tm o objetivo de mostrar que um sistema est de acordo com

sua especificao e cumpre os requisitos do cliente do sistema. Envolvem os processos de veri-ficao, reviso e de testes de sistema. Os testes do sistema envolvem a execuo do sistema de acordo com os casos de teste, que so derivados a partir da especificao dos dados reais a serem processados pelo sistema.

A fase de testes do sistema pode ser dividida nas seguintes etapas: teste unitrio (teste de componentes individuais), testes modulares (teste de conjuntos de componentes relacionados e dependentes), testes de subsistema (testes dos mdulos integrados em subsistemas cujo foco deve ser o teste de interfaces), teste do sistema (teste do sistema como um todo e anlise das propriedades emergentes), teste de aceitao (testes com dados do cliente para verificar se o sistema pode ser aceito).

eVOlUO DO SOftwAre O produto software flexvel e pode mudar. Como os requisitos mudam com as circunstn-

cias de mudana do negcio, o software que suporta o negcio tambm deve evoluir e mudar.

engenHArIA De PrOCeSSO De negCIOA engenharia de processo de negcio utiliza um conjunto integrado de procedimentos, m-

todos e ferramentas para identificar como os sistemas de informao podem alcanar as metas estratgicas de uma empresa. Ela foca primeiro na empresa e depois na rea de negcio.

Para atender s metas da empresa criam-se modelos de empresa, modelos de dados e modelos de processos. Um framework para administrar, distribuir e controlar melhor a informa-o tambm criado.

Trs arquiteturas diferentes devem ser analisadas e desenhadas no contexto dos objetivos e metas do negcio. So elas:

Arquitetura de dadosA arquitetura de dados necessria para fornecer a estrutura para as necessidades da infor-

mao de um negcio ou parte dele. Define os objetos de dados usados pelo negcio, ou seja, o conjunto de informaes manipuladas pelo negcio e suas caractersticas.

Arquitetura de aplicaes A arquitetura de aplicaes abrange os elementos de um sistema que transformam objetos

da arquitetura de dados para alguma finalidade do negcio, ou seja, so os programas aplicativos que suportam o processo de negcio ou parte dele.

InfrAeStrUtUrA teCnOlgICAA infraestrutura tecnolgica fornece a base para a arquitetura de dados e arquitetura de

aplicaes, trata da definio dos equipamentos de computao e comunicao, softwares bsi-cos e gerenciadores, etc..

57


engenHArIA De reqUISItOSDefinio

Segundo o dicionrio Aurlio, engenharia significa cincia, tcnica e arte da construo de obras de grande porte, mediante a aplicao de princpios matemticos e das cincias fsicas. Tambm segundo o dicionrio Aurlio, requisito significa condio que se deve satisfazer para al-canar certo fim. Pela juno das duas definies pode-se definir a engenharia de

Documents

adsi-p3