Análise Estruturada 21 Processo de análise estruturada - Abordagem clássica Desenvolver modelo lógico actual Modelo físico actual Desenvolver modelo físico actual Desenvolver modelo lógico novo Modelo lógico actual Desenvolver modelo 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.
22
Embed
Processo de análise estruturada - Abordagem clássica Teóricos/as... · Análise Estruturada 23 Processo de análise estruturada - Modelo essencial O modelo essencial é o modelo
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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.
Análise Estruturada 22
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.
Análise Estruturada 23
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
Análise Estruturada 24
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.
Análise Estruturada 25
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.
Análise Estruturada 26
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
Análise Estruturada 27
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)
Análise Estruturada 28
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.
Análise Estruturada 29
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;
Análise Estruturada 30
• 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)