JugManaus

http://www.jugmanaus.com

Construindo Softwares com Qualidade e Rapidez Usando ICONIX

Jos Anzio Maia Este tutorial aborda as principais fases de construo de softwares de forma rpida e com qualidade atravs do processo de desenvolvimento de software ICONIX. Introduo Fazer software hoje em dia no fcil, cada vez mais os programas esto se tornando complexos, os problemas fceis j foram resolvidos e possvel encontr-los em vrios portais gratuitamente, porem, os problemas que hoje tentamos resolver, atravs da implementao de um software, se tornaram complexos e sofisticados, por exemplo, antigamente a micro empresa do seu Joaquim tinha um sistema de folha de pagamento, um sistema de controle de estoque, um sistema de contas a pagar etc. Hoje, por questes de integridade dos dados, eficincia, rapidez nas informaes etc., os sistemas esto integrados e conseqentemente sua complexidade aumentou. Com isso, podemos perceber o quanto importante planejar, projetar e avaliar o software que ser construdo. Isso pode ser feito atravs de um processo de desenvolvimento de software. A quem se destina este Artigo? Este artigo est destinado as pessoas que tem algum interesse em Engenharia de Software e desejam saber mais sobre os processos de desenvolvimento de sistemas. Somente recomendvel ter noo de UML. Isso facilitar bastante para assimilar a proposta do ICONIX. O que um processo de desenvolvimento de software? So etapas cuidadosamente planejadas onde o sucesso de cada etapa primordial para produtos com qualidade, baixo custo e rapidez na construo, ou seja, pode possibilitar bom resultado final no produto de software. Nem sempre foi assim, com o surgimento do software como forma de agilizar o trabalho, controlar informaes, armazenar dados, reduzir custos, etc. para as empresas e rgos governamentais no mundo inteiro, criou-se um novo mercado de trabalho e oportunidade de negcio. Mas, o processo de desenvolvimento de software era verdadeiramente um caos, as organizaes criavam softwares de qualquer jeito e os clientes aceitavam sem reclamar de nada, mesmo porque no sabiam como se concebia softwares. Agora a realidade diferente, existe concorrncia, altos custos e o cliente esta super exigente. No inicio da dcada de 90, verificou-se o nascimento de uma srie de metodologias de desenvolvimento de software. Isto devido ao envolvimento de vrios engenheiros de software, que conseguiram visualizar as vantagens de usarem essas metodologias quando os compararam com os diversos processos existentes at ento. A ordem agora controlar, ter o domnio desde os primeiros rabiscos da idia at o produto final, poder prever todos os possveis problemas que possam impedir o sucesso do projeto. Mas como conseguir isso? Claro que no fcil, mas tambm no impossvel, basta ter fora de vontade e selecionar o processo adequado de acordo com o tipo de projeto e segui-lo a risca.

Grupo de Usurios Java http://www.guj.com.br Pgina 1

JugManaus
http://www.jugmanaus.com

Observao Existem vrios processos de desenvolvimento de software, cada um com suas caractersticas, mas, cabe ao gerente de projeto escolh-lo. Essa escolha deve ser feita de acordo com as caractersticas do projeto e o que se espera para o resultado final. Por exemplo: um sistema em que a vida de pessoas esteja em risco (sistema de trafego areo) no pode permitir falhas, nesse caso, ter o controle detalhado de todas as fases deve ser uma obsesso pela equipe, um software de grande porte, um software de mdio ou pequeno porte, tempo, custo tambm so outros pontos que devem ser levados em considerao ao selecionar um processo de desenvolvimento de software, ou, simplesmente voc pode usar um processo que a empresa onde voc trabalha o obrigue a usar. O que ICONIX ICONIX considerado uma metodologia pura, prtica e simples, mas tambm poderosa e com um componente de anlise e representao dos problemas slido e eficaz, por isso, a metodologia ICONIX caracterizada como um Processo de Desenvolvimento de Software desenvolvido pela ICONIX Software Engineering. O ICONIX um processo no to burocrtico como o RUP, ou seja, no gera tanta documentao. E apesar de ser um processo simples como o XP, no deixa a desejar na Anlise de Design, e se destaca com um poderoso processo de anlise de software. Isso poder ser visto posteriormente nos tpicos seguintes. Este processo tambm faz uso da linguagem de modelagem UML e possui uma caracterstica exclusiva chamada Rastreabilidade dos Requisitos (Traceability of Requirements), mais precisamente, ele nos permite obrigatoriamente atravs de seus mecanismos, verificar em todas as fazes, se os requisitos esto sendo atendidos. A abordagem do ICONIX flexvel e aberta, isto , se for necessrio usar outro recurso da UML para complementar os recursos usados nas fases do ICONIX, no h problema algum. O ICONIX composto pelas seguintes principais fazes das quais entraremos em detalhes nos prximos tpicos: Modelo de Domnio Modelo de Caso de Uso Anlise Robusta Diagrama de Seqncia Diagrama de Classe

Grupo de Usurios Java http://www.guj.com.br Pgina 2

JugManaus
http://www.jugmanaus.com

Este processo dividido em dois grandes setores, que podem ser desenvolvidos em paralelo e de modo recursivo. Os modelos so: Modelo Esttico e o Modelo Dinmico como mostra a Figura 1:

Figura 1: viso macro do ICONIX

O Modelo Esttico formado pelos Diagramas de Domnio e o Diagrama de Classe que pertencem diviso esttica por modelarem o funcionamento do sistema sem nenhum dinamismo e interao do usurio, ou seja, o posto do Modelo Dinmico que sempre mostra o usurio interagindo com o sistema atravs de aes onde o sistema apresenta alguma resposta ao usurio em tempo de execuo. O modelo esttico dever ser refinado incrementalmente durante as iteraes sucessivas do modelo dinmico. No exige marcos formais de projeto para o refinamento, isso feito de forma natural durante o projeto. A proposta do ICONIX permite um alto grau de Rastreabilidade. Em cada fase ao longo do caminho necessrio rever os requisitos em algum momento. No existe um ponto em que o processo permite distanciar dos requisitos do usurio. Rastreabilidade tambm significa encontrar novos objetos em cada fase durante o projeto. O processo ICONIX trabalha a partir de um prottipo de interface onde se desenvolvem os diagramas de caso de uso baseado nos requisitos do usurio. Com base nos diagramas de caso de uso se faz anlise robusta para cada caso de uso e com os resultados obtidos, possvel desenvolver o diagrama de seqncia e posteriormente, povoar o modelo de domnio j revisado com mtodos e atributos descobertos.

O uso da interface como ponto de partida

Grupo de Usurios Java http://www.guj.com.br Pgina 3

JugManaus
http://www.jugmanaus.com

O modelo de caso de uso criado a partir de um prottipo de interface validado pelo usurio de acordo com os requisitos do sistema. O objetivo da interface no codificao do sistema e pode ser feito usando qualquer ferramenta ou tecnologia mesmo que esteja longe da realidade do sistema proposto pelo cliente. No ICONIX, os sistemas so concebidos a partir da viso do usurio para com o sistema, por isso o uso de um prottipo construdo na presena do cliente de acordo com suas necessidades. O uso desta interface possibilita ter maior garantias que os requisitos esto sendo atendidos e uma viso maior do sistema e conseqentemente maior controle. O Modelo de Domnio O Modelo de Domnio uma parte essencial do processo de ICONIX. Ele constri uma poro esttica inicial de um modelo que essencial para dirigir a fase de design a partir dos casos de uso. Basicamente o modelo de domnio consiste em descobrir objetos de um problema do mudo real. Transferir os problemas do mundo real para um diagrama nem sempre fcil, mas, com bastante treino e experincia, nossa capacidade de abstrao tende a melhorar. Para realizar o modelo de domnio, preciso tentar descobrir o maior nmero possvel de classes existentes no problema para qual se pretende desenvolver o software. Claro que modelo de domnio no retratar o cenrio completo adequando para o problema que se pretende resolver, algumas classes sero excludas e outras sero encontradas ou modificadas etc. Isso faz parte do processo de desenvolvimento de softwares. Construindo o Modelo de Domnio: 1. A primeira coisa que temos a fazer ao construir um modelo esttico do sistema achar classes apropriadas que com preciso representam as reais abstraes do domnio de problema. Devemos executar bem est atividade, pois assim teremos uma base slida para construir o sistema. 2. Destacar todos os substantivos e frases que contenham substantivos, analisar e refinar esta lista gradualmente, pois substantivos e frases de substantivo se tornaro objetos e atributos, enquanto que verbos e frases de verbo se tornaro associaes. Casos possessivos como (seu, nosso e seus) tendem a indicar ser substantivos, mas, devem ser atributos no lugar de objetos. 3. Revisar a lista de classes em busca de ambigidades, irrelevncia, classes incorretas ou vagas e itens desnecessrios, algumas vazes mesmo que sejam substantivos possvel que estejam fora do escopo do problema. 4. Fazer generalizao quando necessrio, devemos tomar cuidado com generalizao, verificar se realmente existe uma relao de generalizao e garantir que esteja de acordo com o mundo real. Verifique se for o caso de existncia de agregao ou composio e aplique no modelo. 5. Finalmente revise este diagrama, com ateno em associaes e generalizaes, pois, este diagrama ser a base para o diagrama de classe. Ex: suponhamos que queremos construir um software bancrio onde um dos requisitos seria que os clientes pudessem abrir uma conta, os clientes podem ser pessoas fsicas ou jurdicas. De posse
Grupo de Usurios Java http://www.guj.com.br Pgina 4

