Análise e Projeto de Sistemas - Apostilas - Informática_Part2, Notas de estudo de Computação. Centro Federal de Educação Tecnológico (CEFET-PA)
Alfredo_88
Alfredo_88

Análise e Projeto de Sistemas - Apostilas - Informática_Part2, Notas de estudo de Computação. Centro Federal de Educação Tecnológico (CEFET-PA)

25 páginas
664Número de visitas
Descrição
Apostilas de Informática sobre Análise e Projeto de Sistemas, Abordagem sistêmica, O que é afinal um sistema, Interdependência, Eventos de um sistema, Natureza dos sistemas.
20 pontos
Pontos de download necessários para baixar
este documento
Baixar o documento
Pré-visualização3 páginas / 25
Esta é apenas uma pré-visualização
3 mostrados em 25 páginas
Baixar o documento
Esta é apenas uma pré-visualização
3 mostrados em 25 páginas
Baixar o documento
Esta é apenas uma pré-visualização
3 mostrados em 25 páginas
Baixar o documento
Esta é apenas uma pré-visualização
3 mostrados em 25 páginas
Baixar o documento
manual4.PDF

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 26

levantamento de eventos abrangendo o conteúdo que deverá ser informatizado. Ou seja, deve ser feito o famoso levantamento de requisitos do sistema. Todos os aspectos envolvidos no problema devem ser levantados, pessoas devem ser entrevistadas, documentos devem ser avaliados, o fluxo de trabalho deve ser entendido. Você deverá sair desta fase sendo quase um especialista sobre o assunto que deverá informatizar, ou seja, no mínimo saberá todos os eventos e dados essenciais relativos ao assunto.

De posse deste conhecimento você começa a estar apto a iniciar alguma especificação dos requisitos do sistema.

Modelo Ambiental

Assim, passado este momento inicial em que se avalia o domínio do problema e se busca os requisitos do sistema, você poderá definir qual a relação do sistema a ser desenvolvido com o ambiente no qual ele estará inserido. Vai descrever qual é ou quais serão os objetivos do sistema, bem como quais serão os estímulos que o sistema receberá do meio ambiente, que eventos eles acionarão e quais respostas o sistema devolverá ao meio.

Basicamente, neste ponto há uma descrição da relação entre o sistema e o meio ambiente onde ele se encontra.

Modelo Comportamental

Neste ponto, o trabalho se volta para definição interna do sistema. Serão especificados todos os processos que irão compor o sistema. Haverá também a definição do modelo de dados que será utilizado para armazenar as informações por ele manipuladas.

Projeto(“design”)

Nesta fase, o objetivo é modelar o sistema determinando como implementar, em um ambiente de processadores, a solução sistêmica idealizada na fase de análise.

Esta parte do trabalho cuidará das especificações referentes as limitações impostas pela tecnologia, a distribuição dos processos de acordo com os lugares onde serão executados.

As restrições de implementação, da tecnologia não ideal e imperfeita serão incorporadas através de atividades de infra-estrutura administrativas.

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 27

5. Ferramentas

O Analista de Sistemas, deverá utilizar algumas ferramentas que o ajudarão a trilhar o seu caminho.

Elas poderão ser utilizadas em diferentes partes do método de análise essencial. Daí a razão de destacar-se o funcionamento de cada uma antes de conhecermos profundamente o método. Desta forma, o objetivo é entender a ferramenta em sí, livre do contexto onde será empregada.

5.1. Entrevistas

É certo que um grande volume de informações, persuasão, flexibilização, consenso e especialmente divergências, ocorrerão em encontros pessoais (duas ou mais pessoas), às vezes de caráter mais formal, outras vezes bem informal e que, em geral, recebe o nome de reunião. A reunião pode ter um momento de questionamentos, na busca de informações; ou seja, uma entrevista, normalmente sem qualquer conotação de rigor ou formalidade como o termo pode sugerir.

Entrevistas portanto, são situações inseridas nas relações humanas que não estão sujeitas a regras ou fórmulas exatas. Mas, pode ser útil que o Analista de Sistemas tenha em mente alguns aspectos, relacionados a esta atividade que poderão ajudar na sua execução.

O objetivo de uma entrevista (para a análise de sistemas) é o de coleta de informações sobre o sistema a ser desenvolvido. Talvez, seja esta a fonte mais rica de conhecimentos sobre o sistema que deverá ser feito. Ajuda nos aspectos chaves do sistema bem como esclarece pontos contraditórios do mesmo, ou, em alguns casos, torna o aspecto mais contraditório, o que é algo também importante de se conhecer. Verifica-se posicionamentos pessoais acerca das questões envolvidas (omissões, medo, desvios).

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 28

