EPBE: Introdução
Chororô só não basta. E não dá para esperar que todo mundo com um mínimo de curiosidade compre o único livro* que documenta a EPBE (Eriksson-Penker Business Extensions) ou participe dos meus eventos. Então, começo agora uma pequena série com um objetivo muito simples: explicar o básico da EPBE e compará-la com outras propostas.
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" [1].
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:
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:
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:
* - 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.
.:.
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" [1].
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.
- 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.
- 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:
- Business Modeling with UML - Business Patterns at Work
Hans-Erik Eriksson e Magnus Penker. Wiley (2000). - The Rational Unified Process - An Introduction (2nd Edition)
Philippe Kruchten. Addison-Wesley (2000).
* - 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.
.:.
Marcadores: analista_de_negócios, cursos_e_palestras, epbe, modelagem_de_negócios, uml
quinta-feira, 25 de outubro de 2007 |
Assine o finito
Lista completa no del.icio.us
Pois é, depois de ler esse excelente post, acho que estamos falando a mesma coisa mas usando termos diferentes.
O EPBE é o que fazemos quando seguimos o processo de análise de negócios proposto por Howard Podeswa, um dos revisores do BABOK 2) em:
UML for the IT Business Analyst: A Practical Guide to Object Oriented Requirements Gathering este livro somado ao Writing Effective Use Cases forma uma dupla da pesada para quem está a caminho da análise de negócios.
"UML for the IT Business Analyst"
O nome do livro diz tudo não? Assim que eu vi na Amazon eu encomendei e valeu a pena. Tem tudo a ver com a introdução que você faz quando começa a explicar EPBE.
Elevar o nível de abstração tratando os elementos do negócio como objetos traz ganhos enormes para resolver problemas no nível certo.
A idéia da metodologia é trabalhar os níveis diferentes em momentos diferentes, no início, casos de uso de negócio (texto e/ou diagrama - caixa branca), diagramas de classe e máquinas de estados com alto nível de abstração, depois de todas as questões do negócio resolvidas e acertadas e o comportamento do negócio mapeado temos concluída a etapa que ele chama de BOOM, Business Object Oriented Modeling.
Eu acho essa etapa excepcional pois conseguimos resolver muitas questões sem utilizar a palavra "sistema". Além disso, é aqui que podemos influir para melhorar os processos da organização.
Depois de criado o processo e a área de análise de negócios notamos através do apontamento de horas que ficamos mais tempo no negócio do que no sistema e que isso tem trazido uma queda expressiva nos incidentes relacionados à má definição do escopo.
Depois de pronta essa etapa ficamos muito mais tranqüilos para definir os casos de uso de sistema (metas do usuário) que irão suportar os processos do negócio. Junto com eles vêm as classes e máquinas de estados, bem mais próximos dos diagramas gerados pelos analistas de sistemas, mas sem métodos, só propriedades e vínculos.
Desta forma eu posso dizer que adoro EPBE e nem sabia!
O seu curso deve ser muito interessante, pois além de bem embasado, é inovador, não vejo ninguém falando desses assuntos desta maneira aqui no Brasil. Espero ter a oportunidade de participar de um curso e trocar umas idéias pessoalmente.
Abraço,
Kerber ITBA
Analista de Negócios
Oi Kerber,
antes de mais nada, grato pelo comentário e pelos elogios.
Sim, temos as mesmas preocupações. Mas repare que a EPBE é um tanto diferente das referências citadas por ti. A principal: não existem "casos de uso de negócio" ou BUC (Business Use Cases).
Nos artigos seguintes desta série as diferenças serão melhor explicadas. Cogito inclusive escrever um artigo só com comparações.
Outra coisa que me encuca um pouco: ITBA, ou o Analista de Negócios de TI. Ainda não *entendo* bem a separação. A necessidade da separação.
Conheço o livro citado por ti. É bom, mas joga boa parte das fichas no uso da UML como proposto no RUP. A EPBE é um tanto diferente. E, no meu ponto de vista, mais completa. Espero que você siga gostando da EPBE, que não é nem pretende ser uma metodologia, ok?
Abraços,
A importância da engenharia de requisitos nos projetos de sistemas está ficando mais evidente. Uma dessas evidências é o artigo de Ricardo Veríssimo na Webinsider.
Mesmo sem dar nomes aos bois (o AN não foi citado) a importância desse processo está clara. Contudo, muito pouco é explorado no que tange à Modelagem de Negócios, deixando a atuação do nosso lado sempre passiva, documentando o que já existe ou o que o especialista do domínio quer.
São duas áreas de atuação no escopo da análise de negócios e aparentemente serão duas brigas implantá-las.