apontamentos de análise de...

Apontamentos de Análise

de Sistemas

A presente compilação tem como objectivo ser um auxiliar de estudo para os alunos, possuindo a

informação necessária para o apoio à realização do módulo de Análise de Sistemas

Apontamentos de Análise de Sistemas

Página 2 de 20

Índice

1. Introdução ................................................................................................................................................................... 3 2. Análise de Sistemas ................................................................................................................................................ 3

2.1. Modelo ..................................................................................................................................................................... 3 2.2. Identificação de utilizadores e necessidades ............................................................................................ 3 2.3. Especificação de requisitos .............................................................................................................................. 4

2.3.1. Requisitos do Utilizador ........................................................................................................................... 4 2.3.2. Requisitos Técnicos ................................................................................................................................... 5 2.3.3. Requisitos Organizacionais ..................................................................................................................... 5

3. Desenvolvimento de Sistemas de Informação .............................................................................................. 5 3.1. Técnicas de Análise Estruturada .................................................................................................................... 5

4. Modelação ................................................................................................................................................................... 6 4.1. Ferramentas de Modelação .............................................................................................................................. 7

4.1.1. Diagrama de Fluxo de Dados (DFD) ................................................................................................... 8 4.1.2. Diagrama Emtidade-Relação (DER) .................................................................................................. 12


Página 3 de 20

1. Introdução

Análise de Sistemas é uma técnica de resolução de problemas que decompõe um sistema nos seus

componentes de forma a perceber como estes trabalham e interagem para atingir o seu propósito.

Já a Análise de Sistemas de Informação (SI) é definida como a fase de desenvolvimento, num

projecto que se focaliza numa primeira fase no problema do negócio, independentemente da

tecnologia que possa ou vá ser usada para implementar a solução desse problema.

2. Análise de Sistemas

Pode ser entendida como o processo de classificar e interpretar factos de forma a identificar

problemas, utilizando a informação recolhida para recomendar melhorias no sistema ou suportar o

desenvolvimento de um novo sistema. A análise de sistemas obriga, em primeiro lugar, ao estudo

dos requisitos de informação e dos utilizadores finais. Mas uma percepção adequada das

necessidades das organizações requer igualmente o estudo das actividades, dos recursos e dos SI

existentes de modo a identificar o que é ou não pertinente para as organizações.

2.1. Modelo

Um modelo é uma abstracção, uma representação habitualmente gráfica, de uma determinada

realidade ou visão, temos que um modelo lógico mostra o que o sistema é ou faz, sendo

independente da implementação, enquanto um modelo físico mostra não só o que o sistema é ou

faz, mas também como o sistema é física e tecnicamente implementado.

Figura 1 - Modelo Lógico e Físico

2.2. Identificação de utilizadores e necessidades

Qualquer processo de análise de SI tem como inicio a caracterização de sector de actividade onde a

organização se insere e posteriormente a caracterização da organização e das suas actividades. Com

o propósito de identificar utilizadores e necessidades, deve ser verificado se os objectivos do SI se

encontram alinhados com os da organização, facto que poderá tornar necessária a redefinição de

tarefas específicas.


Página 4 de 20

O envolvimento dos potenciais utilizadores, no processo de análise do sistema, torna-se importante

para assegurar que o sistema resolve apropriadamente os seus problemas e aumentam as

probabilidades de ser implementado com sucesso.

2.3. Especificação de requisitos

A especificação de requisitos inicia-se quando se reconhece um problema que necessita de solução

ou quando surge a ideia de um novo SI, terminando quando se obtêm a descrição completa do

comportamento do sistema a ser modificado ou construído.

Convém, todavia, ter em consideração que os problemas não podem ser resolvidos apenas com o

recurso a um caminho puramente tecnológico, sendo necessário ter em conta o contexto social, pois

esta actividade envolve pessoas com valores individuais próprios e personalidades distintas, assim

como com objectivos diferentes.

A identificação de requisitos torna crucial uma escolha adequada e criteriosa dos processos de recolha

de factos, sendo identificados como mais comuns os seguintes:

Entrevistas (visam reunir informação proveniente de pessoas ou grupos);

Questionários (complementam a entrevista e envolvem questões de facto e questões de opinião);

