1

UNIVERSIDADE CATÓLICA DE GOIÁS

DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO
PROJETO FINAL DE CURSO I

DESENVOLVIMENTO DE UMA FERRAMENTA CASE

PARA MODELAGEM CONCEITUAL DE DADOS

GOIÂNIA, JUNHO 2005

UNIVERSIDADE CATÓLICA DE GOIÁS

DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO
PROJETO FINAL DE CURSO I

1
 2

DESENVOLVIMENTO DE UMA FERRAMENTA CASE

PARA MODELAGEM CONCEITUAL DE DADOS

LUIZ FERNANDO BATISTA LOJA

ORIENTADOR: PROFº RONALDO LOPES DE OLIVEIRA,
MSC

2
 3

GOIÂNIA, JUNHO 2005

AGRADECIMENTOS

Colocarei os agradecimentos

3
 4

SUMÁRIO
LISTA DE FIGURAS
INTRODUÇÃO
ORGANIZAÇÃO DO DOCUMENTO
INTRODUÇÃO
FUNDAMENTOS DE SISTEMAS DE BANCO DE DADOS
MODELOS DE DADOS
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
PARADIGMA DE ORIENTAÇÃO A OBJETO
LINGUAGEM DE PROGRAMAÇÃO JAVA

4
 5

LISTA DE FIGURAS

5
 6

SINOPSE
Atualmente o meio academico necessita uma ferramenta
CASE para a modelagem de dados. Tendo em vista tal carência
e a dificuldade em conseguir uma ferramenta deste tipo
licenciada, de domínio público e que se ajuste as necessidades
das disciplinas, foi sugerido pelo professor e mestre Ronaldo de
Oliveira Lopes a criação da mesma, como uma proposta de
resolver tal problema, de forma a aproveitandar os projetos
finais dos alunos do curso de Cinência da Computação.
Esta ferramenta deve ser usada, a principio, nos
laboratórios da Universidade de Católica de Goiás, pelos alunos
das disciplinas de Engenharia de Software, Análise e Projeto de
Sistema, Banco de Dados I e Banco de Dados II.
A ferramenta visa modelar esquemas conceituais
entidade relacionamento, mapear estes esquemas para esquemas
lógicos de implementação relacional, gerar o script do esquema
relacional, podendo executar o script diretamente no próprio
SGDB PostgreSQL.
Com o intuito continuar o projeto, esta monografia
apresentará os principais conceitos de Banco de Dados e de

6
 7

Engenharia de Software que estão sendo usados na construção

deste sistema.

ORGANIZAÇÃO DO DOCUMENTO

Este documento está dividido nos seguintes capítulos:

Capítulo I - Introdução.
Capítulo II - Fundamentos de Sistemas de Banco de
Dados. O capítulo II descreve os conceitos básicos de Sistemas
de Bancos de Dados.
Capítulo III – Modelos de Dados. Neste capítulo é
descrito o Modelo de Entidade Relacionamento e o Modelo
Relacional que são usados na ferramenta pretendida. Há também
uma descrição do mapeamento entre os dois modelos.
Capítulo IV – Fundamentos de Engenharia de Software.

7
 8

Capítulo V – Paradigma de Orientação a Objeto. Neste

capítulo é apresentado um breve estudo sobre os conceitos
básicos do Paradigma de Orientação a Objeto.
Capítulo VI – Linguagem de Programação Java. Este
capítulo mostra um pouco sobre a linguagem de programação
Java, que foi adotada no projeto, definindo sua sintaxe e
apresentando a API (Application Programming Interface) JDBC
que é também utilizada no projeto.
Capítulo VII - Conclusão – Na conclusão é feita uma
análise a respeito desta etapa do desenvolvimento do projeto
final de uso em questão e considerações sobre os próximos
passos.

CAPÍTULO I
INTRODUÇÃO

1.1. APRESENTAÇÃO
A criação de um Diagrama de Entidade Relacionamento
à mão é muito trabalhosa, pois, durante o processo de

8
 9

modelagem, as revisões são freqüentes. Além disso, quando

ocorrem alterações do modelo durante a sua vida útil, diagramas
feitos à mão dificilmente serão atualizados. Portanto, é
recomendável que desde o início da confecção do modelo
Entidade Relacional, seja usada uma ferramenta em computador
para apoio à modelagem. O meio academico necessita deste tipo
de ferramenta, denominada CASE (Computer Aided Software
Engineering), porém, há uma grande dificuldade em conseguir
ferramentas deste tipo licenciadas, de domínio público e que se
ajustem as necessidades das disciplinas que as utilizarão.
Com o intuito de sanar tal necessidade foi proposto pelo
professor e mestre Rolando de Oliveira Lopes a criação de uma
ferramenta CASE que se adpte as necessidades dos cursos de
Engenharia de Software, Análise e Projeto de Sistema, Banco de
Dados I e Banco de Dados II.
Esta ferramenta está sendo construida com a participação
dos alunos do curso de Ciência da Computação que dedicam
seus projetos finais para seu desenvolvimento.
A primeira parte deste projeto final visa abordar assuntos
sobre as teorias de Banco de Dados e Engenharia de Software a
fim de obter o conhecimento necessário para dar continuidade a
ferramenta que está sendo desenvolvida.
Esta ferramenta CASE será usada nos laboratórios da
Universidade Católica de Goiás visando auxiliar na criação de
modelos de dados e facilitando a geração de esquemas para os
Sistemas Gerenciadores de Bancos de Dados Relacionais
(SGBDR´s).

1.2. MOTIVAÇÃO
A principal motivação deste projeto é construir uma

9
 10

ferramenta CASE que seja fiél às teorias de modelagem de

dados e às diferenças existentes entre o esquema conceitual
entidade relacionamento e esquema lógico de implementação
relacional, com o intuito de que está seja usada nos laboratórios
da universidade para ajudar na formação academica dos alunos.
Minha principal motivação neste projeto foi a
oportunidade de estar aprendendo mais sobre Banco de Dados,
área em que pretendo me especializar futramente. Sei que este
projeto aumentará bastante meu conhecimento nesta área que eu
tenho total fascínio.
Também devo salientar que tal projeto é de grande valia
para aplicação de muitos dos conhecimentos obtidos durante o
curso de Ciência da Computação.
Devo lembrar também que estarei aprofundando meu
conhecimento na parte de Engenharia de Software podendo
aplicá-lo na minha vida profissional.

10
 11

CAPÍTULO II
FUNDAMENTOS DE SISTEMAS DE BANCO DE DADOS

2.1 INTRODUÇÃO

Um Sistema de Banco de Dados é composto de três

elementos: conjunto de dados, conjunto de arquivos e sistemas
que os administram. Os dados são compostos por todas as
informações da empresa, indo dos boletos bancários até as notas
fiscais de seus equipamentos. O Sistema Gerenciador de Banco
de Dados é constituído por um conjunto de arquivos e
programas que permitem consulta e alterações dos dados. O
SGBD também pode ocultar detalhes de armazenamento e
manutenção sobre estes dados, facilita sua recuperação, favorece
a diminuição da redundância e ajuda a evitar inconsistência de
dados através de regras de integridade que são validadas
automaticamente pelo SGBD.

11
 12

Tendo em vista a interação entre diversos usuários de

variados tipos de conhecimento com o SGBD, foi proposta uma
arquitetura de referência que caracteriza os dados em três níveis
de abstração: nível físico, nível lógico e nível de visão.

 Nível Físico
É o nível mais baixo e descreve como os dados estão
realmente armazenados fisicamente. Geralmente é utilizado
apenas por DBAs (Administradores de Banco de Dados) para
otimizar consultas e acessos ao banco.

 Nível Lógico
É um nível médio de abstração. Este nível de abstração
descreve logicamente o conjunto de dados informando quais
dados devem ser armazenados, quais os inter-relacionamentos
entre eles e as regras de integridade que eles devem obedecer.
Sendo assim o banco de dados pode ser descrito usando um
número pequeno de estruturas neste nível.

 Nível de Visão
É o nível mais alto de abstração e descreve uma visão
dos dados armazenados no banco de dados do ponto de vista de
uma aplicação ou de um usuário em particular.
Podem ser definidas varias visões para o mesmo banco
de acordo com os usuários/aplicações que o utilizam. Esta
divisão, em diferentes níveis de representação, permite uma
maior independência de dados ou comparação com arquivos.
A independência de dados é a capacidade de modificar a
definição dos esquemas em determinado nível, sem afetar os
esquemas dos níveis superiores. Há dois tipos de independência
de dados: física e lógica.

12
 13

 Independência de dados física: Capacidade de modificar o

esquema físico sem afetar qualquer programa que tenha sido
escrito. Realizada para melhorar o desempenho do banco.
 Independência de dados lógica: Capacidade de modificar o
esquema no nível lógico sem alterar o programa que interage
com ele; sempre necessário quando estruturas lógicas de
dados são alteradas.

Dois conceitos importantes no contexto de Sistemas de

Banco de Dados são: o conceito de esquema e o conceito de
instância. Onde um esquema de banco de dados é especificado
por um conjunto de definições que são expressas em uma
linguagem de definição de dados, segundo as regras do modelo
conceitual em que eles são expressados em um modelo
conceitual. O resultado da compilação das instruções da
linguagem de definição de dados se traduz em um esquema
definido no catálogo do SGBD em um conjunto de tabelas.
Instância é um conjunto de dados armazenados no banco em
um determinado instante que obedecem as definições contidas
no esquema.

2.2 MODELOS DE DADOS

Conforme foi dito anteriormente o resultado do processo
de modelagem de dados é o esquema do banco de dados. Para
executar esta modelagem são usadas ferramentas conceituais
conhecidas como modelos de dados. Os vários modelos são
classificados em três tipos:
 Modelos conceituais com base em objetos;
 Modelos lógicos com base em registros;
 Modelos físicos.

13
 14

2.2.1 MODELOS CONCEITUAIS COM BASE EM

OBJETO
Estes modelos são usados na descrição conceitual dos
dados. Dispõem de recursos de estruturação bem mais flexíveis
e por viabilizar a especificação explícita as restrições de
integridade de dados. Sendo sua descrição feita de forma
independente variando de SGBD para SGBD no que diz respeito
à implementação. Ou seja, é uma descrição formal da estrutura
de um banco de dados. O modelo de dados registra que dados
podem aparecer no banco de dados, mas não registra como estes
dados estão armazenados no nível de SGBD. Alguns exemplos
deste tipo de modelo são: Modelo Entidade-Relacionamento,
Modelo Orientado a Objeto.
O resultado de uma modelagem de dados usando um
modelo conceitual é o esquema conceitual do BD.

2.2.2 MODELOS LÓGICOS COM BASE EM REGISTRO

Este modelo descreve os dados no nível lógico e de
visão. Em contraste com os modelos conceituais este tipo de
modelo é usado tanto para especificar a estrutura lógica do
banco de dados quanto para implementar uma descrição de alto
nível.
Neste modelo cada registro define um número fixo de
campos ou atributos, e cada campo possui normalmente
tamanho fixo.
Os três modelos de dados com base em registro mais
comumente utilizados são: Modelo Relacional, Modelo de Rede
e Modelo Hierárquico.

2.2.3 MODELO FÍSICO DE DADOS

14
 15

Os modelos físicos de dados são usados para descrevê-

los no nível mais baixo. Em contraste com os modelos
conceituais e lógicos, há poucos modelos físicos de dados em
uso. Dois deles são amplamente conhecidos: o Modelo
Unificado e o Modelo de Partição de Memória.

2.3 LINGUAGEM DE BANCO DE DADOS

Um sistema de banco de dados proporciona dois tipos de
linguagens: uma específica para os esquemas do banco de dados
e outra para expressar consultas e atualizações. Assim o modelo
lógico será passado para o banco de dados através destas
linguagens.
 Linguagens de Definição de Dados (DDL - Data Definition
Language): Um esquema é especificado por um conjunto de
definições expressas por uma linguagem especial chamada
Linguagem de Definição de Dados. O resultado dos
parâmetros das DDLs são armazenados em um conjunto de
tabelas constituindo o dicionário de dados ou diretório de
dados. O dicionário de dados é um arquivo metadados que
são dados a respeito de dados. Este arquivo é consultado
antes da criação dos dados reais. As estruturas de memória e
os métodos de acesso usados pelos SGBDs são especificados
por um conjunto especial de DDL chamado Linguagem de
Definição e Armazenamento de Dados. A compilação desta
linguagem especifica os detalhes da implementação do
banco de dados. Estes são os detalhes omitidos no nível
físico e no nível lógico.
 Linguagem de Manipulação de Dados (DML - Data
Manipulation Language): A DML é responsável pela
recuperação das informações armazenadas no banco de
dados inserção de novas informações do banco de dados,

15
 16

remoção de informações do banco de dados, modificação

das informações do banco de dados. As DMLs são
caracterizadas em dois tipos: procedurais ou não
procedurais.
 DMLs procedurais: Exigem que o usuário especifique quais
dados são necessários , e como obtê-los.
 DMLs não procedurais: Exigem que o usuário especifique
quais dados são necessários sem especificar como obtê-los.

2.4 GERENCIAMENTO DE TRANSAÇÕES

Transação é uma coleção de operações que desempenha
uma função lógica e única dentro de uma aplicação do sistema
de banco de dados e para haver integridade do banco de dados é
necessário que o SGBD tenha as seguintes características:

 Atomicidade: uma transação não pode ser executada pela

metade, isto é, ou se executa ela por inteiro, ou se retorna
para o estado anterior a transação, onde nada foi executado;

 Consistência: uma Transação só executa se o estado do

Banco de Dados permanecer consistente após seu fim;
 Isolabilidade: sua necessidade surge em execuções
concorrentes, a intercalação das diversas transações que
ocorrem simultaneamente, não podem ser intercaladas de
forma a gerar um estado inconsistente;
 Durabilidade: quando ocorre falha no banco de dados, após a
execução com sucesso de uma transação, a durabilidade
garante por algum mecanismo a recuperação das
informações perdidas.

É responsabilidade do programador definir o modo

apropriado para manuseio de diversas transações tais que cada
uma preserve a consistência do banco de dados. Por exemplo,
16
 17

considere uma produção de carros, onde é retirada uma

quantidade de carros da fábrica e passada para o revendedor. O
programador deve definir um programa para retirar da fábrica e
outro para adicionar o carro ao revendedor. Sendo assim se um
programa for executado sem a execução do outro programa não
levara o Banco de Dados a um estado consistente.
A propriedade de atomicidade e durabilidade é também
responsabilidade do sistema de banco de dados – especialmente,
os componentes de gerenciamento de transações. Toda a
transação deve acontecer por inteiro, se acontecer algum
problema durante a transação o banco deve voltar ao estado de
consistência anterior para refazer esta transação incompleta.
Este estado de consistência anterior a uma transação incompleta
deve ser garantido pelo SGBD.
Enfim, quando as transações estão ocorrendo no banco
de dados podem causar a ele um estado inconsistente
dependendo da ordem de execução das mesmas. Sendo assim é
tarefa do gerenciador de controle que o banco continue em um
estado consistente de dados mesmo que as transações sejam
concorrentes.

