quinta-feira, setembro 20, 2007

Análise Arquitetural no RUP e OpenUP / Série Análise e Design - Parte 2

Conforme visto no artigo anterior (parte 1) da série Análise e Design, trataremos agora acerca da atividade Análise Arquitetural (Architectural Analysis em inglês).

Pode-se resumir a atividade de análise arquitetural como um primeiro esboço feito pelo aquiteto de software acerca da possível solução (ou soluções) a ser dada tecnicamente para atender os requisitos e necessidades levantados e descritos formalmente pelo analista de sistemas no documento de Visão e no primeiro esboço(outline) dos casos de uso.

Agora uma análise da descrição de seus passos (steps) principais (Observação: Cada atividade do RUP pode ser dividida em um ou mais passos. Esses passos são os elementos mais granulares em termos de tarefas no RUP. Esse é o nível mais detalhado que a equipe e o gerente de projetos podem chegar ao fazer o plano de uma iteração do projeto RUP).

- Desenvolver a Visão Geral da Arquitetura: Esse passo é o primeiro esboço e análise da possível arquitetura candidata que pode ser adotada. Essa etapa é aquela em que o arquiteto fará uso de toda a sua experiência e também da experiência e artefatos já implementados na organização e fará um breve esboço da visão de implantação. A visão de implantação nada mais é que a primeira tentativa de elaborar um diagrama de implantação (deployment diagram) do sistema. Exemplo: O arquiteto pode decidir que o sistema usará o ambiente J2EE já existente na organização. Portanto ele esboça em uma ferramenta de modelagem os componentes da plataforma J2EE que provavelmente usará para elaborar o sistema. Lembrem que esse é apenas o primeiro esboço. Essa análise é feita na fase de Iniciação ou bem no início da primeira iteração de Elaboração. Lembrem que esse esboço de arquitetura será refinado em atividades posteriores.

- Avaliar os Recursos Disponíveis: Nesse passo o arquiteto verifica na empresa ou no mercado quais componentes, bibliotecas, frameworks, sistemas e códigos já existem e que poderão ser reutilizados para o sistema. Esse passo deve ser revisto várias vezes durante o projeto, especialmente nas iterações da fase de Elaboração.

- Definir as camadas (layers) do sistema: Nesse ponto o arquiteto deve definir as camadas do sistema. É importante lembrar que esses passos não são estanques. Eles podem ser revistos no decorrer do projeto. Mas, de preferência, as camadas (assim como a arquitetura como um todo) devem estar estáveis até o final da última iteração da fase de Elaboração.

- Identificar as Abstrações-Chave: Essa interessante atividade é aonde o arquiteto analisa os requisitos e monta o primeiro diagrama de classes do sistema. Esse diagrama de classes é ainda conceitual. Ele só possui as classes e seus nomes. Essas classes identificadas são apenas as principais entidades de negócio de um sistema: Exemplo: em um sistema de leilão teríamos cliente, leilão, lance, lote, etc.

- Desenvolver a Visão Geral da Implantação: nesse passo o arquiteto poderá detalhar ainda mais o diagrama de implantação e descrever os recursos de hardware e software necessários para o funcionamento da aplicação.

- Identificar os Mecanismos de Análise: Primeiramente o conceito rápido de mecanismos de análise: mecanismos de análise são representações abstratas de soluções necessárias para resolver um problema determinado de uma aplicação. Um exemplo clássico: suponha que a aplicação necessite armazenar, recuperar e alterar dados que ficam gravados por um longo período de tempo (um clássico em aplicações corporativas). Para resolver esse problema terei que usar um mecanismo de persistência de dados. Nessa atividade só identificamos o mecanismo de análise. Posteriormente veremos que este se traduzirá em mecanismo de design e de implementação. Mas só para não ficar confuso veja o exemplo completo:

Mecanismo de Análise: Persistência

Mecanismo de Design: Banco de Dados Relacional

Mecanismo de Implementação: Oracle

Para que então existe esse passo? Ele é um jeito disciplinado do arquiteto documentar as soluções arquiteturais que irão resolver o problema de negócio. Ao documentar o mecanismo em um nível de análise fica mais fácil depois avaliar diversas soluções que possam solucionar o mecanismo. Desse modo o arquiteto de software pode, usando o documento de arquitetura de software, justificar em termos qualitativos e quantitativos suas decisões e escolhas de componentes, frameworks e plataformas.

O mais comum em nossa área é que essas decisões arquiteturais sejam tomadas intuitivamente e informalmente. Mesmo que haja maior formalidade na escolha esta muitas vezes não é descrita e documentada para uso futuro. A idéia do RUP e do OpenUP de definir mecanismos como forma de documentar as soluções que serão usadas para resolver um problema formaliza de uma maneira excelente essas decisões. Do meu ponto de vista, o uso dos mecanismos de análise, design e implementação são essenciais para facilitar e formalizar os debates e o entendimento acerca do porquê de se usar determinadas soluções para o projeto. Além disso é um dos passos fundamentais a ser realizado pelo arquiteto. Não esqueça que o resultado das deliberações será descrito no artefato "Documento de Arquitetura de Software".

Mais alguns exemplos de mecanismos de análise:

- comunicação entre processos
- interface gráfica de usuário
- acesso a dados
- roteamento de mensagens
- troca e conversão de informações
- segurança
- detecção e tratamento de erros
- redundância
- interface a sistema legado
- geração de logs
- distribuição de objetos
- gerenciamento de transações
- sincronização e controle de processos

Caso tenham alguma dúvida sobre essa atividade deixem um comentário que responderei assim que puder. Assim teremos um histórico em cada parte dessa série acerca das atividades de análise e design.

Nosso próximo artigo tratará da atividade de análise de caso de uso (Use Case Analysis em inglês). Até a próxima!!!

Marcadores: , , ,

2 Comentários:

At 3:05 PM, Blogger Stefan_Oliveira disse...

Olá José, primeiramente quero parabenizar pela qualidade do material apresentado. Excelente abordagem de um tópico bastante incomum (pelo menos não tenho visto muitas abordagens como a sua). Gostaria de saber se, além das descrições no "Documento de Arquitetura de Software", há alguma outra formalização das especificações relacionadas a aspectos arquiteturais, como representações gráficas, por exemplo.
[]'s.
P.S.: Aguardo ansiosamente os próximos posts dessa seqüência.

 
At 5:19 PM, Blogger José Paulo Papo disse...

Olá Stefan,

Os outros artigos tratarão das representações gráficas feitas usando a UML 2. Algumas delas inclusive podem constar do documento de arquitetura de software.

 

Postar um comentário

Links para este artigo:

Criar um link

<< Home


Veja as Estatísticas