Nota prévia. Convenções

Transcrição

1 Nota prévia O draft de diagrama de componentes, e respectivas interfaces, foi actualizado pela última vez em 07/12/2007. Este draft servirá de base para as implementações do CyberChair. Caso detecte alguma omissão, ou incorrecção, indique no moodle claramente o que está mal e proponha uma solução alternativa. Caso a sua sugestão seja aceite, será incorporada numa nova versão deste draft, sendo as alterações assinaladas junto a cada diagrama. Para que todos os componentes possam comunicar correctamente, é necessário usar as interfaces aqui especificadas. Convenções 1. Quando um utilizador faz login no sistema, deverá ser criado um sessionid para esse utilizador. Em diversas operações, é enviado o argumento sessionid. Esse argumento serve para identificar quem está a invocar a operação. Naturalmente, o sessionid deixa de ser válido quando o utilizador fizer logout do sistema. 2. Dado que temos uma arquitectura por camadas, os componentes de uma camada só podem ter dependências para a camada que está abaixo deles, ou dentro da própria camada, mas nunca com a camada superior. 3. Do ponto de vista da implementação, um componente vai corresponder a um package em Java. Podemos criar packages internos deste package, como é natural. Mas as interfaces fornecidas por cada componente deverão ser, portanto publicadas no package que as oferece. Dentro de cada componente, poderá implementar as classes que entender convenientes, mas tenha sempre presente que apenas temos acesso às interfaces oferecidas pelo componente. 4. Em operações que devolvem objectos, ou iteradores sobre colecções de objectos, a falha no acesso a esses objectos deve ser assinalada devolvendo-os a null. Note que um iterador com uma colecção vazia indica que não há elementos que satisfaçam os requisitos para pertencer à colecção solicitada, enquanto que null indicaria a tentativa de acesso sem privilégios adequados a essa colecção. 5. Em operações que devolvem inteiros que representam o identificador de um elemento (por exemplo, a função submitnew(newabstract: IAbstract): Integer devolve o paperid), vamos assumir, por convenção, que esses identificadores têm de ser números inteiros positivos. Portanto, se essas funções devolverem um número negativo, ou 0, isso significa que houve insucesso na operação. 6. Há uma série de verificações de segurança que podem ser mais facilmente acauteladas no repositório de dados do que em outros sítios. Portanto, o repositório de dados deve verificar o sessionid do requerente antes de ler ou escrever nas tabelas.

2 Diagrama de componentes (actualizado a 05/12/2007) Login (actualizado a 07/12/2007) getuserkind serve para que quem faz o login consiga saber que tipo de interface vai ter de apresentar ao utilizador, logo de seguida ao login. (actualizado a 05/12/2007) Quer em createpcmemberaccount( ) quer createpcchairaccount( ), o valor de retorno indica se a operação teve sucesso. A criação de contas pode falhar se o sessionid não tiver privilégios de administrador, ou se o login escolhido já existir. A criação de

3 uma conta de autor (leia-se, o autor de contacto de um artigo) tem sempre sucesso e não requer autenticação prévia, dado que é feita quando se submete um abstract. A String de retorno devolve o sessionid dessa IContactPerson. Note que não incluímos aqui a criação da conta de administrador porque essa criação tem de ser feita à parte, na configuração inicial do sistema. Não haveria forma de autenticar quem criasse a conta de administrador. (actualizado em 07/12/2007) Nos métodos referentes às contas, o valor booleano de retorno indica o sucesso ou insucesso da operação, a exemplo do que acontecia em IAccount. No de criação da conta, o valor retornado é o sessionid da conta criada. As operações getusername() e getpassword devolvem esses dados, relativamente ao sessionid passado para a camada do repositório como argumento nessas chamadas. (actualizado em 05/12/2007) Em getsessionid, se o par username, password for desconhecido, a operação devolve null. Nota: Na aula de dia 5/12 foi solicitado ainda um método para conseguir, dado um sessionid, obter o paperid do abstract/artigo enviado pelos autores. Afinal, não é necessário. A informação está disponível na camada de apresentação via IAbstractSubmission (método getabstract( )), que a obtém através do componente AbstractSubmission. Por sua vez, este componente pode obter o paperid através da interface IAbstractRep (método readmyabstract(sessionid: String): IAbstract devolve o abstract submetido pelo autor com aquele sessionid, ou null, se não existir nenhum abstract associado ao sessionid). Para mais detalhes, ver a secção dedicada à submissão de abstracts. Repare que na submissão de um artigo temos acesso ao respectivo abstract, e, por essa via, ao paperid. (acrescentado em 30/11/2007)

