Anlise de Sistemas

ESCOLA

Anlise
de Sistemas

1
 Anlise de Sistemas
Sumrio
1 INTRODUO................................................................................................................................ 2
2 OS SISTEMAS................................................................................................................................. 2
2.1 Viso geral..................................................................................................................................................................... 2
2.2 Definio de Sistemas..................................................................................................................................................... 2
2.3 O que um sistema........................................................................................................................................................ 3
3 Sistemas Naturais................................................................................................................ 4
3.1 Sistemas feitos pelo Homem........................................................................................................................................... 4
3.2 Sistemas Automatizados................................................................................................................................................. 4
3.2.1 Tipos de Sistemas Automatizados................................................................................................................................ 4
4 Processo de desenvolvimento de Software....................................................... 5
4.1 Anlise de Sistemas......................................................................................................................................................... 5
4.2 A Equipe de Desenvolvimento........................................................................................................................................ 5
4.2.1 O Analista de Sistemas................................................................................................................................................. 5
5 Fases do Desenvolvimento de Sistemas de Informao............................... 7
5.1 Diagrama de Fluxo de Dados DFD.............................................................................................................................. 7
5.1.2 Elementos Bsicos do DFD......................................................................................................................................... 7
5.2 Exploso para um nvel de funo principal................................................................................................................ 10
5.3 Exploso das funes principais................................................................................................................................... 11
6 O Paradigma da Orientao a Objeto..................................................................... 12
6.1 Classes e Objetos.......................................................................................................................................................... 12
6.2 Modelagem de Sistemas .............................................................................................................................................. 12
7 A linguagem de Modelagem Unificada - UML.................................................... 13
7.1 Fases do Desenvolvimento de um Sistema em UML................................................................................................... 13
7.2 Vises de um sistema.................................................................................................................................................... 14
8. Diagramas da UML............................................................................................................... 14
8.1 Diagrama Use-Case (Caso de Uso)............................................................................................................................... 14
8.2 Diagrama de Classes..................................................................................................................................................... 16
8.3 Diagrama de SeqUncia................................................................................................................................................ 18
9 Modelagem de Dados........................................................................................................ 18
10 A MODELAGEM DE DADOS................................................................................................... 18
10.1 O Modelo conceitual de dados................................................................................................................................... 19
10.1.1 Componentes do modelo conceitual de dados........................................................................................................ 19
6 DIAGRAMA DE ENTIDADE-RELACIONAMENTO (DER)................................................. 21
Exemplo Prtico de Anlise............................................................................................ 23
Locao de Fitas................................................................................................................................................................. 23

1
 Escola Alcides Maya - Segundo Mdulo

1 INTRODUO
Este material foi desenvolvido para a rea (disciplina) de anlise e projeto de sistemas. Ele pressupe um conhecimento
razovel dos conceitos e da terminologia de computao. O material foi previsto como apoio ao aluno iniciante rea.
A primeira tarefa do iniciante adquirir uma percepo do processo bsico de analisar e projetar sistemas. Vrios livros
de texto abrangem o tradicional ciclo de vida do sistema, e muitos so bastante bons; infelizmente, poucos incorporam as
metodologias estruturadas. H muitos livros excelentes sobre as tcnicas estruturadas, mas pouco incorporam os princpios
bsicos da anlise e projeto, to essenciais ao iniciante. Este material introduz ao aluno as metodologias estruturadas dentro
do contexto do tradicional ciclo de vida de um sistema.
A anlise de sistemas uma profisso desafiadora e emocionante. Como qualquer outra profisso, a anlise de sistemas
exige dedicao e muito trabalho.

2 OS SISTEMAS

2.1 Viso geral

O fato de voc estar lendo este texto indica que j do seu conhecimento alguma coisa sobre computadores. Alguns
leitores sero programadores profissionais ou administradores procurando compreender melhor o processo de anlise e
projeto de sistemas. O analista de sistemas experiente poder estar interessado em uma viso geral, concreta, de algumas das
novas tcnicas utilizadas nesta rea. Todos tm algo em comum: sabem o que um programa. Provavelmente j elaboraram
programas; e se no, certamente utilizaram um.
Os programadores e usurios tendem a se concentrar em um nico programa. O programador v um trabalho especfico
a ser realizado, enquanto o usurio v um problema especfico a ser resolvido. Tente obter uma viso um pouco mais ampla
desse programa. Faa-se algumas perguntas: Por que esse programa em particular foi feito? Os programas no surgem por
acaso. Obviamente, algum o desejava, seno ele no teria sido feito; mas, por que esse programa? E por que o programa foi
projetado do jeito que foi?
Obviamente, algum deve ter planejado no s o programa, mas todo o ambiente em que ele se situa. Estamos lidando
com algo muito mais amplo do que um programa. Estamos lidando com um sistema.
Este captulo comea definido o termo sistema. Depois, consideramos o processo de anlise e projeto de sistemas,
enfatizando o trabalho executado pelo analista. Utiliza-se um exemplo de engenharia para ilustrar a necessidade metdica
para projetar um sistema grande e complexo. Para o analista, a abordagem estruturada da anlise e projeto de sistemas
fornece essa metodologia. A chave para esse tipo de anlise e projeto estruturado o ciclo de vida do sistema, de modo que
descrevemos sucintamente como esta abordagem orienta o analista atravs das etapas deste ciclo.

2.2 Definio de Sistemas

Conceito de Sistemas
Define-se sistema como um conjunto de elementos interrelacionados que possuem caractersticas comuns e que podem
ser entendidos como um todo.
Os sistemas so divididos em duas categorias: Naturais e feitos pelo homem.

2
 Anlise de Sistemas
2.3 O que um sistema

Quantas vezes j nos referimos ou ouvimos a palavra sistema?

