AnESTR-Extensoes

Prévia do material em texto

A ANÁLISE ESTRUTURADA E SUAS EXTENSÕES
  
  
     A análise estruturada, usando sua própria notação, serve para criação de modelos que retratam o fluxo e o conteúdo da informação (dados e controle), dividimos os sistema em partições funcionais e comportamentais e descrevemos a essência daquilo que deve ser construído. 
NOTAÇÃO BÁSICA E SUAS EXTENSÕES 
     A informação é tranformada à medida que flui atravéz de um sistema baseado em computador. O sistema aceita entrada numa variedade de formas, aplica hardware, software e elementos humanos para transformar entrada em saída e produz saída numa variedade de formas. A entrada pode ser um sinal de controle transmitido por uma fonte de energia, uma série de números digitados por um operador humano, um bloco de informações transmitido numa conexão em rede (network link) ou um volumoso arquivo de dados recuperado de um dispositivo de armazenamento. 
  
 A análise estruturada é uma técnica de modelagem do conteúdo e do fluxo de informações.   
Diagrama de Fluxo de Dados 
     O diagrama de fluxo de dados pode ser usado para representar um sistema ou software em qualquer nível de abstração. De fato, os Diagramas de Fluxos de Dados (DFDs) podem se divididos em partições de acordo com níveis que representem um crescente detalhamento funcional e do fluxo de informações. 
     O nível 0 do DFD, também chamado de modelo fundamental do sistema ou modelo de contexto, representa o elemento software global como uma única bolha e dados de entrada e a saída indicados por setas que chegam e saem, respectivamente. Por exemplo um DFD de nível 1 poderia conter cinco ou seis níveis de bolhas com setas de interligações. Cada um dos processos representados no nível 1 são subfunções do sistema global descrito no modelo de contexto. 
     É inportante observar que nenhuma indicação explícita da seqüência de processamento é fornecida pelo diagrama. O procedimento ou a seqüência pode estar implícito no diagrama, mas a representação procedimental explícita geralmente é retardada até o projeto do software. 
     O diagrama de fluxo de dados é uma ferramenta gráfica que pode ser muito valiosa durante a análise de requisitos de software. Porém o diagrama pode causar confusão se sua função for confundida com a do fluxograma. Um diagrama de fluxo de dados descreve o fluxo de informações sem uma representação explícita da lógica procedimental (condições ou loops). 
Extensões para Sistemas de Tempo Real 
     Muitas aplicações de software são dependentes do tempo e processam mais informações orientadas ao controle do que dados. O sistema em tempo real deve interagir com o mundo real num limite de tempo ditado pelo mundo real. Para acomodar a análise de software de tempo real, uma série de extensões foram propostas. 
Extensões de WARD e MELLOR 
     Ampliam a notação básica nas seguintes especificações: 
       - Fluxo de informações que sejam obtidas ou produzidas em base de tempo real; 
       - Informações de controle passadas pelo sistema e associadas ao processamento do controle; 
       - Múltiplas instâncias da mesma tranformação que às vezes encontram-se em situações de multitarefa; 
       - Estados de sistemas e o mecanismo que causa a trasição entre os estados. 
     Numa significativa porcentagem de aplicações de tempo real, o sistema deve monitorar informações em tempo contínuo geradas por algum processo do mundo real. A notação convencional para o fluxo de dados não faz distinção entre dados discretos e dados em tempo contínuo. 
     A distinção entre fluxo de dados discretos e em tempo contínuo tem importantes implicações tanto para o engenheiro de sistema como para o projetista de software. À medida que o modelo físico ou de implementação for criado, o projetista deve estabelecer um mecanismo para coleta de dados em tempo contínuo. A notação indica onde será exigido hardware analógico-digital e quais tranformações provavelmente exigirão software de elevado desempenho. 
     O fluxo de dados é representado por uma seta sólida, o fluxo de controle, por uma seta pontilhada ou sombreada, um processo que trata apenas um fluxo de controle, denominado processo de controle, é similarmente representado por uma bolha sombreada. 
Extensões de HATLEY e PIRBHAI 
     As extensões de Hatley e Pirbhai à notação básica da análise estruturada concentram-se menos na criação de símbolos gráficos adicionais e mais na representação e especificação dos aspectos orientados aocontrole do software. É definido um diagrama de fluxo de controle (Control Flow Diagram - CFD), que apresenta os mesmos processos que o DFD, mas mostra o fluxo de controle e não o fluxo de dados. 
     A especificação de controle contém uma série de importantes ferramentas de modelagem. Uma tabela de ativação do processo é usada para indicar quais processos são ativados por determinado evento que flui pela barra vertical. 
     Uma fluxo de eventos pode ser introduzido diretamente num processo, como é observado com a falha de produção, porém, esse fluxo não ativa o processo, mas, ao contrário, fornece informações de controle para o algoritmo de processo. 
