processo de análise estruturada - abordagem clássica teóricos/as... · análise estruturada 23...

Análise Estruturada 21

Processo de análise estruturada - Abordagem clássica

Desenvolvermodelo lógico

actual

Modelo físico actual

Desenvolvermodelo físico

actual

Desenvolvermodelo lógico

novo

Modelo lógico actual

Desenvolvermodelo físico

novo

Modelo lógico novo

Modelo físico novo

Modelos a desenvolver tendo em conta a

abordagem clássica

Modelo físico ⇒ (Actualmente) Modelo de implementação

Modelo do sistema que o utilizador usa no momento. Pode ser um sistema

manual, automatizado ou uma mistura de ambos.

Aspectos mais comuns de detalhes de implementação:

• Sequenciação de actividades:

• Dados temporários, redundantes ou deriváveis;

• Validações de dados e processos

Modelo lógico ⇒ (Actualmente) Modelo essencial

Modelo dos requisitos puros ou essenciais do sistema, ou seja, sem detalhes

de implementação.


A abordagem clássica baseia-se nos seguintes pressupostos:

• O analista de sistemas pode não conhecer aspectos da área da aplicação,

sendo a elaboração dos modelos, físico e lógico, do sistema actual um meio

de aprendizagem;

• O utilizador tem dificuldade em analisar o modelo abstracto do sistema,

servindo a modelação do sistema físico actual, simultaneamente, como um

mecanismo de introdução do processo de análise estruturada e como uma

garantia, para o utilizador, de que analista está a modelar o sistema

correctamente;

• A transformação do modelo lógico actual no novo modelo lógico, não requer

grande esforço, nem trabalho desperdiçado, quando o utilizador só quer

acrescentar novas funções ou dados, a um sistema que já existe,

permanecendo a maior parte do sistema intacto.

Motivos de insucesso da abordagem clássica

Os pressupostos da abordagem clássica podem ser correctos em alguns casos,

mas, na maior parte dos casos representam:

• grande dispêndio de tempo e esforço quando analista especifica todos os

aspectos;

• desperdício de tempo e esforço pois grande percentagem do modelo físico

será deixado de lado na sua transição para modelo lógico actual, devido a

redundância, e aspectos relacionados com validações que não fazem parte do

modelo lógico;

• uma influência negativa quando diminui a tendência de colocar em causa

determinados procedimentos, possivelmente, menos adequados ou

desactualizados.


Processo de análise estruturada - Modelo essencial

O modelo essencial é o modelo do que o sistema tem de fazer, de forma a

satisfazer os requisitos do utilizador, com o mínimo possível de informação

sobre como o sistema deve ser implementado.

O modelo essencial descreve:

• Política essencial ou lógica das actividades que têm de ser executadas;

• Conteúdo essencial dos dados armazenados e que circulam pelo sistema;

• Comportamento dependente do tempo essencial que o sistema possui para

tratar sinais e interrupções do ambiente.

O modelo essencial é constituído por:

• Modelo ambiental

• Modelo comportamental

Modelos Ferramentas utilizadas

Ambiental Declaração de propósito

Diagrama de Contexto (DC)

Lista de Eventos

Comportamental Diagrama Entidade Relacionamento (DER)

Diagrama de Fluxo de Dados (DFD)

Diagrama de transição de estados (DTE)

Dicionário de dados (DD)

Especificação de Processos


Modelo ambiental

O modelo ambiental define:

• Limites essenciais do sistema

Determinação do que faz parte do sistema, definindo fronteiras entre o

sistema e o ambiente.

• Interfaces entre o sistema e o ambiente

Determinação da informação proveniente do exterior e da informação que

o sistema tem de produzir e enviar para exterior.

• Eventos externos

Identificação dos eventos, ou estímulos, que ocorrem no ambiente, aos

quais, o sistema tem de responder.

Exemplo considerado

Pretende-se uma aplicação para automatizar os serviços prestados por uma

biblioteca, tendo em conta os seguintes aspectos:

Um utente, no acto de inscrição, preenche uma ficha de leitor, que

obrigatoriamente contém o nome, morada, BI, telefone e profissão.

O leitor escolhe os livros que pretende consultar, podendo levá-los por um prazo

a definir pela administração da biblioteca, mediante o registo do respectivo

empréstimo. Caso o livro não seja entregue no prazo devido, o utente será

sancionado com uma multa. Um empréstimo não é concedido se o leitor possui