O sistema telefnico ficou mudo!
O sistema de coleta de lixo est perfeito.
Chefe, cheguei atrasado porque o sistema de trnsito desta cidade est uma porcaria
Em qualquer um dos casos podemos observar que a palavra sistema est sempre acompanhada de outra que a qualifica.
Desta forma, temos o objetivo declarado de um sistema, ou seja, a razo de sua existncia. Por exemplo, sistema telefnico,
sistema de coleta de lixo, sistema de trnsito, sistema circulatrio, sistema educacional, sistema poltico, sistema mdico,
sistema nervoso, sistema digestivo, etc.
Todo e qualquer sistema est inserido em um meio ambiente que o contm, ou seja, tudo o que externo a um sistema
chamado de seu meio ambiente.
Em qualquer sistema pode-se encontrar elementos caractersticos vinculados ao seu fim. No caso do sistema de trnsito,
temos veculos, motoristas, pedestres, ruas, guardas, placas, semforos, etc. Igualmente, pode-se verificar isto em um sistema
de controle do acervo de uma biblioteca, onde tem-se: os ttulos das obras, os exemplares, os usurios, a localizao de cada
exemplar, etc.
Observe que estes elementos interagem entre si. Eles se completam e permitem ao sistema atingir seu objetivo.
Podem ser encontradas vrias definies para sistema, as quais muitas vezes so extremamente amplas, bastante
abrangentes. Nosso trabalho iniciar considerando um sistema um conjunto de entidades relacionadas que interagem entre
si, buscando atingir um objetivo declarado e outros correlatos.
Os elementos aos quais nos referimos so as caractersticas do sistema em questo. Esses elementos sempre vo entrar
com certas caractersticas e, quando saem, possuem novas caractersticas.
Exemplo, no Sistema Educacional, encontramos como elementos os estudantes, os professores, os livros, a administrao
(funcionrios) e equipamentos.
Os elementos de um sistema esto relacionados e interagindo entre si com vistas ao objetivo declarado do sistema.
Exemplo, professores, alunos, livros, direo, enfim, todos os elementos do sistema educacional buscam atingir juntos o
objetivo educacional.
Observe que, dentro de um sistema educacional, certamente se encontrar um sistema de avaliao. Temos ento um
sistema dentro de outro. Quando isto ocorre, tem-se um subsistema. Portanto, o sistema de avaliao, pelo fato de estar
inserido no sistema educacional, um subsistema deste.
Obs.: Subsistemas tambm so considerados elementos do sistema onde encontram-se.

3
 Escola Alcides Maya - Segundo Mdulo

3 Sistemas Naturais
A maioria dos sistemas no feitos pelo homem, e sim encontrados na natureza e com propsito prprio. So
basicamente:
Sistemas fsicos: sistemas estrelares, geolgicos, etc.
Sistemas vivos: sistema reprodutor, ingestor, etc.

3.1 Sistemas feitos pelo Homem

Alguns so construdos, organizados e mantidos por seres humanos. Entre eles podemos considerar:
Sistemas sociais, organizao de leis, etc.
Sistemas de transporte: redes rodovirias, linhas areas, etc.
Sistemas de comunicao: telefone, telex, etc.
Sistemas de manufatura: fbricas, linhas de montagem, etc.
Sistemas financeiros: contabilidade, controle de estoques, etc.

3.2 Sistemas Automatizados

Hoje em dia, muitos desses sistemas no funcionariam sem computadores, mesmo que eles j existiam muito antes
do computador. Existem outros que utilizam o computador como componente, mas possui outros componentes no-
computadorizados ou manuais. Os sistemas feitos pelo homem, que interagem com ou so controlados por um ou mais
computadores so denominados sistemas automatizados.
Embora haja muitos tipos diferentes de sistemas automatizados, todos tem componentes em comum:
Hardware UCP, Perifricos, Memria, etc.
Software Sistemas Operacionais, Programas de Sistemas, Banco de Dados,
Programas de Controle de Telecomunicao, etc.
Pessoas operadores do sistema, que fornecem as entradas e utilizam as sadas.
Dados informaes que o sistema conserva por um perodo de tempo.

3.2.1 Tipos de Sistemas Automatizados

a) Sistemas on-line
Usurios interagem com o computador (fornece e recebe dados) por terminais.
b) Sistemas de tempo real

4
 Anlise de Sistemas
Variaes dos sistemas on-line. Controlam um ambiente pelo recebimento de dados, seu processamento e apresentao
dos resultados com rapidez suficiente para afetar o ambiente naquele momento. Alm da velocidade, este sistema interage
tanto com pessoas quanto com o ambiente.
c) Sistemas de apoio deciso
So sistemas tipicamente passivos no sentido de que no funcionam de uma forma regular, em vez disso, so utilizados
quando isso se faz necessrio. So utilizados pelos diretores para avaliar a misso da empresa, fornecendo informaes mais
amplas e gerais sobre clientes, comportamento dos competidores, etc.
d) Sistemas baseados no conhecimento
Tambm conhecidos como sistemas especialistas, so construdos habitualmente para terem a capacidade de explicar as
linhas de raciocnio que conduzem a suas decises.
Alguns podem at mesmo explicar porque rejeitaram certas linhas de raciocnio e escolheram outras. Neste tipo de
sistema se armazena dados e regras. Ex.: Sistemas de aprovao de crditos bancrios a deciso do gerente do banco.
e) Sistemas Artificiais
Normalmente so chamados de Sistemas de Informao, justamente porque seu maior objetivo fornecer, controlar,
prover, pesquisar, analisar informaes.
Estes sistemas so criados dentro ou para organizaes sociais (empresas), considerando dois aspectos: os componentes
da empresa e o nvel de deciso da empresa.
a) Componentes da empresa: correspondem aos diversos setores que executam as diferentes funes necessrias ao seu
funcionamento ( RH, Vendas,Marketing).
b) Nveis de Deciso: obedecem a hierarquia existente na empresa e so conhecidos como: nvel estratgico, ttico e
operacional.

4 Processo de desenvolvimento de Software

4.1 Anlise de Sistemas

A tarefa de construir sistemas de informao uma das mais complexas e, em ltima anlise, um processo de soluo
de problemas.
A Anlise de Sistemas consiste nos mtodos e tcnicas de investigao e especificao da soluo de problemas, a partir
dos requisitos levantados, para criao e implementao de software em algum meio que o suporte.

4.2 A Equipe de Desenvolvimento

A equipe de desenvolvimento o conjunto de pessoas responsveis por construir o software. Dela fazem parte pessoas com
diferentes habilidades. Em sistemas de informaes tradicionais teremos gerentes de desenvolvimento, analistas, projetistas,
programadores, administradores de banco de dados, etc... Em sistemas mais modernos, como sistemas multimdia e websites,
podemos ainda ter profisses novas como artistas e professores.
importante verificar que as pessoas em uma equipe de desenvolvimento se comunicam de alguma forma. Seguindo a
regra de quanto maior o projeto, maior o nmero de pessoas, muito maior o nmero de formas em que essas pessoas podem
se comunicar.

4.2.1 O Analista de Sistemas

Os usurios ou pretensos usurios de computador tem algo em comum: os problemas.
Surge ento o profissional Analista de Sistemas, que ser o elo entre os usurios e o computador.
O analista de sistemas deve ser capaz de compreender as disciplinas de engenharia de software e as das atividades
da organizao. A relao existente entre essas duas reas e o nvel corrente de tecnologia determina a interao entre o
exeqvel e o desejvel.

Uma pessoa que atua como analista de sistemas um bom facilitador e possui habilidades de comunicao acima da
mdia. fundamental que os profissionais que desempenham este papel tenham conhecimento dos domnios do negcio e
da tecnologia.

5
 Escola Alcides Maya - Segundo Mdulo

Analista
Usurio Programador

