Você está na página 1de 52

NOME DO PROFESSOR: CLEITON FABIANO PATRICIO COORDENADOR DE ENSINO TCNICO EM INFORMATICA: - NELSON FABBRI GERBELLI

ANALISE DE PROJETOS EM SISTEMAS DE INFORMAO

Aluno ___________________________________ N ___Turma ____ Habilitao _________ 1

Para a disciplina: Analise de Projeto em Sistemas Ano: 2Modulo Curso: Tcnico em Informtica

Prof.: Cleiton Fabiano Patricio

INDICE

SISTEMAS ......................................................................................................... 4
1.1 Tipos De Sistema.............................................................................................................................4 1.1.1 Sistemas Naturais: ....................................................................................................................4 1.1.2 Sistemas Artificiais:..................................................................................................................4 1.2 Princpios Gerais Dos Sistemas .....................................................................................................5 1.2.1 Sistemas Automatizados (Sas) ................................................................................................6 1.2.2 O Sistema Empresa...................................................................................................................7 1.2.3 SISTEMAS DE INFORMAO (S.I.)....................................................................................8 1.2.3.1 TIPOS DE SISTEMAS DE INFORMAO ..........................................................................9 1.2.4 Dificuldades Na Automatizao Dos Sistemas De Informao..............................................14

2 3 4

DESENVOLVIMENTO DE SISTEMAS DE INFORMAO....................... 15 ANALISE DE SISTEMAS .......................................................................... 20 DIAGRAMA DE FLUXO DE DADOS......................................................... 23


DIRETRIZES PARA A ELABORAO DE DFD ..............................................................26

4.1.1

5 6 7
7.1

DICIONRIO DE DADOS .......................................................................... 34 ESPECIFICAO DE PROCESSO........................................................... 41 TABELAS DE DECISO ........................................................................... 49


RVORE DE DECISO .............................................................................................................52

SISTEMAS
DEFINIO: Conjunto uniforme de grupos de itens independentes em regulamentada, tendo em vista a concretizao de objetivo definidos. Ou Conjunto organizado de doutrinas, idias ou princpios, normalmente com a inteno de explicar a disposio ou um todo sistemtico. interao

1.1 Tipos De Sistema


Tendo em conta que quase tudo com que contatamos pode ser visto como um sistema, ou componente de um sistema, ou ainda ambas as coisas. Podemos classificar os diversos sistemas segundo diferentes critrios:

1.1.1

Sistemas Naturais:

So sistemas que no tem qualquer interferncia do homem para a sua criao e engloba a maioria dos sistemas. Podemos, no entanto dividi-lo em dois tipos:

Sistemas Fsicos: Sistemas astrais (Galxias, Sistema Solar), Geolgicos


(rios, cadeias montanhosas) complexa de tomos) ou sistemas moleculares (organizao

Sistemas Vivos: Plantas ou animal incluindo o ser humano. 1.1.2 Sistemas Artificiais:
So sistemas construdos, organizados e mantidos pelo Homem. Temos como exemplo:

a) Sistemas Sociais: b) Sistemas Legislativos; c) Sistemas de Transporte; d) Sistemas de Comunicao; e) Sistemas de Manufatura; f) Sistemas Financeiros; g) Sistemas de Informao.

1.2 Princpios Gerais Dos Sistemas


1 Quanto mais especializado o sistema menos capaz de se adaptar a circunstncias diferentes. 2 Quanto maior for um sistema, maior o nmero de recursos que sero destinados sua manuteno diria. 3 Os Sistemas fazem sempre parte de sistemas maiores e podem ser sempre divididos em sistemas menores.

1.2.1

Sistemas Automatizados (Sas)

So sistemas artificiais (construdos pelo homem) que interagem com computadores, ou so controlados por um ou mais computadores. Hoje em dia, muitos dos exemplos avanados sobre sistemas artificiais (SAs) incluem computadores. Na realidade, muitos s existem graas aos computadores. Todavia, salientase que tais sistema existem antes de haver computadores. Alguns dos exemplos so totalmente no computadorizados (manuais) e assim permanecero nos prximos tempos. Outros incluem componentes computadorizados e componentes manuais.

Componentes dos Sistemas Automatizados (SAs) Existem vrios tipos de sistemas automatizados, mas todos tm componentes em comum: a) b) Equipamento computacional: Hardware (CPU, Terminais, Impressoras, unidades magnticas, etc.). Suporte Lgico: Software (programas de sistemas, como sistemas operacionais, sistemas de bancos de dados e programas de controlo de telecomunicaes, alm dos programas aplicativos). Pessoas: aquelas que operam com o sistema, que fornecem as entradas e utilizam as sadas, e as que desempenham atividades de processamento manual de um sistema. Dados: as informaes que o sistema conserva por um perodo de tempo.

c)

d)

1.2.2

O Sistema Empresa

A empresa constitui um sistema. Um sistema que, por sua vez pode ser visto como um conjunto de trs subconjuntos (subsistemas) inter-relacionados entre si.

1. SISTEMAS DE DECISO: Sistemas com caractersticas homeostticas atuando por medio das variveis de controlo do sistema; no qual decorre a definio das polticas, as regras de gesto e as tomadas de deciso. Ou seja o sistema que determina os objetivo da empresa, descrevendo as suas necessidades e formando todas as medidas (polticas e aes a seguir) necessrias para que tais objetivo sejam alcanados.

2 SISTEMA DE EXECUO: Sistemas onde se desenvolvem as atividades vocacionadas ao tratamento dos acontecimentos elementares do sistema, e por onde fluem as informaes de entrada e sada deles decorrentes ou a eles associadas. Ou seja. Sistema que formula e executa os caminhos a seguir e as aes a tomar de acordo com as polticas definidas para que os objetivos previstos sejam atingidos.

NOTA: Muitas empresa ainda possuem um outro subsistema que o Sistema Financeiro - Administrativo. Este estabelece as medidas a tomar de acordo com as polticas definidas e tambm de acordo com o oramento disponvel para que os objetivos sejam atingidos.

1.2.3

SISTEMAS DE INFORMAO (S.I.)

Sistema capaz de receber, processar, memorizar e produzir informao, de modo a coloc-la disposio dos utilizadores, quando e onde necessrio.

SISTEMA DE INFORMAO

Sistema de Deciso

Sistema De Comunicao

Sistema de Execuo

Sistemas Exteriores

O fluxo de informao entre os vrios sistemas assegurado pelo Sistema de Comunicao, aqui representado como um subsistema do Sistema de Informao da Empresa.

Caractersticas dos Sistemas de Informao: 1. Fornece aos seus utilizadores, sob forma de mensagens, representaes da realidade organizacional que no podem observar diretamente. Para isso o sistema de Informao memoriza, trata e comunica os dados. (Funo essencial dos SIs) 2. Na realidade organizacional produzem-se acontecimentos que transformam tanto objetos concretos (produtos, matrias, imobilizados, pessoas, etc.), como abstratos (encomendas, facturas, processos de recrutamento, etc.). 3. Os Dados so substitutos que permitem representar os valores que tomam as propriedades das ocorrncias bem definidas de objetos. 4. Pela Combinao de Dados, podem-se descrever os objetos e represent-los. 5. Os Objectos e as suas associaes tm propriedades. S se conhecem os objectos e as suas propriedades indiretamente, por meio dos valores que tomam as propriedades

Para representar as diferentes situaes da organizao, necessrio descrever:

Os

Objetos, associaes;

quer

tomados

isoladamente,

quer

considerados

como

Os Acontecimentos que traduzem as transformaes sofridas pelos objetos,


ou as suas associaes.

1.2.3.1

II. TIPOS DE SISTEMAS DE INFORMAO

1. SISTEMAS DE ACESSO DIRECTO (ON-LINE SYSTEMS); 2. SISTEMAS EM TEMPO REAL (REAL TIME SYSTEMS); 3. SISTEMAS DE APOIO DECISO (DECISION-SUPPORT SYSTEMS); 4. SISTEMAS BASEADOS NO CONHECIMENTO (KNOWLEGE-BASED SYSTEMS).

1 SISTEMAS ON-LINE: So sistemas que recebem entradas de informao diretamente do local onde foi criada. So tambm os sistemas em que as sadas ou resultados do processamento, so dirigidas diretamente para onde sejam necessrias.

PROCESSADOR

A sada transmitida para onde for necessrio

Os dados so organizados de modo a que possam ser recuperados rapidamente

CARATERISTICAS: a) Uma caracterstica tpica de um sistema On-Line o fato de que os dados so introduzidos no sistema de processamento e dele recebido remotamente. Isto quer dizer que, os utilizadores do sistema de processamento interagem com o computador atravs de terminais que podem estar localizados a longas distncias de outros terminais e do prprio computador. b) Os dados so armazenados e podem ser recuperados (consultados) e/ou modificados rapidamente sem necessidade de aceder a outros dados do sistema. Ex.: Registro de reserva de uma passagem area. Registro individual sobre uma pessoa. 9

Sistema On-Line, interage diretamente com as pessoas por isso necessrio que o analista planeje cuidadosamente o interface Homem - Maquina. Ex.: Carto de Crdito (Planear todas as operaes perguntas e respostas e outras possiveis situaes).

