Fundamentos conceituais para a construção de sistemas operacionais baseados em conhecimento

Texto

(1)UNIVERSIDADE FEDERAL DE SANTA CATARINA CENTRO TECNOLÓGICO PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA DE PRODUÇÃO. FUNDAMENTOS CONCEITUAIS PARA A CONSTRUÇÃO DE SISTEMAS OPERACIONAIS BASEADOS EM CONHECIMENTO. Mauro Marcelo Mattos. Roberto Pacheco, Dr. Orientador. Florianópolis (SC), novembro de 2003..

(2)

(3) Universidade Federal de Santa Catarina Programa de Pós-Graduação em Engenharia de Produção. Mauro Marcelo Mattos. FUNDAMENTOS CONCEITUAIS PARA A CONSTRUÇÃO DE SISTEMAS OPERACIONAIS BASEADOS EM CONHECIMENTO. Tese de Doutorado. Florianópolis 2003.

(4)

(5) MAURO MARCELO MATTOS. FUNDAMENTOS CONCEITUAIS PARA A CONSTRUÇÃO DE SISTEMAS OPERACIONAIS BASEADOS EM CONHECIMENTO. Tese apresentada ao Programa de Pós-Graduação em Engenharia de Produção da Universidade Federal de Santa Catarina como requisito parcial para a obtenção do título de Doutor em Engenharia de Produção.. Orientador: Prof. Roberto Carlos dos Santos Pacheco, Dr.. Florianópolis 2003.

(6)

(7) Ficha Catalográfica elaborada pela Biblioteca da FURB Mattos, Mauro Marcelo M444f Fundamentos conceituais para a construção de sistemas operacionais baseados em conhecimento / Mauro Marcelo Mattos. – 2003. 372p. : il. Orientador: Roberto Carlos dos Santos Pacheco. Tese (doutorado) – Universidade Federal de Santa Catarina, Programa de Pós-Graduação em Engenharia de Produção e Sistemas. 1. Sistemas operacionais (Computadores). I. Pacheco, Roberto Carlos dos Santos. II. Universidade Federal de Santa Catarina. Programa de PósGraduação em Engenharia de Produção e Sistemas. III. Título. CDD 005.43.

(8)

(9) Mauro Marcelo Mattos FUNDAMENTOS CONCEITUAIS PARA A CONSTRUÇÃO DE SISTEMAS OPERACIONAIS BASEADOS EM CONHECIMENTO Esta tese foi julgada e aprovada para a obtenção do título de Doutor em Engenharia de Produção no Programa de Pós-Graduação em Engenharia de Produção da Universidade Federal de Santa Catarina Florianópolis, 14 de novembro de 2003.. Prof. Edson Pacheco Paladini, Dr. Coordenador do Curso. BANCA EXAMINADORA Prof. Luiz Natal Rossi,Dr Universidade de São Paulo Examinador externo. Prof. Roberto Pacheco,Dr. Universidade Federal de Santa Catarina Orientador. Prof. Marco Antônio Barbosa Cândido, Dr. Pontifícia Universidade Católica do Paraná Examinador externo. Prof. Luiz Fernando Friedrich,Dr. Universidade Federal de Santa Catarina Moderador. Profª. Elizabeth Sueli Specialski,Dra. Universidade Federal de Santa Catarina Membro. Prof. Rômulo Silva de Oliveira,Dr. Universidade Federal de Santa Catarina Membro. Prof. João Bosco da Mota Alves,Dr. Universidade Federal de Santa Catarina Membro.

(10)

(11) À minha adorada esposa Mariene, companheira e grande incentivadora, presença indispensável em minha vida..

(12)

(13) AGRADECIMENTOS Os meus sinceros agradecimentos e todas as pessoas e instituições, cuja ajuda, direta ou indireta, tornaram possível a realização deste trabalho. Aos professores Elizabeth Sueli Specialski,Dra., Rômulo Silva de Oliveira,Dr., João Bosco da Mota Alves, Dr., e Roberto Carlos dos Santos Pacheco,Dr., pelas considerações e contribuições no exame de qualificação e na banca examinadora desta tese. Aos professores Luiz Fernando Friedrich,Dr., Luiz Natal Rossi,Dr. E, Marco Antônio Barbosa pelas considerações e contribuições realizadas na banca examinadora desta tese. Ao Prof. Bernard Ziegler, PhD., pela atenção e pelas importantes considerações que contribuiram para a concepção do modelo proposto. À Universidade Federal de Santa Catarina – UFSC, aos professores do Curso de Pós-graduação em Engenharia de Produção e Sistemas – PPGEP, pelo apoio, incentivo e colaboração durante a fase do pós-graduação. À Universidade Regional de Blumenau – FURB pelo apoio logístico e financeiro. Aos amigos e colegas do Departamento de Sistemas e Computação que apoiaram o projeto. À CAPES/PICDT pelo apoio financeiro. Aos amigos, Sérgio e Daniela Castro, Cláudia Holetz, Rômulo,Simone e Augusto, Roland e Luci Dagnoni, Jorge Sampaio Farias, Miriam e Sérgio Volpi e Marluza Mattos, Diala e Fernando e, outros tantos amigos, pela presença e constante apoio – fator importante em projetos desta envergadura. Ao Professor e Orientador Roberto Carlos dos Santos Pacheco,Dr., pelo grande incentivo ao desenvolvimento deste projeto, o qual foi viabilizado pela sua filosofia de trabalho. Muito obrigado! Ao amigo e colega Jomi Fred Hübner,Dr., pela paciência em ouvir as minhas idéias e pelas considerações que determinaram o fechamento do modelo deste trabalho. Muito obrigado! Ao grande amigo Rômulo Silva de Oliveira,Dr., cuja disponibilidade, incentivo, caráter ético e muita paciência, contribuiram fundamentalmente para a realização deste trabalho. O meu muito obrigado! Ao grande Prof.Pedro Bertolino, pelas inestimáveis discussões sobre a elaboração do conceito de conhecimento em um sistema operacional baseado em conhecimento. Sua disponibilidade, visão de futuro e caráter científico foram determinantes na realização deste trabalho. Muito Obrigado! Ao amigo Juarez Estrázulas, meu sogro, pela revisão do português que tornou este texto legível. À amiga Inar Araújo, minha sogra, pela acolhida, torcida e pelas orações. Voces foram muito importantes durante todo o processo. Muito obrigado. À Mariene, pelo carinho, amor, amizade, paciência e companheirismo nos momentos difíceis, sem os quais seria difícil concluir este trabalho. Muito obrigado! Um agradecimento especial vai para a minha avó Isabel (in memorian), que desejava que eu fosse “doutor”, ao meu pai Alípio (in memórian), que desejava que eu fosse “engenheiro”e, a minha mãe Marília, que desejava que eu fosse “professor”. Hoje eu sou Prof.Dr.Eng., graças aos ensinamentos de voces. Muito obrigado!.

(14)

(15) “Do ponto de vista da física básica, os fenômenos mais interessantes estão, sem dúvida, nos novos lugares, os lugares onde as regras não funcionam – não os lugares onde funcionam! É assim que descobrimos novas regras!” Richard P. Feynman..

(16)

