XISA for smartTAGs

eXtended Information System Architecture for SmartTags Andr Tavares Duarte Ramos

Dissertao para obteno do Grau de Mestre em Engenharia Informtica e de Computadores

Jri
Presidente: Professor Jos Manuel Nunes Salvador Tribolet Orientador: Professor Pedro Manuel Moreira Vaz Antunes de Sousa Vogal: Professor Alberto Manuel Rodrigues da Silva

Setembro 2008

ii

Agradecimentos
Agradeo a todas as pessoas envolvidas no projecto e em especial ao Orientador, o professor Pedro Sousa, pela oportunidade que me concedeu de trabalhar num contexto empresarial e numa rea de grande interesse e actualidade e pela orientao que me concedeu durante a realizao do projecto. Ainda reconheo particular gratido a todas as pessoas da rea de Business Consulting da Link, pela sua contribuio e disponibilidade durante o projecto, ao meu amigo Andr Silva pelos inmeros conselhos e sugestes que muito contriburam para o resultado do projecto e ao meu pai no apoio elaborao do relatrio. No me podia esquecer de todo o apoio dado pela minha famlia e amigos ao longo do meu percurso universitrio e por fim agradecer em especial minha me por todo o suporte que me proporcionou ao longo de todos estes anos.

iii

Resumo
A mobilidade humana um factor essencial para o crescimento sustentvel da Europa e est actualmente a crescer a um nvel elevado. As viagens internacionais e de longa distncia crescem a um nvel ainda mais elevado, respondendo globalizao. A combinao do tratamento de bagagens e o transporte multimodal ainda no foi completamente abordado pela indstria do transporte. No entanto, bvio que para as grandes transportadoras o reencontro entre passageiros e bagagens tem grandes implicaes nos atrasos dos transportes, na logstica para lidar com as excepes de cada passageiro e at com problemas de segurana. O suporte para o transporte multimodal actualmente considerado um aspecto chave no transporte de cargas e na mobilidade urbana. Alguns progressos tm sido feitos nestas reas. No entanto, a reconciliao entre passageiros e bagagens ao longo da cadeia de transporte ainda no recebeu o devido tratamento. Assim, a contribuio fundamental deste projecto consiste em perceber como usar as etiquetas RFID para fornecer uma nova maneira de tratar a reconciliao entre passageiros e bagagens durante uma viagem de transporte multimodal. Pretende-se aplicar a metodologia de arquitectura de sistemas de informao, que enquadre a informao e as funcionalidades residentes nas tags RFID, ao caso real em que intervenham todos os conceitos na rea do transporte de pessoas e bagagens. Adicionalmente pretende-se usar uma nova metodologia que partindo dos processos de negcio permite representar uma arquitectura SOA, como forma de garantir o alinhamento entre as TI e o negcio.

Palavras-chave: Arquitecturas Orientadas aos Servios, Identificao por rdio frequncia, Transporte Multimodal, Reconciliao.

iv

Abstract
Human mobility is a key factor for sustainable growth in Europe. It is currently growing at an high rate. International and long distance travelling is growing even at higher rates. A key aspect of long distance Human Mobility is the need to handle passengers luggage. Such combination of luggage handling and multimodal transportation has not been fully addressed by the transport industry. However it is obvious for the large operators that reconciliation between passengers and luggage has major implications in transportation delays, logistics for handling all exceptions hazards for the travelers and even security related problems. Support for multimodality is already considered a key aspect in cargo transportation and in urban mobility. Relevant progress has been made in those areas. However the issue of reconciliation between passengers and luggage across the transportation chain has not been addressed yet. Thus, the fundamental contribution of this project is to know how to use advanced RFID tags to provide a completely new way for handling passenger and luggage reconciliation in a multimodal human transportation. The project purpose is to apply the information system architecture methodology that covers information and functionalities residing in RFID tags, to a real case in the area of passenger and luggage transportation. Furthermore, it seeks to use a new methodology that represents a SOA architecture from the business processes, to guarantee the alignment between IT and the business.

Keywords:

Service

Oriented

Architecture,

Radio

Frequency

Identification,

Multi-modal

Transportation, Reconciliation.

ndice
AGRADECIMENTOS ................................................................................................................................III RESUMO ..................................................................................................................................................... IV ABSTRACT ...................................................................................................................................................V NDICE......................................................................................................................................................... VI LISTA DE ABREVIATURAS.................................................................................................................... IX LISTA DE FIGURAS....................................................................................................................................X LISTA DE TABELAS ................................................................................................................................XII 1 INTRODUO ..................................................................................................................................... 1 1.1 1.2 1.3 1.4 1.5 2 CONTEXTO ....................................................................................................................................... 1 PROBLEMA A RESOLVER ................................................................................................................... 1 OBJECTIVO DO TRABALHO ................................................................................................................ 2 METODOLOGIA ................................................................................................................................. 2 ORGANIZAO DO RELATRIO ........................................................................................................ 3

ESTADO DA ARTE.............................................................................................................................. 5 2.1 SISTEMA DE SEGUIMENTO LOGSTICO ............................................................................................... 5 Topologia da rede.................................................................................................................... 6 Modelo hub & spoke................................................................................................................ 7 Tecnologia ............................................................................................................................... 8 Processo de seguimento......................................................................................................... 11 Seguimento baseado em eventos............................................................................................ 12

2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.2

REDE DE CLULAS .......................................................................................................................... 13 Subsistema da estao base................................................................................................... 14 Subsistema de comutao de rede ......................................................................................... 14 Gesto da mobilidade ............................................................................................................ 15 Roaming................................................................................................................................. 16

2.2.1 2.2.2 2.2.3 2.2.4 2.3

SISTEMA DE POSICIONAMENTO GLOBAL ......................................................................................... 18 Descrio tcnica .................................................................................................................. 18 Mtodo de operao .............................................................................................................. 19 Sistemas de seguimento por GPS........................................................................................... 21

2.3.1 2.3.2 2.3.3 2.4 3

REFLEXO SOBRE O ESTADO DA ARTE ............................................................................................ 21

DESCRIO DA METODOLOGIA USADA ................................................................................. 23 3.1 FUNDAMENTOS............................................................................................................................... 23 Framework Zachman............................................................................................................. 24 Arquitectura de Sistemas de Informao............................................................................... 25

3.1.1 3.1.2

vi

3.2

FRAMEWORK BPB-SOA ................................................................................................................ 26 Business Solutions ................................................................................................................. 27 Business Services ................................................................................................................... 27 Information Services.............................................................................................................. 28 Business Infra-structure Services .......................................................................................... 28

3.2.1 3.2.2 3.2.3 3.2.4 3.3

METODOLOGIA SOP....................................................................................................................... 28 Identificao das Business Solutions ..................................................................................... 29 Identificao dos Business Services ...................................................................................... 30 Identificao dos Business Infra-structure Services .............................................................. 31

3.3.1 3.3.2 3.3.3 4

ARQUITECTURA PROPOSTA........................................................................................................ 32 4.1 4.2 ANLISE DO PROBLEMA ................................................................................................................. 32 Relao com a framework Zachman...................................................................................... 35 ARQUITECTURA ORGANIZACIONAL ................................................................................................ 36 Organigrama ......................................................................................................................... 36 Misso e Objectivos............................................................................................................... 37 Macro-Processos ................................................................................................................... 37 Relao com a framework Zachman...................................................................................... 38

4.1.1

4.2.1 4.2.2 4.2.3 4.2.4 4.3

ARQUITECTURA PROCESSOS ........................................................................................................... 38 Decomposio funcional ....................................................................................................... 38 Especificao de Processos ................................................................................................... 40 Objectivos, Actores e Processos ............................................................................................ 40 Relao com a framework Zachman...................................................................................... 41

4.3.1 4.3.2 4.3.3 4.3.4 4.4

ARQUITECTURA INFORMACIONAL .................................................................................................. 41 Entidades informacionais ...................................................................................................... 42 Matriz de relaes entre entidades ........................................................................................ 44 Relao com a framework Zachman...................................................................................... 46

4.4.1 4.4.2 4.4.3 4.5

ARQUITECTURA DE APLICAES .................................................................................................... 46 Matriz de CRUD .................................................................................................................... 47 Descrio das aplicaes propostas...................................................................................... 48 Relao com a framework Zachman...................................................................................... 50

4.5.1 4.5.2 4.5.3 4.6 4.7

ARQUITECTURA TECNOLGICA ...................................................................................................... 50 Relao com a framework Zachman...................................................................................... 51 ARQUITECTURA DE SERVIOS ........................................................................................................ 51 Business Solutions ................................................................................................................. 52 Business Services ................................................................................................................... 52 Information Services.............................................................................................................. 55 Business Infra-structure Services .......................................................................................... 56 Arquitectura Centralizada ou Distribuda............................................................................. 58 Relao com a framework Zachman...................................................................................... 58

4.6.1

4.7.1 4.7.2 4.7.3 4.7.4 4.7.5 4.7.6

vii

PROTTIPO ....................................................................................................................................... 60 5.1 TECNOLOGIA USADA ...................................................................................................................... 61 Windows Server 2003 ............................................................................................................ 61 Framework .NET ................................................................................................................... 61 ASP .NET ............................................................................................................................... 61 Visual Studio 2005................................................................................................................. 62 BizTalk Server 2006 R2 ......................................................................................................... 62 SQL Server 2005.................................................................................................................... 66 DLP RFID1............................................................................................................................ 66

5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.1.6 5.1.7 5.2 5.3

ARQUITECTURA 3-TIERS ................................................................................................................ 66 IMPLEMENTAO ........................................................................................................................... 67 Aplicao de Base de Dados ................................................................................................. 67 Aplicao de Lgica de Negcio ........................................................................................... 67 Portal..................................................................................................................................... 68 Aplicao Gesto RFID......................................................................................................... 68

5.3.1 5.3.2 5.3.3 5.3.4 6 7 8

VALIDAO ...................................................................................................................................... 71 CONCLUSES.................................................................................................................................... 75 BIBLIOGRAFIA ................................................................................................................................. 77

ANEXO A..................................................................................................................................................... 80 ANEXO B ..................................................................................................................................................... 89

viii

Lista de Abreviaturas
AE Arquitectura Empresarial AI Arquitectura Informacional API Application Programming Interface ASI Arquitectura de Sistemas de Informao BPMN Business Process Modeling Notation B2B Business to Business BPB-SOA Business Process Based Service Oriented Architecture CRUD Create, Read, Update, Delete DSPI Device Service Provider Interface EAI Enterprise Aplication Integration EPC Electronic Product Code ERP Enterprise Resource Planning GPS Global Positioning System GSM Global System for Mobile Communications. HTML HyperText Markup Language P2P Peer to Peer RFID Radio Frequency Identification SDK Software Development Kit SI Sistema de Informao SOA Service Oriented Architecture SOP Service on Processes TI Tecnologia de Informao TSMART Tags for SMARt Travellers UPC Universal Product Code XML eXtensible Markup Language

ix

Lista de Figuras
Figura 1 Metodologia usada no desenvolvimento do projecto...................................................... 3 Figura 2 Exemplos das vrias topologias de redes [4]. ................................................................ 6 Figura 4 Exemplo de cdigo de barras. ........................................................................................ 9 Figura 5 Exemplo de tag RFID. ..................................................................................................... 9 Figura 6 Quadro comparativo entre cdigo de barras e RFID [13]. ............................................ 10 Figura 7 Estrutura da rede de distribuio de uma cadeia de logstica [14]. .............................. 12 Figura 8 Fluxograma do processo de seguimento por eventos [18]. .......................................... 13 Figura 9 Estrutura da rede GSM [20]. ......................................................................................... 13 Figura 10 Exemplo da comunicao entre duas redes. .............................................................. 17 Figura 11 Exemplo do processo de trilaterao no GPS [39]. .................................................... 20 Figura 12 Framework de Zachman [52]. ..................................................................................... 23 Figura 13 Arquitectura de sistemas de informao..................................................................... 25 Figura 14 Framework BPB-SOA [51]. ......................................................................................... 27 Figura 15 Relao entre a arquitectura empresarial e a metodologia SOP................................ 28 Figura 16 Metodologia SOP [51]. ................................................................................................ 29 Figura 17 Exemplo de uma viagem multimodal. ......................................................................... 33 Figura 18 Bagagem permanece no aeroporto de partida. .......................................................... 34 Figure 19 Bagagem encaminhada para o aeroporto errado. ...................................................... 34 Figura 21 Organigrama e stakeholders internos do TSMART. ................................................... 36 Figura 22 Resumo dos meios e fins para o plano de negcio do TSMART. .............................. 37 Figure 23 Decomposio dos objectivos organizacionais........................................................... 37 Figura 24 Macro-Processos. ....................................................................................................... 37 Figura 25 Decomposio funcional dos processos de primeiro nvel. ........................................ 38 Figura 26 Matriz da relao entre processos e objectivos. ......................................................... 40 Figura 27 Matriz da relao entre processos e actores. ............................................................. 41 Figura 28 Matriz de relao entre entidades............................................................................... 45 Figura 29 Alinhamento entre as vrias arquitecturas [55]........................................................... 46 Figura 30 Contextualizao dos SI na matriz de CRUD [55]. ..................................................... 47 Figura 31 Matriz de CRUD. ......................................................................................................... 48 Figura 32 Identificao dos responsveis por cada aplicao.................................................... 50 Figura 33 Arquitectura tecnolgica.............................................................................................. 50 Figura 34 Exemplo da macro a correr a heurstica B2 sobre o processo Gerir Alertas.............. 55 Figura 35 Identificao de Information Services de actualizao atravs da matriz CRUD....... 55 Figura 36 Relao entre Servios das vrias camadas. ............................................................. 57 Figura 37 Arquitectura de Componentes e de Deployment. ....................................................... 60 Figura 38 Biztalk Server 2006 [42]. ............................................................................................. 62 Figura 39 Exemplo de integrao EAI [42].................................................................................. 63 Figura 40 Arquitectura do motor de mensagens do BizTalk [43]. ............................................... 64

Figura 41 Arquitectura do Biztalk RFID [44]................................................................................ 64 Figura 42 Motor de Processamento de Eventos [46]. ................................................................. 65 Figura 43 Arquitectura 3 camadas Cliente/Servidor [61]. ........................................................... 67 Figura 44 Exemplo de uma orquestrao em Biztalk.................................................................. 68 Figura 45 RFID Manager. ............................................................................................................ 68 Figura 46 Visualizao da passagem de tags nos processos RFID........................................... 69 Figura 47 Exemplo de ficheiro XML que representa a passagem de uma tag por um leitor. ..... 70 Figura 48 Imagem do leitor fsico usado no prottipo [48]. ......................................................... 70 Figura 49 Ecr inicial do prottipo. .............................................................................................. 71 Figura 50 Ecr de registo de uma viagem por um cliente........................................................... 72 Figura 51 Ecr de consulta de informao por parte do cliente.................................................. 72 Figura 52 Ecr de um operador a consultar avisos..................................................................... 73 Figura 53 Ecr de consulta da viagem de uma tag..................................................................... 74

xi

Lista de Tabelas
Tabela 1 Catlogo dos processos de negcio. ........................................................................... 39 Tabela 2 Entidades de Informao.............................................................................................. 42 Tabela 3 Justificao das ligaes entre entidades.................................................................... 45 Tabela 4 Descrio da aplicao 1. ............................................................................................ 48 Tabela 5 Descrio da aplicao 2. ............................................................................................ 48 Tabela 6 Descrio da aplicao 3. ............................................................................................ 49 Tabela 7 Descrio da aplicao 4. ............................................................................................ 49 Tabela 8 Descrio da aplicao 5. ............................................................................................ 49 Tabela 9 Descrio dos Business Services sugeridos................................................................ 54

xii

1 Introduo
1.1 Contexto
O projecto a que me propus nasce de uma proposta de projecto, denominado TSMART (Tags for SMARt Travellers), de diversos intervenientes ao nvel europeu tais como a ISFEFE, a LINK, a ANA, a INOV, entre outros [3]. Apesar da primeira proposta do projecto no ter sido aprovada, est neste momento em concluso uma nova proposta para discusso. No projecto TSMART pretende-se desenvolver uma plataforma multimodal para suportar a reconciliao entre passageiros e bagagens, cobrindo a viagem toda, desde a sua partida at porta de chegada, e envolvendo tanto a bagagem levada pelo passageiro como a bagagem levado por outras entidades. Assim sendo, de todo conveniente investigar alguns aspectos propostos no projecto TSMART, no com o intuito de o resolver num todo mas para cobrir uma parte deste todo.

1.2 Problema a resolver

Um aspecto chave da mobilidade humana de longa distncia o problema de lidar com a bagagem. O suporte ao transporte multimodal, ou seja, englobando transporte areo, martimo, ferrovirio e rodovirio, tratado em algumas indstrias, como acontece na indstria do transporte de cargas. No entanto, em relao reconciliao entre passageiros e bagagens ao longo da cadeia de transporte, ainda no se verifica uma conveniente aproximao. Portanto, justifica-se uma nova abordagem em relao reconciliao de passageiros e bagagens num transporte multimodal. O problema fundamental a ser respondido no projecto ocorre no modo de utilizar as tags RFID para suportar eficazmente a reconciliao entre passageiros e bagagens numa perspectiva de viagem multimodal. Da a necessidade do presente trabalho devido a dois factores: Aumento das viagens internacionais e de longa distncia, consequente do elevado crescimento da mobilidade humana que a globalizao tem originado nos ltimos anos, provocando viagens cada vez mais longas e frequentes, e muitas vezes em meios de transporte diferentes. Gesto das bagagens dos passageiros e todos os problemas inerentes ao seu manuseamento, como a perda, atraso ou reenvio de bagagens, donde resulta a

necessidade de efectuar a reconciliao de passageiros e a sua bagagem ao longo de toda a viagem, isto , ao longo dos pontos intermdios da viagem at ao destino final. Viajar envolve enviar passageiros e bagagens atravs de uma srie de entidades e plataformas de transporte. Desde a partida do local de origem, que pode ser o hotel ou a sua casa, os passageiros e a bagagem movimentam-se entre entidades autnomas, at chegarem ao destino final. Isto necessita que os passageiros e as bagagens sejam registados e seguidos at ao fim da viagem. O objectivo passa por suportar a reconciliao de passageiros e bagagens, ao longo de toda a viagem, englobando a bagagem de poro, normalmente levada por terceiros, e a bagagem de mo carregada pelo prprio passageiro. Esta plataforma de reconciliao poder ter vrias vantagens: os passageiros ficam com uma perspectiva global da viagem com nveis de qualidade superiores, em vez de vrias viagens independentes; as companhias reduzem os gastos no processo logstico, lidando com situaes imprevisveis, como a perda, atraso ou reenvio de bagagens; entre companhias a informao em tempo real permite-lhes efectuar estimativas do fluxo entre si, favorecendo uma melhor locao de recursos no pico de dia espectvel.

1.3 Objectivo do trabalho

O problema enunciado anteriormente leva ao desenvolvimento de uma plataforma de reconciliao entre passageiros e bagagens ao longo de uma viagem multimodal, desde o seu incio at ao seu fim, utilizando a tecnologia de RFID. Nesta perspectiva, prosseguem-se trs objectivos claros: Produzir uma arquitectura de processos que d resposta ao problema enunciado. Criar uma arquitectura SOA para o problema, partindo de uma arquitectura de processos como forma de garantir o alinhamento entre o negcio e o TI, utilizando uma metodologia em investigao. Desenvolver um prottipo com o intuito de validar os servios encontrados na fase de desenho.

1.4 Metodologia
A realizao do projecto foi dividida em vrias fases (Fig. 1). Numa fase inicial, efectuou-se um enquadramento com o projecto TSMART, onde se leu a proposta de projecto que permitiu avaliar e perceber o problema a ser resolvido. De seguida investigou-se a tecnologia envolvida, levando ao estudo dos RFID, pois estes constituem uma tecnologia emergente e onde h algum desconhecimento e desconfiana das suas reais capacidades. Numa segunda fase, efectuou-se uma pesquisa sobre o seguimento de itens, pois durante a realizao do projecto tem que se fazer o seguimento das tags RFID para seguir os passageiros

e as bagagens. Foram abordados trs tipos de seguimento: nas cadeias logsticas, nas redes de clulas e atravs de satlite.

Figura 1 Metodologia usada no desenvolvimento do projecto. De seguida partiu-se para a realizao das arquitecturas que representam uma arquitectura empresarial usando a metodologia ASI: uma Arquitectura Organizacional apenas para enquadrar o sistema a ser proposto, uma Arquitectura de Processos, uma Arquitectura de Informao, uma de Aplicaes e uma Tecnolgica. Seguiu-se depois uma metodologia que estava a ser investigada pela equipa de Business Consulting da Link, no mbito do projecto FEABS, tendo este projecto terminado durante a realizao do presente trabalho. O projecto FEABS pretende descrever uma metodologia para desenvolver uma arquitectura SOA a partir dos processos de negcio. Com o auxlio dos elementos da equipa do projecto FEABS e com o estudo da metodologia foi desenvolvida uma proposta de arquitectura SOA para o problema da reconciliao entre passageiros e bagagens numa viagem multimodal. Efectuou-se ainda uma anlise funcional aos processos de negcio desenhados para complementar a identificao dos servios. Esta situao permitiu uma posterior comparao entre os dois mtodos de descoberta de servios. Numa fase final, a partir dos servios identificados, realizou-se a implementao de alguns desses servios. O prottipo implementado contm uma parte de apresentao, com um site, uma parte de lgica de negcio, implementada em Biztalk, e uma parte de acesso aos dados muito camuflada no Biztalk, seguindo uma arquitectura 3-Tiers. Para concluir realizou-se a integrao da lgica de negcio com um leitor fsico e tags reais.

1.5 Organizao do Relatrio

Concluda a apresentao do projecto, no captulo dois, descreve-se o estudo do problema do seguimento de bens, que ser necessrio para a realizao do projecto, com o seguimento de pessoas e bagagens. O captulo trs faz uma apresentao das frameworks e das metodologias utilizadas para a realizao do projecto. Refere-se a metodologia ASI e a metodologia SOP, que ser a base da arquitectura de servios e as frameworks de Zachman, usualmente utilizada na representao de organizaes e BPB-SOA para a definio dos conceitos SOA.