2. SISTEMAS EM TEMPO REAL (REAL-TIME SYSTEMS)

Estimulo

Sistema em Tempo Real


Resposta

O AMBIENTE

Passagem do Tempo

o sistema que controla um ambiente pelo recebimento de dados, o seu processmento e apresentao dos resultados com rapidez suficiente para afectar o ambiente naquele momento. Este sistema e o sistema On-Line so muito parecidos, a diferena est no tempo de resposta ou no tempo de reaco por parte dos computadores. No caso dos Sistemas On-Line de 1 ou 2 segundos, no Sistema em Tempo-Real a reaco de milisegundos e s vezes em microsegundos s entradas de dados recebidas. Este sistema interage tanto com as pessoas como com o ambiente (Sistema Informtico), que normalmente autnomo. A preocupao do analista a rapidez com que a resposta tem que ser enviada (instantaneamente) para que o ambiente (SIs) no se descontrole e provoque perda de dados que no se podero recuperar.

Ex.:

Sistema de caixa automtica (ATM) - as caixas electrnicas que usamos


para retirar e depositar dinheiro;

Sistema de orientao de misseis - sistemas de processamento que


acompanha a trajectria de um missil e fazem continuos ajustamentos na orientao e activao dos propulsores do missil;

Sistema de comutao telefnica - sistemas de processamento que


monitoram voz e transmisso de dados entre milhares de chamadas telefonicas, detectando os ns discados, condies de no-gancho e fora-dogancho, assim como, as restantes condies de uma rede telefnica.

Sistema de monitorao de pacientes - sistemas de processamento que


monitoram os diversos sinais vitais.

10

CARACTERISTICAS: a) b) c) d) e) Muitas actividades de processamento ocorrem em simultaneo; Estabelecimento de diferentes prioridades para diferentes tarefas de processamento; Interrupo de uma tarefa de processamento antes de terminada, para que outra tarefa com alta prioridade possa ser atendida. Acesso simultaneo a dados de uso comum, tanto na memria principal como na secundaria. Uso dinmico e alocao da memoria RAM no sistema de processamento, visto no ser econmico ocupar memria fixa para manipular situaes de pico de quantidade de dados.

3. SISTEMAS DE APOIO DECISO ( DECISION-SUPPORT SYSTEM )


So sistemas de processamento que no tomam decises por si prprios, mas auxiliam gerentes e outros profissionais de uma organizao a tomarem decises inteligentes e bem informadas sobre os vrios aspectos da operao. S so utilizados quando existe necessidade. CARACTERISTICAS: a) Recuperam e apresentam dados. Executam diversas anlises matemticas e estticas sobre os dados. b) Apresentam as informaes sob varias formas grficas (tabelas, diagramas). Nota: Fornece informaes relevantes em formatos adequados para que um gerente possa tomar a deciso. Ex.: Folhas de Clculo.

IDENTIFICAR OPES ALTERNATIVAS

ESTABELECER CRITRIOS DE AVALIAO

ESCALONAR AS OPES ALTERNATIVAS CONFORME CRITRIOS

SELECCIONAR A MELHOR OPO

11

4. SISTEMAS SYSTEMS)

BASEADOS

NO

CONHECIMENTO

(KNOWLEDGE-BASED

So constitudos habitualmente para terem a capacidade de explicar as linhas de raciocnio que conduzem s suas decises. E alguns at explicam porque rejeitaram certas sugestes e escolheram outras. Desta transparncia surge a credibilidade perante utilizador. Ex.: Linhas de montagem automatizadas.

Nota: Tambm poder ser chamados por Sistemas Especializados.

III. GERAES DOS SISTEMAS DE INFORMAO AUTOMATIZADOS


1 GERAO: Identificao dos Sistemas de Informao com as aplicaes, implicando a redundncia dos dados; X X X
SI1 SIn PROGRAMAS Mensagens Mensagens PROGRAMAS

R E G I S T O S

...

R E G I S T O S

X 2 GERAO:

Existncia de ficheiros especficos para cada Sistema de Informao em conjuno com as bases de dados partilhados por vrios Sistemas de Informao;
BASE DE DADOS

X
SI1 PROGRAMAS Mensagens

X
SIn

X
Mensagens

PROGRAMAS

R E G I S T O S

...

R E G I S T O S

12

3 GERAO: Comunicao entre sistemas distintos atravs de mensagens.

BASE DE DADOS

X
SI1 PROGRAMAS Mensagens

X
SIn

X
Mensagens

PROGRAMAS

R E G I S T O S

...

R E G I S T O S

Mensagens X X

Mensagens X

BASE DE DADOS

X
SIk1 PROGRAMAS Mensagens

X
SIkn

X
Mensagens

PROGRAMAS

R E G I S T O S

...

R E G I S T O S

13

1.2.4

Dificuldades Na Automatizao Dos Sistemas De Informao


quais os Sistemas de Informao no devem ser

As razes pelas automatizados so:

1. Custo - pode ser mais barato manter o antigo sistema manual de execuo de funes e armazenamento dos dados, do que adquirir computadores que por vezes no so mais rpidos nem mais baratos que o sistema anterior. 2. Conforto - Um sistema automatizado pode ocupar demasiado espao, fazer muito rudo, gerar muito calor ou consumir eletricidade demasiada. 3. Segurana - Se o sistema de informao mantm dados importantes e confidenciais, o utilizador pode achar que o sistema automatizado no seja suficientemente seguro, preferindo manter a capacidade de guardar informaes fisicamente e fechadas chave. 4. Manuteno - O utilizador pode argumentar que o sistema computadorizado econmico, mas que no existe ningum que possa manter o Hardware e/ou o Software do computador, de forma que no haveria ningum capacitado para reparar o sistema ou efetuar modificaes ou mesmo melhoramentos no sistema. 5. Poltica - A comunidade de utilizadores pode achar que os computadores so uma ameaa aos seus empregos ou que tornam o seu trabalho mecnico. Mesmo que estas razes nos paream absurdas certo que o sistema pertence aos utilizadores e se estes no o aprovarem nem o quiserem tudo faro para que o sistema fracasse.

14

2 Desenvolvimento De Sistemas De Informao

Qualquer organizao sente necessidade de alterar os seus objetivo, aumentar, eliminar ou mesmo modificar os componentes dos sistemas que a compem. Com os Sistemas de Informao acontece o mesmo. E como uma alterao no Sistema de Informao afeta em profundidade o comportamento dos outros sectores, tem que se ter muito cuidado com o seu desenvolvimento ou mesmo com a alterao dos seus componentes. H que planificar e estruturar cuidadosamente o plano de desenvolvimento.

CICLO DE DESENVOLVIMENTO
A anlise, o projeto e a implementao de novos sistemas consiste em tomar uma srie de medidas e atitudes que em conjunto se d o nome de ciclo de desenvolvimento. Existe normalmente uma equipa especial para realizar o ciclo de desenvolvimento. Essa equipa, tem objetivo e organizao prprios e formada por membros de cada uma das partes da organizao que vo ser atingidas ou servidas pelo sistema. Nela fazem partes especialistas em anlise de sistemas, projectistas e programadores vindos do departamento de processamento de dados. Esta equipa est sujeita a uma observao peridica atravs de um grupo de executivos, que determinam a continuidade do trabalho a desenvolver, a sua interrupo, ou mesmo uma mudana nos seus objetivos. O perodo de desenvolvimento est dividido em varias etapas:

A) Analise 1. Estudo do sistema; 2. Proposta de solues; 3. Estudo de viabilidade; B) Projeto 4. Definio das necessidades funcionais; 5. Preparao das especificaes para a implementao; C) Implementao 6. Programao; 7. Instalao; 8. Converso.
Mtodos do Ciclo de Desenvolvimento As diversas etapas pelas quais o ciclo de desenvolvimento est dividido, esto sujeitas a avaliao que permitem o seguimento ou a interrupo das mesmas etapas. 15

ANALISE 1. Estudo do sistema Concentra-se na reviso e anlise das necessidades que foram previamente identificados como problemas organizacionais e que foram ainda resolvidas pelos sistemas existentes. So levantadas informaes detalhadas sobre o fluxo das informaes e sobre decises tcticas tomadas pelos sectores organizacionais causadores dos problemas identificados ou que por eles foram afetados. O objetivo isolar e entender as causas dos problemas, e como eles levam a ineficincia das operaes, perda de informao por decises tcticas tomadas pelos sectores da organizao causadores de problemas. O resultado um Relatrio de Estudo do sistema que documenta a analise executada e recomendada ou a no continuao do ciclo de desenvolvimento. Os estudos devem levar em conta os objetivo da organizao, a sua estrutura administrativa, os grupos de trabalho e os procedimentos formais e informais. 1 Passo Determinar o que deve ser feito por uma determinada rea para que possa colaborar adequadamente com a organizao para que assim como um todo, sejam atingidos os seus objetivo. 2 Passo Determinar Como feito. Deve identificar as alternativas pelas quais as mesmas coisas poderiam ser feitas e compar-las com o existente de forma a esclarecer as ineficincias e identificar as melhorias que possam ser introduzidas.

2. Proposta de Solues Estabelecer as intenes, raio de ao e custos do novo sistema a ser desenvolvido. O resultado final desta fase o documento formal chamado Proposta.

