Manual de Uso da FAFOOPS

   A seguir listamos todas as características implementadas pela FAFOOPS destacando a forma de utilização dos mesmos. Obviamente que esses recursos da FAFOOPS estão, direta e totalmente, voltados para as características da linguagem formal FOOPS, implicando assim que o uso da FAFOOPS por um engenheiro depende do conhecimento do mesmo com relação a linguagem formal FOOPS. Em vários pontos, a seguir, fazemos referência a número de requisitos que elicitamos para  a FAFOOPS e que estão de alguma forma sendo implementados. Todos esses requisitos podem ser encontrados na documentação referente à FAFOOPS.

Formas de Acessar as Funções da FAFOOPS

    Na FAFOOPS, existem duas formas distintas, de acessar as funções disponibilizadas: através dos menus, ou através do botões suspensos. Através dos menus, o usuário da FAFOOPS poderá acessar todas as funções da ferramenta. Adicionalmente, os menus, sempre estão visíveis e disponíveis ao especificador, não alterando de forma alguma, mesmo que a FAFOOPS esteja em modos de trabalho diferentes.

Os botões suspensos, por sua vez, possuem características diferentes dos menus. Primeiramente, que seu uso, não tem por objetivo disponibilizar um meio para que o usuário acesse todas as funções da ferramenta, mas sim, criar um mecanismo rápido (sem a necessidade de navegar em menus e sub-menus) e intuitivo (através do uso de ícones) de acessar as principais funções da ferramenta. Na FAFOOPS, os botões suspensos foram utilizados dentro da proposta citada acima, ou seja, disponibilizar um meio de acesso rápido e intuitivo aos principais recursos da ferramenta. Contudo, uma observação fundamental aqui, é que, devido a FAFOOPS fazer uso de vários modos de trabalho diferentes, os botões suspensos da ferramenta não fixos, ou seja, os botões disponibilizados ao especificador, dependem do modo de trabalho que ele esteja utilizando. Ratificando, o que foi dito, temos que quando o usuário estiver no modo de trabalho ``Editor de Módulo'', os botões suspensos apresentados pela ferramenta serão relacionados a este modo de trabalho. O mesmo ocorre para os demais modos de trabalho, ``Diagrama de Módulos'' e ``Diagrama de Classes''. A figura 5.3, destaca, os menus e os botões suspensos da FAFOOPS.

Figura 5.3: Formas de Acessar as Funções da FAFOOPS

A figura 5.4 apresenta a parte do menu da FAFOOPS destinada para que o usuário possa navegar entre os diferentes modos de trabalhos. É importante destacar estas opções, pois toda a ferramenta é configurada, automaticamente, para trabalhar sobre o modo de trabalho que estiver selecionado.

Figura 5.4: Opções de Modos de Trabalho da FAFOOPS

Detalhamento dos Recursos Implementados na FAFOOPS

    Nesta seção visamos apresentar todas as funcionalidades existentes na FAFOOPS. Mais do que, simplesmente listar estas funções implementadas, iremos também, simultaneamente, destacar as decisões de desenho que tangenciaram cada uma dessas funções e relacionar as mesmas aos requisitos elicitados por nós para a FAFOOPS. Todas as decisões de desenho, que implicaram na não implementação de recursos para a FAFOOPS, ou mesmo, implicaram na implementação parcial dos mesmos, serão discutidos separadamente, na próxima seção, desta página.

Suporte a Múltiplos Projetos

    A FAFOOPS implementa a noção de projetos, como definido no requisito R1. Sendo assim, a FAFOOPS permite que seus usuários possam trabalhar na especificação de diversos sistemas diferentes, bastando, para isto, criar um projeto independente para cada um desses sistemas. Desta forma, sempre que for necessário trabalhar sobre um dado sistema, basta que o projeto correspondente ao mesmo seja aberto.

Funções Implementadas para Apoiar Múltiplos Projetos

    Existem várias funções distintas, disponibilizadas pela FAFOOPS, que o usuário pode utilizar no     contexto de projetos. Elas são: criar um novo projeto, abrir um projeto existente, salvar um projeto, fechar o projeto aberto para liberar a ferramenta para que outro projeto possa ser editado, visualizar e editar propriedades do projeto, criar um novo projeto a partir de um existente (salvar como), realizar um backup automatizado de um projeto e por último excluir um projeto existente.

Por razões de tempo, decidimos por implementar somente as funções associadas a projeto que viabilizassem ao engenheiro utilizar a interface em vários projetos distintos. Desta forma a FAFOOPS está disponibilizando dentre as funções apresentadas em seu menu, as seguintes funções básicas:

