Classe Mode

Modos no GEF são objetos que definem um contexto para interpretação de eventos de entrada gerados pelo usuário. Por exemplo, um objeto ModePopup abre um menu de opções caso um evento de clique do botão direito do mouse for gerado. Modos podem instanciar comandos para serem executados no editor.

Como dito anteriormente, um editor possui um ModeManager, o qual mantém uma lista dos modos ativos do editor. O último modo adicionado a este gerenciador é o que têm prioridade. Um editor pode ter mais de um modo interpretando entrada de usuário, pois apenas um modo não cobre todas as possibilidades.

Dentre as várias classes que implementam os modos do GEF, as principais são: ModeSelect, ModeModify e ModeCreate.

• ModeSelect interpreta entrada de usuário quando uma ou mais figuras são selecionadas. Clicar em uma figura irá selecioná-la. Shift + clique em uma figura inverte a seleção. Arrastar o mouse em espaço aberto irá desenhar um retângulo de seleção (veja figura 4.7). Arrastar uma figura fará com que o modo de modificação seja chamado (ModeModify). Arrastar a partir de uma porta de um nodo fará com o que o modo de criação de arco seja chamado (ModeCreateEdge).

• ModeModify processa eventos quando o usuário está modificando uma figura. Os eventos tratados são relativos ao arrastamento ou redimensionamento de figuras.

• ModeCreate e suas várias subclasses tratam os eventos relacionados à criação das várias formas de figuras, como círculos, retângulos, linhas, texto, etc. Cada subclasse interpreta eventos de sua forma. Por exemplo, um modo de criação de linha desenha uma linha a medida que se arrasta o mouse, enquanto um modo de criação de círculo desenha um círculo.

4.2.1.5 Classe Selection

Seleções são objetos usados pelo Editor quando o usuário seleciona uma figura, ou um grupo de figuras, da área de edição. Seleções são responsáveis por desenhar "manipuladores" (handles), tratar eventos de arraste do mouse nos manipuladores e passar mensagens às figuras selecionadas. Seleções também representam o alvo do próximo comando. Na figura 4.5 há duas figuras selecionadas. Pode-se ver que as seleções desenharam vários manipuladores na forma de pequenos quadrados.

Como pode-se ver no diagrama da figura 4.8, a classe Selection é abstrata, sendo que suas subclasses implementam seleções de acordo com o tipo da figura selecionada. Por exemplo, se for possível que uma figura seja movida e redimensionada, um objeto SelectionResize (subclasse de Selection) será criado para esta seleção. Pode-se selecionar múltiplas figuras no editor, sendo que para cada figura é criado um objeto de seleção específico. O editor mantém um SelectionManager, que tem a função de gerenciar a coleção de seleções atual. Por exemplo, se foi pressionada uma tecla de movimentação, o SelectionManager avisa todas as seleções que estas devem se mover.

Figura 4.8 Seleções 4.2.2 Pacote org.tigris.gef.graph

Neste pacote há classes de interface a serem usadas para se representar grafos conexos. Também há classes exemplificando a implementação destas interfaces. A figura 4.9 mostra um diagrama com as classes deste pacote.

Como foi dito, o GEF pode ser usado para representar e editar graficamente objetos de aplicações já existentes. Para isto, o desenvolvedor que deseja usar o GEF para criar um editor de diagramas deve definir um modelo para o grafo de sua aplicação. Este modelo é uma classe que implementa a interface GraphModel, de forma a dar acesso aos dados da aplicações para, por exemplo, interfaces de usuário. Os dados não

ficam fora de sincronia, pois somente os objetos da aplicação guardam os dados e interfaces de usuário acessam estes dados somente por meio do modelo.

Figura 4.9 Interfaces para representar grafos

A interface GraphModel é uma fachada para os objetos do nível de rede, ou seja, é uma coleção de métodos que permitem consulta aos componentes do grafo, como nodos e arcos. Exemplos de representação em nível de rede são as classes NetList, NetNode, NetEdge e NetPort, descritas na seção 4.2.3.

A interface GraphModel é estendida pela interface MutableGraphModel, que possibilita a modificação do grafo e não somente acesso. MutableGraphSupport é uma classe abstrata que facilita ao desenvolvedor criar sua implementação do MutableGraphModel, pois já fornece implementações genéricas para os métodos mais comuns.