Natureza das mudanas


Define as funes a serem alteradas; descreve as novas atividades e o pessoal que utilizar o novo sistema; Compara os mtodos do sistema corrente com os do sistema proposto.

Descrio
Descreve os procedimentos operacionais propostos, tanto manuais como automticos; estabelece os objetivos a serem alcanados pelo novo sistema.

Consideraes econmicas
Identifica os custos de desenvolvimento e instalao do novo sistema, os custos estimados da operao aps a instalao e as eventuais economias conseguidas com o novo sistema

Plano de desenvolvimento
Estabelece um desenvolvimento. plano para os estgios pessoas, subseqentes de do ciclo e de de

Especifica as necessidades de gerenciamento do desenvolvimento.

programao

16

Nota: Atravs da avaliao da proposta determinado se o sistema conveniente ou no.

3. Estudo de Viabilidade A parte das consideraes econmicas da proposta alargada at aos mais pequenos detalhes. So feitas projees do movimento de caixas de retorno do investimento e outras consideraes econmicas. Os dados financeiros relevantes so analisados por especialistas de administrao para determinar o custo da implantao da proposta prevista para a organizao. E verificar tambm atravs de especialistas financeiros os benefcios que poder trazer o novo sistema.

PROJETO: 4. Definio das necessidades funcionais Produz um documento formal que contenha uma descrio mais detalhada da proposta, com os seguintes pontos: 1. Descrio detalhada das funes: Descrio de todas as principais funes a serem realizadas pelo sistema, bem como o modo pelo qual elas se relacionam entre si e com os restantes componentes da organizao.

2. Performance desejada
Nveis esperados de preciso, tempos de respostas dos terminais de computadores e limites para o tempo de processamento.

3. Entradas e Sadas desejadas


Documentos, formulrios e transies executados pelos utilizadores e as sadas a serem produzidas, incluindo detalhes dos itens de dados.

4. Ligaes com outros sistemas de processamento de dados


Interdependncias entre os diversos sistemas.

5. Disponibilidades de dados
Recurso necessrio de avaliao e reteno dos registros e dos itens de dados.

6. Volume de transaes
Estimativa do volume de transaes a serem executadas.

17

5. Preparao das Especificaes para a Implementao Aqui se produz um projeto detalhado do Sistema, especificando-se toda a informao envolvida. Os registros e os dados so descritos, incluindo-se o tamanho, tipo e valor que podem assumir individualmente, regras de validao e para as relaes com outros registros ou dados. As entradas e as sadas tm que ser especificadas de forma a determinar a disposio de cada dado em formulrios ou em listagens. Todos estes valores (validos de entrada e de sada), bem como as respostas do sistema a cada entrada possvel, so fornecidos ao utilizador. Todos os procedimentos so escritos o mais claramente possvel, com um considerado nvel de detalhe (Analise descendente TOP-DOWN), de modo a que possam ser escritos os manuais e os programas de computadores. Evitar as ambigidades e a no especificao de detalhes.

IMPLEMENTAO 6. Programao

Todos os procedimentos a serem seguidos tanto pelos operadores quanto pela mquinas tem que ser escritos. So obtidos os seguintes resultados:

a) Programas de computadores:
Os programas so escritos e testados de forma a se garantir que o Hardware aceite os dados, os processe, os armazene e que produza sadas conforme as especificaes para a implementao.

b) Procedimentos com o computador:


So produzidas instrues para a manuteno e operao dos novos programas, revistas pelo pessoal responsvel.

c) Procedimentos com o utilizador:


So produzidos e testados manuais para descrever os novos programas.

d) Cursos de Formao:
So preparados e aplicados cursos para a formao dos utilizadores do novo sistema.

e) Documentao do Sistema:
Todo o material necessrio para ajudar a perceber, usar ou modificar o novo sistema que desenvolvido e aprovado.

f) Planificao do teste:
So feitos detalhes sobre a forma de como ser testado o sistema na fase de implementao, as entradas a serem utilizadas e os resultados esperados.

18

7. Instalao Instalao funcionamento. dos equipamentos, do Software e testes exaustivos de

Nesta fase ambos os sistema ( novo e velho ) esto implantados sendo testados paralelamente, podendo-se assim verificar a eficincia do novo sistema. Se houver mal funcionamento do novo sistema revelado nos testes, h necessidade de trabalho suplementar no projeto e na correo dos programas.

8. Converso / Manuteno

Aqui d-se a passagem do sistema antigo para o novo sistema novo. desejvel que a equipa conhecedora dos dois sistemas esteja presente e acompanhe os vrios grupos de trabalho durante a transio. Dois mtodos para a converso:

Instantnea: Todos os utilizadores da empresa passam a utilizar o novo


sistema.

Incremental: Grupos isolados de utilizadores ou de funes passam a ser


gradualmente atendidos pelo novo sistema.

19

3 ANALISE DE SISTEMAS

ANALISE DE SISTEMAS: o estudo dos objetivos do sistema como um todo, dos procedimentos que o envolvem, da sua estrutura, dos fluxos de informao que estabelece o seu desempenho e as suas deficincias.

Atividades da Analise do Sistema: Uma vez compreendido como um sistema interage com os outros, o analista deve preocupar-se com o sistema em si. Identificar cada um dos seus componentes, examinando-os com cuidado de forma a levantar todos os detalhes respeitantes sua natureza, funcionamento e relao com outros componentes. Etapas necessrias:

1. Determinao dos Objetivos: Antes de qualquer anlise necessrio


estabelecer uma base para decidir o que se pretende que o sistema faa tendo em conta os objetivos de cada um dos sectores da organizao. Com estes objetivos e as relaes entre departamentos, pode-se estabelecer os objetivos do sistema como um todo.

2. Levantamento de informaes sobre os mtodos utilizados: Antes de


se tirar concluses sobre os problemas ou deficincias do sistema prexistente, deve-se compreender e documentar todos os fatos relacionados execuo dos procedimentos, manuteno das informaes e ao processo de tomada de deciso.

3. Anlise das inter-relaes: Os dados encontrados devem agora ser


organizados, analisados e comparados com os de sistemas similares, de forma a serem facilmente entendidos. Os fatores crticos para o desempenho da organizao vo ser identificados e passar a merecer toda a ateno.

4. Determinao dos dados necessrios: Determinar a melhor disposio


do fluxo de informao. Quem precisa de qual informao? Quem fornece os dados? Quem processa os dados e obtm os resultados? Fazer por qu?

5. Definio dos procedimentos necessrios: So propostas vrias


alternativas pelas quais os processos poderiam ser realizados; um ou mais cursos de ao devem ser apresentados. Ferramentas para a Anlise de Sistemas: Para se fazer uma anlise necessria se recorrer utilizao de ferramentas e tcnicas prprias, de forma a garantir a obteno de dados completos e acertados de modo a que se possa chegar a concluses corretas. Estas so as ferramentas freqentemente utilizadas:

20

1. Entrevistas: Esta a tcnica mais utilizada para a obteno de informao


sobre um sistema existente, atravs de entrevistas com os utilizadores do sistema. Deve-se tentar extrair opinies sobre as tarefas que desempenham, ou que acham que deviam desempenhar e como a desempenham.

2. Questionrio: Uma ferramenta bastante eficaz, pois pode obter informaes


sobre os detalhes da organizao, visto que os consultados permanecem annimos, o que possibilita respostas mais honestas e mais tempo para pensar nas respostas.

3. Diagramas Funcionais: Tcnica usada para identificar cada uma das partes de
um sistema. Apresenta um sistema decomposto nos seus componentes, comeando por uma descrio geral passando e por um detalhe contnuo de cada um dos subsistemas, atravs da tcnica (Top-Down). O diagrama comea por um nico bloco que identifica a funo geral do sistema. O nvel inferior seguinte subdivide a funo geral em outras menores, mas ainda no detalhadas. Apartir dai, cada nvel sucessivo subdivide cada vez mais a funo a que est ligado e o processo continua at que no haja necessidade para mais detalhe. Quando o nvel mais baixo estiver atingido, cada bloco documenta uma funo em entradas, sadas e etapas de processamento.

4. Diagramas de Fluxo de Dados: Determina o modo pelo qual a informao


manipulada, bem como as transformaes que sofre, e a documentao do fluxo de dados entre os centros de processamento e os centros de tomada de decises. Quando uma informao alterada como resultado de um processamento ou de uma deciso, diz-se que houve uma transformao. Um conjunto completo de diagramas, mostra toda a rede de informaes que toda a organizao. 5. Mapas Estruturais: Estes mostram a movimentao dos dados e o controle adequado das funes atravs das setas. As setas ligam um bloco superior aos blocos subordinados indicam o controle das funes. A seta mais longa indica um ciclo repetitivo e as setas menores mostram o fluxo dos dados de um mdulo para outro. Os crculos pequenos, em branco, indicam os dados, como o nome, endereo, nmero de pedido e data. Os crculos cheios indicam que os dados passam para o controle da informao (ex. o numero de vezes que uma operao deve ser repetida). 6. Diagramas CPM e PERT: Definem a organizao temporal das tarefas e as suas inter-relaes. Ex. para jantar, necessrio que antes este tenha sido preparado. Por outro lado aps ter jantado necessrio que sejam lavados os pratos, talheres, etc. Existem dependncias entre preparar o jantar, come-lo e limpar a loua. Podemos escrever esta dependncia pelo diagrama: Incluindo o tempo necessrio para a execuo de cada um dos passos. Os crculos (ns) Representam pontos onde as tarefas anteriores esto terminadas. PERT- um mtodo para o controle regular de todas as partes responsveis pelo trmino das tarefas, para definir ou redefinir o caminho critico necessrio.

21

7. Diagrama Entidade-Relao: Descreve em detalhes a informao que est contida nos arquivos de dados e tambm as relaes que existem entre eles. Importantes componentes: Tipos de objetos, representados por um retngulo. Uns objetos representam uma coleo, um conjunto ou coisas do mundo real que desempenham um papel no sistema. Relaes, so representados por losangos. Uma relao representa um conjunto de conexes ou associaes, entre os tipos de objetos interligados por setas s relaes. necessrio se proceder a um detalhe do DER com informaes textuais.

22

4 DIAGRAMA DE FLUXO DE DADOS

Os DFD podem ser usados no s para modelar sistemas de processamento de informaes, mas tambm como um meio de se modelar organizaes inteiras, isto como uma ferramenta para o planejamento comercial e estratgico. Vamos formular diretrizes para a construo de diagramas de fluxos de dados para que se possa minimizar possibilidade de construirmos um DFD confuso, incorretos ou inconsistentes. Vamos tambm discutir o conceito de DFDs nivelados como um mtodo de modular sistemas complexos.

COMPONENTES DE UM DFD: No necessita de explicaes; basta olharmos para ele para compreend-lo. A representao simples e sem intruses e, de certa forma, bastante intuitivo. O diagrama acomoda-se facilmente numa pgina. Isso tem dois significados. 1: Uma pessoa pode examinar o diagrama sem se confundir e, 2: o sistema que est a ser moldado no muito complexo. Que fazer se o sistema for to complexo que haver centenas de crculos e linhas no diagrama? Um diagrama desenhado por computador mais exato e mais padronizado do que se fosse desenhado mo e as alteraes podem ser feitas e novas verses podem ser produzidas em questo de minutos.

1. O Processo, O primeiro componente de um DFD conhecido como processo. O processo mostra uma parte do sistema, que transforma entradas em sadas - ou seja, mostra uma ou mais entradas que so convertidas em sadas. O Processo representado por:

Calcular Imposto sobre Renda

1. Processo O processo denominado ou descrito com uma nica palavra ou sentena simples. A designao do processo descreve o que o processo faz. Um bom nome geralmente composto por uma frase constituda de um verbo e de um objeto, tal como VALIDAR ENTRADA ou CALCULAR VALOR IMPOSTO. O processo contm o nome de uma pessoa departamento ou diviso de uma empresa), dispositivo mecnico. Ou seja, o processo s executa o processo, em vez de descrever o que ou de um grupo de pessoas (um ou de um computador ou de um vezes descreve quem ou o que o o processo .

23

2. O Fluxo,
O fluxo graficamente representado por uma seta que entra ou sai de um processo. O fluxo utilizado para mostrar o movimento de fragmentos ou pacotes de informaes de um ponto a outro do sistema, Deste modo, o fluxo representa dados em movimento, enquanto os arquivos representam dados em repouso.

2. Fluxo de dados Na maioria dos sistemas os Fluxos, representam dados, isto , bits, caracteres, mensagens, nmeros de ponto flutuante e os diversos tipos de informao com que lida o computador. Os DFDs podem tambm ser utilizados para moldar uma linha de montagem onde no haja componentes computadorizados. Nas figuras abaixo esto representados os fluxos que tm nomes. O nome representa o significado do pacote que se move no fluxo. O fluxo transporta apenas um tipo de pacote, o que indicado pelo nome do fluxo. No se deve atribuir a um fluxo de dados um nome como MAS E LARANJAS E VARIAS OUTRAS COISAS. Podemos ter no entanto um fluxo de dados denominado VEGETAIS, em vez de vrios fluxos diferentes rotulados como BATATAS, CEBOLAS e ERVILHAS.

Mistura para Bolos Ovos Leite Acar Preparar Bolo Bolo

3. Fluxos de materiais
No ser demais dizer que o mesmo contedo pode ter significados diferentes em pontos diferentes do sistema. O fragmento de dados (ex. 212 4456), tem um significado quando passa pelo fluxo com o nome de NUMERO-DE-TELEFONE e outro quando passa pelo fluxo denominado por NUMERO-DE-TELEFONE-VALIDO. No primeiro caso indica que o nmero de telefono pode ser valido ou no, enquanto que o segundo indica que o nmero de telefone valido dentro do contexto.

NUMERO-DE-TELFONE-VALIDO NUMERO-DE-TELFONE

VALIDAR NUMERO DE TELEFONE


NUMERO-DE-TELFONE-INVALIDO

4. Um DFD tpico

24

Podemos dizer que o fluxo denominado numero de telefone capaz de permitir a passagem indiscriminada de nmeros de telefone validos ou invlidos, atravs dele, enquanto que o fluxo NUMERO-DE-TELEFONE-VALIDO mais discriminativo, permitindo que passe por ele apenas um conjunto definido de dados.

3. Arquivo,
O arquivo utilizado para moldar uma coleco de pacotes de dados em repouso. A representao grfica de um arquivo um rectngulo como mostra na figura 5. O nome escolhido para o arquivo geralmente o plural dos nomes dos pacotes transportados pelos fluxos de dados para dentro e para fora do arquivo.
D1 PEDIDOS

5. Representao de Arquivo
Os arquivos so muitas vezes implementados em sistemas computadorizados; mas um arquivo pode tambm conter dados armazenados em cartes perfurados, microfilmes, microfichas, discos pticos, etc.

Arquivo existe como uma necessidade de armazenamento de espera entre dois


processos que ocorrem em momentos diferentes.

O arquivo permite que a entrada de pedidos seja feita em momentos diferentes


do processo de consulta a pedidos.
DETALHE DE PEDIDOS
CONSULTA

PEDIDO
INTRODUZIR PEDIDO

PEDIDOS

PEDIDO

RESPONDER PEDIDO

RESPOSTA

6. Um arquivo necessrio. Um arquivo apresenta-se num DFD como:

Um fluxo de um arquivo; Um fluxo para um arquivo.


Um fluxo normalmente interpretado como uma leitura ou acesso feito s informaes desse arquivo, Isto pode significar que: Fluxo de um arquivo:

Um registro isolado de dados foi recuperado do arquivo; um fluxo que sai do


arquivo envolve a recuperao do registro de informao;

Mais de um registro foi recuperado do arquivo, podem-se recuperar registros


de vrios clientes ao mesmo tempo;

Apenas parte do registro foi recuperado do arquivo. Apenas se quer o nmero


do telefone;

So recuperadas mais que uma parte de vrios registros. Clientes com o


cdigo postal x. Fluxo para um arquivo: 25

Um ou mais registros podem ser introduzidos no mesmo arquivo; Um ou mais registros podem ser eliminados ou removidos no mesmo arquivo; Um ou mais registros podem ser alterados ou modificados no mesmo arquivo,
pode ser alterado parte ou a totalidade do registro;

4. Entidades Externas (Terminadores),


Entidade Externa representada graficamente por um retngulo. Estas comunicam com o sistema. Normalmente uma pessoa ou um grupo de pessoas, uma empresa do governo, um grupo ou sector que esteja dentro da mesma organizao, mas fora do controle do sistema que est a ser moldado. Em alguns casos tambm as entidades externas podem ser outro sistema. Ex. Um sistema de processamento com o qual o nosso sistema comunica. Trs aspectos a ter em conta:

a) Elas so externas ao sistema que estamos a moldar; os fluxos que interligam as


entidades aos diversos processos do nosso sistema representam uma interface entre o mundo exterior e o sistema.

b) As entidades no podem ser alteradas nem modificadas o seu contedo ou nem


mesmo o modo de como funciona. O analista no pode modificar o contedo ou a organizao ou mesmo os procedimentos relativos s entidades externas.

c) Qualquer relacionamento existente entre as entidades externas no constar


nos DFDs. Alguns relacionamentos podem existir, mas, por definio elas no podem fazer parte do sistema que se est a investigar. Por outro lado se existirem relacionamentos entre entidades externas e se for essencial que o analista de sistemas os molde para documentar de forma corretas os requisitos do sistema, ento por definio as entidades externas devem ser moldadas como processos.

4.1.1

DIRETRIZES PARA A ELABORAO DE DFD

As diretrizes ajudam-nos a construir DFDs corretos, a desenhar DFDs agradveis vista, assim podem ser examinados pelos utilizadores com mais ateno. As diretrizes so as seguintes: 1. 2. 3. 4. 5. Escolher nomes significativos para os processos, fluxos, arquivos e entidades externas. Numerar os processos. Refazer os DFD tantas vezes quantas forem necessrias at obter uma boa esttica. Evitar DFD complexos demais. Certificar-se de que o DFD seja internamente consistente alm de manter a consistncia com os outros DFD.

