sexta-feira, outubro 26, 2007

MaintainJ : Engenharia reversa simples e ágil!

MaintainJ é um plugin para o Eclipse que gera diagramas de sequência e diagramas de classe com base na engenharia reversa.

Qual a sua diferença para outras opções no mercado? A maior de todas é que ela é uma das raras que gera o diagrama de sequência à partir de um cenário de uso da aplicação. De acordo com o RUP seria um diagrama de sequência de um dos fluxos da realização do caso de uso.

Esse processo é feito usando o conceito de engenharia reversa dinâmica. No mercado o mais comum é encontrarmos a engenharia reversa estática. Esta simplesmente lê o código e gera os elementos da UML (normalmente apenas as classes) respectivos. Já a engenharia reversa dinâmica é feita à partir do uso do sistema. Como isso é feito? O código é inicialmente instrumentado (compilado com opções especiais, de forma parecida com a instrumentação feita por ferramentas de cobertura de código). Quando o sistema é executado ele gera logs mostrando o caminho, métodos executados e objetos instanciados. Com base nesses dados é gerado o diagrama de sequência de um cenário.

Essa ferramenta pode ser útil para analisar sistemas em Java sem documentação de design e também em projetos ágeis que necessitam de documentação mas preferem fazer o processo reverso de trnasformação do código para diagramas.

Agora vocês podem imaginar: nossa, quanto custa a facada? Esse é outro ponto positivo do plugin: custa apenas 20 dólares por ano!!!

Marcadores:

quinta-feira, outubro 25, 2007

Esforco das Atividades de Gerência de Projetos para Desenvolvimento de Software

Minha resposta sobre o assunto, a partir de pergunta no grupo CMM-Brasil:

O esforço da gestão pode variar bastante e principalmente de acordo com a complexidade, a quantidade de riscos do projeto, o número de stakeholders, etc.

De acordo com uma tabela do COCOMO II, modificada por Bittner e Spence no livro "Managing Iterative Software Development Projects", para o RUP, temos que se gasta em média para a gestão:

14% do esforço da fase de iniciação

12% do esforço da fase de elaboração

10% do esforço da fase de construção

14% do esforço da fase de transição

Portanto, podemos dizer que a média de esforço em gestão é de 10 a 15% do total de esforço do projeto.

Marcadores:

quinta-feira, outubro 18, 2007

Ponteiros para a série sobre a disciplina de análise e design do RUP e OpenUP

Os artigos dessa série sobre a disciplina de disciplina de análise e design do RUP e OpenUP têm como objetivo dar uma visão geral e um contexto para essas atividades. Assim os desenvolvedores podem ter uma idéia de quando fazer ou não uma atividade e porquê realizá-la. Isso porque o RUP e mesmo o treinamento de OOAD não esclarecem muito bem essas dúvidas essenciais. O RUP acaba se aprofundando nos detalhes e só depois de algum tempo fica mais claro para algumas pessoas como as coisas se encaixam.



Deixem suas dúvidas, sugestões e propostas de novos artigos para mim aqui ou nos outros artigos da série. Seguem abaixo os links para eles:


Análise e Design: Para que serve e como fazer? - Parte 1

Análise Arquitetural no RUP e OpenUP / Série Análise e Design - Parte 2

Análise de Caso de Uso no RUP e OpenUP / Série Análise e Design - Parte 3

Identificação de Elementos de Design no RUP e OpenUP / Série Análise e Design - Parte 4

Identificação de Mecanismos de Design no RUP e OpenUP / Série Análise e Design - Parte 5

Descrição da arquitetura em tempo de execução e descrição da distribuição no RUP e OpenUP / Série Análise e Design - Parte 6

Design do Caso de Uso no RUP e OpenUP / Série Análise e Design - Parte 7

Design de Subsistemas e Design de Classes no RUP e OpenUP / Série Análise e Design - Parte 8

Marcadores: , , ,

Design de Subsistemas e Design de Classes no RUP e OpenUP / Série Análise e Design - Parte 8

Conforme visto no artigo anterior (parte 7) da série Análise e Design, trataremos agora acerca da atividade Design de Subsistemas(Subsystem Design em inglês) e Design de Classes (Class Design em inglês).


Podemos resumir a atividade de Design de subsistemas como aquela aonde detalhamos a estrutura e a dinâmica interna de um subsistema. Lembre-se: um subsistema nada mais é que um conjunto de elementos que fornecem um comportamento através de uma interface definida. Portanto o que temos nessa atividade? Ela é similar ao design de um caso de uso ou à documentação de um mecanismo de design. Portanto para cada subsistema teremos também uma espécie de realização. Dentro desta haverá um diagrama de classes participantes que contém as classes que pertencem ao subsistema e um conjunto de diagramas de interação. Muias pessoas ficam em dúvida de quantos seriam os diagramas de interação. De acordo com o RUP você fará um diagrama de interação(eu prefiro usar o diagrama de sequência) para cada operação contida na interface do subsistema.


Podemos resumir a atividade de Design de classes como aquela aonde detalhamos totalmente uma classe específica. Portanto o lembrete principal é que essa atividade é feita constantemente e diariamente. Não é feita só em um momento específico do projeto e depois esquecida. Os detalhes das classes podem se modificar até o último dia do projeto. Novas operações aparecerão também devido à necessidade de refactorings (poderíamos incluí-lo aqui, apesar de ser pouco comentado no RUP).

Pronto! Teminamos nossa série de análise e design. Espero que todos tenham aproveitado essa visão geral dessa disciplina tão importante do RUP e do OpenUP.




Marcadores: , , ,

Design do Caso de Uso no RUP e OpenUP / Série Análise e Design - Parte 7

Conforme visto no artigo anterior (parte 6) da série Análise e Design, trataremos agora acerca da atividade Design de Caso de Uso (Use Case Design em inglês).


Podemos resumir a atividade de Design de Caso de Uso como aquela aonde os elementos de design se encontram com os mecanismo arquiteturais. É onde se refina a análise de caso de uso (se esta tiver sido feita). No design de caso de uso focamos na solução e, portanto, devemos descrever as interações de forma a capturar como o sistema funciona em sua plataforma específica.

Desse modo, a realização de caso de uso de design terá elementos similares à análise de caso de uso. Ele terá um diagrama de classes participantes e um diagrama de interação para cada fluxo do caso de uso. Qual a diferença? Enquanto a análise de caso de uso fala em classes de análise e em estereótipos de classes de fronteira, de controle e de entidade (boundary, control, entity), o design de caso de uso fala em classes de design como JSPs, EJBs, Factory, COM+, etcs.

Lembre-se da grande "sacada" para reduzir o tamanho dos diagramas de interação. Podemos resumir em dois pontos:

1 - Utilizar os mecanismos de design: desse modo deve aparecer apenas a classe ou interface do mecanismo de design dentro do diagrama de interação.

2 - Utilizar os subsistemas: desse modo deve aparecer apenas a interface do subsistema dentro do diagrama de interação.

Com essas duas sacadas o design de caso de uso será mais enxuto e simples de produzir.

Um ponto importante: lembre-se que a modelagem é uma técnica. Sua equipe ou empresa deve definir como prefere criar a solução. Há empresas que preferirão usar o chamado Model-Driven Development (Desenvolvimento dirigido a modelos) ou MDA (Model-Driven Architecture). Portanto criarão os diagramas e a partir destes gerarão parte do código-fonte (a chamada forward engineering). Já outras preferem primeiro criar o código e depois gerar os diagramas a partir do código-fonte (a chamada reverse engineering ou engenharia reversa). Agora, o que é ruim é você ter os modelos totalmente desassociados do código. Isso gera perda de produtividade e frustração para todos os envolvidos.

Os diagramas são úteis não só para documentação mas também para facilitar as discussões e reuniões sobre arquitetura. A mensagem que quero passar é: use o modo que mais convém à sua equipe ou empresa. De qualquer uma das formas você terá bons resultados pois obterá código E modelos. Por isso é importante ter uma ferramenta de modelagem que realmente faça bem a forward/reverse engineering.

Criar manualmente o código a partir dos diagramas ou criar os diagramas a partir do código realmente são soluções "tiro no pé" e um convite à burocracia e lentidão. Otimize seu processo e tenha o bom dos dois mundos (código e modelos) com produtividade e qualidade usando boas ferramentas de modelagem.

Uma dica final: para quem quiser todos os detalhes da atividade de design de caso de uso e ainda contendo um exemplo de ponta a ponta vide o artigo Getting from use cases to code, Part 2: Use-Case Design do grande mestre Gary Evans. Recomendo fortemente a leitura pormenorizada tanto para arquitetos e desenvolvedores novatos como para os experientes.

No próximo artigo trataremos da atividade de design de subsistemas e design de classes. Até a próxima!!!

Marcadores: , , ,

Descrição da arquitetura em tempo de execução e descrição da distribuição no RUP e OpenUP / Série Análise e Design - Parte 6

Conforme visto no artigo anterior (parte 5) da série Análise e Design, trataremos agora acerca da atividade Descrever a arquitetura em tempo de execução (Describe the Run-Time Architecture em inglês) e da atividade Descrever a distribuição (Describe Distribution em inglês).

Por que trato essas duas atividades em conjunto? Porque nós veremos que uma delas costuma não ser necessária para as atuais aplicações empresariais e a outra é bem simples.

Podemos resumir a atividade de Descrever a arquitetura em tempo de execução como aquela aonde modelamos os processos e threads de uma aplicação e como estes se comunicam. Essa é a atividade que não precisamos na maioria dos casos. Você poderia precisar dela se trabalhar em uma aplicação em que precise controlar explicitamente processos e threads. Como hoje em dia a maioria das aplicações empresariais usam plataformas que fazem esse controle pra gente "por baixo dos panos" (como as plataformas JEE e .NET), então ela é desnecessária. Essa atividade é que cria a famosa "Visão de Processo" do Modelo 4+1 do RUP.

Podemos resumir a atividade de Descrever a distribuição como aquela aonde modelamos os nós físicos nos quais uma aplicação é ou será instalada e configurada e como estes nós se comunicam. Essa atividade é que cria a famosa "Visão de Implantação" (Deployment) do Modelo 4+1 do RUP. Ela possui, basicamente, um ou mais diagramas de implantação (deployment) da UML 2. Essa é uma visão que será necessária para aquelas soluções que precisam de mais de um nó físico para executar (portanto, para uma solução que executa toda em um computador só, como um jogo de computador que não tem opção de conexão com rede ou Internet, ela não é necessária).

E é isso! Lembrando que esses artigos têm como objetivo dar uma visão geral e um contexto para essas atividades. Para que os desenvolvedores tenham uma idéia de quando fazer ou não uma atividade e porquê realizá-la. Isso porque o RUP e mesmo o treinamento de OOAD não esclarecem muito bem essas dúvidas essenciais. Para os detalhes (por exemplo, como criar um diagrama de implantação ou de processos) basta recorrer ao RUP ou ao treinamento de OOAD.

No próximo artigo trataremos da atividade de Design de Caso de Uso. Até a próxima!!!

Marcadores: , , ,

Identificação de Mecanismos de Design no RUP e OpenUP / Série Análise e Design - Parte 5

Conforme visto no artigo anterior (parte 5) da série Análise e Design, trataremos agora acerca da atividade Identificar mecanismos de Design (Identify Design Mechanisms em inglês).

Podemos resumir a atividade de Identificação de Mecanismos de Design como aquela aonde refinamos os mecanismos de análise em mecanismos de design com base nas restrições impostas pelo ambiente de implementação e pela plataforma tecnológica.

A atividade de mecanismos de análise pode ser dividida em dois grandes passos:

1 - Categorizar os clientes dos mecanismos de análise: Neste momento o objetivo é ver quais são os mecanismos de análise que foram identificados durante a análise arquitetural e entender em quais pontos da solução terão que ser utilizados. Dessa forma teremos uma tabela mapeando as classes de análise para os mecanismos de análise que cada uma necessita. Você também pode trocar essa tabela por outra que mapeia os casos de uso para os mecanismos de análise. Se achar necessário você também pode definir características mais específicas de um mecanismo de análise (por exemplo, você pode tentar estimar a média de transações diárias que passarão por um mecanismo de persistência). Essas características ajudarão na escolha da melhor solução específica para o mecanismo de análise identificado.