A maior desvantagem em estabelecer uma lista de requisitos como esta que jamais se encontrar algum que venha
a possuir todos eles. Mesmo assim, no se pode esquecer este panorama, e deve-se tentar conciliar o mximo possvel a
presena destes requisitos na sua formao profissional.
Para uma boa atuao como Analista de Sistemas, conveniente observar algumas diretrizes de conduta, que serviro
para facilitar seu trabalho:
Procure ser aceito profissionalmente, do nvel mais alto ao nvel mais baixo da empresa.
Tente entender o que o usurio quer dizer e no o que voc pensa que ele quer dizer.
Escute muito primeiro, fale muito pouco depois!
Esteja sempre familiarizado com os ltimos progressos da tecnologia de informao e compreenda como aplic-los
na sua empresa.
Seja capaz de explicar conceitos complexos em termos simplificados.
No se esconda em jarges da Informtica; fale a linguagem da empresa.
Conhea a rea de negcios para a qual desenvolver sistemas, passando boa parte do seu tempo com o usurio.
Sugira solues inovadoras aos requisitos de informao e desenvolva com clareza, analisando sempre a relao
custo/benefcio e utilizando alternativas viveis.

6
 Anlise de Sistemas
5 Fases do Desenvolvimento de Sistemas de
Informao
O processo de desenvolvimento de sistemas de informao, tambm chamado de ciclo de vida, abrange todas as atividades
necessrias para definir, desenvolver, testar, operar e manter um sistema. Veja abaixo as fases do ciclo de vida de um Sistema
de Informao:
a) Anlise
A proposta desta fase definir e modelar o que o sistema ir fazer, independente da tecnologia que ser utilizada. Em
acrscimo ao modelo do sistema descrevendo os requisitos do usurio, um mais cuidadoso e detalhado conjunto de oramento
e clculo de custo benefcio preparado, geralmente, ao final da fase de anlise.
b) Projeto
Nesta fase, o objetivo de definir a melhor tecnologia, levando-se em conta todas as caractersticas do sistema (conforme
obtido na fase de anlise). A atividade de projeto ocupa-se de partes da especificao aos processadores apropriados e para
tarefas apropriadas no interior de cada processador. Em cada tarefa, a atividade de projeto ocupa-se com o desenvolvimento
de uma hierarquia apropriada de mdulos de programa e interface entre estes mdulos para implementar a especificao
criada na atividade de anlise. Alm disso, a fase de projeto ocupa-se com a transformao de modelos de dados de entidade
- relacionamento em um projeto de banco de dados.
c) Implementao
Codificar, integrar mdulos e criar banco de dados so os objetivos desta fase. Esta , tipicamente, uma atividade em que
o analista de sistemas no est envolvido, embora muitas vezes todas as fases sejam realizadas pela mesma pessoa.
d) Implantao
O objetivo desta fase implantar o sistema nas instalaes do usurio. Nesta etapa so prontificados os manuais, os
arquivos so carregados, o sistema instalado e os usurios so devidamente treinados.
e) Manuteno
Todo trabalho efetuado aps a fase de implantao. A manuteno pode ser de dois tipos: corretiva ou evolutiva. Ela ser
corretiva, a partir do momento em que o propsito a correo de erros encontrados no sistema. Ela ser evolutiva, a partir
do momento em que o propsito incluir novas funcionalidades no sistema, mesmo depois de implantado.

5.1 Diagrama de Fluxo de Dados DFD

Representa o modelo funcional do sistema. utilizado para a representao lgica de processos. O objetivo descrever
graficamente, o que acontece, sem se preocupar em como e quando tais coisas acontecem. Trata-se de uma ferramenta para
o modelo funcional do sistema.
Pode ser empregado para a comunicao com pessoal tcnico ou no tcnico, j que a representao grfica de fcil
entendimento.
Em resumo o DFD deve explicitar
Funes do sistema (processos/servios)
Interaes entre as funes do sistema
Transformaes que o sistema deve realizar
As fontes de informao
O destino dos resultados.
Dados mantidos pelo sistema (dados em repouso)

5.1.2 Elementos Bsicos do DFD

a) Entidade Externa: pessoa, grupo de pessoas ou subsistema /sistema fora do sistema em estudo que recebem dados do
sistema e/ou enviam dados para o sistema. As entidades externas funcionam sempre como origem/destino de dados.

b) Fluxo de dados: dados que fluem entre processos, entre processos e arquivos de dados ou ainda entre processos e
7
 Escola Alcides Maya - Segundo Mdulo
entidades externas, sem nenhuma especificao temporal (por exemplo ocorrncia de processos simultneos, ou todas as
semanas).

c) Depsito de dados: meio de armazenamento de dados para posterior acesso e/ou atualizao por um processo.

Dn
n

d) Processo: recebe dados de entrada e transforma estes dados num fluxo de sada.

nr nr

Como exemplo, podemos ter:

Para representar um fluxo de acesso memria (depsito de dados), comum usar:

a) Consultar (Ler) b) Incluir (Gravar)

8
 Anlise de Sistemas
c) Atualizar d) Excluir

Observe que o processo no necessariamente um programa. Um nico processo poder representar uma srie de
programas, um nico programa, ou um mdulo dentro de um programa; ele poder at representar um processo manual, tal
como a perfurao ou a conferncia visual dos dados. Note, tambm, que o depsito de dados no o mesmo que um arquivo.
Aquele poder representar o arquivo, uma parcela do arquivo, elementos em uma base de dados, ou mesmo uma parcela de
um registro. O depsito de dados poder residir em disco, fita magntica, memria principal, carto perfurado, ou qualquer
outro meio (inclusive o crebro humano).
Qual a diferena entre o depsito de dados e o fluxo de dados? O fluxo de dados representa os dados em movimento; o
depsito de dados representa dados em repouso. Em outras palavras, so meramente dois estados da mesma coisa. Voltaremos
a esta idia posteriormente.
Em nome da facilidade de leitura do DFD, conveniente usar sempre a mesma notao para cada um de seus
componentes.
Muitas vezes, ao desenhar um DFD complexo, nos deparamos com a possibilidade de cruzamento de linhas que
representam os fluxos de dados, o que dificulta a inteligibilidade do diagrama. Para resolver este problema, a sada costuma
ser a repetio, em outro ponto do DFD, de algumas das figuras que representam os seus componentes, da seguinte forma:
a) Para duplicao de entidades externas, costuma-se acrescentar ao smbolo uma linha diagonal para cada repetio
utilizada, como a seguir:

b) Para duplicao dos depsitos de dados, costuma-se acrescentar ao smbolo uma linha paralela para cada repetio
utilizada, como a seguir:

c) Nos casos em que for inevitvel o cruzamento de linhas, uma soluo que pode ser usada o de desenhar uma Ponte
(by pass), como a seguir :

d) No faz sentido duplicar processos. Isto geraria confuso quanto ao entendimento do diagrama.
Para ilustrar as situaes acima descritas, observar o DFD a seguir:

9
 Escola Alcides Maya - Segundo Mdulo