No captulo quatro descreve-se a arquitectura proposta de maneira detalhada. Esta proposta de arquitectura contempla a arquitectura organizacional, arquitectura de processos, arquitectura de informao, arquitectura de aplicaes, arquitectura tecnolgica e por fim a arquitectura de servios. O captulo cinco, descreve de um modo gera,l a implementao dos servios encontrados. Fazse uma descrio das tecnologias associadas e as opes tomadas para a implementao do prottipo. O captulo seis apresenta a validao dos servios obtidos atravs do prottipo que foi produzido. Finalmente, no captulo seis so descritas as consideraes finais relativamente ao projecto realizado, onde aparecem as concluses sobre o que foi estudado durante o projecto.

2 Estado da Arte
Esta combinao, como o tratamento de bagagens e o transporte multimodal de passageiros, levou ao estudo de sistemas de seguimento. Estes sistemas identificam os vrios pontos de passagem dos passageiros e bagagens, funcionando como pontos de controlo para se efectuar a reconciliao entre passageiros e a bagagem ao longo da cadeia de transporte. Estudaram-se trs tipos de sistemas, tendo os trs em comum o facto de permitirem efectuar o seguimento de um bem ou indivduo, embora com mtodos e tecnologias diferentes: Sistemas de seguimento logstico: seguimento com pontos de controlo, atravs do auxlio de leitores fixos a determinados locais fsicos, sendo registado o local por onde passou o objecto, sem no entanto se saber onde se encontra efectivamente. Permite responder pergunta: Onde passou?. o mtodo usado nas cadeias de distribuio para se fazer o seguimento de produtos ao longo da cadeia logstica. Pode ser efectuado recorrendo tecnologia dos cdigos de barras ou aos RFIDs. Este tipo de sistemas est descrito na seco 2.1. Redes de clulas: seguimento em tempo real, que permite saber onde se encontra o objecto em qualquer instante, respondendo pergunta: Onde est?. Este tipo de seguimento baseia-se na infra-estrutura da rede para identificar o local do dispositivo, atravs de clulas residentes e clulas vizinhas, que cobrem determinadas reas geogrficas e comunicam entre si, para indicar o local actual do dispositivo. Este tipo de seguimento utiliza-se na indstria das telecomunicaes, sendo descrito o exemplo da rede GSM na seco 2.2. Sistemas de posicionamento global: outro tipo de seguimento em tempo real, que tal como nas redes de clulas permite responder pergunta: Onde est?. Baseia-se na utilizao de satlites e de um dispositivo receptor para determinar a longitude, a latitude e a altitude deste. O receptor responsvel pelo clculo da sua localizao com base nos sinais recebidos dos satlites em rbita na terra. Exemplo deste tipo de sistemas o GPS, que ser descrito na seco 2.3.

2.1 Sistema de seguimento logstico

The Council of Logistics Management defines logistics as that part of the supply chain process that plans, implements, and controls the efficient, effective flow and storage of goods, services,

and related information from the point of origin to the point of consumption in order to meet customers requirements. The logistics program prepares you for employment in a large number of different positions and types of firms across the entire supply chain [1]. A logstica a arte e cincia de gerir e optimizar a cadeia de abastecimento, controlando e reorganizando o fluxo de produtos, informao e outros recursos, como servios e pessoas, desde a sua fonte at ao cliente final. Envolve a integrao de informao com o transporte, inventrio, armazenamento, manuseamento e empacotamento de material [2]. Como forma de melhorar a cadeia logstica, foram desenvolvidos inmeros esforos, sendo o seguimento dos bens um dos aspectos essenciais. Seguimento o processo de determinar a localizao actual, as localizaes anteriores e outra informao de estado do bem, de modo a identificar a sua rota e para onde deve ser enviado futuramente. A este processo tambm se chama dar visibilidade ao bem na cadeia de distribuio. Pode-se recolher qualquer informao acerca da momentnea ou temporria localizao de um objecto ou pessoa, a fim de poder seguir o caminho de uma instncia ou pessoa. Assim sendo, qualquer sistema de localizao ir usar o conhecimento que tem a priori acerca da localizao dos seus ns. Em 2.1.1 descrevem-se as vrias topologias de redes existentes actualmente. Em 2.1.2 descreve-se a topologia da rede usada actualmente em todas as cadeias logsticas, sendo o seu modelo denominado hub & spoke. Os sistemas de seguimento logstico existentes envolvem duas tecnologias distintas: os cdigos de barras, muito usados nas cadeias de retalho; e os RFID, uma tecnologia mais recente, que comea agora a ter maior utilizao. Estas duas tecnologias esto descritas em 2.1.3, onde tambm se faz uma comparao entre ambas as abordagens. Em 2.1.4 efectuada a descrio do processo de seguimento convencional. Por fim, em 2.1.5 apresenta-se a descrio do seguimento de objectos baseado em eventos.

2.1.1 Topologia da rede

A topologia uma descrio da disposio esquemtica da rede, incluindo os seus ns e as suas ligaes. H duas formas de definir a geometria da rede: atravs da topologia fsica ou por intermdio da topologia lgica. No entanto, no contexto da logstica interessa apenas a descrio fsica da rede [4].

Figura 2 Exemplos das vrias topologias de redes [4]. Os vrios tipos de topologia, representados na figura 1, so: bus, estrela, anel, malha, linha, rvore e totalmente conectada [5, 6]. 6

Bus: o tipo de topologia em que todos os ns da rede esto conectados a um meio de transmisso comum, o qual tem exactamente dois pontos finais.

Estrela: Existe um n central, ao qual todos os ns esto ligados, e atravs deste n central que se faz a comunicao entre os diversos ns. o tipo de topologia em que se baseia o modelo hub & spoke descrito em 2.1.2, utilizado nas cadeias logsticas.

Anel: Tipo de topologia no qual cada n est conectado a outros dois ns da rede e em que o primeiro e o ultimo n esto tambm ligados, formando assim um anel.

Malha: Tipo de topologia em que os ns esto ligados de forma arbitrria, havendo no entanto sempre um caminho possvel entre cada n da rede.

Linha: Cada n da rede est conectado a dois outros ns, com excepo do primeiro e ltimo ns que s esto ligados a um outro n.

rvore: Tipo de topologia no qual um n de raiz tem uma conexo com um ou mais ns, tendo estes por sua vez ligao com um ou mais ns, no havendo limite para esta hierarquizao dos ns.

Totalmente ligada: o tipo de rede em que cada um dos ns tem ligao com todos os outros ns da rede. usualmente classificado como modelo ponto a ponto e ser descrito tambm em 2.1.2 comparativamente com o modelo hub & spoke.

2.1.2 Modelo hub & spoke

A rede de distribuio hub & spoke, como exemplifica a figura 3, uma rede na qual todos os caminhos comeam numa ponta e se deslocam no sentido de outras pontas, passando atravs de um ou vrios centros agregadores (hubs). A topologia semelhante a uma roda de bicicleta, em que todos os aros se agregam no centro, sendo os extremos dos aros representativos das pontas. Este modelo segue a

topologia em estrela descrita na seco anterior e o modelo geralmente utilizado na indstria, em particular no transporte de pessoas e cargas, telecomunicaes, bem como na computao distribuda. muitas vezes Figura 3 Exemplo de uma rede hub & spoke [60].

comparado ao modelo ponto a ponto (descrito na seco anterior pela topologia totalmente ligada), em que o transporte se efectua do local de origem directamente para o local de destino, em vez de passar por um centro agregador. No exemplo descrito na figura 3, um passageiro que pretenda ir de San Francisco para Atlanta, dever passar pelo centro agregador de Denver, seguindo uma abordagem hub & spoke, enquanto que a viagem de San Francisco at Los Angeles feita seguindo o modelo ponto a ponto [7]. Vantagens do modelo hub & spoke face ao modelo ponto a ponto [7]: Operaes complicadas, como a ordenao de pacotes, podem ser consolidadas num centro, em vez de se fazer em vrios ns da rede. Permite uma maior eficincia de recursos no transporte, pois o nmero de viagens reduzido. Os vrios ns que no so centrais tornam-se assim bastante simples, o que facilita o aparecimento de novos ns. O servio feito com mais frequncia.

Desvantagens do modelo hub & spoke face ao modelo ponto a ponto [7]: O centro agregador pode ser um problema, visto que se pode exceder a sua capacidade de resposta. Alguns casos podem levar a que uma viagem seja mais longa do que uma viagem ponto a ponto. O modelo centralizado e a rotina diria pode ser inflexvel. Como exemplo, um pedido urgente de entrega entre dois pontos pode afectar as operaes do centro.

2.1.3 Tecnologia
Nesta seco sero descritas as duas tecnologias associadas ao seguimento de produtos ao longo da cadeia logstica, quer a tecnologia do cdigo de barras quer a RFID.

2.1.3.1 Cdigo de barras

O cdigo de barras (Fig. 4) uma representao grfica de dados, que pode ser numrica ou alfanumrica, dependendo do tipo de cdigo de barras utilizado. As linhas paralelas e verticais pretas e os espaos brancos entre si tm diferentes larguras, em funo das vrias tcnicas usadas na codificao de dados. A descodificao dos dados representados realiza-se por um equipamento chamado scanner, dotado de uma fonte luminosa vermelha, que por contraste das barras e seus espaos converte a representao grfica em bits (sequncias de 0 ou 1). Estes so interpretados pelo computador, que por sua vez os converte em letras ou nmeros, legveis para os utilizadores humanos [8]. O cdigo mais conhecido o adoptado para impresso nas embalagens de produtos de retalho. O cdigo EAN/UPC constitui um sistema internacional de identificao, que auxilia na 8

identificao inequvoca de um item a ser vendido, movimentado ou armazenado. Os nmeros representados nas barras identificam o pas emissor do cdigo, a empresa proprietria do produto e 4 ou 5 dgitos identificam o produto dentro dos seus outros produtos. Um ltimo dgito, conhecido por checksum, auxilia na segurana da leitura e descodificao do cdigo de barras, totalizando 12 ou 13 dgitos [9]. Existem ainda muitos outros tipos de cdigo de barras, para alm do UPC/EAN. O pharmacode usa-se nas distribuies farmacuticas, o telepen nas livrarias, o code 24 ou o code 128 para diversas utilizaes e muitos outros, cada um com uma finalidade diferente na indstria mundial e com simbologias distintas. Um caso especifico so os cdigos de barras a duas dimenses, sendo os mais comuns o PDF417, o Aztec Code e o Data Matrix. Estes novos tipos de cdigos de barra conseguem codificar milhares de bytes de dados num nico smbolo, sejam eles de texto ou binrios, tendo no entanto de recorrer a leitores que suportem este tipo de smbolos [10].

Figura 4 Exemplo de cdigo de barras.

Figura 5 Exemplo de tag RFID.

2.1.3.2 RFID
A identificao por rdio frequncia, conhecida pela sigla inglesa RFID, o mtodo de remotamente guardar e devolver dados, correspondentes a sinais de rdio emitidos por dispositivos chamados tags RFID. Uma tag RFID um pequeno objecto, com o aspecto da figura 5, parecido com uma etiqueta adesiva, que pode ser preso ou incorporado num produto, pessoa ou animal. A tag RFID contm uma antena, que permite receber e emitir sinais de rdio num transmissor RFID. Quando uma tag RFID passa numa zona electromagntica, detecta o sinal do leitor RFID. O leitor descodifica os dados codificados no circuito integrado da tag e reenvia-os para o computador que lhe est associado, com o intuito de processar a informao recebida. Existem dois tipos de etiquetas. Umas etiquetas so denominadas activas porque contm uma bateria, que consiste na sua fonte de energia. As outras so passivas, ou seja, usam a energia da onda emissora para efectuar o processamento e a resposta para o transmissor. Para alm disso, as etiquetas podem ser read-only, quer dizer, so apenas para leitura pois so programadas aquando da sua produo para no poderem ser alteradas, ou podem ser readwrite, se a memria da etiqueta for programada para poder ser lida e ao mesmo tempo escrita. A frequncia na qual operam as tags representa um factor determinante nos sistemas RFID. Estas apresentam trs tipos distintos:

High-frequency, serve aplicaes que necessitem de longos alcances, como as cadeias de distribuio. Intermediate-frequency, sistemas que esto agora a aparecer associados aos cartes inteligentes. Low-frequency, sistemas usados em aplicaes que necessitam de alcances pequenos, como o controlo de acessos.

As etiquetas dispem de um nmero de identificao nico, designado EPC, e potencialmente outro tipo de informao. O EPC tem 96 bits, 8 bits para o cabealho, 28 para o proprietrio da etiqueta, 24 para o tipo de item e 36 bits para a sua identificao. Este nmero est geralmente associado a uma base de dados e serve de chave para aceder informao mais detalhada do produto ou pessoa, a que est associada a etiqueta [11, 12].

2.1.3.3 Comparao do cdigo de barras com RFID

Nesta seco pretende-se fazer uma comparao entre o RFID e o cdigo de barras. Muitas vezes o RFID descrito como uma nova gerao de cdigo de barras, devido s vantagens enunciadas na figura 6.

Figura 6 Quadro comparativo entre cdigo de barras e RFID [13]. Em vez de se usar a luz para recolher ou ler o nmero de um cdigo de barras, as ondas de rdio so usadas para ler o nmero de uma etiqueta RFID, que no necessita de linha de viso para operar. Usar meios como as ondas de rdio significa que a etiqueta no ter de estar visvel para que se consiga efectuar a leitura no objecto ao qual est ligado. A etiqueta pode estar escondida dentro de uma caixa ou no interior do prprio objecto, que a leitura ser efectuada mesma. Isto minimiza ou elimina a necessidade de uma pessoa ter que passar ou orientar a etiqueta pelo leitor, como acontece no caso do cdigo de barras, podendo o leitor estar fixo, por exemplo, numa parede. Como o item ao passar pelo leitor ser lido automaticamente, originar uma enorme poupana de mo-de-obra e um substancial aumento de eficincia na leitura de itens. Outro aspecto do sistema RFID a sua capacidade de ler muitas etiquetas ao mesmo tempo. No necessrio apresentar cada etiqueta ao leitor separadamente, como exige o cdigo de barras. Em vez disso, todas as etiquetas dentro do alcance do leitor podem ser lidas quase simultaneamente medida que passam pelo dispositivo de leitura. 10

Para alm disso, os dados podem ser escritos numa etiqueta RFID, uma caracterstica que no possvel no cdigo de barras. Esta caracterstica tem muitas implicaes nos sistemas de informao e nos potenciais benefcios do sistema RFID. Note-se ainda que o cdigo de barras apresenta um UPC, nmero que identifica um tipo de produtos, enquanto que o sistema RFID consegue identificar uma unidade de produto, suportado pelo EPC. No entanto, nem s vantagens tm os RFIDs portanto, neste momento, o seu custo implica um preo bastante acima do apresentado pelo cdigo de barras. Mas verifica-se uma tendncia para decrescer cada vez mais. Associando esta tendncia s vantagens enunciadas anteriormente, natural que se verifique uma gradual transio do cdigo de barras para os RFIDs nas cadeias logsticas [13].

2.1.4 Processo de seguimento

Em geral, o processo de seguimento descrito anteriormente o que se utiliza na cadeia logstica. A topologia da rede, descrita em 2.1.1 e 2.1.2, hub & spoke, exibe uma distribuio com vrios pontos intermdios de maneira a optimizar o processo de distribuio. As tecnologias utilizadas no seguimento dos objectos sero cdigos de barras ou etiquetas RFID, como descrito na seco 2.1.3, que em nada diferenciam a forma como o processo de seguimento efectuado, a no ser todas a vantagens inerentes aos RFID referidas em 2.1.3.3. O seguimento de itens uma parte integral de um servio de distribuio, que permite a um cliente seguir os bens que pediu para entregar ou que ir receber. A figura 7 exemplifica como o processo se efectua. O aparecimento da Internet permitiu que os distribuidores comerciais, como a UPS, FedEx ou DHL, tornem possvel o seguimento on-line (na figura com o nmero 218) dos carregamentos. Num processo convencional de seguimento, durante a distribuio de um item tudo comea no primeiro posto de entrega (52), onde o cliente se dirige. A comea-se por registar o nome e a morada do emissor e do receptor, que podem ser pessoas ou entidades, o tipo e a classe da entrega, e outra informao adicional considerada relevante, sendo-lhe ento associado um nmero de seguimento. Esta informao ser registada no sistema e ficar guardada numa base de dados central (208) para se poder aceder aos dados, podendo essa informao ser vista por clientes, terceiros, bem como para uso interno (216). De seguida, associa-se uma etiqueta caixa ou item a ser transportado, a qual est associada ao nmero de seguimento do item e que pode ser um cdigo de barras ou um RFID. O nmero de seguimento lido atravs da etiqueta por um leitor (60) e transmitido (72) ao sistema central, para que este registe onde se encontra o item, sendo tambm registada a hora da leitura. Assim, qualquer entidade autorizada tem disponvel o local onde se verificou a ltima leitura do item e as horas a que foi realizada. O item depois recolhido no local do registo inicial (52) pela transportadora, para se proceder sua entrega. Em cada n ou ponto intermdio (80, 100, 110), os itens so lidos novamente quando entram e/ou saem e essa informao passa igualmente para o sistema central (208). Os 11

itens so tambm ordenados e reenviados de acordo com o local a enviar, podendo ser atravs de comboio, camioneta ou avio. Este processo repetir-se- at que se chegue ao destino final (120). No fim restar apenas encaminhar o item para o receptor (210). Naturalmente, durante todo este processo, a etiqueta vai sendo lida para se poder fazer um acompanhamento do item [14, 15, 16, 17].

Figura 7 Estrutura da rede de distribuio de uma cadeia de logstica [14].

2.1.5 Seguimento baseado em eventos

Geralmente os sistemas de seguimento tradicionais descrevem-se como sendo baseados em eventos, no sentido que a localizao de um item registada pela leitura da etiqueta associada ao item, seja essa etiqueta um cdigo de barras ou RFID. Se tivermos em conta a previsibilidade e a consistncia que estes eventos tm para o transportador, pode-se fornecer informao adicional com vista a aumentar a visibilidade. Por exemplo, quando um item que transportado no for recebido ou lido num local onde deveria passar durante o processo de entrega, pode ser gerado um alerta. ainda possvel efectuar uma previso temporal de quando um item ir chegar aos pontos intermdios e ao destino, de modo a monitorizar se os itens esto a chegar de acordo com o intervalo de tempo definido para os vrios locais da cadeia de distribuio [18]. Para se satisfazer esta necessidade necessrio escolher uma rota preferencial e rotas alternativas, para facilitar o reenvio do respectivo item, por exemplo, no caso de um ponto intermdio da cadeia de distribuio estar lotado. Tambm so calculados os tempos esperados de chegada a cada n da rede [18]. Se durante o transporte, entre o emissor e o receptor, o item for recebido e lido numa localizao esperada dentro de um intervalo de tempo previsto, ento o item ser considerado como estanto em trnsito normal, ou seja no estado verde. Se o item for recebido num local esperado mas fora do intervalo de tempo previsto, geralmente depois do tempo estimado, ento ser lanado um alerta amarelo. Se o item nunca for recebido na localizao esperada, quer seja ela da rota 12

principal ou secundria, ento um alerta vermelho ser lanado, podendo produzir uma procura do item ao longo da rede. Toda esta informao ser comunicada ao sistema central, tal como se indicou em 2.1.4. Assim, qualquer utilizador autorizado tem acesso ao estado da sua encomenda, porque no s disponibilizada informao dos eventos ocorridos e das suas respectivas localizaes mas tambm se fornece a indicao de que um item est na sua rota prdeterminada e vai dentro do intervalo de tempo considerado razovel. Este processo baseado em eventos est tambm descrito no fluxograma apresentado na figura 8 [18].

Figura 8 Fluxograma do processo de seguimento por eventos [18].

2.2 Rede de clulas

A rede de clulas uma rede de difuso de rdio, feita por um determinado nmero de clulas de rdio, cada uma das quais servida por um transmissor fixo, conhecido como estao base. Cada uma destas clulas usada para cobrir diferentes reas, para que conjuntamente possam fornecer cobertura rdio sobre uma grande rea. As redes de clulas tm associado um conjunto de transmissores principais e um conjunto de transmissores distribudos, que fornecem os servios aos utilizadores [19]. Como exemplo das redes de clulas temos a rede GSM, que o standard mais popular no mundo inteiro, estando descrita a sua estrutura na figura 8 [20].

Figura 9 Estrutura da rede GSM [20].

13

A rede apresentada na figura 9 divide-se em trs partes [21]: As Estaes Mveis (MS, Mobile Station ) so constitudas pelo equipamento mvel (ME, Mobile Equipment) e um carto inteligente denominado mdulo de identidade do subscritor (SIM, Subscriber Identity Module) [22]. O Subsistema da Estao Base (BSS, Base Station Subsystem) a seco da tradicional rede de telefone por clulas responsvel por lidar com o trfego e o sinal entre o telefone mvel e o NSS. O BSS realiza a traduo dos canais de voz, a locao dos canais de rdio para os telefones mveis, gesto da qualidade da transmisso e recepo com interfaces areas e muitas outras tarefas relacionadas com a rede de rdio [23]. O Subsistema de Comutao de Rede (NSS, Network and Switching Subsystem) a parte da rede que se aproxima da rede fixa, sendo s vezes chamada rede central. Realiza as funes de comutao e gere a comunicao entre os telefones mveis e a rede pblica de telefonia comutada. propriedade dos operadores de telefones mveis e permite a comunicao com outros telefones numa grande rede de telecomunicaes. A arquitectura faz lembrar uma central telefnica, mas tem funes adicionais, que so necessrias devido ao facto de os telefones no se encontrarem fixos a uma localizao. Por isso, tem que se ter em conta a gesto da mobilidade, a qual ser descrita em pormenor em 2.2.3 e 2.2.4 [23].

2.2.1 Subsistema da estao base