(17) VIII. SUMÁRIO LISTA DE FIGURAS.............................................................................................. XIII LISTA DE TABELAS ............................................................................................. XVI LISTA DE REDUÇÕES.........................................................................................XVII RESUMO................................................................................................................. XIX ABSTRACT ...............................................................................................................XX. 1. INTRODUÇÃO .................................................................................................. 21 1.1 Contextualização do tema e definição do problema de pesquisa.................... 21 1.1.1 Tema de Pesquisa .................................................................................. 28 1.1.2 Problema de Pesquisa ............................................................................ 28 1.1.3 Questões de Pesquisa............................................................................. 33 1.2 Objetivos....................................................................................................... 34 1.2.1 Objetivo Geral ....................................................................................... 34 1.2.1 Objetivos Específicos ............................................................................ 34 1.2.2 Pontos Críticos e Dificuldades ............................................................... 35 1.3. Justificativa................................................................................................... 36. 1.4 Procedimentos Metodológicos....................................................................... 43 1.4.1 Delimitação do tema de pesquisa ........................................................... 43 1.4.2 Delimitação temporal da pesquisa.......................................................... 44 1.4.3 Tipo de Estudo Realizado ...................................................................... 44 1.4.4 Classificação da Natureza da Pesquisa................................................... 46 1.4.5 Classificação da Abordagem do Problema ............................................. 47 1.4.6 Classificação dos Objetivos ................................................................... 47 1.4.7 Classificação dos Procedimentos Técnicos ............................................ 48 1.4.8 Procedimentos para a elaboração do trabalho......................................... 48 1.5. Estrutura do Trabalho................................................................................... 51. 2. O ESTADO DA ARTE NA TEORIA CLÁSSICA DE SISTEMAS OPERACIONAIS ....................................................................................................... 55 2.1. Introdução .................................................................................................... 55. 2.2 O Conceito de Sistema Operacional .............................................................. 55 2.2.1 Outros Conceitos Que Formam o Modelo Atual .................................... 57 2.3. O modelo evolutivo de hardware ................................................................... 61. 2.4 Estruturas organizacionais clássicas............................................................. 65 2.4.1 Estruturas Monolíticas ........................................................................... 66 2.4.2 Estruturas Baseadas em Camadas .......................................................... 67 2.4.3 Estruturas Hierárquicas.......................................................................... 67 2.4.4 Estruturas Baseadas em Micronúcleos ................................................... 68.

(18) IX. 2.4.5 2.4.6 2.4.7 2.4.8 2.4.9 2.4.10 2.4.11 2.4.12 2.4.13 2.4.14. Estruturas Configuráveis ou Adaptáveis ................................................ 69 Estruturas Baseadas em Núcleos Coletivos ............................................ 70 Estruturas Baseadas em Library Operating Systems............................... 71 Estruturas Baseadas em Nanonúcleos .................................................... 74 Estruturas Baseadas em Máquinas Virtuais............................................ 76 Estruturas Baseadas no Conceito de Objetos.......................................... 76 Estruturas Baseadas em Reflexão Computacional .................................. 77 Estruturas Baseadas em Conhecimento.................................................. 79 Estruturas Baseadas em Agentes............................................................ 81 Estruturas Híbridas ................................................................................ 82. 2.5. Técnicas para obtenção de dados do núcleo.................................................. 83. 2.6. O modelo evolutivo dos sistemas operacionais .............................................. 85. 2.7. Considerações Finais .................................................................................... 90. 3. NOVAS DEMANDAS: COMPUTAÇÃO UBÍQUA, TELETRABALHO e COMÉRCIO ELETRÔNICO.................................................................................... 94 3.1. Introdução .................................................................................................... 94. 3.2. Tendências em Computação .......................................................................... 94. 3.3 Pesquisas em computação ubíqua ................................................................. 96 3.3.1 Principais requisitos de computação ubíqua ......................................... 100 3.4. Demandas em Teletrabalho......................................................................... 107. 3.5. Demandas em Comércio Eletrônico ............................................................ 109. 3.6. Considerações finais ................................................................................... 109. 4. ABORDAGENS DE INSTRUMENTALIZAÇÃO DE SISTEMAS OPERACIONAIS ..................................................................................................... 111 4.1. Introdução .................................................................................................. 111. 4.2 Emprego de técnicas de Inteligência Artificial em Sistemas Operacionais... 111 4.2.1 Sistemas Especialistas ......................................................................... 113 4.2.2 Redes neurais ...................................................................................... 115 4.2.3 Lógica difusa....................................................................................... 116 4.2.4 Redes Probabilísticas........................................................................... 119 4.2.5 Mapas Cognitivos Difusos (Fuzzy Cognitive Maps)............................. 120 4.3 Outras técnicas utilizadas ........................................................................... 121 4.3.1 Agentes ............................................................................................... 122 4.3.2 Visualização de informações ............................................................... 124 4.3.3 Análise de perfil .................................................................................. 127 4.3.4 Ferramentas baseadas em histórico ...................................................... 129 4.3.5 Outras pesquisas relacionadas.............................................................. 130 4.4 Abordagens adotadas em projetos de robótica ............................................ 134 4.4.1 Modelo de mundo................................................................................ 134 4.5. Considerações Finais .................................................................................. 138.

(19) X. 5. CARACTERIZAÇÃO DO PROBLEMA ........................................................ 142 5.1. Introdução .................................................................................................. 142. 5.2. Definição do Problema ............................................................................... 142. 5.3. Deficiências do estado da arte .................................................................... 144. 5.4 Confiabilidade e Segurança ........................................................................ 149 5.4.1 Aspectos de confiabilidade de sistemas comerciais .............................. 151 5.4.2 Estudos sobre Invasões ........................................................................ 155 5.4.3 Aspectos de segurança relacionados à computação ubíqua................... 156 5.4.4 Aspectos de segurança relacionados a teletrabalho............................... 158 5.4.5 Aspectos de segurança relacionados a comércio eletrônico .................. 162 5.5 Complexidade de Utilização........................................................................ 163 5.5.1 Visibilidade do estado do sistema: ....................................................... 164 5.5.2 Sincronismo (match) entre sistema e o mundo real .............................. 165 5.5.3 Controle do usuário e liberdade ........................................................... 166 5.5.4 Consistência e padronização ................................................................ 167 5.5.5 Prevenção de erros............................................................................... 168 5.5.6 Identificar ao invés de relembrar.......................................................... 168 5.5.7 Flexibilidade e eficiência de uso .......................................................... 168 5.5.8 Projeto harmonioso e simples .............................................................. 169 5.5.9 Auxiliar o usuário a reconhecer, diagnosticar e recuperar-se de erros... 169 5.5.10 Ajuda (help) e documentação .............................................................. 170. 6. 5.6. Outras Considerações ................................................................................. 170. 5.7. Domínio do Problema ................................................................................. 172. 5.8. Análise comparativa.................................................................................... 174. 5.9. Considerações finais ................................................................................... 177. BASE CONCEITUAL DO MODELO PROPOSTO....................................... 182 6.1. Introdução .................................................................................................. 182. 6.2 Comportamento inteligente e conhecimento ................................................ 182 6.2.1 A questão do aprendizado em sistemas inteligentes ............................. 192 6.3. A questão do tempo e suas implicações ....................................................... 194. 6.4. O formalismo DEVS.................................................................................... 198. 6.5. Modelo de mundo – aspectos conceituais .................................................... 201. 6.6 O Modelo de Árvores Paralelas Funcionais de Decisão.............................. 205 6.6.1 Aspectos conceituais ........................................................................... 207 6.6.2 Visão arquitetônica.............................................................................. 212 6.6.3 Representação do mapeamento entre estados do mundo e ações .......... 217 6.6.4 Arquitetura do protótipo InSitu............................................................ 218 6.7. 7. Considerações finais ................................................................................... 223. SISTEMA OPERACIONAL BASEADO EM CONHECIMENTO - SOBC.. 224.