2 - Documentar os mecanismos de design: Esse passo é o mais importante. Primeiro deve-se identificar um mecanismo de design e implementação que atenda aos requisitos e características definidos na descrição dos mecanismos de análise. Um exemplo para o mecanismo de análise de persistência. Você pode definir que a persistência será feita com um banco de dados relacional Oracle. Como a plataforma tecnológica é o Java e com base nas características do mecanismo de persistência o arquiteto escolhe que usará o Hibernate(poderia ser outro como iBatis, JDBC direto, etc).

Essa escolha é a mais simples. Agora o passo fundamental é documentar o mecanismo de design. Como isso é feito? Nesse ponto você primeiro irá analisar se precisará usar um ou mais design patterns (padrões de design) para ajudar a encapsular e facilitar o trabalho com esse mecanismo. E então você irá criar uma espécie de realização de caso de uso para documentar o mecanismo. Portanto, você criará um diagrama de sequência para cada método na interface ou classe externa do mecanismo. Lembre-se de encapsular ao máximo o mecanismo para que ele seja reutilizável dentro da solução (e até fora dela). Você também gerará um diagrama de classes de design participantes.

Por que o RUP e o OpenUP tratam os mecanismos de design à parte das realizações dos casos de uso? Porque eles prezam a eliminação de redundância de informações e os benefícios do reuso. Ao isolar o mecanismo de design você poderá fazer uma realização de caso de uso de design muito mais resumida. Você não precisa incluir novamente as classes criadas para o mecanismo de design. Você colocará na realização de caso de uso apenas a classe ou interface para o mecanismo. Costumo explicar isso nos treinamentos de OOAD com a analogia do desenvolvimento por uma equipe. O comum é que a equipe monte um primeiro cenário contendo, por exemplo um ou mais mecanismos. Isso é chamado na literatura de esqueleto arquitetural ou protótipo arquitetural. Depois disso o que os desenvolvedores farão quando precisarem usar um mecanismo similar em outros casos de uso? Eles usarão a mesma solução via reuso componentizado ou então copiarão a solução dada no primeiro caso de uso e a mudarão para atender aos requisitos do outro cenário.

Então a mensagem importante é que você se lembre que documentar os mecanismos de design separadamente ajuda a diminuir o esforço de criação e de manutenção. Além de facilitar o processo criativo dos arquitetos e desenvolvedores e o uso de design patterns com objetivos claros e sem exageros.

No próximo artigo trataremos das atividades descrever a arquitetura de execução e descrever a distribuição. Até a próxima!!!

Marcadores: , , ,

terça-feira, outubro 16, 2007

PodCast de José Papo sobre RUP e OpenUP

RUP pode ser ágil - Podcast e explicação abaixo produzidos por Vinícius Teles

RUP pode ser ágil, ao contrário do que muitos acreditam. Isso é que nos explica José Paulo Papo no Improvecast número 20. José Papo trabalha com implantação de processos e gerência de projetos. Além disso, é professor de Engenharia de Software, de Lógica de Programação e de RUP e OpenUP.

Um dos destaques desse podcast foi a evolução do RUP nos últimos anos, no sentido de adotar princípios alinhados com os do Manifesto Ágil. Outro assunto interessante é o surgimento do OpenUP. Conversamos também sobre os seguintes assuntos:

Como e quando foi seu primeiro contato com abordagens ágeis de desenvolvimento de software?
O que mais chamou sua atenção nessas abordagens?
Que tipo de problemas você tinha antes de adotar tais abordagens?
Que tipo de uso prático você vem fazendo das metodologias ágeis atualmente? Você utiliza alguma ou algumas delas em seu trabalho?
Que práticas ágeis você mais utiliza atualmente?
Quais você considera mais fáceis?
Quais são as mais difíceis?
O que é o OpenUP?
Como você enquadra o OpenUP em relação às metodologias ágeis de desenvolvimento de software?
Na sua atuação como professor universitário, você ensina abordagens ágeis de desenvolvimento?
Pelo que você tem observado, as universidades estão começando a ensinar metodologias ágeis, ou ainda estão baseadas apenas nos modelos tradicionais de desenvolvimento de software?
Como você está vendo a evolução da adoção de métodos ágeis aqui no Brasil?
Quais são seus planos para o futuro, na área de desenvolvimento ágil?