A entrevista de que se fala aqui, pode ser um simples bate-papo durante o cafezinho. Pode ser um encontro no corredor, por acaso. Enfim, qualquer situação que se apresente como oportunidade para se buscar a informação necessária, em que o meio seja o diálogo entre duas ou mais pessoas. O Analista deve estar pronto para realizá-la, sabendo de antemão, que a ela poderá acontecer assim, ao acaso.

Não raro, haverá a necessidade de se entrevistar diversas vezes uma ou várias pessoas, para se chegar a informação desejada.

Como Preparar

Para se conseguir uma entrevista eficaz, alguns cuidados devem ser tomados: - Clareza de sua finalidade - Identificação de perguntas chaves - Repasse de documentação formal (se houver)

Atente para alguns detalhes: quando se tratar de aspectos gerais sobre um assunto, a pessoa mais indicada para se buscar esta informação é a gerência. Quando o interesse for para assuntos que exijam maior riqueza de detalhes, o ideal é entrevistar uma pessoa operacional, que esteja no seu dia a dia, envolvida com aquele aspecto. Mas, lembre-se da hierarquia da empresa, primeiro fale com o supervisor a quem a pessoa estiver locada. Isto envolve desde aspectos políticos até um fator de motivação para que a pessoa fale melhor sobre o assunto, visto que “o chefe a indicou por ser a melhor funcionária que domina aquela questão...”.

Programe a entrevista de acordo com a disponibilidade do entrevistado.

Toda entrevista bem conduzida, formal ou não, possui três aspectos: abertura, corpo e o fecho.

Na abertura, procure estabelecer uma atmosfera amigável para a comunicação, informe sobre o objetivo.

O corpo se caracteriza por ser a entrevista propriamente dita, a arrancada é feita com sua primeira pergunta. Certifique-se de que entendeu o que lhe foi transmitido. Um meio indicado é o repasse (deixa ver se entendi, então quer dizer que...).

Ouça as respostas enquanto a questão está sendo respondida, não se preocupe em elaborar a próxima. Faça as anotações que julgar necessárias, porém seja breve, sintetize as idéias.

Entrevista não é julgamento, disputa do saber ou concorrência com o entrevistado. Lembre-se sempre que a pessoa é a especialista no que faz e você apenas busca informações. Procure distinguir fatos de opiniões pessoais.

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 29

No fecho da entrevista, procure manter a atmosfera de comunicabilidade. Esteja atento ao horário para evitar qualquer transtorno ao entrevistado. Agradeça a colaboração, mesmo que o encontro tenha sido infrutífero e distante do planejado.

5.2. Diagrama de Fluxo de Dados (DFD)

É utilizado para a representação lógica 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 comunicação com pessoal técnico ou não técnico, já que a representação gráfica é de fácil entendimento. O seu uso não depende de hardware, software, estrutura de dados ou organizações de arquivos.

O DFD permite que se organize informações colhidas nas entrevistas acerca do sistema que se desenvolverá. Possibilita a visão global do sistema e seu desmembramento a níveis mais detalhados. O DFD às vezes também é chamado de diagrama de bolhas.

A seguir, a notação gráfica utilizada:

Para representar processos (ações):

Para representar sentido do fluxo

Para representar armazenamento de dados (depósito de dados)

Entidades externas ao sistema

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 30

Algumas situações com agregação da simbologia:

Operação de Inclusão

Operação de Leitura

Operação de Modificação ou Exclusão

Um exemplo, agregando todos aspectos da simbologia:

A entidade externa é sempre um elemento ativo. Ela aciona processos, mediante o envio de estímulos (fluxos de dados ou fluxo de controle). No caso acima, o cliente envia um fluxo de dados, acionando o processo cadastrar pedidos, o qual, utiliza o cadcliente e cadlivro em operações de input, e o cadpedido para operações de i-o.

Cliente

Cadastrar Pedidos

CADLIVROS

CADCLIENTE

CADPEDIDO

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 31

Para empregar uma representação com mesmo significado (redundância) no mesmo desenho do DFD, utiliza-se alguns recursos.

Para obter um bom desenho global do DFD, procure seguir algumas normas que são observadas como um consenso no desenho do mesmo:

- O sentido do desenho é sempre de cima para baixo, da esquerda para a direita. - As entidades externas, tanto quanto possível, devem aparecer nas bordas do desenho

Evite erros grosseiros, conforme definido abaixo:

- Jamais um fluxo de dados parte de um depósito e vai para outro depósito sem a intermediação de um processo.

- Um fluxo de dados nunca parte de uma entidade externa diretamente para o depósito; sempre há um processo intermediando.

- Também não é possível um fluxo partir de uma entidade externa diretamente para outra entidade externa.

- Igualmente, um fluxo jamais parte de um depósito diretamente para uma entidade, sempre há a intermediação de um processo.

Exercícios

Desenvolver um D.F.D. para cada enunciado abaixo:

1. “O caixa do banco recebe cheque para descontar. Ele verifica na ficha do cliente se há saldo disponível, em caso afirmativo, dá o dinheiro; caso contrário devolve o cheque”