JugManaus
http://www.jugmanaus.com

destas informaes, j poderamos comear um modelo de domnio simples, ento o diagrama poderia ficar assim: (ver Figura 2).

Figura 2: exemplo de modelo de domnio

Erros mais comuns na construo do Modelo de Domnio O principal objetivo do Modelo de Domnio e descobrir objetos e associaes, portanto, detalhes de cada objeto e sua multiplicidade deve ser omitida. Geralmente alguns erros so cometidos durante a construo do Modelo de Domnio: 1- No se apressar em usar multiplicidades e associaes, pois, ainda no temos informaes suficientes e provavelmente isso causar paralisia de anlise, ou seja, ser perda de tempo tentando descobrir detalhes e se descobri-los provavelmente sero alterados. 2- No fazer anlise exaustiva analisando substantivos e verbos, pois melhor ter um nvel de abstrao correto ao invs de um nvel de detalhe alto e no garantido. Essa uma boa tcnica, mas devemos ter cuidado com exageros e no levar to a srio. 3- No tentar descobrir operaes para as classes do modelo de domnio, pois, no temos informaes suficientes para isso, melhor esperar pela anlise robusta e o diagrama de seqncia. 4- No tentar construir o Modelo de Domnio pensando em reutilizao de cdigo, prefira primeiramente atender os requisitos do usurio. 5- No perder tempo em dvidas quanto agregao e composio para as partes da associao, prefira agregao que mais simples, agregao contra composio so detalhes posteriores. 6- No construir o modelo pensando em alguma estratgia de implementao ou tecnologia que representem algum compromisso tecnolgico especfico, exemplo: servidores, bancos relacionais, assuntos de implementao ou de licena etc. 7- No usar nomes difceis para as classes. Procurar usar nomes bvios e legveis, isso ser bom para todo o time de projeto. 8-Se for modelar usando um legado, cuidado ao trazes as classes e seus relacionamentos para o modelo esttico, apesar do banco de dados ser uma grande fonte de classes, existem muitos atributos e operaes que no iro fazer parte do modelo.

Grupo de Usurios Java http://www.guj.com.br Pgina 5

JugManaus
http://www.jugmanaus.com

9- No usar padres de projeto prematuramente; devemos nos preocupar em atender os requisitos do usurio, o uso de padres deve ficar mais claro durante a anlise robusta, portanto, agora no hora para isso.

O Modelo de Caso de Uso Este modelo usado para representar as exigncias do usurio seja um sistema novo (partindo do nada) ou baseado em um sistema j existente. Ele deve detalhar de forma clara e legvel, todos os cenrios que os usurios executaro para realizar alguma tarefa. Construindo o Modelo de Caso de Uso: 1. Identificar tantos quantos casos de uso pudermos, descrever cada caso de uso detalhadamente com clareza e sem ambigidades, manter um ciclo de refinamento de texto contnuo. comum durante a descrio encontrar novos casos de uso. 2. Se j existe um sistema legado, o manual do usurio uma grande fonte de casos de uso. 3. Para cada caso de uso, refinar o texto tendo certeza que oraes esto claras e bem descritas, o formato bsico do texto substantivo-verbo-substantivo, e os potenciais atores e objetos de domnio so fceis identificar. 4. Atualizar o modelo de domnio, pois comum encontrarmos novos objetos e isso pode influenciar na compreenso do problema previamente modelado. 5. Durante a descrio dos casos de uso procurar definir claramente os cursos de ao bsicos (realizao da ao pelo usurio) e os cursos alternativos (algo que impea o curso de ao bsico). 6. Verificar se todos os casos de uso atendem as necessidades funcionais desejadas no sistema. 7. Verificar se para cada caso de uso foi descrito o curso bsico de ao e o(s) curso(s) alternativo(s). Ex: esse um exemplo de descrio de caso de uso e o diagrama para o exemplo proposto no modelo de domnio (Figura 3).
Curso Bsico O usurio entra com as informaes necessrias do cliente no sistema. O sistema valida o cadastro do cliente. Armazena os dados do cliente Uma conta criada em nome do cliente. O sistema notifica o usurio sobre o cadastro. Se o cadastro foi bem sucedido, o sistema exibe uma mensagem de confirmao. Curso Alternativo - se o cliente j estiver cadastrado no sistema do banco, uma mensagem ser exibida. Curso Alternativo - se os dados estiverem incompletos o sistema dever bloquear o cadastro Exibir uma mensagem para que o usurio fornea as informaes completas.

Grupo de Usurios Java http://www.guj.com.br Pgina 6

JugManaus
http://www.jugmanaus.com

Figura 3: diagrama de caso de uso

Erros mais comuns na Descrio de Caso de Uso O principal objetivo do Modelo de Caso de Uso e descobrir a maior quantidade possvel de casos de uso e descrev-los detalhadamente e verificar se os mesmos atendem aos requisitos do sistema. Geralmente alguns erros so cometidos durante a construo do Modelo de Caso de uso: 1- No escrever requisitos funcionais em vez de escrever texto de argumento de uso. Os requisitos geralmente so declarados dentro de condies do que o sistema dever fazer, enquanto que argumentos de uso descrevem uma ao do usurio e a resposta que o sistema gera. Eventualmente, o texto de descrio ser usado como run-time comportamental e este texto servir de apoio para o diagrama de seqncia. Ns precisamos ver como sistema executar o comportamento desejado como descrito no texto de caso de uso, para isso, precisamos diferenciar descrio de uso (comportamento) e requisitos do sistema. 2- No descrever atributos e mtodos em lugar de uso. O texto no deve incluir muitos detalhes de apresentao, mas tambm deve ser relativamente livre de detalhes sobre os campos de telas. No deveriam ser nomeados mtodos ou descrev-los no texto de caso de uso porque eles representam como o sistema far coisas, ao invs do que o sistema far. 3- No escrever os casos de uso muito concisamente. prefervel escrever texto para casos de uso expansivos. preciso descrever todos os detalhes de aes de usurio e respostas de sistema. Isso servir para uma boa anlise robusta. Tambm bom lembrar que os casos de uso serviro para construir o manual de usurio. melhor errar por excesso de detalhe na documentao de usurio. 4-No ignorar o prottipo de interface. Na orientao a casos de uso fundamental o uso de telas para construir o sistema a partir da viso do usurio para com o sistema. No descrever casos de uso sem ser especficos sobre como as aes do usurio executaro em suas telas, no precisa descrever nome de campos nem aparncia das telas. 5- No evitar nomes explcitos para os objetos de interface. Objetos de interface so os objetos com que os atores iro interagir. Estes freqentemente incluem janelas, telas, dilogos e menus. Devemos manter amplo detalhe incluindo e sendo explcito sobre navegao do usurio, submetemos ns que necessrio nomear os objetos interface no contesto explicitamente no texto de caso de uso. Tambm importante fazer isto porque estaremos explorando o comportamento destes objetos durante anlise robusta, e poderemos reduzir ambigidade e confuso ao nomelos.

Grupo de Usurios Java http://www.guj.com.br Pgina 7

JugManaus
http://www.jugmanaus.com

6- No escrever os textos na voz passiva, usando uma perspectiva diferente do usurio. Um caso de uso mais eficaz escrito da perspectiva do usurio como um jogo de frases e verbos no presente em voz ativa. A tendncia dos engenheiros em usarem voz passiva muito grande, mas casos de uso deveriam declarar as aes que o usurio executa, e as respostas do sistema para essas aes. Este tipo de texto s efetivo quando expresso na voz ativa. 7- No escrever somente iteraes do usurio, no ignorar as respostas do sistema para as aes. A narrativa de um caso de uso deveria ser evento - resposta, como em: "O sistema faz isto quando o usurio fizer aquilo". O caso de uso deveria capturar uma transao boa do que acontece a respeito ao que o ator est fazendo, se o sistema cria objetos novos, valida usurio, gera mensagens de erro ou tudo que for possvel. Lembrando que o texto de caso de uso descreve ambos os lados do dilogo entre o usurio e o sistema. 8- No omitir texto para cursos alternativos de ao. Cursos bsicos de ao so geralmente mais fceis identificar e descrever. Porm, isso no significa que devemos ignorar detalhes dos cursos alternativos. Longe disto. Na realidade, muito importante quando cursos alternativos e de ao so descobertos, pois do contrrio, quando forem codificar e depurar, o programador responsvel por escrever o cdigo tende a trat-los de modos que so muito convenientes para ele. Isto no saudvel para um projeto. 9- No devemos focalizar o texto em algo diferente de uma descrio de caso de uso. No escrever texto com informaes desnecessrias somente porque em um livro ou artigo foi publicado. 10- No perder muito tempo pra decidir em usar esteretipos include e extends.

O Modelo de Anlise Robusta Est fase tem como objetivo, conectar a parte de anlise com a parte de projeto (ver Figura 4) assegurando que a descrio dos casos de uso esto corretas, alm de descobrir novos objetos atravs do fluxo de ao. A Anlise Robusta focaliza construir um modelo analisando as narrativas de texto de caso de uso, identificando um conjunto de objetos que participaro de cada caso de uso. Estes objetos podem ser classificados em trs tipos como mostra a Figura 5.

Figura 4: conecta a fase de anlise com a fase de design.

Grupo de Usurios Java http://www.guj.com.br Pgina 8

JugManaus
http://www.jugmanaus.com

Tipos de Objetos da Anlise Robusta:

1.

2. 3.

