TESE Mestrado Jorge Oliveira e Sá

ASA - ANLISE DE SISTEMAS AUTOMTICA
por

Jorge Vaz de Oliveira e S

Tese submetida

UNIVERSIDADE DO MINHO

para obteno do grau de MESTRE EM INFORMTICA

Especialidade em Informtica de Gesto

Departamento de Informtica
Universidade do Minho Dezembro de 1993

AGRADECIMENTOS

Em primeiro lugar, os meus agradecimentos especiais para o supervisor, Dr.
Antnio Godinho, que esteve sempre presente, durante o desenrolar deste trabalho,
atravs das suas valiosas sugestes e anotaes.

Para os meus Pais, pelo apoio incondicional sem o qual esta tese no teria
sido possvel.

Para o Eng. Luis Amaral e Dr. Joo Alvaro, pelas suas sugestes e crticas

Para Gil Brites, que demonstrou uma amizade especial em todos os
momentos.

Para Paula Cardoso, pelas suas preciosas palavras de encorajamento e
amizade.

Para todos os outros meus colegas, amigos e familiares, pelo interesse
demonstrado ao longo deste trabalho.

Junta Nacional de Investigao Cientifica e Tecnolgica, atravs do seu
Programa Cincia, a concesso de uma Bolsa de Estudos.

SUMRIO

A produtividade da equipa de desenvolvimento e a qualidade das aplicaes
produzidas so dois dos principais problemas que ainda persistem no
desenvolvimento de Sistemas de Informao. Estes problemas existem devido ao
desenvolvimento de aplicaes informticas ser ainda do tipo "papel e lpis" e estar
fortemente, dependente, da experincia da equipa de desenvolvimento, o que implica
consequentemente o aparecimento de inmeras falhas e/ou lapsos.

ASA, Anlise de Sistemas Automtica, o resultado de uma tentativa de
soluo dos problemas anteriores. ASA composto por um mtodo de anlise e uma
ferramenta de desenvolvimento de aplicaes, concebida com o propsito de permitir
tirar partido das vantagens da automatizao.

Este projecto consiste em refinar e validar ASA. Para o efeito foi construdo
um prottipo com o objectivo de, incrementalmente, refinar e validar as tcnicas e
as respectivas notaes adoptadas em ASA.

ASA, permite automatizar de uma forma simples, rpida e eficiente a
actividade de Anlise de Sistemas de Informao. Desta forma, para alm de garantir
a fiabilidade da informao, permite a manipulao e fornecimento da mesma pelo
utilizador, o "perito de domnio". Consequentemente, ASA possibilita gerar
resultados a partir da especificao inicial, soluciona parte do problema de
manuteno das aplicaes e uma tentativa de reduo do tempo e custo do
desenvolvimento de Sistemas de Informao.

NDI CE

Captulo 1: Introduo ................................................................................................. 1

1.1 Viso geral .................................................................................................. 2
1.2 Tema do Projecto ........................................................................................ 7
1.3 Abordagem ao Projecto ............................................................................... 9
1.4 Organizao do Relatrio ............................................................................ 10

Captulo 2: Fundamentos tericos ............................................................................... 12

2.1 Definio de sistema .................................................................................... 13
2.2 Sistema de Informao ................................................................................ 16
2.2.1 Metodologia de Desenvolvimento de Sistemas de Informao ............ 17
2.2.2 Ferramentas ....................................................................................... 23
2.2.3 Arquitectura de Informao ............................................................... 25
2.4 Enquadramento com ASA .......................................................................... 28

Captulo 3: Estudo do Mtodo ..................................................................................... 29

3.1 Evoluo do Mtodo ................................................................................... 30
3.2 Entrada de Informao ................................................................................ 31
3.2.1 Diagrama de Fluxos de Informao .................................................... 31
3.2.2 Descrio da Informao ................................................................... 39
3.3 Automatizao ............................................................................................ 39
3.3.1 Matriz de Redundncia Mltipla ........................................................ 39
3.3.2 Tabela de Relaes de Entrada/Sada de Informao .......................... 43
3.3.3 Diagrama de Fluxos de Informao Interna ......................................... 44
3.4 Trabalhos Anteriores .................................................................................... 49
3.5 Caracterizao do Mtodo ........................................................................... 51
3.6 Resumo ...................................................................................................... 55

ndice

Captulo 4: Refinamento do Mtodo ........................................................................... 59

4.1 Objectivos a Atingir ..................................................................................... 60
4.2.1 Diagrama de Fluxos de Informao .................................................... 62
4.2.2 Descrio da Informao ................................................................... 63
4.3 Automatizao ............................................................................................ 64
4.3.1 Diagrama de Fluxos de Informao Interna ........................................ 65
4.4 Ferramenta ASA .......................................................................................... 69
4.5 Caracterizao do Mtodo ........................................................................... 74
4.6 Resumo ....................................................................................................... 78

Captulo 5: Validao do Mtodo ................................................................................ 79

5.1 Abordagem .................................................................................................. 80
5.3 Automatizao ............................................................................................ 93
5.4 Resumo ....................................................................................................... 109

Captulo 6: Concluso .................................................................................................. 110

Bibliografia ................................................................................................................... 115

Anexos:
A -Exemplos
B -Lista de mtodos
C -Glossrio

CAPTULO 1

I NTRODUO

O tema deste projecto consiste em refinar e validar um mtodo, cuja
particularidade permitir automatizar algumas fases do Ciclo de Vida de
Desenvolvimento de Aplicaes Informticas. Este mtodo denominado por ASA -
Anlise de Sistemas Automtica.

Este captulo comea por apresentar as dificuldades de aceitao de
mtodos de desenvolvimento de Sistemas de Informao, devido ao nvel de
maturidade informtica existente. Descreve as necessidades de utilizao de
ferramentas CASE (Computer Aided Software Engineering) e sublinha a importncia
de se investigarem ferramentas que cubram e automatizem o Ciclo de Vida de
Desenvolvimento de Aplicaes Informticas.

Captulo 1: Introduo 2

1.1 VISO GERAL

Hoje em dia, para que uma organizao seja competitiva, tem que dispor de
informao fivel de uma forma oportuna. No entanto, a quantidade de informao
existente atinge, por vezes, propores elevadas, o que, para alm do seu
processamento, implica uma grande sofisticao e complexidade no controlo da
mesma. A informatizao das organizaes, atravs da construo de aplicaes
informticas, permite colmatar esta necessidade.

Neste momento, uma grande maioria das aplicaes existentes no consegue
satisfazer todas as necessidades definidas pelos seus proponentes. Isto deve-se
essencialmente ao facto de o processo de desenvolvimento de aplicaes
informticas ainda ser do tipo "papel e lpis", o que implica, logicamente, o
aparecimento de inmeras falhas e/ou lapsos.

Existe consenso de que quem desenvolve aplicaes informticas no
consegue fazer uso efectivo de novas ferramentas e mtodos, mesmo sendo
adequados, enquanto no atingir um determinado estdio de maturidade. O estdio
de maturidade necessrio para adoptar e utilizar ferramentas e mtodos, corresponde
ao terceiro dos seguintes cinco nveis [Humphrey, 1988]:

1. Nvel inicial - No existe um processo formal, consistncia e normas de
como as aplicaes informticas devem ser desenvolvidas. Cada analista
considera-se um artista.


2. Nvel repetio - As pessoas esto de acordo acerca de "como se devem
fazer as coisas", embora no exista um processo bem formalizado e escrito.
O sucesso depende das capacidades individuais dos gestores de projecto.

3. Nvel definio - Existe um processo de desenvolvimento de aplicaes
bem formalizado e documentado, embora este processo ainda seja pouco
qualitativo, devido quase inexistncia de indicadores de aferio da
eficincia do processo. Contudo, fornece as bases para uma melhor
compreenso do processo de desenvolvimento de aplicaes.

4. Nvel gesto - Est institucionalizado um processo mtrico formal para
medir o desenvolvimento das aplicaes.

5. Nvel ptimo - So utilizadas as medidas do nvel anterior como
mecanismo de "feedback", para melhorar as partes do processo que no se
encontram ainda optimizadas.

ainda referido [Humphrey, 1988] que, nos ltimos anos da dcada de 80,
85% das organizaes americanas, que desenvolvem aplicaes informticas, se
encontravam ainda no primeiro nvel, enquanto 10% a 12% se encontravam no
segundo nvel, somente cerca de 3% estavam no terceiro nvel e nenhuma se
encontrava no quarto ou quinto nvel.

Esta informao reflecte a mentalidade dos gestores acerca do "paradigma
da mudana", pois, geralmente, no se adopta um novo mtodo e/ou ferramenta para
resolver os problemas mais rapidamente ou eficientemente, devido existncia de


custos de fazer a mudana e porque o ser humano tem uma inrcia natural e, por
vezes, resistncia para aprender coisas novas.

Se a maior parte das organizaes que desenvolvem aplicaes
informticas, ainda se encontram num nvel de maturidade informtica muito
elementar, porque pensam, erradamente, que o desenvolvimento de aplicaes
pode prescindir de ferramentas dedicadas. Deve-se contudo realar que, quando se
fala em ferramentas dedicadas, no se pretende referir aos seguintes tipos de
ferramentas: editores, compiladores, "drivers" para gerir os dispositivos de entrada e
sada, etc.

As aplicaes informticas podem ser classificadas como ferramentas de
trabalho por quem as utiliza, porque ajudam esses utilizadores a automatizarem
determinadas tarefas e assim aumentarem a produtividade e a qualidade do seu
trabalho. No entanto, essas mesmas aplicaes informticas ainda so, muitas das
vezes, construdas manualmente, sem ajuda de qualquer ferramenta de
desenvolvimento que automatize e verifique a consistncia de todas as fases da
construo dessas aplicaes. Assim, urge adoptar ferramentas, que permitam cobrir
e automatizar o Ciclo de Vida de Desenvolvimento de Aplicaes Informticas
(CVDAI), ver Fig. 1, e consequentemente aumentar a produtividade das equipas de
desenvolvimento e a qualidade final das aplicaes informticas.

Estas ferramentas ao serem suportadas por computadores, so denominadas
por CASE (Computer Aided Software Engineering) de forma a granjearem da
credibilidade conseguida por outras ferramentas de distintas reas de engenharia,
como por exemplo: CAD (Computer Aided Design) e CAM (Computer Aided
Manufacturing). A maioria das ferramentas CASE existentes cobrem e automatizam


partes do CVDAI, normalmente as fases finais, havendo mesmo algumas ferramentas
CASE que comeam na fase de Desenho fsico, o que implica que se tenha a ideia de
que as ferramentas CASE, servem somente para "facilitar e tornar rigorosa, a tarefa
de programao" [Towner, 1989]. No entanto, uma definio mais correcta de
CASE, proposta pelo mesmo autor, que "CASE uma ferramenta que permite
ajudar a organizar, estruturar e simplificar o processo de desenvolvimento de
aplicaes".

A ocorrncia de determinados erros e omisses provocada,
frequentemente, pelas actividades iniciais do CVDAI, tal com se pode aperceber ao
Codificao
Implementao
Desenho
Desenho
Especificao
de Requisitos
Fig. 1 - CVDAI - Ciclo de Vida de Desenvolvimento de Aplicaes Informticas
fsico
lgico
e testes


analisar a Fig. 2. A, mostra-se um esquema que permite entender a ocorrncia de
problemas durante a actividade de desenvolvimento de aplicaes informticas, tais
como:

.por vezes torna-se complicado definir o contorno do sistema a tratar,
isto , definir a fronteira e comunicaes entre a aplicao a desenvolver
e o seu ambiente exterior, adoptando-se, muitas das vezes, vises
demasiado simplistas;

.construo de sistemas demasiado grandes obriga a que o tempo de
desenvolvimento de aplicaes seja bastante longo, podendo mesmo
demorar anos, ocasionando possveis alteraes nos requisitos iniciais do
sistema;

.os processos de desenvolvimento so orientados para o programador,
descurando-se as actividades iniciais do sistema a tratar;

.existem falta de directrizes no desenvolvimento, fazendo com que
possam haver problemas de comunicao entre a aplicao e o seu
ambiente exterior, a partir do momento em que a aplicao esteja pronta
a funcionar, pois poder j estar desenquadrada em relao ao seu
ambiente.

Em jeito de concluso, pode-se afirmar que, para uma ferramenta CASE
ajudar a desenvolver, de uma forma rpida, melhores aplicaes, deve cobrir todo o
CVDAI e automatizar as etapas de especificao e desenho, o que possibilitar
reduzir em termos de tempo e custo o desenvolvimento de aplicaes. Essa reduo,


pode resultar, somente, da eliminao da tarefa de corrigir os erros introduzidos nas
etapas iniciais do CVDAI.

1.2 TEMA DO PROJECTO

O projecto proposto consiste no refinamento e validao de um mtodo,
denominado por ASA - Anlise de Sistemas Automtica. ASA surgiu em 1987
[Godinho e Lopes, 1987] como consequncia de um estudo e comparao de
algumas tcnicas e notaes, tendo dado origem a projectos com o objectivo de
testar e, em particular, procurar provar a viabilidade de um processo de gerao
automtica de informao [Godinho e Lopes, 1988].

Mundo Real
Sistema
Implementao
Especificao
de Requisitos
Fig. 2 - Problemas no CVDAI
Codificao Desenho Desenho
lgico fsico e testes


ASA permite cobrir o CVDAI, realando, tal como o seu nome diz, as
etapas iniciais, pois , especialmente, nessas etapas que se torna crtica a tarefa de
recolha e obteno de informao, de forma, a se poder obter uma viso global do
sistema, para, posteriormente, ser possvel definir, correctamente, o que o sistema
deve fazer.

Deste modo, o analista de sistemas deve assumir um papel de consultor, ao
guiar, supervisionar e motivar o utilizador, de forma a obter uma definio e
especificao correcta do sistema em estudo. A participao do utilizador crucial
no processo de desenvolvimento, especialmente nas primeiras fases.

Na etapa de especificao de requisitos, o analista informtico recolhe
informao atravs da utilizao de tcnicas, tais como, por exemplo: entrevistas
e/ou inquritos, que obrigam existncia de dilogo com os fornecedores de
informao, ocasionando possveis entradas de erros ou ms interpretaes da
informao. Assim, ASA pode ser visto como um meio de comunicao entre o
analista e os fornecedores de informao, ao permitir a ligao com o fornecedor de
informao a fim de obter a informao necessria, para modelar, de modo correcto,
o problema objecto. Desta forma, ASA, tem como objectivo principal, conseguir que
os fornecedores de informao possam, eles mesmos, definir os requisitos do sistema
que pretendem informatizar, eliminando, deste modo, possveis entradas de erros no
sistema a desenvolver.

O uso do fornecedor de informao ou do utilizador (denominado por
"perito do domnio") como principal interlocutor de ASA, faz com que este mtodo
se distinga de todos os existentes. Assim, o nvel da informao fornecida tem que


ser bastante prxima do nvel de informao do funcionamento do posto de trabalho
ou do domnio conhecido pelo utilizador.

Devido a estas caractersticas, ASA pode ser dividido em duas grandes
componentes, sendo ambas igualmente importantes para o seu funcionamento:

.Entrada de Informao - O dilogo entre ASA e o utilizador deve ser o
mais simples possvel, de forma a que seja mais fcil guiar e acompanhar
o utilizador na actividade de fornecimento de informao, apresentando,
sempre que seja necessrio, mensagens de diagnstico a informar o
estado e consistncia da informao fornecida.

.Processamento da Informao - A partir da informao fornecida pelo
utilizador, ASA gera automaticamente um conjunto diverso de
informao, composto em diversos relatrios que permitem avaliar e
compreender o Sistema de Informao que se est a desenvolver.

1.3 ABORDAGEM AO PROJECTO

Antevendo-se a efectiva possibilidade de automatizar o processo de
desenvolvimento de aplicaes informticas, o mtodo ASA, inclui tcnicas e
notaes que ainda no foram completamente testadas nem validadas. Assim,
objectivo deste projecto proceder ao seu teste e validao, para que seja possvel
refinar e evoluir o prprio mtodo.


Esta automatizao obriga a um dilogo bastante cuidado, visto os seus
utilizadores no necessitarem de ter conhecimentos de mtodos de anlise
informtica e de informtica de uma forma geral. Este dilogo entre o computador e
o utilizador deve ser simples e flexvel, para que a tarefa de fornecimento de
informao, por parte dos utilizadores, tambm o seja. O que implica que o nvel de
abstraco da informao, fornecida pelo utilizador, esteja o mais prximo possvel
do "Mundo Real" ou do nvel de informao que conhece.

Partindo dos pressupostos anteriores, verifica-se que a melhor aproximao
para resolver este projecto atravs da elaborao de um prottipo. Esse prottipo,
deve permitir, desde o inicio da sua construo, validar o mtodo ASA e possibilitar
o ajuste e refinamento das suas regras. Esta aproximao pode ser denominada por
incremental, pois pode ser descrita como um ciclo onde os resultados do prottipo
servem de entrada para o seu prprio desenvolvimento, garantindo, ao mesmo tempo,
o cumprimento dos pressupostos inicias.

1.4 ORGANIZAO DO RELATRIO

Este captulo comeou com uma viso geral do problema a tratar, seguido
do tema do projecto e da forma como foi realizado.

seguido do captulo 2, onde se apresentam os fundamentos tericos
necessrios para a elaborao deste projecto, compreendendo definies sobre
sistemas, sistemas de informao e mtodos. Como complemento apresenta-se no
Anexo C, um breve glossrio dos principais termos abordados.


No captulo 3, apresentado e descrito o mtodo ASA tal como existia no
momento em que este projecto se iniciou.

As alteraes efectuadas no mtodo ASA, so apresentadas no captulo 4,
de forma a permitir a evoluo e aperfeioamento do mesmo.

A validao do mtodo ASA, efectuada atravs da introduo de um
exemplo e anlise dos resultados do prottipo, apresentada no captulo 5.

Finalmente, no captulo 6, as concluses acerca deste projecto e sugestes
para trabalhos futuros so apresentadas.

