Ê


A cada dia que passa os softwares se tornam mais robustos e com diversas
funcionalidades que antigamente não eram necessárias, conseqüentemente aumentam o tempo
de desenvolvimento, mão de obra empregada, custos, e sem falar que a qualidade exigida é
muito maior ao término do desenvolvimento.
O papel da engenharia de software é de fundamental importância para o processo de
desenvolvimento de sistemas, onde através de suas metodologias podemos destacar que todos
os processos são bem planejados e definidos para acompanhar todo o projeto.
O ICONIX é uma das metodologias de desenvolvimento de softwares a qual
abordaremos nesse trabalho. Falaremos sobre seu surgimento, conceitos, históricos, principais
características e aplicações.

c
 £Ê

Ê
Na década de 90 os engenheiros de software descobriram as vantagens de se utilizar
metodologias para desenvolver softwares em comparação com processos utilizados (Método
de Booch, Método Objectory e Técnica de modelagem de Objetos (OMT)), perceberam que a
existência de um modelo é apontada como um dos primeiros passos em direção ao
gerenciamento e a melhoria do processo, a partir daí surgiram várias metodologias de
desenvolvimento de software.
Dentre tantas outras temos o Iconix desenvolvido em 1993 por Doug Rosemberg e
Kendall Scott da ICONIX Software Engineering, utiliza padrão UML e o seu processo é
interativo e incremental, uniu os pontos fortes de cada método, são eles:
OMT ± Modelo de Objetos do Domínio do Problema;
Objectory ± Modelo de Domínio de Solução dirigida pelo usuário;
Booch ± Modelos a nível de projeto detalhados.

Œ
  Ê

O ICONIX é uma metodologia de desenvolvimento de software que reúne um
conjunto de processos que mostram as visões dinâmicas e estáticas de um sistema que serão
desenvolvidas de maneira incremental.
Sua metodologia é bastante prática e simples, onde podemos defini-la como
intermediária entre a complexidade do RUP (Rational Unified Process) e a simplicidade do
XP (Extreme Programming), porém sem deixar a desejar em nenhum aspecto.
É recomendada para desenvolvimento de softwares de pequeno ou médio porte e não
tem como característica forte a documentação, mas se destaca como um excelente processo de
análise de software.
É importante destacar sua alta performance no aspecto rastreabilidade, seus requisitos
são revistos periodicamente para estarem sempre alinhados com as necessidades do cliente,
sem falar que a cada fase do projeto novos objetos podem ser definidos.













·
Este processo de desenvolvimento possui dois principais setores:
D
 
  
Demonstra o desenvolvimento do sistema sem a participação do usuário, onde é
incrementado durante as interações do modelo dinâmico.Utiliza o Modelo de Domínio e o
Diagrama de Classe.
D
 
  
Demonstra a interação do usuário com o sistema. Utiliza Diagrama de Casos de Uso,
Diagrama de Robustez e Diagrama de Seqüência.

D
   




 

Tem como objetivo identificar os objetos no mundo real e todas as relações que
possam existir entre eles, geralmente se utiliza o diagrama de classe de alto nível que é
definido como ³
 

 ´.

É importante apresentar uma prototipação sucinta da interface do sistema ou alguma

outra forma de visualização que possa mostrar para o cliente as funcionalidades propostas
para o sistema.

Nesta fase também é importante mostrar os diagramas de caso de uso identificando

todos os atores envolvidos no sistema, assim como organizá-los em grupos, onde utilizamos o
³

  ´.

No ICONIX não podemos deixar de citar a diferença entre um  
  que
descreve o comportamento e um  descreve uma regra para tal comportamento.
´
    

Neste processo descrevem-se os casos de uso, com o fluxo principal das ações,
podendo ou não conter o fluxo alternativo e as exceções. Abordamos também a análise de
robustez, onde para cada caso de uso identificamos os objetos do cenário e atualizamos os


.

!  

Através dos diagramas de seqüência atribuímos comportamentos aos casos de uso,

identificando as comunicações entre os diversos objetos, lembrando que se preciso também
utilizamos diagramas de contribuição para mostrar as principais transações entre os objetos.

Deve-se concluir o modelo estático, mostrando particularidades do diagrama de

classes e avaliar se o projeto satisfaz os requisitos identificados.

Ê " 

O ICONIX não oferece um grande suporte para esta fase, pois segundo a maioria dos
autores existem muitas bibliotecas que falam a respeito, sem falar que se precisa escolher a
linguagem para o desenvolvimento que é bem particular dos desenvolvedores, mas ele nos
orienta com algumas dicas para o procedimento, que são:

Produzir diagramas para apoiar na implementação;

Gerar códigos da aplicação;

Realizar testes de unidades e de integração;

Realizar testes de sistema e aceitação.

 
 #