Objetos Limite ou interface (Boundary Objects) usado pelos atores (por exemplo, os usurios) para se comunicarem com o sistema. A maioria dos objetos interface podem ser vistos no prottipo de interface. Objetos Controladores (Control Objects) - so objetos que controlam a lgica de negcio, eles fazem a conexo entre os objetos interface e objetos entidade. Objetos entidade (Entite Objects) so responsveis para realizar algum tipo de persistncia. Geralmente eles vm do modelo de domnio.

Figura 5: representao dos objetos limite/interface, controlador e entidade.

A anlise robusta um modelo simples, mas, uma tcnica extremamente til para anlise, uma fase primordial e tem vrios papeis dentro do ICONIX. Construindo o Modelo de Anlise Robusta: 1. Durante a anlise robusta, ser possvel encontrar problemas na descrio dos casos de uso e, portanto, ns seremos obrigados a corrigi-los. Ao final desta fase, teremos o modelo de caso de uso refinado. O mesmo acontecer para o modelo esttico. 2. Devemos ter certeza que os casos de uso foram descritos corretamente e esto de acordo com as funcionalidades do sistema, caso contrrio, a anlise robusta nos ajudar a corrigir estes problemas. 3. Durante a anlise robusta ser necessrio que todos os cursos bsicos e alternativos tenham sido identificados, caso contrrio, devemos voltar aos casos de uso de identificlos. A anlise robusta tambm ajudara nesse processo. 4. Se for necessrio, devemos perder bastante tempo neste modelo, pois, ele servir para construo do diagrama de seqncia. Caso este modelo no esteja de acordo com a realidade ou mal feito, no ser possvel prosseguir para o diagrama de seqncia. 5. Durante a construo do modelo robusto, ser possvel encontrar objetos novos no identificados anteriormente no modelo de domnio, e possveis problemas de discrepncia ou conflito entre objetos antes que eles causem maiores problemas. 6. A anlise robusta a ponte entre a fase de anlise e a fase de projeto, portanto, ao concluir este modelo, ns estaremos partindo para os detalhes de projeto. 7. Qualquer pessoa deve ser capas de rastrear um diagrama robusto de acordo com a descrio do texto de caso de uso.

Grupo de Usurios Java http://www.guj.com.br Pgina 9

JugManaus
http://www.jugmanaus.com

8. A maioria das pessoas no escreve casos de uso corretamente na primeira vez, ento se tiver excesso ou falta de informao, o diagrama robusto ir ajudar a identificar essas falhas. 9. Refinar o modelo esttico continuamente com os novos objetos encontrados e se alguns atributos importantes foram descobertos hora de ir povoando nossas classes mais importantes com eles. 10. Se for o caso de usar algum padro de projeto hora de aplicar no diagrama robusto. Regras para uso dos objetos na anlise Robusta: 1. 2. 3. 4. Atores somente podem se comunicar com objetos interface. Objetos interface somente podem se comunicar com atores e controladores. Objetos entidade somente podem se comunicar com objetos controladores. Objetos controladores somente podem se comunicar com objetos entidade e interface, tambm com outros controladores, mas no com atores.

Ex: elaborando o modelo de anlise robusta para o exemplo proposto no modelo de domnio no qual j foi feita a descrio de caso de uso e o diagrama de caso de uso. Esse diagrama poderia ser de acordo com a Figura 6:

Figura 6: exemplo de diagrama robusto

Grupo de Usurios Java http://www.guj.com.br Pgina 10

JugManaus
http://www.jugmanaus.com

Erros mais comuns na construo do Modelo de Anlise Robusta O Modelo de Anlise Robusta tem vrios papeis dentro do ICONIX como, por exemplo, criar um diagrama Robusto de acordo com a descrio do caso de uso, refinar o modelo esttico, refinar a descrio dos casos de uso, identificar novos objetos. Geralmente alguns erros so cometidos durante a construo do Modelo Robusto: 1- No violar as quatro regras do Diagrama de Anlise Robusta listados acima. Estas regras garantem coerncia com os testos de casos de uso e que os objetos no iro receber responsabilidades erradas. 2- Usar a anlise robusta para ajudar a dar um formato consistente para os textos de casos de uso, melhorando a redigibilidade e a manutenibilidade. 3- Incluir cursos alternativos no diagrama de anlise robusta. A maioria dos comportamentos interessante acontece nos curso alternativo, assim bom modelar esses comportamentos. comum encontrar cursos alternativos novos, especialmente quando os objetos controladores so explorados em verificar e validar informaes. 4- Usar anlise robusta para assegurar consistncia entre o nome das classes e do texto de descrio dos casos de uso. Isso tambm ser til ao construir bons diagramas de seqncia. 5- No colocar comportamento de classes no diagrama robusto.No devemos nomear mtodos a classes em um diagrama robusto, porque provvel que no tenha bastante informao. Devemos tomar decises sobre comportamento seqencial para cada fluxo. 6- No incluir poucos controladores. bom ter entre dois e cinco controladores em um diagrama robusto, se tiver apenas um controlador em um diagrama robusto, provavelmente no foi bem descrito o comportamento do caso de uso. Por outro lado, se tiver mais de dez controladores em um caso de uso, bom quebrar este caso de uso para melhor manejo. 7- No perder tempo para detalhar diagrama robusto e torn-lo perfeito, pois seu objetivo no detalhamento de projeto e sim ter uma viso geral do problema, descobrir novos objetos, alocar atributos refinar o texto de caso de uso. Se detalharmos demasiadamente o diagrama robusto, poderemos perder seus benefcios. O detalhamento deve ficar para o diagrama de seqncia. 8- Fazer um rastro visual do diagrama robusto de acordo com o texto de caso de uso. O esquema deve estar de acordo com o texto e o texto de acordo com os requisitos do sistema. No devemos considerar os casos de uso concludos at que esteja finalizado a anlise robusta e que ele passe no teste de rastreabilidade visual. 9- Atualizar o modelo esttico. Temos que atualizar o modelo de domnio antes de considerar concludo a anlise robusta e passar ento para o diagrama de seqncia. Pois no podemos alocar comportamento a classes que no aparecem no modelo esttico.

