Design Patterns

1
Design Patterns MDSoCCasos de uso em software
ITS

• Tiago Delgado Dias Software Architect Tiago.Dias
  _at_brisa.pt

2
Agenda

• Design Patterns o que são?
• Identificação e apresentação de padrões usados na
  plataforma iBrisa
• Para além dos padrões
• Multi-Dimensional Separation of Concerns
• MDSoC com partial types (.NET 2.0)
• Hyper/Net, MDSoC para além das classes

3
Design Patterns

• Soluções para problemas típicos
• Abordagem com origem na Arquitectura (Christopher
  Alexander'77)
• Aplicação à programação em 1987 por Kent Beck
  (Extreme Programming, Agile) e Ward Cunningham
  (Wiki) apresentada na OOPSLA'87
• Popularização em 1994 com o livro do Gang-of-Four
  (Erich Gamma, Richard Helm, Ralph Johnson e John
  Vlissides)
• São assim padrões catalogados e com sugestões de
  aplicação em linguagens correntes (Java, C,
  etc.), tipicamente OO
• São um recurso utilizado na fase de desenho
• Principais factores a favor
• Ampla utilização,
• presença (através de templates) nas frameworks
  (Java, .NET),
• garantias empíricas

4
iBrisa Padrões Componente

• Se considerado como um padrão (B. Appleton,
  Component Design Patterns) será o padrão mais
  utilizado no software contemporâneo
• Promove a modularização através da oferta de
  funcionalidades a camadas de mais alto nível (ou
  ao utilizador final)
• Utilizado no iBrisa a nível de arquitectura
• Separação em camadas, tipicamente
• Dados
• Serviços
• Interface
• através da utilização de bibliotecas e frameworks

5
(No Transcript)
6
iBrisa Padrões Provider/Adapter

• Um adaptador funciona como mediador entre
  interfaces distintas
• É o mecanismo chave para a independência de
  fornecedores de equipamentos/serviços no Traffic
  Atlas
• É devido a este padrão que é possível
• com a mesma interface gerir a video-wall do CCO e
  a componente da concessão Brisa nas Estradas de
  Portugal
• notificar a ocorrência de uma incidência via
  email, SMS ou de um serviço Datex
• Por se ter aplicado este padrão seria possível
• Trocar por completo a solução de call-center
  usada no CCO e não alterar a componente de gestão
  de canais de comunicações
• Introduzir equipamentos (CCTVs, PMVs, EMs) de
  novos fornecedores na rede sendo geridos através
  do Traffic Atlas

Adaptador 1
Fornecedor de serviço 1
Consumidor de serviço
Consumidor de serviço
Fornecedor de serviço N
Adaptador N
7
iBrisa Padrões Observer e Hook

• Ambos os padrões definem um ponto de registo para
  acções a tomar caso se verifiquem determinadas
  condições
• No caso do Hook as acções que tratam o evento vão
  definir em conjunto uma resposta para a origem do
  evento (por exemplo validar um conjunto de
  condições necessárias para a efectivação do
  evento)
• O padrão do Observador é utilizado no Traffic
  Atlas
• através do mecanismo de eventos do .NET
• em situações em que é necessário efectuar acções
  não operacionais para uma dada situação (ex.
  sincronizar o estado de um equipamento, registar
  uma operação efectuada ou registar um alarme)
• quando existe mais do que uma acção para o evento
  separa o código de cada acção, nos casos
  restantes separa o código operacional de
  funcionalidades transversais, como o registo de
  ocorrências (logging)
• São utilizados Hooks no Traffic Atlas
• através da implementação de uma classe específica
• para o tratamento de alterações do estado da
  sessão dos utilizadores (valida-se se um operador
  pode abandonar o seu posto sem deixar zonas por
  operar, etc.)

8
Padrões e limitações

• Objectivos comuns aos padrões apresentados
• Modularização
• Separação de conceitos
• Contudo estes objectivos não são antingidos na
  totalidade
• A estrutura de componentes nem sempre permite a
  separação desejada
• Pode não ser possível ter uma visão unificada de
  todo código envolvido numa dada funcionalidade
  (ex. controlo de portagens), quando existem
  requisitos de alteração de funcionalidade esta
  possibilidade é desejável
• Por vezes não é possível testar uma
  funcionalidade ou um conjunto de funcionalidades
  de forma isolada
• O código que lança os eventos ou hooks
  encontra-se disperso pelo código operacional
• Por exemplo para acrescentar a alteração do
  estado de um SOS como fonte de um evento de acção
  (usado para registar acções em BD e para alterar
  o estado dos equipamentos) é necessário alterar o
  projecto de serviços de SOS
• É contudo possível adicionar um novo tratamento
  do evento de acções sem ser necessária qualquer
  alteração aos módulos que despoletam o evento

9
Para além dos padrões

• Aspect oriented software
• Separação de funcionalidades cross-cutting
• Extensão às linguagens orientadas aos objectos
  (OO)
• As soluções de AOP mais conhecidas são baseadas
  no AspectJ, de Gregor Kiczales, 1997
• Multi-Dimensional Separation of Concerns (MDSoC)
• Abordagem AOP desenvolvida desde 1999 por Peri
  Tarr e Harold Ossher, com uma implementação
  Hyper/J
• Promove uma separação equilibrada e equalitária
  das estruturas de classes num hiper-espaço
  populado por funcionalidades/requisitos
• O programador manipula o software a este nível
  dentro do hiper-espaço, uma classe pode existir
  em várias funcionalidades distintas e ser vista
  parcialmente em cada uma
• Tal como outras abordagens AOP para além da
  separação tem uma fase de composição em que o
  hiper-espaço é condensado numa implementação OO
  clássica

10
MDSoC Aplicação a ITS

• Inicialmente utilizaram-se os partial types do
  .NET 2.0 para uma primeira experiência de MDSoC
  na área de ITS
• Classe Portagem com 2 funcionalidades Cobrança e
  Contagem

11
MDSoC Aplicação a ITS (2)

• Alguns métodos continuavam a combinar
  funcionalidades distintas
• public int ChargeToll(Toll originToll)
• int amountToCharge this.AmountFromOtherToll(orig
  inToll)
• amountCharged amountToCharge
• // This region shouldn't be aware of this traffic
  management variable
• numVehiclesPassedThisHour
• return amountToCharge

12
Hyper/Net

• Desenvolveu-se um protótipo para .NET que permite
  acomposição de métodos entre tipos parciais
  Hyper/Net
• Baseado no Hyper/J, oferece os métodos de
  composição
• Override, Merge, Bracket
• Utiliza os partial types para a composição de
  classes
• Utiliza um conjunto de atributos para definir os
  métodos de composição e as suas propriedades
• ex. a política de composição de retornos dos
  métodos compostos
• Utilizando o Hyper/Net já foi possível separar
  totalmente as 2 funcionalidades
• Na classe da funcionalidade de contagem
  acrescentou-se
• HyperNet.MethodMerge(HyperNet.MethodMergeAction.M
  erge, -3, ChargeTollMerge)
• public int ChargeToll(Toll originToll)
• numVehiclesPassedThisHour
• return 0

13
Hyper/Net (2)

• Uma terceira funcionalidade, de congestion
  charging, foi adicionada sem quaisquer alterações
  às 2 funcionalidades existentes
• Vantagens
• É possível ter uma separação total baseada numa
  estrutura de funcionalidades
• É possível remover (1 click) e adicionar
  funcionalidades (alguns clicks ) ) sem
  alterações ao código existente
• Podem-se continuar a aplicar padrões existentes
• Finalmente é possível mapear requisitos
  directamente no código