Como os fluxogramas lgicos tradicionais, a direo do fluxo de cima para baixo e da esquerda para a direita. Um bom
DFD tende a seguir uma conveno semelhante, com os dados deslocando-se de sua origem (na parte superior esquerda) at
seu destino (na parte inferior direita), mas as regras so muito menos rgidas. Por exemplo, os dados s vezes fluem de volta
at sua fonte. Uma maneira de indicar isso desenhar uma longa linha de fluxo de um lado do diagrama para o outro. Como
alternativa, o smbolo para a origem do dado simplesmente poder ser repetido em outras palavras, o mesmo smbolo
representando a mesma fonte de dados pode aparecer mais de uma vez no DFD.

cliente gerncia

Dados Cliente
Lista de Cliente

1
cadastrar Dados Cliente
cliente Vlido
D1 Clientes 2
gerar
Dados Cliente Relatrio
n
Vlido cliente

5.2 Exploso para um nvel de funo principal

A figura acima representa talvez a viso mais ampla possvel do sistema. Contudo, exceto pelo destaque de origens
e destinos de dados, este DFD no particularmente til. O passo seguinte explodir o processo dentro de suas partes
funcionais. Para fazer isso, dois processos podem ser identificados: gerar relatrio e processar transao. Esses dois
processos representam as funes bsicas que tero de ser realizadas pelo sistema; elas iro substituir sistema de reposio.
A exploso de um DFD significa a substituio de um processo de alto nvel por seus componentes de nvel inferior.Observe
abaixo:

10
 Anlise de Sistemas

Observe que dois depsitos de dados foram acrescentados ao novo DFD. Processar transaes precisa de dados do
estoque; assim temos o depsito de dados conhecido por estoque. Voc se lembra da diferena do tempo entre o processamento
das transaes de estoque e a gerao do relatrio de reposio? Por causa desta diferena, informaes de reposio tero de
ser armazenadas; por isso, temos o depsito de dados reposio.
A Figura acima ilustra diversas convenes utilizadas para desenhar o DFD. Os processos so numerados para facilidade
de consulta. Os depsitos de dados so rotulados com D seguido de um nmero; mais uma vez, esses rtulos so apenas
para fins de consulta. Os nomes dos depsitos, origens e destinos de dados so todos escritos em letras maisculas, enquanto
os nomes dos processos e de fluxos de dados so, exceto a primeira letra, escritos em letras minsculas. Estas convenes
ajudam a tornar o DFD mais fcil de ser seguido.
Os nomes dos vrios fluxos de dados so escritos dentro de seu diagrama. Como os processos, origens, destinos e
depsitos de dados, eles so derivados da descrio do problema. Considere um desses fluxos reposio. Reposio um
fluxo de dados ou um depsito de dados? primeira vista, distinguir entre depsitos e fluxos poder parecer confuso. No se
preocupe a respeito. O fluxo de dados so dados em movimento; o depsito de dados so dados em repouso (armazenados).
Que elementos so encontrados no depsito de dados? Apenas aqueles elementos que entraram no depsito de dados atravs
de um fluxo de dados. Em outras palavras, o depsito e o fluxo de dados so apenas duas verses diferentes da mesma
coisa.

5.3 Exploso das funes principais

Uma vez identificadas as funes principais e incorporadas ao DFD, o analista pode comear a explodir cada uma dessas
funes para um nvel inferior de detalhamento. Por exemplo, considere a funo processar transaes. Logicamente, poderia
ser razovel decompor este processo em trs passos: aceitar transao, atualizar estoque e processar reposio. Por que estes
trs passos? Pense a respeito do fluxo lgico dos dados atravs do sistema. Primeiro, a transao ter de ocorrer e ser aceita.
A seguir a transao pode ser processada. Finalmente, uma vez que a fase de processamento tenha determinado que uma
reposio necessria, os dados de reposio podem ser processados. Os trs passos tero de ocorrer na ordem prevista.
Eles so relativamente independentes, vinculados apenas por um fluxo de dados. Uma decomposio semelhante pode ser
imaginada para muitos processos de nvel funcional.

DFD com o processo processar transaes explodido para um nvel inferior.

11
 Escola Alcides Maya - Segundo Mdulo
Observe como os processos foram numerados no DFD explodido. Os processos 1.1, 1.2 e 1.3 so partes componentes do
que era o processo 1. Se o processo 2 fosse explodido, seus componentes seriam numerados 2.1, 2.2, e assim por diante.
Devemos explodir o segundo processo, gerar relatrio? No. relativamente fcil de visualizar o que o processo de gerao
de relatrio far. Embora voc possa imaginar diversos meios diferentes de gerar o relatrio utilizando uma classificao ou
outro mecanismo qualquer de seqenciamento, tais detalhes envolvem especificaes fsicas e no so apropriados no DFD.
Devemos explodir os processos apresentados na figura anterior para um nvel ainda mais baixo? Provavelmente no.
Por qu? Como saber quando j desceu ao nvel suficiente? Considere o processo 1.1, aceitar transao. Tente imaginar a
decomposio desse processo sem pensar como voc vai aceitar as transaes, ou de onde (fisicamente) essas transaes
viro. Quando voc atingir o ponto em que uma maior subdiviso o levar a pensar em como implementar o processo, ser
o suficiente.
Qual o detalhamento do Diagrama do Fluxo de Dados? O exemplo apresentado neste mdulo relativamente trivial; o
que aconteceria se o DFD contivesse dezenas de processos e depsitos de dados? Esse diagrama seria muito difcil de seguir,
prejudicando, assim, uma importante finalidade a comunicao.
Diversos estudos sugerem que as pessoas encontram dificuldade em seguir um DFD contendo mais de 7+/-2 processos.
Esses estudos sugerem uma estratgia. Comece com um diagrama de alto nvel. Exploda at o nvel funcional. Se a exploso
de todas as funes para o seu nvel seguinte de detalhamento fizer com que voc supere o limite de 9 processos, no exploda
o DFD. Ao invs disso, tome cada funo, uma de cada vez, e desenvolva um subdiagrama, apresentando apenas a exploso
de um nico processo. Repita este passo para cada processo. O DFD de nvel funcional pode ento ser utilizado para fornecer
uma viso global lgica do sistema como um todo. Se o usurio ou o gerente quiser saber o que acontece dentro de um
processo dado, o subdiagrama apropriado pode ser apresentado.

6 O Paradigma da Orientao a Objeto

Interessante ao desenvolvimento atual de sistemas de software o Paradigma da Orientao a objetos. Um paradigma
uma forma de abordar um problema. Considere a histria da maa caindo sobre a cabea de Isaac Newton. Em vez de pensar
que somente a maa estava caindo sobre a terra, Newton tambm considerou a hiptese de o prprio planeta tambm estar
caindo sobre a ma. Essa outra maneira de abordar o problema pode ser vista como um paradigma.
O paradigma da orientao a objetos visualiza um sistema de software como uma coleo de agentes interconectados
chamados objetos. Cada objeto responsvel por realizar tarefas especficas. atravs da interao entre objetos que uma
tarefa computacional realizada.
Pode-se concluir que a orientao a objetos, como tcnica para modelagem de sistemas, diminui a diferena semntica
entre a realidade sendo modelada e os modelos construdos.