Estudo de documentação existente;

Observação (a apreciação directa das actividades realizadas em determinada área da organização

permite obter informação sobre a forma como estas decorrem, como se utilizam os documentos e

como se executam os processos).

A especificação de requisitos parece ser a actividade mais crítica do desenvolvimento de sistemas,

logo, também será a actividade mais crítica da análise de sistemas. Isto acontece, em grande parte,

devido a ser nessa actividade que se define o tipo de suporte que os SI devem proporcionar às

actividades organizacionais, considerando as suas necessidades e objectivos.

Pode assim constatar-se que uma incorrecta definição de requisitos conduzirá à disponibilização de SI

inadequados às actividades organizacionais, podendo até comprometer os seus objectivos e afectar o

normal funcionamento das actividades de negócio.

Nesse sentido, atendendo à diversidade de situações a contemplar, a especificação de requisitos

envolverá obrigatoriamente a determinação de requisitos do utilizador, de requisitos técnicos e de

requisitos organizacionais.

2.3.1. Requisitos do Utilizador

Com os requisitos do utilizador (obtidos essencialmente através de questionários e entrevistas)

pretende-se obter as características funcionais do sistema, identificar os processos de recolha,

tratamento e disponibilização de dados, quais os processos que devem ser automatizados e

caracterizar os requisitos de entrada e de saída do sistema.


Página 5 de 20

2.3.2. Requisitos Técnicos

Relativamente aos requisitos técnicos, procura-se identificar quais são os equipamentos de suporte do

sistema, que aplicações vão ser utilizadas, quem as vai utilizar e em que circunstâncias, assim como

qual o sistema de comunicação de dados a utilizar.

2.3.3. Requisitos Organizacionais

Já no que diz respeito aos requisitos organizacionais (obtidos essencialmente através da análise da

documentação da organização e de entrevistas com os seus responsáveis), pretende-se identificar o

que é necessário para que o SI se adeqúe à estratégia da organização, assim como proporcionar um

suporte adequado às suas actividades.

3. Desenvolvimento de Sistemas de Informação

Destacam-se essencialmente três métodos de desenvolvimento de sistemas de informação, a saber:

Método do Ciclo de Vida de Desenvolvimento de Sistemas;

Método de Desenvolvimento da Análise Estruturada;

Método da Prototipagem de Sistemas.

Nota: no presente módulo apenas abordaremos o método da Análise estruturada.

3.1. Técnicas de Análise Estruturada

As técnicas de Análise Estruturada, de que os Diagramas de Fluxo de Dados (DFD) constituem a

principal referência, e o desenho estruturado, tornaram-se o Standard da indústria para a descrição

de Sistemas de Informação (SI).

A análise estruturada é uma técnica centrada nos processos, utilizada para estudar um sistema

existente, ou definir requisitos de negócio para um novo sistema. Estes modelos são figuras que

ilustram as peças componentes do sistema: processos, entidades e saídas associadas, e também

ficheiros.

A análise estruturada deverá conduzir a melhorias, para tal é essencial que sejam seguidas algumas

etapas capazes potenciar a obtenção dessas melhorias, de entre essas etapas destacam-se:

Desenvolver um conhecimento profundo dos requisitos futuros da organização;

Conhecer os detalhes do sistema existente, assim como os procedimentos actualmente em uso;

Recomendar qualquer melhoria ou revisão necessária ao sistema actual;

Documentar as características do novo sistema com um nível de detalhe que permita a todos os

intervenientes o seu entendimento;

Envolver gestores e utilizadores.


Página 6 de 20

De entre a diversidade possível de componentes a análise estruturada utiliza habitualmente os

seguintes:

Símbolos gráficos - ícones e convenções para identificar e descrever os componentes de um sistema

e as relações entre esses componentes;

Dicionário de dados - Descrição de todos os dados utilizados no sistema, podendo ser manual ou

automatizado;

Procedimentos e descrições dos processos - Declarações formais utilizando técnicas e linguagens

que permitem aos analistas descreverem as actividades relevantes que constituem o sistema;

Regras - Standards para descrever e documentar correcta e completamente o sistema.

Para cumprir a diversidade de aspectos considerados relevantes, no contexto da análise estruturada,

