15
1 Anexo I - DAS (Documento de Arquitetura de Software) Concurso de Desenvolvimento de Jogos SEBRAE

Anexo I - DAS (Documento de Arquitetura de Software ...walderson.com/site/wp-content/uploads/2016/02/02.Documento-de... · A decomposição refere-se à fragmentação de um sistema

Embed Size (px)

Citation preview

1

Anexo I - DAS (Documento de Arquitetura de Software)

Concurso de Desenvolvimento de Jogos SEBRAE

2

Sumário Sumário ....................................................................................................................... 2 1 – INTRODUÇÃO ................................................................................................... 3

1.1 – Propósito ..................................................................................................... 3 1.2 – Escopo ........................................................................................................ 3 1.3 – Referências ................................................................................................. 3

2 – DIRETRIZES ...................................................................................................... 4 3 - FOCOS DA ARQUITETURA .............................................................................. 5

3.1 – Decomposição ............................................................................................. 5 3.2 – Componentes .............................................................................................. 5 3.3 – Padrões ....................................................................................................... 5 3.4 – Camadas ..................................................................................................... 6

4 - SISTEMÁTICA DE QUALIDADE ........................................................................ 7 4.1 – Operacional ................................................................................................. 7 4.3 - Desenvolvimento .............................................................................................. 7 4.2 – Evolucionário ............................................................................................... 7

5 - DESCRIÇÃO DO MODELO DE ARQUITETURA ............................................... 7 5.1 – Sistema Operacional ........................................................................................ 9 5.2 – Browser .......................................................................................................... 10 5.3 – Controle de Persistência ................................................................................ 11 5.4 – Resolução ...................................................................................................... 11 5.5 – Integrações .................................................................................................... 12

6 – CAMADAS ....................................................................................................... 12 6.1 - Camada de Apresentação .............................................................................. 13

6.1.1 - Camada Web / GUI .................................................................................. 13 6.1.2 - Camada de Serviços WEB ....................................................................... 14

7 – DESCRIÇÃO DAS TECNOLOGIAS DISPONÍVEIS NO SEBRAE ................... 14 7.1 –Linguagem de Programação ........................................................................... 14 7.2 – Banco de Dados............................................................................................. 14 7.3 – Servidores de aplicação ................................................................................. 14 7.4 – Sistemas Operacionais para Suporte às Aplicações ...................................... 14

3

1 – INTRODUÇÃO

1.1 – Propósito

A finalidade do “Documento de Arquitetura de Software - DAS” é definir um modelo

arquitetural para ser aplicado ao desenvolvimento dos jogos do Desafio SEBRAE, bem como

reunir todas as informações necessárias ao controle das atividades de Arquitetura, oferecendo

uma visão macro dos requisitos arquiteturais e não funcionais para suportar o

desenvolvimento dos games e seu posterior acoplamento a plataforma do Desafio SEBRAE.

1.2 – Escopo

Estão contemplados no “Documento de Arquitetura de Software - DAS” os padrões

de software, componentes de software, plataformas de desenvolvimento, plataformas de

hardware, softwares de desenvolvimento, servidores de aplicação, servidores de banco de

dados, sistemas operacionais, frameworks e APIs.

São também descritos neste “Documento de Arquitetura de Software - DAS” a

descrição dos focos e sistemáticas arquiteturais, descrição das camadas de que é composto o

modelo arquitetural, requisitos de segurança, requisitos de desempenho e requisitos de

integrações.

Este documento limita-se a definir a arquitetura tecnológica dos jogos, sem qualquer

alusão a casos de uso previamente definidos, dado que os jogos terão livre criação e

abordarão temas diversos.

É também escopo deste documento orientar todo o pessoal técnico envolvido nas

equipes de desenvolvimento dos jogos, oferecendo diretrizes quanto às tecnologias a serem

utilizadas neste projeto, assim como seu padrão de utilização.

1.3 – Referências

1. W3C: O Consórcio World Wide Web (W3C) é uma comunidade internacional que

desenvolve padrões com o objetivo de garantir o crescimento da web:

a. http://www.w3c.br/Home/WebHome

4

2. Padrões W3C:

a. http://www.w3c.br/Padroes

3. HTML5:

a. http://www.w3.org/html/wg/drafts/html/master/

4. JSR 224: JavaTM API for XML-Based Web Services (JAX-WS) 2.0

a. http://jcp.org/en/jsr/summary?id=224

5. JSR 311: JAX-RS: The JavaTM API for RESTful Web Services

a. http://jcp.org/en/jsr/summary?id=311

6. Framework Unity3D:

a. http://unity3d.com/unity/collaboration/

2 – DIRETRIZES

O detalhamento das Diretrizes, a serem adotadas para “Documento de Arquitetura de

Software – DAS” está descrito a seguir:

A arquitetura do jogo será voltada primeiramente à produtividade e desempenho

de maneira a facilitar tanto o desenvolvimento inicial quanto as evoluções futuras;

Serão utilizadas camadas para modularizar o desenvolvimento, dentre elas,

camada de Apresentação, camada de Negócio, e camada de Integração /

Persistência;

O MVC (Model View Controller) será implementado no padrão “Pull”;

A camada de apresentação deverá ser totalmente independente da camada de

conversação com a Plataforma SEBRAE, não possuindo nenhuma codificação de

regras de interação com a plataforma SEBRAE dentro da mesma;

O jogo será desenvolvido de maneira que seja fácil externalizar regras de interação

com a Plataforma SEBRAE (através de técnicas SOA) que possam ser reutilizadas

por outro jogo (por disponibilização de serviços) e, para isto, existirão

tecnicamente, duas camadas de apresentação (WEB):

o A primeira será responsável por disponibilizar uma GUI para iteração

diretamente com os usuários (atores) do jogo através de plugin no

browser. A primeira camada deverá ser também Desktop, podendo ser

instalada na máquina do usuário, estando disponível offline;

o A segunda camada web será para invocar serviços WEB da plataforma

SEBRAE do tipo REST utilizando RESTEasy (RESTFul Web Services).

Os serviços WEB da plataforma estarão no padrão JAX-WS e serão criados como

EJB Stateless. Tais serviços estão a cargo do SEBRAE, bastando ao desenvolvedor

5

do jogo, para este concurso, desenvolver a simulação de interação com os

mesmos, trocando informações de entrada e saída definidas neste documento.

3 - FOCOS DA ARQUITETURA

Além dos detalhes específicos anteriormente descritos, o desenvolvimento será focado nos

seguintes conceitos arquiteturais:

3.1 – Decomposição

A decomposição refere-se à fragmentação de um sistema em partes menores e

lógicas, facilitando gerenciar a complexidade. Os módulos, os subsistemas e os componentes

são exemplos de decomposição.

A decomposição pode ajudar também na distribuição do software em diversos

processadores. A desvantagem, claro, é que a decomposição inadequada ou em excesso pode

levar facilmente a uma grave degradação do desempenho devido ao overhead da

comunicação.

3.2 – Componentes

Um componente é uma unidade coesiva de software que fornece um conjunto afim

de funções e serviços.

Comparados com o software tradicional, os componentes são mais fáceis de manter

e de modificar para as futuras necessidades.

Os componentes têm o potencial para aumentar a produtividade no

desenvolvimento do jogo, permitindo uma montagem e término rápido da aplicação a partir

de componentes construídos previamente.

As aplicações construídas a partir de componentes podem ser potencialmente mais

flexíveis.

3.3 – Padrões

6

Um padrão de software é uma construção reutilizável que foi capturada, refinada e

abstraída por meio da experiência e foi aprovada com sucesso ao resolver tipos específicos de

problemas, ou seja:

Criação: Os padrões de construção de criação fornecem soluções para os

problemas de construção da configuração e iniciação. Um padrão com um tipo,

que fornece um padrão para limitar a classe a uma única instância: Singleton;

Estrutural: Os padrões de construção estrutural resolvem os problemas da

construção estruturando as interfaces e as relações de suas classes de maneiras

específicas. O padrão “Proxy” é um exemplo de padrão de construção estrutural.

Comportamental: Os padrões comportamentais identificam maneiras nas quais um

grupo de classes interage entre si para conseguir um comportamento específico.

Um exemplo é o padrão “Observer”.

3.4 – Camadas

A camada é um padrão para a decomposição. A decomposição leva a uma

fragmentação lógica do sistema em subsistemas e módulos, e as camadas agrupam e separam

esses subsistemas, assim limitando quem pode usar os subsistemas, componentes e módulos.

As camadas criam separação de preocupações no software abstraindo os tipos específicos de

funcionalidade em camadas funcionais e fornecendo limites conceituais entre os conjuntos de

serviços.

O “RUP (Rational Unified Process)” identifica duas abordagens para as camadas:

Camada baseada em Responsabilidades: Nas camadas baseadas em

responsabilidades, as mesmas têm responsabilidades bem definidas, significando

que cumprem um papel específico no esquema geral das coisas. Tais camadas

também são referidas como níveis.

Camada baseada em Reutilização: Na camada baseada em reutilização, as mesmas

são criadas de modo a fornecerem a melhor reutilização dos elementos do

sistema. Nessa configuração, as camadas geralmente fornecem serviços para

outras camadas. Isso permite que elas sejam entendidas individualmente sem

precisar de compreensão ou de um conhecimento anterior significativo das

camadas acima ou abaixo delas, o que leva a um acoplamento mais baixo entre as

camadas.

A relação entre as camadas é estritamente hierárquica por natureza. Ou seja, uma

camada pode contar com a camada abaixo dela, mas não vice-versa.

7

As camadas são geralmente estruturadas para que a camada mais inferior seja a mais

acoplada ao hardware e ao sistema operacional. As camadas do meio fornecem a base para

construir uma grande variedade de sistemas de software que requerem capacidades

parecidas.

4 - SISTEMÁTICA DE QUALIDADE

Além dos padrões de software e arquitetural, descritos anteriormente nesta proposta de

arquitetura, os seguintes elementos de qualidade de software serão considerados no

desenvolvimento de projetos.

4.1 – Operacional

Concentra-se nas qualidades refletidas na execução do jogo, como por exemplo:

segurança.

4.3 - Desenvolvimento

Concentra-se nas qualidades refletidas durante o planejamento e implementação

física do jogo, como por exemplo: planejamento, processos e qualidade de código.

4.2 – Evolucionário

Concentra-se nas qualidades refletidas em longo prazo pelo sistema, como por

exemplo: escalabilidade, flexibilidade e capacidade de extensão/expansão.

5 - DESCRIÇÃO DO MODELO DE ARQUITETURA

O jogo deverá será desenvolvido em framework Unity 4.0 ou similar, devendo

funcionar em diversos sistemas operacionais e em browsers Web, por meio de plugin.

O jogo deverá ser implementado utilizando a linguagem C#.

8

A programação deverá ser realizada utilizando tal framework, devendo o jogo ser

exportado para os sistemas operacionais Windows XP, Windows 7, Windows 8, Mac OS X e

Linux. Deve ser possível ainda exportar os jogos para mobile, nos sistemas operacionais iOS e

Android, em suas últimas versões.

O jogo deve ainda ser exportado para rodar em plataforma WEB, por meio de plugin,

devendo ser executado em todos os browsers, em suas últimas versões.

Para os jogos publicados para os sistemas operacionais descritos, deve ser possível

jogar off-line, salvando os dados de pontuação em arquivo criptografado, submetendo os

resultados da jogada à plataforma SEBRAE quando da disponibilidade de conexão.

A programação de comunicação com a plataforma SEBRAE, para este concurso

deverá ser simulada, pois não está prevista a interação com a plataforma neste momento,

porém os jogos desenvolvidos no concurso devem estar preparados para a integração com a

plataforma.

No início e fim do jogo haverá comunicação por serviço com a plataforma. Os dados

de entrada e saída do jogo estão definidos na seção Integração deste documento.

O diagrama abaixo ilustra a divisão lógica do jogo com suas camadas:

9

Figura 1 - Camadas Lógicas

5.1 – Sistema Operacional

Os jogos do concurso serão utilizados nos seguintes sistemas operacionais para PC (Personal

Computer):

a. Windows XP;

b. Windows 7;

c. Windows 8;

d. Mac OS X 10.4+;

e. Distribuições Linux.

Devem oferecer possibilidade de exportação para móbile, nos seguintes sistemas operacionais:

a. Apple iOS 4.3+;

b. Android 2.2+.

Os jogos deste concurso devem ser executados na máquina e dispositivo do usuário em

10

modo on-line e off-line, devendo o jogo validar a conectividade para estabelecer os

momentos de comunicação com a Plataforma SEBRAE.

5.2 – Browser

Os jogos do concurso também serão utilizados através de um browser web.

Os jogos deste concurso devem seguir os padrões HTML5, porém fazendo uso de plugin para

sua execução.

Jogos utilizados em Browser podem ser divididos em três tipos, que aqui explanamos para

garantir a distinção e o uso correto da tecnologia escolhida:

A. Um jogo que requer um plugin do navegador.

o O framework Unity3D possui o plugin Unit Web Player, que pode ser utilizado

para a publicação do jogo. Outros plugins estão disponíveis no mercado,

podendo ser utilizados para o jogo.

B. O plugin para applet Java.

o Basicamente, devido ao Java pode acessar a capacidade do sistema de placa

de vídeo (com Java OpenGL), é possível criar um verdadeiro jogo / full 3D

usando applet Java. Porém, existem ressalvas quanto à atualização da JRE Java

na máquina do usuário e a degradação da performance em sua utilização.

C. Um jogo que não necessita de um plugin para o navegador.

o Este tipo de jogo é normalmente implementado totalmente usando HTML e

JavaScript. Basicamente, é possível criar um bom jogo 2D (ou 2,5 D) usando

JavaScript.

Portanto, os jogos deste concurso seguem a definição A, fazendo uso de plugin para sua

execução.

Os jogos deverão possuir compatibilidade com os browsers listados abaixo:

Firefox 3.5 +, Google Chrome 4.0 +, Apple Safari 4.0 +, Opera 10.5 + e IE 9.

11

Necessário frisar que desejável é que os jogos contenham áudio, melhorando a experiência do

usuário em sua utilização.

5.3 – Controle de Persistência

O jogo deverá permitir a ação de pausa e ainda de salvar o estado do jogo.

O estado do jogo deverá ser salvo em estrutura no servidor de aplicação, quando

online. Os jogos podem salvar os dados da jogada em arquivo próprio, quando offline,

devendo as informações do jogo serem submetidas à plataforma SEBRAE quando online.

O usuário, ao retornar ao jogo, poderá optar por restaurar ao estado salvo ou iniciar

nova interação.

Os dados salvos em arquivo deverão ter a seguinte estrutura:

[E-mail];[Nome];[Fase];[Pontuação];[Configurações]

Onde E-mail é o endereço de correio eletrônico recebido da plataforma; Nome é o

Nome do Jogador, recebido da plataforma; Fase deve ser a string que armazena todo o estado

do jogo salvo; Pontuação refere-se ao pontos atuais do jogador; Configurações contêm todas

as pré-seleções e set-ups realizados pelo jogador.

A pontuação deverá estar compreendida no intervalo de 0 a 1.000.000 (Um milhão),

sendo 1.000.000 o valor máximo permitido a ser atingido no jogo.

5.4 – Resolução

A resolução será de escolha do desenvolvedor, lembrando que deverá rodar nos

browsers definidos, em PCs comuns e em dispositivos móveis.

12

5.5 – Integrações

As Integrações deverão ser realizadas via programa no servidor ou por AJAX,

invocando WebService que simule a plataforma SEBRAE.

Não haverá máscara para estes serviços, portanto a simulação da chamada pode ser

realizada de forma livre, desde que os parâmetros de entrada e saída contenham os dados

definidos abaixo.

Dados de Entrada:

Estes dados devem ser invocados no serviço da plataforma, solicitando receber as

seguintes informações:

a. Cadastro único do usuário na plataforma (E-mail), Nome do Usuário (texto), data fim do desafio (data), Melhor pontuação deste usuário no jogo.

Os dados de entrada serão recuperados na primeira tela do jogo e exibidos em tela.

Dados de Saída:

Estes dados devem ser informados no serviço da plataforma, entregando as

seguintes informações:

a. O identificador do jogo (número), a pontuação no jogo (número), data e hora do fim da jogada (data/hora) e o cadastro único do jogador (E-mail).

Os dados de saída serão informados no final de uma jogada completa (roteiro

finalizado) ou ao salvar o estado da jogada, para posterior recuperação.

b. Ao final de uma jogada completa deve ser apresentado ao jogador ícone para que este informe seu desempenho através do Facebook e Twitter, publicando em sua própria time line. Para isso, deve ser utilizada as APIs do Facebook e Twitter, visando interagir com tais redes sociais.

c. Deve ser utilizada a Graph API para integração com o Facebook, disponível em http://developers.facebook.com/docs/reference/api/.

d. Deve ser utilizada a REST API para integração com o Twitter, disponível em https://dev.twitter.com/docs/api/1.1 .

6 – CAMADAS

As camadas que compõem o diagrama da solução proposta estão detalhadas a

seguir:

13

6.1 - Camada de Apresentação

O sistema possuirá duas camadas de apresentação:

6.1.1 - Camada Web / GUI

A camada de apresentação web/Desktop/Mobile será responsável por prover as

funcionalidades para os atores ou usuários diretos do jogo (GUI – Graphical User Interface).

Todas as mensagens do jogo devem estar encapsuladas em arquivo de mensageria,

estando o jogo preparado para suporte a multi-linguagem (diversos idiomas como PT_BR, FR,

EN, ES, etc).

O framework utilizado para publicação do jogo deve ser capaz criar jogos 2D ou 3D,

em modo multi-player ou single-player, sendo possível a exportação para as diversas

plataformas e sistemas operacionais descritos neste documento.

O código-fonte escrito no framework deve ser entregue ao SEBRAE, com todas as

dependências, arquivos e manuais, necessários a manutenção e utilização do jogo.

O GDD (Game Design Document) – Documento de Design do Jogo – deve ser escrito

e entregue juntamente com os itens citados acima ao SEBRAE.

Conforme o edital do concurso, os vencedores do concurso obrigam-se a ceder ao

SEBRAE todos os direitos autorais patrimoniais relativos ao jogo. Por ocasião da divulgação dos

vencedores o organizador do certame entrará em contato com os vencedores encaminhando o

termo de cessão de direitos autorais patrimoniais, que deverá conter a assinatura do(s)

autor(es) e, quando for o caso, dos representante(s) legal(is) das pessoas jurídicas.

6.1.1.2 - Segurança: Autenticação e Autorização

O jogo deverá invocar os serviços da plataforma para recuperar o usuário logado.

Somente será habilitado a jogar aquele usuário cadastrado e ativo na plataforma (mesmo que

simulada, no momento).

Em modo offline, continua-se o jogo para o usuário previamente habilitado.

14

6.1.2 - Camada de Serviços WEB

A camada de serviços Web (Web Services) será responsável pelo processo de

disponibilização de regras de negócio existentes na plataforma e deverá ser criado pelo

desenvolvedor para apenas simular a interação com o jogo. Esta camada deve ser criada em

linguagem JAVA.

7 – DESCRIÇÃO DAS TECNOLOGIAS DISPONÍVEIS NO SEBRAE

Aqui estão descritas as tecnologias disponíveis no Sebrae, para que sejam utilizadas

como referência para o desenvolvimento dos jogos, objeto deste concurso.

7.1 –Linguagem de Programação

DotNet;

Java( J2EE e J2ME).

7.2 – Banco de Dados

Microsoft SQL Server 2008.

7.3 – Servidores de aplicação

Apache Tomcat 7.0

Internet Information Services – IIS Versão 7;

Internet Information Services – IIS Versão 7.5;

7.4 – Sistemas Operacionais para Suporte às Aplicações

Windows Server 2003

Windows Server 2008 R2

Debian 6;

15

Conforme as informações contidas no edital, os jogos deverão ser enviados

juntamente com as documentações mínimas previstas no GDD – Game Design

Document, que refletem nos artefatos dos ciclos de vida do desenvolvimento de

jogos digitais.