2. “O professor passa para a secretaria 4 notas de cada aluno que possui. A secretaria calcula a média de cada um e anota o resultado na ficha do aluno. Quando o aluno solicitar sua média, a secretaria consulta a ficha dele, anota a mesma em um papel e entrega ao aluno”

Cliente Cliente

Cadpedido Cadpedido1 1

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 32

3. “Para fazer um bolo, pega-se ovos, fermento, leite e manteiga na geladeira. O açúcar e a farinha encontram-se no armário. Se estiver faltando um destes ingredientes, deve-se compra-los no supermercado. Mistura-se todos os ingredientes até formar a massa. A massa deve ficar em repouso por uma hora. Depois deste tempo, deve-se colocar a massa no forno em fogo baixo. Após uma hora e trinta minutos, retirar do forno e deixar sobre a mesa para resfriar. Quando resfriar, acrescentar a cobertura a gosto, em seguida, guardar na geladeira.”

5.3. Dicionário de Dados

O dicionário de dados é uma coleção de dados a respeito de dados. A idéia básica é fornecer informações sobre a definição, a estrutura e a utilização de cada elemento de dados que o sistema utiliza. Elemento de dado é a unidade de dados que não pode ser decomposta.

Ao se falar em dicionário de dados, temos que lembrar duas concepções de organização hierárquica de dados hoje existentes:

a) Organização Hierárquica Tradicional

Geralmente é utilizada por linguagens de 3ª geração e possui a estrutura que segue:

b) Organização Hierárquica Emergente

Estrutura conceitual mais recente, com advento das linguagens de 4ª geração, bancos de dados e orientação a objeto.

Arquivo

Registro

Campo

SubCampo

Estrutura de Dado

Elemento de Dado

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 33

Estrutura de dados – são formadas de elementos de dados ou de outras estruturas de dados, ou uma mistura de ambos.

Elemento de dado – dados que não necessitam de decomposição para o fim a que se destinam.

Por que utilizar um dicionário de dados ?

A razão mais óbvia é a documentação. Contudo, esta é uma visão simplista de sua necessidade. Em uma organização, diferentes pessoas ou grupos, poderão definir um elemento de dados específico de modo bastante diferente.

Exemplo. “Em uma escola, um Analista de Sistemas, conversou com três pessoas pessoas: a secretária, a tesoureira e o professor. Na conversa individual com cada um, todos citaram um elemento de dados chamado “tipo de aluno”, contudo, para cada um deles este dados tinha conteúdo diferente: Secretária – Boa nota, má nota Tesoureira – Bom ou mal pagador Professor – Muito esforçado, pouco esforçado.”

O inverso também acontece, nomes diferentes para referenciar o mesmo conteúdo. Por exemplo: registro do empregado, código do funcionário ou nº de identificação funcional podem ser exatamente a mesma coisa.

Perceba, portanto, as implicações amplas de um dicionário de dados no desenvolvimento de sistemas. Se todos os desenvolvedores envolvidos em um sistema, tiverem que utilizar descrições de dados a partir de um dicionário comum, vários problemas potencialmente graves poderão ser evitados.

Para qualquer dado procure sempre definir : - um nome de identificação - pseudônimos - tipo de conteúdo (numérico, alfanumérico, inteiro, data) - tamanho máximo - formatação - domínio (restrições de atributo – ex. de 1 até 9) - restrições de relacionamentos

As formas de especificar ou documentar estas informações acerca de um dado, tem alguma variação. Normalmente, se estiver utilizando linguagem de 4ª geração terá a sua disposição um dicionário de dados pertinente a linguagem. O mesmo pode-se verificar em ferramentas orientadas a objetos, ou ainda, pode-se lançar mão de softwares especialmente construídos para tal fim, que possuam uma interface com sua plataforma de desenvolvimento.

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 34

6. O Processo de Análise – Modelo Essencial

O Modelo Essencial ou Análise Essencial é uma evolução dos métodos antecessores no desenvolvimento de sistemas, conforme mostra a tabela abaixo:

MODELO ABORDAGEM FERRAMENTAS Convencional / Tradicional Surgiram no início dos anos 50 e foram muito utilizados até 1975

Totalmente funcional Textos Fluxogramas

Estruturado Começou a partir de 1975 e ainda deverá continuar a ser utilizado mais alguns anos por algumas empresas Chris Gane / 1979 Yourdon / 1979

Funcional

Dados

DFD Diagrama de Estrutura de dados Especificação dos processos Normalização Dicionário de dados

Essencial Trata-se de um aprimoramento do estruturado que teve início em 1984. Sthepehn McMenamim John Palmer

Essência Funcional

Dados

Integração Funcional e Dados

DFD de Contexto DFD por eventos Tabela de Eventos Diagrama Entidade Relacionamentos Diagrama de Estrutura Normalização Dicionário de dados