Ê Ê$
D
 
  
É essencial para dirigir a fase de g
 a partir dos casos de uso, basicamente o
modelo de domínio consiste em descobrir objetos de um problema do mudo real, é preciso
tentar descobrir o maior número possível de classes existentes no problema para qual se
pretende desenvolver o

 .
Lembrando que o modelo de domínio não retratará o cenário completo para o problema que se
pretende resolver, algumas classes serão excluídas e outras serão encontradas ou modificadas.


 
% " 
D
 
  
Não tentar descobrir operações para as classes do modelo de domínio, pois, ainda não ha
informações suficientes para isso, é melhor esperar pela análise robusta e o diagrama de
seqüência.
Não tentar construir o Modelo de Domínio pensando em reutilização de código, prefira
primeiramente atender os requisitos do usuário.
Não usar nomes difíceis para as classes. Procurar usar nomes óbvios e legíveis, isso será bom
para todo o desenvolvimento do projeto.
Evitar utilizar design patterns prematuramente; devemos nos preocupar em atender os
requisitos do usuário, o uso de padrões deve ficar mais claro durante a análise robusta.

D
 
 
 

 É um modelo das funções pretendidas do sistema e seu ambiente, e serve como um
contrato estabelecido entre o cliente e os desenvolvedores. O modelo de caso de uso é usado
como fonte de informações essencial para atividades de análise, design e teste.
Este modelo nada mais é do que representar as exigências do usuário, pode ser
utilizado em um sistema novo ou em outro já existente. Ele deve detalhar de forma clara e
objetiva, todos os cenários que os usuários executarão ao término do sistema.

% " 
D
 
 
 
Não descrever atributos e métodos em lugar de uso. O texto não deve incluir muitos detalhes
de apresentação, mas também deve ser relativamente livre de detalhes sobre os campos e
telas.
Não ignorar o protótipo de interface. Na orientação a casos de uso é fundamental o uso de
telas para construir o sistema a partir da visão do usuário para com o sistema. Não descrever
casos de uso sem ser específicos sobre como as ações do usuário executarão em suas telas,
não precisa descrever nome de campos nem aparência das telas.
Não perder muito tempo pra decidir em usar estereótipos ³include´ e ³extends´.

 
Existem vários papeis como, por exemplo, criar um diagrama Robusto de acordo com a
descrição do caso de uso, refinar o modelo estático, refinar a descrição dos casos de uso,
identificar novos objetos.
Esta fase tem o objetivo, integrar a parte de análise com a parte de projeto, assegurando que a
descrição dos casos de uso estão corretas. A Análise Robusta focaliza construir um modelo

U
analisando as narrativas de texto de caso de uso, identificando um conjunto de objetos que
participarão de cada caso de uso.


% " 
D
 
 

Usar a análise robusta para ajudar a dar um formato consistente para os textos de casos de
uso, melhorando a redigibilidade e a manutenibilidade;
Não incluir poucos controladores. É bom ter entre dois e cinco controladores em um diagrama
robusto;
Atualizar o modelo estático. Temos que atualizar o modelo de domínio antes de considerar
concluído a análise robusta e passar então para o diagrama de seqüência. Pois não podemos
alocar comportamento a classes que não aparecem no modelo estático.



 Representa as funcionalidades do sistema de modo estático sem a interação do usuário
com o sistema, descrevem as classes que formam a estrutura do sistema e suas relações. As
relações entre a classe podem ser associações, agregações ou heranças.


&'  

 

l

 

Representa o artefato principal do produto de g
, descrevendo uma seqüência particular
de funcionamento, que tem como objetivo construir um modelo dinâmico entre o usuário e o
sistema exibindo o comportamento do sistema em tempo de execução de forma detalhada,
devemos utilizar os objetos e suas interações identificadas na análise robusta, temos por
obrigação o detalhar cada fluxo de ação.

% " 

 

Não fazer um diagrama de seqüência para cada caso de uso. É preciso mostrar os objetos e a
responsabilidade de cada um;
Atualizar o modelo estático transformando-as em diagrama de classe agrupadas em pacotes de
caso de uso. Nesse momento estaremos trocando o espaço do problema pelo espaço da
solução do problema;
Não focalizar os métodos mais importantes (mostrem o real funcionamento do sistema) e
gastar tempo em definir métodos get() e set(). Devemos explorar o comportamento dinâmico
do sistema, alocar atributos é métodos as classes.

ƒ
  ( 
A
    


  
        



 
 
  
 




  



 
  

 
   


  !
   
      
  "





  
 
#$ %&'  
 



( 
 )
 



*+



 +  ,  


  
 
-.  
 )
 /
  &
 # $ 0A
 

  "



 
 




  

    
#$ 

.  


  
            

 "


  



 
 


1.
$
 

 
"  
 
2