quinta-feira, fevereiro 24, 2011

Um Pequeno Glossário Para Arquitetos de Software

Compilo aqui um pequeno glossário de termos usados dentro do processo de arquitetar software. Estes termos foram compilados a partir de fontes diversas da literatura de arquitetura, da experiência de colegas de trabalho e também da nossa experiência em projetos. Acredito sinceramente que estes termos podem ajudar arquitetos a comunicar conceitos e remover mal-entendidos comuns em projetos de TI, especialmente com leigos na disciplina de arquitetura de software.
Condutor Arquitetural
Uma importante diretriz, de natureza de negócio ou técnica, que conduz e influencia as decisões arquiteturais primordiais de um projeto. Os condutores arquiteturais expressam os principais elementos da estratégia arquitetural a serem observados pelo time de arquitetura.
Como exemplo, um projeto de um novo portal governamental pode ter como condutores a universalização do acesso (padrão EGov), a confidencialidade dos dados dos contribuintes e não repudiação no acesso das informações.
Condutores são negociáveis e devem ser priorizados conforme a sua importância estratégica ou tática dentro do cronograma de um projeto.
Projetos de complexidade média possuem entre seis e doze condutores. Projetos muito complexos podem ter algumas dezenas de condutores.
Princípio Arquitetural
Um princípio arquitetural é um tipo especial de condutor, que se torna tão importante que passa a ser não negociável. Um princípio arquitetural é também chamado de meta-condutor.
Como exemplo, um projeto de um home-banking pode ter como um dos seus princípios arquiteturais o elemento a segurança dos dados de um correntista, enquanto que um projeto de uma promoção de um feriado comemorativo em uma empresa de TELECOM pode ter como princípio arquitetural o tempo de mercado.
Projetos devem ter poucos princípios arquiteturais (Normalmente um número entre três e seis princípios)
Requisito Arquitetural
Um requisito arquitetural é um requisito de alto valor de negócio, alta complexidade e abrangência técnica e que permite detalhar um condutor arquitetural. Requisitos arquiteturais devem ser específicos, mensuráveis, atingíveis, realizáveis e rastreáveis. Por exemplo, no exemplo anterior da segurança para o sistema de home banking, poderíamos identificar um requisito arquitetural de autenticação que requer que usuários sejam corretamente identificados no primeiro acesso a um portal.
Requisitos arquiteturais não são necessariamente requisitos não-funcionais. Requisitos arquiteturais podem advir de requisitos funcionais, desde que estes gerem impacto para a arquitetura. Por um exemplo, um requisito de cadastro de bilhetes em um sistema de bilhetagem de TELECOM pode gerar impacto para a arquitetura de persistência, dado que as bases de dados podem precisar manter e recuperar quase 1 bilhão de registros em alguns exemplos reais no Mercado Brasileiro.
Visão Arquitetural
A visão arquitetural expressa os objetivos primários do esforço arquitetural dentro de um projeto de TI. A visão arquitetural promove o alinhamento das estratégias técnicas à visão de um produto a à estratégia de uma organização.
A visão arquitetural pode ser complementada com um primeiro rascunho ou desenho chamado de visualização de negócio (esboço arquitetural).
Visualização de Negócio
Também chamada de esboço arquitetural ou marketecture, é um diagrama de forma livre e com formas humanizadas que permite comunicar o propósito da arquitetura a todos os envolvidos de um projeto, inclusive gerentes e leigos.
Muitas vezes esta visualização de negócio é denominada, incorretamente, de arquitetura, por leigos na terminologia técnica de arquiteturas de software.
Estratégia Arquitetural
A estratégia arquitetural define a forma de atuação básica do esforço arquitetural. Advinda da escola do pensamento estratégico (OMG BMM e BSC), a estratégia é composta da visão arquitetural, da visualização de negócio e é baseada também nos princípios e condutores arquiteturais.
Tática Arquitetural
Uma estratégia é composta por um conjunto de táticas. Uma tática arquitetural, também chamada de mecanismo arquitetural por alguns autores, define uma preocupação importante no espaço da solução. Exemplos de táticas podem incluir a persistência de objetos, a interoperabilidade entre aplicações ou a auditoria.
Um tática pode ser expressa em nível de análise, nível de desenho ou nível de implementação, à medida que for refinada dentro de um projeto. Por exemplo, o requisito arquitetural que expressa que usuários sejam corretamente identificados pode ser expresso nas seguintes táticas:
• Tática de análise: Autenticação
• Táticas de desenho: Autenticação com LDAP ou Autenticação com Kerberos
• Tática de implementação: Autenticação com os produtos OpenLDAP ou Microsoft AD com Kerberos.
Plano Arquitetural
Reflete o planejamento do projeto referente às ações do time de arquitetura. Este plano é desenhado a quatro mãos pelo arquiteto de software e o gerente do projeto.
Risco Arquitetural
É um risco que pode afetar a arquitetura do projeto e eventualmente gerar um colapso técnico dentro do produto. Por exemplo, dentro de um projeto que envolva a comunicação em tempo real entre dois sistemas, a latência de disco pode ser um risco arquitetural que deve ser identificado e mitigado.
Arquitetura Candidata
É um primeiro desenho da arquitetura, com as principais decisões e estratégia do projeto. É normalmente usada para gerar um processo de viabilidade técnica do produto nas fases preliminares de um projeto. Em projetos ágeis, deveria ser o produto de um primeiro Sprint. Em projetos baseados no UP, deveria ser produzida no primeiro décimo de um projeto.
Em diversos processos e métodos, é formalizada em um documento chamado de Documento de Arquiteutra de Software (DAS).
Arquitetura Executável
Representa uma arquitetura que contenha fragmentos de códigos executáveis, normalmente produzidos para mitigar riscos arquiteturais de táticas e requisitos arquiteturais complexos. Uma arquitetura executável é refinada ao longo de um projeto, embora deva ser trabalhada com mais ênfase nas fases iniciais de um projeto.
Quando uma arquitetura executável consegue mitigar todos os principais riscos de uma arquitetura, esta é chamada de arquitetura executável estável. Em processos baseados no UP, a arquitetura executável estável é o marco de fim de fase de Elaboração.

Nenhum comentário: