Rational Team Concert - Detalhes da nova solução de ALM da IBM Rational

O Rational Team Concert é uma robusta ferramenta de ALM (Application Lifecycle Management) colaborativa, baseada na plataforma aberta Jazz. Nesse artigo, vou falar sobre seus principais recursos, suas três diferentes edições e preços, a visão futura da plataforma e a questão que ainda confunde novos e antigos clientes: o RTC substitui a suite Rational clássica?

Começando pelas funcionalidades: O RTC conta com um sistema de controle de incidências integrado com controle de versões (possui um sistema de controle de versões próprio e tem conector para o Subversion), wiki, sistema de integração contínua e um servidor portal que gera as mais diversas métricas, relatórios e informações executivas sobre os projetos. É o nirvana dos desenvolvedores e gerentes de projeto!

O Rational Team Concert já vêm com dois processos pré-definidos na "caixinha": são eles o Scrum e o OpenUP. Além é claro da flexibilidade que o RTC fornece para a equipe configurar seu próprio processo. Todas as edições do produto contam com esses recursos. Lembre-se que o Rational Team Concert pode ser usado como um plugin do Eclipse (é uma nova perspectiva) ou através de um browser Web conectado diretamente ao servidor (vide abaixo sobre o futuro do RTC para detalhes específicos relaciuonados a desenvolvedores .NET).

O RTC pode ser usado em três edições distintas (preços de acordo com a página do RTC no site oficial da IBM, na data deste artigo. Para informações mais atualizadas, pode me consultar! ):

- Express-C: permite até 10 usuários. Não possui custo de licença para o servidor e o custo por usuário é de 1200 dólares por desenvolvedor e 600 dólares por contribuidor. Usa como infra-estrutura o Tomcat e o banco de dados Derby.

- Express: permite até 50 usuários. Possui custo de licença de servidor de 6.000 dólares. O valor de licenças para desenvolvedor e contribuidor é o mesmo da edição Express-C. Usa como infra-estrutura o Tomcat ou o WebSphere Application Server e o banco de dados DB2 Express, DB2 ou Oracle. Possui os mesmos recursos que a versão Express-C. A única grande diferença é a quantidade de usuários máximos permitidos.

- Standard: permite até 250 usuários. Possui custo de licença de servidor de 50.000 dólares. O valor de licenças para desenvolvedor é de 3900 dólares e o de contribuidor é o mesmo da edição Express. Usa como infra-estrutura o Tomcat ou o WebSphere Application Server e o banco de dados DB2 Express, DB2 ou Oracle. Além do maior número de usuários possui os seguintes recursos extras: Configuração de permissões de acesso baseado em papéis, Conectores para ClearCase e ClearQuest, Customização de itens de trabalho do gerenciador de incidências (nas versões Express-C e Express não é possível customizar os work itens), Customização de relatórios e dashboards executivos.

Uma dica e vantagem interessante: em qualquer uma das versões você tem o direito de usar 3 (três) licenças de desenvolvedor gratuitamente! Portanto, se você tem uma equipe de até 3 pessoas pode usar o RTC Express-C sem custo algum! Se sua equipe crescer você paga só pelo quarto usuário em diante.

O que podemos esperar para o futuro próximo do Rational Team Concert?

- Lançamento de um plugin para o Microsoft Visual Studio (hoje desenvolvedores .NET podem usar a ferramenta através do servidor Web mas, com o lançamento do plugin, o desenvolvedor não precisará mais sair da IDE para realizar o seu trabalho).

- Lançamento da edição Enterprise do Rational Team Concert (já virá com as novas versões do Rational ClearCase, ClearQuest e BuildForge. Versão 8.0 da suite Rational).

- Lançamento da ferramenta Requirements Composer, que já está em beta. Facilitará o processo de levantamento de requisitos e criação de protótipos rápidos. Essa ferramenta não substitui o RequisitePro. Elas possuem objetivos distintos: o Requirements Composer auxilia o analista de requisitos no levantamento e o ReqPro auxilia na gestão desses requisitos levantados com os stakeholders.

- Lançamento da ferramenta Quality Manager, que já está em beta. Fornecerá funcionalidade de gestão de testes e qualidade (será a evolução do Rational ClearQuest TestManager) já integrada dentro da plataforma Jazz.

E, para finalizar, vamos ajudar a responder a pergunta: o RTC substitui a suite Rational clássica?

Para empresas pequenas e médias ou equipes pequenas ou médias em grandes corporações o Rational Team Concert atenderá às necessidades imediatas que a suite Rational oferece. E com uma grande vantagem: uma velocidade muito maior (e custo menor!) de instalação, configuração, customização, treinamento, mentorização e administração da ferramenta (a suite Rational clássica demanda mais recursos e tempo, devido à sua grande capacidade de customização). Para times pequenos e médios que desejam usar um processo e ferramenta out-of-the box com as melhores práticas de processos e ferramentas existentes no mercado de desenvolvimento de software, essa é a ferramenta ideal.

Grandes empresas, que desejam uma maior flexibilidade de customizações, configurações e adaptações para adequar ferramentas ao seu processo continuarão necessitando da suite Rational clássica e, em 2009, usarão o novo empacotamento dessa suite, chamado de Rational Team Concert Enterprise. Mas já podem já adquirir a suite Rational Team Concert Standard e plugá-la em suas ferramentas atuais, para facilitar aind mais a vida das equipes de desenvolvimento!

Portanto, pequenos e médios times (de 1 a 250 usuários!) já possuem uma solução completa para suas necessidades de desenvolvimento colaborativo: o Rational Team Concert!

Caso você tenha lido este artigo e está avaliando uma possível aquisição deste produto e seus respectivos treinamentos, configurações e mentorizações entre em contato comigo que ajudarei no que for possível, inclusive para detalharmos face a face as vantagens da nova plataforma Jazz!

Fotos com líderes e visionários do desenvolvimento de software - RSDC 2008 Orlando EUA - Parte 2

Continuando a série de fotos tiradas com os líderes e autores importantes no mundo de desenvolvimento de software. Temos também algumas fotos com amigos da IBM Rational Brasil.


Foto com Terry Quatrani (autora dos livros "Visual Modeling with Rational Rose and UML" e "Visual Modeling with Rational Software Architect and UML"):

Foto com Erich Gamma (um dos membros da GoF - Gang of Four - co-autor do livro "DEsign PAtterns" e líder do projeto Jazz e Rational Team Concert da IBM Rational):

Foto com Peter Eeles (co-autor do livro "Building J2EE Applications with the RUP"):






Foto com Kurt Bittner (co-autor dos livros "Use Case Modeling" e "Managing Iterative Software Development Projects"):






Foto com Per Kroll (co-autor do livro "Agility and Discipline Made Easy: Practices from OpenUP and RUP" e "RUP Made Easy"):





Foto com Joe Marasco (autor do livro "The Software Development Edge"):

Foto com Wagner Arnaut (IBM Rational Brasil):

Foto com Paulo Henrique Cruz nos Estúdios da Universal(IBM Rational Brasil):

Foto com Callado (IBM Rational Brasil):

Fotos com líderes e visionários do desenvolvimento de software - RSDC 2008 Orlando EUA

Caros,


No primeiro dia assisti a palestras de grandes nomes do desenvolvimento de software. Nesse post vou apenas colocar algumas das fotos minhas com os grandes papas da engenharia de software atual. Mais tarde, quando eu tiver mais tempo(pois já está tarde e preciso acordar cedo para o segundo dia de evento... he, he!), vou postar sobre os temas que assisti. Amanhã e quarta vou assistir a palestras de Erich Gamma, Per Kroll, Terry Quatrani, Kurt Bittner, Joe Marasco e Peter Eeles. Aguardem mais fotos!!!

Creio que principalmente quem trabalha, como eu, durante 8 a 10 horas por dia tendo como base a idéia desses mestres ( e ainda estuda, prepara aulas, leciona e discute esses conceitos com os alunos por mais 4 a 6 horas por dia podendo totalizar facilmente umas 16 horas por dia!!!) é que terá a noção da grande honra, emoção e alegria que é poder ouvir de perto, conversar e trocar idéias com esses gigantes do mundo de desenvolvimento de software.

Agora chega de devaneios... vamos às fotos :-) !!!

Foto com Grady Booch (um dos Três Amigos, co-criador da UML e autor dos livros "Object-Oriented Analisys and Design with Applications" e "UML Users Guide"):

Foto com Ivar Jacobson (Outro dos três amigos. Co-autor da UML, autor de livros como "UML Users Guide" e criador do conceito de casos de uso):

Foto com Scott Ambler (Autor de livros como "Agile Modeling", "Object Primer" e "Refactoring Databases"):

Foto com Murray Cantor (Autor do livro "Software Leadership" e líder do plugin RUP para System Engineering):

Foto com Ian Spence (co-autor com Kurt Bittner dos excelentes e fundamentais livros "Use Case Modeling" e "Managing Iterative Software Development Projects"):

