Aula 03

Prévia do material em texto

Aula 03
Analise Estruturada
Contextualizando o momento em que surge a análise estruturada
Antes do surgimento da análise estruturada não existiam técnicas e nem ferramentas para especificação e modelagem de sistemas. As especificações iniciais eram meramente textuais e, mais tarde, com uso de fluxogramas, que na verdade são mais adequados a especificação da lógica de programas e não de requisitos de sistemas.
Nessa época não havia equipe de desenvolvimento com funções bem definidas tais como: analista, projetista e programador de sistemas. Geralmente poucas pessoas trabalhavam em um sistema e, portanto, participavam em sua maioria de todas as fases as fases do processo de desenvolvimento de sistemas.
Havia dificuldade do analista de sistemas em entender as necessidades do usuário e representá-las de forma adequada à compreensão da equipe técnica, ou seja, aumentam as dificuldades do analista de sistemas no papel de  comunicador e elo de ligação entre usuário e equipe técnica de desenvolvimento do sistema.
Os sistemas desenvolvidos não atendem as especificações dos analistas e necessidades dos usuários, em função da incompreensão das  reais necessidades desses.
Os sistemas extrapolavam seus orçamentos e cronogramas, em função da dificuldade em realizar previsões de tempo e dinheiro adequadamente e do real entendimento necessidades do que deve ser o sistema (funcionalidades que deve possuir).
Aumenta o tamanho e a complexidade dos sistemas e com isso as dificuldades no processo de desenvolvimento do software.
Surgem, em função do exposto no item [4], acima, as equipes de desenvolvimento para suprir a necessidade do trabalho em fases (analise, projeto, desenvolvimento, testes e implantação). Surgia o primeiro processo de desenvolvimento de software, denominado “Em Cascata Clássico”.
Atenção
O cenário estava propício à absorção de novas técnicas de desenvolvimento de Sistemas, pois crescia, dia a dia, a demanda por novos e modernos sistemas nas empresas.
A natureza VARIÁVEL dos Requisitos
	Seria fantástico se não fosse verdade, mas é fato que os requisitos mudam. E como mudam, durante o desenvolvimento do sistema. Mudam porque os requistos fazem parte da empresa, que é uma entidade dinâmica, influenciada pelo meio em que está inserida. Por exemplo, mudanças pelo meio em que está inserida. Por exemplo, mudanças governamentais interferem nos requisitos de um sistema. Ações dos concorrentes afetam os requisitos de um sistema. Mudança na própria organização, como implementação de novos procedimentos para melhorias de processos afetam os requistos de um sistema. Enfim, vários fatores afetam os requisitos de um sistema uma vez que afetam a forma da empresa funcionar.
	Essas características de requisito (volatilidade) é um tanto óbvia e, racionalmente, todo analista de sistema conhece e reconhece esse fato como verdadeiro.
O grande problema, na verdade, é em função da forma com o Processo de desenvolvimento do sistema "Em cascata Clássico" trata a mudança de requisitos: não permite mudança de requisito durante o processo de desenvolvimento. Isso mesmo, todos os requistos devem ser definidos no inicio na fase de análise e uma vez especificadas não podem mais ser alterados,, ou seja, devem ser congelados. 
	Acontece que isso ai de encontro ao próprio conceito de requisto, que é volátil e variável sim. Os gerentes de projeto usam grande parte do tempo, no desenvolvimento de um sistema, monitorando as mudanças dos requisitos, Tal problema atinge, em cheio os sistemas grandes, cujos processos de desenvolvimento podem durar mais de um ano, Quando maior o tempo de desenvolvimento, maior o risco de processos mudarem.
	
	
Um breve histórico da análise estruturada
	No início da década de 70 ganhou notoriedade, pela utilidade prática para construção de programas eficientes, a técnica de programação estruturada, possível com as linguagens estruturadas de alto nível (Fortran, COBOL, Pascal e etc). 
