ASA - Análise de Sistemas Automática

Texto

(1)ASA - ANÁLISE DE SISTEMAS AUTOMÁTICA por Jorge Vaz de Oliveira e Sá. Tese submetida à. UNIVERSIDADE DO MINHO para obtenção do grau de MESTRE EM INFORMÁTICA Especialidade em Informática de Gestão. Departamento de Informática Universidade do Minho. Dezembro de 1993.

(2)

(3) AGRADECIMENTOS. Em primeiro lugar, os meus agradecimentos especiais para o supervisor, Dr. António Godinho, que esteve sempre presente, durante o desenrolar deste trabalho, através das suas valiosas sugestões e anotações.. Para os meus Pais, pelo apoio incondicional sem o qual esta tese não teria sido possível.. Para o Eng. Luis Amaral e Dr. João Alvaro, pelas suas sugestões e críticas. 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 Investigação Cientifica e Tecnológica, através do seu Programa Ciência, a concessão de uma Bolsa de Estudos..

(4) SUMÁRIO. A produtividade da equipa de desenvolvimento e a qualidade das aplicações produzidas são dois dos principais problemas que ainda persistem no desenvolvimento de Sistemas de Informação. Estes problemas existem devido ao desenvolvimento de aplicações informáticas ser ainda do tipo "papel e lápis" e estar fortemente, dependente, da experiência da equipa de desenvolvimento, o que implica consequentemente o aparecimento de inúmeras falhas e/ou lapsos.. ASA, Análise de Sistemas Automática, é o resultado de uma tentativa de solução dos problemas anteriores. ASA é composto por um método de análise e uma ferramenta de desenvolvimento de aplicações, concebida com o propósito de permitir tirar partido das vantagens da automatização.. Este projecto consiste em refinar e validar ASA. Para o efeito foi construído um protótipo com o objectivo de, incrementalmente, refinar e validar as técnicas e as respectivas notações adoptadas em ASA.. ASA, permite automatizar de uma forma simples, rápida e eficiente a actividade de Análise de Sistemas de Informação. Desta forma, para além de garantir a fiabilidade da informação, permite a manipulação e fornecimento da mesma pelo utilizador, o "perito de domínio". Consequentemente, ASA possibilita gerar resultados a partir da especificação inicial, soluciona parte do problema de manutenção das aplicações e é uma tentativa de redução do tempo e custo do desenvolvimento de Sistemas de Informação..

(5) ÍNDICE. Capítulo 1: Introdução .................................................................................................. 1. 1.1 Visão geral .................................................................................................. 1.2 Tema do Projecto ........................................................................................ 1.3 Abordagem ao Projecto ............................................................................... 1.4 Organização do Relatório ............................................................................. 2 7 9 10. Capítulo 2: Fundamentos teóricos ................................................................................ 12. 2.1 Definição de sistema .................................................................................... 2.2 Sistema de Informação ................................................................................ 2.2.1 Metodologia de Desenvolvimento de Sistemas de Informação ............ 2.2.2 Ferramentas ....................................................................................... 2.2.3 Arquitectura de Informação ............................................................... 2.4 Enquadramento com ASA .......................................................................... Capítulo 3: Estudo do Método ..................................................................................... 3.1 Evolução do Método ................................................................................... 3.2 Entrada de Informação ................................................................................ 3.2.1 Diagrama de Fluxos de Informação .................................................... 3.2.2 Descrição da Informação ................................................................... 3.3 Automatização ............................................................................................ 3.3.1 Matriz de Redundância Múltipla ........................................................ 3.3.2 Tabela de Relações de Entrada/Saída de Informação .......................... 3.3.3 Diagrama de Fluxos de Informação Interna ......................................... 3.4 Trabalhos Anteriores .................................................................................... 3.5 Caracterização do Método ........................................................................... 3.6 Resumo ....................................................................................................... 13 16 17 23 25 28 29 30 31 31 39 39 39 43 44 49 51 55.

(6) Índice. Capítulo 4: Refinamento do Método ........................................................................... 4.1 Objectivos a Atingir ..................................................................................... 4.2 Entrada de Informação ................................................................................ 4.2.1 Diagrama de Fluxos de Informação .................................................... 4.2.2 Descrição da Informação ................................................................... 4.3 Automatização ............................................................................................ 4.3.1 Diagrama de Fluxos de Informação Interna ........................................ 4.4 Ferramenta ASA .......................................................................................... 4.5 Caracterização do Método ........................................................................... 4.6 Resumo ........................................................................................................ 59 60 61 62 63 64 65 69 74 78. Capítulo 5: Validação do Método ................................................................................. 79. 5.1 Abordagem .................................................................................................. 5.2 Entrada de Informação ................................................................................ 5.3 Automatização ............................................................................................ 5.4 Resumo ........................................................................................................ 80 81 93 109. Capítulo 6: Conclusão ................................................................................................... 110. Bibliografia .................................................................................................................... 115. Anexos: A -Exemplos B -Lista de métodos C -Glossário.

(7) CAPÍTULO 1. INTRODUÇÃO. O tema deste projecto consiste em refinar e validar um método, cuja particularidade é permitir automatizar algumas fases do Ciclo de Vida de Desenvolvimento de Aplicações Informáticas. Este método é denominado por ASA Análise de Sistemas Automática.. Este capítulo começa por apresentar as dificuldades de aceitação de métodos de desenvolvimento de Sistemas de Informação, devido ao nível de maturidade informática existente. Descreve as necessidades de utilização de ferramentas CASE (Computer Aided Software Engineering) e sublinha a importância de se investigarem ferramentas que cubram e automatizem o Ciclo de Vida de Desenvolvimento de Aplicações Informáticas..

(8) Capítulo 1: Introdução. 1.1. 2. VISÃO GERAL. Hoje em dia, para que uma organização seja competitiva, tem que dispor de informação fiável de uma forma oportuna. No entanto, a quantidade de informação existente atinge, por vezes, proporções elevadas, o que,. para além do seu. processamento, implica uma grande sofisticação e complexidade no controlo da mesma. A informatização das organizações, através da construção de aplicações informáticas, permite colmatar esta necessidade.. Neste momento, uma grande maioria das aplicações existentes não consegue satisfazer todas as necessidades definidas pelos seus proponentes. Isto deve-se essencialmente ao facto de o processo de desenvolvimento de aplicações informáticas ainda ser do tipo "papel e lápis", o que implica, logicamente, o aparecimento de inúmeras falhas e/ou lapsos.. Existe consenso de que quem desenvolve aplicações informáticas não consegue fazer uso efectivo de novas ferramentas e métodos, mesmo sendo adequados, enquanto não atingir um determinado estádio de maturidade. O estádio de maturidade necessário para adoptar e utilizar ferramentas e métodos, corresponde ao terceiro dos seguintes cinco níveis [Humphrey, 1988]:. 1.. Nível inicial - Não existe um processo formal, consistência e normas de como as aplicações informáticas devem ser desenvolvidas. Cada analista considera-se um artista..