Sobre a IBM Rational Software Development Conference 2008

Dos dias 1 a 5 de junho ocorre em Orlando, Estados Unidos o evento IBM Rational Software Development Conference 2008. Será um evento gigante, contendo centenas de sessões interessantíssimas sobre técnicas e ferramentas para apoiar o desenvolvimento e a engenharia de software.

Participarei do evento e pretendo escrever em meu blog (espero que tenha uma rede wireless lá nas salas da conferência!) sobre todas as novidades. Se possível, vou colocar fotos também.

Vamos ver se consigo tirar fotos com o William Shatner (sim, o capitão Kirk da Enterprise!!!), com o Erich Gamma (um dos caras da GoF) e com o Grady Booch. Vou aproveitar para levar alguns dos meus livros para pegar uns autógrafos. Não voltarei sem ter o meu livro "Design Patterns" assinado pelo próprio Gamma :-) !

Aguardem as notícias e artigos sobre o evento a partir do dia primeiro de junho!!!

CMMI Brasil - Novo Grupo de Discussão!

Devido à decisão de fechar o grupo CMM-Brasil, feita pelo fundador, criei um novo grupo de nome CMMI-Brasil para continuar as discussões e os debates que ocorriam na antiga lista.

Ele possui o mesmo escopo do anterior, que é ser um grupo criado para troca de experiências entre profissionais que trabalham com modelos de maturidade e processos de desenvolvimento de software. O tema de interesse do grupo é ligado a modelos, padrões e processos que possuam aceitação internacional, como CMMI, MPS.BR, ITIL, SPICE, RUP, Metodologias Ágeis, SWEBOK, PRINCE2 e Guia PMBOK do PMI, séries ISO, etc. A participação é aberta a todos interessados ou envolvidos profissionalmente com exportação e modelos de melhoria de processos de software, bem como gerenciamento de projetos.

Aproveite e junte-se a nós para gerar e compartilhar conhecimentos sobre essa área tão vasta. Acesse a página do CMMI-Brasil e faça seu cadastro!

Benefícios da Certificação RUP - Rational Unified Process V7.0

A certificação "IBM Certified Solution Designer - IBM Rational Unified Process V7.0", da IBM Rational, pode ser obtida com a realização do teste 839. Esse teste é uma prova realizada por um centro autorizado Prometric e seu objetivo é mostrar que o candidato conhece realmente o RUP versão 7.



Quais são, então, os benefícios da certificação RUP?



O primeiro é demonstrar para os empregadores que você estudou a fundo o tema e que realmente sabe quais são os princípios do RUP, como ele é formado, quais são suas disciplinas, papéis, atividades, etc. Isso é um diferencial, pois nota-se em sites de emprego que o conhecimento de RUP é um requisito muito pedido. Um grande número de empresas e consultorias no Brasil utiliza o framework do RUP para customizar seus processos de desenvolvimento de software.



A segunda vantagem é que você se tornará um profissional mais valioso para uma consultoria ou fábrica de software. Diversas licitações governamentais já pontuam bem as empresas que possuem profissionais certificados em RUP. Mesmo empresas privadas gostam de saber e conhecer os currículos das pessoas que trabalharão em seus projetos.



A terceira vantagem é que a certificação do RUP abre as portas para diversas outras certificações da IBM Rational. Para você se tornar um "IBM Certified Specialist for Rational Requirements Management w/Use Cases" (isto é, um especialista em gestão de requisitos) você obrigatoriamente precisa ter sido certificado em RUP 7.0. A certificação RUP, aliada a uma certificação de UML como a da OMG, demonstrará com ainda mais ênfase o seu valor.



É claro que devemos sempre lembrar que uma certificação não garante que um profissional aplicou na prática uma determinada tecnologia ou conceito, porém ela mostra que esse profissional é disciplinado o suficiente para ter estudado o assunto a fundo. Assim, ele terá mais facilidades em aplicar esse conhecimento do que aquele que ainda não teve nenhum contato com o processo.



Um ponto a favor da certificação RUP é que ele é um dos raros frameworks de processos de desenvolvimento de software que possuem uma certificação formal que ajuda a mostrar que o profissional possui um conhecimento aprofundado no assunto.



O conteúdo do exame foca no conhecimento do RUP clássico para grandes projetos e, desse modo, abrange uma grande quantidade de informações.



