Análise e Desenvolvimento de Sistemas - Análise e Desenvolvimento de Sistema Cliente e Servidor (UMESP) [André Luiz Perin]

Prévia do material em texto

Tecnólogo em
Análise e Desenvolvimento 
de Sistemas
Análise e 
desenvolvimento 
de sistema 
cliente e servidor
Organizador
André Luiz Perin
1o semestre de 2013 - 1a edição w
w
w
.m
et
od
is
ta
.b
r
Coordenador do Curso de Tecnologia em 
Análise e Desenvolvimento de Sistemas
Prof. Me. André Luiz Perin
Organizador
Prof. Me. André Luiz Perin
Professores Autores
Prof. Alexandre Atanes de Jesus
Prof. Me. André Luiz Perin
Prof. Cristiano Camilo dos Santos de Almeida
Prof. Esp. Durval de Oliveira Dorta Junior
Prof. Me. Leonardo Mairene Muniz
Prof. Rafael Guimarães Sakurai
Profa. Dra. Silvia Brunini
Assessoria Pedagógica
Adriana Barroso de Azevedo
Bruno Tonhetti Galasse
Karin Müller
Thais Helena Santinelli
Coordenação Editorial
Prof. Me. André Luiz Perin
Editoração Eletrônica
Editora Metodista
Projeto Gráfico
Cristiano Leão
Revisão
Victor Hugo Lima Alves
Data desta edição
1o semestre de 2013
Dados Internacionais de Catalogação na Publicação (CIP) 
(Biblioteca Central da Universidade Metodista de São Paulo)
Rua do Sacramento, 230 - Rudge Ramos 
09640-000 São Bernardo do Campo - SP 
Tel.: 0800 889 2222 - www.metodista.br/ead
É permitido copiar, distribuir, exibir e executar a obra para uso não comercial, desde que 
dado crédito ao autor original e à Universidade Metodista de São Paulo. É vedada a criação 
de obras derivadas. Para cada novo uso ou distribuição, você deve deixar claro para outros 
os termos da licença desta obra. 
Universidade Metodista de São Paulo
Conselho Diretor
Stanley da Silva Moraes (Presidente); Nelson Custódio Fér (Vice-Presidente); Osvaldo Elias de 
Almeida (Secretário); Ademir Aires Clavel; Augusto Campos de Rezende; Aureo Lidio Moreira 
Ribeiro; Kátia Santos; Marcos Sptizer; Oscar Francisco Alves; Paulo Roberto Lima Bruhn; Regina 
Magna Araujo; Valdecir Barreros
Reitor: Marcio de Moraes
Pró-Reitoria de Graduação: Vera Lúcia Gouvêa Stivaletti
Pró-Reitoria de Pós-Graduação e Pesquisa: Fábio Botelho Josgrilberg
Direção da Faculdade de Exatas e Tecnologia: Carlos Eduardo Santi
Coordenação do NEAD: Adriana Barroso de Azevedo
ex
pe
di
en
te Un3a Universidade Metodista de São Paulo Análise e desenvolvimento de sistema cliente e servidor / Universidade Metodista de São Paulo. Organização de André Luiz Perin. São Bernardo do Campo : Ed. do Autor, 2013.
 _ _ _ p. (Cadernos didáticos Metodista - Campus EAD)
 Bibliografia
 ISBN 
 1. Análise de sistemas 2. Processamento eletrônico de dados 
 I. Perin, André Luiz II. Título.
CDD 004.21
Tecnólogo em
Análise e Desenvolvimento 
de Sistemas
1o semestre de 2013 - 1a edição
UMESP
Análise e 
desenvolvimento 
de sistema 
cliente e servidor
Organizador
André Luiz Perin
w
w
w
.m
et
od
is
ta
.b
r
Palavra do Reitor
Prezado/a Aluno/a da Metodista,
A Universidade Metodista de São Paulo entende que a educação a distância vem marcar não 
só o desenvolvimento tecnológico que viabiliza a circulação de grande fluxo de conteúdo entre 
diversas localidades, mas, principalmente, a democratização da Educação Superior e a participação 
efetiva na formação de pessoas exercendo poder de influência e contribuindo na melhoria da qua-
lidade das relações entre educando e educador. A expansão de cursos na modalidade a distância 
abriu um novo cenário de atuação para esta Instituição em nível nacional e até internacional. 
A Educação a distância que vem se desenvolvendo nos últimos anos no Brasil, trabalha nessa 
mesma direção e é parte integrante do cumprimento dessa missão educacional. Nos cinco anos 
de oferecimento dos cursos na modalidade a distância na Metodista já formamos mais de 6.000 
profissionais nas diversas áreas do conhecimento que envolvem Administração de Empresas, Cur-
sos Superiores de Tecnologia em diversas habilitações, licenciaturas como em Pedagogia e Letras, 
além do bacharelado em Teologia.
Nosso compromisso com uma educação de qualidade passa pela promoção de processos 
educacionais que viabilizam a inclusão, com novas formas de contato com as mais variadas fontes 
do conhecimento e a interação entre os diversos atores envolvidos no processo educativo. Tais 
processos garantem um universo de possibilidades que qualificam o processo de ensino e apren-
dizagem em EAD da Metodista.
A fim de auxiliá-lo neste processo de formação, cujo foco principal é a qualidade, este Guia de 
Estudos apresenta textos desenvolvidos pelos docentes da instituição, nos quais são apresentados 
os conceitos principais que serão desenvolvidos no curso. Este material atua como um norteador 
das atividades de estudos, guiando-o (a) a outras fontes de pesquisa, como artigos científicos, 
livros, revistas e demais referências importantes à sua trajetória escolar. 
Bons estudos e um excelente ano de trabalho!
Prof. Dr. Marcio de Moraes
Reitor
Universidade Metodista de São Paulo
6
9
21
47
65
77
101
131
149
165
Módulo: Modelagem e Documentação de 
Sistemas
Laboratório de Modelagem
Professor Alexandre Atanes de Jesus
Modelagem de Banco de Dados 
Prof. Esp. Durval de Oliveira Dorta Junior
Engenharia de Requisitos – Parte 1
Prof. Me. André Luiz Perin
Engenharia de Requisitos – Parte 2
Prof. Me. André Luiz Perin
Módulo: Organização de Dados
Introdução ao Banco de Dados
Parte 1
Prof. Esp. Leonardo Mairene Muniz
Introdução ao Banco de Dados
Parte 2
Prof. Esp. Leonardo Mairene Muniz
Organização de Dados I
Professora Dra. Silvia Brunini
Organização de Dados II
Professora Dra. Silvia Brunini
Organização de Dados III
Professora Dra. Silvia Brunini
su
m
ár
io
Módulo: Implementação de Sistemas Cliente 
Servidor
Introdução ao desenvolvimento de interface grá-
fica utilizando swing
Prof. Rafael Guimarães Sakurai
Criando aplicações desktop que gravam 
informações em arquivos texto
Prof. Rafael Guimarães Sakurai
Criando uma aplicação Swing com acesso ao banco 
de dados
Prof. Rafael Guimarães Sakurai
Módulo: Programação Orientada a Objetos – 2
Conexão com bancos de dados utilizando a Java 
Database Connectivity.
Prof. Cristiano Camilo dos Santos de Almeida
Enumerações e tipos genéricos
Prof. Cristiano Camilo dos Santos de Almeida
Collections
Prof. Cristiano Camilo dos Santos de Almeida
173
195
209
223
245
261
Laboratório 
de Modelagem
Professor Alexandre Atanes de Jesus
Objetivos: 
Apresentar ao aluno os principais conceitos ligados 
à modelagem e à documentação de sistemas utilizando 
o paradigma de projeto orientado a objetos em conjunto com 
uma metodologia para Modelar e Documentar Sistemas de 
Informação bastante utilizada pelas empresas que trabalham 
com desenvolvimento de sistemas; ajudar o aluno a identificar 
os principais requisitos dos sistemas e agrupá-los em 
diagramas que ajudarão no desenvolvimento e na documenta-
ção final da solução. Praticar a modelagem e documentação de 
sistemas utilizando a notação da UML (Unified Modeling 
Language) e seus principais diagramas.
 
Palavras-chave: 
Modelagem; Documentação; Unified Modeling Language 
(UML); Metodologia; Diagramas; Classes; Objetos, 
Requisitos; Análise.
Módulo
www.metodista.br/ead
Modelagem e Documentação 
de sistemas
POR quE MODELAR E DOCuMENTAR SOftwAre?
Por que não podemos simplesmente conversar com o nosso cliente e/ou usuário e já sair 
“programando”?
Muitos “profissionais” podem afirmar que conseguem determinar todas as necessidades de 
um sistema de informação de cabeça e que sempre trabalharam assim, mas a concepção de um 
software, muitas vezes, é complexa e demanda um bom tempo para o entendimento do problema 
a ser solucionado. Neste caso, a documentação dessa solução deve seguir alguns padrões que 
possam ser entendidos e acompanhados por todos os envolvidos no desenho e na construção da 
solução, o que nunca foi uma tarefa fácil.
Mesmo em sistemas simples é importante fazermos a sua modelagem e documentação, 
pois todo sistema está sujeito a novasversões, atualizações e manutenções e é nesses casos que 
vamos precisar analisar a documentação para verificar como a solução foi “construída” e como 
podemos modificá-la.
Hoje em dia os softwares tem uma importância muito grande para qualquer ramo de atuação 
e isso faz com que eles tenham uma dinâmica muito grande e sejam “modificados” e “atualizados” 
com muita frequência e sem seus modelos e documentação seria impossível realizar essa tarefa.
Precisamos documentar e gerenciar todas as solicitações e necessidades do nosso cliente 
e/ou usuário para direcionar a solução de uma forma que atenda da melhor forma possível essas 
necessidades, sem perder o foco do objetivo final do sistema e sem criar falsas expectativas em 
relação ao que deve ser entregue.
Outro ponto importante da documentação está ligado ao custo final dos sistemas, pois 
quanto mais tarde se descobre um erro maior o custo para consertá-lo e as consequências podem 
ser irreparáveis. 
Segundo Pressman (2006), cerca de 60% dos erros ocorrem já na fase de elaboração do 
projeto, nas atividades exercidas pela engenharia de requisitos e análise de sistemas. Obviamente 
esses erros podem ser corrigidos antes do final do projeto. Porém, o custo para a correção desses 
erros tende a aumentar conforme o sistema vai chegando próximo a sua versão final. Após a sua 
entrega, a correção de um defeito pode custar até 1.000 vezes mais que na fase de levantamento 
dos requisitos.
A imagem abaixo mostra os dados coletados por Boehm (1981) que demostram a relação 
entre o custo de uma solução e as etapas de desenvolvimento de um sistema.
Figura 1 
Fonte: Boehm (1981)
Universidade Metodista de São Paulo
10
MAS O que é MODelAgeM?
É um recurso de suporte para a síntese da solução, um modelo ajuda a planejar um sistema 
antes de criá-lo.
Os modelos também podem ajudá-lo a se certificar de que o design é confiável, que os 
requisitos foram entendidos e cumpridos por todos os envolvidos no projeto.
Modelos são ferramentas para melhorar o entendimento do sistema, pois apresentam de 
forma clara e direta as funcionalidades do sistema, quais informações são manipuladas pelo siste-
ma e seu comportamento dinâmico.
Um modelo é uma simplificação da realidade, eles podem ser estruturais, dando ênfase à 
organização do sistema, ou podem ser comportamentais, dando ênfase à dinâmica do sistema. 
Modelos Visuais são essenciais para a comunicação entre os envolvidos no projeto e o cli-
ente.
MODELO DE SOftwAre – DEFINIçãO!
Um modelo de software captura a visão de um sistema físico e faz a abstração do sistema 
com certo propósito, como descrever aspectos estruturais ou comportamentais do software. Esse 
propósito determina o que deve ser incluído no modelo e o que é considerado irrelevante. Assim, 
um modelo descreve completamente aqueles aspectos do sistema físico que são relevantes ao 
propósito do modelo em um nível apropriado de detalhe.
Um modelo de software define semântica e notação:
•	informação semântica: descreve o significado ou intenção do sistema;
•	notação: apresentação visual, mostram o modelo de forma facilmente compreensível e 
podem ser apresentados de várias formas, incluindo texto e diagramas.
Visões de um modelo de Software:
Diferentes pontos de vista devem ser usados para refletir os aspectos desejados.
Cada visão mostra um conjunto de aspectos do sistema numa notação adequada à sua 
compreensão.
A arquitetura de um sistema pode ser refletida em cinco visões distintas:
Figura 2
Fonte: Professor Alexandre Atanes
11
www.metodista.br/ead
Possibilitando aos desenvolvedores analisar o sistema de diferentes perspectivas, são pro-
postas as seguintes visões:
Visão de Casos de Uso: descreve o sistema de um ponto de vista externo como 
um conjunto de interações entre o sistema e os agentes externos do sistema.
Visão de projeto: enfatiza as características do sistema.
Visão de implementação: abrange o gerenciamento de versões do sistema.
Visão de implantação: corresponde à distribuição física do sistema em seus sub-
sistemas e à conexão entre essas partes.
Visão de processos: enfatiza as características de concorrência, sincronismo e de-
sempenho do sistema.
PArADIgMA DA OrIentAçãO A ObJetOS.
O paradigma da orientação a objetos visualiza um sistema de software como uma coleção 
de agentes interconectados chamados de objetos. Cada objeto é responsável por realizar tarefas 
especificas. É através da interação entre objetos que uma tarefa computacional é realizada. Sendo 
uma técnica para a modelagem que diminui a diferença semântica entre a realidade sendo mod-
elada e os modelos construídos.
A orientação a objetos tem sua origem nos anos 60, na Noruega, com Kristen Nygaard e 
Ole-Johan Dahl, no Centro Norueguês de Computação. Através da linguagem Simula 67, foram 
introduzidos os conceitos de classe e herança.
A orientação a objetos passou a ser mais conceituada e elaborada nos laboratórios da Xe-
rox, em Palo Alto, sendo refinada numa sequência de protótipos da linguagem Smalltalk. O líder 
desse projeto foi Alan Curtis Kay, considerado um dos criadores do termo “programação orien-
tada a objetos”.
Alan Key estabeleceu alguns princípios básicos relacionados à programação orientada a 
objetos como:
•	Qualquer coisa é um objeto.
•	Objetos realizam tarefas através da requisição de serviços a outros objetos.
•	Cada objeto pertence a uma determinada classe.
•	A classe é um repositório para o comportamento associado ao objeto.
•	Classes são organizadas em hierarquia.
ClASSeS e ObJetOS
O mundo real é formado por coisas, como carros, pessoas, vendas, casas, etc. Na termino-
logia orientada a objetos essas coisas do mundo real são chamadas de objetos. Seres humanos 
costumam agrupar os objetos. Este processo mental de agrupamento ajuda a gerenciar a com-
plexidade de entender as coisas do mundo real. É muito fácil entender a ideia de um carro in-
dependente das suas variações e modelos. Na terminologia da orientação a objetos cada ideia é 
denominada classe de objetos ou simplesmente classe. Uma classe é uma descrição dos atributos 
e serviços comuns a um grupo de objetos, entende-se uma classe como sendo o molde do qual 
os objetos são construídos. Nesta terminologia ainda diz-se que um objeto é uma instância de 
uma classe.
Universidade Metodista de São Paulo
12
A programação Orientada a Objetos traz alguns conceitos importantes como:
Mensagens
Para que uma operação em um objeto seja executada deve haver um estímulo 
enviado a esse objeto. Independentemente da origem do estímulo, quando ele 
ocorre, diz-se que o objeto em questão está recebendo uma mensagem requisi-
tando que ele realize alguma operação.
Encapsulamento
Objetos possuem comportamentos. O termo comportamento diz respeito a oper-
ações realizadas por um objeto e também ao modo pelo qual essas operações são 
executadas. O Mecanismo de encapsulamento é uma forma de restringir o acesso 
ao comportamento do objeto. Quando um objeto faz uma requisição a outro ob-
jeto ele não precisa saber como o objeto realizará a operação. Ele só precisa saber 
que o objeto é capaz de fazer determinada requisição e ele será capaz de saber 
através da interface do objeto que diz apenas o que o objeto é capaz de fazer, sem 
dizer como.
Polimorfismo
É caracterizado quando duas ou mais classes distintas têm métodos de mesmo 
nome, de forma que uma função possa utilizar um objeto de qualquer uma das 
classes polimórficas, sem necessidade de tratar de forma diferenciada conforme a 
classe do objeto.
Herança
Na herança, classes semelhantes são agrupadas em hierarquias. Cada classe em 
um nível de hierarquia herda as características das classes nos níveis acima. Esse 
mecanismo facilita o compartilhamento de comportamento comum entre um con-
junto de classes semelhantes.
A MODelAgeM OrIentADA A ObJetOS.
A essência do desenvolvimento baseado em objetos é a identificação e a organização de 
conceitos do domínio da aplicação, em vez de sua representação em uma linguagemde pro-
gramação.
A visão orientada a objetos evoluiu mais facilmente, pois somos incentivados a usar classes 
para representar coisas do nosso dia a dia.
Na visão da Orientação a Objetos, o principal bloco de construção de todos os sistemas 
de softwares é o objeto ou a classe, sendo que uma classe é a descrição de um conjunto de 
objetos comuns.
Todos os objetos têm uma identidade (um nome), um estado (normalmente ele possui 
dados associados a ele) e um comportamento (podemos fazer algo com ele ou ele poderá fazer 
algo com outros objetos).
13
www.metodista.br/ead
Algumas observações importantes sobre Modelagem:
• A escolha dos modelos a serem criados tem profunda influência sobre a maneira como 
um determinado problema é atacado e como uma solução é definida;
• Cada modelo poderá ser expresso em diferentes níveis de precisão;
• Os melhores modelos são relacionados à realidade;
• Nenhum modelo único é suficiente. Qualquer sistema não trivial será mais bem investi-
gado por meio de um pequeno conjunto de modelos quase independentes com vários 
pontos de vista. 
A uML (unIfIeD MODelIng lAnguAge).
De acordo com o prefácio do livro “UML Guia do Usuário”, da editora Elsevier, a Linguagem 
Unificada de Modelagem (UML) é uma linguagem gráfica para visualização, especificação, con-
strução e documentação de artefatos de sistemas complexos de software. A UML proporciona 
uma forma padrão para a preparação de planos de arquitetura de projetos de sistemas, incluindo 
aspectos conceituais tais como processos de negócios e funções do sistema, além de itens con-
cretos como as classes escritas em determinada linguagem de programação, esquemas de banco 
de dados e componentes de softwares reutilizáveis.
Figura 3 
Fonte: Internet – nerdson.com
A UML surgiu da fusão de três grandes métodos, do BOOCH, OMT (Rumbaugh) e OOSE 
(Jacobson). Esta linguagem de modelagem não proprietária de terceira geração não é um método 
de desenvolvimento. Tem como papel principal auxiliar na visualização do desenho e na comuni-
cação dos objetos. Ela permite que desenvolvedores visualizem os produtos de seu trabalho em 
diagramas padronizados e é muito usada para criar modelos de sistemas de software.
Além de fornecer a tecnologia necessária para apoiar a prática de engenharia de software 
orientada a objetos, a UML poderá ser a linguagem de modelagem padrão para modelar sistemas 
Universidade Metodista de São Paulo
14
concorrentes e distribuídos. Utiliza-se de um conjunto de técnicas de notação gráfica para criar 
modelos visuais de software de sistemas intensivos, combinando as melhores técnicas de modela-
gem de dados, negócios, objetos e componentes. É uma linguagem de modelagem única, comum 
e amplamente utilizável.
Embora com a UML seja possível representar o software através de modelos orientados a 
objetos, ela não demonstra que tipo de trabalho deve ser feito, ou seja, não possui um processo 
que define como o trabalho tem que ser desenvolvido. O objetivo então é descrever “o que fazer”, 
“como fazer”, “quando fazer” e “porque deve ser feito”. É necessária a elaboração completa de 
um dicionário de dados, para descrever todas as entidades envolvidas, refinando, com isso, os 
requisitos funcionais do software.
A Linguagem Unificada de Modelagem possui diagramas (representações gráficas do mod-
elo parcial de um sistema) que são usados em combinação, com a finalidade de obter todas as 
visões e aspectos do sistema.
MODelOS, VISõeS e DIAgrAMAS DA uMl
Para permitir a aplicação e utilização da UML em todas as fases do projeto e para possibilitar 
que todos os diferentes pontos de vista dos especialistas envolvidos no projeto estejam contem-
plados no projeto, a UML possui vários diagramas diferentes!
A imagem abaixo mostra uma parte desses diagramas:
Figura 4
Fonte: Internet
15
www.metodista.br/ead
Os Diagramas da UML estão divididos em:
Diagramas Estruturais
De Classe: este diagrama é fundamental e o mais utilizado na UML e serve 
de apoio aos outros diagramas. O Diagrama de Classe mostra o conjunto de 
classes com seus atributos e métodos e os relacionamentos entre classes.
De Objeto: o diagrama de objeto esta relacionado com o diagrama de classes e 
é praticamente um complemento dele. Fornece uma visão dos valores armaze-
nados pelos objetos de um Diagrama de Classe em um determinado momento 
da execução do processo do software.
De Componentes: está associado à linguagem de programação e tem por fi-
nalidade indicar os componentes do software e seus relacionamentos.
De implantação: determina as necessidades de hardware e características físi-
cas do Sistema.
De Pacotes: representa os subsistemas englobados de forma a determinar par-
tes que o compõem.
De Estrutura: descreve a estrutura interna de um classificador.
Diagramas Comportamentais
De Caso de uso (use Case): geral e informal para fases de levantamento e 
análise de Requisitos do Sistema.
De Máquina de Estados: procura acompanhar as mudanças sofridas por um 
objeto dentro de um processo.
De Atividades: descreve os passos a serem percorridos para a conclusão de 
uma atividade.
De Interação: dividem-se em:
De Sequência: descreve a ordem temporal em que as mensagens são 
trocadas entre os objetos.
Geral interação: variação dos diagramas de atividades que fornece 
visão geral dentro do sistema ou processo do negócio.
De comunicação: associado ao diagrama de Sequência, comple-
mentando-o e concentrando-se em como os objetos estão vinculados.
De tempo: descreve a mudança de estado ou condição de uma instân-
cia de uma classe ou seu papel durante o tempo.
OS PrInCIPAIS DIAgrAMAS DA uMl
a) Diagrama de Casos de uso (use Cases)
O Diagrama de Casos de Uso tem o objetivo de auxiliar a comunicação entre os analistas e 
o cliente.
Um diagrama de Caso de Uso descreve um cenário que mostra as funcionalidades do siste-
ma do ponto de vista do usuário. 
Universidade Metodista de São Paulo
16
O cliente deve ver no diagrama de Casos de Uso as principais funcionalidades de seu sistema.
O diagrama de Caso de Uso é representado por:
•	atores;
•	casos de uso;
•	relacionamentos entre estes elementos.
Estes relacionamentos podem ser:
•	associações entre atores e casos de uso;
•	generalizações entre os atores;
•	generalizações, extends e includes entre os casos de uso.
Exemplos:
Figura 5 
Fonte: Internet
b) Diagrama de Classes
Exibe um conjunto de classes, interfaces e colaborações, bem como seus relacionamentos. 
Esses diagramas são encontrados com maior frequência em sistemas de modelagem orientados 
a objetos e abrangem uma visão estática da estrutura do sistema.
Exemplos:
Figura 6 
Fonte: Internet
17
www.metodista.br/ead
c) Diagrama de Objetos
Exibe um conjunto de objetos e seus relacionamentos. Representa retratos estáticos de in-
stâncias de itens encontrados no diagrama de classes sob uma perspectiva de casos reais ou de 
protótipos.
Exemplos:
 
Figura 7 
Fonte: Internet
d) Diagrama de Sequência
Tem por objetivo descrever as comunicações necessárias entre objetos para a realização 
dos processos em um sistema computacional. Os diagramas de sequência tem este nome porque 
descrevem ao longo de uma linha de tempo a sequência de comunicações entre objetos.
Exemplo:
Figura 8 
Fonte: Internet
Universidade Metodista de São Paulo
18
Referências
BOEHM, Barry. Software Engineering Economics. Prentice-Hall, 1981.
GUEDES, Gilleanes T. A. uML 2: uma abordagem prática, 2. ed. São Paulo: Novatec, 2011.
PRESSMAN, Roger S. Engenharia de Software. 6. ed. Rio de Janeiro: McGrawHill, 2006.
SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Addison Wesley, 
2011.
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________ 
__________________________________________________________________________________
_________________________________________ 
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________ 
_________________________________________
_________________________________________
_________________________________________ 
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
19
www.metodista.br/ead
Universidade Metodista de São Paulo
20
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________ 
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
________________________________________
__________________________________________
_________________________________________
________________________________________
________________________________________
_________________________________________
_________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
________________________________________
__________________________________________
Objetivos:
Apresentar conceitos detalhados de mode-
lagem de banco de dados, teoria relacional e 
do projeto de banco de dados. Também serão 
apresentados conceitos de modelagem 
conceitual e lógica de banco de dados, 
a partir de requisitos.
Palavras-chave:
Modelo lógico; modelo conceitual; teoria 
relacional; projeto de banco de dados; banco 
de dados; entidade; relacionamento; atributo; 
cardinalidade.
Modelagem de 
Banco de Dados 
 
Prof. esp. Durval de Oliveira Dorta Junior
Módulo
www.metodista.br/ead
Modelagem e Documentação 
de sistemas
IntrODuçãO
Um dos principais propósitos da tecnologia da informação é automatizar processos existen-
tes ou, no caso de processos de alta complexidade, possibilitar a existência deles. Para atingir este 
objetivo são desenvolvidos os sistemas de informação. A modelagem de banco de dados é um 
fator importante no desenvolvimento destas soluções, considerando que todo processo utiliza e 
também pode criar dados. 
Para ilustrar, vamos analisar um ambiente de negócios típico, em que constatamos a exis-
tência de vários departamentos de diferentes áreas de atuação. Independentemente do nome 
destes departamentos podemos afirmar que eles são responsáveis pelos processos de negócios, 
por exemplo, Vendas, Compras, Contabilidade, Produção e outros tantos. Estes processos de uma 
empresa produzem e/ou utilizam dados para desempenhar o seu papel. Por exemplo, no mínimo, 
o processo de vendas manipula dados dos clientes, dos pedidos e dos produtos, então podemos 
afirmar que o sistema Vendas é o conjunto dos processos automatizados por programas de com-
putador e os dados criados ou alterados por estes. 
Concluímos que o conjunto de dados utilizados pelos processos é um componente impres-
cindível para o projeto de sistemas. Ao conjunto destes dados armazenados damos o nome de 
Banco de Dados. 
A definição de Banco de dados é: “Conjunto de dados integrados que tem por objetivo aten-
der a uma comunidade de usuários” (HEUSER, 2009).
A forma como armazenamos estes dados tem se desenvolvido desde o início da era da in-
formação, criando uma nova área de conhecimento, que chamamos de Modelagem de Banco de 
Dados. O seu propósito é o estudo das metodologias utilizadas na descrição formal dos tipos de 
dados que estão armazenados em um banco de dados. A esta descrição chamamos de Modelo 
de Banco de Dados.
O modelo de dados amplamente utilizado é modelo de dados relacional. Por este motivo, o 
nosso estudo será focado neste tipo de modelo.
O MODelO De DADOS relACIOnAl
O modelo de dados relacional foi introduzido inicialmente por Ted Codd, na época fun-
cionário da IBM no ano de 1970, por meio de seu artigo clássico (CODD, 1970; CHEN, 1976) que 
atraiu grande atenção imediata devido a sua simplicidade e base matemática. Sua base teórica 
reside na teoria de conjuntos e lógica de predicado de primeira ordem.
O modelo relacional representa o banco de dados como uma reunião de relações. Cada 
relação é semelhante a uma tabela de valores, ou seja, esta tabela é composta de cabeçalhos de 
colunas que representam o nome dos dados. Cada uma destas colunas possuem valores, que são 
os dados, e cada linha desta tabela representa uma ocorrência da tabela. 
Formalmente, os nomes no modelo relacional são os seguintes: a linha é chamada Tupla, 
um cabeçalho da coluna é chamado de Atributo, os valores dos dados na coluna é chamado de 
Domínio e a tabela é chamada de Relação. 
Universidade Metodista de São Paulo
22
Veja o exemplo abaixo:
Nome CPF Celular Rua Número CEP Cidade uF
João S. Rios 306.610.243-51 9995-3535 Consolação 2019 09000-430 São Paulo SP
Paula R. Santos 381.620.124-45 8476-9821 Jardim 300 01415-300 São Paulo SP
Barbara Passos 533.690.123-80 NULL Goiabeiras 230 03445-212 São Paulo SP
No modelo de dados relacional, a integração dos dados vai além dos atributos agrupados 
em uma relação, apresentando o relacionamento entre estas relações. Por exemplo, em uma 
empresa, em que todo funcionário trabalha em um departamento, e lembrando que departa-
mento é outra relação de dados, é necessário representar a informação associando corretamente 
cada funcionário ao único departamento no qual ele trabalha. Esta informação que caracteriza a 
associação entre as relações é tratada no modelo relacionalcom o nome de Relacionamento. A 
representação do conjunto das relações e de seus relacionamentos chamamos de Esquema de 
Banco de Dados.
Veja um exemplo de um Diagrama de Esquema de Banco de Dados:
 Na figura 2, acima, destaca-se:
Figura 1
Note, neste exemplo, cada coluna é um Atributo e cada linha é uma Tupla que 
representa uma ocorrência da Relação Funcionário, ou seja, cada Tupla é um 
Funcionário diferente e, também, chamada de uma Ocorrência da Relação. 
 Atributos 
 
Tuplas 
 Nome da 
Relação 
 
funCIOnÁrIO
A relação que retrata o Funcionário participa de dois relacionamentos, um com o 
Departamento ao qual este funcionário pertence e o outro com a Alocação de 
suas horas em projetos.
23
www.metodista.br/ead
A relação Alocação registra as horas que cada funcionário dedica a um determina-
do projeto, e se relaciona com o funcionário e o projeto para a devida associação 
do Funcionário com cada Projeto dos vários que ele pode trabalhar.
Além dos valores de dados que cada relação armazena (nome, horas, departa-
mento, etc.) o relacionamento entre estas relações é também uma informação ge-
rada, ou seja, com o relacionamento sabemos a qual departamento o funcionário 
pertence e em qual projeto ou projetos trabalha.
PrOJetO De bAnCO De DADOS
O projeto de banco de dados envolve três fases, descritas a seguir (HEUSER, 2009):
Modelagem Conceitual
É a primeira fase. É construído um modelo conceitual na forma de um diagrama 
entidade-relacionamento, comumente chamado de DER. Este modelo captura as 
necessidades da organização em termos de armazenamento de dados e as regras 
de negócio.
Modelo Lógico
A segunda etapa, também chamada de projeto lógico, é quando se transforma 
o modelo conceitual da primeira fase em um modelo lógico. O modelo lógi-
co define como o banco de dados será implementado em um SGBD específico. 
Lembrando que o SGBD, é o software que gerencia o banco de dados, sua sigla 
significa Sistema Gerenciador de Banco de dados.
Projeto físico
Terceira e última etapa do projeto de Banco de Dados, o modelo do banco de da-
dos é transcrito para um script na linguagem SQL e, também, é enriquecido com 
detalhes que influenciam no desempenho do banco de dados, mas não interferem 
em sua funcionalidade. O modelo obtido neste passo é o modelo físico do banco 
de dados pronto para ser usado no SGDB a fim de se criar o Banco de Dados.
MODelAgeM COnCeItuAl
A modelagem conceitual é independente do SGDB a ser utilizado e utilizaremos a aborda-
gem Entidade-Relacionamento (E-R), que não contém aspectos técnicos que poderiam se rela-
cionar a um SGDB específico. O objetivo da utilização deste tipo de modelagem é permitir um 
foco na captura de necessidades do usuário e suas regras de negócio. O resultado é um modelo 
gráfico chamado de Diagrama Entidade-Relacionamento ou mais comumente chamado DER ou 
MER (Modelo E-R), que por ser uma representação gráfica sem detalhes técnicos é facilmente 
usada também na validação com o usuário ou usuários que forneceram as necessidades e regras 
de negócio.
Universidade Metodista de São Paulo
24
A figura abaixo é um exemplo do Diagrama Entidade-Relacionamento (DER):
Figura 3
A seguir, abordaremos cada componente desta técnica, que foi criada em 1976 por Peter 
Chen (CHEN, 1976), podendo ser considerada como um padrão de fato para a modelagem con-
ceitual. Mesmo as técnicas de modelagem orientada a objetos, que têm surgido nos últimos anos, 
como a UML, baseiam-se nos conceitos da abordagem ER (HEUSER, 2009).
PrInCIPAIS eleMentOS DA AbOrDAgeM entIDADe-relACIOnAMentO
entIDADe
A entidade é um conceito fundamental da abordagem E-R. Segundo Heuser (2009), a enti-
dade é o conjunto de objetos da realidade modelada sobre os quais deseja-se manter informações 
no banco de dados. Importante observar é que, neste texto, o termo “objeto” possui a conotação 
que lhe é dada na linguagem natural, de “coisa, tudo que é perceptível ou manipulável”. Não fala-
remos, neste texto, do termo “objeto” como ele é usado na Teoria de programação de Orientação 
a Objetos.
Uma entidade representa um conjunto de objetos da realidade modelada. Como o objetivo 
de um modelo ER é modelar de forma abstrata um BD, interessam-nos somente os objetos sobre 
os quais deseja-se manter informações. Por exemplo, em um sistema de informações para con-
trolar os processos de uma escola, alguns exemplos de entidades poderiam ser Alunos, Cursos, 
Turmas, Avaliações, Disciplinas e Professores. Já em um sistema para controlar os processos de 
contas a pagar, algumas entidades podem ser os Fornecedores, Boletos, Notas fiscais e Bancos, 
entre outras.
25
www.metodista.br/ead
A entidade é representada através de um retângulo, que contém o nome da entidade. Al-
guns exemplos são mostrados abaixo:
Cada retângulo, que é cada entidade, representa um conjunto de objetos sobre os quais 
deseja-se guardar informações. Assim, no exemplo da Figura 4, o primeiro retângulo designa o 
conjunto de todos os funcionários sobre os quais se deseja manter informações no banco de 
dados, enquanto o segundo retângulo designa o conjunto de todos os projetos sobre os quais 
se deseja manter informações. Caso seja necessário referir-se a um objeto particular (um deter-
minado funcionário ou um determinado departamento) fala-se em ocorrência de entidade ou 
“instância” de entidade.
Da forma como está apresentada, o modelo da Figura 4 indica apenas quais os conjuntos de 
objetos sobre os quais deseja-se manter informações, mas não quais as informações que devem 
ser mantidas para cada objeto. Estas informações são definidas pelas propriedades das entidades, 
dadas pelos relacionamentos, atributos e generalizações/especializações.
AtrIbutO
O conceito de atributo serve para associar informações a ocorrências de entidades ou de re-
lacionamentos. O atributo é o elemento que representa um determinado dado de uma ocorrência 
de uma entidade ou de um relacionamento.
O atributo pode ser de diferentes tipos. 
Um atributo simples tem a seguinte representação:
Nesta figura, acima, nota-se que os atributos código e tipo estão associados por meio de 
uma linha ligando o círculo que representa o atributo a uma entidade.
Figura 5
Figura 4
Universidade Metodista de São Paulo
26
AtrIbutO IDentIfICADOr 
Uma condição é que toda entidade possua uma identificação demostrando que cada enti-
dade é única, por exemplo, a entidade projeto, na figura 5, tem o atributo código associado a ela 
para identificar que um projeto é diferente do outro. Este tipo de atributo é chamado de atributo 
identificador com o seu círculo preenchido.
relACIOnAMentO
Uma das propriedades sobre as quais pode ser desejável manter informações é a associação 
entre objetos. Exemplificando, em um sistema de contas a pagar é importante saber-se a qual 
fornecedor se associa um boleto a ser pago. A propriedade de entidade que especifica as associa-
ções entre objetos é o relacionamento.
O relacionamento associa as ocorrências de uma entidade à outra entidade, conforme co-
mentado no parágrafo anterior, por exemplo, cada boleto, que é uma ocorrência da entidade bo-
leto, estará associado a um fornecedor específico que, por sua vez, é uma ocorrência da entidade 
fornecedor.
O relacionamento é representado por um losango, ligado por linhas aos retângulos, que 
representam as entidades que participam do relacionamento.
A figura 6, a seguir, representa o relacionamento comentado anteriormente:
Neste modelo, vemos que o Fornecedor se associa ao Boleto pelo relacionamento Emite, ou 
seja, é o fornecedor que emite o boleto para pagamento. 
Este modelo expressa que o BD mantém informações sobre:
•	um conjunto de objetos classificados como Fornecedores (entidade FORNECEDOR);
•	um conjunto de objetos classificados como Boletos (entidade BOLETO); e
•	um conjunto de associações, cada uma ligando um Fornecedor a cada Boleto emi-
tido por ele (relacionamento EMITE);
•	Note os atributos, de fato sem eles a entidade não é corretamenterepresentada, 
pois os dados residem nos atributos da entidade.
Figura 6
27
www.metodista.br/ead
Quando nos referirmos a associações específicas em um relacionamento, vamos nos referir 
a ocorrências ou instâncias de relacionamentos. No caso do relacionamento EMITE, uma ocorrên-
cia seria um par específico, formado por uma determinada ocorrência da entidade FORNECEDOR 
e por uma determinada ocorrência da entidade BOLETO.
Para fins didáticos, vamos utilizar um diagrama de ocorrências (HEUSER, 2009), apresenta-
do na Figura 7. 
Este diagrama refere-se ao Diagrama ER da Figura 6.
Em um diagrama de ocorrências, ocorrências de entidades são representadas por círculos 
brancos e ocorrências de relacionamentos por círculos negros. As ocorrências de entidade partici-
pantes de uma ocorrência de relacionamento são indicadas pelas linhas que ligam o círculo negro 
representativo da ocorrência de relacionamento aos círculos brancos representativos das ocorrên-
cias de entidades relacionadas. Assim, a Figura acima representa que, entre outras, há uma ocor-
rência de EMITE que liga o fornecedor f1 com o boleto b1. Observe-se que, na forma como está, 
o modelo da Figura acima não informa quantas vezes uma entidade é associada através de um 
relacionamento (veremos como isso pode ser representado mais adiante). O modelo apresentado 
permite que uma ocorrência de entidade (por exemplo, o fornecedor f4) não esteja associada a 
alguma ocorrência de entidade através do relacionamento, e que uma ocorrência de entidade 
(por exemplo, o boleto b3) esteja associada a exatamente uma ocorrência de entidade através do 
relacionamento ou, ainda, que uma ocorrência de entidade fornecedor (por exemplo, o forncedor 
f1) esteja associada a mais de uma ocorrência de entidade boleto através do relacionamento.
AutOrrelACIOnAMentO
Não é obrigatório um relacionamento associar-se a ocorrências de entidades diferentes. A 
Figura abaixo mostra um DER de um autorrelacionamento, isto é, um relacionamento entre ocor-
rências de uma mesma entidade. Neste caso, é necessário um conceito adicional, o de papel da 
entidade no relacionamento. 
Universidade Metodista de São Paulo
28
No caso do relacionamento de supervisão, os funcionários são supervisionados por um 
chefe que, por sua vez, também é um funcionário, uma ocorrência de funcionário exerce o papel 
de chefe e a outra ocorrência de pessoa exerce o papel de supordinado. Papéis são anotados no 
DER como mostrado na Figura 8. No caso de relacionamentos entre entidades diferentes, como 
o de FORNECEDOR EMITE BOLETO mostrado na Figura 6 anteriormente, não é necessário indicar 
os papéis das entidades, já que eles são óbvios.
A Figura 9 apresenta um diagrama de ocorrências para o Modelo ER da Figura 8. Observe 
os papéis de chefe e subordinado das ocorrências da entidade Funcionário, em cada ocorrência 
de relacionamento as linhas que ligam os círculos representativos das ocorrências “Chefe”com as 
ocorrências representativas de “Subordinado”.
Figura 8
Figura 9
No diagrama da figura 9, notamos que a relação de supervisão para as ocorrências é a se-
guinte:
•	Funcionário f4 é chefe do funcionário f5 que é, por consequência, subordinado ao f4;
•	Funcionário f5 é chefe do funcionário f3 que é, por consequência, subordinado ao f5;
•	Funcionário f3 é chefe dos funcionários f1 e f2 que são, por consequência, subordinados 
ao f3.
O motivo de se usar a mesma entidade para caracterizar os papéis é que partimos do princí-
pio de que todos são funcionários. O atributo cargo da entidade cumpre o papel de diferenciação 
entre os diferentes cargos existentes. O aluno poderá pensar em criar uma entidade diferente para 
29
www.metodista.br/ead
cada cargo, mas esta solução é fraca, pois a cada novo cargo ou nível hierárquico criado haveria 
a necessidade de alterar fisicamente o banco de dados, o que tornaria o sistema pouco prático. 
Também existem outros motivos relacionados à performance e integridade da informação que 
tornam a solução do autorrelacionamento a melhor para o requisito de diferentes papéis exerci-
dos por uma mesma entidade. 
CArDInAlIDADe
O conceito de cardinalidade é de grande importância para a modelagem de banco de dados. 
Para fins de projeto de banco de dados, a cardinalidade é uma característica do relacionamento. 
A cardinalidade qualifica quantas ocorrências de uma entidade se relacionam com as ocor-
rências da entidade a qual está associada no relacionamento. É traduziada pela anotação do nú-
mero mínimo e máximo de ocorrências relacionadas entre as entidades.
As cardinalidades possíveis são as seguintes:
- (0,1) Lê-se no mínimo Zero ocorrência e no máximo Uma ocorrência;
- (1,1) Lê-se no mínimo Uma ocorrência e no máximo Uma ocorrência;
- (0,n) Lê-se no mínimo Zero ocorrência e no máximo várias ocorrências;
- (1,n) Lê-se no mínimo Uma ocorrência e no máximo várias ocorrências;
- (n,n) ou (n,m) Lê-se no mínimo Várias ocorrências e no máximo Várias ou Muitas 
ocorrências, (n,n) e (n,m) são equivalentes e têm o mesmo significado. Importante res-
saltar que este tipo de cardinalidade existe somente no modelo conceitual e não estará 
presente no modelo lógico, as demais persistem no modelo lógico.
Agora, vamos para um exemplo prático, vamos modelar os seguintes requisitos:
•	Uma empresa é composta de empregados que são organizados em departamen-
tos no qual trabalham com atividades de uma área específica, por exemplo, finanças, 
vendas, oficina e assim por diante.
•	Todo empregado trabalha em um único departamento.
•	Todo departamento é composto de, no mínimo, um empregado. 
•	Departamento pode ter mais de um empregado.
O modelo abaixo atende a estes requisitos:
Figura 10
Universidade Metodista de São Paulo
30
A figura 10 é um Diagrama ER, ou seja, um Modelo ER, contendo o relacionamento e as 
entidades “Empregado trabalha no Departamento”. Agora, para melhor entendimento da quanti-
dade de ocorrências que se relacionam entre uma entidade e a outra, vamos analisar o Diagrama 
de Ocorrências:
No diagrama de ocorrências da figura 11, podemos analisar os seguintes requisitos:
Figura 11
Todo Empregado trabalha para um departamento e somente um departamento. Neste 
caso, sabemos que cada ocorrência da entidade Empregado se relaciona com no mí-
nimo uma ocorrência da entidade Departamento e também que cada ocorrência da 
entidade Empregado se relaciona com máximo uma ocorrência da entidade Departa-
mento.
Todo Departamento é composto de um ou mais empregados. Neste caso, sabemos que 
cada ocorrência da entidade Departamento se relaciona com no mínimo uma ocorrên-
cia da entidade Empregado e também que cada ocorrência da entidade Departamento 
se relaciona com no máximo várias ocorrências da entidade Empregado.
O Modelo ER correspondente aos requisitos acima com as suas cardinalidades representa-
das, é o seguinte:
31
www.metodista.br/ead
Na Figura 12, note os números entre parênteses. O primeiro número é a cardinalidade mí-
nima e o segundo é a máxima. Ao lado da entidade Empregado está a sua cardinalidade (1,N) e 
o mesmo ocorre com o departamento com a sua cardinalidade (1,1) no relacionamento Trabalha. 
A cardinalidade é característica de todo relacionamento e sempre haverá a indicação da 
cardinalidade mínima e máxima para cada extremo do relacionamento.
Neste exemplo acima, lê-se, cada ocorrência da entidade Empregado está relacionada com 
no mínimo uma e no máximo uma ocorrência da entidade Departamento, e cada ocorrência en-
tidade Departamento está relacionada com no mínimo uma e no máximo várias ocorrências da 
entidade Empregado.
tIPOS De relACIOnAMentO
Os relacionamentos são classificados quanto a sua cardinalidade máxima nos seguintes 
tipos de relacionamento:
Figura 12
Relacionamento 1:1 ou Relacionamento Um para Um;
Relacionamento 1:n ou Relacionamento Um para Vários;
Relacionamento n:n (ou n:m) ou Relacionamento Vários para Vários ou Vários para 
Muitos. As anotações n:n e n:m são equivalentes e têm omesmo significado. 
Importante ressaltar que este tipo de relacionamento existe somente no modelo 
conceitual e não estará presente no modelo lógico, os demais persistem no mo-
delo lógico.
Universidade Metodista de São Paulo
32
A seguir, são apresentados os exemplos dos tipos de Relacionamentos:
Relacionamento 1:1 ou Relacionamento Um para Um
 
Para entender este relacionamento, sua cardinalidade e tipo, vamos primeiro entender seus 
requisitos:
- A pessoa pode estar Viva ou Morta, sendo assim pode Não ter um Atestado de óbito. Por 
este motivo, a cardinalidade mínima no atestado é Zero e somente um atestado pode existir por 
pessoa quando esta falecer;
- Todo atestado de óbito, quando existir, está relacionado a somente uma pessoa no míni-
mo e no máximo.
O tipo de relacionamento aqui apresentando é do tipo um para um. Note que a cardinalida-
de máxima de ambos os extremos do relacionamento denotam esta característica.
Relacionamento 1:n ou Relacionamento Um para Vários
Figura 14
Figura 13
Este relacionamento da figura 14 atende aos seguintes requisitos:
- O curso pode ter no mínimo nenhum aluno matriculado e no máximo vários alunos ma-
triculados.
- O Aluno para ser aluno deve estar matriculado no mínimo em um curso e em mais ne-
nhum outro.
O tipo de relacionamento aqui apresentando é do tipo um para vários. Note que a cardina-
lidade máxima de ambos os extremos do relacionamento denotam esta característica.
33
www.metodista.br/ead
Mais um exemplo deste tipo de relacionamento, agora analisando um exemplo de autor-
relacionamento apresentado anteriormente na figura 8 e representado na figura abaixo com as 
suas cardinalidades:
O relacionamento da figura 15 atende aos seguintes requisitos:
- O funcionário possui no mínimo nenhum e no máximo vários funcionários como 
subordinados, a cardinalidade mínima igual a zero representa o caso do assistente que 
não possui Subordinados.
- O funcionário responde a no mínimo nenhum e no máximo a único Chefe. Neste caso, a 
cardinalidade mínima igual a Zero é para contemplar ao requisito que há funcionários que não 
possuem Chefe, por exemplo, o presidente da empresa não possui Chefe. 
O tipo de relacionamento aqui apresentando é do tipo um para vários. Note que a cardina-
lidade máxima de ambos os extremos do relacionamento denotam esta característica.
Relacionamento n:n ou Relacionamento Vários para Vários
(ou também chamado Vários para Muitos). 
Figura 15
Figura 16
Universidade Metodista de São Paulo
34
 Este relacionamento da figura 16 representa aos seguintes requisitos:
- O Empregado pode estar alocado ou não em um ou mais projetos;
- O projeto para existir deve ter alocado para ele, um Empregado, e também pode ter alo-
cado vários Empregados.
O tipo de relacionamento aqui apresentando é do tipo vários para vários muitas vezes cha-
mado, também, de vários para muitos ou, ainda, muitos para muitos. Note que a cardinalidade 
máxima de ambos os extremos do relacionamento denotam esta característica.
AtrIbutO ASSOCIADO A uM relACIOnAMentO
Uma novidade neste relacionamento da figura 16 é o atributo associado a um relacio-
namento. Assim como entidades os relacionamentos podem possuir atributos. No exemplo da 
figura 16, o atributo Horas Alocadas tem o objetivo de registrar a quantidade de horas que o 
funcionário dedicará a cada um dos projetos que pode participar.
Podemos, também, alternativamente representar este tipo de relacionamento Vários para 
Vários com dois relacionamentos Um para Vários, com a mesma função no Modelo ER, ,aliás, esta 
será a solução a ser empregada no modelo lógico que logo mais veremos. 
AtrIbutO MultIVAlOrADO
O Atributo multivalorado representa a informação que ocorre mais de uma vez para uma 
mesma entidade.
Analisando o modelo ER acima, concluímos que o Empregado pode ter nenhum, um ou 
mais telefones, por exemplo, pode ter o telefone residencial e dois telefones Celulares ou mesmo 
pode não ter telefones. No exemplo da figura 17, este requisito esta representado pela cardinali-
dade atribuída ao atributo Telefone, em que podemos ler que o atributo telefone pode no mínimo 
não existir e no máximo existir várias vezes para um mesmo Empregado.
AtrIbutO DerIVADO
O Atributo derivado representa a informação que é obtida por cálculo a partir de outro atri-
buto, o atributo derivado é meramente informativo no modelo e não existirá no modelo lógico.
Figura 17
35
www.metodista.br/ead
Neste modelo ER, acima, o atributo idade é representado por linhas pontilhadas denotando 
que este atributo é do tipo atributo derivado, o motivo é que a idade é uma informação obtida 
por um cálculo a partir da informação da data de nascimento e por este motivo o atributo deri-
vado idade está ligado ao atributo data de nascimento. Os atributos derivados não constarão no 
modelo lógico, porque realmente não são armazenados. A sua representação no modelo ER tem 
por finalidade ajudar ao desenvolvedor, mostrando qual é a informação que será obtida. Neste 
caso do exemplo da figura 18, o modelo indica que o desenvolvedor deverá fazer um cálculo com 
a informação do atributo Data de Nascimento para obter a idade.
AtrIbutO COMPOStO
O Atributo Composto representa a informação agrupada, ou seja, este tipo de atributo é 
composto por outros atributos. 
Figura 18
Figura 19
Na figura 19, é apresentando o modelo ER com o atributo Endereço do tipo composto. 
Todo atributo composto tem em sua estrutura outros ligados a ele. Neste caso, o endereço é 
composto pelos atributos Rua, Número, Cidade, Estado e CEP.
Universidade Metodista de São Paulo
36
generAlIZAçãO e eSPeCIAlIZAçãO
Utilizamos o recurso de generalização e es-
pecialização quando há subtipos relevantes a se-
rem modelados. Com este recurso podemos atri-
buir propriedades particulares a um subgrupo de 
ocorrências de uma mesma entidade.
MODelO er, DIAgrAMA er
Ambos são sinônimos, o Modelo Entidade 
Relacionamento (MER) e o Diagrama Entidade Re-
lacionamento (DER). É comum referir- se com mais 
frequência utilizando a abreviatura DER.
eXeMPlO PrÁtICO
O DER da figura abaixo é um modelo proposto para um sistema que controla o cadastro de 
funcionários, seus dependentes, departamentos, e os projetos em que os funcionários trabalham.
Figura 21
Figura 20
37
www.metodista.br/ead
No DER apresentado na figura 21 podemos verificar vários conceitos apresentados anterior-
mente, agora consolidados em único DER.
entIDADe frACA
É chamada de entidade fraca quando no relacionamento a sua cardinalidade mínima é Zero, 
ou seja, ela é opcional no relacionamento. No exemplo da figura 21, observamos uma entidade 
fraca no relacionamento Empregado Possui Dependente. Neste caso, a entidade fraca é Depen-
dente, pois para uma ocorrência de Empregado existir não é necessário existir uma ocorrência de 
Dependente, mas para Dependente existir é necessário que exista uma ocorrência de Empregado. 
A entidade fraca também é chamada de entidade opcional. 
Também pode ser utilizada a opção de representar a entidade fraca não somente pela sua 
cardinalidade, mas também por uma linha mais larga do seu lado do relacionamento.
PrOPrIeDADeS releVAnteS nA MODelAgeM er
É importante considerar algumas propriedades relevantes na fase de modelagem conceitual 
(HEUSER, 2009):
Um modelo ER é um modelo formal:
Um modelo ER é um modelo formal, preciso, não ambíguo. Em outras 
palavras, diferentes pessoas lendo o mesmo modelo ER devem entender 
exatamente o mesmo significado.
Modelos ER têm poder de expressão limitado:
Em um modelo ER estão registradas apenas algumas propriedades de um 
banco de dados, há mais elementos importantes para o projeto do ban-
co de dados, principalmente relevantes para a implementação física, tais 
como, restrições de integridade entre outras.
Diferentes modelos podem ser equivalentes:
Considerando a finalidade do projeto de banco de dados, dois modelos 
ER são equivalentes quando ambos geram o mesmo esquema de banco 
de dados.
COnSIDerAçõeSSObre O ASPeCtO teMPOrAl DA InfOrMAçãO
O Banco de dados e o seu modelo ER correspondente devem refletir o aspecto temporal 
quando é exigido no requisito, e, portanto, deve ser considerado na modelagem.
Um exemplo é o relacionamento Empregado Trabalha Departamento, que foi representa-
do na figura 18. Da forma como foi implementado o modelo nesta figura, não seria possível re-
gistrar historicamente os vários departamentos em que um Empregado pode trabalhar em uma 
empresa durante a sua trajetória profissional. Caso o requisito para o sistema exija este registro 
histórico, o modelo ER que cobre adequadamente esta exigência é o seguinte:
Universidade Metodista de São Paulo
38
Na figura 22 foi adicionada a entidade Lotação. Seu objetivo é registrar o histórico dos de-
partamentos que o funcionário trabalhou na empresa durante a sua carreira. A entidade Lotação 
associa o empregado ao departamento que trabalha ou que trabalhou.
Na entidade Lotação, o seu atributo identificador sendo a data de início, assegura que 
haverá somente uma lotação por data. Para se consultar onde este funcionário, atualmente, está 
trabalhando, basta consultar a última ocorrência da entidade Lotação e, em seguida, consultar a 
ocorrência da entidade Departamento que estiver associada a esta ocorrência específica da enti-
dade Lotação.
Note, ainda, que no exemplo da figura 22, as cardinalidades asseguram que cada ocorrên-
cia da entidade Lotação estará associada a uma única ocorrência das entidades Departamento e 
Empregado, e que também toda ocorrência da entidade Empregado e da entidade Departamento 
poderá ter uma ou mais lotações.
MODelO lÓgICO
Este modelo é a representação do Banco de Dados Relacional e geralmente é a transforma-
ção do modelo ER, que é um modelo abstrato. 
Adotamos a abordagem de transformação do Modelo ER em Modelo Lógico, sendo esta 
uma fase do projeto de Banco de Dados Relacional posterior a Modelagem Conceitual na qual 
obtemos o Diagrama Entidade Relacionamento (DER).
Antes de iniciarmos o estudo dos passos de transformação do Modelo ER para o Modelo 
Lógico, apresentamos a composição de um Banco de Dados Relacional.
bAnCO De DADOS relACIOnAl
O Banco de Dados Relacional é composto por tabelas também chamadas de relações. Va-
mos empregar a terminologia tabela que é a mais comum e também a adotada pelos produtos 
comerciais de gerenciamento de banco de dados.
tAbelA
A tabela é um conjunto de linhas (tuplas, na terminologia acadêmica). A tabela é identifica-
da pelo seu nome. 
Cada linha é composta por uma série de campos (valor de atributo, na terminologia acadê-
mica). 
Figura 22
39
www.metodista.br/ead
Cada campo é identificado por um nome de campo (nome do atributo).
O conjunto de campos de um mesmo nome forma a coluna da tabela.
Os valores, que são as informações armazenadas nos campos da tabela, são atômicos e 
monovalorados. Atômico significa que o campo não pode ser composto de outros. E mono-
valorado significa que o campo possui somente um valor, ele não é um campo do tipo vetor 
(arranjo ou array). 
Figura 22
CHAVe
É um conceito básico que tem as funções de identificar as linhas e de estabelecer relações 
entre as tabelas.
Há três tipos de chaves: Chave Primária, Chave Estrangeira e Chave Alternativa.
CHAVe PrIMÁrIA
A chave primária é uma coluna ou combinação de colunas que tornam cada linha da tabela 
única, ou seja, identifica cada linha da tabela como distinta das demais.
Na figura abaixo, um exemplo de tabela com chave primária composta.
Figura 24
Universidade Metodista de São Paulo
40
Na figura abaixo, um exemplo de tabela com chave primária não composta.
CHAVe eStrAngeIrA
A chave estrangeira é uma coluna ou combinação de colunas que correspondem aos valo-
res de uma chave primária de outra tabela.
A chave estrangeira é o meio pelo qual é implementado o relacionamento entre tabelas de 
um banco de dados relacional.
Na figura abaixo, encontra-se um exemplo de chave estrangeira. 
Figura 25
Figura 26
Na Figura 26, a tabela Aluno possui uma chave estrangeira que é formada pelo atributo 
Curso, que tem valores iguais aos valores de uma chave primária de outra tabela chamada Curso. 
Note que, também, possui a chave primária Matrícula para atender ao requisito obrigatório da 
modelagem relacional em que toda tabela deve conter uma coluna que identifica cada ocorrên-
cia como única. Neste caso, o número da matrícula será único mesmo que ocorram alunos com 
nomes idênticos.
41
www.metodista.br/ead
Na figura 27, podemos ver o relacionamento entre a chave estrangeira da tabela Aluno e a 
chave primária da tabela Curso, verificando os valores correspondentes em cada tabela do atribu-
to Curso, que contém o código de cada curso.
Figura 27
CHAVe AlternAtIVA
Há situações em que há mais de uma coluna ou mais de um conjunto de colunas que pode 
perfeitamente indicar a distinção de uma linha das demais, uma destas colunas ou conjunto de 
colunas será a chave primária e as demais serão as chaves alternativas. As chaves alternativas são 
muito utilizadas para se encontrar a informação por meio de outras referências além da coluna ou 
colunas que determinam a chave primária.
Figura 28
Na figura acima, há um exemplo de chave alternativa.
Universidade Metodista de São Paulo
42
AS CHAVeS e A reStrIçãO De IntegrIDADe
É importante ressaltar que o conceito de chave primária e de chave estrangeria são impor-
tantes restrições de integridade, ou seja, existem não somente para identificar as linhas e construir 
relacionamentos, respectivamente, mas também garantem a integridade da informação de forma 
que somente os valores permitidos possam ser inseridos e / ou alterados nas suas colunas.
eSqueMA teXtuAl DO bAnCO De DADOS relACIOnAl
Uma notação compacta de esquema textual é bem prática e de fácil utilização. A seguir, é 
mostrado um esquema textual correspondente às tabelas da figura 27.
Figura 29
Na figura 29, o esquema textual utiliza o sublinhado para indicar a chave primária. O nome da 
tabela está fora dos parênteses enquanto que dentro dos parênteses estão os atributos (colunas).
A chave estrangeira é indicada pela seta quando liga a coluna, que é chave estrangeira, ao 
seu correspondente de chave primária na outra tabela. Note que as cardinalidades mínimas e 
máximas são representadas nos extremos do relacionamento indicado pela seta que une a chave 
estrangeira com a chave primária.
DIAgrAMAçãO DO bAnCO De DADOS relACIOnAl
Existem diversos esquemas diagramáticos 
para o modelo relacional. A seguir, um exemplo 
muito utilizado atualmente:
O diagrama da figura 30 trata os elementos 
da seguinte forma:
Chave Primária: A coluna ou o conjunto de 
colunas a que se atribui o papel de chave primá-
ria tem ao extremo do lado esquerdo as iniciais PK 
entre parênteses. Estas iniciais são a tradução de 
chave primária para a língua inglesa (Primary Key).
Chave Estrangeira: A coluna ou o conjunto de 
colunas a que se atribui o papel de chave estran-
geira tem ao extremo do lado esquerdo as iniciais 
FK entre parênteses. Estas iniciais são a tradução 
de chave estrangeira para a língua inglesa (Foreign 
Key) e a seta liga a tabela que contém a chave es-
trangeira com a tabela que contém a chave primá-
ria correspondente no relacionamento.
Figura 30
43
www.metodista.br/ead
trAnSfOrMAçãO entre OS MODelOS er e lÓgICO
A transformação entre os modelos Entidade Relacionamento (ER) e o Modelo Lógico (Ban-
co de dados Relacional) é implementada por um processo de passos. A seguir, descrevemos um 
processo simplificado:
PASSOS DA trAnSfOrMAçãO
Para toda entidade no Modelo ER cria-se uma tabela para o modelo relacional. 
Os atributos desta tabela serão os atributos simples da entidade ou compo-
nentes simples de atributos compostos. A chave primária desta tabela será um 
dos atributos identificadores da entidade. Os atributos compostos serão sempre 
decompostos em atributos simples.
Para toda entidade fraca, ou seja, com cardinalidade mínimaZero no Modelo 
ER, cria-se uma nova tabela no modelo relacional. Os atributos desta tabela se-
rão os atributos simples da entidade ou componentes simples de atributos com-
postos mais a chave primária (como chave estrangeira) da tabela proprietária. A 
chave primária desta tabela será a chave primária da tabela proprietária mais o 
identificador da entidade fraca. 
Para todo relacionamento do Um para Um, na chave primária de uma das tabe-
las envolvidas no relacionamento (preferencialmente a de cardinalidade míni-
ma “zero”, se houver), inclui-se como chave estrangeira a chave da outra tabela 
envolvida no relacionamento. Os atributos do relacionamento acompanham a 
chave estrangeira.
Para todo relacionamento do tipo Um para Vários pega-se a chave primária da 
tabela do lado 1 e inclui-se como chave estrangeira na tabela do lado N. Os atri-
butos do relacionamento acompanham a chave estrangeira.
Para todo relacionamento do tipo Vários para Vários cria-se uma nova tabela. Os 
atributos desta tabela serão as chaves primárias das tabelas envolvidas, incluídas 
como chave estrangeira, mais os atributos do próprio relacionamento. A chave 
primária desta tabela será as chaves primárias das tabelas envolvidas.
Para todo atributo multivalorado cria-se uma nova tabela. Os atributos desta ta-
bela serão a chave primária da tabela de origem mais o próprio atributo multiva-
lorado. A chave primária dessa tabela deve ser composta destes dois atributos.
Preferencialmente, eliminar a especialização utilizando atributos adicionais na 
entidade generalizada. Estes atributos devem conter como domínio as especia-
lizações. Caso não seja possível o procedimento acima, optar por incluir nas en-
tidades específicas a chave primária da entidade geral como chave estrangeira. 
Universidade Metodista de São Paulo
44
eXeMPlO De trAnSfOrMAçãO entre MODelOS
Utilizando o software BR-Modelo, geramos o seguinte Modelo Lógico de um banco de 
dados relacional com base na transformação do modelo conceitual, ou seja, o Modelo Entidade 
Relacionamento do DER da figura 21. 
Na figura 31, o modelo produzido com a ferramenta BR-Modelo utiliza a seguinte nomen-
clatura:
- Chave Primária – Chaves em Amarelo.
- Chave Estrangeira – Chaves em Cinza.
- Coluna de uma chave primária composta, que também é uma chave estrangeira - Chaves 
em dourado com uma parte em cinza. 
- Atributos com nomes e tipos de dados.
- Nome da Tabela no topo do retângulo.
- Relacionamentos são as linhas ligando as entidades e apresentando as cardinalidades 
mínimas e máximas de cada relacionamento.
Nota-se o seguinte:
- Cada entidade do modelo conceitual se torna uma tabela.
- O relacionamento muitos para muitos, que alocava os Empregados nos Projetos, foi subs-
tituído por uma nova tabela e dois relacionamentos um para vários.
Figura 31
45
www.metodista.br/ead
- A chave Primária da tabela Alocação criada a partir de um relacionamento do modelo 
conceitual possui uma chave primária composta de duas colunas e estas duas colunas também 
são chaves estrangeiras cada uma.
- Note que no lugar do atributo multivalorado Telefone foi criada a tabela Telefone.
- Nesta tabela Telefone, a chave primária é composta pelo próprio atributo telefone e mais 
o atributo código do empregado, sendo este último também uma chave estrangeira.
Referências
CHEN, P. P.-S. The entity-relationship model—toward a unified view of data. ACM Transac-
tions on Database Systems (TODS) , 1 (1), 9-36, (1976).
CODD, E. F. A relational model of data for large shared data banks. (P. Banxedale, Ed.) Com-
munications of the AMC , 13 (6), (1970), p. 377-387.
DATE, C. J. Introdução a Sistemas de Banco de Dados. Sao Paulo, SP: Editora Campus, 
(2004).
ELMASRI, R. Sistemas de Banco de Dados. Tradução da 6. ed. americana). São Paulo, SP: 
Pearson, (2011).
HEUSER, C. Projeto de Banco de Dados. Porto Alegre/RS, Brasil: Bookman, (2009).
Universidade Metodista de São Paulo
46
Módulo
www.metodista.br/ead
Modelagem e Documentação 
de sistemas
Engenharia de 
Requisitos
Parte 1
Prof. Me. André luiz Perin
Objetivos:
Apresentar a disciplina e definir os conceitos 
básicos de engenharia de software.
Apresentar o ciclo de vida de software e os 
processos de software.
Palavras-chave: 
Engenharia de software; engenharia 
de requisitos; ciclo de vida de software.
Universidade Metodista de São Paulo
48
IntrODuçãO
Software de computador pode ser entendido como o conjunto de programas que podem 
ser executados em computadores de qualquer tipo e arquitetura, seu conteúdo e seus documen-
tos, em formato digital ou impresso.
Os profissionais de software são aqueles que constroem e/ou mantêm o software ao longo 
do tempo. Tanto a construção quanto a manutenção do software não seguem os mesmos proces-
sos conhecidos de outras áreas.
A essência da engenharia de software envolve algumas etapas que podem ser resumidas 
nos seguintes itens: compreensão do problema, planejamento da solução, execução do plano e 
verificação do resultado.
Compreensão do Problema
A Compreensão do Problema é a etapa inicial e envolve as tarefas de Comunicação e Análise. 
A fase de Comunicação é feita através da interação entre as partes interessadas, ou seja, o cliente 
ou seus representantes e o desenvolvedor ou grupo de desenvolvedores.
Planejamento da solução
Além das tarefas de gerenciamento de projetos, que são entendidas como as tarefas que 
não fazem parte do ciclo de vida de software e podem ser utilizadas por qualquer tipo de produto, 
envolve as tarefas de Modelagem e Projeto de Software. A tarefa de Modelagem de Software de-
fine o conjunto de atividades necessárias para a construção de um ou mais modelos do sistema. 
O Projeto de Software envolve a elaboração de modelos mais aprofundados e técnicos, voltados 
ao programador, com o objetivo de fornecer detalhes técnicos que, muitas vezes, não são de 
conhecimento do cliente.
Execução do Plano
A execução do plano de projeto envolve a geração de código, sua transformação em execu-
tável e alguns testes iniciais.
Verificação do Resultado
Para verificar o resultado são conduzidos testes com os objetivos de achar defeitos ou falhas 
do software, tanto no processo que o software automatiza quanto na sua aderência aos desejos e 
necessidades do cliente.
As atividades de garantia da qualidade do software são estabelecidas com o objetivo de 
minimizar ou eliminar os defeitos do software durante e após a sua construção.
engenHArIA De SISteMAS
A engenharia de sistemas parte do princípio que o software é parte de algo maior e os ob-
jetivos do sistema devem ser estabelecidos antes de serem estabelecidos os objetivos do software.
O profissional responsável pelo sistema, ou engenheiro de sistemas, trabalha com o obje-
tivo de entender as necessidades dos sistemas, ou requisitos, através da interação com o cliente, 
os futuros usuários e quaisquer outros interessados.
49
www.metodista.br/ead
Sistemas baseados em computador
Um sistema baseado em computador pode ser definido como um conjunto ou arranjo de 
elementos organizados para atingir alguma meta pré-definida por meio do processamento da 
informação (PRESSMAN, 2006).
A meta ou objetivo definido pode ser desde a automação, uma simples função do negócio, 
até a geração de um produto completo.
eleMentOS De uM SISteMA bASeADO eM COMPutADOr
Um sistema pode ser composto e utilizar diversos elementos do sistema. São eles:
Software
Pode ser definido como programas de computador, estruturas de dados e outros produtos 
de trabalho necessários.
Hardware
São os equipamentos ou dispositivos eletrônicos ou eletromecânicos que possuem capa-
cidade computacional (computadores, microcontroladores e conexões de comunicação) e per-
mitem o fluxo de informações e acesso às funções do mundo externo (sensores e atuadores).
Pessoal
São as pessoas que utilizam o sistema (usuários) e as pessoas que mantêm o sistema (op-
eradores), tanto na parte de hardware quanto de software.
Banco dedados
É o grande conjunto de informações organizadas, persistente ao longo do tempo e acessível 
por meio de software.
Documentação
São os documentos que descrevem o sistema, o seu uso e a sua operação, tanto para os 
operadores quanto para os usuários. Podem também incluir os documentos utilizados para a 
construção do sistema.
Procedimentos
São as etapas que definem o uso e o contexto de cada elemento específico do sistema.
HIerArquIA DA engenHArIA De SISteMAS
Um sistema complexo pode ser interpretado como um conjunto de elementos que são eles 
mesmos outros sistemas. 
A hierarquia da engenharia de sistemas envolve um conjunto de procedimentos que trata o 
sistema a partir de seu nível mais alto para o mais baixo, chamados de top-down, e outro conjunto 
que trata o sistema a partir de seu nível mais baixo para o mais alto, chamados de bottom-up. Ao 
percorrer a hierarquia do sistema deve-se utilizar tais métodos.
A Figura 1 mostra um exemplo de hierarquia de sistemas, em que o seu nível mais alto, 
chamado de “visão de mundo” pode ser decomposto em elementos menores, chamados de 
“domínio”. Os “domínios” podem ser sistemas ou conjuntos de sistemas e podem ser divididos 
em elementos. Os elementos, por sua vez, podem ser divididos em componentes técnicos (pro-
gramas, módulos, classes ou até mesmo comandos de linguagens de programação).
Universidade Metodista de São Paulo
50
Figura 1 - Hierarquia da Engenharia de Sistemas
Fonte: adaptado de Pressman (2006)
MODelAgeM DO SISteMA
A modelagem do sistema define os processos que servem às necessidades da visão con-
siderada. Cada nível da hierarquia deve ser representado pelo conjunto adequado de modelos. 
Ela representa o comportamento dos processos e os pressupostos nos quais o comportamento 
está baseado. Esses pressupostos podem conter alguns fatores restritivos, como por exemplo, os 
próprios pressupostos, simplificações, limitações, restrições e preferências. Os pressupostos po-
dem reduzir a quantidade dae possíveis variações do sistema. As simplificações permitem a cria-
ção dos modelos nos prazos adequados. As limitações ajudam a cercar o escopo do sistema. As 
restrições ajudam no direcionamento da criação dos modelos. Por fim, as preferências indicam as 
soluções de tecnologia, dados, funções e etc. que têm relação direta com a satisfação do cliente.
A definição explícita, tanto as entradas exógenas quanto as endógenas do modelo, também 
faz parte da modelagem. As entradas exógenas são aquelas entradas que ligam uma parte de 
51
www.metodista.br/ead
uma determinada visão a outras partes do mesmo nível ou de outros níveis. As entradas endó-
genas são aquelas que ligam componentes individuais de uma parte em uma determinada visão.
A modelagem do sistema também representa todas as ligações (inclusive saídas) que per-
mitirão ao engenheiro compreender melhor a visão.
PrOCeSSOS De SOftwAre
Os chamados processos de software são os conjuntos de atividades para especificar, pro-
jetar, implementar e testar sistemas de software.
Processo de software
Uma definição mais adequada a um processo de software pode ser dada por um conjunto 
estruturado de atividades necessárias para desenvolver um sistema de software.
Um processo de software contém as etapas de especificação, projeto, validação, etc. e pode 
ser caracterizado por um modelo de processo.
Um modelo de processo de software é uma representação abstrata de um processo. Ele 
apresenta uma descrição de um processo de uma perspectiva particular. Cada organização pode 
definir e adotar o seu próprio modelo de processo, porém, a maioria das organizações adota um 
modelo genérico e desenvolve adaptações desse modelo para ajustá-lo à sua própria cultura.
MODelOS genérICOS De PrOCeSSO De SOftwAre
Os modelos genéricos de processo de software foram desenvolvidos para organizar as ativi-
dades de desenvolvimento de software. Existem diversos modelos genéricos de processo de soft-
ware, por exemplo, o modelo em cascata, o modelo incremental, o desenvolvimento evolutivo, o 
modelo espiral, etc.
Modelo Cascata
O modelo cascata de desenvolvimento de software foi o primeiro modelo publicado e teve 
sua origem em processos mais gerais da engenharia de sistemas. O modelo cascata apresenta 
fases separadas encadeadas que representam os principais processos de desenvolvimento de 
software (Figura 2).
Figura 2 - Modelo cascata de desenvolvimento de software
Fonte: adaptado de Sommerville (2011)
Universidade Metodista de São Paulo
52
fases do modelo cascata
A primeira fase é a fase de análise e definição de requisitos, que tem por objetivo definir os 
serviços, as restrições e os objetivos do sistema detalhadamente para serem utilizados como uma 
especificação do sistema.
Em seguida, a fase de projeto de sistema e de software, que tem como objetivo definir a 
arquitetura do sistema ou do software.
A etapa de implementação e teste de unidade segue a de projeto e tem a finalidade de 
gerar os programas ou unidades dos programas assim como de realizar os testes iniciais nessas 
unidades.
A etapa de integração e testes do sistema é realizada após a fase de implementação e nela 
as unidades individuais de programas ou os programas são integrados e testados como um siste-
ma completo. Um dos objetivos dessa fase é garantir que os requisitos tenham sido atendidos e, 
após os testes, o sistema é liberado ao cliente ou usuário.
A fase de operação e manutenção é a última do processo e nela o sistema é instalado e 
colocado em operação. A manutenção descrita nessa fase envolve a correção de erros não encon-
trados anteriormente, o aprimoramento das unidades desenvolvidas e na ampliação das funcio-
nalidades à medida que novos requisitos são encontrados.
Problemas do modelo cascata
Uma desvantagem do modelo cascata em relação a outros modelos é a dificuldade de aco-
modar as mudanças no software após o processo estar em andamento. Isso é devido ao fato de 
o modelo ter as fases bem definidas e estanques, em que não é possível iniciar uma fase sem a 
anterior ter terminado. Isso faz com que esse modelo seja apropriado quando os requisitos são 
bem compreendidos.
DeSenVOlVIMentO eVOluCIOnÁrIO
O desenvolvimento evolucionário tem base no desenvolvimento de uma implementação 
inicial, que é mostrada ao cliente para que ele faça críticas e dê sugestões e, então, o resultado 
é refinado por meio de várias versões do sistema, que são criadas até que um sistema adequado 
seja obtido, como pode ser visto na Figura 3. Existem, basicamente, dois tipos de desenvolvim-
ento evolucionário, o desenvolvimento exploratório e a prototipação.
Figura 3 - Desenvolvimento evolucionário
Fonte: adaptado de Sommerville (2011)
53
www.metodista.br/ead
Desenvolvimento exploratório
Este processo possui o objetivo de trabalhar com clientes para explorar os requisitos e 
evoluir para o sistema final a partir de uma especificação inicial. Deve iniciar com requisitos bem 
compreendidos para as partes iniciais do sistema.
Prototipação
A prototipação possui o objetivo de entender os requisitos do sistema e, a partir disso, 
desenvolver uma melhor definição de requisitos do sistema. O protótipo deve se concentrar na 
experimentação dos requisitos mal compreendidos. O processo deve iniciar com requisitos mal 
compreendidos.
Problemas do Desenvolvimento Evolucionário
Um dos problemas do desenvolvimento evolucionário é a falta de visibilidade do processo, 
pois se as versões são desenvolvidas rapidamente, não é economicamente viável produzir os 
documentos correspondentes às várias versões.
Outra desvantagem é que os sistemas são mal estruturados devido às contínuas mudanças 
e cada nova mudança aumenta a dificuldade de introduzir outras mudanças.
DeSenVOlVIMentO bASeADO eM reuSO 
 Este processo é baseado no reuso sistemático de componentes em que os sistemas são 
integrados a partir de componentes existentes ou sistemas de prateleira.
As etapas do desenvolvimento baseado em reuso são: análise de componentes,