Metodologia de desenvolvimento de software com ICONIX

Levi Corrêa Tancredo1, Thiago Cesconeto1

1
Especialização em Engenharia de Projetos de Software
Universidade do Sul de Santa Catarina (UNISUL) – Florianópolis – SC – Brazil
{levi.tancredo,thiago.cesconeto}@unisul.br

Abstract. This paper presents the characteristic of operation and flexibility of

the process model of software development with ICONIX, aiming to clarify for
deployment in software development organization.

Resumo. Esse artigo apresenta a característica de funcionamento e

flexibilidade do modelo de processo de desenvolvimento de software com
ICONIX, objetivando esclarecimento para implantação em organização de
desenvolvimento de software.

1. Introdução
As metodologias para desenvolvimento de software vêm ao longo de tempos sofrendo
evoluções, ponto muito positivo para a constante melhoria dos processos, porem um
pouco confuso na escolha de um método. A empresa poderá escolher uma metodologia
burocrática ou liberal, porem o extremismo nunca foi uma ótima prática, dentre esses
processos nasceu o ICONIX uma metodologia que é flexível, exige documentação e em
contrapartida possui foco na codificação. Para Sommerville (1995) a produção de
software é um conjunto de atividades e resultados associados.
Proposto em 2005 por Rosenberg, Stephens e Collins-Cope através de
publicações famosas como Agile Development with ICONIX Process: People, Process
and Pragmatism essa nova metodologia define-se como um processo de
desenvolvimento de software simples e prático.

2. ICONIX
ICONIX é um modelo de processo para desenvolvimento de software iterativo
incremental que possui como objetivo ser uma metodologia prática e intermediária entre
a complexidade do RUP (Rational Unified Process) e a simplicidade do XP (Extreme
Programming), sem que a documentação do projeto seja esquecida. Segundo Maia
(2005), o modelo ICONIX se destaca como eficiente processo de análise de software.
O modelo é dividido em duas visões: Dinâmica e a Estática, onde:
• Dinâmica: Apresenta a interação do usuário com o sistema. Utilizam-se os
seguintes artefatos: Digrama de caso de uso, Digrama de robustez e Diagrama de
sequencia.
• Estática: Mostra o funcionamento do sistema sem nenhum dinamismo e
interação do usuário. Utilizam-se os seguintes artefatos: Modelo de Domínio e
Digrama de Classe
 Figura 1. Visão macro de funcionamento do ICONIX

2.1. Principais Características

Dentre várias características, o ICONIX se destaca com três itens fundamentais:
Interativo e incremental – são realizadas várias iterações durante o desenvolvimento
onde cada incremento fornece uma série de funcionalidades.
Utilização da UML – o método propõe alguns artefatos essenciais, porem se aceita
outros do padrão UML por utilizar a mesma linguagem, fornecendo flexibilidade ao
modelo.
Rastreabilidade – esse é um dos grandes diferenciais da metodologia, pois permite que
se exponha como os diferentes artefatos são relacionados, fornecendo o grau de impacto
que uma alteração pode produzir no projeto. Para Maia (2005) esse recurso permite
checar em todas as fases se os requisitos estão sendo atendidos.

2.1.1. Modelo iterativo incremental

A natureza interativo incremental são como “mini projetos” onde para Scott (2002)
resulta em uma versão do sistema liberada interna ou externamente. Supõe-se que essa
versão ofereça uma melhora incremental sobre a interior, motivo pela qual interação é
chamada de incremento.
 Figura 2. Modelo do processo interativo incremental

Esse modelo é muito recomendado para projetos que possuem problemas

complexos, recursos humanos insuficientes e datas de entregas inflexíveis. Pois
podemos dividir os grandes blocos de problemas em pequenas partes e codificando em
etapas, utiliza melhor os recursos humanos porque permite que cada membro trabalhe
em uma pequena parte do projeto e principalmente permite que o projeto seja
apresentado em versões intermediárias fornecendo ao patrocinador do projeto
visualização palpável e/ou dependendo as funcionalidades finalizadas apresentação de
versões betas.

2.1.2. Linguagem UML