(9) Capítulo 1: Introdução. 2.. 3. Nível repetição - As pessoas estão de acordo acerca de "como se devem fazer as coisas", embora não exista um processo bem formalizado e escrito. O sucesso depende das capacidades individuais dos gestores de projecto.. 3.. Nível definição - Existe um processo de desenvolvimento de aplicações bem formalizado e documentado, embora este processo ainda seja pouco qualitativo, devido à quase inexistência de indicadores de aferição da eficiência do processo. Contudo, fornece as bases para uma melhor compreensão do processo de desenvolvimento de aplicações.. 4.. Nível gestão - Está institucionalizado um processo métrico formal para medir o desenvolvimento das aplicações.. 5.. Nível óptimo - São utilizadas as medidas do nível anterior como mecanismo de "feedback", para melhorar as partes do processo que não se encontram ainda optimizadas.. É ainda referido [Humphrey, 1988] que, nos últimos anos da década de 80, 85% das organizações americanas, que desenvolvem aplicações informáticas, se encontravam ainda no primeiro nível, enquanto 10% a 12% se encontravam no segundo nível, somente cerca de 3% estavam no terceiro nível e nenhuma se encontrava no quarto ou quinto nível.. Esta informação reflecte a mentalidade dos gestores acerca do "paradigma da mudança", pois, geralmente, não se adopta um novo método e/ou ferramenta para resolver os problemas mais rapidamente ou eficientemente, devido à existência de.

(10) Capítulo 1: Introdução. 4. custos de fazer a mudança e porque o ser humano tem uma inércia natural e, por vezes, resistência para aprender coisas novas.. Se a maior parte das organizações que desenvolvem aplicações informáticas, ainda se encontram num nível de maturidade informática muito elementar, é porque pensam, erradamente, que o desenvolvimento de aplicações pode prescindir de ferramentas dedicadas. Deve-se contudo realçar que, quando se fala em ferramentas dedicadas, não se pretende referir aos seguintes tipos de ferramentas: editores, compiladores, "drivers" para gerir os dispositivos de entrada e saída, etc.. As aplicações informáticas 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 aplicações informáticas ainda são, muitas das vezes,. construídas. manualmente,. sem ajuda. de. qualquer. ferramenta. de. desenvolvimento que automatize e verifique a consistência de todas as fases da construção dessas aplicações. Assim, urge adoptar ferramentas, que permitam cobrir e automatizar o Ciclo de Vida de Desenvolvimento de Aplicações Informáticas (CVDAI), ver Fig. 1, e consequentemente aumentar a produtividade das equipas de desenvolvimento e a qualidade final das aplicações informáticas.. Estas ferramentas ao serem suportadas por computadores, são 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.

(11) Capítulo 1: Introdução. 5. partes do CVDAI, normalmente as fases finais, havendo mesmo algumas ferramentas CASE que começam na fase de Desenho físico, o que implica que se tenha a ideia de que as ferramentas CASE, servem somente para "facilitar e tornar rigorosa, a tarefa de programação" [Towner, 1989]. No entanto, uma definição 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 aplicações".. Especificação de Requisitos. Desenho lógico. Desenho físico. Codificação e testes. Implementação. Fig. 1 - CVDAI - Ciclo de Vida de Desenvolvimento de Aplicações Informáticas. A. ocorrência. de. determinados. erros. e. omissões. é. provocada,. frequentemente, pelas actividades iniciais do CVDAI, tal com se pode aperceber ao.

(12) Capítulo 1: Introdução. 6. analisar a Fig. 2. Aí, mostra-se um esquema que permite entender a ocorrência de problemas durante a actividade de desenvolvimento de aplicações informáticas, tais como:. .. por vezes torna-se complicado definir o contorno do sistema a tratar,. isto é, definir a fronteira e comunicações entre a aplicação a desenvolver e o seu ambiente exterior, adoptando-se, muitas das vezes, visões demasiado simplistas;. .. construção de sistemas demasiado grandes obriga a que o tempo de. desenvolvimento de aplicações seja bastante longo, podendo mesmo demorar anos, ocasionando possíveis alterações nos requisitos iniciais do sistema;. .. os processos de desenvolvimento são 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 comunicação entre a aplicação e o seu ambiente exterior, a partir do momento em que a aplicação esteja pronta a funcionar, pois poderá já estar desenquadrada em relação ao seu ambiente.. Em jeito de conclusão, pode-se afirmar que, para uma ferramenta CASE ajudar a desenvolver, de uma forma rápida, melhores aplicações, deve cobrir todo o CVDAI e automatizar as etapas de especificação e desenho, o que possibilitará reduzir em termos de tempo e custo o desenvolvimento de aplicações. Essa redução,.

(13) Capítulo 1: Introdução. 7. pode resultar, somente, da eliminação da tarefa de corrigir os erros introduzidos nas etapas iniciais do CVDAI.. Mundo Real. Especificação. Implementação. Sistema. de Requisitos. Codificação. Desenho. e testes. físico. Desenho lógico. Fig. 2 - Problemas no CVDAI. 1.2. TEMA DO PROJECTO. O projecto proposto consiste no refinamento e validação de um método, denominado por ASA - Análise de Sistemas Automática. ASA surgiu em 1987 [Godinho e Lopes, 1987] como consequência de um estudo e comparação de algumas técnicas e notações, tendo dado origem a projectos com o objectivo de testar e, em particular, procurar provar a viabilidade de um processo de geração automática de informação [Godinho e Lopes, 1988]..

(14) Capítulo 1: Introdução. 8. ASA permite cobrir o CVDAI, realçando, tal como o seu nome diz, as etapas iniciais, pois é, especialmente, nessas etapas que se torna crítica a tarefa de recolha e obtenção de informação, de forma, a se poder obter uma visão global do sistema, para, posteriormente, ser possível 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 definição e especificação correcta do sistema em estudo. A participação do utilizador é crucial no processo de desenvolvimento, especialmente nas primeiras fases.. Na etapa de especificação de requisitos, o analista informático recolhe informação através da utilização de técnicas, tais como, por exemplo: entrevistas e/ou inquéritos, que obrigam à existência de diálogo com os fornecedores de informação, ocasionando possíveis entradas de erros ou más interpretações da informação. Assim, ASA pode ser visto como um meio de comunicação entre o analista e os fornecedores de informação, ao permitir a ligação com o fornecedor de informação a fim de obter a informação necessária, para modelar, de modo correcto, o problema objecto. Desta forma, ASA, tem como objectivo principal, conseguir que os fornecedores de informação possam, eles mesmos, definir os requisitos do sistema que pretendem informatizar, eliminando, deste modo, possíveis entradas de erros no sistema a desenvolver.. O uso do fornecedor de informação ou do utilizador (denominado por "perito do domínio") como principal interlocutor de ASA, faz com que este método se distinga de todos os existentes. Assim, o nível da informação fornecida tem que.

(15) Capítulo 1: Introdução. 9. ser bastante próxima do nível de informação do funcionamento do posto de trabalho ou do domínio conhecido pelo utilizador.. Devido a estas características, ASA pode ser dividido em duas grandes componentes, sendo ambas igualmente importantes para o seu funcionamento:. .. Entrada de Informação - O diálogo entre ASA e o utilizador deve ser o. mais simples possível, de forma a que seja mais fácil guiar e acompanhar o utilizador na actividade de fornecimento de informação, apresentando, sempre que seja necessário, mensagens de diagnóstico a informar o estado e consistência da informação fornecida.. .. Processamento da Informação - A partir da informação fornecida pelo. utilizador, ASA gera automaticamente um conjunto diverso de informação, composto em diversos relatórios que permitem avaliar e compreender o Sistema de Informação que se está a desenvolver.. 1.3. ABORDAGEM AO PROJECTO. Antevendo-se a efectiva possibilidade de automatizar o processo de desenvolvimento de aplicações informáticas, o método ASA, inclui técnicas e notações que ainda não foram completamente testadas nem validadas. Assim, é objectivo deste projecto proceder ao seu teste e validação, para que seja possível refinar e evoluir o próprio método..

(16) Capítulo 1: Introdução. 10. Esta automatização obriga a um diálogo bastante cuidado, visto os seus utilizadores não necessitarem de ter conhecimentos de métodos de análise informática e de informática de uma forma geral. Este diálogo entre o computador e o utilizador deve ser simples e flexível, para que a tarefa de fornecimento de informação, por parte dos utilizadores, também o seja. O que implica que o nível de abstracção da informação, fornecida pelo utilizador, esteja o mais próximo possível do "Mundo Real" ou do nível de informação que conhece.. Partindo dos pressupostos anteriores, verifica-se que a melhor aproximação para resolver este projecto é através da elaboração de um protótipo. Esse protótipo, deve permitir, desde o inicio da sua construção, validar o método ASA e possibilitar o ajuste e refinamento das suas regras. Esta aproximação pode ser denominada por incremental, pois pode ser descrita como um ciclo onde os resultados do protótipo servem de entrada para o seu próprio desenvolvimento, garantindo, ao mesmo tempo, o cumprimento dos pressupostos inicias.. 1.4. ORGANIZAÇÃO DO RELATÓRIO. Este capítulo começou com uma visão geral do problema a tratar, seguido do tema do projecto e da forma como foi realizado.. É seguido do capítulo 2, onde se apresentam os fundamentos teóricos necessários para a elaboração deste projecto, compreendendo definições sobre sistemas, sistemas de informação e métodos. Como complemento apresenta-se no Anexo C, um breve glossário dos principais termos abordados..

(17) Capítulo 1: Introdução. 11. No capítulo 3, é apresentado e descrito o método ASA tal como existia no momento em que este projecto se iniciou.. As alterações efectuadas no método ASA, são apresentadas no capítulo 4, de forma a permitir a evolução e aperfeiçoamento do mesmo.. A validação do método ASA, efectuada através da introdução de um exemplo e análise dos resultados do protótipo, é apresentada no capítulo 5.. Finalmente, no capítulo 6, as conclusões acerca deste projecto e sugestões para trabalhos futuros são apresentadas..

(18) CAPÍTULO 2. FUNDAMENTOS TEÓRICOS. Este capítulo, começa por definir o que é um Sistema, de forma a que se possa, posteriormente, entender o conceito de Sistema de Informação.. Para os Sistemas de Informação descrevem-se os significados de Metodologia, Método, Modelo, Técnica e Notação, para que, mais facilmente, se possa entender o método ASA.. Apresenta-se um esquema de Arquitectura de Informação, que permite compreender os níveis de detalhe da descrição da informação.. Por fim, apresenta-se o enquadramento dos conceitos apresentados neste capítulo com o método ASA..

(19) Capítulo 2: Fundamentos Teóricos. 2.1. 13. DEFINIÇÃO 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, organizações e mesmo fábricas.. Existem outras definições de sistema, como:. .. "um sistema pode ser definido como uma agregação de objectos juntos. numa interacção ou interdependência regular" [Gordon, 1969];. .. "é um conjunto de matéria, partes ou componentes as quais estão. incluídas dentro de uma específica, por vezes arbitrária fronteira" [Shearer, Murphy e Richardson, 1967].. No entanto, entre muitas outras, existe uma definição mais completa [Rosnay, 1975], "Um sistema é um conjunto de elementos em interacção dinâmica, organizados em função de um objectivo". Esta definição inclui três conceitos cruciais: "...é um conjunto de elementos..." transmite a ideia de estrutura do sistema, "...em interacção dinâmica..." define o funcionamento do sistema em função do factor tempo e "...em função de um objectivo" introduz a ideia da finalidade do sistema ou objectivo.. A definição de sistema é incompleta sem a noção de ambiente. Um sistema é parte de um universo e está fechado pelo ambiente no qual opera. Uma mudança no ambiente pode afectar o sistema e vice-versa. As interacções entre o sistema e o.

(20) Capítulo 2: Fundamentos Teóricos. 14. ambiente são consideradas entradas e saídas, as quais podem ser de três tipos: energia, matéria e informação.. Existe uma outra definição de sistema que inclui o conceito de ambiente [Moigne, 1977]. "Um sistema é:. . . . . . .. algo (identificável);. faz algo (actividade, função);. tem uma estrutura;. altera-se ao longo do tempo;. está dentro de algo (ambiente); e. serve para alguma coisa (objectivo).". Um sistema pode também ser descrito através de dois pontos de vista , visão estrutural e funcional [Rosnay, 1975]:. .. aspectos estruturais englobam a fronteira, componentes, reservatórios e. redes de comunicações do sistema; e. .. aspectos funcionais englobam o tempo, passado, fluxos e centros de. decisão do sistema..

(21) Capítulo 2: Fundamentos Teóricos. 15. Alguns autores neste campo classificam os aspectos estruturais e funcionais de um sistema como estáticos e dinâmicos, respectivamente.. Como os sistemas são 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.. SISTEMA. SUBSISTEMA. SUBSISTEMA. SUBSISTEMA. SUBSISTEMA. SUBSISTEMA. SUBSISTEMA. Fig. 3 - Conceito de Sistema. Em conclusão:. . .. um sistema é composto por diferentes componentes;. as componentes do sistema trabalham em conjunto com a finalidade de. atingir o objectivo do sistema;. .. as componentes têm relações com elas mesmas, criando a estrutura do. sistema;.

(22) Capítulo 2: Fundamentos Teóricos. . . .. 16. um sistema é limitado por uma fronteira;. um sistema tem sempre um ambiente;. um sistema tem a sua própria maneira de interactuar com o ambiente,. denominada por comportamento do sistema;. .. um sistema tem um ciclo de vida: evolução, maturidade, manutenção e. finalmente a morte.. 2.2. SISTEMA DE INFORMAÇÃO. Actualmente, é reconhecido que as organizações necessitam cada vez mais de Sistemas de Informação. Um Sistema de Informação pode ser "definido como o mecanismo que fornece os meios de armazenar, gerar e distribuir informação..." [Layzell e Loucopoulos, 1986] e pode ser classificado como manual, informatizado ou misto. É obvio, que neste projecto o objectivo é focar os Sistemas de Informação que possam ser, ou vir a ser, suportados por computadores.. Para exemplificar o conceito de Sistema de Informação, apresentam-se na Tabela 1, diversos tipos de possíveis Sistemas de Informação [Projecto AMADEUS, 1986]..