• Criar um Novo Projeto - Permite ao especificador criar um novo projeto de especificação para um sistema. Basicamente o especificador tem que fornecer um nome para o projeto e indicar a pasta na qual o projeto irá ficar armazenado. Uma restrição fundamental aqui é que dois projetos diferentes não podem compartilhar a mesma pasta, pois os módulos de um projeto são identificados pela FAFOOPS como sendo aqueles que estiverem presentes na pasta (ou diretório) onde o projeto estiver.
• Abrir um Projeto Existente - Possibilita que o engenheiro abra um projeto já existente para editar as especificações do mesmo. É uma função bastante semelhante à listada acima, ou seja, cabe ao especificador dizer qual projeto ele deseja abrir.
• Salvar Projeto - Esta função não possui um tela específica para ela. Quando a mesma é acionada a FAFOOPS faz uma verificação de todos os módulos que foram editados (e não salvos) e grava o código dos mesmos nos seus correspondentes arquivos. Adicionalmente esta função também salva algumas propriedades (posição de cada módulo no diagrama de módulos e posição de cada classe no diagrama de classes) relacionadas ao projeto em si, de forma a garantir que, quando o projeto for novamente aberto na FAFOOPS, os diagramas sejam recuperados exatamente na forma como foram salvos na última edição do projeto.
• Fechar Projeto - Assim como a função Salvar Projeto, esta também não possui um tela destinada para ela. Esta função é bastante simples e pode ser descrita nos seguintes passos: primeiramente ela verifica se o projeto esta salvo ou não; caso não, o usuário é questionado sobre o que ele deseja fazer, salvar o mesmo ou não; depois, dependendo da escolha do usuário, o projeto é salvo, ou caso contrário, é descartado; e finalmente, a interface é reinicializada de forma a deixá-la pronta para trabalhar sobre outro projeto.
• Interagir FOOPS - Esta função caracteriza muito bem como algumas de nossas decisões de desenho na FAFOOPS não são definitivas. Como pode ser observado, o requisito R4 declara que o usuário deve ter a impressão de que a FAFOOPS e o FOOPS, são na verdade, um elemento só. Porém a interação entre esses dois elementos não foi implementada ainda, o que impossibilitou que este requisito fosse atendido. De qualquer forma a necessidade de que as especificações produzidas através da FAFOOPS fossem analisadas pelo FOOPS não deixou de existir.

  Daí, resolvemos definir um recurso que viabilizasse esta comunicação FAFOOPS - FOOPS, mesmo que de forma rudimentar. Este meio de comunicação se dá através da função ``Interação'' apresentada no menu ``Projeto''. Esta função faz uso da janela apresentada na figura 5.5, onde o usuário pode definir quais módulos devem ser submetidos para o FOOPS (Lista de módulos denominada ``Módulos Selecionados'') a partir de uma lista de módulos existentes no projeto atual (denominada ``Módulos Disponíveis''). Um módulo pode ser selecionado para ser submetido através do botão ``Selecionar'', ver figura 5.5. A remoção de um módulo da lista de módulos a serem submetidos ao FOOPS é realizada através do botão ``Remover'' na figura 5.5.

  Além de definir quais módulos devem ser submetidos ao FOOPS, através desta janela o especificador pode definir a ordem na qual esses módulos devem ser submetidos, fator este que é muito importante, pois o FOOPS exige que exista um precedência de carga entre os módulos. Esta ordem em que os módulos devem ser submetidos ao FOOPS pode ser alterada por intermédio dos botões ``Subir'' e ``Descer'', apresentados em 5.5. É importante registrar que a ordem de carga desses módulos no FOOPS é de cima para baixo na listagem.

  Depois que o usuário definir quais módulos do projeto devem ser submetidos ao FOOPS e em que ordem isso deve ocorrer ele deve clicar no botão salvar, isto fará com que a FAFOOPS gere um arquivo com o nome do projeto e extensão ``.foo'' onde todas essas informações sobre carga dos módulos são armazenadas de uma forma que o FOOPS compreenda. Assim quando o especificador executar o FOOPS e for avaliar a especificação que ele desenvolveu na FAFOOPS basta que ele digite no FOOPS o comando in seguido pelo nome deste arquivo gerado pela FAFOOPS, que desta forma toda a carga dos módulos ocorrerá automaticamente. Obviamente que esta forma de interação com o FOOPS é bastante limitada e portanto é digna de futuras atualizações.

  Figura 5.5: Janela para Definir Ordem de Carga dos Módulos No FOOPS

Diagrama de Módulos da FAFOOPS

O módulo, para a linguagem FOOPS, é a unidade básica para construção de uma especificação. Ou seja, uma especificação em FOOPS é um conjunto de módulos que no seu total (considerando suas hierarquias e componentes) determinam os requisitos de um sistema.

Sendo assim, para um especificador FOOPS, é fundamental visualizar o sistema através de um diagrama que apresente os módulos e todas as hierarquias existentes entre os mesmos, para que assim ele consiga racionar de forma modular (o que é fundamental para especificar sistemas grandes), direcionando seu raciocínio somente nas propriedades importantes no momento de planejar o sistema como um todo.

Este recurso da FAFOOPS, denominado Diagrama de Módulos, é definido e especificado no nosso requisito R6. Lá discutimos detalhadamente a importância deste Diagrama de Módulos e suas possíveis conseqüências benéficas.

Notação Gráfica Utilizada no Diagrama de Módulos

Em [Soc92] é definida uma notação gráfica para visualizar uma especificação FOOPS através dos módulos e teorias que a compõem e das hierarquias existentes entre os mesmos.

A FAFOOPS fez uso desta notação gráfica para apresentar o Diagrama de Módulos. Como pode ser notado na figura 5.6 um módulo ou uma teoria são representados no diagrama através de um retângulo. Logo MES, HORA, DATA e INTERVALOTEMPO são exemplos de módulos na especificação do SAR [Dar92] visualizada na FAFOOPS.

