Separando Arquitetura e Negócios em Sistemas de
Gestão
Rafael Chaveshttp://abstratt.com
[email protected]: @abstratt
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-)
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
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 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
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 Clientes (CRM) em Java
Sistema de Compras em .Net
Exemplos
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
Definindo dois universos diferentesConhecimento 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)
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
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
Empresas de software de gestãonão são empresas de tecnologia, são empresas especializadas em
gestão de negócios
(valor produzido vs. instrumento aplicado)
Implementando Sistemas de Gestão(idealmente)
Conhecimento do negócio(domínio do problema)
+Tecnologia (arquitetura)
(Custo Total = Custo N + Custo A)
Implementando Sistemas de Gestão(na prática)
Conhecimento do negócio(domínio do problema)
XTecnologia (arquitetura)
(Custo Total = Custo N * Custo A)
Implementando Sistemas de Gestão(na prática)
Cliente, Produto, Pedido, Pagamento...
XClasse de domínio, Repositório,
Serviço, tabela do BD, representação API, ...
Implementando Sistemas de Gestão(na prática)
Classe de domínio ProdutoClasse repositório Produto
Classe serviço ProdutoTabela Produto
Representação XML ProdutoAPI Produto
...
Implementando Sistemas de Gestão(na prática)
Classe de domínio ClienteClasse repositório Cliente
Classe serviço ClienteTabela Cliente
Representação XML ClienteAPI Cliente
...
Implementando Sistemas de Gestão(na prática)
Classe de domínio PedidoClasse repositório Pedido
Classe serviço PedidoTabela Pedido
Representação XML PedidoAPI Pedido
...
Implementando Sistemas de Gestão(na prática)
Classe de domínio PagamentoClasse repositório Pagamento
Classe serviço PagamentoTabela Pagamento
Representação XML PagamentoAPI Pagamento
...
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 adicionado
Um elemento da arquitetura precisa ser modificado
Um elemento da arquitetura precisa ser removido
O que acontece quando...
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êemvalores 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*
Adoção:● Automotiva, Telecom, Defesa, Aeronáutica,
Seguros, Controle e Automação
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
EntitiesRelationshipsConstraints
ActionsStatesEvents
ServicesRoles
Tecnologia
Manual
Automático
PersistenceQuerying
AuthorizationREST API
Text searchIntegration
Simple UI (or BYOUI)
AuthenticationBackupsScaling
Email notificationsUsage-based billingPayment processing
Prog. language
EntitiesRelationshipsConstraints
ActionsStatesEvents
ServicesRoles
Manual
Automático
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 ----+------------------+---------------------+--------------------- 6 | David Green | [email protected] | 2 | Andrew Eisenberg | [email protected] | 4 | Rafael Chaves | [email protected] | [email protected] 14 | Test User | [email protected] | [email protected](4 rows)
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 nullIndexes: "meeting_Meeting_pkey" PRIMARY KEY, btree (id)Foreign-key constraints: "organizer" FOREIGN KEY (organizer) REFERENCES "ifrs-cloudfier-examples-meeting"."meeting_User"(id) DEFERRABLE INITIALLY DEFERREDReferenced by: TABLE ""ifrs-cloudfier-examples-meeting"."meeting_Participation"" CONSTRAINT "meetings" FOREIGN KEY (meetings) REFERENCES "ifrs-cloudfier-examples-meeting"."meeting_Meeting"(id) ON DELETE CASCADE
CUSTOM UI
Revisando
Solução conceitual completamente definida
independentemente da arquitetura
● nível de abstração mais adequado● independência de tecnologia
● portabilidade e reuso
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
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
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
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.comhttp://doc.cloudfier.comhttp://textuml.org
Separando Arquitetura e Domínio em Sistemas de
Gestão
Rafael Chaveshttp://abstratt.com
[email protected]: @abstratt