Tags:
create new tag
, view all tags
Histórico de Revisões

1 Introdução

O que é Arquitetura? A estrutura ou estruturas de um sistema, formada por componentes e suas propriedades visíveis externamente e as relações entre eles [BASS et al., 2003].

2 Finalidade do Sistema

O sistema tem como finalidade criar ambientes onde as pessoas poderão se comunicar e trabalhar colaborativamente. Nesse ambientes, chamados de ondas (Waves), o usuários irão poder se comunicar quase que instantaneamente e trabalhar colaborativamente com textos, fotos, vídeos, entre outros. O Google Wave também irá dispor de um conjunto de APIs abertas para permitir que desenvolvedores insiram waves em serviço na web e criem extensões que trabalhem dentro das waves.

Para cumprir seu objetivo o sistema deverá prover as seguintes funcionalidades (requisitos funcionais) :

* O usuário precisa possuir uma conta no wave provider. * O usuário precisa estar logado para operar o sistema. * O usuário pode criar waves. * O usuário pode compartilhar waves com outros usuários, cadastrados no mesmo wave provider ou não. * O usuário pode responder a waves criados por outros usuários e nas quais ele foi adicionado. * O usuário pode editar o conteúdo de um wave que inicialmente foi criado por outro usuário. * Edições no conteúdo de um wave são marcados para que os outros usuários do wave possam ver o conteúdo da edição. * Usuários adicionados depois da edição do wave não vêem as marcações da edição. Mas podem vê-las através do playback. * Mensagens não lidas pelo usuário aparecem realçadas. * Uma resposta a um wavelet pode possuir um subconjunto dos usuários originais do wave. * Atualizações nos wavelets são visualizadas em tempo quase real por todos os participantes daquele wavelet. * A atualização em tempo quase real pode ser ser desativada. * O usuário pode fazer o playback da história do wave. * O usuário pode adicionar fotografias ao wave (necessário ter o Google Gears para que essa feature funcione). * O usuário pode editar as legendas das fotografias concorrentemente. * O usuário pode iniciar um slideshow com as fotografias de um wave. * O usuário pode embarcar waves em páginas web comuns. * O usuário pode responder a um wave embarcado numa página. Isto cria uma conversação como se o usuário estivesse usando o cliente wave tradicional. * O usuário que respondeu ao wave embarcado no site pode continuar a conversação dentro do seu cliente wave. * Google Wave funciona também em dispositivos móveis. * O usuário possui ferramentas de texto rico, o que faz com que um wave possa ser um ambiente de compartilhamento de documentos. Conversões * Conversações podem acontecer dentro do documento. * O usuário pode esconder conversções individualmente dentro do documento. * O usuário pode gerar uma versão final do documento sem as conversações. * Um documento pode ter várias versões, semelhante a um controle de versões. Cada versão pode ter um grupo diferente de participantes. As versões diferentes do wave podem ser "mergeadas" ao wave principal. * O sistema suporta diferentes linguagens e tipos de edição (Hebraico por exemplo, é escrito da direita para a esquerda).

* O usuário pode criar pastas. * O usuário pode salvar buscas. * O usuário pode associar tags aos waves. * O usuário pode adicionar links para outros waves dentro de um wave e navegar por eles como navegaria dentro de um browser. * As buscas funcionam "ao vivo": se um usuário edita ou cria um wave que agora faz parte do resultado de alguma busca sendo visualizada, o novo wave aparece dentro do painel de buscas automaticamente. O mesmo é válido para waves que após uma edição não faz mais parte do resultado de uma busca. * O usuário pode criar extensões para o cliente wave(e.g. correção ortográfica, detecção de links). * Robôs criados com a Robot API tem o mesmo status de usuários comuns. Eles podem editar o texto, responder a wavelets, etc.

E alguns requisutos, embora que não impliquem em funcionalidades para os usuários finais, implicam no funcionamento do sistema, sendo eles assim, os requisitos não-funcionais, que são:

* O sistema deverá permanecer online 99,999% do tempo (média do uptime do google no brasil, isso corresponde a 3min por ano de downtime); * O sistema deverá ter um tempo de resposta de no máximo 0,5s em LAN; * O sistema deverá ter um tempo de resposta de no máximo 1,0s em WAN; * O sistema deverá permitir pelo menos XXX usuários logados simultaneamente; * O sistema deverá rodar em servidores linux; * O sistema deverá prover relatórios de estado da rede e do próprio sistema para uso dos mantenedores e administradores; * O sistema deverá prover acesso web;

* O sistema deverá realizar log de operações como: login, ... (o que mais?); * O sistema deverá prover login e trasmissão de dados seguros (criptografados);

* O sistema de armazenamento deve ser escalável (horizontalmente de preferência).

3 Atributos de Qualidade

* Disponibilidade

o Tolerância a falhas * Modificabilidade o Escalabilidade o Manutenabilidade o Extensibilidade (plugins) * Usabilidade * Desempenho o Simultaneidade o Persistência + SGBD o Latência * Linguagem de Programação * Testabilidade * Segurança o Autenticação o Autorização - Controle de Acesso o Confidenciabilidade de dados - Encriptação o Integridade de dados o Não-Repudiação o Accountability * Portabilidade * Suportabilidade

4 Requisitos Arquiteturais

São chamados de Requisitos Arquiteturais o subconjunto de Requisitos Funcionais (RFs) e Requisitos Não-Funcionais (RNFs) arquiteturalmente significativos.

Quais dos nossos Requisitos afetam a arquitetura de forma significativa ??

5 Stakeholders do Sistema

Um stakeholder em uma arquitetura de software é uma pessoa, grupo ou entidade com um interesse em ou preocupações sobre a realização da arquitetura. [IEEE Standard 1471, 2000]

definir stakeholders e como seus interesses impactam na arquitetura. (Isso pode ajudar a escolher os tipos de visões a serem construídas)

6 Principais Decisões Para Definição da Arquitetura

Este tópico descreve as principais decisões que norteiam o projeto do sistema. Para cada decisão, são indicados os requisitos arquiteturais que levam à decisão descrita. Cada decisão é descrita mais detalhadamente, e suas vantagens e desvantagens são indicadas. Podem ser incluídas algumas decisões de “não fazer”.

Decisão 01 Utilizar linguagem de programação Java

Requisitos afetados: Descrição: Uso da linguagem de programação Java para codificação do sistema Vantagens: Java tem como principal virtude a independência de plataforma, pois se baseia no princípio das máquinas virtuais, o que leva a portabilidade. Além de seguir o paradigma orientado a objetos, o que facilita a modelagem do modelo de negócios, dá pleno suporte a multithreading e é bastante documentável. Desvantagens: Pelo fato de ser baseada em máquina virtual, pode tornar a aplicação um pouco mais lenta. Observações:

Decisão 02 Usar SGBD distribuído

Requisitos afetados: Descrição: Uso do banco de dados distribuído para realizar a persistência dos dados Vantagens: menor custo de ampliação da capacidade, pois adição de um novo nó no grid segue um modelo de escalabidade horizontal. Desvantagens: Maior complexidade Observações:

Decisão 03 Usar o SGBD HyperTable: http://www.hypertable.org/

Requisitos afetados: Persistência, Disponibilidade, Tolerância a Falhas e SGBD Descrição: Os dados deverão ser persistidos em um banco de dado HyperTable Vantagens: É um sistema distribuido, open-source, sob licença GPL V2 e compatível com os sistemas de arquivos HDFS e KFS Desvantagens: Maior complexidade, inerente ao fato de ser distribuido. Observações: Tem usuários e patrocinadores de grande porte com o Baidu e o Rediff.

Decisão 04 Usar sistema de arquivos HDFS: http://hadoop.apache.org/common/docs/current/hdfs_design.html

Requisitos afetados: Descrição: Usar Hadoop Distributed File System como sistema de arquivos Vantagens: Armazena arquivos grandes em múltiplas máquinas, a confiabilidade é mantida pela multiplicação dos arquivos em múltiplos hosts. Não necessita RAID nas máquinas. Desvantagens: Cada cluster possui um NameNode que se torna um ponto de falha único, que se cair ira derrubar todo o cluster. Observações: Amplamente usado na indústria. Algumas empresas que utilizam a tecnologia: AOL, Facebook, Last.fm, ...

Decisão 05 Prover redundância dos dados.

Requisitos afetados: Descrição: Usar uma política de replicação de dados padrão do HDFS, replicação de dados em três nós. Dispor de réplicas do conteúdo dos nós, para em caso de indisponibilidade de um deles, a deficiência seja suprida pelos outros nós enquanto o problema é sanado. Vantagens: Torna o sistema menos passível a falhas, já que diminui a chance de ocorrer uma falha crítica em toda a base de dados. Desvantagens: Há um custo extra em manuntenção e aquisição de hardware. Observações:

