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

478 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
478
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

×