?

Apesar de toda a má fama que a acompanha, a ferramenta Caso de Uso continua sendo apresentada por muitos, inclusive este que vos escreve, como a mais eficaz no apoio às atividades de “descoberta e descrição dos requisitos funcionais de um sistema”. Os mal ditos sobre os casos de uso têm origem bem identificada. Em dado momento, entre o final dos anos 1990 e início do novo século, tentaram sofisticar demais a ferramenta. Modelos rebuscados e divisões artificiais e redundantes (fluxo disso, fluxo daquilo…) deram enorme contribuição. A gota d’água veio daquela parte da população que tem preguiça de pensar e adora templates repletos de badulaques. Pronto, estava criada a fama – justíssima, dados os casos criados – de que casos de uso eram muito complicados, de difícil elaboração pelos analistas, incompreensíveis para os usuários, detestados e consequentemente ignorados pelos desenvolvedores e distantes demais dos testers (provavelmente os únicos que, se tivessem a chance, talvez gostassem daquilo. Porque era melhor que nada!)

O advento do Manifesto Ágil quase nos fez crer que Caso de Uso era coisa do século passado. Mas o que seria do mundo se não fossem os teimosos? Alistair Cockburn nunca abandonou os casos. Nem Ivar Jacobson, o pai da criança que agora nos apresenta essa releitura (escrita a seis mãos com Ian Spence e Kurt Bittner, autores de “Use Case Modeling” – Addison-Wesley, 2002).
O que ela traz de novo a ponto de merecer o “2.0”? Antes disso, qual a motivação para uma nova versão?

Os autores defendem que o Caso de Uso 2.0 é: Leve, Escalável, Versátil e Fácil de usar. Fica implícita a intenção de oferecer a versão remoçada da ferramenta como alternativa para as User Stories. Apesar de ilustrarem sua utilização até em um processo baseado no modelo waterfall. A falta de um comparativo entre User Stories e Casos de Uso, a exemplo do que fizeram James Coplien e Gertrud Bjørnvig em “Lean Architecture“ (Wiley, 2010), reduz o impacto da proposta. Mas, afinal, qual é a proposta?

Jacobson reforça uma mensagem que já apresentava em seus tempos de Rational¹: “casos de uso são a cola de todo o ciclo de vida do processo “. Ou seja, eles “suportam a análise, projeto, planejamento, estimativas, acompanhamento e testes de sistemas”, além da captura de requisitos, é claro.

Um mapa conceitual nos ajuda a entender todos os elementos da proposta e as relações entre eles. Peço desculpas pela redundância mas vou reescrever as partes que representam as maiores alterações (e, tentarei mostrar, os problemas da proposta).

Os interessados (stakeholders): i) são as fontes dos Requisitos; ii) estão envolvidos e priorizam Casos de Uso; e iii) se comunicam contando Histórias.

Até aqui tudo bem, até porque o mapa informa que: iv) Requisitos são capturados na forma de Casos de Uso.  Agora, como falamos aqui no interior, a porca torce o rabo (e a proposta se enrola). Porque é colocado que: v) Casos de Uso são explorados através da narração de Histórias; e vi) seu escopo é gerenciado e endereçado como um conjunto de Fatias de Caso de Uso (Use-Case Slice); que, por sua vez, vii) são identificadas (ou têm sua identificação facilitada) pelas Histórias.

Essas histórias, a princípio, não têm nada a ver com as conhecidas User Stories (não citadas no e-book). Mas é impossível não perceber a intenção de fazer com que elas sejam elaboradas e tratadas da mesmíssima maneira proposta por Kent Beck (em “Extreme Programming Explained” – Addison-Wesley, 1999) e amadurecida por Mike Cohn (“User Stories Applied” – Addison-Wesley, 2004). Uma História, segundo os autores, pode ser qualquer coisa: requisito funcional ou não funcional, um trecho ou fluxo(s) do Caso de Uso, um requisito especial (?) ou ainda um caso de teste. E elas, genéricas (e versáteis assim), ajudariam na identificação de Fatias de Casos de Uso.

Essas Fatias, apresentadas como “o elemento mais importante do Caso de Uso 2.0”, justificariam-se porque, segundo os autores, “precisamos de uma maneira de dividir casos de uso em conjuntos menores”. Li e reli o documento e continuo não acreditando que o próprio cara que inventou a ferramenta e seus naturais mecanismos de quebra (extensão) e organização esteja propondo tamanha confusão. Talvez meus neurônios não tenham percebido o fim das férias, sei lá. O fato é que a proposta, particularmente suas Histórias e Fatias, não parece fazer muito sentido.

Um Caso de Uso é uma maneira mais (ou menos) ESTRUTURADA² de se contar e registrar uma história, um causo. Ele sempre possui um Fluxo Principal (ou Básico), uma sequência natural de interação entre um Ator e um Sistema onde todos os passos são bem sucedidos. Todas as variações ou desvios desta sequência principal são capturados e registrados na forma de Fluxos Alternativos (ou Secundários). Está aqui o primeiro mecanismo natural de ‘quebra’ de um caso de uso. Considero-o natural porque ele reflete a forma do usuário pensar. Uma vez registrado o comportamento mais esperado, como Fluxo Principal, a história se desenrola, por exemplo, em uma sequência de “e se”: “e se o cliente não tiver crédito”, “e se não houver estoque disponível” etc³. Casos de uso são tremendamente eficazes na “descoberta e descrição de requisitos funcionais de um sistema” exatamente porque permitem que uma história seja narrada e estruturada da forma mais natural (e próxima do usuário) possível.