Tal técnica caracteriza-se pela escrita dos programas usando apenas 3 estruturas: sequencial, decisão e repetição, além da não utilização dos desvios incondicionais (GOTO), que tornavam os programas ilegíveis. A programação estruturada visava a escrita de programas legíveis, eficientes e de fácil manutenção.
Como a programação estruturada teve sucesso, foi necessária a criação de técnicas de construção de Projeto de Software compatível com os preceitos da programação estruturada.
Como a programação estruturada teve sucesso, foi necessária a criação de técnicas de construção de Projeto de Software compatível com os preceitos da programação estruturada.
Era a chegada da técnica do Projeto Estruturado, possibilitando que os programas pudessem ser projetados para usar as características superlativas da programação estruturada. Tal técnica trouxe ferramentas como o DEM* , que dividia o programa em módulos (físicos) a serem programados. Trouxe também relevantes conceitos como acoplamento e coesão e formas eficientes de particionar a arquitetura do software. 
Seguindo a cronologia, observamos o surgimento, no início dos anos 80, da técnica de Análise Estruturada, popularizada por Tom DeMarco, em seu livro sobre o assunto, chamado Análise Estruturada e Especificação de Sistema, uma referência para estudo do assunto.
*DEM - > Diagrama de Estrutura Modular
Conceitos e características da análise estruturada
A Análise Estruturada, na prática, é uma atividade composta por um conjunto de técnicas e ferramentas cuja finalidade é auxiliar no processo de desenvolvimento de sistemas, especificamente na fase de análise e definição de sistemas. Descreve, passo a passo, as etapas que vão desde a identificação do problema* até a efetiva implantação, na empresa, do sistema de informação que contemplará a sua solução.
A análise estruturada é uma atividade baseada na construção de modelos** utilizando técnicas gráficas, como diagramas.
*Problema -> Necessidades do Usuário
**Modelos -> Abstrações da Realidade
As principais características da análise estruturada são:
Objetivo
Visa auxiliar no estudo de partes ou toda a empresa com vistas a especificação de um sistema de computação eficiente que ajude a empresa a resolver problemas específicos.
Como a analise estruturada compre o seu papel ?
1. Cria modelos, que são diagramas ou imagens gráficas, para representar os sistemas e facilitar as alterações necessárias (a qualquer tempo).
2. Retrata, nos diagramas, os fluxos de dados que fluem na empresa, especificamente nos processos pertinentes a área da empresa em estudo. O fluxo dos dados representado mostra como o processo funciona, ou seja, que entradas de dados recebe, quais processamento realiza e quais informações ou saídas gera.
3. Usa a técnica de refinamentos sucessivos ou top down, onde o sistema é dividido em partições funcionais, ou seja, apresentado sob a visão de múltiplos níveis, onde cada um detalha mais características que o nível anterior. Útil para o entendimento e modelagem de sistemas grandes e complexos, partindo-se de uma visão geral (macro) do sistema e detalhando-o melhor na medida em que o estudo e a compreensão do problema avançam .
O principal elemento da Análise Estruturada: o DFD
A base da proposição da Análise Estruturada é a elaboração do DFD. O DFD, por definição, é um modelo funcional, posto que apresenta a rede dos processos* que compõem o sistema em desenvolvimento, interligados por fluxos de dados.
*Processos -> Funções
O DFD baseia-se no conceito de que um sistema baseado em computador é representado como “um transformador de dados em informação”, através do processamento, conforme mostrado na imagem.
Processo:
1. Representado pela elipse ou círculo.
2. O nome do processo deve estar relacionado com uma atividade ou função do negócio. Devem ser evitados nomes muito físicos(gravar, imprimir), muito técnicos (deletar, becapear) ou nomes muito genéricos (processar).  
3. Transforma, pelo processamento, dados de entrada em informação de saída.4. Representa as ações que o sistema executa.
5. Nem todos os processos representados no DFD devem ser automatizados.
6. Regras: Nenhum processo pode ter apenas saídas  (transforma o que?).
7. Nenhum processo pode ter apenas entradas (buraco negro)
Representado pela seta com o nome do fluxo.  Veja abaixo as notações possíveis:
1. São dados e informações que trafegam pelo sistema.
2. Mostra como os fluxos fluem através do sistema, o caminho percorrido pelos dados no sistema.
3. O nome do fluxo deve ser um substantivo que facilite a identificação do dado ou pacote de dados transportado.  Todo fluxo de dados possui direção (origem e destino).  
4. Vejamos pelo exemplo apresentado na figura.
     Fluxo 1 = entrada de dados enviada pela Entidade Externa 1
     Fluxo 2 = entrada de dados enviada pela Entidade Externa 2
     Fluxo 3 = dado armazenado no depósito de dados
     Fluxo 4 = informação gerada pelo processo, pelo processamento dos fluxos: fluxo 1, Fluxo 2 e Fluxo 3.
Regras para uso de fluxos de dados:
A.   O fluxo de dados tem 1 única direção, exceto de/para depósitos de dados.
B.   É permitido fluxo de dados entre:
       A.  2 processos.
       B.  1 processo e 1 depósito.
       C.  1 processo e 1 entidade.
C.   Não são permitidos fluxos de dados entre:
       A.  2 ou mais entidades externas.
       B.  2 ou mais depósitos de dados.
       C.  1 entidade externa e 1 depósito de dados.
