Processo de análise estruturada - Abordagem clássica

Transcrição

1 Processo de análise estruturada - Abordagem clássica Desenvolver modelo físico actual Modelo físico actual Modelos a desenvolver tendo em conta a abordagem clássica Desenvolver modelo lógico actual Modelo lógico actual Desenvolver modelo lógico novo Modelo lógico novo Desenvolver modelo físico novo Modelo físico novo 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 21

2 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 22

3 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 Ambiental Comportamental Ferramentas utilizadas Declaração de propósito Diagrama de Contexto (DC) Lista de Eventos 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 23

4 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 24

5 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 25

6 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) Diálogo_empréstimo Pagamento_multa UTENTE Diálogo_pesquisa_autor Diálogo_pesquisa_título Multa Ficha_leitor Livros_a_entregar Diálogo_pesquisa_disp Gestão de Bibliotecas Relatório Lista_livros_adquiridos ADMINISTRAÇÃO EDITORA Análise Estruturada 26

7 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 27

8 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 28

9 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 29

10 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 30

11 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 31

12 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 32

13 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 33

14 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 34

15 DFD preliminar do exemplo de gestão de bibliotecas Evento 1 - Utente inscreve-se como leitor (F) Utente Ficha_leitor 1 Registar dados de leitor Leitor Evento 2 - Utente solicita empréstimo de livros (F) Utente Diálogo_empréstimo Leitor Empréstimo 2 Verificar e registar empréstimo Livro Multa Evento 3 - Utente entrega livros (F) Utente Multa Empréstimo Livros_a_entregar 3 Registar entrega de empréstimo Livro Multa Análise Estruturada 35

16 Evento 4 - Utente paga multas (F) Utente Pagamento_multa 4 Registar pagamento de multas Multa Evento 5 - Utente pede informação por autor de livros (F) Utente Diálogo_pesquisa_autor Autor_livro 5 Pesquisar Livros por autor Livro Autor Evento 6 - Utente pede informação por título de livros (F) Utente Diálogo_pesquisa_título Autor_livro 6 Pesquisar Livros por título Livro Autor Análise Estruturada 36

17 Evento 7 - Utente pede informação de disponibilidade de livro (F) Utente Diálogo_pesquisa_disp Empréstimo 7 Pesquisar disponibilidade de livro Livro Evento 8 - Administração requer relatório (mensal) de empréstimos (T) Administração Relatório_empréstimos Empréstimo 8 Emitir relatório de empréstimos Livro Evento 9 - Editora envia livros (F) Editora Lista_livros_adquiridos Autor_livro 9 Registar livros adquiridos Livro Autor Análise Estruturada 37

18 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 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 38

19 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 Análise Estruturada 39

20 Diagrama 1 - Gerir empréstimos Ficha_leitor Utente Multa Pagamento_multa 1.1 Registar dados de leitor Diálogo_empréstimo 1.3 Registar pagamento de multas Livros_a_entregar Leitor 1.2 Verificar e registar empréstimo Multa Livro 1.4 Registar entrega de empréstimo Empréstimo Diagrama 2 - Gerir livros Diálogo_pesquisa_autor Utente Diálogo_pesquisa_disp 2.2 Pesquisar Livros por autor Autor_livro 2.1 Pesquisar Livros por título Autor Diálogo_pesquisa_título Livro 2.4 Pesquisar disponibilidade de livro Autor_livro Livro 2.3 Registar Empréstimo livros adquiridos Lista_livros_adquiridos Editora Análise Estruturada 40

21 Diagrama 0 Diálogo_empréstimo Pagamento_multa UTENTE Diálogo_pesquisa_autor Diálogo_pesquisa_título Multa Livros_a_entregar Diálogo_pesquisa_disp 1 Gerir empréstimos Ficha_leitor Livro 2 Gerir livros Empréstimo 3 Emitir relatório de empréstimos Empréstimo Relatório_empréstimos Lista_livros_adquiridos ADMINISTRAÇÃO EDITORA Análise Estruturada 41

22 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 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. Análise Estruturada 42