Devido às características do método ASA, é através da construção de uma ferramenta/protótipo que se torna mais fácil entender o funcionamento de ASA. Assim, foi construído um protótipo debaixo de um ambiente iminentemente gráfico, o Windows 3.1, de forma a aproveitar as suas vantagens e adoptar o "interface" aí existente.
Como foi anteriormente verificado, no método ASA, a fase de análise (automatização) só começa quando a entrada de informação termina. Contudo, no protótipo desenvolvido tal não se verifica, pois para cada conjunto de informação fornecido, é feita, imediatamente, a respectiva análise, visto que o método assim o permite.
Para trabalhar com o protótipo ASA basta definir as componentes, os fluxos de informação e a descrição dessa informação, fazendo com que ASA disponibilize, ao seu utilizador, uma série de relatórios de diagnósticos sobre a especificação fornecida. Desta forma, o utilizador pode proceder a adições ou a alterações na especificação e pode, de novo, gerar uma outra série de relatórios de diagnósticos.
Provar a validade do método ASA, pode ser conseguida através da elaboração de um exemplo, que, ao ser processado, exemplifique o funcionamento do método e do protótipo respectivamente.
O exemplo consiste num Sistema de Gestão de Vencimentos. Este sistema pode não estar completo, no entanto cobre as principais funções da Gestão de Vencimentos, tais como:
Capítulo 5: Validação do Método 81
.
admissão de trabalhadores.
emissão de recibo de vencimento.
envio automático dos valores de acumulados trimestrais de IRS para os Serviços Centrais das Finanças, IRSA sua escolha foi facilitada por este ser um problema clássico, bastante aproximado da realidade e a sua implementação ser bem conhecida por aqueles que são especialistas de Análise de Sistemas na área da Informática de Gestão.
5.2 ENTRADA DE INFORMAÇÃO
Em primeiro lugar é preciso definir o sistema a trabalhar, o que é feito a partir do écran existente na Fig. 22, onde se indica que o sistema é denominado por RecHum (Recursos Humanos).
Capítulo 5: Validação do Método 82
A etapa seguinte consiste em descrever o DFI para este sistema. Assim, RecHum necessita ter um domínio denominado por ResProc (Responsável pelo Processamento) que tem como funções obter toda a informação para proceder ao processamento de vencimentos e emissão de recibo para entregar aos trabalhadores (domínio externo ao sistema em estudo). Este domínio, o ResProc, todos os trimestres, envia o valor de IRS, que é deduzido mensalmente a todos os trabalhadores, para as Finanças (domínio externo ao sistema em estudo). Sempre que houver alteração aos dados de um trabalhador ou um trabalhador novo for admitido, então esse trabalhador terá que enviar esses dados para o responsável pela admissão que procederá à actualização do seu cadastro.
O DFI para o exemplo acima descrito está apresentado na Fig. 23.
Capítulo 5: Validação do Método 83
Como já foi anteriormente referido, existem domínios que pertencem ao Sistema (denominados internos) e domínios que não pertencem (denominados externos).
Os domínios internos podem ainda ser classificados como locais, remotos e não informatizáveis. Os domínios locais, para poderem efectuar as suas funções, têm toda a informação que necessitam totalmente disponível. Os domínios remotos, de forma a obterem os documentos necessários para desempenharem as suas funções, necessitam de recorrer a um meio qualquer de comunicação. Os domínios não informatizáveis efectuam as suas funções manualmente, sem recorrer ao auxilio do computador.
Para os domínios descritos no DFI da Fig. 23, temos:
.
Finanças - domínio externo;.
Trabalha (Trabalhador) - domínio externo;.
Admissao (Admissão) - domínio interno e local;.
ResProc (Responsável pelo processamento) - domínio interno e local. Para definir em ASA os tipos de domínios, recorre-se à utilização da janela de domínios, ver Fig. 24 onde está descrito o domínio ResProc. Nesta janela salienta- se a existência da secção denominada Informação, na parte direita da janela, onde de uma forma automática, é mostrada a identificação da área do que se está a trabalhar, neste caso a identificação do sistema em estudo.Capítulo 5: Validação do Método 84
Para completar a informação existente no DFI é necessário descrever os documentos aí existentes:
.
Inform - documento que circula entre os domínios Trabalha eAdmissao, com frequência Ext (devido a somente acontecer quando ocorrer uma alteração ou admissão de trabalhador);
.
Inf_Trab - documento que circula entre os domínios Admissao eResProc, com frequência Clock2 (todos os meses a informação dos trabalhadores é enviada para ResProc para o processamento e emissão de recibos);
.
Receita - documento que circula entre os domínios ResProc eFinanças, com frequência Clock3 (todos os meses ResProc envia para as Finanças os valores de IRS previamente deduzidos);
Capítulo 5: Validação do Método 85
.
IRS - documento que circula entre os domínios Finanças e ResProc, com frequência Ext (Externo, sempre que existam alterações à tabela de IRS);.
Recibo - documento que circula entre os domínios ResProc e Trabalha, com frequência Clock1 (mensalmente os recibos são entregues aos trabalhadores);Para fornecer a ASA os tipos de domínios existentes recorre-se à utilização da janela de documentos, ver Fig. 25 onde está descrito o documento Recibo. Salienta-se que nesta janela os domínio de destino e origem já se encontram preenchidos.
Capítulo 5: Validação do Método 86
Para cada documento existe uma frequência à qual é necessário fornecer um peso para permitir uma ordenação da sua ocorrência (documentos com menor peso implica uma grande frequência de ocorrência). Assim, se na janela da Fig. 25 se seleccionar o botão de frequência aparecerá a janela representada na Fig. 26.
Após se ter definido o peso da frequência, passa-se à definição da estrutura e conteúdo dos diversos documentos. Considerou-se que os documentos são compostos por blocos de informação, podendo esses blocos identificar entidades. Assim, para os diversos documentos teremos:
.
Inform - contém o bloco denominado por Inf (dados do trabalhador); Fig. 26 - Descrição da Frequência Clock1Capítulo 5: Validação do Método 87
.
Inf_Trab - contém o bloco denominado por Registo (dados do trabalhador para processamento);.
Receita - contém o bloco denominado por Registo (dedução efectuado pelo trabalhador para pagamento do IRS);
.
IRS - contém o bloco denominado por Registo (registo da tabela de IRS que permite definir os escalões de tributação de IRS);.
Recibo - contém os blocos Cabecalh (Cabeçalho, agrupa a informação de identificação do trabalhador) e Corpo (onde são agrupados os valores de remunerações e deduções para calcular o valor liquido do recibo);Na Fig. 27, pode ver-se a janela de Blocos onde se encontra representado o bloco Corpo do documento Recibo.
Capítulo 5: Validação do Método 88
Após a definição dos blocos de cada documento, passa-se à descrição do conteúdo de cada um. Assim, para os diversos documentos/blocos teremos:
.
Inform - bloco: Inf Campos:Nome - nome do trabalhador
NContr - número de contribuinte
NDep - número de dependentes
ECiv - estado civil
NSegSoc - número de segurança social
.
Inf_Trab - bloco: Registo Campos:NTrab - número do trabalhador
Nome - nome do trabalhador
NContr - número de contribuinte
NDep - número de dependentes
ECiv - estado civil
CatProf - categoria profissional
NSegSoc - número de segurança social
VencIliq - vencimento ilíquido;
.
Receita - bloco: Registo Campos:Ano - ano da dedução
Mes - mês da dedução
Capítulo 5: Validação do Método 89
Dedu - valor da dedução;
.
IRS - bloco: Registo Campos:EcivIRS - estado civil
NDepIRS - número de dependentes
TIRS - taxa de IRS;
.
Recibo - bloco: Cabecalh Campos:NomOrg - nome da organização
Ano - ano do processamento
Mes - mês do processamento
NTrab - número do trabalhador
Nome - nome do trabalhador
NContr - número de contribuinte
NDep - número de dependentes
ECiv - estado civil
CatProf - categoria profissional
NSegSoc - número de segurança social
bloco: Corpo Campos:
VencIliq - vencimento ilíquido DAus - dias de ausência DTrab - dias trabalháveis DPag - dias a pagar
Capítulo 5: Validação do Método 90
Dedu - deduções
Remun - Remunerações Liq - liquido a receber;
Na Fig. 28, pode observar-se a janela de Campos onde se encontra representado o campo DAus do bloco Corpo e documento Recibo.
Todos os campos, atrás referidos, são criados de uma forma automática com um conjunto pré-definido de propriedades. Assim, todos os campos são da classe variável (o seu conteúdo pode variar nas diversas instâncias do documento) e do tipo alfanumérico. Contudo, pode-se pretender alterar algumas dessas propriedades, o que obrigará a escolher o botão, propriedades da janela representada na Fig. 28 o que fará aparecer logo de seguida a janela da Fig. 29.
Capítulo 5: Validação do Método 91
Se a classe do campo DPag for alterada para fórmula, com o conteúdo de DPag = DTrab - DAus (dias a pagar é igual à diferença entre os dias trabalháveis e os dias que faltou), obriga a alterar as propriedades desse campo na janela da Fig. 29 e acrescentar a respectiva fórmula, ver Fig. 30.
Capítulo 5: Validação do Método 92
O campo NomOrg é da classe constante, o que implica alterar a sua propriedade para constante e gravar o respectivo texto no écran da Fig. 31.
Desta forma todos os existentes pertencem à classe Variável e são do tipo alfanumérico, excepto os campos representados na Tabela 9.
Fig. 30 - Descrição da fórmula do campo DPag do bloco Corpo e documento Recibo
Capítulo 5: Validação do Método 93
Campo Classe Conteúdo
NomOrg (nome organização) Constante XPTO, Lda
DPag (dias a pagar) Fórmula DTrab - DAus
Remun (remunerações) Fórmula (VencIliq * DPag)/ DTrab
DescSS (desc. seg. social) Fórmula Remun * 11%
Dedu (deduções) Fórmula Se(ECiv=ECivIRS ^ NDep=NDepIRS) Então
Remun * TIRS
Liq (liquido a receber) Fórmula Remun - DescSS - Dedu
Tabela 9 - Campos cuja Classe é diferente de Variável
Neste momento está descrita toda a informação necessária para se proceder ao processamento da informação. No entanto, salienta-se que se poderia proceder ao processamento em qualquer altura desta etapa de introdução de informação, o que implicaria, logicamente, que os resultados fossem diferentes, porque dependem da quantidade de informação previamente fornecida.
5.3 AUTOMATIZAÇÃO
O etapa de automatização, ou processamento da informação, no protótipo ASA é despoletada, imediatamente, após o utilizador seleccionar uma das opções de consulta representadas na Fig. 32.
Capítulo 5: Validação do Método 94
Durante o processamento, ASA pode colocar uma questão ao utilizador de forma a saber se a informação que vem do exterior pode ser guardada no momento em que é necessária para fornecer o documento interno. Neste exemplo, ASA pergunta se a informação, que um trabalhador fornece na sua admissão, pode ser registada somente no momento em que vai ser necessária para o processamento de vencimentos, ver Fig. 33. A resposta à questão colocada na Fig. 33, pode ser respondida positivamente, devido à inexistência da necessidade da informação de admissão do trabalhador noutros domínios da organização e consequentemente a frequência entre os dois documentos poder ser igual. No entanto, na Fig. 34, coloca-se a mesma questão entre o documento Recibo e IRS, a resposta, desta vez, deveria ser negativa, pois o documento IRS tem uma frequência anual, enquanto que o Recibo tem uma frequência mensal.
Capítulo 5: Validação do Método 95
Quando o processamento terminar todas as opções de consulta se encontram disponíveis, ver Fig. 32.
Fig. 33 - Comparação da criação dos documentos Inf_Trab e Inform
Capítulo 5: Validação do Método 96
Se seleccionar a primeira opção aparecerá a janela representada na Fig. 35, onde se encontra o sistema RecHum.
Se seleccionar a segunda opção aparecerá uma janela idêntica à representada na Fig. 23, onde se encontra o DFI do sistema RecHum.
Capítulo 5: Validação do Método 97
A terceira opção mostra a janela representada na Fig. 36 , onde se encontram todos os domínios existentes em RecHum, embora, por falta de espaço, seja somente possível observar o domínio ResProc. Em termos de diagnósticos, e ao aplicar a Tabela de Relações de Entrada/Saída de Informação (apresentada no capítulo 3), vai-se obter os diagnósticos mostrados na Fig. 36.
Capítulo 5: Validação do Método 98
A quarta opção mostra a janela representada na Fig. 38, onde se encontram todos os documentos existentes em RecHum, embora, por falta de espaço, seja somente possível mostrar parte do documento Recibo. Nesta janela, aparecem diagnósticos que informam a existência de uma eventual omissão na informação de alguns documentos, neste caso da descrição. Existe outro diagnóstico informando que o documento Inf_Trab parece ser redundante no domínio ResProc, ou seja, este documento pode não ser necessário, porque a informação que contém não é utilizada por nenhum outro documento no domínio de destino deste documento, neste caso ResProc.
Capítulo 5: Validação do Método 99
A quinta opção mostra a janela representada na Fig. 39, onde se encontram todos os campos existentes em RecHum, embora, por falta de espaço, seja somente possível mostrar alguns desses campos. Como se pode observar, para cada campo é mostrado todos os documentos onde esse campo ocorre, o seu conteúdo se o campo for da classe Fórmula ou Constante e o documento que fornece esse campo ao sistema RecHum desde que o campo não seja da classe Fórmula ou Constante.
Capítulo 5: Validação do Método 100
A sexta opção mostra a janela representada na Fig. 40, onde se encontram todos os Ficheiros existentes em RecHum, embora, por falta de espaço, seja somente possível mostrar alguns dos ficheiros existentes. Para cada ficheiro são mostrados, em termos de diagnósticos, os campos que não são utilizados, o que, em princípio, pode permitir a sua eliminação.
Capítulo 5: Validação do Método 101
A sétima opção mostra a janela representada na Fig. 41, onde se encontram todos os processos existentes em RecHum, embora, por falta de espaço, seja somente possível mostrar alguns dos processos existentes. A descrição dos processos, neste momento, é bastante reduzida, mostrando-se somente os documentos necessários para produzir os documentos de saída desse processo. Para cada um, apresenta-se um diagnóstico a informar se o processo é redundante, o que poderia implicar a sua eliminação.
Capítulo 5: Validação do Método 102
A oitava opção divide-se em duas janelas, ver Fig. 42 e Fig. 43, onde se encontra o Diagrama de Fluxos de Dados (DFD) do sistema RecHum. Sublinha-se que o DFD não faz parte do método ASA, mas é apresentado como uma forma de permitir provar a validade do método, ou seja, poder verificar, de uma forma bastante simples (gráfica), o processo automático de geração de informação existente.
A Fig. 42 apresenta o diagrama de contexto e a Fig. 43 o diagrama 0 do sistema em estudo. É importante realçar que os DAux's (Documentos auxiliares) são documentos gerados por ASA de forma a poder satisfazer os documentos internos (ver no capítulo 4 o Diagrama de Fluxos de Informação Interno, DFII). Os processos e ficheiros são também gerados pelo DFII. No Diagrama 0, mostra-se a diferença entre os documentos que são gerados por entidades internas, ou que têm como origem uma entidade interna (pequeno quadrado todo escuro) e aqueles que têm como origem ou destino uma entidade externa (pequeno quadrado com o interior a branco).
Capítulo 5: Validação do Método 103
Fig. 42 - Consulta do diagrama de contexto do sistema RecHum
Capítulo 5: Validação do Método 104
A nona opção mostra a janela representada na Fig. 44, onde se encontram as entidades internas geradas para o sistema RecHum, embora, por falta de espaço, seja somente possível visualizar algumas dessas entidades. Estas entidades têm como função fornecer informação existente em documentos cuja origem são domínios externos, e por outro lado, criar documentos auxiliares para fornecer informação a documentos internos
Capítulo 5: Validação do Método 105
RESULTADOS
Depois de uma breve explicação do funcionamento do protótipo ASA e da visualização dos resultados obtidos, é pertinente, neste momento, validar esses resultados, através do seguinte critério:
.
uma forma de validar esses resultados é analisar o DFD da Fig. 43, assim:o um dos processos iniciais é ResProc_4, este processo recebe o
fluxo de informação IRS e guarda-o no ficheiro Fich_2 (para posterior utilização);
o outro processo inicial é Admissao_2, este processo recebe os
fluxos Inform e DAux_1 (devido à resposta à questão da Fig. 33 ter sido positiva) e guarda essa informação no ficheiro Fich_1;
o o processo Admissao_1 produz, a partir da informação existente no
Fich_1, o fluxo Inf_Trab. Este fluxo não tem influência na produção de qualquer outro fluxo de informação e, desta forma, pode ser considerado redundante (o seu destino é uma entidade interna, que em princípio, utiliza este fluxo para unicamente efectuar consultas ao seu conteúdo) ;
o o processo ResProc_3 produz, a partir da informação existente no
Fich_1 (cadastro do trabalhador), Fich_2 (Tabela de IRS) e DAux_2 (Data do processamento mais os dias de ausência dos
Capítulo 5: Validação do Método 106
trabalhadores), o fluxo Recibo. Devido ao processo ResProc_5 necessitar de informação que existe neste processo, ocasiona que este processo produza ainda os ficheiros Fich_3 e Fich_4;
o o processo ResProc_5 produz o fluxo Receita, a partir da
informação existente em Fich_3 (igual à informação de DAux_2) e Fich_4 (contém a informação do Recibo).
.
comparar o DFD gerado por ASA (ver Fig. 43) com o DFD (ver Fig. 45) elaborado por um Analista de Sistemas (com vários anos de experiência nesta função). Pela análise dos dois diagramas verifica-se que as diferenças são mínimas. Salienta-se, contudo, que a maior diferença nos dois DFD's é devido à existência do Fich_3 e Fich_4 para produzir o documento Receita, ver Fig. 43. Esta diferença é devido:Capítulo 5: Validação do Método 107
o ao processo de geração automática de informação, proceder à
procura da origem da informação. Como os campos Ano e Mes fazem parte do documento Receita e esses campos têm como
Admissão Trabalhador Inf_Trabalh Trabalhadores Emissão Recibo Gestão IRS Inf_IRS IRS Envia Finanças Pagamentos IRS_Retido Recibo_Venc IRS
Capítulo 5: Validação do Método 108
origem o documento DAux-2, logo ASA vai buscar essa informação ao documento DAux-2. Devido à diferença das frequências dos documentos Receita e DAux-2, ASA criou o ficheiro Fich_3 para poder satisfazer a produção do documento Receita.
o ao documento Receita incluir um campo, denominado Dedu, que
existe somente no documento Recibo. Este campo, por ser do tipo fórmula, implica que, ASA não tenha necessidade, no processo ResProc_5, de proceder novamente a esse cálculo. Assim, ASA vai buscar esse campo ao documento Recibo, mas devido à diferença de frequências entre os dois documentos, ASA tem que criar um ficheiro, chamado Fich_4, para transportar esse campo entre os dois processos.
.
verificar se houve aumento de detalhe da informação inicialmente fornecida. Assim, em termos de Arquitectura de Informação, verifica-se que a informação, gerada por ASA, tem um nível de detalhe diferente daquele que lhe foi inicialmente fornecido (ver Tabela 2). Porque, a informação fornecida, em termos de funções, encontra-se ao nível da Descrição da Organização e a informação gerada está ao nível da Descrição do Sistema de Informação.Ao analisar os resultados, segundo as perspectivas atrás referidas, conclui- se que o DFD gerado pelo ASA, para além de ser optimizado, satisfaz o sistema RecHum e a informação gerada por ASA têm um nível de detalhe superior ao inicial.
Capítulo 5: Validação do Método 109
5.4 RESUMO
A validação do método é conseguida através da introdução de um exemplo no protótipo ASA. Esse exemplo permitiu provar que:
.
se evitou a ambiguidade e redundância no diálogo com o utilizador através do uso de facilidades gráficas, tal como foi utilizado no momento da definição do DFI;.
na visualização dos resultados/diagnósticos, houve o cuidado de os mostrar de forma a facilitar a leitura;.
existe qualidade nos resultados gerados pelo protótipo, através da análise do DFD gerado por ASA;.
os resultados gerados por ASA têm um nível de detalhe diferente e superior ao da informação inicialmente fornecida pelo "perito de domínio".CAPÍTULO 6
C O N C L U S Ã O
Capítulo 6: Conclusão 111
O objectivo principal deste trabalho consistiu em validar e refinar um