Outra notação gráfica utilizada é a seta tracejada que vai de um módulo A em direção a um outro módulo B. Esta seta indica que o módulo A é importado pelo módulo B. Em nossa figura 5.6 podemos notar que no SAR, o módulo DATA importa o módulo MES, pois para definirmos uma data necessitamos da noção de mês. O mesmo ocorre com o módulo INTERVALOTEMPO (cujo nome na figura 5.6, aparece cortado, devido ao seu comprimento) que especifica que um intervalo de datas é composto por duas datas, uma data inicial que deve ser menor ou igual a uma data final. Obviamente que o módulo INTERVALOTEMPO necessita da especificação de uma data (módulo DATA) para ser definido.

Uma característica que adicionamos à notação listada em [Soc92] é uma pequena descrição que é apresentada no canto inferior direito de cada módulo. Esta descrição é uma indicação de que tipo de módulo ou teoria está sendo representado pelo retângulo. Basicamente na linguagem FOOPS podemos ter: um módulo funcional (fmod), um módulo orientado a objetos (omod), uma teoria funcional (fth) ou uma teoria orienta a objetos (oth). Logo a descrição diz em qual dos quatro tipos listados acima o módulo ou teoria representado pelo retângulo se encaixa. Recorrendo novamente a figura 5.6 podemos notar por exemplo que o módulo INTERVALOTEMPO é um módulo funcional (fmod) enquanto que o módulo REUNIAO é um orientado a objetos (omod). Este recurso, agregado por nos ao diagrama de módulos, foi definido e justificado no requisito R6.6 da FAFOOPS.

Figura 5.6: Diagrama de Módulos para o Sistema SAR

Descrição das Funções Correlatas ao Diagrama de Módulo

Iremos descrever, agora, as funções de nossa ferramenta formal, relacionadas ao Diagrama de Módulos, que foram implementadas. Estas funções são listadas e explicadas detalhadamente abaixo. As funções, definidas nos requisitos da FAFOOPS, mas que não forem descritas abaixo, são funções não implementadas. Adiante, na seção 5.5.4 iremos discutir cada uma delas.

• Criar um Novo Módulo - Esta função pode ser acionada tanto do menu quanto de um botão suspenso. Ela é responsável por criar um novo módulo e adicioná-lo ao projeto que estiver sendo editado. Este processo de criação exige do especificador somente que ele informe em uma janela o nome e o tipo de módulo que ele deseja criar. A FAFOOPS por sua vez, gera automaticamente a especificação para o módulo, cria o arquivo texto correspondente ao módulo na pasta do projeto que esta em edição e grava neste arquivo texto a especificação gerada para o módulo (Este arquivo tem o nome do módulo que foi criado e a extensão ``.foo'').
• Selecionar Módulo - Esta é uma das funções mais simples da FAFOOPS. Basta um clique duplo sobre o módulo no Diagrama de Módulos para que ele seja selecionado. Sempre existe um, e somente um, módulo selecionado na FAFOOPS. No Diagrama de Módulos o módulo que esta selecionado é apresentado com uma cor cinza escura, o que o diferencia de todos os demais módulos (Na figura 5.6 o módulo DATA está selecionado). Esta propriedade de sempre existir um único módulo selecionado (ou em foco) é advinda do próprio FOOPS. No FOOPS todas as expressões submetidas para execução são aplicadas sobre o módulo que estiver ativo (selecionado) naquele momento. Como a FAFOOPS tem que trabalhar de acordo com esta restrição, logicamente que ela também teve que implementar a noção de módulo ativo ou selecionado. Outra razão que conduz a necessidade de sempre existir um módulo selecionado é que assim a FAFOOPS consegue identificar em qual módulo deve ser aplicada uma dada operação requisitada pelo engenheiro. Por exemplo, se o usuário da interface acionar a função Editar Módulo qual deve ser o módulo a ser editado? Logicamente que é o módulo que estiver selecionado naquele momento.
• Editar Módulo Selecionado - Um outro modo de trabalho da FAFOOPS é o Editor de Módulos. Na verdade, quando o usuário requisita a execução desta função, o que ele está dizendo para a FAFOOPS é: altere seu modo de trabalho de forma a abrir o módulo que está selecionado no Diagrama de Módulos no Editor para que eu possa altera-lo. Este é um processo típico onde a FAFOOPS necessita trocar seu modo de trabalho e ao mesmo tempo manter a consistência na especificação. Ou seja, se o usuário alterou a especificação utilizando o Diagrama de Módulos (criou um nova hierarquia entre módulos, criou um novo módulo, etc), ao ele entrar no Editor essas alterações devem ser visualizadas na especificação do módulo que foi aberto. Em 5.4.4 iremos apresentar o Editor de Módulos em detalhes.
• Salvar Módulo Selecionado - Ao ser executada, esta função da FAFOOPS, simplesmente salva no arquivo texto correspondente a especificação do módulo que estiver selecionado. Esta função também pode ser utilizada no Editor de Módulos tendo o mesmo resultado. É importante salientar que a FAFOOPS mantém a informação de que módulos foram alterados, mas não foram salvos. Assim caso o usuário mande salvar um módulo que não sofreu alterações a FAFOOPS simplesmente não faz nada.
• Definir Hierarquia entre Módulos - Através deste recurso, é possível que o usuário - sem a necessidade de editar qualquer especificação - defina a hierarquia entre dois módulos distintos, ou seja, defina que um módulo A deve importar um módulo B. Para definir uma hierarquia entre dois módulos no Diagrama de Módulos o usuário deve clicar no módulo que será importado com a tecla shift pressionada e logo em seguida clicar no módulo importador ainda com a tecla shift pressionada. A FAFOOPS modifica a cor dos dois módulos definidos como importado e importador para amarelo (como apresentado na figura 5.7). Isto facilita para o usuário identificar entre quais módulos ele esta definindo a hierarquia.

  Figura 5.7: FAFOOPS Criando Hierarquia entre Módulos

  Na figura 5.8, temos a mensagem que a FAFOOPS apresenta para o usuário, logo após ele clicar no segundo módulo, portanto logo em seguida a ele indicar qual é o módulo importado e importador. Repare que, na figura 5.7, nos havíamos selecionado o módulo DATA para ser importado e o módulo PARTICIPANTE como importador. Repare que a figura 5.8 declara exatamente esta situação. Note também que na mensagem são apresentados quatro opções ao especificador: importar o módulo DATA com a diretriz using, ou importar o módulo DATA com a diretriz protecting, ou importar o módulo DATA com a diretriz extending, ou finalmente cancelar a operação de importar o módulo DATA. Estas opções vão de encontro as diferentes formas de importar um módulo disponibilizada pelo FOOPS.

  Figura 5.8: Mensagem da FAFOOPS para Criar uma Hierarquia entre Módulos

  É notável que criar hierarquia entre módulos sem ter que editar códigos de especificações torna o trabalho do usuário da FAFOOPS muito mais interessante. Este recurso adicionado a possibilidade de criar módulos também sem ter que editar especificações permite ao usuário criar toda a estrutura (esqueleto) da especificação de um sistema, sem ter que perder a visão sistêmica da especificação tendo que detalhar o código de cada um dos módulos. Esta é mais uma característica da FAFOOPS que vai de encontro ao requisito R6, referente ao Diagrama de Módulos.

