Os principais problemas no desenvolvimento de sistemas de gestão são: 1) o alto custo para implementar novos requisitos de negócio, 2) arquiteturas se tornam ultrapassadas rapidamente, e 3) profissionais ficam defasados rapidamente. A solução é tratar negócio e tecnologia separadamente usando modelos executáveis que permitem a separação entre negócio e tecnologia.

1. Separando Arquitetura e
Negócios em Sistemas de
Gestão
Rafael Chaves
http://abstratt.com
rafael@abstratt.com
twitter: @abstratt

2. Palestrante
● Formação
○ bacharel (2000) e mestre (2004) em Computação
(UFSC)
● Experiência
○ Perfil/Datasul CRM (2001-2002)
○ OTI/IBM Canada: Eclipse (2002-2005)
○ IBM Canada: Jazz/Team Concert (2005-2006)
○ Genologics: Desenv. Senior/Arquiteto (2008-2012)
● Hoje
○ Desenvolvendo Cloudfier (2012-)
○ Consultor em Engenharia de Software (2013-)

3. Desenvolvimento de aplicações de negócios é
extremamente ineficiente
A solução é tratar negócio e tecnologia
separadamente
Demonstração
Modelos executáveis como mecanismo para
separação entre negócio e tecnologia
Discussão / comentários / perguntas*
Visão geral

4. Quais os maiores problemas do
desenvolvimento de software de
gestão?

5. a) Custo de implementar um novo requisito de negócio,
mesmo que relativamente simples, ainda é muito alto
b) Arquitetura se torna ultrapassada rapidamente, difícil
mantê-la atualizada
c) Profissionais ficam defasados rapidamente, difícil manter-
se atualizado
d) Muito tempo e dinheiro gasto com tecnologia, quando o
que devia importar é o negócio
e) ...
Problemas em desenvolvimento de
software de gestão

6. Sistemas de Gestão
Conhecimento do negócio
(domínio do problema)
+
Arquitetura (tecnologia)

7. Sistema de Contabilidade em Cobol
Sistema de Controle de Estoque em Delphi
Sistema de Gestão de Relacionamento com
Clientes (CRM) em Java
Sistema de Compras em .Net
Exemplos

