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).
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).
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.
O conceito de teste de software pode ser compreendido através de uma visão intuitiva ou mesmo de uma maneira formal. Existem atualmente várias definições para esse conceito. De uma forma simples, testar um software significa verificar através de uma execução controlada se o seu comportamento corre de acordo com o especificado. O objetivo principal desta tarefa é revelar o número máximo de falhas dispondo do mínimo de esforço, ou seja, mostrar aos que desenvolvem se os resultados estão ou não de acordo com os padrões estabelecidos.
A atividade de teste é composta por alguns elementos essenciais que auxiliam na formalização desta atividade. Esses elementos são os seguintes:
...
