Post on 26-May-2015
description
Livre reprodução, desde que citada a fonte. www.fgsl.eti.br @fgsl
Quem sou eu
Autor
Instrutor
Arquiteto e DesenvolvedorCertificado
Livre reprodução, desde que citada a fonte. www.fgsl.eti.br @fgsl
Especialista em história em quadrinhos http://perse.doneit.com.br
romocavaleirodoespaco.blogspot.com
Arquitetura de Software
Arquitetura é a essência da estrutura: é a forma A estrutura ofusca a forma
Arquitetura Enxuta: entrega sob demanda de funcionalidades, o que realmente gera valor.
Arquitetura Ágil: a que suporta mudança, interação com o usuário final, descoberta e fácil compreensão (de funcionalidades)
Lean Architecture“Arquitetura Enxuta”
Lean Architecture“Arquitetura Enxuta”
O “Pensamento Enxuto” (Lean Thinking), surgiu no final dos anos 80 do século XX, em um projeto do MIT sobre a indústria automobilística mundial.
A pesquisa mostrou que a Toyota havia desenvolvido um novo paradigma de gestão nas principais dimensões dos negócios.
Em 2009, a Toyota tornou-se a maior em volume de vendas, mostrando as vantagens e benefícios do sistema que desenvolveu.
Lean Architecture“Arquitetura Enxuta”
O “Pensamento Enxuto” é uma estratégia de negócios para aumentar a satisfação dos clientes através da melhor utilização dos recursos.
O foco da implementaçao deve estar nas reais necessidades dos negócios.
Qual o valor da arquitetura?
A arquitetura suporta “o que acontece lá”. Código habitável – pelas pessoas que
desenvolvem e pelas pessoas que o usam. A arquitetura é o que faz o código parecer
familiar. Uma boa arquitetura reduz lixo e inconsistência
Menos retrabalho Consistência do sistema
Arquitetura e Orientação a Objetos
Orientação a Objetos (OO) é um paradigma – um modo de falar sobre a forma.
Fundamentos de OO: capturar o modelo mental do usuário final no código.
OO captura As entidades (objetos) que os usuários conhecem As classes que servem como conjuntos de tais
objetos.
MVC
O que é isso? Algum mnemômico para Twitter?
Model View Controller
Model
Controller
View
Model View Controller
View Model
Controller
Projeto MVC
Projeto MVC
<?phpnamespace Mvc\Controller;
abstract class Controller{
}
<?phpnamespace Mvc\View;
abstract class View{
}
<?phpnamespace Mvc\Model;
abstract class Model{
}
Não ficou claro...
Então vamos recorrer às analogias.
Modelo
Visão
Controlador
Capitão Marvel
Capitão Marvel
Remember, remember...
Um mesmo nome identifica duas entidades distintas.
O nome por si só, não tem nenhum significado. O nome é apenas um dado. Mas o dado, dentro de um contexto, traz
informação para o receptor.
Contexto
MVC é a encarnação da visão OO
O modelo mental do usuário é introduzido no código.
O objetivo das visões é a manipulação direta – a interação com o usuário.
O objetivo do controlador é coordenar múltiplas visões. Os dados do modelo podem ser apresentados de várias formas.
Como nasceu o MVC
O cientista norueguês Trygve Reenskaug estava desencantado com a arquitetura das linguagens Simula e Smalltalk.
Em 1978, ele apresentou um padrão de projeto chamado Model-View-Controller-User.
MVCU?Mas onde foi parar o U?
Os objetivos do MVCU
Deixar que os usuários interagissem diretamente com o código que foi projetado como uma reflexão de seus próprios modelos mentais. É pra isso que serve a visão.
Permitir que o usuário coordene várias visões simultâneas do mesmo modelo. É pra isso que serve o controlador.
Isso é baseado na hipótese de que basta modelar a noção que o usuário final tem sobre o sistema de objetos.
Mas arquitetura é mais do que isso
A forma do domínio de negócio O que o sistema é. Modelo de Domínio (como no MVC). Com o que o programador se preocupa.
A forma das interações do sistema O que o sistema faz. Modelos de papéis: OORAM (Object Oriented Role
Analysis and Modeling). Com o que o usuário se preocupa.
Análise e Modelagem de Papéis Orientada a Objetos
Precursora da UML
Papel
Casode Uso
Responsabilidade
Análise e Modelagem de Papéis Orientada a Objetos
<?phpnamespace Arquitetura\OORAM;
class Papel{ public function responsabilidade() { }}
De volta a OO: Outras formas na cabeça do usuário final
Usuários pensam mais sobre os papéis manipulados por objetos do que nos objetos.
O que o sistema faz, novamente! Dinheiro transferido de uma conta bancária: os
papéis são a conta de origem e a conta de destino. Os objetos poupança, conta de investimento
podem todos fazer uso desses papéis.
As associações de papéis para objetos, para um dado caso de uso, também é parte do modelo do usuário final.
Ainda mais formas!
E o algoritmo? O algoritmo também tem forma na cabeça do
usuário. Inicia a transação. Debita a conta de origem. Credita a conta de destino. Finaliza a transação.
De volta a OO: Outras formas na cabeça do usuário final
O usuário está mais preocupado com as responsabilidades que são carregadas no sistema.
A orientação a objetos tem servido aos programadores (o processo de descoberta, a arquitetura) mas não aos usuários e clientes – e muito menos à qualidade do software.
Operações de Sistema: Separação de Interesses
Computadores podem: Armazenar e recuperar dados Transformar dados Comunicarem-se!!!
A comunicação torna-se cidadã de primeira classe na computação.
Programação orientada a classes: noodles DCI: Separação de interesses:
Cada tarefa codificada separadamente.
Operações de Sistema: Separação de Interesses
Execução de tarefas em um sistema
Contexto
Operação
Mensagem
Operações de Sistema: Executadas por Contexto
Execução de tarefas em um sistema
<?phpclass Context{
}
Operações de Sistema: Executadas por Contexto
Execução de tarefas em um sistema
public function executarAtividade1(){ $this->outroContexto->executarAtividade2();}
Operações de Sistema: Executadas por Contexto
Execução de tarefas em um sistema
Operações de Sistema: Executadas por Contexto
Execução de tarefas em um sistema
Operações de Sistema: Executadas por Contextos
Um Contexto (uma instância de uma classe de contexto).
Recebe uma mensagem. É responsável por uma operação de sistema. Dispara um método no primeiro papel. A execução continua como especificado nos
métodos do papel.
Essas formas trazem uma nova arquitetura
Papéis repletos de métodos (responsabilidades)
Cla
sses
de
Do m
íni o Casos de Uso
Ident ificad ores e papé is se m
Mé
todos
cc
Essas formas trazem uma nova arquitetura
A proposta de Trygve para uma nova arquitetura é suportar a visão do usuário dos casos de uso e localizar algoritmos em um papel encapsulado.
Essas formas trazem uma nova arquitetura
Uma das formas maioreis dessa arquitetura, chamada forma (ou arquitetura), comportamental) básica, definida apenas em termos de protocolos de papéis. Esses são os papéis sem métodos.
Compromissos.
Contratos.
Responsabilidades.
Essas formas trazem uma nova arquitetura
<?phpinterface Compromisso{public function cumprir();}
<?phpinterface Contrato{public function respeitar();}
<?phpinterface Responsabilidade{public function ter();}
Essas formas trazem uma nova arquitetura
O que Trygve adiciona são os papéis com métodos. Esses papéis podem invocar métodos próprios ou de outro papel.
Papéis com Métodos
Esses papéis são implementados como classes.
Cada papel com métodos é injetado dentro de uma classe cujos objetos manipulam aquele papel em algum momento de seu tempo de vida.
A injeção é um tipo de operação de “colagem”, onde a lógica dos papéis com métodos é adicionada à lógica das classes.
Cada classe se comportará de acordo com os métodos dos papéis que foram “copiados” para dentro dele.
Casos de Uso
Cada cenário de caso de uso é implementado como uma interação de algoritmos entre papéis.
Isso é um tipo de decomposição funcional, pois muitos usuários decompõem tarefas complexas em subtarefas.
Em tempo de execução, associamos um papel sem métodos com um objeto que pode suportar os contratos, compromissos, daquele papel e deixamos o cenário ocorrer.
Composição de Classes
Precisamos compor algoritmos genéricos (pense em trechos de código), de papéis com métodos com as classes cujos objetos manipulam esses papéis.
Estamos falando de colar pedaços de código, e não classes inteiras.
Entramos em um problema que não é resolvido pela mecanismo fundamental de reuso da orientação a objetos, a herança.
Composição de Classes
Um objeto pode ter papéis variáveis de acordo com o contexto em que está operando.
Um objeto pode adquirir responsabilidades em tempo de execução.
Como atribuir poderes para um objeto que não foram definidos previamente?
Como estabelecer a dependência entre objetos em tempo de execução?
Palavras-chave
Herança, Reuso, Lean Archicteture
Dependência, Composição, Contexto
Palavras-chave
Acoplamento
X
Desacoplamento
É hora de conhecer DCI
O que é isso? Um mnemônico para mensagens instantâneas?
“DCI pra gente tomar um café!”
Data Context Interaction
Data
Context
Interaction
Data Context Interaction
InteractionData
Context
Projeto DCI
<?phpnamespace Dci\Context;
abstract class Context{
}
<?phpnamespace Dci\Interaction;
abstract class Interaction{
}
<?phpnamespace Dci\Data;
abstract class Data{
}
Data Context Interaction
Quando estudamos um negócio, também devemos ter esse tipo de preocupação. Separamos a Visão da Estrutura da Visão dos Processos, cientes da maior complexidade e volatilidade da segunda. Costumo dizer em meus treinamentos que a Visão dos Processos ocupará, no mínimo, 70% do tempo de um analista de negócios. Acontece que a aplicação tradicional ou indisciplinada de conceitos OO, em determinado momento, mistura tudo. Através do padrão DCI essa separação é sempre respeitada. Entre a estrutura (Data, o D de DCI) e o-que-o-sistema-FAZ (Interaction), sempre há um Contexto. E um Contexto é uma representação fiel de… um Caso de Uso!
Paulo Vasconcelos, Finito Consultoria
Dados
Contexto
Interação
Como nasceu o DCI?
Podemos considerar a publicação do artigo “The DCI Architecture: A New Vision of Object-Oriented Programming”, de James O'Coplien e … Trygve Reenskaug, em 2009
The Brave and The Bold
Solução para os problemas de composição
Traits Injeção de dependências
Traits
Traits: Composing Classes from Behavioral Building Blocks
Dissertação de Nathanael Scharli. Apresentada na Philosophisch-
naturwissenschaftlichen Fakultat der Universitat Bern em 2005.
Um simples modelo composicional que estende a herança simples.
PHP >= 5.4
trait [nome] {
[bloco de código]
}
class [nome] extends [nome] {
use [nome];
}
namespace Tomarre\Helper;class Url{public function __construct(Request $request){$this->request = $request;}public function setRouter(Router $router){$this->router = $router;}}
Injeção de dependências
c
Injeção de dependências
use Zend\Di\Definition,Zend\Di\Reference;$mongo = new Definition('Mongo');$mongoDB = new Definition('MongoDB');$mongoDB->setParam('conn', new Reference('mongo')) ->setParam('name', 'test');$coll = new Definition('MongoCollection');$coll->setParam('db', new Reference('mongodb')) ->setParam('name', 'resource');$di->setDefinitions(array( 'mongo'=> $mongo, 'mongodb' => $mongoDB, 'resource' => $coll,));$resource = $di->get('resource');
2
Ou seja...
Muita gente fala de MVC, mas poucos o implementam direito. Exemplo disso é a proliferação de modelos magros e controladores gordos.
DCI não substitui MVC, apenas o complementa.
Livre reprodução, desde que citada a fonte. www.fgsl.eti.br @fgsl
Obrigado!
Flávio Gomes da Silva Lisboa
www.fgsl.eti.br
flavio.lisboa@fgsl.eti.br