(20) XI. 7.1. Introdução .................................................................................................. 224. 7.2. Definição .................................................................................................... 225. 7.3 Identificação dos requisitos do modelo proposto ......................................... 230 7.3.1 Requisitos funcionais da nova geração de sistemas operacionais.......... 230 7.3.2 Requisitos Não Funcionais .................................................................. 232 7.3.3 Comparativo entre requisitos funcionais e não funcionais .................... 233 7.3.4 Avaliação da Viabilidade dos Requisitos Identificados ........................ 235 7.4 O Modelo Proposto ..................................................................................... 236 7.4.1 O modelo de tempo ............................................................................. 237 7.4.2 Modelo de Mundo ............................................................................... 250 7.4.3 Modelo de Aplicação........................................................................... 259 7.4.4 O ambiente de execução ...................................................................... 270 7.5. 8. Considerações finais ................................................................................... 285. CONCLUSÕES................................................................................................. 289 8.1. 9. Recomendações finais ................................................................................. 292. BIBLIOGRAFIA .............................................................................................. 294. 10 10.1. APÊNDICES ................................................................................................. 309 Apêndice 1 – Call for papers ACM SIGOPS 2003 ....................................... 310. 10.2 Apêndice 2 – Descrição detalhada das arquiteturas de núcleos de sistemas operacionais ........................................................................................................... 311 10.2.1 Estruturas Monolíticas ......................................................................... 312 10.2.2 Estruturas Baseadas em Camadas ........................................................ 313 10.2.3 Estruturas Hierárquicas........................................................................ 315 10.2.4 Estruturas Baseadas em Micronúcleos ................................................. 316 10.2.5 Estruturas Configuráveis ou Adaptáveis .............................................. 319 10.2.6 Estruturas Baseadas em Núcleos Coletivos .......................................... 323 10.2.7 Estruturas Baseadas em Library Operating Systems............................. 324 10.2.8 Estruturas Baseadas em Nanonúcleos .................................................. 329 10.2.9 Estruturas Baseadas em Máquinas Virtuais.......................................... 333 10.2.10 Estruturas Baseadas no Conceito de Objetos.................................... 340 10.2.11 Estruturas Baseadas em Reflexão Computacional ............................ 343 10.2.12 Estruturas Baseadas em Conhecimento ............................................ 347 10.2.13 Estruturas Baseadas em Agentes...................................................... 356 10.2.14 Estruturas Híbridas .......................................................................... 359 10.2.15 Considerações finais ........................................................................ 362 10.3. Apêndice 3 – Exemplo de log de erro no sistema (DrWatson –Windows).... 363. 10.4. Apêndice 4 – Exemplo de log obtido através de device driver (Windows) .... 365. 10.5. Apêndice 5 – Exemplo de log obtido através de Sar (Unix).......................... 368. 10.6. Apêndice 6 – Modelo de árvore de decisões para algoritmos ...................... 370. 10.7. Apêndice 7 – Modelo de árvore de decisões para redações ......................... 371.

(21) XII. 10.8. Apêndice 8 – Planilha para identificação de regras .................................... 372.

(22) XIII. LISTA DE FIGURAS Figura 1 - Evolução das abstrações em favor do programador....................................... 26 Figura 2 - Virtualização do processador através de multiprogramação .......................... 30 Figura 3 - Intromissão virtual de pessoas na máquina do usuário .................................. 31 Figura 4 - Estágio atual de evolução dos sistemas operacionais..................................... 32 Figura 5 - Exemplo de opções de configuração do browser Internet Explorer................ 33 Figura 6 - Chamada da IEEE para criação de um padrão para construção de sistemas operacionais seguros. ............................................................................................ 41 Figura 7 - Delimitação da proposta ............................................................................... 42 Figura 8 - Abrangência temporal x número de trabalhos consultados ............................ 45 Figura 9 - Organização dos diretórios preservando a origem das informações coletadas.49 Figura 10 - Software utilizado para indexação da base digital ....................................... 50 Figura 11 - Estrutura do trabalho. ................................................................................. 54 Figura 12 - Estrutura funcional de um sistema operacional ........................................... 56 Figura 13 - Pseudo-código que implementa um interpretador de máquina virtual.......... 57 Figura 14 - Modelo Evolutivo de Hardware.................................................................. 64 Figura 15 - Formas de obtenção de informações do sistema operacional ....................... 85 Figura 16 - Fase 0: primeiro estágio evolutivo dos sistemas operacionais...................... 86 Figura 17 - Fase 1: Protocolos implementados como bibliotecas externas ao sistema .... 86 Figura 18 - Fase 2: protocolos incorporados ao sistema operacional.............................. 87 Figura 19 - Fase 1: Navegadores desenvolvidos como bibliotecas externas .................. 88 Figura 20 - Fase 2: Navegadores incorporados ao sistema operacional .......................... 88 Figura 21 - Próximas demandas .................................................................................... 90 Figura 22 - Evolução dos modelos de núcleos de sistemas operacionais........................ 92 Figura 23 - Tendências em Computação. ...................................................................... 95 Figura 24 - Visão geral do projeto Oxygen do MIT. ...................................................... 97 Figura 25 - As quatro fases da evolução do espaço de trabalho. .................................. 108 Figura 26 - Classificador de padrões de acesso de E/S em PPFSII............................... 117 Figura 27 - Arquitetura de um OS Agent. ................................................................... 123 Figura 28– Fisheye: menu apresentando os 100 mais populares sites web retirados da lista dos mais populares da revista PC Magazine................................................. 125 Figura 29– Data Mountain: exemplo de seleção de um documento. ............................ 127 Figura 30– Infra-estrutura para aquisição de informações contextuais......................... 128 Figura 31 - Mecanismo de inserção de mensagens aleatórias no Windows NT5.0. ...... 151 Figura 32 - (a) numero de erros por diretório no linux; (b) taxa de erros comparada com outros diretórios.................................................................................................. 152 Figura 33 – Versões de correção de erros.................................................................... 153 Figura 34 - Mensagem de erro quando o usuário tenta remover um arquivo do S.O. ... 165 Figura 35 - Mensagem de aviso durante o cancelamento de operação com erro........... 166 Figura 36- Associação entre formato de arquivo-aplicação. ........................................ 167 Figura 37- Uso de linguagem técnica na interface com o usuário. ............................... 167 Figura 38- Exemplo de mensagem de erro crítico ....................................................... 169 Figura 39- Mensagens de erro dependentes de API. .................................................... 170 Figura 40 - Flutuações na disponibilidade de processador ........................................... 171 Figura 41 – Tecnologia usada para coletar dados sem que o usuário tenha autorizado 173 Figura 42 – Contexto onde os projetistas de SO trabalham.......................................... 177.