Modelagem Comportamental 
     A modelagem comportamental é um dos princípios fundamentais para todos os métodos de análise de requisitos. Contudo, somente as versões estendidas da análise estruturada oferece uma notação para este tipo de modelagem. 
Extensões para Aplicações com Dados Intensivos 
     A notação básica para a análise estruturada funciona bem quando informações relativamente simples fluem através de uma série de processos. Porém, em muitas aplicações de sistema de informação existe a nescessidade de se representar o relacionamento entre coleções complexas de dados. Para realizar isto a notação da análise estruturada foi ampliada a fim de abranger um componente de modelagem de dados. 
  
A MECÂNICA DA ANÁLISE ESTRUTURADA 
  
  
     Para ser usada efetivamente na análise dos requisitos de software, essa notação deve ser combinada com um conjunto de heurísticas que possibilite ao engenheiro de software derivar um bom modelo análise. 
Criação do Modelo de Fluxo de Dados 
     Algumas diretrizes básicas podem ajudar consideravelmente durante a derivação de um diagrama de fluxo de dados: 
       (1) o diagrama de fluxo de dados de nível 0 deve descrever o software/sistema como uma única bolha; 
       (2) a entrada e a saída iniciais devem ser couidadosamente anotadas; 
       (3) o refinamento deve iniciar isolando-se possíveis processos, itens de dados e depósitos de dados a serem representados no próximo nível; 
       (4) todas as setas e bolhas devem ser rotuladas com nomes significativos; 
       (5) a continuidade do fluxo de informação deve ser mantida de nível em nível; 
       (6) uma bolha de cada vez deve ser refinada. 
Criação do Modelo de Fluxo de Controle 
     Para muitos tipos de aplicações de processamento de dados, a modelagem do fluxo de dados é suficiente para se obter um significativo esclarecimento dos requisitos do software. Entretento existe uma grande classe de aplicações, que é baseada em eventos e não em dados, que produz informações de controle em vez de relatórios ou displays e que processa informações com forte preocupação com o tempo e o desempenho. 
Especificação de Controle 
     A especificação de controle (CSPEC) representa o comportamento do sistema de duas maneiras diferentes. A CSPEC contém um diagrama de transição de estado (STD) que é um especificação seqüêncial do padrão de comportamento. Ela também pode conter uma tabela de ativação de programa (PAT) - uma especificação combinatória de comportamento. 
     A CSPEC descreve o comportamento do sistema, mas não no dá quaisquer informações sobre o funcionamento interno dos processos que são ativados como resultado desse comportamento. 
Especificação de Processo 
      A especificação de processo (PSPEC) é usada para descrever todos osprocessos do DFD que aparecem no nível de refinamento final. Ao definir uma PSPEC para cada bolha do modelo de fluxo, o engenheiro de software cria uma "miniespecificação" que pode servir como um primeiro passo na criação da Especificação de Requisitos de Software e com um guia para projeto do componente de programa que implementará o processo. 
  
  
  
  
O DICIONÁRIO DE REQUISITOS 
  
  
     O dicionário de requisitos (também chamado de dicionário e dados) foi proposto como uma gramática quase formal para descrever o conteúdo de objetos definidos durante a análise estruturada. 
     Atualmente o dicionário de requisitos quase sempre é implementado como parte de um "ferramenta de projeto e análise estruturada" - CASE. Embora o formato dos dicionários varie de ferramenta para ferramenta, a maioria contém as seguintes informações: 
       - Nome; 
       - Alias; 
       - Onde é usado/como é usado; 
       - Descrição de conteúdo; 
       - Informação complementar. 
     Para grandes sistemas baseados em computador, o dicionário de requisitos cresce rapidamente em tamanho e em complexidade. De fato é extremamente difícil manter um dicionário manualmente. Por essa razão, ferramentas CASE são usadas. 
A ANÁLISE ESTRUTURADA E CASE 
  
     A notação original para a análise estruturada foi desenvolvida para aplicações de processamento de dados convencional, mas as extensões agora tornam o método aplicável a sistemas de tempo real. A análise estruturada é apoiada por uma série de ferramentas CASE que auxiliam a criação de cada elemento do modelo e também ajudam a assegurar consistência e exatidão.