Separando Arquitetura e Negócios em Sistemas de

Gestão

Rafael Chaveshttp://abstratt.com

rafael@abstratt.comtwitter: @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 | 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)

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

rafael@abstratt.comtwitter: @abstratt