Na BSS encontram-se descritos dois elementos fundamentais: As estaes base (BTS, Base Transceiver Station) contm o equipamento para transmitir e receber sinais de rdio, transmissores, antenas e equipamento para encriptar e descriptar as comunicaes com a BSC. Cada BTS controlada por uma BSC, sendo a partir delas que se faz a ligao aos telefones mveis [23, 24]. Os controladores da estao base (BSC, Base Station Controller) significam a inteligncia por detrs das BTS. Normalmente, tm sua responsabilidade vrias BTS, funcionando como um seu concentrador e onde se faz a ponte entre as BTSs e as centralizadas MSCs. Controlam a transferncia dos telefones mveis de BTS para BTS, isto , monitorizam a passagem dos telefones de uma clula para outra, dentro da sua rea de jurisdio, sabendo-se assim em que rea (BTS) se encontra o telefone [23, 24].

2.2.2 Subsistema de comutao de rede

Na NSS encontram-se cinco elementos chave: A central de comutao mvel (MSC, Mobile Switching Center) uma sofisticada central telefnica, que constitui o elemento central da NSS e do processo de roaming. responsvel pela comutao das chamadas dos utilizadores e pelas funcionalidades de

14

gesto da mobilidade e outros servios dentro da sua rea de jurisdio. O encaminhamento das chamadas dos subscritores na rede GSM realiza-se pela MSC com o auxlio dos registos HLR e VLR. Permite ainda efectuar a ligao com a rede fsica, pois representa o elo de ligao entre o BSS e o NSS [25]. HLR, Home Location Register, uma base de dados central, existindo uma para cada operador. Contm detalhes de cada subscritor de um telefone mvel, que est autorizado a utilizar a rede. Esses detalhes sero os dados do carto SIM lanado pelo operador de telefone mvel, que tem um identificador nico, o IMSI, representando a chave primria para aceder aos registos no HLR e o MSISDN, que o nmero de telefone usado para fazer e receber chamadas. Outro dado guardado na base de dados ser a localizao actual do dispositivo, ou seja, a VLR actual [23, 26]. VLR, Visitor Location Register, uma base de dados temporria dos subscritores que se encontram, de momento, na rea que esta serve. Cada estao central na rede servida por uma VLR. Logo, um utilizador no pode estar presente em mais do que uma VLR em cada instante. As funes principais da VLR so informar o HLR que um determinado subscritor entrou na sua zona [24, 26]. O registo de autenticao (AUC, Authentication Center) fornece informao de segurana rede, tipicamente quando o telefone mvel for ligado. uma base de dados que armazena uma cpia do cdigo secreto contido em cada carto SIM da rede, sendo utilizado para autenticao dos subscritores e encriptao dos dados [27]. A identidade do equipamento (EIR, Equipment Identity Register) contm uma lista de todas as estaes mveis existentes, atravs do seu nmero IMEI. usado por razes de segurana, como complemento da operao de autenticao do SIM, onde se verifica se o dispositivo mvel ME tem um nmero vlido. Pode ainda efectuar-se a monitorizao deste dispositivo por suspeitas sobre o seu utilizador, ou pode-se impedir a utilizao do dispositivo devido ao aparelho ter sido roubado [28]. Depois de descrita, de uma maneira geral, a estrutura de rede e os seus principais elementos, passa-se descrio do funcionamento da mobilidade geral, nas duas seces seguintes.

2.2.3 Gesto da mobilidade

O objectivo da gesto da mobilidade efectuar o seguimento de onde os subscritores esto, para que as chamadas, SMS e outros servios possam ser efectuados onde quer que estes se encontrem, permitindo que os telemveis funcionem fora da sua rede principal. No GSM podem existir quatro diferentes tipos de handoff , referentes transferncia das chamadas entre as seguintes entidades:
1

Handoff refers to the process of transferring an ongoing call or data session from one channel connected to the core network to another. 15

1. Canais numa mesma clula. 2. Clulas sob o controlo de um mesmo controlador de estao base (BSC). 3. Clulas sob o controlo de BSCs diferentes, porm, associados a uma mesma central de comutao mvel (MSC). 4. Associadas a diferentes MSCs. O primeiro e o segundo caso so tratados dentro do BSS, pois este responsvel por controlar as transferncias dentro das BTS e entre BTSs. Os dois casos seguintes j envolvem a interveno da MSC, pois j se trata de transferncias dos dispositivos entre BSS e entre MSC, respectivamente. Consegue-se a localizao dos dispositivos porque as BSS difundem a identidade das clulas, em certos intervalos de tempo constantes, para a rede. Os dispositivos tm guardada a identidade da clula qual esto associados e ao mudarem de localizao recebero a identidade da nova clula. Ao se aperceberem da mudana de identidade, indicam ao BSS a sua nova localizao, que por sua vez enviada para MSC ao qual est ligado. A informao posteriormente enviada VLR que contacta a HLR (Fig. 10) para esta registar a nova localizao do subscritor. Por sua vez, a HLR pede antiga VLR do utilizador para apagar os registos temporrios que contm e responde VLR actual com uma cpia da informao do servio do subscritor [29]. Aquando do envio da identidade por parte das clulas, todos os dispositivos respondem independentemente de estes terem ou no mudado de localizao, pois a maneira da BSS conseguir monitorizar se os dispositivos se encontram realmente na rede, ou se, por exemplo, se desligaram sem conseguir avisar a rede. A diferena na resposta reside no facto de os aparelhos que mudaram de localizao enviarem BSS um pedido de alterao de localizao [29]. Os registos dos utilizadores na VLR so tambm alterados quando os dispositivos se ligam, chamando-se a este processo uma ligao IMSI , onde acrescentado um registo na VLR. Por sua vez, uma operao de desligar IMSI , quando os dispositivos so desligados, faz com que os registos temporrios na VLR sejam apagados [29].
3 2

2.2.4 Roaming
Roaming o termo geral nas telecomunicaes por rdio, que se refere extenso do servio de conectividade numa localizao diferente da sua localizao original, onde o servio est registado. O termo roaming definido como a capacidade de um cliente de redes mveis automaticamente fazer e receber chamadas, enviar e receber dados ou aceder a outro servios, incluindo os servios de dados da rede original, quando est a viajar fora da rea geogrfica que coberta pela sua rede originria, usando para tal a rede visitada. Isto pode ser feito usando um terminal de comunicao e a identidade de subscritor na rede visitada. O roaming tecnicamente suportado por procedimentos de gesto da mobilidade, autenticao, autorizao e facturao [30].
2 3

IMSI attach. IMSI detach.

16

Figura 10 Exemplo da comunicao entre duas redes. O processo de roaming genericamente o seguinte [31, 32]: 1. Quando o telemvel for ligado ou transferido para uma rede diferente da que se encontrava, ir procurar a BTS mais prxima com o intuito de se identificar. Se conseguir contactar alguma BTS, estamos perante um local com cobertura de rede. Cada rea geogrfica tem uma base de dados temporria, a VLR, como descrito anteriormente, na qual esto contidos detalhes de todos os telefones mveis que se encontram na rea actualmente. Quando a rede visitada v o aparelho, verifica que este no est registado no seu prprio sistema e tenta identificar a rede de origem do dispositivo. Se no existir um acordo para roaming entre as duas redes, a manuteno do servio revela-se impossvel, sendo este negado na rede visitada [33]. 2. Se existir acordo, a rede visitada contacta a rede de origem e efectua um pedido de requisio de informao de servio (incluindo se o telemvel pode ou no efectuar o roaming) acerca do dispositivo, usando para tal o nmero IMSI (Fig. 10). 3. Se tiver sucesso, a rede visitada comea por requisitar ao HLR do dispositivo uma cpia da informao que este tem disponvel sobre o aparelho do subscritor, a qual ser guardada temporariamente na VLR. Da mesma forma, a rede de origem actualiza a sua informao para indicar que o aparelho est na rede anfitri e por isso qualquer informao enviada para o aparelho poder ser correctamente encaminhada. 4. Durante o contacto com a rede de origem, o AUC contactado para se efectuar a autenticao do subscritor. A partir do momento em que um utilizador est ligado rede, encontra-se disponvel para efectuar e receber chamadas. Para efectuar uma chamada, o utilizador marca o nmero no seu dispositivo e um pedido de chamada enviado rede em que se encontra, atravs de uma BTS. O elemento da estrutura da rede que trata dos pedidos de envio de uma chamada a MSC. A MSC ir verificar se o utilizador tem privilgios para efectuar a chamada nos registos temporrios da VLR. Se assim for, a chamada ser encaminhada da mesma maneira que a central telefnica faria para a rede fixa.

17

Para receber uma chamada, o procedimento j mais complexo: Depois de se efectuar o procedimento acima descrito, a chamada encaminhada para a MSC de modo a ser identificada a localizao do receptor da chamada. Como foi dito anteriormente, um utilizador pode estar em qualquer parte da rede, e portanto o primeiro passo ser contactar a rede de origem do nmero receptor da chamada (Fig. 10), onde ser indicada a VLR a que o dispositivo a contactar est associado [34]. Assim sendo, quando o pedido chega ao HLR, verifica-se se o receptor est ligado a alguma VLR. Caso no esteja porque o telefone est desligado ou sem cobertura de rede e essa informao ser indicada ao emissor. Caso contrrio, o HLR sabe que o dispositivo est sob a jurisdio de uma determinada VLR e o seu endereo transmitido MSC (emissora) para que esta possa contactar a outra MSC (receptora). Desta maneira, ao chegar MSC do receptor, verifica-se nos registos da VLR qual a rea onde o dispositivo se encontra e atravs da BTS respectiva contactado o telefone mvel [34].

2.3 Sistema de posicionamento global

O GPS um sistema global de navegao por rdio, formado por uma constelao de satlites e por cinco estaes terrestres. Esta constelao de satlites transmite sinais precisos, permitindo ao receptor determinar a localizao, velocidade e direco de um objecto. O GPS usa estas estrelas construdas pelos humanos, como pontos de referncia para calcular as posies. O sistema de posicionamento global concretiza o nico sistema de navegao por satlite que est totalmente funcional. Outros sistemas similares so o russo GLONASS, o sistema de posicionamento Galileu, que um projecto europeu, bem como outras propostas da China e ndia. GPS um sistema de dupla utilizao para fins civis ou militares. Desenvolvido pelo departamento de defesa dos Estados Unidos da Amrica, foi a partir de 1983 que o presidente Ronald Reagen possibilitou o uso civil do GPS. Dependendo da qualidade do receptor, do ambiente, do tipo de medidas feitas e processamento, a exactido do posicionamento do GPS pode variar desde poucos metros at um centmetro, permitindo um grande alcance de aplicaes de posio desde veculos de navegao at estudos do movimento das placas tectnicas do planeta Terra [35].

2.3.1 Descrio tcnica

A Navastar Global Positioning System, ou GPS, consiste em trs componentes [36]: 1. Uma constelao de satlites, actualmente na quantidade de trinta, em rbita a cerca de 20 000 km acima da superfcie da Terra, com um perodo de 12 horas, permite que cada satlite d duas voltas Terra por dia. H seis planos de rbitas, com um espaamento de 60 cada uma e com inclinao de cerca de 55 em relao ao

18

plano equatorial. Esta constelao fornece entre cinco a oito satlites visveis para cada ponto da Terra, estando imune a qualquer tipo de adversidade temporal como a chuva, nevoeiro, neve ou tempestades de areia. Transmitem sinais em duas frequncias na parte das microondas do espectro de rdio [37]. 2. Um segmento de controlo controla os satlites de GPS, atravs de estaes de monitorizao terrestres e de aparelhos de actualizao. O controlo compreende cinco estaes, que operam como olhos e orelhas do GPS. A informao enviada pelos satlites capada pela estao de controlo principal, em Colorado Springs, e aqui que os parmetros que descrevem as rbitas dos satlites e o desempenho do relgio so estimados, bem como o estado de sade dos satlites para determinar a eventual necessidade de um reposicionamento. Esta informao depois devolvida para as outras estaes terrestres, que reencaminham a informao para os satlites [37]. 3. O receptor do utilizador, que pode ser civil ou militar. Os receptores GPS so apenas receptores pois s recebem os sinais dos satlites e no os transmitem. Este segmento responsvel por descodificar o sinal enviado pelos satlites com o intuito de determinar a posio, velocidade e tempo [37].

2.3.2 Mtodo de operao

Embora os receptores GPS sejam instrumentos sofisticados, o princpio usado para determinar a posio na Terra relativamente simples. Relgios exactos e o princpio da trilaterao so usados para medir a distncia entre o utilizador e a combinao de trs ou mais satlites [38]. As distncias entre os satlites e os receptores so medidas de acordo com o tempo necessrio para que os sinais de rdio transmitidos pelos satlites cheguem aos receptores. Os sistemas de GPS sincronizam os satlites com os receptores, para que gerem o mesmo cdigo no mesmo instante. Quando um receptor recebe um cdigo, sequncia de 0s e 1s enviada por um satlite, verifica h quanto tempo gerou um cdigo igual ao recebido. Comparando este instante com o instante actual, ter-se- a diferena temporal que ditar quanto tempo o sinal levou na viajem entre o satlite e o receptor. Multiplicando este tempo pela velocidade da luz, o receptor consegue determinar a distncia exacta entre a sua localizao e o satlite [38]. Assim sendo, com apenas um satlite, o receptor pode ser localizado algures na superfcie da Terra, na rea abrangida pelo satlite (Fig. 11 a, b). Usando dois satlites (Fig. 11 c, d), o receptor consegue limitar a sua localizao para um crculo, que representa a interseco de duas esferas. Uma terceira localizao de um satlite necessria para indicar a localizao em um de dois pontos (Fig. 11 e). Muitos receptores conseguem depois eliminar um desses dois pontos porque indicam locais muito distantes da superfcie terrestre (Fig. 11 f) [38]. No entanto, para obter uma posio exacta, o receptor GPS necessita de efectuar quatro medies, que sincronizem o seu relgio com os relgios dos satlites, a fim de se eliminarem os

19

erros de relgio. Um erro na casa dos milissegundos poder originar uma deslocalizao de perto de 200 milhas. Para prevenir erros na determinao dos tempos de viagem dos sinais, os satlites GPS esto equipados com relgios atmicos, que tm extrema exactido e so muito caros. No entanto, os relgios que esto nos receptores no so to exactos, sendo semelhantes aos relgios de quartzo. Para conseguir sincronizar o seu relgio com os relgios atmicos dos satlites, o receptor recolhe o sinal de um quarto satlite para verificar a sua correcta localizao. Estes quatro sinais tm de coincidir em apenas um ponto no espao. Neste caso, o relgio do receptor est alinhado com o dos satlites. Se os sinais no coincidirem num ponto, o receptor ter de calibrar o seu relgio para que tal acontea e nessa altura obtm a sua localizao correcta, alm de conseguir sincronizar o seu relgio com os dos satlites [38, 39]. A medio das distncias de quatro ou mais satlites simultaneamente, e sabendo a exacta localizao dos satlites, informao includa no sinal transmitido pelos satlites, permite que o receptor determine a sua latitude, longitude e altitude [38].

a)

b)

c)

d)

e) f) Figura 11 Exemplo do processo de trilaterao no GPS [39].

20

2.3.3 Sistemas de seguimento por GPS

Uma unidade de seguimento por GPS um dispositivo que usa o sistema de posicionamento global para determinar a localizao exacta de um veculo, pessoa ou outro bem ao qual est anexado, guardando a posio do bem num intervalo de tempo regular. A informao da localizao pode ser guardada dentro da unidade de seguimento, ou pode ser transmitida para uma base de dados central ou at atravs da Internet. Assim sendo, um seguidor de GPS possui normalmente trs subsistemas [40]: Data loggers: Um GPS logger anota simplesmente a posio de um dispositivo em intervalos de tempo regulares, na sua prpria memria interna. Podem tambm ser usados cartes de memria, memria flash interna ou ainda uma porta USB. Posteriormente, os dados podem ser retirados destes dispositivos para uma anlise pomenorizada. Um exemplo de utilizao o desporto, podendo depois ser verificado o trajecto da pessoa, quilmetros percorridos, etc. Data pushers: Este tipo de dispositivo usa-se na segurana industrial, onde a informao da posio do dispositivo enviada, em intervalos de tempo regulares, para um determinado servidor, que consegue analisar instantaneamente os dados. Alguns negcios usam esta tecnologia, para o controlo da sua frota. Como exemplo, uma empresa de distribuio coloca um dispositivo em cada um dos seus veculos, permitindo que se tenha conhecimento se o veculo est atrasado ou no e na rota desejada. Ainda se utiliza na pesquisa de veculos roubados, no controlo de animais, em espionagem e muitos outros casos. Data pullers: Ao contrrio do data pusher, que envia a posio do dispositivo em intervalos de tempo regulares, estes dispositivos esto sempre disponveis para que lhes seja requerida a sua localizao. No so normalmente utilizados, porque tm de estar associados a dispositivos conectados Internet.

2.4 Reflexo sobre o estado da arte

Ao longo do estado da arte, tentou-se fazer um paralelismo entre as necessidades emergentes associadas reconciliao de passageiros e bagagens no TSMART e o estudo efectuado para suportar essa reconciliao. A topologia da rede utilizada ao longo da viagem no controlada pelo TSMART, pois o passageiro escolhe a viagem que disponibilizada pelos operadores de transporte. A arquitectura proposta no captulo 4 segue o processo de seguimento logstico descrito em 2.1.5, baseado em eventos, que uma estenso do processo descrito em 2.1.4. Este processo permite registar por onde os itens passam e verificar se esto na rota correcta. Para o projecto TSMART, fica a faltar se os itens pertencentes a uma entidade/indivduo esto todos juntos

21

aquando da passagem por um leitor, sendo esta a melhoria proposta aos processos de seguimento existentes. Estudou-se a rede de clulas com o intuito de analisar a forma como o roaming efectuado. Um utilizador consegue falar na sua rede local e tem a possibilidade de utilizar uma rede vizinha para efectuar as suas operaes fora da rede me, desde que exista um pr-acordo entre as duas redes. Avaliar esta situao importante, pois na rede TSMART tambm existe a necessidade de integrao entre os diversos operadores, para que exista uma comunicao que possibilite a partilha de informao. O GPS foi a ltima abordagem estudada, que pressupe um modelo de negcio muito mais caro e com uma infra-estrutura fsica de grande escala pois faz uso de satlites, para fornecer a localizao de um item. Apesar de ser uma tecnologia que permite a localizao em tempo real, acaba por no ser vivel a sua utilizao, pois estamos muitas vezes a distinguir a localizao de itens dentro de infra-estruturas fsicas como aeroportos, onde o GPS no consegue distinguir a sua exacta localizao. Decidiu-se usar as tags no projecto apenas como um identificador e no como um repositrio de informao. Esta deciso baseou-se no facto das tags actualmente estarem ainda numa fase inicial de maturao e de serem usadas apenas como um identificador, o prprio nmero da tag, para se poder aceder informao que se encontra na base de dados. A outra hiptese seria a tag conter todos os dados, permitindo que os leitores lessem, escrevessem e apagassem os dados contidos na tag, mas foi deixada de parte com o intuito de efectuar uma proposta de sistema mais realista com a tecnologia actual. Relativamente ao cdigo de barras, em 2.1.3.3 esto descritas as vantagens que a tecnologia dos RFID tem em relao a esta. O nico problema seria o preo das tags mas dado que estas so reutilizadas no modelo de negcio, ou seja, a tag pode e deve ser usada em vrias viagens em instantes diferentes, no ser por isso que o sistema no ser vivel. Se as tags fossem para usar apenas numa viagem, o seu preo poderia pr em xeque a utilizao do sistema, visto que o seu preo elevado, em comparao com o cdigo de barras, poderia inviabilizar o negcio.

22

3 Descrio da Metodologia Usada

A metodologia usada parte de algumas frameworks e metodologias j usadas h alguns anos na representao dos sistemas das organizaes. Em 3.1 descrevem-se os fundamentos que esto por trs da framework apresentada em 3.2, que permite estruturar conceitos necessrios para modelar servios e uma metodologia (em 3.3) que indica um processo de definir os servios necessrios para que o negcio funcione da melhor maneira possvel, garantido o alinhamento entre os SI e os propsitos do negcio.

3.1 Fundamentos
Tomando como linhas orientadoras de representao das organizaes a framework de Zachman e a metodologia ASI de Steven H. Spewak, consegue-se uma descrio realista do enquadramento dos sistemas na organizao. Cada uma das arquitecturas referidas pela metodologia ASI podem ser devidamente explicitadas a diferentes nveis e com determinadas formas de arrumao se for usada a framework de Zachman.

Figura 12 Framework de Zachman [52].

23

3.1.1 Framework Zachman

A framework de Zachman, representada na figura 12, uma maneira muito comum de conceptualizao de como todas as arquitecturas especficas de uma organizao podem ser integradas numa imagem conjunta e inteligvel por todos os seus elementos. A framework definese como um modelo analtico ou um esquema de classificao que organiza representaes descritivas desdobradas em perspectivas e dimenses. No descreve um processo de implementao e independente de metodologias especficas [59]. Caracteriza-se por apresentar uma matriz de trinta clulas, em que as colunas representam as vrias vertentes (dimenses) pelas quais um sistema pode ser abordado e as linhas apresentam diferentes nveis (perspectivas) de detalhe para os diferentes intervenientes da organizao [52, 54]. A framework de Zachman extremamente flexvel e no so impostos mtodos para o seu preenchimento. A representao de cada clula livre, podendo ser usada qualquer notao, tendo no entanto que suportar o objectivo desta. Deve-se recordar que tem de ser coerente e percebido por todos os stakeholders para permitir que estes tenham uma viso global da organizao. O resultado da combinao de tais perspectivas com estas dimenses uma matriz suficientemente genrica para poder ser usada como repositrio das vrias descries da organizao, mas tambm suficientemente poderosa para evidenciar os seus desalinhamentos [62].

3.1.1.1 Descrio das linhas