Grupo de Usurios Java http://www.guj.com.br Pgina 11

JugManaus
http://www.jugmanaus.com

O Diagrama de Seqncia O Diagrama de Seqncia tem como objetivo construir um modelo dinmico entre o usurio e o sistema. Para tal, devemos utilizar os objetos e suas interaes identificadas na anlise robusta, s que agora, temos por obrigao o detalhamento de cada fluxo de ao. Teoricamente isso j possvel, pois, uma vez concludo o modelo de domnio (diagrama de classe de alto nvel) e anlise robusta, ns, teremos descoberto a maioria dos objetos no contexto do problema e definido alguns atributos e relaes estticas entre objetos no diagrama de classe de alto nvel e algumas relaes dinmicas na anlise robusta. Estas conquistas representam passos largos para um bom resultado. Construindo o Diagrama de Seqncia: Agora hora de projetar como o software realmente ir funcionar. O modelo de interao fase onde construmos as linhas de ao entre objetos. Agora comeamos a ver como o sistema executar comportamentos teis. Durante a construo do modelo de interao, ns devemos alcanar as seguintes metas primrias: 1- Alocar comportamentos entre os objetos interface, controlador e entidade identificados durante a anlise robusta. Isso permitir realizar o comportamento desejados para os casos de uso. Se tiver difcil identificar os objetos e seus comportamentos, nesse caso melhor retornar a anlise robusta e ter certeza que os fluxos esto corretos. 2- Mostrar as interaes detalhadas que ocorrem na linha de tempo entre os objetos associados com o texto de caso de uso. Os objetos interagem mandando mensagens (chamadas) uns aos outros. Uma mensagem estimula um objeto a executar alguma ao desejada. Para cada comportamento de um caso de uso, temos que identificar as mensagens necessrias e os mtodos. 3- Finalmente devemos povoar o diagrama de classe distribuindo as operaes entre os objetos. Quando se termina a anlise robusta possvel ter identificado a maioria dos atributos dentro do modelo esttico. 4- Uma vez concludo o modelo de interao, ns teremos bastantes informaes e poderemos dispor de comportamento detalhado do esquema de seqncia entre objetos no contexto de seus respectivos casos de uso. Podemos finalizar procurando e alocando apropriadamente atributos e operaes. 5- medida que vamos progredindo no modelo de interao, devemos atualizar o modelo esttico. Isso tambm ajuda a compreender melhor como o sistema dever se comportar.
6-

Dentro do ICONIX, o diagrama de seqncia representa o artefato principal do produto de design, devemos construir o diagrama de seqncia de acordo com o curso bsico e alternativo de para cada caso de uso.

7- O resultado que o modelo de interao deve apresentar a essncia do modelo dinmico no qual exibe o comportamento do sistema em tempo de execuo de forma detalhada.

Grupo de Usurios Java http://www.guj.com.br Pgina 12

JugManaus
http://www.jugmanaus.com

Um Diagrama de seqncia composto por quatro componentes: 1- O texto que descreve os fluxos de ao para os caso de uso o texto deve estar do lado esquerdo das linhas de ao dos objetos, bom separar o texto com uma linha em branco entre os fluxos de ao, assim, fica fcil ver cada linha de ao e sua descrio. 2- Os objetos que interagem entre si os objetos so extrados da anlise robusta e so formados por dois componentes: o nome do objeto (opcional) e a classe a qual ele pertence, todos ficam no topo do diagrama dentro de uma caixa da qual desce uma linha pontilhada. 3- Mensagens - mensagens so setas entre objetos. Uma seta de mensagem pode ir diretamente entre duas linhas pontilhadas, entre uma linha e um mtodo de um retngulo, ou entre dois mtodos de um retngulo. 4- Mtodos ou operaes so mostrados em cima das linhas a qual pertencem os objetos. Quatro passos para montar o Diagrama de Seqncia:
1-

