Aplicac¸˜ao do Model View Controller

Um dos padr˜oes de desenho mais utilizados no desenvolvimento de software ´e o Model View Controller (MVC)[Fow06]. Este padr˜ao separa conceptualmente uma aplicac¸˜ao em trˆes m´odulos fundamentais: modelo, vista e controlador. O modelo cont´em a definic¸˜ao dos objetos que representam as entidades no mundo real. Na nossa aplicac¸˜ao, os con- troladores (hardware) ou os jardins, s˜ao exemplos de objetos que constituem o mo-

delo. A definic¸˜ao dos objetos do modelo deve ser independente da forma como estes s˜ao apresentados numa determinada interface. Assim, compete ao m´odulo vista tratar desta apresentac¸˜ao que pode ser atrav´es de uma interface gr´afica Web, uma aplicac¸˜ao Desk- top, aplicac¸˜ao m´ovel, etc. Finalmente, o m´odulo controlador ´e respons´avel pela l´ogica do neg´ocio, ou seja, para uma determinada operac¸˜ao, procura a informac¸˜ao nos objetos do modelo necess´arios e faz as transformac¸˜oes necess´arias. Os resultados s˜ao passados `a vista e devidamente apresentados. Uma separac¸˜ao de m´odulos idˆentica est´a bem presente na numa aplicac¸˜ao JavaEE como explicamos nas pr´oximas secc¸˜oes.

4.2

Camada de Neg´ocio

A camada de neg´ocio da plataforma de gest˜ao est´a concentrada no m´odulo EJB. Numa aplicac¸˜ao JavaEE, esta camada encaixa-se no m´odulo controlador do padr˜ao MVC. Cont´em todo o c´odigo respons´avel pela l´ogica do neg´ocio e serve de suporte a outras camadas, como por exemplo, a camada Web. O m´odulo EJB do JavaEE acrescenta o conceito de Enterprise Java Beans (EJBs) que s˜ao objetos com propriedades especiais e cujo ci- clo de vida ´e gerido automaticamente. Entre estas propriedades destacamos a capaci- dade de invocac¸˜ao de m´etodos remotamente (designada de Remote Method Invocation (RMI)), a disponibilizac¸˜ao de servic¸os na Web e a utilizac¸˜ao de recursos de um sistema de informac¸˜ao empresarial (Enterprise Information System (EIS)), como por exemplo, o acesso a uma base de dados relacional.

O dom´ınio da nossa plataforma cont´em objetos chave com responsabilidades bem dis- tintas seguindo os padr˜oes de desenho de software que melhor se adequam aos requisitos do sistema [Lar01] e que ser˜ao descritos mais `a frente. Para al´em da utilizac¸˜ao dos ob- jetos EJB referidos, s˜ao utilizados tamb´em objetos Plain Old Java Object (POJO) cujo ciclo de vida ´e da responsabilidade do programador. A figura 4.1 pretende ilustrar os intervenientes principais da camada de neg´ocio, e a forma como estes se relacionam entre si, atrav´es de uma vis˜ao de alto n´ıvel. Na figura ´e poss´ıvel ver tamb´em o papel de cada interveniente na aplicac¸˜ao. De seguida fazemos uma descric¸˜ao detalhada para cada um destes intervenientes.

4.2.1

Entidades

De acordo com o modelo de dom´ınio descrito na secc¸˜ao 3.1 existem entidades que repre- sentam os principais intervenientes no sistema SRI. Estas entidades guardam a informac¸˜ao espec´ıfica de cada interveniente, exp˜oem as suas operac¸˜oes e mapeiam as interligac¸˜oes entre intervenientes. As entidades s˜ao objetos POJO e constituem o m´odulo modelo do padr˜ao MVC. Cada classe de entidade implementa uma interface como se pode ver o exemplo para a entidade “Jardim” na figura 4.2. As setas a tracejado simbolizam a in- terface de uma determinada classe. As outras setas representam ligac¸˜oes entre entidades

Cap´ıtulo 4. Desenho e implementac¸˜ao 29

Figura 4.1: Camada de neg´ocio - conceitos principais

relacionadas com os seus atributos (e.g., o jardim tem um atributo que ´e uma lista de controladores).

Algumas entidades tˆem uma correspondˆencia direta com o modelo de dom´ınio, como ´e o caso das entidades “Jardim”, “Controlador”, “Plano de rega”, “Tarefa”, “Tipo de rega” e “Estac¸˜ao de rega”. A entidade “Controlador” ´e aquela que tem mais ligac¸˜oes com outras entidades. Estas entidades e as suas relac¸˜oes s˜ao vis´ıveis nas figuras 4.3 e 4.4. Outras entidades foram adicionadas de forma a enriquecer o modelo de neg´ocio e que descrevemos brevemente em baixo e na figura 4.5:

• “ClientRequest”: cont´em informac¸˜ao sobre um pedido efetuado na plataforma de gest˜ao e que deve ser convertido e enviado para o controlador. Exemplos de pedidos s˜ao “atualizar o plano de rega”, “obter informac¸˜ao dos sensores de rega”, “obter o estado da bateria”, etc. Um pedido ´e sempre identificado por um c´odigo ´unico que

Figura 4.2: Diagrama de classes - exemplo de entidade e sua interface ´e conhecido tanto pela plataforma central como pelo controlador;

• “LogEntry”: esta entidade auxilia na criac¸˜ao de registos com todas as leituras feitas para cada controlador. Sempre que ´e iniciada uma nova ligac¸˜ao ´e criado um novo registo. Cada registo ´e constitu´ıdo por v´arias leituras. ´E grac¸as a estes registos que ser´a poss´ıvel ter um hist´orico para cada controlador;

• “LogReading”: representa uma leitura de um sensor espec´ıfico de um controlador. Cada leitura tem por isso uma associac¸˜ao com um plugin (sensor) espec´ıfico; • “LogWriting”: permite guardar informac¸˜oes relacionadas com os pedidos envia-

dos para o controlador em cada comunicac¸˜ao. Cada instˆancia desta entidade ter´a informac¸˜oes tais como “todos os pedidos enviados para o controlador foram recebi- dos e executados com sucesso”, “data e durac¸˜ao da comunicac¸˜ao e de cada pedido especificamente”, etc;

• “Plugin”: esta entidade ´e a representac¸˜ao l´ogica de um disposito capaz de ler valores quando ligado a um controlador. Tipicamente, um plugin ser´a um sensor relacio-

Cap´ıtulo 4. Desenho e implementac¸˜ao 31

Figura 4.3: Diagrama de classes - entidades (I)

nado com a rega. A ideia de plugin pretende oferecer flexibidade no crescimento do sistema. Uma entidade para cada sensor espec´ıfico seria mais limitativo se qui- sermos que o utilizador possa adicionar e remover sensores ao longo do tempo. As entidades est˜ao na base do modelo de neg´ocio o qual est´a organizado em func¸˜ao destas. Como veremos nas pr´oximas secc¸˜oes, todos os intervenientes est˜ao ligados direta ou indiretamente com as v´arias entidades.

Figura 4.4: Diagrama de classes - entidades (II)