4 Abstract submission (actualizado a 05/12/2007) Note que a submissão de um novo abstract não leva um sessionid, porque esta operação é feita por um utilizador não registado no sistema. Note que quando a contact person submete um abstract pela primeira vez, ainda não conhece o respectivo paperid. A camada de controlo, também não. Cabe à camada do repositório gerar o paperid, de modo a que ele passe a ser conhecido na camada de controlo e, por sua vez, esta o possa devolver à camada de apresentação. Assim, o valor de retorno de submitnew é o paperid. A operação gettopics devolve uma colecção de strings, uma por tópico. Opta-se por não devolver directamente um ITopicsInfo, para evitar que novos tópicos possam ser acrescentados, neste contexto. (actualizado a 06/12/2007)

5 (actualizado a 06/12/2007) (actualizado a 30/11/2007) (alterado a 30/11/2007) Temos vários tipos de leituras, destinadas a utilizadores diversos. Quando passamos um paperid, queremos o abstract correspondente a esse artigo. Quando fazemos

6 readmyabstract, apenas acedemos ao abstract submetido por nós (ou seja, pela contact person cujo sessionid é passado como argumento). Há ainda duas leituras, por tópico e para todos os abstracts, pensadas para os membros da comissão de programa, chair, ou administrador do sistema. Paper bidding (alterado em 05/12/2007) Acrescentou-se a possibilidade de declarar o nível de expertise num determinado tópico, sendo o booleano retornado apenas uma indicação do sucesso da actualização da informação. Note-se que ao ser feito bid do paper, IPaperBid tem gets e sets de expertise level. O expertise level num tópico não tem implicações directas no expertise level num artigo sobre esse tópico (que vem expresso em IPaperBid). O motivo é o seguinte: um artigo aborda mais que um tópico, um revisor pode ser perito em alguns dos tópicos abordados, mas inexperiente noutros. Assim, quando fazemos um setexpertise( ) em IPaperBid, estamos a dar informação específica sobre a experiência do revisor no tema abordado no artigo, e isso é completamente independente da sua experiência no tópico, em geral. Por omissão, o nível de experiência em qualquer artigo, ou tópico, pode ser considerado low. Para concluir, repare que ao fazer o paper bid, o revisor ainda não leu o artigo. Pode acontecer que, a julgar pelo resumo, o revisor se julgue inexperiente, mas depois de ler o artigo chegue à conclusão de que afinal até é perito no conteúdo do artigo. Isso pode acontecer, por exemplo, com resumos mal feitos. Ou seja, não é obrigatório que o nível de experiência indicado por um revisor face ao artigo seja o mesmo no bid e na revisão. Para verificar se as revisões efectuadas incluíram a opinião de peritos, conta a indicação dada nas revisões, não a dos bids.

7 (acrescentado em 30/11/2007) (actualizado em 30/11/2007) Send paper (actualizado a 05/12/2007) A actualização pretende harmonizar o estilo de interface com o seguido na submissão do resumo. Quer em submitnew, quer em replace, o inteiro devolvido tem o paperid. Para obter o paperid, começa-se por fazer um getpaper, com o sessionid a servir para identificar a contact person e, consequentemente, o paper.

8 (actualizado em 30/11/2007) (actualizado em 30/11/2007) Review paper (actualizado em 06/12/2007)

9 (actualizado a 05/12/2007) (acrescentado em 30/11/2007) Send feedback to authors

10 (actualizado em 06/12/2007) A decisão é um valor com 3 estados (Accepted, Rejected, ou Undefined). Isso teve implicações quer em IPaperFeedBack, quer em IFeedbackRep, quer na criação do enumerado Decision. Esta alteração resulta do consenso encontrado na representação do resultado da avaliação, no repositório. Note que deixa de existir uma operação de create em IFeedbackRep, uma vez que quando um artigo é submetido ele fica imediatamente com a sua decisão no estado Undefined. (actualizado em 30/11/2007) Note que em update não é necessário passar o paperid porque o podemos obter dentro do IPaperFeedback. (acrescentado em 27/11/2007)

11 Camera ready submission (actualizado a 05/12/2007) (acrescentado em 06/12/2007) Maintenance (actualizado em 07/12/2007) Nesta interface, e em IConfiguration, Date foi substituída por Timestamp, por estar depreciada.

12 (alterado em 05/12/2007) (acrescentado em 05/12/2007) (alterado em 30/11/2007) (alterado em 30/11/2007)

13 Chair (actualizado em 06/12/2007) (actualizado em 30/11/2007) (actualizado em 06/12/2007)

14 (removido em 05/12/2007) (actualizado em 05/12/2007) (acrescentado em 27/11/2007) Messenger (acrescentado em 05/12/2007) (acrescentado em 27/11/2007)

15 (alterado em 06/12/2007) (acrescentado em 30/11/2007)