• Arquiteto de Software

• Arquiteto de Software

• Análise Arquitetural

• Avaliar Viabilidade de Prova de Conceito Arquitetural

Organização de Ativos

A organização que possui os ativos da Arquitetura de Referência precisará decidir como eles serão classificados e organizados para facilitar a recuperação por parte do arquiteto de software, atendendo aos critérios de seleção do novo sistema. Embora a criação e o armazenamento de Arquiteturas de Referência estejam no momento fora do escopo do RUP, uma sugestão é que as arquiteturas sejam organizadas em torno da idéia de Definição de Termo: domínio, onde um domínio é uma área de assunto que define o conhecimento e os conceitos de um aspecto de um sistema ou de uma família de sistemas. Aqui estamos aceitando o uso do termo 'domínio' em níveis inferiores aos do aplicativo. Esse uso difere um pouco de algumas definições - por exemplo, do uso apresentado em [HOF99] - mas está bem alinhado ao apresentado em [LMFS96]:

"Domínio de Linha de Produto: um grupo restrito de recursos - presente e/ou futuro - definido para facilitar a comunicação, análise e engenharia, visando identificar, projetar e gerenciar os atributos comuns de uma linha de produto. Tais domínios poderão incluir grupos intrinsecamente relacionados de sistemas de usuário final, funções comumente utilizadas em vários sistemas ou grupos amplamente aplicáveis de serviços básicos."

Essa definição inclui a noção de que os elementos usados para compor sistemas podem pertencer a um domínio que é, por si só, digno de estudo. A figura a seguir, tirada de [LMFS96], ilustra esse princípio.

Domínios Horizontais e Verticais do Exército dos EUA

Essa figura mostra as principais famílias de sistemas, Sistemas de Informações, Comando & Controle e Sistemas de Armamentos, cada um com alguns domínios verticais inteiramente contidos e alguns domínios horizontais que interceptam os verticais e também as famílias de sistemas. Assim, os conceitos de Planejamento em Tempo Real são aplicáveis ao Domínio Tático de Comando & Controle e a todos os domínios verticais de Sistemas de Armamentos. Isso provavelmente faz sentido quando é necessário resolver problemas de programação em tempo real para todos esses domínios ao mesmo tempo e tratar o conhecimento e os ativos desenvolvidos como um domínio separado, que tenha uma associação com Conflitos Eletrônicos, por exemplo, mas não com Sistema de Informações Pessoais.

Conteúdo

A Arquitetura de Referência possui a mesma forma do Produto de Trabalho: Documento de Arquitetura de Software e dos modelos associados, desprovida de referências específicas de projeto ou com referências e características de projeto genéricas, a fim de que a Arquitetura de Referência possa ser classificada corretamente na base de recursos. Os modelos típicos associados ao SAD (Software Architecture Document) são um Modelo de Caso de Uso, Modelo de Design, Modelo de Implementação e Modelo de Implementação.

O acesso ao SAD e aos modelos associados fornece vários pontos de entrada para o arquiteto de software, que pode optar por usar somente as partes conceituais ou lógicas da arquitetura (se a política de reutilização da organização permitir isso). Por outro lado, o arquiteto de software pode ser capaz de extrair da base de ativos subsistemas funcionais completos e um Modelo de Implementação no nível físico (ou seja, uma planta de hardware e de rede completa).

Outros artefatos de suporte são necessários para tornar utilizáveis os recursos arquiteturais.  

1. O Modelo de Casos de Uso descreve o comportamento da arquitetura, mas o arquiteto de software também precisará conhecer suas qualidades não-funcionais. Esses dois - Modelo de Caso de Uso e os requisitos não funcionais - podem ter sido capturados anteriormente em uma Especificação de Requisitos de Software. A partir dessa especificação, o arquiteto de software será capaz de determinar se a Arquitetura de Referência está atendendo satisfatoriamente ou não aos requisitos atuais.

2. O uso e, mais especificamente, a modificação da arquitetura precisam ter a mesma orientação do desenvolvimento original. Por exemplo, o arquiteto de software precisará saber quais regras foram aplicadas na formação da Arquitetura de Referência e o grau de dificuldade que ele experimentará para modificar as interfaces. O acesso às diretrizes de design associadas à Arquitetura de Referência pode ajudar a responder essas perguntas.

3. (Opcional) A revisão de todos os planos de teste relevantes já existentes também pode ser útil. Esses Planos de Teste informarão ao arquiteto sobre as estratégias de teste e de avaliação anteriormente usadas para testar arquiteturas similares que, como tal, podem vir a fornecer uma idéia das possíveis deficiências da arquitetura.

4. (Opcional) A revisão de todas as arquiteturas de automação de teste existentes e relevantes e das especificações da interface de teste pode ser útil. Esses artefatos informam ao arquiteto sobre as solicitações que provavelmente serão feitas com relação à arquitetura para facilitar o teste.

Organização de Ativos