(23) XIV. Figura 43 - Visão sobre a qual está baseada a tecnologia de computação.................... 178 Figura 44 – Confronto entre a visão de projeto de SO e a visão geral do atual modelo de computação......................................................................................................... 179 Figura 45 – Modelo DEVS. ........................................................................................ 200 Figura 46 – DFD de nível 0 do projeto InSitu. ............................................................ 212 Figura 47 – DFD de nível 1 do Projeto InSitu. ............................................................ 213 Figura 48 – Modelo de mundo hiperdimensional ........................................................ 236 Figura 49 – Estrutura de uma quadtree........................................................................ 238 Figura 50 – Representação de evento instantâneo localizado numa base de tempo ...... 239 Figura 51 – Sensores lógicos representando histórico de eventos ................................ 243 Figura 52 – Sensores lógicos representando espaço disponível em um disco............... 244 Figura 53 – Quadtree representando fragmentação de disco ........................................ 245 Figura 54 - Treze relacionamentos entre dois intervalos de tempo............................... 245 Figura 55 - Especificação do relógio de intervalo big-ben........................................... 249 Figura 56 – Dimensão física do Modelo de Mundo proposto ...................................... 251 Figura 57– Estados do Contexto Físico do Dispositivo ............................................... 253 Figura 58- Exemplo de representação de Modelo Físico do Mundo ............................ 254 Figura 59 - Estados do Contexto Lógico do Dispositivo.............................................. 255 Figura 60 – Contexto Lógico do Mundo - CLM.......................................................... 257 Figura 61– Exemplo de representação do Contexto Lógico do Mundo ........................ 258 Figura 62 - Transformação do modelo hiperdimensional em modelo unidimensional.. 259 Figura 63 – Processo de Desenvolvimento de Aplicações (a) tradicional (b) proposto. 261 Figura 64 – Modelo de desenvolvimento de aplicações.............................................. 262 Figura 65 – Contextualização do problema ................................................................. 266 Figura 66 –Feedback ao aluno .................................................................................... 266 Figura 67 – Pseudo-código resultante da execução do sistema .................................... 267 Figura 68 – Tempo nominal de execução das aplicações............................................. 270 Figura 69 – Modelo preemptivo conceitual ................................................................. 271 Figura 70 – Exemplo de modelo preemptivo real ........................................................ 271 Figura 71 – Modelo de substrato reativo no paradigma atual....................................... 272 Figura 72 – Interação do especialista desenvolvedor................................................... 276 Figura 73 – Interface de assimilação e aprendizagem.................................................. 277 Figura 74 – Interação do especialista escritor.............................................................. 278 Figura 75 – Tratamento de tempo explicito x tempo implícito..................................... 281 Figura 76 – Uso da cláusula NAO_SEI....................................................................... 284 Figura 77 – Comparativo entre modelos exógenos e o modelo proposto (endógeno) ... 285 Figura 78 – Chamada de trabalhos para o congresso na área de Sistemas Operacionais sob a chancela da ACM em 2003. ....................................................................... 310 Figura 79 –Modelo de núcleo monolítico.................................................................... 312 Figura 80 – Modelo em camadas. ............................................................................... 314 Figura 81 -Organização do sistema Pilot..................................................................... 316 Figura 82 - O micronúcleo do Mach e seus sub-sistemas............................................. 318 Figura 83 - Estrutura de núcleo coletivo...................................................................... 324 Figura 84 – Modelo de cache kernel. .......................................................................... 328 Figura 85 – Exemplo de funcionamento de uma máquina virtual Windows 98 executando sobre um host Windows 2000 ............................................................................. 335 Figura 86 – Uma máquina virtual implementada sobre uma máquina real com mesmo conjunto de instruções......................................................................................... 335 Figura 87 - Estrutura da Máquina Virtual VirtualPC. .................................................. 336.

(24) XV. Figura 88 - Objetos A, B e C implementam a solução de um problema específico. Objetos meta-nível M1..M4 controlam a execução dos abjetos A, B e C e implementam parte de seu comportamento.......................................................... 344 Figura 89 - O ambiente Lisp consistindo de todas as funções e objetos em memória virtual. ................................................................................................................ 349 Figura 90 – Estrutura organizacional do sistema ABOS. ............................................. 358 Figura 91- Abordagem híbrida do sistema operacional Windows 2000 Server. .......... 360 Figura 92 – Exemplo de árvore de decisões utilizada no protótipo de validação do modelo de aplicações .......................................................................................... 370 Figura 93 – Exemplo de árvore de decisões modelando conhecimento sobre construção de redações ......................................................................................................... 371 Figura 94 – Planilha de regras utilizadas para montagem da árvore de decisões .......... 372.

(25) XVI. LISTA DE TABELAS Tabela 1 - Latência de processos e threads ................................................................... 60 Tabela 2 - Características de núcleos monolíticos ......................................................... 66 Tabela 3 - Características de núcleos em camadas......................................................... 67 Tabela 4 - Características de núcleos hierárquicos. ....................................................... 68 Tabela 5 - Características de micronúcleos. .................................................................. 69 Tabela 6 - Características de núcleos configuráveis/adaptáveis. .................................... 70 Tabela 7 - Características de núcleos coletivos.............................................................. 71 Tabela 8 - Características de núcleos baseados em library OS....................................... 72 Tabela 9 - Características de exonúcleos....................................................................... 73 Tabela 10 - Características de cache kernel. .................................................................. 74 Tabela 11 - Características de nanonúcleos ................................................................... 75 Tabela 12 - Características de núcleos baseados em máquinas virtuais.......................... 76 Tabela 13 - Características de núcleos baseados no conceito de objetos ........................ 77 Tabela 14 - Características de núcleos baseados em reflexão computacional ................. 78 Tabela 15 - Características de núcleos baseados em conhecimento ............................... 80 Tabela 16 - Características de núcleos baseados em agentes ......................................... 82 Tabela 17- Características de núcleos híbridos.............................................................. 83 Tabela 18 - Requisitos funcionais e não funcionais de projetos de sistemas operacionais ............................................................................................................................. 91 Tabela 19 - Requisitos funcionais de computação ubíqua, teletrabalho e comércio eletrônico............................................................................................................ 110 Tabela 20 - Resumo das características de uso da tecnologia de informações .............. 140 Tabela 21 - Requisitos funcionais e não funcionais de projetos de robôs autônomos ... 141 Tabela 22 - Requisitos de segurança em computação ubíqua na visão de companhias de telecomunicações................................................................................................ 157 Tabela 23 - Problemas e medidas de segurança em tele-trabalho................................. 160 Tabela 24 - Comparativo entre requisitos de projetos de sistemas operacionais, computação ubíqua, teletrabalho, comércio eletrônico e robótica. ....................... 175 Tabela 25 - Comparativo entre requisitos funcionais e não funcionais......................... 233 Tabela 26 - Relacionamento entre intervalos usando quadtrees ................................... 246 Tabela 27 - Aliases para variáveis lingüísticas ............................................................ 256.