Orientado a Objetos Decorrente dos conceitos já existentes na programação - Simula (67) / Smalltalk(70). Mais nova Abordagem sobre Análise. Final década 80.

Objeto = Encapsulamento de Funções e Dados

Contempla o estado de um objeto

Visão estática e dinâmica

Diagrama de Casos de Uso Diagrama de Classes e Objetos Diagrama de Sequencia Diagrama de Colaboração Diagrama de Componentes Diagrama de Distribuição

A análise essencial deve começar com o entendimento daquilo que o usuário está solicitando. Este entendimento no primeiro momento, refere-se apenas ao tracejamento dos limites fronteiriços do sistema, ou seja, procure responder:

O que o sistema deverá fazer ? Quais são seus objetivos ?

Tendo claramente definido este aspecto você terá traçado as fronteiras daquilo que deverá ser desenvolvido, por exemplo:

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 35

Depois de haver entendido claramente o que o usuário espera que seja feito, o analista de sistemas deverá mergulhar profundamente na busca de informações que envolve aquela área. É a fase precedente do inicio de análise, chamada de análise de requisitos do sistema ou levantamento de eventos e dados iniciais.

Após este passo, o analista de sistema deverá no mínimo conhecer todas as atividades mais essenciais ligadas ao sistema a ser desenvolvido. Portanto, se o sistema for para controle da locação e consulta do acervo de uma biblioteca de universidade, no mínimo o analista deverá saber:

- quem são os usuários da biblioteca - como alguém se torna usuário da biblioteca - como e quando entra e sai o acervo (livros, revistas, jornais, periódicos) - quais são os eventos essenciais existentes no sistema - quais são as regras e restrições envolvendo estes eventos - quais as expectativas do usuários sobre o sistema a ser desenvolvido - quais são os problemas atuais - quais as vantagens que o novo sistema proporcionará

Vamos tomar o controle da locação e consulta do acervo de uma biblioteca de universidade, como um estudo de caso, para termos uma idéia mais clara da aplicação da teoria.

Vejamos qual foi o resultado colhido pelo analista nesta fase de análise de requisitos do sistema.

Sistema: Controle de locação e consulta do acervo de uma biblioteca de universidade.

Objetivos: Controlar os empréstimos, devoluções, reservas, consultas e cadastros do acervo de uma biblioteca universitária.

Abrangência:

Controle da locação e consulta do acervo de uma biblioteca de universidade

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 36

1. O sistema atende a uma biblioteca central de uma universidade. 2. Os usuários (Professores, alunos e funcionários) já se encontram cadastrados em

sistemas já existentes, e as bibliotecas que farão uso do acervo serão cadastradas pelo sistema.

3. No caso de inexistência de uma obra no acervo, os dados referentes a mesma serão guardados, para auxiliar futuras compras pela administração

4. O acervo da biblioteca é composto por livros, revistas, jornais, enciclopédias, dicionários, trabalhos acadêmicos; prevê ainda a possibilidade de inclusão de novos tipos de obras.

5. Periódicos, dicionários e enciclopédias não poderão ser locados, somente consultados na própria biblioteca.

6. Os livros clássicos de cada área poderão ser locados, desde que permaneça um exemplar nas dependências da biblioteca para consulta.

7. O prazo de locação atual é de 3 dias. 8. Uma obra só poderá ser reservada se não estiver à disposição para empréstimo. 9. Os usuários do sistema serão professores, alunos e funcionários da universidade e

outras bibliotecas não pertencentes ao Campus. 10. Mensalmente poderá ser emitido relatórios demonstrando as obras mais retiradas,

permitindo à administração verificar se há a necessidade de aquisição de mais volumes daquela obra.

11. O sistema permitirá identificar, através de relatórios mensais, quais os usuários mais ativos, propiciando a administração algum tipo de premiação, estimulando assim aos demais usuários.

12. Através de um relatório mensal, o sistema acusará os usuários menos pontuais na devolução de obras ao acervo.

Funções:

Empréstimos Devoluções Reservas Cobranças Cadastro de novas obras Cadastro de Bibliotecas Estatística de obras mais retiradas Estatística de usuários mais ativos Relação das obras solicitadas não existentes Estatística dos usuários menos pontuais

Vantagens da implantação do sistema

- Considerável ganho de tempo na localização física de uma obra do acervo. - Absoluta precisão na cobrança de obras em atraso. - Levantamentos estatísticos mensais:

- Das obras mais retiradas - Dos usuários mais ativos

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 37

- Dos usuários menos pontuais na devolução

- Completo controle sobre todas as obras do acervo, locadas ou não, próprias ou de terceiros.

- Possibilidade de pesquisa a qualquer momento das obras reservadas, informando dados da obra e usuário.

- Manutenção de dados sobre obras inexistentes no acervo, auxiliando futuras compras para o mesmo.

6.1.Modelo Ambiental

Quando o analista de sistema estiver de posse das informações mais essenciais sobre o sistema (conforme demonstrado no estudo de caso – análise de requisitos), pode ser dado o primeiro passo da análise essencial – a construção do modelo ambiental.

O modelo ambiental, está constituído de três partes:

Declaração dos objetivos do sistema Elaboração do D.F.D. de Contexto Criação da Lista de Eventos

Pode-se começar por qualquer uma das partes. Aliás, elas poderão ser desenvolvidas paralelamente. Uma não precede a outra, porém devem ser totalmente consistentes entre sí. Normalmente, segue-se a seqüência acima especificada.

O objetivo do modelo ambiental é mostrar qual a relação do sistema com o ambiente onde ele encontra-se inserido. Procura-se documentar quais são os estímulos que partem deste ambiente, mostrando quem os deflagrou. Demonstra-se ainda as respostas que saem do sistema para o meio ambiente.

6.1.1. Declaração dos Objetivos do Sistema

Uma forma textual, narrativa até, para descrever o que se propõe a fazer, quais problemas resolver, construindo o sistema em questão. Ressalta-se que no objetivo(s) do sistema deve estar refletido aquelas atividades fundamentais que o sistema deverá ter (atividades custodiais). Também deve refletir aquelas atividades que é do desejo do usuário que o sistema as tenha (o que também é fundamental – não adianta ter um sistema tecnicamente perfeito se o mesmo não satisfaz o usuário. O usuário e seus problemas é que são a razão da existência do sistema.).

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 38

Para o nosso estudo de caso, poderíamos ter:

Objetivo Geral: Controlar os empréstimos, devoluções, reservas, consultas e cadastros do acervo de uma biblioteca universitária.

Objetivos Específicos Essenciais:

Cadastrar empréstimos do acervo a usuários previamente cadastrados Registrar devoluções do acerto pelos usuários Efetuar Reservas do acervo para usuários Emitir cobranças de acervo emprestado com atraso na devolução Cadastrar novas obras no acervo Cadastrar Bibliotecas Emitir Estatística de obras mais retiradas Emitir Estatística de usuários mais ativos Emitir Relação das obras solicitadas não existentes Emitir Estatística dos usuários menos pontuais

6.1.2. D.F.D. de Contexto

Controle da locação e consulta do acervo de uma biblioteca de universidade

Usuários

Depto Administrativo

Devolução

Reserva

Carta-Cobrança

Consulta

Relatórios-Estatísticos

Dados-Obras

Empréstimo

Dados-Consulta

Dados-Emprestimo

Dados-Cobrança

Dados-Bibliot

Obras-Inex

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 39

6.1.3. Lista de Eventos

Nº Evento Descrição do Evento Estímulo Tipo Estímulo

Ação Resposta

01 Usuário Consulta Obra

Quando o usuário desejar verificar a existência ou situação de determinada obra

Consulta F Consultar Obra Dados-Obra ou Msg-01

02 Usuário Reserva Obra

O usuário pode reservar obras, desde que não seja periódicos ou enciclopédias.

Reserva F Reservar Obra Msg-02

03 Usuário Empresta Obra

O usuário passa os dados da obra que deseja levar. Ela pode ter sido reservada previamente. Períodicos e enciclopédias não podem ser emprestados. Se houver apenas um exemplar de uma obra que seja um clássico em sua área, também não poderá ser emprestado.

Dados- Emprestimo

F Emprestar Obra Obra ou Msg-03

04 Usuário Devolve Obra

Quando o usuário faz a devolução de uma obra que havia emprestado

Obra F Registrar Devolução Msg-04

05 Usuário recebe cobrança

Decorrido o tempo destinado a devolução de obras, o usuário receberá uma carta de cobrança

Dados-Cobrança F Gerar Cobrança Carta- Cobrança

06 Administ ração Cadastra Obras

Quando uma nova obra for fazer parte do acervo da biblioteca (via compra ou doação) a administração efetua o cadastro da mesma

Dados-Obra F Cadastrar Obra Msg-05

07 Administ ração Cadastra Bibliotec as

Quando uma nova biblioteca requisitar seu cadastro, ou necessitar efetuar algum empréstimo

Dados-Bibliot F Cadastrar Bibliotecas Msg-06

08 É hora de emitir relatórios estatistic os

Todo dia primeiro de cada mês é emitido os relatórios: Obras mais lidas Usuários mais ativos Usuários menos pontuais

T Emitir Relatórios Estatísticos

Relatórios- Estatisticos

09 É hora de emitir obras inexistent es

Todo primeiro dia de cada mês é gerado um relatório com as obras solicitadas e que não existem no acervo, referente ao mês anterior

T Listar Obras Inexistentes Obras-Inex

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 40

Cada linha da lista de eventos corresponde a um evento (acontecimento) que de alguma forma estimula (aciona) uma ação (programa) no sistema. Desta maneira, a lista de eventos é apresentada sob a forma de uma tabela que mostra não apenas os eventos, mas também os estímulos, ações e respostas correspondentes.

A primeira coluna, é apenas para identificação dos eventos, enumerando-os de forma crescente.

Na segunda coluna, temos a atribuição de um nome para o evento (acontecimento externo ao sistema, ou qual, vai servir de estímulo a ele – vai acioná-lo). Assim, ao atribuir o nome a um evento, deve-se seguir uma estrutura frasal, conforme indicado abaixo: “sujeito (entidade-externa) + verbo + complemento verbal (ou objeto)”

Todavia, quando se tratar de algum evento cujo estímulo seja de natureza temporal, a estrutura frasal, passa a ser: “É hora de ...”

Uma breve descrição sobre o evento, deve ser colocada na terceira coluna da lista de eventos. Isto permite observar alguns detalhes que não estão expressos no nome atribuído ao evento, ajudando no entendimento do mesmo.

Em seguida, na quarta coluna, indica-se o tipo de estímulo – ele sempre será um Fluxo de Dados (F), um Fluxo Temporal (T) ou um Fluxo de Controle (C).

Fluxos de Dados referem-se ao trânsito de dados propriamente dito, o Fluxo Temporal é um estímulo gerado de acordo com certo tempo (Chegou a hora de ...) e o Fluxo de Controle é gerado por algum dispositivo físico de controle, como o movimento de uma catraca, ou a introdução de um cartão.

Na quinta coluna tem-se o nome da ação que será executada pelo sistema, ou seja, o programa(s) que será(ão) acionado(s). Estes programas são aqueles que você está prevendo ou projetando que deverão ser desenvolvidos, sem contudo, neste momento, preocupar-se com o detalhamento deles. Basta aqui, prever que eles deverão existir, para juntos, atenderem ao objetivo global do sistema.

Na última coluna, é especificado um nome para resposta(s) que a ação do sistema dará para o meio externo a ele. Por exemplo, um relatório é uma resposta (saída) do sistema que irá para o meio externo a ele.

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 41

Sincronismo de Eventos

A lista de evento, apresentada sob forma de tabela, não aborda ou não expressa o momento de determinado evento pode acontecer em função dos outros. Porém, deve-se observar que, entre eventos, podem ocorrer as situações definidas abaixo, que terão maior peso quando se tratar de um sistema em real-time.

Simultaneidade A ocorrência de um evento é simultânea, concomitante com a ocorrência de outro. Pode até haver coincidência, como: o término do verão coincide com o início do outono.

Precedência A ocorrência de um evento deve necessariamente preceder a ocorrência de outro. Há uma seqüência entre os eventos. Exemplo: O Cadastramento de um empregado deve preceder o cadastramento de seu respectivo dependente.

Excludência A ocorrência de um evento deve necessariamente excluir a ocorrência de outro. Há alternância entre os eventos; sempre que um evento ocorrer, o outro não terá ocorrido, ou seja, situações mutuamente excludentes. Exemplo: O cliente é do sexo masculino ou feminino.

Independência Não há nenhuma relação de simultaneidade, precedência ou de excludência entre os eventos. Há total assincronismo. Exemplo: O cadastro de clientes independe do cadastramento de fornecedores.

6.2.Modelo Comportamental

A partir deste momento, o Analista de Sistema passa a se preocupar com os aspectos internos ao sistema, com tudo aquilo que virá determinar o comportamento do mesmo.

No modelo ambiental, o Analista de Sistemas descreveu o sistema sob o ponto de vista externo, observado pelo lado de fora, usando um estilo do tipo estímulo-resposta, mostrando o que faz e ou que não faz parte do sistema, preocupando-se em delimitar fronteiras, definindo qual era o universo de interesse.

Por sua vez, o modelo comportamental é definido do ponto de vista interno, é o modelo do interior do sistema. Irá descrever de que maneira o sistema, enquanto um conjunto de elementos inter-relacionados, reage, internamente, como um todo organizado, aos estímulos do exterior. Neste ponto, se preocupa em mostrar quais as ações que o sistema deve executar para responder adequadamente aos eventos previsto no modelo ambiental, que é o ponto de partida. A partir deste ponto, começa-se a detalhar como se fará um determinado programa.

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 42

Quando pensamos em decompor um sistema, logo nos vêm a mente dois tipos de componentes: funções e dados. Quais são as funções do sistema e quais são seus arquivos ou depósitos de dados. Porém precede a estas questões saber: O que é produzido pelo sistema ? A que estímulos o sistema deve responder ? Na verdade, dados armazenados e funções (programas) são meios para atingir-se o verdadeiro objetivo do sistema, que é apresentar as respostas adequadas ao ambiente em que está inserido. Portanto, a decomposição de que se fala, deve ser feita a partir da necessidade de resposta aos eventos que afetam o sistema, ou seja, o particionamento do sistema deverá ser feito a partir dos eventos existentes.