Por que, então, precisaríamos de outros mecanismos de quebra e organização? Para termos elementos ainda menores, que caibam em uma iteração de duas semanas ou em um post-it? Coplien e Bjørnvig, no capítulo 7 do livro citado acima, já haviam dado a receitinha: “qual é a diferença entre a lista de desvios (Fluxos Alternativos) e uma lista de requisitos, features ou User Stories? Quase nenhuma quando olhamos de perto. Podemos formular cada item da lista na forma de User Stories se isso faz com que a gente se sinta mais Agile“. Bem antes deles, no já distante ano 2000, Alistair Cockburn (em “Writing Effective Use Cases” – Addison-Wesley, 2000) já havia sugerido a derivação de uma Lista de Trabalho a partir de um Caso de Uso e seus diversos fluxos (Work List, págs. 172 – 174). Com itens que cabem perfeitamente em um post-it ou, falando mais sério, “cabem” em iterações (sprints) e facilitam o acompanhamento e gerenciamento de um product backlog ou algo parecido. Enfim, Casos de Uso nunca foram monolitos nem nunca levaram a uma situação “tudo ou nada”. Repito: nunca!

Casos de Uso também podem ser vistos ou utilizados como uma “cola que une todas as etapas de um processo de desenvolvimento” desde a criação da UML (1995-1997) e dos derivados do Processo Unificado (1998~). Não creio que serão as sugeridas Fatias que farão, agora, a mágica de viabilizar tal visão. Porque a verdade é que nós nunca (ou, para pegar um pouco mais leve) raramente utilizamos Casos de Uso em toda a sua plenitude. O faremos agora que ele ficou um pouquinho mais complicado?

?

Observações:

1. Lê-se a primeira frase destacada na apresentação “Common Chalenges in Use Case Modeling”, de autoria de Ivar Jacobson e com logo da Rational Software (sem data de publicação).
2. E é esta propriedade fundamental, o fato do Caso de Uso ser uma história ESTRUTURADA, sua principal diferença em relação a outras propostas, particularmente as User Stories. Um Caso de Uso, por natureza, é um conjunto de requisitos que faz todo o sentido para um usuário ou cliente. Um conjunto estruturado. Um conjunto que “entende” sua relação com os demais componentes da solução. Naturalmente.
3. Destaquei o primeiro (Fluxos Alternativos) mas não cito acima os demais “mecanismos naturais de quebras” dos Casos de Uso. Porque aqui a porca torce o rabo de vez e, preciso admitir, alguns mecanismos não são tão naturais assim (Extends e Includes devem ter passado pela sua cabeça). Para não deixar o tema no limbo preciso dizer que Cenários (combinações de passos dos fluxos principal e alternativos) e Casos de Testes são derivados ou componentes de um Caso de Uso e representam outras formas de “quebra”. Serão mais ou menos naturais dependendo da forma como são elaborados.
4. Slice of a Pumpkin Pie, foto que ilustra este artigo, é de autoria de TheCulinaryGeek.

?

Antes de mais nada, os créditos. A principal provocação para o novo modelo veio de “Lean Architecture” (Wiley, 2010), de James Coplien e Gertrud Bjørnvig. O casal, por sua vez, cita os trabalhos de Rebecca Wirfs-Brock (“Designing Scenarios” – Smalltalk Report, nov-dez/1993) e Constantine e Lockwood (“Software for Use: A Practical Guide to Models and Methods of Usage-centered Design” – Addison-Wesley, 1999). Me convenceram da utilidade e necessidade do uso de duas colunas nos fluxos. E provam, em seu livro, como as especificações podem ser ágeis e enxutas. Na semana passada o “pai” dos casos de uso, Ivar Jacobson, publicou um artigo sobre Casos de Uso 2.0. Dele ganhei a confirmação de que casos de uso: i) são tão ágeis quanto você; ii) escalam o quanto você precisar; iii) não tratam apenas de requisitos funcionais; iv) não se limitam a projetos de sistemas; e v) nem aos requisitos – valem em todo o ciclo de vida de um projeto. Usei todas as novas sugestões como complementos ao modelo que utilizava anteriormente e que era fortemente baseado no trabalho de Alistair Cockburn, “Escrevendo Casos de Uso Eficazes” (Bookman, 2008).

Aos iniciados, letrados e usuários super-avançados de casos de uso e afins, um aviso: o modelo aqui sugerido segue tendo como principal motivação o uso didático. Por isso, talvez o modelo não tenha nenhuma utilidade para vocês. Pensei nos iniciantes e em todos que precisam rever seus (pré)conceitos sobre a ferramenta. Me preocupei, principalmente, com todos que precisam de um tipo de guia (e de limites) enquanto aperfeiçoam sua técnica. Vamos ao que interessa.

O modelo anterior era muito pequeno (formato A5), o que impedia seu uso em casos ‘de verdade’. O novo modelo foi diagramado em formato A4 paisagem. Frente (acima) e verso (logo mais) podem ser impressos em uma única folha ou em separado, como explicarei mais tarde. A frente condensa todas as informações fundamentais sobre um caso de uso. Vou apresentá-la por partes.

Cabeçalho

Segue a preocupação com a identificação da fonte e respectivo ponto de vista (estratégico, tático, operacional ou técnico). Incorporei um sofisticado “controle de versões”. Ele me ajuda a reforçar um grito: “joga o caso no lixo! (tão logo dele tenha brotado algum derivado)”.

Finalmente me lembrei dos ícones que determinam o nível de detalhamento do caso. Não, prezadas fábricas de software (sic), não contemplei o tal nível “pré-sal” que vocês insistem em pedir. Mas a nova versão da ostra, quero crer, não gerará mais dúvidas nem piadinhas.

O campo “processo / atividade” serve para referência cruzada com algum diagrama do negócio, de preferência com o PUCS (Process-Use Case Support) ou um diagrama de atividades.

“Valor”, que talvez ainda seja rebatizado “Benefício”, indica como o cliente ou usuário valoriza o caso em questão. “Custo” é a estimativa de esforço do time de desenvolvimento (expressa em unidades relativas, pontos de casos de uso ou qualquer outra unidade de medida). A possível avaliação benefício/custo pode determinar a “Ordem”, a posição do caso no cronograma (ou, de preferência, no backlog do produto). Daí o espaço “Iteração”, onde deve ser registrado a iteração projetada para o trabalho neste caso. Quem não “itera” pode ignorá-lo, sem problemas.

Contexto, Pré e Pós-Condições

Não se trata de um filler, vulgo “encheção de linguiça”. O Contexto nos ajuda a posicionar o caso de uso no projeto, indicando suas relações com outros elementos. É aberto para possibilitar até mesmo o desenho de um pequeno diagrama de casos de uso. Mesmo que fujas dos temidos (e mal compreendidos) extends e includes da vida, você deve achar alguma utilidade para o espaço. Pré e pós-condições não pedem por maiores explicações. Ah, só preciso dizer que elas são um tipo muito especial de Regras de Negócio. Regra do negócio, e não aquele papo de “o usuário tem que estar logado no sistema (sic)”. Pronto, disse.

Fluxo Principal

A conversa devidamente explicitada. Eu evitava o modelo com duas colunas por morrer de medo daqueles que acham que, para cada intenção do ator o sistema deve, obrigatoriamente, dar uma resposta. Desperdício imperdoável de tempo que culminava em obviedades assim: Ator: Indentificar Cliente / Sistema: Exibir nome do cliente. Terrível! Mas Coplien e Bjørnvig me convenceram de que, apesar dos mestres do óbvio, este modelo é realmente mais eficaz.

Ainda assim, o espaço disponível para descrição dos passos do ‘caminho feliz’ segue exíguo para todos aqueles que não acreditam nos limites sugeridos por Coplien (máximo de 7 passos) ou Cockburn (máximo de 9 passos). Só evitei numerá-lo, como no modelo antigo, para deixar o formulário um pouco menos poluído.

Fluxos Alternativos / Instruções para Testes

Está aqui o trecho que mais me custou mais tempo. O número de fluxos alternativos pode ser muito grande, dependendo do caso de uso. Mas a questão não era só essa. Queria contemplar também um espaço para um tipo de Caso de Testes. Acho que consegui matar os dois coelhos. O trecho acima aparece na parte da frente do modelo e em metade do verso. Por isso eu disse que o verso pode ser impresso de forma independente. Ele também contempla outras regras de negócios e outros tipos de requisitos. Quando o espaço não for suficiente, basta imprimir ou utilizar mais páginas apenas com o verso do modelo. Aos campos.

Indicamos o número do passo afetado e o tipo de registro (fluxo Alternativo o Teste). Na sequência, o motivo para o desvio ou então alguma instrução para a execução de testes. Há ainda uma coluna para comentários e outra para a indicação da iteração que deve contemplar a realização deste fluxo alternativo. Esta ideia combina bem com os slices propostos por Ivar Jacobson no referido artigo. Combina ainda mais com as sugestões apresentadas em “Lean Architecture” (em resumo: em um projeto tocado por um método iterativo, os incrementos são fluxos dos casos de uso. Ex: em uma iteração você entrega o fluxo principal, na seguinte dois fluxos alternativos e assim por diante).

Se a ferramenta é escalável, como confirma Jacobson, o modelinho também deve ser. Daí a diagramação do verso, exibida abaixo.

?

Utilizarei este modelo nas próximas edições de meus treinamentos. Acho que só depois de duas ou três experiências terei noção das alterações necessárias. Ou seja, novidades sobre o tema só no final de novembro. Enquanto isso, se você quiser brincar um pouco com o modelo, faça o download aqui: bit.ly/UCfinito. Claro que estou contando com seu retorno, experiências, críticas e sugestões. Desde já agradeço. Abraços!

Obs.:

1. Nunca antes na história deste blog o nome de uma imagem combinou tanto com o conteúdo. “Extracting Knowledge” é de autoria do HikingArtist e foi legalmente surrupiada no Flickr.
2. Depois de meus canhotos rabiscos, todo o trampo artístico e de diagramação foi do mano Gus Vasconcellos, da Opção Artes Gráficas. Não sei o que seriam de meus rabiscos sem a colaboração dele.

O que não desvaloriza seu diagnóstico objetivo e claro do momento atual da UML. Sim, a UML ganha uma segunda vida. Ou deveríamos dizer segunda chance? Até a Microsoft, que parecia ter sugerido de forma um tanto ingênua que DSL’s (Domain-Specific Languages) seriam alternativas à UML, agora destaca seu amplo suporte como um diferencial da nova versão do Visual Studio¹. São diversos os sinais que indicam um tipo de renascimento da UML. O que fazer para evitar um novo ciclo de desilusões e abandono?

Deveríamos começar por uma isenta avaliação de tudo o que fizemos de errado na primeira onda. Em primeiro lugar há nossa irritante mania de viver colocando a carroça na frente dos bois. A adoção da UML significou, para várias organizações, a aquisição de ferramentas caríssimas. Os fornecedores dessas ferramentas, cumprindo bem o seu papel, prometiam maravilhas. Particularmente em relação ao aumento da produtividade dos desenvolvedores. Ignoravam ou faziam vista grossa para um contexto mais amplo. A incorporação da UML normalmente fazia parte de um plano maior: a implantação de novos métodos de trabalho. Numa cumbuca mais sortida que feijoada baiana fica difícil apontar responsáveis diretos por ganhos ou perdas. E a UML acabou pagando muito mais do que devia. Tanto que até hoje encontramos pessoas que acham que UML é uma “metodologia”.

Ensinar UML através de uma ferramenta é como ensinar matemática com calculadoras: um grande e sério erro.

Desconfio que a raiz do problema está na forma como UML é ensinada e aprendida. O ensino da UML através de uma ferramenta, qualquer ferramenta, é um grande erro. Tão sério quanto ensinar matemática com calculadoras. Os alunos não têm a chance de perceber a UML como ela é, como uma Linguagem. E as limitações das ferramentas, que não são poucas, acabam interpretadas como limitações da linguagem.

Por exemplo, não é raro encontrar pessoas que dizem que o desenho ao lado é um erro. Para elas a UML seria um simples padrão de notação. E, como tal, estaria restrita às figurinhas oferecidas nas ferramentas. Considero este o mais sério e comprometedor problema que temos com a UML. Uma limitação que nos leva a utilizá-la da mesma maneira que um compositor de funk carioca utiliza a língua portuguesa.

Como toda linguagem, do português ao C#, a UML é viva. É extensível. Podemos e devemos adaptá-la às nossas necessidades. Mas fizemos um serviço tão ruim neste ponto que existem aqueles que acham que a possibilidade de criar extensões como a EPBE (Eriksson-Penker Business Extensions) é gambiarra ou correção de bugs, não uma característica projetada da linguagem.

Ao ensinar UML devemos abandonar toda e qualquer ferramenta automatizada. Lápis e páginas de caderno são tudo o que precisamos para ensinar e aprender UML. Um profissional que domine bem os conceitos da linguagem saberá tirar mais valor de qualquer ferramenta que lhe seja oferecida. E assim, talvez, aquelas promessas maravilhosas dos fornecedores de ferramentas se realizem.

Grande Demais, Complexa pra Chuchu

Não deveríamos ensinar português através da gramática e sim com Chico Buarque e Machado de Assis.

São outras críticas comuns, que aparecem principalmente no discurso de alguns agilistas. Toda linguagem é naturalmente complexa. Ou, melhor colocando: toda gramática², em sua plenitude, é naturalmente complexa. O fato é que pouquíssimos de nós dominamos a gramática da língua portuguesa, por exemplo. Mas isso não impede que utilizemos a língua das mais diversas maneiras em nosso dia a dia. O mesmo precisa ser dito sobre a UML. Ninguém precisa conhecer de cor e salteado toda a especificação e o metamodelo da UML, sua gramática, para poder utilizá-la. Aliás, se quisermos espantar fregueses, basta apresentar a UML desta forma.

A UML é grande por necessidade, não por pura encheção de linguiça. E parece complexa para todos que não entendem ou não aceitam sua proposição original, de ser uma Linguagem Unificada de Modelagem. Ela é perfeita? Claro que não – fomos nós humanos que a criamos. É boa? Sim, eu diria excelente. Mas talvez esteja aqui seu grande problema: não há nada que possa ser comparado à UML. Lá em meados dos anos 90 tínhamos dezenas de propostas de padrões de notação. A UML veio para acabar com aquela baderna. Mas seu sucesso e consequente aceitação universal – um tipo de monopólio – criou este problema. Ela não é pior nem melhor nem maior nem mais complexa que ninguém simplesmente porque não temos com o que comparar.

UML não é Chacrinha

