I

UNIVERSIDADE TCNICA DE LISBOA INSTITUTO SUPERIOR TCNICO

LICENCIATURA EM ENGENHARIA INFORMTICA E DE COMPUTADORES

Trabalho Final de Curso

PORTAL ARTE E CULTURA ARTGATE

http://artgate.inesc.pt/jetspeed Julho de 2003

Alunos
Andr Fonseca N 46805 Joo Dias N 46877

Professor Alberto Silva

Orientador

ii

iii

Resumo
Este documento pretende descrever toda a concepo do projecto "Portal Arte e Cultura ArtGate, no mbito do Trabalho Final de Curso, iniciado e finalizado no ano lectivo de 2002/2003 do curso de Engenharia Informtica e Computadores do Instituto Superior Tcnico da Universidade Tcnica de Lisboa, orientado pelo professor Alberto Silva, trabalho este desenvolvido no INESC (Instituto Nacional de Engenharia de Sistemas e Computadores). Este trabalho final de curso teve como objectivo o desenvolvimento de um portal de arte e cultura que pretende ser um local electrnico de referncia em Portugal para promoo, divulgao e mediao cultural de artistas, obras, eventos e outras entidades (galerias, fundaes culturais e museus).

Palavras-chave: Cultura, Arte, Artistas, Galeria, Obras, Portal, Jetspeed, Cocoon, Portlet

iv

ndice
1 Introduo .................................................................................................................. 1
1.1 1.2 1.3 1.4 1.5 Introduo .................................................................................................................... 1 Enquadramento............................................................................................................ 1 Objectivos e Contribuies ......................................................................................... 2 Organizao do Relatrio ........................................................................................... 2 Notaes Adoptadas..................................................................................................... 3 Introduo .................................................................................................................... 5 Estado da Arte.............................................................................................................. 5
J2EE........................................................................................................................................ 5 Enterprise Beans ..................................................................................................................... 7 JBoss e Tomcat....................................................................................................................... 9 SQL Server ............................................................................................................................. 9 Apache Cocoon....................................................................................................................... 9 Jetspeed................................................................................................................................. 10

Estado da Arte e Metodologia Adoptada................................................................... 5

2.1 2.2
2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6

2.3 2.4

Metodologia de Desenvolvimento ............................................................................. 16 Ferramentas de Suporte............................................................................................ 17 Viso Original do Sistema......................................................................................... 19 Requisitos No Funcionais ........................................................................................ 19
Requisito No Funcional Open-source .............................................................................. 19 Requisito No Funcional - Usabilidade ................................................................................ 19 Requisito No Funcional Escalabilidade ........................................................................... 19 Requisito No Funcional Segurana .................................................................................. 20 Espaos Culturais.................................................................................................................. 20 Actores e Casos de Uso Principais........................................................................................ 24

Anlise e Requisitos ................................................................................................. 19

3.1 3.2
3.2.1 3.2.2 3.2.3 3.2.4 3.3.1 3.3.2

3.3

Requisitos Funcionais ................................................................................................ 20

3.4

Modelo de Domnio.................................................................................................... 31 Arquitectura de Instalao ....................................................................................... 35 Modelo de Dados ........................................................................................................ 37 Arquitectura de Software.......................................................................................... 38 Alteraes ao cdigo do Jetspeed ............................................................................. 38 Validao dos Objectivos Originais ......................................................................... 41 Principais Contribuies ........................................................................................... 41 Trabalho Futuro ........................................................................................................ 42 Concluses .................................................................................................................. 43

Desenho e Arquitectura de Software....................................................................... 35

4.1 4.2 4.3 4.4

Concluso ................................................................................................................. 41
5.1 5.2 5.3 5.4

v 6 Referncias ............................................................................................................... 44

VI

ndice de Figuras
Figura 1 Modelo Multicamada doJ2EE[2]................................................................................................. 6 Figura 2 Arquitectura do servidor J2EE[2] ............................................................................................... 6 Figura 3- diagrama de estados de um Entity Bean[3]................................................................................... 8 Figura 4 stack de tecnologia do Jetspeed[7] ............................................................................................ 11 Figura 5 Relao entre Page, Layout, Navigation e screen[7] ................................................................ 12 Figura 6 cadeia de eventos do Turbine[7]................................................................................................ 12 Figura 7- Relao conceptual entre Portlet, PortletControl, PortletSet and PortletController,dentro de um Screen Turbine[7] ........................................................................................................................................ 14 Figura 8 Diagrama de Espaos Culturais ................................................................................................ 21 Figura 9 Diagrama de Obras.................................................................................................................... 22 Figura 10 Diagrama de Eventos ............................................................................................................... 23 Figura 11 Diagrama de Actores................................................................................................................ 24 Figura 12 Diagrama de casos de uso do actor Annimo.......................................................................... 25 Figura 13 Diagrama de casos de uso do actor Membro........................................................................... 26 Figura 14 Diagrama de casos de uso do actor Gestor ............................................................................. 28 Figura 15 Diagrama de casos de uso do actor Parceiro .......................................................................... 29 Figura 16 Diagrama de casos de uso do actor Parceiro Comercial ........................................................ 30 Figura 17 Diagrama de classes do carrinho de compras e ordens de compra......................................... 31 Figura 18 Diagrama de classes dos Produtos e Eventos .......................................................................... 32 Figura 19 Diagrama de classes utilizadas nos mecanismos de segurana do Jetspeed ........................... 32 Figura 20 Diagrama de classes dos utilizadores ...................................................................................... 33 Figura 21 diagrama de instalao ............................................................................................................ 35 Figura 22 Pacotes Java utilizados ........................................................................................................... 36 Figura 23 Modelo ER................................................................................................................................ 37 Figura 24 Arquitectura do Portal ArtGate................................................................................................ 38

Captulo 1 1 Introduo
Este documento tem como objectivo fornecer uma descrio detalhada do trabalho desenvolvido relativamente ao projecto Portal Arte e Cultura. O objectivo deste relatrio agrupar num nico documento a anlise, a especificao e a implementao da tecnologia utilizada no desenvolvimento deste projecto.

1.1 Introduo
O portal ArtGate foi desenvolvido num modelo ASP (provedores de servios de aplicao), isto , um portal que disponibiliza servios a artistas. O portal pretende proporcionar ao artista um espao onde possam criar, gerir e configurar a sua prpria galeria virtual. Este projecto, atendendo sua misso de mediao, deve focar a sua ateno sobre dois mercados complementares: Por um lado, o mercado dos promotores (e.g., artistas, galerias, associaes, autarquias, fundaes, museus) de obras de arte e respectivos eventos, aqui designados por parceiro. Por outro, o mercado do grande pblico que consulta a informao mantida pelo portal e que eventualmente adquire obras de arte electronicamente e/ou participa em eventos electrnicos promovidos pelo mesmo, aqui designados por membros.

Tendo em conta estes dois plos de interesse, apresenta-se na seco Actores Principais os perfis de utilizadores.

1.2 Enquadramento
Este trabalho teve como motivaes os seguintes aspectos: Artistas pouco conhecidos terem dificuldade em conseguir expor as suas obras em galerias fsicas;

Tal como, existirem vrios artistas que j tm pginas pessoais prprias onde apresentam algumas das suas obras, embora a grande maioria destas pginas seja quase sempre de fraca qualidade. Outra das motivaes foi a de em Portugal no existir nenhum portal que permita aos artistas divulgar e vender os seus trabalhos. E por ltimo, a grande massificao da Internet nos ltimos anos, o que permite que os trabalhos estejam acessveis a todos.

Este trabalho foi desenvolvido no INESC-ID (Instituto Nacional de Engenharia de Sistemas e Computadores), nomeadamente no GSI (Grupo de Sistema de Informao).

1.3 Objectivos e Contribuies

Pretende-se com este trabalho continuar o desenvolvimento de um Portal de Arte e Cultura tendo como base o Trabalho Final de Curso efectuado pelo aluno Pedro Virote e orientado pelo professor Alberto Silva, denominado "Centro Comercial Electrnico Baseado em Agentes para a Web no ano de 1999/2001, que mais tarde foi parcialmente desenvolvido pelos alunos Francisco Costeira e Hugo Manguinhas no ano de 2001/2002. O Portal Arte e Cultura pretende ser o local electrnico de referncia em Portugal para promoo, divulgao e mediao cultural de artistas, obras, eventos, e de outras entidades relacionadas (e.g., galerias, universidades, empresas, fundaes culturais e artsticas). O modelo de negcio proposto para o projecto diferente do modelo clssico de portal j instalado e conhecido em Portugal, por exemplo atravs dos sistemas www.artlink.pt e www.armazemcultura.pt. Estes sistemas baseiam-se na metfora do jornal electrnico especializado, apresentando basicamente um conjunto de notcias actualizadas, entrevistas, divulgaes de eventos e de obras, e ainda mecanismos de pginas amarelas electrnicas para galerias e museus. O projecto, para alm de pretender ser tambm um portal de arte e cultura, dever ser melhor reconhecido segundo a metfora de um marketplace da arte e cultura (i.e., um centro artstico-cultural multifacetado) constitudo por diferentes espaosculturais (sites virtuais) geridos directa e descentralizadamente pelos vrios parceiros do mesmo.

1.4 Organizao do Relatrio

O relatrio encontra-se organizada em 5 captulos e 2 apndices conforme se resume de seguida: 1. Introduo 2. Estado da Arte e Metodologia Adoptada 3. Anlise e Requisitos

4. Desenho e Arquitectura de Software 5. Concluso 6. Apndice A

No Captulo 1 faz-se uma descrio geral do trabalho final de curso e especificam-se os objectivos do mesmo. No Captulo 2 apresentam-se as principais tecnologias usadas no mbito do projecto. No Captulo 3 apresenta-se toda a especificao do projecto e modelo de classes, definidos usando diagramas UML. No Captulo 4 especifica-se a arquitectura do projecto em detalhe. No Captulo 5 escrevem-se as concluses e notas finais. A bibliografia aparece no final do relatrio. Os Apndice A contm o Manual de Utilizador e o Manual do Administrador.