Decisão 06 Criar uma interface para manutenção do sistema

Requisitos afetados: Descrição:

Implementar uma interface para auxiliar na manutenção do sistema. Esta interface permitirá:

+ verificar o status de cada nó do banco de dados (memória, disco, enlace de rede). + verificar a carga a qual os servidores estão submetidos no momento (taxa de transferência, requisições).

+ emitir relatórios de desempenho do sistema em relação a performance.

Vantagens: Permitir um fácil acompanhamento do comportamento do sistema permitindo a identificação de gargalos e problemas do sistema, assim como acompanhar sua evolução. Desvantagens: Maior esforço no desenvolvimento. Observações:

Decisão 07 Criar uma interface para administração do sistema

Requisitos afetados: Descrição: Interface para auxiliar o administrador, que entre outras funções é:

+ responsável pelo controle dos usuários cadastrados no sistema. + mediação do controle de criação de waves .

+ relatórios de uso do sistema.

Vantagens: Facilitar a administração do sistema, tornando-a mais rápida e prática. Desvantagens: Maior esforço no desenvolvimento. Observações:

Decisão 08 Uso do protocolo de comunicação baseado no XMPP

Requisitos afetados: Descrição: Implementar o protocolo de comunicação baseado no padrão XMPP Vantagens: Padrão de comunicação descentralizado. Desvantagens: Observações:

Decisão 09 Política de backup

Requisitos afetados: Descrição: Vantagens: Desvantagens: Observações:

Decisão 10: Uso do protocolo de gerenciamento de rede RMON

Requisitos afetados: Descrição: Vantagens: Desvantagens: Observações:

Decisão 11: Usar Simple Authentication and Security Layer (SASL) para realizar autenticação segura

Requisitos afetados: Descrição: O SASL será utilizado para realizar autenticação de forma segura Vantagens: Desvantagens: Observações:

Decisão 12: Usar o protocolo Transport Layer Security (TLS) para prover segurança e integridade dos dados em seu tranporte na rede

Requisitos afetados: Descrição: O Transport Layer Security (TLS) será utilizado para realizar o transporte das mensagens na rede de forma segura (criptografada) Vantagens: Desvantagens: Observações:

Decisão 13 Uso de Programação Orientada a Aspectos para Logging.

Requisitos afetados: Descrição: Vantagens: Desvantagens: Observações:

7 Visões Arquiteturais

7.1 Visões da OMT [Rumbaugh91]

* Visão estática;

* Visão dinâmica;

* Visão funcional.

7.2 Visões de Booch [Booch91]

* Visão Lógica; * Visão Física.

7.3 Visões 4 + 1 [Kruchten00]

* Visão Lógica; * Visão de Processo; * Visão de Implementação; * Visão de Implantação; * Visão de Casos de Uso.

6.4 As visões do RM-ODP [Beitz97]

* Visão da empresa; * Visão da informação; * Visão computacional; * Visão de engenharia; * Visão tecnológica.

7.5 As visões de Zachman [Zachman97]

* Visão contextual; * Visão conceitual; * Visão lógica; * Visão física; * Visão de construção; * Visão do sistema pronto.

8 Bibliografia

[BASS et al., 2003] Bass, L., Clements, P., Kazman, R. Software Architecture in Practice. Addison-Wesley, 2. ed., 2003.

[Beitz97] Ashley Beitz, Andrew Berry, Andrew Lister, Kerry Raymond; “Introduction to Open Distributed Processing”, CRC for Distribuited Systems Technology, Centre for Information Technology Research, University of Queensland, Austrália,1997.

[Booch91] Grady Booch; “Oriented Object Design with Applications”, Benjamin/Cummings Publishing Company, 1991.

[Kruchten00] Phillipe Kruchten; “The Rational Unified Process: An Introduction”. Second Edition, Addison Wesley, 2000. www.rational.com/whitepapers

[Rumbaugh91] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William Lorenson; “Object-Oriented Modeling and Design”; Prentice Hall, 1991.

[Zachman97] John Zachman; “Enterprise Architecture: The Issue of the Century”, Database Programming and Design Magazine, Março de 1997.

Edit | Attach | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r1 - 2009-09-02 - AdautoFilho
 
  • Edit
  • Attach
This site is powered by the TWiki collaboration platformCopyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback

mersin escort bayan adana escort bayan izmit escort ankara escort bursa escort