6.1 Classes e Objetos

Focamos alguns princpios da orientao a objetos:
1. Qualquer coisa um objeto;
2. Objetos realizam tarefas atravs da requisio de servios a outros objetos;
3. Cada objeto pertence a uma determinada classe. Uma classe agrupa objetos similares;
4. A classe um repositrio para comportamento associado ao objeto;
5. Classes so organizadas em hierarquias.
Uma classe um modelo para objetos. Normalmente voc no usaria as classes diretamente em seu programa. Ao invs
disso, voc as usaria apenas para instanciar novos objetos.
Imagine uma classe como uma planta de uma cada: voc no pode morar na planta da casa, mas pode us-la para criar
quantas casas quiser.

6.2 Modelagem de Sistemas

Na dcada de 1990 surgiram vrias propostas de tcnicas para modelagem de sistemas segundo o paradigma orientado
a objetos. Percebeu-se a necessidade da existncia de uma linguagem que viesse a se tornar um padro para a modelagem
de sistemas, que fosse aceita e utilizada amplamente pela indstria e pelos ambientes acadmicos. E os esforos deram
surgimento na definio da UML ( Unified Modeling Language ) em 1996 como a melhor candidata para ser a linguagem
unificadora de notaes , diagramas e formas de representao existentes em diferentes tcnicas.

12
 Anlise de Sistemas
7 A linguagem de Modelagem Unificada - UML
A UML uma tentativa de padronizar a modelagem orientada a objetos de uma forma que qualquer sistema, seja qual
for o tipo, possa ser modelado corretamente, com consistncia, fcil de se comunicar com outras aplicaes, simples de ser
atualizado e compreensvel.
A UML uma linguagem visual para modelar sistemas orientados a objetos. Isso quer dizer que a UML uma linguagem
constituda de elementos grficos (visuais) utilizados na modelagem que permitem representar os conceitos do paradigma da
orientao a objetos. Atravs de elementos grficos definidos nesta linguagem pode-se construir diagramas que representam
diversas perspectivas de um sistema.

7.1 Fases do Desenvolvimento de um Sistema em UML

Existem cinco fases no desenvolvimento de sistemas de software: anlise de requisitos, anlise, design (projeto),
programao e testes. Estas cinco fases no devem ser executadas na ordem descrita acima, mas concomitantemente de
forma que problemas detectados numa certa fase modifiquem e melhorem as fases desenvolvidas anteriormente de forma que
o resultado global gere um produto de alta qualidade e performance. A seguir falaremos sobre cada fase do desenvolvimento
de um sistema em UML:
a) Anlise de Requisitos
Esta fase captura as intenes e necessidades dos usurios do sistema a ser desenvolvido atravs do uso de funes
chamadas use-cases. Atravs do desenvolvimento de use-case, as entidades externas ao sistema (em UML chamados
de atores externos) que interagem e possuem interesse no sistema so modelados entre as funes que eles requerem,
funes estas chamadas de use-cases. Os atores externos e os use-cases so modelados com relacionamentos que
possuem comunicao associativa entre eles ou so desmembrados em hierarquia. Cada use-case modelado descrito
atravs de um texto, e este especifica os requerimentos do ator externo que utilizar este use-case. O diagrama de use-
cases mostrar o que os atores externos, ou seja, os usurios do futuro sistema devero esperar do aplicativo, conhecendo
toda sua funcionalidade sem importar como esta ser implementada. A anlise de requisitos tambm pode ser desenvolvida
baseada em processos de negcios, e no apenas para sistemas de software.
b) Anlise
A fase de anlise est preocupada com as primeiras abstraes (classes e objetos) e mecanismos que estaro presentes no
domnio do problema. As classes so modeladas e ligadas atravs de relacionamentos com outras classes, e so descritas no
Diagrama de Classe. As colaboraes entre classes tambm so mostradas neste diagrama para desenvolver os use-cases
modelados anteriormente, estas colaboraes so criadas atravs de modelos dinmicos em UML. Na anlise, s sero
modeladas classes que pertenam ao domnio principal do problema do software, ou seja, classes tcnicas que gerenciem
banco de dados, interface, comunicao, concorrncia e outros no estaro presentes neste diagrama.
c) Design (Projeto)
Na fase de design, o resultado da anlise expandido em solues tcnicas. Novas classes sero adicionadas para prover
uma infra-estrutura tcnica: a interface do usurio e de perifricos, gerenciamento de banco de dados, comunicao com
outros sistemas, dentre outros. As classes do domnio do problema modeladas na fase de anlise so mescladas nessa nova
infra-estrutura tcnica tornando possvel alterar tanto o domnio do problema quanto a infra-estrutura. O design resulta no
detalhamento das especificaes para a fase de programao do sistema.
d) Programao
Na fase de programao, as classes provenientes do design so convertidas para o cdigo da linguagem orientada a
objetos escolhida (a utilizao de linguagens procedurais extremamente no recomendada). Dependendo da capacidade
da linguagem usada, essa converso pode ser uma tarefa fcil ou muito complicada. No momento da criao de modelos de
anlise e design em UML, melhor evitar traduzi-los mentalmente em cdigo. Nas fases anteriores, os modelos criados so
o significado do entendimento e da estrutura do sistema, ento, no momento da gerao do cdigo onde o analista conclua
antecipadamente sobre modificaes em seu contedo, seus modelos no estaro mais demonstrando o real perfil do sistema.
A programao uma fase separada e distinta onde os modelos criados so convertidos em cdigo.
e) Testes
Um sistema normalmente rodado em testes de unidade, integrao, e aceitao. Os testes de unidade so para classes
individuais ou grupos de classes e so geralmente testados pelo programador. Os testes de integrao so aplicados j usando
as classes e componentes integrados para se confirmar se as classes esto cooperando uma com as outras como especificado
nos modelos. Os testes de aceitao observam o sistema como uma caixa preta e verificam se o sistema est funcionando
como o especificado nos primeiros diagramas de use-cases.
O sistema ser testado pelo usurio final e verificar se os resultados mostrados esto realmente de acordo com as
intenes do usurio final.
13
 Escola Alcides Maya - Segundo Mdulo

7.2 Vises de um sistema

O desenvolvimento de um software complexo demanda que seu desenvolvedores tenham a possibilidade de examinar
e estudar esse sistema a partir de diversas perspectivas. Estas perspectivas so definidas como vises. Cada viso enfatiza
aspectos diferentes do sistema.
Viso de Casos de Uso: descreve o sistema de um ponto de vista externo como um conjunto de interaes entre o
sistema e os agentes externos ao sistema.
Viso de Projeto: enfatiza as caractersticas do sistema que do suporte, tanto estrutural quanto comportamental, s
funcionalidades externamente visveis do sistema.
Viso de Implementao: abrange o gerenciamento de verses do sistema, construdas atravs do agrupamento de
mdulos ( componentes) e subsistemas.
Viso de Implantao: corresponde distribuio fsica do sistema em seus subsistemas e conexo entre essas
partes.
Viso de Processo: enfatiza as caractersticas de concorrncia (paralelismo), sincronizao e desempenho do
sistema.

8. Diagramas da UML
O objetivo dos diagramas apresentar mltiplas vises do sistema sendo que este conjunto de mltiplas vises chamado
de modelo. Podemos dizer que um modelo UML pode ser visto como um conjunto de diagramas que podem ser examinados
e modificados a fim de compreender e desenvolver um sistema de software.
Um modelo UML descreve o que o sistema far, mas no diz nada como implementar o sistema.Um diagrama prov uma
parcial representao do sistema. Ele ajuda a compreender a arquitetura do sistema em desenvolvimento.
Vejamos s seguir os diagramas da UML
Estticos:
Diagramas de Use Cases
Diagramas de Classes
Diagramas de Pacotes
Dinmicos:
Diagramas de Interao
Diagramas de Sequncia
Diagramas de Colaborao
Diagramas de Estado (Statechart)
Diagramas de Atividade

8.1 Diagrama Use-Case (Caso de Uso)

O Diagrama de Use Case tem o objetivo de auxiliar a comunicao entre os analistas e o cliente. Ele descreve um cenrio
que mostra as funcionalidades do sistema do ponto de vista do usurio, ou seja, uma tcnica usada para descrever e definir
os requisitos funcionais do sistema.
O cliente deve ver no diagrama de Use Cases as principais funcionalidades de seu sistema.
O diagrama de Use Cases representado por:
atores;
use cases;
relacionamentos entre estes elementos.
Estes relacionamentos podem ser:
> associaes entre atores e use cases;
> generalizaes entre os atores;
> generalizaes, extends e includes entre os use cases.

14
 Anlise de Sistemas
Atores
Um ator representado por um boneco e um rtulo com o nome do ator. Um ator um usurio do sistema, que pode ser
um usurio humano ou um outro sistema computacional.

Ator

Use case
Um use case representado por uma elipse e um rtulo com o nome do use case. Um use case uma funcionalidade do
sistema.

Relacionamentos
Ajudam a descrever os use cases.
1) Entre um ator e um use case:
a. Associao

Define uma
funcionalidade do
sistema do ponto de
vista do usurio.

Use Case
Ator

2) Entre atores:
a. Generalizao

15
 Escola Alcides Maya - Segundo Mdulo
3) Entre use cases:
a. Include
Um relacionamento include de um use case A para um use case B indica que B essencial para o comportamento de A.
b. Extend
Um relacionamento extend de um use case A para um use case B indica que o use case A pode ser acrescentado para
descrever o comportamento de B (no essencial). A extenso inserida no ponto de extenso do use case B.
Ponto de extenso em um use case uma indicao de que outros use cases podero ser adicionados a ele. Quando o use
case for invocado, ele verificar se suas extenses devem ou no serem invocadas.
c. Generalizao ou Especializao (_um)
Use case B _um use case A (A uma generalizao de B, ou B uma especializao de A).Um relacionamento entre um
use case genrico para um mais especfico, que herda todas as caractersticas de seu pai.

Sistema
Limites do sistema: representado por um retngulo envolvendo os use cases que compem o sistema.
Nome do sistema: Localizado dentro do retngulo.

8.2 Diagrama de Classes

O diagrama de classes demonstra a estrutura esttica das classes de um sistema onde estas representam as coisas que
so gerenciadas pela aplicao modelada. Classes podem se relacionar com outras atravs de diversas maneiras: associao
(conectadas entre si), dependncia (uma classe depende ou usa outra classe), especializao (uma classe uma especializao
de outra classe), ou em pacotes (classes agrupadas por caractersticas similares).

16
 Anlise de Sistemas

Nome classe Cliente

+Atributos +nome: int
-idade: string
+mtodos()
+criar()
+apagar()

Notao:
a) Nome da classe: Um identificador para a classe, que permite referenci-la posteriormente -- por exemplo, no momento
da criao de um objeto.
b) Atributos: O conjunto de propriedades da classe. Para cada propriedade, especifica-se:
a. Nome: um identificador para o atributo.
b. Tipo: o tipo do atributo (inteiro, real, carter, outra classe, etc.)
c. valor_default: opcionalmente, pode-se especificar um valor inicial para o atributo.
d. Visibilidade: opcionalmente, pode-se especificar o quanto acessvel um atributo de um objeto a partir de outros
objetos. Valores possveis so:
- (privativo), nenhuma visibilidade externa;
+ (pblico), visibilidade externa total;
# (protegido), visibilidade externa limitada.

c) Mtodos ( Operaes) : tambm so exibidos com pelo menos seu nome, e podem tambm mostrar seus parmetros
e valores de retorno. Operaes podem, como os Atributos, mostras sua visibilidade:
+ indica operaes pblicas
# indica operaes protegidas
- indica operaes privadas

17
 Escola Alcides Maya - Segundo Mdulo

Conta
-agencia: int
-contacorrente: char
+depositar()
+saldo()

Cliente
-CPF: int
ContaPoupanca -nome: string
-telefone: char
-DiaDeposito: int
+MostrarCPF()
+VerLucro() +VerSaldo()

8.3 Diagrama de SeqUncia

Diagramas de Seqncia mostram a troca de mensagens (isto chamada de mtodo) entre diversos Objetos, numa situao
especfica e delimitada no tempo. Objetos so instncias de classes. Diagramas de Seqncia colocam nfase especial na
ordem e nos momentos nos quais mensagens para os objetos so enviadas.

9 Modelagem de Dados
O modelo de entidade-relacionamento (MER) baseado na percepo do mundo real que consiste em um conjunto de
objetos bsicos chamados entidades e nos relacionamentos entre estes objetos.

10 A MODELAGEM DE DADOS
Trata-se de parte do trabalho do analista de sistemas, cujo propsito buscar especificar, a partir dos fatos essenciais que
estejam associados ao domnio de conhecimento analisado, a perspectiva dos dados, permitindo organiz-los em estruturas
bem definidas, estabelecer as regras de dependncia e restries entre eles, produzindo um modelo expresso por uma
representao, ao mesmo tempo, descritiva e diagramtica.

18
 Anlise de Sistemas
Na literatura de Informtica, de um modo geral, os termos dado e informao costumam ser utilizados como sinnimos,
porm, trata-se de coisas distintas, cada qual com seu conceito.

Dado = Atributo + Valor