A organização que possui os ativos da Arquitetura de Referência precisará decidir como eles serão classificados e organizados para facilitar a recuperação por parte do arquiteto de software, atendendo aos critérios de seleção do novo sistema. Embora a criação e o armazenamento de Arquiteturas de Referência estejam no momento fora do escopo do RUP, uma sugestão é que as arquiteturas sejam organizadas em torno da idéia de domínios, onde um domínio é uma área de assunto que define o conhecimento e os conceitos de um aspecto de um sistema ou de uma família de sistemas. Aqui estamos aceitando o uso do termo 'domínio' em níveis inferiores aos do aplicativo. Esse uso difere um pouco de algumas definições - por exemplo, do uso apresentado em [HOF99] - mas está bem alinhado ao apresentado em [LMFS96]:

"Domínio de Linha de Produto: um grupo restrito de recursos - presente e/ou futuro - definido para facilitar a comunicação, análise e engenharia, visando identificar, projetar e gerenciar os atributos comuns de uma linha de produto. Tais domínios poderão incluir grupos intrinsecamente relacionados de sistemas de usuário final, funções comumente utilizadas em vários sistemas ou grupos amplamente aplicáveis de serviços básicos."

Essa definição inclui a noção de que os elementos usados para compor sistemas podem pertencer a um domínio que é, por si só, digno de estudo. A figura a seguir, tirada de [LMFS96], ilustra esse princípio.

Domínios Horizontais e Verticais do Exército dos EUA

Essa figura mostra as principais famílias de sistemas, Sistemas de Informações, Comando & Controle e Sistemas de Armamentos, cada um com alguns domínios verticais inteiramente contidos e alguns domínios horizontais que interceptam os verticais e também as famílias de sistemas. Assim, os conceitos de Planejamento em Tempo Real são aplicáveis ao Domínio Tático de Comando & Controle e a todos os domínios verticais de Sistemas de Armamentos. Isso provavelmente faz sentido quando é necessário resolver problemas de programação em tempo real para todos esses domínios ao mesmo tempo e tratar o conhecimento e os ativos desenvolvidos como um domínio separado, que tenha uma associação com Conflitos Eletrônicos, por exemplo, mas não com Sistema de Informações Pessoais.

Conteúdo

A Arquitetura de Referência possui a mesma forma do Produto de Trabalho: Documento de Arquitetura de Software e dos modelos associados, desprovida de referências específicas de projeto ou com referências e características de projeto genéricas, a fim de que a Arquitetura de Referência possa ser classificada corretamente na base de recursos. Os modelos típicos associados ao SAD (Software Architecture Document) são um Modelo de Caso de Uso, Modelo de Design, Modelo de Implementação e Modelo de Implementação.

O acesso ao SAD e aos modelos associados fornece vários pontos de entrada para o arquiteto de software, que pode optar por usar somente as partes conceituais ou lógicas da arquitetura (se a política de reutilização da organização permitir isso). Por outro lado, o arquiteto de software pode ser capaz de extrair da base de ativos subsistemas funcionais completos e um Modelo de Implementação no nível físico (ou seja, uma planta de hardware e de rede completa).

Outros produtos de trabalho de suporte são necessários para tornar utilizáveis os recursos arquiteturais. 

1. O Modelo de Casos de Uso descreve o comportamento da arquitetura, mas o arquiteto de software também precisará conhecer suas qualidades não-funcionais. O Modelo de Caso de Uso e os requisitos não funcionais podem ter sido capturados anteriormente em uma Especificação de Requisitos de Software. A partir dessa especificação, o arquiteto de software será capaz de determinar se a Arquitetura de Referência está atendendo satisfatoriamente ou não aos requisitos atuais.

2. O uso e, mais especificamente, a modificação da arquitetura precisam ter a mesma orientação do desenvolvimento original. Por exemplo, o arquiteto de software precisará saber quais regras foram aplicadas na formação da Arquitetura de Referência e o grau de dificuldade que ele experimentará para modificar as interfaces. O acesso às diretrizes de design associadas à Arquitetura de Referência pode ajudar a responder essas perguntas.

3. (Opcional) A revisão de todos os planos de teste relevantes já existentes também pode ser útil. Esses Planos de Teste informarão ao arquiteto sobre as estratégias de teste e de avaliação anteriormente usadas para testar arquiteturas similares que, como tal, podem vir a fornecer uma idéia das possíveis deficiências da arquitetura.

4. (Opcional) A revisão de todas as arquiteturas de automação de teste existentes e relevantes e das especificações da interface de teste pode ser útil. Esses produtos de trabalho informam ao arquiteto sobre as solicitações que provavelmente serão feitas com relação à arquitetura para facilitar o teste.

A menos que o sistema seja completamente sem precedentes, as Arquiteturas de Referência devem ser examinadas para fins de aplicabilidade (quanto ao domínio e ao tipo de desenvolvimento), caso elas existam e possam ser acessadas pela organização de desenvolvimento. A criação de Arquiteturas de Referência é uma questão a ser abordada no nível organizacional. Com certeza, é possível diminuir a lista de conteúdo fornecida anteriormente e, ainda assim, conseguir tirar algum proveito da reutilização arquitetural. Por exemplo, o modelo de teste pode ser omitido, embora os testes tenham de ser escritos novamente caso a arquitetura seja modificada. No mínimo, pode-se esperar um modelo de design e uma descrição comportamental associada (talvez o Modelo de Casos de Uso). É difícil chamar de recurso uma Arquitetura de Referência, visto que poderia ser um tipo de padrão válido.