17
 18

CAPITULO III
MODELOS DE DADOS

3.1 INTRODUÇÃO
A modelagem conceitual visa obter uma descrição
abstrata dos dados independente da implementação no SGBD.
Neste capitulo iremos citar vários exemplos de modelagem
começando pela modelagem de entidade relacionamento. Iremos
verificar a definição do modelo lógico e também a modelagem
UML padrão.

3.2 MODELO DE ENTIDADE E RELACIONAMENTO

A técnica mais utilizada na modelagem de dados é a
abordagem entidade-relacionamento (ER). Nesta técnica o
modelo ER é representado graficamente, através de um
diagrama entidade relacionamento (ER). Neste tópico estaremos
apresentando conceitos centrais da modelagem ER e modelagem
ER estendida: entidade, relacionamento, atributo,
generalização/especialização e entidade associativa.

3.2.1 ENTIDADE
Entidade é um conjunto de objetos da realidade, sobre os
quais se deseja manter informações no banco de dados. Uma
entidade pode representar tanto objetos concretos da realidade
como uma pessoa ou abstratos como um departamento.
Em um DER (Diagrama de Entidade e Relacionamento)
o conjunto de entidades é representada por um retângulo que

18
 19

contém o nome do conjunto representado pela figura 1.1. Cada

ocorrência neste conjunto em particular recebe o nome de
entidade.
Caso referenciar uma entidade em particular disse que é
uma ocorrência de entidade ou instancia.
Usuário
Figura 1.1 Exemplo de Entidade.

3.2.2 RELACIONAMENTO

3.2.2.1 CONCEITO
O relacionamento é caracterizado pela associação entre
objetos, ou seja, o relacionamento é um conjunto de associações
entre entidades que também deve ser mantido pelo banco de
dados.
No DER o relacionamento é representado por um
losango ligado por linhas que se conectam aos retângulos dos
conjuntos de entidades relacionadas representado pela figura
2.1.
U C

Figura 2.1 Exemplo de relacionamento

Um relacionamento pode ser mantido com outra entidade

ou com a mesma entidade caracterizando um auto-
relacionamento demonstrado pela figura 2.2.

19
 20

P essoa

C
as
ad
os
Figura 2.2 Auto Relacionamento

Uma associação em particular é denominada de

ocorrência de relacionamento.
Para facilitar a visualização dos relacionamentos pode-se
fazer um diagrama de relacionamentos. Onde a ocorrência de
entidades é representada por círculos brancos e ocorrências de
relacionamento por círculos negros como na figura 2.3. As
ocorrências de entidades participantes de uma ocorrência de
relacionamento são indicadas pelas linhas que ligam o círculo
negro representativo da ocorrência de relacionamento dos
círculos brancos representativos das ocorrências de entidades
relacionais.
p2 p3
p1 p4 p5

p1. p3.
p2 p5

Figura 2.3 Exemplo de Diagrama de Ocorrências

3.2.2.2 CARDINALIDADE DE RELACIONAMENTO

20
 21

Cardinalidade (mínima, máxima) de entidade

relacionamento é o número (mínimo, máximo) de ocorrências de
entidade associadas a uma ocorrência da entidade em questão
através do relacionamento.
A cardinalidade pode ser de dois tipos como citado:
máxima ou mínima.
 Cardinalidade máxima: é caracterizada pela máxima
quantidade de entidades que pode relacionar com a outra
entidade envolvida no relacionamento. A cardinalidade é
anotada do outro lado outro lado do relacionamento a qual se
refere;
 Cardinalidade mínima: é o número mínimo de entidades que
são associadas a uma entidade através de um
relacionamento. A cardinalidade mínima “1” também recebe
o nome de “associação obrigatória” e a cardinalidade
mínima “0” recebe o nome de “associação opcional”. A
cardinalidade mínima é anotada junto com a cardinalidade
máxima no Diagrama de Entidade Relacionamento como no
exemplo da figura 2.4.

(0 ,N ) (1 .1 )
Po

P essoa C a rg o
ss
ui

Figura 2.4 exemplo de cardinalidade

3.2.2.3 RELACIONAMENTOS BINÁRIOS

Os relacionamentos são caracterizados pelo número de
ocorrências de entidades que participam de cada ocorrência do
relacionamento. Um relacionamento binário é aquele que só
participam duas entidades.

21
 22

Podemos classificar os relacionamentos binários em:

N:N (muitos-para-muitos), 1:N ( um-para-muitos) e 1:1 (um-
para-um).
Uma relação N:N é caracterizada por uma entidade de
um conjunto relacionada com muitas entidades do outro
conjunto e vice-versa. Este relacionamento é claramente
expressado pela associação de professores que lecionam um tipo
de matéria, pois um professor pode lecionar varias matérias e
uma matéria pode ser ensinada por vários professores. Segue
como a figura 2.5:

(1 ,N ) (1 .N )
Le na

P ro fe s s o r M a té r ia
ci
o

Figura 2.5 Representação de uma cardinalidade N:N

Uma relação 1:N é caracterizada por uma entidade de um

conjunto relacionada com muitas entidades do outro conjunto
mas cada entidade do deste conjunto só pode se relacionar com
uma entidade do primeiro conjunto em pertencente a este
relacionamento. Exemplo deste tipo de relacionamento é o caso
de caracterização de tipo de produto de um supermercado. Um
produto pertence a apenas um tipo e um tipo possui vários
produtos. Segue a figura 2.6 como um exemplo representado no
DER.

(0 ,N ) (1 .1 )
Po ui

P ro d u to T ip o
ss

Figura 2.6 Exemplo de relacionamento 1:N.

Uma relação 1:1 é caracterizada por uma entidade

poder estar relacionada com apenas uma entidade do outro
22
 23

conjunto de entidades. Cada entidade deste conjunto só poderá

se relacionar com apenas uma entidade do primeiro conjunto
participante do relacionamento. Temos como exemplo deste tipo
de relacionamento a situação em que um funcionário pode
possuir apenas uma mesa em seu escritório e uma mesa só pode
pertencer a um funcionário. Um exemplo consta na figura 2.7

(0 ,1 ) (0 .1 )

Po ui
F u n c io n a r io M esa

ss
Figura 2.7 Exemplo de relacionamento 1 para 1

Na denominação do relacionamento caso não seja

nomeado seu nome será a concatenação do nome do conjunto de
entidades que estão envolvidas no relacionamento.

3.2.2.4 RELACIONAMENTOS TERNÁRIOS

O relacionamento ternário assim como o primário é
caracterizado pelo numero de ocorrências de entidade que
participam de cada ocorrência do relacionamento.
Vamos supor que três entidades façam parte deste
relacionamento A, B e C sendo assim a cardinalidade máxima
de A e B dentro do relacionamento indica quantas ocorrências de
C podem estar associadas a um par d ocorrências em A e B.

3.2.3 ATRIBUTOS
Os atributos descrevem as entidades e os
relacionamentos associando informações a eles. Um atributo
pode possuir uma cardinalidade, de maneira análoga a uma
entidade em um relacionamento isto define quantos valores
deste atributo podem estar associados a uma ocorrência da
entidade/relacionamento a qual ele pertence.

23
 24

Os atributos geralmente são representados por

circunferências ou elipses. Veja na figura 2.8 e 2.9.

S exo S exo

N om e
N om e F u n c io n a r io
F u n c io n a r io

C PF

C PF
Figura 2.8 Figura 2.9
Atributos Atributos
caracterizados por
circunferências
caracterizados por
Elipses

3.2.3.1 IDENTIFICADOR DE ENTIDADE

Toda entidade deve possuir um identificador. Um
identificador é um conjunto de um ou mais atributos cujos
valores servem para distinguir uma ocorrência de entidade das
demais ocorrências.
O identificador pode ser simples, ou seja, ser apenas um
atributo ou pode ser composto possuindo mais de um atributo
identificador.
Os identificadores também podendo ser formados por
relacionamento identificador. Este tipo de identificador é
caracterizado quando o atributo identificador deriva do
relacionamento. Caso seja este o caso a entidade também é
julgada como sendo uma entidade fraca, pois apenas se a
entidade relacionada a ela existir ela existira.
No DER os atributos identificadores geralmente são
identificados por um círculo preto no caso do atributo podem ser
24
 25

representados por uma elipse e sublinhados. Exemplos são da

representação são mostrados na figura 2.10 e 2.11.
Todo identificador deve obedecer a duas propriedades:
1. O identificador deve ser mínimo: apenas o identificador
sozinho na entidade consegue distinguir aquela entidade entre o
conjunto qual ela pertence.
2. O conjunto identificador deve ser único. Em certos
casos diferentes atributos podem servir como identificadores
sendo assim cabe ao modelador definir qual vai ser o atributo
identificador da entidade.
S exo

F u n c io n a r io

C PF

S e xo

N om e F u n c io n a r io

C PF

Figura 2.10 atributo identificador CPF

2.11 Atributo identificador CPF

3.2.3.2 IDENTIFICANDO RELACIONAMENTOS

A princípio, uma ocorrência de relacionamento
diferencia-se das demais ocorrências do mesmo relacionamento
pelas ocorrências de entidades que dela participam.
25
 26

Assim, de forma geral, um relacionamento é identificado

pelas entidades que dele participam, bem como através dos
atributos identificadores eventualmente definidos.

3.2.4 MODELO ENTIDADE-RELACIONAMENTO

EXTENDIDO
MER estendido é um refinamento do Modelo de
Entidade Relacionamento. Possibilitando uma abstração de
dados representativa no nível conceitual.
Com o MER estendido pode-se usufruir do conceito de
generalização/especialização, entidade associativa, agregação e
também multiplicidade que agregam um maior entendimento do
modelo conceitual.

3.2.4.1 GENERALIZAÇÃO / ESPECIALIZAÇÃO

Generalização/Especialização significa que cada
ocorrência da entidade especializada possui, além de suas
próprias propriedades também as propriedades da ocorrência da
entidade genérica correspondente. Através deste conceito é
possível atribuir propriedades particulares a um subconjunto das
ocorrências.
No DER, o símbolo para representar a
generalização/especialização é geralmente representado por um
triângulo isósceles.
A generalização/especialização pode ser caracterizada
em dois tipos: total ou parcial.
 A generalização/especialização total: é caracterizada pelo
fato de que cada entidade pertencente a
generalização/especialização deve obrigatoriamente
pertencer a uma especialização da entidade;

26
 27

 A generalização/especialização parcial: as entidades podem

ou não pertencer a uma especialização da entidade.
No DER a generalização/especialização é caracterizada
por um t do lado do triângulo enquanto a parcial é caracterizada
por um p.
Podemos aplicar a generalização/especialização no
modelando a entidade funcionário. Um funcionário é
caracterizado pela sua profissão. Em uma empresa temos o
funcionário que é uma secretária, um médico, um motorista. O
medico possui CRN já o motorista possui a CNH e uma
secretária já não possui nem um dos dois atributos. Podemos
fazer uma entidade funcionário geral e a especialização serão as
entidades médico, motorista e secretária como descrito na figura
2.12
M e d ic o

S e c r e tá r ia P
M o to r is ta

F u n c io n a r io

Figura 2.12 Exemplo de especialização

3.2.4.2 ENTIDADE ASSOCIATIVA

Uma entidade associativa nada mais é que a redefinição
de um relacionamento que passa a ser tratado como se fosse
também uma entidade.
É demonstrado no DER como um retângulo desenhado
ao redor do relacionamento e indica que este relacionamento
passa a ser visto como uma entidade.
Exemplo de entidade associativa ocorre quando um
relacionamento se relaciona com outro relacionamento. Se um
27
 28

médico faz consultas com pacientes e cada consulta possui seus

medicamentos podemos usar a entidade associativa para torna a
consulta uma entidade e fazer um relacionamento entre a
entidade consulta com medicamento como na figura 2.13.

C lta
M e d ic o M e d ic o P a c ie n te

on
su
Pr içã
es
cr o
M e d ic a m e n to

Figura 2.13 Descrição da entidade associativa

3.2.4.3 AGREGAÇÃO
Permite que um conjunto de entidades que se relacionam,
sejam consideradas como uma entidade distinta. Por exemplo,
um usuário que possui um cargo, ou seja, uma entidade cargo se
relaciona com a entidade usuário tendo em vista uma agregação
que se relaciona com departamento. Sendo assim o usuário que
possui tal cargo se relacionara com departamento como na
figura 2.14.
Po ui

F u n c io n a r io C a rg o
ss
Po ui
ss

D e p a rta m e n to

Figura 2.14 Representação da Agregação

28
 29

3.2.4.4 MULTIPLICIDADE
Este conceito indica a cardinalidade mínima e máxima
de um relacionamento entre parêntese do lado oposto da
entidade. O primeiro número indica a relação mínima no caso de
zero como já vimos é uma relação opcional no caso de um a
relação é obrigatória. O segundo número indica a relação
máxima de muitos ou apenas um.

3.3 PROPRIEDADES DE MODELOS ENTIDADE-

RELACIONAMENTO

3.3.1 MODELO FORMAL

O modelo ER é um modelo formal, ou seja, diferentes
leitores de um mesmo modelo ER devem entender exatamente o
mesmo.

3.3.2 EXPRESSÕES LIMITADAS

A linguagem dos modelos ER é pouco poderosa em
muitas propriedades, desejáveis do banco de dados, necessitam
ser anotadas adicionalmente ao DER. Assim para fazer com que
o modelo ER corresponda à realidade que se deseja modelar, é
necessário modificá-lo ou então definir restrições adicionais.
Haja vista que o projeto ER sirva apenas para projetar
um banco de dados caracterizando assim uma descrição abstrata
das estruturas do banco de dados somente são incluídas
construções em um modelo ER, quando estas possuem uma
correspondência no banco de dados a ser implementado

3.3.3 DIFERENTES MODELOS PODEM SER

EQUIVALENTES

29
 30

Dois modelos são equivalentes, quando geram o mesmo

esquema de banco, modelam a mesma realidade.

3.3.4 IDENTIFICANDO CONSTRUÇÕES

As construções da abordagem ER devem ser feitas
visando expressar a realidade do problema. Sendo assim o
modelador do modelo ER deve se inteirar do ambiente em que
se encontra a situação, a fim de modelá-lo.
Mesmo assim, existem alguns critérios que podem ser
usados na escolha de construções de modelagem.

3.3.4.1 ATRIBUTO VERSUS ENTIDADE RELACIONADA

Como devemos modelar um objeto como atributo de
uma entidade ou como entidade autônoma relacionada a essa
entidade.
Alguns critérios para decisão são: caso o objeto cuja
modelagem está em discussão esteja vinculado a outros objetos,
o objeto deve ser modelado como entidade, já que um atributo
não pode ter atributos, nem estar relacionado a outras entidades,
nem ser generalizado ou especializado.
Quando o conjunto de valores de um determinado objeto
é fixo durante toda a vida do sistema, ele pode ser modelado
como atributo visto que o domínio de valores de um atributo é
imutável. Quando houver transações no sistema, que alteram o
conjunto de valores do objeto, o mesmo não deve ser modelado
como atributo.