1.5 Notaes Adoptadas

Ao longo do relatrio so adoptadas genericamente as seguintes regras de notao textual: Nomes e expresses em ingls so escritos em itlico. As excepes so expresses vulgarmente adoptadas para o Portugus (e.g., software, bit), expresses intensamente usadas ao longo do texto (e.g., Internet, Web, applet), ou nomes de produtos de origem anglo-saxnica (e.g., MS-Word, Firefly). Frases e expresses que se pretendam destacar so escritas com nfase (a negrito). Exemplos de cdigo, pseudo-cdigo, nomes de classes, ou endereos electrnicos so apresentados numa fonte de tamanho fixo (i.e., Courier).

Relativamente representao de diagramas ser utilizada, sempre que for adequado, a linguagem UML (Unified Modeling Language) [1].

Captulo 2 2 Estado da Arte e Metodologia Adoptada

2.1 Introduo
O portal ArtGate a continuao de um trabalho feito pelo Pedro Virote e que tm como principal objectivo a elaborao de um ambiente onde os utilizadores possam criar uma galeria sua medida escolhendo entre vrios componentes, disposies e cores, de uma forma fcil, simples e flexvel. Tendo em conta estes objectivos verificamos que estes poderiam ser suportados por um Enterprise Information Portal, que no mais que uma classe de aplicaes que permitem aos utilizadores o acesso a informao interna e externa e providencia aos utilizadores uma gateway nica para a personalizao da informao.

2.2 Estado da Arte

Na elaborao do projecto com as caractersticas do ArtGate, foram utilizadas diversas tecnologias, de modo a facilitarem a elaborao e manuteno do projecto. De seguida passamos a descrever de uma forma sucinta as vrias tecnologias utilizadas, e o modo como se enquadram no projecto.

2.2.1 J2EE
A plataforma Java 2, Enterprise Edition (J2EE) define um standard para o desenvolvimento de aplicaes multicamada. Desta forma podemos definir uma aplicao multicamada como uma aplicao com trs ou mais camadas distintas: uma camada cliente, que providencia a interface com o utilizador, uma ou mais middle-tire que fornecem servios camada cliente, e lgica de negcio para as aplicaes e por fim uma camada de sistemas de informao empresarial que tem como objectivo a gesto da base de dados.

Figura 1 Modelo Multicamada doJ2EE[2]

Assim, o J2EE simplifica as aplicaes empresariais baseando-as em componentes standards e modulares, providenciando um leque completo de servios a esses componentes, e lidando com vrios detalhes do comportamento das aplicaes automaticamente sem que seja necessrio utilizar programao complexa. Esses servios so providenciados por Containers que do suporte automtico a transaes e gesto do ciclo de vida de cada componente Enterprise Java Beans (EJB), bem como a gesto de nomes e persistncia entre outros servios. Alm disso permitem ainda aceder a sistemas RDBMS atravs do uso da API JDBC. A figura em baixo representa um cenrio de 3 camadas enquadrado nesta arquitectura e que serviu de base ao desenvolvimento deste projecto.

Figura 2 Arquitectura do servidor J2EE[2]

Esta plataforma, especialmente criada para o desenvolvimento de aplicaes distribudas, oferece os seguintes benefcios: Arquitectura e desenvolvimento simplificados Escalabilidade Integrao com sistemas de informao j existentes Total liberdade na escolha de ferramentas de desenvolvimento, servidores e componente Um modelo de segurana flexvel

2.2.2 Enterprise Beans

Os Enterprise Beans so os componentes que implementam a tecnologia EJB. Os quais simplificam o desenvolvimento de grandes aplicaes distribudas por diversas razes: Primeiro, porque o container EJB providencia servios ao nvel do sistema aos enterprise beans, e deste modo o programador pode concentrar-se apenas na resoluo de problemas ligados ao negcio. O container EJB responsvel por diversos servios tais como a gesto de transaes e as autorizaes de segurana. Segundo, porque os beans e no os clientes contm a lgica de negcio da aplicao, e deste modo o programador pode focar-se na apresentao do cliente, isto , o programador do cliente no tem que implementar as rotinas que implementam as regras de negcio nem o acesso base de dados. Como resultado os clientes so mais leves, um benefcio que pode ser muito importante para clientes que correm em dispositivos com poucos recursos. Em terceiro, porque os enterprise beans so componentes portveis, e o assemblador da aplicao pode construir novas aplicaes a partir dos beans existentes. Estas aplicaes podem correr em qualquer servidor J2EE compatvel. Existem basicamente trs tipos de beans: sesso, entidade e orientados mensagem. Deste trs tipos apenas se passar a descrever os dois primeiros, uma vez que foram estes que foram usados no projecto. Os beans de sesso representam um cliente dentro do servidor J2EE. Como o nome sugere, um bean de sesso similar a uma sesso interactiva. Um bean de sesso no partilhado, o que significa que s pode representar um cliente. Tal como uma sesso interactiva, um bean de sesso no persistente, assim quando um cliente termina, o seu bean de sesso tambm parece terminar e deixa de estar associado ao cliente. Os beans de sesso podem ainda dividir-se em duas categorias beans com estado e sem estado. Os beans com estado consistem numa coleco de variveis que representam o estado da sesso de um par cliente-bean. O estado mantido enquanto durar a sesso. Se o cliente remover o bean ou o terminar, a sesso acaba e o bean desaparece. O estado deste no pode ser recuperado se acontecer um crash do conteiner onde este esta alojado.

Os beans sem estado no mantm o estado para um cliente em particular. Quando um cliente invoca um mtodo no bean sem estado, as variveis do bean podem conter estado, mas este apenas valido apenas durante a durao da invocao. Quando o mtodo terminado, o estado deixa de ser retido. Excepto durante a invocao de um mtodo todas as instncias de um bean sem estado so equivalentes, permitindo ao container EJB atribuir uma instncia a qualquer cliente. Como os beans sem estado podem suportar mltiplos clientes, oferecem melhor escalabilidade para aplicaes que requerem um grande nmero de clientes. Os EntityBeans representam uma entidade de negcio que guardada de modo persistente (como um ficheiro, uma base de dados ou uma aplicao legada), o que quer dizer que o bean em si persistente. Tipicamente o bean semelhante a uma "interface" com a base de dados, implementando os pedidos base de dados para responder aos clientes. Este bean pode ter vrios clientes ao mesmo tempo, dai a possvel necessidade de suporte transaccional. Tm ainda a possibilidade do seu ciclo de vida ser gerido pelo contentor ou por si prprio. De notar que este tipo de bean s deve ser usado por outros EntityBeans ou por um bean de sesso, que quem faz a ligao directa ao cliente. O ciclo de vida deste tipo de beans controlado pelo contentor e no pela aplicao. Aps ter instanciado um bean, o contentor passa-lhe um contexto atravs do mtodo setEntityContext. O bean ento colocado numa pool de instncias disponveis. Neste estado, uma instncia no se encontra associada a nenhum objecto EJB em particular so todas idnticas. S quando uma instncia passa ao estado activo que o contentor lhe atribui uma identidade. ainda de notar que, no caso de ser o bean a gerir a persistncia, ao passar do estado pooled ao estado activo o contentor no configura automaticamente a chave primria dessa instncia, pelo que dever ser o programador a faz-lo nos mtodos ejbCreate e ejbActivate.
remov e ejbRemove

unsetEntityContext

ejbPassivate

No Existente
setEntityContext

Pooled
ejbActivate

Activo

create ejbCreate ejbPostCreate

Figura 3- diagrama de estados de um Entity Bean[3]

Os EntityBeans tm tambm algumas restries adicionais: Tm de implementar a interface EntityBean. Tm de declarar o ejbActivate, ejbPassivate, ejbLoad e o ejbStore (isto para o contentor poder ler os Beans quando arranca, ou escrev-los de volta quando termina para o meio persistente). De notar que por causa disto no estritamente

necessrio definir um create pois um EntityBean no precisa de ser criado, apenas lido do meio persistente. Tm de definir como que uma "chave primria" (um atributo que tm um valor que nico para todos os elementos dessa classe), isto para um cliente poder especificar o Bean que esta a procura. Tm de ter mtodos de procura (pela mesma razo que a anterior). Tm de definir, se necessrio, os mtodos transaccionais (para o contentor garantir as propriedades ACID desse mtodos).

A tecnologia EJB foi a base para o desenvolvimento da lgica de negcio e para o suporte base de dados, tirando partido de todas as vantagens que foram referidas anteriormente.

2.2.3 JBoss e Tomcat

Como servidor aplicacional e servidor Web optou-se por utilizar o JBoss e o Tomcat respectivamente, uma vez que enquanto o primeiro suporta todos os requisitos da arquitectura J2EE tm ainda a vantagem de ser rpido, fivel e escalvel, o segundo suporta a tecnologia de servlets e JSP, as quais foram as escolhidas para fazer toda a parte de apresentao.

2.2.4 SQL Server

Como servidor de base de dados foi escolhido o SQL Server.

2.2.5 Apache Cocoon

O Apache Cocoon uma framework de publicao de contedos que eleva o uso das tecnologias XML e XSLT a um novo nvel. Desenhado para obter boas performances e ser escalvel recorrendo a um pipeline de processamento SAX, o Cocoon oferece um ambiente flexvel baseado na separao entre lgica, contedo e estilo. Alm disso oferece ainda um sistema de configurao centralizado e um mecanismo de cache sofisticado, que ajuda a criar, instalar e manter as aplicaes baseadas em XML [4,5]. O Coocon foi desenhado como um motor abstracto que pode ser ligado a quase tudo, mas vem com servlets e conectores de linha de comandos. Os conectores Servlet permite que se chame o Cocoon de qualquer motor de servlet ou de qualquer servidor aplicacional. A interface de linha de comandos permite que se gere contedos estticos com processos batch. Por exemplo o contedo que vem com o Cocoon gerado automaticamente quando se faz deploy do cocoon. O Cocoon agora baseado no conceito de pipelines. Como um pipe em UNIX, mas em vez de passar bytes entre o STDIN e o STDOUT, o cocoon passa eventos SAX Os trs tipos de pipeline components so: geradores que pegam num pedido e produzem um evento SAX; transformadores que consomem eventos SAX e produzem eventos SAX; e serializadores, que consomem eventos SAX e produzem uma resposta. Um pipeline Cocoon composto de um gerador, zero ou mais transformadores, e um

10

serializador. Como com os pipes em UNIX, um pequeno nmero de componentes do um nmero incrvel de combinaes possveis. Alguns dos geradores do Cocoon incluem: Um FileGenerator que actua como um parser, lendo um ficheiro (ou um URL) e produzindo um eventos SAX a partir deste; Um DirectoryGenerator l uma directoria, formata-a em XML e produz um evento; ServerPagesGenerator que gera XML dinmico a partir de XSP; JSPGenerator similar mas usa como template uma pgina JSP; VelocityGenerator tambm similar mas usa o Velocity como a linguagem de template. Alguns dos transformadores do Cocoon incluem XSLTTransforme, que transformam uma stream SAX dependendo da stylesheet XSLT fornecida; XIncludeTransformer aumenta a stream SAX processando o namespace xinclude e incluindo fontes externas nas stream; I18NTransformer transforma o contedo baseado no dicionrio i18n e alguns parmetros de linguagem. Alguns serializadores do Cocoon incluem: XMLSerializer, que transforma o evento SAX em XML; HTMLSerializer transforma um evento SAX em HTML; PDFSerialize produz uma stream PDF a partir do evento SAX XSL:FO, usando Apache FOP; SVG2JPGSerializer que produz um stream JPG a partir de uma evento SAX SVG, usando Apache Batik Esta framework foi utilizado no mbito do ArtGate, na publicao de contedos que puderam surgir em vrios formatos, nomeadamente HTML e PDF.

2.2.6 Jetspeed
O jetspeed um sub projecto da The Jakarta Project que comeou em 1999, que por sua, como vez um sub projecto da Apache Software Foundation (ASF)[6]. O Jetspeed sofre de uma sria falta de documentao que explique como os diferentes nveis de baixo trabalham, como as diferentes entidades se ligam e quais os seus ciclos de vida. Contudo, o cdigo fonte esta disponvel, mas isto baixo nvel tornando uma reviso de alto nvel da arquitectura difcil. Mesmo assim, existem vrias razes pelas quais o projecto bastante interessante. As funcionalidades da plataforma so bastante ricas, e a API dos portlets do sistema e servios associados so bastante interessantes. O sistema open source e grtis. Por ltimo a ASF membro de um grupo que est responsvel por desenvolver a especificao Portlet API, em conjunto com a IBM. Assim a especificao final ir ser influenciada de um forma muito significativa por os autores do Jetspeed. 2.2.6.1 Arquitectura do Jetspeed O Jetspeed construdo por cima do framework Turbine, que por sua vez construdo sob Java Servlets. O Jetspeed implementa a API de portlets da Apache. O stack de tecnologia resultante apresentado na figura de baixo.

11

Figura 4 stack de tecnologia do Jetspeed[7]

O Jetspeed necessita ainda de uma base de dados para os dados de autenticao dos utilizadores e dados relativos a configurao dos portlets. 2.2.6.2 Turbine O Turbine uma framework para desenvolver aplicaes web baseadas em Java. Est cheio de servios desenhados especialmente para facilitar o desenvolvimento de aplicaes web. O Turbine pode ser utilizado como uma framework baseada em servlets, ou usando o Turbine Servlet como controlador principal. O Jetspeed construdo sobre o Turbine Servlet. O Turbine trata da autenticao do utilizador. Por norma a autenticao feita ao nvel da aplicao, circundando os procedimentos de segurana do contentor de servlets. Embora no seja fcil configurar a segurana gerida pelo contentor de servlet o Turbine tambm suporta este tipo de gesto. O sistema consiste num modelo que inclui Action, Layouts, Navigators, Screens e Pages. As Actions so aces iniciadas pelo utilizador (atravs do browser). As restantes entidades esto relacionadas com a criao do contedo da pgina web, e a sua relao mostrada na figura de baixo.

12

Figura 5 Relao entre Page, Layout, Navigation e screen[7]

Quando chega um pedido do browser, a framework Turbine verifica se o utilizador est logado. Se no estiver, a pgina de login mostrada. Caso contrrio, a cadeia de eventos a seguinte:

Figura 6 cadeia de eventos do Turbine[7]

Os pedido dos utilizadores incluem qual o screen que a aplicao deve carregar e a action que dever executar. Depois de invocada a aco, o screen resultante emparelhado com o layout que dever ser utilizado. O layout retornado executado, o qual por sua vez executa e inclui o contedo dos navigations e dos screens. A construo de diferentes partes da pgina so feitas usando um sistema de rendering. Correntemente so suportados o WebMacro, o Velocity e o JSP, entre outros. Os servios e funcionalidades da framework Turbine incluem um gestor de ligao base dados, Um parser de parmetros http, aces baseadas em eventos, sistema de controlo de acessos, segurana baseada em grupos e integrao com diversas ferramentas de base de dados relacionais incluindo uma prpria, o Torque.

13

2.2.6.3 Conceitos do Jetspeed 2.2.6.3.1 Panes A base de trabalho da framework so os panes. O sistema permite que o utilizador crie novos panes. Os panes usam um controller para arranjar o seu contedo. O Controller designado de layout quando este mostrado ao utilizador. Existem ainda dois tipos de layouts; o primeiro pode conter portlets, enquanto os segundos podem conter um conjunto de panes. Os ecrs de configurao permitem ao utilizador adicionar portlets num layout de portlets e panes num layout de panes. O layout de panes ainda se pode dividir em dois tipos: o Menu pane, que apresenta as opes na vertical e um Tab pane, que apresenta as opes na horizontal. No que diz respeito s panes de portlets podem surgir com vrias disposies, ou seja com um nmero diferente de colunas e com uma espessura diferente em cada coluna. 2.2.6.3.2 Multi-linguagem e Capacidades O Jetspeed suporta mltiplas linguagens e pode gerar o seu contedo tanto em HTML como em WML. Existe um conceito de capacidade com o cliente que se liga ao Jetspeed. Capacidades incluem o suporte ou no, por parte do browser, de frames, forms, imagens, tabelas, e muito mais. As diferentes linguagens que so suportadas pelo Jetspeed so configurveis e adicionar uma nova linguagem bastante fcil. Para isto, os portles devem ser programados para suportar diferentes linguagens de output, e configurados de modo a que a framework saiba que linguagem deve ser utilizada na construo de cada portlet. 2.2.6.3.3 Papeis e Permisses O Turbine usa um sistema de permisses baseado em papis. Um ou mais papis so associados a um utilizador. Um papel consiste em uma ou mais permisses. Um programador pode questionar a AccessControlList para saber se o utilizador tem uma permisso especfica ou se tem um determinado papel. 2.2.6.3.4 Objecto RunData Um objecto especial, denominado RunData, passado atravs de todos os mtodos na framework Turbine para cada pedido emitido pelo browser. O objecto tem mtodos que permitem aos utilizadores aceder tanto aos mtodos especficos do Turbine como aos dos Servlets. Os mtodos do Turbine incluem mtodos de get para a AccessControlList, a aco invocada, get para o objecto que representa o utilizador, e atributos similares disponveis na framework. Inclui ainda gets e sets para cookies, endereos dos clientes, e muitos outros relativos aos objectos de request e de response, relativos framework de servlets. O Jetspeed configura o Turbine para instanciar um objecto RunData especial. Este permite ao Jetspeed aumentar os mtodos do Turbine com mtodos relativos ao Jetspeed, por exemplo mtodos para obter o mapa de capacidades do browser.

14

2.2.6.3.5 Actions Quando um utilizador carrega num boto, elo ou um controle de um portlet, uma action disparada. Os parmetros enviados do browser incluem o nome da aco e a qual portlet a aco se reporta. O Turbine traduz isto num objecto especfico, e fornece esta informao no objecto RunData. Isto faz com que os portlets possam referenciar aces para eles prprios ou para outros portlets. 2.2.6.4 Caractersticas da Framework

2.2.6.4.1 Portlet API Existem duas APIs associadas ao projecto Jetspeed. A que est a ser usada na verso actual do Jetspeed (1.4b3), que ir ser discutida mais adiante, e a segunda que corresponde contribuio da IBM e que procura desacoplar a API das frameworks Turbine e Jetspeed. Esta API ser adoptada num verso 2 do Jetspeed, a qual ainda est em desenvolvimento. A ideia por detrs desta abordagem permitir a outros fabricantes a implementao desta API sem que para isso necessitem de utilizar o Turbine, e tornar os portlets portveis, permitindo que estes corram em qualquer plataforma que implementasse a API. Na API corrente a interface Portlet deve ser implementada por todo o cdigo que dever correr no ambiente do portlet. Existem vrias sub interfaces de classes abstractas que lhe servem de base, das quais podemos destacar as seguintes: Portlet, PortletControl, PortletController and PortletSet. Podemos ver a relao entre estas na figura de baixo.

Figura 7- Relao conceptual entre Portlet, PortletControl, PortletSet and PortletController,dentro de um Screen Turbine[7]

15