CAPTULO 2

FUNDAMENTOS TERI COS

Este captulo, comea por definir o que um Sistema, de forma a que se
possa, posteriormente, entender o conceito de Sistema de Informao.

Para os Sistemas de Informao descrevem-se os significados de
Metodologia, Mtodo, Modelo, Tcnica e Notao, para que, mais facilmente, se
possa entender o mtodo ASA.

Apresenta-se um esquema de Arquitectura de Informao, que permite
compreender os nveis de detalhe da descrio da informao.

Por fim, apresenta-se o enquadramento dos conceitos apresentados neste
captulo com o mtodo ASA.

Captulo 2: Fundamentos Tericos 13

2.1 DEFINIO DE SISTEMA

Um sistema composto por conjuntos de componentes, que se relacionam
entre si de forma a atingir um objectivo comum. Assim, pode-se catalogar como
sistema, por exemplo: seres humanos, organizaes e mesmo fbricas.

Existem outras definies de sistema, como:

."um sistema pode ser definido como uma agregao de objectos juntos
numa interaco ou interdependncia regular" [Gordon, 1969];

." um conjunto de matria, partes ou componentes as quais esto
includas dentro de uma especfica, por vezes arbitrria fronteira"
[Shearer, Murphy e Richardson, 1967].

No entanto, entre muitas outras, existe uma definio mais completa
[Rosnay, 1975], "Um sistema um conjunto de elementos em interaco dinmica,
organizados em funo de um objectivo". Esta definio inclui trs conceitos
cruciais: "... um conjunto de elementos..." transmite a ideia de estrutura do sistema,
"...em interaco dinmica..." define o funcionamento do sistema em funo do
factor tempo e "...em funo de um objectivo" introduz a ideia da finalidade do
sistema ou objectivo.

A definio de sistema incompleta sem a noo de ambiente. Um sistema
parte de um universo e est fechado pelo ambiente no qual opera. Uma mudana no
ambiente pode afectar o sistema e vice-versa. As interaces entre o sistema e o


ambiente so consideradas entradas e sadas, as quais podem ser de trs tipos:
energia, matria e informao.

Existe uma outra definio de sistema que inclui o conceito de ambiente
[Moigne, 1977]. "Um sistema :

. algo (identificvel);

. faz algo (actividade, funo);

. tem uma estrutura;

. altera-se ao longo do tempo;

. est dentro de algo (ambiente); e

. serve para alguma coisa (objectivo)."

Um sistema pode tambm ser descrito atravs de dois pontos de vista , viso
estrutural e funcional [Rosnay, 1975]:

.aspectos estruturais englobam a fronteira, componentes, reservatrios e
redes de comunicaes do sistema; e

.aspectos funcionais englobam o tempo, passado, fluxos e centros de
deciso do sistema.


Alguns autores neste campo classificam os aspectos estruturais e funcionais
de um sistema como estticos e dinmicos, respectivamente.

Como os sistemas so complexos, cada componente referida nos aspectos
estruturais de um sistema pode ser considerada um sistema. Assim, um sistema pode
ser subdividido em subsistemas e, por seu turno, os subsistemas podem-se subdividir
novamente, Fig. 3.

Em concluso:

.um sistema composto por diferentes componentes;

.as componentes do sistema trabalham em conjunto com a finalidade de
atingir o objectivo do sistema;

.as componentes tm relaes com elas mesmas, criando a estrutura do
sistema;
SISTEMA
SISTEMA
SUB-
SISTEMA
SUB-
SISTEMA
SUB-
SISTEMA
SUB-
SISTEMA
SUB-
SISTEMA
SUB-
Fig. 3 - Conceito de Sistema


.um sistema limitado por uma fronteira;

.um sistema tem sempre um ambiente;

.um sistema tem a sua prpria maneira de interactuar com o ambiente,
denominada por comportamento do sistema;

.um sistema tem um ciclo de vida: evoluo, maturidade, manuteno e
finalmente a morte.

2.2 SISTEMA DE INFORMAO

Actualmente, reconhecido que as organizaes necessitam cada vez mais
de Sistemas de Informao. Um Sistema de Informao pode ser "definido como o
mecanismo que fornece os meios de armazenar, gerar e distribuir informao..."
[Layzell e Loucopoulos, 1986] e pode ser classificado como manual, informatizado
ou misto. obvio, que neste projecto o objectivo focar os Sistemas de Informao
que possam ser, ou vir a ser, suportados por computadores.

Para exemplificar o conceito de Sistema de Informao, apresentam-se na
Tabela 1, diversos tipos de possveis Sistemas de Informao [Projecto AMADEUS,
1986].


2.2.1 METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS DE
INFORMAO

A Metodologia a cincia do mtodo, isto , um tratado ou dissertao
sobre o mtodo, ou pode tambm ser vista como a cincia que estuda os mtodos.
Sistemas de Informao
Escritrio
Sistemas de Arquivo
Sistemas de Processamento de Documentos
Sistemas de Comunicaes
Controlo
Processamento de Dados Administrativos
Sistemas de Controlo de Produo
Sistemas de Comando e Controlo
Controlo de Processos em Tempo Real
Sistemas de Robtica
Conhecimento
Transferncia
de
Obteno de Informao
Sistemas de Ensino
Traduo de Linguagens
Planeamento,
Desenho e
Resoluo de
Problemas
Sistemas de Fabrico e Desenho
Sistemas de Apoio Deciso
Sistemas Cientficos e Estatsticos
Sistemas Periciais
Tabela 1 - Exemplos de Sistemas de Informao


Assim, uma metodologia pode ser composta por um ou mais mtodos, sendo
cada mtodo constitudo por um conjunto de tcnicas integradas e cada tcnica usa
uma notao, ver Fig. 4.

MTODOS

A cada vez maior complexidade dos Sistemas de Informao motivou o
aparecimento de mtodos, com o objectivo de melhorar a qualidade dos sistemas
finais e facilitar o seu desenvolvimento.

Metodo-
logia
Mtodo
Tcnica Notao
Fig. 4 - Relaionamento entre Metodologia, Mtodo, Modelo, Tcnica e Notao
Legenda
Relao 1:1
Relao 1:N
Relao N:N
Modelo


Mtodos podem ser descritos como as indicaes, os passos a seguir, para o
melhor desenvolvimento de Sistemas de Informao.

Existem mais de uma centena de mtodos (ver no Anexo B uma lista de
mtodos existentes), os quais foram desenvolvidos nas ltimas duas dcadas [Layzell
e Loucopoulos, 1986] no existindo um mtodo claramente favorito e normalmente a
opo pela sua utilizao levanta alguns problemas.

Cada mtodo tem as suas caractersticas e particularidades, mas todos
partilham conceitos comuns, o que poder causar confuso no campo da anlise de
sistemas e mtodos de desenvolvimento, devido a:

.alguns mtodos utilizarem os mesmos termos no seu desenvolvimento,
mas esses termos podero ter diferentes significados, dependendo do
mtodo em questo;

.mtodos diferentes partilharem notaes e tcnicas comuns. Contudo, a
combinao tcnica/notao escolhida depende de cada mtodo;

.todos os mtodos terem por objectivo modelar o sistema, mas o
elemento de modelao do sistema poder ser diferente, dependendo do
mtodo.

Pode-se concluir que um mtodo "consiste numa coleco de tcnicas,
notaes e procedimentos formais ou semi-formais" [Blokdijk A. e P., 1987], tal com
j foi apresentado na Fig. 4.


MODELOS

A anlise de sistemas e mtodos de desenvolvimento no conseguem, num
nico passo, descrever um sistema na sua forma final, para isso socorrem-se de
modelos que permitem representar um sistema complexo de uma forma mais
acessvel e compreensvel.

Trs vises de modelos podem ser reconhecidas [Blokdijk A. e P. , 1987]:

.Viso lgica - descreve de uma forma abstracta mas perceptvel para o
utilizador (pois no utiliza termos tcnicos) como que o mundo real
ser no futuro;

.Viso fsica - mostra como o sistema aparecer tecnica e fisicamente ao
utilizador;

.Viso de implementao - descreve a forma como o sistema ser
implementado informaticamente, em termos de dados (bases de dados),
funes (programas/procedimentos) e comunicaes (rede de dados).

TCNICAS

Uma tcnica um conjunto de processos, baseados em conhecimentos
cientficos e no empricos, utilizados para obter um certo resultado; pode ser vista
como a cincia que est por detrs de uma notao.


Existem muitas tcnicas na rea de desenvolvimento de Sistemas de
Informao, onde se pode realar:

.Decomposio Funcional - decompor funes incrementando os nveis
de detalhe [Stevens, 1974];

.Normalizao de dados - remover redundncias e relaes que podero
causar anomalias na operao de armazenamento dos dados
[Codd, 1970];

.Processos estruturados - fornecer uma receita para descrever os
processos: um processo s poder ter uma entrada e uma sada; so
permitidos unicamente a sequncia, seleco e interaco de processos
[Dijkstra, 1972];

.Reviso estruturada - encontrar erros: por omisso, contradio, ou um
erro lgico de qualquer tipo [Yourdon, 1986];

NOTAES

Uma notao um conjunto de caracteres, smbolos ou abreviao de
expresses usados para exprimir factos tcnicos.


Cada modelo do Sistema de Informao, construdo atravs de um mtodo
de desenvolvimento de sistemas, ter que estar de acordo com as notaes suportadas
por esse mtodo.

Existe um grande nmero de notaes usadas por diferentes mtodos. Por
conseguinte, mostra-se, de uma forma no exaustiva, diversas notaes existentes:

.Data Flow Diagram (DFD) - usado para mostrar o fluxo dos dados
atravs do sistema [Gane, 1979; DeMarco 1979];

.Portugus Estruturado - usado para descrever os processos atravs de
combinaes simples de frases na forma imperativa [DeMarco, 1979];

.rvores de deciso - usadas para exprimir condies e aces dentro de
um processo [DeMarco, 1979];

.Dicionrio de Dados (DD) - usado como repositrio de definies e
todos os nomes dos dados [Gane e Sarson, 1979];

.Grfico estruturado - usado para especificar a hierarquia dos mdulos
e as relaes entre eles [Yourdon e Constantine, 1987];

.Diagrama de entidades e relacionamentos (E-R) - usado para realar o
relacionamento entre as diversas entidades [Chen, 1977];


.Diagrama de transio de estados - usado para representar estados e a
transio entre dois estados, a entrada dispara a transio e a sada a
resposta do sistema [Macdonald, 1986].

2.2.2 FERRAMENTAS

O desenvolvimento de Sistemas de Informao gera um grande volume de
informao que necessita de ser capturada e analisada. Os mtodos e as notaes
podem ajudar nesse processo de desenvolvimento, mas a sua automatizao que os
torna realmente utilizveis para manusear o volume de informao existente.

Os mtodos e notaes so essenciais para uma correcta utilizao de
ferramentas, no entanto sem ferramentas a maioria, daqueles que desenvolvem
aplicaes informticas, no conseguiriam aproveitar todas as vantagens da sua
utilizao. Em verdade, isto no mais que a reafirmao de que a tarefa de
desenvolvimento de Sistemas de Informao no pode ser executada adequadamente,
sem uma aproximao metdica suportada por ferramentas.

Como as aplicaes cada vez se tornam mais complexas, os mtodos tm
que se adaptar e evoluir para permitirem o manuseamento dessa complexidade. Por
outro lado, utilizar esses mtodos sem a existncia de uma ferramenta que os suporte,
torna-se uma tarefa impensvel. Assim, ao haver a disponibilidade de mtodos e
ferramentas adequadas, torna-se exequvel o desenvolvimento de aplicaes
informticas mais complexas. Esta situao pode ser considerada como um ciclo que
tem como resultado imediato o aparecimento de ferramentas bastante potentes.


Este tipo de ferramentas pode ser denominado por CASE (Computer Aided
Software Engineering) que , sem duvida, um dos acrnimos mais falados na rea
ligada ao desenvolvimento de Sistemas de Informao. Embora "no exista uma
definio real do que uma ferramenta CASE" [Towner, 1989], entende-se que uma
ferramenta CASE deve "documentar e modelar um Sistema de Informao desde os
requisitos inicias dos utilizadores, passando pelas fases de desenho e implementao
e ainda permitir aplicar testes de consistncia, correco e validao das normas pr-
estabelecidas" [Chikofsky e Rubenstein, 1988].

A actividade de desenvolvimento de Sistemas de Informao, gera um
grande volume de informao que tem que ser capturada e analisada pelo analista.
As ferramentas CASE permitem ajudar o analista nessa actividade e o seu uso pode
tornar-se um factor crtico de sucesso. Assim, as ferramentas CASE tero que evoluir
segundo as seguintes perspectivas:

.utilizar interfaces grficas;

.utilizar repositrios de informao que permitam ser transferidos de
umas ferramentas para outras;

.permitir cobrir todo o ciclo de vida de desenvolvimento e automatizar
algumas das fases.

Existe um grande nmero de ferramentas CASE disponveis, que suportam
diversos mtodos de desenvolvimento de Sistemas de Informao. Devido a essa
diversidade, "uma ferramenta CASE pode ser mais adequada de que outras, para


auxiliar o desenvolvimento de determinados tipos de Sistemas de Informao"
[Lopes, 1990].

Desta forma, o futuro das ferramentas CASE passa pela integrao de vrios
mtodos numa nica ferramenta, que com um nico interface e repositrio deveria
permitir seleccionar o mtodo mais adequado para modelar um determinado tipo de
Sistema de Informao. Seria tambm interessante poder acrescentar novos
componentes (mtodos) nessa ferramenta (tal como actualmente possvel adicionar
ou retirar componentes de diferentes fabricantes no interior de um computador).

2.2.3 ARQUITECTURA DE INFORMAO

Uma Arquitectura de Informao tem como propsito a harmonizao dos
objectivos de um Sistema de Informao com os objectivos de uma organizao de
modo a produzir informao de uma forma efectiva, eficiente e controlada.

Apresenta-se na Tabela 2 um exemplo de uma Arquitectura de Informao.
Esta Arquitectura de Informao foi elaborada por Zackman [QED, 1989] e tem a
particularidade de fornecer, para um determinado nvel de detalhe de descrio, uma
representao adequada da informao. A informao dividida em trs
perspectivas: dados, funes e rede de comunicaes. Ao analisar a Tabela 2.4
constata-se que:

.Os nveis da informao cobrem diversas aproximaes de detalhe,
desde a descrio geral da organizao at descrio do detalhe das
aplicaes informticas existentes. esta caracterstica que torna esta
Arquitectura de Informao inovadora, pois transporta para a actividade


de Engenharia de "Software" conceitos existentes noutros domnios de
engenharia, como por exemplo a Engenharia Civil, onde, para se
construir um edifcio, se desenham diversos esboos com nveis de
detalhe e objectivos distintos.


.A diviso dos nveis de detalhe segundo trs perspectivas (dados,
funes e rede de comunicaes), permite o estudo de cada perspectiva

Dados Funes
Lista de elementos
importantes para
a organizao
Entidade - Classe dos
elementos da organizao
Lista de funes que
a organizao
Funo - Classe de
processos da organizao
Descrio
da
Organizao
Diagrama de
Entidades e
Diagrama de Fluxos
de Informao
Entidade. - Ent. da org.
Relaciona. - Regra org.
Descrio
Geral
Processo. - Proc. da org.
Descrio
do
Sistema de
Informao
Modelo de Dados
Entidade. - Ent. de dados
Rel. - Rel. de dados
Diagrama de Fluxos
de Dados
Relacionamentos
Proc. - Funo da aplic.
proc., fich. ou entidades
Descrio
do
Detalhe
Descrio da
Base de Dados
Programa
Rede
Lista de lugares
onde a organizao
opera
Nodo - Local da org.
Nodo - Unidade da org.
Ligao - Relaes entre
as unidades
Nodo - Funo (acesso a
disco, processador, etc)
Ligao - Caractersticas
da linha
Descrio
das
Restries
Desenho dos Dados Grfico Estruturado
Rel. - apontador/chave
Proc. - Funes do.
computador
Fluxos - crans e mapas
Arquitectura do
Nodo - "Hardware"/sist.
e "software"
Ligao - Caracteristicas
da linha
Nodo - Endereos
Ligao - Protocolos
Sistema
(documentos)
Fluxos - Recursos da org.
Fluxos - Dados entre
Rel. - Endereos dos
campos
Entidades - Campos
Fluxos - Controlo da
execuo do programa
Proc. - Comandos da ling.
Ent. - Linha da tabela
Tabela 2 - Arquitectura de Informao
executa


de uma forma independente, embora tenham que ser geridas de uma
forma global para arquitectar um correcto Sistema de Informao.

2.4 ENQUADRAMENTO COM ASA

Os conceitos apresentados neste captulo servem para fundamentar
teoricamente o trabalho realizado no mtodo ASA.

ASA um mtodo, composto por tcnicas e notaes prprias que foram
desenvolvidas com o objectivo de permitirem modelar, de uma forma bastante
automatizada, Sistemas de Informao. Devido a essa caracterstica, o mtodo ASA
no foi estudado e desenvolvido para ser utilizado de uma forma manual, mas sim
com a ajuda de uma ferramenta de suporte. Essa ferramenta ter que satisfazer os
requisitos propostos no captulo 2.2.2, para que possa ser reconhecida como uma
ferramenta CASE.

ASA inclui a particularidade de descrever a informao com um nvel de
detalhe muito prximo do nvel de descrio da organizao, tal como foi mostrado
na Arquitectura de Informao representada na Tabela 2.

CAPTULO 3

ESTUDO DO MTODO

Pretende-se, neste captulo, apresentar o mtodo ASA tal como existia antes
de este projecto se ter iniciado.

Comea-se por apresentar a evoluo do mtodo ASA, as tcnicas e
notaes existentes realando as vantagens e inconvenientes de cada uma. De
seguida so descritos os trabalhos anteriormente realizados sobre este tema,
indicando os objectivos que se pretenderam atingir.

Apresenta-se, ainda, uma avaliao de ASA de forma a caracterizar o
mtodo.