Diagrama de Classes da FAFOOPS

    Apesar de a unidade básica para construção de uma especificação FOOPS ser o módulo, esta linguagem apresenta uma propriedade extremamente interessante para o usuário, que é o suporte a orientação à objetos. A OO (orientação a objetos) traz várias vantagens para o especificador, principalmente na forma como pensar e organizar as partes (componentes) do sistema.

A FAFOOPS, como interface do FOOPS, também fornece mecanismos para que o engenheiro possa trabalhar utilizando a OO em suas especificações. Estes mecanismos basicamente giram em torno de um recurso especial da FAFOOPS que é o Diagrama de Classes. Este diagrama é a representação gráfica de todas as classes e subclasses (juntamente com algumas de suas propriedades) definidas na especificação. Disponibilizando assim ao especificador um visão abstrata que se concentra nos aspectos OO e despresa outros elementos da linguagem FOOPS como: módulos, hierarquias entre módulos, sorts, funções, etc.

A seguir, como para o Diagrama de Módulos, iremos descrever todas as funções disponibilizadas pela FAFOOPS para este modo de trabalho. Já podemos adiantar que existem ainda poucas funções e recursos na FAFOOPS que apóiem o seu usuário a pensar e especificar utilizando todo o poder da OO, na seção 5.5.5 iremos falar detalhadamente sobre estas limitações.

Notação Gráfica Utilizada no Diagrama de Classes

Na figura 5.9, temos um exemplo de Diagrama de Classes gerado pela FAFOOPS para o sistema SAR (Apêndice A e [Dar92]). Como é notável na figura, uma classe no diagrama é representada por um retângulo que possui uma barra horizontal em sua parte superior. Acima desta barra temos o nome da classe na qual o retângulo está representando. Abaixo temos uma lista dos atributos definidos na especificação para tal classe. Sendo assim temos que em nosso exemplo Reuniao, Participante, PartImportante, PartComum e PartReuniao são classes. Já, intervalodata, duracao e iniciador, por sua vez, são atributos da classe Reuniao (como pode ser observado abaixo da barra horizontal superior da classe Reuniao).

Adicionalmente temos que as hierarquias entre as classes também são representadas no diagrama. Recorrendo novamente a figura 5.9 podemos verificar a existência de duas setas partindo das classes PartImportante e PartComum e chegando na classe Participante. Elas indicam que ambas as classes PartImportante e PartComum são subclasses da classe Participante. Vale ressaltar as classes PartImportante e PartComum, não fazem parte realmente da especificação formal do SAR, nos criamos as mesmas, temporariamente no SAR, somente para exemplificar o que estamos dizendo aqui.

Figura 5.9: Exemplo de Diagrama de Classes da FAFOPS

A notação utilizada acima vai de encontro à notação proposta em [Boo00] que descreve a linguagem para modelagem OO conhecida como UML. Na seção 5.5.5, como já mencionado, iremos enumerar mais propriedades de uma especificação OO que deveriam, mas não são apresentadas na FAFOOPS.

Descrição das Funções Correlatas ao Diagrama de Classes

