Metodologia

A implementac~ao do CMF foi realizada seguindo duas abordagens:  Bottom-Up

Algumas aplicac~oes foram desenvolvidas nas plataformas apresentadas no Captulo 2. A partir do desenvolvimento destas aplicac~oes, torna-se possvel conhecer cada uma das plataformas e como ocorre a interac~ao entre a plataforma e a aplicac~ao. Alem disto, podemos identicar as semelhancas e diferencas entre elas.

 Top-Down

E formulada uma vis~ao global do Framework sem detalhamento de seus componen- tes internos. Esta macro-arquitetura e ent~ao detalhada para cada componente do Framework , ate atingir um nvel de detalhe que valide o modelo e seja possvel sua implementac~ao.

A utilizac~ao das duas abordagens em conjunto tem como principal objetivo gerar um equilbrio que evita os problemas inerentes a cada uma delas. A abordagem bottom- up evita que seja construdo um framework generico demais (problema causado pela

3.2 metodologia 27 utilizac~ao da abordagem top-down). Enquanto a abordagem top-down evita que o fra- mework termine por car bastante especializado no tipo de aplicac~ao que e utilizado na sua construc~ao (problema inerente a abordagem bottom-up).

Considerando estas duas abordagens, foi tracado um plano de desenvolvimento para a construc~ao do CMF. O escopo denido neste plano contempla o desenvolvimento de aplicac~oes nas cinco plataformas apresentadas anteriormente: Symbian, BREW, J2ME, Windows Mobile e Embedded Linux. Estas aplicac~oes foram desenvolvidas de acordo com a demanda de clientes do C.E.S.A.R.

Na plataforma Symbian, foram implementados dois jogos. Para BREW, foram im- plementadas uma aplicac~ao de sincronizac~ao de informac~oes pessoais e um cliente do VNC (Virtual Network Computing), esta ultima sendo portada para Embedded Linux. Para Windows Mobile, desenvolvemos uma aplicac~ao de captura e identicac~ao de audio. Por m, em J2ME, foram desenvolvidas aplicac~oes de compartilhamento de imagens e execuc~ao de apresentac~oes tipo slide-show.

O objetivo principal da execuc~ao deste plano foi entender o funcionamento de cada uma das plataformas, conhecer as formas1 _{e ambientes de desenvolvimento e tentar iden-}

ticar os pontos em comum entre elas.

De acordo com esta experi^encia de desenvolvimento de aplicac~oes nas varias platafor- mas, foram denidos quais os criterios relevantes para a escolha das plataformas iniciais do Framework. As plataformas foram ent~ao ordenadas dentro de cada criterio e, dentro desta ordem, receberam pontos de acordo com a sua relev^ancia e suas caractersticas.

Este processo de decis~ao formal ira indicar as plataformas com maior pontuac~ao dentro dos critarios denidos. A partir desta indicac~ao, ser~ao denidas quais as duas plataformas que ir~ao formar o escopo inicial de implementac~ao do CMF.

Abaixo listaremos os criterios denidos, junto com a explanac~ao da sua import^ancia e a escala de pontuac~ao de cada um. A adoc~ao de um peso em cada criterio visa denir a import^ancia do criterio em relac~ao aos outros.

 Numero de dispositivos

Devem ser priorizadas as plataformas com o maior numero de dispositivos no mer- cado, para que o CMF tenha a maior abrang^encia possvel. Este criterio sera pontuado em escala de 1 a 5 com peso 2.

 Facilidade de desenvolvimento

As plataformas com uma maior facilidade de desenvolvimento de aplicac~oes devem ser priorizadas, pois tendem a ser mais adotadas pelos desenvolvedores. Este criterio sera pontuado em escala de 1 a 5 com peso 1.

 Linguagem de programac~ao C/C++