26

DIRETRIZES PARA ELABORAO DE DFDs

1. ESCOLHER NOMES SIGNIFICATIVOS PARA OS PROCESSOS, FLUXOS,


ARQUIVOS E ENTIDADES EXTERNAS Um processo representa uma funo que est a ser executada ou pode indicar como a funo vai ser executada. necessrio que se rotule (dar nome) o processo para que os utilizadores sejam capazes de identificar os mesmos e que estes aprovem o modelo escolhido. de evitar nomes de pessoas de grupos ou funes polticas. Devem-se rotular os processos com as funes que o sistema executa. O melhor mtodo para o nome do processo utilizar o verbo e um objetos. Encontrar um verbo que represente a ao e uns objetos adequados de modo a formar uma frase descritiva do processo. Ex.:

Calcular Trajetria do Mssil; Produzir Relatrio de Inventario; Validar Nmero de Telefone; Designar Alunos para Salas.
Os nomes escolhidos para os processos, para os fluxos e entidades externas devem surgir de um vocabulrio usado pelo utilizador. Isto acontece naturalmente depois da srie de entrevistas feitas ao o utilizador. Devem ser tomadas duas precaues: a) Devem ser evitadas expresses tpicas dos utilizadores de modo a que o DFD possa ser lido por pessoas de sistemas diferentes. Ex.: Se for um banco, importante que os trabalhadores de outros bancos compreendam o desenho do DFD. b) Se o desenho do DFD for feito por um programador este usar expresses tais como: Rotina, Subsistema e Funo. Esta situao deve ser evitada a no ser quem for desenhar o DFD oua os utilizadores a usarem tais expresses.

2. NUMERAR PROCESSOS Mtodo mais prtico de referenciar os processos numer-los sem regra precisa desde que seja consistente no modo como se atribui os n.s. A numerao do DFD representa para o leitor uma seqncia de execuo. O que no verdade, pois o DFD uma rede de processos assncronos que se intercomunicam. Numa certa seqncia pode-se ver uma presena ou ausncia de dados (Ex.: pode ser visvel que o processo 2 no possa executar a sua funo antes de receber dados do processo 1), mas o esquema de numerao nada tem a ver com isso. 27

Os processos so numerados, para que seja mais fcil a sua identificao. Ainda mais importante, os nmeros so a base para o esquema de numerao hierrquica quando representamos diagramas de fluxo de dados nivelados.

3. EVITAR DFDs COMPLEXOS Os objetos de um DFD moldar corretamente as funes que um sistema deve executar e as iteraes entre elas. E tambm ser lido e compreendido, no somente pelo analista como pelos seus utilizadores. Isto quer dizer que um DFD deve ser compreendido e facilmente absorvido e agradvel ao olhar. No criar um DFD com demasiados processos, arquivos, fluxos e entidades externas. Isto quer dizer que no deve incluir mais de uma dzia de processos, fluxos, arquivos e entidades externas a eles relacionadas num nico DFD. Ou seja, tudo isto tem que ser acomodado confortavelmente numa folha de papel A4. A no ser que se fale nos diagramas de contexto onde esto representadas as entidades externas e um nico processo.

4. REFAZER O DFD TANTAS VEZES QUANTAS FOREM NECESSRIAS O DFD ter que ser feito, refeito e novamente refeito, at que seja: 4.1. Tecnicamente correto;

4.2. Aceitvel pelo utilizador; 4.3. To bem desenhado que no nos sentimos constrangidos ao mostr-lo a outras pessoas. O que torna o DFD esteticamente agradvel depende da opinio e gosto pessoal e, tambm de determinados padres estabelecidos pela empresa ou pelas caractersticas de algum pacote automatizado.

Problemas que podem surgir: a) Tamanho e forma dos processos: Os processos devem ter todos os mesmo tamanhos. Caso um circulo do processo seja maior que outro, pode dar a entender que o circulo maior mais importante que o menor. b) Fluxos de dados curvos versus fluxos de dados retos: Depende de uma opinio pessoal, mas convm que sejam retos e que no se verifique cruzamento entre os fluxos. c) Diagramas desenhados mo versus diagramas gerados por maquina: Dentro de poucos anos o desenho dos diagramas ser feito por sistemas de processamento grfico. No entanto hoje em dia os diagramas ainda so desenhados mo. O problema a reao do utilizador, pois alguns preferem os DFDs desenhados pela mquina pois parecem mais limpos enquanto outros preferem as figuras desenhadas mo, porque lhes d a sensao de que o desenho dos diagramas no est terminado e que podem aceitar alteraes.

28

5. Certificar-se de que o DFD seja logicamente consistente: Algumas diretrizes para um DFD consistente: a) Evitar os poos sem fundo crculos que tm entradas mas no tm sadas.

PROCESSAR CONTEDO

c)

Evitar crculos com gerao espontnea crculos que no tm entradas e s tm sadas, so geralmente incorretas. Um exemplo aceitvel seria um gerador aleatrio de nmeros.
PROCESSAR CONTEDO y b

c) Cuidado com fluxos e processos sem nome: No caso de um fluxo, pode significar que vrios elementos de dados no relacionados foram arbitrariamente reunidos. No caso de um processo, pode significar falta de ateno ou tentativa de disfarar uma situao anmala no DFD.

b) Cuidado com arquivos de leitura - apenas ou de escrita - apenas: Um arquivo deve ter sempre entradas e sadas. A exceo est apenas quando se trata de um arquivo externo.

Arquivo apenas de escrita

Arquivo apenas de Leitura

29

DFD COM NIVEIS


Para que se possa solucionar o problema de DFDs complexos, divide-se o DFD em vrios nveis, para que desta forma cada nvel inferior oferea mais detalhe sobre a parte do nvel superior. O nvel mais alto consiste num nico crculo, que representa o sistema inteiro; os fluxos de dados mostram as interfaces entre o sistema e as entidades externas. Este DFD especial conhecido como Diagrama de Contexto. O DFD imediatamente abaixo do Diagrama de Contexto conhecido como figura 0. Ele representa a viso do mais alto nvel das principais funes do sistema bem como as principais interfaces entre essas funes. Os nmeros servem para se relacionar um crculo (processo) com o DFD de nvel imediatamente inferior que descreve esse processo de um modo mais complexo. Ex.: (Fig.1)

O processo da figura 1 est associado ao DFD de nvel inferior conhecido como


figura 2. Os processos da figura 2 so numerados como 2.1, 2.2, 2.3, etc..

O processo 2.2 da figura 2 est associado ao DFD de nvel inferior conhecido


como figura 2.2. Os processos da figura 3 so numerados 3.1, 3.2, 3.3, etc..

Se o processo tiver um nome (o que deve acontecer), ento esse nome


transportado para a figura de nvel imediatamente abaixo. Assim se o processo 2.2 tiver o nome de CALCULAR TAXA DE VENDAS, ento a figura 2.2, que subdivide o processo 2.2 mais detalhadamente, deve ter o nome de Figura 2.2: CALCULAR TAXA DE VENDAS. Apesar de este modo ser bastante direto de se organizar o DFD existe outras coisas que devem ser acrescentadas a essa descrio da subdiviso em nveis: 1. Como saber quantos nveis deve ter um DFD? A figura do DFD no deve ter mais de meia dzia de processos e de arquivos a eles relacionados. Assim se j tivermos o sistema subdividido em trs nveis e no nvel mais baixo do DFD ainda tivermos 5 processos em cada um, deve ser estabelecido pelo menos mais de um nvel abaixo desse. Outra forma seria a especificao de processos. 2. Existem diretrizes sobre o nmero de nveis que devem ser esperados num sistema tpico? Um sistema simples encontra-se provavelmente dividido em trs nveis ou mesmo dois. Os nveis aumentam mediante a complexidade do sistema, sabendo que o nmero total de processos cresce exponencialmente quando passa para o nvel imediatamente inferior. 3. Todas as partes do sistema devem ser subdivididas at ao mesmo nvel de detalhe? No, pois alguma parte de um sistema podem ser mais complexas que outras e podem exigir tambm a subdiviso em mais partes ou dois nveis. No entanto no aconselhvel que haja uma disparidade muito grande de subdiviso de processos. Ex.: 30

Se o processo 2 da figura 0 do nvel mais elevado for primitiva, enquanto o processo 3 requer uma subdiviso em sete nveis, isto quer dizer que o modelo geral assimtrico e foi provavelmente mal organizado. H que transferir algumas partes do processo 3 para outro processo separado ou talvez redesenh-lo no processo 2.

O SISTEMA

DIAGRAMA DE CONTEXTO

FIGURA 0 3. 1 3. 2

Fig. 1 - DFD com nveis

3. 3

3. 4

FIGURA 3

31