O Chacrinha dizia que tinha vindo para “complicar, não para explicar”. O maior objetivo da UML é o oposto. E, de novo, tenho que apelar para o “L” de UML: toda linguagem criada pelo homem tem esse único objetivo, facilitar a comunicação. Mas não são poucas as organizações que destruíram esse propósito quando instituíram que UML era “padrão de documentação”. Quando passaram a exigir que esse ou aquele diagrama fossem elaborados com o único propósito de documentar determinado trecho de um projeto. Nada pode ser mais nocivo e criar mais antipatia a uma proposta do que a percepção de obrigatoriedade descerebrada ou insensata. Por isso não são poucos os que fazem cara de nojo quando ouvem as letrinhas U-M-L. Passa da hora de devolvermos à UML suas proposições originais: explicar, e não complicar; Facilitar a comunicação e interação, e não substituí-las.

Confesso que a ficha do péssimo uso que fazemos da UML só caiu quando comecei a participar de alguns fóruns e a apresentar meus eventos para analistas de negócios. Cheguei a acreditar na realização da profecia sugerida na capa da Software Development de abril de 2001, apresentada acima. Mas aí vieram o artigo do Jacobson, debates mais ricos, empresas interessadas na ressurreição da UML e a onda do Pensamento Visual. Taí, a UML realmente tem sua segunda chance. Ou eu deveria dizer que nós temos uma segunda chance?

.:.

Observações:

1. Na revista INFO de junho/2010 tem um anúncio do Visual Studio, apresentado na forma de uma entrevista com o gerente de produtos da Microsoft Brasil, Sr. Rodrigo de Carvalho. A primeira pergunta é: “Por que clientes devem migrar para a nova versão do Visual Studio 2010?”. Resposta: “Por várias razões, mas destacaria: suporte à modelagem UML…“. Sim, ele começou pelo suporte à UML. Quem conhece o histórico das idas e vindas da MS em relação à UML entenderá o meu destaque aqui.
2. Gramática, segundo o Houaiss, é um “conjunto de regras que determinam o uso correto de uma língua”.
   Não exagero quando trato a especificação da UML como um tipo de gramática. E reitero objetivando a aceitação de que UML é de fato uma língua. E que, como tal, ela deve nos ajudar a atender três grandes objetivos: i) Organizar o conhecimento; ii) Representar o conhecimento; e iii) Trocar conhecimentos.

A EPBE (Eriksson-Penker Business Extensions), como o nome indica, foi desenvolvida por Hans-Erik Eriksson e Magnus Penker. Foi apresentada no ano 2000, no livro “Business Modeling with UML – Business Patterns at Work“. Como o título indica, o livro tem objetivos bem maiores. Mas a compreensão da EPBE está em seu núcleo. Mas o que é, afinal, a EPBE?

A EPBE é uma extensão da UML (Unified Modeling Language). Foi desenhada para possibilitar o uso da UML na modelagem de negócios. A UML é extensível, e várias outras especializações existem: sistemas Web, modelagem de bases de dados, sistemas embarcados etc. Estendemos a UML através de três elementos: estereótipos (stereotypes), valores nomeados (tagged values) e restrições (constraints). Quando uma organização ou equipe faz um uso maduro da UML, ela cria suas próprias extensões. Evita-se a “reinvenção da roda” quando se parte de uma extensão existente, como a EPBE, por exemplo.

Mas a EPBE “reinventou a roda”, não? Afinal, no ano 2000, já existiam diversos padrões de notação para a modelagem de negócios. A justificativa para sua criação é exatamente essa: existiam diversos padrões – o que é o mesmo que dizer que não existia padrão nenhum. A mesma razão, em outro domínio, motivou Grady Booch, Ivar Jacobson e James Rumbaugh a criarem a UML. E por que utilizar a UML como base para a modelagem de negócios?

Segundo os criadores da EPBE, a primeira motivação são os “conceitos similares: um negócio pode ser descrito em termos de processos que satisfazem objetivos através da colaboração de diferentes tipos de recursos. Regras definem condições e restrições sobre como os processos e recursos devem se relacionar e como devem se comportar. Tudo isso pode ser mapeado em objetos, relacionamentos e interações entre objetos” .

Outras razões apontadas por Eriksson e Penker são: i) a maturidade da UML (e da orientação a objetos); ii) a notação padrão (de facto); iii) o aprendizado rápido; e, iv) a nova e fácil maneira de ver a organização e o negócio. Vale reforçar a motivação descrita no parágrafo anterior com outra leitura: negócio e TI teriam uma mesma linguagem padrão de modelagem. Os benefícios são óbvios.

Do mesmo parágrafo podemos extrair os 4 elementos fundamentais que utilizamos para descrever qualquer negócio:

• Recursos: é tudo o que a empresa utiliza, consome ou produz. São as pessoas, materiais, informações e produtos. Recursos são manipulados através de processos, ou os manipulam e gerenciam. E são classificados como: físicos, abstratos e de informação.
  Para ficar um pouco mais claro: uma nota fiscal é um recurso abstrato, assim como uma ordem de compra ou um “bilhete azul”. Quando uma nota fiscal é registrada em uma base de dados, por exemplo, torna-se um recurso de informação.