Os dados podem ser vistos como uma coleo de smbolos organizados intencionalmente para representar uma parte da
realidade de que estivemos tratando.
Podemos definir informao como sendo conhecimento novo. Por ser conhecimento, a informao existe apenas na
mente das pessoas, ou seja, a informao s pode ser assim chamada se representar acrscimo de conhecimento para algum.
Os dados podem ser usados para representar informaes, aumentando, desta forma, o conhecimento de algum a respeito
de algum assunto ou situao.
A modelagem de dados, comea no momento em que um analista de sistemas define algum depsito de dados
no DFD particionado por evento. Tal fato significa que o analista, ao examinar o domnio de seu problema no mundo real,
interpretou que, para aquele determinado evento, haveria a necessidade de se armazenar alguma informao sobre algo. Esta
interpretao do analista chamada de viso a nvel conceitual, cuja inteno espelhar a realidade. Deste fato decorre um
processo a nvel de dados conhecido por abstrao de dados, ou seja, se tenho um usurio no sistema, devo verificar se
necessrio armazenar dados sobre ele. Em caso afirmativo, pergunto quais dados sobre este usurio devo armazenar? A
resposta : certamente aqueles que so relevantes para o seu sistema.

Esta idia conceitual, ainda que preliminar, sobre os dados a serem armazenados, segundo uma viso interpretada do
mundo real, a chamada abstrao de dados.

10.1 O Modelo conceitual de dados

O valor de um modelo conceitual de dados tanto maior quanto sua aderncia realidade do mundo que ele se prope
a representar. Antes de pensarmos em implementao, necessrio que tenhamos uma descrio da realidade to fielmente
retratada quanto possvel. Uma tcnica de modelagem de dados deve procurar capturar os conceitos do ambiente a ser
modelado, bem como expressar-se em uma linguagem (notao) que facilite a percepo do usurio a respeito da organizao
da realidade que o cerca. Alm disso, o mtodo proposto deve permitir tambm que se possa estabelecer agrupamentos das
classes de elementos do mundo real sob diversas formas de agregao.
Podemos, ento, estabelecer que o mtodo de modelagem conceitual de dados satisfaa, entre outros, aos seguintes
requisitos:
a) Expandir a habilidade do analista no reconhecimento dos requisitos de informao;
b) Capacidade de capturar ao mximo os conceitos do mundo real durante o prprio processo de modelagem;
c) Facilidade de entendimento, atravs de uma representao pragmtica, que possa, inclusive, ser entendida por usurios
no-tcnicos de Informtica.

10.1.1 Componentes do modelo conceitual de dados

Os quatro componentes primitivos do modelo, que representam o mundo real, so: entidades, relacionamentos, atributos
e domnios.
Entidade
A denominao usada para referir-se ao primeiro conceito, embora seja um tanto esquisita, j se consolidou pelo seu
amplo uso na rea de modelagem de dados e de projeto de banco de dados. Segundo o autor J. Ullman, uma entidade algo
que existe e que possui caractersticas que a tornam distingveis.
No dicionrio de Aurlio Buarque de Holanda, encontramos ainda as seguintes definies, que podem nos ajudar a
entender do que estamos falando:

Entidade:
1. aquilo que constitui a essncia de uma coisa, existncia, individualidade, ente, ser;
2. tudo quanto existe ou pode existir.

Assim, uma entidade alguma coisa que desempenha um papel especfico no sistema que est sendo modelado. algo
sobre o qual desejamos guardar informaes. A existncia e a identificao de uma entidade dependem inteiramente do
19
 Escola Alcides Maya - Segundo Mdulo
contexto em que ela estiver inserida. Por exemplo, em um sistema acadmico, uma pessoa (que seria uma entidade) pode ter o
papel de aluno ou professor. Esta mesma pessoa, em um sistema de arrecadao de atributos, ser, digamos, um contribuinte,
enquanto em um sistema de competies esportivas, ela poder ser um atleta. Como vemos, nenhuma entidade pode ser
identificada independentemente de um universo de interesse.
Uma entidade pode ser:
a) um objeto real, como um livro, uma mquina, um lugar, um avio;
b) uma pessoa, como um empregado, um contribuinte, um aluno, um cidado;
c) um conceito abstrato, como um curso, uma cor, uma disciplina;
d) um acontecimento, isto , uma situao em que algo est ocorrendo ou est planejado, como o fornecimento de uma
encomenda, a inscrio de um aluno em um curso, uma reunio, um casamento, etc.
Um grupo de entidades possuindo os mesmos atributos forma um conjunto de entidades. Um conjunto de entidades
deve ser encarada como uma reunio (famlia, conjunto) de entidades (elementos) com caractersticas comuns. Assim, a
classe de entidades pessoa teria as entidades Joo, Virgnia, Jos, Teresa, etc.
Exemplos de entidades:
o conjunto de todos os empregados;
o conjunto de todos os fornecedores;
o conjunto de todos os departamentos;
o conjunto de todos os alunos.

Relacionamento
Dentro do contexto de um sistema, os conjuntos de entidades relacionam-se entre si. Definiremos relacionamento
como uma associao entre duas entidades. Por exemplo, o relacionamento que expressa todas as encomendas feitas a um
fornecedor pode ser expresso:
Fornecedor fornece encomenda ou
Encomenda fornecida por fornecedor,
Onde Fornecedor e Encomenda so conjuntos de entidades. Por outro lado, fornece e fornecida por representam o
relacionamento entre as duas entidades.

Atributo
Conforme j dissemos, nosso interesse em identificar entidades est no fato de desejarmos armazenar dados a seu respeito.
Tais dados representam caractersticas destas entidades. Assim, n-de-matrcula, nome, data-de-nascimento e endereo
podem ser, por exemplo, caractersticas da entidade empregado. As caractersticas ou propriedades das entidades recebem a
denominao de atributo. Atributo pode ser entendido como sendo aquilo que o intelecto percebe a respeito da entidade como
constituindo a essncia dela, isto , a determinao de uma propriedade essencial da entidade. Desta forma, cada empregado
uma entidade que possui os atributos mencionados. Todas as entidades de um determinado conjunto possuem os mesmos
atributos.
A cada atributo de uma entidade associado um domnio de valores. Estes domnios podem ser um conjunto de nmeros
inteiros, nmeros reais, cadeia de caracteres ou qualquer outro tipo de valores. Por exemplo, as entidades do conjunto de
entidades fornecedor podem ter atributos como:
razo social (uma cadeia de caracteres);
capital social (um nmero real);
data de fundao da empresa (uma data), etc.
O domnio o conjunto de valores vlidos para um determinado atributo. O atributo nome-do-empregado tem como
domnio (Joo, Jos, Maria, ...). Isto , Joo, Jos, Maria, etc. so valores que podem ser atribudos ao nome do empregado.
O atributo cor-do-carro tem como domnio (azul, verde, amarelo, ...), ou seja, azul, verde, amarelo, etc. so valores possveis
para a cor do carro.

Ele foi desenvolvido para facilitar o projeto de banco de dados, permitindo a especificao de um esquema de negcio,
onde tal esquema representa a estrutura lgica geral do banco de dados.

20
 Anlise de Sistemas