Marcadores: , , ,

segunda-feira, outubro 15, 2007

Tecnologia da Informação e o meio ambiente: tudo a ver?

No dia de hoje, 15 de outubro, é a data conhecida como Blog Action Day. Nesta data vários blogueiros ao redor do mundo se unirão para falar sobre um tema em seus blogs. O tema deste ano é meio ambiente ( Environment ). Encontrei essa notícia no Slashdot.

Aproveito para unir o assunto ambiental com nossa área de Tecnologia da Informação. Por estarmos à frente da empresa em relação ao uso de dispositivos eletrônicos, de computadores, de impressoras e de software acredito que devemos dar o exemplo. Como podemos ajudar em relação, por exemplo, ao uso de papel e impressões?

Aí vão algumas dicas (a primeira e mais importante é assistir ao documentário "Uma Verdade Inconveniente" de Al Gore, que foi premiado com o Nobel da Paz. Esse filme te fará pensar muito):

- Imprimir apenas o estritamente necessário. É impressionante o número de pessoas que imprimem um documento apenas para fazer uma revisão neste. Muitas vezes os documentos são impressos dezenas de vezes (até quando ocorreram pequenas correções). Podemos utilizar a ferramenta de controle de alterações do Word para facilitar a visualização das alterações. Não podemos também mais dar a desculpa de que é difícil ler na tela do computador. Eu, por exemplo, leio livros eletrônicos inteiros pelo computador, sem imprimi-los. Qual será o futuro que deixaremos a nossos filhos e netos, se continuarmos depredando a natureza de forma tão descontrolada?

- Utilizar automação de ambientes de desenvolvimento. Vamos utilizar as ferramentas (pagas ou gratuitas) para reduzir a redundância de informações e a proliferação de documentos. Isso também acabará reduzindo o desperdício (não só de papel mas também de produtividade!).

- Ao invés de revisar documentos em papel, leve um notebook ou computador para a sala de reunião. Revise os documentos no próprio computador (utilizando um projetor se for necessário).

- Só imprima documentos realmente imprenscindíveis, como aqueles que necessitam de uma assinatura formal. Apesar de que hoje também temos mecanismos de assinatura eletrônica. Que tal agilizarmos isso em nossas empresas para reduzirmos ainda mais a papelada em nossas mesas e arquivos mortos?

Resumindo, nós da área de Tecnologia devemos dar o exemplo com pensamentos e atitudes. Se cada um de nós realizar a sua parte reduziremos o desperdício em todos os níveis da nossa sociedade.

É isso aí! Agora sou um feliz participante do Blog Action Day !!!

Marcadores:

quarta-feira, outubro 10, 2007

Identificação de Elementos de Design no RUP e OpenUP / Série Análise e Design - Parte 4

Conforme visto no artigo anterior (parte 3) da série Análise e Design, trataremos agora acerca da atividade Identificar Elementos de Design (Identify Design Elements em inglês).

Podemos resumir a atividade de Identificação de Elementos de Design como aquela aonde as classes de análise são refinadas em classes de design e subsistemas.

A seguir os quatro passos dessa atividade:

1 - Identificar Classes e Subsistemas: Aonde o arquiteto deve decidir se uma classe de análise virará uma ou mais classes de design ou então um subsistema.

2 - Identificar interfaces dos subsistemas: Aonde o arquiteto deve definir todas as responsabilidades (operações) que serão fornecidas pelas interfaces dos subsistemas.

3 - Identificar oportunidades de reuso: Com base nas interfaces identificadas no passo 2, o arquiteto deve analisar internamente na empresa e externamente no mercado para buscar subsistemas (componentes, frameworks, web services, etc) que possam atender as necessidades da solução sem ter que reconstruir o subsistema do zero. Esse é um passo fundamental que costuma ser feito apenas de forma intuitiva pelos arquitetos.

