Fases

Um pouco mais sobre o ICONIX

ICONIX Process é um processo de desenvolvimento de software que vem evoluindo desde o início da década de 90, tendo Doug Rosenberg como principal idealizador. Muita coisa mudou no mundo da Engenharia de Software desde aquela época. A UML foi consolidada como linguagem de modelagem de sistemas orientados a objetos e o Processo Unificado (cuja mais famosa implementação é o RUP - Rational Unified Process), destaca-se como o principal processo de desenvolvimento de software a utilizar a UML.

No final da década de 90 e início dos anos 2000, um novo grupo de Metologias de Desenvolvimento de Software começou a surgir e em 2001, com a publicação do Manifesto Ágil, tais metodologias passaram a ser chamadas de Metodologias Ágeis. O ICONIX também evoluiu afim de incorporar características que o permitissem ser adaptado a projetos ágeis, ou seja, em um ciclo de vida iterativo e incremental.

Quando utilizado em um ciclo de vida iterativo e incremental, cada iteração do projeto a ser desenvolvido e que servirá de atualização ao incremento anterior, conterá as fases descritas abaixo.

Obs.: os processos são classificados como sendo dinânimcas como: diagramas de sequencia e estática como o diagrama de classe.

Requisitos

Como entrada para o processo, é necessário ter em mãos os requisitos funcionais do sistema a ser desenvolvido. O ICONIX não define claramente como os requisitos devem ser levantados ou documentados. Algumas abordagens utilizam a criação dos esboços das interfaces gráficas do sistema (storyboards) ou da iteração em questão. Outras abordagens utilizam descrição textual dos requisitos.

Com os requisitos em mãos, pode-se identificar o Modelo de Domínio, ou seja, um diagrama de classes sem atributos nem operações, apresentado as principais entidades que serão manipuladas pelo sistema.

Através dos requisitos também será possível identificar os casos de uso do sistema. os casos de uso constituirão a ponte entre os requisitos e a implementação do sistema, portanto, para o ICONIX, é extremamente importante para o processo descobrir os casos de uso de forma a representar com fidelidade os requisitos do sistema.

Ao final da fase de requisitos, verifique que o texto dos casos de uso (fluxo de eventos) represente com fidelidade os requisitos ditados pelo cliente.

Obs.: Se for utilizar  o ciclo de vida iterativo e incremental, a fase de requisitos deverá mapear apenas os requisitos que serão implementados na iteração.

Análise e projeto preliminar

Para cada caso de uso identificado na fase de requisitos, devemos criar um diagrama de robustez baseado no texto do caso de uso (fluxo de eventos). Pode, também, surgir a necessidade de reescrever o texto do caso de uso. O diagrama de robustez não é um diagrama padrão da UML. No ICONIX, esse diagrama é utilizado para descobrir as classes de análise e detalhar, em alto nível, o funcionamento básico do caso de uso.

Nessa fase devemos  em paralelo ao diagrama de robustez, atualizar o modelo de domínio e adicionar os atributos às entidades identificadas. Inclua também as novas classes de projeto identificadas nessa fase.

Ao final da fase de análise e projeto preliminar, verifique a consistência dos artefatos gerados, ou seja, do projeto preliminar. Se realmente necessário, atualize a fase de requisitos com eventuais alterações identificadas aqui.

Projeto detalhado

Para cada caso de uso, devemos criar um diagrama de sequência de forma a detalhar a futura implementação do caso de uso. O diagrama de sequência deverá conter as classes que realmente serão implementadas, ou seja, as classes de projeto. As mensagens enviadas entre os objetos deverão corresponder aos métodos que realmente serão implementados.

Atualize o modelo de domínio com as operações encontradas no diagrama de sequência. Inclua também as novas classes de projeto identificadas, criando o diagrama de classes final do seu sistema (ou da iteração).

Reveja o projeto do sistema (ou da iteração) de forma crítica, fazendo com que ele fique aderente à tecnologia que será utilizada para a implementação.

Implementação

O ICONIX não é muito voltado à fase de implementação, pois isso depende e varia muito conforme a tecnologia escolhida. O importante nesse fase é não esquecer sempre de estar atualizando os diagramas de modelo de domínio, de caso de uso entre os outros caso haja algum tipo de alteração. Abaixo segue uma imagem extraída do site do ICONIX Process sugerindo a implementação como uma fase do ICONIX.

Exemplo de Implementação.

AS Fases do ICONIX são constituídas por:

• Modelo de Domínio;

• Modelo de Caso de Uso;

• Análise Robusta;

• Diagrama de Sequência;

• Diagrama de Classe.

Modelo de Domínio

Segundo Bona (apud Rosenberg & Scott, 1999), o modelo de domínio é a tarefa de se descobrir objetos que representam coisas e conceitos do “mundo real”.

É considerada uma tarefa essencial do processo no auxílio da fase de design a partir dos casos de uso. Consiste em descobrir todos os objetos do mundo real de um determinado problema. Para construir o modelo de domínio, é importante encontrar o maior número de classes possíveis existentes no problema.