(23) Capítulo 2: Fundamentos Teóricos. 17. Sistemas de Informação Sistemas de Arquivo Escritório. Sistemas de Processamento de Documentos Sistemas de Comunicações Processamento de Dados Administrativos Sistemas de Controlo de Produção. Controlo. Sistemas de Comando e Controlo Controlo de Processos em Tempo Real Sistemas de Robótica. Obtenção de Informação Transferência de Sistemas de Ensino Conhecimento Tradução de Linguagens. Planeamento, Desenho e Resolução de Problemas. Sistemas de Fabrico e Desenho Sistemas de Apoio à Decisão Sistemas Científicos e Estatísticos Sistemas Periciais. Tabela 1 - Exemplos de Sistemas de Informação. 2.2.1. METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO. A Metodologia é a ciência do método, isto é, um tratado ou dissertação sobre o método, ou pode também ser vista como a ciência que estuda os métodos..

(24) Capítulo 2: Fundamentos Teóricos. 18. Assim, uma metodologia pode ser composta por um ou mais métodos, sendo cada método constituído por um conjunto de técnicas integradas e cada técnica usa uma notação, ver Fig. 4.. Metodologia. Método Legenda Relação 1:1 Modelo. Relação 1:N Relação N:N. Técnica. Notação. Fig. 4 - Relaçionamento entre Metodologia, Método, Modelo, Técnica e Notação. MÉTODOS. A cada vez maior complexidade dos Sistemas de Informação motivou o aparecimento de métodos, com o objectivo de melhorar a qualidade dos sistemas finais e facilitar o seu desenvolvimento..

(25) Capítulo 2: Fundamentos Teóricos. 19. Métodos podem ser descritos como as indicações, os passos a seguir, para o melhor desenvolvimento de Sistemas de Informação.. Existem mais de uma centena de métodos (ver no Anexo B uma lista de métodos existentes), os quais foram desenvolvidos nas últimas duas décadas [Layzell e Loucopoulos, 1986] não existindo um método claramente favorito e normalmente a opção pela sua utilização levanta alguns problemas.. Cada método tem as suas características e particularidades, mas todos partilham conceitos comuns, o que poderá causar confusão no campo da análise de sistemas e métodos de desenvolvimento, devido a:. .. alguns métodos utilizarem os mesmos termos no seu desenvolvimento,. mas esses termos poderão ter diferentes significados, dependendo do método em questão;. .. métodos diferentes partilharem notações e técnicas comuns. Contudo, a. combinação técnica/notação escolhida depende de cada método;. .. todos os métodos terem por objectivo modelar o sistema, mas o. elemento de modelação do sistema poderá ser diferente, dependendo do método.. Pode-se concluir que um método "consiste numa colecção de técnicas, notações e procedimentos formais ou semi-formais" [Blokdijk A. e P., 1987], tal com já foi apresentado na Fig. 4..

(26) Capítulo 2: Fundamentos Teóricos. 20. MODELOS. A análise de sistemas e métodos de desenvolvimento não 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 acessível e compreensível.. Três visões de modelos podem ser reconhecidas [Blokdijk A. e P. , 1987]:. .. Visão lógica - descreve de uma forma abstracta mas perceptível para o. utilizador (pois não utiliza termos técnicos) como é que o mundo real será no futuro;. .. Visão física - mostra como o sistema aparecerá tecnica e fisicamente ao. utilizador;. .. Visão de implementação - descreve a forma como o sistema será. implementado informaticamente, em termos de dados (bases de dados), funções (programas/procedimentos) e comunicações (rede de dados).. TÉCNICAS. Uma técnica é um conjunto de processos, baseados em conhecimentos científicos e não empíricos, utilizados para obter um certo resultado; pode ser vista como a ciência que está por detrás de uma notação..

(27) Capítulo 2: Fundamentos Teóricos. 21. Existem muitas técnicas na área de desenvolvimento de Sistemas de Informação, onde se pode realçar:. .. Decomposição Funcional - decompor funções incrementando os níveis. de detalhe [Stevens, 1974];. .. Normalização de dados - remover redundâncias e relações que poderão. causar. anomalias. na. operação de armazenamento dos dados. [Codd, 1970];. .. Processos estruturados - fornecer uma receita para descrever os. processos: um processo só poderá ter uma entrada e uma saída; são permitidos unicamente a sequência, selecção e interacção de processos [Dijkstra, 1972];. .. Revisão estruturada - encontrar erros: por omissão, contradição, ou um. erro lógico de qualquer tipo [Yourdon, 1986];. NOTAÇÕES. Uma notação é um conjunto de caracteres, símbolos ou abreviação de expressões usados para exprimir factos técnicos..

(28) Capítulo 2: Fundamentos Teóricos. 22. Cada modelo do Sistema de Informação, construído através de um método de desenvolvimento de sistemas, terá que estar de acordo com as notações suportadas por esse método.. Existe um grande número de notações usadas por diferentes métodos. Por conseguinte, mostra-se, de uma forma não exaustiva, diversas notações existentes:. .. Data Flow Diagram (DFD) - usado para mostrar o fluxo dos dados. através do sistema [Gane, 1979; DeMarco 1979];. .. Português Estruturado - usado para descrever os processos através de. combinações simples de frases na forma imperativa [DeMarco, 1979];. .. Árvores de decisão - usadas para exprimir condições e acções dentro de. um processo [DeMarco, 1979];. .. Dicionário de Dados (DD) - usado como repositório de definições e. todos os nomes dos dados [Gane e Sarson, 1979];. .. Gráfico estruturado - usado para especificar a hierarquia dos módulos. e as relações entre eles [Yourdon e Constantine, 1987];. .. Diagrama de entidades e relacionamentos (E-R) - usado para realçar o. relacionamento entre as diversas entidades [Chen, 1977];.

(29) Capítulo 2: Fundamentos Teóricos. .. 23. Diagrama de transição de estados - usado para representar estados e a. transição entre dois estados, a entrada dispara a transição e a saída é a resposta do sistema [Macdonald, 1986].. 2.2.2. FERRAMENTAS. O desenvolvimento de Sistemas de Informação gera um grande volume de informação que necessita de ser capturada e analisada. Os métodos e as notações podem ajudar nesse processo de desenvolvimento, mas a sua automatização é que os torna realmente utilizáveis para manusear o volume de informação existente.. Os métodos e notações são essenciais para uma correcta utilização de ferramentas, no entanto sem ferramentas a maioria, daqueles que desenvolvem aplicações informáticas, não conseguiriam aproveitar todas as vantagens da sua utilização. Em verdade, isto não é mais que a reafirmação de que a tarefa de desenvolvimento de Sistemas de Informação não pode ser executada adequadamente, sem uma aproximação metódica suportada por ferramentas.. Como as aplicações cada vez se tornam mais complexas, os métodos têm que se adaptar e evoluir para permitirem o manuseamento dessa complexidade. Por outro lado, utilizar esses métodos sem a existência de uma ferramenta que os suporte, torna-se uma tarefa impensável. Assim, ao haver a disponibilidade de métodos e ferramentas adequadas, torna-se exequível o desenvolvimento de aplicações informáticas mais complexas. Esta situação pode ser considerada como um ciclo que tem como resultado imediato o aparecimento de ferramentas bastante potentes..

