3. APRESENTAÇÃO DO MOBILE FITTING ROOM
3.6 A RQUITETURA DE S OFTWARE
3.6.1 Padrões de Desenho de Software
A Figura 22, representa uma vista simplificada da arquitetura interna da aplicação MFR. Como se pode identificar nesta figura, o padrão de desenho de software utilizado para servir como base da arquitetura da aplicação é o Model View Controller (MVC).
Os padrões de desenho de software descrevem soluções genéricas reutilizáveis para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos (Martin, 2000).
O componente Model representa objetos que são responsáveis pela gestão das estruturas de dados em memória do domínio da aplicação, por exemplo, as estruturas de dados que representam os
artigos de têxtil ou os estados do Espelho do MFR. Estes dados podem inicialmente estar localizados na Internet mas, posteriormente serão armazenados na memória interna do próprio dispositivo.
A componente View representa todos os controlos e vistas de interface da aplicação, tendo estes a responsabilidade de servir de interface da aplicação e interagir diretamente com o utilizador.
O componente Controller é composto pelos objetos que informam os componentes Model e
View para reagirem de acordo com o estado da aplicação, lógica de negócio ou input proveniente da
interação com o utilizador.
A implementação deste padrão permite a separação entre a GUI da aplicação e a lógica de negócio, isto é, torna possível o desenvolvimento da GUI da aplicação independente do desenvolvimento da lógica de negócio e dos dados. Devido à complexidade da lógica de negócio e dependências entre funcionalidades, o componente Controller está dividido em dois subcomponentes: o UIController e o ModelController. O UIController representa os componentes que são responsáveis por atualizar as Views da aplicação, podendo se abstrair das alterações a serem efectuadas no Model. O ModelController abrange todos os componentes necessários para a lógica de negócio da aplicação e responsáveis por atualizar os componentes Model.
Foram utilizados os seguintes padrões de criação: Singleton e Builder.
O padrão Singleton foi utilizado com o objetivo de apenas haver uma instância de determinados tipos de objetos, por exemplo, no MFR, foi criado um objecto com o objectivo de gerir todos os downloads a serem ou para serem efectuados pela aplicação e, que onde só deverá existir uma instância deste tipo.
O Builder foi utilizado para simplificar a forma como os objetos que representam, por exemplo, artigos do catálogo da La Redoute, são construídos. Como a informação de diversos objetos, por exemplo os artigos, provém de diversas fontes remotas em diversos formatos, esses objetos são construídos por parsers que assumem o papel de Builders e a ordem de construção é dada pelos
Managers do contexto do objeto, por exemplo, o objeto com a função de gestor dos artigos.
Como padrões estruturais foram utilizados os seguintes padrões de desenho: Facade e Adapter. O padrão Facade, no caso do MFR, permite unificar através de uma só todas as funcionalidades disponíveis à aplicação provenientes dos serviços externos relacionados com a La Redoute. Desta forma, sempre que for necessário efetuar algum pedido ou realizar alguma operação relacionada com o catálogo da la Redoute ou com o Carrinho de Compras, acede-se apenas à Facade.
O padrão Adapter descreve a forma como uma interface pode ser convertida noutra interface na qual o cliente espera. Neste caso, permite tratar objetos diferentes, por exemplo, o catálogo e as categorias dos artigos como iguais, objetos que contêm produtos.
Padrões de desenho de software comportamentais: Null Object, Observer e Iterator.
O padrão Null Object também foi implementado durante o desenvolvimento do MFR e, permitiu que determinado tipo de objetos tenha uma representação default.
objetos, em que quando o estado de um objecto muda, todas as suas dependências são notificadas. No MFR este padrão foi utilizado, por exemplo, nos objetos que representam os downloads que podem ter até três dependências diferentes para notificar consoante o seu estado. O Gestor de Downloads e o Objecto que irá representar os dados obtidos pelo download são duas dependências obrigatórias na qual serão sempre notificados. Ainda existe uma outra dependência que é opcional, que representa um componente de interface que poderá ter comportamentos específicos consoante o estado do download.
O padrão de software Iterator está implementado implicitamente sempre que se acede de forma sequencial a uma coleção de objectos.
Para além dos padrões de desenho referidos acima, também existiram outros padrões com igual importância que foram implementados no MFR.
O padrão de desenho de software Delegation também tem um papel importante no desenvolvimento do MFR, pois este permite que um objecto (delegator) em vez de realizar alguma das suas tarefas originadas por eventos de estado, delega essa tarefa para outro objecto (delegate) associado.
3.7 Conclusão
Neste capítulo pode se concluir que o MFR é uma aplicação completamente nova e independente do protótipo que a originou, o VFR. Em relação ao VFR, o MFR é uma aplicação mais completa, isto é, disponibiliza um maior número de funcionalidades e, para além disso, também permite ao utilizador utilizar um maior número de gestos standard para interagir com a mesma.
Concui-se que um dos maiores objectivos e desafios com o desenvolvimento do MFR, é que resulte uma aplicação com uma interface intuitiva, fácil de navegar, e ainda, que ofereça ao utilizador a melhor experiência de utilização possível. A implementação de todas as funcionalidades requeridas também é um objectivo de maior importância.