O PortletSet contido por um PortletController. O PortletSet contm todos os portlets que devero ser expostos. O PortletController pode ser paned, o que quer dizer que poder conter vrios portlets, seleccionados via tabs. O PortletControl responsvel pela apresentao da janela em que reside o contedo do portlet. Finalmente o portlet executado e o seu contedo includo na janela de output. Esta API est intimamente relacionada com trs frameworks: Turbine, Jetspeed, e Element Construction Set, ECS. O toolkit ECS um conjunto de cdigo que permite ao programador que codifique programaticamente um documento HTML assemblando objectos que referenciam tags de HTML como body, header ou center, de uma maneira estruturada. A ligao entre a API do portlet e ECS que o mtodo de gerao do contedo na interface do portlet, getContent (), dever retornar um elemento ECS. Contudo a ideia por de trs do getContent () simples, no entanto poderosa. Isto permite aos programadores gerar o contedo da maneira que eles desejarem. Por exemplo, o programador pode escolher uma linguagem de template para fazer o render do contedo. Ou poder ainda escolher enviar os parmetros para um segundo servidor para que este faa o render do contedo. Isto abre a possibilidade de se usarem vrias linguagens de programao diferentes, como por exemplo o PHP, ASP, ou tecnologias semelhantes. Os portlets podem usar o seu objecto PortletConfig, que providencia parmetros de configurao durante o tempo de execuo. Isto permite que se use o cdigo de um portlet em mltiplos portlets. Por exemplo, um portlet genrico de apresentao de notcias pode ser configurado com o URL e com o protocolo de apresentao de notcias que este usa. 2.2.6.4.2 Configuraes XML e Reutilizao do cdigo dos Portlets O programador pode configurar os portlets, controls e os controllers no Registry. O registry um conjunto de ficheiros XML que terminam com a extenso .XREG. Um Portlet-entry contm os seguintes elementos: Classname, a classe Java que implementa a interface do portlet Parameter, que esto acessveis no objecto PortletConfig Meta info, que contm a descrio do portlet Role, que especifica o papel que o utilizador dever possuir para poder ver o portlet Media, uma lista separada por vrgulas com a lista extenses de ficheiros que o portlet poder mostrar Hidden, se o portlet deve ou no estar visvel aos utilizadores

Existe ainda um parmetro type. O valor deste parmetro instance, ref ou abstract. Um portlet instance um portlet definido directamente, e deve incluir todos os parmetros necessrios para ser instanciado. Um portlet ref refere-se a um portlet pai, sobre passando todos os parmetros que puderam estar definidos no portlet pai. O portlet pai tambm poder ser uma referncia, permitindo assim que se estabelea uma cadeia de referncias, acabando por fim numa instncia ou num portlet abstracto. A nica maneira

16

de instanciar um portlet abstracto referir-se a ele via portlet ref, preenchendo os parmetros necessrios para a configurao do portlet. Includos com o sistema esto um conjunto de portlets standard. Estes portlets so para serem referenciados por portlets ref, fornecendo os parmetros necessrios para que o portlet seja mostrado correctamente. Por exemplo: RSSPortlet recebe um ficheiro no formato Rich Site Summary (RSS) e formata o seu contedo em HTML ou WML. VelocityPortlet processa um template velocity e mostra o resultado. JspPortlet executa um ficheiro JSP e mostra o resultado. 2.2.6.4.3 Portal Structure Markup Language (PSML) As preferncias dos utilizadores vulgarmente chamadas de Site Markup so duas linguagens de Markup que compe o PSML. A disposio dos elementos do site guardada num ficheiro XML separado para cada utilizador. Estes ficheiros incluem informao sobre que portlets vo ser mostrados em cada pane, que layout ser utilizado, o estado do portlet e a skin que ser utilizada em cada portlet. Esta informao guardada de uma forma similar forma hierrquica em que os portlets e os panes dos utilizadores esto configurados. 2.2.6.4.4 Servios Os servios so pedaos de cdigo que so configurados no ficheiro de configurao do Turbine. Estes podem ser acedidos no cdigo atravs do objecto RunData, que passado em todos os mtodos. Os portlets baseados em templates descritos anteriormente usam o servio templatelocator service para encontrar e carregar as configuraes do template, e o template rendering service especifico da linguagem para serem processados. O servio de cache providencia funcionalidades ao programador para desenvolver programaticamente mecanismos de cache para o portlet. Existe ainda um servio de persistncia rudimentar, que pode ser invocado pelos portlets.

2.3 Metodologia de Desenvolvimento

Na realizao do projecto Portal de arte e cultura foi seguido uma abordagem interactiva e incremental, assente em trs iteraes conforme se passa a descrever em seguida: Iterao 1 (Set.2002-Out.2002): Nesta primeira fase, e uma vez que o projecto pretendia dar seguimento a outro realizado em 1999/2001 pelo colega Pedro Virote, correspondeu sobretudo a uma fase de aprendizagem das tecnologias que tinham sido usadas na realizao do projecto anterior, da forma como o cdigo estava estruturado, e da forma como tinha sido planeado o modelo de dados. Para isso fez-se uma avaliao do portal e de seguida procederam-se a diversas mudanas na interface do portal. Iterao 2 (Nov.2002-Jan.2003): A segunda fase correspondeu consolidao dos conhecimentos adquiridos na primeira fase, para isso, procedeu-se realizao de novos casos de uso, assim como actualizao do servidor aplicacional da verso 2.4.4 para a verso 3.0.3. Finda esta fase foi colocada online a primeira verso do portal de arte e cultura.

17

Iterao 3 (Fev.2003-Jul.2003): A terceira fase foi a fase mais critica, uma vez que esta correspondeu integrao de todo o cdigo feito anteriormente com o Jetspeed, e que tinha como objectivo uma mudana completa da filosofia do portal, passando de um conjunto de pginas que eram iguais para todos os utilizadores, para uma filosofia de portlets em que cada utilizador tinha sua disposio uma srie de portlets e uma srie de disposies em que os poderia colocar, de modo a construir de uma forma mais personalizada a sua prpria galeria. Alm disto foram ainda acrescentados vrios tipos de portlets noticiosos que os parceiros poderiam colocar nas suas galerias. Estas notcias so obtidas de um site noticioso portugus que disponibiliza notcias de cultura e media em formato RSS. Por fim, e de modo a se poder dar a oportunidade aos parceiros de fornecer o contedo dos suas galerias e dos eventos introduzidos por si em vrios formatos, foi utilizado o Cocoon como ferramenta de apoio transformao do XML. Depois de feito todo o cdigo procedeu-se resoluo de pequenos problemas que foram surgindo medida que os testes se realizavam. No final foi elaborado o relatrio e os manuais de utilizao.

Devido s caractersticas mencionadas anteriormente nas diversas iteraes por que o projecto passou foi adoptado um conjunto de boas prticas normalmente associadas s metodologias geis, tais como (1) pair-programming; (2) daily build; estas metodologias visavam a diminuio do risco de sucesso do projecto, uma vez que este utilizava vrias tecnologias open source e com pouca documentao que auxiliasse a sua compreenso, com por exemplo o Jetspeed e o Cocoon.

2.4 Ferramentas de Suporte

Devido ao tamanho do projecto e s vrias tecnologias envolvidas foram utilizadas diversas ferramentas de suporte, de modo a facilitar o desenvolvimento com todas as tecnologias envolvidas nomeadamente: Forte For Java 4: Como IDE utilizado para o desenvolvimento do projecto, e uma vez que o projecto s utilizava tecnologias open source optou-se por utilizar o forte, uma vez que alm de ser um bom IDE suporta a leitura e edio de vrios formatos de ficheiros utilizados no projecto, nomeadamente Java, jsp, xml. Jakarta Ant: Esta ferramenta foi utilizada para automatizar a compilao e a instalao do projecto no servidor aplicacional, uma vez que o IDE no tinha instalado entre os seus servidores o JBOSS, que foi o servidor seleccionado para o projecto portal arte e cultura. XmlSpy 5 Enterprise Edition: Esta ferramenta foi utilizada para a criao e edio de ficheiros XSL e XSL:FO que tinham como objectivo converter XML em HTML e PDF respectivamente. Photoshop: Este software foi utilizado basicamente para a edio das imagens utilizadas na concepo do portal de arte e cultura.

Alm das ferramentas descritas anteriormente foi tambm utilizada uma biblioteca Java da ibm que tinha como objectivo facilitar a procura de ficheiros no computador do parceiro para fazer upload para o portal.

18

19

Captulo 3 3 Anlise e Requisitos

Neste captulo apresenta-se toda a especificao do projecto e modelo de classes, definidos usando diagramas UML.

3.1 Viso Original do Sistema

A viso original do projecto consistiu na anlise, desenho e desenvolvimento do sistema Centro Comercial Electrnico Baseado em Agentes para a Web, com as seguintes caractersticas fundamentais: Estrutura do Portal bem definida; Permitir a configurao de galerias; Usar tecnologia Open source.

3.2 Requisitos No Funcionais

Nesta seco apresentam-se sucintamente os principais requisitos no funcionais definidos originalmente no planeamento do projecto.

3.2.1 Requisito No Funcional Open-source

Utilizar tecnologia open-source foi desde logo uma condio imposta no inicio do projecto, assim sendo, foram utilizadas as tecnologias jboss e tomcat, ant, jetspeed, cocoon, entre outras.

3.2.2 Requisito No Funcional - Usabilidade

Outro requisito foi o da usabilidade do portal, ou seja, pretende-se que todos os utilizadores encontrem este portal de fcil utilizao.

3.2.3 Requisito No Funcional Escalabilidade

A escabilidade foi proposta como um requisito inicial, tendo como finalidade a acessibilidade do portal, ou seja, o portal deve poder ser acedido por um grande nmero de utilizadores de uma forma rpida.

20

3.2.4 Requisito No Funcional Segurana

A segurana neste portal consiste em garantir aos utilizadores a autenticidade. Neste projecto foram usados vrios mecanismos de segurana do Jetspeed: Autenticao. Controle de acesso. Gesto de utilizadores. Gesto de papeis (roles). Gesto de grupos. Gesto de permisses.

