Padr˜oes de projetos s˜ao artefatos bastante utilizados na engenharia de software para facilitar e guiar o processo de desenvolvimento atrav´es de solu¸c˜oes pr´e-definidas para problemas recorrentes no projeto de softwares. Por´em, em nossas contribui¸c˜oes n´os utilizamos os mesmos para guiar o desenvolvimento de esquemas de banco para dados de trajet´orias de objetos m´oveis. A id´eia consiste em oferecer um meta-esquema padr˜ao de esquema de dados utilizando os conceitos de trajet´oria semˆantica e pontos para extens˜ao do esquema (hooks), os quais podem ser utilizados para adicionar informa¸c˜oes semˆanticas relacionadas com as trajet´orias.
O meta-esquema transacional para representa¸c˜ao semˆantica de trajet´orias pro- posto tem como principal caracter´ıstica o encapsulamento dos dados de trajet´orias em tipos estruturados. No modelo de dados s˜ao consideradas, al´em da entidade trajet´oria, entidades para representar os objetos m´oveis e os eventos decorrentes de cada trajet´oria. O modelo permite uma maior legibilidade e facilidade de manipula¸c˜ao dos dados do que em seu estado bruto e, al´em disso, o encapsulamento de cada entidade em um tipo estrutu- rado permite propor, ainda, m´etodos para manipula¸c˜ao de cada entidade e seus atributos. Com isso, tem-se uma maneira eficiente de lidar com os aspectos geom´etricos dos objetos, enquanto o aspecto semˆantico fica a cargo dos atributos exigidos pelo dom´ınio de aplica¸c˜ao acrescentados como extens˜ao do modelo e dos relacionamentos do objeto trajet´oria com os demais objetos do contexto da aplica¸c˜ao.
listas de objetos encapsuladas. Uma para objetos que representam os dados oriundos dos dispositivos de localiza¸c˜ao geogr´afica e outra para objetos que representam a segmenta¸c˜ao semˆantica da trajet´oria com base nos eventos decorrentes da mesma. Essas listas s˜ao res- pons´aveis por capturar os aspectos geom´etricos e semˆanticos das trajet´orias em um ´unico tipo de dado. Cada evento possui dois pontos espa¸co-temporais que correspondem ao in´ıcio e fim do mesmo e uma descri¸c˜ao textual sobre o mesmo (caracteriza¸c˜ao do tipo de evento), a qual ´e pr´opria de cada aplica¸c˜ao. Mais ainda, possui m´etodos recuperar e manipular os atributos geom´etricos e computar medidas da trajet´oria como, por exemplo, o comprimento, dura¸c˜ao, velocidade m´edia e a linha espacial do seu percurso. Al´em dos m´etodos j´a propostos no encapsulamento, o projetista da aplica¸c˜ao pode estender o tipo com novos m´etodos e atributos de acordo com suas necessidades. Al´em da semˆantica asso- ciada ao tipo trajet´oria, qualquer outra deve ser acrescentada atrav´es de novos atributos em tipos definidos pelo projetista (e.g. objeto m´ovel contendo uma lista de trajet´orias) ou atrav´es do relacionamento de trajet´orias com outros objetos (e.g. locais de interesse).
Figura 2: Trajectory data type
Exibimos na Figura 3 um exemplo de extens˜ao do tipo TrajectoryType do padr˜ao proposto de acordo com o nosso estudo de caso para ilustrar. As extens˜oes s˜ao real¸cadas por um sinal de “+”. Na defini¸c˜ao dos m´etodos, foi identificada a necessidade de obter rela¸c˜oes de velocidade m´edia para a trajet´oria como um todo, sua dura¸c˜ao total e, prin- cipalmente, m´etodos para manipula¸c˜ao dos eventos. Dentre estes m´etodos identificados, destacamos a necessidade de um m´etodo para contagem de eventos de tipos espec´ıficos da trajet´oria (e.g. quantidade de eventos do tipo Atendimento realizado em uma tra- jet´oria), para computar a soma da dura¸c˜ao de tipos espec´ıficos de eventos (e.g. a soma da
dura¸c˜ao dos eventos do tipo atendimento da trajet´oria) e para computar a soma do valor associado aos eventos (e.g. soma da quantidade de produto entregue por trajet´oria). Na defini¸c˜ao das propriedades, criamos atributos para representar como vari´avel o resultado do processamento dos m´etodos para evitar reprocessamento em trajet´orias que j´a foram finalizadas.
Figura 3: Exemplo de extens˜ao do Trajectory data type com base no estudo de caso Como exposto, grande parte das informa¸c˜oes das trajet´orias ´e dependente da aplica¸c˜ao. ´E imposs´ıvel fixar um tipo trajet´oria adequado a todos os dom´ınios. A solu¸c˜ao, ent˜ao, ´e decompor os atributos do tipo em componentes na forma de um meta-esquema na qual outros objetos ou informa¸c˜oes semˆanticas da aplica¸c˜ao possam ser ligados. Para o atributo que identifica o objeto m´ovel, um novo tipo (MovingObjectType) foi criado, j´a que uma trajet´oria ´e sempre resultado de um deste.
A Figura 4 exibe o meta-esquema proposto para o esquema transacional de tra- jet´orias com tipos necess´arios para representar as trajet´orias, seus eventos e os objetos m´oveis, pois consideramos que estes s˜ao os componentes comuns para todas as aplica¸c˜oes
de gerenciamento de trajet´orias. O projetista pode acrescentar atributos para os tipos e, atrav´es dos pontos de extens˜ao representados pelas caixas quadriculadas, acoplar os tipos da aplica¸c˜ao. Esses tipos podem ser especializa¸c˜oes para os tipos do padr˜ao. Po- demos ter especializa¸c˜oes do tipo MovingObjectType para representar os diferentes tipos de objetos m´oveis como, por exemplo, pessoas, ve´ıculos, animais, navios etc. Racioc´ınio an´alogo pode ser aplicado para trajet´orias, onde al´em de estender o tipo TrajectoryType com os atributos necess´arios para cada dom´ınio, podemos especializ´a-lo para diferentes interpreta¸c˜oes de trajet´oria. Podemos ter, para trajet´orias de pessoas se deslocando a p´e em uma cidade, um tipo espec´ıfico como trajet´orias de turistas. As caixas tracejadas podem representar, ainda, objetos da aplica¸c˜ao com os quais os objetos do padr˜ao se relacionam, como regi˜oes, clientes, locais de interesse (e.g. local de trabalho, shoppings), planejamentos de entrega (nos casos de trajet´orias de ve´ıculos de entrega) etc. Essas extens˜oes, juntamente com a segmenta¸c˜ao da trajet´oria por eventos, s˜ao respons´aveis por representar a semˆantica do dom´ınio da aplica¸c˜ao.
Figura 4: Meta-esquema para ambiente transacional
Ilustramos a extensibilidade do meta-esquema transacional proposto atrav´es da Figura 5, na qual apresentamos o padr˜ao adaptado de acordo com o estudo de caso. Estendemos o tipo MovingObjectType e criamos a classe Truck para representar os ve´ıculos
da aplica¸c˜ao. A trajet´oria ´e representada pelo tipo TravelType previamente estendido na Figura 3 e, a partir deste tipo, outros dois foram especializados: DeliveryTravel e
RefuelingTravel. O primeiro para representar as caracter´ısticas espec´ıficas de viagens de
entrega de produto, enquanto o segundo para as de viagens de coleta de produto. Ainda, para os eventos, foi necess´ario a cria¸c˜ao de uma propriedade para representar um valor associado ao evento (e.g. a quantidade entregue em um evento do tipo Atendimento, velocidade instantˆanea em um evento do tipo Excesso de velocidade). Al´em dos tipos especializados, podemos ter objetos do dom´ınio da aplica¸c˜ao, como os do tipo ´Area e Planejamento, os quais podem ser usados para estabelecimento de rela¸c˜oes. Por exemplo, podemos usar objetos do tipo ´Area para verificar rela¸c˜oes espaciais (e.g. inside, cross) entre estes e trajet´orias ou segmentos de trajet´oria definidos por eventos.
Figura 5: Exemplo de extens˜ao do meta-esquema para ambiente transacional com base no estudo de caso