6.2.1. D.F.D. Particionado por Eventos

O D.F.D. particionado por eventos é um detalhamento de cada um das ações que serão acionadas por eventos, conforme indicado na lista de eventos. Este passo só deve ser iniciado quando o Analista de Sistemas entender que a sua lista de eventos está “completa”. Naturalmente, para chegar a conclusão de que a lista de eventos está completa, basta checar se todos os eventos mais essenciais existentes no sistemas estão alí definidos. Não significa que, se posteriormente, alguém se lembrar de algum evento que esteja faltando, não seja possível acrescer o mesmo na lista. É claro que isto deverá ser feito. Porém, quanto mais completo a lista estiver, melhor para começar esta etapa, já que aqui tem-se um aprofundamento em detalhes de cada um dos eventos, e portanto, uma visão da relação entre eles e os dados que irão manipular. A ausência de algum evento, poderá levar a não previsão de alguma informação essencial ao sistema.

A partir do Diagrama de Contexto e da Lista de Eventos, adota-se a seguinte conduta, para obter o particionamento do sistema:

1) Para cada evento do sistema, desenha-se uma função (um D.F.D.) ou processo de resposta ao evento (uma ação). Deverá existir tantos processos quantos forem os eventos existentes na lista de eventos. Se a lista possuir 47 eventos, significa que deverá ser desenhado 47 D.F.Ds, um para cada evento existente. O nome atribuído ao processo deverá ser de acordo com a coluna ação existente na lista de eventos.

2) Não pode-se esquecer de representar no DFD as respostas oriundas do processo. Observe que para um processo, pode haver respostas externas ao sistema ou internas a ele. No caso de uma resposta interna, tem-se, por exemplo, o fluxo de dados para um depósito de dados. É só a partir do DFD particionado por evento que passa a existir a representação deste fluxo (já que no DFD de contexto é tratado tudo que é externo ao sistema, e portanto, lá não aparecem depósitos de dados).

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 43

Exemplos de DFDs particionados por evento, decorrentes e em conformidade com a lista de eventos presente em uma das páginas anteriores.

Evento 01 - Usuário Consulta Obra

Evento 02 - Usuário Reserva Obra

Usuário Consultar Obra

CadObras

CadObrasInex CadReserva

Consulta

Usuário Reservar Obra

CadObras

CadReserva

Reserva

Dados-Obra

Msg-01

CadUsuário

Msg-02

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 44

Evento 03 - Usuário Empresta Obra

Evento 04 - Usuário Devolve Obra

Usuário Emprestar Obra

CadObras

CadEmprestimo CadReserva

Dados- Emprestimo

Obra

Msg-03

Usuário Registrar Devolução

CadObras

CadEmprestim

CadObrMaisLida

Obra

Msg-04

CadUsuMaisAtivo CadUsuMenosPont

CadUsuário

CadUsuário

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 45

Evento 05 - Usuário Recebe Cobrança

E assim, deve-se proceder para todos os eventos que compõem a lista de eventos. Portanto, no caso da nossa lista de eventos (pág.36) ainda está faltando os DFDs referentes aos eventos de 6 a 9.

Esta parte do trabalho, em que há um detalhamento dos processos é também conhecido como Modelagem Funcional, já que o aspecto principal é desenhar um modelo de como as funciona as ações existentes no sistema. Porém, neste momento, começam a existir os chamados depósitos de dados, onde os dados manipulados serão armazenados.

Existe uma necessidade de se estudar mais profundamente, como estes dados utilizados pelo sistema, deverão ser organizados. Este fato deve-se a fatores de performance na sua utilização cotidiana pelos usuários. Este aspecto do trabalho, que pode acontecer em paralelo com a modelagem funcional, chama-se Modelagem de Dados.

Usuário Gerar Cobrança

CadObras

CadEmprestimo CadUsuário

Dados- Cobrança

Carta-Cobrança

CadUsuário

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 46

6.2.2. Modelagem de Dados

Trata-se de parte do trabalho do Analista de Sistemas, cujo propósito é buscar especificar, a partir dos fatos essenciais que estejam associados ao domínio de conhecimento analisado, a perspectiva dos dados, permitindo organizá-los em estruturas bem definidas, estabelecer as regras de dependência e restrições entre eles, produzindo um modelo expresso por uma representação, ao mesmo tempo, descritiva e diagramática.

Na literatura de informática, de um modo geral, os termos “dados” e “informação” costumam ser utilizados como sinônimos, porém, trata-se de coisas distintas, cada qual com seu conceito.

Dado = Atributo + Valor