3.3.4.2 ATRIBUTO VERSUS

GENERALIZAÇÃO/ESPECIALIZAÇÃO
Modelar o objeto como atributo ou como especialização?
A especialização só deve ser usada quando se sabe que as

30
 31

classes especializadas de entidades possuem propriedades

particulares.

3.3.4.3 ATRIBUTOS OPCIONAIS E MULTI-VALORADOS

Os atributos podem ser opcionais (nem toda ocorrência
da entidade possui um valor do atributo) ou multivalorados.
Porém quando se inicia o processo de modelagem é
aconselhável tentar restringir-se ao uso de atributos obrigatórios
e mono-valorados pelas seguintes razões: geralmente atributos
opcionais indicam subconjuntos de entidades que são modelados
mais corretamente através de especializações. Os atributos
multivalorados não possuem implementação direta nos SGBDs
relacionais que seguem o padrão SQL/2, atributos
multivalorados podem induzir a um erro de modelagem, que é o
de ocultar entidades e relacionamentos em atributos multi-
valorados.

3.3.5 VERIFICAÇÃO DO MODELO

O modelo, para ser bom, tem que preencher uma série de
requisitos básicos, como ser completo, ser correto e não conter
redundâncias.

3.3.5.1 MODELO DEVE SER CORRETO

Uma modelagem deve ser feita corretamente de acordo
com as regras de modelagem conceitual. Os erros de modelagem
se dividem em dois tipos: erros semânticos e erros sintáticos.
 Erros Semânticos: São os erros que ocorrem na modelagem
do banco de dados como um relacionamento que não existe
ou um atributo que está na entidade errada. São também os
erros de interpretação passados para o modelo Entidade

31
 32

Relacionamento, que causam a reflexão da realidade de

forma inconsistente.
 Erros Sintáticos: São os erros que ocorrem nos modelos que
não respeitam as regras de modelagem relacional como é o
caso do modelo possuir um atributo relacionado com outro
atributo o que não é possível no modelo entidade
relacionamento.

3.3.5.2 MODELO DEVE SER COMPLETO

Deve representar a realidade tal qual ela é. Logo o
modelo precisa ter clareza na representação para refletir a
realidade. Deve responder a todas as perguntas em relação à
realidade que está sendo modelada moldada.

3.3.5.3 MODELO DEVE SER LIVRE DE REDUNDÂNCIA

O modelo deve ser mínimo, ou seja, livre de
redundâncias.
Um tipo de redundância comum é a de relacionamentos,
que acontece quando um relacionamento pode ser obtido por
outros relacionamentos que já estão feitos no modelo. Logo este
relacionamento pode ser eliminado do DER e não haverá perda
de informação.

3.3.5.4 MODELO DEVE REFLETIR O ASPECTO

TEMPORAL
Certas informações devem ficar armazenadas no banco
para manter um histórico de informações. O modelo deve ser
feito visando manter tal histórico para consulta e recuperação de
dados quando necessário.

32
 33

Haja vista atributos e relacionamentos modificados que

serão necessários em um futuro ou que precisaram contar com a
data de sua modificação para recuperação dos dados.

3.3.6 ENTIDADE ISOLADA E ENTIDADE SEM

ATRIBUTOS
A entidade isolada é a entidade que não apresenta
nenhum relacionamento com as demais entidades cadastradas no
modelo de entidade relacionamento. Esta entidade pode ter
como objetivo modelar a organização em qual o banco de dados
esta enquadrado.

3.3.7 ESTRATÉGIAS DE MODELAGEM

A modelagem não é feita em um único passo, ou seja,
deve se fazer o modelo e revisa-lo constantemente para que
possa refiná-lo obtendo a realidade que está sendo modelada.
Visando tal processo foram elaboradas algumas estratégias de
modelagem.
Para definir qual estratégia deve ser usada devemos focar
a fonte das informações do banco de dados. Iremos considerar
duas fontes: descrição dos dados existentes e o conhecimento
que pessoas possuem sobre o sistema.

3.3.7.1 PARTINDO DE DESCRIÇÃO DE DADOS JÁ

EXISTENTES
Considerando a existência de dados em arquivos
distintos iremos aplicar o processo de engenharia reversa, com
objetivo de obter uma especificação a partir de um produto já

33
 34

existente aplicando as regras de normalização. Esta estratégia

dá-se o nome de “botton-up” pois começa de conceitos mais
detalhados, como é o caso de dados contidos em arquivos, para
chegar a uma abstração total do modelo. Finalizando este
processo os atributos são agregados as entidades e as entidades
são relacionadas e generalizadas.

3.3.7.2 PARTINDO DO CONHECIMENTO DE PESSOAS

Este tipo de modelagem é aplicado quando o sistema é
novo e as únicas fontes de informação são as pessoas que
participam do cotidiano da realidade a ser modelada. Neste caso
podem se aplicar estratégias “top-down” e a “inside-out”.

3.3.7.3 ESTRATÉGIA “TOP-DOWN”

Esta estratégia caracteriza pela formação das
entidades com base nas informações fornecidas pelas pessoas
que iram usar o sistema e tem conhecimento da realidade que o
cerca logo após a criação das entidades são identificados os
atributos que serão agregados as entidades já implementadas. Ou
seja, um processo que se inicia e sofre refinamentos até compor
um modelo completo.

3.3.7.4 ESTRATÉGIA “INSIDE-OUT”

Estas estratégias definiram primeiramente as entidades
mais importantes.
Haja vista posteriormente estar refinando tais entidades
formando outras entidades e identificando atributos e
relacionamentos existentes no modelo que esta se formando.

3.4 ABORDAGEM RELACIONAL

34
 35

Iremos apresentar a modelagem relacional. Esta

modelagem visa a implementação direta no Banco de Dados.
Ela demonstra como as tabelas serão formadas e representadas
no banco de dados.

3.4.1 COMPOSIÇÃO DE UM BANCO DE DADOS

RELACIONAL
Um banco de dados relacional é composto por tabelas e
relações.

3.4.1.1 TABELAS
Uma tabela é composta por tuplas que são linhas de
registros e campos. Cada campo é identificado por um nome. O
conjunto de campos homônimo de todas as linhas de uma tabela
forma uma coluna.

Nome do Campo
Emp Coluna (atributo) (nome do atributo)
CodigoEmp Nome CodigoDepto CategFuncional
E1 luiz C4 32
E29 fernando C21 34 Linha (Tupla)
E7 Batista C8 34
E4 Loja C8

valor do campo
(valor do atributo)

Figura 4.1 Exemplo de tabela

3.4.1.2 CHAVES
Para distinguir uma linha das demais e estabelecer
relações com outras tabelas dentro do banco de dados foi criado
o conceito de chave. As chaves podem ser enquadradas em três
tipos: chave primária, chave alternativa e chave estrangeira.

35
 36

 Chaves Primárias: é uma coluna ou um conjunto de colunas

que identificam uma linha das demais dentro de uma tabela.
Esta deve ser mínima para este atributo, ou combinação de
atributos, sozinho deve distinguir a linha das demais;
 Chave Estrangeira: é uma ou um conjunto de colunas que
aparece necessariamente em uma chave primária de outra
tabela ou da mesma tabela. Este tipo de chave permite
implementar relacionamentos dentro do banco de dados;
 Chave Alternativa: é uma coluna ou um conjunto de colunas
que além da chave primária também podem distinguir este
registro dos demais registros existentes na tabela.

Chave Chave Chave Alternativa

Primaria Estrangeira
Emp
CodigoEmp Nome CodigoDepto CategFuncional CPF
E1 luiz C4 32 99372446168
E29 fernando C21 34 99396468674
E7 Batista C8 34 99646849754
E4 Loja C8 99396568769

Figura 4.2 Exemplos de chaves

3.4.1.3 DOMÍNIOS E VALORES VAZIOS

Para cada campo devemos definir que tipo de valores
eles irão aceitar. Os campos podem ser numéricos, alfa-
numérico, podem ser campos de imagens entre outros. Este
conjunto de valores é chamado de domínio da coluna ou
domínio do campo. É necessário especificar se os campos
poderão ter valores vazios ou não, ou seja, se os campos serão
ou não obrigatórios.

36
 37

3.4.1.4 RESTRIÇÕES DE INTEGRIDADE

Falar que um banco é integro significa dizer que os
dados estão íntegros e que refletem a realidade do banco de
dados corretamente caracterizando também a consistência entre
os dados, o que é fundamental para um SGBD. Tendo em vista a
integridade o SGBD oferece um mecanismo de restrição de
integridade. Uma restrição de integridade é uma regra de
consistência de dados. Elas se enquadram nas seguintes
categorias: integridade de domínio, integridade de vazio,
integridade de chave, integridade referencial.
 Integridade de domínio: Esta restrição estabelece que os
dados que ficarem nos campos possuirão o domínio pré-
estabelecido;
 Integridade de vazio: Esta restrição estabelece se um campo
será ou não obrigatório;
 Integridade de chave: Esta restrição estabelece que o valor
da chave primária e da chave alternativa deve ser único;
 Integridade referencial: Esta restrição estabelece que os
valores das chaves estrangeiras devem aparecer como sendo
chaves primárias em outras tabelas.
Existem também restrições que não são garantidas pelo
SGBD que são as restrições semânticas. Estas restrições são
caracterizadas pelo contexto em que o banco de dados esta
sendo tratado.

3.4.2 ESPECIFICAÇÃO DE BANCO DE DADOS

RELACIONAL
A especificação de um banco de dados relacional deve
conter tabelas que formam o banco de dados, colunas que as
tabelas possuem e restrições de integridade no mínimo.
Exemplo uma tabela de empregados:

37
 38

Emp(codigoEmp, Nome, CodigoDepto,

CategFuncional, CIC)
CodigoDept, referencia Dept.

3.4.3 CONSULTAS A BASE DE DADOS

Os dados que estão no banco são recuperados por
consultas SQLs realizadas no mesmo.
Na consulta SQL o programador não faz referência a
nenhum tipo de caminho de acesso. Quando mais de uma tabela
é referenciada na consulta a relação é estabelecida por Joins
entre as tabelas que são as relações entre chaves primárias e
estrangeiras.

3.5 MAPEAMENTO ENTRE MODELOS

A abordagem ER é voltada para uma modelagem de
dados de forma independente do SGBD enquanto a modelagem
MR é voltada para o SGBD relacional
Iremos apresentar como transforma um modelo
conceitual ER em um modelo lógico MR. Ou seja,
transformaremos um modelo mais abstratos de dados em um
modelo mais complexo e com mais detalhes na implementação.

3.5.1 MAPEAMENTO ENTRE O MODELO ER PARA

RELACIONAL
Devemos compor um esquema MR com uma boa
performance fazendo menos acessos a disco e que simplifique o
desenvolvimento e a manutenção de aplicações. Para isso são
definidas algumas regras de tradução.
 Evitar Junções: Obter os dados necessários e uma consulta
em uma única linha. Ou seja, uma vez encontrada a linha de

38
 39

uma tabela, seus campos deverão estar todos disponíveis

sem necessidade de acesso adicionais a disco.
 Diminuir o número de chaves: Tendo em vista diminuir o
consumo de espaço em disco e diminuir os acessos ao
mesmo a implementação tende a desenvolver um número
mínimo de chaves.
 Evitar campos opcionais: Campos opcionais são os campos
que aceitam valores vazios (null) logo tuplas que ficarem
vazias geraram uma ociosidade de espaço no banco de
dados. Além de gerar o problema no qual a obrigatoriedade
ou não do preenchimento de um campo depende do valor de
outros campos.
Sendo assim a transformação do ER para um MR se dão
nos seguintes passos: primeiro na tradução iniciais de entidades
e respectivos atributos, tradução de relacionamentos e
respectivos atributos e tradução de generalizações/
especializações, agregações.

3.5.1.1 IMPLEMENTAÇÃO INICIAL DE ENTIDADES.

Este passo é extremamente simples cada entidade é
traduzida em uma tabela e cada atributo em uma coluna desta
tabela. Os atributos identificadores formam a chave primária da
tabela.
3.5.1.2 NOMES DE ATRIBUTOS E NOMES DE COLUNAS
Para obter uma melhor performance, manutenção e
desenvolvimento não é aconselhável simplesmente transcrever
os nomes dos atributos para as colunas, pois as colunas serão
referenciadas pelos usuários do banco então devem ter nomes
sem espaços e de preferência nomes curtos.
Por exemplo, o atributo Código do Funcionário se torna:
codFun.

39
 40

3.5.1.3 RELACIONAMENTO IDENTIFICADOR

Quando a tabela possui um atributo identificador externo
a passagem dela para o modelo relacional não é tão simples. A
tradução de identificadores externos se da dá seguinte forma:
para cada identificador externo seja criada uma coluna, caso o
identificador seja composto varias colunas devem ser criadas, na
tabela em questão, coluna esta, ou estas, que irão compor a
chave primária da tabela em questão.
A tabela funcionário se relaciona com departamento
obtendo um identificador externo relacionado com
departamento. Devemos então criar uma coluna na tabela
funcionário que conterá a chave primária da tabela departamento
e fará parte da chave primária de funcionário.

3.5.1.4 IMPLEMENTAÇÃO DE RELACIONAMENTOS

Para determinar os relacionamentos temos que levar em
conta como fator principal a cardinalidade mínima e máxima
que está envolvendo o relacionamento.

3.5.1.4.1 TABELA PRÓPRIA

Nesta tradução o relacionamento se transforma em uma
tabela relacionada com as duas tabelas que compõe o
relacionamento.
Esta tabela criada é composta pelos atributos
identificadores de cada tabela do relacionamento formando sua
chave primária. Qualquer atributo pertencente ao
relacionamento será transformado em coluna.
Para exemplificar em um modelo de uma empresa temos
um funcionário fazendo varias funções estas funções por sua
vez podem ser executadas por vários funcionários. Neste caso

40
 41

criaríamos uma tabela chamada possui função com chave

primaria composta pelos atributos identificadores de cada
entidade envolvida no relacionamento neste caso as entidades
funcionário e função. Estas duas colunas criadas seriam nossa
chave primária e qualquer atributo pertencente a este
relacionamento, como por exemplo a data que o funcionário
ficou apto a realizar esta função, seria transformada em coluna
pertencente a esta tabela.

3.5.1.4.2 COLUNAS ADICIONAIS DENTRO DE TABELA

DE ENTIDADE
Esta é outra opção de implementação de relacionamento
onde o atributo do relacionamento é adicionado a uma das
tabelas que compõe o relacionamento.
Porém este tipo de tradução só é possível quando uma
das tabelas possui cardinalidade máxima “1” cujo qual será
adicionado os atributos do relacionamento e também os
atributos identificadores da outra tabela que participa do
relacionamento.
Tendo em vista que data de entrada no departamento
pertença ao relacionamento funcionário departamento podemos
adicionar a coluna data a tabela funcionário para modelar este
relacionamento.