A linguagem UML surgiu para unificar as diversas linguagens que existiam no período
da criação, pois existiam diversas ótimas ideias mas não havia uma linguagem que
possuísse uma metodologia eficaz para os problemas que surgiam no momento do
desenvolvimento de projetos de software. O nome UML vem da sigla de palavras
americanas Unified Modeling Language, traduzindo Linguagem de Modelagem
Unificada. Para Shalloway e Trott (2002) a UML é uma linguagem visual utilizada para
criar modelos de programas, os quais podem ser entendidos como uma representação
diagramática dos programas. Nela podemos ver os relacionamentos entres os objetos no
código.

2.2 Processos
O processo ICONIX trabalha (conforme figura 1) a partir de um protótipo de interface
onde se desenvolvem os diagramas de caso de uso baseado nos requisitos do usuário.
Com base nos diagramas de caso de uso se faz à análise robusta para cada caso de uso e
com os resultados obtidos, é possível desenvolver o diagrama de sequência e
posteriormente, povoar o modelo de domínio já revisado com métodos e atributos
descobertos. O ICONIX é composto pelos seguintes principais diagramas:
• Modelo de domínio;
• Modelo de Caso de Uso;
• Diagrama de Robustez;
• Diagrama de Sequencia;
• Digrama de Classe.

2.2.1. Modelo de domínio

Tem o objetivo de identificar abstrações no mundo real que serão os objetos principais
do futuro sistema, bem como os relacionamentos entre os mesmos. O modelo de
domínio é um digrama de classes em nível de análise de forma simplificada, ou seja,
sem atributos ou métodos. Esta representação não tem pretensão de ser perfeita e
completa, na verdade ao longo do processo esse modelo será revisado diversas vezes até
chegar a um ponto considerado ideal.

Figura 3. Exemplo do modelo de domínio.

2.2.2. Modelo de Caso de Uso

O modelo de caso de uso possui a função de identificar os atores envolvidos do projeto e
as ações que um ator possa executar.
Caso de Uso: é uma sequencia de ações que um ator (pessoa, entidade externa ou outro
sistema) executa no sistema para atingir um objetivo particular.
Ator: Representa um papel que o usuário pode desempenhar no sistema a ser modelado.
 Figura 4. Exemplo do modelo de caso de uso.

2.2.3. Diagrama de Robustez

É a ponte entre a fase de análise e a de projeto, assegurando que as descrições de casos
de uso estão corretas, além de descobrir novos objetos através do fluxo de ação. Para
construir um uma Análise de robustez, utilizamos a narrativa de texto (o detalhamento)
de caso de uso, identificando um conjunto de objetos que participação de cada caso de
uso. São utilizados três tipos de objetos:
• Objeto limite ou interface;
• Objeto de controle;
• Objeto entidade.

Figura 5. Representação dos objetos

 Figura 6. Exemplo do digrama de robustez

2.2.4. Diagrama de Sequência

Para Faria (2001) um diagrama de sequencia mostra a interação, isto é, uma sequencia
de mensagens trocadas entre vários objetos num determinado contexto. Esse diagrama é
baseado no diagrama de robustez que descreve a sequencia particular de funcionamento.

Figura 7. Exemplo do digrama de sequência.

2.2.5. Digrama de Classe

Um diagrama de classes descreve a visão estática do processo. Um dos objetivos do

digrama de classes é definir os atributos e operações permitidas para a codificação. Uma
classe é representada por um retângulo divido em três partes: nome, atributos e
operações, onde:
• Nome – identificador do objeto;
• Atributo – descreve as características do objeto;
• Operações – são utilizadas para manipular os atributos e realizar outras ações.

Figura 8. Exemplo do digrama de classe

Referências
FARIA, João Pascoal. UML – Diagramas de Sequência, 2001. Disponível em: <
http://paginas.fe.up.pt/~jpf/teach/POO/sequencia.pdf > Acesso em 30 de nov 2010.
MAIA, José Anízio. Construindo software com qualidade e rapidez usando ICONIX,
2005. Disponível em: < http://www.guj.com.br/content/articles/patterns/iconix_guj.pdf>
Acesso em 30 de nov 2010.
SCOTT, Kendall. O Processo Unificado Explicado. 1 ed. São Paulo: Pearson Education
do Brasil, 2002.
SHALLOWAY, Alan. TROTT, James R. Explicando padrões de projeto: Uma nova
perspectiva em projeto orientado a objeto. 1 ed. São Paulo: Pearson Education do Brasil,
2002.
SOMMERVILLE, Ian. Engenharia de Software. 6 ed. São Paulo: Pearson Education do
Brasil, 2005.