Para cada um destes mecanismos o Jetspeed fornece implementaes por defeito. A maioria destas implementaes tm como base um sistema de segurana de base de dados. Estes mecanismos de segurana tm como base um modelo de objectos de segurana, utilizadores, papis, grupos e permisses.

3.3 Requisitos Funcionais

Nesta seco so apresentados sucintamente os principais requisitos funcionais definidos no planeamento do projecto. Para tal organiza-se tal apresentao em torno de diagramas de classes e de casos de utilizao.

3.3.1 Espaos Culturais

Para alm das funcionalidades disponibilizadas nos portais comuns (e.g., divulgao de notcias e agenda cultural), o Portal Arte e Cultura dever suportar: Criao e gesto de espaos-culturais. A gesto destes espaos-culturais dever ser realizada directamente pelos parceiros (e.g., galerias, artistas, autarquias, museus, associaes), devendo ter mecanismos versteis de gesto e configurao (e.g., de modo que cada espao-cultural apresente um design distinto de todos os outros).

Tipificao de espaos-culturais. Devero existir diferentes tipos de espaosculturais de forma a suportar diferentes necessidades dos vrios parceiros. Entre outros, devero ser suportados os seguintes tipos: Atelier-do-Artista: espao cultural, onde um parceiro, com perfil artista, poder divulgar as suas obras e eventos. Atelier-do-Artista-Comercial: semelhante ao espao Atelier-do-Artista, em que adicionalmente dever ser suportado transaes comerciais: essencialmente a possibilidade do parceiro poder vender as suas obras. Galeria: espao cultural, onde um parceiro, com perfil galeria, autarquia, museu, ou associao poder divulgar os seus artistas, obras e eventos.

21

Galeria-Comercial: semelhante ao espao Galeria, em que adicionalmente dever ser suportado transaes comerciais: essencialmente a possibilidade do parceiro poder vender as suas obras. Museus / Instituies: espao cultural, onde se pode colocar / consultar endereos de museus e instituies.
Museu / Instituies

Espao Cultural

Atelier

Galeria

Atelier Comercial

Galeria Comercial

Figura 8 Diagrama de Espaos Culturais

Mecanismos de suporte s transaces comerciais (compra e venda de obras) directamente nos espaos comerciais. Mecanismos de personalizao e fidelizao dos membros e clientes do Portal Arte e Cultura. Mecanismos de configurao de galerias e ateliers dos membros do portal ArtGate.

3.3.1.1 Configurao dos Espaos Culturais Um galerista pode alterar o logotipo e o banner publicitrio da sua galeria, bem como os seus dados e os da galeria. Pode introduzir autores, produtos e eventos na sua galeria, e apresent-los em local de destaque.

22

Pode escolher os portlets, e o modo como sero apresentados aos utilizadores, como por exemplo, alterar a cor, o local, o cabealho. Caso seja um espao cultural comercial pode escolher quais os produtos que deseja colocar venda. Cada membro pode observar e receber um catlogo sobre as obras e eventos mais recentes no formato HTML ou PDF. Todos os membros que possuam uma galeria ou atelier no portal podem configurar um portlet de notcias que podem agregar sua galeria.

3.3.1.2 Configurao do Portal (eventos, espaos culturais, notcias) Tem todas a possibilidades oferecidas aos gestores de espaos culturais aplicadas ao portal. Pode gerir os espaos culturais museus / instituies, ou seja, dar a possibilidade de inserir/remover informao sobre os mesmos. Pode fazer a gesto dos membros do portal. Suportar todas as funcionalidades atribudas ao gestor. Pode enviar para todos os membros um porte flio com as novidades de obras e eventos.

3.3.1.3 Obras
Tipo de Obra e.g., Msica, Escultura, Pintura.

Autor

Obra

Formato Fisico

Formato MIME, e.g., Image, Text, Audio.

Formato Electrnico

e.g., Escultura, leo, Serigrafia, Montagem.

Figura 9 Diagrama de Obras

O Galerista pode criar novas obras na sua galeria. Ao criar uma obra, o galerista dever colocar todas as informaes referentes mesma. Pode igualmente associar-lhe uma imagem de destaque e/ou uma imagem de desenvolvimento. O Galerista pode igualmente

23

alterar caractersticas ou remover obras, bem como coloc-las ou remov-las de uma zona de destaque da sua galeria. 3.3.1.4 Eventos
Evento Tipo de Evento

e.g., Exposies, Seminri o, Feiras, Concertos, Leiles

Figura 10 Diagrama de Eventos

O Galerista pode criar novos eventos na sua galeria. Ao criar um evento, o galerista dever colocar um ttulo para esse evento, bem como uma descrio e a data de incio e fim do mesmo. Pode igualmente associar-lhe uma imagem de destaque e/ou uma imagem de desenvolvimento. O Galerista pode igualmente remover eventos, bem como coloc-lo ou remov-lo de uma zona de destaque da sua galeria. 3.3.1.5 Compras / Encomendas Todo este processo de compras e encomendas foi simulado no portal. No tendo sido realizado todo o processo de transferncia e validao dos dados do carto de crdito. Por tal, a realizao do pagamento de compras no foi implementado neste portal. Um membro registado pode adquirir um produto que esteja venda numa Galeria Comercial. Para comprar um produto, o membro ter que seleccionar o produto, coloc-lo no carrinho de compras e ordenar a encomenda do produto. Para encomendar o produto, o membro ter que escolher o modo de entrega, dados do local de entrega e da entidade de facturao. Caso no sejam os predefinidos, introduzir os dados do carto de crdito como meio de pagamento do artigo. O produto deixar de figurar na galeria onde estava venda, caso no existam mais exemplares do mesmo artigo. Todos os dados confidenciais devero ser transferidos com segurana. Uma encomenda pode conter mais que um produto, pode ser entregue num local diferente do local de facturao, pode ser facturada por outra entidade diferente do membro que efectuou a encomenda. Um membro s pode fazer o pagamento da sua encomenda atravs do VISA.

24

3.3.2 Actores e Casos de Uso Principais

Nesta seco feita uma descrio dos diversos casos de utilizao por perfil de utilizador. No Figura 11 Diagrama de Actores, mostra-se a relao entre os diversos actores que interagem com o sistema, nas seces seguintes mostram-se os casos de utilizao com mais detalhe. Existem ao todo 5 actores, cada actor tem a sua funo bem delimitada e podem ser agrupados numa rvore como se pode verificar por anlise do diagrama abaixo representado.

UAnnimo

UMembro

UGestor

UParceiro

UParceiroComercial

Figura 11 Diagrama de Actores

3.3.2.1 Actor - Annimo Este utilizador pode "navegar" no portal e consultar toda a informao sobre autores, galeristas, produtos e eventos disponveis no portal ArtGate. No pode fazer mais nada sem estar registado, ou seja, sem ser um membro.

25

Consultar produtos

Consultar eventos

<<include>> Consult ar not icias cult urais Consultar espaos culturais <<include>> <<inc lude>> <<include>> <<include>> Consultar informao geral Consultar autores

UAnnimo

Entrar no sistema

Faz er registo

Figura 12 Diagrama de casos de uso do actor Annimo

Pode listar produtos e eventos existentes no portal e visualizar os dados especficos de cada um. Listar e visitar todos os espaos culturais existentes no portal, pesquisando produtos, visualizando listagens e detalhes de produtos existentes nas galerias ou ateliers. Pode ainda listar e visitar museus e instituies ligadas cultura.

Este tipo de utilizador pode pesquisar produtos e eventos a partir das categorias dos mesmos. Pesquisar artistas existentes no portal, e visualizar os detalhes de cada um dos artistas tais como o nome do artista, data de nascimento, obras expostas no portal e o seu curriculum vitae.

Entrar no sistema como um utilizador registado, fornecendo para isso um login e uma password. Para proceder ao registo, o utilizador ter que fornecer, por intermdio de um formulrio, todos os dados obrigatrios. De acordo com o tipo de registo efectuado, assim ser definido o perfil do utilizador criado.

Cada utilizador ter apenas um perfil no sistema. A cada utilizador criado ser atribudo um login e uma password que servem para entrar e identificar o utilizador no sistema.

26

Aps o registo, o utilizador no entrar no sistema automaticamente.

3.3.2.2 Actor - Membro Utilizador registado no portal. Este utilizador pode comprar em qualquer galeria. Pode ainda receber notcias e informao sobre produtos e eventos.

UAnnimo Comprar Produtos

UMembro

Alterar dados pessoais

Sair do sistema

Figura 13 Diagrama de casos de uso do actor Membro

Pode seleccionar produtos colocando-os no carrinho de compras para posterior compra s se estiver autenticado (entrado no sistema). O produto poder ser colocado no carrinho de compras se estiver venda.

Poder existir mais de um exemplar de cada produto no carrinho de compras. Retirar um ou mais produtos que estejam inseridos no carrinho de compras. Visualizar o contedo do carrinho de compras, listando os produtos que nele esto includos.

Ao concretizar uma compra o carrinho de compras ser apagado. Para comprar o produto, o membro ter que seleccionar o produto, coloc-lo no carrinho de compras e ordenar a encomenda do produto. Para encomendar o produto, o membro ter que escolher o modo de entrega, dados do local de entrega e da entidade de facturao, caso no sejam os pr-definidos, introduzir os dados do carto de crdito como meio de pagamento do artigo. O produto deixar de figurar na galeria onde estava venda.

27

Uma encomenda pode conter mais que um produto, pode ser entregue num local diferente do local de facturao, pode ser facturada por outra entidade diferente do membro que efectuou a encomenda.

Um membro registado pode alterar os seus dados armazenados no sistema, desde que estejam sempre preenchidos os dados que so obrigatrios. Um membro registado pode receber informao oriunda do sistema de forma assncrona na forma de emails. Estes emails so gerados pelo sistema, pelo gestor do portal informao ou catlogos sobre novos produtos e eventos. Estes emails so enviados para a conta de Mail que o membro tem armazenada nos seus dados pessoais. Um membro registado pode terminar a sua sesso no centro comercial, bastando para tal dar o comando de "Logout". A partir deste momento, o utilizador deixar de ter o perfil de membro registado, passando a ser um utilizador annimo at voltar a fazer o 'Login' no centro comercial.