Existem somente três funções vinculadas ao Diagrama de Classes (e, portanto, a gerência das classes e subclasses da especificação) na FAFOOPS. A seguir, iremos enumerá-las e explicá-las detalhadamente.

• Criar Nova Classe - Esta função é responsável por criar uma nova classe na especificação do sistema. Para o especificador executar esta função basta que ele forneça o nome da classe que ele deseja criar, não necessitando, portanto, que haja edição de especificação FOOPS.

  Como para criar uma classe necessitamos inserir a respectiva codificação no interior da especificação de um módulo, a FAFOOPS foi projetada para sempre assumir o módulo ativo (ou selecionado) para ser o módulo no qual a nova classe será definida. Esta decisão de desenho procura seguir o padrão do FOOPS no qual toda operação que lhe é enviada é aplicada sobre o módulo ativo do FOOPS no momento da requisição.

  A FAFOOPS não permite que uma classe seja criada em um módulo funcional, quando este problema ocorrer, a FAFOOPS irá identificar o problema e alertar seu usuário sobre o ocorrido.

  E ainda para ajudar o especificador no momento de criar suas classes a FAFOOPS apresenta em seu rodapé sempre o nome do projeto aberto e o nome do módulo ativo no projeto naquele momento. Assim, o usuário sempre poderá saber em qual módulo a nova classe será criada.

• Criar Nova Sub-Classe - Possui o funcionamento idêntico ao da função ``Criar Nova Classe'' discutida acima. Uma consideração adicional que temos que fazer aqui é: quando o especificador requisitar a criação de uma subclasse, a FAFOOPS criará a subclasse requisitada para a classe que estiver selecionada no momento da requisição. No Diagrama de Classes sempre existe uma classe selecionada, assim como no Diagrama de Módulos sempre existe um módulo selecionado.
• Editar Classe ou Sub-Classe - Esta função, por sua vez, é semelhante a função editar módulo, ou seja, quando o usuário aciona esta função a FAFOOPS automaticamente altera seu modo de trabalho se conduzindo para o Editor de Módulos e já apresenta a especificação do módulo correspondente no editor, pronta para ser alterada. Obviamente que, ao usuário requisitar a edição de uma classe, o módulo que será aberto no Editor de Módulos será aquele onde a referida classe foi definida.

Editor de Módulos da FAFOOPS

    Este é o recurso da FAFOOPS do qual o especificador provavelmente mais fará uso. Ele é denominado de Editor de Módulos e tem por objetivo disponibilizar um editor inteligente, que apóie ao máximo o engenheiro, no momento de escrever suas especificações. Esta codificação da especificação é um das tarefas mais lentas e complexas para o especificador. Sua complexidade é proporcional a complexidade das linguagens formais em si, que fazem uso de inúmeras expressões, comandos e regras de sintaxe e semântica para disponibilizar poderes para especificar precisamente os requisitos dos sistemas do mundo real.

Sendo assim, como advogado em R10, é fundamental para o especificador ter um editor integrado com o ambiente de seu método formal e que seja totalmente voltado para apoiar as peculiaridades da linguagem formal que ele utiliza, de forma que ele alcance uma maior facilidade e produtividade em seu trabalho.

A seguir, detalharemos todos os recursos do Editor de Módulos da FAFOOPS, destacando também pontos a serem futuramente desenvolvidos. Um primeira visão do Editor de Módulos da FAFOOPS é apresenta na figura 5.10. Nesta figura temos o editor ativo na FAFOOPS com a especificação do módulo Reuniao do SAR.

Figura 5.10: Editor de Módulos com uma Especificação de um Módulo

Descrição das Funções Correlatas ao Editor de Módulos

Abaixo, segue uma lista das funções disponibilizadas atualmente pela FAFOOPS ao especificador, em se tratando do Editor de Módulos. Algumas destas funções são usuais em qualquer editor de texto, porém, em sua grande maioria, estas funções apóiam o engenheiro a trabalhar especificamente com a linguagem formal FOOPS. No requisito R10, temos a definição de todas as propriedades e funcionalidades correspondente ao Editor de Módulos.

• Palavras Reservadas do FOOPS em Negrito - Como é notável na figura 5.10, temos que todas as palavras reservadas da linguagem formal FOOPS sempre aparecem em destaque (negrito) no Editor de Módulo. Este é um recurso que ajuda o especificador a ter uma visão mais clara da especificação e conseqüentemente entendê-la com maior facilidade.

  Adicionalmente é importante destacar que esta característica da FAFOOPS também é válida durante a edição da especificação. Sendo assim, ao se terminar de digitar uma palavra no editor, caso esta palavra seja reservada a mesma ficará imediatamente em negrito. Isto traz uma vantagem ao especificador, pois quando ele digitar uma palavra reservada e o editor não a coloca-la em negrito, então temos a indicação de um erro de digitação (sintaxe).

• Inserção Automática de Expressões (Comandos) FOOPS - A FAFOOPS disponibiliza um conjunto de funções que são destinadas a inserir expressões padrões para definir novos elementos dentro de uma especificação FOOPS.

  Por exemplo, sempre que desejamos criar um sort temos que digitar a palavra sort seguida pelo nome desejado para o sort e por um ponto final ``.''. Já com estas funções, basta que o especificador tecle CTRL + S simultaneamente para que a expressão-padrão do FOOPS para criação de um sort seja inserida na especificação e o cursor fique posicionado no ponto ideal para digitação do nome do mesmo.

  Na figura 5.11, temos a relação completa de todas as teclas de atalho do editor com o respectivo tipo de elemento que será criado na especificação caso a mesma seja pressionada. A janela apresentada na figura 5.11 pode sempre ser consultada pelo especificador através do subitem de menu ``Inserir Especificação'' do item de menu ``Editor''.

  Figura 5.11: Teclas para Inserir Estruturas de Especificação FOOPS Padrões

• Importar Outro Módulo dentro do Editor - Das funções discutidas e listadas na seção anterior, uma se destaca, Importar um Módulo. É muito comum que ao se estar editando a especificação de um módulo, seja necessário importar outro. Como no editor não existe como o especificador visualizar quais são os demais módulos existentes na especificação do sistema, a FAFOOPS apresenta um tela onde o engenheiro pode determinar duas informações: primeiro o modo de importação que ele deseja realizar (using, protecting, extending), e por último o módulo a ser importado.

  A figura 5.12 apresenta exatamente esta tela. Assim que o especificador terminar de selecionar os dados que ele deseja basta que ele pressione ENTER para que esta tela se feche e o respectivo comando de importação seja criado na especificação.

  Figura 5.12: Tela para Importar outro Módulo no Editor de Módulo