8. Arquitetura (tecnologia)
●linguagens de programação (Java, C#, Ruby)
●interface com usuário (HTML, Swing, WinForms)
●integração (SOAP, REST, CORBA, JMS, sockets)
●persistência (SQL, No-SQL, prevalence)
●ambiente operacional (hardware, SO, rede etc)
●paralelismo, transações, distribuição, logging,
auditoria, síncrono vs. assíncrono, local vs. remoto, ativo
vs. passivo…
Definindo dois universos diferentes

9. Definindo dois universos diferentes
Conhecimento do negócio
● entendimento do domínio do problema (jurídico, obras, ...)
● necessidades dos clientes (o que é ou não importante)
● como atendê-las (solução conceitual)

10. Comparando dois universos diferentes
Arquitetura (tecnologia)
●custo de se construir solução concreta (o "meio")
●não é diferencial competitivo significativo (commodity)
●independente de domínio
●trivial, bem compreendida, padronizada, repetitiva
●estabilidade: volátil (um a dois anos)
●linguagem: bem servidas pelas linguagens técnicas
convencionais

11. Comparando dois universos diferentes
Conhecimento do negócio
●a essência do valor da solução (o "fim")
●diferencial competitivo
●independente de tecnologia
●estabilidade: depende do domínio
●linguagem: linguagens técnicas convencionais deixam a
desejar

12. Empresas de software de gestão
não são empresas de tecnologia,
são empresas especializadas em
gestão de negócios
(valor produzido vs. instrumento aplicado)

13. Implementando Sistemas de Gestão
(idealmente)
Conhecimento do negócio
(domínio do problema)
+
Tecnologia (arquitetura)
(Custo Total = Custo N + Custo A)

14. Implementando Sistemas de Gestão
(na prática)
Conhecimento do negócio
(domínio do problema)
X
Tecnologia (arquitetura)
(Custo Total = Custo N * Custo A)

15. Implementando Sistemas de Gestão
(na prática)
Cliente, Produto, Pedido,
Pagamento...
X
Classe de domínio, Repositório,
Serviço, tabela do BD,
representação API, ...

16. Implementando Sistemas de Gestão
(na prática)
Classe de domínio Produto
Classe repositório Produto
Classe serviço Produto
Tabela Produto
Representação XML Produto
API Produto
...

17. Implementando Sistemas de Gestão
(na prática)
Classe de domínio Cliente
Classe repositório Cliente
Classe serviço Cliente
Tabela Cliente
Representação XML Cliente
API Cliente
...

18. Implementando Sistemas de Gestão
(na prática)
Classe de domínio Pedido
Classe repositório Pedido
Classe serviço Pedido
Tabela Pedido
Representação XML Pedido
API Pedido
...

19. Implementando Sistemas de Gestão
(na prática)
Classe de domínio Pagamento
Classe repositório Pagamento
Classe serviço Pagamento
Tabela Pagamento
Representação XML Pagamento
API Pagamento
...

20. Implementando Sistemas de Gestão
(na prática)
20 entidades do negócio (N)
x
5 artefatos por entidade (A)

21. Implementando Sistemas de Gestão
(na prática)
50 entidades do negócio (N)
x
7 artefatos por entidade

22. Uma nova entidade precisa ser criada
Um novo atributo precisa ser adicionado
Um elemento da arquitetura precisa ser adicionado
Um elemento da arquitetura precisa ser modificado
Um elemento da arquitetura precisa ser removido
O que acontece quando...

23. Problema

24. Arquitetura e Negócio são
completamente diferentes

25. Arquitetura e Negócio requerem
linguagens diferentes

26. Arquitetura e Negócio requerem
talentos diferentes

27. Arquitetura e Negócio provêem
valores diferentes

28. Arquitetura e Negócio são
completamente independentes

29. Ainda assim,
Arquitetura e Negócio são tratadas:
● pelas mesmas pessoas
● usando as mesmas linguagens
● ao mesmo tempo

30. POR QUÊ?

31. Solução: tratar negócio e tecnologia
separadamente
● Com pessoas diferentes
● Usando linguagens diferentes

32. Demonstração

33. Modelos Executáveis
Abordagens:
● Executable UML (OMG)
● DSM
Produtos:
● PathfinderMDA, Bridgepoint, MetaEdit+,
Cloudfier*
Adoção:
● Automotiva, Telecom, Defesa, Aeronáutica,
Seguros, Controle e Automação

34. Modelos Executáveis
Programas minimalistas, focam na essência
(dica: não é a tecnologia)

35. Modelos Executáveis
Mas completos e precisos sobre o que
interessa
(dica: não é a tecnologia)

36. Modelos Executáveis
Programas num nível de abstração mais
apropriado (>3GL)

37. Modelos Executáveis
Plataforma de execução não determina a
ferramenta de desenvolvimento

38. Modelos Executáveis
Arquitetura definida externamente,
aplicada automaticamente

39. “Programando"
modelos executáveis
com Cloudfier

40. Negócio
Tecnologia

41. Tecnologia
ManualNegócio
Automático

42. Entities
Relationships
Constraints
Actions
States
Events
Services
Roles
Tecnologia
Manual
Automático

43. Persistence
Querying
Authorization
REST API
Text search
Integration
Simple UI (or BYOUI)
Authentication
Backups
Scaling
Email notifications
Usage-based billing
Payment processing
Prog. language
Entities
Relationships
Constraints
Actions
States
Events
Services
Roles
Manual
Automático

44. STRUCTURE
Entities
Properties
Relationships

45. BEHAVIOR AND RULES
Actions
Constraints
Derivations

46. DYNAMICS
State machines
Triggers
Signals / Events

47. INTEGRATION
Components
Ports
Services

48. REST API

49. BANCO DE DADOS
select * from "ifrs-cloudfier-examples-meeting"."meeting_User"
id | name | email | username
----+------------------+---------------------+---------------------
6 | David Green | dgreen@tasktop.com |
2 | Andrew Eisenberg | andrew@eclipse.org |
4 | Rafael Chaves | rafael@abstratt.com | rafael@abstratt.com
14 | Test User | test@test.com | test@test.com
(4 rows)

50. BANCO DE DADOS
d "ifrs-cloudfier-examples-meeting"."meeting_Meeting"
Table "ifrs-cloudfier-examples-meeting.meeting_Meeting"
Column | Type | Modifiers
-------------+-------------------+-----------
id | bigint | not null
title | character varying | not null
description | character varying | not null
date | date | not null
organizer | bigint | not null
Indexes:
"meeting_Meeting_pkey" PRIMARY KEY, btree (id)
Foreign-key constraints:
"organizer" FOREIGN KEY (organizer) REFERENCES "ifrs-cloudfier-
examples-meeting"."meeting_User"(id) DEFERRABLE INITIALLY DEFERRED
Referenced by:
TABLE ""ifrs-cloudfier-examples-meeting"."meeting_Participation""
CONSTRAINT "meetings" FOREIGN KEY (meetings) REFERENCES "ifrs-cloudfier-
examples-meeting"."meeting_Meeting"(id) ON DELETE CASCADE

51. CUSTOM UI

54. Revisando

55. Solução conceitual
completamente definida
independentemente da arquitetura
●nível de abstração mais adequado
●independência de tecnologia
●portabilidade e reuso

56. Avaliação de solução conceitual via
interface c/ usuário prototípica
●comunicação entre stakeholders técnicos e do
negócio
●feedback pode ser obtido e incorporado
imediatamente
●iterações sobre a solução conceitual muito mas
eficiente sem envolver tecnologia

57. Testes de unidade e aceitação
definidos no nível conceitual
● codificação precisa dos requisitos
● validação automática da solução conceitual sem
requerer geração de código

58. Estratégias de implementação
definidas como mapeamentos
automáticos
●arquitetura “codificada” no gerador de código
●combinação automática de negócio c/ tecnologia
●reuso de decisões técnicas no produto ou entre
produtos
●agilidade na evolução da arquitetura
●próprias ou de terceiros

59. Referências
Blog
http://abstratt.com/blog/category/editorial/
UML executável
http://www.executableumlbook.com/
http://www.omg.org/spec/FUML/
http://www.omg.org/spec/ALF/
Cloudfier/TextUML
http://cloudfier.com
http://doc.cloudfier.com
http://textuml.org

60. Separando Arquitetura e
Domínio em Sistemas de
Gestão
Rafael Chaves
http://abstratt.com
rafael@abstratt.com
twitter: @abstratt