deve notar-se que os analistas necessitam de responder a algumas questões específicas, de entre as

quais se destacam:

Quais os processos que compõem o sistema?

Que dados são usados em cada processo?

Que dados são armazenados?

Que dados entram e saem do sistema?

As principais questões que surgem colocam claramente a ênfase na análise dos dados que fluem no

sistema, não esquecendo no entanto os processos cruciais na utilização desses mesmos dados.

4. Modelação

Enquanto a modelação de processos é uma técnica para organização e documentação da estrutura e

fluxo de dados através dos processos do sistema, a modelação de dados é uma técnica para organização

e documentação dos dados de um sistema.

A modelação de processos envolve a representação gráfica de funções ou processos que capturam,

manipulam, armazenam e distribuem dados entre os sistemas e o seu ambiente e entre os

componentes no sistema, enquanto a modelação de dados procura captar toda a estrutura dos dados

organizacionais, independentemente de qualquer Sistema de Gestão de Base de Dados ou outras

considerações de implementação.

O modelo de dados explica o que a organização faz e que regras determinam a forma como o trabalho

é feito na organização, não sendo necessário saber como e quando os dados são processados ou como

são utilizados para modelação.

Neste tipo de modelação utilizam-se habitualmente duas perspectivas distintas: top-down e bottom-

up.


Página 7 de 20

A perspectiva top-down corresponde a uma metodologia genérica de Planeamento de Sistemas de

Informação (PSI) que procura obter um entendimento alargado das necessidades do SI de toda a

organização. Esta aproximação inicia-se com a condução de uma análise externa da estratégia,

missão e objectivos organizacionais e determinação dos requisitos de informação necessários para

atingir cada objectivo, chegando às regras de negócio, para um determinado modelo de dados,

partindo de um entendimento o mais completo possível do negócio (aplica-se no Diagrama Entidade-

Relação - DER).

A perspectiva bottom-up corresponde a uma metodologia genérica de PSI que identifica e define os

projectos de Desenvolvimento de Sistemas de Informação (DSI), baseados na resolução dos

problemas operacionais de negócio ou que tira vantagem de algumas oportunidades de negócio. Esta

aproximação pode ser mais rápida e barata de desenvolver do que a outra, tendo a vantagem de

identificar problemas organizacionais importantes, sendo feita com recurso à recolha de informação

para modelação através da revisão de documentos de negócio (aplica-se no DFD). Todavia, falha por

vezes na visão das necessidades informacionais de toda a organização.

4.1. Ferramentas de Modelação

A aplicabilidade de ferramentas de modelação deriva da necessidade de focalizar os diferentes

aspectos do sistema, tendo em conta as características funcionais, as estruturas de dados e

considerações temporais.

Atendendo à aplicabilidade das ferramentas em que se suporta a análise estruturada, opta-se pela

abordagem proposta por Yourdon para apresentar os fundamentos da análise estruturada,

particularmente por ter sido o precursor da análise de sistemas, definindo um conjunto de

ferramentas que ainda hoje são utilizadas.

A aplicabilidade de ferramentas de modelação deriva da necessidade de focalizar os diferentes

aspectos do sistema, tendo em conta as características funcionais, as estruturas de dados e

considerações temporais.

Segundo Yourdon, como principais ferramentas gráficas de modelação, em termos de análise

estruturada, identificam-se:

Diagrama de Fluxo de Dados (DFD) - Identifica as funções que o sistema deve desempenhar.

Diagrama Entidade-Relação (DER) - Coloca a ênfase nos dados e no seu

relacionamento.

Diagrama de Transição de Estados (DTE) - Tem em conta o comportamento do sistema em

função do tempo.


Página 8 de 20

Como ferramentas de modelação, baseadas essencialmente na descrição textual, que complementam

as anteriormente identificadas, de acordo com Yourdon, referenciam-se:

Dicionário de Dados (DD) - Ferramenta de modelação textual que permite descrever, de forma

precisa, o significado de cada componente e as ligações que existem nos modelos de representação

gráfica.

Especificação de Processos (EP) - Ferramenta de modelação textual que permite definir o que

deve ser feito para transformar entradas em saídas.

Note-se todavia, que nem sempre existe a necessidade de fazer uso da totalidade ou parte destas