Captulo 3: Estudo do Mtodo 30

3.1 EVOLUO DO MTODO

O mtodo ASA surgiu em 1987 [Godinho e Lopes, 1987] em consequncia
de estudos e comparaes de algumas tcnicas e notaes. Posteriormente,
efectuaram-se dois trabalhos, um em 1988 e outro em 1990, com o objectivo de
avaliar o mtodo ASA. Desses trabalhos foi concludo que o mtodo tinha potencial
e que deveria continuar a ser desenvolvido.

ASA basicamente consistia na utilizao de tcnicas que, ao utilizarem
notaes grficas simples, podiam ser facilmente assimilveis e trabalhveis por
utilizadores no especializados. Essas tcnicas e notaes so:

.Diagrama de Fluxos de Informao - permite identificar os domnios
de uma organizao e os respectivos fluxos de informao.

.Descrio da Informao - permite descrever a estrutura dos
documentos de uma organizao.

.Matriz de Redundncia Mltipla - permite validar a redundncia de
informao existente nos documentos.

.Matriz de Relaes de Entrada/Sada de Informao - permite
identificar informao que no foi ainda definida e/ou foi omitida por
esquecimento.


.Diagrama de Fluxos de Informao Interna - permite identificar os
ficheiros necessrios para o correcto fluxo de informao e as funes
que manipulam esses fluxos de informao.

Devido s caractersticas referidas, as tcnicas e notaes podem ser
agrupadas segundo duas perspectivas:

.facilitar a entrada de informao - em que se inscreve o Diagrama de
Fluxos de Informao e a Descrio da Informao;

.permitir a automatizao - em que se inscreve a Matriz de
Redundncia Mltipla, a Matriz de Relaes de Entrada/Sada de
Informao e o Diagrama de Fluxos de Informao Interna.

3.2 ENTRADA DE INFORMAO

A entrada de informao est dividida em duas partes distintas, mas que se
complementam. Essas duas partes so: o Diagrama de Fluxos de Informao e a
Descrio da Informao.

3.2.1 DIAGRAMA DE FLUXOS DE INFORMAO

O Diagrama de Fluxos de Informao (DFI), permite representar a
circulao da informao pelos domnios de um sistema em estudo. Antes de se


explicar o funcionamento do diagrama, importante definir os conceitos de
informao e domnios:

.Informao - so documentos (conjuntos de informao) que possibili-
tam que uma organizao se relacione externamente com outras
entidades e internamente com as suas sucursais, filiais, departamentos,
empregados, etc. A maior vantagem da utilizao de documentos, como
unidade de informao, deriva das seguintes observaes [Choobineh,
Mannino e Tseng, 1992]: "os documentos so bem conhecidos pelas
pessoas que os manipulam e dessa forma essas pessoas podem fornecer
um grande nmero de requisitos a partir desses documentos; os
documentos contm a maior parte da informao que circula nas
organizaes".

.Domnios - so funes internas ou externas organizao onde a
informao produzida, alterada, consultada, ou apagada.

O DFI permite representar os domnios de um dado sistema, bem como os
documentos que iro ser necessrios e/ou os documentos que iro ser produzidos,
permitindo deste modo:

.subdividir o sistema em estudo segundo os seus principais domnios, e
proceder ao seu estudo isoladamente ou de uma forma integrada;

.visualizar o circuito de informao;

.validar informao aos mais diversos nveis;


.construir uma viso global do sistema, correcta e completa;

.validar os requisitos principais do sistema.

As regras de construo de um DFI so bastante simples. Trata-se de
representar os domnios de um sistema em estudo e a informao que circula entre
eles, indicando o sentido do fluxo dos respectivos documentos.

Cada domnio representado por um rectngulo, ao qual se deve atribuir um
nome descritivo das funes que desempenha. Se considerarmos, por exemplo, como
sistema uma organizao, podemos considerar como domnios dois dos
departamentos existentes: Departamento Financeiro (contabilidade) e Comercial, ver
Fig. 5.

A informao, como j foi atrs referido, composta pelos documentos que
circulam numa organizao e representam-se por uma linha com indicao da sua
orientao, ver Fig. 6.

Financeiro
Contabilidade
Comercial
Fig. 5 - Exemplo da representao de domnios no DFI

Fig. 6 - Exemplo de uma ligao de um DFI


Utilizando os domnios anteriormente referidos podem-se descrever alguns
documentos que poderiam circular entre eles, por exemplo: O departamento
Comercial, de forma a poder aceitar uma encomenda de determinado cliente, poder
necessitar de informao acerca do saldo do cliente, a qual dever ser pedida ao
departamento Financeiro.

Em termos de DFI esse pedido (consulta de saldo) e consequente resposta
so considerados documentos e sero descritos tal como se encontra exposto na
Fig. 7.

Existem algumas vantagens na utilizao do DFI, tais como

.a partir de uma breve descrio do sistema pode logo traar-se um DFI
geral (de toda a organizao ou de apenas alguns domnios de
informao);

.permite estabelecer uma fronteira para o sistema e para a rea de
actividade abrangida pelo mesmo. Os domnios no representados, no
fazem parte do sistema em estudo;

Financeiro
Contabilidade
Comercial
Fig. 7 - Exemplo de um DFI completo
Consulta de Saldo
Resposta


.permite identificar os principais procedimentos de cada sistema e as
respectivas necessidades de informao;

. um esquema com caractersticas no tcnicas e, portanto, facilmente
compreendido por pessoas familiarizadas com o funcionamento da
organizao, quer tenham ou no conhecimentos informticos. Esta
particularidade facilita o dilogo analista/utilizador e, ao ser construdo e
discutido por pessoas conhecedoras do sistema, aumenta a validade da
informao expressa no diagrama.

Contudo verificou-se que este tipo de DFI no era suficiente para
representar a maior parte dos sistemas, devido constatao dos seguintes
problemas:

.no indicao de ordem cronolgica - Uma das desvantagens deste
esquema est relacionada com o facto de no indicar o inicio e o fim do
procedimento descrito (qual o fluxo que inicia o processo?);

.seleco de um fluxo - Este problema surge quando podemos ter dois
ou mais caminhos diferentes mas selectivos e no sabemos qual das
hipteses seleccionar;

.deteco de "ciclos" - Este problema surge quando existem ligaes em
ciclo entre vrios domnios. Este um caso em que se torna difcil dizer
quantos e quais os documentos que so necessrios para que se avance
para o passo seguinte.


Estes problemas derivam do facto dos sistemas em estudo serem dinmicos,
em que a dimenso temporal de importncia vital. Em sistemas dinmicos a
ateno do analista centra-se em realidades nas quais os acontecimentos ocorrem
segundo uma determinada ordem [Jackson, 1983].
Para se capturar o dinamismo deste tipo de sistemas temos que descrever a
frequncia da circulao dos documentos na organizao. Existem basicamente trs
tipos de frequncias:

.peridicas - associadas a um relgio;

.dependentes - da ocorrncia de um determinado evento; e

.compostas - combinao dos diversos tipos de frequncias existentes.

FREQUNCIAS PERIDICAS

As frequncias peridicas, tal como o seu nome indica, esto associadas a
um relgio e indicam intervalos de tempo discretos ou contnuos.

Exemplos tpicos de frequncias peridicas sero as frequncias dirias,
semanais, mensais, anuais, e podem ser associadas a documentos com periodicidade
deste tipo, por exemplo: "mensalmente o departamento de recursos humanos tem que
produzir o recibo de pagamento dos trabalhadores", logo, a frequncia do
documento recibo mensal.

FREQUNCIAS DEPENDENTES


Estas frequncias no so fceis de temporizar, pois no esto associadas a
um relgio, podendo ser consideradas aleatrias. No sendo peridicas, podem
acontecer a qualquer momento. No entanto, devido dependncia que lhes est
associada, obriga a que um documento que tenha uma frequncia deste gnero s
seja produzido depois de verificar as condies da frequncia associada.

Existem trs tipos de frequncias dependentes:

.directas - Existe uma dependncia directa em relao a um documento
ou condio;

.de deciso humana (estticas) - A produo de um documento est
dependente de uma deciso humana, por exemplo: antes de se fazer o
pagamento do prmio de produtividade o gestor tem que seleccionar os
trabalhadores com direito a esse prmio;

.externas organizao - Tal como o seu nome indica, a organizao
no interfere na produo dos documentos cuja frequncia seja deste
tipo, por exemplo: recepo de uma encomenda por parte de um cliente
que necessita de mais matria prima.

FREQUNCIAS COMPOSTAS


Os diferentes casos anteriormente apresentados, so exemplos de
frequncias simples. No entanto, o que vulgarmente acontece, surgirem frequncias
compostas por diferentes tipos.

A combinao de diferentes tipos de frequncias possibilita resolver os
problemas encontrados nos DFIs, pois atravs da sua utilizao que se pode obter
uma viso clara da sequncia de acontecimentos no sistema em estudo.

RESOLUO DOS PROBLEMAS

Referiram-se atrs alguns problemas dos DFIs, concretamente:

.Falta de ordem cronolgica - Este problema ficou praticamente
resolvido com a utilizao de frequncias nos documentos, pois
consegue-se perfeitamente descrever um caminho com base na
interpretao do significado das frequncias

.Impossibilidade de distinguir seleces - Este problema surgia devido
dificuldade existente na identificao de diversos caminhos selectivos,
por exemplo, quando se segue pelo caminho X se a condio Y for
satisfeita, ou se segue pelo caminho Z ... . Existem casos em que as
decises podem prolongar-se por vrios nveis, originando caminhos
muito distintos. Como bvio, as frequncias associadas a estas
situaes tornam-se mais complexas, mas, em contrapartida, so mais
precisas e agrupam-se em expresses cuja interpretao clara e
simples.


.Impossibilidade de descrever ciclos - Com o aparecimento das
frequncias este problema ficou solucionado, pois a ocorrncia do ciclo
acontece enquanto as condies existentes nas frequncias forem falsas.

3.2.2 DESCRIO DA INFORMAO

A maioria das organizaes usam documentos para, diariamente,
executarem tarefas e comunicarem internamente e externamente com um variado
conjunto de domnios (clientes, fornecedores, departamentos, trabalhadores, etc).

A informao mnima, que garante o correcto funcionamento do mtodo, a
descrio do contedo dos documentos, ou simplesmente, os nomes dos campos
existentes.

3.3 AUTOMATIZAO

A automatizao do mtodo conseguida atravs da utilizao das tcnicas:
Matriz de Redundncia Mltipla, Tabela de Relaes de Entrada/Sada de
Informao e Diagrama de Fluxos de Informao Interna.

3.3.1 MATRIZ DE REDUNDNCIA MLTIPLA

A utilizao desta matriz pretende ser uma forma de testar a redundncia de
informao nos documentos.


O processo consiste em determinar o nmero de formas diferentes com que
a informao (campo de um documento) chega a cada domnio. Para isso utilizam-se
as seguintes matrizes:

.Campos/Documentos - Esto na horizontal todos os documentos que
circulam na organizao e na vertical todos os campos existentes nesses
documentos. Sempre que um campo pertence a um documento
colocado um 1, seno colocado um 0. Ver Fig. 8 (o exemplo aqui
apresentado s serve para demonstrar o funcionamento da Matriz de
Redundncia Mltipla).

.Documentos/Domnios - Esto na horizontal todos os domnios
existentes no sistema a estudar e na vertical todos os documentos que
circulam na organizao. Sempre que um documento entre num
determinado domnio colocado um 1, seno colocado um 0, ver Fig.
9.

Campos
Documentos N
1 2 3 4
Nome
Endereo
Cdigo
Descrio
Preo
Quantidade
1 0 1 1
0 1 0 1
1 1 1 0
0
1
1
1
0
1
0
1
1
1
0
1
Fig. 8 - Matriz de Campos/Documentos


Estas duas matrizes so utilizadas para construir a matriz apresentada na
Fig. 10.

A matriz da Fig. 10 foi acrescida de duas novas matrizes:

.a submatriz inferior esquerda que contm a diagonal principal toda a -
1;

.a submatriz superior direita toda a zeros.

Documentos
Domnios
A B C
1
2
3
4
1 0 1
0 1 0
1 0 0
Fig. 9 - Matriz de Documentos/Domnios
0 1 1

Documentos N
1 2 3 4
Nome
Endereo
Cdigo
Descrio
Preo
Quantidade
1 0 1 1
0 1 0 1
1 1 1 0
0
1
1
1
0
1
0
1
1
1
0
1
Fig. 10 - Matriz de Redundncia Mltipla, preparada para transformao
A B C
Domnios
1
2
3
4
-1 0 0 0
0 -1 0 0
0 0
0
0 -1
-1 0 0
0 0 0
0 0 0
0 0 0
0 0 0
0 0 0
0 0 0
1 0 1
0 1 0
1 0 0
0 1 1


So efectuadas operaes sucessivas sobre as colunas das matrizes, de
forma a reduzir a submatriz inferior direita a zeros.

Neste caso, ao efectuarem-se as somas da coluna 1 com a coluna 5, (1,5), e
as somas (1, 7), a submatriz inferior direita fica com a primeira linha a zeros e
alteram-se os elementos respectivos da matriz superior direita. Quando se realizarem
as somas (2,6) a segunda linha da submatriz direita fica a zeros. Concluindo-se as
restantes somas (3,5), (4,5) e (4,7), obtm-se a matriz exposta na Fig. 11, onde os
elementos da matriz superior direita, correspondem ao nmero de vezes que os
campos entram em cada domnio.

Esta matriz possibilita analisar o contedo dos diversos documentos,
indicando o nmero de vezes que qualquer elemento (campo) surge nos vrios
domnios, se esse nmero for superior a 1 recomendado uma reduo dessa
redundncia.

Documentos N
1 2 3 4
Nome
Endereo
Cdigo
Descrio
Preo
Quantidade
1 0 1 1
0 1 0 1
1 1 1 0
0
1
1
1
0
1
0
1
1
1
0
1
Fig. 11 - Matriz de Redundncia Mltipla mostrando, por exemplo,
A B C
Domnios
1
2
3
4
-1 0 0 0
0 -1 0 0
0 0
0
0 -1
-1 0 0
3 2
1 1
2 2
1 1
2 1
3 2
0
0 0
0 0
0
0
1
1
1
0
1
0
0
0
0
0
0
que o campo Nome chega aos Domnios A e C por trs e
e duas vias respectivamente.


3.3.2 TABELA DE RELAES DE ENTRADA/SADA DE INFORMA-
O

O processo de preenchimento desta tabela consiste em assinalar os
contactos estabelecidos entre os domnios. Entende-se por contactos os documentos
que transitam entre domnios.

Tal como se pode observar na Fig. 12 (o exemplo s serve para demonstrar
o funcionamento da Tabela de Relaes de Entrada/Sada de Informao), a tabela
composta por duas entradas:

.domnios origem - so os domnios de onde a informao sai;

.domnios destino - correspondem a domnios onde a informao entra.

Os contactos entre dois domnios, origem e destino, so assinalados por um
C e os domnios sem contacto so assinalados por um ?.

Depois de preenchida a tabela passa-se sua anlise. Em princpio, se para
cada documento for recebida uma "resposta", a tabela simtrica, se houver "no
simetria", e caso esse contacto no exista no sistema actual, recomenda-se definir um
novo documento que satisfaa esse contacto. Por outro lado, o contacto pode ter sido
omitido por esquecimento, havendo desta forma uma validao da informao
fornecida.


3.3.3 DIAGRAMA DE FLUXOS DE INFORMAO INTERNA

Embora o nome indique que estamos perante um diagrama que esquematiza
os fluxos de informao internos, na verdade esse esquema s usado para facilitar a
explicao do funcionamento do mesmo. Este diagrama permite, com alguma
facilidade, a automatizao, e desse modo, o seu funcionamento torna-se invisvel
para quem esteja a trabalhar com este mtodo.

COMERCIAL
ARMAZEM
FORNECEDOR
CONTROLO DE
PRODUO
CONTABILI-
guia de remessa
aviso interno
(mercadoria a receber)
(chegada de mercadoria)
(valor a pagar)
pedido de
encomenda
encomenda
confirmao de encomenda
pedido de reconfirmao de encomenda
reconfirmao de encomenda
aviso interno
aviso interno
DADE


Basicamente, o funcionamento deste diagrama corresponde anlise do
contedo dos documentos que saem de um determinado domnio e da informao
necessria para a produo desses documentos.

Para os documentos de sada, de um determinado domnio, verificam-se
quais os documentos de entrada que contm informao necessria para a produo
desses documentos. de salientar, que os documentos tm "uma altura certa" em que
devem ser recebidos e produzidos, quer sejam de entrada ou de sada. Este conceito
de "uma altura certa", ou denominada frequncia, pode sugerir a necessidade de
armazenamento de informao, sempre que a frequncia dos documentos de entrada
seja distinta da dos documentos de sada, implicando que se tenha que armazenar a
informao dos documentos de entrada at serem necessrias, para produzir os
documentos de sada. Por outro lado, se no existir informao suficiente para
produzir um documento de sada, quando a frequncia desse documento indicar que
Destino
Origem
F
DC
A
CP
C
F DC A C
C C
C C C
C C
C
?
?
? ?
Fig. 12 - Tabela de Relaes de Entrada/Sada de Informao. Da anlise da tabela,
Legenda:
F - Fornecedor
DC - Dep. Comercial
A - Armazem
CP
CP - Controle de Produo
C - Contabilidade
- Processamento local
C - contacto
? - possvel falta de contacto
e tendo em conta a informao do DFI apresentado, pode colocar-se
por exemplo a seguinte questo: Ser que deve existir um documento em
resposta ao pedido de encomenda feito pelo Departamento de Controlo
de Produo ao Departamento Comercial?


o documento deve ser produzido, pode haver necessidade de definir documentos
auxiliares. Na Fig. 13, podemos ver o formato do diagrama onde se realam as zonas
A, B, C e D:

.A - identifica o domnio que se est a tratar;

.B - os documentos que entram no domnio e/ou os documentos
auxiliares que so criados para que os documentos de sada possam ser
produzidos;