Ao fazer "Logout", o estado do membro no se altera. Permanecendo os dados pessoais, os dados do carrinho de compras, bem como as encomendas efectuadas.

3.3.2.3 Actor - Gestor Este utilizador o gestor do portal, pode personalizar a pgina inicial do portal, faz a gesto dos pedidos de compra e faz a gesto dos membros e espaos culturais.

28

Gerir categorias UMembro Gerir espaos culturais

<<include>>

Gerir segurana

<<include>>

<<include>> <<include>>

UGestor

Gerir portal <<include>> <<include>> <<include>>

Gerir pedidos

Gerir membros Gerir pgina principal do portal <<include>>

Gerir eventos

<<include>>

Seleccionar eventos

Seleccionar produtos

Figura 14 Diagrama de casos de uso do actor Gestor

O gestor pode criar eventos no portal e apagar eventos. Pode tambm colocar eventos em zonas de destaque da pgina principal do portal, bem como colocar eventos criados pelos galeristas em zonas de destaque do portal a pedido destes.

O gestor do portal pode gerir todos os Membros registados no portal. Pode retir-los do sistema. O gestor do portal pode gerir toda a segurana relacionada com os Membros registados no portal. Pode alterar os papis dos membros. Adicion-los a grupos e adicionar ou retirar-lhe permisses.

O gestor do portal pode colocar ou remover produtos, que estejam venda ou no, em zonas de destaque da pgina principal do Centro Comercial.

3.3.2.4 Actor - Parceiro Representa o galerista. Pode gerir a galeria, pode acrescentar novos produtos e autores Galeria, pode remover produtos, pode lanar eventos, pode personalizar a Galeria configurando a estrutura e contedo da mesma. No pode vender produtos.

29

UMembro

Gerir produtos

Gerir eventos <<include>> Selec cionar eventos <<include>> UParceiro Gerir pgina principal galeria/atelier Seleccionar produt os

Criar Autores

Configurar aparncia da galeria

Figura 15 Diagrama de casos de uso do actor Parceiro

O Parceiro pode criar novos eventos na sua galeria. Ao criar um evento, o galerista dever colocar um ttulo para esse evento, data de incio e de fim, bem como uma descrio do mesmo. Pode igualmente associar-lhe uma imagem de destaque. O galerista pode igualmente remover eventos, bem como coloc-lo ou remov-lo de uma zona de destaque da sua galeria.

O galerista pode acrescentar ou retirar portlets, mudar a configurao dos portlet (cor, tipo de letra) e alterar a estrutura do espao cultural, isto , alterar o nmero de colunas e linhas.

O galerista pode requerer ao administrador do portal para colocar um evento da sua galeria numa zona de destaque do centro comercial por correio electrnico. O galerista pode alterar a aparncia da sua galeria, isto , pode escolher, sempre que quiser, qual a cor e tipo de letra do ttulo, e cor do contedo, sobre o qual o aspecto do portlet se vai reger. Pode inclusive alterar o logotipo da sua galeria.

30

Um galerista pode criar novos autores para atribuir s obras que vai colocar na sua galeria. Pode tambm alterar ou apagar produtos desde que tenha permisses para o fazer (apenas podem apagar produtos os tiver criado ou se for gestor). O galerista pode colocar produtos em destaque, ou destacar eventos na sua galeria. Pode igualmente, sempre que quiser, colocar outros produtos nas zonas de destaque em substituio dos que j l esto.

Um galerista pode acrescentar produtos sua galeria, alterar os dados dos produtos j l existentes e elimin-los. Pode tambm acrescentar produtos sua galeria com autores j existentes mesmo quando tenham sido criados noutra galeria ou atelier.

3.3.2.5 Actor Parceiro Comercial Este actor representa um utilizador que pode vender produtos na sua galeria. Tem as mesmas funcionalidades que o utilizador Parceiro.

UParceiro <<include>>

Vender produtos

<<inc lude>> Gerir espao comercial UParceiroComercial

Consultar/emitir relatrios de pedidos

Figura 16 Diagrama de casos de uso do actor Parceiro Comercial

Um galerista Parceiro Comercial pode colocar venda produtos que tenha na sua Galeria. O galerista pode requerer ao gestor do portal para colocar o produto numa zona de destaque do portal.

Quando um produto vendido, o galerista recebe uma nota de encomenda do portal, de modo a fornecer esse produto ao centro de distribuio do portal para que este o entregue ao cliente juntamente com os outros produtos que o cliente poder ter comprado a outros espaos culturais na mesma encomenda. O galerista receber do portal o resultado da venda do produto aps lhe ter sido descontado uma comisso de venda ao portal.

O galerista pode, sempre que quiser, retirar o produto de venda.

31

3.4 Modelo de Domnio

Nesta seco apresenta-se atravs de diagramas de classes os principais conceitos subjacentes do projecto ArtGate em relao ao modelo de dados. A linguagem utilizada foi a SQL (Structured Query Language).
SHOP I D : INT EGE R NA ME : V ARCHAR SHORT _NA ME : V ARCHAR DE SCRIP TI ON : VARCHA R FIS CAL _NR : VA RCHAR ADDRE SS : VARCHA R CIT Y : VA RCHAR ZIP 1 : VA RCHAR ZIP 2 : VA RCHAR ZIP 3 : VA RCHAR PHONE _NR : VA RCHAR MOB ILE_ NR : VARCHA R FA X_ NR : V ARCHAR EM AIL : V ARCHAR CO MIS SI ON : FL OAT PROFIT : VARCHA R LO GO_ URL : VA RCHAR LO GO_ IM AGE_ NA ME : V ARCHAR PUB_IMA GE_ NAM E : VA RCHAR PUB_URL : VARCHA R PROFIL E : I NT E GER ST ATE _P RIVACY : VA RCHAR

SHOPPING_CART I D : INT EGE R TO TAL _ITE MS : INT EGE R TO TAL _V ALUE : F LOA T CART_FK

SHOPP ING_CART _L INE ID : INTEGER PRODUCT_QT Y : INT EGER PRODUCT_VALUE : FLOAT GIFT : VARCHAR PRODUCT _FK SHOP_FK

USER_ FK US ERS ID : INT EGER LOGIN : VARCHAR PASSWORD : :VARCHAR CREATEDATE : DATETIME LASTLOGIN : DAT ETIME LASTMODIFIED : DAT ETIME US ER_ FK MEMBER_FK CURRECY_FK CURRENCY CURRENCY_FK CURRENCY_FK ID : INTEGER REF : VARCHAR RATE : FLOAT

ORDER_L INE ID : INT EGER PRODUCT_QTY : INT EGER PRODUCT_PRICE : FLOAT PRODUCT_VAT : FLOAT GIFT : VARCHAR

CURRE NCY _FK

US ER_ FK USER_SE SSION ID : INT EGER SESSION : :VARCHAR

CURRENCY_FK ORDERS ID : INTEGER TOTAL_IT EMS : INTEGER TOTAL_VALUE : FLOAT SHIP_COST : FLOAT ORDER_ST ATUS : VARCHAR CREATE_DATE : DATETIME BILL_PROFILE_FK ORDER_FK PRODUCT_FK PRODUCT ID : INTEGER NAME : VARCHAR SHORT_DESC : VARCHAR LONG_DESC : VARCHAR THUMB_IMG : VARCHAR LARGE_IMG : VARCHAR ON_SELL : VARCHAR CREATION_DAT E : DATETIME BUSINESS_CODE : VARCHAR PRICE : FLOAT ST OCK : FLOAT VAT : FLOAT PROMOTION_PERCENTAGE : FLOAT PROMOTION_VALUE : FLOAT COST UM1_TEXT : VARCHAR COST UM1_VALUE : VARCHAR COST UM2_TEXT : VARCHAR COST UM2_VALUE : VARCHAR COST UM3_TEXT : VARCHAR COST UM3_VALUE : VARCHAR COST UM4_TEXT : VARCHAR COST UM4_VALUE : VARCHAR

MEMBER ID : INT EGER NAME : VARCHAR SEX : VARCHAR BIRTHDAY : DATETIME FISCAL_NR : VARCHAR ADDRESS : VARCHAR CITY : VARCHAR ZIP1 : VARCHAR ZIP2 : VARCHAR ZIP3 : VARCHAR PHONE_NR : VARCHAR MOBILE_NR : VARCHAR FAX_NR : VARCHAR EMAIL : VARCHAR URL : VARCHAR

VISA SHIPPING_METHOD_FK SHIPPING_METHOD ID : INTEGER NAME : VARCHAR DESCRIPTION : VARCHAR COST : FLOAT ID : INTEGER NR : VARCHAR END_DAT E : DATETIME VISA_FK

BILL_PROFILE ID : INTEGER ADDRESS : VARCHAR CITY : VARCHAR ZIP1 : VARCHAR ZIP2 : VARCHAR ZIP3 : VARCHAR SAME_AS_DELIVERY : VARCHAR

Figura 17 Diagrama de classes do carrinho de compras e ordens de compra

32
PRO DUCT ID : INT EGER NAME : VARCHAR SHORT _DESC : VARCHAR LONG_DESC : VARCHAR T HUMB_IMG : VARCHAR LARGE_IMG : VARCHAR ON_SELL : VARCHAR CREATION_DAT E : DATETIME BUSINESS_CODE : VARCHAR PRICE : FLOAT STOCK : FLOAT VAT : FLOAT PROMOTION_PERCENT AGE : FLOAT PROMOTION_VALUE : FLOAT COSTUM1_TEXT : VARCHAR COSTUM1_VALUE : VARCHAR COSTUM2_TEXT : VARCHAR COSTUM2_VALUE : VARCHAR COSTUM3_TEXT : VARCHAR COSTUM3_VALUE : VARCHAR COSTUM4_TEXT : VARCHAR COSTUM4_VALUE : VARCHAR

