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: , , ,

quarta-feira, setembro 19, 2007

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

Marcadores: , , ,

sábado, setembro 08, 2007

Novas ferramentas livres para gestão ágil de projetos: Mingle e ProjectKoach

Duas novas ferramentas para gerenciamento ágil de projetos foram lançadas no mercado.

A ferramenta ProjectKoach é uma ferramenta leve e gratuita feita especialmente para gerenciar projetos usando o processo OpenUP 1.0. Com a ferramenta ProjectKoach você pode:

- planejar projetos
- gerenciar iterações
- Medir a velocidade da equipe
- Rastrear itens de trabalho a requisitos e outros itens
- Integração com o processo OpenUP e facilidades de editar o processo e alterar também a ferramenta automaticamente
- Guias de processo para analistas e desenvolvedores, que explicam em detalhes as tarefas alocadas.

A única funcionalidade que eu acho que ainda é necessária na ferramenta é a integração com ferramentas de controle de versões como Subversion, CVS, IBM Rational ClearCase, etc.

Vide abaixo uma figura da tela principal da ferramenta:


Faça o download do ProjectKoach e experimente a ferramenta! Você precisa apenas de um JDK do Java. Ela pode se tornar um excelente apoio ao seu projeto e, ainda melhor, sem custo!!!

A ferramenta Mingle foi desenvolvida pela famosa consultoria de projetos ágeis americana ThoughtWorks. Ela é gratuita para até 5 usuários. A partir do sexto usuário deve ser paga uma taxa de licenciamento conforme a tabela de preços.

A ferramenta Mingle está atualmente bem mais completa que o ProjectKoach, porém tem um custo após o sexto usuário. Ela inclusive possue integração com ferramentas de controle de versões e integração entre requisitos, casos de teste, defeitos e riscos.

Uma outra excelente funcionalidade é a capacidade de visualizar os requisitos e tarefas no Mingle como cartões na tela. Vide a imagem de exemplo abaixo:


Faça o download do Mingle e experimente a ferramenta! Você precisa ter o banco de dados MySQL 5 instalado.

Marcadores: , ,


Veja as Estatísticas