Upload
vukhue
View
227
Download
0
Embed Size (px)
Citation preview
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)
• 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)
Análise Estruturada 31
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.
Análise Estruturada 32
• 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.
Análise Estruturada 33
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.
Análise Estruturada 34
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.
Análise Estruturada 35
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
Análise Estruturada 36
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
Diálogo_pesquisa_autor
Autor
Utente
Livro
Evento 6 - Utente pede informação por título de livros (F)
Autor_livro
6PesquisarLivros por
título
Diálogo_pesquisa_título
Autor
Utente
Livro
Análise Estruturada 37
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
Análise Estruturada 38
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”
Análise Estruturada 39
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 - -
Análise Estruturada 40
Diagrama 1 - Gerir empréstimos
1.1Registardados de
leitor
Leitor
Ficha_leitor
1.2Verificare registar
empréstimo
Diálogo_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
Diálogo_pesquisa_autor
Autor
Utente
2.1PesquisarLivros por
título
Diálogo_pesquisa_título
2.4Pesquisar
disponibilidadede livro
Diálogo_pesquisa_disp
Autor_livro
Autor_livro
Livro
Livro
Análise Estruturada 41
Diagrama 0
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_empréstimos
1Gerir
empréstimos
3Emitir
relatório deempréstimos
2Gerirlivros
Livro
Empréstimo Empréstimo
Multa
Análise Estruturada 42
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.