A linguagem de programac~ao das plataformas devera ser igual, na vers~ao inicial do Framework. Isto reduz esforco e riscos com a realizac~ao de transformac~ao automatica entre linguagens (que n~ao esta no escopo deste trabalho). Devido a 1_{Entende-se por formas de desenvolvimento as linguagens de programac~ao e API's utilizadas, meca-}

3.2 metodologia 28 exist^encia de apenas uma plataforma que utilize linguagem Java, a linguagem de programac~ao do CMF sera inicialmente C ou C++. Portanto, este criterio sera pontuado da seguinte forma: 5 - para plataformas com suporte a linguagem C ou C++; 0 - para as outras. Este criterio tem peso 1.

 Portabilidade

A plataforma deve prover compatibilidade com vers~oes anteriores, alem de mecanis- mos para reduzir o esforco de porting de aplicac~oes entre dispositivos com interface (tela e teclado) diferente. Isto e necessario para que o CMF possa evoluir junto com a plataforma alvo2 _{e seja compatvel entre os dispositivos da mesma plataforma,}

sem a necessidade de reescrita do Framework a cada evoluc~ao da vers~ao da plata- froma escolhida ou a cada novo dispositivo suportado. Este criterio possui grande import^ancia e sera pontuado em escala de 1 a 5, com peso 3.

 Desempenho

As plataformas devem ser priorizadas de acordo com seu desempenho. O desempe- nho inclui n~ao somente numero de instruc~oes por segundo, mas tambem a quanti- dade de memoria disponvel e o tamanho maximo permitido para uma aplicac~ao. Isto permite uma maior exibilidade no desenvolvimento de aplicac~oes para a pla- taforma. Este criterio sera pontuado de 1 a 5 com peso 2.

 Acesso aos recursos do hardware

A quantidade de recursos do hardware que podem ser acessados pela plataforma dene a ordem de prioridade deste criterio. Este criterio dene a abrang^encia inicial do Framework . Como o CMF sera desenvolvido para varias plataformas, o conjunto de recursos suportados pelo Framework devera ser o denominador comum entre as plataformas alvo. Este criterio sera pontuado de 1 a 5 com peso 2.

A Tabela 3.1 mostra o enquadramento das plataformas de desenvolvimento em cada um dos criterios citados acima. Este enquadramento foi obtido atraves da implementac~ao das aplicac~oes conforme o plano de desenvolvimento do CMF e do estudo inicial de desenvolvimento de aplicac~oes para cada uma das plataformas abordadas conforme visto no Captulo 2.

As pontuac~oes de cada plataforma nos criterios estabelecidos foram somadas e este resultado pode ser visto na Tabela 3.2. A partir deste resultado, pode-se perceber que Symbian foi apontada como a plataforma mais indicada.

No entanto, a partir da experi^encia de desenvolvimento de aplicac~oes nesta plataforma, foi possvel perceber que Symbian possui diversos pontos de diverg^encia entre as outras plataformas. Os dois principais pontos s~ao:

 Padr~ao Two Phase Constructor[Sym02]

O desenvolvimento de aplicac~oes em Symbian segue o padr~ao Two Phase Cons- tructor. De acordo com este padr~ao, a alocac~ao din^amica de memoria n~ao deve 2_{Entende-se por plataforma alvo cada uma das plataformas de desenvolvimento de aplicac~oes para}

3.2 metodologia 29

Criterios Prioridade das plataformas

(Pontuac~ao) 5 4 3 2 1 Numero de dispositivos Facilidade de desenvolvimento Linguagem de programac~ao C e C++ Portabilidade Desempenho

Acesso aos recursos do hardware

Tabela 3.1. Criterios para escolha das plataformas

ser realizada dentro dos contrutores dos objetos. Em vez disto, deve-se ter um metodo estatico new que e responsavel por construir o objeto em duas fases: alocar memoria para o objeto propriamente dito, chamando o seu construtor e colocando este objeto dentro de uma estrutura de gerenciamento de memoria chamada Cle- anup Stack; e depois, chamar o metodo ConstructL que e responsavel por alocar a memoria din^amica para os atributos do objeto. Isto se faz necessario para evitar vazamento de memoria (memory leak), pois, caso n~ao exista memoria suciente para alocac~ao dos atributos do objeto, a Cleanup Stack e responsavel por desalocar o objeto e todos os seus atributos previamente alocados.

 Arquitetura cliente-servidor[NOK02]

Todos os servicos relativos ao sistema operacional s~ao implementados seguindo uma arquitetura cliente-servidor. Nesta arquitetura, os servidores gerenciam os recur- sos para diversos clientes. Desta forma, as aplicac~oes que desejam acessar recursos do hardware devem fazer requisic~oes aos servidores destes recursos. Estes servi- dores entregam os servicos requisitados atraves de classes-cliente que tratam estes servicos.

Portanto, para compatibilizar Symbian com outras plataformas, deve-se implementar nestas outras plataformas todos estes mecanismos deste sistema operacional. Isto implica em fazer um framework que implemente o framework de aplicac~oes Symbian em cada uma das plataformas.

Comecamos a desenvolver o CMF em Symbian, no entanto, devido aos motivos apre- sentados anteriormente, foi decidido que Symbian n~ao faria parte do escopo inicial do CMF. Assim, as duas plataformas selecionadas foram as que obtiveram maior pontuac~ao

3.2 metodologia 30 Plataforma Pontuac~ao 39 37 37 34 23

Tabela 3.2. Pontuac~ao das plataformas de acordo com os criterios

depois de Symbian, segundo os criterios utilizados: BREW e Embedded Linux. Este resultado esta ilustrado na Tabela 3.2.

Depois de denidas as plataformas, foi escolhida a vers~ao da plataforma a ser utilizada. Para BREW, temos basicamente uma evoluc~ao da mesma plataforma entre as diferentes vers~oes. Ent~ao foi denido que o CMF seria implementado na vers~ao mais nova disponvel no momento de incio da implementac~ao, o BREW 3.1.5. Para o Embedded Linux, temos diversas distribuic~oes, da mesma forma que temos varias distribuic~oes para PC's. Assim, foi escolhida a distribuic~ao disponibilizada pela MontaVista, que utiliza o Qtopia como framework graco, pois posuamos acesso a esta distribuic~ao e a todo o ambiente de desenvolvimento.

Depois de escolhidas as plataformas de desenvolvimento e suas vers~oes, planejamos os seguintes passos:

i) Elicitac~ao dos requisitos

Levantar os requisitos funcionais e n~ao-funcionais necessarios ao Framework. ii) Denic~ao da arquitetura

Denir uma arquitetura inicial para o CMF, levando em considerac~ao a estrutura de desenvolvimento de aplicac~oes nas diversas plataformas.

iii) Implementac~ao do Framework em BREW

Implementar o CMF em BREW para validac~ao da arquitetura. iv) Implementac~ao de uma aplicac~ao de testes

Em paralelo a implementac~ao do Framework e necessario implementar uma aplicac~ao para usar e rodar o CMF. Esta aplicac~ao tambem deve ser responsavel por testar cada um dos modulos implementados.

v) Correc~oes na arquitetura

De acordo com o uso do CMF para implementac~ao da aplicac~oes de testes, ajustes na arquitetura proposta devem ser feitos.

3.3 requisitos funcionais 31