Um dos principais resultados do trabalho do arquiteto de software é o caderno arquitetural. O caderno arquitetural compila as principais decisões técnicas ao longo de um projeto e é produzido primordialmente ao longo das fases iniciais de um projeto (iniciação e elaboração).

O caderno arquitetural é fundamental para uma empresa bem governada, pois é a evidência que um processo racional de escolha de soluções foi conduzido para uso das soluções em um projeto.

Vários processos de indústria usam este conceito, mas vemos infelizmente muito pouco exemplos disponíveis para consumo. Descrevo abaixo um exemplo de um caderno arquitetural, no formato Open-UP, para um problema fictício de um sistema acadêmico da universidade XYZ.

Problema exemplo

A universidade XYZ está evoluindo o seu sistema acadêmico, que roda atualmente em tecnologia CICS/COBOL.

O usuário de negócio responsável, que não tem conhecimento formal de requisitos, lhe passou as seguintes informações sobre o sistema:

• O sistema deve ser modular e implantável por módulos. Os principais módulos são o de inscrição, controle de alunos, controle de cursos, percursos curriculares e históricos, controle de pagamentos 
• O sistema deve prover integração com o MEC.
• O sistema deve prover boa usabilidade
• O sistema deve ser Web 2.0.
• O sistema deve ser rápido.
• O sistema deve apresentar manutenção facilitada.
• O sistema deve ser simples para testar.
• O sistema deve se comunicar com o antigo sistema já desenvolvido com tecnologia COBOL/CICS.
• O sistema deve operar em qualquer período do dia e da noite.
• O sistema deve apresentar altos padrões de segurança.

Modelo no formato OPEN-UP

1. Finalidade

Este documento descreve a filosofia, decisões, restrições, justificativas, elementos significativos e quaisquer outros aspectos globais do sistema que influenciam e formam o desenho e implementação.

[As seções 2-6 são consideradas obrigatórias no OpenUP. Outras seções são recomendadas dependendo da complexidades da nova arquitetura, a quantidade de manutenção prevista, as habilidades da equipe de desenvolvimento e a importância com  outras preocupações arquitetônicas.]

2. Metas da arquitetura

[Descreva a filosofia da arquitetura. Identificar as questões que irão conduzir a arquitetura, tais como:

• Será que o sistema seja dirigida por condutores tais como uma implantação complexa, integração com sistemas legados ou problemas de desempenho? Será que ela precisa ser robusto para a manutenção a longo prazo?

Passos para preencher esta seção:

• Formular um conjunto de metas que a arquitetura tem de cumprir em sua estrutura e comportamento.
• Identificar as questões críticas que devem ser abordados pela arquitetura.

[Liste as suposições e dependências que irão conduzir as decisões de arquitetura. Isso pode incluir as áreas críticas, as dependências com interfaces de legado, a habilidade e a experiência da equipe, a disponibilidade de recursos importantes, e assim por diante]

4. Requisitos Arquitetonicamente Significativos

[Inserir aqui os requisitos que devem ser endereçados para suportar a arquitetura.]

5. Lista de decisões, restrições e justificativas

[Liste as decisões que têm sido feitas sobre as abordagens de arquitetura e as limitações de serem colocados no caminho que os desenvolvedores a construir o sistema. Elas servirão como diretrizes para a definição da arquitetura partes significativas do sistema. Justificar a decisão de cada um ou restrição para que os desenvolvedores possam entender a importância da construção do sistema de acordo com o contexto criado por essas decisões e restrições. Isto pode incluir uma lista de prós e contras para orientar os colaboradores na construção do sistema.]

• Decisão ou restrição e justificativas

• Decisão ou restrição e justificativas

6. Mecanismos da arquitetura

[Liste os mecanismos de arquitetura para descrever o estado atual de cada um. Inicialmente, cada mecanismo pode ser um nome e uma breve descrição. Eles vão evoluir até que o mecanismo seja uma colaboração de classes ou padrão que pode ser aplicado diretamente a algum aspecto do projeto.]

Mecanismo Arquitetural 1

[Descrever o objetivo, atributos e função do mecanismo de arquitetura.]

Mecanismo Arquitetural 2

 [Descrever o objetivo, atributos e função do mecanismo de arquitetura.]

7. Abstrações chave

[Liste e descreva brevemente as principais abstrações do sistema. Esta deve ser uma lista relativamente curta dos conceitos fundamentais que definem o sistema. Os principais abstrações normalmente traduzem-se as classes de análise inicial e padrões importantes.]

8. Camadas ou estrutura arquitetônica

[Descrever o padrão de arquitetura que você vai usar, ou como a arquitetura será consistente e uniforme. Esta poderia ser uma simples referência a um padrão existente, como o padrão Layer, uma referência a um modelo de alto nível  ou uma descrição de como os principais componentes do sistema devem ser colocados juntos.]

9. Visões de arquitetura

[Descreva os pontos de vista arquitetônicos que vocês irão usar para descrever a arquitetura de software. Isso ilustra as diferentes perspectivas que você vai disponibilizar para rever e documentar as decisões de arquitetura.]

Visualizações recomendadas:

• Visualização lógica: Descreve a estrutura e o comportamento das camadas significativas da arquitetura do sistema. Isso pode incluir a estrutura de pacotes, interfaces críticas, importantes classes e subsistemas, e as relações entre esses elementos. Também inclui exibições física e lógica dos dados persistentes, se a persistência será incorporado ao sistema.

• Operacional: Descreve os nós físicos do sistema e os processos, segmentos e componentes que são executados sobre os nós físicos.

• Caso de Uso: uma lista ou diagrama de casos de uso que contêm os requisitos significativos da arquitetura.

Solução no formato OPEN-UP

As soluções abaixo foram simplificadas e não tem intenção de serem completas ou reais. É apenas um exemplo didático para orientar estudantes de arquitetura de software.

2. Metas da arquitetura

A arquitetura de software do sistema acadêmico deve suportar as seguintes metas de negócio:

• Suportar a implantabilidade parcial (a cada 6 meses) a medida que o sistema na nova tecnologia substituta o sistema em tecnologia COBOL
• Suportar padrões modernos de usabilidade para os portais do aluno, do professor, dos funcionários e da comunidade;
• Flexibilidade para suportar regras de negócio complexas, manutenibilidade e facilidade para testes;

3. Suposições e dependências

• O novo sistema deve interoperar com o sistema COBOL;
• O novo sistema deve interoperar com o sistema do MEC;
• A equipe de desenvolvimento da universidade XYZ é habil em tecnologias Java EE;

4. Requisitos Arquitetonicamente Significativos

Implantabilidade

Os módulos do Sistema Acadêmico devem ser desenvolvidos e implantados de forma modular.  Toda implantação deve ser feita em uma segunda-feira, de 00:00h. às 05:00h., com data pré-agendada. 

Portabilidade entre navegadores

As funcionalidades dos módulos citados acima devem ser acessíveis nos seguintes navegadores: Internet Explorer – versão 7 e 8 e Mozilla Firefox – versão 4 

 Tempo de resposta

O tempo de resposta máximo para as operações cadastrais, com acesso simultâneo de até 1000 usuários simultâneos, não deve ser superior a 8 segundos (para 90% das requisições). Este tempo de resposta não se aplica a relatórios e casos de uso processamentos em lote.

Interoperabilidade com o COBOL/CICS

Os módulos do sistema acadêmico devem ser integrados ao sistema Web Acadêmico (Legado) desenvolvido com tecnologia COBOL/CICS.

Interoperabilidade com o sistema de censo do MEC

Os módulos do sistema acadêmico devem ser integrados ao sistema de censo do MEC através de FTP (tecnologia disponibilizada pelo MEC), em formato próprio de arquivo.

Disponibilidade

Os módulos do sistema acadêmico devem apresentar disponibilidade de 99,99% (ou seja, devem estar fora do ar no máximo 14 minutos por dia).

Autenticação

O sistema deve prover auditoria de todas as operações de escrita.

(*) Esta lista poderia se estender para contemplar diversos outros tipos de requisitos. Guias como o FURPS+ e a ISO 9126 fornecem bons insumos para os arquitetos compilarem os itens de maior risco para a arquiteutra.

5. Lista de decisões, restrições e justificativas

A plataforma tecnológica do sistema será baseada em padrões abertos e Java EE, devido ao conhecimento do time técnico que irá desenvolver a nova plataforma. O time já possui um conjunto de tecnologias padrão Java EE  que tem sido usada para desenvolver sistemas.

A tecnologia de integração com o COBOL/CICS será baseada em WebServices. Esta escolha se deve ao suporte ao padrão WS-* do CICS e do conhecimento comum do padrão WS-* pelo time COBOL e pelo time Java EE.

A tecnologia de integração com o MEC será através de envio de arquivos, por restrição do próprio MEC.

As tecnologias candidatas para a construção do portal acadêmico serão o JBOSS Portal, o Apache Portal e o Alfresco. Testes e explorações mais detalhadas devem ser realizadas para a seleção da plataforma mais apropriada.

A plataforma de hardware deverá operar com virtualização para que os requisitos de disponibilidade e escalabilidade sejam alcançados. A virtualização já é uma tecnologia conhecida pelo time de infraestrutura.

(*) No mundo real, cada decisão pode envolver um complexo estudo de tecnologias. O ponto didático apresentado aqui é cada decisão tenha uma justificativa (um racional arquitetural).

6. Mecanismos da arquitetura

O mecanismo de análise de interoperabilidade foi estudado paras duas integrações:

• com o sistema legado COBOL/CICS;
• com o sistema do MEC

O mecanismo de análise de autenticação foi estudado e detalhado em dois mecanismos de desenho:

• LDAP
  Kerberos

• Microsoft AD
• Oracle OID
• Open LDAP

http://blog.mhavila.com.br/2011/05/26/ajax-e-ria-radar-do-mercado/

http://www.w3.org/TR/WCAG/

http://dev.w3.org/html5/spec/Overview.html

7. Abstrações chave

Os principais conceitos a serem explorados e detalhados são:

• Alunos
• Professores
• Cursos
• Histórico
• Percurso curricular (evolução da grade curricular)
• Turmas
• Matrícula em curso
• Matrícula em disciplina
• Eventos acadêmicos (ex: Matrícula, trancamento)
• Pagamentos

8. Camadas ou estrutura arquitetônica

A organização em camadas para o projeto irá seguir o modelo básico abaixo:

Apresentação Web (Portal)
—————–
Controladores (fluxos de processos de negócio)
——————
Modelo de domínio (dados e regras de negócio)
——————
Camada de persistência (SQL)

(*) Uma boa introdução ao tema organização em camadas é o artigo Layering Strategies, de Peter Eeles.

Be Sociable, Share!

•