Algumas outras interfaces estão presentes neste pacote: GraphNodeHooks, GraphEdgeHooks e GraphPortHooks são interfaces que objetos do nível de rede podem implementar caso queiram executar ações específicas após conexão ou desconexão de nodos ou queiram impor restrições sobre a conexão de nodos

GraphEvent e MutableGraphEvent são notificações de que um grafo sofreu mudanças. Para uma classe reagir a estas notificações, deve implementar a interface GraphListener.

4.2.3 Pacote org.tigris.gef.graph.presentation

Neste pacote há classes que implementam as interfaces do pacote org.tigris.gef.graph. Esta implementação é um exemplo genérico, que pode ser usado por algumas aplicações, mas não é adequada para todas. A classe DefaultGraphModel deste pacote é uma implementação genérica de um grafo, sendo as classes NetNode, NetEdge e NetPort os componentes do grafo (figura 4.10).

Também está presente neste pacote o JGraph: um componente de interface gráfica que usa a classe Editor e muitas outras para apresentar grafos conexos e possibilitar sua edição interativa.

Figura 4.10 Primitivas do nível de rede 4.2.4 Pacote org.tigris.gef.presentation

Este pacote contém classes definindo vários tipos de figuras usadas no editor para apresentar graficamente grafos e outros objetos.

Fazem parte deste pacote a classe Fig e suas muitas subclasses, que representam objetos de desenho básicos, como retângulos, linhas, textos, círculos, polígonos, etc. Objetos da classe Fig podem ser mostrados por uma camada do tipo LayerDiagram e manipulados a partir de um Editor.

