1 Design Patterns & MDSoC Casos de uso em software ITS Tiago Delgado DiasSoftware

Apresentação em tema: "1 Design Patterns & MDSoC Casos de uso em software ITS Tiago Delgado DiasSoftware"— Transcrição da apresentação:

1 1 Design Patterns & MDSoC Casos de uso em software ITS Tiago Delgado DiasSoftware ArchitectTiago.Dias@brisa.pt

2 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 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 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 5 iBrisa – Padrões: Componente (2) através da utilização de Web Controls, ex.: - Controlo de autenticação - Localização de elementos - Listagem de PMVs Toll.Services Traffic Tolls.CAD Tolls.Sinoptic Atlas.Video Video.Services Atlas.Logging Atlas.Matrix Atlas.Security CAD Atlas.Security Atlas.Audit iBrisa.SIC SGI SGMA SGDT Cross-cut do módulo de portagens AUTENTICAÇÃO

6 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 Consumidor de serviço Adaptador #1 Fornecedor de serviço #1 Consumidor de serviço Adaptador #N Fornecedor de serviço #N

7 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 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 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 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 11 MDSoC – Aplicação a ITS (2) Alguns métodos continuavam a combinar funcionalidades distintas: public int ChargeToll(Toll originToll) { int amountToCharge = this.AmountFromOtherToll(originToll); amountCharged += amountToCharge; // This region shouldn't be aware of this traffic management variable numVehiclesPassedThisHour++; return amountToCharge; }

12 12 Hyper/Net Desenvolveu-se um protótipo para.NET que permite a composiçã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.Merge, -3, ChargeTollMerge)] public int ChargeToll(Toll originToll) { numVehiclesPassedThisHour++; return 0; }

13 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