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: análise e design, OpenUP, RUP, UML
4 Comentários:
Papo
Parabéns pela iniciativa. Estarei acompanhando atentamente os artigos e já estou ansioso para ler o próximo.
Abçs
Olá José!
Gostei do post, quero acompanhar os outros da série.
[ ]´s
Olá José.
Estou aprendendo muito com o seu material. Porém, sinto falta de um exemplo prático de como utilizar o OpenUP de fato. Do início ao fim da concepção de um sistema, como utilizar os artefatos, como armazená-los, como divulgá-los para a equipe de projeto e tudo mais. Poderia ser mesmo em um exemplo simples, como construir uma calculadorea, não sei. Desde já agradeço e parabenizo pelo excelente material.
Abraços!
Parabéns pela iniciativa. O material está muito claro e eu estou aprendendo muito. Obrigado.
Postar um comentário
<< Home