4. Como se mostram esses nveis para o utilizador? Muitos utilizadores s querem ver um diagrama. Um utilizador executivo de alto nvel pode querer ver apenas o diagrama de contexto ou talvez a figura 0, enquanto que um utilizador de nvel operativo pode querer ver apenas a figura que descreve a rea do sistema em que esteja interessado. Se algum estiver interessado em ver grande parte do sistema ou o sistema inteiro, so lhe apresentados os diagramas na metodologia Top-Down: comeando pelo diagrama de contexto, descendo aos nveis de mais detalhe. prtico ter os dois diagramas lado a lado para se poder mostrar. 5. Como garantir que os nveis dos DFDs so consistentes entre si? O aspecto de consistncia muito importante porque os diversos nveis dos DFDs so normalmente desenvolvidos por pessoas diferentes nos projetos do mundo real. Para garantir a consistncia com a figura do nvel superior, existe uma regra simples: os fluxos de dados que entram e saem de uma figura inteira do nvel imediatamente superior devem corresponder aos fluxos que entram e saem de uma figura imediatamente inferior que descreve aquele processo. Exemplo explicativo na Fig. 2. 6. Como mostrar os arquivos nos diversos nveis? Existe a seguinte diretriz: mostrar um arquivo no nvel mais alto onde serve como interface entre dois ou mais processos; em seguida mostrlo em cada diagrama de nvel inferior que descreva (ou subdivida) os processos em interface. Fig. 3. Um corolrio: os arquivos locais, utilizados apenas pelos processos de uma figura de nvel inferior, no sero mostrados nos nveis superiores, porque estaro includos num processo de nvel imediatamente superior. 7. Como realmente se faz a subdiviso dos DFDs em nveis? tpico que os DFDs sejam apresentados segundo a metodologia TopDown, esta intuitiva e atraente. Mas neste caso podem existir problemas na abordagem desta metodologia, por isso melhor que se identifique primeiro os eventos externos aos quais o sistema deve reagir e usar estes eventos para criar em esboo do DFD. Podendo a subdiviso ser feita Down-Top (para os nveis mais altos) e Top-Down (para os nveis mais baixos).

32

B A
O SISTEMA

1
C x y

DIAGRAMA DE CONTEXTO

3
z

4
C

x
3. 1 3. 2

FIGURA 0

3. 3

3. 4

z
FIGURA 3

4.1.1.1.1.1.1.1 4.1.1.1.1.1.1.2 Fig. 2: Fragmento de um DFD equilibrado

A.1

B.1

A.2

B.2

Fig. 3: Exibio de arquivos nos nveis inferiores.

33

5 DICIONRIO DE DADOS
Dicionrio de dados: uma listagem organizada de todos os elementos dos dados que fazem parte do sistema, com definies precisas e rigorosas para que o utilizador e o analista de sistemas possam conhecer todas as entradas, sadas, componentes do arquivo e clculos intermdios. Os elementos dos dados so definidos da seguinte forma:

Descrever o significado dos fluxos e arquivos que aparecem nos diagramas de


fluxo de dados.

Descrever a composio dos pacotes de dados que se movimentam pelos fluxos,


ou seja, pacotes complexos (como endereo de cliente) que podem ser divididos em itens mais elementares (como cidade, cdigo de postal e pais).

Descrever a composio dos pacotes de dados nos arquivos. Especificar os valores e unidades de partes elementares da informao dos
fluxos de dados e arquivos de dados relevantes.

Descrever os detalhes dos relacionamentos entre os arquivos de um diagrama


de entidade-relacionamento.

1. A NECESSIDADE DA CONOTAO DO DICIONRIO DE DADOS


Os elementos de dados complexos so definidos em termos de elementos de dados simples, e os elementos de dados simples so definidos em termos das unidades vlidas e dos valores que eles podem assumir. Pode-se dar como exemplo um problema sobre o significado do nome de uma pessoa.

O nome ser constitudo pelo primeiro nome e o ultimo? O nome para alm do primeiro e ltimo nome dever-se- incluir um nome
intermdio?

Poder o ltimo nome ter caracteres de pontuao, exemplo DArcy? Como se poder lidar com os sufixos, que por vezes acompanham o ultimo
nome? Exemplo Duarte Silva Jr.. Deve-se considerar uma nova categoria? Nenhuma destas perguntas influenciar a maneira como as informaes sero armazenadas no computador, mas ajudam a determinar a validade do nome para fins comerciais.

34

2. CONOTAO DO DICIONRIO DE DADOS


Smbolos d conotao para o dicionrio de dados:

SIMBOLOS = + () {} [] ** @ |

DESCRIO composto de e Opcional (pode estar presente ou ausente) Iterao Escolha uma das opes alternativas Comentrio Identificador (campo chave) de um arquivo Separa opes alternativas na construo [ ]

Para exemplificar, podemos definir nome da seguinte maneira: Nome = titulo_cortesia ultimo_nome + primeiro_nome + (nome_intermdio) +

titulo_cortesia = [Sr. |Sra. |Sr.as. |Dr. | Professor] primeiro_nome = {carcter_vlido} nome_intermdio = {carcter_vlido} ultimo_nome ={carcter_vlido} carcter_vlido = [A-Z|a-z|0-9||_| |]

35

2.1. Definies
Uma definio de um elemento de dados apresentada com o smbolo =; neste contexto, o = lido como definido como, ou composto de, ou simplesmente 2significa. Ento a conotao A=B+C poderamos l-la das seguintes maneiras:

Sempre que dissermos A, queremos dizer B e C. A compe-se de B e C A definido como B e C.


Para definirmos completamente um elemento de dados, deveremos incluir o seguinte na definio:

a) O significado do elemento de dados no contexto desta aplicao do utilizador.


Normalmente apresentado e como comentrio, usando-se a conotao **.

b) A composio do elemento de dados, se ele for composto por componentes


elementares significativos.

c) Os valores que o elemento de dados poder assumir, se ele for um elemento de


dados elementar que no possa ser decomposto. Desta forma, se construir um sistema mdico que controlam pacientes, podamos definir os termos peso e altura da seguinte forma: peso = *peso do paciente ao chegar ao hospital* *unidades: quilogramas; intervalo: 1-200* altura = *altura do paciente ao chegar ao hospital* *unidades: centmetros; intervalo: 20-200*

Assim so descritas as unidades e os intervalos relevantes com caracteres * correspondentes. Para alm das unidades e os intervalos, podemos tambm precisar especificar com exatido ou a preciso com que o elemento de dados medido. Para um dado como o preo, por exemplo, importante indicar se os valores sero expressos na forma inteira, at ao ultimo centavo etc. E, algumas aplicaes de engenharia e cientficas, so importantes indicar o nmero de dgitos significativos no valor dos elementos de dados. 2.1. Elementos de dados elementares

Elementos de dados elementares so aqueles para os quais no existe decomposio significativa no contexto no ambiente do utilizador. Pode ser uma questo de interpretao e que deve explorada cuidadosamente pelo utilizador. No exemplo que vimos anteriormente sobre o nome, este poderia ser decomposto pelo ultimo-nome, primeiro-nome, nome-intermdio e titulo-cortesia. Estas decomposies noutros ambientes podem no ter qualquer significado relevante nem significativo.

36

Quando os itens dos dados elementares estiverem a ser identificados, devem ser introduzidos no dicionrio de dados e neste deve aparecer um pequeno comentrio narrativo, entre os caracteres *, descrevendo o significado do termo no contexto do utilizador. Podem no entanto surgir termos que sejam auto-explicativos. Os seguintes termos podem ser considerados como auto-explicativos: altura - atual peso - atual data - de - nascimento sexo telefone - residncia Nenhum destes termos necessita de comentrio narrativo. Podemos utilizar a conotao ** para indicar um comentrio nulo, quando o elemento autoexplicativo altura - atual = * * *unidades: centmetros; intervalo: 1 - 220* peso - atual =* * *unidades: kilos; intervalo:1-96* data - de - nascimento =** *unidades: dias desde 1, jan, 1900; intervalo: 0-36500* sexo = ** *valores: [M|F]*

37

2.3. Elementos de dados opcionais Este pode estar ou no presente como um componente de um elemento de dados composto.

Um nome de cliente poder ou no incluir o nome intermdio O endereo de cliente pode ou no incluir alguma informao secundria como o
nmero do apartamento.

Um pedido de cliente pode ou no conter um endereo de cobrana, endereo


para remessas ou ambos. Situao como a ultima referida devem ser conferidas cuidadosamente com o utilizador e cuidadosamente documentadas no dicionrio de dados. Por exemplo: Endereo_cliente = (endereo_de_remessa) + (endereo_de_cobrana) Significa, que o endereo do cliente pode ser constitudo por:

apenas o endereo de remessas;


ou

apenas o endereo de cobrana;


ou

o endereo de remessas e o endereo de cobrana;


ou ainda,

nenhum dos endereos.


Esta ltima possibilidade muito duvidosa, visto ser bastante provvel que o utilizador queira alguma referncia de endereo do cliente escolhendo assim uma das restantes possibilidades. Resultado: Endereo_de_cliente = [endereo_de_remessas | endereo_de_cobrana endereo_de_carga + endereo_de cobrana] Por fim podemos constatar que sempre necessrio o endereo de remessa para onde deve ser enviado o pedido do cliente e o endereo de cobrana separado que pode ser opcional (ex. departamento de contabilidade). Endereo_de_cliente = endereo_de_remessas + (endereo_de_cobrana) necessrio que se explique as implicaes das diferentes notaes mostradas. 2.4. Iterao