(30) Capítulo 2: Fundamentos Teóricos. 24. Este tipo de ferramentas pode ser denominado por CASE (Computer Aided Software Engineering) que é, sem duvida, um dos acrónimos mais falados na área. ligada ao desenvolvimento de Sistemas de Informação. Embora "não exista uma definição real do que é uma ferramenta CASE" [Towner, 1989], entende-se que uma ferramenta CASE deve "documentar e modelar um Sistema de Informação desde os requisitos inicias dos utilizadores, passando pelas fases de desenho e implementação e ainda permitir aplicar testes de consistência, correcção e validação das normas préestabelecidas" [Chikofsky e Rubenstein, 1988].. A actividade de desenvolvimento de Sistemas de Informação, gera um grande volume de informação 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 crítico de sucesso. Assim, as ferramentas CASE terão que evoluir segundo as seguintes perspectivas:. . .. utilizar interfaces gráficas;. utilizar repositórios de informação 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 número de ferramentas CASE disponíveis, que suportam diversos métodos de desenvolvimento de Sistemas de Informação. Devido a essa diversidade, "uma ferramenta CASE pode ser mais adequada de que outras, para.

(31) Capítulo 2: Fundamentos Teóricos. 25. auxiliar o desenvolvimento de determinados tipos de Sistemas de Informação" [Lopes, 1990].. Desta forma, o futuro das ferramentas CASE passa pela integração de vários métodos numa única ferramenta, que com um único interface e repositório deveria permitir seleccionar o método mais adequado para modelar um determinado tipo de Sistema de Informação. Seria também interessante poder acrescentar novos componentes (métodos) nessa ferramenta (tal como actualmente é possível adicionar ou retirar componentes de diferentes fabricantes no interior de um computador).. 2.2.3. ARQUITECTURA DE INFORMAÇÃO. Uma Arquitectura de Informação tem como propósito a harmonização dos objectivos de um Sistema de Informação com os objectivos de uma organização de modo a produzir informação de uma forma efectiva, eficiente e controlada.. Apresenta-se na Tabela 2 um exemplo de uma Arquitectura de Informação. Esta Arquitectura de Informação foi elaborada por Zackman [QED, 1989] e tem a particularidade de fornecer, para um determinado nível de detalhe de descrição, uma representação adequada da informação. A informação é dividida em três perspectivas: dados, funções e rede de comunicações. Ao analisar a Tabela 2.4 constata-se que:. .. Os níveis da informação cobrem diversas aproximações de detalhe,. desde a descrição geral da organização até à descrição do detalhe das aplicações informáticas existentes. É esta característica que torna esta Arquitectura de Informação inovadora, pois transporta para a actividade.

(32) Capítulo 2: Fundamentos Teóricos. 26. de Engenharia de "Software" conceitos existentes noutros domínios de engenharia, como por exemplo a Engenharia Civil, onde, para se construir um edifício, se desenham diversos esboços com níveis de detalhe e objectivos distintos..

(33) Capítulo 2: Fundamentos Teóricos. Dados. 27. Funções. Rede. Lista de elementos importantes para a organização. Lista de funções que Lista de lugares a organização onde a organização opera executa. Entidade - Classe dos elementos da organização. Função - Classe de processos da organização. Descrição Geral. Descrição da Organização. Diagrama de Entidades e Relacionamentos. Diagrama de Fluxos de Informação. Processo. - Proc. da org.. Descrição do Sistema de Informação. Nodo - Local da org.. Nodo - Unidade da org. Ligação - Relações entre as unidades. Entidade. - Ent. da org. Relaciona. - Regra org.. Fluxos - Recursos da org. (documentos). Modelo de Dados. Diagrama de Fluxos de Dados. Entidade. - Ent. de dados Rel. - Rel. de dados. Proc. - Função da aplic.. Nodo - Função (acesso a disco, processador, etc). Fluxos - Dados entre proc., fich. ou entidades. Ligação - Características da linha. Desenho dos Dados. Gráfico Estruturado. Ent. - Linha da tabela. Proc. - Funções do. computador. Rel. - apontador/chave. Fluxos - écrans e mapas. Descrição da Base de Dados. Programa. Arquitectura do Sistema. Descrição das Restrições. Descrição do Detalhe. Entidades - Campos Rel. - Endereços dos campos. Nodo - "Hardware"/sist. e "software" Ligação - Caracteristicas da linha. Proc. - Comandos da ling.. Nodo - Endereços. Fluxos - Controlo da execução do programa. Ligação - Protocolos. Tabela 2 - Arquitectura de Informação. .. A divisão dos níveis de detalhe segundo três perspectivas (dados,. funções e rede de comunicações), permite o estudo de cada perspectiva.

(34) Capítulo 2: Fundamentos Teóricos. 28. de uma forma independente, embora tenham que ser geridas de uma forma global para arquitectar um correcto Sistema de Informação.. 2.4. ENQUADRAMENTO COM ASA. Os conceitos apresentados neste capítulo servem para fundamentar teoricamente o trabalho realizado no método ASA.. ASA é um método, composto por técnicas e notações próprias que foram desenvolvidas com o objectivo de permitirem modelar, de uma forma bastante automatizada, Sistemas de Informação. Devido a essa característica, o método ASA não 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 capítulo 2.2.2, para que possa ser reconhecida como uma ferramenta CASE.. ASA inclui a particularidade de descrever a informação com um nível de detalhe muito próximo do nível de descrição da organização, tal como foi mostrado na Arquitectura de Informação representada na Tabela 2..

(35) CAPÍTULO 3. ESTUDO DO MÉTODO. Pretende-se, neste capítulo, apresentar o método ASA tal como existia antes de este projecto se ter iniciado.. Começa-se por apresentar a evolução do método ASA, as técnicas e notações existentes realçando as vantagens e inconvenientes de cada uma. De seguida são descritos os trabalhos anteriormente realizados sobre este tema, indicando os objectivos que se pretenderam atingir.. Apresenta-se, ainda, uma avaliação de ASA de forma a caracterizar o método..

(36) Capítulo 3: Estudo do Método. 3.1. 30. EVOLUÇÃO DO MÉTODO. O método ASA surgiu em 1987 [Godinho e Lopes, 1987] em consequência de estudos e comparações de algumas técnicas e notações. Posteriormente, efectuaram-se dois trabalhos, um em 1988 e outro em 1990, com o objectivo de avaliar o método ASA. Desses trabalhos foi concluído que o método tinha potencial e que deveria continuar a ser desenvolvido.. ASA basicamente consistia na utilização de técnicas que, ao utilizarem notações gráficas simples, podiam ser facilmente assimiláveis e trabalháveis por utilizadores não especializados. Essas técnicas e notações são:. .. Diagrama de Fluxos de Informação - permite identificar os domínios. de uma organização e os respectivos fluxos de informação.. .. Descrição da Informação - permite descrever a estrutura dos. documentos de uma organização.. .. Matriz de Redundância Múltipla - permite validar a redundância de. informação existente nos documentos.. .. Matriz de Relações de Entrada/Saída de Informação - permite. identificar informação que não foi ainda definida e/ou foi omitida por esquecimento..

