Design for change: Fatores que influenciam na longevidade de um Software PHP

Design for Change: Fatores que influenciam
na longevidade de um Software
Pablo Dall'Oglio
@pablodalloglio fb/pablodalloglio

Roteiro
● Metodologia;
● Visão;
● BPMN;
● UML;
● DDD;
● Acoplamento;
● Design Patterns.
Adianti Solutions Ltda © Pablo Dall'Oglio Programando para Programadores #2

Meu caminho
● Clipper (1994-1998): comercial, bibliotecas, funções;
● Delphi (1998-1999): automação, componentes;
● PHP (2000): SAGU (php+html+sql);
● PHP-GTK(2001): PHP só com classes;
● Agata Report (2001-2006);
● Gnuteca (2002): PHP Web com classes;
● PHP-GTK: Criando Aplicações Gráficas com PHP (2004);
● Design Patterns (2004): Unisinos;
● Core (2006): Primeira experiência com Framework MVC;
● PHP: Programando com Orientação a Objetos (2007);
● Mestrado em Engenharia de Software (2008, 2009);
● Criando Relatórios com PHP (2011);
● Adianti Framework para PHP (2012).

Software longevo?
● Longevidade tem a ver com resistência, resiliência!
● Software precisa ser longevo?
– Enquanto alguns dirão:
● O novo sempre é melhor;
● Novas tecnologias, pensamentos...
Absorver
energia
sem deformar
● Faça de qualquer jeito, pois logo vai mudar tudo...
– Outros dirão:
● Fazer frequentemente tudo do zero é caro;
● Quanto mais tempo durar, maior o ROI;
● Faça bem feito, para dar menos incomodação.

Qualidade
● O que é ter qualidade?
– Um software feioso mas que atende bem o cliente...
– É um software de qualidade? E o contrário?
● Qualidade envolve:
– Questões funcionais (orientadas pelo negócio);
– Questões não-funcionais (arquitetura, padrões);
● Tá, mas e daí? O que eu tenho a ver com isso?
– O software é reflexo do processo, do negócio;
– Negócio em 2o plano + sofrimento → com mudanças;
– Um modelo bom é mais resiliente e consegue absorver
a energia das modificações sem se romper;
Adianti Solutions Ltda © Pablo Dall'Oglio Fatores que influenciam na longevidade de um Software #5

Qualidade
Projeto mal concebido mudanças mal executadas → → Resultado ruim.

Longevidade
● O que afeta a longevidade em Software?
– Aspectos originais (DNA):
● Processo/Metodologia de software escolhidos;
● Artefatos de análise, projeto, desenvolvimento;
● Boa arquitetura, modelo, design patterns;
– Aspectos evolutivos (crescimento):
● Novas features bem projetadas, refactoring;
● Evoluir com segurança (unit tests).
Vou focar
aqui

Design for change
" The goal for most software developers still
remains to design for change...
The debate is do you do it early (given
foreknowledge) or later (once more is known
and you know you need it)?
In many cases the design should be
Previsão
refactored, and the patterns provide a target
to do this "
Richard Helm - Gang of Four

Processo de software
● A escolha do Processo de software muda tudo;
● Ex: Modelo Waterfall. Acredite, ele ainda é bastante usado!
● O modelo sequencial tenta 'imitar' a engenharia tradicional;
● BDUF: Pensar em tudo com detalhes no início.
● Sucumbiu por que:
– Meses para produzir docs;
– Interação muito tardia para validar;
– Não consideravam a arquitetura;
– Requisitos mudam a todo instante;
– Quando prontos não refletiam a realidade;
– Os developers acabavam refazendo do seu jeito.

● Aí vieram os métodos ágeis. Ciclos;
● Cada ciclo entrega uma parte do sw;
● Cada ciclo exerce todas áreas de conhecimento;
● Feedback e planejamento constantes.
● Como alguns entenderam a metodologia?
Joinha, já entendi
● 'Working software over comprehensive documentation'
– Ahhh, não preciso mais documentar NADA;
– Modelar pra quê? Discutir requisitos pra quê?
– Oba, vamos direto ao código e terminar isso logo!
– Se o software funcionar, é a conta.
– Deixamos de perder tempo projetando!

● Qual problema que isso gera?
– Começa sem a visão do todo;
– As entregas são rápidas;
– Mas daria pra fazer melhor...
– O modelo fica confuso;
– O bom design acaba ficando
em segundo plano;
– O Software fica orientado a
puxadinho;
– Ninguém tem orgulho daquilo;
– OO? DDD? Pra quê?
– E a excelência técnica?