.C - os documentos que saem do domnio;

.D - os ficheiros que so criados e/ou utilizados no domnio.

A
B C
D
Fig. 13 - DFII, descrio das zonas importantes


Para desenhar o diagrama, traam-se linhas que unem os documentos de
sada com todos os documentos necessrios para os produzir. Essas linhas indicam a
fonte de informao necessria para produzir os documentos de sada.

Na Fig. 14 (exemplo fictcio, onde no houve a preocupao de descrever o
contedo dos documentos), apresenta-se o DFII completo. Para se entender melhor o
DFII da Fig. 14, reala-se que:

.Doc3 e Doc4 tm frequncias diferentes;

.Doc1 e Doc3 tm frequncias iguais;

.Doc2 e Doc4 tm frequncias iguais;

.O documento Aux1 foi criado para satisfazer a produo de Doc3 e tem
a mesma frequncia que Doc3;
.Doc3 para ser produzido necessita de informao existente nos
documentos Doc1 e Aux1;

.Doc4 para ser produzido necessita de informao existente nos
documentos Doc2 e Doc1; e

.O ficheiro Fich_1 foi criado, porque Doc1 e Doc4 tm frequncias
distintas.


Outra caracterstica do DFII possibilitar identificar os processos
necessrios para processar os documentos de entrada e/ou produzir os documentos de
sada. Na Fig. 14 possvel visualizar e identificar os processos 1 e 2 necessrios
para produzir os documentos Doc3 e Doc4, respectivamente. possvel, para cada
processo, identificar as actividades correspondentes produo de cada documento,
assim:

.Processo 1 (identificado na Fig. 14 com um 1 e uma linha contnua) -
Este processo produz o Doc3 e executa as actividades: ler Aux1, ler
Doc1 e escrever Doc1 no Fich_1. Todas estas actividades tm como
factor comum a frequncia de Doc3.

.Processo 2 (identificado na Fig. 14 com 2 e uma linha a tracejado) - Este
processo produz o Doc4 e executa as actividades: ler Doc2 e ler Fich_1.
Estas actividades tm como factor comum a frequncia de Doc4.

Domnio Exemplo
Fig. 14 - DFII completo
Doc3
Doc4
Doc1
Doc2
Fich_1
Aux1
1
1
2
2
1


3.4 TRABALHOS ANTERIORES

Em 1988, foi desenvolvido um trabalho com o objectivo de estudar a
validade do mtodo ASA, construindo-se na altura um pequeno prottipo [Couto,
Moreira e Araujo, 1988].

A entrada de informao existente no projecto de 1988 era muito simples,
consistindo na seguinte informao:

.nome do sistema em estudo;

.nome dos domnios pertencentes ao sistema;

.nome dos documentos;

.nome dos campos de cada documento;

.tipo dos documentos;

.frequncia dos documentos cujo tipo seja de entrada, sada ou esttico;

Esta informao era fornecida de uma forma no interactiva o que
pressupunha que os resultados obtidos dependessem da ordem de fornecimento da
informao.

A automatizao assentava na classificao de campos segundo a sua
origem da informao, ver Tabela 3.


O objectivo da Tabela 3 determinar relaes para cada domnio e atribuir
classes aos campos dos documentos de sada desse domnio, permitindo verificar se
estes tm informao suficiente para serem criados. No entanto, a anlise da Tabela 3
permite verificar que uma outra forma de visualizar o funcionamento do processo
de automatizao descrito atravs do Diagrama de Fluxos de Informao Interna .

Em 1990, foi desenvolvido um outro trabalho com o objectivo de continuar
o trabalho anterior, tendo como resultado a construo de um novo prottipo
[Ferreira e Azevedo, 1990]. Este trabalho conseguiu diversas melhorias em relao
ao anterior ao estudar as reas de:

.deteco de redundncias, atravs da adopo das tcnicas anteriormente
descritas;

Classe
Texto
Sistema
Ficheiro
Directo
Ficheiro
Esttico No
Campo existe no Sistema?
Sim
Onde?
Entrada
Freq =
Freq <>
Esttico
Freq =
No
num Ficheiro
de
Sistema
Texto
Domnio
Esttico
Ficheiro Freq <>
Em qualquer
Domnio
Noutro
Domnio
Ficheiro num Ficheiro
Esttico Ficheiro
Tabela 3 - Identificao das classes dos Campos


.gerao de relaes e especificaes de Sistemas de Informao,
baseando-se no DFII e na tabela representada na Tabela 3;

.utilizao de um dilogo com o utilizador, que possibilita a
interactividade no prottipo, atravs da adopo de um interpretador em
"linguagem quase natural". Faltando, contudo, a possibilidade de se
estabelecer dilogo com o utilizador atravs de diagramas ou grficos.

3.5 CARACTERIZAO DO MTODO

O critrio utilizado para caracterizar o mtodo vai ser o mesmo que a Dr.
Filomena Lopes utilizou na sua tese de mestrado [Lopes, 1990]. Este critrio assenta
em dois pressupostos:

1 definir uma lista de atributos para os diversos Sistemas de Informao
existentes, ver Tabela 1 (pg. 17) onde se representam diversos tipos de
Sistemas de Informao;

2 para essa lista de atributos de sistema definir quais as caractersticas dos
mtodos que satisfazem esses atributos.

Este critrio permite seleccionar o mtodo mais adequado para satisfazer
determinados tipos de atributos de sistemas. No entanto, a Dr. Filomena Lopes,
considera que existem trs atributos comuns a todos os Sistemas de Informao


(Inteligibilidade, Exactido e Perfeio), devido a esta caracterstica esses atributos
so considerados relevantes e devem ser satisfeitos pelos mtodos existentes.

Ao aplicar este critrio ao mtodo ASA, obtm-se a seguinte lista de
caractersticas:

.Definio da Fronteira da Informao - Define qual a rea a ser
estudada atravs dos domnios definidos no DFI.

.Desenho Centrado no Utilizador - Usa notaes simples e
perfeitamente assimilveis e trabalhveis pelos seus utilizadores sendo
peritos ou no em informtica ou em mtodos de desenvolvimento.

.Deteco de Erros - Ainda no est considerada ao nvel do desenho a
validao da entrada de informao.

.Desenho de Dilogos Homem-Mquina - No considerada como
uma etapa no processo de desenvolvimento.

.Estruturado - A forma como a informao fornecida no rgida.

.Estudo de comportamento - No ainda possvel estudar o
comportamento do sistema a desenvolver.

.Ferramentas Automticas - Este mtodo no tem razo de existir sem
uma ferramenta automtica que o suporte.


.Ferramentas Integradas - Devido no utilizao de notaes
grficas, no existe integrao.

.Ferramentas para Simular Dilogos - No existem ferramentas
desenvolvidas para formatar crans ou mapas.

.Formao dos Utilizadores - No permite planificar a formao dos
utilizadores do sistema a ser desenvolvido.

.Independncia da Implementao - O trabalho de anlise est
perfeitamente independente do ambiente onde vai ser implementado.

.Informao Alterada - Este mtodo guarda somente a ltima
informao fornecida para um determinado sistema. Seria perfeitamente
possvel haver a possibilidade de existirem verses de desenvolvimento.

.Informao de Consulta - As ferramentas existentes no fornecem
informao de consulta de uma forma clara.

.Informao Guardada - Guarda somente a informao necessria para
o desenvolvimento do sistema.

.Modularidade - O DFI permite ter a ideia de um sistema como um todo
e, sucessivamente, poder ser dividido em domnios de informao ou
funes da organizao e posteriormente, os processos que fazem parte
dessas funes.


.No Ortogonalidade - Foca a informao redundante a nvel do
sistema, domnios e documentos.

.Notaes Adaptadas - As notaes existentes no mtodo ASA no
podem ser configuradas pelo utilizador.

.Participao do Utilizador - Considera o utilizador essencial no
processo de desenvolvimento, sendo a sua participao como fonte de
informao, como crtico da informao fornecida e principalmente
como utilizador do prprio mtodo.

.Testar e Corrigir Cdigo - No permite testar e corrigir cdigo, pois a
fase de gerao de cdigo ainda no est tratada.

.Validao de Produtos-Finais Intermdios - O desenvolvimento do
mtodo ASA resultante de uma caracterstica deste tipo. No entanto,
ASA no permite implementar esta facilidade.

Como se pode verificar, certas caractersticas no esto includas na lista
anterior, tais como a cobertura do mtodo, a maneira como os mtodos modelam o
sistema, etc., porque essas caractersticas no tm relao com os atributos de
sistema [Lopes, 1990].

Aproveita-se para mostrar de uma forma comparativa o mtodo ASA com
outros mtodos SASD, JSD, IE e EXTENDED E-R. No entanto, a Dr. Filomena
Lopes, [Lopes, 1990] refere que "na lista das caractersticas dos mtodos
encontram-se, por vezes, a mesma caracterstica presente em diferentes mtodos.


Contudo essa caracterstica pode ter um grau de concretizao diferente de mtodo
para mtodo. Uma soluo, para resolver este problema, seria atribuir um peso para
cada caracterstica dependendo do grau de concretizao do mtodo a estudar, o que
tornaria esta tarefa bastante subjectiva. Assim, considerou-se somente a presena (S)
ou no presena das caractersticas para cada mtodo em estudo", ver Tabela 4.

3.6 RESUMO

Neste captulo foram apresentados os trabalhos que, anteriormente,
refinaram e avaliaram o mtodo ASA, no entanto estes trabalhos no se preocuparam
com um dos objectivos mais importantes deste mtodo, o dilogo com o utilizador.
Se no trabalho de 1988 esse dilogo era praticamente inexistente, j no trabalho de
1990 houve a preocupao de tornar esse dilogo interactivo, o que foi conseguido
pela adopo de um interpretador de uma "linguagem quase natural", descurando-se
contudo a parte notacional e grfica do mtodo ASA.

Em relao ao processamento e tratamento de diagnsticos, o trabalho de
1988 implementou o Diagrama de Fluxos de Informao Interna e a Matriz de
Redundncia Mltipla, apresentando todos os resultados gerados sobre forma de
matrizes, o que torna a informao compacta e de difcil leitura. O trabalho de 1990
acrescentou a Tabela de Relaes de Entrada/Sada de Informao e apresentou a
informao dividida em assuntos e sobre a forma de lista, o que simplifica a leitura e
interpretao dos resultados.

Em relao ao mtodo, pode-se concluir que o nvel de descrio para
entrada de informao encontra-se, segundo a arquitectura apresentada na Tabela 2


(Pg. 26), ao nvel da descrio da organizao, o que permite colocar o
utilizador/"perito do domnio", como principal interlocutor e fornecedor de
informao, pois ele quem conhece o funcionamento das funes da organizao.

A caracterizao do mtodo prova que o mtodo ASA tem potencialidades,
apesar de no ter ainda sofrido qualquer refinamento, pois nos trs atributos de
sistema mais importantes Inteligibilidade, Perfeio e Exactido, ASA encontra-se
ao nvel do mtodo JSD.


Caractersticas Mtodos SASD JSD IE
EXTEND
Def. da Fronteira da Informao
E-R
ASA
Desenho Centrado no Utilizador
Deteco de Erros
Des. Dialogos Homem-Maquina
Estruturado
Estudo de Comportamento
Ferramentas Integradas
Ferramentas Simular Dialogos
Independncia Implementao
Informao Alterada
Informao de Consulta S S
Informao Guardada
S
Modularidade
Formao dos Utilizadores
No Ortogonalidade
Notaes Adaptadas
Tabela 4 - Atributos de Sistemas / Caractersticas dos Mtodos (S- Sim)
Atributos de Sistemas
Inteligibilidade
Estruturado
Ferramentas Automticas
Valid. de Produtos Finais Interm.
Testar e Corrigir Codigo
Participao do Utilizador
Estruturado
Exactido
S S S
S
S S
S
S S S
S
S S S
S S S S S
S S
S S
S
S S S S
S S S
S
S
S S S
S S S S S
S S
S S S S
S
S S S
Perfeio
Portabilidade
S S S S S
S S
S S S
Usabilidade
S
S
S
Flexibilidade S S S
S S
Documentao
Informao Guardada
Informao Alterada
Informao de Consulta
S S S S S
S S
S S S
Modificabilidade
Informao Alterada
Informao de Consulta S S
Informao Guardada
S
S S S S S
S S
Notaes Adaptadas S S


S S S
Elegncia
Estruturado S S S
No Ortogonalidade S S S
Desenho Centrado no Utilizador S S S S S
Ferramentas Simular Dialogos S
Des. Dialogos Homem-Maquina S
Formao dos Utilizadores S
Eficincia
Estruturado S S S
Deteco de Erros
S S
S S
S
S S S S
S S S
S
S
Caractersticas Mtodos SASD JSD IE
EXTEND
E-R
ASA Atributos de Sistemas
S S S
Confiana
Estruturado S S S
Deteco de Erros
S S
S S
S
S S S S
S S S
S
S
Tabela 4 (cont.) - Atributos de Sistemas / Caractersticas dos Mtodos (S- Sim)

CAPTULO 4

REFI NAMENTO
DO
MTODO

Pretende-se, neste captulo, apresentar as modificaes efectuadas sobre o
mtodo ASA, de forma a melhor-lo, garantindo a sua evoluo.

Este captulo comea por apresentar alguns dos principais objectivos que se
pretendem atingir. Seguidamente, so apresentadas os melhoramentos introduzidos
no mtodo ASA, comparativamente descrio do mtodo do captulo anterior.

Apresenta-se ainda uma caracterizao do mtodo ASA, aps ter sofrido um
processo de refinamento, de forma a comparar a sua evoluo em relao
caracterizao efectuada no captulo anterior.

Captulo 4: Refinamento do Mtodo 60

4.1 OBJECTIVOS A ATINGIR

Um dos principais objectivos a atingir com este mtodo facilitar ao
mximo o trabalho dos utilizadores. Pretende-se mesmo que seja o "perito de
domnio" quem trabalhe e dialogue com ASA, tal como est representado na Fig.
15:

."perito de domnio" - tem como funo fornecer informao
ferramenta e receber os resultados;

.interface - tem como objectivo validar a informao que entra na
ferramenta e formatar a informao que sai;

.processamento - prope-se gerar informao de uma forma automtica,
desde processos e ficheiros a diagnsticos de redundncias e omisses.

"Perito de
Interface
Processamento
Entrada Sada
DFI
Descrio Inf..
Validao
DFII
Matriz de Red.Mult.
Tabela Rel. E/S Inf.
Preparao
Document. Anlise
Diagnsticos
Fig. 15 - Funcionamento de ASA
domnio"


Outro objectivo no obrigar o utilizador a fornecer mais informao do
que a indispensvel para o processo de automatizao e gerao de documentao.
Por outro lado, pretende-se possibilitar a descrio da informao pela ordem
pretendida, havendo somente limitaes quando o "perito de domnio" no conhecer
suficientemente bem o sistema a estudar.

Assim, tal como foi visto no captulo anterior, ASA utiliza tcnicas simples
tanto para a entrada de informao como para a automatizao. Dessas tcnicas
algumas sofreram alteraes profundas de forma a melhorar o prprio mtodo e so
essas alteraes que vo ser descritas neste captulo.


A entrada de informao uma tarefa crtica, sobretudo quando se pretende
dirigir este mtodo a "peritos de domnio" em vez de peritos em informtica e/ou
mtodos de anlise. No entanto, esta caracterstica que distingue este mtodo de
outros existentes.

A entrada de informao est dividida em duas partes:
.Diagrama de Fluxos de Informao - este um diagrama
iminentemente grfico, da ser um dos objectivos a possibilidade do
diagrama ser fornecido atravs de um editor grfico.

.Descrio da Informao - Esta tcnica permite retirar dos documentos
que circulam o mximo de informao possvel, sofrendo
consequentemente grandes alteraes em relao ao apresentado no
captulo anterior.


4.2.1 DIAGRAMA DE FLUXOS DE INFORMAO

Para entender o funcionamento deste diagrama consulte, no captulo
anterior, o subcaptulo 3.2.1. Para alm da possibilidade de representao e
manuteno de um modo grfico, a alterao considerada pertinente nos DFI foi a
atribuio de pesos s frequncias dos documentos.

Os pesos permitem definir qual a frequncia que ocorre mais vezes. Um
valor de peso prximo de 0 indica que uma frequncia muito alta, se o valor de
peso for elevado indica que a frequncia baixa. Se houver a composio de duas ou
mais frequncias o valor do peso seleccionado corresponde frequncia que ocorre
mais vezes. Podem ser vistos exemplos de frequncias e pesos na Tabela 5.

Clock1 Anualmente no dia 15 de Janeiro 30
Clock2 Mensalmente no dia 20 15
Clock3 Trimestralmente a partir de Janeiro 22
Clock4 Diariamente s 15 horas 5
Nome Descrio Peso
Tabela 5 - Frequncias e seus respectivos pesos
16
Clock5 Semanalmente Segunda-Feira
Clock6 Mensalmente no dia 10
8
Clock3 + Clock5 19
Clock4 + Clock7 5
Clock1 + Clock4 5


4.2.2 DESCRIO DA INFORMAO

A informao de um documento, est nos campos desse documento. Assim,
os campos so a estrutura elementar de um documento e podem ser caracterizados
pelas suas propriedades:

.Tipo - tipo elementar ou definido pelo utilizador, e pode conter os tipos:
caracter, numrico, nmero de telefone, morada, data, hora, etc.

.Classe - identifica se o campo pode ter uma das seguintes classes:

.Constante - o contedo de um campo com esta classe sempre
igual no objecto documento e nas suas instncias sendo
normalmente composto por texto;

.Frmula - permite descrever o processo de clculo para se obter o
campo;

.Varivel - o campo pode ter valores diferentes nas vrias
instncias do documento.

.Identificador - informa se o campo identifica o documento.

.Nmero de repeties - indica se o nmero de vezes que o campo se
repete no documento.


.Restries - identifica diversas restries existentes nos campos, por
exemplo: se o campo for do tipo numrico, o nmero de casas decimais
pode ser uma restrio.