4 - Atualizar a organização do modelo de design: Aonde o arquiteto define um esboço inicial da arquitetura em camadas e do empacotamento da solução.

Um subsistema nada mais é que um conjunto de elementos que fornecem um comportamento através de uma interface definida. A diferença de um subsistema e um pacote ( package ) da UML é que o subsistema realiza uma ou mais interfaces enquanto o pacote não possui uma interface definida (a interface do pacote são as operações públicas das classes que o compõem).

Por ser uma definição muito genérica e ter o nome de subsistema(o sistema no nome assusta e dá impressão de um módulo grande) os desenvolvedores confundem às vezes o que pode ser um subsistema. Alguns exemplos para facilitar:

- um componente COM+ de uma solução .NET pode ser considerado um subsistema.
- um Session EJB que fornece uma interface e faz ligações com outras classes pode ser considerado um subsistema.
- um módulo, componente ou API para um produto existente como, por exemplo, softwares de comunicação, acesso a bancos de dados, utilitários comuns (exemplo: uma solução open source para geração de logs como o Log4J, um componente para persistência de dados como Hibernate, ADO, etc).
- um componente para acessar um sistema externo ou legado.
- um web service.

Lembre-se da regra: um subsistema é tudo aquilo que possui uma ou mais classes reunidas e que são acessíveis somente através de uma interface bem definida.

Nessa atividade de identificação dos elementos de design o arquiteto ainda não deve detalhar o componente em si e suas interações internas. Aqui ele só deve identificar as responsabilidades ( operações ) que devem existir nas interfaces para atender aos requisitos do sistema e das realizações dos casos de uso. Cada subsistema deverá ter no mínimo uma interface (pode ter mais de uma).

Outra dica importante é a referente ao passo 4, que trata da arquitetura em camadas da aplicação. Recomendo fortemente a leitura do livro "Patterns of Enterprise Application Architecture" onde o grande Martin Fowler aborda em profundidade o assunto e também o livro "Applying UML and Patterns, 3rd Edition" do Craig Larman para uma abordagem mais didática.

No próximo artigo trataremos da atividade de identificação dos mecanismos de design. Até a próxima!!!

Marcadores: , , ,

Análise de Caso de Uso no RUP e OpenUP / Série Análise e Design - Parte 3

Conforme visto no artigo anterior (parte 2) da série Análise e Design, trataremos agora acerca da atividade Análise de Caso de Uso (Use Case Analysis em inglês).

Primeiro um parênteses importante: quando falamos em análise estamos falando no que o Rational Unified Process chama de uma "solução idealizada". Já estamos desmembrando os elementos e responsabilidades a partir dos requisitos, mas sem ainda definir uma solução e uma plataforma concreta de implementação. Quando falamos da solução concreta então estamos tratando do design.

Podemos resumir a atividade de análise de caso de uso como aquela onde identificamos as classes de nosso sistema, ainda no nível de análise. As responsabilidades(que se transformarão em operações e métodos) das classes de análise são identificadas com o uso de diagramas de interação (O diagrama de sequência e o diagrama de comunicação são os dois tipos de diagramas de interação na UML 2.0). Porém existe um método disciplinado para a criação dos diagramas de classes e os diagramas de interação, e esse ponto é o mais crucial para se entender o processo de elaboração da solução no RUP.

O conceito fundamental para entendermos a disciplina de análise e design do RUP aparece nessa atividade de análise de caso de uso. Esse conceito se chama realização de caso de uso (use case realization). A realização de caso de uso nada mais é que um conjunto de diagramas da UML que, em conjunto, validam as classes, responsabilidades e interações entre objetos necessários para fornecer o comportamento de um caso de uso em particular. Portanto, teremos sempre uma realização de caso de uso para cada caso de uso identificado durante a disciplina de requisitos.

Esse conceito de realização de caso de uso não é apenas central para facilitar o trabalho de desenvolvimento da solução, mas também é o segredo do RUP para manter a rastreabilidade bidirecional entre requisitos e código. A partir do momento que você utilizou o conceito de realização de caso de uso você terá dentro de cada um deles um diagrama de classes participantes. Esse diagrama mostrará todas as classes que compõem um caso de uso. Portanto obterá a rastreabilidade do requisito para o código. Também terá diagramas de sequência (um para cada fluxo), que mostrarão quais operações serão afetadas caso você altere um determinado fluxo (básico ou alternativo).