multas por pagar ou livros que excederam o prazo de entrega.

Devem ser implementadas pesquisas de títulos, autores e de disponibilidade de

um livro.

A decisão de aquisição de livros baseia-se num relatório, produzido

mensalmente, dos empréstimos concedidos aos utentes. Os livros adquiridos são

registados depois de catalogados.


Declaração de propósito do sistema

Consiste numa descrição textual breve da razão de ser do sistema. É uma

primeira tentativa de diferenciação entre o que está dentro e o que está fora do

sistema.

Características de uma declaração de propósito:

• deve ser curta, de preferência uma única frase longa;

• deve fornecer uma visão muito geral do sistema, permanecendo ao

mesmo tempo tão específica quanto possível (não deve incluir

generalizações verdadeiras para todos os sistemas);

• deve ser completa;

• alguns analistas consideram que deve apresentar o resumo dos benefícios

quantificáveis visados com o novo sistema. Em projectos de elevada

dimensão será preferível apresentar uma análise de custos benefícios

separadamente.

Exemplos de declaração de propósito:

• O propósito do sistema GB é manter e disponibilizar informação sobre

livros e leitores, controlar empréstimos e produzir relatórios de

empréstimos.

• O propósito da GSP é manter a informação necessária para a gestão de um

stock de produtos, o que incluí controlo de stocks, processamento de

encomendas e registo de movimentos.


Diagrama de contexto

Os principais aspectos que este diagrama especifica são:

• As pessoas, organizações, ou sistemas com os quais o sistema comunica

(terminadores);

• Os dados que o sistema recebe do ambiente e que têm de ser processados

(fluxos de dados de entrada)

• Os dados produzidos pelo sistema e enviados para o ambiente (fluxos de

dados de saída);

• As fronteiras entre o sistema e o resto do universo.

Um diagrama de contexto é constituído por terminadores, fluxos de dados, um

só processo que representa todo o sistema, podendo ainda conter, fluxos de

controlo e depósitos de dados externos.

Exemplo: Gestão de bibliotecas (simplificado)

ADMINISTRAÇÃO

Ficha_leitor

Diálogo_pesquisa_autor

UTENTEPagamento_multa

Diálogo_pesquisa_disp

Diálogo_pesquisa_título

Diálogo_empréstimo

Livros_a_entregar

EDITORA

Lista_livros_adquiridosRelatório

Gestão de Bibliotecas

Multa


Lista de eventos

Consiste na lista narrativa dos estímulos que ocorrem no exterior, aos quais o

sistema tem de responder. Esta lista determina o propósito para o

comportamento do sistema e dá uma perspectiva do sistema diferente da do

diagrama de contexto. Os eventos devem ser descritos sob o ponto de vista do

ambiente, ou seja, por exemplo, é preferível usar “Cliente envia pedido” em vez

de “Chegada de pedido do cliente”.

Os eventos podem ser classificados da seguinte forma:

• Evento orientado por fluxo (F);

• Evento temporal (T);

• Evento de controlo (C).

Evento orientado por fluxo (F)

É um evento associado a um fluxo de dados. O sistema é notificado da

ocorrência do evento pela chegada de um conjunto de dados. Um evento

orientado por fluxo corresponde a uma das entradas do diagrama de contexto.

Contudo, nem todos os fluxos de dados de um diagrama de contexto

correspondem a eventos, pois existem fluxos que são requeridos pelo sistema

para que este possa processar um evento.

Exemplos:

Cliente efectua encomenda (F)

Cliente cancela encomenda (F)


Eventos temporais(T)

Os eventos temporais são desencadeados pela passagem do tempo por um dado

instante. Não existem fluxos associados a este tipo de evento. Supõe-se que o

sistema possui um relógio interno que determina passagem do tempo. Apesar

destes eventos não terem fluxos associados, podem desencadear um pedido de

informação a terminadores, pedidos estes que não representam eventos.

Exemplos:

Administração requer relatório de vendas(T)

Clientes recebem facturas (T)

Eventos de Controlo(C)

Podem ser considerados como casos especiais de eventos temporais que

ocorrem num ponto do tempo imprevisível. Um evento deste tipo não pode ser

antecipado pela passagem do tempo, nem detectado pela chegada de

informação. Este tipo de evento pode ser considerado como um fluxo de dados

binário e está associado a um fluxo de controlo. Conforme já foi referido, os

fluxos de controlo são uma extensão utilizada na modelação de sistemas em