(26) XVII. LISTA DE REDUÇÕES ACM ADA. - Association of Computer Machinery - Active Document Architecture. AFIPS AOP API ARTIS ASIC AUP BIOS BNF. -. CASE CFD. - Computer Aided Software Engineering - Contexto físico do dispositivo. CFM CLD CLM COM COP CORBA DARPA DMA E/S FAT. -. Contexto físico do mundo Contexto lógico do dispositivo Contexto lógico do mundo Component Object Model Component-based Operating System Proxy Common Object Request Brocker Defense Advanced Research Projects Direct Memory Access Entrada e Saída File Allocation Table. FBI FCM FLIPS GNU. -. Federal Bureau of Investigation Fuzzy Cognitive Maps Fuzzy Logic Inferences per Second General Public License. GPS GUI HAL HCI HPFS HTML. -. Global Positioning System Graphical User Interface Hardware Abstraction Layer Human-Computer-Interaction High Performance File System Hypertext Markup Language. IA IBM IDS. - Inteligência Artificial - International Business Machines - Intrusion Detection System. IEEE IIDS IOCS. - Institute of Electrical and Electronics Engineers - Intelligent Intrusion Detection System - Input/Output Control System. American Federation of Information Processing Societies Aspect Oriented Programming Application Program Interface Architecture for Real-time Intelligent Systems Application Specific Integrated Circuit Active Universal Plans Basic Input-Output System Backus Naur Form.

(27) XVIII. IPC IVR. - Inter-Process Communication - Interactive Voice Response. JVM LRU. - Java Virtual Machine - Least Recently Used. MIPS MIT MM. - Million Instructions per Second - Massachusetts Institute of Technology - Modelo de Mundo. MMU MUD NCR NSA NC. -. NTFS OLE ORB. - NT File System (ou New Technology File System) - Object Linking and Embedding - Object Request Broker. PC PDF PKI PGP. -. POSIX PPFS QoP. - Portable Operating System Interface - Portable Parallel File System - Quality of Protection. RBC RISC. - Raciocínio Baseado em Casos - Reduced Instruction Set Computer. RMI RPC. - Remote Method Invocation - Remote Procedure Call. SE SMA SOBC SOM TIC. -. Sistema Especialista Sistemas Multiagentes Sistema Operacional Baseado em Conhecimento System Object Model Tecnologias de Informação e Comunicação. TLB UML VFS VMM. -. Translation Look-aside Buffer Unified Modeling Language Virtual File System Virtual Machine Monitor. VPN. - Virtual Private Network. WDM WMI XML. - Windows Driver Model - Windows Management and Instrumentation - Extended Markup Language. Memory Management Unit Multiple User Domain National Cash Register Company (adquirida pela AT&T em 1991) National Security Agency Network Computer. Personal Computer Portable Document Format Public Key Infrastructure Pretty Good Privacy.

(28) XIX. RESUMO MATTOS,Mauro M. Fundamentos conceituais para a construção de sistemas operacionais baseados em conhecimento. 2003. 372 páginas. Tese (Doutorado em Engenharia de Produção) – Programa de Pós-Graduação em Engenharia de Produção, UFSC, Florianópolis. Um sistema inteligente deve ser capaz de adquirir autonomamente as informações necessárias, através da percepção, e executar as ações apropriadas. Para atingir a esta meta, sistemas artificiais devem acessar diretamente o ambiente que os cerca. O paradigma atual de sistemas operacionais suporta a noção de abstração de hardware, onde cada aplicação supõe possuir seu próprio processador e demais recursos. Esta situação e o fato de que em geral os sistemas operacionais tradicionais são baseados em (i) multitarefa, contribuem para a permanência de problemas identificados há mais de 30 anos. Estes problemas envolvem não só aspectos de segurança e usabilidade como também questões de privacidade das informações. Alem disso, há outros dois conceitos que contribuem para piorar a situação: (ii) o conceito de operador e (iii) o conceito de programa. A função de operador foi necessária nos primórdios da computação, quando os computadores eram enormes e difíceis de usar. O conceito de programa implica virtualmente na extensão das “mãos dos desenvolvedores” para dentro da máquina dos usuários. Este trabalho introduz uma definição para a noção de sistema operacional baseado em conhecimento, estabelece a possibilidade concreta dessa definição a partir da apresentação de uma base conceitual que sustenta a definição apresentada e fornece indicações sobre a sua necessidade – isto é, dá-lhe um conteúdo objetivo e mostra o interesse e a utilidade que esta nova concepção pode ter para a área de Sistemas Operacionais em particular e para a área de Computação em geral. Especificamente, realiza-se uma particular leitura sobre o paradigma atual de concepção de sistemas operacionais e confronta-se este modelo com as demandas de computação ubíqua, teletrabalho e comércio eletrônico, resultando numa evidente disparidade entre os requisitos dos projetos de sistemas operacionais e os requisitos dos projetos das áreas elencadas. Por outro lado, uma mudança de atitude face aos objetivos propostos é também requerida. A definição dada supõe que se reconheça a autonomia operacional dos sistemas. E isto implica em abandonar, ou pelo menos colocar em segundo plano, o que comumente é chamado de artificialismo – a busca de imitação do comportamento inteligente de seres humanos ou animais - e adotar o ponto de vista denominado naturalismo – a consideração de inteligência de máquina como fenômeno natural nas máquinas, digno de ser estudado em si próprio. O trabalho apresenta os resultados da reflexão através da qual se tentou realizar os objetivos. Palavras-chave: Sistemas operacionais, sistemas operacionais baseados em conhecimento, modelo de kernel endógeno..

(29) XX. ABSTRACT. MATTOS,Mauro M. Fundamentos conceituais para a construção de sistemas operacionais baseados em conhecimento. 2003. 372 páginas. Tese (Doutorado em Engenharia de Produção) – Programa de Pós-Graduação em Engenharia de Produção, UFSC, Florianópolis. An intelligent system should be able to autonomously acquire its required information through perception and carry out the contemplated actions. To achieve this goal, artificial systems must have direct access to their surroundings. The paradigm over which we build operating systems today is based on an hardware abstraction where each application is supposed to possess its own processor (and other resources). This situation and the fact that in general all commercial operating systems are based on (i) multitasking, contribute to enforce problems identified since 30 years ago. Those problems range from security to usability, but also include aspects related to privacy. Besides that, there are two other concepts that contribute to make things worse: (ii) the operator concept and (iii) the program concept. The operator function was necessary in the first moments of computing area since the computers were big and difficult to use. Operators at that time were responsible for turning on/off the machine, starting programs, collecting reports, restarting new programs and so on. The program concept can be thought as the programmer’s hands virtually inside the user’s machines. This research introduces the definition for the notion of a knowledge-based operating system (KBOS), establishes the real possibility of this definition based on a conceptual basis that supports the definition and, presents some indications about its needs – that is, gives an objective content and shows the interest and usefulness that this new conception can be to operating systems in particular and computing in general. A particular reading is made about the current operating system building paradigm and this model was compared with new demands in ubiquitous computing, teleworking and ecommerce areas resulting in a disparity between operating system’s projects and the other projects. On the other hand, a change in attitude is required in face of the proposed objectives. The presented definition supposes the recognition of the operational autonomy of the KBOS. Thus, this abandons or at least puts in second plan what is called artificialism – the search for imitation of animals or of the human beings’ intelligent behavior and to adopt the point of view denominated naturalism – the consideration of machine intelligence as natural phenomenon in the machines worthy of being studied in itself. This research presents the results of the reflection through which the objectives were accomplished.. Keywords: Operating systems, knowledge-based operating systems, endogenous kernel model..