As linhas representam as diferentes perspectivas sob as quais se pode observar a organizao. Partindo de uma viso de alto nvel da organizao, descrevem os componentes e entidades mais importantes para o negcio, at um nvel mais detalhado, por exemplo o hardware usado para suportar determinada actividade. mbito: O mbito representa a perspectiva de mais alto nvel, que pode ser percepcionada por exemplo por um responsvel pelo planeamento dentro da organizao. Apresenta as razes pelas quais a organizao existe e descreve a modelao do negcio, as suas finalidades e os componentes mais importantes. Modelo de Negcio: O modelo de negcio representa a perspectiva do dono da organizao, que pode ser visto como o utilizador ou cliente do modelo. Descreve os modelos de operao do negcio e quais as relaes existentes entre os seus componentes mais importantes, descritos na perspectiva anterior. Modelo de Sistema: O modelo de sistema representa a perspectiva de um designer, por exemplo, um arquitecto de software. Nesta linha descrevem-se os modelos lgicos das estruturas de suporte ao negcio e os sistemas usados.

24

Modelo Tecnolgico: O modelo tecnolgico representa a perspectiva de um responsvel pelo desenvolvimento. Descreve os modelos fsicos da organizao e as ferramentas que so usadas em todas as actividades. Representao Detalhada: A representao detalhada expressa a perspectiva de um subcontratado. Descreve a parte operacional. Como representa a viso mais detalhada da organizao, designada por fora de contexto, pois os componentes representados a este nvel no permitem ter uma viso global da organizao ou do seu negcio.

3.1.1.2 Descrio das colunas

A dimenso horizontal da framework descreve os tipos de abstraces que definem cada perspectiva. Estas abstraces so baseadas em questes colocadas pelas pessoas para descrever o que relevante num determinado acontecimento: porqu, o qu, como, onde, quando e quem. A dimenso o que (dados) refere-se informao que a organizao precisa de gerir, o como (funo) indica os processos e as actividades da organizao, o quem (pessoas) refere-se aos departamentos, pessoas, perfis e competncias da organizao, o quando (tempo) retrata os acontecimentos a que a organizao deve reagir, o porque (motivao) justifica a razo de cada elemento que constitui a organizao e finalmente o onde (rede) traduz os locais onde esses elementos residem. Por exemplo, ao nvel estratgico, o onde indica a cidade ou pas em que a organizao deve ser representada, enquanto que ao nvel do negcio, representa onde que a informao reside, os processos de negcio so concretizados, as pessoas trabalham, etc [62].

3.1.2 Arquitectura de Sistemas de Informao

Dada a sua vasta aceitao e devido aos casos de sucesso, a metodologia ASI proposta por Steven H. Speawk usada muito frequentemente na realizao de projectos. As etapas desta metodologia so normalmente representadas como um "bolo de noiva", tal como ilustrado na figura 13. Esta metodologia visa a definio de uma ASI devidamente enquadrada na realidade orgnica, de negcio e informtica da empresa, e um plano da sua implementao [49].

C o m oT ra b a lh a m o s O n d eE sta m o s O n d eQ u e re m o sC h e g a r C o m oC h e g a m o sl

Iniciao Modelo do Negcio Arquitectura de Informao Alinhamento Estratgico Arquitectura de Sistemas Plano de Implementao Tecnologias e Sistemas Correntes Arquitectura Tecnolgica

Figura 13 Arquitectura de sistemas de informao. Cada uma das camadas corresponde a um objectivo distinto, mas s a concretizao de todas as fases torna possvel obter os resultados necessrios coerncia e consistncia do projecto.

25

Iniciao: A fase de iniciao tem como objectivo clarificar o mbito do projecto, a metodologia, as ferramentas a utilizar, a estrutura da organizao e a equipa de projecto, onde se torna essencial a identificao de todas as entidades envolvidas e a identificao dos seus interlocutores. Levantamento dos Processos de Negcio: O objectivo desta fase fazer um levantamento dos processos de negcio da organizao compreendidos no mbito do projecto. Sero caracterizados em termos das suas dependncias e fontes de informao que utilizam e produzem. Alinhamento Estratgico: O objectivo da fase de alinhamento estratgico consiste em antever outras necessidades futuras das unidades organizacionais, consequentes da viso estratgia preconizada pela gesto de topo da organizao. Tecnologias e Sistemas Correntes: Na fase de tecnologias e sistemas correntes so recenseados os catlogos dos principais sistemas informticos da organizao e as respectivas tecnologias de informao que os suportam. Arquitectura de Informao: O objectivo da fase de arquitectura de informao identificar e estruturar a informao necessria concretizao do negcio da organizao. Arquitectura de Aplicaes: A fase de arquitectura de aplicaes consiste em definir o conjunto de sistemas que permite suportar os processos de negcio de modo optimizado, bem como promover uma gesto eficaz da informao, evitando-se assim a sua replicao e incoerncia. Arquitectura Tecnolgica: A fase de arquitectura tecnolgica define as plataformas tecnolgicas necessrias para suportar os sistemas propostos na arquitectura de aplicaes. As valncias a abordar nesta arquitectura incluem, entre outros artefactos, os sistemas a implementar para operacionalizar a arquitectura de aplicaes, recursos e servios de rede, sistemas operativos, servios de produtividade pessoal, servios de Intranet e Internet, computadores, infra-estrutura de armazenamento de dados, segurana, infra-estrutura de desenvolvimento de aplicaes, infra-estrutura de suporte a deciso. Plano de Migrao e Implementao: O objectivo da fase do plano de migrao e implementao concretiza a identificao das iniciativas necessrias implementao do projecto. Estas iniciativas so do mbito tecnolgico, do mbito organizacional e humano e do mbito da gesto e qualidade do projecto.

3.2 Framework BPB-SOA

A prtica para identificar servios adoptada at agora tem sido de uma postura bottom-up. Numa primeira fase comea-se por criar servios elementares volta das aplicaes existentes. Numa segunda fase, agrega-se esses servios elementares em servios mais complexos. Contudo esta prtica leva a alguns problemas: 26 Proliferao de servios.

Ignora a dependncia entre as aplicaes que sustentam cada servio. No estabelece regras nem orientaes para a implementao de novas aplicaes. Ignora por completo o alinhamento da informao com o negcio e com as aplicaes.

Esta prtica apenas permite definir um conjunto de servios, que fazem sentido com o conjunto de aplicaes existentes na organizao [53]. A framework BPB-SOA, proposta pela Link no mbito do projecto de investigao FEABS, permite definir o universo de discurso das arquitecturas orientadas a servios, com a identificao de servios baseada em processos de negcio [51]. Ao contrrio da prtica que tem sido habitual, esta framework segue uma abordagem top-down.

Figura 14 Framework BPB-SOA [51].

3.2.1 Business Solutions

Nesta camada esto os servios que implementam os processos de negcio da organizao. com estes sistemas que o utilizador interage e nestes que est a lgica do negcio, detalhada num conjunto de actividades automticas ou semi-automticas. Os servios definidos nas Business Solutions implementam processos de negcio e contm [53]: Regras especficas. Actividades com interaco humana. Chamadas s transaces de negcio definidas na camada Business Services.

3.2.2 Business Services

Quando nas Business Solutions ocorrem algumas actividades que se repetem ou podem vir a repetir, usam-se critrios ou heursticas para isolar essas actividades em servios, ou Business Services, os quais podem ser invocados pelo prprio sistema ou por outro que pretenda reutilizar essas actividades de processo de negcio. Um tipo especfico de Business Services representado pelos Information Services, responsveis pela gesto do ciclo de vida da informao. Os Business Services implementam transaces de negcio, contendo [53]: Sequncias de actividades automticas com elevado padro de reutilizao. Chamadas a funes elementares de negcio.

27

3.2.3 Information Services

Alguns Business Services visam exclusivamente o tratamento de informao, seja a criao, actualizao, leitura ou eliminao. Os Information Services correspondem a um tipo de servio herdado do tipo Business Service, mas cuja funo precisamente garantir a gesto e coerncia da informao de negcio. Ou seja, so responsveis por concretizar a arquitectura de informao e esconder toda a complexidade inerente gesto da informao, funcionando assim como uma camada de abstraco.

3.2.4 Business Infra-structure Services

Os Business Infra-structure Services constituem todos os servios nativos que os SI providenciam para outros SI. Por servios nativos entendem-se todos os servios que no foram desenvolvidos especificamente para dar suporte aos processos de negcio da organizao em causa. So servios genricos que podem ser reutilizados pelas Business Services da organizao, estes sim, especficos do negcio.

3.3 Metodologia SOP

A metodologia SOP, Service on Process, uma metodologia que se encontrava em investigao durante a realizao do presente projecto. A figura 15 descreve a relao existente entre as arquitecturas empresariais e a metodologia SOP.

Figura 15 Relao entre a arquitectura empresarial e a metodologia SOP. As vrias arquitecturas constituintes da arquitectura empresarial so [50]: Negcio: estruturao das actividades, processos, actores, unidades, , da organizao. Informao: estruturao da informao necessria s actividades e processos da organizao. Aplicaes: sistemas de informao que, simultaneamente, permitem a automao dos processos e a gesto da informao da organizao. 28 Tecnolgica: tecnologia adequada a cada aplicao/sistema.

A metodologia SOP visa encontrar servios e portanto ser vista como um sub-conjunto das AE. A metodologia pretende que, a partir da execuo da arquitectura empresarial, se possa estender essa arquitectura, criando uma arquitectura de servios que d resposta a novas abordagens entre o negcio e a tecnologia. O crculo verde existente na figura 15 demonstra as vrias arquitecturas consideradas na metodologia. Os rectngulos a roxo so o sumo que se obter da aplicao da metodologia SOP, explicitado na framework BPB-SOA.

Figura 16 Metodologia SOP [51]. A figura 16 ilustra as fases que constituem a metodologia descrita nas seces seguintes [51]. A relao existente entre e metodologia ASI e a metodologia SOP fica patente nesta figura, porque para se obter as Business Solutions tem de se produzir um conjunto de artefactos que so obtidos com a realizao de uma ASI. Na figura 15 tambm se refere essa relao, visto que a metodologia SOP envolve um conjunto de arquitecturas que so partes constituintes da metodologia ASI.

3.3.1 Identificao das Business Solutions

Em primeiro lugar, devem ser catalogados todos os processos de negcio e descrito o objectivo de cada um. De seguida, catalogam-se todas as entidades informacionais e descreve-se o seu objectivo, identificando tambm o cdigo que torna as instncias nicas. Com base no catlogo de processos de negcio e no catlogo de entidades informacionais, obtidos anteriormente, constri-se a matriz CRUD. Atravs da sua manipulao e anlise identificam-se os blocos de funes as Business Solutions. Deste modo obtm-se um catlogo de Business Solutions, onde se indica para cada uma qual o seu cdigo identificador, nome, funcionalidades suportadas e eventuais integraes com outros blocos funcionais. Cada Business Solution suporta um conjunto de processos de negcio que manipulam determinadas entidades informacionais. Cada um destes blocos funcionais incorpora interfaces humano-mquina e regras de negcio, tendo como funo gerir tanto os servios que sustentam os processos como aqueles que sustentam a informao. Para terminar esta primeira fase da metodologia necessrio proceder ao desenho dos processos de negcio catalogados recorrendo a uma notao grfica, como por exemplo BPMN. So estas representaes grficas que iro permitir posteriormente a identificao dos servios [51]. 29

3.3.2 Identificao dos Business Services