Para se construir um bom modelo de domínio, recomenda-se seguir as seguintes fases:

a. Primeiramente encontrar as classes que representam as abstrações do domínio do problema. Pois estas classes servirão como base para a construção do sistema;
 b.Eliminar classes ambíguas, incorretas e itens desnecessários;

 c. Fazer generalização, se necessário. Aplicar técnicas de composição e agregação, caso existam;

d. Revisar o diagrama construído, analisando principalmente as associações e generalizações.

Exemplo Modelo de Domínio

Modelo de Casos de Uso

É o modelo chave do ICONIX, é ele que irá dirigir todo o processo. Os casos de uso são especificações do comportamento do sistema a partir da descrição das funcionalidades do sistema, ou seja, é uma forma de se chegar às funcionalidades de um sistema de forma centrada no usuário.

O modelo de casos de uso é utilizado para representar as exigências do usuário de um sistema. Este modelo deve declarar de forma clara e legível, todos os cenários que os usuários executarão para realizar uma determinada tarefa.

Para construir um modelo de caso de uso, é importante seguir os seguintes passos:

     a.    Identificar o maior número de casos de uso possível e descrevê-los cada um detalhadamente, com clareza e sem ambiguidades.

    b.    Verificar se os casos de uso atendem aos requisitos funcionais desejados no sistema.

Exemplo Diagrama de Caso de Uso.

Análise Robusta

De acordo com Bona (apud Borillo, 2000), a análise robusta tem por finalidade, conectar a parte de análise com a parte de projeto, assegurando que a descrição dos casos de uso esteja correta. Nesta fase podem-se descobrir novos objetos, que não foram vistos no modelo de domínio.

Segundo Bona (apud Rosenberg & Scott, 1999), a análise de robustez se concentra em construir um modelo analisando as narrativas de texto dos casos de uso, identificando um conjunto de objetos que participarão de cada caso de uso.

Tipos de Objetos:

Tipos de Objetos utilizados no diagrama de Análise Robusta

Diagrama de Análise Robusta

Diagrama de Análise de Robustez.

Diagrama de Sequência:

Segundo Bona (apud Rosenberg & Scott, 1999), o diagrama de sequência é a fase onde são construídas as linhas de execução que unem os objetos e capacitam visualizar inicialmente, como o novo sistema apresentará comportamento útil. Nesta etapa deve-se utilizar objetos e suas iterações identificadas na análise robusta, sendo que agora detalhando cada fluxo de ação.

Até aqui já foram descobertos a maioria dos objetos no contexto do problema e definido alguns atributos e relações entre objetos no diagrama de classe de alto nível. Isto representa um enorme passo para um bom resultado.

Os diagramas de sequência são utilizados para modelar a interação entre os objetos em um sistema no comportamento de um caso de uso, onde os objetos são representados por linhas verticais e a passagem entre dois objetos é representada por vetores horizontais. As mensagens seguem uma sequência cronológica do topo à base do diagrama.

Durante a construção do modelo de interação, algumas metas devem ser alcançadas:

     ·      Alocar comportamentos entre os objetos interface, controlador e entidade identificados anteriormente na análise robusta.

    ·      Mostrar as iterações detalhadas que ocorrem na linha de tempo entre os objetos associados com o texto de caso de uso. Os objetos interagem entre si através de mensagens. Cada mensagem estimula algum objeto a realizar alguma ação. Para cada comportamento de um caso de uso, devemos identificar as mensagens necessárias e os métodos.

    ·      Povoar o diagrama de classes, distribuindo as operações entre os objetos, uma vez que, a maioria dos atributos já foram identificados.

    ·      Após concluir o modelo de interação, já se tem bastante informação, portanto pode-se dispor do comportamento detalhado do esquema de sequência entre objetos no contexto de seus respectivos casos de uso. Finaliza-se então, procurando e alocando apropriadamente atributos e operações.

Dentro do ICONIX, o diagrama de sequência representa o artefato principal do produto de design. O resultado que o modelo de interação deve apresentar, exibe o comportamento do sistema em tempo de execução do sistema de forma detalhada. O diagrama de sequência é composto de quatro componentes:

   a.    O texto que descreve os fluxos de ação para os casos de uso;

   b.    Os objetos que interagem entre si;

   c.     As Mensagens;

   d.    Métodos ou operações.

Diagrama de Sequência.

Diagrama de Classe

O diagrama de classe é o resultado final do modelo de domínio, que foi atualizado durante o processo do ICONIX.

Este diagrama representa as funcionalidades do sistema de modo estático sem a interação do usuário com o sistema. São adicionadas informações detalhadas ao modelo de domínio, com base nos diagramas de sequência que identificam as operações que deverão fazer parte das classes correspondentes.

No diagrama também são mostradas as estruturas internas, que são os atributos e os métodos, juntamente com os relacionamentos entre as classes.

Diagrama de Classe.