Os atributos básicos de uma figura são posição (coordenadas x e y), largura, altura, cor de preenchimento e cor de linha, entre outros. As subclasses de Fig (Figura

Figura 4.11 Figuras

Figuras têm a responsabilidade de tratar eventos de edição (remoção de um vértice de um polígono, por exemplo) e notificar seus dependentes de mudanças de estado.

Figuras podem ser usadas para definirem a aparência de nodos, arcos ou portas da camada de rede. Para isso, a figura mantém uma referência para seu proprietário, o objeto o qual representa. Figuras que representam nodos de um grafo devem ser da classe FigNode. FigNode é uma subclasse de FigGroup, que representa uma composição de figuras. Desta forma, um nodo pode ser representado por um conjunto de figuras. Figuras que representam arcos de um grafo devem ser da classe FigEdge. Qualquer figura pode representar uma porta. Na Figura 4.12 pode-se ver três nodos. Estes nodos são representados por composições de figuras: um quadrado com fundo branco, um círculo grande e pequenos círculos para portas.

5 ATIVIDADES E RESULTADOS

Este capítulo descreve a etapa de levantamento de requisitos e duas iterações, incluindo análise, projeto e implementação, que foram executadas. Os testes foram realizados juntamente com a implementação e não são documentados.

O levantamento de requisitos foi a primeira atividade. No Unified Process é feita uma etapa de levantamento de requisitos em cada iteração. No entanto, neste trabalho foi feito um levantamento extensivo inicial, o qual capturou a maior parte dos requisitos. À medida que a análise e projeto foram feitos, os requisitos foram sendo atualizados e estendidos.

O processo de desenvolvimento que adotamos é baseado no processo descrito no capítulo 3. É dirigido por casos de uso, pois cada um dos casos de uso elaborados no levantamento de requisitos é realizado primeiramente com artefatos de análise e, depois, com artefatos de projeto. É um processo iterativo e incremental, pois foram feitas iterações, cada uma sobre um conjunto de casos de uso. Cada iteração incrementa a funcionalidade do sistema.

A figura 5.1 mostra a seqüência ao longo do tempo das tarefas executadas. Como foi dito, os requisitos foram capturados inicialmente e modificados ao longo das iterações. Os testes não foram documentados aqui e foram executados juntamente com a implementação.

Figura 5.1 Seqüência de tarefas ao longo do tempo

O resultado final do levantamento de requisitos é apresentado na próxima seção. Na seção 5.1.5, é descrita a alocação dos casos de uso em cada iteração. Em seguida, as duas iterações são descritas. Na primeira iteração, uma descrição do que é análise e projeto é feita, juntamente com os resultados. Na segunda iteração, somente os resultados são apresentados.

Análise Projeto _{e testes}Impl. Requisitos

Análise Projeto _{e testes}Impl. 1ª Iteração

5.1 Levantamento de requisitos

O levantamento de requisitos é uma tarefa que define o que deve ser construído. Seu propósito é direcionar o desenvolvimento de um sistema correto. Isto se alcança com uma descrição dos requisitos do sistema de forma que seja suficiente para um acordo entre os clientes ou usuários e os desenvolvedores sobre o que o sistema deve ou não fazer. A linguagem do cliente ou usuário deve ser usada nesta descrição.

5.1.1 Contexto do sistema

Cada projeto de software é único e há diferentes pontos de partida para a captura de requisitos. O analista deve ser capaz de adaptar seu método de captura para cada situação. Neste trabalho optou-se por iniciar entendendo o contexto do sistema. Para isto foi escrito um texto (próxima seção) sobre a visão que o usuário tem do sistema final. Este texto apresenta simples descrições das funcionalidades que o usuário imagina que o sistema deve ter. Cabe ressaltar que os autores deste trabalho fazem tanto o papel de usuário como de analista.

5.1.1.1 Visão geral

No editor de UIDs trabalha-se com um projeto de UIDs, o qual consiste de várias áreas de edição destes UIDs e, opcionalmente, áreas de edição de diagramas de relacionamentos (DR).

O projeto de UIDs, com suas várias áreas de edição, é tratado como uma única entidade e apenas um projeto pode estar sendo editado no programa em um determinado momento. O projeto como um todo pode ser gravado como um arquivo único e posteriormente recuperado. O conteúdo individual de uma área de edição pode ser exportado para um arquivo de imagem. O projeto ainda pode ser impresso em folhas de papel.

Dentro das áreas de edição de UIDs, o usuário insere estados e transições entre estes estados. Dentro dos estados, informações de saída de sistema ou de entrada de usuário podem ser inseridas. Notas textuais e condições são inseridas fora de estados. À medida que UIDs estão sendo criados pelo usuário, o projeto mantém uma lista atualizada destes, que então podem ser adicionados ao DR. Pode-se criar relacionamentos e associações entre os UIDs no DR.

O editor deve ser flexível e possibilitar a modificação de qualquer das informações já inseridas. Os estados podem ser movimentados pela área de edição, sendo que as informações dentro do estado e as suas transições se movem de acordo. As informações podem ser modificadas e removidas.

5.1.1.2 Modelo do domínio

No Unified Process, o contexto do sistema pode ser expresso de uma forma mais usável como um modelo de domínio ou um modelo de negócio. Neste trabalho optou-se pelo modelo de domínio, pois o modelo de negócio é aplicável a sistemas que dão suporte a negócios de uma organização.

O modelo de domínio (figura 5.2) descreve conceitos importantes do contexto como objetos de domínio, que são interligados por associações e organizados em um diagrama de classes da UML. Os objetos de domínio representam as coisas ou eventos do ambiente que o sistema trabalha.

Este modelo de domínio apresenta de maneira simples os conceitos do diagrama de interação do usuário, que foram descritos em detalhe no capítulo 2.

O conceito de projeto é introduzido aqui como uma entidade que reúne vários diagramas. O diagrama de relacionamentos é parte do projeto e contém atores e relacionamentos. Neste diagrama pode-se editar as associações entre atores e UIDs, e os tipos de relacionamentos entre UIDs.

Os UIDs contém estados, transições entre os estados e anexos. Anexos são na forma de notas textuais, pré e pós-condições. Um estado contém uma coleção de informações trocadas, na forma de entradas de usuário e saídas de sistema.

Pode haver transições com origem em estados ou com origem em saídas de sistema. Uma transição pode ter origem em uma saída de sistema quando esta saída apresenta um conjunto de dados. Ou melhor, uma transição pode ter origem em várias saídas que apresentam conjuntos.

Figura 5.2 Modelo de domínio

As classes apresentadas no modelo acima são úteis na descrição dos casos de uso e servem como sugestão para classes internas desenvolvidas durante as atividades de análise.

5.1.2 Lista de funcionalidades

Durante o levantamento de requisitos, idéias do que o sistema poderia fazer foram anotadas e são apresentadas abaixo. Estas idéias são uma lista de funcionalidades ou requisitos candidatos, que é mantida atualizada durante todo o processo, como forma de planejamento de trabalho.

Esta lista representa todas as idéias que apareceram até o momento e como são em pequena quantidade, foram aprovadas e alocadas para as primeiras iterações do

processo. A classificação por prioridades serve para se decidir em quais iterações as funcionalidades serão implementadas.

5.1.2.1 Prioridade alta

• Edição dos UIDs com os seguintes componentes: item de dado, estrutura, conjunto, dado opcional, entrada do usuário, entrada do usuário enumerada, saída do sistema, texto, estado, estado inicial, sub-estados, chamada para outro UID, chamada a partir de outro UID, transição, pré-condição, pós-condição, notas textuais e parâmetros.

• Modificação do conteúdo dos componentes. • Renomeação e remoção de componentes.

• Movimentação individual ou em grupo de componentes em uma área de edição. • Edição de vários diagramas: ambiente com possibilidade de se editar vários

diagramas (UIDs) de um projeto ao mesmo tempo.

5.1.2.2 Prioridade média

• Edição do diagrama de relacionamentos. • Salvamento e recuperação dos diagramas.

• Exportação dos diagramas para arquivos de imagem.

• Desfazer/Refazer última ação: ações como inserção, renomeação e remoção podem ser desfeitas e refeitas.

5.1.2.3 Prioridade baixa

• Copiar, recortar e colar figuras.

• Redimensionamento do tamanho da imagem (zoom). • Impressão.

• Vizualização e configuração de impressão. • Localização de componentes por nome. • Formatação de fontes e espessura de linhas.

5.1.3 Requisitos funcionais

5.1.3.1 Lista de requisitos

Cada funcionalidade originou um ou mais requisitos funcionais descritos a seguir. Os requisitos funcionais são melhor capturados pelos casos de uso (seção 4.1.3.2.3), mas estes ficariam muito extensos e numerosos se capturassem todos os requisitos da sintaxe do UID. Assim, foi definida a lista de requisitos que serve de referência para a criação de alguns casos de uso. Esta lista também serve de referência para as atividades de projeto e implementação.

Esta lista de requisitos cobre tudo que o sistema deve fazer, obedecendo a sintaxe do UID, na forma de O sistema deve ... . São classificados em três categorias: edição de um UID, edição do diagrama de relacionamentos e ambiente de edição em geral.

5.1.3.1.1 Edição de um UID

R1.1 Em uma área de edição de UID, o sistema deverá possibilitar a inserção de estados em branco ou chamadas para outros UIDs.

R1.2 Em um estado, o sistema deverá possibilitar a inserção de estados em branco (sub-estado).

Em um estado, o sistema deverá possibilitar a inserção das seguintes saídas de sistema:

R1.3 item de dado, opcionalmente com seu domínio, podendo o domínio ser enumerado;

R1.4 estrutura, opcionalmente com a coleção de informações desta: itens de dado ou outras estruturas;

R1.5 conjunto de itens de dados ou de estruturas, juntamente com sua multiplicidade; R1.6 texto.

R1.7 O sistema deverá possibilitar a declaração das saídas de sistema item de dado , estrutura e conjunto como opcionais e/ou parametrizadas, tendo o usuário capacidade de enumerar os parâmetros.

R1.8 O sistema deverá possibilitar a declaração da saída de sistema texto como opcional.

Em um estado, o sistema deverá possibilitar a inserção das seguintes entradas de usuário, que podem ser declaradas como opcionais e/ou parametrizadas, tendo o usuário a capacidade de enumerar os parâmetros:

R1.9 item de dado, opcionalmente com seu domínio;

R1.10 estrutura, opcionalmente com a coleção de informações desta: itens de dado ou outras estruturas;

R1.11 conjunto de itens de dados ou de estruturas, juntamente com sua multiplicidade; R1.12 entrada enumerada, especificando a lista de opções e a quantidade que deve ser

selecionada.

R1.13 A partir de um estado, ou de um sub-estado, o sistema deverá possibilitar a criação de uma transição sem rótulo, ou com condição e/ou seleção de opção, sendo o destino um estado qualquer, que pode ser o de origem, ou uma chamada de outro UID.

R1.14 A partir de uma chamada de outro UID, o sistema deverá possibilitar a criação de uma transição sem rótulo, sendo o destino um estado qualquer.

R1.15 A partir de uma saída de sistema do tipo conjunto , o sistema deverá possibilitar a criação de uma transição sem rótulo, ou com seleção de N elementos e/ou seleção de opção e/ou com condição, sendo o destino um estado qualquer, um estado de origem, ou uma outra transição saindo de outro conjunto do mesmo estado.

R1.16 Em uma área de edição, o sistema deverá possibilitar a inserção de pré- condições, pós-condições e notas textuais.

R1.17 O sistema deverá possibilitar a renomeação do UID, assim como a renomeação dos componentes item de dado, estrutura e conjunto.

O sistema deverá possibilitar a modificação das seguintes informações dos componentes:

R1.18 nome do UID em uma chamada de UID; R1.19 domínio de um item de dado;

R1.20 conteúdo do domínio enumerado de um item de dado; R1.21 conteúdo da coleção de informações de um estrutura; R1.22 multiplicidade de um conjunto;

R1.23 se uma entrada de usuário ou saída de sistema é opcional e/ou parametrizada; R1.24 lista de parâmetros de um componente parametrizado;

R1.25 lista de opções de uma entrada de usuário enumerada;

R1.26 número de opções a serem selecionadas de uma entrada de usuário enumerada; R1.27 conteúdo de um componente de texto de um estado;

R1.28 se uma transição é explicitamente retornável ou explicitamente não retornável; R1.29 nome da opção, especificação da condição ou número de elementos a serem

selecionados em uma transição;

R1.30 conteúdo de uma pré-condição, pós-condição ou nota textual.

R1.31 O sistema deverá possibilitar a remoção dos componentes estado, saída de sistema, entrada de usuário, transição, pré-condição, pós-condição e nota textual.

R1.32 A movimentação de um estado na área de edição de um UID deverá acarretar na movimentação das transições e dos componentes contidos no estado, de forma a manter a configuração original do UID.

5.1.3.1.2 Edição dos diagramas de relacionamentos

Em uma área de edição de um DR, o sistema deverá possibilitar:

R2.1 a criação de um relacionamento de inclusão, extensão ou precedência entre dois UIDs;

R2.2 a modificação do tipo de um relacionamento existente; R2.3 a remoção de um relacionamento;

R2.4 a inserção de atores, juntamente com o seu nome; R2.5 a renomeação ou remoção de um ator;

R2.7 A partir de um UID, o sistema deverá possibilitar a criação de uma associação com um ator.

R2.8 A movimentação de um UID ou um ator na área de edição de um DR deverá acarretar na movimentação dos relacionamentos e associações conectados a estes, de forma a manter a configuração original do diagrama.

5.1.3.1.4 Ambiente de edição

No ambiente de edição, o sistema deverá possibilitar: R3.1 a edição de apenas um projeto (projeto aberto ); R3.2 a criação de um novo projeto de diagramas; R3.3 o carregamento de um projeto salvo em disco; R3.4 o fechamento de um projeto;

R3.5 o salvamento do projeto com seus diagramas nos formatos SVG e PGML.

Em um projeto, o sistema deverá possibilitar R3.5 a criação de um novo UID;

R3.6 a renomeação de um UID; R3.7 a remoção de um UID.

O sistema deverá:

R3.7 possibilitar o salvamento e recuperação de projetos a partir de arquivos;

R3.8 ser capaz de desfazer as últimas 20 ações, assim como refazer todas as ações desfeitas;

R3.9 ser capaz de exportar o conteúdo de uma área de edição para um arquivo de imagem;

R3.10 ser capaz de copiar, colar ou recortar notas textuais, pré-condições e pós- condições na área de edição de um UID ou entre áreas deste tipo;