1

Design Patterns & Design Patterns & MDSoCMDSoC

Casos de uso em software ITSCasos de uso em software ITSTiago Delgado Dias Software Architect Tiago.Dias@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

iBrisa – Padrões: Componente (2)

através da utilização de Web Controls, ex.:- Controlo de autenticação

- Localização deelementos

- Listagem de PMVs

Toll.Services

Traffic

Tolls.CADTolls.CAD

Tolls.SinopticTolls.Sinoptic

Atlas.VideoAtlas.Video

Video.Services

Atlas.Logging

Atlas.MatrixAtlas.Matrix

Atlas.Security

CADCAD

Atlas.SecurityAtlas.Security

Atlas.AuditAtlas.Audit

iBrisa.SIC

SGISGI

SGMASGMA

SGDTSGDT

Cross-cut do módulo de portagens

AUTENTICAÇÃO

AUTENTICAÇÃO

AUTENTICAÇÃO

AUTENTICAÇÃO

AUTENTICAÇÃO

AUTENTICAÇÃO

AUTENTICAÇÃOAUTENTICAÇÃO

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çoConsumidor de serviço

Adaptador #1 Fornecedor de serviço #1Fornecedor de serviço #1

Consumidor de serviçoConsumidor de serviçoAdaptador #N

Fornecedor de serviço #NFornecedor de serviço #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(originToll);amountCharged += amountToCharge;// This region shouldn't be aware of this traffic management variablenumVehiclesPassedThisHour++;

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.Merge, -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