.cran - todo um conjunto de propriedades que caracteriza um campo,
como por exemplo: cor, tipo e tamanho do caracter, coordenadas x-y, etc.

Sublinha-se que as frmulas tm ainda a particularidade de definirem o
processo de clculo de um campo, e a sua representao ser semelhante utilizada
nas frmulas de uma folha de clculo.

4.3 AUTOMATIZAO

Como foi visto no captulo anterior a etapa de automatizao utiliza as
seguintes tcnicas:

.Matriz de Redundncia Mltipla - no foi alterada em relao ao
proposto no captulo anterior.

.Tabela de Relaes de Entrada/Sada de Informao - no foi
alterada em relao ao descrito no captulo anterior.

.Diagrama de Fluxos de Informao Interna - sofreu profundas
alteraes de forma a afinar e validar o processo de gerao e
automatizao, como se pode verificar no ponto que se segue.


4.3.1 DIAGRAMA DE FLUXOS DE INFORMAO INTERNA

A atribuio de um valor (peso) s frequncias dos documentos, que
circulam no DFI, permite saber de uma forma ordenada, qual a frequncia de
produo dos diversos documentos. Aos documentos, que tiverem um valor de peso
prximo de 0, corresponde uma frequncia bastante elevada (est constantemente a
ser produzido) e o inverso corresponde uma frequncia bastante baixa (raramente
produzido). Em termos de DFII produz-se, em primeiro lugar, o documento de
menor peso e, de seguida, independentemente do domnio a que pertence, produz-se
o seguinte (de menor peso) e assim sucessivamente.

Na Tabela 6, apresenta-se, como exemplo, um conjunto de documentos
ordenados pelo peso das suas frequncias. Deste exemplo verifica-se que o primeiro
documento a ser produzido Marcao de Ausncias com peso 5, seguidamente o
segundo documento a ser produzido Mapa de Ausncias com peso 8, este
documento, em princpio, utilizar informao j disponibilizada pelo documento
Marcao de Ausncias. Este procedimento repete-se para todos os documentos
representados na Tabela 6.
Clock2 Mensalmente no dia 20 15
Clock3 Trimestralmente a partir de Janeiro 22
Clock4 Diariamente s 15 horas 5
Nome Descrio Peso
Tabela 6 - Exemplo de atribuio de pesos a documentos com uma determinada
16
Clock5 Semanalmente Segunda-Feira
Clock6 Mensalmente no dia 10
Documento
Recibo de Vencimento
Clock1 Anualmente no dia 15 de Janeiro 30 Atribuio de Aumento
Marcao de Ausncias
Devoluo do IRS
Mapa de Ausncias 8
Absentismo Mensal
frequncia (Ordenado por Peso)


O resultado imediato da atribuio de pesos s frequncias dos documentos,
a facilidade de identificar a origem da informao existente nos documentos, ou
seja, identificar para um determinado campo, qual o primeiro documento a ser
produzido que o contm. Por exemplo, para produzir o documento Mapa de
Ausncias, em princpio, utiliza-se informao (campos) j existente no documento
Marcao de Ausncias, assim essa informao ter origem no no Mapa de
Ausncias, mas sim no documento Marcao de Ausncias.

Em termos de representao grfica do DFII, inseriram-se modificaes
para reproduzir as alteraes atrs descritas. Na Fig. 16, representa-se o formato do
diagrama onde se realam as zonas A, C e D:

.A - identifica o sistema que se est a tratar;

.C0 - identifica o documento auxiliar necessrio para produzir o
documento existente no sistema com menor peso;

.C1 .. CN-1 - cada uma das divises identifica um determinado valor de
peso para todas as frequncias dos documentos existentes, nessas
divises so representados os documentos produzidos e os documentos
auxiliares necessrios para produzir os documentos da diviso seguinte;

.CN - identifica o documento com maior valor de peso existente; e

.D1 .. DN - permite descrever os ficheiros que so criados e/ou utilizados
em cada uma das divises.


Tal como no esquema anterior (ver Fig. 13, pg. 45), para desenhar o
diagrama, traam-se linhas que unem os documentos a serem produzidos com todos
os documentos necessrios para os produzir. Essas linhas indicam a fonte de
informao necessria para a produo dos documentos de sada.

Para se compreender o funcionamento deste esquema, apresenta-se um
exemplo com os documentos existentes na Tabela 6, no entanto reala-se que este
exemplo um exerccio puramente terico, devido ao facto de no se descrever a
estrutura e contedo de cada um dos documentos, ver Fig. 17.

A
C0 C1
D1
Fig. 16 - DFII, descrio das zonas importantes
C2 CN
D2 DN

Sistema Fictcio
Fig. 17 - Exemplo do funcionamento do DFII
Marcao
Ausncias
Aux1
Mapa
Ausncias
Recibo
Absentismo
Devoluo
IRS
Aumento
Vencimento
Aux2
Fich_1 Fich_2
Mapa
1
2
3
3
4 6 5


Os processos representados na Fig. 17 esto numerados, assim:

.Processo 1 (identificado na Fig. 17 pelo nmero 1) - Este processo
produz o documento Marcao de Ausncias e executa as actividades: ler
Aux1, escrever Aux1 em Fich_1. Todas estas actividades tm como
factor comum a frequncia do documento Marcao de Ausncias.

produz o documento Mapa de Ausncias a partir de informao contida
no ficheiro Fich_1.

produz o documento Recibo e executa as actividades: ler Aux2, ler
Fich_1 e escrever Aux2 em Fich_2.

produz o documento Mapa de Absentismo a partir de informao contida
no ficheiro Fich_1.

produz o documento Devoluo IRS a partir de informao contida no
ficheiro Fich_1 e Fich_2.

produz o documento Aumento de Vencimento a partir de informao
contida no ficheiro Fich_2.


4.4 FERRAMENTA ASA

A ferramenta, que possibilite automatizar o mtodo ASA, deve conter as
seguintes componentes:

.Dilogo com o utilizador - incluindo as tcnicas e notaes que fazem
parte do mtodo, designadamente, o Diagrama de Fluxos de Informao
e a Descrio da Informao.

.Processamento interno - que inclui duas caractersticas importantes:

o Gerao automtica de informao - utiliza a tcnica
denominada por DFII, que gera, automaticamente, os ficheiros e
processos.

o Diagnsticos - fornece, de uma forma automtica, um maior
nmero de diagnsticos. No captulo anterior descreveram-se duas
tcnicas, a Matriz de Redundncia Mltipla e a Tabela de Relaes
de Entrada/Sada de Informao, que, atravs das notaes
utilizadas, permitem deduzir diagnsticos de redundncia e
omisso de informao.

.Repositrio - Esta componente permite que a informao fornecida e
gerada seja guardada para poder, a qualquer momento, ser consultada.

Na Fig. 18, pode ser visualizado um esquema que contm as componentes
principais da ferramenta.


DILOGO COM O UTILIZADOR

As facilidades de "interface" com o utilizador so uma parte crucial do
"ambiente" de uma ferramenta, ver Fig. 19. Um "ambiente" um conjunto de
facilidades concebidas para auxiliar o utilizador na execuo de uma tarefa.

Dilogo com utilizador
Repositrio
Processamento Interno
Ligao entre componentes
Fig. 18 - Componentes da ferramenta

Dilogo com o utilizador
Sair Editar Ajuda
Fig. 19 -Dilogo com o utilizador


Para facilitar a entrada de informao, o "interface" da ferramenta com o
utilizador deve ser consistente e fcil de utilizar. Uma forma de o conseguir atravs
da adopo de um "front-end device" (um tipo de "interface standard" de alta
qualidade), que permita alcanar grandes benefcios, tais como:

.o custo de desenvolvimento pode ser reduzido atravs da reutilizao
das facilidades existentes;

.a uniformidade e consistncia poderem ser favorecidas;

.outros aspectos da integrao de um ambiente poderem ser facilitados.

Outro aspecto a ter em conta o tipo de notao empregue pelo mtodo na
altura da entrada de informao. Como foi visto, o mtodo , fundamentalmente,
grfico, assim, o "interface" dever fornecer um "ambiente" que suporte essa
componente grfica.

PROCESSAMENTO INTERNO

O mtodo recorre definio de frequncia, para a deduo lgica dos
ficheiros e processos necessrios ao sistema.

Esta filosofia est bem patente na ocasio da deduo de especificaes do
sistema a desenvolver, ou seja, na etapa de produo dos documentos, ver Fig. 20.


Este processo de deduo de processos e ficheiros, representado no
Diagrama de Fluxos de Informao Interna, pode ser descrito na Tabela 7.

Processamento Interno
Fig. 20 - Processamento Interno

Classe
Constante
Ficheiro
Directo
Ficheiro
Esttico No
Campo existe
Sim
Onde?
Freq <>
Freq =
Ficheiro
Constante
Ficheiro
Domnio =
Tabela 7 - Identificao das classes dos Campos
Frmula Frmula
Esttico
Documento
Domnio <>
no Sistema?
Peso com
Inferior
Domnio =
Domnio <>
Freq = Directo
Freq <> Ficheiro
Ficheiro
Documento
?
?
?


REPOSITRIO

O repositrio o local onde so armazenadas as mais diversas informaes,
decorrentes das actividades de dilogo com o utilizador e do processamento interno
de ASA. O repositrio dividido em trs componentes, ver Fig. 21:

.Gestor de informao - o processo responsvel por armazenar,
consultar e alterar informao; desta forma considerado responsvel
pela correcta manuteno da informao.

.Dados - funciona como uma base de dados central, onde a informao
depositada, para poder ser mantida de uma forma coerente e integrada.

.Vector de Estado - armazena, de uma forma estruturada e centralizada,
o estado da informao existente na base de dados, permitindo responder,
de uma forma rpida e eficiente, a qualquer pedido de diagnstico.

Repositrio
Fig. 21 - Repositrio
Gestor de Informao


Deve-se no entanto realar que, no foi objectivo deste trabalho desenvolver
um repositrio que permita integrao e transferncia de informao com outros
repositrios existentes noutras ferramentas CASE.

4.5 CARACTERIZAO DO MTODO

Devido s diversas alteraes sofridas pelo mtodo ASA novamente
efectuada a caracterizao do mtodo segundo o critrio estabelecido no captulo
anterior, mas, em vez de se descreverem todos os pontos de classificao existentes,
descrevem-se somente aqueles que sofreram alteraes:

.Deteco de Erros - Ao descrever, de uma forma mais completa, os
documentos e as propriedades dos seus campos, considera-se que j
possvel a validao da autenticidade da informao dos documentos.

.Estruturado - Um sistema pode ser partido em diversos subsistemas,
podendo ser desenvolvidos separadamente e existe uma sequncia de
passos a seguir bem definida.

.Ferramentas Integradas - ASA foi desenvolvido com o propsito de
automatizao e usa um conjunto integrado de notaes grficas de
forma a modelar o sistema.

.Informao de Consulta - Existe uma preocupao de fornecer a
informao existente no mtodo de uma forma perfeitamente legvel.


Se compararmos esta nova classificao do mtodo ASA com a anterior,
pode-se desde j ter uma ideia da evoluo das caractersticas de ASA. Na Tabela 8,
apresenta-se o mtodo ASA actual e anterior, para os atributos de sistema
considerados mais importantes [Lopes, 1990]. Assim, houve a seguinte evoluo:

.Inteligibilidade - composta por trs caractersticas; inicialmente ASA
satisfazia duas dessas trs caractersticas, mas, actualmente, satisfaz a
totalidade;

.Exactido - composta por nove caractersticas; inicialmente ASA
satisfazia somente trs dessas nove caractersticas, neste momento
satisfaz seis (aumento de 50%);

.Perfeio - composta por seis caractersticas; inicialmente ASA
satisfazia somente trs dessas seis caractersticas, satisfazendo agora
quatro.


Caractersticas Mtodos
ASA ASA
Deteco de Erros
Estruturado
Independncia Implementao
Informao Alterada
Informao Guardada
Modularidade
No Ortogonalidade
Notaes Adaptadas
Tabela 8 - Atributos de Sistemas / Caractersticas dos Mtodos (S- Sim)
Inteligibilidade
Estruturado
Estruturado
Exactido
S
S
S
S S
S
S
S S
S
S
S S
S
S
S S
S S
S S
Perfeio
Portabilidade
S S
S
S
Usabilidade
Flexibilidade S S
Documentao
Informao Guardada
Informao Alterada
S S
S
Modificabilidade
Informao Alterada
S
Informao Guardada S S
S
Notaes Adaptadas
Anterior Actual


S S
Elegncia
Estruturado S
No Ortogonalidade S
Desenho Centrado no Utilizador S S
Eficincia
Estruturado
S
S
S
S
Deteco de Erros
Participao do Utilizador S S
S
Caractersticas Mtodos
ASA ASA
S
Confiana
Estruturado
S
S
S
Deteco de Erros
Participao do Utilizador S S
S
S
S
Tabela 8 (cont.) - Atributos de Sistemas / Caractersticas dos Mtodos (S- Sim)
Anterior
S
Actual


4.6 RESUMO

Um dos objectivos atingidos com as alteraes no ASA, visveis desde o
prprio mtodo at ferramenta, a facilidade do dilogo com o "perito de
domnio", sendo conseguido atravs da utilizao e manuteno grfica do DFI.

Por outro lado, em termos de automatizao/processamento houve uma
melhoria substancial da qualidade dos resultados obtidos, devido no s utilizao
de pesos nas frequncias de ocorrncia dos documentos, mas tambm devido s
alteraes efectuadas na lgica do processamento representado no DFII.

Estas melhorias foram reflectidas na classificao do mtodo ASA, onde
nos trs principais atributos de sistema, Inteligibilidade, Exactido e Perfeio, ASA
consegue satisafazer grande parte das caractsticas existentes.

CAPTULO 5

VALI DAO
DO
MTODO

Pretende-se, neste captulo, validar o mtodo ASA.

Comea-se por apresentar a abordagem efectuada de forma a validar o
mtodo ASA. De seguida, explicado o funcionamento do prottipo ASA, atravs
do fornecimento de um exemplo e da visualizao dos resultados.

Captulo 5: Validao do Mtodo 80

5.1 ABORDAGEM

Devido s caractersticas do mtodo ASA, atravs da construo de uma
ferramenta/prottipo que se torna mais fcil entender o funcionamento de ASA.
Assim, foi construdo um prottipo debaixo de um ambiente iminentemente grfico,
o Windows 3.1, de forma a aproveitar as suas vantagens e adoptar o "interface" a
existente.

Como foi anteriormente verificado, no mtodo ASA, a fase de anlise
(automatizao) s comea quando a entrada de informao termina. Contudo, no
prottipo desenvolvido tal no se verifica, pois para cada conjunto de informao
fornecido, feita, imediatamente, a respectiva anlise, visto que o mtodo assim o
permite.

Para trabalhar com o prottipo ASA basta definir as componentes, os fluxos
de informao e a descrio dessa informao, fazendo com que ASA disponibilize,
ao seu utilizador, uma srie de relatrios de diagnsticos sobre a especificao
fornecida. Desta forma, o utilizador pode proceder a adies ou a alteraes na
especificao e pode, de novo, gerar uma outra srie de relatrios de diagnsticos.

Provar a validade do mtodo ASA, pode ser conseguida atravs da
elaborao de um exemplo, que, ao ser processado, exemplifique o funcionamento
do mtodo e do prottipo respectivamente.

O exemplo consiste num Sistema de Gesto de Vencimentos. Este sistema
pode no estar completo, no entanto cobre as principais funes da Gesto de
Vencimentos, tais como:


.admisso de trabalhadores

.emisso de recibo de vencimento

.envio automtico dos valores de acumulados trimestrais de IRS para os
Servios Centrais das Finanas, IRS

A sua escolha foi facilitada por este ser um problema clssico, bastante
aproximado da realidade e a sua implementao ser bem conhecida por aqueles que
so especialistas de Anlise de Sistemas na rea da Informtica de Gesto.


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).

Fig. 22 - Sistema RecHum


A etapa seguinte consiste em descrever o DFI para este sistema. Assim,
RecHum necessita ter um domnio denominado por ResProc (Responsvel pelo
Processamento) que tem como funes obter toda a informao para proceder ao
processamento de vencimentos e emisso de recibo para entregar aos trabalhadores
(domnio externo ao sistema em estudo). Este domnio, o ResProc, todos os
trimestres, envia o valor de IRS, que deduzido mensalmente a todos os
trabalhadores, para as Finanas (domnio externo ao sistema em estudo). Sempre que
houver alterao aos dados de um trabalhador ou um trabalhador novo for admitido,
ento esse trabalhador ter que enviar esses dados para o responsvel pela admisso
que proceder actualizao do seu cadastro.

O DFI para o exemplo acima descrito est apresentado na Fig. 23.

Fig. 23 - DFI do Sistema RecHum


Como j foi anteriormente referido, existem domnios que pertencem ao
Sistema (denominados internos) e domnios que no pertencem (denominados
externos).

Os domnios internos podem ainda ser classificados como locais, remotos e
no informatizveis. Os domnios locais, para poderem efectuar as suas funes, tm
toda a informao que necessitam totalmente disponvel. Os domnios remotos, de
forma a obterem os documentos necessrios para desempenharem as suas funes,
necessitam de recorrer a um meio qualquer de comunicao. Os domnios no
informatizveis efectuam as suas funes manualmente, sem recorrer ao auxilio do
computador.

Para os domnios descritos no DFI da Fig. 23, temos:

.Finanas - domnio externo;

.Trabalha (Trabalhador) - domnio externo;

.Admissao (Admisso) - domnio interno e local;

.ResProc (Responsvel pelo processamento) - domnio interno e local.

Para definir em ASA os tipos de domnios, recorre-se utilizao da janela
de domnios, ver Fig. 24 onde est descrito o domnio ResProc. Nesta janela salienta-
se a existncia da seco denominada Informao, na parte direita da janela, onde de
uma forma automtica, mostrada a identificao da rea do que se est a trabalhar,
neste caso a identificao do sistema em estudo.


Para completar a informao existente no DFI necessrio descrever os
documentos a existentes:

.Inform - documento que circula entre os domnios Trabalha e
Admissao, com frequncia Ext (devido a somente acontecer quando
ocorrer uma alterao ou admisso de trabalhador);

.Inf_Trab - documento que circula entre os domnios Admissao e
ResProc, com frequncia Clock2 (todos os meses a informao dos
trabalhadores enviada para ResProc para o processamento e emisso de
recibos);

.Receita - documento que circula entre os domnios ResProc e
Finanas, com frequncia Clock3 (todos os meses ResProc envia para as
Finanas os valores de IRS previamente deduzidos);
Fig. 24 - Domnio ResProc


.IRS - documento que circula entre os domnios Finanas e ResProc,
com frequncia Ext (Externo, sempre que existam alteraes tabela de
IRS);

.Recibo - documento que circula entre os domnios ResProc e Trabalha,
com frequncia Clock1 (mensalmente os recibos so entregues aos
trabalhadores);

Para fornecer a ASA os tipos de domnios existentes recorre-se utilizao
da janela de documentos, ver Fig. 25 onde est descrito o documento Recibo.
Salienta-se que nesta janela os domnio de destino e origem j se encontram
preenchidos.

Fig. 25 - Documento Recibo


Para cada documento existe uma frequncia qual necessrio fornecer um
peso para permitir uma ordenao da sua ocorrncia (documentos com menor peso
implica uma grande frequncia de ocorrncia). Assim, se na janela da Fig. 25 se
seleccionar o boto de frequncia aparecer a janela representada na Fig. 26.

Aps se ter definido o peso da frequncia, passa-se definio da estrutura
e contedo dos diversos documentos. Considerou-se que os documentos so
compostos por blocos de informao, podendo esses blocos identificar entidades.
Assim, para os diversos documentos teremos:

.Inform - contm o bloco denominado por Inf (dados do trabalhador);

Fig. 26 - Descrio da Frequncia Clock1


.Inf_Trab - contm o bloco denominado por Registo (dados do
trabalhador para processamento);

.Receita - contm o bloco denominado por Registo (deduo efectuado
pelo trabalhador para pagamento do IRS);

.IRS - contm o bloco denominado por Registo (registo da tabela de IRS
que permite definir os escales de tributao de IRS);