Esta notao usada para indicar a ocorrncia repetida de um componente de um elemento de dados. Ela lida como zero ou mais ocorrncias de. A notao : pedido = nome_do_cliente + endereo_de_remessa + {item} Nota: item = produto a pedir Isto significa que um pedido deve conter sempre o nome do cliente e o endereo de remessa (entrega), e conter, tambm zero ou mais ocorrncias de um item. Desta 38

forma podemos lidar com um cliente que apresente um pedido que envolva apenas um ou mais produtos. Na realidade o utilizador pode querer especificar o limite inferior e superior da iterao. Pois no faz sentido que um cliente faa um pedido de zero produtos, devendo ento haver pelo menos um produto no pedido. O utilizador pode tambm querer especificar um limite superior de produtos num pedido; talvez 10 produtos sejam o mximo permitido. Podemos indicar o limite inferior e superior da seguinte forma: pedido = nome_de_cliente + endereo_de_remessa + 1{item}10 { }

Pode-se especificar tambm somente o limite superior ou s o limite inferior, ou ambos, ou nenhum. Exemplos: a = 1{b} { } a = {b}10 } a = 1{b}10 { } a = {b} }

39

2.5. Seleo
Esta notao indica que o elemento de dados consiste em exactamente uma escolha de um conjunto de opes alternativas. As operaes so limitadas pelos parntesis rectos ( e ) e separadas pelo caracter de barra vertical |. Exemplo: sexo = [Masculino | Feminino] tipo - de - cliente = [Governo | Industria | Comercio | Particular | Outro ] importante rever todas as opes com o utilizador para que nenhuma tenha sido esquecida.

2.6. Sinnimos
um nome alternativo para um elemento de dados. uma situao comum quando se lida com um grupo diversificado de utilizadores, muitas vezes de departamentos diferentes que insistem em dar nomes diferentes para indicar a mesma coisa. O sinnimo includo no dicionrio de dados s por uma questo de completar a informao, e deve ter uma referncia com o nome principal ou oficial do dado. Exemplo: cliente = *sinnimo de cliente* Nesta no existe definio do cliente e no mostra a sua composio. Todos os detalhes devem ser fornecidos somente no nome principal. No entanto deve-se evitar o uso de sinnimos sempre que possvel.

3. APRESENTAO DO DICIONRIO DE DADOS AO UTILIZADOR


O utilizador deve ser capaz de ler e compreender o dicionrio de dados para conferir o modelo, ajudando na correo do mesmo, s assim poder verificar se est completo, consistente e sem contradies.

4. A IMPLEMENTAO DO DICIONRIO DE DADOS


Dada a existncia de centenas de entradas de dados, necessrio que se possa fazer uma abordagem.

40

6 ESPECIFICAO DE PROCESSO
A especificao de processos define o que deve ser feito para transformar entradas em sadas. uma descrio detalhada da orientao empresarial executada pelos processos. Existem diversas ferramentas que podemos utilizar para produzir uma especificao de processos: Tabelas de deciso, Linguagem estruturada, condies pr/ps, Fluxogramas e outras. A especificao de processos deve satisfazer dois requisitos essenciais: 1. A especificao de processos deve ser expressa de uma forma que possa ser verificada pelo utilizador e pelo analista de sistemas. por essa razo que se evita a linguagem comum como ferramenta de especificao, ela ambgua, principalmente quando se descreve as aces (decises) alternativas e repetitivas (laos/ciclos). Tende a causar grande confuso ao expressar condies booleanas compostas (condies dos operadores booleanos AND, OR e NOT). 2. A especificao de processos deve ser expressa de uma forma que possa ser efetivamente comunicada s diversas audincias pretendidas (Utilizadores, gerentes, auditores, controladores de qualidade, etc.). Para elaborao das especificaes devem ser usadas uma combinao de ferramentas de especificao, dependendo:

a) da preferncia do utilizador; b) das suas prprias preferncias; c) da natureza dos diversos projetos.
Deve no entanto possuir uma terceira caracterstica: No deve impor (ou implicar) decises arbitrrias de projetos e de implementao. Isto no entanto bastante difcil, porque o utilizador, de quem se depende para estabelecer a poltica seguida em cada processo no DFD, est disposto a descrever a orientao como ela executada. O analista deve escolher a melhor apresentao da essncia do que seja a orientao e no como ela executada. Segundo o exemplo: Desenvolver uma especificao para o processo com o nome CALCULAR FACTOR HIPOTTICO. Depois de entrevistado o utilizador, descobre-se que o clculo de fatores hipotticos para qualquer entrada de X : 1. O fator no calculado de uma forma simples. Temos que comear por uma suposio. O utilizador disse que gosta muito dos 14 como suposies inicial. 2. Em seguida, faz-se outra suposio. Divide-se comeamos, pela suposio corrente. o nmero X com que

3. Toma-se o resultado desse clculo e subtrairmos a suposies correntes. 4. Toma-se o resultado da alnea 3 e dividimo-lo por 2. Essa uma nova suposio.

41