• Processos: são as atividades realizadas pelo negócio. Eles descrevem como o trabalho é executado na empresa, e são delimitados por regras.
• Regras: são as definições ou restrições de algum aspecto do negócio. Regras determinam como um negócio deve ser gerenciado ou como os recursos devem ser estruturados e utilizados. Elas podem ser criadas pela própria empresa ou são impostas por entidades externas (governo, associações, sindicatos etc).
• Objetivos: representam a razão da empresa, ou os resultados que o negócio espera atingir. Objetivos podem ser divididos e distribuídos entre os diversos processos da empresa. Objetivos expressam o estado desejado de determinados recursos (caixa, estoque, market share – por exemplo), e são atingidos através dos processos. O conjunto dos objetivos de alto nível forma a estratégia da empresa.

A lista acima pode ser resumida da seguinte forma: Os objetivos do negócio são atingidos através da execução de processos que usam, transformam e geram recursos, sempre respeitando e seguindo um conjunto de regras. O diagrama ao lado representa esta lógica.

Para entender e aceitar a EPBE, além de compreender os elementos fundamentais descritos acima, é necessário entender o que é a Modelagem de Negócios e para que ela serve. Modelamos um negócio com o objetivo de simplificá-lo. Criamos abstrações ou analogias de uma forma que facilite a compreensão, a documentação e a comunicação de todos os aspectos principais de um negócio. Nós modelamos um negócio para:

• Fornecer uma base que apóie a criação de sistemas de informação;
• Criar um ponto de partida para iniciativas de melhoria da estrutura e dos processos de negócio;
• Experimentar novos conceitos e desenhos;
• Identificar oportunidades de outsourcing; e
• Facilitar a integração com entidades externas.

Tratando especificamente de projetos de sistemas de informação, podemos dizer que a modelagem de negócios também serve para :

• Entender a estrutura e a dinâmica da organização;
• Compreender os problemas da organização e identificar oportunidades de melhoria;
• Garantir que clientes, usuários e desenvolvedores compartilham uma mesma visão do negócio; e
• Extrair requisitos do sistema.

Do que consiste um modelo de negócio? Ele é formado por três partes principais:

• Visões: é impossível descrever completamente um negócio sob um único ponto de vista. Existem quatro categorias de visões: Visão do Negócio, Visão dos Processos, Visão da Estrutura e Visão do Comportamento.
  Obs.: nas próximas partes desta série as visões serão apresentadas de forma mais detalhada.
• Diagramas: toda visão é representada por um ou mais diagramas, que representam partes específicas da estrutura ou da dinâmica do negócio. Diagramas são compostos por objetos e processos.
• Objetos e Processos: Objetos representam todos os recursos, enquanto os processos representam qualquer atividade ou função executada no negócio.

A mensagem mais importante até aqui é a seguinte: Modelar é Simplificar. Modelamos um negócio para facilitar sua compreensão, entender seus problemas correntes e identificar oportunidades de melhoria. Em projetos de sistemas de informação, a modelagem de negócio é lançada para municiar da melhor forma possível a equipe que criará a solução. A EPBE é “só” um padrão de notação. É diferente de outras propostas porque: i) Usa o mesmo padrão dos sistemas, a UML; e, ii) É completa.

A EPBE não é um processo ou metodologia nem pretende sê-lo; O uso da EPBE não implica necessariamente em BDUF (big design up front) ou na utilização de processos “waterfall”; A EPBE não concorre com BPMN e afins – na realidade estes podem ser utilizados como um sub-conjunto da EPBE.

No próximo artigo veremos como a EPBE descreve a Estrutura de um negócio. E no seguinte, como ela é utilizada para modelar Processos de negócio.

Bibliografia:

1. Business Modeling with UML – Business Patterns at Work
   Hans-Erik Eriksson e Magnus Penker. Wiley (2000).
2. The Rational Unified Process – An Introduction (2nd Edition)
   Philippe Kruchten. Addison-Wesley (2000).

Observação:

* – Para não cometer uma total injustiça: o livro “UML 2.0 – Do Requisito à Solução“, de Adilson da Silva Lima, tem um capítulo inteiro dedicado à EPBE. Pelo que sei, é o único em língua portuguesa que toca no assunto. Se tudo der certo, ele perderá o monopólio em março de 2008, quando meu livro deve chegar em algumas prateleiras. Eu disse lá em cima que o livro de Eriksson e Penker é o único porque o Adilson limita-se, como eu aqui nesta série de artigos, a dar um overview da EPBE. Ou seja: EPBE na íntegra, só no original.

Sem querer o Agnello me possibilitou duas coisas: validar a recepção dos AN’s e da EPBE em um grupo “pesado”, o UML-BR. Poder debater e trocar idéias com José Paulo Papo, MTierno, Juan Bernabó, Rodrigo Yoshima e outros é sempre enriquecedor. O outro “brinde” veio hoje: a “desconfiança” de que ninguém utiliza a EPBE. O grupo BPM tem 500 e poucos participantes. Há duas horas eu só penso nisso.

Caramba, baseei boa parte do meu trabalho para formação de analistas de negócios na EPBE e nos conceitos apresentados por seus idealizadores, Hans-Erik Eriksson e Magnus Penker, no livro “Business Modeling with UML“. Nessa altura do campeonato, na reta final e de certa forma cansado do tema, a última coisa que eu preciso é de dúvidas sobre uma das partes principais de minha “tese”. Não estou falando das dúvidas e críticas dos outros. Estou falando que eu não posso duvidar de minhas sugestões. Mas, no cansaço e com um probleminha chato nas costas, confesso que hesitei por alguns minutos: “caramba, ninguém usa isso!”.