A informação é um conjunto de dados. Raramente um único dado expressa por sí só uma informação. Os dados portanto, representam a informação, algo que levará ou aumentará para alguém o conhecimento a respeito de algum assunto ou situação. Portanto, em geral, a informação é conhecimento novo.

A modelagem de dados, começa no momento em que um Analista de Sistemas define algum depósito de dados no DFD particionado por evento.

Tal fato, significa que o Analista de Sistemas, ao examinar o domínio de seu problema no mundo real, interpretou que para aquele determinado evento, haveria a necessidade de se armazenar alguma informação sobre algo. Esta interpretação do Analista é chamada de visão a nível conceitual, cuja intenção é espelhar a realidade. Deste fato decorre um processo a nível de dados conhecido por Abstração de Dados, ou seja, se tenho um usuário no sistema, devo verificar se é necessário armazenar dados sobre ele, se afirmativo, quais dados sobre ele devo armazenar ? Certamente aqueles que são relevantes para o seu sistema. Esta idéia conceitual, ainda que preliminar, sobre os dados a serem armazenados, segundo uma visão interpretada do mundo real, é a chamada abstração de dados.

6.2.2.1. O Modelo Conceitual de Dados

O valor de um modelo conceitual de dados é tanto maior quanto sua aderência à realidade do mundo que ele se propões representar.

Para a representação em forma de diagrama do modelo conceitual de dados, emprega-se o Diagrama Entidade Relacionamentos ( DER) – de Peter Pin Chan Chen.

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 47

Os quatro elementos primitivos do modelo, que representam o mundo real, são: entidades, relacionamentos, atributos e domínios.

Entidade Na modelagem de dados, a palavra entidade, refere-se aquilo que constitui a essência de uma coisa, tudo quanto existe ou pode existir. Assim, entidade é algo sobre o qual desejamos guardar dados. Uma entidade pode ser: - Um objeto real, como um livro, uma máquina, um lugar, um avião, um quarto. - Uma pessoa, como um empregado, um contribuinte, um aluno, um cidadão - Um conceito abstrato, como um curso, uma cor, uma empresa. - Um acontecimento

Relacionamentos Observa-se que as entidades pode relacionar-se entre sí. Por exemplo, dados uma entidade aluno e uma entidade curso, tem-se um relacionamento: Aluno freqüenta curso. Ou seja, os dados do aluno e os dados do curso, tem um relacionamento de onde deriva outros dados pertinentes àquelas duas entidades, por exemplo: data de inscrição do aluno no curso. Esta data não refere-se somente ao aluno, nem tão pouco ao curso, mas a ambos simultaneamente.

Atributos Dados uma entidade qualquer, como por exemplo aluno, podemos listar uma série de características relativas exclusivamente a ele. Tem-se: Nome-do-Aluno, Idade-do-Aluno, Endereço-do-Aluno, Telefone-do-Aluno. Cada campo deste é uma característica específica sobre certa entidade, a isto chamamos Atributo. Atributo mais o seu valor é um dado sobre a entidade.

Domínios Domínio é o conjunto de valores válidos para um determinado atributo. Um domínio pode ser obrigatório, identificador, referencial, simples ou composto. Por exemplo, para o atributo Sexo-Aluno, o domínio possível será { “M”, “F”}. Endereço-Aluno, certamente terá um domínio composto, ou seja, na verdade ele é uma estrutura de dados, tendo portanto outros atributos e seus domínios.

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 48

6.2.2.2. Diagrama Entidades Relacionamentos

FATAN - Faculdade de Tecnologia da Alta Noroeste

Notação do Diagrama de Entidade

Relacionamento segundo Peter P.C.

Chen

Prof. Sérgio Luiz Tonsig

Objetivo

u Documentar graficamente a relação existente entre os dados utilizados pelo sistema

u Quantificar a relação estabelecendo uma política de restrição de integridade

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 49

Componentes u Representação de uma entidade

(depósito de dados)

CLIENTE

u Uma relação entre entidades

FAZ

Visão dos Componentes

CLIENTE FAZ PEDIDOS

POSSUEM

PRODUTOS

CLIENTE FAZ PEDIDOS

PEDIDOS POSSUEM PRODUTOS

Análise e Projeto de Sistemas

Prof. Sérgio Luiz Tonsig Página: 50

Atributos u Tanto as entidades quanto os

relacionamentos, podem conter atributos (campos de dados)

CLIENTE FAZ PEDIDOS

cpf nome

endereço

cod-pedido data-emissão

cod-cond-pgto

Um Exemplo

CLIENTE FAZ PEDIDOS

POSSUEM

PRODUTOS

cpf nome

endereço

cod-pedido data-emissão

cod-cond-pgto

QtdeVr.Unit.

descrição

Unidade

Cod-Produto

Até o momento nenhum comentário
Esta é apenas uma pré-visualização
3 mostrados em 25 páginas
Baixar o documento