5. Se a nova suposio e a suposio corrente esto muito prximas uma da outra, dentro de o intervalo 0,0001, pode parar, a nova suposio o fator hipottico. Caso contrrio volta alnea 2 e comea tudo novamente. Desta forma pode-se argumentar que esta especificao de processo bastante difcil de ser lida e compreendida, porque est escrita em linguagem narrativa. A definio seguinte muito mais esclarecedora (pois so usadas as barras verticais | na clausula UNTIL (ENQUANTO) que significam o valor absoluto da expresso entre elas. Factor_hipo0 = 14 REPITA para N = 0 em saltos de 1 Fator-hipoN+1 = (Fator_hipoN - (X/Fator_hipoN))/2 AT | Fator-hipoN+1 Fator_hipoN | < 0,0001 Ou N=0 Factor_hipo0 = 14 ENQUANTO |Fator_hipoN+1 Fator_hipoN| < 0,0001 FAZER Fator_hipoN+1 = (Fator_hipoN - (X/Fator_hipoN))/2 N incrementa 1 FIM FAZER

CALCULAR FATOR HIPOTETICO

Factor_hipo(X)

Calcular Fator_Hipottico

As especificaes de processos s so desenvolvidas para processos do nvel mais baixo dos DFD com nveis. Como se pode verificar na figura abaixo, todos os processos de um determinado nvel inferior seguinte. Ou seja, a especificao de processos para um processo de um nvel o DFD de um nvel imediatamente inferior.

42

Existem trs principais ferramentas de especificao de processo: 1. Linguagem Estruturada (Portugus Estruturado). 2. Tabelas de Deciso. 3. Arvores de Deciso. 1. PORTUGUS ESTRUTURADO

Definio: uma linguagem de especificao, que usa um vocabulrio limitado e uma sintaxe limitada. O vocabulrio consiste em:

Verbos na lngua portuguesa; Termos definidos no Dicionrio de Dados; Algumas palavras reservadas para formulao lgica.
A Sintaxe de uma afirmao em Portugus Estruturado est limitada pelas seguintes estruturas de controlo: Seqencial; Repetio; Deciso.

Os verbos podem ser escolhidos segundo esta lista: LER ou ACEDER (GET - ACCEPT ou READ) ESCERVER (PUT - SEARCH - LOCATE) ADICIONAR (ADD) SUBTRAIR (SUBTRACT) MULTIPLICAR (MULTIPLY) DIVIDIR (DIVIDE) COMPUTAR (COMPUTE) APAGAR (DELETE) LOCATIZAR (FIND) VALIDAR (VALIDATE) MOVER (MOVE) SUBSTITUIR (REPLACE) COLOCAR (SET) ESCOLHER (SORT).

43

Os objetos devem ser compostos apenas por elementos de dados que tenham sido definidos no Dicionrio de Dados ou em termos locais. Termos locais so palavras explicitamente definidas na especificao de um processo individual. Elas s so conhecidas, relevantes e significativas nessa especificao de processo. Ex.: Calculo intermdio de uma operao. Examina uma srie de registros no arquivo Pedidos para calcular um total dirio.

Total_Dirio = 0 ENQUANTO existirem mais pedidos em Pedidos como data_fatura = Data_hoje FAZER ESCREVER em Contab. Numero_fatura, nome cliente, total_geral Total_dirio = total_dirio + total_geral FIMFAZER ESCERVER em Contab. Total_dirio

CONSTRUO DAS ESTRUTURAS DE CONTROLE:

1. SE - ENTO - SENO(IF-THEN-ELSE) A estrutura SE - ENTO - SENO (IF-THEN-ELSE), utilizada para descrever aes alternativas que devem ser executadas de acordo com o resultado de uma condio (verdadeira - Falsa )

SE < condio > ENTO < ao > FIMSE ou SE < condio > ENTO < aco1 > SENO < aco2 > FIMSE

Ex.: SE idade_cliente maior que 65 ENTO COLOCAR categoria_cobrana em categoria_snior SENO COLOCAR categoria_cobrana em categoria_normal FIMSE

44

2. CASO (CASE) A estrutura CASO (CASE) utilizada para descrever aes alternativas a serem executadas com base no resultado de uma condio com vrios valores (diferente da condio binria que ocorre na estrutura SE-ENTO). A estrutura CASO assume a forma geral:

FAZER CASO CASO < condio 1 = valor 1> < ao 1 > CASO < condio n = valor n> < ao n > CASOCONTRARIO < ao n+1> FIMCASO

Ex.: 1 FAZER CASO CASO idade_cliente < 13 COLOCAR categoria_cobrana em categoria_infantil CASO idade_cliente > 12 e idade_cliente < 20 COLOCAR categoria_cobrana em categoria_adulto CASO idade_cliente >19 e idade_cliente <65 COLOCAR categoria_cobrana em categoria_adulto CASOCONTRARIO COLOCAR categoria_cobrana em categoria_snior FIMCASO 2 FAZER CASO CASO Pais = GB COLOCAR Taxa_Vendas CASO Pais = FRN COLOCAR Taxa_Vendas CASO pais = ESP COLOCAR Taxa_Vendas CASOCONTRARIO COLOCAR Taxa_Vendas FIMCASO

em 0.0825 em 0.07 em 0.05 em 0

45

3. ENQUANTO - FAZER ( DO - WHILE ou WHILE - DO ) A estrutura ENQUANTO - FAZER ( DO - WHILE ou WHILE - DO descrever uma ao que deve ser executada repetidamente determinada condio booleana seja Falsa. O teste condio execuo da 1 ao; assim sendo, se a condio no for satisfeita executada. Procedendo-se ao termino da condio. ) usada para at que uma feito antes da a condio no

ENQUANTO < condio > FAZER < ao 1 > FIMFAZER Ex.: ENQUANTO houver mais itens no pedido do cliente FAZER preo = preo_unit * quant_item FIMFAZER

4. REPETIR AT (REPEAT UNTIL) Outra estrutura de controlo de repetio REPETIR - AT que repete uma condio enquanto esta for Falsa e termina quando for Verdadeira. A condio e executado pelo menos uma vez mesmo pois o teste feito no final das aes terem sido executadas. REPETIR < ao 1 > < ao 2 >

< ao n > AT < condio > CONSTRUO DE ESTRUTURAS COMPOSTAS Para a construo de estruturas compostas a partir de combinaes estruturais simples, acima apresentadas, existem algumas regras:

1. Uma estrutura linear de aes simples equivalente a uma estrutura seqencial.


< ao 1 > < ao 2 >

< ao n > equivalente a uma estrutura condicional (1) ou de repetio (2): (1) SE < condio > ENTO < ao 1 > < ao 2 > 46

< ao SENO < ao < ao < ao FIMSE (2)

m> a> b> n>

ENQUANTO < condio > FAZER < ao 1 > < ao 2 > < ao n > FIM FAZER

2. Uma estrutura SE - ENTO - SENO permite que sejam encadeadas dentro de


outras estruturas SE - ENTO - SENO, ou dentro de estruturas ENQUANTO FAZER ou CASO. Ex.: SE < condio 1 > ENTO < ao 1 > SE < condio 2 > ENTO < ao 2 > < ao 3 > SENTO < ao 4 > < ao 5 > FIMSE < ao 6 > SENO SE < condio 3 > ENTO < ao 7 > FIMSE FIMSE

3. As estruturas de controlo de repetio ENQUANTO - FAZER, pode ser


encadeado dentro de outras estruturas ENQUANTO - FAZER ou mesmo dentro da estrutura CASO. Ex.: Total_geral = 0 ENQUANTO houver pedidos a serem processados FAZER Total_faturas = 0 LER prximo pedido em PEDIDOS ENQUANTO houver itens no pedido FAZER Total_faturas = total_faturas + valor_item FIMFAZER ESCERVER numero_fatura, total_fatura Total_geral = total_faturas + total_faturas FIMFAZER ESCREVER total_geral 47

4. A estrutura CASO pode estar encadeada dentro de outras estruturas CASO, ou


dentro de estruturas SE - ENTO - SENO ou mesmo dentro das estruturas ENQUANTO - FAZER.

RESUMO: Como se viu, possvel se construir estruturas de controlo bastante complexam. No entanto h que ter muita ateno com essa complexidade, pois pode servir como desvantagem caso o utilizador no a conseguir compreender nem mesmo fazer a sua verificao e correo. Nesse caso tudo o projeto ser um fracasso, deste modo devem ser evitadas as seguintes trs diretrizes: 1. Restringir a linguagem de estrutura a uma s pgina de texto. Se for necessrio utilizar mais que uma pgina, deve-se ento tentar alterar para algoritmos mais simples. Seno quer dizer que o DFD correspondente muito complexo, deverse- subdividi-lo em processos mais simples de nvel mais baixo. 2. No usar mais de trs nveis de encadeamento das estruturas de controlo (SE ENTO - SENO ou CASO). Principalmente se for a estrutura SE - SENO SENO, mais que dois nveis de encadeamento representa a necessidade da especificao de uma tabela de decises. 3. Evitar confuses relativamente aos encadeamentos recorrendo-se identificao, como foi visto nos exemplos anteriores. Desta forma torna-se mais fcil a sua visualizao e a sua correo.

48

7 TABELAS DE DECISO
Definio: uma ferramenta que distingue e especifica um conjunto de n aes, em que apenas uma delas aplicada a cada uma das condies dadas. Esta ferramenta usada em situaes em que deve produzir alguma sada ou executar aces com base em condies (decises) complexas. Se as aces forem baseadas em diversas variveis (por Ex.: elemento de dados de entrada), e se essas variveis poderem assumir muitos valores diferentes, ento a lgica expressa pela linguagem estruturada poder ser provavelmente to complexa que o utilizador no a compreender. Numa TABELA DE DECISO esto relacionadas todas as variveis relevantes ou condies e todas as aes relevantes, estas encontram-se posicionadas no lado esquerdo da Tabela de Deciso. Nas colunas do lado direito esto descritas as normas (regras). Uma norma descreve a ao ou aes que devem ser tomadas para uma especfica combinao de valores de variveis. Deve pelo menos ser especificada uma aco para cada norma, isto , para cada coluna vertical na Tabela de Deciso, ou o comportamento do sistema para aquela situao no ser especificada. O nmero de normas existente na Tabela de Deciso depende das condies existentes na mesma. Como escolher o nmero de normas existentes na Tabela de Deciso:

1. Se as variveis dependentes, tiverem n valores binrios (Falso/Verdadeiro), ento teremos 2n normas distintas. Ex.: Se tivermos 3 condies ento teremos 23 normas que equivale a 8 normas. 2. Se as variveis de condio tiverem valores associados ento o nmero de normas ser igual multiplicao do nmero dos valores associados das vrias variveis de condio. Ex.: Se tivermos trs variveis de condio e se duas delas tiverem dois valores associados e a outra trs, ento teremos 2*2*3 normas, ou seja, teremos12 normas.

Regra: O nmero de normas necessrias para completar uma Tabela de Deciso igual ao produto entre os nmeros de valores para todas as variveis de condio.

49

Etapas para a criao de uma Tabela de Deciso para uma especificao de processos:

1. Identificar todas as condies ou variveis na especificao. Identificar todos os valores que cada varivel pode assumir. 2. Calcular o nmero de normas (combinao de condies) existentes na especificao. 3. Identificar cada aco possvel na especificao. 4. Criar uma Tabela de Deciso vazia, relacionando todas as condies e aes no lado esquerdo e numerando as combinaes de condies no topo da tabela. 5. Relacionar todas as combinaes de condies, para cada coluna vertical da tabela. 6. Examinar cada norma (coluna vertical) e identificar as aes adequadas a serem tomadas a cabo. 7. Identificar todas as omisses, contradies e ambigidades da especificao. Ex.: Normas da Tabela de Deciso para as quais a especificao no indica que aes devem ser tomadas. 8. Discutir as omisses, contradies e ambigidades com o utilizador.

Exemplo de uma Tabela de Deciso:


Dadas as seguintes variveis de condio

Variveis de Condio

Valores Associados Sim S No N Masculino M Feminino F Sim S No - N

Idade > 21

Sexo

Peso > 150

Nota: Todas as Variveis de Condio so binrias, pois admitem como valores associados apenas dois. Pode-se verificar que na seguinte Tabela de Deciso teremos trs condies cujas variveis so de tipo binrio (Sim/No), neste caso n igual a 3. Calculo do nmero de normas: 2
3

=8

, normas = 8.

50

1 Idade > 21 Sexo Peso Medicao 1 Medicao 2 Medicao 3 Nenhuma Medicao S M S X

2 S M N

3 S F S

4 S F N

5 N M S X

6 N M N

7 N F S

8 N F N X

X X X

X X X X

51

7.1 RVORE DE DECISO


Definio: a representao grfica de uma Tabela de Deciso.

Esta ferramenta usada quando o utilizador no conseguir compreender a Tabela de Deciso. Esta por vezes mais facilmente compreendida pelo utilizador, pois uma estrutura que lhe parece mais familiar. Nela esto representadas as condies e as aes existentes na especificao, e tambm o modo como elas se relacionam. Exatamente como nas Tabelas de Deciso. Vejamos ento um exemplo: rvore de Deciso sobre o exemplo representado no Ponto anterior (Tabelas de Decises).

Idade > 21

Sexo

Peso > 150

Medicao

S M S F N S M N F N N S N S PROGRAMA DE MEDICAO

2 3

N 1,2

3 N 1,3

52