Nesta seção descreve-se como o particionamento realizado anteriormente foi revisto até que o particionamento possa fornecer a base necessária sobre a qual os requisitos possam ser implementados satisfatoriamente. Assim como na etapa de Particionamento de Hardware e Software, o refinamento relacionado ao software foi maior e mais complexo que o de hardware.
Também vale salientar que essa etapa de refinamento é a primeira do grupo de etapas iterativas do fluxo de projeto adotado. Portanto, os refinamentos aqui descritos não aconteceram todos de uma vez, mas sim durante várias iterações de refinamento, projeto e integração. Uma das lições dessa abordagem iterativa é a de que muitos dos refinamentos só puderam ocorrer devido a dificuldades enfrentadas na etapa de integração.
3.4.1 Refinamento do Particionamento do Hardware
O hardware em questão, o Arduino utilizado no desenvolvimento do Atomik, sofreu modificações ao longo das etapas de refinamento. O primeiro obstáculo enfrentado ao utilizar o Arduino Uno para animações na interface gráfica. A baixa memória do Arduino Uno (2K de memória SRAM) não comportava múltiplos elementos sendo animados simultaneamente na interface. Apesar do objetivo ser o desenvolvimento de uma ferramenta para dispositivos de baixo custo, estava claro que o custo não traria a experiência esperada de uma interface animada.
Outro obstáculo surgiu em função da necessidade de inputs analógicos para interação com a interface. Durante o desenvolvimento, botões foram acrescentados para uma interação mais direcionada na interface da plataforma. Entretanto, o display se sobrepunha ao Arduino Uno ocupando todos os pinos necessários à inserção dos fios que
conectariam os botões a uma protoboard (uma placa utilizada para inserção de componentes externos à placa do Arduino).
Ainda que a adoção de uma placa significasse um aumento de preço, essa adoção era necessária para manter o nível de qualidade esperado da ferramenta. Quando consultado, o aumento de preço não era tão significativo. Segundo o site oficial do Arduino, enquanto um Arduino Uno custa vinte e dois dólares, o Arduino Mega custa trinta e oito dólares. O Arduino Mega, então, foi adotado como plataforma principal no projeto do Atomik em detrimento do Arduino Uno, trazendo mais memória e mais pinos disponíveis para os botões.
3.4.2 Refinamento do Particionamento do Software
A primeira etapa de refinamento do software se deu através da criação de componentes que seriam os elementos base para a construção de qualquer interface gráfica utilizando o Atomik. Então, o Block foi criado como componente elementar da interface gráfica. Estilos e animação de um
Block governam como a interface é construída. Essa entidade foi criada com
a intenção de manter elementos numa mesma unidade, deixando o código e a interface mais coesos. Apesar disso, um problema surge quando muitos Blocks precisam ser gerenciados simultaneamente. Mais precisamente, existe uma grande repetição de código e instruções onde apenas alguns dados são modificados.
A repetição de instruções mostra que esses dados modificados passam por uma parametrização, que pode ficar a cargo de uma entidade ancestral que manipula vários Blocks. Por esse motivo, o Container foi concebido como entidade gerenciadora de múltiplos Blocks. Um Container herda diretamente de um Block e possui os mesmos atributos, com a diferença de ser projetado para abarcar diversos Containers. Parâmetros de renderização de um
Container definem como esses Containers filhos serão inseridos e estilizados
Inicialmente, o Block possuía estilizações de largura, altura e posição diretamente através de atributos da classe. Contudo, isso impedia o reuso e ia de encontro às diretrizes definidas na etapa de Especificação sobre o reuso do estilo. Outro agravante era que um Container, por herdar de Block, não conseguiu solucionar as repetições de código nesse âmbito, já que o mesmo acontecia quando havia muitos Containers. Para lidar com tal dificuldade, foi criada uma classe Style cujas instâncias poderiam ser compartilhadas através de diferentes elementos, efetivamente resolvendo o problema da reutilização dos estilos.
As animações da interface gráfica foram o aspecto mais refinado do software. Devido à sua complexidade, a camada de abstração das animações não poderia fornecer animações sofisticadas. O hardware não suporta o processamento de qualquer animação, como animações 3D. Os refinamentos foram realizados em diversas frentes de animações, desde a quantidade de animações disponíveis até o método de implementação dessas animações.
A quantidade e a complexidade foi a primeira parte das animações a ser refinada. Animações em interfaces gráficas podem variar substancialmente dependendo do hardware ou software onde são executadas e o propósito ao qual servem. No caso desse projeto, o hardware é de baixo poder de processamento, logo as animações não podem ser muito sofisticadas ou envolver distorções gráficas como um zoom ou fade. Nesse contexto, as animações a serem fornecidas pelo Atomik para Blocks foram da seguinte forma:
● TranslateY: define um procedimento de animação para a translação vertical de um elemento indo de um ponto inicial Y0 até um ponto final Y1. Tem como entrada um inteiro DY que servirá para o cálculo da posição final do elemento de modo que Y1 = DY + Y0;
● TranslateX: define um procedimento de animação para a translação horizontal de um elemento de uma posição inicial X0 até uma posição
final X1. Aceita como entrada um inteiro DX que servirá para o cálculo da posição final do elemento de modo que X1 = DX + X0;
● ExpandWidth/ExpandHeight: expande de modo animado uma dimensão do elemento (largura ou altura). Recebe como entrada um valor a ser adicionado à dimensão modificada;
Um Container, por ser uma classe derivada de Block, possui as mesmas animações da sua classe ancestral. No entanto, também possui métodos referentes à manipulação de listas de elementos que devem ser animados simultaneamente. Por exemplo, a animação de translação, quando executada por um container, repassa essa animação, assim como seus parâmetros, aos seus containers filhos. Desta forma, um grupo de elementos é animado por uma única instrução.
Todavia, depois de algumas etapas de projeto e integração, as animações em múltiplos elementos voltaram a rodar de modo travado: os elementos não se moviam em grupo e sincronizadamente quando acionados. Esse comportamento estava aparentemente solucionado quando uma placa de maior processamento foi adotada para o desenvolvimento. Apesar disso, após uma investigação mais meticulosa, descobriu-se que o algoritmo utilizado para processar e renderizar as animações impedia, por definição, que os elementos fossem animados simultaneamente.
Ou seja, a dificuldade enfrentada não era um problema de hardware, mas de software. A solução adotada para atacar tal obstáculo foi criar estados para os Blocks e associar animações a esses estados. Dessa forma, as animações eram executadas através da consulta do estado de um elemento. A cada consulta, a propriedade do elemento era incrementada.
Por último, várias classes foram refinadas através da remoção das suas especificidades para que possam ser utilizadas e forneçam a flexibilidade necessária ao programador na criação de uma GUI. Durante o desenvolvimento, várias classes possuíam código que não iriam para a
versão final do Atomik, mas estavam ali apenas para testes e criação de recursos. À medida que essas especificidades foram sendo removidas do código, às vezes surgiam novas classes que poderiam ser úteis ao programador que utilizasse a ferramenta. Uma dessas classes foi a classe
Screen, que surgiu a partir das remoções de código específico da classe
correspondente à tela onde os Containers e Blocks estavam sendo desenvolvidos.
A classe Screen passou a ser um recurso que representa uma tela da aplicação e administra a entrada de usuário e funcionamento interativo de mais alto nível, como toque de tela e transições entre diferentes telas. Também possui estados que correspondem ao momento atual da tela como um todo. As animações na classe Screen são apenas de transições entre telas. Essas animações são um conjunto de animações em grupo de
Containers nessa tela. A seção 3.5.3 descreve com mais detalhes o
relacionamento entre as três classes Block, Container e Screen através da modelagem.