PRODUCT_CATEGORY ID : INT EGER NAME : VARCHAR CAT _LEVEL : INT EGER CAT EGORY_FK

SHOP ID : INTEGER NAME : VARCHAR SHORT_NAME : VARCHAR DESCRIPT ION : VARCHAR FISCAL_NR : VARCHAR ADDRESS : VARCHAR CIT Y : VARCHAR ZIP1 : VARCHAR ZIP2 : VARCHAR ZIP3 : VARCHAR PHONE_NR : VARCHAR MOBILE_NR : VARCHAR FAX_NR : VARCHAR EMAIL : VARCHAR COMISSION : FLOAT PROFIT : VARCHAR LOGO_URL : VARCHAR LOGO_IMAGE_NAME : VARCHAR PUB_IMAGE_NAME : VARCHAR PUB_URL : VARCHAR PROFILE : INT EGER ST AT E_PRIVACY : VARCHAR CAT EGORY_FK

SHOP_FK

AUTHOR ID : INT EGER CV : VARCHAR NAME : VARCHAR BIRT HDAY : DATETIME PHOTO : VARCHAR PHONE_NR : VARCHAR EMAIL : VARCHAR URL : VARCHAR SEX : VARCHAR

AUT HOR_FK

SHOP_FK

EVENTS I D : I NTEG ER SHORT_DES C : V ARCHAR LONG_DESC : VA RCHAR URL : VARCHAR T HUMB_I MG : VA RCHAR LARGE_IM G : VARCHAR CRE AT IO N_DAT E : DA T ETI ME BEGINDAT E : DAT ET IM E ENDDATE : DATE TIM E

SHOP_CATEGORY ID : INTEGER FAT HER_LEVEL : INTEGER

CAT EGORY_FK

EVE NTS_CAT EGORY ID : INT EGER NAME : VARCHAR FAT HER_LEVEL : VARCHAR

Figura 18 Diagrama de classes dos Produtos e Eventos

TURBINE_USER USER_ID : INTEGE R LOGIN_NAME : VA RCHAR PASS WORD_VALUE : VARCHAR FIRST_NAME : VARCHAR LAST_NAM E : V ARCHAR EMAIL : VARCHAR CONFIRM_VALUE : VARCHAR MODIFIED : DATETIME LAST_LOGIN : DATETIM E DISABLE : CHAR OBJECTDATA : BINARY PASS WORD_CHANGED : DATETIME

TURBINE_USER_GROUP_ROLE USER_ID : INTEGE R GROUP_ID : INTE GER ROLE_ID : INTEGER

TURBINE_GROUP GROUP_ID : INTEGER GROUP_NAME : VARCHAR OBJECTDATA : BINARY

TURBINE_ROLE ROLE_ID : INTEGER ROLE_NAME : VARCHAR OBJECTDATA : BINARY

TURBINE_ROLE_PERMISSION ROLE_ID : INTEGER PERMISS ION_ID : INTEGER

TURBINE_PERMISSION PERMISSION_ID : INTEGER PERMISSION_NA ME : VARCHA R OBJECTDATA : BINARY

Figura 19 Diagrama de classes utilizadas nos mecanismos de segurana do Jetspeed

33

MEMBER ID : INTEGER NAME : VARCHAR SEX : VARCHAR BIRTHDAY : DATETIME FISCAL_NR : VARCHAR ADDRESS : VARCHAR CITY : VARCHAR ZIP1 : VARCHAR ZIP2 : VARCHAR ZIP3 : VARCHAR PHONE_NR : VARCHAR MOBILE_NR : VARCHAR FAX_NR : VARCHAR EMAIL : VARCHAR URL : VARCHAR

OCCUPATION ID : INTEGER NAME : VARCHAR

USER_SESSION ID : INTEGER SESSION : :VARCHAR USER_FK USERS

OCCUPATION_FK

MEMBER_FK

ID : INTEGER LOGIN : VARCHAR PASSWORD : :VARCHAR CREATEDATE : DATETIME LASTLOGIN : DATETIME LASTMODIFIED : DATETIME SHOP_FK

COUNTRY_FK COUNTRY ID : INTEGER NAME : VARCHAR

PROFILE_FK USER_PROFILE ID : INTEGER NAME : VARCHAR

SHOP_CATEGORY ID : INTEGER FATHER_LEVEL : INTEGER

CATEGORY_ FK SH OP COUNTRY_FK SHOPPING_MALL ID : INTEGER NAME : VARCHAR FISCAL_NR : VARCHAR CONTACT_PERSON : VARCHAR ADDRESS : VARCHAR CITY : VARCHAR ZIP1 : VARCHAR ZIP2 : VARCHAR ZIP3 : VARCHAR PHONE_NR : VARCHAR MOBILE_NR : VARCHAR FAX_NR : VARCHAR EMAIL : VARCHAR LOGO : VARCHAR PUB : VARCHAR PUB_URL : VARCHAR LOGO_URL : VARCHAR PROFILE : INTEGER MEMBER_FK ID : INTEGER NAME : VARCHAR SHORT_NAME : VARCHAR DESCRIPTION : VARCHAR FISCAL_NR : VARCHAR ADDRESS : VARCHAR CITY : VARCHAR ZIP1 : VARCHAR ZIP2 : VARCHAR ZIP3 : VARCHAR PHONE_NR : VARCHAR MOBILE_NR : VARCHAR FAX_NR : VARCHAR EMAIL : VARCHAR COMISSION : FLOAT PROFIT : VARCHAR LOGO_URL : VARCHAR LOGO_IMAGE_NAME : VARCHAR PUB_IMAGE_NAME : VARCHAR PUB_URL : VARCHAR PROFILE : INTEGER STATE_PRIVACY : VARCHAR

Figura 20 Diagrama de classes dos utilizadores

Como se pode observar atravs dos diagrama de classes dos utilizadores e diagrama de classes utilizados no Jetspeed, no existem um ligao explcita entre os utilizadores da base de dados do Portal e os utilizadores do Jetspeed. Esta situao ocorreu porque a base de dados j estava feita quando decidimos incluir a framework Jetspeed no projecto, e se a mantivssemos separada ser muito mais fcil de desacoplar o Portal do Jetspeed, permitindo que, de uma maneira mais fcil, se possa utilizar no futuro outra framework. Deste modo quando se faz o login no portal podem acontecer uma de duas coisas, ou o utilizador apenas um utilizador membro que no possui galeria no portal e ento apenas se faz o login no ArtGate, ou o utilizador um galerista e quando faz login o sistema autentica-os nas duas plataformas, de modo a este poder ter acesso s permisses para configurar os portlets que so dadas pelo Jetspeed, e tambm para ter permisses para configurar a sua galeria, gerir as obras, etc, que so dadas pelo ArtGate.

34

35

Captulo 4 4 Desenho e Arquitectura de Software

Neste captulo so apresentados os diagramas relativos arquitectura de instalao, que tem como objectivo a descrio de elementos de configurao de suporte ao processamento de componentes de software. Alm disso feita a apresentao do modelo de dados do portal, da arquitectura de software, que tm como objectivo a apresentao do desenho da arquitectura, e por fim so apresentadas as alteraes ao cdigo do Jetspeed.

4.1 Arquitectura de Instalao

De seguida passamos a apresentar o diagrama de instalao do portal artgate na figura de baixo.

Figura 21 diagrama de instalao

36

Dentro do componente business logic podemos encontrar os seguintes pacotes:

Figura 22 Pacotes Java utilizados

No pacote artgate.database pode-se encontrar a implementao da Pool de Ligaes, usada para fazer ligaes JDBC. Em artgate.servlet encontra-se um servlet que tem como objectivo suportar a funcionalidade de dar a cada galerista um endereo para que este possa aceder directamente a sua galeria. Todos os Enterprise Java Beans encontram-se em artgate.enterprise, os Java Beans e restantes classes java encontram-se em artgate.beans, e por fim o pacote artgate.util contem um parser para fazer o parse de um ficheiro xml em formato RSS.

37

37

4.2 Modelo de Dados

Figura 23 Modelo ER

38

4.3 Arquitectura de Software

No trabalho optou-se por utilizar uma arquitectura de trs nveis: O primeiro nvel designado de nvel de apresentao, suportado basicamente pelo Jetspeed que serve para definir o modo como a pgina vai ser apresentada aos utilizadores. Em que o cocoon que tem como objectivo a apresentao de contedos em vrios formatos e o Tomcat que faz o trabalho do servidor web. Neste nvel incluem-se ainda os templates Jsp que servem como base para a construo da apresentao. O segundo nvel designado de lgica de negcio tm como objectivo fornecer funes que permitam a realizao de aces relacionadas com a lgica de negcio. For fim temos um terceiro nvel que corresponde ao servidor aplicacional J2EE e que faz a ponte entre a camada de negcio e o acesso informao da base de dados quer seja em modo de leitura ou de escrita.

Figura 24 Arquitectura do Portal ArtGate

4.4 Alteraes ao cdigo do Jetspeed

Durante o decorrer da fase de adaptao do cdigo para o Jetspeed foram surgindo alguns problemas com algumas funcionalidades que deveriam ser suportadas pela plataforma mas que na realidade no funcionavam. De seguida passamos a explicar os problemas ocorridos e a forma como estes foram resolvidos:

39

O primeiro problema que surgiu foi que na utilizao de portlets baseados em JSP, uma vez que o Jetspeed no punha na sesso alguns objectos que eram muito importantes para a configurao do aspecto dos portlets. Em primeiro lugar fomos ao site oficial para ver se l conseguamos obter alguma informao sobre o assunto, mas no havia nenhuma referncia ao assunto, de seguida utilizamos um portlet baseado em Velocity para ver se este disponibilizava os objectos de configurao na sesso, e neste caso no houve nenhum problema. Por fim fomos ao ficheiro JspPortlet.java e acrescentamos a seguinte linha de cdigo:
context.put ( "skin", this.getPortletConfig().getPortletSkin() );