(37) Capítulo 3: Estudo do Método. .. 31. Diagrama de Fluxos de Informação Interna - permite identificar os. ficheiros necessários para o correcto fluxo de informação e as funções que manipulam esses fluxos de informação.. Devido às. características referidas, as técnicas e notações podem ser. agrupadas segundo duas perspectivas:. .. facilitar a entrada de informação - em que se inscreve o Diagrama de. Fluxos de Informação e a Descrição da Informação;. .. permitir a automatização - em que se inscreve a Matriz de. Redundância Múltipla, a Matriz de Relações de Entrada/Saída de Informação e o Diagrama de Fluxos de Informação Interna.. 3.2. ENTRADA DE INFORMAÇÃO. A entrada de informação está dividida em duas partes distintas, mas que se complementam. Essas duas partes são: o Diagrama de Fluxos de Informação e a Descrição da Informação.. 3.2.1. DIAGRAMA DE FLUXOS DE INFORMAÇÃO. O Diagrama de Fluxos de Informação (DFI),. permite representar a. circulação da informação pelos domínios de um sistema em estudo. Antes de se.

(38) Capítulo 3: Estudo do Método. 32. explicar o funcionamento do diagrama, é importante definir os conceitos de informação e domínios:. .. Informação - são documentos (conjuntos de informação) que possibili-. tam que uma organização se relacione externamente com outras entidades e internamente com as suas sucursais, filiais, departamentos, empregados, etc. A maior vantagem da utilização de documentos, como unidade de informação, deriva das seguintes observações [Choobineh, Mannino e Tseng, 1992]: "os documentos são bem conhecidos pelas pessoas que os manipulam e dessa forma essas pessoas podem fornecer um grande número de requisitos a partir desses documentos; os documentos contém a maior parte da informação que circula nas organizações".. .. Domínios - são funções internas ou externas à organização onde a. informação é produzida, alterada, consultada, ou apagada.. O DFI permite representar os domínios de um dado sistema, bem como os documentos que irão ser necessários e/ou os documentos que irão ser produzidos, permitindo deste modo:. .. subdividir o sistema em estudo segundo os seus principais domínios, e. proceder ao seu estudo isoladamente ou de uma forma integrada;. . .. visualizar o circuito de informação;. validar informação aos mais diversos níveis;.

(39) Capítulo 3: Estudo do Método. . .. 33. construir uma visão global do sistema, correcta e completa;. validar os requisitos principais do sistema.. As regras de construção de um DFI são bastante simples. Trata-se de representar os domínios de um sistema em estudo e a informação que circula entre eles, indicando o sentido do fluxo dos respectivos documentos.. Cada domínio é representado por um rectângulo, ao qual se deve atribuir um nome descritivo das funções que desempenha. Se considerarmos, por exemplo, como sistema uma organização, podemos considerar como domínios dois dos departamentos existentes: Departamento Financeiro (contabilidade) e Comercial, ver Fig. 5.. Financeiro Contabilidade. Comercial. Fig. 5 - Exemplo da representação de domínios no DFI. A informação, como já foi atrás referido, é composta pelos documentos que circulam numa organização e representam-se por uma linha com indicação da sua orientação, ver Fig. 6.. Fig. 6 - Exemplo de uma ligação de um DFI.

(40) Capítulo 3: Estudo do Método. 34. Utilizando os domínios 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 informação 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 são considerados documentos e serão descritos tal como se encontra exposto na Fig. 7.. Financeiro Contabilidade. Resposta Comercial Consulta de Saldo. Fig. 7 - Exemplo de um DFI completo. Existem algumas vantagens na utilização do DFI, tais como. .. a partir de uma breve descrição do sistema pode logo traçar-se um DFI. geral (de toda a organização ou de apenas alguns domínios de informação);. .. permite estabelecer uma fronteira para o sistema e para a área de. actividade abrangida pelo mesmo. Os domínios não representados, não fazem parte do sistema em estudo;.

(41) Capítulo 3: Estudo do Método. .. 35. permite identificar os principais procedimentos de cada sistema e as. respectivas necessidades de informação;. .. é um esquema com características não técnicas e, portanto, facilmente. compreendido por pessoas familiarizadas com o funcionamento da organização, quer tenham ou não conhecimentos informáticos. Esta particularidade facilita o diálogo analista/utilizador e, ao ser construído e discutido por pessoas conhecedoras do sistema, aumenta a validade da informação expressa no diagrama.. Contudo verificou-se que este tipo de DFI não era suficiente para representar a maior parte dos sistemas, devido à constatação dos seguintes problemas:. .. não indicação de ordem cronológica - Uma das desvantagens deste. esquema está relacionada com o facto de não indicar o inicio e o fim do procedimento descrito (qual é o fluxo que inicia o processo?);. .. selecção de um fluxo - Este problema surge quando podemos ter dois. ou mais caminhos diferentes mas selectivos e não sabemos qual das hipóteses seleccionar;. .. detecção de "ciclos" - Este problema surge quando existem ligações em. ciclo entre vários domínios. Este é um caso em que se torna difícil dizer quantos e quais os documentos que são necessários para que se avance para o passo seguinte..

(42) Capítulo 3: Estudo do Método. 36. Estes problemas derivam do facto dos sistemas em estudo serem dinâmicos, em que a dimensão temporal é de importância vital. Em sistemas dinâmicos a atenção 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 frequência da circulação dos documentos na organização. Existem basicamente três tipos de frequências:. . . .. periódicas - associadas a um relógio;. dependentes - da ocorrência de um determinado evento; e. compostas - combinação dos diversos tipos de frequências existentes.. FREQUÊNCIAS PERIÓDICAS. As frequências periódicas, tal como o seu nome indica, estão associadas a um relógio e indicam intervalos de tempo discretos ou contínuos.. Exemplos típicos de frequências periódicas serão as frequências diárias, 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", documento recibo é mensal.. FREQUÊNCIAS DEPENDENTES. logo, a frequência do.

(43) Capítulo 3: Estudo do Método. 37. Estas frequências não são fáceis de temporizar, pois não estão associadas a um relógio, podendo ser consideradas aleatórias. Não sendo periódicas, podem acontecer a qualquer momento. No entanto, devido à dependência que lhes está associada, obriga a que um documento que tenha uma frequência deste género só seja produzido depois de verificar as condições da frequência associada.. Existem três tipos de frequências dependentes:. .. directas - Existe uma dependência directa em relação a um documento. ou condição;. .. de decisão humana (estáticas) - A produção de um documento está. dependente de uma decisão humana, por exemplo: antes de se fazer o pagamento do prémio de produtividade o gestor tem que seleccionar os trabalhadores com direito a esse prémio;. .. externas à organização - Tal como o seu nome indica, a organização. não interfere na produção dos documentos cuja frequência seja deste tipo, por exemplo: recepção de uma encomenda por parte de um cliente que necessita de mais matéria prima.. FREQUÊNCIAS COMPOSTAS.

(44) Capítulo 3: Estudo do Método. 38. Os diferentes casos anteriormente apresentados, são exemplos de frequências simples. No entanto, o que vulgarmente acontece, é surgirem frequências compostas por diferentes tipos.. A combinação de diferentes tipos de frequências possibilita resolver os problemas encontrados nos DFI´s, pois é através da sua utilização que se pode obter uma visão clara da sequência de acontecimentos no sistema em estudo.. RESOLUÇÃO DOS PROBLEMAS. Referiram-se atrás alguns problemas dos DFI´s, concretamente:. .. Falta de ordem cronológica - Este problema ficou praticamente. resolvido com a utilização de frequências nos documentos, pois consegue-se perfeitamente descrever um caminho com base na interpretação do significado das frequências. .. Impossibilidade de distinguir selecções - Este problema surgia devido. à dificuldade existente na identificação de diversos caminhos selectivos, por exemplo, quando se segue pelo caminho X se a condição Y for satisfeita, ou se segue pelo caminho Z ... . Existem casos em que as decisões podem prolongar-se por vários níveis, originando caminhos muito distintos. Como é óbvio, as frequências associadas a estas situações tornam-se mais complexas, mas, em contrapartida, são mais precisas e agrupam-se em expressões cuja interpretação é clara simples.. e.

(45) Capítulo 3: Estudo do Método. .. 39. Impossibilidade de descrever ciclos - Com o aparecimento das. frequências este problema ficou solucionado, pois a ocorrência do ciclo acontece enquanto as condições existentes nas frequências forem falsas.. 3.2.2. DESCRIÇÃO DA INFORMAÇÃO. A maioria das organizações usam documentos para, diariamente, executarem tarefas e comunicarem internamente e externamente com um variado conjunto de domínios (clientes, fornecedores, departamentos, trabalhadores, etc).. A informação mínima, que garante o correcto funcionamento do método, é a descrição do conteúdo dos documentos, ou simplesmente, os nomes dos campos existentes.. 3.3. AUTOMATIZAÇÃO. A automatização do método é conseguida através da utilização das técnicas: Matriz de Redundância Múltipla, Tabela de Relações de Entrada/Saída de Informação e Diagrama de Fluxos de Informação Interna.. 3.3.1. MATRIZ DE REDUNDÂNCIA MÚLTIPLA. A utilização desta matriz pretende ser uma forma de testar a redundância de informação nos documentos..

(46) Capítulo 3: Estudo do Método. 40. O processo consiste em determinar o número de formas diferentes com que a informação (campo de um documento) chega a cada domínio. Para isso utilizam-se as seguintes matrizes:. .. Campos/Documentos - Estão na horizontal todos os documentos que. circulam na organização e na vertical todos os campos existentes nesses documentos. Sempre que um campo pertence a um documento é colocado um 1, senão é colocado um 0. Ver Fig. 8 (o exemplo aqui apresentado só serve para demonstrar o funcionamento da Matriz de Redundância Múltipla).. .. Documentos/Domínios - Estão na horizontal todos os domínios. existentes no sistema a estudar e na vertical todos os documentos que circulam na organização. Sempre que um documento entre num determinado domínio é colocado um 1, senão é colocado um 0, ver Fig. 9.. Documentos Nº Campos. 1. 2. 3. 4. Nome Endereço Código Descrição Preço Quantidade. 1 0 1 0 1 1. 0 1 1 1 0 1. 1 0 1 0 1 1. 1 1 0 1 0 1. Fig. 8 - Matriz de Campos/Documentos.

(47) Capítulo 3: Estudo do Método. 41. Domínios Documentos 1 2 3 4. A. B. C. 1 0 1 1. 0 1 0 0. 1 0 0 1. Fig. 9 - Matriz de Documentos/Domínios. Estas duas matrizes são utilizadas para construir a matriz apresentada na Fig. 10.. Documentos Nº. Nome Endereço Código Descrição Preço Quantidade 1 2 3 4. Domínios. 1. 2. 3. 4. A. B. C. 1 0 1 0 1 1. 0 1 1 1 0 1. 1 0 1 0 1 1. 1 1 0 1 0 1. 0 0 0 0 0 0. 0 0 0 0 0 0. 0 0 0 0 0 0. -1 0 0 0. 0 -1 0 0. 0 0 -1 0. 0 0 0 -1. 1 0 1 1. 0 1 0 0. 1 0 0 1. Fig. 10 - Matriz de Redundância Múltipla, preparada para transformação. A matriz da Fig. 10 foi acrescida de duas novas matrizes:. .. a submatriz inferior esquerda que contém a diagonal principal toda a -. 1;. .. a submatriz superior direita toda a zeros..

(48) Capítulo 3: Estudo do Método. 42. São efectuadas operações 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), obtém-se a matriz exposta na Fig. 11, onde os elementos da matriz superior direita, correspondem ao número de vezes que os campos entram em cada domínio. Documentos Nº. Nome Endereço Código Descrição Preço Quantidade 1 2 3 4. Domínios. 1. 2. 3. 4. A. B. C. 1 0 1 0 1 1. 0 1 1 1 0 1. 1 0 1 0 1 1. 1 1 0 1 0 1. 3 1 2 1 2 3. 0 1 1 1 0 1. 2 1 2 1 1 2. -1 0 0 0. 0 -1 0 0. 0 0 -1 0. 0 0 0 -1. 0 0 0 0. 0 0 0 0. 0 0 0 0. Fig. 11 - Matriz de Redundância Múltipla mostrando, por exemplo, que o campo Nome chega aos Domínios A e C por três e e duas vias respectivamente.. Esta matriz possibilita analisar o conteúdo dos diversos documentos, indicando o número de vezes que qualquer elemento (campo) surge nos vários domínios, se esse número for superior a 1 é recomendado uma redução dessa redundância..

(49) Capítulo 3: Estudo do Método. 3.3.2. 43. TABELA DE RELAÇÕES DE ENTRADA/SAÍDA DE INFORMAÇÃO. O processo de preenchimento desta tabela consiste em assinalar os contactos estabelecidos entre os domínios. Entende-se por contactos os documentos que transitam entre domínios.. Tal como se pode observar na Fig. 12 (o exemplo só serve para demonstrar o funcionamento da Tabela de Relações de Entrada/Saída de Informação), a tabela é composta por duas entradas:. . .. domínios origem - são os domínios de onde a informação sai;. domínios destino - correspondem a domínios onde a informação entra.. Os contactos entre dois domínios, origem e destino, são assinalados por um C e os domínios sem contacto são assinalados por um ?.. Depois de preenchida a tabela passa-se à sua análise. Em princípio, se para cada documento for recebida uma "resposta", a tabela é simétrica, se houver "não simetria", e caso esse contacto não exista no sistema actual, recomenda-se definir um novo documento que satisfaça esse contacto. Por outro lado, o contacto pode ter sido omitido por esquecimento, havendo desta forma uma validação da informação fornecida..

(50) Capítulo 3: Estudo do Método. 3.3.3. 44. DIAGRAMA DE FLUXOS DE INFORMAÇÃO INTERNA. Embora o nome indique que estamos perante um diagrama que esquematiza os fluxos de informação internos, na verdade esse esquema só é usado para facilitar a explicação do funcionamento do mesmo. Este diagrama permite, com alguma facilidade, a automatização, e desse modo, o seu funcionamento torna-se invisível para quem esteja a trabalhar com este método.. reconfirmação de encomenda pedido de reconfirmação de encomenda confirmação de encomenda encomenda. FORNECEDOR. COMERCIAL. aviso interno (mercadoria a receber). guia de remessa. pedido de encomenda. CONTROLO DE PRODUÇÃO. aviso interno (valor a pagar) aviso interno (chegada de mercadoria). ARMAZEM. CONTABILIDADE.