6 DIAGRAMA DE ENTIDADE-RELACIONAMENTO (DER)
Integrantes do Modelo:
Entidades: Conjuntos de coisas que possuem caractersticas prprias.
Atributos: Representam as caractersticas que qualificam uma Entidade.
Relacionamentos: Condies que permitem o estabelecimento do nvel de associao entre Entidades.
Entidades:
O conceito fundamental da abordagem entidade-relacionamento (E-R) o conceito de entidade.
Conjunto de objetos da realidade modelada sobre os quais deseja-se colecionar dados no banco de dados
Pode ser concreta (pessoa, disco,...) ou abstrata (curso, conceito, circulao, ...)
Uma entidade representa um conjunto de objetos que se deseja guardar dados
Exemplo:
Sistema bancrio as entidades podem ser: clientes, contas correntes, cheques, agncias.
Cliente representa o conjunto de clientes que se deseja manter dados no banco de dados

Aluno Nota fiscal

Atributos:
Dado que associado a cada ocorrncia de uma entidade ou um relacionamento.
So informaes importantes que caracterizam uma entidade ou relacionamento.
Os atributos de uma entidade so independentes de todas as demais entidades.

Exemplo:

Cliente cada ocorrncia de cliente ter associado exatamente os seus atributos (nome, CPF, telefone, endereo)

Aluno

matricula nome

Chave
um ou mais atributos que permite identificar unicamente uma entidade no conjunto de entidades.

Relacionamento
Conjunto de associaes entre entidades.
Um conjunto de relacionamentos uma coleo de ocorrncias das entidades relacionadas.
A funo que uma entidade exerce em um relacionamento chamada de papel, normalmente implcito, mas muito
esclarecedor.
Tambm pode ter atributos descritivos (por exemplo: data, hora, etc.)
A ocorrncia de um relacionamento particular dentro de um conjunto de relacionamentos de um mesmo tipo chamada
de instncia do relacionamento.
Exemplo:
Suponha o relacionamento lotao entre as entidades Departamento e Pessoa.
Este exemplo expressa que o BD armazenar dados sobre:
um conjunto de objetos classificados como pessoa entidade Pessoa;
um conjunto de objetos classificados como departamentos entidade Departamento;
21
 Escola Alcides Maya - Segundo Mdulo
um conjunto de associaes entre cada pessoa e um departamento;
relacionamento lotao

lotao

Cardinalidade
uma restrio de mapeamento que expressa o nmero de entidades as quais outras entidades pode ser associadas via
um conjunto de relacionamentos.
Um para um (1:1): uma entidade de A est associada a uma nica entidade de B, e uma entidade de B est associada a
uma nica entidade de A.
Um para muitos (1:N): uma entidade de A est associada a qualquer quantidade da entidade de B, e uma entidade de B
esta associada somente a uma nica entidade de A.
Muitos para um (N:1): uma entidade de A est associada a uma nica entidade de B, e uma nica entidade de B pode
estar associada a qualquer quantidade de entidades de A.
Muitos para muitos (N:M): uma entidade de A est associada a qualquer quantidade de entidades de B, e uma entidade
de B esta associada a qualquer quantidade de entidades de A.
Observe:

a b a b

a1 b1 a1 b1
a2 b2 a2 b2
a3 b3 a3 b3
b4

Relacionamento um para um Relacionamento um para muitos

b a b
a
a1 b1 a1 b1
a2 b2 a2 b2
a3 b3 a3 b3
a4 a4 b4

Relacionamento muitos para um Relacionamento muitos para muitos

22
 Anlise de Sistemas

Exemplo Prtico de Anlise

Locao de Fitas

Desenvolva um Diagrama de Casos de Uso para um sistema de vdeo locadora equivalente ao mdulo de locao de fitas
de filmes de acordo com as seguintes afirmaes:

a) Ao realizar uma locao, o scio deve primeiro informar seu cdigo para que o atendente possa verificar se este se
encontra cadastrado. Se o scio no estiver cadastrado, ento a locao dever ser recusada e o scio ser informado de como
proceder para se cadastrar. Caso esteja cadastrado, o atendente deve verificar se o scio em questo j devolveu todas as
locaes feitas anteriormente, se no o tiver feito, a locao dever ser recusada.

b) Caso o scio tenha quitado todas as locaes anteriores, ento este dever informar os nmeros das cpias dos filmes
que deseja locar. Em seguida o atendente registrar a locao e fornecer as cpias em questo para o scio.

c) responsabilidade de o atendente realizar a manuteno dos filmes e de suas respectivas cpias, registrando os novos
filmes adquiridos pela locadora, por exemplo.

CadastrarSocio

RealizarLocacao
Cliente Atendente

ManterFilmes

23
 Escola Alcides Maya - Segundo Mdulo

Desenvolva um diagrama de classes para um sistema de vdeo locadora equivalente ao mdulo de locao de fitas de
filmes de acordo com as seguintes afirmaes:

a) Um filme tem obrigatoriedade de pelo menos uma cpia, mas pode possuir diversas delas, porm uma cpia refere-se
exclusivamente a um determinado filme.

b) Um scio pode realizar muitas locaes enquanto permanecer scio da locadora, mas uma locao refere-se unicamente
a um determinado scio.

c) Cada locao deve obrigatoriamente referenciar-se ao menos a uma cpia de um filme, podendo referenciar-se a
muitas cpias, no entanto uma mesma cpia pode ter sido locada diversas vezes, em pocas diferentes obviamente.

Filme Copia ItemLocacao

1..* 0..*
+Titulo: char[60] +NroCopia: int +Preco
+Duracao: Time Possui +DataCopia: Date Compoe
+Registrar(): int

1..* Contem

Locacao
Socio
+DataLoc: Date
+Nome: char[40] Realiza +DataDev: Date
+Endereco: char[40] +Valor: float
+Telefone: char[15] 1..* +Situacao: int
+Consulta(nome: char): int +Locar(): int
+VerPendencias(): int

Desenvolva o diagrama de sequncia para um sistema de vdeo locadora de acordo com os fatos j descritos anteriormente
e nos seguintes fatos complementares:

a) Primeiramente o atendente deve verificar se o scio est cadastrado, se este no estiver, a locao deve ser recusada.

b) Em seguida deve verificar se o scio possui alguma locao pendente, caso que tambm recusar o emprstimo.

c) Se o scio existir e no tiver locaes pendentes, ento a locao dever ser registrada e as cpias emprestadas ao
scio.

d) Durante o registro da locao, devero ser registrados tambm todos os tens da locao.

24
 Anlise de Sistemas

<<boundary>> s1 : Socio : Locacao

Interface do Sistema

: Atendente
1 : Verificar scio()
2 : Consulta()
3 : VerPendencias()

4 : falso
5 : Verdadeiro

6 : Scio vlido, No h pendncias

7 : Registrar Locao()

loc1 : Locacao
8 : Locar()

9 *[para cada item] : Registrar() : ItemLocacao

10 : itens registrados
11 : verdadeiro

12 : Locao registrada com sucesso

25