.Recibo - contm os blocos Cabecalh (Cabealho, agrupa a informao
de identificao do trabalhador) e Corpo (onde so agrupados os valores
de remuneraes e dedues 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.

Fig. 27 - Bloco Corpo do documento Recibo


Aps a definio dos blocos de cada documento, passa-se descrio do
contedo de cada um. Assim, para os diversos documentos/blocos teremos:

.Inform - bloco: Inf
Campos:
Nome - nome do trabalhador
NContr - nmero de contribuinte
NDep - nmero de dependentes
ECiv - estado civil
NSegSoc - nmero de segurana social

.Inf_Trab - bloco: Registo
Campos:
NTrab - nmero do trabalhador
ECiv - estado civil
CatProf - categoria profissional
VencIliq - vencimento ilquido;

.Receita - bloco: Registo
Campos:
Ano - ano da deduo
Mes - ms da deduo


Dedu - valor da deduo;

.IRS - bloco: Registo
Campos:
EcivIRS - estado civil
NDepIRS - nmero de dependentes
TIRS - taxa de IRS;

.Recibo - bloco: Cabecalh
Campos:
NomOrg - nome da organizao
Ano - ano do processamento
Mes - ms do processamento
NTrab - nmero do trabalhador
ECiv - estado civil
CatProf - categoria profissional
bloco: Corpo
Campos:
VencIliq - vencimento ilquido
DAus - dias de ausncia
DTrab - dias trabalhveis
DPag - dias a pagar
DescSS - descontos segurana social


Dedu - dedues
Remun - Remuneraes
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, atrs referidos, so criados de uma forma automtica com
um conjunto pr-definido de propriedades. Assim, todos os campos so da classe
varivel (o seu contedo pode variar nas diversas instncias do documento) e do tipo
alfanumrico. Contudo, pode-se pretender alterar algumas dessas propriedades, o que
obrigar a escolher o boto, propriedades da janela representada na Fig. 28 o que far
aparecer logo de seguida a janela da Fig. 29.
Fig. 28 - Campo DAus do bloco Corpo e documento Recibo


Se a classe do campo DPag for alterada para frmula, com o contedo de
DPag = DTrab - DAus (dias a pagar igual diferena entre os dias trabalhveis e
os dias que faltou), obriga a alterar as propriedades desse campo na janela da Fig. 29
e acrescentar a respectiva frmula, ver Fig. 30.

Fig. 29 - Propriedades do campo DAus inserido no bloco Corpo e Documento Recibo


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 Varivel e so do tipo
alfanumrico, excepto os campos representados na Tabela 9.

Fig. 30 - Descrio da frmula do campo DPag do bloco Corpo e documento Recibo
Fig. 31 - Constante NomOrg


Campo Classe Contedo
NomOrg (nome organizao) Constante XPTO, Lda
DPag (dias a pagar) Frmula DTrab - DAus
Remun (remuneraes) Frmula (VencIliq * DPag)/ DTrab
DescSS (desc. seg. social) Frmula Remun * 11%
Dedu (dedues) Frmula
Se(ECiv=ECivIRS ^ NDep=NDepIRS)
Ento
Remun * TIRS
Liq (liquido a receber) Frmula Remun - DescSS - Dedu
Tabela 9 - Campos cuja Classe diferente de Varivel

Neste momento est descrita toda a informao necessria para se proceder
ao processamento da informao. No entanto, salienta-se que se poderia proceder ao
processamento em qualquer altura desta etapa de introduo de informao, o que
implicaria, logicamente, que os resultados fossem diferentes, porque dependem da
quantidade de informao previamente fornecida.

5.3 AUTOMATIZAO

O etapa de automatizao, ou processamento da informao, no prottipo
ASA despoletada, imediatamente, aps o utilizador seleccionar uma das opes de
consulta representadas na Fig. 32.


Durante o processamento, ASA pode colocar uma questo ao utilizador de
forma a saber se a informao que vem do exterior pode ser guardada no momento
em que necessria para fornecer o documento interno. Neste exemplo, ASA
pergunta se a informao, que um trabalhador fornece na sua admisso, pode ser
registada somente no momento em que vai ser necessria para o processamento de
vencimentos, ver Fig. 33. A resposta questo colocada na Fig. 33, pode ser
respondida positivamente, devido inexistncia da necessidade da informao de
admisso do trabalhador noutros domnios da organizao e consequentemente a
frequncia entre os dois documentos poder ser igual. No entanto, na Fig. 34,
coloca-se a mesma questo entre o documento Recibo e IRS, a resposta, desta vez,
deveria ser negativa, pois o documento IRS tem uma frequncia anual, enquanto que
o Recibo tem uma frequncia mensal.

Fig. 32 - Menu de Consulta


Quando o processamento terminar todas as opes de consulta se encontram
disponveis, ver Fig. 32.

Fig. 33 - Comparao da criao dos documentos Inf_Trab e Inform
Fig. 34 - Comparao da criao dos documentos Recibo e IRS


Se seleccionar a primeira opo aparecer a janela representada na Fig. 35,
onde se encontra o sistema RecHum.

Se seleccionar a segunda opo aparecer uma janela idntica
representada na Fig. 23, onde se encontra o DFI do sistema RecHum.

Fig. 35 - Consulta da informao do Sistema RecHum


A terceira opo mostra a janela representada na Fig. 36 , onde se
encontram todos os domnios existentes em RecHum, embora, por falta de espao,
seja somente possvel observar o domnio ResProc. Em termos de diagnsticos, e ao
aplicar a Tabela de Relaes de Entrada/Sada de Informao (apresentada no
captulo 3), vai-se obter os diagnsticos mostrados na Fig. 36.

Fig. 36 - Consulta dos domnios do sistema RecHum


A quarta opo mostra a janela representada na Fig. 38, onde se encontram
todos os documentos existentes em RecHum, embora, por falta de espao, seja
somente possvel mostrar parte do documento Recibo. Nesta janela, aparecem
diagnsticos que informam a existncia de uma eventual omisso na informao de
alguns documentos, neste caso da descrio. Existe outro diagnstico informando
que o documento Inf_Trab parece ser redundante no domnio ResProc, ou seja, este
documento pode no ser necessrio, porque a informao que contm no utilizada
por nenhum outro documento no domnio de destino deste documento, neste caso
ResProc.

Fig. 38 - Consulta dos documentos do sistema RecHum


A quinta opo mostra a janela representada na Fig. 39, onde se encontram
todos os campos existentes em RecHum, embora, por falta de espao, seja somente
possvel mostrar alguns desses campos. Como se pode observar, para cada campo
mostrado todos os documentos onde esse campo ocorre, o seu contedo se o campo
for da classe Frmula ou Constante e o documento que fornece esse campo ao
sistema RecHum desde que o campo no seja da classe Frmula ou Constante.

Fig. 39 - Consulta dos campos do sistema RecHum


A sexta opo mostra a janela representada na Fig. 40, onde se encontram
todos os Ficheiros existentes em RecHum, embora, por falta de espao, seja somente
possvel mostrar alguns dos ficheiros existentes. Para cada ficheiro so mostrados,
em termos de diagnsticos, os campos que no so utilizados, o que, em princpio,
pode permitir a sua eliminao.

Fig. 40 - Consulta dos ficheiros do sistema RecHum


A stima opo mostra a janela representada na Fig. 41, onde se encontram
todos os processos existentes em RecHum, embora, por falta de espao, seja somente
possvel mostrar alguns dos processos existentes. A descrio dos processos, neste
momento, bastante reduzida, mostrando-se somente os documentos necessrios
para produzir os documentos de sada desse processo. Para cada um, apresenta-se um
diagnstico a informar se o processo redundante, o que poderia implicar a sua
eliminao.

Fig. 41 - Consulta dos processos do sistema RecHum


A oitava opo 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 no faz parte do mtodo ASA, mas apresentado como uma forma de
permitir provar a validade do mtodo, ou seja, poder verificar, de uma forma
bastante simples (grfica), o processo automtico de gerao de informao
existente.

A Fig. 42 apresenta o diagrama de contexto e a Fig. 43 o diagrama 0 do
sistema em estudo. importante realar que os DAux's (Documentos auxiliares) so
documentos gerados por ASA de forma a poder satisfazer os documentos internos
(ver no captulo 4 o Diagrama de Fluxos de Informao Interno, DFII). Os processos
e ficheiros so tambm gerados pelo DFII. No Diagrama 0, mostra-se a diferena
entre os documentos que so gerados por entidades internas, ou que tm como
origem uma entidade interna (pequeno quadrado todo escuro) e aqueles que tm
como origem ou destino uma entidade externa (pequeno quadrado com o interior a
branco).


Fig. 42 - Consulta do diagrama de contexto do sistema RecHum
Fig. 43 - Consulta do diagrama 0 do sistema RecHum


A nona opo mostra a janela representada na Fig. 44, onde se encontram as
entidades internas geradas para o sistema RecHum, embora, por falta de espao, seja
somente possvel visualizar algumas dessas entidades. Estas entidades tm como
funo fornecer informao existente em documentos cuja origem so domnios
externos, e por outro lado, criar documentos auxiliares para fornecer informao a
documentos internos

Fig. 44 - Consulta das entidades internas do sistema RecHum


RESULTADOS

Depois de uma breve explicao do funcionamento do prottipo ASA e da
visualizao dos resultados obtidos, pertinente, neste momento, validar esses
resultados, atravs do seguinte critrio:

.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 informao IRS e guarda-o no ficheiro Fich_2 (para
posterior utilizao);

o outro processo inicial Admissao_2, este processo recebe os
fluxos Inform e DAux_1 (devido resposta questo da Fig. 33 ter
sido positiva) e guarda essa informao no ficheiro Fich_1;

o o processo Admissao_1 produz, a partir da informao existente no
Fich_1, o fluxo Inf_Trab. Este fluxo no tem influncia na
produo de qualquer outro fluxo de informao e, desta forma,
pode ser considerado redundante (o seu destino uma entidade
interna, que em princpio, utiliza este fluxo para unicamente
efectuar consultas ao seu contedo) ;

o o processo ResProc_3 produz, a partir da informao existente no
Fich_1 (cadastro do trabalhador), Fich_2 (Tabela de IRS) e
DAux_2 (Data do processamento mais os dias de ausncia dos


trabalhadores), o fluxo Recibo. Devido ao processo ResProc_5
necessitar de informao 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
informao existente em Fich_3 (igual informao de DAux_2) e
Fich_4 (contm a informao do Recibo).

.comparar o DFD gerado por ASA (ver Fig. 43) com o DFD (ver Fig. 45)
elaborado por um Analista de Sistemas (com vrios anos de experincia
nesta funo). Pela anlise dos dois diagramas verifica-se que as
diferenas so mnimas. Salienta-se, contudo, que a maior diferena nos
dois DFD's devido existncia do Fich_3 e Fich_4 para produzir o
documento Receita, ver Fig. 43. Esta diferena devido:


o ao processo de gerao automtica de informao, proceder
procura da origem da informao. Como os campos Ano e Mes
fazem parte do documento Receita e esses campos tm como
Admisso
Trabalhador
Inf_Trabalh
Trabalhadores
Emisso
Recibo
Gesto
IRS
Inf_IRS
IRS
Envia
Finanas
Pagamentos
IRS_Retido
Recibo_Venc
IRS
Fig. 45 - DFD elaborado por um Analista de Sistemas


origem o documento DAux-2, logo ASA vai buscar essa
informao ao documento DAux-2. Devido diferena das
frequncias dos documentos Receita e DAux-2, ASA criou o
ficheiro Fich_3 para poder satisfazer a produo do documento
Receita.

o ao documento Receita incluir um campo, denominado Dedu, que
existe somente no documento Recibo. Este campo, por ser do tipo
frmula, implica que, ASA no tenha necessidade, no processo
ResProc_5, de proceder novamente a esse clculo. Assim, ASA vai
buscar esse campo ao documento Recibo, mas devido diferena
de frequncias 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 informao inicialmente
fornecida. Assim, em termos de Arquitectura de Informao, verifica-se
que a informao, gerada por ASA, tem um nvel de detalhe diferente
daquele que lhe foi inicialmente fornecido (ver Tabela 2). Porque, a
informao fornecida, em termos de funes, encontra-se ao nvel da
Descrio da Organizao e a informao gerada est ao nvel da
Descrio do Sistema de Informao.

Ao analisar os resultados, segundo as perspectivas atrs referidas, conclui-
se que o DFD gerado pelo ASA, para alm de ser optimizado, satisfaz o sistema
RecHum e a informao gerada por ASA tm um nvel de detalhe superior ao inicial.


5.4 RESUMO

A validao do mtodo conseguida atravs da introduo de um exemplo
no prottipo ASA. Esse exemplo permitiu provar que:

.se evitou a ambiguidade e redundncia no dilogo com o utilizador
atravs do uso de facilidades grficas, tal como foi utilizado no momento
da definio do DFI;

.na visualizao dos resultados/diagnsticos, houve o cuidado de os
mostrar de forma a facilitar a leitura;

.existe qualidade nos resultados gerados pelo prottipo, atravs da anlise
do DFD gerado por ASA;

.os resultados gerados por ASA tm um nvel de detalhe diferente e
superior ao da informao inicialmente fornecida pelo "perito de
domnio".

CAPTULO 6

CONCLUSO

Neste captulo so apresentadas as concluses deste projecto.

Captulo 6: Concluso 111

O objectivo principal deste trabalho consistiu em validar e refinar um
mtodo de desenvolvimento de Sistemas de Informao, denominado por ASA -
Anlise de Sistemas Automtica, e que, fundamentalmente, enderea os domnios
aplicacionais de Anlise de Sistemas e Mtodos de Desenvolvimento.

A investigao de um mtodo como ASA surgiu devido complexidade
crescente dos Sistemas de Informao das organizaes que, para se manterem
competitivas perante um ambiente fortemente concorrencial, tm necessidade de
informao cada vez mais actualizada e integrada. Por outro lado, a maior parte dos
mtodos existentes ainda depende fortemente da capacidade da equipa que efectua a
actividade de desenvolvimento de Sistemas de Informao. De modo a tornar esses
mtodos mais eficientes, na rea da Anlise de Sistemas, e que possibilitem colmatar
as necessidades das organizaes, urge, pois, investigar mtodos que automatizem a
maior parte do trabalho a realizar, integrem e permitam a interveno do "perito do
domnio" na equipa de desenvolvimento.

Por outro lado, os Sistemas de Informao, quando informatizados e
automatizados, podem ser classificados como ferramentas de trabalho, devido a
automatizarem determinadas tarefas, aumentarem a produtividade e a qualidade do
trabalho realizado. No entanto, o desenvolvimento de Sistemas de Informao ainda
, muitas das vezes, realizado manualmente, isto , sem apoio de qualquer ferramenta
que automatize e verifique a consistncia das suas fases de desenvolvimento. Assim,
necessrio investigar ferramentas que automatizem determinadas tarefas,
aumentem a produtividade das equipas de desenvolvimento e a qualidade final das
aplicaes informticas.


ASA um mtodo, composto por tcnicas e notaes prprias, que foram
desenvolvidas com o objectivo de permitir modelar, de uma forma bastante
automatizada, Sistemas de Informao. Devido a essa caracterstica, o mtodo ASA
no foi estudado e desenvolvido para ser utilizado de uma forma manual, mas sim
com a ajuda de uma ferramenta que o suporte.

O funcionamento de ASA baseia-se fundamentalmente nos domnios
(funes das organizaes), no fluxo de informao entre os domnios e na
frequncia desses fluxos de informao. A utilizao das frequncias, permite
modelar a caracterstica dinmica dos sistemas existentes.

Outra caracterstica de ASA o processo automtico de gerao de
informao. Embora este processo no esteja ainda totalmente definido, j possvel,
a partir do Diagrama de Fluxos de Informao, identificar os processos e ficheiros
necessrios para a resoluo dos problemas propostos. informao gerada por
ASA so ainda acrescentados diversos relatrios de validao e consistncia da
informao existente.

ASA permite definir os Sistemas de Informao a um nvel da descrio da
organizao. Desta forma, quem for estudar um determinado Sistema de Informao
no dever necessitar de ter conhecimentos tcnicos na rea de Anlise de
Sistemas. Pode-se mesmo afirmar que a necessidade de conhecimentos se restringe
ao prprio sistema que se est a analisar.

Por outro lado, ao permitir a automatizao do processo de anlise,
garante-se que o sistema final no tenha tantas omisses ou mesmo erros. Deste
modo, ao se efectuarem alteraes ao nvel da anlise, os resultados so


automaticamente alterados e corrigidos para que se encontrem de acordo com os
requisitos pretendidos. O que poder reduzir, em termos de tempo e custo, o processo
de anlise de Sistemas de Informao.

A validao de ASA foi realizada atravs da elaborao de um prottipo
que, para alm de servir de referncia para uma futura ferramenta, implementa as
regras do seu funcionamento. A introduo de diversos exemplos nesse prottipo
permite validar o comportamento e os resultados obtidos de ASA. (Ver Anexo A).

Em termos de trabalho futuro e no mbito do mtodo ASA, existem diversas
reas que necessitam de ser exploradas:

.permitir a visualizao da exploso dos processos existentes em
processos elementares no DFD;

.modelao da estrutura dos dados, de forma a se poder obter o diagrama
de Entidades Relacionamento de uma forma automtica;

.tratamento de documentos de Entrada/Sada. Edio e descrio grfica
da estrutura e contedo de documentos;

.descrio dos processo de uma forma estruturada;

.ligao a um gerador de programas, cujos dados de entrada so os
resultados de anlise gerados por ASA.


Conclui-se que ASA, apesar de ainda no incluir todas as facilidades acima
descritas, possibilita, desde j, antever de, uma forma inequvoca, as potencialidades
deste mtodo.

BIBLIOGRAFIA

Amadeus Project, A Multi-method Approach for Developing Universal
Specifications, 1986

Blokdijk, A. e Blokdijk, P., Planning and Design of Information Systems,
Academic Press Limited, 1987

Chen, M. e Norman, R., A Framework for Integrated CASE, IEEE Software, March
1992

Chen, P., The entity-relationship model - a basis for the enterprise view of data,
National Computer Conference, 1977

Chikofsky, E. e Rubenstein, B., CASE: Reliability Engineering for Information
Systems, IEEE Software, March 1988

Choobineh, J., Mannino, M. e Tseng, V., A Form-Based Approach for Database
Analysis and Design, Communications of the ACM, Vol.35, N2, February 1992

Codd, E., Further normalisation of the data base relational model, Data Base
Systems, Courant Computer Synopsis Series, Vol.6, Prentice-Hall, 1970

Couto, E. S., Moreira, C. e Araujo, F., Teste validade de ASA, Projecto
Informtico, Universidade Portucalense, 1988

DeMarco, T., Structured Analysis and Structured Design, Yourdon Inc., 1979

Dijkstra, E. W., Structured Programming, Academic Press, London, 1972

Ferreira, M. F. e Azevedo, P., GARD - Gerador Automtico de Relaes entre
Documentos, Projecto Informtico, Universidade Portucalense, 1990

Bibliografia 116

Gane, C. e Sarson, T., Structured Systems Analysis: Tools and Techniques,
Prentice-Hall, 1979

Godinho, A. L. e Lopes, M. F. C., Instrumentos de Apoio e Deciso em Anlise de
Sistemas, Centro de Tecnologia da Informao - Departamento de Informtica -
Universidade Portucalense, Relatrio N 001.87, Fevereiro de 1987

Godinho, A. L. e Lopes, M. F. C., Teste validade do ASA, Centro de Tecnologia
da Informao - Departamento de Informtica - Universidade Portucalense, Relatrio
N 002.88, Junho de 1988

Gordon, G., System simulation, Prentice-Hall, New Jersey, 1969

Humphrey, W., Characterising the Software Process: A Maturity Framework,
IEEE Software, March 1988

Jackson, M., System Development, Prentice-Hall, 1983

Layzell, P.J. e Loucopoulos P., Systems Analysis and Development, Chartwell-Biatt
Ltd, 1986

Lopes, M. F. C., M.Sc. Thesis, UMIST, 1990

Macdonald, I. G., Information Engineering - An improved, Automatable
Methodology for the Design of Data Sharing Systems, Proceedings of the IFIP WG
8.1 Working Conference on Comparative Review on Information Systems Design
Methodologies: Improving the Practice, May 1986

Moigne, J., La thorie du systme gnral, Paris, 1977

Norman, R. e Chen, M., Working Together to Integrate CASE, IEEE Software,
March 1992

Pressman, R. S., SOFTWARE ENGINEERING - A Practitioner's Approach,
McGraw-Hill, Second edition, 1987

Bibliografia 117

QED - Information Science, Inc., CASE The potential and the pitfalls, Wellesley,
Massachusetts, 1989

Rosnay, J., Le macroscope: vers une vision globale, Edition du Seuil, Paris, 1975

Shearer, J. L., Murphy, A. T. e Richardson, H. H., Introduction to system
dynamics, Adison-Wesley, 1967

Stevens, W., Meyers, G. e Constantine, L., Structured Design, IBM Systems
Journal, N2, 1974

Towner, L. E., CASE - Concepts and Implementation, McGraw-Hill, J.Ranade IBM
Series, 1989

Yourdon, E., Managing the Structured Techniques: Strategies for software
development in the 1990s, Yourdon Press, 1986

Yourdon E. e Constantine L., Structured Design, Prentice-Hall, 1987

ANEXO A

EXEMPLOS

Neste anexo apresentado um exemplo que, atravs de duas aproximaes,
possibilita observar o comportamento e os resultados gerados por ASA.

O exemplo consiste num hipottico departamento de pessoal. Na primeira
aproximao, o departamento de pessoal tem como funo emitir todos os meses os
recibos dos trabalhadores. Na segunda aproximao, foram incluidas novas funes,
tais como: admisso de novos trabalhadores, calculo do IRS automtico e envio do
IRS retido para os servios centrais das finanas.

Anexo A - Exemplos A2

APROXIMAO 1 - PAGAMENTO MANUAL

Esta aproximao descreve um Sistema de Informao de um departamento
de pessoal, em que a nica funo existente emitir todos os meses o recibo de
vencimento dos trabalhadores. Para emitir o recibo, o domnio pessoal tem que
fornecer toda a informao necessria ao seu processamento, como pode ser
verificado no DFI a seguir apresentado:

Apresenta-se, de seguida, a informao que tem que ser fornecida a ASA:

O Documento Recibo composto por :

Bloco Cabealho Cabecalh
- Ano do processamento - Ano
- Ms do processamento - Mes
- Nome da organizao - NomOrg
- Nmero do trabalhador - NTrab
- Nome do trabalhador - Nome
- Categoria Profissional - CatProf
- Nmero de Segurana Social - NSegSoc
- Nmero de Contribuinte - NContr
Bloco Corpo Corpo
- Vencimento ilquido - Venciliq
- Dias Trabalhveis - DTrab
- Dias Ausncia - DAus
- Dias Pagos - DPag = DTrab - DAus
Pessoal
Trabalha
Recibo (Clock1)
Clock1 - Todos os Meses no dia 25


- Remuneraes - Remun= (Venciliq * DPag) / DTrab
- Descontos Segurana Social - DescSS= Remun * 11%
- Dedues ao IRS - Dedu
- Liquido a receber - Liq = Remun - DescSS - Dedu

Apresenta-se, de seguida, toda a informao gerada automaticamente por ASA.


Sistemas:

rechum1
Descr.: gesto de recursos humanos 1
Domnios:
pessoal
Descr.: departamento de pessoal
Tipo: Interno e Local
trabalha
Descr.: trabalhador
Tipo: Externo

Sistema sem problemas

Domnios:

pessoal
No tem Documentos de Entrada
Documentos que saem
recibo
Descr.: recibo do trabalhador
Freq.: clock1 5
Problemas encontrados:
Parece faltar contacto de trabalha
------------------------------------------------------------------------------------------
trabalha
Descr.: trabalhador
Tipo: Externo
Documentos que entram
recibo
Freq.: clock1 5
No tem Documentos de Sada
Parece faltar resposta para pessoal

Documentos:

recibo
Freq.clock1 5
Bloco: corpo
Descr.: calculo do recibo
Campos:
remun
Descr.: remuneraes
Tipo: f
Formula: ([venciliq]*[dpag])/[dtrab]
Campos elementares:
dtrab
venciliq
daus


Ident.: n
liq
Descr.: liquido a receber
Tipo: f
Formula: [remun]-[descss]-[dedu]
Campos elementares:
daus
dedu
dtrab
venciliq
Ident.: n
venciliq
Descr.: vencimento ilquido
Tipo: v
Ident.: n
dtrab
Descr.: dias trabalhveis
Tipo: v
Ident.: n
daus
Descr.: dias de ausncia
Tipo: v
Ident.: n
dpag
Descr.: dias pagos
Tipo: f
Formula: [dtrab]-[daus]
Campos elementares:
dtrab
daus
Ident.: n
descss
Descr.: descontos segurana social
Tipo: f
Formula: [remun]*11%
Campos elementares:
dtrab
venciliq
daus
Ident.: n
dedu
Descr.: dedues de irs
Tipo: v
Ident.: n
Bloco: cabecalh
Descr.: identificao
Campos:
ano
Descr.: ano do processamento
Tipo: v
Ident.: n
mes
Descr.: ms do processamento
Tipo: v
Ident.: n
nomorg


Descr.: nome da organizao
Tipo: c
Constante: xpto, lda
Ident.: n
ntrab
Descr.: nmero do trabalhador
Tipo: v
Ident.: n
catprof
Descr.: categoria profissional
Tipo: v
Ident.: n
ncontr
Descr.: nmero de contribuinte
Tipo: v
Ident.: n
nome
Descr.: nome do trabalhador
Tipo: v
Ident.: n
nsegsoc
Descr.: nmero de segurana social
Tipo: v
Ident.: n
Documento sem problemas!
--------------------------------------------------------------------------------------------
Documentos deduzidos:

daux-1
Freq.: clock1 5
Campos:
ano
mes
ntrab
catprof
ncontr
nome
nsegsoc
venciliq
dtrab
daus
dedu

Campos:

ano
Origem: [daux-1]
Documentos:
recibo
Campo sem problemas!
------------------------------------------------------------------------------------------
catprof
Origem: [daux-1]


Documentos:
recibo
------------------------------------------------------------------------------------------
daus
Origem: [daux-1]
Documentos:
recibo
------------------------------------------------------------------------------------------
dedu
Origem: [daux-1]
Documentos:
recibo
------------------------------------------------------------------------------------------
descss
Documentos:
recibo
------------------------------------------------------------------------------------------
dpag
Descr.: dias pagos
Documentos:
recibo
------------------------------------------------------------------------------------------
dtrab
Origem: [daux-1]
Documentos:
recibo
------------------------------------------------------------------------------------------
liq
Documentos:
recibo
------------------------------------------------------------------------------------------
mes
Origem: [daux-1]
Documentos:
recibo
------------------------------------------------------------------------------------------
ncontr
Origem: [daux-1]


Documentos:
recibo
------------------------------------------------------------------------------------------
nome
Origem: [daux-1]
Documentos:
recibo
------------------------------------------------------------------------------------------
nomorg
Origem: [recibo]
Documentos:
recibo
------------------------------------------------------------------------------------------
nsegsoc
Origem: [daux-1]
Documentos:
recibo
------------------------------------------------------------------------------------------
ntrab
Origem: [daux-1]
Documentos:
recibo
------------------------------------------------------------------------------------------
remun
Descr.: remuneraes
Documentos:
recibo
------------------------------------------------------------------------------------------
venciliq
Origem: [daux-1]
Documentos:
recibo

Processos:

pessoal_1
Dom.: pessoal
Freq.: clock1 5
Doc. de Entrada:
daux-1
Freq.: clock1 5
Documentos de sada:


recibo
Freq.: clock1 5
Sem problemas

Entidades:

ent-pessoal1
Domnio: pessoal
Freq.: clock1 5
Documento: daux-1
Freq.: clock1 5
Campos
ano
mes
ntrab
catprof
ncontr
nome
nsegsoc
venciliq
dtrab
daus
dedu

Diagrama de Fluxos de Dados (Contexto):

Diagrama de Fluxos de Dados (Diagrama 0):



APROXIMAO 2 - MARCAO DE AUSNCIAS NOS DEPARTAMEN-
TOS E CALCULO DO IRS AUTOMTICO

Nesta aproximao, o Responsvel pelo Processamento (Domnio pessoal)
recebe diversos documentos de outros domnios com informao necessria para a
emisso dos Recibos, tais como: as folhas de ausncia dos diversos departamentos
existentes e a tabela de IRS das Finanas. Conforme o DFI a seguir apresentado:

Apresenta-se, de seguida, a informao que foi fornecida a ASA (este sistema foi
desenvolvido a partir da aproximao 1, o que facilita a tarefa de fornecimento da
informao):

Documento Recibo sofreu alteraes nos campos:

Bloco Corpo Corpo
- Dias Ausncia - DAus = ( Se( Mes = MesAus, Se( Ano =
AnoAus, Se( Ntrab = NTAus, HAus , 0),
0), 0) ) / 24
- Dedues ao IRS - Dedu = Se(ECiv=EcivIRS, Se(NDep=
NDepIRS, Remun * TIRS, 0), 0)

e foram-lhe acrescentados os campos:

Bloco Cabealho Cabecalh
Pessoal
Trabalha
Recibo (Clock1)
Finanas
IRS(Clock2)
Clock2 - Todos os anos no mes de Janeiro
Departam
Aus(Clock4)
Receita(Clock3)
TaxAbsen(Clock1)


- Estado Civil - ECiv
- Nmero de dependentes - NDep

Documento IRS composto por:

Bloco Registo Registo
- Estado Civil - ECivIRS
- Nmero de dependentes - NDepIRS
- Taxa de IRS -TIRS

Documento Receita composto por:

- Nmero de Contribuinte - NContr
- Ano - Ano
- Ms - Mes
- Dedues ao IRS - Dedu

Documento Aus composto por

- Ano - AnoAus
- Ms - MesAus
- Dia - DiaAus
- Nmero do trabalhador - NTAus
- Ausncia (Horas) - HAus

Documento TaxAbsen composto por

- Ano - Ano
- Ms - Mes
- Taxa de Absentismo - TAbs = ( DTrab DAus ) /
DTrab

Apresenta-se, de seguida, os resultados gerados automaticamente por ASA:


Sistemas:

rechum2
Descr.: ausncias e irs existentes
Domnios:
pessoal
trabalha
Descr.: trabalhador
Tipo: Externo
finana
Descr.: finanas (depart. irs)
Tipo: Externo
departam
Descr.: departamentos
Sistema sem problemas

Domnios:

pessoal
irs
Descr.:
Freq.: ext0 0
aus
Descr.: ficha de ausncias
Freq.: clock2 3
Documentos que saem
recibo
Freq.: clock1 5
receita
Descr.: devoluo da reteno
Freq.: clock3 7
taxabsen
Descr.:
Freq.: 0
Parece faltar contacto de trabalha
------------------------------------------------------------------------------------------------------
trabalha
Descr.: trabalhador
Tipo: Externo
recibo
Freq.: clock1 5
No tem Documentos de Sada
Parece faltar resposta para pessoal
------------------------------------------------------------------------------------------------------


finana
Descr.: finanas (depart. irs)
Tipo: Externo
receita
Freq.: clock3 7
Documentos que saem
irs
Descr.:
Freq.: ext0 0
Domnio sem problemas.
------------------------------------------------------------------------------------------------------
departam
Descr.: departamentos
taxabsen
Descr.:
Freq.: 0
Documentos que saem
aus
Freq.: clock2 3
Domnio parece ser redundante

Documentos:

aus
Freq.clock2 3
Bloco: registo
Descr.: linha da ficha de ausncias
Campos:
anoaus
Descr.: ano a que respeitam as ausnci
Tipo: v
Ident.: n
mesaus
Descr.: ms a que respeitam as ausnci
Tipo: v
Ident.: n
diaaus
Descr.: dia do ms a que respeitam as
Tipo: v
Ident.: n
haus
Descr.: horas que faltou
Tipo: v
Ident.: n
ntaus
Descr.: nmero de trabalhador
Tipo: v


Ident.: n
Doc. parece ser redundante no domnio pessoal
------------------------------------------------------------------------------------------------------
irs
Descr.:
Freq.ext0 0
Bloco: registo
Descr.: registo da tabela de irs
Campos:
ecivirs
Descr.: estado civil
Tipo: v
Ident.: n
ndepirs
Descr.: nmero de dependentes
Tipo: v
Ident.: n
tirs
Descr.: taxa de irs
Tipo: v
Ident.: n
Falta a descrio
------------------------------------------------------------------------------------------------------
receita
Freq.clock3 7
Bloco: registo
Descr.: reteno na fonte
Campos:
ncontr
Tipo: v
Ident.: n
ano
Tipo: v
Ident.: n
mes
Tipo: v
Ident.: n
dedu
Tipo: f
Formula: se([eciv]=[ecivirs],se([ndep]=[ndepirs],[remun]*[tirs],0),0)
Formula j calculada!
Ident.: n
------------------------------------------------------------------------------------------------------
recibo
Freq.clock1 5
Bloco: corpo
Descr.: calculo do recibo


Campos:
remun
Descr.: remuneraes
Tipo: f
Campos elementares:
ano
anoaus
dtrab
mes
mesaus
ntaus
ntrab
venciliq
haus
Ident.: n
liq
Tipo: f
Campos elementares:
ano
anoaus
dtrab
eciv
ecivirs
haus
mes
mesaus
ndep
ndepirs
ntaus
ntrab
tirs
venciliq
Ident.: n
venciliq
Tipo: v
Ident.: n
dtrab
Tipo: v
Ident.: n
daus
Tipo: f
Formula: se([mes]=[mesaus],se([ano]=[anoaus],se([ntrab]=[ntaus],
soma([haus]),0),0),0)/24
Campos elementares:
ano
anoaus
mes
mesaus
ntaus
ntrab


haus
Ident.: n
dpag
Descr.: dias pagos
Tipo: f
Campos elementares:
ano
anoaus
dtrab
mes
mesaus
ntaus
ntrab
haus
Ident.: n
descss
Tipo: f
Campos elementares:
ano
anoaus
dtrab
mes
mesaus
ntaus
ntrab
venciliq
haus
Ident.: n
dedu
Tipo: f
Campos elementares:
ano
anoaus
dtrab
eciv
ecivirs
mes
mesaus
ndep
ndepirs
ntaus
ntrab
tirs
venciliq
haus
Ident.: n
Bloco: cabecalh
Descr.: identificao
Campos:
ano


Tipo: v
Ident.: n
mes
Tipo: v
Ident.: n
nomorg
Tipo: c
Constante: xpto, lda
Ident.: n
ntrab
Tipo: v
Ident.: n
catprof
Tipo: v
Ident.: n
ncontr
Tipo: v
Ident.: n
nome
Tipo: v
Ident.: n
nsegsoc
Tipo: v
Ident.: n
eciv
Tipo: v
Ident.: n
ndep
Tipo: v
Ident.: n
------------------------------------------------------------------------------------------------------
taxabsen
Descr.: taxa de absentismo geral
Freq.clock4 6
Bloco: registo
Descr.: valor da taxa de absentismo
Campos:
ano
Tipo: v
Ident.: n
mes
Tipo: v
Ident.: n
tabs


Descr.: taxa de absentismo
Tipo: f
Formula: (soma([dtrab])-soma([daus]))/soma([dtrab])
Campos elementares:
ano
anoaus
dtrab
mes
mesaus
ntaus
ntrab
haus
Ident.: n
Doc. parece ser redundante no domnio departam
------------------------------------------------------------------------------------------------------
Documentos deduzidos:
daux-1
Freq.: clock2 3
Campos
anoaus
mesaus
diaaus
haus
ntaus
------------------------------------------------------------------------------------------------------
daux-2
Freq.: clock1 5
Campos
ano
mes
ntrab
catprof
ncontr
nome
nsegsoc
venciliq
dtrab
eciv
ndep

Campos:

ano
Origem: [daux-2]
Documentos:
receita
Temp.: clock3 7
recibo
Temp.: clock1 5
taxabsen


Temp.: clock4 6
------------------------------------------------------------------------------------------------------
anoaus
Descr.: ano a que respeitam as ausnci
Origem: [daux-1]
Documentos:
aus
Temp.: clock2 3
recibo
Temp.: clock1 5
taxabsen
Temp.: clock4 6
------------------------------------------------------------------------------------------------------
catprof
Origem: [daux-2]
Documentos:
recibo
Temp.: clock1 5
------------------------------------------------------------------------------------------------------
daus
Formula: se([mes]=[mesaus],se([ano]=[anoaus],se([ntrab]=[ntaus],
soma([haus]),0),0),0)/24
Documentos:
recibo
Temp.: clock1 5
------------------------------------------------------------------------------------------------------
dedu
Documentos:
recibo
Temp.: clock1 5
Origem: [recibo]
Documentos:
receita
Temp.: clock3 7
------------------------------------------------------------------------------------------------------
descss
Documentos:
recibo


Temp.: clock1 5
------------------------------------------------------------------------------------------------------
diaaus
Descr.: dia do ms a que respeitam as
Origem: [daux-1]
Documentos:
aus
Temp.: clock2 3
------------------------------------------------------------------------------------------------------
dpag
Descr.: dias pagos
Documentos:
recibo
Temp.: clock1 5
------------------------------------------------------------------------------------------------------
dtrab
Origem: [daux-2]
Documentos:
recibo
Temp.: clock1 5
taxabsen
Temp.: clock4 6
------------------------------------------------------------------------------------------------------
eciv
Origem: [daux-2]
Documentos:
recibo
Temp.: clock1 5
------------------------------------------------------------------------------------------------------
ecivirs
Origem: [irs]
Documentos:
irs
Descr.:
Temp.: ext0 0
recibo
Temp.: clock1 5
------------------------------------------------------------------------------------------------------
haus


Descr.: horas que faltou
Origem: [daux-1]
Documentos:
aus
Temp.: clock2 3
recibo
Temp.: clock1 5
taxabsen
Temp.: clock4 6
------------------------------------------------------------------------------------------------------
liq
Documentos:
recibo
Temp.: clock1 5
------------------------------------------------------------------------------------------------------
mes
Origem: [daux-2]
Documentos:
receita
Temp.: clock3 7
recibo
Temp.: clock1 5
taxabsen
Temp.: clock4 6
------------------------------------------------------------------------------------------------------
mesaus
Descr.: ms a que respeitam as ausnci
Origem: [daux-1]
Documentos:
aus
Temp.: clock2 3
recibo
Temp.: clock1 5
taxabsen
Temp.: clock4 6
------------------------------------------------------------------------------------------------------
ncontr
Origem: [daux-2]


Documentos:
receita
Temp.: clock3 7
recibo
Temp.: clock1 5
------------------------------------------------------------------------------------------------------
ndep
Origem: [daux-2]
Documentos:
recibo
Temp.: clock1 5
------------------------------------------------------------------------------------------------------
ndepirs
Origem: [irs]
Documentos:
irs
Descr.:
Temp.: ext0 0
recibo
Temp.: clock1 5
------------------------------------------------------------------------------------------------------
nome
Origem: [daux-2]
Documentos:
recibo
Temp.: clock1 5
------------------------------------------------------------------------------------------------------
nomorg
Origem: [recibo]
Documentos:
recibo
Temp.: clock1 5
------------------------------------------------------------------------------------------------------
nsegsoc
Origem: [daux-2]
Documentos:
recibo
Temp.: clock1 5


------------------------------------------------------------------------------------------------------
ntaus
Descr.: nmero de trabalhador
Origem: [daux-1]
Documentos:
aus
Temp.: clock2 3
recibo
Temp.: clock1 5
taxabsen
Temp.: clock4 6
------------------------------------------------------------------------------------------------------
ntrab
Origem: [daux-2]
Documentos:
recibo
Temp.: clock1 5
taxabsen
Temp.: clock4 6
------------------------------------------------------------------------------------------------------
remun
Descr.: remuneraes
Documentos:
recibo
Temp.: clock1 5
------------------------------------------------------------------------------------------------------
tabs
Descr.: taxa de absentismo
Formula: (soma([dtrab])-soma([daus]))/soma([dtrab])
Documentos:
taxabsen
Temp.: clock4 6
------------------------------------------------------------------------------------------------------
tirs
Descr.: taxa de irs
Origem: [irs]
Documentos:
irs
Descr.:
Temp.: ext0 0
recibo
Temp.: clock1 5


------------------------------------------------------------------------------------------------------
venciliq
Origem: [daux-2]
Documentos:
recibo
Temp.: clock1 5

Processos:

departam_1
Dom.: departam
Freq.: clock2 3
Doc. de Entrada:
daux-1
Freq.: clock2 3
Documentos de sada:
fich_2
aus
Freq.: clock2 3
Sem problemas
------------------------------------------------------------------------------------------------------
pessoal_2
Dom.: pessoal
Freq.: clock1 5
Doc. de Entrada:
daux-2
Freq.: clock1 5
fich_2
fich_1
Documentos de sada:
fich_4
recibo
Freq.: clock1 5
fich_3
Sem problemas
------------------------------------------------------------------------------------------------------
pessoal_3
Dom.: pessoal
Freq.: ext0 0
Doc. de Entrada:
irs
Descr.:
Freq.: ext0 0
Documentos de sada:
fich_1
Sem problemas
------------------------------------------------------------------------------------------------------
pessoal_4
Dom.: pessoal


Freq.: clock4 6
Doc. de Entrada:
fich_3
fich_2
Documentos de sada:
taxabsen
Freq.: clock4 6
Parece ser redundante
------------------------------------------------------------------------------------------------------
pessoal_5
Dom.: pessoal
Freq.: clock3 7
Doc. de Entrada:
fich_3
fich_4
Documentos de sada:
receita
Freq.: clock3 7
Sem problemas

Ficheiros:

fich_1
Domnio: pessoal
Documento Origem: irs
Campos:
ecivirs
Ident.: n
ndepirs
Ident.: n
tirs
Ident.: n
Lista de processos que utilizam este ficheiro:
pessoal_ 2
Campos do ficheiro utilizados:
ecivirs
ndepirs
tirs
------------------------------------------------------------------------------------------------------
fich_2
Domnio: pessoal
Documento Origem: daux-1
Campos:
anoaus
Ident.: n
mesaus
Ident.: n
diaaus
Ident.: n
haus
Ident.: n
ntaus


Ident.: n
pessoal_ 2
pessoal_ 4
anoaus
mesaus
haus
ntaus
Campos do ficheiro que no foram utilizados:
diaaus
------------------------------------------------------------------------------------------------------
fich_3
Domnio: pessoal
Documento Origem: daux-2
Campos:
ano
Ident.: n
mes
Ident.: n
ntrab
Ident.: n
catprof
Ident.: n
ncontr
Ident.: n
nome
Ident.: n
nsegsoc
Ident.: n
venciliq
Ident.: n
dtrab
Ident.: n
eciv
Ident.: n
ndep
Ident.: n
pessoal_ 4
pessoal_ 5
ano
mes
ntrab
ncontr
dtrab
catprof
nome
nsegsoc
venciliq
eciv
ndep
------------------------------------------------------------------------------------------------------
fich_4


Domnio: pessoal
Documento Origem: recibo
Campos:
ano
Ident.: n
mes
Ident.: n
nomorg
Ident.: n
ntrab
Ident.: n
remun
Ident.: n
liq
Ident.: n
catprof
Ident.: n
ncontr
Ident.: n
nome
Ident.: n
nsegsoc
Ident.: n
venciliq
Ident.: n
dtrab
Ident.: n
daus
Ident.: n
dpag
Ident.: n
descss
Ident.: n
dedu
Ident.: n
eciv
Ident.: n
ndep
Ident.: n
pessoal_ 5
dedu
ano
mes
nomorg
ntrab
remun
liq
catprof
ncontr
nome
nsegsoc
venciliq
dtrab


daus
dpag
descss
eciv
ndep

Entidades:

ent-departam1
Domnio: departam
Freq.: clock2 3
Documento: daux-1
Freq.: clock2 3
Campos
anoaus
mesaus
diaaus
haus
ntaus
------------------------------------------------------------------------------------------------------
ent-pessoal1
Domnio: pessoal
Freq.: ext0 0
Documento: irs
Freq.: ext0 0
Campos
ecivirs
ndepirs
tirs
------------------------------------------------------------------------------------------------------
ent-pessoal2
Domnio: pessoal
Freq.: clock1 5
Documento: daux-2
Freq.: clock1 5
Campos
ano
mes
ntrab
catprof
ncontr
nome
nsegsoc
venciliq
dtrab
eciv
ndep

Diagrama de Fluxos de Dados (Contexto):


Diagrama de Fluxos de Dados (Diagrama 0):

ANEXO B

LI STA DE MTODOS

Neste anexo apresenta-se uma lista de mtodos de Anlise de Sistemas e
Desenvolvimento.

Anexo B - Lista de Mtodos B2

MTODOS DE ANLISE DE SISTEMAS E DESENVOLVIMENTO

Abreviatura Nome Completo Entidade que desenvolveu

ACM/PCM Active and Passive Component Modelling Brodie Computer Corp. Of
America
AXIAL Axial IBM, Frana
BC Bubble Charting IBM
BSP Business System Planning IBM
CIAM Conceptual Information Analysis Method Bubenko
D2S2 Development of Data Sharing Systems CACI
DADES Data Oriented Design Antoni Olive, Univ. Politecnica
Barcelona
DSSAD Data Structured Systems Analysis and
Design
Colin Kneight
DSSD Data Structured Systems Development Ken Orr and Assoc.
EDM Evolutionary Design Methodology George Rzevski
ERAE Entity, Relationship, Attribute, Event Philips Research Laboratory,
Bruchelas
FOUR-FRONT Four-Front Ross and Thomatsu
GEIS Gradual Evolution of Information Systems Veiko Keha
GOS Gestruktureed ontwerp van systemen
HIPO Hierarchical Input Processing Output IBM
HOS Higher Order Software HOS Inc., Cambridge
IDA Interactive Design Approach Universidade de Namur, Belgica
IESM Information Engineering Specification
Method
Resource Mgmt. Ltd
IE Information Engineering James Martin Associates
IML Information Management Language GMD, Alemanha
INFOLOG INFOrmation LOGic Universidade de Lisboa, Portugal
ISAC Information Systems Work and Analysis of
Changes
Mats Ludenberg
ISSM Integration Systems Specification Models Solvberg
JSD Jackson Systems Development Jackson, MJSL
LBMS - SDM -
SSADM
Learmoth & Burchet Management -
Systems System Development Method
Learmoth & Burchet
Merise Merise Tardieu
METHOD/1 Method/1 Arthur Anderson & Co.
MOS Methodical Design of Systems Desisco
NIAM Nijssen's Information Analysis Method Control Data, Belgica
PARET Project Aanpak Raet
PRADOS Projektabwicklungs und
Dokumentationssystem
Scientific Control System GmbH
PRISMA Prisma
PRODOSTA Projekt Dokumentatie en Standaard Philips
PROMOD GEI, Alemanha
PROMPT Project Resource Organisation
Management Planning Techniques
BSO, Utrecht
PSL/PSA Problem Statement Language/Problem
Statement Analysis
ISDOS, Michigan
REMORA Remora Rolland

Anexo B - Lista de Mtodos B3

Abreviatura Nome Completo Entidade que desenvolveu

RML Requirements Modelling Language Universidade de Toronto,
Canada
SADT Structured Analysis & Design
Technique
Ross, Infotech
SARA System ARquitects Apprentice Prof. Gerald Estrin,
UCLA
SASD Structured Analysis and
Structured Design
DeMarco, Yourdon
SASO Systems Analysis and System
Design
IBM
SD1 Systems Developer Hannu Kangassalo,
Univ. de Tempere,
Finlndia
SD2 Structure Design Yourdon & Constantino
SDLA System Descriptor and Logical
Analyser
E.Knuth, F.Halasz,
P.Rado
SDM System Development
Methodology
Pandata BV, Holanda
SEPN Software Engineering
Procedures
Hughes Aircraft Co.
SF Set-Function Approach Universidade de
Pittsburgh, USA
SMX Systematrix
SREM Software Requirements
Engineering Methodology
TRW, Untsville
Laboratory
SSA Structured Systems Analysis Exxon, USA
STFC Structured Techniques of
Computing

STRADIS STRuctured Analysis, Design
and Implementation of Inf.
Systems
McDonnel Autom.
SYSDOC SYSDOC Methodology and
SYSTEMATOR
Aschim & Braaten
TAXIS TAXIS Universidade de
Toronto
TIA Techniques for Information
Analysis
Pandata BV, Holanda
USE User Software Engineering A. Wasserman, UCSF
VDM Vienna Development Method Jones
Warrier Orr Warrier Orr Warrier & Orr

ANEXO C

GLOSSRI O

Neste anexo so apresentados os significados para os termos menos comuns
e que foram utilizados ao longo deste projecto.

Anexo C - Glossrio C2

Termos Significados

Bloco Identifica um subconjunto da informao de um
documento.

Calculo Descrio da operao a efectuar.

Campo Elemento de informao de um documento.

Campo
Entrada
Classe de um campo cuja informao provm de
um documento de entrada.

Campo
Esttico
um documento esttico.

Campo
Ficheiro
dados existente num ficheiro.

Constante Classe de um campo texto.

Classe Fonte dos dados que vo ser inscritos nos campos.

DFD Diagrama de Fluxos de Dados.

DFI Diagrama de Fluxo de Informao, permite
modelar uma organizao.

DFII Diagrama de Fluxo de Informao Interna, permite
obter os processos, ficheiros automaticamente e
documentos estticos.

Documento Fluxo de informao (composto por campos) que
circula entre domnios.


Termos Significados

Documento
Entrada

Documento produzido noutro domnio e a ser
utilizado pelo domnio em causa.
Documento
Sada
Documento produzido num determinado domnio e
a ser usado noutro domnio.

Domnio Funo existente dentro de uma organizao
(Sistema de Informao).

Entidade
Externa
Entidade no pertencente ao domnio em estudo.

Entidade
Interna
Entidade pertencente ao domnio em estudo.

Esttico
Informao auxiliar fornecida por uma entidade
interna ao Sistema em estudo.

Ficheiro Repositrio de informao; criado para guardar
temporariamente a informao entre os diversos
processos.

Frmula Classe de um campo, cujo contedo obtido
atravs de um calculo.

Frequncia Permite temporizar os eventos.

Identificador Caracterstica de um campo que permite identificar
um documento.

Perito do
Domnio
Pode tambm ser denominado por utilizador final.
quem conhece profundamente um determinado
domnio e dessa forma consegue descrever o seu
funcionamento.

Termos Significados


Peso Valor da frequncia de ocorrncia dos documentos,
se o valor de peso for prximo de 0 ento o
documento ocorre muitas vezes, caso contrrio
quanto mais alto for o valor do peso menor a
ocorrncia do documento.

Processo Operaes que permitem transformar os
documentos de entrada em documentos de sada
num determinado domnio.

Sistema Classe de um campo cuja informao provm do
sistema operativo (ex. data).

Texto Classe de um campo cuja informao provm de
dados definidos como constantes no processo do
mesmo.

Tipo Identifica se o campo numrico, alfanumrico ou
alfabtico.

TESE Mestrado Jorge Oliveira e Sá

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

TESE Mestrado Jorge Oliveira e Sá

Загружено:

Авторское право:

Доступные форматы

ASA - ANLISE DE SISTEMAS AUTOMTICA

Вам также может понравиться