Análise e Design: Para que serve e como fazer? - Parte 1

Esse é o primeiro artigo de uma série que explicará de uma forma simples, breve e útil a disciplina de análise e design do Rational Unified Process ( RUP ) e do OpenUP.

A idéia de escrever esses artigos no blog surgiu a partir de uma análise pessoal e empírica. Notei, nas minhas andanças e conversas por muitos projetos de clientes e consultorias diferentes, que a vasta maioria das pessoas que trabalham com Tecnologia da Informação e mais especificamente com o RUP conhecem muito pouco sobre a disciplina de análise e design. Esse é um fenômeno interessante, pois hoje em dia o conceito de casos de uso está sedimentado no mercado de desenvolvimento de software. Da Universidade a grande maioria dos alunos sai com conhecimento sobre o que é um caso de uso e como escrevê-lo. Porém, em relação à disciplina crítica que é a Análise e Design (e que abrange a Arquitetura, falaremos disso mais adiante) vemos que ela é usualmente relegada para segundo plano.

Creio que um dos motivos para esse fenômeno ocorrer é a própria visão dos arquitetos de software. O foco destes profissionais no Brasil é eminentemente técnico. Inclusive o mercado associa à palavra arquiteto a idéia de um profissional sênior com vastos conhecimentos e experiências técnicas em uma ou mais determinadas plataformas. Porém, como iremos mostrar nessa série de artigos, o papel do arquiteto requer um processo para disciplinar e organizar aquilo que ele gera e para agregar realmente valor a um projeto de desenvolvimento de sistemas. Veremos nos artigos que a arquitetura e a análise e design no RUP e no OpenUP não são um monstro de sete cabeças.

Para começar vou passar uma definição mais informal do que é arquitetura de software e para que ela serve. A arquitetura de software nada mais é que "um conjunto de decisões significativas acerca da organização de um software". Alguns exemplos dessas decisões:

- Seleção de elementos estruturais e suas interfaces
- Especificação do comportamento de elementos arquiteturais
- Estilo arquitetural que guia o projeto e a organização
- Seleção de componentes, softwares básicos, frameworks, padrões arquiteturais e de design, ambientes de desenvolvimento e componentes que auxiliem na elaboração do sistema.
- Integrações com outros sistemas e softwares
- Definições de como as soluções atenderão e ajudarão a resolver os requisitos não-funcionais como performance, escalabilidade, usabilidade, internacionalização, suportabilidade, testabilidade, etc.

Pode-se dizer então que a arquitetura envolve uma série de decisões estratégicas em relação à solução a ser dada para resolver uma necessidade de negócio. Essas decisões arquiteturais são fundamentais, pois mudá-las pode gerar impactos profundos. Além disso a arquitetura ajuda a restringir o design e a construção de um software. Portanto, mesmo que um arquiteto faça e tome essas decisões informalmente e não as documente (o que acontece em muitos casos no mercado) ele ainda assim está defindo uma arquitetura.

Sobre o ponto de restringir como será feito o desenvolvimento vale um exemplo: suponha que o arquiteto decida que o sistema usará o Hibernate para realizar a persistência em banco de dados relacional. Essa decisão restringe como os desenvolvedores do projeto farão a persistência. Um deles não pode simplesmente dizer que usará EJB 3 ou JDBC com DAO sem o aval do arquiteto. Isso levaria o projeto ao caos devido ao uso de mais de uma solução de persistência sem um motivo claro. A arquitetura deve se tornar um ponto de estabilidade para a equipe de desenvolvimento. A restrição dessa imaginação do desenvolvedor em relação a componentes adotados é algo bom e não ruim. Essas restrições concentram a imaginação dos desenvolvedores nos aspectos importantes que devem ser resolvidos (como implementar regras de negócio usando os componentes, como converter os requisitos em código e testes na arquitetura definida, etc) e não em decisões estratégicas.

Bom, para uma introdução este artigo está bom! No final do texto você encontrará algumas referências bibliográficas. Na parte 2 trataremos das principais atividades de Análise e Design. Começaremos com a atividade Análise Arquitetural (Architectural Analysis em inglês) e seus passos (steps) principais:

- Desenvolver a Visão Geral da Arquitetura
- Avaliar os Recursos Disponíveis
- Definir as camadas (layers) do sistema
- Identificar as Abstrações-Chave
- Desenvolver a Visão Geral da Implantação
- Identificar os Mecanismos de Análise

Caso tenham alguma dúvida deixem um comentário que responderei assim que puder.

Referências Bibliográficas

Alur, D. et al - Core J2EE Patterns: Best Practices and Design Strategies, Second Edition

Bass, L; Clements, P.; Kazman, R. - Software Architecture in Practice, 2nd Edition (The SEI Series in Software Engineering)

Booch, G. et al - Object-Oriented Analysis and Design with Applications, 3rd Edition

Clements, P. et al - Documenting Software Architectures: Views and Beyond

Eeles, P. et al. - Building J2EE Applications with the Rational Unified Process

Evans, Eric - Domain-Driven Design: Tackling Complexity in the Heart of Software

Fowler, Martin - Refactoring: Improving the Design of Existing Code

Fowler, Martin - Patterns of Enterprise Application Architecture

Freeman, Elisabeth - Head First Design Patterns

Gang of Four - Design Patterns: Elements of Reusable Object-Oriented Software

Hohpe, G; Woolf, B. - Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions

Larman, Craig - Applying UML and Patterns, 3rd Edition

Manassis, Enrico - Practical Software Engineering: Analysis and Design for the .NET Platform

McLaughlin, B.; Pollice, G.; West, D. - Head First Object-Oriented Analysis and Design: A Brain Friendly Guide to OOA&D

Newkirk, James et al. - Enterprise Solution Patterns Using Microsoft .NET. Disponível online na Microsoft

Rozanski, N; Woods, E. - Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives