Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Sistemas de Informação

No description
by

Alan Reis

on 3 November 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Sistemas de Informação

SISTEMAS DE INFORMAÇÃO
UNIPAR - SEDE
144191 - Weslley Carvalho
01053979 - Alan Lenon dos Reis
01055280 - Eduardo Castellini
01055315 - Giuliano Piovezan
01055334 - Jhonatam Priori
01055382 - Igor Fugimoto

3° ANO
Conceitos básicos de Analise Estruturada;
Diagrama Entidade-Relacionamento (DER);
Diagrama de Fluxo de Dados (DFD);
Especificação de Processos;
Especificação de Controle e Dicionário de Dados.

[ ]
[ ]
[ ]
[ ]
[ ]

Conceitos básicos de Analise Estruturada
Para que um analista de sistemas usa ferramentas de modelagem?
Fluxogramas

Pautas Musicais
Globos

Mapas
Desenhos
Arquitetônicos
Com os modelos podemos realçar e enfantizar recursos de um sistema
- Diagrama de fluxo de dados
- Diagrama de entidades-relacionamentos
- Diagrama de transições de estado.
Três ferramentas de modelagem de sistemas importantes, são,
As ferramentas de modelagem consistem em gráficos e ferramenta textual de suporte.
DIAGRAMA DE FLUXO DE DADOS
Neste diagrama os dados consistem em processos, depósitos de dados, fluxos e terminais:
O diagrama de fluxo de dados oferece uma visão geral dos principais componentes do sistema, mas não oferece detalhes sobre eles.
Para mostrar este detalhe utilizamos duas ferramentas textuais que são:
O
dicionário de dados
e a
especificação de processos.
DICIONÁRIO DE DADOS
ESPECIFICAÇÃO DE PROCESSOS
A MODELAGEM DE DADOS ARMAZENADOS: O
DIAGRAMA DE ENTIDADES – RELACIONAMENTOS

Todos sistemas armazenam e usam informações sobre o ambiente com o qual interagem, elas podem ser mínimas ou complexas.
Queremos saber se a informação está contida no depósito de dados. Más também que relacionamentos existem entre eles.
Este aspecto não é mostrado pelo diagrama de fluxo de dados, mas é retratado na ferramenta de modelagem: O diagrama de relacionamentos.
DIAGRAMA DE RELACIONAMENTOS
O d
iagrama de entidades-relacionamentos
, possui dois importantes componentes
1. Tipos de objetos são apresentados por um quadro retangular no diagrama de entidades-relacionamentos.
2. Relacionamentos são representados por losangos no diagrama.
A MODELAGEM DO COMPORTAMENTO TEMPO-
DEPENDENTE: O DIAGRAMA DE TRANSIÇÕES DE ESTADO

Um Terceiro aspecto de muitos sistemas complexos, é o comportamento tempo-pendente.
A ferramenta de modelagem que usamos para descrever esse aspecto do comportamento de um sistema é o diagrama de
transições de estado
, algumas vezes abreviado como DTE.
DIAGRAMA DE TRANSIÇÃO DE ESTADO
O retângulo representa os estados em que o sistema pode estar.
Associado ao estado estão as condições que são os eventos que vão causar a mudança dos estados.


Cada modelo gráfico descrito focaliza em um aspecto diferente de um sistema.

O Diagrama de fluxo de dados:
mostra as funções.

O Diagrama de Transição de Estado:
mostra o comportamento tempo-independente do sistema.

Estes modelos, foram projetados para serem lidos e entendidos por usuários, sem treinamento ou preparação.

O que é?





DER
Pra que serve?

O der é importante para os DBAs e para os analistas de sistemas.

IMPORTÂNCIA
COMPONENTES DE UM DER
São quatro:

Tipos de objetos

Relacionamentos

Indicadores associativos de tipos de objetos

Indicadores de supertipos/subtipos

Ele representam uma coleção ou um conjunto de objetos (coisas) do mundo real cujo membros individuais têm as seguintes características:


Cada um deles só pode ser identificado de uma única forma;

Cada um exerce um papel no sistema em construção;

Cada um pode ser descrito por um ou mais elementos de dados.

Representa um conjunto de conexões entre objeto.

RELACIOANMENTOS
Múltiplos relacionamentos
Notação alternativa para relacionamentos
Uma notação alternativa usada por alguns analistas, mostra tanto cardinalidade como a ordinalidade.

Indicadores associativos de tipos de objetos
Representa alguma coisa que funciona tanto como um objeto quanto como um relacionamento

INDICADORES DE SUPERTIPOS/SUBTIPOS
Consiste em um objeto e uma ou mais subcategorias, interligados por um relacionamento.

DIAGRAMA DE FLUXO DE DADOS
Os Componentes de um DFD

Diagramas de Fluxos de Dados:

* Um DFD não precisa de muita explicação, basta olharmos para o diagrama que conseguimos entender. A representação é simples e sem intrusões e, de uma certa forma, bastante intuitivo.

* O diagrama acomodasse facilmente em uma Pagina. Isso tem dois significados: 1 uma pessoa pode examinar o diagrama sem se confundir, 2 o sistema que está sendo modelado não é muito complexo.

* O diagrama mostrado aqui foi desenvolvido por um computador. Mas nada existe de errado com os diagramas desenhados a mão, claro que com auxilio do computador o desenho fica melhor.

Processo:
O primeiro componente de um DFD é conhecido como processo. Os sinônimos mais conhecidos
São bolhas, função e transformação. O processo mostra uma parte do sistema, a que transforma
Entradas em saídas, isto é, mostra como um ou mais entradas são convertidas em saídas. O processo é
Representado por um circulo como podem ver na figura abaixo

FLUXO:

Um fluxo é graficamente representado por uma seta que entra ou sai de um processo, a imagem
Abaixo representa um exemplo de fluxo.
Na maioria dos sistemas que você modela como analista de sistemas, os fluxos, na realidade,
Representam dados, isto é, bits, caracteres, mensagens, números de ponto flutuante e os diversos outros.
Tipo de informações com que o computador lida.

DEPOSITO:

O depósito é utilizado para modelar uma coleção de pacote de dados em repouso, A representação
Para um depósito são duas linhas paralelas, como na figura abaixo.

Para o analista de sistema com retrospecto de processamento de dados, é tentador referir-se
aos depósitos como arquivos ou banco de dados, como: Oracle, Firebird, MySql e entre outros.

Na Realidade, isso é como os depósitos são muita vezes implementados em sistemas. Computadorizados, mas um depósito também pode conter dados armazenados em cartões perfurados, microfilmes, microfichas, disco óticos, e varias outras variedades eletrônicas...

TERMINADOR

O terminador é mais um componente do Diagrama do fluxo de Dados. Ele é graficamente representado por um retângulo, como mostrado na figura abaixo.

Os terminadores representam entidades externas com as quais o sistema se comunica.

Tipicamente, o terminador é uma pessoa ou grupo de pessoa, por exemplo, uma organização externa ou uma empresa do governo ou um grupo ou setor que esteja dentro da mesma companhia
ou organização, mas fora do controle do sistema que esta sendo modelado.

Costuma ser muito fácil identificar os terminadores do sistema em modelagem. As vezes o terminador é o usuário; isto é, em nossas discussões com o usuário, ele dirá: “Pretendo fornecer os itens de dados X, Y e Z para o sistema e espero receber dele os itens de dados A, B e C”. E outros casos, o usuário considera-se parte do sistema e ajudara a identificar os terminadores importantes; por exemplo, ele poderá dizer-lhe “Precisamos estar prontos para recebermos formulários tipo 321 do departamento da contabilidade” e temos de remeter semanalmente relatórios orçamentais para comissão de finanças”. Nesse ultima caso, é claro que o departamento da contabilidade e a comissão de finanças são determinadores separados com quais sistemas se comunica.