Mapear o negócio
● Desenvolver sem compreender o negócio é como vendar os olhos;
● Onde começa o processo? Onde termina? quais as fronteiras?
● Qual é o seu negócio? para que você existe? Quais os inputs?
● Por que é importante?
– Sugere processos desnecessários (sempre foi desse jeito);
● Nosso trabalho é gerar o relatório para eles;
● Nosso trabalho é olhar o relatório enviado por eles.
– Visualizar processos redundantes (momento errado);
● Entra título → gera taxas, selos → cancelamento (recálculo);
● Solução: Adiar a geração de taxas, já calcula o valor certo.
– Será que TUDO que o cliente quer é necessário?
– Ferramentas: Bizagi, Bonita.

Mapear o negócio
BPMN
Isso não
deveria ser feito
por fulano
Essa
Integração manual
agora vai
via WS
Isso deve ser
feito só no
final
Isso agora vai
ser automático
na CRON Esse recibo
agora vai por e-mail
Isso já é feito
pelo outro operador

A análise
UML Statemachine
Usados em filtros
De tela
Usado em transições
de processos

A análise
● Por que é importante?
● Focar em um objeto;
– Qual o ciclo de vida de um aluno?
● Definir seus estados;
Quais as
transições
Válidas?
– Cancelado é um estado de um título? E estornado?
● Agrupar sinônimos:
– Liquidado e Pago são a mesma coisa?
● Criar um vocabulário:
– Minimiza problemas de comunicação futuros.
● Quando surgir uma manutenção...
– Ahhh, vamos criar só mais uma flag (várias flags!).

O projeto
● Baixei aquela IDE fera, com aquele plugin destruidor;
● Vou usar a arquitetura MXMVPC, ouvi falar que é da hora;
● Baixei aquele 'frame' que todos estão usando, estou pronto?
● É preciso apropriar-se da filosofia;
● Isso é do M,V ou C? Entender bem onde se encaixa cada coisa;
● A equipe deve saber em que classe colocar cada método;
● E que nome dar às coisas;
● E saber bem OO!
O brasileiro vai mundo na onda.

