O Enterprise Architect (EA) (SYSTEMS, 2013) ´e uma ferramenta visual para a modelagem e design de sistemas baseada no UML. Foi desenvolvida pela Sparx Systems e ´e amplamente utilizada na ind´ustria, n˜ao s´o para modelar e arquitetar sistemas, mas tamb´em para controlar e documentar em todas as etapas do ciclo de vida de desenvolvimento. Inicialmente, foi lan¸cada como uma ferramenta de modelagem UML para a vers˜ao UML 1.1, mas o produto evoluiu para incluir outras vers˜oes da UML (1.3, 2.0, 2.1, 2.3 e 2.4.1) e modelos avan¸cados de arquitetura que podem ser utilizados pra o DDM. O EA foi considerado uma ferramenta extremamente robusta e customiz´avel, que possibilita atribuir novos templates, profiles e componentes.
Sabendo que a ferramenta EA exporta XMI para diferentes vers˜oes, e que o WCT j´a possui boas experiˆencias com o XMI, optou-se por realizar alguns testes com esta ferramenta e foi constatado que ela poderia atender as principais necessidades do presente trabalho.
Antes da op¸c˜ao pela utiliza¸c˜ao do EA outros dois sistemas foram testados o Astah(ASTAH, 2013) e o Artisan Studio(ATEGO, 2013). Am- bos os softwares s˜ao bem conceituados para a modelagem de sistemas, mas apresentaram algumas restri¸c˜oes que inviabilizaram sua utiliza¸c˜ao no trabalho:
• O Astah ´e um sistema bem simples e intuitivo para utiliza¸c˜ao de UML b´asico. O XMI gerado a partir dos modelos ´e bem limpo e de f´acil compreens˜ao. Por´em, a associa¸c˜ao de tags aos estere´otipos ´e complexa, e s´o ´e poss´ıvel atrav´es de arquivos de configura¸c˜ao criados fora do sistema. Ainda assim, n˜ao ´e poss´ıvel criar um profile padr˜ao, ou seja, o projetista ´e obrigado a escrever o nome dos estere´otipos exatamente igual ao que foi definido no arquivo para que o sistema reconhe¸ca. Al´em disso, at´e onde foi consta- tado, o Astah n˜ao suporta estere´otipos nos relacionamentos dos diagramas de classes.
• Por sua vez, a Artisan Studio ´e um ferramenta robusta com uma excelente gama de funcionalidades, especialmente se tratando de modelagem para sistemas embarcados e em tempo real. Esta ferramenta possui um m´odulo pr´oprio para gerar c´odigo-fonte a partir do desenvolvimento dirigido a modelos, quando os mode- los est˜ao em UML e SysML. Obviamente, que a transforma¸c˜ao n˜ao atinge o ponto de aplica¸c˜ao, mas serve como aux´ılio para o desenvolvimento. Apesar de todos os benef´ıcios apresentados pela ferramenta, a mesma apresentou alguns problemas durante a gera¸c˜ao do XMI. Nas vers˜oes mais novas (foi utilizada a vers˜ao 7.4), o XMI foi atualizado para a vers˜ao 2.1. Segundo a Atego, nesta nova especifica¸c˜ao h´a muitas interpreta¸c˜oes diferentes do padr˜ao XMI antigo que resulta em uma limita¸c˜ao entre as trans- forma¸c˜oes do mesmo. Como a ferramenta n˜ao disp˜oe da op¸c˜ao de gerar XMI em diferentes vers˜oes, e o XMI gerado visa uma interpreta¸c˜ao utilizada praticamente para o Artisan Studio, h´a dificuldade em adaptar o WCT para importar o XMI do Arti- san. Al´em disso, a exporta¸c˜ao de um XMI ´e extremamente lenta (em torno de algumas horas) e acrescenta ao arquivo apenas o diagrama de sequˆencia.
4.3 LABVIEW
O LabVIEW (INSTRUMENTS, 2013) ´e uma plataforma de pro- grama¸c˜ao gr´afica desenvolvida pela National Instruments. Ela serve como um ambiente de programa¸c˜ao muito usado por engenheiros e ci- entistas para desenvolver sistemas de medida, teste e controle tanto para sistemas de pequeno quanto grande porte. Utiliza uma linguagem de programa¸c˜ao orientada a componentes, sendo que cada componente representa uma funcionalidade previamente desenvolvida, que oferece ao projetista dados de entrada e sa´ıda de acordo com a fun¸c˜ao que ser´a processada. Essas funcionalidades podem ser unidas atrav´es de liga¸c˜oes para formarem um sistema final.
Esta ferramenta foi utilizada devido `a facilidade para integrar hardware e software com seus componentes dispon´ıveis. Com eles, desenvolveu-se um terminal gr´afico para se comunicar com dispositi- vos externos utilizando o SO Windows. Desta forma, foi poss´ıvel gerar logs de leitura dos dados recebidos pelo nodo Sink de forma que ele se integrasse facilmente ao restante do framework.
Inicialmente, foram realizados testes com outros softwares como o Hyperterminal(HILGRAEVE, 2013) e o TeraTerm(TECNOLOGIES, 2013) por´em, apesar do TeraTerm se aproximar do que era necess´ario, n˜ao foram obtidos os resultados esperados, pois a integra¸c˜ao com outros sistemas era complexa e o log gerado era pouco customiz´avel. Sendo as- sim, optou-se por desenvolver um novo terminal que atendesse a todos os requisitos.
4.4 HEROKU
Heroku (HEROKU, 2013) ´e uma plataforma de aplica¸c˜oes nas nuvens (cloud computing ) que reconhece diversas linguagens de pro- grama¸c˜ao. Esta plataforma foi fundada em 2007 por Henry Orion, James Lindenbaum e Adam Wiggins, com o objetivo de criar um PaaS (Platform as a Service) para fazer de forma simples a implementa¸c˜ao, o gerenciamento e o escalonamento de aplica¸c˜oes web de pr´oxima gera¸c˜ao. A principal ideia ´e ausentar a preocupa¸c˜ao dos desenvolvedores com problemas relacionados a servidores, possibilitando a escolha da linguagem do sistema. Em 2007, apenas a linguagem de programa¸c˜ao Ruby era reconhecida, mas, desde ent˜ao, foi acrescentado suporte para Node.js, Java, Python, Clojure e Scala. Al´em disso, possui alguns re- cursos extras como bancos de dados SQL e NoSQL, Memcached, entre
outros, e h´a seu pr´oprio controlador de vers˜oes GIT que roda na infra- estrutura Heroku.
Decidiu-se utilizar o Heroku para manter um WebService de in- tegra¸c˜ao entre a esta¸c˜ao de recebimento de dados (esta¸c˜ao de controle) e o aplicativo do usu´ario final. Apesar de ser poss´ıvel a utiliza¸c˜ao de qualquer linguagem para a implementa¸c˜ao do WebService, optou-se por utilizar a linguagem Scala como forma de demonstrar que a integra¸c˜ao dos componentes utilizados neste estudo s˜ao independentes de lingua- gem.
Visto que os requisitos para esta etapa do projeto eram apenas interligar os sistemas e manter os dados coletados, sendo que eles n˜ao seriam modificados durante o processo, e tendo em mente que o Heroku possui integra¸c˜ao com banco de dados (BD) NoSQL (CATTELL, 2011), concluiu-se que a ferramenta atende precisamente as necessidades em quest˜ao, sendo elas:
• Conex˜ao simples com o BD. • Simples manipula¸c˜ao dos dados.
• Capacidade de se replicar e distribuir dados para in´umeros dis- positivos conectados ao BD.
• Utiliza¸c˜ao eficiente dos recursos como mem´oria RAM, HD, entre outros. Pois os recursos dos dispositivos que fazem o acesso ao BD podem ser limitados.
• Capacidade de adicionar dinamicamente novos atributos para re- gistros de dados.
• Desnecessidade de diferentes liga¸c˜oes e restri¸c˜oes de relaciona- mentos, como ´e o caso dos bancos de dados relacionais.
4.5 MONGODB
Entre os bancos citados pelo Heroku, elegeu-se o MongoDB de- vido suas caracter´ısticas de aceitar alto volume de dados, de baixo valor, muito utilizado para armazenamento de contagem e logs, por exemplo. Este banco de dados foi utilizado para manter as informa¸c˜oes de consulta realizada pelos dispositivos externos de an´alise propostos neste trabalho.
O MongoDB ´e um banco de dados orientado a documentos de- senvolvido em C++ pela empresa 10gen Inc, que disponibiliza o projeto
como c´odigo aberto. De acordo com seus desenvolvedores, o objetivo principal do MongoDB ´e fechar a lacuna entre o armazenamento r´apido e escalon´avel de chaves e valores com os tradicionais sistemas de geren- ciamento de banco de dados relacional RDBMSs (Relational DataBase Management Systems).
As Bases de dados MongoDB residem num servidor MongoDB. Este servidor pode conter uma ou mais bases, sendo elas independentes e armazenadas separadamente pelo servidor MongoDB. Cada base de dados cont´em um ou mais conjuntos que s˜ao compostos por documen- tos.
Os documentos no MongoDB s˜ao persistidos por um formato chamado BSON, que ´e uma serializa¸c˜ao codificada em bin´ario de do- cumentos JSON (JSON, 2013). Esta persistˆencia ´e feita por raz˜oes de eficiˆencia j´a que o BSON ´e projetado para ser mais leve que o JSON. Para realizar o estudo, os dados est˜ao sendo manipulados em formato JSON devido `a simplicidade que ele oferece.