Introdução ao Iconix - Revista SQL Magazine 94

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."