Go horse model
● Para muitos, projeto = ER;
● Para eles, projetar é pensar em tabelas;
● Começam o projeto com o ER;
● Abrem o Astah e só usam associações!
● Só pensam em queries dentro dos frameworks!
$connect = mysql_connect("localhost","root", "root");
if (!$connect) {
die(mysql_error());
}
mysql_select_db("apploymentdevs");
$results = mysql_query("SELECT id, name FROM person
WHERE category_id='{$cat_id}' AND
Gender = 'F'");
while($row = mysql_fetch_array($results)) {
echo $row['Name'] . "</br>";
}
$results = mysql_query("SELECT id, name FROM
Customer WHERE city_id = {$market_city}");

DDD
● Domain Driven Development;

DDD
● UML não é ER!
● São relações entre objetos, não entre tabelas;
● Pensar primeiro nas entidades e relações;
● É um modelo com maior semântica (é um tipo de...);
● Abstrair o Banco de Dados, que pode ser derivado;
● No lugar de Primary key e Foreign Key, pensar em:
– Herança;
– Associação;
– Composição (relação todo parte exclusiva);
– Agregação (relação todo parte não exclusiva);
Programadores tem
dificuldades em
usar relações
TODO/PARTE

A partir do modelo...
<?php
/**
* Customer Active Record
* @author <your-name-here>
*/
class Customer extends TRecord
{
public function get_city()
public function addSkill(Skill $skill)
public function getSkills()
public function load($id)
public function store()
public function delete($id = NULL)
} ?>
XMI
SQL
PHP
Não usamos mais
DB design tools

Navegação no código
● Relações tornam-se navegáveis;
● A query é realizada de maneira transparente.
<?php
// load customer
$obj = new Customer(5);
print $obj->city->name;
print $obj->category->name;
Lazy load:
Acelerado com
cache de objetos
// percorre contatos
foreach ($obj->getContacts() as $contact)
{
$contact->value = '9'.$contact->value;
$contact->store();
print $contact->type . '-' . $contact->value;
}
foreach ($obj->getSkills() as $skill)
{
print $skill->name;
}
Navegabilidade:
tem de ser tão fácil
quanto ler.

Modelos mal definidos
● Um modelo mal definido leva à problemas;
● Novos recursos são necessários;
● O modelo atual se mostra frágil;
● A solução é criar tabelas e mais tabelas;
● Arquitetura de puxadinho;
● One table per ticket.

Metamodelos
Inscrições
Ex: Concursos funcionários/provas; Eventos/palestras, Mestrado/entrevistas.
Vagas por processo/atividade, tipo de seleção: múltipla/exclusiva.

Metamodelos
● Relações tornam-se navegáveis;
● A query é realizada de maneira transparente;
● A preocupação é com o negócio.
<?php
$pi = new ProcessoInscricao(100);
$ai1 = new Atividade(201);
$ai2 = new Atividade(202);
$cp1 = new CampoProcesso( 301 );
$ip = new InscricaoProcesso;
$ip->setProcessoInscricao( $pi );
$ip->addInscricao( date('Y-m-d'), $ai1 );
$ip->addInscricao( date('Y-m-d'), $ai2 );
$ip->addValorCampo( $cp1, 'Graduação');
$ip->store();
?>
Permitiu utilização
em situações
não previstas

Go Horse presentation
<?php
public class MinhaAplicacaoWebEmCodeMacaroni {
public function process($request)
{
$pagina = $request["pagina"];
if ($pagina == null) {
$pagina = "inicial";
Quem nunca
precisou refatorar
isso?
}
if ($pagina == "inicial") {
print("<html>");
print("<li><a href="?pagina=inicial">Pagina Inicial</a></li>");
print("<h2>Pagina Inicial</h2>");
print("<p>Bem-vindo ao nosso Site!</p>");
print("</html>");
}
}
}
$page = new MinhaAplicacaoWebEmCodeMacaroni;
$page->process($_GET);
?>

Componentes
Componentes e templates
$this->datagrid = new TDataGrid;
$code = new TDataGridColumn('code', ...);
$name = new TDataGridColumn('name', ...);
$this->datagrid->addColumn($code);
$this->datagrid->addColumn($name);
$act1 = new TDataGridAction(array($this, 'onView'));
$act1->setLabel('View name');
$act1->setImage('bs:search blue');
$act1->setField('name');
$act_group = new TDataGridActionGroup('Actions', 'bs:th');
$act_group->addHeader('Available Options');
$act_group->addAction($act1);
$act_group->addAction($act2);
$this->datagrid->addActionGroup($act_group);
Abstrair a tecnologia
Solução em alto nível

Evolução
● Frequentemente usamos bibliotecas prontas;
● As bibliotecas evoluem constantemente;
● Novas tecnologias surgem;
● Nosso código não deve referenciar a biblioteca utilizada;
● Devemos separar nosso código do código de terceiros;
● Isso tudo, para facilitar o reuso e a evolução.

Desenvolvimento
● Muitos desenvolvedores integram bibliotecas assim:
Alto acoplamento: Até pode funcionar, mas...

Acoplamento
● É quanto um módulo (classe, método)
conhece e depende de outro;
● Baixo:
– Não depende de muitas outras;
– Menos efeitos colaterais em
modificações.
● Alto:
– Menos reutilizável sozinha;
– Mais sensível à mudanças.
● O objetivo é criar modelos com baixo
acoplamento;
● É impossível acoplamento ZERO;

Evolução
evoluir
"... the hardest is evolving reusable object-oriented
software
We touch on this a little bit in Design Patterns.
For example, factories, adapters and facades
can help when it comes to changing and
evolving a reusable library"
Erich Gamma - Gang of Four

Acoplamento
● Facade ajuda a diminuir o acoplamento;
● Oferece uma interface única para um conjunto de
interfaces de um subsistema;
● O sistema cliente ficará dependente da Facade, não do
subsistema.

Facade
<?php
if ($paymenttype_id == 1) // PAGSEGURO
{
$paymentRequest = new PagSeguroPaymentRequest();
$item = new PagSeguroItem;
$item->setDescription( $product->description );
$item->setQuantity( $data->amount );
$item->setAmount( $price );
$paymentRequest->addItem($item);
$address = new PagSeguroAddress;
$address->setPostalCode( $customer->postal );
$address->setStreet( $customer->address );
$address->setCity( $customer->city );
$paymentRequest->setShippingAddress($address);
$sender = new PagSeguroSender;
$sender->setName( $customer->name );
$sender->setEmail( $customer->email );
$paymentRequest->setSender($sender);
}

Facade
<?php
else if ($paymenttype_id == 2) // PAYPAL
{
$total = ($product->price * $data->amount);
// dados para enviar para o paypal
$padata ='&CURRENCYCODE='.urlencode($ini['currency']).
'&PAYMENTACTION=Sale'.
'&ALLOWNOTE=1'.
'&PAYMENTREQUEST_0_AMT='.$total.
'&PAYMENTREQUEST_0_ITEMAMT='.$total.
'&L_PAYMENTREQUEST_0_QTY0='. $data->amount.
'&L_PAYMENTREQUEST_0_AMT0='.$product->price.
'&L_PAYMENTREQUEST_0_NAME0='.$product->description.
'&L_PAYMENTREQUEST_0_NUMBER0='.1.
'&AMT='.$total;
// obtém o token
$paypal= new PayPalFacade;
$httpresult = $paypal->PPHttpPost('SetExpressCheckout', $padata,
$ini['username'], $ini['password']);
} ?>

Facade
<?php
class PaymentFacade
{
public function addItem($desc, $qtde, $preco)
{
//...
}
public function setCustomer($nome, $ender, $cidade)
{
//...
}
public function setPaymentType($type)
{
//...
}
public function process()
{
//...
}
} ?>
Pode ser resolvido
com outros
padrões também

Wrapper
● Converte a interface de uma classe e outra esperada;
– Object Wrapper: Encapsula adaptado por composição;
– Class Wrapper: Adapta interface por herança.
class TPDFDesigner extends FPDF implements PDFDesignInterface
{
public function fromXml($filename)
public function gotoAnchorXY($anchor_name)
public function writeAtAnchor($anchor_name, $text)
public function replace($mark, $text)
public function writeHTML( $x, $y, $html )
public function setFontColorRGB($color)
public function generate()
public function save($output)
}
Evite modificar a
classe original.
Contrato

Singleton
● Disponibilizar um recurso, independente do contexto:
– Model agnóstica em relação à conexão;
– Separação de contexto, independente do nível.
class CustomerStatusForm extends TPage // controller
{
public function onListIncosistenciasPgto($param) {
TTransaction::open('erp');
$inconsistencias = ContaReceber::getInconsistencias($id);
TTransaction::close();
}
}
class ContaReceber extends TRecord // model
{
public function getInconsistencias($id) {
$conn = TTransaction::get();
$conn->query('SELECT ...');
}
Reaproveitar
a model em
diferentes contextos
}
Obtém a conexão
ativa

Injeção dependência
● Escritor de relatórios definido pela classe da esquerda;
contexto implementação
O que não muda

Injeção dependência
<?php
require_once 'app.reports/ITableWriter.php';
// ...
Implementação
$widths = array(70, 150, 150, 100);
$tr = new TTableWriterPDF($widths);
// cria os estilos
$tr->addStyle('title', 'Arial', '12', 'B', '#ffffff', '#733131');
// atribui o escritor ao relatório
Injeção
$sr = new TSimpleReport;
$sr->setReportWriter($tr);
// adiciona as colunas do relatório
$sr->addColumn('id', 'Código', 'center');
$sr->addColumn('nome', 'Nome', 'left');
// define o banco de dados e a consulta
$sr->setDatabase('exemplos');
$sr->setQuery('SELECT id, nome, telefone, endereco from ...');
$sr->generate(); // gera o relatório
$sr->save('saida4.pdf');
?>

Bridge
● Separa uma abstração de sua implementação;
● As duas podem variar de maneira independente;
● Usa encapsulamento, agregação e herança para separar
responsabilidades.

Jeito tosco
● Proliferação de níveis. Estrutura não-flexível;
● Alto grau de acoplamento. O cliente especifica a classe;
● Quantas novas classes para novo tipo de gráfico (gauge)?
Implementação
filha da
abstração abstração
implementação

Usando bridge
● Esquerda: Abstração;
● Direita: Implementação;
● O programa define a implementação a ser usada.
abstração
implementação

Bridge
<?php
$data['maria'] = array( 1, 2, 3, 4, 5, 6, 7);
$data['pedro'] = array(12, 3, 12, 4, 12, 4, 2);
$data['joao'] = array( 9, 8, 7, 6, 5, 4, 3);
$chart = new TBarChart(new TPChartDesigner);
$chart->setTitle('Título do gráfico', NULL, NULL);
$chart->setSize(500, 300);
$chart->setXLabels(array('a', 'b', 'c', 'd', 'e', 'f', 'g'));
$chart->setYLabel('label do eixo Y');
$chart->setOutputPath('tmp/teste.png');
$chart->addData('maria', $data['maria']);
$chart->addData('pedro', $data['pedro']);
$chart->addData('joao', $data['joao']);
$chart->generate();
?>
chartDesigner->drawBarChart()

Bridge
<?php
// cria um gráfico de pizza usando a JPGraph
$chart = new TPieChart(new TJPGraphDesigner);
$chart->setTitle('Título do gráfico', NULL, NULL);
$chart->setSize(500, 300);
$chart->setOutputPath('tmp/teste2.png');
$chart->addData('maria', 40);
$chart->addData('pedro', 30);
$chart->addData('joao', 30);
$chart->generate();
?>
Com isso,
Conseguimos
evoluir melhor
chartDesigner->drawPieChart()

Obrigado
● Adianti Framework:
– www.adianti.com.br/framework
● Contato:
– www.dalloglio.net
– www.adianti.com.br
– @pablodalloglio
– @adiantisolution
● Não esquecer de falar do Sorteio!

Design for change: Fatores que influenciam na longevidade de um Software PHP

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (17)

Similar a Design for change: Fatores que influenciam na longevidade de um Software PHP

Similar a Design for change: Fatores que influenciam na longevidade de um Software PHP (20)

Design for change: Fatores que influenciam na longevidade de um Software PHP