Calcular trajetória do míssil, Validar número de telefone
Calcular trajetória do míssil, Validar número de telefone).
Porém há uma necessidade de se preocupar com verbos genéricos como FAZER, MANIPULAR e PROCESSAR,
Algumas precauções devem ser tomadas:
1. Escolher verbos e objetos compreensíveis ao usuário,
2. Caso o desenho DFD for realizado baseado em programação,
Numerar Processos
Evitar DFD Complexos Demais
Refazer o DFD tantas vezes forem necessárias
Um projeto de analise de sistemas do mundo real deve ser refeito ate que esteja
a. Tecnicamente correta
b. Aceitável pelo usuário
c. Visivelmente atraente aos olhos.
Alguns dos problemas da maneira de se desenhar:
• Tamanho e forma das bolhas • Fluxo de dados curvos versus fluxo de dados retos • Diagramas desenhadas a mão versus diagramas desenhada por maquina

VERSÃO DE UM DIAGRAMA DE
FLUXO DE DADOS
VERSÃO DE UM DIAGRAMA DE FLUXO DE DADOS DIFERENTE
Evite os poços sem fundo ou buraco negro
Evite bolhas com geração espontânea
Cuidado com os fluxos e processos sem rotulo
Cuidado com depósitos de leitura-apenas ou escrita-apenas

CERTIFICAR-SE DE QUE O DFD SEJA LOGICAMENTE CONSISTENTE
DFD com níveis
Top-Down?

Alto nível?

Detalhado?
Vemos que é uma forma direta para organizar um DFD complexo em níveis manipuláveis, porem há coisas que devem ser acrescentadas a essa descrição da subdivisão em níveis:

1) Como saber quantos níveis deve ter um DFD?
2) Existem diretrizes sobre o número de níveis que devem ser esperados em um sistema típico?
3) Todas as partes do sistema devem ser subdivididas ate o mesmo nível de detalhamento?
4) Como se mostram esses níveis para o usuário?
5) Como garantir que os níveis dos DFD sejam consistentes entre si ?
6) Como mostrar depósitos nos diversos níveis?
7)Como realmente se faz a subdivisão dos DFD em níveis?

Um DFD complexo
DFD em níveis
Um fragmento de DFD equilibrado
Um fragmento de DFD desiquilibrado
Extensões ao DFD para sistemas de tempo real.
Dentro do DFD é necessário modelaros fluxos de controle(sinais, interrupções...) e um modo de mostra processos de controle(bolhas que única tarefa é coordenar e sincronizar as atividades de outras bolhas do DFD).
Um DFD com fluxo de controle e processos de controle
A exibição de depósitos nos níveis inferiores
Especificação de Processos
A especificação de processos consiste na descrição interna da tarefa de cada processo primitivo dos níveis inferiores de um DFD.
A descrição de um processo primitivo também é designada por mini-especificação.
A especificação de processos só é elaborada para os processos primitivos e não deve ultrapassar a dimensão de uma página. Se a mini-especificação for complexa é necessário decompor o processo num DFD de nível inferior.

Objectivos da mini-especificação:

Descrever as regras de transformação dos fluxos de entrada em fluxos de saída, traduzindo a política de transformação e não um método de implementar essa política;

Descrever atividades sem impor decisões arbitrárias de desenho ou implementação;

Rever e corrigir o DFD elaborado, pois a especificação de processos permite detectar necessidades de fluxos e atividades adicionais.

Técnicas para a escrita de mini-especificações

• Linguagem estruturada;
• Pré e Pós-condições;
• Tabelas e árvores de decisão;
• Fluxogramas;
• Diagramas de Nassi-Shneiderman;
• Qualquer combinação das técnicas anteriores.