O procedimento realizado para identificar os Business Services consiste em percorrer todas as Business Solutions catalogadas e, para cada uma, aplicar um conjunto de heursticas ou critrios de descoberta aos processos por esta suportados. As actividades identificadas ou sugeridas em cada um desses processos passam a constituir candidatos a Business Services, os quais ficam agregados Business Solution em questo. As heursticas correspondem a critrios de descoberta que identificam padres no desenho de processos. A metodologia SOP define dois tipos de heursticas, as aplicveis a uma actividade isolada (Heursticas Tipo A) e as aplicveis a grupos de actividades (Heursticas Tipo B) [51]. Heursticas A Uma actividade de um processo candidata a Business Service se obedecer a uma ou mais das seguintes heursticas: 1. Actividade com N ou mais entradas (N > # entradas absorvncia. 2. Actividade com N ou mais sadas (N > # sadas mdias) Critrio da Centralidade. 3. Actividade que se repete N ou mais vezes no processo (N > 1) Critrio da reutilizao. 4. Actividade utilizada em mltiplos caminhos do diagrama Critrio da Importncia. 5. Actividade que contenha detalhe, i.e., que represente um sub-processo. 6. Actividade com apenas uma entrada e uma sada que se relacionem com uma mesma actividade. 7. Actividade com N ou mais entradas, seguida de uma actividade com N ou mais sadas. Heursticas B Um conjunto de actividades de um processo dever ser encapsulado num Business Service se obedecer a uma ou mais das seguintes heursticas: 1. Grupo de actividades que se repete N ou mais vezes no processo (N > 1) Critrio da Reutilizao. 2. Grupo de actividades utilizado em mltiplos caminhos do diagrama Critrio da importncia. 3. Grupo de actividades em que uma actividade com N ou mais entradas seguida por mltiplas actividades com uma entrada e uma sada e depois por uma ultima actividade com os mesmas N sadas. 4. Grupo de actividades em que uma actividade s tem uma sada e as actividades seguintes tm tambm s uma sada. mdias) Critrio da

30

3.3.2.1 Information Services

A identificao dos Information Services feita directamente a partir da matriz de CRUD, atravs da verificao das aces realizadas sobre a informao e que se encontram assinaladas nas respectivas clulas da matriz (Create, Read, Update e Delete). Os servios identificados ficaro agregados Business Solution responsvel pela gesto da entidade informacional em questo [51].

3.3.3 Identificao dos Business Infra-structure Services

Em primeiro lugar, necessrio identificar as aplicaes que podero suportar os Business Services. Na organizao em causa poder existir j um conjunto de aplicaes que fornecem servios passveis de ser reutilizados. Neste momento, deve ser feito o levantamento dessas aplicaes e descritos os servios fornecidos. Em segundo lugar, torna-se necessrio inter-relacionar os servios entre si. Os vrios servios podem interagir uns com os outros, sendo absolutamente necessrio poder modelar a dependncia mtua. Toda esta fase focada na descoberta de servios tecnolgicos que j existem ou que podem ser desenvolvidos medida ser para dar suporte aos servios encontrados nas fases anteriores da metodologia. Por isso, o que se pretende obter nesta fase o cadastro dos servios tecnolgicos que existem ou que tero de ser desenvolvidos [51].

31

4 Arquitectura Proposta
Nos captulos anteriores tivemos uma descrio do problema a resolver, dos objectivos do trabalho, acerca do estado da arte sobre o seguimento de itens e a metodologia que se segue para efectuar uma arquitectura SOA. No fcil consolidar conhecimentos numa viso nica da organizao, integrando aspectos como a estratgia, as estruturas hierrquicas e organizacionais, os colaboradores, as suas competncias e os seus objectivos, os processos e a informao de negcio, os sistemas e as tecnologias de informao, entre outros. Assim sendo, ao longo deste captulo vai sendo feita uma inter-ligao entre as vrias seces constituintes da arquitectura proposta e a framework de Zachman. Pretende-se descrever em cada seco que clulas esto a ser representadas materializando essa relao [58]. Uma imagem global da relao pode ser visualizada no anexo B. Antes de comear a realizar a arquitectura, importante descrever os passos da metodologia ASI que foram usados para a sua realizao. As fases mais exploradas so o levantamento dos processos de negcio, a arquitectura de informao, a arquitectura de aplicaes e a arquitectura tecnolgica. As restantes fases no foram representadas porque esto fora do contexto da tese. Por fim, refere-se que o captulo se inicia com uma breve anlise dos vrios problemas que podero ocorrer aos passageiros e bagagens numa viagem multimodal, tendo em conta o estado da arte, anlise essa que estar na base da descrio de todas as arquitecturas seguintes.

4.1 Anlise do problema

importante realar que o sistema pretende reconciliar passageiros e bagagens e permitir agilizar processos para o tratamento de erros comuns na cadeia de transporte, tal como a perda, atraso ou reenvio de bagagens. Partindo destes pressupostos necessrio que existia uma forma de integrar operadores, tal como gestores de aeroportos, com a plataforma de reconciliao. Essa integrao feita atravs de um contracto, acordado entre uma entidade reguladora TSMART e o prprio operador, que pressupe que os operadores disponibilizem aquando do seu registo, informao sobre os locais onde operam e as viagens que tm disponveis a partir dos mesmos. Esse contracto pode ser actualizado a qualquer momento permitindo plataforma ter conhecimento de novos locais de operao e novas possibilidades de

32

troos. O operador fica responsvel por colocar os leitores de RFID nas zonas onde opera e assim a infra-estrutura fsica ficar pronta a operar. De referir que no se pretende que procedimentos como a venda de bilhetes para uma viagem sejam feitos pela TSMART, substituindo as companhias de transporte ou agncias de viagem nesse particular. A utilizao do sistema despoletada pelos passageiros, por questes de tica relacionada com os RFID e porque estes que podero indicar os vrios troos que compem a sua viagem, muitas vezes de entidades transportadoras diferentes. Assim sendo, um passageiro poder dirigir-se a uma agncia de viagens, escolhendo uma viagem que ser posteriormente registada no sistema. Outra opo ser o cliente efectuar um registo no sistema para poder aceder a um conjunto de funcionalidades, como registar viagens previamente compradas, associar passageiros a viagens, controlar o estado das suas bagagens, etc.

Figura 17 Exemplo de uma viagem multimodal. A figura 17 ilustra um exemplo de viagem multimodal. O cliente ou a agncia de viagens apenas tem que registar a viagem completa e os passageiros que a iro efectuar para que o sistema tenha conhecimento. No dia da viagem o passageiro dirige-se ao aeroporto (de Lisboa, neste caso) e efectua o checkin da viagem num balco. Nesta fase so identificadas as vrias tags dos passageiros. De referir a necessidade da existncia de trs tipo de tags: Tag identificadora do prprio passageiro, que poder ser colocada no seu bolso. Tags das bagagens de mo. Tags das bagagens que sero tratadas por terceiros, ou seja, as bagagens de poro.

Faz-se a distino entre bagagem de poro e bagagem de mo porque o transporte areo necessita dela, visto que as bagagens de poro so tratadas por entidades externas e no pelos prprios passageiros. O passageiro ter duas bagagens, uma de mo e outra de poro. A partir de um dado momento o passageiro segue o seu percurso normal de viagem, passando por diversos leitores, que estaro espalhados pelas instalaes dos operadores. Mostra-se importante referir a necessidade de trs tipos de leitores: 33

Leitores que apenas lem tags, registando a sua passagem no local. Leitores que registam a passagem de uma tag mas que efectuam a reconciliao entre os passageiros e a sua bagagem de mo. Este tipo de leitor importante nas instalaes de um aeroporto, pois o passageiro despende a maior parte do tempo nos aeroportos apenas com as suas bagagens de mo, estando a sua bagagem de poro a ser tratada por entidades externas. No entanto, o passageiro poder perder ou esquecer-se de algum item que esteja etiquetado e ser alertado disso quando atravessar um leitor deste tipo (Leitor parcial).

Leitores que registam a passagem de uma tag e que originam a reconciliao entre passageiros e todas as suas bagagens. Este ser o tipo de leitor mais usual, porque na generalidade dos tipos de transporte, excluindo o transporte areo, o passageiro responsvel pelas suas bagagens. Nos aeroportos este tipo de leitor poder fazer sentido, por exemplo, no final de uma viagem (Leitor total).

Sero agora descritos alguns exemplos dos problemas que podero acontecer nas bagagens durante uma viagem. O primeiro exemplo, na figura 18, descreve o caso da permanncia da bagagem de poro do passageiro no aeroporto de Lisboa aquando da partida para Madrid. Esta situao muito frequente e os operadores no se apercebem dessa situao atempadamente, que permitiria colocar a bagagem no avio antes da sua partida.

Figura 18 Bagagem permanece no aeroporto de partida. O segundo caso (Fig. 19) consiste no envio da bagagem do passageiro que vai de Lisboa para Madrid para outro aeroporto. Os operadores do aeroporto apercebem-se que a bagagem est possivelmente no local errado pois no foi reclamada. At podem verificar nas etiquetas o local de partida e de destino da mala, procedendo ao seu reenvio, com o devido atraso temporal que esta situao acarreta. No entanto, por vezes estas etiquetas so perdidas e os operadores ficam sem qualquer tipo de informao sobre as bagagens.

Figure 19 Bagagem encaminhada para o aeroporto errado.

34

Por outro lado, o passageiro chega a Madrid e depois de esperar pela sua bagagem que no vir, ir reclamar perante o operador da sua ausncia. Aqui a situao ainda mais critica pois no existe qualquer tipo de informao se a bagagem se encontra noutro tapete rolante, perdida nas infra-estruturas do aeroporto ou eventualmente noutro aeroporto, levando a grandes tempos de reenvio das bagagens que provocam insatisfao nos passageiros e gastos com indemnizaes nos operadores. O ltimo exemplo, apresentado na figura 20,

representa a situao da perda de um objecto que levado pelo passageiro na mo. Por exemplo, o passageiro pode-se esquecer de algo na zona de free shop, e quando se encaminha para a zona de embarque seria alertado dessa situao, podendo voltar atrs para recolher o item. Figure 20 Bagagem de mo perdida. Podero ocorrer outras situaes que gerem alertas, como a passagem de uma tag identificadora de bagagem sem a tag do seu passageiro num leitor total, situao que pode ocorrer quando um outro passageiro leva uma bagagem que no lhe pertence, quer por engano ou propositadamente. Outra funcionalidade desejada para o sistema a existncia de um controlo de posicionamento do passageiro numa infra-estrutura com o intuito de evitar atrasos. Por exemplo, quando faltarem quinze minutos para o incio do embarque, pode-se controlar se o passageiro se encontra na zona devida ou se est noutro local. Se for este o caso, ento pode-se lanar um aviso ao passageiro para ele se encaminhar para a zona de embarque.

4.1.1 Relao com a framework Zachman

Neste trabalho no se pretendia efectuar o planeamento de uma organizao, tendo sido usada a informao que consta na proposta de projecto TSMART para efectuar o levantamento dos conceitos mais relevantes para a organizao. Muitos desses conceitos esto descritos nesta seco e encaixam nas seguintes clulas: mbito X dados, listando as coisas mais importantes para o negcio; mbito X rede, indicando os locais onde o negcio realizado; mbito X pessoa, descrevendo as organizaes mais importantes para o negcio; por fim mbito X tempo, assinalando os eventos significativos para o negcio. Naturalmente, sendo esta uma fase de alto nvel, a relao que existe com a framework de Zachman na perspectiva do mbito, que est relacionada com quem planeia a gesto da organizao (Fig. 12).

35

4.2 Arquitectura organizacional

Apesar de se definir uma arquitectura organizacional, no constitua objectivo do projecto a definio de um modelo de negcio para uma organizao que fosse operar o sistema a implementar. Foi criado um cenrio de negcio, baseado na proposta de projecto TSMART, apenas com o intuito de enquadrar os processos numa arquitectura empresarial, sem nunca esquecer que o foco da tese no consiste em desenvolver uma arquitectural empresarial. O que se pretende com esta arquitectura apenas simular uma organizao que seja responsvel pelo sistema, com a inteno de enquadrar os processos de negcio que forem feitos e todas as restantes arquitecturas. Assim sendo, durante a realizao do projecto podem ser definidos os departamentos onde os processos so executados, quais os responsveis pelos blocos aplicacionais encontrados e quais os responsveis pelos servios sugeridos. Partindo deste pressuposto, a Arquitectura Organizacional do projecto constituda pelos seguintes componentes: Organigrama, Macro-Processos, Viso, Misso, Objectivos. Estes componentes esto descritos nas seces seguintes.

4.2.1 Organigrama
O organigrama apresentado na figura 21 descreve no s a estrutura departamental da empresa TSMART como tambm os correspondentes actores (stakeholders) internos identificados nesta fase.

Figura 21 Organigrama e stakeholders internos do TSMART. Para alm dos stakeholders internos devem ainda ser considerados quatro externos: operadores de transporte, agncias de viagens, clientes e passageiros. Os clientes so os utilizadores que interagem com o sistema TSMART para o registo de viagens, tal como as agncias de viagens. Os passageiros iro efectuar as viagens registadas no sistema. Os operadores tero os leitores instalados nas suas infra-estruturas e representam gestores de aeroportos ou de estaes de comboio.

36

4.2.2 Misso e Objectivos

A imagem seguinte apresenta o resumo dos meios e dos fins definidos pela administrao do TSMART no seu plano de negcios.

Means
Rec onciliar Passageiros e Bagagens numa viagem multimodal
* *

Ends
Promover nova forma de transporte de pas sageiros e bagagens
* *

* *

Mission

Efec tuar o seguimento dos itens na cadeia de transporte

Facilitar a integraao de operadores de trans porte

Reduzir problemas no tratamento das bagagens

Vision

Reduzir custos operacionais dos operadores

*

Expansao do Negcio
*

Strategy

Strategy

Implementaao de uma infraestrutura tecnologica de leitores de tags RFID

Implementaao de uma plataforma tecnologica

T a c ti c

Reduzir 30% das perdas /atrasos de bagagens

Goal

Reduzir 20% do tempo de reenvio de uma bagagem

Goal

10% dos passageiros Goal europeus usarem o sistema no primeiro ano

T actic

T acti c Promover o uso de tags RFID por parte dos passageiros e operadores

Objective

Objective

Melhorar em 30% gastos com pessoal devido a melhor alocaao de recursos

Objective

Objecti ve

Figura 22 Resumo dos meios e fins para o plano de negcio do TSMART. Com base na figura 22 procurou-se decompor os objectivos organizacionais em objectivos de uma menor granularidade, que se pudessem associar a pontos de controlo nos processos. Deste modo, ser possvel fazer a rastreabilidade do problema at origem.
Reduzir 30% das perdas/atrasos de bagagens Reduzir 20% do tempo de reenvio de uma bagagem 10% dos passageiros europeus usarem o sistema no primeiro ano Melhorar em 30% gastos com pessoal devido a melhor alocaao de recursos

Objective

Obj ec ti ve

Objective

Objective

Identific ar Clientes

Control ar atrasos nas bagagens

A umentar satisf ao dos clientes

Garantir Seguran a

Aval iar Ocorrenc ia Problemas

Garantir Presena Passageiros

Identific ar pontos de controlo

Es colher Nova Rota

Identific ar Operadores Fornecer viso global da viagem

Identific ar Rotas Opera o

Controlar Flux os no Operador

Evitar Alertas Desnec es srio s

Melhorar proc edimentos logs tic os

Identificar Tags

Reconc iliar Pass ageiros e Tags

Figure 23 Decomposio dos objectivos organizacionais.

4.2.3 Macro-Processos
Aps anlise de todo o contexto organizacional do TSMART, foram identificados os macroprocessos apresentados na figura seguinte.

TSM AR T

Gerir Inc identes

Gerir Comerc ial

Gerir Trans porte

Gerir Rede

Gerir P laneam ento

Figura 24 Macro-Processos.

37

4.2.4 Relao com a framework Zachman

Como foi referido anteriormente, esta seco foi produzida para enquadrar as restantes arquitecturas num contexto real. Mais uma vez, estamos a falar de conceitos de alto nvel que foram apreendidos pela leitura da proposta de projecto TSMART. So quatro as clulas preenchidas com a arquitectura organizacional: mbito X funo, com uma lista dos processos de alto nvel que a organizao executa (macro-processos); mbito X motivao e modelo negcio X motivao com uma descrio da misso, objectivos e estratgia do negcio; modelo negcio X pessoa, onde o organigrama do TSMART se encontra representado.

4.3 Arquitectura Processos

Uma arquitectura de processos uma estruturao que explicita os processos existentes e como que esto estruturados. Esta arquitectura usa-se para explicitar o modo como a organizao cria valor e de que maneira v, mede e gere a eficcia e a eficincia da criao de valor [57].

4.3.1 Decomposio funcional

Por cada processo de alto nvel, faz-se uma decomposio hierrquica, que descreve os subprocesso de cada processo de primeiro nvel.
TSMART

Gerir Incidentes

Gerir Comercial

Gerir Transporte

Gerir Rede

Gerir Planeamento

Gerir Alertas

Registar Clientes

Gerir Leituras

Gerir Operadores

Gerir Plano Viagem

Consultar Informao

Lanar Alertas

Validar Posicionam ento

Gerir Leitores Alterar Informaao Viagem Gerir Localizaes

Validar Partidas

Criar Plano Viagem

Prever Trfego

Estabelecer ligao com a rede

Alterar Plano Durante Viagem

Check-In Viagem Substituir Plano Viagem

Consultar Viagem Tag

Apagar Informao Viagem

Figura 25 Decomposio funcional dos processos de primeiro nvel.

38

Na tabela seguinte apresenta-se o catlogo dos processos TSMART: ID Processo

GI1 GI2 GC1 GT1 GT2 GT3 GT4 GT5 AN1 AN1 AN2 AN3 AN3 AN3 AN3 AN3

ID Processo Pai

Nome do Processo
Lanar Alertas Gerir Alertas Registar Cliente Prever Trfego Gerir Leituras Validar Partidas Validar Posicionamento Check-In Permite

Descrio
registar avisos quando ocorrem

problemas nas bagagens e/ou passageiros. Cria mecanismos para facilitar a resoluo avisos criados pelo sistema. Permite registar um novo cliente no sistema. Permite verificar quantos passageiros e bagagens so esperados no operador. Permite Reconciliar tags quando passam por leitores. Permite reconciliar tags de bagagens de poro antes da partida dos passageiros. Permite verificar se o passageiro se encontra no local certo momentos antes do embarque. Permite verificar se o passageiro marcou presena para a viagem e registar as tags dele. GT6 GR1 GR2 GR3 GR4 GP1 GP2 GPV1 GPV2 GPV3 AN3 AN4 AN4 AN4 AN4 AN5 AN5 GP1 GP1 GP1 Consultar Viagem Tag Gerir Operadores Gerir Leitores Gerir Localizaes Estabelecer ligao rede Gerir Plano Viagem Consultar Informao Criar Plano Viagem Alterar Informao Viagem Alterar Plano Durante Viagem GPV4 GPV5 GP1 GP1 Substituir Plano Viagem Apagar Informao Viagem Permite que um leitor porttil leia a viagem associada tag. Permite identificar quais os operadores pertencentes rede. Permite identificar quais os leitores que pertencem ao operador. Permite gerir os locais onde a rede opera. Permite efectuar a ligao fsica de leitores rede. Gesto de viagens multimodais. Permite ao cliente consultar informao de viagens e os seus alertas. Permite registar uma viagem no sistema com os seus troos e passageiros. Permite a um cliente alterar uma viagem no sistema previamente registada. Permite a um operador alterar a viagem do passageiro durante a sua realizao. Importante no caso de cancelamento de voos. Permite criar uma nova viagem para uma tag caso ocorra algum erro. Permite apagar uma viagem no sistema previamente registada.

Tabela 1 Catlogo dos processos de negcio.

39

4.3.2 Especificao de Processos

A especificao de processos consiste no modo como um processo transforma as entradas em sadas. Serve para assegurar uma maneira nica de fazer esse processamento e assim possibilitar a sua optimizao e automao. Existem diferentes conceitos que importa referir: processo, sub-processo, actividade ou tarefas. Em relao s actividades, que sero as caixas amarelas desenhadas nos diagramas representados nas figuras seguintes, consideram-se trs categorias: Manuais, quando so executadas por pessoas. Automticas, quando so ou podem ser executadas por mquinas. Semi-automticas, quando obrigam a uma interaco entre pessoas e mquinas.

Esta distino ser feita nos diagramas, aquando da sua especificao, pois cada actividade desenhada ter representado um smbolo (M), indicando que uma actividade manual, um (S) significando que a actividade semi-automtica, ou um (A), indicativo de que a actividade automtica. Os desenhos, efectuados em BPMN, encontram-se no Anexo A. Esta opo deve-se ao facto da especificao dos processos ter includo a representao grfica dos servios, apresentados no captulo da Arquitectura de Servios.

4.3.3 Objectivos, Actores e Processos

Os objectivos esto directamente relacionados com os processos da organizao. Estes processos so os meios pelos quais se atinge um determinado objectivo, pelo que a relao entre estes deve ser explcita. Na Framework de Zachman a relao entre os objectivos e os processos permite responder questo porque? (Fig. 26). Da mesma maneira os actores identificados anteriormente interligam-se com os processos, permitindo responder pergunta quem? (Fig. 27).

Figura 26 Matriz da relao entre processos e objectivos. 40

Figura 27 Matriz da relao entre processos e actores.

4.3.4 Relao com a framework Zachman

Na arquitectura de processos j estamos a falar da perspectiva do modelo de negcio da framework de Zachman. Cinco das clulas que envolvem esta perspectiva esto representadas nesta seco: modelo negcio X funo, onde esto especificados os processos de negcio da organizao, com as suas actividades constituintes e a hierarquia de processos; modelo negcio X rede, representada na especificao dos processos pela swimlanes que indicam onde que os processos se realizam; modelo negcio X pessoa, indicada na especificao dos processos de negcio quem que executa o processo; modelo negcio X tempo, pois os processos de negcio so despoletados por eventos representados na especificao dos processos; modelo negcio X motivao, descrita pela matriz de relao entre processos e objectivos.

4.4 Arquitectura informacional

A arquitectura de informao a estruturao das entidades informacionais necessrias prossecuo dos processos de negcio da organizao. Por outras palavras, uma AI define que entidades informacionais so necessrias e como se relacionam [56]. A identificao e definio das Entidades Informao tem por base a informao recolhida da fase anterior. As principais Entidades Informacionais que iro suportar toda a informao, considerada a necessria para gerir no Sistema de Informao dos TSMART, encontram-se sistematizadas na tabela seguinte.

41

ID E 01 E 02 E 03 E 04 E 05 Leitor

NOME Operador Cliente Passageiro Viagem

ID E 06 E 07 E 08 E 09 Troo Tag Local Aviso

NOME

Tabela 2 Entidades de Informao. Para cada Entidade, alm do seu identificador (ID), que identifica univocamente a entidade informacional, so apresentados os seguintes dados: Nome, nome pelo qual conhecida a entidade e reflecte a informao que a mesma segrega. Objectivo, qual o objectivo da entidade. Identificador, parte da informao segregada que caracteriza univocamente um conjunto de informao relevante para o sistema. Principais atributos, identificao da principal informao que ser segregada em cada uma das entidades e que se identifica atravs do seu identificador. Relao com outras entidades, evidenciado na matriz de relaes entre entidades. Processos que interactuam com a entidade, evidenciados na matriz de CRUD, no captulo Arquitectura de Aplicaes.

4.4.1 Entidades informacionais

ID Nome Objectivo Identificador Operador Identifica um operador que tem acesso para operar na rede. Contm o nmero de localizaes onde opera e pode registar leitores. N. Operador Nome Morada Tipo (Areo, Rodovirio, Martimo ou Ferrovirio) Contacto Lista Localizaes E 01

Principais Atributos

ID Nome Objectivo Identificador Principais Atributos Leitor

E 02

Identifica um leitor RFID de um operador que esteja a operar na rede para fazer leituras s tags. ID Leitor Local Tipo (Porttil ou fixo) Tipo Reconciliao (4 tipos)

42

ID Nome Objectivo Identificador Cliente

E 03

Identifica um indivduo/empresa que se regista no sistema, podendo a partir da reservar viagens e usufruir das funcionalidades do sistema. N. Cliente Nome Email Telefone Password

Principais Atributos

ID Nome Objectivo Identificador Passageiro

E 04

Identifica um indivduo que est registado como participante de uma viagem. Pode ser o prprio cliente ou outro indivduo que o cliente registou numa viagem. N. Passageiro Nome Identificao (BI ou Passaporte) Numero de telemvel Cliente Lista Tags Viagem Check-In

Principais Atributos

ID Nome Objectivo Identificador Principais Atributos Viagem

E 05

Representa uma viagem de um passageiro ou tag. A viagem constituda por um ou mais troos e pode englobar qualquer tipo de transporte (Areo, Rodovirio, Ferrovirio, Martimo). N. Viagem Lista troos (data) Lista de passageiros

ID Nome Objectivo Identificador Troo

E 06

Representa um caminho entre dois locais. Tem um local de origem e outro local de destino. ID Troo Local Partida Local Chegada Hora Partida Hora Chegada Operador Transporte

Principais Atributos

43

ID Nome Tag

E 07

Identifica uma etiqueta RFID que estar presente na bagagem de um passageiro ou no seu Objectivo prprio bolso. Permite seguir a localizao do passageiro e das suas bagagens ao longo da viagem. Identificador N EPC Passageiro Tipo (Bagagem Poro, Bagagem Mo ou Passageiro) Viagem Descrio da leitura anterior (Local, Leitor, Data, Hora)

Principais Atributos

ID Nome Objectivo Identificador Principais Atributos Local

E 08

Identifica um local onde se opera na rede. Pode ser um aeroporto ou uma estao de comboios de uma cidade, por exemplo. ID Local Nome Pas Cidade

ID Nome Objectivo Identificador Aviso

E 09

Identifica um incidente que tenha ocorrido com as bagagens de um passageiro. N. Aviso Passageiro Estado Tipo Tag

Principais Atributos

4.4.2 Matriz de relaes entre entidades

A matriz representada na figura 28 tem como objectivo evidenciar as interligaes que existem entre as entidades informacionais identificadas para o sistema. As interligaes identificadas apenas mostram que entre as entidades existe uma relao, no sendo identificado o seu tipo nem a sua cardinalidade.

44

Operador E01

E02

E03

Passageiro E04

E05

E06

E07

E08 2 4 Local 12 14

Viagem

Cliente

Troo

Leitor

E01 Operador 1 E02 Leitor 1 E03 Cliente E04 Passageiro 6 E05 Viagem 7 E06 Troo E07 Tag E08 Local E09 Aviso Figura 28 Matriz de relao entre entidades.

3 6 8 9 10 11 12 13 7 8 10 9 11

13 14

A tabela 3 apresenta a justificao das ligaes mencionadas na matriz anterior. Deve-se ter em considerao que a matriz simtrica, o que significa que s necessrio referir o par de ligao. So referenciados os nmeros colocados na matriz. N. 1 2 3 4 5 6 7 8 9 10 11 Ligao (Entidade/Entidade)
Operador Operador Leitor Leitor Leitor Cliente Cliente Passageiro Passageiro Viagem Viagem Leitor Local Tag Local Aviso Passageiro Viagem Viagem Tag Troo Tag

Justificao da Ligao
Operador regista Leitores para operar na sua rea. Operador tem localizaes onde exerce o transporte de passageiros. Leitor l tags RFID. O leitor est registado numa localizao. Avisos so originados num leitor. Cliente regista viagens para passageiros. Cliente regista planos de viagem. Passageiro est associado a uma determinada viagem. Passageiro tem um conjunto de tags, uma que o identifica e as restantes para identificao das suas bagagens. Uma viagem composta por um ou mais troos. Tag tem uma viagem quer ir fazer. A tag tambm tem de ter uma viagem associado pois nem sempre as tags e os passageiros iro juntos.

12 13 14

Troo Tag Local

Local Aviso Aviso

Um troo composto por dois locais, um de partida e outro de chegada. Avisos dizem respeito a uma tag. Aviso originado num local.

Tabela 3 Justificao das ligaes entre entidades.

45

Aviso

Tag

E09

4.4.3 Relao com a framework Zachman

A arquitectura de informao encontra-se representada na coluna dos dados, e pelas trs perspectivas de mais alto nvel. Assim sendo, as clulas representadas so: mbito X dados, com catlogo das entidades envolvidas; modelo negcio X dados, com a descrio das entidades informacionais e a sua relao com o negcio (seco 4.4.1); modelo sistema X dados, clula descrita pela relao existente entre as vrias entidades informacionais (seco 4.4.2).

4.5 Arquitectura de Aplicaes

A arquitectura de sistemas de informao de uma organizao a identificao dos seus sistemas de informao e das suas interdependncias. Nasce do cruzamento da arquitectura de processos com a arquitectura de informao. Um sistema de informao dever ser caracterizado por um nome que o identifique, a misso e os benefcios desse sistema, as funcionalidades do sistema, a informao que gere e as dependncias com outros sistemas. Para a definio desta arquitectura, o alinhamento existente entre o negcio e a TI crucial. Representa-se em trs dimenses na figura 29: Processos vs SI Foco na automao das actividades. Aplicaes vs Informao Foco na gesto das rplicas de informao residentes nos vrios SI. Processos vs Informao Foco na coerncia dos conceitos de negcio.

Figura 29 Alinhamento entre as vrias arquitecturas [55]. Como forma de garantir esse alinhamento, existem boas prticas, que se devem seguir na elaborao de uma ASI, as quais podem ser verificadas atravs da anlise da matriz de CRUD resultante. Essas regras tambm so aplicadas na metodologia SOP como forma de garantir o alinhamento entre Processos, Entidades e Business Solutions. As heursticas so as seguintes: H1 Todas as entidades informacionais so lidas e criadas, pelo menos, por um processo de negcio. H2 Uma entidade informacional no deve ser criada por mais do que um processo de negcio. H3 Todos os processos de negcio devem criar, actualizar, eliminar ou ler, pelo menos, uma entidade informacional. 46 H4 Cada processo de negcio deve ser suportado por uma nica aplicao. H5 Cada aplicao suporta, pelo menos, um processo de negcio. H6 Cada entidade informacional deve ser gerida apenas por uma aplicao.

4.5.1 Matriz de CRUD

A Matriz de CRUD tem como objectivo evidenciar a interaco que existe entre os processos de negcio e as entidades informacionais identificadas para o sistema. A elaborao da Matriz tem em considerao as aces que cada processo ir efectuar sobre as entidades, nomeadamente no que se refere a criar, ler, alterar e apagar [55]. Na figura 30 est representada a contextualizao que se consegue efectuar com a representao de uma matriz para a realizao de um SI. A partir da matriz de CRUD e seguindo boas prticas na sua realizao consegue-se encontrar manchas que identificam os SI, como representa a figura pela seta 1. A partir da anlise da matriz ainda se pode verificar que processos de negcio esto associados ao sistema (seta 3), evidenciando a sua funcionalidade, e que informao gerida pelo sistema (seta 2). As dependncias existentes entre sistemas (seta 4) so percepcionadas atravs dos vrios Reads ou Updates que um processo gerido por um sistema tem de fazer, considerando a informao gerida por outro sistema [55].

Figura 30 Contextualizao dos SI na matriz de CRUD [55]. Para construir a matriz de CRUD de aplicaes foi efectuado o seguinte procedimento: 1. Agrupamento dos processos com base na criao e manipulao de entidades comuns; 2. Aproximao das entidades criadas por cada grupo de processos agrupados no passo anterior (como um todo). A aproximao de processos, por um lado, e de entidades, por outro, resultou no aparecimento de zonas em que se destacava um grande conjunto de Cs, Rs e Us, dando origem a cada uma das aplicaes. O aparecimento de sobreposies e incongruncias entre sistemas foi evitado pois foram respeitadas as heursticas para a realizao da uma matriz CRUD.

47

Figura 31 Matriz de CRUD.

4.5.2 Descrio das aplicaes propostas

ID Nome Objectivo Descrio Apl01 Sistema de Gesto de Clientes Gerir a relao entre os clientes e a organizao

1. Armazena as informaes relativas aos

clientes

2. Permite consultar informao til para o

Processos Suportados Entidades Relacionadas cliente. Registar Cliente Consultar Informao Cliente: CRUD Passageiro: R Viagem: R Tag: R Aviso: R Troo: R

Tabela 4 Descrio da aplicao 1.

ID Nome Objectivo Descrio Apl02 Sistema de Gesto Viagens Dar suporte s actividades de planeamento de viagens. 1. 2. Processos Suportados Armazena as informaes relativas aos passageiros e viagens. Permite gerir o planeamento das viagens. Criar Plano Viagem Alterar Informao Viagem Alterar Plano Durante Viagem Apagar Informao Viagem Substituir Plano Viagem Cliente: R Passageiro: CRUD Tag: RU Viagem: CRUD Troo: R

Entidades Relacionadas

Tabela 5 Descrio da aplicao 2.

48

ID Nome Objectivo Descrio Processos Suportados

Apl03 Sistema de Gesto de Transporte Dar suporte s actividades de transporte de passageiros e bagagens. 1. 2. Armazena as informaes relativas s tags. Permite gerir a mobilidade das tags. Check-In Gerir Leituras Validar Partida Validar Posicionamento Prever Trfego Consultar Viagem da Tag Passageiro: R Tag: CRUD Viagem: R Leitor: R Troo: R

Entidades Relacionadas

Tabela 6 Descrio da aplicao 3.

ID Nome Objectivo Descrio Apl04 Sistema de Gesto de Incidentes Dar suporte aos alertas gerados pela gesto das tags. 1. 2. Armazena a informao relativa aos avisos. Permite gerir o tratamento de problemas nas tags. Lanar Alertas Gerir Alertas Tag: R Leitor: R Viagem: R Troo Aviso: CRUD

Processos Suportados Entidades Relacionadas

Tabela 7 Descrio da aplicao 4.

ID Nome Objectivo Descrio Apl05 Sistema de Gesto da Rede Dar suporte s actividades de infra-estrutura da rede. 1. 2. Processos Suportados Armazena as informaes relativas aos troos, operadores, leitores e locais . Permite gerir toda a infra-estrutura fsica de suporte reconciliao de passageiros e bagagens. Gerir Operadores Gerir Leitores Gerir Localizaes Estabelecer ligao rede Operador: CRUD Leitor: CRUD Local: CRUD Troo: CRUD

Entidades Relacionadas

Tabela 8 Descrio da aplicao 5. Na matriz representada na figura 32 cruzam-se os sistemas identificados com os responsveis pelos prprios sistemas. Esta relao importante porque cada servio identificado posteriormente e associado a uma Business Solution (Aplicao) ficar sob a responsabilidade do responsvel da prpria aplicao.

49

APL1

APL2

APL3

APL4

APL5

Gestor Dep. Operaes Gestor Dep. Planeamento Gestor Dep. Infra-estrutura Gestor Dep. Comercial Gestor Dep. Incidentes Figura 32 Identificao dos responsveis por cada aplicao.

4.5.3 Relao com a framework Zachman

A arquitectura de aplicaes suportada pela framework de Zachman em duas clulas: modelo sistema X funo, que representada por um modelo lgico de sistemas suportado pelos processos de negcio e informao, expressos pela matriz de CRUD; modelo sistema X pessoa, descritivo das responsabilidades que cada elemento da organizao tem com os sistemas da organizao.

4.6 Arquitectura Tecnolgica

Neste captulo pretende-se sugerir uma abordagem para a arquitectura tecnolgica do sistema TSMART. Alguns aspectos importantes para uma arquitectura tecnolgica, como a segurana e a disponibilidade, no so abordados na arquitectura. Na verdade, pretende-se apenas dar uma ideia como que a reconciliao de passageiros e bagagens passaria do papel para a prtica.

Figura 33 Arquitectura tecnolgica. A arquitectura tecnolgica descreve uma plataforma que seja totalmente distribuda, quer dizer, sem nenhum n global. Desta forma podemos respeitar requisitos de escalabilidade e a possibilidade de integrao de vrios operadores sem haver problemas de sobrecarga. A figura 33 descreve a arquitectura proposta. Cada entidade que escolha utilizar a plataforma TSMART ter um concentrador e alguns leitores de RFID associados. A comunicao dos leitores pode-se fazer atravs da rede ou sem fios, dependendo das necessidades do negcio. O conjunto de

50

concentradores forma uma confederao de sistemas que comunicam usando a tcnica peer-topeer (P2P), atravs de uma rede como a internet. Um concentrador, quando entra na rede, anuncia a sua chegada a todos os restantes, para que todos eles tenham conhecimento da sua presena. O sistema de cada concentrador mantm apenas a informao necessria para efectuar a reconciliao entre o passageiro e as suas bagagens. Essa informao ir deslocar-se de um concentrador para o prximo concentrador da viagem seguindo o movimento das tags. Esta abordagem ir permitir que a informao esteja onde realmente importante, rapidamente acessvel, e possibilita que cada concentrador guarde a menor quantidade de informao possvel. Uma procura adicional, baseada em P2P, permite obter informao no caso de uma tag, de um passageiro ou da bagagem, emergida num local diferente do que era esperado. Os leitores sero responsveis por ler as tags e enviar a informao para o servidor de RFID, que se encarrega de processar essa informao, disponibilizando-a ao servidor aplicacional. O sistema de leitura dever ter as necessrias interfaces humano-mquina, para permitir parametrizar os leitores consoantes as necessidades do TSMART. Tendo em conta que um dos requisitos do sistema a facilidade de integrao de novas funcionalidades, seguindo uma abordagem SOA, onde a necessidade de efectuar alteraes constante, a arquitectura a utilizar em cada aplicao dever ser de trs camadas. Camada de apresentao (Servidor WEB), mais prxima do utilizador e de mais alto nvel, camada de lgica (Servidor Aplicacional), que reflecte a lgica de negcio e a camada de dados (Servidor de Base de Dados), que o repositrio de informao.

4.6.1 Relao com a framework Zachman

A arquitectura tecnolgica representada na clula modelo tecnolgico X rede da framework de Zachman. A clula tem o mesmo nome desta seco. Logo, a relao perceptvel partida. No entanto, como se verifica na imagem no anexo B, apenas metade da clula est pintada. Isto deve-se ao facto da arquitectura tecnolgica descrita no ter um nvel de detalhe elevado, representando-se vrios componentes de hardware, ns e as suas ligaes, embora tenham ficado por representar diversos componentes, como os sistemas operativos, questes de segurana, etc.

4.7 Arquitectura de Servios

A Arquitectura de Servios um dos objectivos que se pretendia atingir desde o incio do projecto. Tal como referido no captulo 3, a metodologia SOP que se usa para chegar Arquitectura de Servios tinha em conta as vrias arquitecturas da Arquitectura Empresarial e que se descreveram no captulo 4: Arquitectura de Negcio, englobando a Arquitectura Organizacional e Arquitectura de Processos, a Arquitectura de Informao, a Arquitectura de

51

Aplicaes e Arquitectura Tecnolgica (Fig. 15). Para obter estas arquitecturas recorreu-se metodologia de Arquitectura de Sistemas de Informao, descrita em 3.1.2, existindo uma complementaridade das duas metodologias ASI e SOP, de modo a estender a arquitectura empresarial com uma arquitectura de Servios. Nesta arquitectura procede-se materializao da framework BPB-SOA, apresentada no captulo 3.2 e descrita nas seces seguintes.

4.7.1 Business Solutions

Todas as arquitecturas necessrias para a realizao da arquitectura SOA esto j explicitadas nos captulos anteriores. De acordo com a metodologia SOP, primeiro identificam-se as Business Solutions, catalogando os processos e as entidades informacionais, realizando a matriz de CRUD e o desenho dos processos de negcio. Dado que todos estes passos j foram feitos nas seces anteriores, a descoberta de Business Solutions torna-se clara. As Business Solutions, que contm os servios que implementam os processos de negcio, so as manchas encontradas como aplicaes na Arquitectura de Aplicaes, pelo que teremos cinco Business Solutions.

4.7.2 Business Services

Parte-se agora para a descoberta de Business Services. Tal como est descrito na figura 16, necessrio identificar padres de actividades ou sequncias de actividades que sejam reutilizadas nos diagramas. Optou-se por efectuar uma anlise funcional para a descoberta de servios e comparar esses mesmos servios com as heursticas propostas na metodologia SOP. Seguiram-se os passos descritos a seguir para a realizao da analise funcional: Seleccionar os sub-processos de mais baixo nvel (geralmente actividades). A ideia de no partir dos processos nesta fase justificada pela reutilizao. Verificar se so automatizveis. Entende-se por automatizvel uma actividade que possa no ter interveno humana. Descobrir padres de sequncias de actividades que se repitam em diversos diagramas ou conjuntos de actividades que no sendo reutilizados, possam vir a ser no futuro.

4.7.2.1 1 iterao
Na primeira iterao feito um levantamento das actividades e de seguida procede-se identificao de quais so automatizveis. Este trabalho j se encontra efectuado, porque na especificao dos processos as actividades tm descrito o seu tipo, manual (M), automtica (A) ou semi-automtica (S).

52

4.7.2.2 2 iterao
Importa referir que nesta seco estamos muitas vezes a lidar com actividades que representam Information Services e Infra-structure Services, ambos descritos mais adiante. Logo no ser considerada a sua reutilizao. A finalidade da sua descrio aqui consiste em agrup-los com outras actividades no sentido de encontrar padres de reutilizao, ou de potencial reutilizao. A tabela seguinte apresenta um resumo dos processos que contm actividades automticas e dessas actividades os padres que foram encontrados e originaram servios. Processo
Alterar Informao Viagem Alterar Informao Viagem Alterar Plano Durante Viagem Alterar Plano Durante Viagem Check-In Consultar Informao Consultar Informao Consultar Informao Consultar Informao Consultar Informao Viagem Consultar Viagem Tag Consultar Viagem Tag Consultar Viagem Tag Consultar Viagem Tag Criar Plano Viagem Criar Plano Viagem Estabelecer ligao com a rede Estabelecer ligao com a rede Gerir Alertas Gerir Alertas Gerir Alertas Gerir Alertas Gerir Leitores Gerir Leitores Gerir Leituras Gerir Leituras Gerir Leituras Gerir Leituras Gerir Leituras Gerir Localizaes Gerir Localizaes Gerir Operador

Actividade
Actualizar Viagem Actualizar Passageiro Actualizar Viagem Actualizar Passageiro Consulta Informao Viagem Verificar Autenticao Notificar Autenticao Vlida Notificar Autenticao Invlida Consultar Informao Viagem Apagar Informao Viagem Recebe Informao Leitura Regista Nova Localizao Tag Consulta Informao Viagem Lanar Alerta Registar Viagem Regista Passageiros Verificar autenticao Notificar Erro Autenticao Substituir Plano Viagem Consultar Informao Viagem Enviar SMS Passageiro Registar Aviso Tratado Verificar Autenticao Notificar autorizao vlida Recebe Informao Leitura Regista Nova Localizao Tag Reconciliar Tags Lanar Alerta Apagar Informao Viagem Regista Troos para local Enviar Email Notificao Regista Troos para local

Servio
Alterar Plano Viagem

Business Solution
BS2

Heurstica SOP
B1, B4

Alterar Plano Viagem

BS2

B1, B4

Consulta Informao Viagem Autenticao

BS2

A3

BS1

B1

Consulta Informao Viagem Apagar Informao Viagem Regista Passagem Tag Consulta Informao Viagem Lanar Alerta Criar Plano Viagem

BS2 BS2 BS3 BS2 BS4 BS2

A3 A3, A5 B1, B2 A3 A3, A5 B4

Autenticao

BS5

B1

Criar Plano Viagem Consulta Informao Viagem Registar Aviso Tratado Autenticao Regista Passagem Tag Reconciliar Lanar Alerta Apagar Informao Viagem Regista Local Operao

BS2 BS2 BS4 BS5 BS3 BS3 BS4 BS2 BS5

A5 A3 B2 B1 B1,B2 A3, A5 A3, A5 A3, A5 B1, B4

53

Gerir Operador Prever Trfego Prever Trfego Prever Trfego Registar Cliente Registar Cliente Registar Cliente Validar Partidas Validar Partidas Validar Partidas Validar Partidas Validar Posicionamento Validar Posicionamento Validar Posicionamento

Enviar Email Notificao Consultar Viagens previstas Operador Procura Lista Passageiros Troo Verifica Tags do Passageiros a caminho Regista Cliente Enviar Notificao de Erro Registar Cliente Reconciliar Tags Obtem Master Tag Passageiro Procura Lista Passageiros Troo Lanar Alerta Consulta Lista Passageiros Troo Localiza Passageiro Lanar Alerta

Regista Local Operao Consultar Viagens Operador Consulta Informao Troo

BS5 BS5 BS2

B1, B4 ___ B1

Registar Cliente Reconciliar Consulta Informao Troo Lanar Alerta Consulta Informao Troo Lanar Alerta

BS1

___

BS3 BS2

A3, A5 B1

BS4 BS2 BS4

A3, A5 B1 A3, A5

Tabela 9 Descrio dos Business Services sugeridos. Os Business Services encontrados podem ser visualizados na especificao dos processos, que esto em Anexo A, representados pelas caixas verdes. Todos os servios sugeridos por anlise funcional seguem uma de trs abordagens, seguindo-se a sua descrio: Conjunto de actividades que, embora no estejam repetidas, podero a vir a estar no futuro, ou seja, potencialmente reutilizveis. o caso do servio Alterar Plano Viagem, por exemplo. Uma actividade ou conjunto de actividades que se encontre replicada em vrios diagramas. O servio Lanar Alerta um destes casos intuitivos de reutilizao. Actividades que, embora no sejam iguais, tenham comportamentos semelhantes, podendo levar a produo de servios parametrizveis que executam diferentes fluxos. O servio Criar Plano Viagem um exemplo.

4.7.2.3 Comparao entre a anlise funcional e as heursticas SOP

Nesta seco efectua-se uma comparao entre os servios encontrados por anlise funcional e as heursticas para a descoberta de servios propostas na metodologia SOP. Pela anlise de cada servio sugerido pela anlise funcional confirmam-se as heursticas presentes na metodologia SOP (Tabela 9). As duas excepes so servios que, propostos por anlise funcional, representam potenciais reutilizaes mas que no so ainda reutilizados, Registo Cliente e Consulta Viagens Operador. Apresenta-se agora, na figura 34, um exemplo da aplicao da heurstica B2, na procura de um grupo de actividades utilizado em mltiplos caminhos do diagrama (Critrio da importncia). No processo Gerir Alertas esse grupo de actividades ser composto por trs actividades, a Regista

54

Aviso Tratado, a Envia SMS ao Passageiro e a Recebe Aviso, pois estas actividades so utilizadas em seis caminhos do diagrama. O processo acaba sempre com o envio de uma mensagem e o registo de um aviso, dai o conjunto destas duas actividades ter sido considerado um servio por anlise funcional.

Figura 34 Exemplo da macro a correr a heurstica B2 sobre o processo Gerir Alertas.

4.7.3 Information Services

Os Information Services foram identificados a partir da Matriz CRUD [51]. Segundo a metodologia SOP, atravs da anlise das aces efectuadas sobre a informao, Create, Read, Update ou Delete, criam-se servios para efectuar essas mesmas aces, ficando esses servios responsabilidade da Business Solution responsvel pela criao da entidade de informao. Importa agora justificar a reutilizao que se faz dos Information Services. Considere-se na matriz CRUD representada na figura 35 o processo Modificar Plano Viagem e a Business Solution 2 que lhe d suporte. Atravs da anlise da matriz so sugeridos os seguintes servios para a Business Solution: Servios CRUD das entidades Passageiro e Viagem. Servios de leitura e actualizao da entidade Tag e de leitura da entidade Troo e Cliente.

Figura 35 Identificao de Information Services de actualizao atravs da matriz CRUD. Considere-se depois o processo Gerir Leituras e a Business Solution 3 que lhe d suporte. Verificamos que, mais uma vez, sugerido o servio de Read Tag. Esta situao leva-nos a

55

uma indefinio, pois existem dois servios iguais em duas Business Solutions diferentes. No entanto, esta situao no passa da reutilizao do servio de Read Leitor por parte do processo Modificar Plano Viagem. Uma vez que a Business Solution responsvel por gerir/suportar a entidade Tag, segundo a matriz, a BS3, a ela que dever ficar associado o servio. Sempre que o processo Modificar Plano Viagem necessitar deste servio ter de reutiliz-lo atravs da BS3 e no recorrer directamente Business Solution que directamente lhe d suporte (BS2). Sempre que se identificar que um determinado processo utiliza um determinado Information Service do tipo Read sobre uma determinada entidade, dever ser reutilizado o servio j existente na Business Solution indicada na matriz como sendo a responsvel pela gesto dessa mesma entidade. Em relao ao servio de actualizao a situao anloga. Em ambos os casos, esta situao permitida porque estamos a actualizar ou a ler o estado associado ao identificador da entidade e no a partilhar esse identificador.

A metodologia SOP prope que a identificao de Business Solutions seja feita com base nos create e delete da matriz, para evitar problemas com a sobreposio de aplicaes nas matrizes. Esta abordagem significa que quem faz create ir criar o identificador para essa entidade e quem faz o delete estar a invalidar o identificador dessa entidade. Estes servios no sero reutilizados fora da Business Solution que d suporte entidade [51]. Um exemplo da reutilizao do servio de criao de uma entidade existe na matriz, representada no processo Criar Plano Viagem e Modificar Plano Viagem. No entanto, como a reutilizao ocorre dentro da mesma Business Solution, no haver a partilha da criao do identificador da entidade, sendo esta situao permitida.

4.7.4 Business Infra-structure Services

Na terceira fase da metodologia SOP, o objectivo consistia em encontrar os Business Infrastructure Services, ou seja, servios de baixo nvel que no esto directamente relacionados com o negcio. Esto representados em actividades automticas, na especificao dos processos de negcio, e so o Enviar SMS, Enviar Email e o Ler Tag.

4.7.4.1 Identificar as aplicaes que suportam a implementao dos Business Services

Segundo a metodologia SOP, qualquer servio tem de estar associado a uma Business Solution, que assumir a responsabilidade da sua gesto. A relao dos servios com as respectivas Business Solutions encontra-se descrita na tabela 9. Existem situaes de Business Services sugeridos que so reutilizados por processos, os quais so geridos por diferentes Business Solutions, levantando a questo de quem ser o responsvel pelo servio? A resposta a esta pergunta no surge da anlise da Matriz CRUD. necessrio analisar com maior detalhe a arquitectura de processos e a arquitectura de informao, para perceber com que entidades(s) se relacionam a(s) actividade(s) constituinte(s) do servio. Se se constata que essa(s) entidade(s) so geridas por uma determinada Business Solution, ento a esta que o servio dever ser

56

agregado. Caso contrrio, se a actividade se relaciona com diversas entidades, cada qual gerida por uma Business Solution diferente, j no claro a que Business Solution deve ser agregado esse servio. A seguir analisa-se o que foi descrito no pargrafo anterior com um exemplo prtico: quem ser o responsvel pelo servio Criar Plano Viagem? A questo surge porque as actividades do servio so reutilizadas por processos geridos pela Business Solution 2 e pela Business Solution 4. Analisando as entidades informacionais relacionadas com as actividades, verificamos que so criadas as entidades Viagem e Passageiro e actualizada a Tag. Como a metodologia SOP foca o critrio da agregao de servios a Business Solutions pela criao de entidades, ento a deciso ser a Business Solution 2 ficar responsvel pelo servio, pois a responsvel pela criao das entidades Viagem e Passageiro. Para efectuar a actualizao da entidade Tag, reutiliza-se o servio da Business Solution 3, tal como descrito no captulo de Information Services.

4.7.4.2 Inter-relacionar todos os servios

Nesta seco pretende-se apresentar um diagrama geral da arquitectura de servios. Na figura 36 est representada a relao entre os servios das vrias camadas. Por exemplo, o Business Service Consultar Informao Viagem reutiliza-se em trs Business Solutions, porque se usa o servio em vrios processos que pertencem a diferentes Business Solutions. O Information Service Ler Troo reutilizado por vrios Business Services, podendo essa situao ser visualizada nos diagramas dos processos de negcio e na matriz de CRUD. Por fim, refere-se que no se colocaram todos os Information Services na imagem devido ao exagerado nmero de servios existentes, que iriam tornar complexa a percepo da arquitectura geral.

Figura 36 Relao entre Servios das vrias camadas.

57

4.7.5 Arquitectura Centralizada ou Distribuda

A implementao do prottipo, descrita mais frente, foi realizada com uma arquitectura centralizada. No entanto, para a implementao real do projecto, a arquitectura teria de ser distribuda. Assim sendo, revela-se importante distinguir as implicaes que a arquitectura tecnolgica ter na arquitectura proposta. O desenvolvimento dos vrios processos de negcio, da arquitectura de informao e de aplicaes independente do tipo de arquitectura tecnolgica. Estas fases podem ser feitas, como acontece com frequncia no mundo real, por pessoas que no tm conhecimentos tecnolgicos. No entanto, interessa perceber onde consistir a diferena de uma abordagem centralizada e de uma abordagem distribuda. Essa diferena surge ao nvel dos servios que sero implementados, pois tecnologicamente no ser igual efectuar o desenvolvimento de servios para uma arquitectura centralizada e para uma arquitectura distribuda. Ou seja, a grande diferena reside no tipo de servios tecnolgicos que os servios das camadas de negcio iro usar. Partindo do pressuposto que a arquitectura est centralizada, o servio de consulta de informao da viagem ir apenas efectuar uma consulta base de dados central para recolher a informao pretendida. No entanto, se se tratar de uma abordagem distribuda, e tal como referido na arquitectura tecnolgica, a informao para a reconciliao dos passageiros e bagagens segue a mesma rota dos passageiros ao longo da viagem. Acontece que se uma bagagem for para um local no esperado, esse concentrador no ter informao sobre a tag e o passageiro, o que levar a que o servio de consulta de informao da viagem no seja feito a nvel local mas atravs de um mecanismo de broadcast, ficando a aguardar a resposta do concentrador que tem essa informao. No caso do servio de registo de planos de viagem, numa perspectiva distribuda passa-se a informao ao concentrador onde se dar o incio da viagem. No caso da arquitectura estar centralizada bastava colocar essa informao na base de dados central. Ou seja, a diferena em que base de dados se coloca a informao, havendo a necessidade de um levantamento de requisitos rigoroso para que tudo funcione correctamente. Importa referir nesta fase que os servios de negcio obtidos no sero alterados, os servios tecnolgicos que iro suportar a sua implementao que podero diferir consoante o tipo de arquitectura tecnolgica.

4.7.6 Relao com a framework Zachman

A arquitectura de servios uma nova abordagem na representao das arquitecturas empresarias. Tendo em conta que a arquitectura de servios est relacionada com a reutilizao e integrao, a opo foi relacionar esta arquitectura com 3 clulas representativas da integrao de sistemas [59]: modelo sistema X dados, porque esta clula representa a relao entre as vrias entidades informacionais; modelo sistema X funo pois nesta clula representa-se a

58

arquitectura de aplicaes que est na base da descoberta de servios; e modelo sistema X rede que contm a representao lgica da arquitectura de sistemas distribudos.

59

5 Prottipo
Depois de se ter obtido o catlogo de servios que sero necessrios para a realizao do sistema, partiu-se para a ltima fase do projecto, que consistiu na implementao de alguns dos servios encontrados. Comeou-se por realizar uma arquitectura de componentes e de deployment, representada na figura 37, que ir suportar a implementao dos servios. Esta arquitectura ser composta por quatro elementos fundamentais: Portal Aplicao de Lgica de Negcio Aplicao de Base de Dados Aplicao de Gesto RFID
Aplicao Lgica de Negcio

Portal Cliente/Operador Web Services (http)

Aplicao WEB (ASP .NET)

Aplicao Lgica de Negcio (BizTalk)

Orquestador de Mensagens (Microsoft BizTalk 2006)

Servidor Web (Microsoft ISS)

Servidor Web (Microsoft ISS)

Microsoft SQL Server 2005

Servidor Aplicacional (Microsoft IIS)

Servidor Aplicacional (Microsoft IIS)

Aplicao de Comunicao com a Base de Dados (BizTalk)

SQL

Web Services

Aplicao de Base de Dados

Aplicao Gesto RFID

Microsoft SQL Server 2005

Microsoft BizTalk RFID

Figura 37 Arquitectura de Componentes e de Deployment. O Portal ir suportar a interface com os utilizadores do sistema. Nesta fase sero implementadas as actividades semi-automticas representadas nos processos de negcio anteriormente analisados. A aplicao de lgica de negcio ir dar corpo ao catlogo de servios encontrados. nesta fase que sero implementados os servios correspondentes s actividades automticas dos processos de negcio. Nesta aplicao faz-se tambm a gesto dos servios que gerem a informao. 60

A aplicao de base de dados ir suportar as entidades de informao necessrias ao modelo de negcio. A aplicao de gesto de RFID a aplicao que ir fornecer as leituras feitas nas tags. Esta aplicao servir de ponte para a integrao dos leitores fsicos de RFID e a aplicao de lgica de negcio.

5.1 Tecnologia Usada

5.1.1 Windows Server 2003
O Windows Server 2003 foi o sistema operativo utilizado para a implementao dos servios, pois era sistema operativo que suportava a tecnologia a utilizar, nomeadamente o Biztalk Server 2006 R2.

5.1.2 Framework .NET

A framework .NET tem uma grande biblioteca de solues pr-codificadas para problemas de programao comuns e gere a execuo de programas escritos especificamente para a framework.

5.1.3 ASP .NET

O ASP.NET parte constituinte da arquitectura da framework .NET e permite a construo de web sites. O portal apresentado no captulo anterior foi implementado com esta tecnologia. Tal deciso deve-se ao facto de se estar a utilizar a framework .NET dispensando recorrer a outro tipo de tecnologia. Assim construiu-se o portal que suportar a camada de apresentao do sistema. O site foi construdo recorrendo a um conjunto de funcionalidades grficas disponibilizadas pela framework .NET que automaticamente transformam toda a funcionalidade grfica em cdigo, muito parecido com HTML. Esta parte denomina-se por lado cliente do site e a parte do sistema que ficar visvel aos utilizadores do sistema. O lado servidor do site est construdo atravs da linguagem de programao C#, uma das disponibilizadas pela framework, onde se constri toda a lgica da camada de apresentao e comunicao com a camada de lgica de negcio. A tecnologia utilizada para a comunicao entre as duas camadas foi os web services, tal como est representado na figura 37. Para a construo do site foi muito til o guia disponibilizado pela Microsoft [41], onde se refere um dos principais aspectos utilizados, as Master Pages. As Master Pages permitem que se defina a estrutura de uma pgina Web. Parte-se da sua interface e assim pode-se reutilizar esta interface em qualquer pgina que se pretenda, fazendo com que s a restante parte da pgina seja modificvel.

61

5.1.4 Visual Studio 2005

O Microsoft Visual Studio um pacote de programas da Microsoft para o desenvolvimento de software, especialmente dedicado framework .NET e s linguagens de programao Visual Basic e C#.

5.1.5 BizTalk Server 2006 R2

O Biztalk utiliza-se para resolver problemas que as empresas encontram quando pretendem automatizar os processos de negcio. Usualmente, esses problemas passam pela necessidade de integrar mltiplos sistemas heterogneos e de comunicar com parceiros externos. Dispe de ferramentas de desenvolvimento, administrao e monitorizao, algumas das quais representadas na figura 38 pelas caixas azuis.

Figura 38 Biztalk Server 2006 [42]. A grande maioria dos processos de negcio actuais depende em parte do software. Enquanto que alguns desses processos so suportados por uma nica aplicao, muitos outros dependem de diversos sistemas. Em alguns casos, esse software foi criado em diversas ocasies, em diferentes plataformas e usando distintas tecnologias. Automatizar esses processos requer ligar vrios sistemas. Existem dois cenrios principais na integrao de aplicaes: EAI, Enterprise Aplication Integration, que consiste em ligar aplicaes existentes dentro da mesma organizao. B2B, Business to Business, que permite integrar aplicaes de diferentes organizaes.

O primeiro caso est representado na figura 39. No exemplo, uma aplicao de inventrio verifica que o valor de um determinado item est abaixo do mnimo desejvel, fazendo com que seja lanado um pedido para o restabelecimento do stock. Este pedido enviado para uma orquestrao Biztak, que trata de reencaminhar o pedido para o ERP da organizao, a fim de

62

requisitar o pedido de compra. O ERP responde enviando uma mensagem para o motor do Biztalk Server que ir concluir o processo ao informar o sistema de execuo de que o artigo deve ser encomendado [42].

Figura 39 Exemplo de integrao EAI [42].

5.1.5.1 BizTalk Server 2006 Engine

O Biztalk Server 2006 Engine o corao do produto. Da sua estrutura destacam-se as principais funcionalidades: Servios de comunicao e de transformao de mensagens XML. Servios de orquestrao que permitem automatizar os vrios passos de processamento (workflow). Capacidade de interaco com sistemas externos atravs de adaptadores prprios. Possibilidade de integrao com web services.

Recuperando o exemplo da figura 39, cada aplicao pode comunicar atravs de um protocolo diferente e com formatos de mensagem especficos dessa aplicao. O Biztak tem de ser capaz de comunicar com cada aplicao atravs do seu protocolo nativo, e tambm de conseguir converter as mensagens para o formato exigido pelos outros sistemas. Toda a comunicao entre o Biztalk e os outros sistemas baseada na troca de mensagens. O motor de mensagens do Biztalk recebe mensagens, identifica o seu formato, extrai os elementos da mensagem, aplica regras de encaminhamento e entrega as mensagens no destino. Durante este processamento, o Biztalk usa uma base de dados chamada MessageBox. Normalmente o processamento a aplicar a cada mensagem define-se por uma ou mais orquestraes. Os servios de mensagens e de orquestrao esto representados na figura 40.

63

Figura 40 Arquitectura do motor de mensagens do BizTalk [43].

5.1.5.2 BizTalk RFID

O BizTalk RFID contm uma arquitectura que se encontra representada na figura 41, seguindo uma abordagem em camadas, das quais se distinguem [45]:

Device Service Provider Interface Event processing engine Object model (OM) and APIs Designers, tools, and adapters

Figura 41 Arquitectura do Biztalk RFID [44]. Device Service Provider Interface No BizTalk RFID, a abordagem seguida consiste em adicionar uma camada de software tecnologia, de forma a permitir que todos os tipos de dispositivos RFID, incluindo os actuais, os futuros, sensores ou leitores EPC sejam incorporados de uma maneira fcil e que estejam prontos a usar. O resultado pretendido semelhante aos ratos usados nos computadores hoje em dia, ou seja, independentemente da marca, o que se pretende lig-lo e que ele funcione. 64

Esta camada composta por um conjunto de APIs genricas e extensveis que ajudam os vendedores de hardware a construir drivers e interfaces que permitam aos dispositivos RFID trabalhar sem esforo num ambiente Microsoft. Para facilitar tal integrao, fornecido um SDK que permite normalizar a comunicao de diferentes protocolos e suportar diferentes tipos de leitores. Event processing engine O motor de processamento de eventos o componente nuclear do BizTalk RFID, que ajuda um programador a criar, desenvolver e gerir processos lgicos que so independentes do tipo de dispositivo e do protocolo de comunicao. A figura seguinte demonstra o motor de processamento de eventos e a sua interaco com outros blocos da arquitectura Biztalk RFID [46].

Figura 42 Motor de Processamento de Eventos [46]. Um evento gerado quando um dispositivo l uma tag. O elemento principal do motor de processamento de eventos o pipeline de eventos despoletado com a entrada da leitura de uma tag. Usando o modelo de objectos e as ferramentas RFID, descritas em baixo, o programador consegue construir uma rvore de processamento de eventos que pode escalar entre o simples e o complexo. O uso de dispositivos lgicos no motor de processamento de evento permite que o processo seja totalmente independente da infra-estrutura fsica. Um aspecto essencial do motor de processamento de eventos o event hander. Dependendo do cenrio de negcio, o event handler pode executar cdigo baseado na framework .NET ou baseado em regras de negcio com o intuito de o filtrar, alertar ou transformar o evento. Object model (OM) and APIs O BizTalk RFID fornece um modelo de objectos e APIs que ajudam os programadores a desenhar, estender e gerir solues RFID. Isto inclui as ferramentas necessrias para o desenho e deploy dos pipelines necessrios para filtrar, agregar e transformar dados em informao til.

65

Usando o modelo de objectos em conjunto com as APIs, consegue-se criar uma variedade de ferramentas para gerir o Biztalk RFID, que inclui a gesto de dispositivos, desenho e extenso de processos, seguimento de eventos e monitorizao. Designers, tools, and adapters Consiste em duas ferramentas bsicas fornecidas com o BizTalk RFID: uma consola de administrao, chamada RFID Manager, e uma ferramenta de composio de regras de negcio. Os adaptadores permitem uma efectiva troca de dados entre o Biztalk RFID e outros sistemas.

5.1.5.3 BizTalk Web Services Publishing Wizard

Permite ao programador publicar uma orquestrao efectuada em BizTalk como um web service, sem ter de efectuar qualquer linha de cdigo. Ao fazer isto, possvel expor a funcionalidade de uma orquestrao para terceiros.

5.1.6 SQL Server 2005

O SQL Server 2005 foi a base de dados utilizada para suportar o modelo de negcio. Esta deciso acabou por no gerar problemas, pois j se utilizava esta base de dados para suportar o Biztalk Server.

5.1.7 DLP RFID1

O leitor fsico utilizado foi disponibilizado pela Link Consulting, e da DLP Design. O modelo consiste no DLP RFID1, que permite a escrita e a leitura de tags com protocolos de comunicao ISO 15693 e ISO 18000-3. O fornecedor do leitor disponibiliza suporte para o BizTalk RFID, existindo disponvel o driver que permite fazer a integrao entre o dispositivo fsico e o BizTalk RFID. Basicamente, este driver corresponde camada de software descrita anteriormente, DSPI do BizTalk RFID.

5.2 Arquitectura 3-Tiers

No desenvolvimento do prottipo foi seguida uma abordagem de trs camadas (Fig. 43), com uma camada de apresentao representada no portal, uma camada de lgica de negcio onde se encontram os diversos servios implementados e uma camada de dados representada na aplicao de base de dados. Esta arquitectura uma extenso ao modelo cliente/servidor, onde o processamento de informao no critica feito do lado do cliente e as funes criticas so processadas do lado do servidor. O objectivo pretendido consiste em separar em diferentes camadas os servios que automatizam os processos de negcio, os dados que suportam os processos e a apresentao do prottipo.

66

Figura 43 Arquitectura 3 camadas Cliente/Servidor [61].

5.3 Implementao
Para implementar os servios partiu-se o seu desenvolvimento em quatro fases, correspondentes a cada uma das aplicaes pretendidas: Aplicao de Base de Dados Aplicao de Lgica de Negcio Portal Aplicao de Gesto RFID e integrao com Lgica de Negcio.

Reala-se ainda que o prottipo foi implementado numa arquitectura centralizada.

5.3.1 Aplicao de Base de Dados

Comeou-se com a criao de uma base de dados, no SQL Server 2005, e de um conjunto de tabelas que suportassem o modelo de negcio proposto e as entidades de informao apreendidas durante a fase de anlise. De seguida programou-se os stored procedures que permitem o acesso s tabelas, pois foi usado um wizard do Biztalk que permite s orquestraes o acesso base de dados atravs de stored procedures.

5.3.2 Aplicao de Lgica de Negcio

Passada a fase anterior, iniciou-se o desenvolvimento dos servios encontrados anteriormente, atravs de orquestraes em Biztalk. Um exemplo de uma orquestrao em BizTalk encontra-se representado na figura 44. Os primeiros servios implementados foram os Information Services, que so os de suporte para criar, alterar, ler e apagar as entidades de informao. Numa segunda fase, comeou-se ento a implementar os Business Services encontrados que correspondem a actividades automatizveis dos processos de negcio. Aqui j se usam web services, os quais permitem que se chame uma orquestrao atravs de outra orquestrao. Todos os servios foram testados por intermdio de ficheiros XML para averiguar a correco dos servios.

67

Figura 44 Exemplo de uma orquestrao em Biztalk.

5.3.3 Portal
De seguida implementou-se um site, pois foi a forma definida para a interaco entre os intervenientes do sistema e o TSMART e a maneira de testar os servios implementados atravs de uma interface mais agradvel do que ficheiros XML. Esses testes sero referenciados no captulo 7, de validao.

5.3.4 Aplicao Gesto RFID

Por fim, e dado que era uma tecnologia completamente nova, preencheu-se algum tempo a perceber como que o Biztalk RFID funciona. Efectuaram-se os tutoriais do Biztalk RFID disponveis na internet [47], permitindo perceber como se efectuam processos RFID e event handlers, simulao de dispositivos fsicos e simulao da passagem de tags reais pelos leitores. Uma ferramenta importante RFID Manager, onde se faz toda a gesto da aplicao de RFID. Uma imagem da aplicao encontra-se disponvel na figura 45. Esta ferramenta permite criar processos, associar event handlers aos processos, criar dispositivos lgicos e integrar leitores reais.

Figura 45 RFID Manager. Para o Biztalk RFID funcionar correctamente necessrio criar um processo RFID. A figura 45 apresenta dois processos, um dos quais, o TsmartProcess, encontra-se no estado ligado. Esse processo tem associados dois event handlers, que sero descritos adiante. Ao processo est tambm associado um logical device, que por sua vez est ligado a um dispositivo fsico. Na 68

figura 46 esto descritos exemplos de leituras efectuadas pelo leitor e que so percepcionadas pelo RFID Manager.

Figura 46 Visualizao da passagem de tags nos processos RFID. Para o processamento das tags foram efectuados dois event handlers, ambos em C#, que permitam processar as leituras efectuadas s tags. Cada leitura retorna um identificador, que o identificador da tag representado em hexadecimal (Fig. 46). O primeiro event handler pretendia filtrar leituras repetidas num determinado intervalo de tempo, ou seja, uma tag, ao passar na zona de alcance da antena de um leitor, est constantemente a enviar sinais indicando a sua presena e pretendia-se que essas vrias sinalizaes de presena fossem entendidas como uma nica. O segundo event handler permite o envio de um evento para o servio que gere as leituras de tags na camada de lgica de negcio, sendo esta integrao feita atravs de web services. aqui que se efectua o ponto de ligao entre a camada de lgica de negcio e a aplicao de gesto RFID. Este servio, de gesto das leituras constitui o servio principal para a reconciliao de passageiros e tags, no sentido que ele que ir originar possveis problemas nas bagagens. A identificao do leitor faz-se como parmetro no RFID Manager, dado que apenas se dispunha de um dispositivo fsico. A partir desta identificao, o sistema percebe qual dos tipos de leitor estar associado a este identificador e executa o fluxo de processamento correspondente. Esta situao semelhante a uma regra de negcio. Como foi dito na seco anterior, o fabricante de hardware deve produzir drivers que permitam integrar o leitor com o Biztalk RFID e uniformizar a comunicao entre o leitor, que tem um tipo de dados prprio, e o tipo de dados interpretado pelo BizTalk. Cada leitura que chega ao Biztalk RFID interpretada como um TagReadEvent e portanto a camada DSPI descrita deve ser capaz de transformar a informao contida na tag num TagReadEvent. Um exemplo de um TagReadEvent encontra-se descrito na figura 47.

69

Figura 47 Exemplo de ficheiro XML que representa a passagem de uma tag por um leitor. Por fim, procedeu-se instalao dos drivers DSPI [48] do leitor fsico DLP RFID1 (Fig. 48), que permitiram efectuar leituras das tags fsicas existentes na Link. Toda a infra-estrutura fsica est pronta para ser usada e as leituras s tags reais iro gerar eventos que so tratados pela lgica de negcio, permitindo, por exemplo a gerao de alertas e a sua posterior visualizao no site.

Figura 48 Imagem do leitor fsico usado no prottipo [48].

70

6 Validao
A validao que se efectua soluo consiste em validar os servios obtidos atravs de verificaes prticas, ou seja, atravs do prottipo implementado. A validao ir englobar vrios tipos de servios sugeridos na Arquitectura de Servios. O primeiro teste que se descreve diz respeito ao servio tecnolgico de leitura de tags. Como se verificou no captulo anterior, foram testadas leituras a tags reais, sendo estas realizadas com sucesso. A sua passagem era detectada pelo Biztalk RFID, como se apresenta na figura 46, e a filtragem feita por um handler que permitiu passar lgica de negcio apenas os eventos que interessavam. No entanto, refere-se que nem todos os servios foram implementados, devido falta de tempo e porque era apenas pretendido efectuar um prottipo para a soluo. Assim sendo, demonstra-se agora um conjunto de imagens retiradas do prottipo, que permite validar alguns dos servios produzidos. Na figura 49 aparece um exemplo do ecr inicial. Neste ecr possvel registar novos clientes ou efectuar o log-in no sistema. O log-in pode ser feito por operadores, clientes ou administradores do TSMART.

Figura 49 Ecr inicial do prottipo. Aps a introduo do identificador do utilizador e da respectiva password, verificada a sua autorizao de acesso ao sistema. Caso seja vlida, ter-se- acesso a um ecr com um menu lateral, permitindo que os utilizadores efectuem algumas funcionalidades. Os ecrs da gesto da rede, por pessoal responsvel pelo TSMART, permitem o registo de operadores e o registo de

71

localizaes onde estes operadores operam na rede. a partir do registo destas localizaes, no prottipo, que os clientes podem escolher os troos da viagem. Caso seja um cliente a entrar no sistema, este teria outro menu de funcionalidades sua disposio. As funcionalidades so o registo de viagens, a consulta de avisos ou a consulta da sua informao. No registo de viagens, representado na imagem da figura 50, onde o cliente pode escolher os vrios troos da viagem e a data da ocorrncia da viagem e de seguida pode escolher quantos passageiros tem a viagem, podendo depois registar tambm a informao dos passageiros nos ecrs seguintes. A consulta de avisos semelhante que se faz nos operadores, isto , os clientes tm acesso a toda a informao dos avisos, onde ocorrem, etc, mas no conseguem alter-lo como o operador.

Figura 50 Ecr de registo de uma viagem por um cliente. A consulta de informao do cliente d-lhe acesso a um ecr com a sua informao pessoal, onde poder consultar as suas viagens registadas, os passageiros que pertencem viagem e, se pretender, pode alter-la, adicionando passageiros (Fig. 51).

Figura 51 Ecr de consulta de informao por parte do cliente.

72

No caso de ter sido um operador a entrar no sistema, h trs funcionalidades, que so o registo de novos leitores, o check-in ou a consulta de avisos (Fig. 52). O registo de leitores permite associar identificadores de leitores localizao onde o operador opera. O check-in permite em trs passos registar a tag que identifica o passageiro, as tags associadas bagagem de poro e as tags associadas bagagem de mo, atravs da passagem de tags reais pelo leitor fsico disponvel. Assim o sistema fica a conhecer que tags pertencem ao passageiro e qual o seu tipo. A partir deste momento simula-se a passagem do passageiro atravs de leitores num aeroporto, igualmente com a passagem de tags reais no leitor fsico disponvel. Apesar de o leitor ser o mesmo, o sistema adquire comportamentos diferentes consoante o identificador do leitor que parametrizado no RFID Manager, ou seja, o ID do leitor est associado a um tipo, que pode ser check-in, reconciliao total, parcial ou apenas registo passagem. Testou-se os casos em que as tags passam todas juntas num leitor de reconciliao total e no h gerao de erros, as passagens em que a reconciliao gera erros e situaes de aparecimento de tags em locais no esperados, todos eles com sucesso. Na figura 52 apresenta-se o caso da consulta de erros que forem despoletados pelos leitores do prprio operador. Caso existam erros, a sua resoluo ser da responsabilidade do operador. Como se verifica pela imagem, existe um erro com uma tag, que ocorreu na zona de aco do operador. O aviso criado contm um nmero de erro, a data da ocorrncia, o identificador da tag envolvida, a descrio do erro que neste exemplo a passagem de um passageiro por um leitor sem toda a sua bagagem prevista, a localizao do erro dentro da zona de aco do operador e o estado em que se encontra. Para alm desta informao o operador tem um link denominado change a azul, que permite ao operador visualizar a informao relativa viagem da tag, observar os vrios troos onde esperado passar e alterar a sua viagem caso seja necessrio. Este ecr est apresentado na figura 53.

Figura 52 Ecr de um operador a consultar avisos.

73

Figura 53 Ecr de consulta da viagem de uma tag.

74

7 Concluses
O projecto foi planeado com trs objectivos. O primeiro consistia em produzir uma arquitectura de processos para a resoluo dos problemas que existem na reconciliao entre passageiros e bagagens, numa perspectiva de viagem multi-modal, recorrendo tecnologia RFID. O segundo objectivo pretendia que a concepo do sistema seguisse uma metodologia para desenvolver uma arquitectura SOA, como forma de criar um novo cenrio de teste para a metodologia em investigao. Por fim, pretendia-se criar um prottipo para validar se os vrios servios encontrados tinham correspondncia no modelo de negcio proposto. O primeiro objectivo insere-se numa proposta inovadora, pois actualmente no existe um modelo de negcio que espalhe a reconciliao de passageiros e bagagens. Assim sendo, importante a realizao de uma arquitectura de processos. A sistematizao dos processos antes destes existirem na prtica permitir fornecer um suporte para a difcil comunicao entre o pessoal de negcio e o pessoal de sistemas de informao. O modelo desenvolvido serve de guia para a implementao real da plataforma tecnolgica a aplicar, permitindo identificar e medir a ocorrncia de problemas, atravs dos seus pontos de controlo. Por outro lado, fornece informao til formao dos utilizadores, pois todos tm noo das diferentes actividades que tero de desenvolver. Ao nvel do negcio de grande importncia a integrao dos vrios operadores. Principalmente os gestores dos aeroportos, devem ter conscincia que a integrao, tal como acontece com as redes de telecomunicaes, resolve o grande problema que a perda das bagagens no transporte areo. Por ano, so perdidas ou reenviadas milhares de bagagens, que originam elevados prejuzos, alm do incmodo causado satisfao do cliente. Muitos dos operadores nem sequer se apercebem dos problemas que ocorrem nas bagagens at serem confrontados pela perda das malas dos passageiros. O sistema analisado permite avisar o operador da ocorrncia desses problemas e proporciona informao que reduz o tempo necessrio ao reenvio de uma bagagem. A viabilidade do sistema ser reforada se aderirem vrios operadores sua utilizao. De facto no caso do sistema ser usado por um nmero reduzido de operadores, as tags correm o risco de ser lidas apenas num local e pode no voltar a haver controlo noutro local, perdendo assim o objectivo de multi-modalidade ou multi-operador que se pretende com o sistema. Por isso, conveniente que exista uma rede de utilizadores o mais extensa possvel.

75

O segundo objectivo consistia na concepo de uma arquitectura SOA seguindo uma metodologia que garantisse o alinhamento entre o negcio e o TI. Foi feita uma anlise funcional dos processos e, posteriormente, uma comparao com as heursticas da metodologia. Verificouse que quase todos os servios propostos tm correspondncia nas heursticas. Acrescenta-se ainda o facto da importncia destas duas fases de desenho permitirem ter rastreabilidade. Assim, o impacto da alterao dos processos de negcio poder ser sempre avaliado, dado que alteraes ao nvel dos processos iro sempre repercutir-se nos sistemas da organizao. Esta abordagem poder ainda ser til em propostas de projecto como o Mala Segura, em desenvolvimento na LINK, e no s no projecto TSMART. O terceiro objectivo pretendia validar que os processos de negcio satisfazem a resoluo dos problemas envolvidos. Foi testado um cenrio de utilizao com tags reais com sucesso. H que referir a importncia da rapidez com que se gera um aviso caso ocorra um problema com as bagagens. O Biztalk RFID permite, no seu motor de eventos, tratar as leituras feitas s tags e aplicar-lhes regras de negcio. Por outro lado, essa informao poder ser passada directamente para a camada de negcio. O compromisso entre a flexibilidade e o desempenho do sistema revela-se crucial para que o modelo de negcio tenha sucesso. Com vista completude do projecto, prope-se a realizao de investigao noutras reas: Um projecto mais tecnolgico que efectue um estudo exaustivo dos RFIDs e que avalie a sua capacidade para suportar o modelo de negcio proposto. Neste caso, ser muito importante analisar certos requisitos, como a distncia a que os leitores so capazes de ler tags, a sua fiabilidade ou a segurana para efectuar leituras. Sugere-se ainda a aplicao da ideia do projecto a um caso real, onde se teste o comportamento das tags numa viagem entre dois locais fsicos e com grande quantidade de tags. De qualquer modo, o trabalho executado constitui uma base inovadora para solucionar a complexidade que representa o encaminhamento das bagagens em transportes na sociedade tecnolgica em construo no sculo XXI.

76

8 Bibliografia
1. 2. 3. 4. 5. 7. Center for Logistics Education and Research, What is logistics?, http://www.logistics.unt.edu/what-isit/ Laudon, Kenneth; Laudon, Jane, Management Information Systems: Managing The Digital Firm, Prentice Hall, 9th Ed., 2006. Platform for ISDEFE, Tags for SMARt Travellers: a Multi-Modal Luggage and Passenger Conciliation Door to Door Service, 2007. Wikipedia, Network Topologies, http://en.wikipedia.org/wiki/Image:NetworkTopologies.png About.com, Network Topologies, http://compnetworking.about.com/od/networkdesign/a/topologies.htm Yang, Lee; Kornfeld, Richard, Examination of the Hub-and-Spoke Network: A Case Example Using Overnight Package Delivery, 41st Aerospace Sciences Meeting and Exhibit, Reno, Nevada, 6-9 January 2003. 8. 9. Tal Tech, Introduction to bar codes, http://www.taltech.com/TALtech_web/resources/intro_to_bc/bcbascs.htm Simply Bar Codes, UPC Bar Codes, http://www.upccode.net/faq.html http://www.adams1.com/pub/russadam/upccode.html 11. Palowireless, What is RFID?, http://www.palowireless.com/rfid/whatisrfid.asp 12. SmartCode, RFID Overview, http://www.smartcodecorp.com/solutions/EPC_overview.asp 13. MSDN Architecture Center, RFID: An Introduction, http://msdn2.microsoft.com/enus/library/aa479355.aspx 14. Olsen, John; Bradley, David, Systems and Methods for Tracking Items using Wirelessly-Enabled Devices, Patent US 2006/0091206 A1, May 2006. 15. Kato, K; Pham, T, Package and Mail Delivery System, Patent US 7079913 B2, July 2006. 16. Kabada, N, Multi-Stage Parcel Tracking System, Patent US 6285916 B1, July 2001. 17. Swan, R, Item Tracking System Architectures Providing Real-Time Visibility to Supply Chain, Patent US 6901304 B2, May 2005. 18. Kodger, JR, Next Generation Visibility Package Tracking, Patent US 2006/0229895 A1, Oct 2006. 19. Answers.com, Definition of cellular network, http://www.answers.com/topic/mobile-phone 20. J. Eberspcher ; H.-J. Vgel, GSM: Switching, Services and Protocols, John Wiley & Sons, 1998. 21. Wikipedia, Structure of GSM Network, http://en.wikipedia.org/wiki/Image:Gsm_network.png 22. Fernandes, Ivo, Arquitectura GSM, http://paginas.fe.up.pt/~ee99207/Tecnologias/celulares/GSM.html 23. BSI, GSM Cellular Network, http://www.bsi.de/literat/doc/gsm/index_e.htm 24. Nokia, GSM Architecture: Training Document, Finland, Jan 2002. 10. Adams Communications, Universal Product Code (UPC) and EAN Article Numbering Code (EAN),

6. Network tutorials, Network topology Introduction, http://www.networktutorials.info/topology.html

77

25. M-Indya,

GSM

architecture

and

detailed

discussion

of

GSM,

http://www.m-

indya.com/gsm/gsmarchitecture.php#3 26. Chang, Li-Fung, Method and System for supporting pacs using a GSM Mobile Switching Center, Patent US 6167279, Dec 2000 27. Wikipedia, Network and Switching Subsystem, http://en.wikipedia.org/wiki/Network_and_Switching_Subsystem 28. Sallin, Hannu, Method of checking the Identity of a subscriber equipment, Patent US 5625671, 1997. 29. Rahnema, Moe, Overview of the GSM System and Protocol Architecture, IEEE Communications Magazine, April 1993. 30. GSM World, GSM Roaming, http://www.gsmworld.com/roaming/index.shtml 31. Wikipedia, Roaming, http://en.wikipedia.org/wiki/Roaming 32. Houde, Michel, Cellular Telephone Network routing method and apparatus for internationally Roaming Mobile Stations, Patent US 5978678, Nov 1999. 33. GSM World, GSM Roaming How does Roaming Work, http://www.gsmworld.com/roaming/how_roaming_works.shtml 34. Sallin, Hannu, Method for establishing an inbound call to the mobile telephone in a GSM cellular mobile telephone network, Patent US 5400390, 1995. 35. Langley, Richard, In Simple Terms, How Does GPS Work?, 2003, http://gge.unb.ca/Resources/HowDoesGPSWork.html 36. GPS Overview, http://www.geog.okstate.edu/gpstools/overview1.htm#what_is_gps 37. Smithsonian Institution, How Does GPS Works?, http://www.nasm.si.edu/gps/work.html 38. Royal Observatory of Belgium, How work GPS, http://www.gps.oma.be/gb/lbesch_gb_ok_css.htm 39. HowStuffWorks, How GPS receiver work, http://electronics.howstuffworks.com/gps3.htm 40. The Tech-FAQ, Como funciona o GPS tracking funciona?, http://www.tech-faq.com/lang/pt/gpstracking.shtml 41. Visual Web Developer 2005 Guide Tour, http://www.asp.net/Guided-Tour/ 42. Introducing Biztalk Server 2006, http://technet.microsoft.com/en-us/library/aa547058.aspx 43. The BizTalk Server 2006 Messaging Engine, http://technet.microsoft.com/en-us/library/aa578449.aspx 44. BizTalk RFID Architecture, http://technet.microsoft.com/en-us/library/bb749746.aspx 45. BizTalk RFID WhitePaper, http://download.microsoft.com/download/B/3/3/B3319653-EF57-4C70-A3F8195DDB4884D4/BizTalkRFIDWhitePaper.doc 46. RFID Engine, http://technet.microsoft.com/en-us/library/bb745960.aspx 47. Tutorial RFID, Order Fulfillment, http://technet.microsoft.com/en-us/library/bb745997.aspx 48. De la Cruz, Irving, BizTalk RFID Device Deployment Kit for DLP Design Devices, Alpha Release Version 0.9 49. Enterprise Architecture Planning - Developing a Blueprint for Data, Applications and Tecnology, John Willey & Sons, 1992. 50. Tribolet, Jos; Sousa, Pedro; Arquitectura Organizacional da Administrao Publica, 2005 51. Almeida, J.M.; Santos, P.; Carvalho, B.; Marques, E.; Segura, J.; Vieira, A.; Sousa, P.; BPB-SOA e SOP: uma Framework e Metodologia para SOA orientado ao negcio, Link Consulting, 2008. 52. ZIFA, Zachamn Framework Overview, 2005, http://www.zifa.com/ 53. Sousa, P; Silva, A; Vasconcelos, A; Caetano, A; Arquitecturas de Sistemas de Informao Arquitecturas de Servios, 2008. 54. Sousa, P; Silva, A; Vasconcelos, A; Caetano, A; Frameworks de Arquitectura Empresarial, 2008. 55. Sousa, P; Silva, A; Vasconcelos, A; Caetano, A; Arquitectura de Sistemas de Informao, 2008.

78

56. Sousa, P; Silva, A; Vasconcelos, A; Caetano, A; Arquitectura de Informao, 2008. 57. Sousa, P; Silva, A; Vasconcelos, A; Caetano, A; Arquitectura de Processos, 2008 58. ZIFA, The Framework for Enterprise Architecture Cell Definitions, 2003 59. Frankel, D; Harmon, P; Mukerji, J; Odell, J; Owen, M; Rivitt, P; Rosen, M; Soley, R; The Zachman Framework and the OMGs Model Driven Architecture, Business Process Trends White Paper, 2003 60. Wikipedia, Spoke-hub distribuition paradigm, http://en.wikipedia.org/wiki/Spokehub_distribution_paradigm 61. Kambalyal, C, 3-Tier Architecture, http://members.tripod.com/ChannuKambalyal/NTierArchitecture.pdf 62. Sousa, P, John Zachman e as Arquitecturas Empresariais.

79

Anexo A
Alterar Informao Viagem
Cliente Alterar Viagem Requisita Viagem (S) Fim Acrescentar Passageiro Fornece Detalhes Passageiro (S) ApagarPassageiro Indica Passageiro (S) Recebe Confirmao

Dep. Planeamento Actualizar Viagem (A)

Alterar Plano Viagem Actualizar Passageiro (A)

Apagar Passageiro (A)

Troos

Viagem

Passageiro

Passageiro

Registar Passageiro (A)

Alterar Plano Durante Viagem

Operador Alterar Viagem Requisita Viagem (S) Recebe Informaao Viagem Escolhe Troos (S)

Dep. Planeamento Troos

Consultar Informaao Viagem Consulta Informaao Viagem Actualizar Viagem (A) Passageiro

Alterar Plano Viagem Fim Actualizar Passageiro (A) Actualizar Tag (A)

Viagem Troos Viagem

Passageiro

Tag

80

Apagar Informao Viagem

Dep. Planeamento Fim Viagem Recebe Nr Viagem (A) Apagar Passageiros da Viagem (A) Apagar Viagem (A) Fim

Passageiro

Viagem

Check-In Viagem
Passageiro
Passageiro Inicia Viagem Fornece Numero Passageiro (M) Nr Passageiro

Operador
Insere Numero Passageiro (S) Recebe Informao Viagem (A) Requisita Leitura Master Tag (S) Requisita Leitura Luggage Tags (S) Requisita Leitura Hand Luggage Tags (S)

Le Tag RFID (A)

Le Tag RFID (A)

Le Tag RFID (A)

Envia Informao Tags (S)

Dep. Operaes Tag Fim Check-In Registar Tag (A) Passageiro

Passageiro

Dep. Planeamento

Consulta Informao Viagem

Viagem

Consulta Informao Viagem (A) Troos

81

Consultar Informao
Cliente Dados Cliente No

Consulta infomacao Indica Dados Cliente

Escolhe tipo de Consulta (S) Alterar Informaao Viagem

Apagar Plano? Saida Fim Cliente Aviso Procura Info Aviso Cliente (S) Recebe Informao Viagens

Sim

Sim

No

Notifica Apagar Viagem

Recebe Informaao Avisos

Procura Informao Cliente (S)

Alterar Plano?

Dep. Comercial Autenticaao Cliente Verificar autenticaao(A) Notifica Autenticaao Vlida (A)

AutenticaaoVlida? Sim No Notifica Autenticaao Invalida (A)

Dep. Planeamento Consulta Informao Viagem

Troos Apagar Informao Viagem Consultar Informao Viagem (A) Viagem Apagar Informao Viagem +

Cliente

Dep. Incidentes

Aviso

Consultar Avisos Cliente (A)

Consultar Viagem Tag

Operador Bagagem Perdida Le Tag RFID (A) EPC Number Recebe Informaao Viagem da Tag Fim

Dep. Operaoes Recebe Informaao Leitura (A) Leitor

Regista Passagem Tag Consulta Informaao Viagem Existe Leitor? Sim Sim Tag Local Esperado? Ignorar Leitura Existe Tag? Sim Sim Leitor Registado depois da viagem da tag? No Regista Nova Localizaao Tag (A) No Consulta Informaao Viagem (A) Sim

Viagem

Troo

Aviso j lanado? No

Tag

Envia Alerta (A)

Dep. Incidentes Lanar Alerta

Lanar Alerta
+

82

Criar Plano Viagem

Cliente

Criar Viagem

Intermediao? No

Escolhe Troos (S)

Indica numero de passageiros (S)

Fornece Detalhes Passageiro (S) Fim

Info Troos Sim Indica Informao Viagem e Passageiros (M)

Recepao de Informao (A)

Info Passageiro

Agencia Viagens

Valida Viagem Proposta (M)

Valida Disponibilidade Viagem (M)

Indica Troos (S)

Indica Detalhes Passageiro (S)

Dep. Planeamento Troo Criar Plano Viagem Regista Viagem (A) Regista Passageiros (A)

Cliente

Passageiro

Viagem

Estabelecer ligao com a rede

Operador
ID Leitor Leitor Ligado Enviar pedido de ligao Ligao impossvel Erro de comunicao Leitor Ligado Recebe Notificaao ligaao estabelecida

Dep. Infraestrutura Autenticaao Notifica Erro Autenticaao (A) Leitor Verificar autenticaao(A) Autenticaao Vlida? No Leitor

Sim

Regista Estabelecimento de Ligao (A)

83

Gerir Alertas
Operador Indica Troos Substituir Viagem (S) Reencaminha bagagem No Notifica Problema Resolvido (S) Sim Possivel devolver bagagem?

Recebe Alerta Reconciliao Errada (A)

Recebe Alerta Bagagem Local Errado (A)

Dep. Operaoes

Aviso Recebe Aviso (A) Recebe Alerta Sim No Passageiro Mal Posicionado? No Tag Local Errado? Sim

Consultar Informao Viagem Consulta Informao Viagem (A)

Troo

Viagem

Aviso

Reconciliaao Errada?

Sim

Notifica Operador (A)

Tag

Criar Plano Viagem Substituir Plano Viagem

+

Fim Regista Aviso Tratado (A)

Registar Aviso Tratado Envia SMS ao Passageiro (A) No

Passageiro

Notifica Passageiro

Gerir Leitores
Operador
Adicionar Leitor Apagar Apagar Leitor Indica Dados Operador (S) Dados Operador Apagar Informaao Leitor Tags (S)

Alterar Alterar Leitor Escolher Local Operao (S) Tipo de Operaao?

Actualiza Informaao do Leitor (S)

Dados Leitor

Registar

Indicar Dados Leitor (S)

Escolher Tipo Leitor (S)

Dep. Infraestrutura Registar leitor de tags (A)

Fim

Local

Leitor

Alterar Leitor de Tags (A)

Apagar Leitor Tags (A)

Dep. Comercial Autenticao Operador Verificar autenticaao(A) Notifica Autenticaao Vlida (A) Nao Fim registo leitor

Autenticaao Vlida?

Sim

84

Gerir Leituras
Operador Tag Atravessa Leitor Le Tag RFID (A) EPC Number

Dep. Operaoes
Registar Passagem Tag No Ignorar Leitura No

Reconciliar Reconciliar Tags (A)

+

Recebe Informaao Leitura (A)

Existe Leitor? Primeira Tag? Sim Sim Existe Tag? No Inicia Reconciliaao (A) Reconciliao correcta?

Leitor

EPC Number

Sim

Sem Reconciliao

No

Sim

10 segundos Leitor Registado depois da viagem da tag? Sim Com Reconciliao Envia Alerta (A)

Ultimo local da viagem

Fim

Sim No Sim Tag Regista Nova Localizaao da Tag (A) Tag Local Esperado? No Tipo Leitor? Apagar Informaao Tags (A)

No

Tag

Dep. Incidentes Lanlar Alerta

Lanar Alerta
+

Reconciliao Incorrecta

Dep. Planeamento Apagar Informao Viagem Fim Apagar Informaao Viagem

Gerir Localizaes
Operador Regista Local Operao Envia Informaao Local Operaao (S) Recebe Notificaao

Dep. Infraestrutura

Avalia Pedido (M)

No

Apagar Troo

Escolhe Troo (S)

Pedido Aceite? Apagar Local Operaao

Apagar Troos do local (A) Escolhe Local (S) Apagar Local (A)

Fim

Local Sim Adicionar Troo Regista Informao (S)

Troo

Registar Local Operaao Adicionar Local Regista Informaao (S) Regista Localizaao (A) Regista Troos para novo local (A) Envia Email de notificaao (A)

85

Gerir Operadores
Operador
Novo Operador Escolher Dados Registo (S) Recebe Notificaao

Dep. Comercial

Fim Pedido Aceite No

Regista Local Operaao Avaliar pedido (M) Registar operador (A) Aderir rede Operador Local Cancelar adesao rede Apagar Informaao Operador (A) Apagar Informaao Associada Operador (A) Leitores Troos Regista Localizaao (A) RegistaTroos Local (A) Envia Email de Notificaao (A)

Sim

Lanar Alerta
Dep. Operaoes
Recebe Erro Recebe Informacao Tag (A) Regista Aviso (A) Envia SMS Passageiro (A) Fim

Tag

Aviso

Passageiro

Notifica Passageiro

Prever Trfego
Operador
Iniciar previso Escolher intervalo tempo (S) Recebe Relatrio Trafego (A) Fim

Dep. Operaoes Troo

Consultar Viagens Operador

Consultar Informao Troo

Consultar Viagens previstas no operador (A)

Procura Lista Passageiros do Troo (A)

Verifica Tags do Passageiro a caminho do Operador (A)

Enviar Relatrio Trafego Previsto (A)

Viagem

Passageiro

Tag

86

Registar Cliente
Utilizador

Novo Cliente Insere Dados de registo (S) Recebe Notificao Erro Registo Fim

Recebe Numero de Cliente

Dep. Comercial Registar Cliente Envia Notificao de Erro (A) Cliente Dados Vlidos? Sim Registar Cliente (A)

No

Recebe Dados Registo (A)

Substituir Plano Viagem

Dep. Planeamento Troos Fim Tag Local Errado Regista Viagem (A) Actualizar Tag (A)

Viagem

Tag

Validar Partidas
Operador

Pronto para partida Insere ID Troo (S) Recebe Relatrio Alertas Fim

Dep. Operaoes Consultar Informao Troo Reconciliar Procura Lista Passageiros Troo (A) Obtem Tag Poro Passageiros (A) Reconciliar Tags (A)
+

No

Problema nas tags? Sim

No

Ultimo Passageiro Lista?

Sim

Envia Relatrio Alertas (A)

Troo

Passageiro

Tag

Envia Alerta para tratar (A)

Dep. Incidentes

Lanar Alerta Lanar Alerta (A)

+

87

Validar Posicionamento
Operador Fim Indica ID Troo (S) Recebe Relatorio Alertas 5 min. para partida

Dep. Operaoes Consulta Informao Troo No

Procura Lista de Passageiros do Troo (A)

Localiza Passageiros (A)

Local Correcto? No

Sim

Ultimo Passageiro?

Sim

Envia Relatorio Alertas (A)

Troo Tag

Envia Alerta (A)

Dep. Incidentes Lana Alerta

Lana Alerta (A)

+

88

Anexo B

89