ferramentas, mas poderá ser útil a sua utilização conjunta em função de necessidades específicas, uma

vez que se complementam.

4.1.1. Diagrama de Fluxo de Dados (DFD)

Diagrama de Fluxo de Dados (DFD) – é uma representação em rede de um sistema. O sistema

pode ser automatizado, manual ou misto. O Diagrama de Fluxo de Dados retracta o sistema em

termos das suas componentes.

O Diagrama de Fluxo de Dados:

Representa o fluxo de dados num sistema de informação, assim como as sucessivas

transformações que estes sofrem;

Mostra, para o sistema em estudo, as funções e como são armazenados e transferidos os dados;

É uma ferramenta gráfica que transcreve, de forma não técnica, a lógica do procedimento do

sistema em estudo.

Características dos Diagramas de Fluxos de Dados:

Mostra a essência lógica do sistema em estudo;

Não é um diagrama técnico – permite ser facilmente entendido por pessoas que não sabem

nada de computadores;

Para ser construído tem que se definir a área do sistema em estudo - tudo o que estiver fora

dessa área não pertence ao sistema a desenvolver;

Informação temporal não é representada;

Fluxos de controlo não são representados.

O diagrama de fluxo de dados é uma das ferramentas de modelagem do sistema mais utilizada,

devido à facilidade da linguagem e às poucas alternativas da simbologia. Estes factores tornam-no

numa ferramenta fácil de utilizar, de elaborar, de ser lida e compreendida.


Página 9 de 20

O DFD abrange quatro elementos gráficos: os processos, o fluxo de dados, os arquivos e a entidade

de origem/destino.

Processo

Descrição – O processo mostra uma

parte do sistema que transforma entradas

em saídas isto é, mostra como uma ou

mais entradas são convertidas em saídas. O nome do processo deve ser único e é constituído por

um verbo e um substantivo e deve figurar dentro do círculo, descrevendo o que este faz. A

adequada atribuição dos nomes é muito importante, uma vez que tem que reflectir, de uma forma

clara, a actividade que o processo engloba. A identificação normalmente é um número, em ordem

crescente, colocado no meio da parte superior; esse número possui a função de identificar o

processo no momento em que ele ocorre. Além disso, um mesmo processo pode ser desdobrado em

vários (novos números serão incluídos).

Fluxo de Dados

Descrição – Um fluxo é graficamente representado por uma seta que entra ou sai de um processo

e é utilizado para mostrar o movimento de pacotes de informação de um ponto a outro do sistema.

Deste modo, o fluxo representa dados em

movimento. Cada fluxo de dados tem de ter um

nome apropriado e o mais preciso possível.

Arquivos / Banco de Dados

Descrição – Cada arquivo possui um nome

exclusivo que se encontra no plural. O arquivo

contém um conjunto de informações que pode

ser acedido e/ou actualizado por um processo.

As operações que se podem fazer com um arquivo estão representadas em baixo:

A origem e o destino mostram,

respectivamente, de onde o

dado requerido pelo sistema

vem e para onde o dado

produzido pelo sistema vai. Uma

origem é um provedor de fluxo

de dados para o sistema, e o destino é um recebedor de fluxo de dados do sistema.


Página 10 de 20

Entidade de Origem / Destino

Descrição – São frequentemente categorias lógicas de coisas ou pessoas que representam a origem

ou o destino para as transacções. A identificação e definição das entidades externas definirá as

fronteiras ou limites do sistema.

A forma com estes quatro elementos podem/ou não estar ligados tem que respeitar determinadas

regras que são aqui esquematizados:

Relacionamento Entidades Processos Arquivos

Entidades Não Sim Não

Processos Sim Sim Sim

Arquivos Não Sim Não

Directrizes para a elaboração do DFD

1. Escolher nomes significativos para os processos, fluxos, arquivos e entidades externas.

2. Numerar os processos.

3. Refazer o DFD tantas vezes quantas forem necessárias até obter uma boa estética.

4. Evitar DFDs complexos demais.

5. Certificar-se de que o DFD seja internamente consistente.

6. Convenções de expansão

Escrever nomes significativos

Deve ser evitado o uso de nomes de pessoas, grupos e de funções políticas, mas rotular os

