Aula 4 - 18/8/6

Padrões de Análise: Reuso de Modelos

• Analysis Patterns - Reusable Object Models
• de Martin Fowler
  

• Bons desenvolvedores refletem muito sobre a arquitetura OO do sistemas que desenvolvem.
• Padrões de projeto e padrões arquiteturais descrevem soluções arquiteturais para a implementação de sistemas em termos das classes e objetos que compõem uma solução e do relacionamento entre eles.
• Excelentes desenvolvedores, antes de pensar na arquitetura OO de um sistema refletem e trabalham na criação de um modelo conceitual para explicar a situação ou processo que se quer representar no sistema computacional.
• Um modelo conceitual é uma idéia mental que fazemos de um processo ou de um problema a ser resolvido.
• Exemplo: construção de um programa para simular um jogo de sinuca
• poderíamos especificar o sistema escrevendo casos de uso;
• poderíamos filmar centenas de jogadas e tentar emular o resultado no computador;
• mas isso não seria suficiente para escrever uma boa simulação
• para escrever uma boa simulação precisamos entender o que está se passando por trás daquilo que estamos observando;
• precisamos de um modelo conceitual para explicar as leis do movimento que relacionam massa, força, velocidade, etc.
• podemos usar um modelo newtoniano da física clássica
• ou um modelo einsteiniano baseado na física moderna
• provavelmente o modelo clássico seria mais apropriado pois é mais simples embora menos exato
• um fanático por re-utilização poderia argumentar que o modelo da física moderna seria mais apropriado pois o código poderia ser reutilizado em uma programa para simular colisões entre átomos...
• acrescentar flexibilidade demais a um sistema é um caminho perigoso pois pode levar a um excesso de complexidade.
• Portanto: escolha o modelo mais simples que atenda às suas necessidades.
• Princípio de Modelagem: Modelos não são certos ou errados; eles são mais ou menos apropriados .
• Modelos simples, em geral, não são os primeiros a passar pela nossa cabeça. Vale a pena investirmos tempo para simplificar nossos modelos.

• Como expressar um modelo conceitual?
• linguagem de programação -> modelo pode se tornar muito dependente da linguagem
• diagramas, texto explicativo
• mas, não esquecer que o modelo conceitual é a idéia que fazemos em nossa cabeça do problema em questão.
• algo excelente a se fazer é envolver os especialistas no domínio no processo de modelagem (médicos, bibliotecários, estudantes, trabalhadores de escritório, etc.)
  

• Ao desenvolver um modelo, não se esqueça que um bom modelo conceitual se relaciona diretamente às interfaces dos elementos do modelo (e não às suas implementações).
• Princípio de Modelagem: Modelos conceituais são diretamente relacionados a interfaces (tipos) e não a implementações (classes).

• O livro de padrões de análise surgiu da experiência do autor como consultor de modelagem de sistemas durante mais de dez anos para empresas públicas e privadas nas áreas de saúde, finanças e administração.
• Tipos de padrões de análise presentes no livro:
• Contabilização/ Responsabilização
• Observações e Medidas
• Observações para Finanças de Empresas
• Referências a Objetos
(nome, id, equivalência, etc.)
• Inventário e Contabilidade
• Planejamento
• Negociação
• Contratos de Derivativos

Padrões relativos a Observações e Medidas

• Muitos sistemas armazenam informações sobre objetos do mundo real.
• Estas informações acabam nos sistemas como registros, atributos, objetos, etc.
• Por exemplo, o fato de que eu peso 72Kg pode ser armazenado em um atributo de um objeto do tipo pessoa.
• O capítulo 3 do livro examina os casos em que essa abordagem não funciona e propõe uma modelagem alternativa.
  

Quantidade

• A forma mais simples e comum de representar um valor medido do mundo real é através de um atributo:

• Pessoa

  altura: Número peso: Número nível de colesterol no sangue: Número

• problema: utilizar um Número é impreciso; o que significa uma altura 183 ou 6? Precisamos de unidade.
• possível solução: colocar a unidade no nome do atributo, p.ex., peso_em_kg.
• o que fazer se um paciente, quando perguntado sobre seu peso, diz que ele pesa 250 libras?
• em alguns casos, a melhor solução seria converter libras para kg; mas, neste caso, o sistema não estaria guardando a informação sobre o que foi observado mas sim uma adaptação. Em medicina, é importante guardar o que foi observado.
• exemplo mais convincente:
• pergunta: quanto dinheiro você tem na carteira?
• resposta1: 30 reais
• resposta2: 10 dólares
• obs.: mesmo que a taxa de conversão seja 1:3, as respostas não são equivalentes!
• Precisamos então de um conceito de Quantidade

• Pessoa

  altura: Quantidade peso: Quantidade nível de colesterol no sangue: Quantidade

  Quantidade

  valor: Número unidade: Unidade +, -, *, /, =, >, <

• valores monetários também devem ser representados com unidades (moeda)
• no mundo globalizado é cada vez mais comum termos que lidar com múltiplas moedas
• será que os sistemas bancários brasileiros passaram a usar uma modelagem assim depois de tantas mudanças de moeda no Brasil?
• Princípio de Modelagem: Quando vários atributos interagem com comportamento que pode ser utilizado em vários tipos, combine os atributos em um novo tipo fundamental.
  

Taxa de Conversão

• Uma boa conseqüência de representar unidades explicitamente, é a facilidade de conversão entre unidades.
• Objetos de conversão podem ser associados a unidades e as quantidades podem implementar uma operação convertTo (unit)
• Figura 3.3
  