(30) 21. 1 INTRODUÇÃO Este capítulo apresenta a pesquisa. Com este propósito, inicialmente contextualizase o tema e define-se o problema que norteia o desenvolvimento da tese. Os objetivos gerais e específicos são apresentados a seguir, juntamente com as justificativas teóricas e práticas. O capítulo é finalizado com a descrição da estrutura da tese. 1.1. Contextualização do tema e definição do problema de pesquisa “Uma análise da eficiência econômica e da viabilidade dos produtos e serviços de informação nos orienta a uma reflexão de apreciação na manifestação do fenômeno da informação. A produção ou geração de conhecimento (no indivíduo, seu grupo, sua instituição ou a sociedade) ocorre em uma articulação mais ampla, mediada por uma função de passagem, a que chamaremos de função de transferência da informação. A assimilação da informação é a finalização de um processo de aceitação da informação, o qual transcende a disponibilidade, o acesso e o uso da mesma. A assimilação da informação faz realizar o fenômeno do conhecimento no indivíduo (receptor) e em sua ambiência. Este é o destino final da informação: criar conhecimento modificador e inovador no indivíduo e no seu contexto. Conhecimento, que o referencie tanto com o seu mundo de convivência, quanto com um melhor estágio de desenvolvimento” Barreto (1999).. O impacto e a evolução das tecnologias de informação nas últimas décadas têm apresentado sucessivos desafios, tanto aos indivíduos em relação à sociedade, como às empresas em relação ao mercado globalizado. Segundo Elhajji (1999), “Não há como negar que a conjugação da dinâmica da globalização ao seu correlato tecnoorganizacional, cristalizado no processo de convergência dos meios de comunicação, é portadora de uma profunda força transformadora de todas as condições existenciais da vida contemporânea, desde nossas estruturas sociais, nossos modos de produção e de representação política, até as regras de convivilidade, o sentido de cultura ou ainda o entretenimento. Na verdade, essas mudanças estruturais já estão afetando o conjunto de nosso aparato social material e simbólico, tanto na maneira de organizar nossos lares e nossos círculos afetivos, como nos modos de nos relacionarmos com a comunidade".. Neste sentido complementa Aun (1999) que, “As transformações do mercado, em nível mundial, atingem as economias dos Estados pelos processos de privatizações e da desregulamentação do mercado, limitando a participação dos Estados ao fornecimento de tradicionais bens públicos e à tarefa de regulamentar. Tais processos atingem o campo informacional por meio das Tecnologias de Informação e Comunicação (TIC), cuja valorização, nas últimas décadas, atinge o seu ápice com o surgimento das infovias de informação, ou redes, com destaque todo especial para a Internet”..

(31) 22. Senra (1999) complementa que, “A informação sempre foi importante, promovendo, em diferentes tempos e espaços, expressivas aberturas de mundo. Entretanto, no limiar do terceiro milênio, em que o marcante movimento de globalização agita, para o bem e/ou para o mal, o nosso viver, sua importância se apresenta ainda mais intensa e potente. De fato, em um mundo que concorre, a informação que engendra conhecimento se faz o recurso básico da produção, levando a uma intensa renovação organizacional”.. Neste contexto, a dependência e demanda crescentes da sociedade, em relação às Tecnologias de Informação e Comunicação, têm ressaltado uma série de problemas relacionados ao processo de desenvolvimento de software – um dos componentes fundamentais na concepção das TICs – quais sejam: alto custo, alta complexidade, dificuldade de manutenção e uma disparidade entre as necessidades dos usuários e o produto desenvolvido. Segundo Cordeiro (2000) apud Bona (2002,pág 14), “empresas de software em todo o mundo empregam perto de 7 milhões de técnicos e geram anualmente uma receita de mais de 600 bilhões de dólares, com taxa de crescimento de mais de 25% nos últimos três anos”. Contudo, segundo Semeghini (2001) apud Bona (2002,pág 16) “no Brasil, cerca de 87% das empresas de desenvolvimento de software são de pequeno e médio portes. Isto implica que existem limitações de recursos a serem aplicados em treinamento e consultorias voltadas à implantação de qualidade de software e de um processo que garanta resultados adequados ”. Segundo Tkach e Puttick (1994), “A medida em que a capacidade computacional e as facilidades de acesso a estes recursos computacionais têm aumentado com os avanços tecnológicos, a complexidade dos sistemas a serem desenvolvidos tem aumentado da mesma forma. Mais e mais usuários são atendidos pelos sistemas computacionais e cientes destas facilidades disponíveis, estes usuários estão demandando cada vez mais novas facilidades”.. Além da dificuldade em atender a estas novas demandas, o backlog de manutenção também é um aspecto crítico a ser considerado. Várias das técnicas para análise, projeto e documentação de sistemas utilizadas para implementar sistemas que atendam àquelas demandas, não são flexíveis o suficiente para viabilizar um rápido atendimento das mesmas. Esta situação é comumente referida na literatura como: a crise do software. (TKACH e PUTTICK, 1994)..

(32) 23. “Esta crise demanda para os departamentos de gerenciamento de sistemas de informação soluções que aumentem a produtividade em pelo menos uma ordem de magnitude. Não há dúvidas que a mudança em algum dos elementos - seja ele uma ferramenta, uma habilidade (skill), uma linguagem de programação ou um paradigma – poderiam produzir tal aumento de produtividade. Tkach e Puttick(1994).. A referida crise tem várias facetas e a afirmação a seguir caracteriza bem a complexidade do problema: “A metáfora do computador transparente descreve um dos principais objetivos da engenharia de software contemporâneo – ramo da engenharia da informação que se preocupa com o desenvolvimento dos programas complexos (software) necessários para converterem um montículo inerte de dispositivos (hardware), num instrumento poderoso tão fácil de ser usado como são o lápis e o papel. Quem já esperou um dia ou mais por um programa de computação convencional que nem sequer chegou a ser processado apenas porque uma vírgula fora mal colocada, poderá testemunhar que ainda não chegou o dia em que a transparência computacional instantânea estará a serviço de todos.” Anthony G. Oettinger (1966).. O problema destacado por Oettinger infelizmente ainda hoje, 37 anos depois, é uma realidade nos ambientes de desenvolvimento de software – um simples ponto, ou vírgula, ou ponto e vírgula, indevidamente posicionado ou ausente, pode ser o fator determinante na produção de um software que funciona corretamente ou não. E são fatores como este que fazem com que a crise do software ainda hoje continue presente nas organizações. Corroborando esta afirmação, é apresentado em Rational (2001) apud Ferreira (2002) um estudo realizado em 1995 pelo Standish Group, abrangendo mais de 352 empresas e envolvendo mais de 8.000 projetos de software, o qual apresentou os seguintes resultados: •. 31% dos projetos de software são cancelados antes de serem concluídos;. •. 53% dos projetos ultrapassam os custos estimados e,. •. Em pequenas empresas, apenas 16% dos projetos de software são concluídos dentro do tempo e do orçamento previstos. Nas grandes empresas, este número cai para 9%.. Segundo Ferreira (2002), para a solução desta chamada crise do software, foram definidos complexos conjuntos de princípios, técnicas, métodos e ferramentas que suportam atividades de desenvolvimento de software. No contexto das empresas envolvidas com o desenvolvimento de software, as diversas estruturas propostas resultam em dificuldades. A ausência de simplicidade dos modelos propostos para o software, forma barreiras que inibem a sua aplicação (BACH, 1994 apud FERREIRA,2002). Torna-se difícil a identificação das estruturas mais importantes. e de como se relacionam com as demais propostas. Também existem dúvidas em relação.