Deste modo j conseguimos aceder s skins para a configurao do aspecto do portlet. O segundo problema que tambm implicou a alterao do cdigo do Jetspeed foi que o tipo de skins que eram disponibilizados de raiz pela plataforma era muito reduzido e no existia maneira de acrescentar propriedades s skins. A nica soluo seria alterando os ficheiros de configurao. Assim e de modo a podermos ter mais variedade nos elementos que compe as skins decidimos acrescentar alguns elementos ao ficheiro PortletSkin.java e ao ficheiro BasePortletSkin.java que passamos a descrever de seguida:
public public public public public public static static static static static static final final final final final final String String String String String String TEXT_SPECIAL_ITEM = "text-special-item"; EVENT_BACKGROUND = "event-background"; TOP_TABLE = "top-table-class"; SIDE_TABLE = "side-table-class"; BOTTOM_TABLE = "bottom-table-class"; DECOR_TABLE = "decor-table-class";

Estes atributos acrescentados visavam aumentar a flexibilizar e o poder de configurao dos portlets. O terceiro e ltimo problema encontrado foi que ns espervamos poder utilizar portlets baseados no Cocoon uma vez que no site [5] anunciava que este tipo de portlets j era suportado pelo Jetspeed, a verdade que ainda no eram suportados, e deste modo tivemos que recorrer ao projecto Cocoon que ficou exterior ao Jetspeed para resolver o problema de publicao de contedos em vrios formatos a partir de XML.

40

41

Captulo 5 5 Concluso

5.1 Validao dos Objectivos Originais

O trabalho tinha como principais objectivos principais a criao de um portal de arte e cultura utilizando tecnologias open source que possibilitasse aos seus utilizadores que criassem galerias com os seus trabalhos, e que estas pudessem ter um grau de configurao muito elevado, tanto ao nvel dos contedos quanto ao nvel do modo como estas se apresentam aos utilizadores, e alm disso dar a possibilidade aos utilizadores de poderem incluir contedos dinmicos no portal sem que estes se tivessem de se preocupar com a gesto dos mesmos. Do nosso ponto de vista os objectivos foram atingidos, o primeiro foi conseguido atravs da utilizao de uma filosofia de portlets na implementao do portal. Esta filosofia permite a diviso do portal em pequenos componentes que podem ser facilmente includos no portal principal, tendo ainda a possibilidade de escolher vrios skins para os portlets e disp-los de vrias maneiras distintas. O segundo objectivo foi alcanado atravs da criao de portlets noticiosos de notcias de mdia e cultura que obtm o seu contedo de um site noticioso em formato RSS. Segundo o planeamento feito no foram implementadas as funcionalidades relacionadas com os leiles e a parte referente a transaces comerciais de suporte s compras. Estas funcionalidades no foram implementadas pois o projecto enveredou para outro tipo de funcionalidades. Foi desenvolvido um servio para a criao de documentos em diversos formatos utilizando o projecto Cocoon em vez dessas funcionalidades planeadas. O desenvolvimento deste projecto correu sempre dentro das expectativas, tendo sido cumpridos os prazos planeados para cada iterao.

5.2 Principais Contribuies

O trabalho realizado veio preencher um espao desocupado no panorama portugus, uma vez que no existia nenhum portal portugus que desse a possibilidade aos artistas de criar as suas prprias galerias e gerir os seus espaos de modo a promoverem ou mesmo venderem as suas obras. Estas caractersticas podem ser aproveitadas por todas os artistas que pretendam expor as suas obras uma vez que a gesto do portal no requer grandes conhecimentos no uso das tecnologias de informao.

42

O trabalho realizado, que foi a continuao de um projecto realizado pelo colega Pedro Virote em 1999/2002 permitiu que se pudessem usar metodologias de anlise do cdigo existente e adaptao forma como este estava elaborado, o que foi muito importante porque ser esta a situao mais provvel de acontecer nas empresas onde poderemos vir a trabalhar. Devido ao uso de vrias frameworks de open source no desenvolvimento do portal, nomeadamente o jboss, jetspeed, cocoon permitiu que se tivesse que aprender em pouco tempo, vrias frameworks, que pelo facto de serem open source e terem pouca documentao (nomeadamente as duas ltimas) obrigou-nos a fazer um esforo de aprendizagem para utilizar estas ferramentas que tm poucos utilizadores e que disponibilizam pouca informao. Esta caracterstica foi muito importante na nossa formao, uma vez que no mundo real muitas aplicaes onde podemos vir a trabalhar tambm possurem pouca documentao e as pessoas que as desenvolveram j no estarem presentes. Outra das vantagens que obtivemos do uso de tecnologia open source foi a experincia adquirida com o uso das mesmas, uma vez que estas esto a ganhar cada vez mais popularidade entre as empresas. Por fim foram adquiridas vrias competncias em vrias tecnologias Java para a web com por exemplo o uso de JSP e servlet, e no uso de metodologias geis para o desenvolvimento de software.

5.3 Trabalho Futuro

Como foi referido anteriormente os objectivos do trabalho foram alcanados, mas o trabalho pode continuar uma vez que o portal pode suportar uma grande quantidade de servios que ainda no foram implementados. De seguida so apresentados vrias funcionalidades que puderam ser feitas de modo a enriquecer as funcionalidades do portal. Uma das funcionalidades que fica em aberto a possibilidade de um galerista poder criar a sua prpria skin para utilizar nos seus portlets com as caractersticas que desejar. Como por exemplo, criar uma skin com as cores por ele desejar ou redesenhar toda a parte que envolve o contedo de portlet. Em resumo, uma funcionalidade para a criao artstica de um portlet. Outra funcionalidade que poderia ser implementada poderia ser a da criao de um frum para os membros poderem colocar questes ou fazerem pedidos sobre obras de arte ou eventos a outros membros. Uma das possibilidades que tambm poder ser implementada ser a criao de um servio de ajuda. Conforme o local em que se encontre o membro ter uma ajuda apropriada, com dicas sobre o que pode fazer nesse mesmo local. Ficando o Portal com um servio de ajuda interactiva.

43

Por fim dever ponderar-se sobre se a framework jetspeed ser a mais indicada para o suporte ao trabalho, uma vez que esta ainda tm alguns bugs e segundo alguns estudos ainda no se encontra preparada para ambientes de produo. de referir ainda que as suas funcionalidades so um pouco limitadas. Como exemplo disto temos o caso da segurana, em que no possvel ter a condio de o utilizador poder ter que possuir dois papis para ver um portlet. Ainda outro exemplo foi o caso dos portlets baseados em JSP no terem na sesso elementos fundamentais que a plataforma deveria fornecer para a configurao das skins dos portlets, e que so fornecidos para outro tipo de portlets baseados noutras tecnologias como por exemplo os portlets baseados em Velocity. Casos como os que foram acabados de referir dificultaram em muito o desenvolvimento de vrios aspectos do trabalho, nomeadamente os que envolvem aspectos relacionados com a apresentao dos portlets.

5.4 Concluses
O trabalho foi desenvolvido com xito sendo que os principais objectivos foram alcanados. Apesar das dificuldades encontradas ao longo do trabalho, especialmente no inicio do trabalho em que nos tivemos que familiarizar com o cdigo j desenvolvido e com uma srie de tecnologias que j estavam a ser utilizadas, e posteriormente numa segunda fase que correspondeu adopo do jetspeed como plataforma de suporte ao portal. A plataforma Jetspeed, que embora tenha resolvido a maior parte dos nosso problemas no foi suficiente por si s, uma vez que tivemos que alterar o cdigo da plataforma de modo a que esta pudesse suportar todas as funcionalidades que ns pretendamos implementar para o portal, sobretudo no que diz respeito configurao do aspecto do Portal. Foram estas razes que nos levaram a recomendar que no caso de continuao do trabalho se mude para outra plataforma, embora se espere para breve que a nova verso do Jetspeed a 2.0 se encontre disponvel para download. Esta nova verso ter vrios problemas resolvidos sendo nessa verso uma plataforma independente do Turbine, que implementa a Portlet API da Java, e que estende de uma forma significativa as possibilidades de evoluo no futuro, uma vez que o portal poder correr em qualquer plataforma que suporte estas novas especificaes. Apesar destas dificuldades os objectivos principais foram atingidos. Assim o Portal ArtGate veio preencher um lugar vago no panorama artstico portugus, possibilitando aos artistas expor as suas obras online e gerir as respectivas galerias. Para finalizar podemos concluir que o trabalho foi bastante gratificante uma vez que nos possibilitou adquirir um grande conjunto de competncias ao nvel de vrias tecnologias que tm como base a linguagem Java, o que nos ser muito til para futuros projectos, principalmente os que envolvam tecnologias open-source.

44

Referncias

6 Referncias
[1] [2] [3] [4] Alberto Silva, Carlos Videira, UML metodologias e ferramentas CASE, Portugal: Edies Centro Atlntico 2001 J2EE Containers: http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Overview3.html Java Blueprints J2EE: http://java.sun.com/j2ee/tutorial Stefano Mazzocchi. OReilly Open Source Software Convention: Julho 7 11, 2003 Introducing Cocoon 2.0, February 2002 http://www.xml.com/pub/a/2002/02/13/cocoon2.html Site official do Cocoon: http://cocoon.apache.org Endre Stlsvik, Modular Development Frameworks for Corporate Portals- A Literature Review, Junho 2003 Site official do Jetspeed: http://jakarta.apache.org/jetspeed/site/index.html Ian Kelley, Jason Novotny, Michael Russell, Oliver Wehrens, Jetspeed Evaluation, Maio de 2002

[5] [6] [7] [8]