processos de modo a identificar as funções que o sistema executa.


Página 11 de 20

Numerar processos

Método prático de referenciar os processos. O esquema de numeração, pode não implicar uma

determinada sequência de execução, porque o DFD é uma rede de processos assíncronos que se

intercomunicam, dando uma representação do modo como funciona a maioria dos sistemas.

Refazer o DFD tantas vezes quantas necessárias:

Um projecto de análise de sistemas, para que esteja tecnicamente correcto, aceitável pelo utilizador

e tão bem desenhado que seja perceptível por todos, terá de ser feito, refeito e novamente refeito,

por dez ou mais vezes.

Evitar DFD complexos

Deve-se modelar as funções que o sistema executa e as interacções entre elas, de modo a que ao

ser lido seja compreendido, não só pelo analista que o elaborou mas também pelos utilizadores.

Deve-se modelar em níveis, para que cada nível ofereça sucessivamente mais detalhes.

Consistência do DFD

Além do relacionamento com outros modelos do sistema, existem algumas directrizes consideradas

principais:

Evitar os processos que tenham entradas mas que não tenham saída.

Evitar processos que tenham saídas, mas que não tenham entradas.

Identificar as componentes estáticas

Entidades Externas

Identificar os principais depósitos de dados

Identificar os principais Processos e Fluxos de Dados

Identificar os fluxos que partem das fontes e convergem para as entidades, e ainda os principais

processos que surgem nesses percursos.

Rotular os Fluxos:

o Garantir que cada Fluxo é rotulado

o Garantir que o nome do Fluxo se refere a todos os dados transportados pelo mesmo

o Evitar nomes vagos

Convenções de expansão

Um Processo de nível superior pode ser expandido em novos processos de nível inferior.

Exemplo: 2 --------> 2.1 e 2.2


Página 12 de 20

4.1.2. Diagrama Emtidade-Relação (DER)

Diagrama de entidade-relação - é uma representação lógica detalhada dos dados de uma

organização ou de uma determinada área de negócio. O Modelo Entidade-Relação (MER) expressa-

se em termos de entidades, das relações entre essas entidades e dos atributos (ou propriedades)

das entidades e das suas relações.

Entidades

Uma entidade representa um conjunto de objectos do mundo real, cujos componentes elementares

(exemplares ou instâncias), possuem as seguintes características:

A identificação tem de ser feita de uma única forma (modo de diferenciar as instâncias

individuais do tipo de entidade);

Cada entidade desempenha um papel no sistema (o funcionamento do sistema depende do

acesso aos componentes desse tipo de entidade);

Pode ser descrita por um ou mais elementos de dados (os atributos aplicam-se a cada instância

do tipo de entidade).

Figura 2 - Notação de Entidade

Figura 3 - Exemplos de Entidades DER

Relações

As entidades são interligadas por relações. Cada instância da relação representa uma associação

entre zero ou mais ocorrências de uma entidade e zero ou mais ocorrências de outra entidade (uma

relação pode ligar duas ou mais instâncias do mesmo objecto).

Uma relação pode ser descrita do ponto de vista de qualquer um dos tipos de entidades

participantes, sendo válidos todos esses pontos de vista.

Figura 4 – Notação de Relação


Página 13 de 20

Deve, no entanto, ter-se em atenção que a atribuição do nome da relação apenas deve ser feita para

um único ponto de vista e nunca para os dois em simultâneo. Os exemplos da figura seguinte

apresentam três pontos de vista distintos: no caso (b) a leitura é 'gestor atribui descontos', enquanto

no caso (c) a leitura é 'descontos são atribuídos pelo gestor', já no caso (a) a leitura será 'cliente

efectua pedidos'.

Figura 5 - Exemplos de Relações

Atributos

Os atributos são o conjunto das características dos objectos, descrevendo ocorrências de uma

entidade, ou seja, são as características comuns a todas as instâncias de uma entidade.

Figura 6 – Notação de Atributo

Figura 7 - Exemplos de Atributos

Identificadores

Um identificador é um atributo (ou combinação de atributos) que identifica univocamente (são

chaves) uma ocorrência de uma determinada entidade. Os nomes dos identificadores são sublinhados.