Copiar o texto de especificao do caso de uso no lado direito do diagrama. O texto serve como uma lembrana continua do que necessrio fazer. O resultado que quando se est fazendo o design, o comportamento requerido sempre est diante de nossos olhos e se no foi definido todos os cursos alternativos pertinentes as aes do curso bsico para cada caso de uso, ento melhor no continuar at que eles estejam identificados, caso contrrio os diagramas no cobriro todos os casos especiais e no ser possvel descobrir tudo sobre o comportamento dos casos de uso. Isto significa que no ser possvel descobrir todos os mtodos necessrios para os objetos.

2- Adicionar os objetos entidade do diagrama robusto. Cada um destes objetos um exemplo de classe que deve estar no diagrama de classe que representa o modelo esttico. Lembrando que j era para estar atualizado o diagrama de classe com os novos objetos encontrados na anlise robusta, se isso no foi feito, podemos fazer agora. Estes objetos esto com a maioria dos atributos encontrados, mas possvel encontrar novos atributos perdidos durante a construo do diagrama de seqncia. Devemos ser meticulosos ao acrescentar algo no diagrama de seqncia, pois, este o ultimo passo antes da codificao. 3- Adicione os objetos interface do diagrama de anlise robusta. 4- Alocar os mtodos em suas respectivas classes adequadamente. Isso envolve converter os controladores do diagrama robusto, um de cada vez, aos conjuntos dos mtodos e mensagens que envolvem o comportamento desejado. Ocasionalmente um controlador pode se tornar um objeto real de controle.

Grupo de Usurios Java http://www.guj.com.br Pgina 13

JugManaus
http://www.jugmanaus.com

Ex: este um exemplo de como ficaria o diagrama de seqncia pra o exemplo dos tpicos anteriores (Figura 7).

Figura 7: diagrama de seqncia

Grupo de Usurios Java http://www.guj.com.br Pgina 14

JugManaus
http://www.jugmanaus.com

Erros mais comuns na construo do Diagrama de Seqncia O Diagrama de Seqncia tem como papel principal mostrar o funcionamento do sistema em tempo de execuo, para tal, preciso realizar a troca de mensagens entre os objetos seguindo a descrio do caso de uso que deve estar no diagrama de seqncia. Geralmente alguns erros so cometidos durante a construo do diagrama de seqncia: 1- No fazer um diagrama de seqncia para cada caso de uso. preciso mostrar os objetos e a responsabilidade de cada um. 2- No colocar o texto de caso de uso no diagrama de seqncia. O texto permite a Rastreabilidade dos requisitos do sistema, de modo que no tem como no seguir as necessidades do sistema visto que sua descrio est face a face com o projetista e cada mensagem deve corresponder a uma ao. 3- No identificar todos os objetos necessrios no diagrama robusto. Se tiver ocorrendo paralisia de anlise (no est conseguindo fazer o diagrama de seqncia) provavelmente h problemas com diagrama robusto, ento devemos voltar e se certificar que ele esteja seguindo corretamente a descrio de caso de uso. 4- No prover um rastro visual entre as setas de mensagens e o texto de caso de uso. Cada seta de mensagem deve esta alinhada com a descrio de sua ao, isso torna mais fcil a compreenso para qualquer pessoa que tentar ler o diagrama e garante a rastreabilidade dos requisitos e identificar possveis problemas. 5- No mostrar em detalhes a realizao do caso de uso. Um diagrama de seqncia com nvel de abstrao muito elevado pode prejudicar na codificao do sistema, o diagrama de seqncia a ultima etapa antes da codificao, portanto devemos abusar dos detalhes. 6- Transformar o diagrama de seqncia em um fluxograma ao invs de alocar comportamentos entre objetos. O diagrama de seqncia a fase onde se deve tomar decises de projeto muito importantes, alocar comportamento nas classes corretamente, isso pode tornar o projeto bom ou ruim. 7- No focalizar os mtodos mais importantes (mostrem o real funcionamento do sistema) e gastar tempo em definir mtodos get() e set(). Devemos explorar o comportamento dinmico do sistema, alocar atributos mtodos as classes. 8- No pensar cuidadosamente na origem das setas de mensagens, em outras palavras qual objeto est no controle em determinado momento. Mensagens entre objetos so operaes entre classes, por isso, elas devem estar bem definidas no diagrama de seqncia. O fluxo entre as mensagens deve ser bvio e mostrar qual objeto est no controle. 9- No seguir os princpios bsicos da orientao a objeto. Um objeto atravs da extenso de uma classe deve ter uma nica responsabilidade. Isso quer dizer que uma classe deve ser focalizada em um comportamento relacionado a sua existncia. Isso tambm ser til para Reusabilidade. Portanto, antes de alocar um mtodo a um objeto, devemos nos perguntar se este comportamento esta realmente de acordo com as funes daquele objeto. 10- Atualizar o modelo esttico transformando-as em diagrama de classe agrupadas em pacotes de caso de uso. Nesse momento estaremos trocando o espao do problema pelo espao da soluo do problema.
Grupo de Usurios Java http://www.guj.com.br Pgina 15