3.5.1.4.3 FUSÃO DE TABELAS DE ENTIDADES

A terceira forma de implementar um relacionamento é
através da fusão das tabelas. Esta técnica só pode ser usada se o
relacionamento for de um para um.

3.5.1.5 DETALHES DA IMPLEMENTAÇÃO DE

RELACIONAMENTOS

41
 42

Como já foi mencionada a tradução dos relacionamentos

depende da cardinalidade das tabelas envolvidas no
relacionamento. Sendo assim iremos estabelecer algumas regras
de mapeamento dos relacionamentos existentes.

3.5.1.5.1 RELACIONAMENTOS 1:1

 Ambas as entidades tem participação opcional:
A preferência para tradução é a adição de colunas a uma
das tabelas do relacionamento em segundo caso a tradução para
uma tabela própria. Sendo que no segundo caso é mais vantajoso
apenas quando temos varias colunas opcionais no
relacionamento.
 Uma entidade tem participação opcional e a outra tem
participação obrigatória.
Neste caso é preferida a fusão das tabelas
correspondentes às duas entidades ou então a adição de colunas
a entidade que possui cardinalidade mínima “0”.
 Ambas as entidades tem participação obrigatória
Neste caso definitivamente a melhor tradução seria a
fusão entre as tabelas participantes do relacionamento.

3.5.1.5.2 RELACIONAMENTOS 1:N

No caso de relacionamentos 1:n a saída preferida é a
adição de colunas. Também pode verificar a viabilidade de
implementar este relacionamento através de tabela própria
porém não apresenta vantagens consideráveis para a
implementação da tradução citada.

3.5.1.5.3 RELACIONAMENTOS N:N

42
 43

Neste caso não importa a cardinalidade mínima a única

tradução viável é por tabela própria.

3.5.1.5.4 RELACIONAMENTOS DE GRAU MAIOR QUE

DOIS
Para a tradução de um relacionamento maior do que dois
faz-se da seguinte maneira: primeiramente transforma o
relacionamento em uma tabela que tem relação com as outras
tabelas do relacionamento adicionando a ela as chaves das
tabelas que participam do relacionamento. Logo, se aplica a
regra de relacionamento binária ao relacionamento formado pela
tabela criada.
3.5.1.6 IMPLEMENTAÇÃO DE
GENERALIZAÇÃO/IMPLEMENTAÇÃO
Este tipo de implementação é feito de duas maneiras: uso
de uma tabela para cada entidade ou uso de uma única tabela
para toda hierarquia de generalização/especialização.

3.5.1.6.1 UMA TABELA POR HIERARQUIA

Esta tradução tem em vista uma tabela para todas as
especializações formadas. Ou seja, todas as entidades são
fundidas em uma única tabela na hora da tradução.
A chave primária ira corresponder ao atributo
identificador da entidade mais genérica do relacionamento. Se
não existir uma coluna tipo para identificar o tipo da entidade à
mesma deve ser criada, deve ser definido uma coluna para cada
atributo da entidade genérica. Toda coluna que pertença a
entidade especializada deve ser adicionada traduzida como
coluna na tabela que esta sendo formada e devem ser todas
opcionais. As colunas de relacionamento da entidade genérica
devem continuar na tabela assim como as colunas que iram

43
 44

definir os relacionamentos das entidades especializadas que

deve também ser adicionada a tabela genérica, porém devem ser
opcionais.

3.5.1.6.2 UMA TABELA POR ENTIDADE

ESPECIALIZADA
Outra alternativa seria implementar uma hierarquia de
generalização/especialização criando uma tabela para cada
entidade que compõe a hierarquia, aplicando as regras
correspondentes à implementação do modelo entidade e
relacionamento já apresentadas nas seções anteriores.
Cada tabela formada pela especialização deve possuir a
chave primária da tabela genérica a fim de referenciá-la. Sendo
que esta chave deve ser a chave primária da especialização
criada. Tendo em vista que cada especialização terá uma linha
correspondente na tabela genérica formada.

3.5.2 COMPARAÇÃO ENTRE AS DUAS ALTERNATIVAS

DE IMPLEMENTAÇÃO
As vantagens da implementação por tabela única são que
não há necessidades de fazer junções para obter os dados das
tabelas referentes as especializações pois todas estão em uma
mesma tabela. Com isso a chave primária é armazenada apenas
uma vez evitando indexações desnecessárias.
As vantagens da implementação com uma tabela por
entidade especializada são que as colunas opcionais que
aparecem são apenas aquelas referentes a atributos que podem
ser vazios do ponto de vista da aplicação. O controle das
colunas opcionais passa a ser feito pela aplicação com base na
coluna tipo e não pelo SGBD.

44
 45

3.5.2.1 SUBDIVISÃO DA ENTIDADE GENÉRICA

Nesta alternativa cria-se uma tabela para cada entidade
especializada que não possua outra especialização. Sendo assim
cada entidade especializada será uma tabela, porém além de seus
atributos ela também levara consigo os atributos da entidade
geral. Com isso eliminara o problema das chaves indexadas,
porém para garantir a unicidade será necessário a verificação da
chave em todas as tabelas especializadas o que o SGBD não faz
sendo assim tem que ser implementado durante a aplicação.

3.5.2.2 REFINAMENTO DO MODELO RELACIONAL

Tendo em vista o ideal de implementação apresentado
nas ultimas seções temos que estar cientes que nem sempre será
possível estar implementando desta maneira para obter a melhor
performance. Sendo assim temos que buscar alternativas de
implementação que resulte em um melhor desempenho do
sistema. Baseados nesta afirmativa se propõem, apenas em
último caso, apresentamos algumas alternativas de
implementação que podem ser usadas.

3.5.2.3 RELACIONAMENTOS MUTUAMENTE

EXCLUSIVOS
Este caso a entidade participa de relacionamentos
mutuamente exclusivos, ou seja, a entidade que participa deste
relacionamento só participará de um deles. Então
implementaremos uma coluna na tabela do relacionamento que
será chave estrangeira das duas tabelas que se relacionam com
esta ao mesmo tempo. Tendo em vista que as tabelas não
poderão ter chaves primárias iguais.

45
 46

3.5.2.4 SIMULAÇÃO DE ATRIBUTOS MULTI-

VALORADOS
Haja vista um atributo multi-valorado podemos criar uma
tabela para o mesmo, cuja a chave estrangeira será a chave
primária da qual o atributo pertence.
3.5.2.5 INFORMAÇÕES REDUNDANTES
Tendo em vista uma redundância controlada podemos
dizer que alguns valores derivados poderiam ser implementados
nas tabelas como colunas tendo em vista que estes valores serão
utilizados com grande freqüência por consultas ao SGBD.

3.5.3 ENGENHARIA REVERSA DE MODELOS

RELACIONAIS
Um processo de engenharia reversa é caracterizado por
partir da forma implementada para chegar à forma conceitual,
ou seja, transformamos modelos ricos em implementação em
uma forma mais abstrata. Partimos do modelo lógico para
chegarmos num modelo conceitual.
Para obter o modelo conceitual faz-se necessário seguir
os seguintes passos: identificar as construções ER
correspondentes a cada tabela, definir relacionamentos e
cardinalidades 1:n , 1:1, ..., definir os atributos e finalmente
definir os identificadores das entidades e relacionamentos.

3.5.3.1 IDENTIFICAÇÃO DA CONSTRUÇÃO ER

CORRESPONDENTE A CADA TABELA
Devemos a principio identificar as tabelas do modelo
tendo em vista que cada tabela irá corresponder a uma entidade
ou um relacionamento N:N ou uma entidade especializada.
O fator determinante da construção do ER que
corresponde a uma tabela é a composição da chave primária.
46
 47

 Chave primária composta por mais de uma chave estrangeira

A tabela possui uma chave primária composta por chaves
estrangeiras de varias tabelas caracterizando um relacionamento
N:N entre as entidades correspondentes das chaves estrangeiras.
 Toda chave primária é uma chave estrangeira
A tabela que possui uma chave primária como sendo uma
chave estrangeira é uma especialização.
 Demais casos.
Quando a tabela não corresponde às especificações
citadas acima então caracterizamos a tabela como sendo uma
entidade.

3.5.3.2 IDENTIFICAÇÃO DE RELACIONAMENTOS 1:N

OU 1:1
Toda chave estrangeira que não faz parte de uma chave
primária composta por múltiplas chaves estrangeiras, nem é toda
ela uma chave primária, representa um relacionamento 1:n ou
1:1. Logo podemos determinar o relacionamento porém não
podemos determinar qual cardinalidade existe entre as tabelas
sem analisar os dados contidos nas mesmas. Sendo assim após a
verificação dos dados contidos nas tabelas pertencentes ao
relacionamento podemos definir a cardinalidade.

3.5.3.3 DEFINIÇÃO DE ATRIBUTOS

Nesta fase, cada coluna de uma tabela, que não seja
chave estrangeira, é definida como atributo na
entidade/relacionamento correspondente à tabela. É importante
frisar que as chaves estrangeiras não possuem correspondentes
no diagrama ER.

47
 48

3.5.3.4 DEFINIÇÃO DE IDENTIFICAÇÃO DE

ENTIDADES
No último passo da engenharia reversa é a definição dos
identificadores que se caracteriza da seguinte maneira.
 Coluna da chave primária que não é chave estrangeira
Toda coluna que corresponde a chave primária, mas não
é chave estrangeira corresponde a um atributo identificador no
modelo ER.
 Coluna da chave primária que não é estrangeira
Toda coluna que faz parte da chave primária e que é
chave estrangeira corresponde a um identificador externo da
entidade.

3.6 ENGENHARIA REVERSA DE ARQUIVOS E

NORMALIZAÇÃO
Um modelo conceitual pode ser de grande valia quando
fazemos manutenções rotineiras de software de um sistema de
informações. Neste caso, o modelo conceitual pode ser usado
como documentação abstrata dos dados durante discussões entre
usuários, analistas e programadores. A existência de um modelo
conceitual permite que pessoas que não conheçam o sistema
possam aprender mais rapidamente sobre seu funcionamento.
O modelo conceitual também pode ser usado para
migração do banco de dados para uma nova plataforma de
implementação, por exemplo, usando um SGBD relacional. A
disponibilidade de uma documentação, na forma de um modelo
conceitual dos dados do sistema existente, pode acelerar em
muito o processo de migração, pois permite encurtar a etapa de
modelagem de dados do novo banco de dados.

48
 49

Sendo assim apresentaremos as formas normais

aplicadas na engenharia reversa.

3.6.1 VISÃO GERAL DO PROCESSO DE ENGENHARIA

REVERSA
O primeiro passo é a descrição dos arquivos que compõe
o sistema existente na forma de um esquema de tabelas
relacionais não normalizadas visando à descrição, independente
do tipo de arquivo que está sendo utilizado. Dai em diante o
processo trabalhara apenas com tabelas relacionais, que o torna
independente do tipo de arquivo que está sendo usado como
entrada ao processo de normalização.
A partir deste modelo não normalizado nos aplicaremos
às regras normais para obter o sistema conceitual. As regras
normais visam reagrupar informações de forma a eliminar
redundâncias de dados e podem ser aplicados a qualquer modelo
relacional que se deseje normalizar.

3.6.2 REPRESENTAÇÃO NA FORMA DE TABELA NÃO

NORMALIZADA
Tendo em vista transformar o sistema de arquivos em um
modelo relacional não normalizado, cada arquivo será
transformado em uma entidade a ser normalizada
posteriormente.
3.6.3 NORMALIZAÇÃO
Obtido o esquema não normalizado iremos aplicar as
regras normais para que ele se tornasse o modelo conceitual
ideal. Este conceito baseia-se no conceito de forma normal. Uma
forma normal é uma regra que deve ser obedecida por uma
tabela para que esta seja considerada “bem projetada”. Vamos

49
 50

verificar as formas normais: primeira, segunda, terceira e quarta

forma normal.

3.6.3.1 PASSAGEM À PRIMEIRA FORMA NORMAL

Diz-se que a tabela está na primeira forma normal se ela
não contém tabelas aninhadas[2]. Logo eliminaremos as tabelas
aninhadas na passagem para a primeira forma normal.
Temos duas alternativas para passar a tabela para a
primeira forma normal
 Construir uma única tabela com redundância de dados
Cria-se uma tabela cujos dados das linhas externas à
tabela aninhada são repetidos para cada linha da tabela
aninhada.
 Construir uma tabela para cada tabela aninhada
Cria-se uma tabela referente à própria tabela que está
sendo normalizada e uma tabela para cada tabela aninhada.
Para construir uma tabela para cada tabela aninhada
devemos criar uma tabela na 1FN referente a tabela não
normalizada e que contenha apenas as colunas com valores
atômicos. Sua chave deve ser idêntica a chave da tabela não
normalizada.
Para cada tabela aninhada é criada uma tabela na 1FN
composta pela chave primária de cada tabela na qual a tabela em
questão está aninhada e as colunas da própria tabela aninhada,
logo são definidas as chaves primárias das tabelas na 1FN que
correspondem a tabelas aninhadas.
Para determinar a chave primária de uma tabela na 1FN
que corresponda a uma tabela aninhada na forma ÑN devemos
tomar como parte da chave primária da tabela na 1FN a chave
primária da tabela ÑN e verificar se esta chave primária é
suficiente para identificar as linhas da tabela na 1FN. Caso seja

50
 51

suficiente, a chave primária da tabela na 1FN é a mesma que a

da tabela aninhada na forma ÑN caso contrário deve-se
determinar quais as demais colunas que são necessárias para
identificar as linhas da tabela na 1FN compondo assim a chave
primária na 1FN.

3.6.3.2 DEPENDÊNCIA FUNCIONAL

Definimos dependência funcional quando para cada
coluna de A existe um valor e para cada vez que este valor
aparece nesta coluna existe uma coluna em B com o mesmo
valor. Ou seja, para cada coluna existente em A dependente de B
haverá um valor correspondente em B que repetira.

3.6.3.3 PASSAGEM À SEGUNDA FORMA NORMAL

(2FN)
O objetivo é eliminar certas redundâncias de dados.
Logo para estar na segunda forma normal a tabela também deve
estar na primeira forma normal e cada coluna da tabela fica
dependente da chave primaria completa. Uma tabela que não se
encontra na segunda formal contém dependências funcionais
parciais, ou seja, contém colunas não chave que dependem
apenas de uma parte da chave primária [1].
Vale lembrar que tabelas compostas apenas por uma
chave primária simples já estão na segunda forma normal, pois
sua chave é composta por apenas um único atributo.
O processo de passagem da 1FN a 2FN é feito da
seguinte maneira:
 Copiar para a 2FN cada tabela que tenha chave primária
simples ou que não tenha colunas além chave.
 Para cada tabela chave primária composta e com pelo menos
uma coluna não chave:

51
 52

1. Criar na 2FN uma tabela com as chaves primárias da tabela