Figura 8 – Notação de Identificador


Página 14 de 20

Figura 9 - Exemplos de Identificadores

A uma entidade está associado o conceito de arquivo de dados, relacionando-se com um qualquer item

de uma organização, acerca do qual existe um conjunto de dados inter-relacionados (pode ser uma

pessoa, um evento, um objecto).

Os atributos associam o conceito de campo de dados, as ocorrências associam o conceito de registo e o

identificador associa o conceito de chave.

Cardinalidade

A cardinalidade (grau de associação - número de objectos que participam numa relação) pode ser

obrigatória ou opcional.

Figura 10 – Notação de Cardinalidade

Figura 11 - Exemplos de Cardinalidade

Associação

Uma associação entre duas entidades pode ser caracterizada de três formas distintas:

Figura 12 – Notação de Associação entre Entidades

Figura 13 - Exemplos de Associação entre Entidades


Página 15 de 20

Caracterização e Regras de utilização

O primeiro DER construído estará certamente longe da versão final pois, tal como acontece com os

Diagramas de Fluxos de Dados (DFD) ou outras ferramentas de modelação de sistemas, torna-se

necessário proceder à sua revisão e ao consequente aperfeiçoamento tantas vezes quantas forem

necessárias.

Deste modo, para a construção de um DER dever-se-á ter em conta o seguinte:

Identificar as entidades e as suas relações;

Atribuir cardinalidades e a participação nas relações;

Definir os atributos das entidades e os atributos identificadores;

Refinar o modelo construído.

Construção e Refinação dos DER

Na construção de um DER verifica-se que os três primeiros passos identificados correspondem à

construção do modelo conceptual dos dados.

Deve no entanto notar-se que o DER obtido inicialmente no processo de análise poderá não coincidir com

o que se vier a obter no final das actividades, em particular pela necessidade frequente de propiciar a

sua adequação aos requisitos da organização e dos utilizadores.

Figura 14 - Exemplos de DER


Página 16 de 20

A propósito do exemplo apresentado, deve de se atender à relação m:n, estabelecida entre as

entidades "Produtos" e "Pedidos", o que torna necessário proceder à refinação da parte do

diagrama onde isso se verifica.

A refinação do modelo, segundo Yourdon, corresponde a um conjunto de regras que a seguir se

identificam:

Desfazer relações n : m;

Evitar que o sistema a modelizar surja como uma entidade;

Evitar que o modelo fique fechado;

Garantir que os atributos expressam conceitos simples;

Evitar as relações complexas (que envolvem mais de duas entidades, mais de um conceito).

Figura 15 – Refinação da relação m:n do DER

A figura 15 apresenta o DER da figura 14 já refinado, desaparecendo a relação n:m existente entre

as entidades "Pedidos" e "Produtos".


Página 17 de 20

4.1.3. Dicionário de Dados (DD)

O Dicionário de Dados (DD) constitui uma listagem organizada dos elementos de dados que são

considerados pertinentes para o sistema.

Elementos de dados

A listagem dos elementos de dados suporta-se em definições precisas e rigorosas de modo a que, quer

os utilizadores, quer os analistas, possam conhecer entradas, saídas, armazéns e processos do

sistema.

Com esse objectivo o DD define os elementos de dados das seguintes formas:

Descrição do significado dos fluxos de dados e dos armazéns de dados dos Diagramas de Fluxos de

Dados (DFD);

Descrição da composição dos pacotes de dados (dividindo-os em dados elementares) que circulam

nos fluxos dos DFD;

Descrição da composição dos pacotes de dados nos armazéns de dados;

Especificação os valores e unidades relevantes de partes elementares de informação nos fluxos de

dados e nos armazéns de dados;

Descrição dos detalhes dos relacionamentos entre os armazéns realçados num Diagrama Entidade-

Relação (DER).

Caracterização e Regras de utilização

A figura 16 especifica a notação que, de entre as muitas existentes e passíveis de ser utilizadas, vai ser

aplicada no suporte dos exemplos apresentados neste documento.

= É composto de

+ E

[ ] Escolha de uma das opções

( ) Opcional

| Separador de opções na construção [ ]

{ } Iteração

@ Identificador (campo chave) de um armazém

* * Comentário

Figura 16 – Notação para DD


Página 18 de 20

Uma definição de elemento de dados é representada pelo símbolo =. Uma definição completa

incluirá:

O significado do elemento de dados no contexto do utilizador (apresentando-se como um

comentário, utilizando para isso a notação * *);

A composição de elemento de dados (se for constituído por componentes elementares

significativos);

Os valores que o elemento de dados poderá assumir (se já não for passível de decomposição).

nome = primeiro_nome +último_nome

morada = rua + numero + localidade

Figura 17 - Exemplos de Definição

Elementos de dados singulares são aqueles para os quais não existe decomposição significativa no

contexto do ambiente do utilizador.

Um elemento de dados opcional ( ) é o que pode estar ou não presente como componente de um

elemento de dados composto.

nome = primeiro_nome + ( nome_do_meio ) + último_nome

codigo_postal = código + (localidade )

Figura 18 - Exemplos de Opção

A notação de selecção | significa que o elemento de dados consiste na escolha de uma das opções

(delimitadas por [ ]) disponíveis.

estado_civil = [ solteiro | casado | viúvo | divorciado ]

tipo_de_cliente - [ empresa | particular | especial ]

Figura 19 - Exemplos de Selecção

A notação de iteração { }• surge para indicar a ocorrência repetida de um componente de um elemento

de dados.

data_de_nascimento = 1 { dia } 31 + { mês } 12 + { ano }

montante_de_crédito = 20 { valor } 1000

Figura 20 - Exemplos de Iteração

A notação de comentário * * surge para referenciar aspectos relevantes que possam não estar

especificados de outro modo.

A notação de identificador @ surge para marcar um elemento chave que permite referenciar, de uma

forma inequívoca, um conjunto de elementos de dados relacionados.

@código_produto = * utilizar 3 letras e 6 números *

@num_BI =

Figura 21 - Exemplos de Identificador e Comentário


Página 19 de 20

Construção do Dicionário de Dados

O DD é criado pelo analista durante o processo de desenvolvimento do modelo do sistema, de modo a

que o utilizador seja capaz de o compreender para conferir o modelo.

Algumas das regras para a construção de DD são:

Identificar no diagrama de contexto as entidades externas e os dados que emitem ou recebem

relativamente ao sistema.

Associar, nos outros níveis, processos aos fluxos de dados que entram ou saem do sistema.

Construir um processo sempre que exista uma alteração num fluxo de dados.

Seguir os fluxos de dados enviados/recebidos, associando-lhes processos que tratam esses dados.

Identificar/construir os depósitos de dados que o sistema modifica, cria ou utiliza em instantes

diferentes.

@numCliente = *utiíizar quatro dígitos*

nomeCliente = primeiroNome + últimoNome

tipoCliente = [Empresa|Particular]

endereçoCiiente = rua + numPorta + locaíidade + (codPostal)

@numPedido = "utilizar seis dígitos*

numCliente =

dataPedido = 1{dia}31 + 1{mes}12 + 2003{ano}

codDesconto = [A|B|C|D]

contactoVendedor = telefone + (email)

'preferencialmente deve registar-se o telernóvel*

@codDesconto = *utilizar código com letras e números*

descriçãoDesconto = *texto com o máximo de 20 caracteres*

numPedido =

numProduto =

quantPedido = *números inteiros*

@numProduto = *uti!izar nove dígitos*

preçoProduto = *valores em euros*

descriçãoProduto = *texto com o máximo de 50 caracteres*

Figura 7 - Exemplo de Dicionário de Dados (parcial)


Página 20 de 20

Validação do Dicionário de Dados

Não sendo prático proceder a uma leitura extensiva do DD, a sua exactidão é verificada em

combinação com o DFD, com o DER, com o Diagrama de Transição de Estados (DTE) ou com as

especificações de processos.

Em termos práticos o que se procura é que o DD esteja completo, consistente e sem contradições.

A implementação do DD é feita habitualmente com o recurso a meios automatizados que facilitam

a tarefa de introdução de centenas e mesmo milhares de entradas em sistemas relativamente

simples, sendo por isso essencial compreender o processo básico em que se suporta a sua

definição, evitando-se dessa forma repetir as entradas.

apontamentos de análise de...

Documents