(33) 24. ao real progresso a ser alcançado na implementação das referidas propostas (SHEARD,2001 apud FERREIRA ,2002). Ainda segundo Ferreira (2002), “No âmbito das jovens empresas em fase de formação e crescimento no mercado de software, estas dificuldades são agravadas. Caracterizadas por processos informais, grande escassez de recursos disponíveis, sobrecarga de trabalho e um imaturo conhecimento de software, estas empresas contribuem para as estatísticas negativas da crise de software e do mercado de novos empreendimentos”.. A partir destas considerações cabe destacar: um sistema operacional é um produto de software – portanto, está sujeito aos mesmos problemas. Um exemplo disto é a afirmação recente de Steve Ballmer (CEO da Microsoft) (WATERS,2003): "O sistema operacional Windows 2003 Server é seguro por definição (secure by design) e nós investimos U$200 milhões neste projeto. Ele é seguro por definição com 60% menos superfície de ataque em comparação ao NT4 service pack 3”.. A afirmação de Nagle (1994) também caracteriza estes aspectos: “Muitos projetos recentes tais como Windows NT, Mach 3.0, Chorus, System V e Sprite são projetados para minimizar o custo do porte para outras plataformas suportando múltiplas APIs. Contudo, as facilidades adicionais destes projetos possuem um custo associado: são mais lentos que os sistemas tradicionais”.. Desde os primórdios da computação, a comunidade de Sistemas Operacionais estuda e implementa estratégias e soluções em software, conjugadas com soluções em hardware, que visam permitir a utilização do hardware da forma mais adequada e eficiente possível. Caracterizada como uma área que desenvolve soluções de baixo nível, devido à íntima relação com as características e funcionalidades do hardware sobre o qual estas soluções são construídas, experimentou um período de evidência até o final da década de 80. Este fato pode ser constatado pelo grande número de publicações científicas especializadas na área e corroboradas, inclusive, sob a chancela de organizações como ACM (Association of Computer Machinery) e IEEE (Institute of Electrical and Electronic Engineers). Precursora da área de Engenharia de Software, a comunidade de Sistemas Operacionais experimentou todo tipo de dificuldades no que tange ao desenvolvimento de suas soluções de software, visto que, para viabilizá-las, teve que propor e testar, na prática, várias técnicas de gerência de projetos, especificação de software, construção de.

(34) 25. compiladores, depuradores, otimizadores de código e até mesmo linguagens de programação. Restrita a grupos que se foram especializando dentro das instalações fabricantes de hardware, os cientistas de software começaram a entrar em evidência a partir do momento em que a IBM decidiu comercializar tanto hardware como software. Segundo Deitel (1990), este é o marco que estabeleceu o início da área de Engenharia de Software. Isto porque problemas que eram antes restritos aos fabricantes e às poucas instalações que possuíam computadores extrapolaram com o surgimento de empresas denominadas de software houses. Seguindo este processo evolutivo, a área de Engenharia de Software começou a identificar segmentos que necessitavam aprofundamento de pesquisa e vários cientistas que anteriormente trabalhavam com Sistemas Operacionais, paulatinamente começaram a enquadrar suas atividades de pesquisa e desenvolvimento em segmentos da área de Engenharia de Software. O aspecto filosófico que está por trás da evolução da computação em geral é o de liberar os programadores de detalhes desnecessários. A idéia tem sido de que, quanto maior o nível de abstração permitido, mais complexos são os problemas que eles podem resolver. Isto porque havia no passado uma realidade impondo sérias restrições na forma de utilização das máquinas – custo de hardware e software muito elevados e requisitos de qualidade, confiabilidade e performance incomparavelmente inferiores aos de hoje. Segundo John McCarty (1966), “Em 1966 o governo americano gastava metade do orçamento de U$844 Mi com software. Além disso, havia aproximadamente 35.200 computadores, 200.000 programadores e 2100 grandes sistemas custando U$ 1Milhão cada (AFIPS - American Federation of Information Processing Societies)”.. Segundo Moeller (1991), alguns dos maiores avanços na história da computação convencional (Figura 1) têm sido motivados por esta filosofia, conforme se pode observar nos exemplos a seguir: •. Linguagens de montagem (assembly): para evitar que um programa fosse codificado em zeros e uns, foram desenvolvidos os montadores e, a partir daí, os programadores passaram a expressar suas idéias em termos de instruções mnemônicas de mais alto nível;. •. Linguagens de alto nível: para evitar preocupações com detalhes de hardware e instruções de baixo nível, foram desenvolvidas as linguagens de programação contendo estruturas.

(35) 26. lógicas mais abstratas. Isto permitiu que os programadores pudessem expressar suas intenções sem ter que se preocupar com um tipo em particular de hardware e/ou conjunto de instruções; •. Alocação dinâmica de memória: para liberar os programadores do planejamento antecipado de suas necessidades de memória, foram desenvolvidas estratégias de alocação dinâmica e disponibilizadas em linguagens de alto nível (ex: Java).. •. Orientação a objetos e aspectos: para auxiliar o programador a organizar e proteger suas estruturas desenvolveu-se o conceito de objetos, o qual permite manipulações de mais alto nível sobre as mesmas. A técnica de programação orientada a aspectos (AOP) visa solucionar estes problemas através do principio da separação de interesses (concerns), no qual são separados o código de um componente do código de um aspecto.. Observa-se que este processo evolutivo tem ocorrido em função de um usuário especializado conhecido como “o programador”. Este vem recebendo todas as atenções por décadas, enquanto outro tipo de usuário, conhecido como usuário final, não vem recebendo a atenção devida.. Figura 1 - Evolução das abstrações em favor do programador.. O próprio caminho evolutivo de hardware facilitou o surgimento de desenvolvedores de hardware específicos, os quais importaram desenvolvedores para implementar o que começou a ser denominado de firmware (e/ou a camada de device drivers1) específicos para aquele hardware. À medida que este processo tornou-se mais e mais rápido, em função da explosão do uso de tecnologia de computação na sociedade, mais e mais o conceito de projetistas de sistemas operacionais tornou-se nebuloso.. 1. Camada de software especializada que contém instruções que comandam os componentes controladores dos dispositivos de hardware..

