A metodologia ICONIX

A metodologia ICONIX é baseada no Processo Unificado, e como este é iterativo e incremental. Ela é orientada por casos de uso e busca a modelagem por um conjunto mínimo de diagramas UML, porém deixa em aberto a possibilidade de selecionar outros aspectos da UML para suplementar este material básico. É um processo enxuto e robusto voltado para trabalho em grupos com poucos integrantes e desenvolvimentos de tamanho pequeno e médio. Ele esta representado pela Figura 4-4.

Dentro do processo ICONIX um dos primeiros passos é a criação de um modelo de casos de uso. Os casos de uso são usados para capturar os requisitos de alto nível do sistema segundo a visão do usuário. Eles também são utilizados como unidade de trabalho, entrega e estimativa da evolução do desenvolvimento do sistema. O levantamento dos casos de uso é uma técnica onde o usuário descreve suas expectativas de forma geral e normalmente pouco precisa, é, portanto segundo este aspecto um processo informal de modelagem. Este modelo substitui a tradicional especificação funcional, (Jacobson,1992), e responde a questão “O que o sistema deve fazer, para qual usuário?” A captura dos requisitos dos usuários é feita pelo detalhamento dos cursos típicos de eventos em cenários de interação entre os usuários e o sistema.

Como é uma metodologia orientada por casos de uso significa que se deve escrever o manual do usuário primeiro, e só então escrever o código. Esta prática reforça a noção fundamental de que um sistema deve se conformar às necessidades dos usuários, em vez de seus usuários terem que se conformar ao sistema (Rosenberg e Scott, 2001). É importante que o usuário participe ativamente da determinação dos casos de uso e que faça ao final uma revisão e validação destes casos. Erros nesta etapa podem se mostrar críticos e terem um custo muito alto se forem detectados tardiamente. A participação dos usuários traz segurança aos desenvolvedores uma vez que parte da responsabilidade sobre o sucesso ou fracasso depende deste trabalho conjunto. Tendo em mente que está lidando com informações validadas pelo usuário, parte das preocupações dos desenvolvedores pode ser transferida para questões que realmente necessitem de maior esforço.

A modelagem do domínio do problema é a tarefa de descobrir classes que representem as principais coisas e conceitos do sistema e seus inter relacionamentos. O termo domínio do problema refere-se à área que abrange as coisas do mundo real e os conceitos relacionados ao problema para o qual o sistema esta sendo projetado para resolver. Nesta tarefa, para a obtenção das classes e seus relacionamentos, faz-se o uso da análise gramatical da declaração em alto nível do domínio do problema, requerimentos de baixo nível e do conhecimento especialista do problema. A partir desta atividade há a proposição do modelo do domínio que é uma representação inicial do modelo de objetos do sistema. Este modelo vai sendo refinado conforme o projeto evolui, e novos objetos vão sendo incluídos até constituir o modelo de objetos final representado pelo diagrama de objetos. A modelagem do domínio revive a análise gramatical também utilizada por Rumbaugh (1994) em seu método OMT (“Object Modeling Technique”).

Figura 4-4 – Diagrama esquemático do processo ICONIX, Fonte Rosenberg e Scott, 2001

Esta metodologia utiliza técnica para, a partir dos casos de usos descobrir os objetos que compõem o sistema classificando-os em objetos limites, entidades, e controladores esta técnica é denominada modelagem de robustez (Scott, 2001). Os objetos limites são aqueles com os quais

os atores interagem, por exemplo, as telas. As entidades são as classes que irão armazenar as informações do sistema e formam a estrutura do sistema. Os controladores fazem a conexão entre os demais e entre si, eles usualmente servem como apresentação de funcionalidades e comportamento do sistema requerido pelos casos de uso. As regras para a implementação deste modelo são: Os atores do sistema somente podem se comunicar com os objetos limites, os objetos limites só podem se comunicar com os controladores e atores, as entidades só podem se comunicar com os controladores, e os controladores podem se comunicar com outros controladores, entidades e objetos limites, mas não com os atores. Esta técnica faz uma ligação entre a análise, “o que”, e o projeto “como”, refinando os casos de uso e o modelo. Com a análise de robustez busca-se o refinamento e padronização dos casos de uso e do modelo do domínio, e como é um esboço do modelo dinâmico do sistema diminui o tempo da construção dos diagramas de seqüência. Esta técnica se torna de mais valiosa quando os casos de uso são grandes.

Na fase de projeto, onde se determina “como” realmente o software irá atuar faz-se a modelagem através de diagramas de seqüência. Um diagrama de seqüência mostra uma interação, isto é, uma seqüência de mensagens trocadas entre vários objetos num determinado contexto. Este diagrama enfatiza a comunicação e a passagem de controle entre os objetos ao longo do tempo. A partir dos casos de uso busca-se determinar a interação entre os objetos em uma linha do tempo definindo quais objetos são responsáveis por quais comportamentos. Desta forma é possível distribuir as operações entre as classes. Para cada unidade do comportamento dentro do caso de uso, devem-se identificar as mensagens e os métodos necessários. Uma mensagem é uma comunicação entre objetos (emissor e receptor) que veicula informação na expectativa de provocar uma resposta, é representada por uma seta horizontal, do emissor para o receptor, com nome e possíveis argumentos. Os tipos de mensagens são síncronos e assíncronos. As mensagens síncronas são àquelas em que o emissor fica parado esperando a resposta do receptor, corresponde tipicamente à chamada de operação ou procedimento no receptor. Nas mensagens assíncronas o emissor não fica parado a espera de uma resposta, corresponde tipicamente a envio de sinal entre objetos concorrentes.

Esta metodologia utiliza intensivamente os diagramas de seqüência para guiar a implementação. Com estes diagramas determinam-se claramente os objetos a comunicação entre

eles, as principais seqüências de ação, e as principais operações a serem implementadas nas classes.

Neste processo há uma intensa interação com o modelo de objetos, de forma que ele vai sendo atualizado conforme as operações vão sendo alocadas às classes. Ao final é criado o diagrama de classes.