Portanto, no mundo competitivo do mercado corporativo, a certificação Rational Unified Process provavelmente ajudará você numa potencial disputa por vagas em uma empresa que adota o RUP como processo e também pode alavancar sua carreira e suas recompensas financeiras.



Para as empresas, contratar um profissional certificado em RUP 7 garante que aquela pessoa já possui um conhecimento razoável do framework e que, desse modo, terá maior facilidade de se adaptar ao processo de trabalho da organização. Mostra também que a pessoa é disciplinada e interessada o suficiente para estudar maneiras de melhorar seu trabalho (um processo está aí para isso: ajudar você a melhorar continuamente sua forma de desenvolver software com qualidade e agilidade).



Logo teremos uma grande novidade para ajudar as pessoas a obter a certificação IBM Certified Solution Designer - IBM Rational Unified Process V7.0. No início de fevereiro haverá maiores detalhes aqui no blog. Quem tiver interesse em tirar a certificação ainda este ano pode mandar um email para mim. Empresas interessadas em fazer com que seus profissionais sejam certificados em RUP também podem entrar em contato. Eu responderei com as informações iniciais desse apoio que ainda não existe com força aqui no Brasil. O endereço é jose ponto papo arroba gmail ponto com ( transforme a palavra ponto em . e a palavra arroba em @ ).

Vamos nos capacitar e crescer profissionalmente para tornar o Brasil um país mais avançado!

Integração entre RUP e PMBOK: Como conciliar?

Pergunta endereçada por email para mim (o colega deu a permissão de publicá-la):

Sou professor e estou orientando 5 TCC's - Trabalho de Conclusão de Curso, todos voltados para Governança de TI. Um deles tem como tema Gestão de Projeto de Desenvolvimento de Software, em Processo Incremental (RUP), utilizando PMBOK. Este trabalho pesquisa uma solução para a dificuldade de compatibilização desses frameworks, uma vez que os mesmos são os mais utilizados para desenvolvimento e gestão do projeto.

Para ficar mais claro, transcrevo alguns trechos do trabalho .Na contextualização falamos :" ..Embora freqüentemente utilizadas em projetos de desenvolvimento de software, essas duas metodologias apresentam uma grande dificuldade para serem utilizadas em conjunto. Enquanto o RUP utiliza um modelo que busca a construção de um software através de sucessivas iterações (modelo espiral incremental), ou seja, a seqüência de desenvolvimento vai se repetindo em ciclos sucessivos, o PMBOK parte do princípio que as atividades ocorrerão de forma seqüencial e sem repetições..."

Entretanto, quando da elaboração do orçamento de um projeto, dois dos requisitos indispensáveis são : Custo e Prazo . Ora, como determinar custo e prazo antecipadamente se a priori não sei quantas iterações terei que fazer no processo de desenvolvimento ? Como compatibilizar o gerenciamento de um projeto com PMBOK se o processo é RUP ?

Minha resposta:

Em relação à contextualização tenho uma crítica: o PMBOK não diz que obrigatoriamente o projeto será feito de forma sequencial. Ele define a importância e o formato do "rolling-wave planning" e da "progressive elaboration" que nada mais é que um ciclo iterativo e incremental. Apesar de falar pouco sobre isso o "rolling-wave planning" e a "progressive elaboration" constam da 3a. edição do PMBOK. Sobre a questão de custo e prazo posso adiantar que esse problema ocorre quando o cliente deseja um projeto de preço e prazo fechado. Há várias maneiras de resolver isso e tenho uma palestra que trata do assunto e que ministrei para o PMI-SP.

Outros dados mais detalhados podem ser encontrados nos livros do Craig Larman - Agile and Iterative Development, A Manager's Guide - e do Mike Cohn - Agile Estimating and Planning.

Posso resumir dizendo que não há nenhuma incompatibilidade entre RUP e PMBOK. Termos diferentes são usados para descrever conceitos similares nos dois. Mas nada no RUP contradiz o PMBOK e vice-versa. Portanto, se um Gerente de Projetos estiver usando a disciplina de gestão de projetos do RUP ele estará aderente também às práticas do PMBOK. Há duas áreas pouco tratadas no RUP e que podem ser alavancadas com o PMBOK: Gestão de Aquisições e Gestão de Custos. Para maiores detalhes dessa conclusão vide o artigo "A Mapping between PMBOK and RUP".

Portanto, use a disciplina de gestão de projetos do RUP. Ela é aderente ao PMBOK. E se tiver necessidade de alguma boa prática extra então avalie o que tem no PMBOK e customize a disciplina de Gestão de Projetos do RUP. Não caia na armadilha de substituir a getão de projetos do RUP, pois você correrá o risco de destruir o principal princípio do Rational Unified Process: Realizar desenvolvimento iterativo e incremental.

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

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.

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!!!

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!!!

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!!!

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?

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!!!

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á!

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.

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

