Neste artigo será apresentada uma introdução ao Iconix, um processo de desenvolvimento de software baseado no RUP, mas que usa um número reduzido de artefatos e checkpoints. Descreveremos as suas principais características e detalharemos cada uma de suas fases.
Em que situação o tema útil:
Este artigo é útil para desenvolvedores de software que usam a UML como linguagem de modelagem, mas que não utilizam o RUP por considerá-lo pesado e burocrático e ainda não possuem uma metodologia de desenvolvimento que seja fácil de aplicar, bastante prática e com passos bem definidos.
Resumo DevMan
A UML foi criada em meados da década de 90 e atualmente é a linguagem de modelagem mais usada pela indústria de software. No entanto, o RUP, o mais famoso processo de desenvolvimento que a aplica, é considerado por muitos como impraticável por exigir uma excessiva documentação. Neste artigo apresentaremos uma metodologia chamada Iconix, que por meio de um subconjunto dos artefatos e práticas do RUP, torna a vida dos desenvolvedores que utilizam à UML bem mais fácil.
O processo Iconix começou a ser desenvolvido em 1993 por Doug Rosenberg com o objetivo de mesclar os melhores aspectos das três mais famosas metodologias orientada a objetos vigentes na época (Booch, OMT e Objectory) e que posteriormente formaram a base da UML (ler Nota DevMan 1).
Nota DevMan 1. Orientação a Objetos
A orientação a objetos surgiu com a necessidade de se criar um paradigma de programação simples baseado na percepção humana dos objetos ao seu redor. Este novo paradigma não é apenas um modo de programar, mas uma maneira de pensar e conceber as ideias. Neste paradigma, o software é composto por uma coleção de objetos que interagem entre si através de mensagens, simulando as ações que ocorrem no mundo real.
A partir dos conceitos do paradigma orientado a objetos é possível fazer uma análise dos requisitos do sistema, investigando as entidades que o compõem. O sistema pode ser quebrado em unidades de objetos e a partir daí é possível entender como eles se relacionam. Nesta etapa será feita a análise de requisitos para serem construídos modelos que representem o sistema.
O importante é o que será feito, sem se preocupar em como será feito, desprendendo-se de qualquer tipo de tecnologia. O sistema assim precisa ser validado e verificado, para ter certeza de que os requisitos atendem as necessidades do cliente.
Em um processo de desenvolvimento orientado a objetos, o resultado da analise são modelos que representam as estruturas das classes de objetos componentes e modelos que especifiquem as funcionalidades do sistema. A ênfase está em achar e descrever objetos (ou conceitos) no domínio do problema. Por exemplo, num sistema acadêmico alguns dos conceitos poderiam ser “aluno”, “matricula”, “curso”.
A utilização deste mecanismo possibilita não somente à equipe de desenvolvimento o entendimento do problema. Como este paradigma aproxima o mundo real do computacional, ele traz também como benefício uma melhor interpretação do cliente quanto ao documento de requisitos especificado.
O Iconix se apresenta como uma metodologia prática, simples, intermediária entre a complexidade do RUP (Rational Unified Process) e a simplicidade do XP (Extreme Programming), mas sendo ao mesmo tempo poderosa para guiar a análise e projeto orientado a objetos. Entre suas características principais podemos destacar:
- Utiliza um subconjunto da UML: apenas 4 diagramas, os que são realmente necessários, ao invés dos 14 diagramas existentes atualmente;
- Minimiza a paralisia da análise: ignora palavras confusas do padrão UML tais como << extends >>, << includes >>, etc que não adicionam valor algum a essa etapa e que retardam a passagem da análise para o projeto;
- Possui alto grau de rastreamento: todos os requisitos são associados a casos de uso e classes, que por sua vez formam o eixo de sustentação de todo o processo;
- É iterativo e incremental: várias iterações ocorrem entre o desenvolvimento do modelo de domínio e a modelagem dos casos de uso, enquanto que o modelo estático é incrementalmente refinado pelo modelo dinâmico;
- É baseado nas questões fundamentais da orientação a objetos: o que fazem os usuários? (casos de uso); quais os objetos do mundo real? (modelo de domínio); quais os objetos relacionados com os casos de usos? (robustez); como os objetos colaboram entre si? (sequência); como realmente será construído o software? (classes).
Como podemos ver no diagrama apresentado na Figura 1, o processo Iconix é dividido em um fluxo dinâmico, para representar os aspectos comportamentais do software, e outro fluxo estático, para expressar os aspectos estruturais do software. Esses fluxos andam em paralelo e possuem quatro fases: a fase de requisitos, onde são utilizados protótipos de interface e os diagramas de casos de uso e de classe de alto nível (também conhecido como modelo de domínio); a análise e projeto preliminar, na qual é utilizado o diagrama de robustez e o modelo de domínio é refinado; o projeto detalhado, onde é modelado o diagrama de sequência e no qual ocorre o refinamento final do modelo de domínio, tornando-se um diagrama de classes; e a implementação, na qual há a codificação e a escrita de testes (ler Nota DevMan 2).
Nota DevMan 2. Teste de Software
Teste de software é o processo de execução de um produto para determinar se ele atingiu suas especificações e funcionou corretamente no ambiente para o qual foi projetado. O seu objetivo é revelar falhas em um produto, para que as causas dessas falhas sejam identificadas e possam ser corrigidas pela equipe de desenvolvimento antes da entrega final. Por conta dessa característica das atividades de teste, dizemos que sua natureza é “destrutiva”, e não “construtiva”, pois visa ao aumento da confiança de um produto através da exposição de seus problemas, porém antes de sua entrega ao usuário final."
[...] continue lendo...