• Copiar, Recortar e Colar Texto de Especificação - Estas são características bastante simples e comuns em quase todos os editores de textos convencionais. Obviamente que elas são úteis também para o especificador formal. Elas podem ser acessadas através do menu ``Editor'' e também de teclas de atalho.
• Desfazer e Refazer Alterações na Especificação - Também são recursos comuns e simples, porém para o especificador formal elas são muito úteis, pois um acidente ou equívoco de digitação pode levar a deleção de uma expressão bastante complexa, o que causaria um prejuízo de tempo e esforço. Estas são funções que podem ser acessadas tanto do menu quanto dos botões suspensos.
• Descartar as Alterações Realizadas no Módulo - Esta função é uma espécie de ``super'' desfazer. Sempre que ela é acionada a especificação do módulo volta a ficar na situação que estava no momento em que ela foi salva pela última vez. Isto é possível pois na FAFOOPS, sempre que um módulo é salvo, é gerado uma cópia de segurança para ele (arquivo com o nome do módulo e a extensão ".bfo''). Desta forma a recuperação da especificação deste arquivo de backup garante o funcionamento deste recurso. Este recurso é encontrado no item de menu Módulo, assim como os próximos descritos nesta seção. Esta decisão foi tomada por acharmos mais intuitivo para o usuário visualizar estes recursos como sendo pertinentes ao módulo em si.
• Salvar Especificação Módulo - Já discutimos esta função nesta página quando falávamos do Diagrama de Módulos. Ela, para o modo de trabalho Editor de Módulos não apresenta nenhuma novidade, ou seja, simplesmente salva a especificação atual do módulo (que esta no editor) no arquivo de texto correspondente.
• Criar um Novo Módulo - Assim como no modo de trabalho Diagrama de Módulos esta função faz a requisição de um nome para o módulo e da informação de qual tipo de módulo se deseja criar. A única diferença é que quando estamos no Editor de Módulos a FAFOOPS simplesmente fecha algum módulo que por acaso esteja aberto e já abre a especificação gerada para o novo módulo, não chegando assim a apresentar a representação gráfica do mesmo.

Considerações Adicionais sobre as Decisões de Desenho da FAFOOPS

Nesta seção visamos apresentar diversas decisões de desenho que tomamos com relação a FAFOOPS. Com algumas exceções, como o próximo item listado abaixo, que discute decisões relacionadas a linguagem de programação e plataforma, todos os demais itens, nesta seção, estão voltados principalmente para um caminho. Este caminho é, discutir decisões de projeto, que de alguma forma conduziram a não implementação, ou mesmo implementação parcial, de funções especificadas através dos requisitos elicitados para a FAFOOPS. Com isto, deixaremos claro ao leitor, os pontos desta ferramenta que necessitam de serem desenvolvidos ou melhorados. Vale ressaltar que, todas essas decisões de desenho, que limitaram a funcionalidade da FAFOOPS, foram tomadas principalmente em decorrência da falta de tempo.

Linguagem e Plataforma

    FAFOOPS foi desenvolvida utilizando a linguagem Java (SDK 2.0 - JFC/Swing). A opção pela linguagem Java foi, primeiramente, de encontro à possibilidade de implementação da FAFOOPS em uma arquitetura cliente-servidor que, viabilizasse o seu uso em estações clientes Windows, Linux, e assim por diante, tornando, desta forma, a ferramenta totalmente multiplataforma - do lado cliente - e também multiusuária (Com Java poderíamos desenvolver tanto o lado cliente quanto o lado servidor da ferramenta, utilizando a mesma linguagem de programação).

Outro ponto que nos conduziu para a linguagem Java foi a intenção de implementar a FAFOOPS para trabalhar em ambiente Web, dado que existem vários recursos que Java disponibiliza para aplicações Web, como Applets, Sevlets, JSP, dentre outros. Assim, o especificador poderia trabalhar em um browser e especificar seus sistemas com todos os benefícios agregados à Internet. Esta opção de implementação chegou a ser inicialmente implementada por nós, entretanto, nós desistimos desta abordagem, pois atualmente a criação de GUI's (Interfaces Gráficas com o Usuário) com as propriedades que a FAFOOPS exige é bastante limitada em um ambiente como o da Internet.

A FAFOOPS, na forma como se encontra - uma aplicação que trabalha em conjunto com FOOPS em uma única estação de trabalho (monousuária) - está preparada para ser atualizada para implementar uma arquitetura cliente-servidor que viabilize à mesma ser totalmente multiplataforma e multiusuária.

Interação com o FOOPS

Como mencionado na introdução desta página, muitas das decisões de desenhos que tomamos não são definitivas, em decorrência da pouca disponibilidade de tempo. Uma das principais decisões dentre essas, diz respeito à forma como a FAFOOPS interage com o FOOPS. Foi definido como um requisito da FAFOOPS (R4) que ela deveria implementar toda a interação com o FOOPS de forma automática e transparente, de forma a garantir que o usuário não tivesse a percepção de que o FOOPS e a FAFOOPS são ambientes distintos. Contudo durante o desenho da interface decidimos por não implementar esta interação, adotando um abordagem não definitiva, onde a FAFOOPS ficou independente do FOOPS, permitindo que o especificador gere suas especificações em um ambiente gráfico mas que no momento de validar e verificar suas especificações ele tenha que recorrer ao FOOPS por conta própria, submetendo ao mesmo os textos de especificação gerados no FAFOOPS. Em 5.4.1 detalhamos a função ``Interagir FOOPS'' que é uma função paliativa que apóia o especificador no momento de submeter as suas especificações desenvolvidas no FAFOOPS para o FOOPS.

Decisões de Desenho Adicionais sobre Gerência de Projetos

• Armazenamento dos Dados de um Projeto - A primeira, e fundamental, decisão de desenho que tomamos para implementar a noção de projeto foi definir como seria fisicamente armazenado os módulos de um projeto. O FOOPS permite que vários módulos possam ser armazenados em um mesmo arquivo texto no disco rígido, porém na FAFOOPS por um questão de gerenciar mais facilmente a especificação de módulo, decidimos que cada módulo deve ser armazenado em um único arquivo texto correspondente a ele. Este arquivo texto deve ter o nome do módulo e deve ter como extensão ``.foo''. Esta convenção apesar de conduzir a certas limitações sobre a forma na qual a especificação é armazenada, traz facilidade para a implementação da FAFOOPS pois assim é muito mais fácil obter a especificação de um módulo para ser editada, salvar a especificação de um módulo e assim por diante.
• Módulos de um Projeto - Todos os módulos que estiverem na pasta correspondente a um projeto, por uma decisão também de desenho, passa a ser um módulo do projeto. Esta propriedade é a única que identifica quais são os módulos de um projeto.
• Reusabilidade de Módulos - O requisito R5 determina que a FAFOOPS deve possibilitar que módulos possam ser reutilizados em vários projetos distintos. Apesar deste recurso não ter sido implementado nesta versão da interface, o fato de cada módulo ser armazenado em um único arquivo texto, favore-se o seu reuso.
• Propriedades de um Projeto - Para cada projeto a FAFOOPS cria um arquivo (como nome igual ao nome do projeto e extensão igual a ``.pfa''), o qual fica armazenado na pasta correspondente ao projeto. Este arquivo pode ser utilizado para armazenar quaisquer informações sobre o projeto, nós tomamos uma decisão não definitiva de armazenar neste arquivo somente informações relativas a posicionamento dos elementos gráficos dos diagramas (posição de cada módulo no diagrama de módulos e posição de cada classe no diagrama de classes).

Decisões de Desenho Adicionais sobre o Diagrama de Módulos

• Posicionamento dos Módulos no Diagrama - A FAFOOPS é capaz de abrir qualquer especificação FOOPS, mesmo aquelas que não foram inicialmente desenvolvidas através dela (desde que a restrição de que cada módulo deva estar em um arquivo texto próprio seja satisfeita). Porém uma limitação da interface diz respeito a forma na qual os módulos de uma especificação com estas características serão apresentados. Isto porque a FAFOOPS sempre armazena a posição de cada módulo no diagrama no momento em que o projeto é salvo. Assim quando o projeto for aberto futuramente a ela é capaz de recuperar exatamente o posicionamento de cada módulo dentro do diagrama. Contudo no caso do sistema estar sendo aberto pela primeira vez, ela simplesmente organiza os módulos em cascata na tela (para que um não sobreponha o outro) e deixa por conta do usuário distribuir os mesmo de uma forma lógica e que facilite a compreensão da especificação como um todo. Esta decisão foi tomada devido a complexidade de um algoritmo que organiza-se, desde do princípio, os módulos de uma especificação de um forma lógica para o engenheiro.
• Relacionamento entre Módulos e Teorias - A linguagem FOOPS implementa várias formas diferentes de relacionamentos entre os módulos e teorias.

  Sendo assim além da possibilidade de um módulo (ou teoria) importar outro (através da diretriz using, extending e protecting), existem as seguintes outras formas de relacionamento:

  • Um módulo pode estar relacionado a outro através de um expressão modular, que faz uso de um módulo parametrizado e um segundo módulo qualquer para definir um terceiro e novo módulo. O terceiro é o resultado da instanciação do módulo parametrizado tendo o segundo módulo como parâmetro.
  • Um módulo pode estar relacionado a uma teoria, de forma que o módulo em questão é parametrizado e utiliza a teoria para definir seus requisitos de interface.
  • E, por último, uma teoria pode estar relacionada a um módulo ou a outra teoria, caso exista uma ou mais visões entre eles.

  As três últimas formas de relacionamento descritas acima não são representadas atualmente no diagrama de módulos, apesar da importância das mesmas no momento de construir e compreender especificações FOOPS completamente. Por conseguinte, estes são recursos que terão que ser adicionados nas próximas versões da FAFOOPS. O requisito R6.3, declara exatamente esta questão para a FAFOOPS.

• Demais Funções Não Implementadas - A seguir segue uma lista adicional de recursos que também não foram implementas na FAFOOPS: excluir um módulo, criar um novo módulo a partir de outro (salvar como), realizar backup de um módulo, definir módulo como padrão, utilizar módulo padrão e gerenciar módulos padrão. As três últimas funções enumeradas acima vão de encontro ao requisito descrito em R5. Enquanto que as demais são especificações dos requisitos descritos em R2 e R6.

   

Decisões de Desenho Adicionais sobre o Diagrama de Classes

• Notações do Diagrama de Classes - Quando consideramos os vários conceitos pertinentes a OO podemos perceber que existe muito trabalho - neste contexto - a ser feito na FAFOOPS. Um exemplo desta situação pode ser percebido na figura 5.9 onde é apresentada a classe Reuniao. Note que esta classe possui um atributo nomeado de iniciador que corresponde ao participante responsável pela reunião, ou seja, o participante que requisita e gerencia todos os dados da reunião. Como o iniciador de um reunião é um participante, podemos concluir que existe um relacionamento entre a classe Reuniao e Participante, isto porque o próprio atributo iniciador é definido como sendo do tipo Participante. Este relacionamento entre classes, é também apresentado no diagrama de classes, proposto na UML ([Boo00]), e em outros métodos OO. Assim como esta propriedade não é apresentada no Diagrama de Classes disponibilizado atualmente pela FAFOOPS, existem várias na mesma situação, dentre as quais podemos citar: cardinalidade dos relacionamentos entre classes, agregação, composição, etc. A FAFOOPS, para atender o requisito descrito em R7, necessita seguir completamente a notação padrão de algum método de engenharia de software OO do mercado, o que deixa pontos a serem cobertos em trabalhos futuros também aqui.
• Criação de Objetos para as Classes - Outra questão fundamental não apoiada ainda pela FAFOOPS está relacionada aos objetos criados para as classes. Um especificador FOOPS sempre trabalha definindo suas classes e criando objetos para as mesmas de forma que ele possa validar seu trabalho. Esta validação se dá através da criação de objetos e da requisição de execução (ao FOOPS) dos métodos desses objetos para os resultados obtidos possam ser verificados. Quando vivemos esta situação na prática sentimos a necessidade de uma ferramenta que nos ajudasse a visualizar os atuais objetos criados, como eles estão relacionados, quais os valores de seus atributos, de forma que em posse destas informações fosse possível verificar se as saídas produzidas pela execução dos métodos condizem com o estado dos objetos no momento desta execução. Estas questões relacionadas aos objetos foram discutidas e especificadas em forma de requisito para a FAFOOPS em R8. De qualquer forma temos que registrar que este requisito não foi implementado nem mesmo parcialmente, ficando assim a cargo do especificador recorrer ao FOOPS para consultar em um modo texto quais são os objetos criados na memória atualmente, quais são os valores de seus atributos, etc.

Decisões Adicionais de Desenho sobre o Editor de Módulos

Vamos enumerar agora algumas derivações do requisito correspondente ao Editor do Módulo (requisito R10) que não foram implementadas. Sempre lembrando que o fator tempo foi responsável por estas decisões.

• Linhas Referentes a um Elemento da Especificação - Um primeiro ponto que a FAFOOPS não está implementando em sua versão atual é apoio visual para o especificador identificar todas as linhas da especificação referente a um elemento específico. Para entender melhor o que esta sendo dito, temos que considerar que para definirmos uma classe em FOOPS, por exemplo, pode ser necessário várias linhas de codificação. Desta forma a definição deste recurso diz que se o usuário estiver editando alguma das linhas correspondentes a classe, então todas as outras linhas também correspondentes a ela devem ser apresentadas em destaque. Com isso o engenheiro poderia avaliar as conseqüências de sua alteração.
• Correção Automática de Erros de Digitação - Outro ponto interessante para o usuário da FAFOOPS que não foi implementado é correção automática e instantânea (on the fly) de palavras chaves digitas com algum erro. Por exemplo ao digitar o termo sort ao invés de sort o editor corrigiria automaticamente o erro do especificador.
• Cópias de Segurança - Um último ponto discutido no requisito escrito em R10 faz referência a gerência de várias cópias de segurança distinta de um mesmo módulo.