Conforme visto no artigo anterior (parte 1) da série Análise e Design, trataremos agora acerca da atividade Análise Arquitetural (Architectural Analysis em inglês).

Pode-se resumir a atividade de análise arquitetural como um primeiro esboço feito pelo aquiteto de software acerca da possível solução (ou soluções) a ser dada tecnicamente para atender os requisitos e necessidades levantados e descritos formalmente pelo analista de sistemas no documento de Visão e no primeiro esboço(outline) dos casos de uso.

Agora uma análise da descrição de seus passos (steps) principais (Observação: Cada atividade do RUP pode ser dividida em um ou mais passos. Esses passos são os elementos mais granulares em termos de tarefas no RUP. Esse é o nível mais detalhado que a equipe e o gerente de projetos podem chegar ao fazer o plano de uma iteração do projeto RUP).

- Desenvolver a Visão Geral da Arquitetura: Esse passo é o primeiro esboço e análise da possível arquitetura candidata que pode ser adotada. Essa etapa é aquela em que o arquiteto fará uso de toda a sua experiência e também da experiência e artefatos já implementados na organização e fará um breve esboço da visão de implantação. A visão de implantação nada mais é que a primeira tentativa de elaborar um diagrama de implantação (deployment diagram) do sistema. Exemplo: O arquiteto pode decidir que o sistema usará o ambiente J2EE já existente na organização. Portanto ele esboça em uma ferramenta de modelagem os componentes da plataforma J2EE que provavelmente usará para elaborar o sistema. Lembrem que esse é apenas o primeiro esboço. Essa análise é feita na fase de Iniciação ou bem no início da primeira iteração de Elaboração. Lembrem que esse esboço de arquitetura será refinado em atividades posteriores.

- Avaliar os Recursos Disponíveis: Nesse passo o arquiteto verifica na empresa ou no mercado quais componentes, bibliotecas, frameworks, sistemas e códigos já existem e que poderão ser reutilizados para o sistema. Esse passo deve ser revisto várias vezes durante o projeto, especialmente nas iterações da fase de Elaboração.

- Definir as camadas (layers) do sistema: Nesse ponto o arquiteto deve definir as camadas do sistema. É importante lembrar que esses passos não são estanques. Eles podem ser revistos no decorrer do projeto. Mas, de preferência, as camadas (assim como a arquitetura como um todo) devem estar estáveis até o final da última iteração da fase de Elaboração.

- Identificar as Abstrações-Chave: Essa interessante atividade é aonde o arquiteto analisa os requisitos e monta o primeiro diagrama de classes do sistema. Esse diagrama de classes é ainda conceitual. Ele só possui as classes e seus nomes. Essas classes identificadas são apenas as principais entidades de negócio de um sistema: Exemplo: em um sistema de leilão teríamos cliente, leilão, lance, lote, etc.

- Desenvolver a Visão Geral da Implantação: nesse passo o arquiteto poderá detalhar ainda mais o diagrama de implantação e descrever os recursos de hardware e software necessários para o funcionamento da aplicação.

- Identificar os Mecanismos de Análise: Primeiramente o conceito rápido de mecanismos de análise: mecanismos de análise são representações abstratas de soluções necessárias para resolver um problema determinado de uma aplicação. Um exemplo clássico: suponha que a aplicação necessite armazenar, recuperar e alterar dados que ficam gravados por um longo período de tempo (um clássico em aplicações corporativas). Para resolver esse problema terei que usar um mecanismo de persistência de dados. Nessa atividade só identificamos o mecanismo de análise. Posteriormente veremos que este se traduzirá em mecanismo de design e de implementação. Mas só para não ficar confuso veja o exemplo completo:

Mecanismo de Análise: Persistência

Mecanismo de Design: Banco de Dados Relacional

Mecanismo de Implementação: Oracle

Para que então existe esse passo? Ele é um jeito disciplinado do arquiteto documentar as soluções arquiteturais que irão resolver o problema de negócio. Ao documentar o mecanismo em um nível de análise fica mais fácil depois avaliar diversas soluções que possam solucionar o mecanismo. Desse modo o arquiteto de software pode, usando o documento de arquitetura de software, justificar em termos qualitativos e quantitativos suas decisões e escolhas de componentes, frameworks e plataformas.

