Separando Arquitetura e
Negócios em Sistemas de
Gestão
Rafael Chaves
http://abstratt.com
rafael@abstratt.com
twitter: @abs...
Palestrante
● Formação
○ bacharel (2000) e mestre (2004) em Computação
(UFSC)
● Experiência
○ Perfil/Datasul CRM (2001-200...
Desenvolvimento de aplicações de negócios é
extremamente ineficiente
A solução é tratar negócio e tecnologia
separadamente...
Quais os maiores problemas do
desenvolvimento de software de
gestão?
a) Custo de implementar um novo requisito de negócio,
mesmo que relativamente simples, ainda é muito alto
b) Arquitetura s...
Sistemas de Gestão
Conhecimento do negócio
(domínio do problema)
+
Arquitetura (tecnologia)
Sistema de Contabilidade em Cobol
Sistema de Controle de Estoque em Delphi
Sistema de Gestão de Relacionamento com
Cliente...
Arquitetura (tecnologia)
●linguagens de programação (Java, C#, Ruby)
●interface com usuário (HTML, Swing, WinForms)
●integ...
Definindo dois universos diferentes
Conhecimento do negócio
● entendimento do domínio do problema (jurídico, obras, ...)
●...
Comparando dois universos diferentes
Arquitetura (tecnologia)
●custo de se construir solução concreta (o "meio")
●não é di...
Comparando dois universos diferentes
Conhecimento do negócio
●a essência do valor da solução (o "fim")
●diferencial compet...
Empresas de software de gestão
não são empresas de tecnologia,
são empresas especializadas em
gestão de negócios
(valor pr...
Implementando Sistemas de Gestão
(idealmente)
Conhecimento do negócio
(domínio do problema)
+
Tecnologia (arquitetura)
(Cu...
Implementando Sistemas de Gestão
(na prática)
Conhecimento do negócio
(domínio do problema)
X
Tecnologia (arquitetura)
(Cu...
Implementando Sistemas de Gestão
(na prática)
Cliente, Produto, Pedido,
Pagamento...
X
Classe de domínio, Repositório,
Ser...
Implementando Sistemas de Gestão
(na prática)
Classe de domínio Produto
Classe repositório Produto
Classe serviço Produto
...
Implementando Sistemas de Gestão
(na prática)
Classe de domínio Cliente
Classe repositório Cliente
Classe serviço Cliente
...
Implementando Sistemas de Gestão
(na prática)
Classe de domínio Pedido
Classe repositório Pedido
Classe serviço Pedido
Tab...
Implementando Sistemas de Gestão
(na prática)
Classe de domínio Pagamento
Classe repositório Pagamento
Classe serviço Paga...
Implementando Sistemas de Gestão
(na prática)
20 entidades do negócio (N)
x
5 artefatos por entidade (A)
Implementando Sistemas de Gestão
(na prática)
50 entidades do negócio (N)
x
7 artefatos por entidade
Uma nova entidade precisa ser criada
Um novo atributo precisa ser adicionado
Um elemento da arquitetura precisa ser adicio...
Problema
Arquitetura e Negócio são
completamente diferentes
Arquitetura e Negócio requerem
linguagens diferentes
Arquitetura e Negócio requerem
talentos diferentes
Arquitetura e Negócio provêem
valores diferentes
Arquitetura e Negócio são
completamente independentes
Ainda assim,
Arquitetura e Negócio são tratadas:
● pelas mesmas pessoas
● usando as mesmas linguagens
● ao mesmo tempo
POR QUÊ?
Solução: tratar negócio e tecnologia
separadamente
● Com pessoas diferentes
● Usando linguagens diferentes
Demonstração
Modelos Executáveis
Abordagens:
● Executable UML (OMG)
● DSM
Produtos:
● PathfinderMDA, Bridgepoint, MetaEdit+,
Cloudfier*...
Modelos Executáveis
Programas minimalistas, focam na essência
(dica: não é a tecnologia)
Modelos Executáveis
Mas completos e precisos sobre o que
interessa
(dica: não é a tecnologia)
Modelos Executáveis
Programas num nível de abstração mais
apropriado (>3GL)
Modelos Executáveis
Plataforma de execução não determina a
ferramenta de desenvolvimento
Modelos Executáveis
Arquitetura definida externamente,
aplicada automaticamente
“Programando"
modelos executáveis
com Cloudfier
Negócio
Tecnologia
Tecnologia
ManualNegócio
Automático
Entities
Relationships
Constraints
Actions
States
Events
Services
Roles
Tecnologia
Manual
Automático
Persistence
Querying
Authorization
REST API
Text search
Integration
Simple UI (or BYOUI)
Authentication
Backups
Scaling
Em...
STRUCTURE
Entities
Properties
Relationships
BEHAVIOR AND RULES
Actions
Constraints
Derivations
DYNAMICS
State machines
Triggers
Signals / Events
INTEGRATION
Components
Ports
Services
REST API
BANCO DE DADOS
select * from "ifrs-cloudfier-examples-meeting"."meeting_User"
id | name | email | username
----+----------...
BANCO DE DADOS
d "ifrs-cloudfier-examples-meeting"."meeting_Meeting"
Table "ifrs-cloudfier-examples-meeting.meeting_Meetin...
CUSTOM UI
Revisando
Solução conceitual
completamente definida
independentemente da arquitetura
●nível de abstração mais adequado
●independênci...
Avaliação de solução conceitual via
interface c/ usuário prototípica
●comunicação entre stakeholders técnicos e do
negócio...
Testes de unidade e aceitação
definidos no nível conceitual
● codificação precisa dos requisitos
● validação automática da...
Estratégias de implementação
definidas como mapeamentos
automáticos
●arquitetura “codificada” no gerador de código
●combin...
Referências
Blog
http://abstratt.com/blog/category/editorial/
UML executável
http://www.executableumlbook.com/
http://www....
Separando Arquitetura e
Domínio em Sistemas de
Gestão
Rafael Chaves
http://abstratt.com
rafael@abstratt.com
twitter: @abst...
Separando arquitetura e negócios em sistemas de gestão
Separando arquitetura e negócios em sistemas de gestão
Próximos SlideShares
Carregando em…5
×

Separando arquitetura e negócios em sistemas de gestão

487 visualizações

Publicada em

Os males do desenvovimento de software de gestão são oriundos da falta de separação entre tecnologia e negócios.

Modelos executáveis são uma abordagem para realizar tal separação.

Cloudfier é uma ferramenta/plataforma que implementa modelos executáveis em UML.

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
487
No SlideShare
0
A partir de incorporações
0
Número de incorporações
10
Ações
Compartilhamentos
0
Downloads
2
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Separando arquitetura e negócios em sistemas de gestão

  1. 1. Separando Arquitetura e Negócios em Sistemas de Gestão Rafael Chaves http://abstratt.com rafael@abstratt.com twitter: @abstratt
  2. 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. 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. 4. Quais os maiores problemas do desenvolvimento de software de gestão?
  5. 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. 6. Sistemas de Gestão Conhecimento do negócio (domínio do problema) + Arquitetura (tecnologia)
  7. 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. 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. 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. 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. 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. 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. 13. Implementando Sistemas de Gestão (idealmente) Conhecimento do negócio (domínio do problema) + Tecnologia (arquitetura) (Custo Total = Custo N + Custo A)
  14. 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. 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. 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. 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. 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. 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. 20. Implementando Sistemas de Gestão (na prática) 20 entidades do negócio (N) x 5 artefatos por entidade (A)
  21. 21. Implementando Sistemas de Gestão (na prática) 50 entidades do negócio (N) x 7 artefatos por entidade
  22. 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. 23. Problema
  24. 24. Arquitetura e Negócio são completamente diferentes
  25. 25. Arquitetura e Negócio requerem linguagens diferentes
  26. 26. Arquitetura e Negócio requerem talentos diferentes
  27. 27. Arquitetura e Negócio provêem valores diferentes
  28. 28. Arquitetura e Negócio são completamente independentes
  29. 29. Ainda assim, Arquitetura e Negócio são tratadas: ● pelas mesmas pessoas ● usando as mesmas linguagens ● ao mesmo tempo
  30. 30. POR QUÊ?
  31. 31. Solução: tratar negócio e tecnologia separadamente ● Com pessoas diferentes ● Usando linguagens diferentes
  32. 32. Demonstração
  33. 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. 34. Modelos Executáveis Programas minimalistas, focam na essência (dica: não é a tecnologia)
  35. 35. Modelos Executáveis Mas completos e precisos sobre o que interessa (dica: não é a tecnologia)
  36. 36. Modelos Executáveis Programas num nível de abstração mais apropriado (>3GL)
  37. 37. Modelos Executáveis Plataforma de execução não determina a ferramenta de desenvolvimento
  38. 38. Modelos Executáveis Arquitetura definida externamente, aplicada automaticamente
  39. 39. “Programando" modelos executáveis com Cloudfier
  40. 40. Negócio Tecnologia
  41. 41. Tecnologia ManualNegócio Automático
  42. 42. Entities Relationships Constraints Actions States Events Services Roles Tecnologia Manual Automático
  43. 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. 44. STRUCTURE Entities Properties Relationships
  45. 45. BEHAVIOR AND RULES Actions Constraints Derivations
  46. 46. DYNAMICS State machines Triggers Signals / Events
  47. 47. INTEGRATION Components Ports Services
  48. 48. REST API
  49. 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. 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. 51. CUSTOM UI
  52. 52. Revisando
  53. 53. Solução conceitual completamente definida independentemente da arquitetura ●nível de abstração mais adequado ●independência de tecnologia ●portabilidade e reuso
  54. 54. 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
  55. 55. 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
  56. 56. 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
  57. 57. 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
  58. 58. Separando Arquitetura e Domínio em Sistemas de Gestão Rafael Chaves http://abstratt.com rafael@abstratt.com twitter: @abstratt

×