Marco Mendes´s Blog

O termo domínio é utilizado para denotar ou agrupar um conjunto de sistemas ou de áreas funcionais que exibam funcionalidades similares.

Exemplos de domínio incluem:

• Domínio de Telecomunicações
• Domínio Logístico Atacadista
• Domínio Bancário
• Domínio de Seguros de Saúde
• Domínio Acadêmico Escolar

Podemos então descrever o domínio aplicacional como sendo uma coleção de aplicações de software que partilham um determinado conjunto de características. Da mesma forma, o domínio é definido por um conjunto de características que descrevem uma família de problemas para os quais uma determinada aplicação pretende dar solução.

Um modelo de domínio é um artefato comum em várias metodologias (RUP ou escolas ágeis) usado para expressar um determinado domínio, normalmente em linguagem UML.

Antes de definir este artefato, vamos dizer o que não é este modelo. Um modelo de domínio não é um diagrama de classes em nível de análise, um diagrama de classes em nível de desenho, muito menos um modelo de entidades e relacionamentos (DER). Um modelo de domínio não carrega informaçães técnicas (Java ou C#), que devem estar presentes em um modelo de desenho. Um modelo de domínio também não carrega todo o detalhamento do comportamento e estrutura (operações e atributos), que devem estar presentes em um modelo de análise. Um modelo de domínio também não carrega informações de armazenamento de informações ou normalizações, que devem estar presentes em um DER.

Mas, afinal, o que é um modelo de domínio?

1. Um modelo de domínio é um produto da modelagem de negócios, i.e., ele representa, em certa escala, o negócio sendo modelado e compreendido.

2. Um modelo de domínio deve, por consequência, ser realizado inicialmente pelos analistas de negócios e usuários do projeto, e revisado e complementado pelo máximo de participantes de um projeto. O modelo de domínio deve ser um artefato colaborativo, compartilhado por todo o time do projeto.

3. Um modelo de domínio captura o vocabulário do sistema ou negócio sob modelagem. Como exemplo, um modelo de domínio de um sistema acadêmico de uma faculdade irá possuir os elementos Aluno, Professor, Curso, Disciplina ou Matrícula, entre diversos outros. Podemos perceber, então, que o modelo de domínio expressa o glossário do negócios sob modelagem.

4. Um modelo de domínio é uma representação lógica e estrutural de elementos do domínio e seus relacionamentos. Um diagrama de classes UML possui os elementos necessários para esta estruturação. Normalmente os conceitos de classes, associações e generalizações são suficientes para estruturar um modelo de domínio. Como consequência, um modelo de domínio não captura interações temporais ou representações físicas de modelagem.

5. Um modelo de domínio expressa uma visão conceitual preliminar acerca de um sistema e é chamado de diagrama de classes conceitual por alguns autores. Um exemplo extraído do excelente site do Scott Ambler (http://www.agilemodeling.com) de modelagem de domínio representa esta idéia.

(c) Scott Ambler, 2003-2006.

6. Um modelo de domínio deve ser feito no começo do projeto. Temporalmente, ele deve ser expresso e ganhar maturidade até o primeiro décimo do projeto. Por exemplo, se você tem na sua mão uma demanda de dois meses, devemos conseguir um modelo de domínio relativamente estável até o fim da primeira semana. Isso requer, como pode ser imaginado, um esforço intenso com os usuários chave para capturar o vocabulário, glossário e representá-lo em UML.

7. Um modelo de domínio (enquanto artefato) não precisa ser evoluído formalmente no restante do projeto. Isto pode parecer estranho, mas o objetivo do modelo de domínio é capturar o negócio e servir de insumo para a geração de modelos mais formais como o diagrama de classes ou o DER e depois o código executável. Em outras palavras, podemos imaginar o modelo de domínio como um estágio evolucionário para gerarmos os diagramas estruturais, comportamentais e o código de um projeto de software. Cabe citar que o modelo de domínio, enquanto conceito, como bem capturado pelas resenhas a este blog, evolui sempre, isto é, o diagramas de classes, o DER e o código também refletem conceitualmente o domínio do problema e por isso podem ser entendidos como “modelos de domínio”.

8. Um modelo de domínio também é um padrão arquitetural para a modelagem de sistemas OO, padrão este que encapsula lógica de negócios e dados em entidades coesas. Uma referência mais densa sobre este aspecto pode ser encontrada no excelente livro Patterns of Enterprise Application Architectures (http://martinfowler.com/books.html#eaa), do autor Martin Fowler. Recomendo também o artigo Anemic Domain Model (http://www.martinfowler.com/bliki/AnemicDomainModel.html) como anti-exemplo do uso deste padrão.

9. Um modelo de domínio pode carregar padrões de análise. Um padrão de análise não é um padrão técnico (desenho ou arquitetura), mas uma representação conveniente para expressar um aspecto de negócio em sistemas de informação. Exemplos de padrões de análise envolvem a representacão de quantidades (monetárias ou medicamentos), a representação de faixas de valores (início/fim), padrões contábeis (parcelamentos de dívidas, contratos) ou representação de papéis (roles). O site sobre Analysis Patterns (http://martinfowler.com/articles.html#ap) do autor Martin Fowler traz informações valiosas sobre este tópico.

Se você não entendeu nada até o momento, um exemplo pode ajudar a colocar alguma luz neste conceito. Vamos assumir que você precise representar o domínio de sistemas de gestão da geração e transmissão de energia elétrica. Um modelo de domínio que mostra este negócio em termos de seus elementos (ex: transformador, consumidor de energia) e relacionamentos é mostrado aqui.

Compilo aqui, para os mais interessados neste artefato e nesta técnica, uma lista de referências mais técnicas de modelagem de domínio de vários especialistas de mercado.

• ICONIX: http://www.ddj.com/architect/184414689 - Fornece uma visão sobre os 10 erros mais comuns na modelagem de domínio de sistemas computacionais.
• Introduction to Class Normalization - http://www.agiledata.org/essays/classNormalization.html - Fornece uma visão evolutiva sobre modelagem de classes em UML.
• Agile Modeling – http://www.agilemodeling.com/essays/amddPresentation.htm - Traz princípios complementares sobre a modelagem ágil de sistemas.
• Análise Robusta – http://www.agilemodeling.com/artifacts/robustnessDiagram.htm e http://www.ddj.com/architect/184414712 - Técnica complementar à modelagem de domínio para capturar entidades, comportamentos e fronteiras de um sistema.

Se a sua empresa lembra o programa Zorra Total, talvez seja interessante trocar de canal. A troca de canal significa pensar sua empresa como uma coleção de processos e implementar práticas ágeis de BPM e BPM Enabled by SOA. Experiências a respeito são sempre uma boa fonte de inspiração e por isso compartilho neste brevíssimo blog uma coletânea de dezenas de filmes SOA compilados pela IBM.
Filmes e WebCasts SOA

Acredito que independente da sua escolha de fornecedor, estes vídeos fornecem exemplos, relatos, experiências e casos de sucesso da adoção de BPM e SOA em empresas de toda sorte.

Recomendo também, para complementar estes webcasts, o espaço SOA da IBM (SOA Space). O SOA Space é um mash-up (portal Web 2.0) com dezenas de portlets com conteúdos variados e informativos sobre SOA.

Uma suíte BPMS (Business Process Management Suites) é um conjunto de ferramentas para a modelagem de processos de negócio (BPM) fim a fim, cobrindo diversos aspectos como a modelagem, simulação, orquestração, monitoração e geração de indicadores de desempenho de processos de negócio; entre outros.

O Gartner divulgou recentemente um relatório onde avalia e compara suítes de gerenciamento de processos de negócio. Um resumo rápido da situação é colocada na figura abaixo.

Além das 22 excelentes ferramentas comparadas neste estudo do Gartner, notamos que o mercado de ferramentas para BPM está em franca expansão também na comunidade de ferramentas livres e open-source. Bons exemplos incluem:

• JBOSS jBPM - Suíte para modelagem e orquestração baseado na linguagem jPDL.
• Intalio: Suíte completa BPMS para modelagem, simulação, orquestração e monitoração com suporte a BPEL.

Realizamos uma apresentação sobre qualidade de software dirigida por processos de negócio no Segundo Seminário de Testes e Qualidade de Software organizado em Belo Horizonte. O mote central da apresentação foi na necessidade da TI repensar suas ações através de um alinhamento mais formal com as necessidades de negócio de uma organização. A partir disso, exploramos na apresentação algumas técnicas de qualidade para implementar este alinhamento, através de um ciclo de vida de desenvolvimento orientado por processos de negócio.

A apresentação está em anexo aqui.

Nesta apresentação divulgamos também ferramentas open-source/gratuitas de apoio para o ciclo de vida de modelagem de processos de negócio.
Um resumo segue abaixo:

BPMS

• Intalio BPMS
• Tibco Business Studio
• JBOSS jBPM

Reuso de Ativos

• RAS Repository for Workgroups
• Open UDDI

A área de TI cada dia conta com mais (e melhores) corpos de conhecimento para vários papéis de engenharia de software, gerência e outras áreas. Compilo aqui um conjunto de BOKs de renome reconhecido e de grande valor para projetos de TI.

• PMBOK: Clássico corpo de conhecimento do PMI. Atualmente em sua terceira edição (inclusive em português), compila as melhores práticas para a gerência de projetos para as áreas de gerência integrada, de escopo, qualidade, custo, prazo, recursos humanos, aquisições, riscos e comunicações. Outros excelentes corpos de conhecimento do PMI incluem o corpo de conhecimento para gerência de portfólios de projetos e o corpo de conhecimento para gerência de programas (conjunto de projetos relacionados em um tema).
• SWEBOK: Iniciativa de grande qualidade do IEEE, traz um excelente conjunto de referências para informações primárias sobre requisitos, desenho, construção, implementação, qualidade de software, gerência de projeto, processos de software, ferramentas e métodos.
• BABOK: Corpo de conhecimento para modelagem de processos de negócio do Instituto Internacional de Analistas de Negócio.
• EABOK: Corpo de conhecimento de arquiteturas corporativos do MITRE. Outros corpos de conhecimento sobre arquitetura corporativa incluem o DODAF (do Departamento de Defesa Americano), MODAF (Governo Inglês), o SEI Feature Oriented Domain Analysis, o TOGAF ( do Open Group) e talvez o mais conhecido deles, o Zachman Framework.
• Usability Body of Knowledge: Corpo de conhecimento de usabilidade da associação de professionais de usabilidade.

Um aspecto fundamental em arquiteturas orientadas por serviço é a gerência contínua da qualidade em todo o ciclo de desenvolvimento de processos de negócio e serviços. Em um recente evento de SOA organizado pela Squadra, apresentamos um modelo de qualidade contínua para o suporte ao desenvolvimento orientado por serviços baseado em idéias da IBM e da nossa experiência na condução de alguns projetos desta natureza.

Uma conclusão importante apresentada neste trabalho é que a qualidade de software está cada vez mais ancorada no atendimento a processos de negócio ponta a ponta, implementando o conceito de governança de TI, chave para qualquer implementação SOA. Colocamos no final da apresentação também um conjunto de recursos para aqueles que tiverem um interesse de se aprofundar neste instigante tema.

A apresentação realizada está disponibilizada aqui para download.

Um termo que ganha cada vez mais momento nos noticiários de TI é o BPM. O BPM significa Business Process Management e pode mudar a forma com que a TI desenvolve sistemas. Mas, afinal, o que é o BPM?

Para entendermos o BPM, precisamos entender primeiramente como a TI desenvolve software hoje. Podemos resumir o processo da forma abaixo:

1. O analista de requisitos entrevista um conjunto de usuários para coletar suas necessidades para desenvolver uma visão sobre o sistema ser montado.

2. Após uma série de entrevistas e reuniões, uma específicação de requisitos é produzida.

3. Em paralelo, o time de arquitetura técnica começa a trabalhar os requisitos suplementares do sistema (segurança ou desempenho, por exemplo) e trabalhar os riscos técnicos de um projeto através de testes preliminares. Uma arquitetura executável é produzida como resultado desta tarefa.

4. Após uma fase de maturação dos requisitos, o sistema começa a ganhar corpo e é implementado e testado funcionalmente.

5. O sistema é colocado em ambiente de testes de homologação até que atinja estabilidade para ser colocado em produção.

O ciclo acima, com pequenas variações, parece ser bem adequado. Muitas vezes, entretanto, o sistema colocado em produção não melhora a lucratividade ou outras metas de uma empresa. Isso ocorre porque a TI não tem fim em si mesma. A TI serve apenas a um propósito maior, que é fazer uma empresa funcionar mais eficientemente. A questão que se coloca é como uma empresa funciona com mais eficácia e eficiência.

A chave para esta resposta é com um processo de negócio mais adequado. Um processo de negócio é a descrição de um conjunto de procedimentos que envolve pessoas, tarefas, máquinas, softwares e outros elementos coordenados para atingir metas (objetivos) de negócio. Por exemplo, podemos ter uma meta em um banco de trazer 30M de reais em um ano através de novas contas. Isso pode ser realizado de várias formas, mas apenas os processos eficientes e eficazes podem implementar esta meta. Nesta hora o BPM entra em ação. O BPM é uma metodologia que permite que um especialista (ex: em operações bancárias) defina ou experimente diversos processos de negócio (ex: abertura de conta) e veja qual o mais efetivo.

O BPM pode ser feito apenas em papel, através de modelos e diagramas como os clássicos workflows. Entretanto, workflows não são modelos vivos e deixam muita margem para especulação ou incertezas.

O BPM pode ser feito através da geração de demandas para a TI para a construção de sistemas, experimentado hipóteses de negócios. Infelizmente, este processo é muito lento pois a construção de sistemas de informação é naturalmente demorada e o custo de readaptações nos sistemas é inviável.

Recentemente, o BPM ganhou força com ferramentas que permitem não somente expressar um processo de negócio através de seus componentes (pessoas, tarefas, máquinas, softwares), como também exprimir custos, tempo e consumo de recursos para cada um destes componentes. O analista de negócio pode então criar um simulacro do mundo real, desde que possua um profundo conhecimento do negócio (ex: abertura de contas bancárias). Além disso, algumas ferramentas podem literamente simular os diversos cenários propostos pelos analistas e gerar métricas de eficiência temporal ou monetária para o processo. Cenários podem ser comparados e o melhor cenário é passado para a TI para ser automatizado como um sistema de informação.

Exemplos de ferramentas que suportam estes modelos incluem:
- JBOSS jPBM (open-source)
- IBM WebSphere Business Modeler (Ferramenta mais robusta e profissional para BPM)

Modelos BPM podem ser expressos em linguagems vivas como o BPEL, que permitem a simulação de um workflows em um engine de simulação, presentes nas ferramentas acima. Modelos BPEL podem ser exportados como modelos UML para a TI ou mesmo ser incorporados em orquestradores de processo (ex: IBM WebSphere Process Server) para execução real.

A forma de trabalho da TI é diferente e pode ser então reescrita da seguintes forma:

1. O analista de negócio simula diversos processos de negócio para promover o alinhamento das metas organizacionais. Os melhores processos de negócio são escolhidos para automatização parcial (dado que componentes do processo de negócio envolvem seres humanos, como um correntista no processo de abertura de uma conta).

2. O analista de requisitos entrevista um conjunto de usuários para coletar suas necessidades para desenvolver uma visão sobre o sistema ser montado, que irá automatizar parte do processo de negócio.

3. Após uma série de entrevistas e reuniões, uma específicação de requisitos é produzida.

4. Em paralelo, o time de arquitetura técnica começa a trabalhar os requisitos suplementares do sistema (segurança ou desempenho, por exemplo) e trabalhar os riscos técnicos de um projeto através de testes preliminares. Uma arquitetura executável é produzida como resultado desta tarefa.

5. Ainda em paralelo, o time de arquitetura de negócio “coreografa’ o processo de negócio em uma ferramenta de orquestração. Cada elemento do processo de negócio será possivelmente automatizado como um ou mais serviços. (Por exemplo, a verificação de restrições bancárias em um sistema de abertura de contas pode ser implementada através de um ou mais serviços que consultam o Banco Central, CDL ou SERASA, por exemplo. Tecnicamente, estes serviços podem ser implementados em WebServices com o suporte de linguagens como Java ou C#).

6. Após uma fase de maturação dos requisitos, o sistema começa a ganhar corpo e é implementado e testado funcionalmente. O sistema agora não é mais uma peça monolítica, mas um conjunto de serviços (Web Services) que juntos formam workflows (processos de negócio derivados dos modelos BPEL dos analistas de negócios).

7. O sistema é colocado em ambiente de testes de homologação até que atinja estabilidade para ser colocado em produção.

Claramente, o sistema implementado agora estará alinhado com o negócio. Se o negócio mudar (e irá mudar), o ciclo é realizado em termos de manutenções evolutivas. Entretanto, esta dinâmica pode ser realizada de forma muito mais ágil que os antigos sistemas monolíticos pois o sistema é implementado como um conjunto de serviços, dirigido *por* workflows de negócio. Os serviços podem então ser re-arranjados muito mais facilmente para se adaptar às mudanças com menor custo.

Mais informações sobre BPM podem ser achadas aqui.
O padrão OASIS BPEL é descrito aqui