Fatores que influenciam na longevidade de um Software

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

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).
Adianti Solutions Ltda © Pablo Dall'Oglio Programando para Programadores #2

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
mudanças
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;
– Existem fatores criacionais, e outros evolutivos;
– 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 #4

Qualidade
Projeto ruim → Maior chance de gambiarra na execução!

Software longevo?
● O que afeta a longevidade em Software?
– Aspectos originais (DNA):
● Processo/Metodologia de software escolhidos;
● Análise, projeto, desenvolvimento;
● Boa arquitetura, modelo, 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;
● No início, tentava-se 'imitar' a engenharia tradicional;
● Na Engenharia tradicional, o que é projetado é construído;
● Modelo Waterfall;
● Sucumbiu por que:
– Requisitos mudam a todo instante;
– 'Analistas' ficavam meses produzindo docs;
– Não consideravam limitações da arquitetura;
– Quando prontos já estavam desatualizados;
– Os developers acabavam refazendo do seu jeito.

● Aí vieram os métodos ágeis;
● Dividido em ciclos;
● Cada ciclo entrega uma parte do sw;
● Cada ciclo exerce todas áreas de conhecimento;
● Usa feedback e planejamento constantes.
Joinha, já entendi

● Como alguns entenderam a metodologia?
● '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!
– Vamos direto ao que importa.
● 'Responding to change over following a plan'
– Antecipar problemas para que?
– Não preciso mais daquele Gantt chato!

● Qual problema que isso gera?
– Começa a fazer sem a visão
do todo;
– As entregas são rápidas;
– Mas daria pra fazer melhor...
– O modelo de domínio acaba
ficando confuso;
– O bom design acaba ficando
em segundo plano;
– OO? DDD? Pra quê?
Brasil, o país da
arquitetura de puxadinho.

O negócio
● A visão do negócio vem sempre em primeiro lugar;
● Onde começa o processo?
● Onde termina? quais as fronteiras?
● Qual é o seu negócio, para que você existe?
● Pode envolver gestores, proprietários;
● Ajuda a quebrar o todo em partes para guiar a análise;
● Permite comparar o antes e o depois (AS IS / TO BE);
● Sabemos que:
– É inviável definir os requisitos COMPLETAMENTE antes da
construção;
– Mas é necessário ter a compreensão do negócio.

O negócio
BPMN
Com o uso de WS no processo A,
não precisaremos mais dessa
rotina de envio em lote.

O negócio
● 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);
● Recalcular taxas e emolumentos após cancelamento;
● Solução: Adiar a geração, por que já calcula certo os selos.
– Será que TUDO que o cliente quer é necessário?
● O que a visão de negócio permite?
– Questionar: Por que isso é assim? Por que sempre foi...
– Troca de papeis de usuários (é função dele fazer isso?).
● Ferramentas: Bizagi, Bonita.

O negócio
UML Statemachine
Usados em filtros
de relatório,
bloqueio de
processos, etc.

O negócio
● 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!).

Projeto
● Tenho uma IDE fera, estou pronto?
● 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;
● Só pensam em queries dentro dos frameworks!
● Abrem o Astah e só usam associações!
<?php
$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);

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
Tipos: Concursos funcionários (currículo), Evento/show, Mestrado (comprovantes)...
Atividades: provas (concurso), palestras (evento), entrevista (mestrado)...

Go Horse presentation
<?php
public class MinhaAplicacaoWebEmCodeMacaroni {
public function process($request)
{
$pagina = $request["pagina"];
if ($pagina == null) {
$pagina = "inicial";
}
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

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
Contexto
$sr = new TSimpleReport;
$sr->setReportWritter($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
require_once 'app.reports/TChart.class.php';
require_once 'app.reports/TBarChart.class.php';
require_once 'app.reports/TPieChart.class.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
require_once 'app.reports/TChart.class.php';
require_once 'app.reports/TBarChart.class.php';
require_once 'app.reports/TPieChart.class.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!

Fatores que influenciam na longevidade de um Software

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Fatores que influenciam na longevidade de um Software

Similar a Fatores que influenciam na longevidade de um Software (20)

Fatores que influenciam na longevidade de um Software