(51) Capítulo 3: Estudo do Método. Destino F Origem F DC. C. A. ?. DC. A. C. C C. C. CP. C. C. ?. 45. CP. ?. C. C C. ?. Legenda: F - Fornecedor DC - Dep. Comercial A - Armazem CP - Controle de Produção C - Contabilidade - Processamento local C. - contacto. ?. - possível falta de contacto. Fig. 12 - Tabela de Relações de Entrada/Saída de Informação. Da análise da tabela, e tendo em conta a informação do DFI apresentado, pode colocar-se por exemplo a seguinte questão: Será que deve existir um documento em resposta ao pedido de encomenda feito pelo Departamento de Controlo de Produção ao Departamento Comercial?. Basicamente, o funcionamento deste diagrama corresponde à análise do conteúdo dos documentos que saem de um determinado domínio e da informação necessária para a produção desses documentos.. Para os documentos de saída, de um determinado domínio, verificam-se quais os documentos de entrada que contém informação necessária para a produção desses documentos. É de salientar, que os documentos têm "uma altura certa" em que devem ser recebidos e produzidos, quer sejam de entrada ou de saída. Este conceito de "uma altura certa", ou denominada frequência, pode sugerir a necessidade de armazenamento de informação, sempre que a frequência dos documentos de entrada seja distinta da dos documentos de saída, implicando que se tenha que armazenar a informação dos documentos de entrada até serem necessárias, para produzir os documentos de saída. Por outro lado, se não existir informação suficiente para produzir um documento de saída, quando a frequência desse documento indicar que.

(52) Capítulo 3: Estudo do Método. 46. o documento deve ser produzido, pode haver necessidade de definir documentos auxiliares. Na Fig. 13, podemos ver o formato do diagrama onde se realçam as zonas A, B, C e D:. . .. A - identifica o domínio que se está a tratar;. B - os documentos que entram no domínio e/ou os documentos. auxiliares que são criados para que os documentos de saída possam ser produzidos;. . .. C - os documentos que saem do domínio;. D - os ficheiros que são criados e/ou utilizados no domínio.. A B. C. D Fig. 13 - DFII, descrição das zonas importantes.

(53) Capítulo 3: Estudo do Método. 47. Para desenhar o diagrama, traçam-se linhas que unem os documentos de saída com todos os documentos necessários para os produzir. Essas linhas indicam a fonte de informação necessária para produzir os documentos de saída.. Na Fig. 14 (exemplo fictício, onde não houve a preocupação de descrever o conteúdo dos documentos), apresenta-se o DFII completo. Para se entender melhor o DFII da Fig. 14, realça-se que:. . . . . .. Doc3 e Doc4 têm frequências diferentes;. Doc1 e Doc3 têm frequências iguais;. Doc2 e Doc4 têm frequências iguais;. O documento Aux1 foi criado para satisfazer a produção de Doc3 e tem. a mesma frequência que Doc3; Doc3 para ser produzido necessita de informação existente nos. documentos Doc1 e Aux1;. .. Doc4 para ser produzido necessita de informação existente nos. documentos Doc2 e Doc1; e. .. O ficheiro Fich_1 foi criado, porque Doc1 e Doc4 têm frequências. distintas..

(54) Capítulo 3: Estudo do Método. 48. Domínio Exemplo Doc1. 1. 1. Doc3. Doc2. 2. 2. Doc4. Aux1. 1 Fich_1 Fig. 14 - DFII completo. Outra característica do DFII é possibilitar identificar os processos necessários para processar os documentos de entrada e/ou produzir os documentos de saída. Na Fig. 14 é possível visualizar e identificar os processos 1 e 2 necessários para produzir os documentos Doc3 e Doc4, respectivamente. É possível, para cada processo, identificar as actividades correspondentes à produção de cada documento, assim:. .. Processo 1 (identificado na Fig. 14 com um 1 e uma linha contínua) -. Este processo produz o Doc3 e executa as actividades: ler Aux1, ler Doc1 e escrever Doc1 no Fich_1. Todas estas actividades têm como factor comum a frequência 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 têm como factor comum a frequência de Doc4..

(55) Capítulo 3: Estudo do Método. 3.4. 49. TRABALHOS ANTERIORES. Em 1988, foi desenvolvido um trabalho com o objectivo de estudar a validade do método ASA, construindo-se na altura um pequeno protótipo [Couto, Moreira e Araujo, 1988].. A entrada de informação existente no projecto de 1988 era muito simples, consistindo na seguinte informação:. . . . . . .. nome do sistema em estudo;. nome dos domínios pertencentes ao sistema;. nome dos documentos;. nome dos campos de cada documento;. tipo dos documentos;. frequência dos documentos cujo tipo seja de entrada, saída ou estático;. Esta informação era fornecida de uma forma não interactiva o que pressupunha que os resultados obtidos dependessem da ordem de fornecimento da informação.. A automatização assentava na classificação de campos segundo a sua origem da informação, ver Tabela 3..

(56) Capítulo 3: Estudo do Método. 50. Campo existe no Sistema? Onde?. Sim. é Texto Em qualquer Domínio é Sistema num Ficheiro Freq = No é de Domínio Entrada Freq <>. Classe Texto Sistema Ficheiro Directo Ficheiro. é Freq = Estático Freq <> num Ficheiro é Estático. Estático Ficheiro Ficheiro Ficheiro. Noutro Domínio Não. Estático. Tabela 3 - Identificação das classes dos Campos. O objectivo da Tabela 3 é determinar relações para cada domínio e atribuir classes aos campos dos documentos de saída desse domínio, permitindo verificar se estes têm informação suficiente para serem criados. No entanto, a análise da Tabela 3 permite verificar que é uma outra forma de visualizar o funcionamento do processo de automatização descrito através do Diagrama de Fluxos de Informação Interna .. Em 1990, foi desenvolvido um outro trabalho com o objectivo de continuar o trabalho anterior, tendo como resultado a construção de um novo protótipo [Ferreira e Azevedo, 1990]. Este trabalho conseguiu diversas melhorias em relação ao anterior ao estudar as áreas de:. .. detecção de redundâncias, através da adopção das técnicas anteriormente. descritas;.

(57) Capítulo 3: Estudo do Método. .. 51. geração de relações e especificações de Sistemas de Informação,. baseando-se no DFII e na tabela representada na Tabela 3;. .. utilização de um diálogo com o utilizador, que possibilita a. interactividade no protótipo, através da adopção de um interpretador em "linguagem quase natural". Faltando, contudo, a possibilidade de se estabelecer diálogo com o utilizador através de diagramas ou gráficos.. 3.5. CARACTERIZAÇÃO DO MÉTODO. O critério utilizado para caracterizar o método vai ser o mesmo que a Dr.ª Filomena Lopes utilizou na sua tese de mestrado [Lopes, 1990]. Este critério assenta em dois pressupostos:. 1º definir uma lista de atributos para os diversos Sistemas de Informação existentes, ver Tabela 1 (pág. 17) onde se representam diversos tipos de Sistemas de Informação;. 2º para essa lista de atributos de sistema definir quais as características dos métodos que satisfazem esses atributos.. Este critério permite seleccionar o método mais adequado para satisfazer determinados tipos de atributos de sistemas. No entanto, a Dr.ª Filomena Lopes, considera que existem três atributos comuns a todos os Sistemas de Informação.