D.   O cruzamento de fluxos deve ser minimizado.
Depósito de dados
1. Representado pelas linhas paralelas ou retângulo aberto do lado direito, conforme  a imagem.
2. Armazenam, temporariamente, os dados que fluem no sistema.
3. Constituem a memória do sistema. Representando os dados em estado de repouso.
4. As operações (fluxos entrando e saindo) em depósitos de dados são:
    -Incluir dados: seta (fluxo) chegando no depósito
    -Alterar e excluir dados: seta (fluxo) dupla (chegando e  saindo), representando uma consulta (existência do dado) e uma atualização dos dados.
    -Leitura de dados: seta saindo do depósito.
Depósito de dados
Entidade Externa
a. São as f São as fontes dos dados de entrada e destino das informações de saídas, respectivamente conduzidas pelos fluxos de dados.
b. Não fazem parte do sistema, mas interagem com ele, mostrando 
ontes dos dados de entrada e destino das informações de saídas, respectivamente conduzidas pelos fluxos de dados.
Não fazem parte do sistema, mas interagem com ele, mostrando
Conceitos e características da análise estruturada
O DFD em níveis
A análise estrutura propõe a elaboração do DFD em níveis, através da técnica de refinamentos ou top down, onde se inicia com um DFD geral e detalha-se cada um, na medida em que há necessidade.
Balanceamento do DFD
É necessário que haja coerência entre os níveis de DFD e que haja um balanceamento também.
REGRA GERAL: Ao particionar (explodir) um processo, qualquer fluxo, depósito ou entidade que esteja em 1 nível, deve aparecer no nível imediatamente anterior.
Cada DFD deve estar balanceado com relação ao processo que o originou:
O conjunto de entradas e saídas de 1 DFD deve ser equivalente ao que o originou.
A consistência da entrada e saída entre os níveis é obrigatória: não pode haver fluxo de entrada/saída no nível inferior que não esteja no nível superior.
Pelo exemplo, o DFD que contém os processos 2.1 e 2.2 encontra-se NÃO balanceado pois:
1. No nível anterior (processos 1, 2 e 3), acima e a esquerda, o processo 2, recebe como entrada o fluxo “e” (do processo 1) e gera como saída o fluxo “d” (para o processo 3).
2. No nível seguinte, existe um fluxo “x”, que chega ao processo 2.1, que não existe chegando ao processo 2, no diagrama do nível anterior (acima e a esquerda). Por isso diz-se que o mesmo esta NÃO balanceado, pois está incompatível com o nível anterior e deve ser revisto.
Num DFD não é necessário desenhar um depósito de dados que apareça apenas no interior de cada um seus processos. Se um depósito é usado por mais de 1 processo em 1 DFD então deve ser representado.
Quando um depósito de dados é usado por 2 ou mais processos, deve ser apresentado neste nível e em cada diagrama de nível inferior que descreva os processos que usam o depósito de dados. 
As ferramentas da Análise Estruturada
Além do DFD, a análise estruturada utiliza dois outros modelos que o complementam.
Dicionário de Dados (DD) que complementa o DFD, explicando melhor seus elementos: entidades, fluxos de dados e depósito de dados. Ao ler um DFD você precisará ter em mãos o DD (Dicionário de dados), para que possa compreender os dados que compõem um fluxo ou os dados que estão sendo armazenados em um depósito de dados, por exemplo.
1. Para as entidades, descreve-se a sua finalidade (interação com o sistema).
2. Para os fluxos de dados, descreve-se a sua composição. Por exemplo, vamos supor o fluxo de dados Pedidos_Livro. No DD deve-se especificar todos os dados que fazem parte desse pedido.
3. Para os depósitos de dados deve-se especificar os dados que estão sendo armazenados.
4. Os fluxos e depósitos vão gerar estruturas intermediárias chamadas Estruturas de dados.
5. As estruturas de dados são formadas por outras estruturas ou por elementos de dados, que são os dados atômicos.
6. As estruturas e depósitos de dados devem ser representadas no DD.
O DD deve ser elaborado com símbolos especiais, conforme tabela abaixo.
Vamos exemplificar a confecção de um DD com auxílio da imagem – Exemplo de DFD Simples para exemplificar DD.
Vamos exemplificar a especificação do depósito de dados Pedidos.
O depósito PEDIDOS é composto de um conjunto (repetição)  do fluxo Dados_pedido
O fluxo dados_Pedido é composta pelos elementos de dados Cod_Cliente, Cod_Livro, Data_Pedido, Qtde_livro.
O depósito PEDIDOS tem como chave 3 elementos de dados em conjunto (que estão sublinhados): Cod_Cliente, Cod_Livro, Data_Pedido,
O elemento Cod_cliente é numérico com com 10 dígitos no máximo.
PEDIDOS =  * pedidos feitos pelos clientes *
{ dados_pedido }
Dados_pedido = Cod_Cliente + Cod_Livro + Data_Pedido + Qtde_livro
Cod_Cliente = * código do cliente
                       Tipo: Numérico
                       Tamanho: 10 posições