O mais comum em nossa área é que essas decisões arquiteturais sejam tomadas intuitivamente e informalmente. Mesmo que haja maior formalidade na escolha esta muitas vezes não é descrita e documentada para uso futuro. A idéia do RUP e do OpenUP de definir mecanismos como forma de documentar as soluções que serão usadas para resolver um problema formaliza de uma maneira excelente essas decisões. Do meu ponto de vista, o uso dos mecanismos de análise, design e implementação são essenciais para facilitar e formalizar os debates e o entendimento acerca do porquê de se usar determinadas soluções para o projeto. Além disso é um dos passos fundamentais a ser realizado pelo arquiteto. Não esqueça que o resultado das deliberações será descrito no artefato "Documento de Arquitetura de Software".

Mais alguns exemplos de mecanismos de análise:

- comunicação entre processos
- interface gráfica de usuário
- acesso a dados
- roteamento de mensagens
- troca e conversão de informações
- segurança
- detecção e tratamento de erros
- redundância
- interface a sistema legado
- geração de logs
- distribuição de objetos
- gerenciamento de transações
- sincronização e controle de processos

Caso tenham alguma dúvida sobre essa atividade deixem um comentário que responderei assim que puder. Assim teremos um histórico em cada parte dessa série acerca das atividades de análise e design.

Nosso próximo artigo tratará da atividade de análise de caso de uso (Use Case Analysis em inglês). Até a próxima!!!

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

Esse é o primeiro artigo de uma série que explicará de uma forma simples, breve e útil a disciplina de análise e design do Rational Unified Process ( RUP ) e do OpenUP.

A idéia de escrever esses artigos no blog surgiu a partir de uma análise pessoal e empírica. Notei, nas minhas andanças e conversas por muitos projetos de clientes e consultorias diferentes, que a vasta maioria das pessoas que trabalham com Tecnologia da Informação e mais especificamente com o RUP conhecem muito pouco sobre a disciplina de análise e design. Esse é um fenômeno interessante, pois hoje em dia o conceito de casos de uso está sedimentado no mercado de desenvolvimento de software. Da Universidade a grande maioria dos alunos sai com conhecimento sobre o que é um caso de uso e como escrevê-lo. Porém, em relação à disciplina crítica que é a Análise e Design (e que abrange a Arquitetura, falaremos disso mais adiante) vemos que ela é usualmente relegada para segundo plano.

Creio que um dos motivos para esse fenômeno ocorrer é a própria visão dos arquitetos de software. O foco destes profissionais no Brasil é eminentemente técnico. Inclusive o mercado associa à palavra arquiteto a idéia de um profissional sênior com vastos conhecimentos e experiências técnicas em uma ou mais determinadas plataformas. Porém, como iremos mostrar nessa série de artigos, o papel do arquiteto requer um processo para disciplinar e organizar aquilo que ele gera e para agregar realmente valor a um projeto de desenvolvimento de sistemas. Veremos nos artigos que a arquitetura e a análise e design no RUP e no OpenUP não são um monstro de sete cabeças.

Para começar vou passar uma definição mais informal do que é arquitetura de software e para que ela serve. A arquitetura de software nada mais é que "um conjunto de decisões significativas acerca da organização de um software". Alguns exemplos dessas decisões:

- Seleção de elementos estruturais e suas interfaces
- Especificação do comportamento de elementos arquiteturais
- Estilo arquitetural que guia o projeto e a organização
- Seleção de componentes, softwares básicos, frameworks, padrões arquiteturais e de design, ambientes de desenvolvimento e componentes que auxiliem na elaboração do sistema.
- Integrações com outros sistemas e softwares
- Definições de como as soluções atenderão e ajudarão a resolver os requisitos não-funcionais como performance, escalabilidade, usabilidade, internacionalização, suportabilidade, testabilidade, etc.

Pode-se dizer então que a arquitetura envolve uma série de decisões estratégicas em relação à solução a ser dada para resolver uma necessidade de negócio. Essas decisões arquiteturais são fundamentais, pois mudá-las pode gerar impactos profundos. Além disso a arquitetura ajuda a restringir o design e a construção de um software. Portanto, mesmo que um arquiteto faça e tome essas decisões informalmente e não as documente (o que acontece em muitos casos no mercado) ele ainda assim está defindo uma arquitetura.