JugManaus
http://www.jugmanaus.com

O Diagrama de Classe O diagrama de classe o modelo de domnio que foi atualizado ao longo das fazes do ICONIX e representa as funcionalidades do sistema de modo esttico sem a interao do usurio com o sistema. Os objetos banco e agncia (ver figura 8) no foram includos no diagrama de seqncia e na anlise robusta para no complicar os exemplos, mas somente para nvel de abstrao, devemos saber que uma agncia deve ter um relacionamento de composio com a classe banco, ou seja, a classe agncia somente existe se a classe banco existir. Se tivssemos que modelar o requisito usado como exemplo neste artigo em um caso real, teramos que fazer algumas alteraes em todos os diagramas que foram usados como exemplo, essas mudanas seriam em relao a detalhes que foram omitidos tambm para no complicar os exemplos. Por exemplo, o diagrama robusto usado como exemplo neste artigo no uma boa prtica de modelagem, nele poderamos incluir pelo menos mais um objeto controlador e um objeto interface. Devemos observar que o sexto item dos erros mais comuns na elaborao do diagrama robusto acusa erro em caso e se usar apenas um controlador por diagrama.

Figura 8: diagrama de classe

Codificao O ICONIX considera a fase de codificao fora de sua rea de anlise, por considerar subjetiva para o desenvolvimento correto do sistema que se deseja construir. A fase de codificao na atividade de produo do sistema final responsvel pela correta traduo dos artefatos produzidos para um produto de software correto e estruturado. O produto deve refletir as funcionalidades requeridas identificadas durante a construo dos diagramas. Obviamente para qualquer tarefa de codificao, ser necessrio especificar que aps desenvolver as utilidades necessrias para estabelecer a ligao entre os diversos objetos, uma bateria de testes

Grupo de Usurios Java http://www.guj.com.br Pgina 16

JugManaus
http://www.jugmanaus.com

devera ser aplicada no sistema para verificar se o mesmo est de acordo com as operaes desejadas e resultados esperados.

Grupo de Usurios Java http://www.guj.com.br Pgina 17

JugManaus
http://www.jugmanaus.com

Concluso Podemos observar durantes os tpicos deste artigo, como possvel ter controle no desenvolvimento de um software. Ter controle total de um sistema a ser construdo pode ser determinante para o resultado final de um projeto, portanto, sempre bom que as organizaes adotem algum processo de desenvolvimento de software. O ICONIX uma sugesto de processo de desenvolvimento de software. Este artigo no uma referncia completa, mas podemos mostrar a essncia do ICONIX, suas principais caractersticas como rastreabilidade de requisitos que um processo natural que ocorre durante todas as fases. O seu poderoso mecanismo de anlise tambm um bom ponto a ser elogiado e levado em considerao. Como na vida nem tudo so flores, h tambm os espinhos, existe alguns problemas nessa metodologia como, por exemplo, o fato do ICONIX se afastar bastante da fase de codificao. Faz sentido a filosofia empregada por esse sistema (a codificao deve retratar o que foi produzido durante as fases de anlise), mas, no devemos esquecer que um processo sozinho no faz nada, preciso que pessoas o executem, e bom lembrar que nenhum ser humano esta livre de falhas. Logicamente que se todos os artefatos produzidos durante as fases que compe o ICONIX estiverem retratando clara e detalhadamente o comportamento do sistema, no h mais nada a fazer a no ser codificar e testar. Isso levanta a hiptese que os engenheiros de sistemas que elaboraram essa metodologia esto certos de que ao final do projeto de anlise, os artefatos produzidos esto retratando perfeitamente o que o sistema dever fazer. Jos Anzio Pantoja Maia (gorran4@hotmail.com / anizio_maia@yahoo.com.br) formado em Sistemas de Informao, certificado em Java atualmente trabalha com desenvolvimento de dispositivos mveis usando a Plataforma Java Micro Edition e um dos fundadores do JugManaus (http://www.jugmanaus.com).
Referncias: http://www.iconixsw.com/Spec_Sheets/Uml2.html http://pst.web.cern.ch/PST/HandBookWorkBook/Handbook/SoftwareEngineering/UCDOM_summary.html http://www.dca.fee.unicamp.br/cursos/EA976/2s2002/referencia.html#iconix

Grupo de Usurios Java http://www.guj.com.br Pgina 18