Especificação do Processo
Descreve, através de algumas técnicas a lógica de processamento (funcionamento) do processo. Pode-se usar: português estruturado, árvore de decisão, tabela de decisão.
Consideração da Especificação
Ao chegar no nível dos processos (funções) primitivos, não há mais o que especificar em termos de DFD.
Precisamos então especificar cada processo primitivo de forma clara e precisa.
Usaremos o Português Estruturado: subconjunto do Português, cujas sentenças são organizadas, segundo as três estruturas de controle introduzidas pela programação estruturada : sequências, seleção e repetição.
O português estruturado é usado tanto na abordagem da análise estruturada como na análise essencial.
Características da Especificação
Deve especificar "o que o processo deve fazer" e NUNCA "como o processo deve fazer".  Veja a diferença abaixo, para o seguinte enunciado : "para registrar a matrícula de um aluno o Processo – Matricula Aluno – deve atribuir um valor numérico e sequencial para – Código-matrícula".
Especificação I
Inicio
Obter novo_aluno
Localizar último registro de aluno  em ALUNOS
Ler matrícula-aluno do registro localizado.
Acrescente 1 a matrícula-aluno
Armazene novo registro em ALUNOS com matrícula-aluno , Nome-aluno e endereço-aluno
Fim
Especificação II – MAIS INDICADA
Início
Obter novo-aluno
Atribuir valor numérico e sequencial a matrícula-aluno
Armazenar matrícula-aluno, nome-aluno e endereço-aluno em ALUNOS.
Fim
Modelagem dos dados
A análise estruturada, inicial e conceitualmente estava calcada na análise funcional, baseada no DFD.
Os dados do sistema eram representados pelos depósitos de dados. Com o surgimento e proliferação dos sistemas gerenciadoresde banco de dados e do modelo relacional, a modelagem dos depósitos deixou de ser suficiente e Peter Chain propôs um modelo conceitual de dados que denominou Modelo de Entidade e Relacionamento.*
*O MER é um modelo de dados, de alto nível de abstração que mostra o relacionamento dos dados que são armazenados em um sistema. 
Era elaborado com base nos dados armazenados nos depósitos de dados.
O MER é composto dos elementos:
Entidade (produto e tipo de produto).
Relacionamento (losango, que pode ter um nome).
Atributo das entidades:  entidade produto tem os atributos codigo, descrição e preço.; A entidade tipo de produto tem os atributos código e descrição.
Estudo de Caso: O caso da Livraria ABC
Apresentaremos, nesse tópico, um estudo de caso, partindo da especificação do mini-mundo (especificação textual dos requisitos) de uma livraria que solicita livros as editoras atendendo especificamente a pedidos prévios de seus clientes.
Abaixo, o mini mundo:
A Livraria ABC atua no mercado de livros há mais de 20 anos. Sua estratégia de atuação não prevê manutenção de livros em estoque. Todos os livros solicitados pelos clientes são, semanalmente, requisitados às editoras. As editoras e os livros oferecidos são selecionados pela Direção da Livraria. 
 
Atualmente, a Livraria possui 1.200 clientes cadastrados, fornece 170 livros e atende a uma média de 150 pedidos por semana.
 
Os clientes enviam seus pedidos pelo correio. O pedido é aceito se o cliente e os livros estiverem previamente cadastrados. Caso contrário, o pedido é rejeitado e devolvido ao cliente.
Ao final da semana, a Livraria emite as requisições para as editoras, com base nos pedidos recebidos ao longo da semana.
Quando os livros são fornecidos pelas editoras, a Livraria confere as notas fiscais emitidas pelas editoras com as requisições, devolve as que contiverem erros e atende os pedidos dos clientes, emitindo as respectivas faturas, que acompanham os livros. Uma cópia da fatura é encaminhada à Tesouraria, onde é feito o controle de pagamentos.
Sugerimos o acesso aos seguintes sites, referentes aos diferentes paradigmas de desenvolvimento, no que tange a linguagens de programação e os métodos (e técnicas) de análise de sistemas. 
Procure explorar todos os links existentes nas URLs abaixo relacionadas. 
Todos os sites abaixo foram acessados em 22/12/2011 
Site Wikipédia sobre Análise Estruturada.
Material de aula da Universidade Federal Rural do Pernambuco.