Caso você queira analisar ao contrário poderá fazer uma busca na sua ferramenta de modelagem (a maioria delas possui essa função) para achar em quais realizações de caso de uso uma determinada classe está. Desse modo você também obtém a rastreabilidade do código para o requisito e obterá uma vantagem significativa para fazer uma análise de impacto de mudanças em um caso de uso. Também poderá se livrar da incômoda e infame matriz de rastreabilidade para rastrear classes para requisitos!

Não descreverei o passo a passo de como fazer a atividade de análise de caso de uso (para isso vide o artigo de Evans citado no final), mas darei algumas dicas e lembretes:

1 - Os principais diagramas de uma realização de caso de uso são: diagrama de classes participantes e diagramas de interação.

2 - Você poderá ter um diagrama de classes participantes para cada realização de caso de uso. Recomenda-se fazê-lo, especialmente se você precisar da rastreabilidade bidirecional

3 - Quantos diagramas de interação você deve fazer? Se seguir a regra do Processo Unificado você fará um diagrama de interação para cada fluxo do caso de uso. Não se faz por cenário porque o número de cenários de um caso de uso tende a ser maior que o número de fluxos e, além disso, ocorreria redundância de informações em cenários que utilizam os mesmos fluxos.

4 - Eu, particularmente, prefiro o uso do diagrama de sequência do que o diagrama de comunicação. O diagrama de sequência facilita a visualização do fluxo temporal das mensagens.

5 - Seja pragmático. Muitas vezes me perguntam se TODOS os fluxos devem possuir um diagrama de sequência. De acordo com o RUP isso seria o ideal. Mas analise a sua situação específica e verifique se eles serão úteis. Fluxos mais simples talvez não necessitem de diagramas de sequência. Mas é recomendável realizar os diagramas de sequência de, pelo menos, todos os fluxos arquiteturalmente significativos da solução.

6 - Lembre-se que o RUP é um framework de processo. Você deve customizá-lo conforme suas necessidades. Há equipes experientes que pulam a etapa de análise de caso de uso para ir diretamente para o design de caso de uso. A análise de caso de uso é útil para equipes inexperientes e também para sistemas onde o domínio do negócio é menos conhecido pelos desenvolvedores. Nada impede também que essa atividade seja feita pelos analistas de requisitos. Lembre-se que a análise de caso de uso ainda não entra nos aspectos técnicos da solução.

Uma dica final: para quem quiser todos os detalhes da atividade de análise de caso de uso e ainda contendo um exemplo de ponta a ponta vide o artigo Getting from use cases to code, Part 1: Use-Case Analysis do grande mestre Gary Evans. Recomendo fortemente a leitura pormenorizada tanto para arquitetos e desenvolvedores novatos como para os experientes.

No próximo artigo trataremos da atividade de Identificação de Elementos de Design. Até lá!

Marcadores: , , ,

terça-feira, outubro 02, 2007

Sobre a certificacao RUP 7 e OMG UML 2.0

Seguem informações para realizar os exames para certificação UML 2 e RUP 7, que são muito requisitadas em listas de discussão.

Para realizar a prova da certificação UML oficial da OMG o candidato deve se inscrever no site da Prometric. Há três níveis de certificação OMG UML: Fundamental, Intermediate e Advanced. Pode-se encontrar maiores detalhes sobre o exame UML no site da OMG. Um excelente livro que pode ser usado para as certificações Fundamental e Intermediate é o UML 2 Certification Guide: Fundamental & Intermediate Exams.

Para a prova do RUP 7.0 (também se inscreva na Prometric) é recomendável fazer o treinamento oficial da IBM chamado "Essentials of RUP v 7.0", estudar através das apostilas desse material e também estudar muito bem o RUP 7 (que vêm agora dentro do produto Rational Method Composer).

Leia mais sobre os benefícios da certificação RUP.

Marcadores: , ,


Veja as Estatísticas