• Em muitos casos, um objeto de conversão pode guardar apenas um número (a taxa/razão de conversão).
• Em outros casos, isso não é suficiente, p.ex., conversão de Fahrenheit para Celsius.
• Esteja ciente de que conversão de tempo pode ser problemática (p.ex., conversão de meses para dias não é constante).
• Para valores monetários, as taxas de conversão variam ao longo do tempo.
• Se as taxas variam muito, o Fowler usa cenários (padrão descrito no capítulo 9); caso contrário, ele prefere o modelo mais simples descrito aqui.

Unidades Compostas

• Unidades podem ser atômicas ou compostas (metros por segundo ²)
• Uma operação de conversão sofisticada pode utilizar as razões de conversão das unidades atômicas para converter entre unidades compostas.
• Para isso, a unidade composta deve ser ciente da sua composição (quais unidades atômicas são usadas e quais as potências usadas).
• Modelo: Figura  3.4.
• Isso permite automatizarmos a conversão de m/s para Km/h ou de acres e hectares para Km², etc.

• Uma variação para simplificar o modelo é usar sacos (bags), que são "conjuntos com multiplicidade"
• Modelo mais compacto: Figura 3.5
• Exemplo: a aceleração da gravidade pode ser expressa como uma quantidade com número 9.81 e unidade composta com unidade direta metro e unidades inversas segundo e segundo.
  

Medida

• Modelar as quantidades medidas de uma pessoa como atributos da pessoa pode ser razoável para um departamento de um hospital que faz algumas medidas básicas cada vez que um paciente dá entrada (p.ex., altura, peso, pressão arterial).
• Mas, se incluirmos todos os departamentos do hospital e todos os possíveis médicos que o paciente pode visitar, i.e., toda a medicina, teríamos então dezenas ou centenas de medidas associadas a cada paciente. Não faria sentido ter um atributo para cada medida.

• Uma primeira solução é considerar todos os tipos de coisas que podem ser medidas como objetos do tipo fenômeno.
• Figura 3.6

• Neste modelo, medidas são acrescentadas normalmente como parte da atividade diária do sistema.
• Novos tipos de fenômenos também podem ser acrescentados facilmente, mas em geral, não são criados tão freqüentemente.
• Isso divide o modelo em duas partes: 
1. o nível do conhecimento (no topo da figura)
2. e o nível operacional (na parte inferior da figura)

• Princípio de Modelagem: O nível operacional inclui os conceitos que mudam diariamente (freqüentemente) no sistema. A sua configuração é restringida pelo nível do conhecimento que muda muito menos freqüentemente.
• Princípio de Modelagem: Se um tipo possui muitas associações similares (p.ex., pessoa tem vários atributos do tipo Quantidade), transforme todas estas associações em objetos de um novo tipo. Crie um tipo no nível do conhecimento para diferenciar entre eles.
  

• Outro exemplo deste princípio: 
• um modelo para representar os relacionamentos sociais de um indivíduo poderia utilizar um atributo para cada tipo de relacionamento (pai, mãe, irmão, namorado, cônjuge, amigo, inimigo, ídolo, fã, colega de trabalho, professor, aluno, etc.).
• um modelo mais elegante, utilizaria um tipo no nível do conhecimento para descrever os diversos tipos de relacionamento.
  

Observação

• Além dessas quantidades medidas associadas aos pacientes, podemos ter também informações qualitativas associadas aos pacientes
• exemplos: sexo, tipo sangüíneo, se a pessoa é diabética ou não, etc.
• Solução: modelo com um tipo observação e sub-tipos medida e observação de categoria.
• Figura 3.7
• Nesta figura, por exemplo, gênero seria um Tipo de Fenômeno e masculino e feminino seriam instâncias de Categoria.
  

• Exemplo: um paciente se queixa ao médico que ele tem muita sede, perda de peso e urina com muita freqüência. O médico o diagnostica com diabetes. O médico não pode simplesmente registrar a observação de diabetes. Ele registra a observação da queixa e registra que essa observação leva à observação da diabetes.
• Isso é representado com uma associação recursiva no registro da observação para representar as evidências e os desdobramentos de cada observação.
• Figura 3.8

• Agora, note que Categoria pode ser mais útil se movida para o nível do conhecimento.
  
• O tipo sangüíneo de um paciente é A
• Devemos representar isso como um valor "A" na categoria tipo sangüíneo (como feito na Fig. 3.8) ou devemos representar isso como um valor "tipo sangüíneo A" numa observação de categoria? 
• A última possibilidade nos permite associar comportamento e regras à observação: colocar afirmações qualitativas (p.ex., "tipo sangüíneo A") no nível do conhecimento, permite que elas sejam utilizadas em regras deste nível.
  
• Figura 3.9 (onde Categoria é movida para o nível do conhecimento e renomeada para Fenômeno.
• Fenômeno define os valores possíveis para um tipo de fenômeno (p.ex., cada um dos 3 tipos de Hepatite).
  
• Em certos casos, a ausência de uma observação também pode ser uma informação relevante. A Figura 3.10 permite modelar presença e ausência.
  

Referências

• Martin Fowler. Analysis Patterns - Reusable Object Models. Addison-Wesley. 1997.
• Sítio de Padrões de Análise do Fowler com vários exemplos
• Diagramas UML correspondentes às figuras apresentadas aqui.