Me lembrei que já passei por isso antes. No final de 98, por exemplo, quando falava que ia utilizar UML em um grande projeto, um monte de gente me olhou com cara de interrogação, tipo: “que p**** é essa?”. Dali até os primeiros diagramas de seqüência com algum sentido passou um certo tempo. Dali até uma certa aceitação da UML foi outro tanto de tempo. Mês que vem a UML completará 10 anos de existência. Sob um prisma – caramba, é uma linguagem! – ela é muito nova. Por outro – pô, informática! – ela é velha. Mas a EPBE é do ano 2000. E parece não ter aceitação nenhuma*! O que pode estar errado?

Richard Lingner, em sua participação na thread do BPM, apresentou algumas razões: “a EPBE não é mantida pelo OMG e também não é difundida ou suportada por empresas e ferramentas”. Seria outro caso de uma boa idéia carente de um bom marketing.

Mas quem a considera uma boa idéia? Definitivamente, eu não estou sozinho. Vejam, por exemplo, as avaliações que os leitores do livro “Business Modeling with UML” no site da Amazon. Surrupiarei alguns trechos:

“The ‘Eriksson-Penker extensions for business modelling’ are important because several UML-based case tools have now implemented them as an emerging standard for business process modelling with UML. If you want to fully understand how these work, this is the book to read.”
– A.K. Johnston

“Sometime ago I have been wondering if somebody will try to bridge the gap between business modeling (the one used by consultants) and software engineering. It would certainly make it easier for people to understand and explain business operations. This book is an application of the UML into the realm of business modeling. It is very good in the sense that it explains and goes through the patterns that form business models.”
– J. Chong

Claro, tem também algumas críticas negativas (ao livro). Mas sua média é 4 estrelas! As avaliações que citei são de 2003 e 2000, respectivamente. E, sabe-se lá a razão, parece que pouquíssimos conhecem a EPBE.

Suspeito que o buraco é mais embaixo. Como eu disse no post anterior, a análise e modelagem de negócios é a disciplina mais ignorada em nossos projetos. E quando ela aparece, em modelos RUP-like, é meio capenga**. Se a disciplina é negligenciada, o que esperar das ferramentas que devem suportá-la? Correndo o risco de ser (muito) chato, vou reforçar minha suspeita: currículos, processos e metodologias dão atenção desproporcional para o domínio da solução; Parecemos adorar “analistas-programadores”; Esquecemos que sem o correto domínio do problema podemos gerar falsas e caras soluções.

Essa questão me preocupa bem mais que a aceitação ou não da EPBE. A EPBE é só uma extensão de uma linguagem. É só uma ferramenta. Ferramentas passam. Mas eu acho que o OMG e todos os fornecedores de ferramentas CASE que ignoram a EPBE estão perdendo uma bela oportunidade. O OMG, por exemplo, poderia incorporar a extensão e adicionar a opção BPMN à ela. Reforçariam assim a UML, expandindo consideravelmente o seu público. Sendo chato (de novo!), reforço as motivações para sua utilização:

1. UML já é uma linguagem madura e consolidada;
2. Utilizada amplamente no domínio da solução;
3. Por que não utilizá-la também para a modelagem do problema?
4. Assim, TI e negócio teriam pela primeira vez em sua história uma mesma língua – mesmo que ela seja “só” para modelagem.

Pronto, minhas dúvidas já se dissiparam. E as suas?

Observações:

* Os workshops para formação de analistas de negócios já contaram com mais de 150 participantes. A EPBE é apresentada neles, mas de forma breve. Então, só depois do treinamento que ocorre agora em novembro poderei dizer se a EPBE ganhou novos adeptos.

** Adjetivos pouco nobres (como o “capenga” acima) vivem me criando problemas. Um dia foram as “bullshitagenzinhas ágeis”. Hoje foi o BPMN “bonitinho”. Não adianta, não me livro deles. Não acho sinônimos que passem exatamente o que quero expressar naquele momento. Até me arrependo depois. Mas, na hora – na lata, não edito não. Também não edito depois, a menos que alguém se diga ofendido. Nunca aconteceu.

No UML-BR, “brigando” com o MT na questão “BUC’s X EPBE”, eu usei “fraquinho” no lugar do “capenga”. É a mesma coisa. Fica feio do mesmo jeito. Peço desculpas.

Mas aqui cabe uma explicação: sou fã do Jacobson. Seu “The Object Advantage – Business Process Reengineering with Object Technology” é fonte frequente de consulta para desenvolvimento do meu material. Mas, definitivamente, casos de uso de negócio e modelos de objetos de negócio não são ferramentas legais para a análise e modelagem de negócios. Probleminha básico: assim como a BPMN, são incompletos. A arquitetura de um negócio é descrita em quatro visões: Negócio, Estrutura, Processos e Comportamento. Qualquer proposição que vise a análise e modelagem de negócios deve cobrir as 4 visões. Ponto.