na 1FN
2. Para cada coluna não chave fazer a seguinte pergunta:
“A coluna depende de toda a chave ou de apenas
parte dela?”
Caso a coluna dependa de toda a chave deve-se criar a
coluna correspondente na tabela com a chave completa na 2FN.
Caso a coluna dependa apenas de parte da chave deve-se
criar, caso ainda não existir, uma tabela na 2FN que tenha como
chave primária à parte da chave que é determinante da coluna
em questão e formar a coluna dependente dentro da tabela na
2FN.

3.6.3.4 PASSAGEM À TERCEIRA FORMA NORMAL

(3FN)
Na passagem para terceira forma normal eliminaremos
outras redundâncias. Desta vez devemos eliminar as
dependências funcionais transitivas ou indiretas. Isso ocorre
quando temos uma coluna não chave primária que dependa de
outra coluna não chave primária ou de um conjunto de colunas.
Uma tabela encontra-se na terceira forma normal,
quando além de estar na segunda forma normal, não contém
dependências transitivas.
O processo de passagem da 2FN para a 3FN é feito como
se segue:
 Copiar para o esquema na 3FN cada tabela que tenha menos
que duas colunas não chave, pois neste caso não há como
haver dependências transitivas.
 Para tabelas com duas ou mais colunas não chave:
1. Criar uma tabela no esquema da 3FN com a chave primária
da tabela em questão.

52
 53

2. Para cada coluna não chave fazer a seguinte pergunta:

“A coluna depende de alguma outra coluna que não seja
chave?“
Caso a coluna dependa apenas da chave deve-se copiar a
coluna para a tabela na 3FN.
Caso a coluna depender de outra coluna deve-se criar,
caso ainda não exista, uma tabela no esquema 3FN que tenha
como chave primária a coluna da qual há dependência indireta.
Copiar a coluna dependente para a tabela criada e a coluna
determinante deve permanecer também na tabela original.

3.6.3.5 PASSAGEM À QUARTA FORMA NORMAL

Na maioria dos casos até a terceira regra normal já é
suficiente para determinar o modelo de entidade relacionamento.
Na quarta forma normal eliminaremos a dependência
funcional multi-valorada que é caracterizada por uma coluna ou
conjunto de colunas que depende multi-valoradamente de uma
coluna da mesma tabela quando um valor do atributo
determinante identifica repetidas vezes um conjunto de valores
na coluna dependente.
Logo uma tabela está na 4FN caso, além de estar na 3FN,
não possua mais que uma dependência funcional multi-valorada.
Para colocar na 4FN devemos decompor as tabelas que
possuem dependências multi-valoradas em tabelas que não
possuam a dependência.

3.6.4 PROBLEMAS DA NORMALIZAÇÃO

Vamos discutir os problemas que poderão ocorrer no
processo de normalização.

53
 54

3.6.4.1 CHAVES PRIMÁRIAS OMITIDAS OU

INCORRETAS
Podemos dizer que a chave primária não é obrigatória
nos arquivos, logo encontraremos arquivos que não possuam
chave primária, neste caso é necessário inseri-la, tratando o
arquivo com mais um campo, que é o da chave que acaba de ser
inserida.

3.6.4.2 ATRIBUTOS RELEVANTES IMPLICITAMENTE

REPRESENTATIVOS
No caso da própria ordenação do arquivo representar
uma informação devemos inserir uma coluna para controlar este
tipo de atributo que ficara perdido na normalização se não for
tratado corretamente.

3.6.4.3 ATRIBUTOS IRRELEVANTES, REDUNDANTES

OU DERIVADOS
Atributos podem aparecer em arquivos convencionais de
forma implícita, na forma de ordenação de registros ou de listas,
na forma de ponteiros físicos etc. Quando esta situação ocorre
deve-se proceder como se o atributo aparecesse explicitamente
no documento.
3.6.4.4 INTEGRAÇÃO DE MODELOS
A normalização de cada um dos arquivos ou documentos
de um sistema conduz à definição de um conjunto de tabelas. O
passo seguinte da engenharia reversa é o de integrar os modelos
obtidos para cada arquivo no modelo global do banco de dados.
Esse processo é conhecido por integração de visões ou
integridade de esquemas.
Esse processo tem dois objetivos:

54
 55

1. Os atributos de uma mesma entidade podem estar

armazenados em diferentes arquivos. Após o processo de
normalização, estes atributos aparecem como colunas em
diferentes tabelas. O processo de integração de visões
objetiva juntar estas tabelas em uma única tabela que
representa a entidade ou relacionamento em questão.
O processo de normalização garante que cada tabela, se
considerada isoladamente, esteja livre de redundâncias de dados.
Entretanto, certos casos de redundâncias de dados entre tabelas
podem ainda permanecer e devem ser eliminados durante o
processo de integração de visões.

55
 56

CAPÍTULO IV
FUNDAMENTOS DE ENGENHARIA DE
SOFTWARE

4.1 INTRODUÇÃO
Sistemas informatizados têm enorme potencial de trazer
benefícios. Têm também enorme potencial de trazer prejuízos,
quando feitos de forma errada. O software é a alma dos sistemas
informatizados, e a engenharia de software tem como objetivo a
construção de produtos reais a partir dos conceitos fundamentais
da informática. Apresentaremos características básicas da
engenharia de software junto à metodologia que está sendo
usada no projeto.

4.2 PROCESSO DE SOFTWARE

Um processo de software pode ser visto como um
conjunto de atividades, métodos, ferramentas e práticas que são
utilizadas para construir um produto de software. Na definição
de um processo de software devem ser consideradas as seguintes
informações: atividades a serem realizadas, recursos
necessários, artefatos requeridos e produzidos, procedimentos
adotados e o modelo de ciclo de vida utilizado.

4.3 MÉTODOS DE DESENVOLVIMENTO.

56
 57

Com a preocupação de processos que deveriam ser

utilizados no desenvolvimento dos sistemas. Diversos modelos
foram criados e vêm sendo aprimorados ao longo do tempo.
Estes modelos são conhecidos como métodos de
desenvolvimento de sistemas ou SDM (acrônimo em inglês).
Alguns métodos de desenvolvimento são:
 Desenvolvimento em cascata;
 Desenvolvimento utilizando prototipagem;
 RAD - Rapid Application Development (Desenvolvimento
rápido de aplicações);
 Desenvolvimento em espiral;
 Desenvolvimento incremental e interativo.
Este projeto está usando a metodologia do
desenvolvimento incremental e interativo utilizando UML e
padrões.

4.4 PROCESSO INCREMENTAL E ITERATIVO

O desenvolvimento deste aplicativo de objetivo didático
é uma grande tarefa que pode ser estendida por vários anos. Por
isso, é mais prático dividir o trabalho em “pedaços” menores ou
iterações. Cada iteração resultará num incremento. Iterações são
passos em fluxo de trabalho e incrementos são crescimentos do
software. O processo iterativo se baseia no aumento e no
refinamento sucessivo de um sistema através de múltiplos ciclos
de desenvolvimento de análise, de projeto, de implementação e
teste. Ou seja, a principal conseqüência da aproximação iterativa
é que os produtos finais de todo o processo vão sendo
amadurecidos e completados ao longo do tempo, mas cada
iteração produz sempre um conjunto de produtos finais.
Algumas vantagens do processo incremental e interativo
são:

57
 58

 Possibilidade de avaliar mais cedo os riscos e pontos críticos

do projeto, e identificar medidas para eliminar ou controlar;
 Redução dos riscos envolvendo custos a um único
incremento. Se os alunos que desenvolvem o software
precisarem repetir a iteração, o projeto perde somente o
esforço mal direcionado de uma iteração, não o valor de um
produto inteiro;
 Definição de uma arquitetura que melhor possa orientar todo
o desenvolvimento;
 Disponibilização natural de um conjunto de regras para
melhor controlar os inevitáveis pedidos de alterações
futuras;
 Permite que os vários intervenientes possam trabalhar mais
efetivamente pela interação e partilha de comunicação daí
resultante.
O processo incremental e interativo juntamente com a
utilização de UML como linguagem de apresentação, uso do
paradigma orientado a objeto, a centralização em requisitos e
casos de uso e ainda a utilização de padrões de projeto. Define a
metodologia completa que está sendo trabalhada no projeto.

4.4.1 UTILIZAÇÃO DE UML COMO LINGUAGEM DE

APRESENTAÇÃO

4.4.1.1 UML
A UML (Unified Modeling Language ou Linguagem de
Modelagem Unificada) é uma linguagem para modelagem visual
utilizada para modelar sistemas computacionais por meio do
paradigma de Orientação a Objetos.
O objetivo da linguagem é auxiliar os desenvolvedores a

58
 59

definir as características do software, tais como seus requisitos,

seu comportamento, sua estrutura lógica, a dinâmica de seus
processos e até mesmo suas necessidades físicas em relação ao
equipamento sobre o qual o sistema deverá ser implantado.

4.4.1.2 DIAGRAMAS
Os diagramas são formas visuais de representar a UML
de maneira simples e de fácil compreensão.
A UML é composta por vários diagramas com o intuito
de dar múltiplas visões do sistema a ser modelado, analisando-o
e modelando-o sob diversos aspectos, procurando-se assim
atingir a plenitude da modelagem, permitindo que cada
diagrama complete os outros.

4.4.1.3 DIAGRAMAS DE CLASSES

Como o próprio nome diz, este diagrama define a
estrutura das classes utilizadas pelo sistema, determinando os
atributos e métodos possuídos por cada classe, além de
estabelecer como as classes se relacionam e trocam informações
entre si.

4.4.1.4 DIAGRAMAS DE CASOS DE USO

O Diagrama de Casos de Uso é o diagrama mais geral e
informa da UML, sendo utilizado normalmente nas fases de
Levantamento e Análise de Requisitos do sistema.
Apresenta uma linguagem simples e de fácil
compreensão para que os usuários possam ter uma idéia geral de
como o sistema irá se comportar. Procuram identificar os atores
(usuários, outros sistemas ou até mesmo algum hardware
especial), que utilizarão alguma forma o software, bem como os
serviços, ou seja, as opções , que o sistema disponibilizará aos

59
 60

atores.
4.4.1.5 DIAGRAMA DE MÁQUINA DE ESTADOS
Este diagrama procura acompanhar as mudanças sofridas
por um objeto dentro de um determinado processo. O diagrama
de Estados é utilizado normalmente para acompanhar os estados
por que passa uma instância de uma classe, no entanto pode ser
utilizado para representar os estados de um caso de uso ou
mesmo os estados gerais de um sub-sistema ou de um sistema
completo.

4.4.1.6 DIAGRAMA DE IMPLANTAÇÃO

O Diagrama de Implantação determina as necessidades
de hardware do sistema, as características físicas como
servidores, estações, topologias e protocolos de comunicação,
ou seja, todo o aparato físico sobre o qual o sistema deverá ser
executado.

4.4.1.7 DIAGRAMAS DE SEQÜÊNCIA

O diagrama de Seqüência preocupa-se com a ordem
temporal em que as mensagens são trocadas entre os objetos
envolvidos em um determinado processo.
Um diagrama de seqüência costuma identificar o evento
gerador do processo modelado, bem como, o ator responsável
por este evento e determina como o processo deve se desenrolar
e ser concluído por meio da chamada de métodos disparados por
mensagens enviadas entre os objetos.

4.4.1.8 DIAGRAMA DE COMUNICAÇÃO

Esse diagrama está amplamente associado ao Diagrama
de Seqüência, na verdade, um complementa o outro. As
informações mostradas no Diagrama de Comunicação são, com

60
 61

freqüência, praticamente as mesmas apresentadas no Diagrama

de Seqüência, porém com um enfoque diferente, visto que este
diagrama não se preocupa com a temporalidade do processo,
concentrando-se em como os objetos estão vinculados e quais
mensagens trocam entre si durante o processo.

4.4.1.9 DIAGRAMAS DE OBJETOS

O Diagrama De Objetos fornece uma visão dos valores
armazenados pelos objetos de um Diagrama de Classes em um
determinado momento da execução de um processo do software.
4.4.1.10 DIAGRAMA DE ATIVIDADES
O Diagrama de atividades concentra-se na representação
do fluxo de controle de uma atividade preocupando-se em
descrever os passos a serrem percorridos para a conclusão de
uma atividade específica, muitas vezes representada por um
método com um certo grau de complexidade e não de um
processo completo.

4.4.1.11 DIAGRAMA DE COMPONENTES

Esse diagrama representa os componentes do sistema
quando este for ser implementado em termos de módulos de
código-fonte, bibliotecas, formulários, arquivos de ajuda,
módulos executáveis. E determina como esses componentes
estarão estruturados e interagirão para que o sistema funcione de
maneira adequada.

4.4.2 USO DO PARADIGMA ORIENTADO A OBJETO

O paradigma Orientado a Objeto nos da à possibilidade

de implementarmos um sistema o mais próximo da realidade
que seja robusto, fácil de se manter e como características como
portabilidade, acopabilidade, maneabilidade e adaptabilidade.
61
 62

Também podemos constatar que tal paradigma ajuda na

reutilização de código. Com isso podemos agilizar o
desenvolvimento de tal sistema.

4.4.3 CENTRALIZAÇÃO EM REQUISITOS E CASOS DE

USO

4.4.3.1 REQUISITOS
Nesta etapa, o desenvolvedor busca compreender as
necessidades do usuário e o que ele deseja que o sistema a ser
desenvolvido realize. Sendo assim o desenvolvedor tentara
levantar o máximo de informações possíveis sobre o sistema a
ser desenvolvido visando uma compreensão do problema
existente para que segue desenvolvido um sistema que resolva
tal necessidade.
Os requisitos são geralmente divididos em requisitos
funcionais e não funcionais.
 Os requisitos funcionais são: os requisitos determinados pelo
usuário, ou seja, aquilo que o usuário do sistema deseja que
o software faça independente da maneira com a qual o
programa executara esta função. Como, por exemplo, a
necessidade de emissão de notas fiscais ou que o software
gere um relatório com o lucro diário que a empresa está
tendo.
 Os requisitos não funcionais são: aquelas restrições nos
serviços do sistema, tais como tempo de resposta, segurança,
viabilidade, disponibilidade, normas, etc.

4.4.3.2 CASOS DE USO

O Caso de uso é um artefato de software utilizado na
análise e no planejamento do projeto. Um caso de uso descreve

62
 63

um conjunto de atividades de um sistema sob o ponto de vista de

seus atores. Sendo um modelo de descrição de requisitos para o
sistema. Os casos de uso podem ser estórias ou casos de
utilização do sistema.
Um caso de uso tem inicio quando o usuário faz uma
requisição ao sistema, ou seja quando ele interage com o
sistema. Quando isso acontece o ator é conectado ao símbolo
(geralmente uma elipse) do caso de uso por um caminho sólido
dando origem a um relacionamento ou associações.
As associações representam as interações ou
relacionamentos entre os Atores que fazem parte do diagrama,
entre os Atores e os Casos de Uso ou os relacionamentos entre
os Casos de Uso e outros Casos de Uso. Os relacionamentos
entre Casos de Uso recebem nomes especiais, como Inclusão,
Extensão e Generalização.

4.4.3.2.1 GENERALIZAÇÃO
O relacionamento Generalização é uma forma de
Associação entre Casos de Uso na qual existem dois ou mais
Casos de Uso com características semelhantes, apresentando
pequenas diferenças entre si.

4.4.3.2.2 INCLUSÃO
A Associação de Inclusão costuma ser utilizada quando
existe um serviço, situação ou rotina comum a mais de um Caso
de Uso. Quando isso ocorre, a documentação dessa rotina é
colocada em um Caso de Uso específico para que outros Casos
de Uso utilizem-se desse serviço, evitando-se descrever uma
mesma seqüência de passos em vários Casos de Uso.

4.4.3.2.3 EXTENSÃO

63
 64

Associações de Extensão são utilizadas para descrever

cenários opcionais de um Caso de Uso. Os Casos de Uso
estendidos descrevem cenários que somente ocorrerão em uma
situação específica, se uma determinada condição for satisfeita.

4.4.4 UTILIZAÇÃO DE PADRÕES DE PROJETO

Na tecnologia de objetos, um padrão é uma descrição
nomeada de um problema e sua solução que pode ser utilizado
em novos contextos.
Os desenvolvedores experientes em orientação a objetos
construíram um repertório tanto de princípios gerais quanto de
soluções idiomáticas que os guiam na criação de software. Esses
princípios e idiomas, se codificados em um formato estruturado,
descrevendo o problema e a solução e recebendo um nome,
podem ser chamados de padrões.
A utilização de padrões é importante para o tratamento
de possíveis erros que ocorrerão no decorrer do
desenvolvimento do sistema sendo que outros especialistas já
passaram pelo mesmo problema e relatam os métodos padrões
para a solução de tais problemas.
Como exemplo de um padrão a ser seguido, esta o
padrão GRASP (General Responsibility Assignment Software
Patterns).

4.4.4.1 PADRÃO GRASP

Um sistema orientado a objetos é composto de objetos
que enviam mensagens a outros objetos para completar
operações.
Existe uma grande variação na qualidade potencial do
projeto da interação entre objetos e da atribuição de
responsabilidades. Más escolhas conduzem a sistemas e

64
 65

componentes que são frágeis e difíceis de manter, de

compreender, de reutilizar, ou de estender. Uma implementação
habilidosa está fundamentada nos princípios cardinais do bom
projeto orientado a objetos. Alguns destes princípios, aplicados
durante a criação de diagramas de interação e/ou atribuição de
responsabilidades, estão codificados nos GRASP que são
padrões de Larman.

4.4.4.2 ESCOLHA DE RESPONSABILIDADE

Para determinarmos as responsabilidades devemos
considerar as seguintes perguntas para cada objeto: o que ele
deve fazer e o que ele deve conhecer.
As obrigações de conhecer possibilitam ele conhecer
itens que o permitem calcular, conhecer objetos relacionados,
conhecer dados encapsulados.
As obrigações de fazer podem ser fazer algo a si mesmo,
iniciar ações em outros objetos, controlar ou coordenar
atividades em outros objetos.
Como, por exemplo, uma conta deve conhecer seu saldo
e deve fazer seu relacionamento com o cliente.

65
 66

CAPÍTULO V
PARADIGMA DE ORIENTAÇÃO A OBJETO

5.1 CONCEITOS BÁSICOS

Conceitualmente, um programa pode ser construído em
torno do código ou em torno dos dados. Ou seja, alguns

66
 67

programas são escritos em função “do que acontece”, enquanto

outros são escritos em função “do que está sendo afetado”. São
esses dois paradigmas que governam a forma como os
programas são construídos. A primeira forma é chamada de
modelo orientado para o processo. Esse enfoque caracteriza um
programa como sendo uma série linear de passos, que formam o
código. O modelo orientado para o processo pode ser descrito
como o código atuando sobre os dados. Contudo à medida que
os programas se tornam maiores e mais complexos, os
problemas desse enfoque começam a se manifestar.
Para gerenciar a crescente complexidade, foi concebido o
segundo enfoque, chamado programação orientada a objetos. A
programação orientada a objetos organiza um programa em
torno de seus dados, ou seja, os objetos, e de um conjunto de
interfaces bem definidas para acesso a esses dados. Uma forma
de descrever um programa orientado a objetos é como sendo os
dados controlando o acesso ao código. Isso significa que o
programa é construído em função dos dados a serem
manipulados e dos métodos que manipulam esses dados. Juntos
os dados e os métodos procuram simular o comportamento dos
objetos do mundo real.
Os principais fundamentos do paradigma orientado a
objetos são:
 Objetos;
 Classes;
 Métodos;
 Abstração;
 Herança;
 Polimorfismo;
 Encapsulamento.

67
 68

5.2 OBJETOS
Por definição, um objeto pode ser entendido como
alguma coisa que exista que possua características, e que faz
algo. O objeto possui atributos (variáveis) e comportamento
(métodos), tal qual o mesmo objeto visto no mundo real. Estas
variáveis que representam os atributos dos objetos devem
possuir um domínio, elas podem ser números inteiros, números
reais, cadeias de caracteres, um único caractere, entre outros
tipos definidos por cada linguagem.
Com o desenvolvimento do programa vários objetos são
criados e finalizados pelo software. Quando um objeto é criado
dizemos que este objeto foi e quando ocorre a eliminação de um
objeto podemos dizer que ele foi finalizado. Também podemos
criar objetos que continuam existindo mesmo depois do termino
do programa que os criou chamado objeto persistente. Exemplo
deste tipo de objeto é quando criamos um objeto e colocamos
em um banco de dados ou em um arquivo.
Exemplo:
Ser humano é um Ser Vivo.
Ser vivo possui várias características como cor dos olhos,
cor do cabelo, idade, estatura, sexo, cor da pele entre outros
atributos. O humano se diferencia dos outros humanos pela
variação destes atributos, um é mais alto outro mais baixo,
alguns possuem olhos azuis, outros olhos verdes.

5.3 MÉTODOS
Os métodos são procedimentos pertencentes aos objetos
que manipulam seu comportamento alterando algum dos seus
atributos ou realizando alguma tarefa com os dados passados a
ele. Exemplo: O ser humano pode andar, nadar, comer, dormir,

68
 69

estudar entre outras coisas.

5.4 ABSTRAÇÃO
Abstração é uma forma de lidar com a complexidade. Ela
nos dá a possibilidade de ignorar detalhes para nos
concentrarmos nas características fundamentais dos objetos,
permitindo que os objetos sejam representados da forma que for
conveniente e mais interessante. Exemplo:
Ninguém pensa em si mesmo como sendo um conjunto
de dezenas de órgãos individuais. Quando pensamos nos seres
humanos, nós pensamos em um objeto bem definido que realiza
todas as suas funções vitais.
Essa abstração permite que nos, humanos, vivamos sem
nos preocupar como nosso corpo administra suas funções vitais
como digerir alimentos, absorver O2, podemos simplesmente
viver.
5.5 CLASSES
Podemos dizer que classes é o conjunto de todos os
elementos semelhantes, no nosso caso, objetos. Uma classe
define a estrutura e o comportamento (dados e código) que serão
comuns a um conjunto de objetos. Cada objeto de uma dada
classe contém a estrutura e o comportamento definidos pela
classe, como se a classe fosse um molde usado para estampar o
formato de cada um deles. Todo objeto pertence a uma
determinada classe tanto no mundo real quando no “mundo
virtual” (mundo descrito no programa). Este conceito é muito
importante para o paradigma Orientado a Objeto, tendo em vista
que ele permite a reutilização de código (Dedicar mais sobre o
assunto).
A declaração de uma classe é similar ao dos tipos
definidos pelo usuário no paradigma orientado para o processo.

69
 70

Neste paradigma é possível definir novos tipos, como por

exemplo, tipos compostos. No paradigma orientado a objetos
definimos as classes com seus atributos e métodos e as
utilizamos para instanciar o objeto.
Exemplo:

class Humano // criando uma classe

{
String nome;
String corCabelo;
String corOlhos;
int idade ;
}

5.6 ENCAPSULAMENTO
O encapsulamento é o mecanismo que permite agrupar
em uma única entidade o código e os dados que esse código
manipula. Tais elementos ficam assim protegidos contra
interferências externas e utilização inadequada.
Uma forma de pensar no encapsulamento é como um
envoltório protetor que impede que o código e os dados sejam
acessados arbitrariamente por outro trecho de código que esteja
definido fora do envoltório. O acesso ao código e aos dados que
ficam dentro do envoltório é rigidamente controlado por meio de
uma interface bem definida.

5.7 HERANÇA
Uma herança é um processo pelo qual um objeto adquire
as propriedades de outro objeto. A herança é o que viabiliza o
conceito de uma classificação hierárquica e também influencia

70
 71

na reutilização do código através da generalização.

Suponha que exista uma classe Seres Vivos, que seria a
super classe ou chamada classe base. Teríamos a classe
Humanos, que seria uma subclasse da super classe Seres Vivos.
Sendo assim, a classe, Humanos, herdaria todos os métodos e
atributos da classe Seres Vivos e só precisaria definir as
qualidades que o tornam único dentro de sua classe.

5.8 POLIMORFISMO
Polimorfismo significa muitas formas. Trata-se de uma
característica que permite que uma interface seja usada para uma
classe genérica de ações, sendo que a ação especifica em cada
caso é determinada pela exata natureza da situação. Ou seja o
objeto irá decidir que método irá utilizar dependendo da situação
que for colocada para ele.
O polimorfismo pode ser utilizado de duas maneiras:
Usando “sobrecarga de métodos” (overload), que é
caracterizada quando o método possui o mesmo nome porém
sua assinatura (numero e ou tipo de argumentos que é passado
para o método) é diferente. E quando o método sobrescreve um
método herdado da super classe, caracterizando um override.

5.9 HERANÇA, ENCAPSULAMENTO E

POLIMORFISMO ATUANDO JUNTOS
A herança, o encapsulamento e a polimorfismo
combinam se para produzir um ambiente de programação que dá
suporte ao desenvolvimento de programas muito mais robustos e
escaláveis do que o modelo orientado a processo.
Uma hierarquia de classes bem projetada é a base para
reutilização do código que representa um valioso patrimônio.

O encapsulamento permite melhorar as implementações

71
 72

com o passar do tempo. Desde que a interface pública das

classes seja respeitada, elas poderão continuar sendo utilizadas
sem rupturas.
O polimorfismo permite criar código limpo, legível,
robusto e lógico.
Aplicando os princípios da orientação a objetos da
maneira correta, as várias partes de um programa complexo
podem ser montadas formando um todo robusto, coeso e de fácil
manutenção.

72
 73

CAPÍTULO VI
LINGUAGEM DE PROGRAMAÇÃO JAVA

6.1. UM POUCO DE HISTÓRIA

A linguagem foi originalmente projetada em 1991, por
um time de programadores da Sun MicroSystems, liderados por
James Gosling, como uma linguagem de programação de
interface do usuário chamada Oak (carvalho, em inglês),
batizada dessa forma dada a existência de uma dessas árvores
em frente ao escritório de Gosling. Seria usada no
desenvolvimento de aplicativos complexos e avançados, para
aplicação em pequenos dispositivos eletrônicos, tais como
VCRs, telefones celulares, entre outros. Esses dispositivos eram
sistemas portáveis, distribuídos, e confiáveis, dirigidos aos
consumidores em geral. As primeiras tentativas de criação de
tais dispositivos receberam nomes como Digital Assistence e
Portable Data Assistents(PDAs).
Em 1994, a Sun começou a adaptar Oak para ser usado
para programação na Internet. Porém devido a problemas de
copyright, o Oak recebeu um novo nome: Java. Em maio de
1995, foi anunciado publicamente com o novo nome, Java. A
versão beta do Java Developers Kit (JDK) saiu em novembro de
1995, assim como a versão beta do browser da Netscape com
suporte para Java.

73
 74

Java é agora usada para criar páginas para Web

dinâmicas e conteúdo interativo com a ajuda de applets (mini
aplicativos feitos em Java que atuam em navegadores) e servlets
que geram conteúdos htmls dinâmicos e fazem conexão com
banco de dados, para o desenvolvimento de aplicações em larga
escala, para a funcionalidade de servidores Web, para prover
aplicações para dispositivos de consumo (telefones celulares,
pagers, microondas ...) etc.

6.2 CARACTERÍSTICAS
A linguagem Java exibe importantes características que,
em conjunto, a diferenciam de outras linguagens de
programação. Dentre as características principais da linguagem
se destacam alguns pontos-chave: é orientada a objetos,
independente de plataforma e de ótima performance, segurança
e com a vantagem de implementações multithreading.

6.2.1 ORIENTADA A OBJETOS

Java é uma linguagem puramente orientada a objetos,
pois, com exceção de seus tipos primitivos de dados, tudo em
Java são classes ou instâncias de uma classe. Atende a todos os
requisitos necessários para uma linguagem ser considerada
orientada a objetos, que, resumidamente, são: oferecer
mecanismos de abstração, encapsulamento e hereditariedade.

6.2.2 INDEPENDENTE DE PLATAFORMA

Java é uma linguagem independente de plataforma, ou
seja, os programas Java não são compilados para uma
plataforma de hardware específica, mas, sim para uma forma
intermediária de código destinada à maquina virtual Java,

74
 75

denominada JVM (Java Virtual Machine). O formato

intermediário é chamado de bytecodees, uma espécie de
linguagem de máquina da JVM que possui neutralidade de
arquitetura e utiliza instruções e tipos primitivos de tamanho
fixo, ordenação big-endian e uma biblioteca de classes
padronizada. A máquina virtual Java é, na verdade, um
interpretador de bytecodes para a plataforma na qual eles são
executados. Por ser possível implementar uma JVM para
qualquer plataforma, um mesmo programa Java pode ser
executado em qualquer arquitetura que disponha de uma JVM,
obtendo-se assim independência de plataforma.

C o d ig o J a v a C o d ig o J a v a é c r ia d o

C o d ig o J a v a é c o m p ila d o e
C o m p il a d o r
tra n s fo rm a d o e m b y te c o d e
p e lo c o m p ila d o r

J a v a B y te C o d e B y t e C o d e c r ia d o e m
lin g u a g e m d e m á q u in a

O b y t e c o d e é in t e r p r e t a d o e
t r a d u z id o p a r a o p r o c e s s a d o r
In te r p r e ta d o r d e B y te C o d e
c o m a s is n t r u ç õ e s n a t iv a s d a
m á q u in a h o s p e d e ir a d a
M a q u in a V ir t u a l J a v a

P ro c e s s a d o r e H a rd W a re

Fluxo do código Java.

6.2.3 SEM PONTEIROS

Java não possui ponteiros, isto é, Java não permite a
manipulação direta de endereços de memória nem exige que os
objetos criados sejam explicitamente destruídos, livrando os
programadores de uma tarefa complexa. Toda a manipulação de
75
 76

variáveis e objetos se dá por intermédio de referências. Além

disso, a JCM possui um mecanismo automático de
gerenciamento de memória conhecido como Atutomatic
Garbage Colelctor, que recupera a memória alocada para
objetos não mais referenciados pelo programador

6.2.4 DESEMPENHO
A linguagem Java foi projetada para ser compacta e
independente de plataforma e para a utilização em rede, o que
levou à decisão de ser interpretada por intermédio dos esquemas
de bytes. Sendo uma linguagem interpretada, sua performance é
razoável, não podendo ser comparada à velocidade de execução
de código nativo. Para superar essa limitação, várias JVCM
existentes dispõem de compiladores just int itme (JIT), capazes
de compilar os bytecodes em código nativo durante a carga do
programa, possibilitando uma melhora significativa na
performance dos programas Java , equiparando-os ao
desempenho obtido com programas nativos.

6.2.5 SEGURANÇA
Considerando a possibilidade de que as aplicações
possam ser obtidas através de uma rede, a linguagem Java
possui mecanismos de segurança que podem, no caso de applets,
evitar, por exemplo, qualquer operação no sistema de arquivos
da máquina-alvo, minimizando problemas de segurança. Tal
mecanismo é flexível o suficiente para determinar se uma applet
é considerada segura, especificando nesta situação diferentes
níveis de acesso ao sistema-alvo.

6.2.6 PERMITE MULTITHREADING

Java oferece recursos para o desenvolvimento de

76
 77

aplicações capazes de executar múltiplas rotinas

concorrentemente, possibilitando sua sincronização. Cada uma
dessas rotinas é como um fluxo de execução independente,
usualmente denominado thread. As threads são importante
recurso de programação para a construção de aplicações mais
sofisticadas.
Além das características comentadas, Java é também
uma linguagem bastante robusta que incentiva o controle
detalhado de erros. Oferece ainda tipos inteiros, ponto flutuante
e aritmética compatíveis com as especificações do IEEE e
compatibilidade com caracteres UNICODE: inclui mecanismos
de reflexão (determinação em tempo de execução dos tipos dos
objetos em uso, além de outras informações), sendo extensível
dinamicamente, além de ser naturalmente voltada para o
desenvolvimento de aplicações em rede ou aplicações
distribuídas.
Mesmo com tudo isso, o Java ainda é uma linguagem
sintática e estruturalmente simples, o que a torna uma linguagem
de programação única.

6.3 RECURSOS NECESSÁRIOS PARA

DESENVOLVIMENTO JAVA
Para trabalhar com o ambiente Java, é necessário, no
mínimo, o uso de um Java Software Developer’s Kit ( JDK) e
um editor de textos ASCII simples, tal como Bloco de Notas.
Existem várias interfaces de desenvolvimentos para Java
feitas na própria linguagem como, por exemplo, JBuilder,
NetBeans, JCreator e Gel.
O JDK é composto de quatro partes básicas:
 Um conjunto de ferramentas para desenvolvimento de
aplicações Java.

77
 78

 Uma extensa biblioteca de classes padronizadas Java,

denominada Java Sttandard API.
 Um ambiente de execução Java.
 Exemplos, código-fonte das porções públicas e a
documentação das APIs.

As principais ferramentas incluídas no kit são:

 Um compilador para linguagem Java (javac).
 Uma máquina virtual Java (java)
 Um visualizador de applets(appletviewer )
 Um programa para geração de documentação (javadoc)
 Um utilitário para criar e manter arquivos compactados Java
Archive (jar).
Com essas ferramentas, é possível a criação desde
pequenas aplicações até sistemas distribuídos que operam em
rede.
6.4 JAVA E SUA SINTAXE
Abordaremos agora a sintaxe básica de Java como as
regras de declaração de variáveis, as recomendações geras para
nomenclatura, os operadores, sua precedência e as estruturas de
controle disponíveis.

6.4.1 ESTRUTURA MÍNIMA DO PROGRAMA

Um programa Java pode ser composto de um ou mais
arquivos-fontes, denominados unidades de compilação. Cada
uma dessas unidades de compilação pode, por sua vez, ser
composta de:
 Uma declaração de pacotes (package);
 Uma ou mais diretivas de importação (import);
 Uma ou mais declarações de classes (class);
 Uma ou mais declarações de interfaces (interface).
78
 79

A declaração de um pacote (package) se refere à

definição de um conjunto de classes que pertence a esse pacote,
enquanto as diretivas de importação (import) permitem indicar
quais pacotes de classes serão utilizados por um programa.
A declaração de classes (class) e interfaces (interfaces)
permite a definição de novos tipos de dependências entre os
mesmos.
Consideremos agora apenas a estrutura mínima que um
programa Java pode ter, a qual se compõe da declaração de uma
única classe:

public class Minimo {

Como todo programa deve ter um início, convenciona-se

que a primeira ação de um programa é a execução de um
método denominado main, que deve sempre ser declarado como:

public static void main (String args[]){

}

Dado que os métodos pertencem a uma classe, temos que

estes são declarados ‘dentro’ das classes, como segue, ou seja,
um programa mínimo.

public class Minimo{

public static void main (String args[]){
//corpo de main
}

79
 80

Temos a declaração de uma classe de nome Mínimo, na

qual existe um método main, o qual não contém instruções, ou
seja, seu corpo não declara nenhuma diretiva, portanto não faz
nada.
Em um programa, as diversas declarações e diretivas
utilizadas devem ser separadas por um “;” (ponto-e-vírgula).
Várias declarações ou diretivas podem ser colocadas numa
mesma linha, desde que separados por “;”.

6.4.2 Comentários
Os comentários em Java podem ser de uma linha ou de
bloco. Comentário de uma linha utiliza duas barras (//), para
marcar seu inicio.

public class Minimo{

public static void main (String args[]){
//isto é um comentário
}
}

Os comentários de bloco utilizam (/*) barra asterisco

para iniciar o comentário e (*/) asterisco e barra para finalizar o
comentário.

public class Minimo{

public static void main (String args[]){

/*isto é um comentário

80
 81

de bloco
aqui é o fim do comentário */

}
}

6.4.3 TIPOS DE DADOS PRIMITIVOS

A linguagem Java tem oito tipos primitivos, que podem
ser agrupados em quatro categorias.
Tipos inteiros: byte, inteiro curto, inteiro, inteiro longo.
Tipos de ponto flutuante: ponto flutuante simples, ponto
flutuante duplo
Tipo caractere: caractere.
Tipo lógico: booleano.

6.4.3.1 INTEIROS
Existem quatro diferentes tipos de dados inteiros ou
integrais: byte (8bits), short (inteiro curto – 16 bits), int (inteiro
– 32 bits) e long (inteiro longo -64 bits). Todos os tipos inteiros
são internamente representados pelo complemento de 2,
podendo armazenar valores.

6.4.3.2 PONTO FLUTUANTE

No Java, existem duas representações para números de
ponto flutuante (números reais), que se diferenciam pela
precisão oferecida: o tipo float permite representar valores reais
com precisão simples (representação interna de 32 bits),
enquanto o tipo double oferece dupla precisão.

81
 82

6.4.3.3 CARACTERE
O tipo char permite a representação de caracteres
individuais. O Java utiliza internamente uma representação no
padrão UNICODE, em que cada caractere ocupa 16 bits (2
bytes) sem sinal, o que permite representar até 32.768 caracteres
diferentes. Teoricamente, isso facilitaria muito todo trabalho de
internacionalização de aplicações, embora, na prática, a
compatibilidade oferecia ao UNICODE pela maioria dos
sistemas seja ainda bastante limitada. Em tese., o Java já está
preparado para tal compatibilidade e permite efetivamente a
internacionalização de suas aplicações. O valor literal de
caracteres deve sempre ser delimitado por aspas simples (‘’), tal
como: ‘L’ ‘u’ ‘7’ ‘i’.

6.4.3.4 LÓGICOS
Java dispõe do tipo lógico boolean, capaz de assumir os
valores falso (false) ou verdadeiro (true), isto é, que equivalem
aos estados off (desligado) e on (ligado), ou no (não) e yes
(sim).

6.4.4 VARIÁVEIS
O nome de uma variável em Java pode ser formado por
uma seqüência de um ou mais caracteres alfabéticos e
numéricos, iniciados por uma letra ou ainda pelos caracteres ‘_’
(underscore) ou ’$’ (cifrão). Os nomes não podem conter outros
símbolos gráficos, operadores ou espaços em branco, podendo
ser arbitrariamente longos, embora apenas os primeiros 32
caracteres sejam utilizados para distinguir nomes de diferentes
variáveis. Como a linguagem Java é sensível ao caso, o que
significa que letras maiúsculas e minúsculas são distintas.

82
 83

Exemplo de varáveis validas: _especial , TOT,

Maximo, exdata
Exemplo de variáveis não validas: 10x , total geral,
numero-maximo , void

6.4.4.1 PALAVRAS RESERVADAS

Além das regras de formação dos nomes, uma variável,
ou qualquer outro nome a ser definido pelo programador, não
pode ser uma das palavras reservadas da linguagem.
A lista das palavras reservadas é:

abstra
ct if int
s
u
p throw
float er s
c
at defau
public h lt
i
m
pl
e
m
e
boole nt interf
an s ace
s
w
it
c transi
for h ent
83
 84

c
h
return ar do
i
m
p
or
break t long
si
n
c
hr
o
ni
z
functi e
on d true
cl
as doubl
short s e
nativ
byte in e
th
goto is try
c
o
n
static st else
case in new
st
a
n
c
e
84
 85

of
th
ro
void w var
c
o
nt
in
u exten
false e ds
w
packa hi
ge le null
w
it privat
final h e
pr
ot
e
ct
e
finally d

6.4.4.2 DECLARAÇÃO DE VARIÁVEIS

Para declararmos uma variável, devemos seguir a
seguinte sintaxe:

<tipo> <nome1> [ , nome2 [, nome3 [ ... nomeN]]];

Ou seja, primeiro é obrigatório a especificação de um

Tipo e depois a declaração de uma ou mais variáveis, como em

85
 86

uma lista em que os nomes são separados por virgulas e a

declaração deve terminar com ‘;’(ponto-e-vírgula). Exemplos
utilizando tipos primitivos:
int i;
float total, preco;
byte mascara;
double valorMedio ;
Também é possível definirmos o valor inicial para a
variável:
int i = 0 ;
char a = ‘b’;

6.4.4.3 ESCOPO DE VARIÁVEIS

Consideremos um bloco de comandos, ou seja, um
conjunto de comandos da linguagem, delimitados por uma
{inicial e outra} final. A partir do ponto em que ocorreu a
declaração da variável, dizemos que a variável está em seu
escopo. Exemplo:

public class Inicio {

public static void main (String args[]){ //inicio do
escopo de I

int I ; // inicio de i

}// fim do escopo de i ela não existira mais apartir

deste momento.
}

6.4.4.4 REGRAS DE DENOMINAÇÃO DE VARIÁVEIS.

86
 87

Para declaração de variáveis, recomenda-se que os

nomes sejam iniciados com letras minúsculas. Caso o nome seja
constituído de uma única letra, sugere-se a inicial de seu próprio
tipo, acompanhada eventualmente de números para diferenciar a
variáveis. Caso o nome seja composto de mais de uma palavra, a
primeira inicial deverá ser minúscula e as demais devem ser
letras maiúsculas tal como nos exemplos:
luizFernandoBatistaLoja, valorMinimo, mediaDoGrupo.
Nome de classes deve iniciar com letra maiúscula e
nome de constante deve ser em caixa alto, enquanto nomes de
métodos devem seguir o mesmo padrão de denominação de
variáveis.

6.4.5 OPERADORES
A linguagem Java oferece um conjunto bastante amplo
de operadores destinados à realização de operações de
atribuição, aritméticas, lógicas e relacionais.

6.4.5.1 OPERAÇÃO DE ATRIBUIÇÃO

A operação de atribuição é feita pelo operador (=) igual e
é associativa à direita. Exemplo:
variavel = expressao ;

6.4.5.2 OPERADORES ARITMÉTICOS

Java tem vários operadores aritméticos.

Op S A S E
era i s i x
dor g s n e
n o t m
if c a p

87
 88

i
i a
c t
a i
d v x l
o o e o
2
E
s
+
q
u
2
S e
o r x =
m d +
+ a a x 4
2
S E
u s
-
b q
tr u
2
a e
ç r x =
ã d -
- o a x 0
* M E x 2
u s *
lt q x *

i u
2
p e
li r
=
c d
a a
4
ç
ã
88
 89

o
2
E
s
/
D q
i u
2
v e
is r x =
ã d /
/ o a x 1
R
e
st
o
d
e
u
2
m E
a s
%
d q
i u
2
v e
is r x =
ã d %
% o a x 0
++ I E +
n s +
c q x
r u
e e o
m r u
e d
n a x
89
 90

/
D
i
r
e
i
t t +
o a +
E
s
q
u
e
r
D d -
e a -
c / x
r D
e i o
m r u
e e
n i x
t t -
-- o a -

6.4.5.3 OPERADORES RELACIONAIS

Além dos operadores aritméticos, o Java possui

operadores relacionais, isto é operadores que permitem
comparar valores literais, variáveis ou o resultado de expressões
90
 91

retornado um resultado do tipo lógico, isto é, um resultado falso

ou verdadeiro. Os operadores relacionais disponíveis são:

O
p S E
e í x
r m e
a b m
ç o p
ã l l
o o o
2

=
=

Ig (
u f
al a
d l
a s
d = o
e = )
D ! 2
if =
er !
e =
nt
e 3
91
 92

(
v
e
r
d
a
d
e
i
r
o
)
2

>

(
f
a
l
M s
ai o
or > )
M < 2
e
n <
or
3

92
 93

(
v
e
r
d
a
d
e
i
r
o
)
3

>
=

(
v
e
r
M d
ai a
or d
o e
u i
ig r
u > o
al = )
M < 2
93
 94

<
=

(
v
e
r
e d
n a
or d
o e
u i
ig r
u o
al = )

6.4.5.4 OPERADORES LÓGICOS

Os operadores lógicos de Java são:

Op Sí
era mb
ção olo Exemplo
(3>2) &&
(5>=5) -
E && Verdadeiro
ou || (3<2) ||
(4>1)

94
 95

-Verdadeir
o
NE
GA
ÇÃ !(4>2) -
O ! Falso

6.4.5.5 OPERADORES COMPACTOS

Durante a programação, é muito comum a ocorrência de
expressões tais como as exemplificadas a seguir:
x = x + 15;
Esta operação pode ser resumida com um operador
compacto que é :
x += 15;
Assim x recebera seu resultado mais 15 podemos usar
outros operadores no lugar do (+).

6.4.5.6 PRECEDÊNCIA DE AVALIAÇÃO DE

OPERADORES
Como podemos construir uma expressão com diversos
operadores diferentes, é necessário ter um critério para
determinarmos qual desses operadores será primeiramente
processado, tal como ocorre em expressões matemáticas
comuns. O conceito de precedência representa esse critério isto
é, a ordem ou hierarquia de avaliação dos operadores.
Para qualquer expressão, envolvendo qualquer
combinação de operadores, sempre é aplicada a regra de
precedência convencionada pela linguagem, garantindo que uma
dada expressão sempre produza o mesmo resultado,
independentemente do compilador ou da plataforma utilizada.

95
 96

Operado
Níveis res
. (seletor)
1 [] ()
++ -- ~
instanceof
new clone
(unário)
2 (cast)
3 */%
4 +-
<< >>
5 >>>
6 < > <= >=
7 == !=
8 &
9 ^
10 |
11 &&
12 ||
13 ?:
14 = op=
15 ,

6.4.6 ESTRUTURA DE CONTROLE

Naturalmente, as instruções de um programa são
executadas em seqüência , o que se denomina fluxo seqüencial
de execução. Mas, em inúmeras circunstâncias, é necessário
executar as instruções de um programa em uma ordem diferente
da estritamente seqüencial. Tais situações são caracterizadas
pela necessidade de repetição de instruções individuais ou
conjunto de instruções, e também pelo desvio do fluxo de
execução, tarefas que podem ser realizadas por meio das
estruturas de controle da linguagem.

96
 97

6.4.6.1 TIPOS DE ESTRUTURAS DE CONTROLE

As linguagens de programação tipicamente têm
estruturas de programação diferentes para cada forma de
controle do fluxo de execução, isto é, existem estruturas de
controle destinadas à repetição e outras que permitem o desvio
do fluxo de execução. Geralmente as estruturas de controle são
dividas em:
 Estruturas de repetição simples;
 Estruturas de repetição condicional;
 Estruturas de desvio de fluxo;
 Mecanismos de modularização;
 Estruturas de controle de erros.

6.4.6.2 ESTRUTURAS DE REPETIÇÃO SIMPLES

A estrutura de repetição simples em Java tem a seguinte
sintaxe:
for([inic]; [cond];[incr_decr])
O for tem três seções distintas de controle, todas
opcionais, delimitadas por um par de parênteses, nos quais cada
seção é separada de outra por um ponto-e-vírgula. Após as
seções de controle, é declarado a diretiva ou bloco que será
repetido.
A primeira seção é utilizada para declarar e inicializar
uma variável de controle (geralmente, um contador de
repetições). A segunda seção determina a condição de execução
da diretiva associada ao for e, geralmente, é uma expressão
lógica que utiliza a variável de controle e outros valores se a
mesma for avaliada como verdadeira, a diretiva associada será
executada uma vez, caso contrário o comando for é encerrado. A

97
 98

última secção determina como a variável de controle será

modificada a cada iteração. A seguir um exemplo desta diretiva;
For (int i; i < tamanho; i++) {
//corpo do for
}

6.4.6.3 ESTRUTURA DE REPETIÇÃO COM

CONDICIONAIS
Essas estruturas são adequadas para permitir a execução
repetida de uma ou mais diretivas por um número indeterminado
de vezes, isto é, um número que não conhecido durante a
programação, mas que se torna conhecido durante a execução do
programa, está como um valor fornecido pelo usuário, obtido de
um arquivo, ou ainda de cálculos realizados com outros dados.
No Java, tais estruturas são o while e do while.
Na diretiva while, um conjunto de instruções é repetido,
enquanto o resultado de uma expressão lógica (a condição) é
avaliado como verdadeiro. Abaixo é mostrada a sintaxe desta
diretiva;
while(condição){
// corpo do while
}

Note que o while avalia o resultado da expressão antes de

executar a diretiva associada; assim, é possível que esta diretiva
nunca seja executada, caso a condição seja inicialmente falsa.
Exemplo e while:
while(j >= d ) {
d = d + 25;

98
 99

J = j + 5;
}

O do while é outro laço condicional, no qual um conjunto

de instruções também é repetido, enquanto o resultado da
condição é avaliado como verdadeiro, mas, diferente do while, a
diretiva associada é executada uma primeira vez antes de
avaliação da expressão lógica e da eventual continuação da
repetição. A sintaxe da diretiva do while é dada abaixo.

do {
// bloco da estrutura
}while(condição)

6.4.6.4 ESTRUTURAS DE DESVIO DE FLUXO

Java possui apenas diretivas de desvio condicional do
fluxo de execução, if e switch.
If é uma diretiva de desvio simples do fluxo de execução,
isto é, capaz de selecionar um entre dois caminhos distintos para
execução, dependendo do resultado falso ou verdadeiro,
resultante da expressão lógica associada. Observemos a sintaxe
da diretiva if.

if (condição){
// corpo da estrutura 1
}
else {
//corpo da estrutura 2
}

99
 100

Notemos que a diretiva if tem uma parte opcional,

relacionada à sua cláusula else. Isso permite duas construções
possíveis: apenas o desvio de fluxo simples e o desvio
precedendo o caso da condição principal não acontecer.
Podemos também utilizar if e else alinhados como no
exemplo.
if (condição 1 ) {
//corpo 1
}
else if ( condição 2) {
//corpo 2
}
else if ( condição 3) {
//corpo 3
}
else {
//corpo default
}

Switch é uma diretiva de desvio múltiplo de fluxo, isto é,

com base na avaliação de uma expressão é escolhido um
caminho de execução dentre muitos. A diretiva switch exige uma
expressão original, uma expressão cujo resultado pertença a um
conjunto no qual se conhece precisamente os elementos
anteriores e posteriores de um elemento. Exemplo:

switch (condição) {
case ordinal1 :
//corpo 1
break ;

100
 101

case ordinal2 :
//corpo 2
break ;
case ordinal3 :
//corpo 3
break ;
default :
//corpo default
}

O corpo da diretiva switch tem um ou mais casos

(cláusulas case) rotulados por literais ordinais. Conforme o
resultado da avaliação da expressão ordinal associada ao switch,
é selecionado o caso correspondente, se este existir. Se um caso
for selecionado, todas as diretiva s encontradas a partir deste até
o final do corpo do switch (mesmo que isso signifique ‘invadir’
outros casos ) ou até a primeira diretiva break encontrada, que
encerra o switch.
Exemplo de switch:
switch ( numero ) {
case 1 :
numero++ ;
break ;
case 2:
numero--;
break ;
default :
numero = 0 ;
}
6.4.6.5 ESTRUTURA DE CONTROLE DE ERROS

101
 102

O Java oferece duas importantes estruturas para controle

de erros try catch e try catch e finally. Ambas têm o propósito de
separar o código que executa as tarefas desejadas das rotinas de
tratamento de eventuais erros, além de evitar que o programador
tenha que realizar estes de verificação e avaliação, antes da
realização de certas operações.
Por meio dessas diretivas, delimitamos um trecho de
código que será monitorado automaticamente pela JVM.
Ocorrendo algum erro, o fluxo de execução é transferido para
uma rotina de tratamento de erro, sendo que tal transferência
pode ser seletiva, isto é, pode-se transferir a execução para
rotinas diferentes, conforme o erro ocorrido.
Com a diretiva try catch, a ocorrência de um ou mais
tipos de erros dentro do trecho de código delimitado desvia a
execução automaticamente para uma ou mais rotinas designadas
para o tratamento especifico desses erros. O uso opcional da
cláusula finally garante a execução de um trecho final de código.
A sintaxe do try catch finally exige que cada bloco try
tenha ao menos um bloco catch ou finally, e é mostrado a seguir:

try {
//bloco de try
}
catch (exceção 1){
//bloco da exceção 1
}
catch (exceção 2){
//bloco da exceção 2
}
finally{
//execução grantida

102
 103

6.4.7 VETORES
Vetores são estruturas de dados que armazenam
usualmente uma quantidade fixa de dados de um tipo, por esta
razão também são conhecidos como estruturas homogêneas de
dados.
Cada linguagem de programação tem uma sintaxe
diferente para a declaração de vetores, mas em todas elas são
fornecidas três informações: o nome do vetor, o número de
posições do vetor (seu tamanho) e o tipo de dado que será
armazenado pelo vetor. A declaração de um vetor para inteiros,
de nome vetor, com tamanho 10, em Java, poderia ser escrita
assim:
int vetor[];
Podemos notar que as declarações de vetores são
semelhantes às declarações de variáveis, pois o nome do vetor é
acompanhado de colchetes. Embora declarado, o vetor não está
pronto para uso, sendo necessário reservarmos espaço para seus
elementos. Quando o tipo do vetor é simples, tal alocação pode
ser feita como segue.
vetor = new int [10];
int vetor2[] = new int[10];

6.5 ACESSO A BANCO DE DADOS

A plataforma Java permite o acesso a banco de dados
relacionais por meio de uma API (Application Programming
Interface) denominada JDBC. Java Database Connectivity. A
JDBC 1.0 foi introduzida na versão 1.1 da família Java , tendo
sido aperfeiçoada e ampliada na versão 2.0, disponibilizada a

103
 104

partir da família Java 2 ( versões 1.2 em diante). A JDBC é

considerada por muitos a mais importante API do Java, um
argumento difícil de combates, dado que qualquer aplicação ou
sistema de porte necessita armazenar grandes quantidades de
dados de forma organizada, o que é feito pelos bancos de dados.
A idéia central da JDBC é prover às aplicações Java o
acesso aos bancos de dados relacionais locais ou remotos,
possibilitando que tanto as aplicações como as applets utilizem
dados existentes em SGBDR (Sistemas Gerenciadores de Banco
de Dados Relacionais) remotos, isto é, localizados em outras
máquinas interligadas a uma rede.
Outra característica importante do JDBC é o uso
extensivo do SQL.

6.5.1 ARQUITETURA JDBC

A JDBC pode ser implementada independentemente da
plataforma, possibilitando seu uso em sistemas de arquitetura
distinta, seguindo os princípios da linguagem Java.
A arquitetura desta API oferece uma interface
independente de qualquer SGBDR, permitindo o acesso
genérico e uniforme aos diferentes bancos de dados. Os dados
são efetivamente acessados por meio do SQL, cujo maior mérito
é separar o tratamento dos dados das diversas implementações
de bancos de dados. O programador deve escrever apenas uma
interface para interagir com um banco de dados relacional por
meio da API JDBC e, utilizando o SQL, o programa poderá
acessar os dados sem a necessidade de programação adicional
para a realização dessas operações. Sendo assim, o uso do SQL é
imprescindível, e o JDBC pode ser visto como uma interface
SQL para bancos de dados.

104
 105

Outra característica importante do JDBC é que ocorre o

mapeamento dos tipos de dados existentes no banco de dados
para os tipos nativos do Java, oferecendo, quando necessário,
classes adicionais para tal tarefa. Por exemplo a classe
java.sql.Date é fornecida para mapear um campo do tipo data
(DATE) dos bancos de dados.

6.5.2 DRIVERMANAGER E URLS

Para utilizarmos qualquer banco de dados, é necessário
estabelecermos uma conexão com este, utilizando, para isso, o
driver adequado. A classe DriverManager é uti8lizada para
administrar e selecionar o driver apropriado para uma conexão
com um banco de dados, bem como para efetuar tal conexão.
Quando uma conexão é solicitada, o DriverManager escolhe um
driver dentre a lista de drivers disponíveis para efetuar a
conexão, dependendo da URL especificada.
Tal lista de drivers pode ser estaticamente especificada
no arquivo <home>.hotjava/properties através da propriedade
jdbc.drivers, como indicado abaixo:

Jdbc.drivers=jdbc.idDriver:outro.driver.Qualquer
A forma mais simples é carregar dinamicamente a classe
que implementa o driver necessário como no trecho a seguir:

try{
Class.forName(“jdbc.idbDriver”);
}
catch(ClassNotFoundException cnfe){
System.err.print(“Driver não encontrado”);
}

105
 106

Estando o driver disponível ou tendo sido carregado,

utilizamos a classe DriverManager para obter conexão com o
banco de dados necessário:

Connection com =
DriverManager.getConnection(url);

A API JDBC utilize uma estrutura de endereçamento

semelhante ao esquema das URLs (Uniform Resource Locator)
para especificar um banco de dados, na forma:

Jdbc:<subprotocolo>:<subnome>

A designação inicial jdbc indica o uso desta API. O

subprotocolo é usualmente a denominação do SGBDR que deve
ser reconhecida por um dos drivers instalados. O subnome
depende do banco de dados, mas é geralmente uma
especificação do host no qual opera o SGBDR ou o nome de
uma fonte de dados. Por exemplo, a URL para o acesso a um
banco de dados Oracle na INTernet/Intranet, por meio de um
driver puro(thin driver): teríamos como subprotocolo
=oracle:thin e o subnome, no formato hostname:port:

Jdbc:oracle:thin@marte.discover.com.br:1526:ORCL

O nome do host é marte.dicover.com.br , a porta é 1526 e

o nome da instância do banco de dados é ORCL. A
documentação fornecida com o driver utilizado deve ser
utilizada para a especificação correta das URLs JDBC.

106
 107

Uma vez estabelecida a conexão com sucesso, as

solicitações de consultas e outras operações sobre os dados serão
feitas por meio de SQL, utilizando a conexão estabelecida pelo
driver JDBC.

CONCLUSÃO

107
 108

Aprendemos nesta primeira fase as definições basicas de

Banco de Dados. Chegamos a uma definição do modelo de
entidade relacionamento, modelo relacional e como fazer o
mapeamento entre estes dois modelos. Vimos também os
conceitos fundamentais de Engenharia de Software que nos
ajudarão a continuar desenvolvendo da ferramenta proposta.
Estudamos a linguagem de modelagem visual UML e a
linguagem de programação Java que está sendo utilizada na
modelagem do sistema e na formação estrutural do sistema
respectivamente.
A primeira etapa deste projeto foi apenas com o intuito
de apresentar o conteudo teorico que está sendo usado na
ferramenta em desenvolvimento e para nos fornecer um
embasamento cientifico necessário para dar continuidade a ela.
Na maturidade que obtive com o desenvolvimento deste
projeto estudarei as maneiras de implementar o caso de uso do
mapeamento do esquema conceitual entidade relacionamento
para o esquema do modelo relacional.
Está interação proposta será implementada no projeto
final de curso II onde compromento-me a desenvolve-la.

108
 109

REFERENCIAS BIBLIOGRAFIA

[1] Junior, Peter Jandli.”Introdução ao Java”

[2] Heuser, Carlos Alberto “Projeto de Banco de Dados”,
Sagra
[3] lmasri, Ramez e Navathe, B. Shamkant. “Sistemas de
Banco de Dados – Fundamentos e Aplicações”. LTC, 2002.
[4] Larman Craig. “Utilizando UML e Padrões”. Bookman,
2000.
[5] Silva, Douglas Marcos da. “UML Guia de Consulta
Rapida “. Novatec
[6] Horstmann, Cay e Cornell, Gary. “Core Java2
Fundamentos”, Volume I. São Paulo Makron Books,2001

109