(36) 27. Segundo Cordeiro (2000) apud Bona (2002), inicialmente acumulados na parcela de hardware, os custos de sistemas computacionais deslocaram-se para a parcela de software. Este fenômeno ocorreu em função da estabilidade alcançada pelos projetos de hardware, bem como pelo surgimento de exigências crescentes em complexidade para os sistemas de software. Também contribuíram problemas emergentes nos processos de desenvolvimento e manutenção de software. Esta migração pode ser constatada a partir da verificação de que a grande maioria dos eventos científicos e das publicações especializadas da área de Sistemas Operacionais, ou acabaram ou foram incorporados como tópicos em eventos ou publicações mais abrangentes. O mercado experimenta, atualmente, a polarização em basicamente duas linhas de sistemas operacionais2: os baseados em Unix e os baseados na arquitetura Microsoft. Desapareceram do mercado soluções como OS/2 e, mais recentemente, o BeOS. Hoje as atenções estão voltadas para novas formas de interação com o usuário, soluções envolvendo Internet (como e-learning, e-commerce e teletrabalho utilizando tecnologias como CORBA, RMI e Java), computação móvel e computação ubíqua, as quais são concebidas, de uma forma geral, sobre alguma das plataformas comercialmente disponíveis. A análise da literatura relacionada à identificação de algumas das novas demandas - Capítulo 3 -, bem como à forma de concepção e projeto dos sistemas operacionais (que constituem a base a partir da qual as TICs são tornadas viáveis) – Capítulo 2 - e à forma como a tecnologia de informações é utilizada para superar as limitações dos sistemas operacionais – Capítulo 4 -, indica a inexistência de trabalhos que reconheçam a importância estratégica que uma nova concepção de sistema operacional, baseado em técnicas de IA, Robótica e Engenharia do Conhecimento, pode trazer para a comunidade de Tecnologia de Informação e Comunicação.. 2. Estes são os produtos dominantes no mercado de computadores desktop e notebooks, embora existam outras propostas como: AS-400 da IBM, Mac OS-X da Apple, a linha de tempo real como QNX e, naturalmente, os sistemas para Mainframe, como o OS/390 da IBM. Embora não seja o foco deste trabalho discutir os aspectos relativos a estas categorias de sistemas, várias considerações apresentadas são a eles aplicáveis..

(37) 28. 1.1.1 Tema de Pesquisa Segundo Oliveira (2002), a formulação do tema de pesquisa pode ser descritiva ou normativa. O tema desta pesquisa, de caráter descritivo, está centrado nas dificuldades que a área de Sistemas Operacionais tem, historicamente, em atender às novas demandas e exigências que surgem, decorrentes da evolução tecnológica, e à evidente necessidade de propor soluções para amenizar e resolver tais dificuldades. As evidências são apresentadas no capítulo 5. A linha mestra do trabalho visa a identificação dos fundamentos conceituais e dos requisitos funcionais e não funcionais, bem como a especificação de uma nova estrutura de Sistema Operacional Baseado em Conhecimento (SOBC), de modo a permitir a construção de novas formas de abstrações que possibilitem a superação de problemas clássicos e recorrentes em sistemas computacionais. 1.1.2 Problema de Pesquisa Buscando uma formulação mais específica, o problema de pesquisa é apresentado indicando de forma mais precisa as dificuldades que se pretende resolver. Segundo o diretor de tecnologia de processamento de informações da agência DARPA (Defense Advanced Research Projects) Ronald J. Brachman: “(…) infelizmente, os melhoramentos constantes na velocidade dos processadores apresenta duas dificuldades: enquanto nos dão a oportunidade de construir grandes e melhores coisas, eles inexoravelmente nos conduzem a fazer coisas grandes e, bem, coisas muito grandes. O tamanho dos sistemas de software está aumentando num espiral virtualmente descontrolado – hoje é comum encontrarem-se aplicações que ocupam 50Mbytes e que possuem 5 milhões de linhas de código – e nós sabemos que este crescimento em complexidade inevitavelmente conduz a sérias e novas vulnerabilidades. Sob a perspectiva de segurança, maior complexidade significa mais possibilidades para um intruso encontrar caminhos para entrar; sob a perspectiva de robustez, mais elementos significam mais caminhos que podem conduzir a erros; sob a perspectiva de manutenção, mais código significa que os custos de manter as coisas rodando crescem continuamente; e, sob a perspectiva de treinamento, significa que mais pessoas precisam gastar mais tempo aprendendo como usar sistemas baseados em computador. E eu ainda não toquei em algo que nos afeta todos os dias – a chamada usabilidade dos nossos sistemas.Tudo isto nos conduz a uma conclusão muito clara: nós necessitamos de alguma coisa dramaticamente diferente. Nós não podemos meramente aumentar a capacidade e velocidade dos nossos computadores. Nós não podemos somente fazer uma engenharia de software melhor. Nós precisamos mudar nossa perspectiva em sistemas computacionais e mudar a trajetória atual(…)” Brachman(2002).3. 3. Os grifos são nossos..

(38) 29. O cenário apresentado anteriormente deve-se, em parte, à enorme demanda por novas soluções que a sociedade impõe ao mercado e que, portanto, fazem com que as empresas tenham que produzir soluções em software cada vez mais rápido. Este processo conduz às questões de reaproveitamento de esforço (código, conhecimento, recursos financeiros, etc) para “não ser necessário reinventar a roda”. Na área da pesquisa também existe muita pressão por prazos e resultados, o que induz a adoção de uma base estável como forma de ganhar tempo e concentrar esforços no alvo dos projetos. Contudo, há um outro aspecto a ser considerado e que está relacionado à virtualização do operador de computador4. À medida que ocorrem a evolução tecnológica e a miniaturização dos computadores, várias funções vêm sendo incorporadas ao sistema na forma de comandos e interpretadores de comandos. A figura do operador desapareceu no contexto de computadores desktops (notebooks e palmtops) e surgiu a figura do usuário. Hoje quem usa um computador tem que saber como operá-lo, ou seja, como preparar os dados, como recuperar arquivos, como configurar programas, onde colocar os arquivos, em que formato armazenar, quando realizar uma cópia de segurança (backup), etc. Ou seja, o processo de virtualização do operador transformou o sistema operacional num facilitador de uso (uma espécie de proxy server) e o usuário num operador especializado. Esta necessidade de aprender a operar é, por si só, um fator de exclusão social, na medida em que pessoas necessitam ser treinadas a operar “botões lógicos” para serem aproveitadas pelo mercado de trabalho. E como a área de computação evolui muito rapidamente, esta necessidade de (re) treinamento torna-se algo tão corriqueiro que chega a ser óbvia no modelo atual. Este caráter de virtualização do operador pode ser caracterizado a partir da seguinte afirmação: “Na Engenharia Semiótica, a interface é vista como uma mensagem unidirecional enviada dos projetistas para os usuários. Segundo esta abordagem, a mensagem é um artefato de metacomunicação, já que não apenas os projetistas se comunicam com os usuários, mas a própria interface troca mensagens com os últimos. Neste contexto, a interface é um conjunto de signos que são representações que os projetistas usam para comunicar aos usuários como manipular o sistema para atingir seus objetivos” De Souza (1993).. 4. Posição ocupada pelo pessoal responsável por efetivamente operar computadores, executando funções como montar discos e fitas, retirar relatórios da(s) impressora(s), disparar a execução de programas e acompanhar o funcionamento do sistema como um todo..