Agendamento de Protocolos de Tratamento
José Tiago Pereira de Carvalho
Relatório de Projecto
Mestrado Integrado em Engenharia Informática e Computação
Orientador: Ana Paula Rocha (Professora Auxiliar)
Agendamento de Protocolos de Tratamento
José Tiago Pereira de Carvalho
Relatório de Projecto
Mestrado Integrado em Engenharia Informática e Computação
Aprovado em provas públicas pelo Júri:
Presidente: Professor Doutor António Carvalho Brito (Professor Auxiliar da FEUP)
____________________________________________________
Arguente: Professor Doutor Carlos Costa (Professor Auxiliar da Universidade de
Aveiro)
Dedicatória
Todo o meu percurso académico e crescimento pessoal só foram possíveis graças ao apoio e dedicação dos meus pais, que sempre estiveram presentes nos momentos mais decisivos da minha vida. Por isso quero agradecer-lhes todos os esforços que fizeram por mim e dedicar-lhes esta tese, sem eles eu não teria conseguido chegar aqui.
Resumo
A presente tese de mestrado insere-se no contexto da área de saúde e trata toda a problemática associada ao Agendamento de Protocolos. O Agendamento de Protocolos, tal como o próprio nome sugere, consiste na marcação de um conjunto de actos médicos para um determinado paciente. Os actos médicos pertencentes a um Protocolo relacionam-se entre si e pretendem tratar em conjunto uma determinada patologia.
Na tese é investigada a relação existente entre o problema de agendamento de protocolos num hospital e o problema de agendamento de recursos no fabrico de um produto na área da indústria. Esta relação é analisada ao nível da definição da estratégia que permite resolver o problema de alocação dos recursos disponíveis às tarefas a cumprir.
Para além da análise conceptual do agendamento é também efectuada uma análise tecnológica, permitindo definir quais as tecnologias que melhor se adaptam à concretização do projecto proposto. As tecnologias ponderadas concentram-se em duas áreas distintas: a arquitectura da aplicação e a construção das interfaces. Para a arquitectura da aplicação são analisadas as Frameworks CAB (Composite UI Application Block) e PRISM (Composite
Application), enquanto na área das interfaces são analisadas as tecnologias WPF (Windows Presentation Foundation) e Windows Forms.
Em resultado da análise tecnológica efectuada surgiu a necessidade de desenvolver uma Infra-estrutura que permitisse criar aplicações independentemente da Framework base CAB ou PRISM. Fundamentalmente, a Infra-estrutura desenvolvida permite endereçar a problemática de integração com as soluções da empresa e ainda serve de plataforma para migração das soluções existentes para uma nova tecnologia.
Por último é importante realçar que foi depositada especial atenção nas questões de usabilidade, capacidade de manutenção e expansibilidade da aplicação. Tal justifica-se pelo facto da área onde o projecto se insere ser bastante volátil ao nível dos requisitos e ser necessário privilegiar a interacção com os utilizadores.
Abstract
This master's thesis urges from the context of healthcare and treats all the problems related to Protocol Scheduling. The Protocol Scheduling, as the name suggests, is about scheduling a set of medical procedures for a given patient. The medical procedures of a Protocol are related and together seek to treat a particular pathology.
In this thesis we research the relationship between the Healthcare Protocol Scheduling Problem and the Manufacturing Resource Scheduling Problem. The goal of this research is try to understand if the strategies used in the industry can be transposed for the hospitals.
Beyond the conceptual research on the schedule subject is also carried out an analysis in technology, allowing defining the technologies that best suit the implementation of the proposed project. The technologies selected address two main areas: the architecture of the application and the development of user interfaces. For the architecture of the application issue are considered two Frameworks: CAB (Composite UI Application Block) and PRISM (Composite Application). For the interface issue are considered two technologies: WPF (Windows Presentation Foundation) and Windows Forms.
As a result of the technology study, a new need emerged: the development of a new Infrastructure for building applications regardless the Framework base used (CAB or PRISM). The Infrastructure has the ability to deal with integration problems, simplifying the connection with the company solutions. Moreover, the infrastructure still supports the migration of existing solutions to a new technology.
At last it’s important to emphasize the special attention placed on issues like usability, maintenance and expansibility of the application. This is justified by the surrounding context of the project, that is quite volatile, and the need to enlarge and clarify interaction with users.
Agradecimentos
Em primeiro lugar queria agradecer a toda a minha família que me tem apoiado e ajudado ao longo de todo este processo de crescimento, com especial ênfase para a minha maninha e a minha afilhada linda.
Se a minha família me pôde acompanhar de perto ao longo de todo este processo houve quem não tivesse essa oportunidade, mas ainda assim desempenha um papel cada vez mais preponderante e decisivo na minha vida. O meu muito obrigado à mulher que me despertou para a vida, és e sempre serás o meu grande amor, Isabel Torres.
No final do meu percurso académico para além do conhecimento o que me resta são os bons momentos que passei com os meus amigos e as noitadas juntos a tentar contornar os desafios que foram surgindo. Para o Fernando Júnior, Francisco Correia, Hélder fontes, Hugo Zenha, João Silva, Micael Queiroz e Pedro Silva um grande abraço e o desejo que tenham uma carreira promissora e cheia de sucesso.
Todo o meu percurso académico também fica marcado pelos docentes que me acompanharam e ajudaram a desenvolver as minhas capacidades, fico-lhes extremamente grato por todo o vosso empenho e dedicação. Não posso deixar de destacar a Doutora Ana Paula Rocha por ter aceite o meu convite para orientadora e ter desempenhado esse papel de forma exímia, contribuindo assim para o sucesso do meu projecto.
Por último mas não menos importante, quero agradecer à empresa onde decorreu o meu projecto, Glintt-Hs, por ter-me proporcionado todas as condições necessárias para conseguir desenvolver o meu trabalho em harmonia. O Eng. Nuno Ribeiro teve um papel importante no meu percurso na empresa, ajudando-me a ultrapassar todas as contrariedades que foram surgindo.
Índice
1 Introdução ... 1 1.1 Contexto ... 1 1.2 Projecto ... 4 1.3 Motivação e Objectivos ... 5 1.4 Estrutura do Documento ... 6 2 Estado da arte ... 7 2.1 Agendamento ... 72.1.1 Definição do tipo do problema ... 7
2.1.2 Análise de Algoritmos para o Problema de Agendamento ... 10
2.1.2.1 Estudos apresentados pela comunidade científica ... 11
2.1.2.2 Conclusões ... 17
2.2 Padrões ... 18
2.2.1 Model View Controller ... 20
2.2.2 Model View Presenter ... 22
2.2.3 Supervising Controller ... 23 2.2.4 Observer ... 24 2.2.5 View Navigation ... 25 2.2.6 Inversion of Control ... 26 2.2.7 Conclusões ... 27 2.3 Revisão Tecnológica ... 28 2.3.1 Framework ... 28 2.3.1.1 Framework Vs Library ... 30 2.3.1.2 CAB ... 31 2.3.1.3 PRISM ... 40
2.3.2 Tecnologias orientadas à construção de interfaces ... 45
2.3.2.1 WPF ... 45
2.3.2.2 Windows Forms ... 48
2.3.3 Conclusões ... 49
3 Análise Tecnológica ... 51
3.1 Infra-estrutura de Migração ... 51
3.2.1.1 Testar a eficiência de CAB e PRISM a carregar as Views ... 53
3.2.2 Migração de uma solução em CAB para PRISM ... 56
3.2.3 Conclusões do estudo ... 56
3.3 Documentação da infra-estrutura de migração ... 57
3.3.1 ModuleInit ... 58 3.3.2 Controller ... 58 3.3.3 Presenter ... 60 3.3.4 WinFormsUserView e WPFUserView ... 61 3.3.5 CommandBroker ... 61 3.3.6 Event ... 62 3.3.7 EventBroker ... 62
3.4 Refactoring de CAB para a Infra-estrutura ... 63
3.4.1 ModuleInit ... 64
3.4.2 WorkItem ... 64
3.4.3 Commands... 66
3.4.4 Views ... 68
3.4.5 Events ... 70
3.5 Migrar um projecto de CAB para PRISM usando a Infra-estrutura ... 72
3.6 Testar a eficiência da Infra-estrutura ... 73
3.6.1 Comparar a Infra-estrutura com as soluções de raiz ... 74
3.6.1.1 CAB ... 74
3.6.1.2 PRISM ... 75
3.6.2 Comparar soluções CAB e PRISM ... 76
3.7 Conclusões ... 77
4 Descrição detalhada do projecto ... 79
4.1 Apresentação detalhada do problema ... 79
4.2 Requisitos do projecto ... 81
4.2.1 Processo de análise e validação ... 81
4.2.2 Requisitos funcionais ... 84
4.2.3 Requisitos não funcionais... 87
4.3 Casos de uso ... 88
4.3.1 Diagrama de casos de uso ... 88
4.3.2 Descrição dos actores ... 89
4.3.3 Descrição detalhada de um caso de uso ... 90
4.4 Arquitectura do projecto ... 92
4.4.1 Arquitectura lógica ... 93
4.4.2 Arquitectura física ... 94
4.5 Integração com a solução da empresa ... 95
5 Implementação ... 97
5.1 Estado actual da aplicação ... 97
6 Conclusões e Trabalho Futuro ... 101
6.1 Satisfação dos Objectivos ... 101
6.2 Trabalho Futuro ... 102
Bibliografia ... 105
A Descrição do Módulo de Marcação ... 111
A.1 Resumo ... 111
A.2 Apresentação do Contexto ... 111
A.3 Apresentação dos Ecrãs do Agendamento ... 112
B Descrição do Módulo de Prescrição e Agendamento ... 125
B.1 Resumo ... 125
B.2 Apresentação do Contexto ... 125
B.3 Apresentação dos ecrãs do módulo de prescrição e agendamento ... 126
C Protótipos do Módulo de Marcação... 131
C.1 Introdução ... 131
C.2 Protótipos e Descrição ... 131
C.3 Opinião do cliente em relação aos protótipos sugeridos ... 142
D Guidelines para migrar um módulo de CAB para PRISM ... 145
D.1 Estrutura base em CAB ... 145
D.2 Alterações no projecto de Infra-estrutura ... 146
Lista de Figuras
Figura 1.1 – Soluções disponibilizadas pela empresa ... 2
Figura 2.1 – Ilustração do funcionamento de um Algoritmo Genético ... 12
Figura 2.2 – Ilustração do funcionamento do algoritmo arrefecimento Simulado... 13
Figura 2.3 – Ilustração do funcionamento do algoritmo Arrefecimento Simulado ... 14
Figura 2.4 – Ilustração do funcionamento de um Algoritmo Memético ... 15
Figura 2.5 – Ilustração do funcionamento do algoritmo Ant Colony Optimization ... 17
Figura 2.6 – Diagrama de classes do MVC ... 20
Figura 2.7 - Diagrama de interacção dos componentes do MVC ... 21
Figura 2.8 – Modelo de classes do MVP ... 22
Figura 2.9 – Diagrama de interacção dos componentes do MVP ... 23
Figura 2.10 - Diagrama de interacção dos componentes do Supervising Controller ... 23
Figura 2.11 – Diagrama de comunicação entre Views e o Model... 25
Figura 2.12 – Modelo de comunicação entre Views ... 26
Figura 2.13 – Diagrama de dependências entre elementos ... 26
Figura 2.14 – Componentes base da Framework e respectiva ligação ... 33
Figura 2.15 – Diagrama hierárquico dos tipos de aplicações suportados por CAB ... 34
Figura 2.16 – Componentes da Shell ... 35
Figura 2.17 – Principais funções do Module ... 36
Figura 2.18 – Propriedades de um WorkItem ... 37
Figura 2.19 – Digrama do mecanismo de eventos ... 38
Figura 2.20 – Exemplo da estrutura hierárquica dos WorkItems ... 39
Figura 2.21 – Componentes de uma aplicação em PRISM... 42
Figura 2.22 – Estrutura de uma aplicação em PRISM ... 43
Figura 2.23 – Diagrama de construção de um módulo ... 44
Figura 2.24 – Diagrama da arquitectura de WPF ... 47
Figura 2.25 – Diagrama da arquitectura de Windows Forms... 48
Figura 3.1 – View do Menu ... 53
Figura 3.2 – View da Opção1 ... 54
Figura 3.3 – View da Opção2 ... 54
Figura 3.4 – View da Opção3 ... 55
Figura 3.5 – Gráfico de comparação do tempo necessário para abrir uma View de WPF em CAB e PRISM ... 55
CAB e PRISM ... 56
Figura 3.7 – Diagrama de alto nível da Infra-estrutura de migração ... 57
Figura 3.8 – Diagrama da estrutura de um ModuleInit ... 58
Figura 3.9 – Diagrama da estrutura de um Controller ... 59
Figura 3.10 – Simulação da hierarquia de WorkItems usando Containers ... 59
Figura 3.11 – Diagrama da estrutura de um Presenter ... 60
Figura 3.12 – Diagrama da estrutura de uma WinFormsUserView e uma WPFUserView . 61 Figura 3.13 – Diagrama da estrutura de um CommandBroker ... 62
Figura 3.14 – Diagrama da estrutura de um Event ... 62
Figura 3.15 – Diagrama da estrutura de um EventBroker ... 63
Figura 3.16 – Como migrar um projecto de CAB para PRISM usando a Infra-estrutura ... 73
Figura 3.17 – Comparação da abertura de Views de WPF com a Infra-estrutura ou com um projecto de raiz em CAB ... 74
Figura 3.18 - Comparação da abertura de Views de Windows Forms com a Infra-estrutura ou com um projecto de raiz em CAB ... 74
Figura 3.19 - Comparação da abertura de Views de WPF com a Infra-estrutura ou com um projecto de raiz em PRISM ... 75
Figura 3.20 - Comparação da abertura de Views de Windows Forms com a Infra-estrutura ou com um projecto de raiz em PRISM ... 75
Figura 3.21 – Comparar a abertura de Views em WPF usando a Infra-estrutura compilada em PRISM ou em CAB ... 76
Figura 3.22 - Comparar a abertura de Views em Windows Forms usando a Infra-estrutura compilada em PRISM ou em CAB ... 76
Figura 4.1 – Constituição de um protocolo ... 80
Figura 4.2 - Diagrama de casos de uso do módulo de prescrição e agendamento ... 88
Figura 4.3 – Diagrama de casos de uso do módulo de marcação ... 89
Figura 4.4 – Diagrama de actividades do caso de utilização ... 92
Figura 4.5 – Protótipo da interface de agendamento ... 92
Figura 4.6 – Diagrama da arquitectura lógica da aplicação ... 93
Figura 4.7 – Diagrama do acesso a dados ... 94
Figura 4.8 – Diagrama da arquitectura física da aplicação ... 95
Figura 4.9 – Módulo de agendamento no contexto do processo clínico ... 95
Figura 5.1 – Ecrã inicial do módulo de prescrição e agendamento ... 98
Figura 5.2 – Ecrã de confirmação dos critérios de inclusão e exclusão do protocolo ... 99
Figura 5.3 – Ecrã inicial do módulo de marcação... 100
Figura 5.4 – Ecrã de marcação do protocolo ... 100
Figura A.2.1 - Zonas envolventes do agendamento ... 112
Figura A.3.1 - Zonas do ecrã inicial ... 113
Figura A.3.2 - Componente que permite a listagem dos protocolos ... 114
Figura A.3.3 - Áreas funcionais de uma DataGrid ... 114
Figura A.3.4 - Zona de agrupamento ... 115
Figura A.3.5 - Exemplo de uma acção de agrupamento ... 116
Figura A.3.8 - Figura do componente com o cabeçalho em dias do ciclo ... 118
Figura A.3.9 - Figura do componente com o cabeçalho em dias do mês ... 118
Figura A.3.10 - Agregadores de tarefas do protocolo ... 118
Figura A.3.11 - Figura ilustrativa da organização dos agregadores e da informação que contêm ... 119
Figura A.3.12 - Resumo da marcação das tarefas mestres ... 119
Figura A.3.13 - Janela de selecção de horários ... 119
Figura A.3.14 - Grelha listada por recursos ... 120
Figura A.3.15 - Grelha agregada por tipo dos recursos ... 120
Figura A.3.16 - Exemplo de marcação de duas sessões ... 121
Figura A.3.17 - Exemplificação da funcionalidade de arrastamento de uma sessão ... 121
Figura A.3.18 - Ilustração inicial das duas vistas antes de efectuar a movimentação ... 122
Figura A.3.19 - Deslocamento de uma marcação ... 122
Figura A.3.20 - Ilustração final das duas vistas depois de efectuar o deslocamento ... 123
Figura A.3.21 - Hierarquia dos componentes ... 124
Figura B.2.1 - Zonas envolventes do agendamento ... 126
Figura B.3.1 - Ecrã inicial da prescrição e agendamento ... 127
Figura B.3.2 - Zona de listagem dos protocolos do paciente ... 128
Figura B.3.3 - Área de trabalho do ecrã de prescrição e agendamento ... 128
Figura B.3.4 - Divisão da área de trabalho em zonas ... 128
Figura B.3.5 - Ecrã de confirmação dos critérios de inclusão e exclusão de um protocolo ... 129
Figura B.3.6 - Zona de confirmação dos critérios de inclusão e exclusão do protocolo ... 130
Figura C.2.1 - Ecrã inicial do módulo de gestão de conflitos ... 132
Figura C.2.2 - das principais zonas do ecrã inicial do módulo de gestão de conflitos... 132
Figura C.2.3 - Demonstração dos agregadores no ecrã inicial ... 133
Figura C.2.4 - Filtros da listagem de protocolos ... 134
Figura C.2.5 - Demonstração da utilização dos filtros ... 134
Figura C.2.6 - Ecrã de marcação de um protocolo... 135
Figura C.2.7 - Divisão do ecrã de marcação de protocolos ... 136
Figura C.2.8 - Ilustração da propriedade “Dias do” ... 137
Figura C.2.9 - Ilustração da propriedade “Mostrar Folgas” ... 138
Figura C.2.10 - Ilustração da propriedade “Actos já marcados”... 138
Figura C.2.11 - Ilustração da propriedade “Suprimir dias sem tarefas” ... 139
Figura C.2.12 - Ilustração da alteração do horário de uma marcação ... 140
Figura C.2.13 - Ilustração do arrastamento em bloco de um conjunto de actividades... 140
Figura C.2.14 - Ecrã de marcação na perspectiva de um dia apenas ... 141
Figura C.2.15 - Alteração do tempo que cada uma das células representa ... 142
Figura D.1.1 - Modelo de referência usado em CAB ... 146
Figura D.1.2 - Ilustração da comunicação entre views ... 146
Lista de Tabelas
Tabela 3.1 – Paralelismo entre código do ModuleInit em CAB e na Infra-estrutura ... 64
Tabela 3.2 – Paralelismo entre o código de criação/lançamento de um WorkItem em CAB e na Infra-estrutura ... 65
Tabela 3.3 - Paralelismo entre o código que permite criar/mostrar uma View a partir de um WorkItem em CAB e na Infra-estrutura ... 65
Tabela 3.4 – Paralelismo entre a injecção de estado num WorkItem em CAB e na Infra-estrutura ... 66
Tabela 3.5 – Paralelismo entre registar o handler de comando em CAB e na Infra-estrutura ... 67
Tabela 3.6 – Paralelismo entre a associação de um comando a um botão em CAB e na Infra-estrutura ... 68
Tabela 3.7 – Paralelismo entre a execução de um comando em CAB e na Infra-estrutura 68 Tabela 3.8 – Paralelismo entre a declaração de uma View de Windows Forms em CAB e na Infra-estrutura ... 69
Tabela 3.9 – Paralelismo entre a declaração de uma View de WPF em CAB e na Infra-estrutura ... 69
Tabela 3.10 – Alterações efectuadas ao XAML da View em CAB para usar a Infra-estrutura ... 70
Tabela 3.11 – Paralelismo entre a publicação de um Evento em CAB e na Infra-estrutura 71 Tabela 3.12 – Paralelismo entre a subscrição de um evento em CAB e na Infra-estrutura 71 Tabela 3.13 – Paralelismo entre a subscrição do evento StateChanged em CAB e na Infra-estrutura ... 72
Tabela 4.1 – Requisitos funcionais do módulo de prescrição e agendamento ... 84
Tabela 4.2 - Requisitos funcionais do módulo de marcação ... 85
Tabela 4.3 – Descrição do caso de uso Marcar Sessão ... 90
Tabela D.3.1 Correspondência de conceitos entre CAB e PRISM ... 147
Tabela D.3.2 - Diferenças na inicialização do módulo (recepção de propriedades) ... 148
Tabela D.3.3 - Como migrar a criação e lançamento de um WorkItem ... 149
Tabela D.3.4 - Particularidades do construtor do Controller em PRISM ... 150
Tabela D.3.5 - Como migrar a criação e activação de uma View ... 150
Tabela D.3.6 - Como injectar estado num Controller em PRISM ... 151
Tabela D.3.7 - Como injectar estado numa View em PRISM ... 151
Tabela D.3.10 - Como migrar a associação de um comando a um botão ... 153 Tabela D.3.11 - Como migrar a execução de um comando ... 153 Tabela D.3.12 - Exemplificação da eliminação da propriedade SmartPart da View ... 153 Tabela D.3.13 - Exemplificação das alterações necessárias na criação do Presenter da View ... 154
Tabela D.3.14 - Como registar as WorkSpaces de uma View (Forms) em PRISM ... 154 Tabela D.3.15 - Como registar as Regions de uma View (WPF) ... 154 Tabela D.3.16 - Como injectar o WorkItem na View ... 155 Tabela D.3.17 - Como migrar a publicação de um evento ... 156 Tabela D.3.18 – Como migrar a subscrição de um evento... 156 Tabela D.3.19 - Como migrar a subscrição de um serviço ... 157 Tabela D.3.20 - Como migrar a execução de um serviço ... 158 Tabela D.3.21 - Como migrar o registo da Shell nos UIExtensionSites ... 158 Tabela D.3.22 - Como aceder ao UIExtensionSites da Shell e adicionar um novo elemento ... 159
Abreviaturas e Símbolos
ACO Ant Colony OptimizationAPI Application Programming Interface ASP Active Server Pages
BD Base de dados
CAB Composite UI Application Block CRUD Create Read Update and Delete
FEUP Faculdade de Engenharia da Universidade do Porto FIFO First In First Out
FSSP Flow Shop Scheduling Problem GA Genetic Algorithms
Glintt - Hs Global Intelligent Technologies - Healthcare Solutions GPRS General Packet Radio Service
HTML Hyper Text Markup Language IoC Inversion of Control
ISO International Organization Standardization JSSP Job Shop Scheduling Problem
KISS Keep It Simple, Stupid
MA Memetic algorithms
MIEIC Mestrado Integrado em Engenharia Informática e Computação MVC Model View Controller
MVP Model View Presenter
OSSP Open Shop Scheduling Problem PRISM Composite Application Library RDA Rich Desktop Applications
SA Simulated Annealing
TS Tabu Search
UI User Interface
WPF Windows Presentation Foundation XAML eXtensible Application Markup Language XML eXtensible Markup Language
Glossário
CAB A Composite UI Application Block é uma Framework desenvolvida pela Microsoft que permite desenvolver aplicações complexas baseadas em Windows Forms. Esta Framework fornece uma arquitectura que reúne um conjunto de padrões que facilitam a construção de aplicações modulares, de fácil manutenção e extensíveis.
Framework Uma Framework é um conjunto de conceitos que pretende evidenciar o comportamento de um tipo de aplicações, para um dado contexto. Uma Framework fornece um esqueleto de uma aplicação que pretende ser o ponto de partida para o seu desenvolvimento.
Infra-estrutura de Migração
Infra-estrutura que permite desenvolver aplicações independentemente da Framework base, CAB ou PRISM. A Infra-estrutura é da autoria do José Carvalho e Luís Ponte.
UI Uma User Interface também conhecida por Human Computer
Interface é a ponte entre o utilizador e o sistema. Através de uma Interface os sistemas informáticos conseguem transmitir informação
para os utilizadores e receber indicações da sua manipulação.
MVP O Model View Presenter é um padrão que define a organização de uma UI de uma aplicação. Através do MVP é possível construir interfaces mais modulares e de fácil manutenção.
Padrão Um padrão é um conjunto de conceitos extraídos do conhecimento prático do dia-a-dia que ilustram uma solução para um tipo de problema.
PRISM Composite Application é o nome de uma biblioteca desenvolvida pela
Microsoft que pretende agilizar a construção de aplicações em WPF e
Silverlight. À semelhança de CAB também PRISM oferece uma
arquitectura que permite desenvolver aplicações modulares, extensíveis e de fácil manutenção.
Windows Forms Windows Forms foi o nome dado à API de desenvolvimento de
interfaces.
WPF Windows Presentation Foundation é o novo subsistema gráfico do
Windows Vista. WPF é usado para construir interfaces mais complexas e ricas (RDA – Rich Desktop Applications).
1 Introdução
O presente relatório tem como objectivo documentar o projecto de final de curso elaborado no contexto do Mestrado Integrado de Engenharia Informática e Computação (MIEIC) realizado na Faculdade de Engenharia da Universidade do Porto (FEUP). O título do projecto é Agendamento de Protocolos de Tratamento e foi realizado em parceria com a empresa Global Intelligent Technologies - Healthcare Solutions (Glintt – HS).
O projecto enquadra-se na área da saúde e pretende agilizar algumas das rotinas diárias do pessoal hospitalar. Ao mecanizar essas tarefas pretende-se que o pessoal hospitalar se foce mais nas tarefas em que realmente são especializados/necessários, contribuindo assim para a qualidade do atendimento aos pacientes.
A rotina de um hospital passa por gerir eficazmente a relação entre os seus recursos e os seus pacientes, tentando assim diminuir o tempo de resposta e aumentar a qualidade dos serviços. É nesse contexto que se enquadra este projecto, pretendendo desenvolver uma aplicação que permita marcar novos protocolos para um paciente e depois agendar os procedimentos que o constituem.
Este capítulo pretende dar um enquadramento geral do projecto, descrever as suas motivações, os seus objectivos e a estruturação geral do documento. Através deste capítulo pretende-se que o leitor seja capaz de perceber a dimensão do projecto, bem como o seu contexto.
1.1
Contexto
Para começar é importante descrever mais detalhadamente a empresa onde decorreu o projecto. Como já foi referido, a empresa denomina-se Glintt – HS e opera na área da saúde. O seu principal mercado alvo são os hospitais portugueses embora os seus negócios já se estejam a alargar ao mercado internacional, nomeadamente, Espanha, Angola e América Latina. As principais actividades da empresa incluem:
A prestação de serviços, desenvolvimento, manutenção e suporte de aplicações informáticas na área dos Sistemas de Informação, com especial ênfase no domínio das Tecnologias da Saúde e Gestão Hospitalar.
O licenciamento, implementação, parametrização, formação e consultoria, seja de produtos próprios ou representados.
A consultoria e gestão de projectos.
A venda de soluções integradas de Sistemas de informação.
Na figura seguinte (Figura 1.1) é possível verificar a panóplia de soluções informáticas que a empresa já oferece. Pode-se verificar que a empresa já disponibiliza uma solução abrangente que pretende endereçar a maioria das problemáticas encontradas num hospital, oferecendo assim uma solução completa e totalmente integrada.
Figura 1.1 – Soluções disponibilizadas pela empresa
O projecto descrito neste relatório será integrado na área do processo clínico e pretende complementar as funcionalidades oferecidas por um módulo já existente (módulo presente na parte superior direita da figura anterior). O processo clínico é um sistema integrado de informação clínica, que pretende dotar os profissionais clínicos de uma ferramenta de registo de informação clínica. O seu principal objectivo é fornecer o acesso a toda a informação clínica dos doentes necessária para prestar cuidados de saúde de qualidade.
Tendo em conta as tendências do mercado onde a empresa está inserida, em que cada vez mais a oferta é à escala mundial e diversificada, é necessário reunir um conjunto de factores que a realcem face á concorrência. Um dos caminhos possíveis será a aposta na qualidade do software.
A construção de bom software não é uma tarefa trivial e subentende a concordância com um conjunto de factores que o regulam. A qualidade de um produto pode ser medida através de quatro factores preponderantes [Som04]:
Flexibilidade – O software deve ser desenvolvido de tal forma que seja fácil dar resposta a alterações solicitadas pelo cliente. Este factor é crítico na construção de software, porque a alteração dos requisitos de uma aplicação é quase inevitável, quer
seja fruto das alterações ocorridas no ambiente envolvente do negócio quer seja por falta de concordância com as necessidades do cliente.
Confiança – A confiança numa aplicação é uma característica extremamente importante, porque reflecte a capacidade de uma aplicação em não causar danos físicos ou monetários na eventualidade de ocorrer uma falha no sistema. As características que normalmente estão associadas à confiança numa aplicação são a segurança e a fiabilidade. A segurança pode ser vista por dois primas, quer pela probabilidade de não ocorrerem erros, quer pela protecção da informação que a aplicação contém. A fiabilidade é a capacidade de um sistema funcionar correctamente durante um determinado período de tempo e sob um determinado conjunto de condições de operação.
Eficiência – O software não deve desperdiçar os recursos que estão ao seu dispor. A eficiência inclui o tempo de resposta de uma aplicação, o tempo que demora a processar e a quantidade de memória usada, entre outros factores. De nada serve ter uma aplicação que cumpre com os requisitos estabelecidos se depois na prática não fornece respostas em tempo útil.
Usabilidade – Durante a construção de software é necessário ter preocupações ao nível da sua usabilidade, adequando-o ao segmento de utilizadores ao qual se destina. A adaptação do software aos seus destinatários implica o desenvolvimento de uma interface e documentação apropriada. Os utilizadores finais da aplicação devem ser capazes de interagir com esta de forma fácil e intuitiva, dissipando assim possíveis ambiguidades que possam existir.
Os factores anteriores são todos preponderantes para o sucesso de um produto de software, mas no âmbito deste projecto foi dada uma ênfase especial à flexibilidade e à usabilidade. A flexibilidade é fruto do reconhecimento, da empresa e do autor deste documento, da necessidade de acompanhar a volatilidade dos requisitos. Durante o ciclo de desenvolvimento do software é necessário haver uma adaptação gradual aos novos detalhes que vão inevitavelmente surgindo. Os requisitos normalmente alteram-se devido a dois factores:
Dificuldades na fase de levantamento de requisitos – nesta fase, as dificuldades podem surgir por: dificuldade na interacção com o cliente, o cliente não consegue expressar claramente o que pretende; o cliente ainda não sabe muito bem o que quer ou a equipa de levantamento de requisitos considera erradamente que sabe o que o cliente realmente pretende.
Alteração do ambiente de negócio – no decorrer do projecto o ambiente que rodeia o negócio do cliente pode sofrer algumas alterações, sendo necessário reflecti-las na aplicação que está a ser desenvolvida.
Outra justificação para a aposta da empresa na flexibilidade do software surge derivado a estratégia que delineou. A empresa aposta em metodologias ágeis de construção de software, conseguindo assim encurtar o time to market 1dos seus produtos.
1
A aposta na usabilidade deve-se mais uma vez ao reconhecimento conjunto, da empresa e do autor, da importância de estabelecer um bom canal de comunicação entre a aplicação e os utilizadores. De que serve ter uma aplicação capaz de responder a todas as necessidades dos seus utilizadores, se no final eles não conseguem interagir com ela. Segundo a norma ISO 9241-11 [ISO98], a construção de aplicações intuitivas e fáceis de utilizar é um grande desafio. A construção de interfaces deve privilegiar a experiência dos utilizadores, simplificando ao máximo todas as funcionalidades que oferece. As interfaces devem ser desenvolvidas de acordo com o público-alvo, o tipo de actividades onde estão inseridas e o contexto de utilização. Uma interface de qualidade caracteriza-se por oferecer uma curva de aprendizagem reduzida e originar uma baixa percentagem de erros por parte dos utilizadores.
1.2
Projecto
Tal como já foi referido na introdução, o projecto incide na área da saúde e pretende agilizar o mecanismo de agendamento de protocolos. O conceito de protocolo na área da saúde é utilizado para ilustrar uma estratégia de combate a uma determinada patologia. Um protocolo não é um conceito trivial de mapear, pelo contrário, um protocolo é composto por um conjunto de actividades diversas, que podem englobar exames, administração de medicamentos, consultas, etc. Para além das actividades, o protocolo também contém um conjunto de restrições que regulam as actividades que o integram. As restrições do protocolo vão desde a dosagem de medicamentos a tomar, a sua periodicidade, frequência, etc.
O projecto reportado neste documento subentende a construção de dois módulos, um módulo de agendamento de protocolos e um módulo de gestão de conflitos. O módulo de agendamento de protocolos consiste numa aplicação que permite agendar as tarefas de um dado protocolo para um determinado paciente. O agendamento de protocolos é uma tarefa complexa, na medida em que implica encontrar um conjunto de recursos que satisfaçam as necessidades das actividades e que ao mesmo tempo respeitem o conjunto de restrições que o protocolo define. Os recursos de um hospital podem ser materiais ou humanos e na maior parte das vezes é preciso conjugá-los para conseguir obter uma vaga.
O módulo de gestão de conflitos entra em plano quando a tentativa de marcar um protocolo não é bem sucedida, derivado à inexistência de vagas que o satisfaçam. Nessas situações é preciso analisar mais cuidadosamente as vagas disponíveis e na pior das hipóteses forçar a marcação de algumas actividades. Os clientes de um hospital são vidas humanas e na maior parte das vezes é simplesmente impossível informá-los que não existem vagas disponíveis ou retardar demasiadamente os seus tratamentos. O impacto de uma decisão desse género poderia ter efeitos nefastos, conduzindo à deterioração do estado clínico de um paciente. Como um hospital não se pode dar ao luxo de ocorrer uma situação dessas é preciso ter uma gestão eficaz e controlada dos recursos existentes, porque eles são demasiadamente preciosos para serem desperdiçados ou mal aproveitados. O módulo de gestão de conflitos deve ser manual e é direccionado para o pessoal administrativo ou enfermeiros.
O módulo de agendamento, pelo contrário, é direccionado para os médicos, que apenas necessitam de uma aplicação que opere automaticamente e forneça uma solução final que respeite as condições que eles indicam.
1.3
Motivação e Objectivos
A motivação deste projecto é tentar encontrar um mecanismo que permita facilitar todo o processo de agendamento de protocolos hospitalares. Considera-se que esta vertente das soluções hospitalares, fornecida pela empresa, tem sido colocada um pouco de parte. Caso se reflicta um bocado facilmente se chega à conclusão que é uma lacuna importante do software existente, uma vez que a base do funcionamento de um hospital são os seus recursos e os pacientes. Através deste projecto pretende-se agilizar todo o processo de agendamento de protocolos, facilitando assim a tarefa do pessoal hospitalar e melhorando os serviços prestados aos pacientes. A principal fonte de lucro de um hospital são os seus pacientes, por isso é natural que a maior parte dos esforços de um hospital sejam na direcção de melhorar a qualidade dos seus serviços. Uma gestão mais eficaz dos recursos do hospital conduz a uma melhoria da sua capacidade de resposta.
O principal objectivo deste projecto é conseguir construir tal aplicação com um elevado grau de usabilidade. O facto de ser difícil traçar o perfil do utilizador que irá interagir com o sistema, conduz a cuidados redobrados na construção da interface. Pretende-se construir uma interface simples e intuitiva, através da qual o utilizador seja capaz de facilmente perceber como interagir. Por outro lado, também se pretende conseguir uma interface poderosa que consiga reunir todas as funcionalidades necessárias para levar a cabo as acções pretendidas. O equilíbrio entre a simplicidade e a conjugação de uma panóplia de funcionalidades num só ecrã não é uma tarefa fácil, perspectivando-se uma longa fase de análise e construção de protótipos.
Em segundo lugar surge a questão da flexibilidade e da integração com os produtos já existentes na empresa. É necessária uma análise cuidada da tecnologia a adoptar para a construção da aplicação. A empresa está numa fase de mudança e pretende avaliar as vantagens e desvantagens de continuar a utilizar a tecnologia actual. Foi proposta uma análise cuidada em relação a esta temática, tendo em atenção os custos inerentes à migração de todas as soluções existentes para uma nova plataforma. A evolução da tecnologia utilizada pela empresa para desenvolver software é inevitável, mas se esta é a altura certa, se este projecto já deverá ser abrangido, são algumas das questões que devem ser respondidas com a análise a efectuar.
Para conseguir dar uma resposta eficaz aos objectivos propostos para o projecto, foi delineado um plano que define as diversas etapas a ser cumpridas.
A primeira etapa consiste no estudo das tecnologias propostas para o projecto. Uma vez concluída a etapa da análise tecnológica, é hora de passar à definição do produto. Nesta etapa é feita uma análise cuidada das necessidades do cliente, existindo uma preocupação redobrada na sua validação. A análise das necessidades do cliente é muito importante e foi efectuada com o auxílio de protótipos, uma vez que são um meio eficaz de esclarecer as necessidades e propor novas formas de resolução do problema. Por último surge a etapa de desenvolvimento e testes, que não é incluída neste projecto, mas estima-se que seja facilitada devido à exaustiva fase de análise.
1.4
Estrutura do Documento
Para além da introdução, este documento contém mais cinco capítulos. No capítulo 2, é feita uma descrição exaustiva do estado da arte, evidenciando todos os temas que foi necessário analisar para conseguir concluir o projecto com sucesso. O capítulo 3 apresenta a análise tecnológica do projecto, incluindo documentação da estrutura de migração criada. A Infra-estrutura surgiu da necessidade de criar uma plataforma de integração entre a tecnologia utilizada na empresa e a tecnologia considerada pelo autor como a mais indicada para o desenvolvimento do projecto. O capítulo 4 descreve de forma detalhada o problema, indo desde a exposição dos casos de uso do projecto até à apresentação da arquitectura do projecto. O capítulo 5 contém a descrição do estado actual da aplicação, proporcionando uma perspectiva geral do cumprimento dos objectivos. O capítulo 6 apresenta a conclusão, em que é descrito o grau de satisfação dos objectivos propostos e o planeamento de possíveis trabalhos futuros.
Este documento contém ainda quatro anexos. O anexo A é a descrição detalhada do módulo de marcação, pretende-se através deste anexo apresentar as interfaces do módulo e explicar as suas funcionalidades. O anexo B é similar ao anexo A, só que neste caso é apresentado o módulo de prescrição e agendamento de um protocolo. O anexo C apresenta o conjunto de protótipos inicialmente produzidos para o módulo de marcação. Por último surge o anexo D que é a cópia integral de um documento produzido para a empresa. Esse documento contém um conjunto de passos necessários para migrar um módulo de CAB para PRISM e foi produzido durante a fase de análise tecnológica.
2 Estado da arte
Neste capítulo é apresentada toda a investigação efectuada no intuito de conseguir as bases para poder elaborar o projecto. O estado da arte é composto por três partes. A primeira parte foca a análise do problema de agendamento inerente ao projecto e pretende fornecer algumas bases para a descoberta de um possível caminho a seguir. A segunda parte descreve um conjunto de padrões que foram importantes na definição da arquitectura da aplicação. Na terceira e última parte é apresentada toda a informação recolhida sobre as tecnologias ponderadas para utilização neste projecto.
2.1
Agendamento
Este subcapítulo apresenta toda a pesquisa efectuada no contexto da resolução do problema de agendamento de um protocolo. Esta análise dividiu-se em duas fases: numa primeira fase tentou-se verificar se este tipo de problema já era reconhecido pela comunidade científica e se já existia alguma abordagem recomendada; numa segunda fase pesquisou-se um conjunto de algoritmos passíveis de utilização e capazes de dar uma resposta efectiva ao problema.
2.1.1 Definição do tipo do problema
Uma parte do problema proposto para a actual tese de mestrado caracteriza-se pela necessidade de um algoritmo que permita agendar um protocolo médico de tratamento de um doente. O processo de agendamento deve tentar melhorar a qualidade de vida dos pacientes, optimizando a marcação dos protocolos (procurando minimizar o tempo dos pacientes no hospital). Um protocolo médico é constituído por um conjunto de procedimentos que necessitam ser marcados na agenda de um hospital, respeitando as vagas disponíveis e os recursos necessários para os satisfazer. Um protocolo médico é pouco flexível e estabelece um conjunto de dependências entre os procedimentos que o compõem. O tempo necessário para cumprir cada procedimento é estático e inclui o tempo de preparação. Quando um paciente
executa mais do que um procedimento seguido num mesmo recurso, então é necessário subtrair os tempos adicionais de preparação. Um hospital é composto por um conjunto de serviços que por sua vez contém um conjunto de recursos. Cada recurso (humano ou físico) é capaz de satisfazer um conjunto de procedimentos, sendo que, para cada procedimento pode haver mais do que recurso habilitado para o cumprir.
Resultante da procura realizada no intuito de tentar encontrar uma solução para o problema de agendamento de protocolos na área da saúde, encontrou-se um paralelismo com as problemáticas existentes na área da indústria. Numa indústria também é necessário escalonar um conjunto de recursos para produzir um conjunto de produtos, sendo que, à produção de cada produto está a associado um conjunto de tarefas. A esta problemática chama-se agendamento, e assume um papel preponderante no contexto de uma empresa, podendo ser um factor de vantagem competitiva face à concorrência. Esta opinião é também expressa por Blum [Blu02], quando afirma que o agendamento trata da alocação de recursos escassos a tarefas ao longo do tempo. O agendamento é um processo de decisão que pretende optimizar um ou mais objectivos.
O agendamento na indústria é uma tarefa complexa e pode ser enquadrada em diversos contextos. A distinção entre os diversos contextos pode ser efectuada segundo um conjunto de características, sendo as mais relevantes [Xha08]:
Distribuição da chegada dos pedidos – pode ser considerada estática ou dinâmica, dependendo se os pedidos chegam todos ao mesmo tempo, ou se são dispersos tempo-ralmente.
Política de gestão do inventário - um plano pode ser considerado aberto, se os produ-tos são todos feiprodu-tos por encomenda, ou fechado, se todos os produprodu-tos são feiprodu-tos para stock.
Atributos dos trabalhos – os planos são classificados como determinísticos, se os recursos e os pedidos estão definidos à priori, caso contrário são classificados como probabilísticos. Outra característica importante dos pedidos, que condiciona a organiza-ção da fábrica, é a necessidade de um produto ser processado por uma ou várias máqui-nas. Essa necessidade depende da constituição de um produto, ou seja, das tarefas que o constituem. Caso os produtos apenas necessitem de uma máquina, então o ambiente da fábrica é considerado de apenas um estado, caso contrário, é multi-estado.
Atributos gerais – o número de máquinas necessárias, o número de pedidos e o percur-so efectuados pelos produtos, são mais algumas propriedades importantes na caracteri-zação de um processo de agendamento de uma fábrica.
Da conjugação das características do agendamento do plano de produção na fábrica destacam-se três tipos de problemas, sendo esses os mais referenciados na bibliografia científica: Flow Shop Scheduling Problem (FSSP); Job Shop Scheduling Problem (JSSP) e
Open Shop Scheduling Problem (OSSP). Esses tipos evidenciam-se pela sua complexidade
(NP-Difícil) e pelo seu enquadramento no plano real.
Aos tipos de problema apresentados pode ser ainda adicionada outra característica (Flexible) que permite a duplicação dos recursos existentes, introduzindo o conceito de grupo. Um grupo é composto por um conjunto de máquinas que desempenham tarefas idênticas,
máquinas essas que funcionam em paralelo e permitem aumentar a produtividade de uma operação.
Em todos estes problemas de agendamento existe um objectivo comum, pretende-se alocar um conjunto de tarefas aos recursos existentes, optimizando alguns factores. Os factores a optimizar podem ir desde: maximizar a taxa de ocupação de cada recurso; diminuir o tempo necessário para produzir cada produto; maximizar o número de produtos que é possível fabricar num dia ou diminuir os custos associados ao ciclo de produção de um produto.
Os parágrafos seguintes descrevem de forma sumária os três tipos de problemáticas enumeradas.
Flow Shop Scheduling Problem (FSSP)
No FSSP parte-se do pressuposto que existe um conjunto de máquinas em série. Todos os produtos têm de ser processados por cada uma das máquinas segundo uma ordem preestabelecida, isto é, todos os processos devem iniciar o processamento na máquina um, seguir para a máquina dois e assim sucessivamente. Adicionalmente, cada um dos produtos só pode ser processado numa máquina de cada vez e as máquinas, também só podem processar um produto por instante. As operações nas máquinas são atómicas, não podendo ser interrompidas. Considera-se que o tempo de preparação da máquina para efectuar uma operação já está incluído no tempo da operação. Depois de um produto completar uma tarefa numa máquina deve seguir para a seguinte, ficando momentaneamente à espera de ser processado. Normalmente, as filas de espera das máquinas seguem o princípio de o primeiro a chegar é o primeiro a sair (FIFO – First In First Out).
Job Shop Scheduling Problem (JSSP)
Tal como no FSSP, o JSSP também parte do pressuposto de que existe um conjunto de produtos que necessitam de ser processados por um conjunto de máquinas. No JSSP mais tradicional todos os produtos têm de ser processados por todas as máquinas, embora para cada tipo de produto possa estar associado um percurso diferente. Existe uma distinção entre o JSSP em que cada produto pode revisitar uma máquina ao longo do seu percurso e o JSSP que não permite, sendo que no primeiro caso diz-se que permite recirculação. As restantes considerações efectuados para o FSSP também são válidas para o JSSP.
Open Shop Scheduling Problem (OSSP)
O OSSP é um caso especial do JSSP. No OSSP não existe nenhuma sequência predefinida de operações para cada produto, cada produto tem apenas um conjunto de operações que precisa de cumprir. Esta característica alarga drasticamente a dimensão do espaço de procura, face ao JSSP em circunstâncias semelhantes (o mesmo número de máquinas e operações). Mais uma vez todas as considerações efectuadas para o modelo anterior são válidas para este [Pin08].
Conclusões
Com base na apresentação e identificação dos pressupostos dos três tipos de agendamento mais comuns na área da indústria, pode-se concluir qual é o mais adequado ao problema em análise nesta tese.
Considerando que os protocolos médicos são muito vastos, que cada protocolo é constituído por diversas combinações de tarefas e as tarefas entre si possuem uma ordem pré-estabelecida, o processo de agendamento que melhor caracteriza esta situação é o JSSP.
2.1.2 Análise de Algoritmos para o Problema de Agendamento
Tendo em conta o processo de agendamento seleccionado no subcapítulo anterior (JSSP), são apresentadas e analisadas algumas das propostas feitas pela comunidade científica para a resolução do agendamento em JSSP.
Antes de escolher qualquer tipo de algoritmo para tentar solucionar o problema, é necessário definir um conjunto de regras que regulam o problema. Por exemplo, antes de poder associar um produto aos recursos é necessário definir o tipo de recursos que ele necessita e qual a sua ordem. Tal como, também é preciso indicar que tarefas cada um dos recursos é capaz de executar e qual a sua capacidade. Este tipo de regras define o espectro do problema e permite ajudar o algoritmo a validar as soluções. Normalmente, este tipo de regras estão definidas na função de avaliação, cujo papel é avaliar a qualidade das soluções. A qualidade de uma solução pode ser vista por dois prismas: a consonância com as restrições do problema e a valorização das características que se pretende optimizar.
Os algoritmos citados na literatura para a resolução de problemas de agendamento são normalmente algoritmos de optimização. Nos problemas de optimização já existe inicialmente uma solução para o problema, solução essa que o algoritmo tenta optimizar. As soluções alternativas são validadas através de uma função de avaliação que mede a qualidade da solução para o problema a resolver.
Um dos caminhos possíveis para resolver os problemas de optimização de um JSSP pode ser a utilização de meta-heurísticas. Uma meta-heurística é um processo iterativo que coordena um conjunto de heurísticas, tendo por objectivo produzir uma solução de maior qualidade [OL96].
A utilização de meta-heurísticas facilmente se justifica pelo facto de a optimização de um JSSP ser um problema de complexidade NP-difícil. A utilização de métodos exactos para resolver problemas de optimização combinatória na maior parte das vezes requer tempos de processamento impraticáveis [Xha08]. Um algoritmo normal não consegue alcançar uma solução num espaço de tempo razoável.
As meta-heurísticas são uma estratégia de alto nível, que permite balancear uma exploração diversificada (tentar explorar todo o espaço de procura) com uma exploração mais focada e especializada (intensificar a procura num local). Este equilíbrio é importante porque permite identificar rapidamente as zonas em que existem soluções de melhor qualidade, restringindo assim o espaço de procura. Uma vez identificadas as zonas com maior probabilidade de encontrar uma boa solução é possível intensificar a procura nessas zonas e alcançar uma melhor solução [Xha08].
2.1.2.1
Estudos apresentados pela comunidade científica
Algumas das soluções apresentadas pela comunidade científica que utilizam a abordagem sugerida são enumeradas nos pontos seguintes:
Algoritmos Genéticos [YZFGW08] [FB91] [Xha08] Algoritmos Genéticos e Pesquisa Tabu [ZSG08] Arrefecimento Simulado [KGR95] [Xha08] Algoritmos Meméticos [CF08] [Xha08]
Ant Colony Optimization [MZ99] [PXH04] [Xha08]
De seguida é apresentada uma breve descrição da lógica inerente a cada um dos algoritmos enumerados.
Algoritmos genéticos
Os algoritmos genéticos (Genetic Algorithms - GA) são uma técnica probabilística de pesquisa, que tem as suas raízes nos princípios da genética. John Holland é o nome do pai dos GA, ele desenvolveu os seus princípios base por volta dos anos 60 e 70. Segundo Falkenauer e Bouffouix [FB91], a grande inovação de Holland foi seguir os princípios da natureza na sua busca por espécies cada vez mais adaptadas ao ambiente. Os GA são inspirados nas capacidades da natureza de evoluir os seres vivos, adaptando-os ao seu meio ambiente.
Os algoritmos genéticos são caracterizados como um modelo computacional evolutivo. O modelo é constituído por uma população, em que cada elemento é representado por um cromossoma. Um cromossoma representa uma possível solução para o sistema e deve respeitar as restrições do problema. O modelo evolui segundo os princípios da evolução natural, em que os elementos da população são cruzados dando origem a novos elementos que constituem uma nova população, população esta que constitui novas soluções para o problema. O algoritmo parte do pressuposto que a consecutiva combinação da sua população conduzirá a uma melhor solução.
Para que a combinação da população traga frutos ela não pode ser feita de forma leviana, ou pelo menos a maior parte das vezes não. Na figura seguinte (Figura 2.1) pode-se ver um diagrama ilustrativo do funcionamento do algoritmo.
Figura 2.1 – Ilustração do funcionamento de um Algoritmo Genético
Em cada iteração do algoritmo (Figura 2.1) um conjunto de operadores é aplicado a alguns elementos da população, construindo assim os elementos da próxima geração. Normalmente, o algoritmo utiliza dois tipos de operadores: o cruzamento e a mutação. O cruzamento é utilizado na geração de novos elementos pela combinação de dois ou mais elementos da população, conjugando a sua informação. A mutação, tal como o próprio nome sugere, é aplicado de forma individual e permite modificar ligeiramente um elemento.
O elemento chave deste algoritmo é a selecção dos elementos da população baseada na propriedade de aptidão. A propriedade de aptidão é associada a um elemento e representa a qualidade da sua solução, evidenciado a sua proximidade de uma solução óptima. Elementos com um maior valor de aptidão têm uma maior probabilidade de serem seleccionados para uma nova iteração da população. Este comportamento baseia-se no princípio da sobrevivência, seguindo a evolução natural do mundo biológico [Blu02] [CZ01].
Pesquisa Tabu
A Pesquisa Tabu (Tabu Search - TS) é uma meta-heurística baseada em pesquisa local. A pesquisa local básica é normalmente conhecida por melhoramento iterativo, uma vez que, dentro do espaço de procura (vizinhança de uma solução) um movimento só é permitido se melhorar a solução.
A principal ideia por trás da TS é muito simples e consiste em apenas adicionar o conceito de memória a um algoritmo normal de melhoramento iterativo. O mecanismo de memória permite forçar a exploração de novas áreas no espaço de procura, tentando assim evitar os ciclos ou os mínimos locais. Na memória do algoritmo são guardados os últimos movimentos efectuados, evitando assim que em futuras decisões se volte a percorrer os mesmos locais. A memória do algoritmo é finita e guarda apenas os N últimos passos, sendo necessário descartar a cada iteração os movimentos mais antigos. Na figura seguinte (Figura 2.2) é ilustrado todo o comportamento do algoritmo.
Figura 2.2 – Ilustração do funcionamento do algoritmo arrefecimento Simulado
A abordagem normal do algoritmo é pesquisar a vizinhança do ponto actual (colocando de parte os elementos que já foram visitadas nas N iterações anteriores) e escolher o elemento que contém a melhor solução. Depois de determinado o ponto, este deve ser adicionado à memória do algoritmo (para evitar ser evitado em pesquisas futuras). Caso o valor da nova solução seja superior ao melhor registo até ao momento, então o seu valor deve ser guardado. Todo este processo contínua enquanto a condição de paragem do algoritmo não se verificar. O critério de paragem verifica se a solução actual é satisfatória e previne a entrada em ciclo infinito do algoritmo [Blu02] [AL03].
Arrefecimento simulado
O arrefecimento simulado (Simulated Annealing - SA) é considerado uma das mais velhas meta-heurísticas e muito provavelmente um dos primeiros algoritmos a incluir uma estratégia para contornar os óptimos locais. O raciocínio adoptado por este algoritmo permite a adopção de movimentos que possam conduzir a soluções locais piores do que a actual, permitindo assim escapar a óptimos locais. A probabilidade de efectuar esses movimentos diminui ao longo do tempo durante a pesquisa.
O algoritmo utiliza duas estratégias bem delineadas para conseguir alcançar o seu objectivo, por um lado faz uma pesquisa aleatória, por outro lado, faz um melhoramento iterativo. A pesquisa aleatória satisfaz a necessidade de contornar óptimos locais e é caracterizada através de um parâmetro T, geralmente conhecido por parâmetro da temperatura. O parâmetro T é a probabilidade que o algoritmo tem de admitir uma solução pior do que a actual durante o processo de melhoramento iterativo. O valor do parâmetro T vai diminuindo á
medida que a pesquisa vai avançando, passando o algoritmo a ter fundamentalmente um comportamento de melhoramento iterativo. O melhoramento iterativo consiste simplesmente em pesquisar a vizinhança de uma solução e guardar a melhor solução registada até ao momento. O SA obriga a definição de uma condição de paragem, que pode ser por exemplo o número de iterações efectuadas. Na figura seguinte (Figura 2.3) é possível visualizar um diagrama ilustrativo do funcionamento do algoritmo.
Figura 2.3 – Ilustração do funcionamento do algoritmo Arrefecimento Simulado
O nome do algoritmo provém da analogia feita entre o comportamento deste algoritmo e o processo de arrefecimento de metais e vidro. O arrefecimento de metais e vidro assume uma configuração final de baixa energia interna, caso o arrefecimento seja lento e controlado, permitindo uma reorganização homogénea dos átomos (reduz os defeitos no material) [Blu02] [MF04].
Algoritmos com meta-heurística
De entre os algoritmos identificados os que se enquadram nas meta-heurísticas são os algoritmos Meméticos e Ant Colony Optimization. Nos parágrafos seguintes, á semelhança dos algoritmos que foram apresentados anteriormente, é apresentada uma breve descrição do seu comportamento.
Algoritmos Meméticos
Em primeiro lugar é fundamental perceber o significado da palavra meme, porque só a partir dai se pode começar a perceber as raízes dos Algoritmos Meméticos (Memetic Algorithm - MA). R. Dawkins apresentou a sua definição através de um dos seus livros “The Selfish Gene” [Daw90], onde refere que o meme representa a unidade de informação que é transmitida entre gerações. Este conceito é similar ao do gene nos algoritmos genéticos, sendo a principal
diferença entre eles o facto de que o meme surge no contexto da evolução cultural, enquanto o gene emula a evolução biológica [Mos89].
A lógica dos MA é muito parecida com as do GA. Em ambos os casos a ideia principal passa pela evolução de uma população, transmitindo propriedades da geração anterior para a seguinte. A principal diferença reside na forma como é feita essa evolução, enquanto no caso dos GA a evolução só surge a partir do cruzamento de elementos da população, nos MA existe também um evoluir solitário de cada um dos indivíduos. Uma definição sumária dos MA é a referida por Moscato [Mos89]: “Memetic algorithms is a marriage between a population-based global search and the heuristic local search made by each of the individuals.”. Na figura seguinte (Figura 2.4) é apresentado um diagrama ilustrativo do funcionamento de um MA.
Figura 2.4 – Ilustração do funcionamento de um Algoritmo Memético
Dada a representação de um problema de optimização é criado um conjunto de elementos que representam a população inicial do problema. A população inicial pode ser gerada de forma aleatória ou pode ser utilizada uma heurística para o fazer. Uma vez criada a população inicial passa-se para a fase da pesquisa local, em que cada elemento tenta melhorar a sua solução. Para efectuar a pesquisa recorre-se a um algoritmo de pesquisa local que visita a vizinhança do elemento tentando melhorar a solução existente (até um determinado nível). Terminada a fase de melhoramento local, passa-se para a fase da pesquisa global. A pesquisa global é composta por duas componentes, a interacção cooperativa e a competitiva. A interacção competitiva é similar ao processo de selecção utilizado nos GA (através do valor da aptidão), enquanto a interacção cooperativa pode ser equiparada ao mecanismo de cruzamento utilizado em GA. Na verdade a interacção cooperativa pode ser modelada através de um qualquer processo que permita a geração de novos indivíduos. No fundo a interacção cooperativa é apenas uma forma de promover a troca de informação. Todo este processo (excepto a fase inicial) é repetido iterativamente até que um critério de paragem seja satisfeito. Um exemplo de um critério de paragem valido é o valor de aptidão da população alcançar um valor esperado [Mos89] [CF08] [KG02].
Ant Colony Optimization
Ant Colony Optimization (ACO) é uma meta-heurística proposta inicialmente por Marco
Dorigo [DS04A]. A ACO inspirou-se no comportamento real das formigas durante a busca de alimentos. O comportamento das formigas durante a fase de busca e recolha de alimento foi documentado por Jean Louis Deneubourg e permitiu compreender a sua estratégia na definição do caminho mais curto entre o local onde o alimento é recolhido e o ninho. Enquanto as formigas caminham entre a fonte da comida e o ninho, ou vice-versa, depositam no caminho por onde passam uma substância denominada feromona. O intuito dessa substância é indicar ao resto da colónia que alguém já passou por ali. Quando as formigas estão prestes a decidir por que caminho seguir escolhem o que tem maior concentração de feromona (decisão probabilística). Este comportamento promove a cooperação entre a comunidade e permite estabelecer mais facilmente uma rota mais curta.
Tendo em conta que as soluções calculadas pelas formigas podem não ser localmente óptimas, algumas implementações do ACO permitem que as formigas melhorem as suas soluções através de algoritmos de pesquisa local. O algoritmo básico de ACO consiste em quatro passos:
Em primeiro lugar estabelecem-se os parâmetros e inicializam-se os caminhos de fero-mona.
Em segundo lugar geram-se N soluções usando a combinação de caminhos de feromona e as restrições do problema.
Em terceiro lugar, aplica-se um algoritmo de pesquisa local às soluções obtidas.
Por último, se o melhor caminho definido no passo anterior é melhor do que todas as soluções geradas até ao momento, então substitui-se a melhor solução por essa. No último passo também está subjacente a actualização dos valores da feromona nos cami-nhos percorridos e o voltar ao passo dois para uma nova iteração do algoritmo.
Na figura seguinte (Figura 2.5) é possível ver uma ilustração do algoritmo ACO e verificar os passos enumerados anteriormente.
Figura 2.5 – Ilustração do funcionamento do algoritmo Ant Colony Optimization
Na maior parte das implementações do algoritmo as formigas são desenvolvidas de forma a assegurar que a construção das soluções para o problema só é feita com passos válidos (que respeitem as restrições), assegurando desde logo a validade da solução [Pin08] [Blu02].
2.1.2.2
Conclusões
Considerando toda a análise de algoritmos apresentada no decorrer deste subcapítulo é importante referir que não é possível identificar uma solução que fosse razoavelmente melhor que as restantes. O factor preponderante dessa incapacidade surge pelo facto de o autor não ter tido oportunidade de colocar em prática todo o conhecimento adquirido, podendo assim constatar qual era a solução que melhor se adequava ao problema.
O trabalho com algoritmos e meta-heurísticas é um trabalho ingrato, na medida em que, na maior parte dos casos é necessário testa-los para verificar a sua aptidão na resolução de problemas.