Sobre o ponto de restringir como será feito o desenvolvimento vale um exemplo: suponha que o arquiteto decida que o sistema usará o Hibernate para realizar a persistência em banco de dados relacional. Essa decisão restringe como os desenvolvedores do projeto farão a persistência. Um deles não pode simplesmente dizer que usará EJB 3 ou JDBC com DAO sem o aval do arquiteto. Isso levaria o projeto ao caos devido ao uso de mais de uma solução de persistência sem um motivo claro. A arquitetura deve se tornar um ponto de estabilidade para a equipe de desenvolvimento. A restrição dessa imaginação do desenvolvedor em relação a componentes adotados é algo bom e não ruim. Essas restrições concentram a imaginação dos desenvolvedores nos aspectos importantes que devem ser resolvidos (como implementar regras de negócio usando os componentes, como converter os requisitos em código e testes na arquitetura definida, etc) e não em decisões estratégicas.

Bom, para uma introdução este artigo está bom! No final do texto você encontrará algumas referências bibliográficas. Na parte 2 trataremos das principais atividades de Análise e Design. Começaremos com a atividade Análise Arquitetural (Architectural Analysis em inglês) e seus passos (steps) principais:

- Desenvolver a Visão Geral da Arquitetura
- Avaliar os Recursos Disponíveis
- Definir as camadas (layers) do sistema
- Identificar as Abstrações-Chave
- Desenvolver a Visão Geral da Implantação
- Identificar os Mecanismos de Análise

Caso tenham alguma dúvida deixem um comentário que responderei assim que puder.

Referências Bibliográficas

Alur, D. et al - Core J2EE Patterns: Best Practices and Design Strategies, Second Edition

Bass, L; Clements, P.; Kazman, R. - Software Architecture in Practice, 2nd Edition (The SEI Series in Software Engineering)

Booch, G. et al - Object-Oriented Analysis and Design with Applications, 3rd Edition

Clements, P. et al - Documenting Software Architectures: Views and Beyond

Eeles, P. et al. - Building J2EE Applications with the Rational Unified Process

Evans, Eric - Domain-Driven Design: Tackling Complexity in the Heart of Software

Fowler, Martin - Refactoring: Improving the Design of Existing Code

Fowler, Martin - Patterns of Enterprise Application Architecture

Freeman, Elisabeth - Head First Design Patterns

Gang of Four - Design Patterns: Elements of Reusable Object-Oriented Software

Hohpe, G; Woolf, B. - Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions

Larman, Craig - Applying UML and Patterns, 3rd Edition

Manassis, Enrico - Practical Software Engineering: Analysis and Design for the .NET Platform

McLaughlin, B.; Pollice, G.; West, D. - Head First Object-Oriented Analysis and Design: A Brain Friendly Guide to OOA&D

Newkirk, James et al. - Enterprise Solution Patterns Using Microsoft .NET. Disponível online na Microsoft

Rozanski, N; Woods, E. - Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

Promoção de baselines no Rational ClearCase, CVS e Subversion

Uma pergunta surgiu na lista CMM-Brasil acerca da promoção de linhas de base ( baselines ) em ferramentas de gerência de configuração.

A Pergunta:
Gostaria de saber se algum dos colegas utiliza o CVS em gestão de configuração. A empresa em que trabalho está homologando este sistema para substituir o Rational ClearCase e uma das queixas mais freqüentes diz respeito à promoção de baselines, que não seria facilitada com o CVS. Desta forma, gostaria de saber afinal como fazer promoção de baselines com o CVS.Para constar, há um movimento - apesar de fraco - em prol do Subversion. Entretanto, soube que as tentativas de usá-lo foram frustradas por motivos técnicos, já que aparentemente o sistema não passou nos testes de simulação de carga com uma grande quantidade deusuários em nível nacional. Assim, relatos do uso de Subversion com uma grande quantidade de usuários também são bem-vindos.

A Minha Resposta:
O conceito de baseline do ClearCase na realidade corresponde ao conceito de tag ou label do CVS e do Subversion. O conceito de branches é chamado de branch no ClearCase Base e de Stream no ClearCase UCM.

O conceito de promoção de baseline realmente não existe no CVS. A promoção nada mais é que você definir uma propriedade (ou metadado) descrevendo a estabilidade daquela baseline. Os valores default são: Integration Tested, System Tested, Acceptance Tested, Production.

O Subversion possui uma funcionalidade que pode ser usada para descrever esse conceito de promoção. Essa funcionalidade se chama "Properties". Ela permite que você crie metadados.

De qualquer maneira, há sempre a possibilidade de simular o conceito de promoção de baselines usando a funcionalidade de tags e labels do CVS e do Subversion.

Sobre a questão da performance, existe uma solução (paga) que aumenta radicalmente a performance do Subversion sem afetar a sua forma comum de utilização. Vide: http://www.wandisco.com/php/product_detail.php?lname=subversion

Mas existem muitos relatos no exterior de companhias com equipes distribuídas grandes satisfeitíssimas com o uso do Subversion. Talvez vocês tenham testado a performance com uma versão mais antiga. Na versão mais nova a performance foi melhorada ainda mais. Outras fontes boas de informações são:

http://blogs.open.collab.net/svn/

http://subversionee.blogspot.com/

http://svk.bestpractical.com/view/HomePage

O Glossário do RUP e do OpenUP: Um Ser Incompreendido!

O artefato Glossário, contido na disciplina de requisitos do Rational Unified Process e do OpenUP, costuma ter pouca utilização prática dentro das empresas. Pouca gente conhece sua potencial utilidade e, neste artigo, tratarei sobre esse assunto. Provavelmente essas idéias ajudarão muitos analistas de requisitos e analistas de sistemas a melhorar a qualidade de seus requisitos.

As informações que passarei foram sumarizadas e baseadas no livro Use Case Modeling de Bittner e Spence, no livro Patterns for Effective Use Cases de Cockburn et al e na apostila do treinamento oficial "Mastering Requirements Management with Use Cases" da IBM Rational.

Quando a técnica de modelagem de casos de uso é utilizada para especificar requisitos funcionais de um sistema, muitos analistas de sistemas acham que a definição todos os atributos, tamanhos e domínios das entidades não está sob sua responsabilidade. Mas é claro que esses elementos fazem parte dos requisitos a se levantar junto com os usuários.

Por exemplo, vamos supor que se esteja definindo os requisitos de um sistema de e-commerce. Se o analista de requisitos disser em um caso de uso que o cliente pode alterar as informações de perfil de cliente, porém não incluir quais são essas informações, o que o desenvolvedor fará? Ele irá perguntar para o analista de requisitos. E o analista de requisitos fará o que? Perguntará para o usuário :-) !

Portanto esses atributos e seus respectivos tamanhos e domínios precisam estar documentados. Mas se eu inserir estas informações na especificação de caso de uso o que ocorrerá?

Problemas

Exemplo de especificação de caso de uso "complicada":
...
Passo 4 - O cliente informa ao sistema os dados de Nome, Endereço e Sexo do Perfil do Cliente.
Passo 5 - O sistema valida os dados do Perfil do Cliente. Nome deve ter 40 posições - alfanumérico; Endereço deve ter 2 linhas de 60 posições cada uma - alfanumérico; Sexo deve ter 1 posição - caractere - domínio: F para Feminino ou M para Masculino.
...

Terei dois problemas graves:

1 - Especificações de casos de uso gigantes, com dezenas de páginas.

2 - O mais grave: quando você utilizar uma entidade em vários casos de uso você gerará duplicação de informações em diferentes artefatos. Essa falha levará a sérias dificuldades na manutenção dessa documentação e ocasionará possíveis erros quando alguém esquecer de alterar um atributo em todos os casos de uso que o referenciam.

Solução

Coloque, além de uma definição simples acerca da entidade, TODOS os atributos e seus respectivos tamanhos e domínios dentro do Glossário. Dessa forma você centralizará essas informações em um único artefato. O Glossário então se tornará um elemento essencial para o desenvolvimento do sistema e atuará também como uma espécie de dicionário de dados do negócio.

Exemplo

Exemplo No Glossário:
Entidade Perfil do Cliente -> entidade que representa as informações básicas de um cadastro realizado pelo próprio usuário do site de e-commerce.
Atributos:
Nome: 40 posições - alfanumérico
Endereço: 2 linhas de 60 posições cada uma - alfanumérico
Sexo: 1 posição - caractere - domínio: F para Feminino ou M para Masculino
...

Na especificação de caso de uso a dica é usar algo para realçar uma entidade que está descrita no Glossário. Defina um padrão para seu projeto. No exemplo abaixo eu padronizei que todas as entidades descritas em uma especificação de caso de uso estarão em itálico.

Exemplo em uma especificação de caso de uso:
...
Passo 4 - O cliente informa ao sistema os dados do Perfil do Cliente.
Passo 5 - O sistema valida os dados do Perfil do Cliente.
...

Portanto, usem o glossário como uma ferramenta essencial da documentação de requisitos. Vocês notarão a melhoria no entendimento dos casos de uso e a facilidade de manutenção que essa técnica proporcionará.