Linguagem Estruturada
A Linguagem estruturada, LE, é uma linguagem de especificação retirada da linguagem corrente à qual foram feitas algumas limitações na sintaxe e no vocabulário. A LE é a técnica de especificação mais utilizada.
A LE é utilizada para escrever vários tipos de instruções:

PRÉ / PÓS Condições
Constituem uma forma conveniente de descrever a função que tem de ser executada por um processo, sem especificar o respectivo algoritmo.
• O utilizador tem tendência para expressar os procedimentos que utiliza para sustentar uma política e não a política subjacente que tem de ser levada a cabo;

• O analista reconhece que existem vários algoritmos diferentes, que podem ser usados, e pretende adiar a opção por um deles para uma fase posterior;

• O analista quer deixar para o programador a tarefa de exploração de vários algoritmos e não se quer envolvem nestes detalhes.

A utilização de pré / pós condições é apropriada quando:
A utilização de pré / pós condições não é apropriada quando:
• O número de passos intermédios para produzir as saídas é elevado, tornando a especificação produzida difícil de interpretar pelo facto de não se visualizar todos os procedimentos executados;

• Os relacionamentos entre entradas e saídas a produzir são complexos, sendo mais fácil escrever a especificação através da utilização da “Linguagem estruturada”.

A especificação de processos através desta técnica é constituída pela descrição de dois tipos de condições:
Pré condições: As pré condições especificam tudo o que se deve verificar antes da atividade do processo se iniciar.

Pós condições: Similarmente, as Pós condições especificam tudo o que se deve verificar quando o processo terminar a sua atividade. Ou, seja, especificam o que é feito e não como é feito.

Tabelas e Árvores de decisão
Tabelas e árvores de decisão são duas técnicas de representação da política de seleção condicional, usada para derivar um conjunto de ações, respectivamente sob a forma:
• Tabular;
• Diagramática.

Estas duas técnicas também são referidas como ferramentas de modelação não procedimentais, pois:
• Especificam a política de transformação das entradas em saídas;
• Não especificam o algoritmo subjacente da transformação.


As árvores de decisão correspondem a uma variante das tabelas de decisão que representam a política de seleção condicional, através da organização hierárquica de séries de decisões.

Comparando as duas técnicas, verifica-se que uma árvore de decisão permite uma representação mais óbvia, mas menos concisa.
Fluxogramas
Os fluxogramas foram usados no passado como um mecanismo de representação gráfica de algoritmos e do seu fluxo de controlo.

Contudo, os fluxogramas perderam interesse devido a problemas relacionados com a sua utilização em duas áreas:

Como ferramenta de modelação de alto nível e como ferramenta de modelação de processos.

Com o objetivo de Restringir a utilização de fluxogramas à modelação interna de processos e restringir a utilização de fluxogramas à combinação aninhada de símbolos equivalentes a estruturas de controlo da programação estruturada.

Exemplos de símbolos de fluxogramas equivalentes a estruturas de controlo da programação estruturada
Diagramas de Nassi-Shneiderman
Os diagramas de Nassi-Shneiderman foram introduzidos como uma técnica de elaboração de fluxogramas estruturados.

Os diagramas de Nassi-Shneiderman orientam-se por blocos sendo mais organizados, mais estruturados e mais compreensíveis do que fluxogramas. Contudo, para além de ser necessário elaborar um grande número de esquemas não triviais, estes esquemas não introduzem grande valor acrescentado. De acordo com o proferido por muitos analistas, “estes diagramas correspondem a Linguagem Estruturada com caixas à volta”.

A utilização de fluxogramas e diagramas de Nassi-Shneiderman não é abençoada por muitos analistas de sistemas.
Contudo, existem estudos que comprovam a preferência deste tipo de ferramentas por parte de estudantes de programação, como um mecanismo de aprendizagem. Se os estudantes preferem estas representações, é natural supor que os utilizadores também as prefiram.
Full transcript