Dica levemente acoplada: não percam o artigo de hoje do Philip “Shoes” Calçado, no Fragmental.

Como já reclamei aqui em outras ocasiões, nossa área adora reinventar algumas coisas. Começar do zero, ao invés de melhorar algo que já existe. Assim nasceram as User Stories, peça fundamental da metodologia-religião popularmente conhecida como XP (eXtreme Programming). Segundo um de seus apóstolos, as User Stories são formadas por três elementos:

• Cartão: onde escrevemos as estórias ;
• Conversas: que nos levariam a entender e detalhar as estórias; e
• Confirmação: o ‘the end’, o fim da estória.

A motivação para tamanha invenção gira em torno da palavrinha ‘documentação’ (um dos pecados mortais, segundo aquela doutrina). Por isso outro apóstolo reforça: “os cartões representam os requisitos do cliente, mas não os documentam”. Vai na linha de um mestre-pacificador (mezzo tucano) que vive insistindo: “gente, modelagem não é documentação… modelagem não é documentação… isso é um mito”. Documentação parece um trauma incurável. Mas falarei mais sobre isso em outras oportunidades. A história aqui são as estórias.

No post anterior eu destaquei um probleminha com o processo adotado pela Anne: “Nós organizamos as cento e poucas estórias por processos de negócios…”. Vai na linha do problema reconhecido por aquele primeiro apóstolo (que escreveu um livro só sobre estórias) : “É difícil saber por onde começar”.

Se o trabalho começa por uma correta análise do negócio e seus processos, não devem existir dúvidas sobre o ponto de partida. Ao organizar os trabalhos de coleta e análise de requisitos a partir dos processos de negócio, não existe o trabalho de “organização de estórias”. Assim, não há justificativas para adoção do POREM (Post-it-Oriented Requirements Elicitation Method).

Ironias à parte, o fato é que as user stories, apesar de bem intencionadas, trazem mais problemas (inclusive alguns que não existiam antes) do que soluções. Sua granularidade e a doentia independência dificultam o gerenciamento; Tornam as atividades de priorização e planejamento das iterações bastante confusas. Ou seja, sua utilização em projetos médios e grandes deve ser um pesadelo .

Se começamos do começo, ou seja, pela análise do negócio e seus processos, é mais natural a adoção dos Casos de Uso como técnica para coleta, organização e análise de requisitos. Segundo seu criador , “um caso de uso é o nosso constructo para um processo de negócio”; ” descrevem o negócio e o seu ambiente”.

A adoção de casos de uso não significa, de maneira alguma, deixar de ser ágil. Aliás, se bem adotada, a técnica deve promover maior agilidade do que as estórias. As 6 qualidades das boas estórias também devem caracterizar os bons casos de uso :

• Independentes: até o limite onde a independência é desejável, ou seja, até o ponto em que ela não gere surpresas e omissões no projeto;
• Negociáveis: se o cliente e demais stakeholders não puderem negociar os casos de uso, o que sobra?
• Valiosos para Usuários e Clientes: óbvio? Nem tanto. Vide o tanto de caso de uso descrevendo CRUD’s e afins por aí.
• Estimáveis: ok, UCP‘s são frágeis. Tanto quanto todos os outros métodos conhecidos. Mas, independente do método, casos de uso são (ou deveriam ser) estimáveis.
• Pequenos: não tanto quanto uma história, mas o suficiente para representar uma unidade significativa para o negócio (seja ela uma tarefa, atividade ou processo). Se um caso de uso for grande ou de difícil leitura ele está errado – regrinha básica;
• Testáveis: wow. Outra regrinha: se não pode ser testado então não é um caso de uso. Deriva de outra regrinha que diz que : “Se um requisito não pode ser testado então ele não é um requisito”.

Resumo da ópera cômica: sejamos ecologicamente responsáveis: post-its e cartões são feitos de árvores; vamos parar com esse papo de ‘casa de ferreiro… espeto de bambu’ (bambu solta farpas); municiemos nossas equipes e stakeholders com informações consistentes, bem pensadas, analisadas e estruturadas…

… começando do começo: o Negócio.

Notas:

1. Não tenho (quase) nada contra XP e afins. Meu problema é só com os fundamentalistas mal educados e donos da verdade suprema. XP e afins foram úteis, representaram um avanço, chacoalharam o status quo. Ou seja, foram um mal necessário.
   
2. User Stories Applied: For Agile Software Development
   Mike Cohn. Addison-Wesley (2004).
   Obs: Mesmo autor do artigo sobre UCP referenciado acima.
3. Lembram-se daqueles livrinhos da Ediouro que sempre traziam uma discussão sobre “estória versus história”? Pois é, me lembrei deles na hora de traduzir stories.
4. The Power of Stories
   Rachel Davies. XP 2001.
5. Debunking Modeling Myths
   Scott W. Ambler. Software Development (Agosto/2001).
6. Deve ser (um pesadelo). Nunca testei e nunca terei coragem para tanto.
7. The Object Advantage – Business Process Reengineering with Object Technology
   Ivar Jacobson. Addison-Wesley (1995).
8. Requirements-Led Project Management
   Suzanne e James Robertson. Addison-Wesley (2005).