tempo real.

Exemplo:

Temperatura de frigorifico sobe para Xº (C)

Componentes adicionais de um modelo ambiental

A natureza e complexidade de um sistema pode ditar a utilização adicional de:

• Dicionário de dados inicial que descreve fluxos e depósitos externos;

• Diagrama de entidade relacionamento dos depósitos de dados externos.


Elaborar diagrama de contexto antes ou depois da lista de

eventos?

A primeira versão do diagrama de contexto não é pré-requisito para construir a

lista de eventos e pode ser desenhada numa etapa separada ou à medida que se

identificam os eventos.

Na maior parte dos casos, é mais fácil elaborar primeiro o diagrama de contexto,

tendo em conta a descrição do utilizador das respostas que espera do sistema e

das entradas que têm de ser fornecidas para produzir as respostas.

Contudo, pode não ser fácil identificar terminadores e fluxos de entrada e saída

do sistema. Neste caso, o ponto de partida poderá consistir na elaboração do

DER, que mostra objectos e seus relacionamentos. A partir da observação das

actividades ou operações que causam criação ou remoção de instâncias é então

possível identificar eventos candidatos. A criação da lista de eventos permite

assim levar ao desenvolvimento do diagrama de contexto.

Aspectos a ter em conta na elaboração da lista de eventos:

• Cada fluxo do diagrama de contexto é necessário para que sistema detecte a

ocorrência do evento, ou, corresponde a uma necessidade de informação do

sistema;

• Cada fluxo de saída deve ser uma resposta a um evento;

• Cada evento não temporal deve corresponder a uma entrada, a partir da qual o

sistema detecta a sua ocorrência;

• Cada evento deve produzir uma actividade imediata de resposta, ou deve

gerar armazenamento de informação a utilizar posteriormente, ou deve causar

uma alteração de estado do sistema;


• Quando se identifica uma resposta em vez de um evento, é necessário

retroceder para determinar qual o evento que causa a resposta. Um candidato

a evento é detectado pelo facto de o sistema não ter de responder.

Exemplo:

Candidato a evento = Calcular valor da acção

Evento real = Accionista requer uma posição de conta

• A lista de eventos, que causam a reacção do sistema, é mais fácil de obter se

também se consideram as respectivas respostas.

Exemplo lista de eventos para exemplo de gestão de stocks:

• Produção envia requisição de produtos (F)

• Fornecedor envia guia de remessa de produtos (F)

• Produção envia dados de novos produtos (F)

• Fornecedores recebem (mensalmente) encomendas (T)

Exemplo de lista de eventos para exemplo de gestão de bibliotecas:

• Utente inscreve-se como leitor (F)

• Utente solicita empréstimo de livros (F)

• Utente entrega livros (F)

• Utente paga multas (F)

• Utente pede informação por autor de livros (F)

• Utente pede informação por título de livros (F)

• Utente pede informação de disponibilidade de livro (F)

• Administração requer relatório (mensal) de empréstimos (T)

• Editora envia livros novos (F)


Modelo comportamental

Consiste na modelação do comportamento interno do sistema, de forma a que

este responda com sucesso ao ambiente. O desenvolvimento deste modelo

contempla a elaboração do DFD, DER, DTE, DD, e especificação de processos.

Abordagem clássica

Consiste numa abordagem top-down, sendo constituída pelas seguintes etapas:

1. Construção do diagrama de contexto;

2. Construção de um DFD de nível elevado, denominado por Diagrama 0,

que envolve:

• identificação das principais componentes do sistema;

• elaboração do diagrama 0 onde os processos representam os principais

subsistemas;

3. Elaboração de DFD´s de nível inferior, que contempla:

• decomposição sucessiva de cada processo num diagrama de nível

inferior, até se obter processos atómicos que não requerem mais

divisões;

4. Elaboração do DD e especificação de processos.

Dificuldades encontradas na utilização desta abordagem:

• Paralisia na análise

Na maior parte dos sistemas complexos, não existe nenhuma indicação que

guie o analista no desenho de um diagrama 0 apropriado, a partir do

diagrama de contexto. Assim sendo, a construção do diagrama 0 tem um

“arranque” demorado e este diagrama é alterado, várias vezes, ao longo do

processo.


• Dificuldade na divisão de trabalho

O desenvolvimento de sistemas complexos é, normalmente, elaborado por

equipas com vários analistas. A necessidade de divisão do trabalho pelos

vários analistas pode gerar partições forçadas do sistema.

• Partição física arbitrária

Em muitos casos um sistema baseia-se noutro sistema já existente, ou na

informatização de partes de uma organização. A estrutura do sistema

existente, ou da organização, é usada frequentemente como um critério de

determinação dos subsistemas do novo sistema. Contudo, essa partição

pode não ser a melhor partição do ponto de vista funcional.

Abordagem Middle-Out

A abordagem proposta não é uma abordagem top-down pura, nem é uma

abordagem bottom-up pura. Esta abordagem parte de um DFD inicial

intermédio e estabelece que é necessário agrupar processos num nível superior e

decompor processos em níveis de detalhe inferiores. Na abordagem middle-out

o desenvolvimento do modelo comportamental efectua-se em duas etapas:

• Desenvolvimento de modelo comportamental preliminar

Envolve o desenvolvimento do DFD e do DER preliminares e a elaboração

inicial das entradas no DD.

• Finalização do modelo comportamental

Organização e refinamento do modelo comportamental preliminar com

vista à obtenção do modelo comportamental final.

Envolve a criação de DFD com vários níveis de detalhe, finalização do

DER, finalização do DD, finalização do DTE e especificação de processos.


Construção de modelo comportamental preliminar

Estratégia para desenvolver a versão inicial de modelo comportamental, com

o objectivo de criar uma versão inicial que sirva como base na construção da

versão final do modelo comportamental.

Identificar respostas do sistema a eventos:

• criar um processo para cada evento da lista;

• numerar os processos utilizando a numeração da lista de eventos;

• dar um nome ao processo que descreva a resposta que o sistema deve

produzir na reacção ao evento;

• ligar fluxos de entrada, necessários para que sistema possa produzir a

resposta, e fluxos de saída que o sistema gera; As saídas e entradas podem

consistir em fluxos para terminadores, ou em fluxos para depósitos de

dados;

• desenhar depósitos a que o sistema tem de aceder e que permitem a

comunicação entre processos;

• verificar se o DFD preliminar está completo e consistente, em relação ao

diagrama de contexto e à lista de eventos. Verificar, ainda, se cada entrada

do DC está associada a uma entrada de um processo no DFD e verificar se

cada saída produzida por um processo é enviada para depósitos de dados

ou é uma das saídas existentes no DC.


Casos especiais:

• um evento que causa múltiplas respostas

Cada resposta é modelada por um processo e o fluxo, que representa o

evento, diverge para cada um dos processos. Isto é apropriado se todas as

respostas usam o mesmo fluxo de entrada e somente se todas as respostas

forem independentes, ou seja, nenhuma parte de uma das respostas é

necessária como entrada para produzir outra resposta.

• múltiplos eventos que causam a mesma resposta

criar um só processo se a resposta é idêntica para os vários eventos e se os

dados de entrada e de saída forem idênticos para as vários respostas aos

eventos.

Ligação entre respostas de eventos

Os processos comunicam através de depósitos, pois os processos criados são

respostas a eventos e os eventos são assíncronos.

Desenvolvimento do modelo de dados inicial

Criar a versão inicial de DER, a partir dos depósitos definidos no DFD

preliminar. Actualizar DFD preliminar em função de DER.

Alternativamente, esta etapa pode decorrer antes ou mesmo em paralelo com

o desenvolvimento do DFD.


DFD preliminar do exemplo de gestão de bibliotecas

Evento 1 - Utente inscreve-se como leitor (F)

1Registardados de

leitor

Utente

Leitor

Ficha_leitor

Evento 2 - Utente solicita empréstimo de livros (F)

Empréstimo

2Verificare registar

empréstimo

LeitorDiálogo_empréstimo

Multa

Utente

Livro

Evento 3 - Utente entrega livros (F)

3Registar

entrega deempréstimo

Empréstimo

Livro

Livros_a_entregar

Multa

UtenteMulta


Evento 4 - Utente paga multas (F)

4Registar

pagamentode multas

Utente MultaPagamento_multa

Evento 5 - Utente pede informação por autor de livros (F)

Autor_livro

5PesquisarLivros por

autor


Autor

Utente

Livro

Evento 6 - Utente pede informação por título de livros (F)

Autor_livro

6PesquisarLivros por

título


Autor

Utente

Livro


Evento 7 - Utente pede informação de disponibilidade de livro (F)

7Pesquisar

disponibilidadede livro

Diálogo_pesquisa_dispUtente

LivroEmpréstimo

Evento 8 - Administração requer relatório (mensal) de empréstimos (T)

Empréstimo

8Emitir

relatório deempréstimos

Relatório_empréstimosAdministração

Livro

Evento 9 - Editora envia livros (F)

Autor_livro

9Registarlivros

adquiridos

Lista_livros_adquiridos

Autor

Editora

Livro


Finalizar modelo comportamental

A finalização do modelo comportamental engloba:

• Estruturação do DFD em vários níveis de detalhe (superiores e inferiores);

• Finalização do DER;

• Finalização do DD;

• Finalização do DTE;

• Especificação de processos.

Estruturar DFD em vários níveis

O DFD construído possui um só nível e muitos processos. Para organizar o

DFD, é necessário agrupar processos relacionados num processo de um

diagrama de nível superior.

1

3

2

4

1|3

5

4

2|5

Os processos 1 e 3 foram agrupados no processo “1|3”, e os processos

2 e 5 foram agrupados no processos “2|5”


Critérios de agrupamento de processos

Os critérios a ter em conta no processo de agrupamento de processos são os

seguintes:

• Cada agrupamento de processos deve envolver respostas relacionadas.

Isto normalmente significa que os processos manipulam dados

relacionados.

• Procurar oportunidades de “esconder” depósitos de dados que aparecem

em níveis inferiores. Se existe um grupo de processos que acedem um

depósito comum, e mais nenhum processo acede esse depósito, então

deve criar-se um processo de nível superior que esconda o depósito de

dados.

• Criar agrupamentos que possuam 7 +/- objectos.

O processo de estruturação de um DFD, em vários de DFD´s, decorre

sucessivamente até se obter um DFD de nível superior com +/- 7 objectos.

Contudo, a restrição de não ter um DFD com +/- 7 objectos não deve ser o único

aspecto a ter em conta. Se existem oportunidades de agrupar processos devido a

partilha de dados relacionados, ou devido à existência de depósitos locais, o

processo de agrupamento deve prosseguir.

Exemplo: Agrupamento de processos do sistema de gestão de bibliotecas

Processos agrupados Depósitos “escondidos” Detalhe

1, 2, 3 e 4 multa e leitor Diagrama 1

5, 6, 7 e 9 Autor e Autor_livro Diagrama 2

8 - -


Diagrama 1 - Gerir empréstimos

1.1Registardados de

leitor

Leitor

Ficha_leitor

1.2Verificare registar

empréstimo


Utente

1.4Registar

entrega deempréstimo

Empréstimo

Livro

Livros_a_entregar

Multa

1.3Registar

pagamentode multas

Pagamento_multa

Multa

Diagrama 2 - Gerir livros

2.3Registarlivros

adquiridos Lista_livros_adquiridos Editora

Empréstimo

2.2PesquisarLivros por

autor


Autor

Utente

2.1PesquisarLivros por

título


2.4Pesquisar

disponibilidadede livro


Autor_livro

Autor_livro

Livro

Livro


Diagrama 0

ADMINISTRAÇÃO

Ficha_leitor


UTENTEPagamento_multa




Livros_a_entregar

EDITORA

Lista_livros_adquiridosRelatório_empréstimos

1Gerir

empréstimos

3Emitir

relatório deempréstimos

2Gerirlivros

Livro

Empréstimo Empréstimo

Multa


Decomposição de processos não primitivos

Normalmente, também é necessário criar níveis inferiores de detalhe se os

processos existentes no DFD preliminar não forem primitivos. Esta necessidade

surge quando os processos responsáveis pela produção de respostas a eventos

são demasiadamente complexos para descrever numa página.

A detecção desta necessidade de decomposição por vezes é evidente. Nos

restantes casos a necessidade de decomposição só é detectada quando se inicia a

especificação de processos.

1. 2.

3.

3.1.

3.3.

3.2.

Critérios de decomposição de processos

Os critérios a ter em conta na decomposição de processos são os seguintes:

• Na maior parte dos casos a abordagem de decomposição funcional é

apropriada. Se existe um processo funcionalmente complexo, identificam-se

subfunções e para cada cria-se um processo de nível inferior;

• Nos restantes casos os fluxos de entrada e de saída proporcionam o melhor

mecanismo para determinar a melhor divisão do processo em processos do

nível inferior.

processo de análise estruturada - abordagem clássica teóricos/as... · análise estruturada 23...

Documents