framework para sistemas de comando e controle: … · ano do curso sempre se colocaram a...
TRANSCRIPT
INSTITUTO MILITAR DE ENGENHARIA
MAJ (CBMERJ) SYLVIO JORGE DE SOUZA JUNIOR
FRAMEWORK PARA SISTEMAS DE COMANDO E CONTROLE:
DEFINIÇÃO A PARTIR DO DOMÍNIO DE DEFESA CIVIL
Dissertação de Mestrado apresentada ao curso de Mestrado em
Sistemas e Computação do Instituto Militar de Engenharia, como
requisito parcial para a obtenção do título de Mestre em Ciências
em Sistemas e Computação.
Orientadora: Prof. Ana Maria de Carvalho Moura – Dr. Ing.
Co-Orientador: Ulf Bergmann – M. Sc.
Rio de Janeiro
2002
2
c2002
INSTITUTO MILITAR DE ENGENHARIA
Praça General Tibúrcio, 80 – Praia Vermelha
Rio de Janeiro – RJ CEP: 22290-270
Este exemplar é de propriedade do Instituto Militar de Engenharia, que poderá
incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar
qualquer forma de arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre
bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que
esteja ou venha a ser fixado, para pesquisa acadêmica, comentários e citações,
desde que sem finalidade comercial e que seja feita a referência bibliográfica
completa.
Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(res)
e do(s) orientador(res).
S729 Souza Junior, Sylvio Jorge.
Framework para sistemas de comando e controle: definição a partir do domínio de defesa civil / Sylvio Jorge de Souza Junior. – Rio de Janeiro: Instituto Militar de Engenharia, 2002.
130 p. : il., tab.
Dissertação (mestrado) : Instituto Militar de Engenharia, 2002.
1. Framework. 2. Orientação a objetos. 3. Reutilização. 4. Defesa civil. 5. Comando e controle. I. Instituto Militar de Engenharia. II. Título.
CDD 005.1
3
INSTITUTO MILITAR DE ENGENHARIA
MAJ (CBMERJ) SYLVIO JORGE DE SOUZA JUNIOR
FRAMEWORK PARA SISTEMAS DE COMANDO E CONTROLE:
DEFINIÇÃO A PARTIR DO DOMÍNIO DE DEFESA CIVIL
Dissertação de Mestrado apresentada ao curso de Mestrado em Sistemas e Computação do Instituto Militar de Engenharia, como requisito parcial para a obtenção do título de Mestre em Ciências em Sistemas e Computação.
Orientadora: Profª. Ana Maria de Carvalho Moura – Dr. Ing. Co-Orientadora: Prof. Ulf Bergmann – M. Sc.
Aprovada em 03 de março de 2002 pela seguinte Banca Examinadora:
__________________________________________________________________ Profª. Ana Maria de Carvalho Moura – Dr. Ing., IME - Presidente
__________________________________________________________________ Prof. Ulf Bergmann – M. Sc., IME
__________________________________________________________________ Prof. Mauro Guedes Ferreira Mosqueira Gomes, D. SC., IME-RJ
__________________________________________________________________ Prof. Luis Alfredo Vidal de Carvalho, Ph. D., COPPE/RJ
Rio de Janeiro 2002
4
Agradeço a Deus, pela vida.
Aos meus pais, pela minha vida.
A minha esposa, por ela e pela vida do meu filho.
Ao meu filho, pela alegria da minha vida.
5
AGRADECIMENTOS
A Deus, por cada minuto de graça concedida para a concretização deste trabalho.
A meu pai e mãe (em memória), que sempre me mostraram o caminho da verdade e da
honra.
À minha esposa Cristina, que pacientemente permaneceu ao meu lado durante este
período e ao meu filho Igor, que é a principal razão deste esforço.
Ao Corpo de Bombeiros Militar do Estado do Rio de Janeiro, pela confiança concedida
para que eu pudesse aprimorar meus conhecimentos.
Ao Instituto Militar de Engenharia, instituto de ensino ao qual sempre almejei estudar e
que me aceitou como aluno, transmitindo-me valiosos ensinamentos.
À professora Ana Maria do IME, minha orientadora, pela paciência em transmitir seus
conhecimentos e pelo grande incentivo para a concretização deste trabalho.
Ao MAJ Ulf Bergmann, meu co-orientador, pelas valiosas observações e intervenções,
sempre demonstrando uma aguçada inteligência e um elevado espírito de colaboração ao
longo do desenvolvimento deste trabalho.
Ao CC(FN) Cezar, ao CAP Victorino, e ao TEN Paulo Renato, que durante o primeiro
ano do curso sempre se colocaram a disposição para auxiliar-me.
À aluna Tania, pelas valiosas e esclarecedoras conversas.
A todos os demais que participaram direta ou indiretamente neste trabalho.
6
SUMÁRIO
LISTA DE ILUSTRAÇÕES ................................................................................................................................................ 8
LISTA DE TABELAS .........................................................................................................................................................10
LISTA DE ABREVIATURAS E SÍMBOLOS ..............................................................................................................11
1 INTRODUÇÃO.....................................................................................................................................................15
1.1 POSICIONAMENTO DO TRABALHO.............................................................................................................15 1.2 OBJETIVOS DA DISSERTAÇÃO......................................................................................................................16 1.3 ORGANIZAÇÃO DA DISSERTAÇÃO..............................................................................................................17
2 COMANDO E CONTROLE NA DEFESA CIVIL .....................................................................................18
2.1 INTRODUÇÃO........................................................................................................................................................18 2.2 CONCEITOS DE COMANDO E CONTROLE .................................................................................................19 2.3 O MODELO DE PROCESSOS DE COMANDO E CONTROLE (MPC2)....................................................20 2.4 O PAPEL DA DEFESA CIVIL..............................................................................................................................22 2.5 DEFESA CIVIL NO MUNDO ..............................................................................................................................23 2.6 DEFESA CIVIL NO BRASIL...............................................................................................................................25 2.6.1 ORGANIZAÇÃO ......................................................................................................25 2.6.2 O CONTEXO BRASILEIRO......................................................................................28 2.6.3 A OPERACIONALIDADE .........................................................................................28 2.6.4 SITUAÇÃO PARTICULAR NO ESTADO DO RIO DE JANEIRO .................................29 2.6.5 O PROBLEMA DO COMANDO E CONTROLE ..........................................................30 2.6.6 A PROPOSTA .........................................................................................................31 2.7 CONSIDERAÇÕES FINAIS .................................................................................................................................31
3 ESTUDO DE FRAMEWORKS ........................................................................................................................33
3.1 INTRODUÇÃO........................................................................................................................................................33 3.2 CONCEITUAÇÃO..................................................................................................................................................33 3.3 CLASSIFICAÇÃO..................................................................................................................................................36 3.4 UM PEQUENO EXEMPLO ..................................................................................................................................38 3.5 OUTRAS TÉCNICAS DE REUTILIZAÇÃO ....................................................................................................41 3.5.1 LINGUAGENS DE PROGRA MAÇÃO ........................................................................41 3.5.2 BIBLIOTECAS DE FUNÇÕES ..................................................................................42 3.5.3 INTERFACES..........................................................................................................42 3.5.4 PADRÕES DE PROJETO (DESIGN PATTERNS)......................................................42 3.5.5 ARQUITETURAS DE SISTEMAS .............................................................................43 3.5.6 COMPONENTES.....................................................................................................44 3.5.7 LINHA DE PRODUTO (PRODUCT LINE)..................................................................44 3.6 ABORDAGENS DE DESENVOLVIMENTO ...................................................................................................45 3.6.1 GENERALIZAÇÃO SISTEMÁTICA ...........................................................................45 3.6.2 DESENVOLVIMENTO BASEADO EM EXPERIÊNCIAS .............................................47 3.6.3 DESENVOLVIMENTO BASEADO EM ANÁLISE DE DOMÍNIO ..................................47 3.6.4 DESENVOLVIMENTO DIRIGIDO A REGIÕES QUENTES (HOT SPOTS)...................48 3.6.5 DIAGRAMA DE FRAMEWORK (DF) .........................................................................49 3.6.6 TÉCNICAS PARA GERAÇÃO DO DF BASEADAS NA UML.......................................50 3.6.7 METODOLOGIA DE DESENVOLVIMENTO DE FRAMEWORKS ORIENTADO A OBJETO BASEADA NA UML .......................................................................................................54 3.6.8 O PROCESSO DE DESENVOLVIMENTO UTILIZADO ..............................................56 3.7 CONSIDERAÇÕES FINAIS .................................................................................................................................57
4 UM MODELO PARA O SIS TEMA NACIONAL DE DEFESA CIVIL...............................................59
4.1 INTRODUÇÃO........................................................................................................................................................59 4.2 A OBTENÇÃO DO MODELO DE REQUISITOS............................................................................................59
7
4.3 UMA ARQUITETURA PARA O SISTEMA NACIONAL DE DEFESA CIVIL........................................61 4.4 AS FUNCIONALIDADES DO SISTEMA .........................................................................................................67 4.5 O MPC2 E O SISTEMA OPERATIVO DE DEFESA CIVIL (SODC) ...........................................................70 4.6 O MODELO ESTRUTURAL................................................................................................................................72 4.6.1 CASO DE USO INSERIR RISCO ..............................................................................73 4.6.2 CASO DE USO INSERIR RECURSO........................................................................75 4.6.3 CASO DE USO CRIAR PLANOS ..............................................................................76 4.6.4 CASO DE USO ATENDER OCORRÊNCIA ...............................................................79 4.6.5 GENERALIZAÇÃO DAS AÇÕES ..............................................................................82 4.6.6 O DIAGRAMA DE CLASSES FINAL .........................................................................84 4.7 O MODELO DINÂMICO ......................................................................................................................................85 4.8 CONSIDERAÇÕES FINAIS .................................................................................................................................86
5 O FRAMEWORK PROPOSTO .......................................................................................................................87
5.1 INTRODUÇÃO........................................................................................................................................................87 5.2 O MODELO ESTRUTURAL DO FRAMEWORK .............................................................................................87 5.2.1 CLASSES EVENTO, LOCAL, FATO, DANO, RISCO E OCORRÊNCIA.......................87 5.2.2 CLASSES INSTITUIÇÃO, AGÊNCIA, PLANO E ATUAÇÃO .......................................89 5.2.3 CLASSES DISPONIBILIDADE E RECURSO .............................................................90 5.2.4 CLASSES AÇÃO, EMPREGO E UTILIZAÇÃO ..........................................................91 5.2.5 O DIAGRAMA DE CLASSES FINAL .........................................................................92 5.3 O MODELO DINÂMICO DO FRAMEWORK ...................................................................................................93 5.4 O FRAMEWORK PROPOSTO E OS PROCESSOS DE C2 ..............................................................................93 5.5 CONSIDERAÇÕES FINAIS .................................................................................................................................95
6 CONCLUSÃO........................................................................................................................................................97
7. REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................................................99
8 APÊNDICES ........................................................................................................................................................102
8.1 APÊNDICE 1: DESCRIÇÃO DOS CASOS DE USO DO SODC................................................................ 103 8.2 APÊNDICE 2: DIAGRAMAS DE SEQUÊNCIA DO SODC....................................................................... 109 8.3 APÊNDICE 3: CARTÕES DE CRC DO SODC .............................................................................................. 115 8.4 APÊNDICE 4: DIAGRAMAS DE SEQUÊNCIA DO FRAMEWORK ........................................................ 120 8.5 APÊNDICE 5: CARTÕES DE CRC DO FRAMEWORK ............................................................................... 126
8
LISTA DE ILUSTRAÇÕES FIG. 2.1 - Modelo de Processos de C2 (MPC2) ........................................................................ 20 FIG. 2.2 - Modelo O-O-D-A de John Boid .............................................................................. 21 FIG. 2.3 - Modelo de processo C3I de Lawson........................................................................ 22 FIG. 2.4 - Organização do SINDEC ........................................................................................ 26 FIG. 3.1 - Especificação e Implementação com frameworks................................................... 35 FIG. 3.2 - Representação dos aspectos caixa branca e caixa preta de um framework ............. 37 FIG. 3.3 - Exemplo da codificação para a classe abstrata F..................................................... 38 FIG. 3.4 - Exemplo de codificação para as pós condições da classe abstrata F....................... 39 FIG. 3.5 - Exemplo de codificação para o método Run( ) da classe concreta CF.................... 40 FIG. 3.6 - Os membros extras (propriedades) das classes C e R ............................................. 40 FIG. 3.7 - Exemplo de codificação para o método IsIn( ) da classe C..................................... 41 FIG. 3.8 - Atividades do Projeto de Frameworks por Generalização ...................................... 46 FIG. 3.9 - Processo de Desenvolvimento Dirigido a Hot-Spots............................................... 49 FIG. 3.10 - Notação do Diagrama de Framework.................................................................... 50 FIG. 3.11 - Processo de Modelagem de Frameworks baseado na UML.................................. 53 FIG. 3.12 - Meta-modelo dos relacionamentos entre os diagramas UML e os elementos de um
diagrama de framework.................................................................................................... 53 FIG. 3.13 - Fases da análise da Metodologia de Desenvolvimento de Frameworks OO baseada
na UML............................................................................................................................ 54 FIG. 3.14 - Fases do projeto da Metodologia de Desenvolvimento de Frameworks OO
baseada na UML............................................................................................................... 55 FIG. 3.15 - As fases de implementação e testes da Metodologia de Desenvolvimento de
Frameworks OO baseada na UML................................................................................... 56 FIG. 4.1 - Estrutura de um órgão de defesa civil ..................................................................... 60 FIG. 4.2 - Blocos Administrativo e Operativo, e suas atividades ............................................ 61 FIG. 4.3 - Arquitetura do bloco operativo ................................................................................ 62 FIG. 4.4 - Modelo de Casos de Uso do Sistema Operativo de Defesa Civil............................ 67 FIG. 4.5 - Modelo de Casos de Uso referentes ao escopo do estudo ....................................... 68 FIG. 4.6 - Similaridade entre Atender Ocorrência e Inserir Risco e Criar Plano ..................... 69 FIG. 4.7 - Casos de Uso auxiliares para Criar Plano e Criar Atuação ..................................... 69 FIG. 4.8 - Diagrama de Classes referente ao caso de uso Inserir Risco................................... 73 FIG. 4.9 - Diagrama de objetos representando os riscos.......................................................... 74 FIG. 4.10 - Diagrama de Classes referente ao caso de uso Inserir Recurso............................. 75 FIG. 4.11 - Diagrama de objetos representando a disponibilidade de recursos....................... 76 FIG. 4.12 - Diagrama de Classes referente ao caso de uso Criar Planos ................................. 77 FIG. 4.13 - Diagrama de objetos representando a criação de Planos para um Risco............... 78 FIG. 4.14 - Diagrama de objetos representando a composição de Ações ................................ 78 FIG. 4.15 - Diagrama de Classes referente ao caso de uso Inserir Ocorrência ........................ 79 FIG. 4.16 - Diagrama de objetos representando a inserção de uma nova Ocorrência ............. 80 FIG. 4.17 - Diagrama de Classes referente ao caso de uso Criar Atuação............................... 81 FIG. 4.18 - Diagrama de objetos representando uma Atuação em uma Ocorrência................ 82 FIG. 4.19 - Diagrama de Classes referente à generalização da classe Ação ............................ 84 FIG. 4.20 - Diagrama de classes do sistema operativo de defesa civil .................................... 85 FIG. 5.1 - Generalização esperada das classes Evento, Local e Fato ...................................... 88 FIG. 5.2 - Obtenção das classes genéricas Acontecimento e Característica............................ 88 FIG. 5.3 - Generalização referentes às classes Evento, Local, Fato, Dano, Risco e Ocorrência
9
.......................................................................................................................................... 89 FIG. 5.4 - Generalização referente às classes Instituição, Agência, Plano e Atuação ............. 90 FIG. 5.5 - Generalização referente às classes Disponibilidade e Recurso ............................... 90 FIG. 5.6 - Diagrama de classes referente às ações................................................................... 91 FIG. 5.7 - Diagrama de classes do framework ......................................................................... 92 FIG. 5.8 - O framework proposto e os processos de C2 ........................................................... 93 FIG. 8.1 - Diagrama de sequência do SODC referente à inserção de um risco ..................... 109 FIG. 8.2 - Diagrama de sequência do SODC referente à inserção de recursos...................... 110 FIG. 8.3 - Diagrama de sequência do SODC referente a criação de planos .......................... 111 FIG. 8.4 - Diagrama de sequência do SODC referente a inserção de uma ocorrência .......... 112 FIG. 8.5 - Diagrama de sequência do SODC referente à criação de uma atuação................. 113 FIG. 8.6 - Diagrama de sequência do SODC referente à avaliação de uma atuação ............. 114 FIG. 8.7 - Diagrama de Sequência do framework referente à inserção de uma Previsão ...... 120 FIG. 8.8 - Diagrama de sequência do framework referente à inserção de Recursos.............. 121 FIG. 8.9 - Diagrama de sequência do framework referente à criação de um Plano ............... 122 FIG. 8.10 - Diagrama de sequência do framework referente à inserção de um Acontecimento
........................................................................................................................................ 123 FIG. 8.11 - Diagrama de sequência do framework referente à criação de uma Atuação ....... 124 FIG. 8.12 - Diag. de sequência do framework referente à avaliação de uma Atuação .......... 125
10
LISTA DE TABELAS
TAB. 3.1 - Algoritmo da Modelagem Estrutural de frameworks - Geração do DF baseado na UML................................................................................................................................. 51
TAB. 3.2 - Algoritmo da Modelagem Dinâmica de frameworks - Geração do DF baseado na UML................................................................................................................................. 51
TAB. 3.3 - Relacionamentos entre os Diagramas da UML e os elementos de um Diagrama de Framework ....................................................................................................................... 52
TAB. 3.4 - Fases de implementação e testes da Metodologia de Desenvolvimento de Frameworks OO baseada na UML................................................................................... 55
TAB. 4.1 - Implementação dos processos de C2 pelo SODC .................................................. 71 TAB. 5.1 - Implementação dos processos de C2 pelo framework............................................ 94
11
LISTA DE ABREVIATURAS E SÍMBOLOS
C2 - Comando e Controle
C3I - Comando, Controle, Comunicações e Inteligência
CBMERJ - Corpo de Bombeiros Militar do Estado do Rio de Janeiro
CEDEC - Coordenadoria Estadual de Defesa Civil
CODAR - Codificação de Desastres, Ameaças e Riscos
COMDEC - Coordenadoria Municipal de Defesa Civil
CONDEC - Conselho Nacional de Defesa Civil
CORBA-OMG - Common Object Request Broquer Architeture
CORDEC - Coordenadoria Regional de Defesa Civil
CRC - Classe/Responsabilidade/Colaboração
CRED - Centre for Research on the Epidemiology of Disasters
DCOM - Microsoft’s Distributed Common Object Model
DC - Defesa Civil
DF - Diagrama de Framework
DGAC - Departamento Geral de Apoio Comunitário
GUI - Interface Gráfica de Usuário
ICS - Incident Command System
MFC - Microsoft Fundation Classes
MPC2 - Modelo de Processos de Comando e Controle
NIIMS - National Interagency Incident Management System
NUDEC - Núcleo de Defesa Civil
OO - Orientação a Objeto
ORB - Object Request Broquer
PAHO/WHO - Pan American Health Organization
RMI - Java Soft’s Remote Method Invocation
SC2 - Sistema de Comando e Controle
SEDEC - Secretaria Nacional de Defesa Civil
SEDEC-RJ - Secretaria Estadual de Defesa Civil do Estado do Rio de Janeiro
SINDEC - Sistema Nacional de Defesa Civil
SODC - Sistema Operativo de Defesa Civil
SSD - Sistema de Suporte a Decisão
12
UML - Unified Modeling Language
VDL - Virtual Disaster Library
13
RESUMO
Framework orientado a objetos é uma promissora tecnologia de desenvolvimento de software, que permite a reutilização tanto de código quanto de projeto. Um framework é formado por um conjunto de classes cooperantes que representam os objetos de um domínio em particular. Quando um framework é desenvolvido, os aspectos genéricos do domínio ao qual ele se refere são capturados, e todas as diferentes aplicações que possam ser desenvolvidas para esse domínio se utilizam dos conceitos presentes no framework, havendo dessa forma, uma economia de esforços. Somente os aspectos específicos das aplicações precisam ser modelados, pois o "trabalho pesado" da modelagem, que obteve os requisitos genéricos, já foi feito.
Defesa Civil é o nome utilizado para designar tudo o que se refere aos esforços que tem por objetivo minimizar as consequências de desastres, pela redução das probabilidades de que venham a ocorrer, ou pela otimização dos recursos utilizados nas ações que são realizadas durante e após a sua ocorrência. Os processos de comando e controle, notadamente de uso militar em conflitos, podem ser de grande utilidade para que as ações de Defesa Civil produzam efeitos mais eficazes.
O presente trabalho apresenta uma modelagem para o Sistema Nacional de Defesa Civil, baseada em conceitos de Comando e Controle, e propõe uma padronização para a estrutura e o funcionamento dos órgãos executores de Defesa Civil no Brasil. O objetivo principal é o de desenvolver e apresentar um framework orientado a objetos para sistemas de Comando e Controle, a partir do domínio de Defesa Civil.
14
ABSTRACT
Object-oriented framework is a promising technology of software development that allows the reuse of code and project. A framework is formed by a group of interlinked classes that represent objects of a domain in matter. When a framework is developed, the generic aspects of the domain to which it refers are captured, and all the different applications that can be developed for that domain use the concepts present in the framework, resulting in an economy of efforts. Only the specific aspects of the applications need to be modeled, therefore the "heavy" work of obtaining the generic requirements was already done.
Civil Defense is the name used to designate everything that refers to the efforts to minimize the consequences of disasters, the reduction of the probabilities that they come to happen, or for the optimization of the resources used in the actions that are taken during and after their occurrence. The command and control processes, especially of military use in conflicts, can be usefull so that the civil defense actions produce more effective results.
This work presents a model for the National System of Civil Defense, based on concepts of Command and Control, and proposes a standardization for the structure and the operation of the executive agencies of civil defense in Brazil. The main objective is to develop and present a object-oriented framework for systems of Command and Control, starting from the Civil Defense domain.
15
1 INTRODUÇÃO
1.1 POSICIONAMENTO DO TRABALHO
Assim como as outras engenharias, a engenharia de software é uma tecnologia repleta de
métodos que apresentam características positivas e negativas, e que se adaptam melhor a
determinadas necessidades. Porém, enquanto as demais engenharias concorrem para o
desenvolvimento de produtos "concretos", a engenharia de software promove o
desenvolvimento de um produto extremamente "pastoso" e de difícil mensuração: o software.
Em (METHODOLOGY) é encontrada uma extensa lista com endereços de sítios da Web
contendo informações sobre as mais diversas metodologias de desenvolvimento de software.
Atualmente, algumas tecnologias vêm se destacando e se tornando quase obrigatórias no
desenvolvimento de sistemas informatizados, como é o caso da Unified Modeling Language
(UML) e, mais recentemente, do uso de frameworks orientados a objetos. Tais tecnologias se
destacam devido a possibilidade de construção de sistemas eficientes, portáveis,
interoperáveis, manuteníveis, e de qualidade, além de tornarem o processo de
desenvolvimento mais eficaz, através da reutilização de produtos de softwares.
Um framework orientado a objeto é um conjunto de classes relacionadas entre si, e que
apresentam as funcionalidades genéricas em relação a algum domínio em particular. Esse
domínio pode ser relacionado às regras de um negócio (sistema bancário, aplicação médica,
aplicação de engenharia, etc.) ou à implementação da solução computadorizada (acesso a
banco de dados, comunicação entre computadores, interface gráfica para usuários, etc).
Havendo um framework disponível para o domínio referente ao qual se deseja desenvolver
uma aplicação, basta expandir o framework com as características específicas do domínio em
questão.
Em outro ramo da atividade humana, pessoas se dedicam a salvaguardar vidas e bens,
muitas vezes colocando a própria vida em perigo. São os integrantes dos sistemas de DC
(Defesa Civil) existentes no mundo. Os principais objetivos dos sistemas de DC são a
prevenção dos desastres e a minimização dos prejuízos advindos das suas ocorrências. Para se
alcançar esses objetivos, são definidas ações que devem ser executadas antes, durante e após
16
as ocorrências. Essas ações, em última análise, definem como os recursos necessários (e
disponívies) devem ser utilizados para que os objetivos possam ser alcançados. Dessa forma,
são questões cruciais para a obtenção de resultados ótimos:
? Localizar os recursos;
? Empregar os recursos;
? Definir o que deve ser feito;
? Melhorar a preparação dos recursos humanos; e
? Avaliar a atuação dos órgãos empenhados nas ações.
Tais sistemas se ressentem de um melhor apoio da informática, como será constatado no
capítulo 2. Com um auxílio mais eficaz dessa ciência, provavelmente as respostas aos
desastres serão mais rápidas e eficientes, possibilitando que mais vidas sejam salvas, com
menor esforço.
Este trabalho pretende estudar e desenvolver mecanismos que permitam auxiliar no
desenvolvimento de SC2 (Sistemas de Comando e Controle) de uma maneira geral, e em
especial, de SC2 para a DC, utilizando as tecnologias da Engenharia de Software. Será dado
um enfoque especial no uso da UML, da orientação a objetos, e da tecnologia de frameworks.
1.2 OBJETIVOS DA DISSERTAÇÃO
O objetivo do presente estudo é a definição de um framework para SC2 , a partir do estudo
do domínio da defesa civil. Sua definição tem como principal propósito facilitar o
desenvolvimento de aplicações de comando e controle, principalmente no âmbito da defesa
civil.
Para atingir tal objetivo é realizado um estudo sobre os processos de defesa civil
utilizados no Brasil, bem como sobre os conceitos relacionados ao tema em outras partes do
mundo. É feito também um breve estudo sobre as noções básicas de comando e controle,
relacionando-as com os processos de defesa civil.
Também é feito um estudo sobre frameworks, comparando essa tecnologia com outras
tecnologias de reutilização de software, e apresentando as principais abordagens de
desenvolvimento encontradas nos meios de pesquisa.
17
1.3 ORGANIZAÇÃO DA DISSERTAÇÃO
Esta dissertação está organizada em 6 capítulos que objetivam apresentar aspectos
teóricos e práticos relacionados ao seu desenvolvimento.
Capítulo 1 – Introdução
Apresenta e situa esta dissertação em um contexto global através da exposição de sua
motivação, justificativa e objetivos.
Capítulo 2 – Comando e Controle na Defesa Civil
Neste capítulo são apresentados conceitos de comando e controle, sendo apresentados
alguns modelos de processos. Também é estudado o papel da defesa civil no brasil e no
mundo, além da sua organização e operacionalidade, em especial no Brasil.
Capítulo 3 – Estudo de frameworks
Exibe conceitos atuais relativos a frameworks, apresentando conceitos e as classificações
mais usadas. Faz uma comparação da tecnologia de frameworks com outras técnicas de
reutilização, e apresenta algumas abordagens de desenvolvimento, finalizando com a
descrição do processo de desenvolvimento utilizado no estudo.
Capítulo 4 – Um Modelo para o Sistema Operativo de Defesa Civil
É descrito todo o processo de modelagem do SODC. São definidos: o modelo de
requisitos, o modelo estático e o modelo dinâmico. Os diagramas utilizados na representação
dos modelos são os previstos em (UML).
Capítulo 5 – O Framework Proposto
Neste capítulo é descrito todo o processo de elaboração do framework, a partir do modelo
para o SODC obtido no capítulo anterior, conforme proposto neste trabalho.
Capítulo 6 – Conclusão
Relata de forma sucinta as principais contribuições deste trabalho e apresenta algumas
sugestões para trabalhos futuros.
18
2 COMANDO E CONTROLE NA DEFESA CIVIL
2.1 INTRODUÇÃO
Sistema de Comando e Controle (SC2) é o nome que se dá ao conjunto de princípios,
normas e processos utilizados em operações militares, com o objetivo de proporcionar uma
atuação eficiente das forças envolvidas em um combate. Esse objetivo é alcançado através do
emprego de processos de tomada de decisão, os quais englobam desde a definição da decisão
até o controle da sua execução, passando pela sua divulgação correta. Sua função principal é
estruturar um modelo de processamento das operações militares, com destaque para os
processos de tomada de decisão.
A Defesa Civil (DC) é um instrumento para garantir a segurança da população frente a
desastres naturais ou provocados pelo homem, que põem em risco o ecossistema, o
patrimônio e a vida da população.
As atividades de defesa civil visam basicamente à minimização dos danos e prejuízos
causados por desastres. A atuação se faz através da coordenação da utilização de recursos, que
na sua maioria não pertencem aos órgãos de defesa civil, mas sim a empresas públicas ou
particulares que os cedem por ocasião de ameaça ou ocorrência de desastres.
Questões referentes à disponibilização e ao emprego dos recursos e a atuação de todos os
órgãos envolvidos devem ser tratadas de forma a maximizar a eficiência das ações de defesa
civil. O emprego de processos de C2 nos processos de DC é uma forma de atingir esse
objetivo.
Este capítulo tem por objetivo apresentar os conceitos básicos de SC2 e quais são os
processos de comando e controle empregados na DC. Para isso são apresentados alguns
modelos de processos de comando e controle, é discutido o papel da DC no Brasil e no
mundo, e são mostradas sua organização e operacionalidade, no Brasil e no estado do Rio de
Janeiro.
19
2.2 CONCEITOS DE COMANDO E CONTROLE
Uma das coisas menos discutíveis que se pode dizer sobre SC2 é que este trata de um
domínio de difícil entendimento (ORR, 1983). Diferentemente de sistemas cujos domínios
são bem estruturados e que podem ser razoavelmente entendidos por desenvolvedores de
softwares (por ex.: sistemas de contabilidade, sistemas de leis, etc.), SC2 caracteriza-se por
apresentar, além da arquitetura complexa (também apresentada por diversos domínios
estruturados), um alto grau de dependência de processos mentais ainda não totalmente
mapeados, muitas vezes intuitivos (o grande número de possíveis soluções -saídas- para um
mesmo problema -entrada-, é uma conseqüência desse fato).
Para ficarmos somente no campo das guerras, a história nos mostra que Sistemas de
Comando, Controle, Comunicações e Inteligência (C3I) - termo atualmente utilizado para
designar comando e controle - influenciam bastante no resultado dos conflitos. Porém, a
despeito da sua importância, não existe uma base intelectual adequada nesta área, nem
programas educacionais apropriados (C3I ).
SC2 tem como função principal estruturar um modelo de processamento das operações
militares, com destaque para os processos de tomada de decisão. Resumidamente, um SC2
deve responder às seguintes perguntas relacionadas ao processo de busca e tratamento da
informação pertinente à decisão, como definido em (IME, 2000):
? Como o Sistema obtém e processa as informações sobre o ambiente (área, clima,
terreno, população, aspectos econômicos e sociais) – Bloco 1 / FIG. 2.1;
? Como o Sistema processa as informações de sensores (Radares, Satélites, e as
informações vindas da análise de inteligência) – Blocos 3 e 4 / FIG. 2.1;
? Como o Sistema processa todos os dados e informações obtidas até então e as
disponibiliza para o tomador de decisão de nível estratégico-operacional – Blocos 4 e
5 / FIG. 2.1;
? Como o sistema disponibiliza e avalia as diversas opções (ações propostas de
comando) em suporte ao tomador de decisão de alto nível (estratégico-operacional) –
Blocos 4, 5 e 6 / FIG. 2.1;
? Como a decisão é repassada aos sistemas atuadores, basicamente os tomadores de
decisão de nível tático – Blocos 5, 7 e 8 / FIG. 2.1;
20
? Como o sistema acompanha as ações desencadeadas e os resultados das mesmas
sobre o ambiente - Blocos 7 e 1 / FIG. 2.1 (basicamente a função controle).
1. Ambiente 2. Análise deInteligência
3. Sensoriamento
8. Decisões deBaixo Nível
6. Alto Nível
4. Processamento
5. Decisão
7. Atuação
FIG. 2.1 - Modelo de Processos de C2 (MPC2)
Um ponto importante a ressaltar é a existência de uma profunda correlação entre Sistemas
de Comando e Controle, de uso eminentemente militar e policial, e os Sistemas de Suporte a
Decisão (SSD), utilizados pelas grandes organizações (civis) para facilitar a tomada de
decisões. Podemos afirmar que as mesmas técnicas empregadas no desenvolvimento de SC2
podem ser aplicadas no desenvolvimento de SSD.
2.3 O MODELO DE PROCESSOS DE COMANDO E CONTROLE (MPC2)
Em (ORR, 1983) é definido o Modelo de Processos de C2 (MPC2) de operações de
combate que será utilizado no presente estudo. A FIG. 2.1 apresenta esse modelo.
Como um dos objetivos desse trabalho não é estudar em detalhes os modelos de
processamento de comando e controle (C2), mas sim identificar os elementos de C2 presentes
no modelo proposto para a defesa civil, o modelo MPC2 será o modelo adotado no escopo
deste trabalho. A escolha desse modelo se deve ao fato de que ele se posiciona a meio
caminho entre o modelo O-O-D-A (Observe-Orient-Decide-Act) (BOYD, 1981) e o modelo
C3I (Comando, Controle, Comunicações e Inteligência) (LAWSON, 1980), como será visto
nos próximos parágrafos.
21
Este modelo foi desenvolvido para representar os processos de operações de combate em
qualquer nível da hierarquia militar, indo do estratégico ao operacional. Os detalhes das
funções individuais e a ênfase que cada uma terá, variam segundo o nível hierárquico.
FIG. 2.2 - Modelo O-O-D-A de John Boid
Por exemplo, no nível de aplicação da força (operacional), o bloco "Análise de
Inteligência" não tem tanta importância, e neste caso o MPC2 poderia ser substituído pelo
modelo O-O-D-A (Observar-Orientar-Decidir-Atuar), descrito em (BOYD, 1981) e mostrado
na FIG. 2.2. A função "Sensoriamento" é identificada neste modelo como a função
"Observar", e a função "Análise de Inteligência" se funde com a "Processamento", sendo
representada pela função "Orientar". As outras funções permanecem idênticas.
Já em níveis hierárquicos mais elevados, a função "Análise de Inteligência" ganha
importância, e o MPC2 pode ser estendido para o modelo de processo C3I (Comando,
Controle, Comunicações e Inteligência) de Lawson, descrito em (LAWSON, 1980) e
mostrado na FIG. 2.3. Neste modelo, essa função é vista em detalhes, e suas atividades são
explicitamente mostradas.
22
FIG. 2.3 - Modelo de processo C3 I de Lawson
2.4 O PAPEL DA DEFESA CIVIL
Durante muito tempo, após a Segunda Guerra Mundial, o mundo ficou sob a ameaça
constante de uma guerra total. Este período ficou marcado como “Guerra Fria”. Os dois
blocos de poder mantinham a paz graças ao nivelamento de forças, o que garantia não haver
ganhadores no caso de uma guerra nuclear, já que a destruição atingiria todo o planeta. A
segurança da população mundial dependia desse equilíbrio de forças.
Com o fim da União das Repúblicas Socialistas Soviéticas, a divisão do mundo em dois
blocos de poder ficou esvaziada. A queda do Muro de Berlim foi um prenúncio de que a
antiga queda de força nuclear entre as duas potências mundiais estaria chegando ao fim.
Como o temor de um supremo desastre nuclear diminuiu de forma considerável, os
conceitos relacionados à segurança da população tiveram que ser repensados. Nos últimos
anos, os desastres, de causas naturais ou não, têm afetado um número cada vez maior de
pessoas ao redor do mundo. Esses desastres provocam muito mais danos e prejuízos do que os
provocados pelas guerras. Por exemplo, durante toda a guerra do Vietnã 57 mil norte
23
americanos perderam a vida, ao passo que anualmente morrem no Brasil cerca de 40 mil
pessoas, somente vítimas de acidentes de trânsito (CASTRO, 1997a). Os orçamentos para
ajuda emergencial e humanitária sobem verticalmente, fazendo com que se torne imperioso
uma melhor preparação e atuação em casos de desastres.
A Defesa Civil é um instrumento para garantir a segurança da população frente a
desastres naturais ou provocados pelo homem, que põem em risco o ecossistema, o
patrimônio e a vida da população.
O principal objetivo da Defesa Civil é reduzir os riscos de desastres, preservando o bem-
estar social, e de restabelecê- lo, em caso de danos e prejuízos que envolvam vidas humanas,
perdas materiais, físicas e morais.
Para tanto, é necessário um conjunto permanente de ações para atuar antes, durante e
depois de uma calamidade. As medidas tomadas pela Defesa Civil são de prevenção, para
evitar a ocorrência de desastres ou minimizar a intensidade das suas conseqüências; de
preparação do contingente e dos meios utilizados visando uma melhor eficácia das
operações; de socorro às vítimas em emergências; e de recuperação dos danos da
comunidade afetada.
2.5 DEFESA CIVIL NO MUNDO
Hoje, a maioria dos países mantém algum tipo de organismo empenhado em atuar em
casos de desastres, e vários centros internacionais mantém pesquisas sobre o tema.
Na Bélgica funciona o Centre for Research on the Epidemiology of Disasters (CRED),
instituição não lucrativa criada em 1973, com status internacional segundo as leis da Bélgica.
Está localizada na School of Public Health of the Université Catholique de Louvain (UCL),
em Bruxelas. Em 1980 se tornou um centro de colaboração para a saúde mundial, expandindo
suas ações para a preparação e respostas a emergências. Embora o principal foco do CRED
seja a salvaguarda de vidas, saúde pública e aspectos sanitários dos desastres, lá também se
estudam os efeitos sócio-econômicos e de longo prazo dos desastres. As questões ligadas à
preparação e desenvolvimento de recursos humanos, principalmente as que dizem respeito aos
problemas relacionados ao gerenciamento de situações de risco, estão tendo uma importância
24
crescente dentro das atividades do Centro. O CRED disponibiliza uma base de dados
acessível pela internet, que mantém informações de mais de 1200 desastres importantes
ocorridos ao redor do mundo nos últimos anos, possibilitando pesquisas sobre os impactos, os
perfis e as medidas de prevenção em relação aos desastres.
A Pan American Health Organization (PAHO/WHO), organização voltada para a
melhoria da saúde pública no continente americano, mantém a Virtual Disaster Library
(VDL), uma biblioteca virtual que contém mais de 250 publicações, em inglês e espanhol,
sobre preparação, redução e resposta aos desastres.
Outra importante organização é a International Association of Emergency Managers
(IAEM), organização educacional sem fins lucrativos, que tem por objetivos o salvamento de
vidas e a proteção da propriedade durante emergências e desastres. Ela mantém cursos,
conferências e certificações para promover a melhoria das ações de gerenciamento dos
desastres.
Nos Estados Unidos da América é utilizado o National Interagency Incident Management
System (NIIMS) (NIFC, 1983), sistema formado pelas agências responsáveis pela redução e
respostas aos desastres. Esse sistema consiste de 5 subsistemas que coletivamente
proporcionam uma abordagem para o gerenciamento de incidentes de qualquer tipo e
dimensão. Esses subsistemas são:
? Incident Command System (ICS),
? Training,
? Qualifications and Certification,
? Publication Management,
? Supporting Technology.
O NIIMS ICS (ICS) é um sistema padronizado de gerenciamento de operações de
resposta. Sua abordagem é direcionada a qualquer tipo de incidente, tendo sido criado
originalmente para ser utilizado pelas agências federais, estaduais e locais de combate a
incêndios. Em 1994 foi estendido para melhor refletir a capacidade "All Hazard – All Risk" do
NIIMS, tornando-se apropriado para utilização em terremotos, incêndios, derramamento de
óleos, e qualquer outro tipo de desastre, independente da sua dimensão. Isso se deve a sua
organização flexível, o que o torna capaz de se adaptar às responsabilidades inerentes aos
eventos de qualquer tamanho ou complexidade.
Inúmeros outros centros e organizações se encarregam de estudar os assuntos
relacionados aos desastres. Um de especial interesse para o nosso país é a Asociación
25
Iberoamericana de Organismos Gubernamentales de Defensa y Protección Civil (IBERO). A
Associação teve sua origem em uma reunião organizada em Santiago, Chile, de 1 a 5 de julho
de 1996, relativa a aplicação de tecnologia espacial na prevenção e redução de desastres. Seus
objetivos são o fomento da cooperação científica e técnica em matéria de gestão de desastres e
o incremento e a melhoria das informações e experiências de interesse mútuo para os países
associados, assim como a promoção da capacitação e o desenvolvimento de recursos humanos
no âmbito da DC.
Como resultado da primeira conferência desta Associação Iberoamericana, foram criados
sete grupos de trabalhos para articular os assuntos do seu interesse, organizados da seguinte
maneira:
Grupo 1 - Formação e Capacitação
Grupo 2 - Informação e Divulgação
Grupo 3 - Legislação Comparada.
Grupo 4 - Administração de Situações de Emergência
Grupo 5 - Sistemas Informáticos e de Comunicações
Grupo 6 - Finanças
Grupo 7 - Harmonização Conceitual e de Terminologia
O Brasil mantém representantes nos grupos 1, 2 e 4, e coordena os trabalhos do grupo 7,
que foi recentemente dividido em língua portuguesa e espanhola.
2.6 DEFESA CIVIL NO BRASIL
2.6.1 ORGANIZAÇÃO
A defesa civil no Brasil está organizada sob a forma de sistema, denominado de Sistema
Nacional de Defesa Civil- (SINDEC), composto por vários órgãos, como mostrado na FIG.
2.4. Sua organização é instituída em (BRASIL, 1993), conforme definido em (BRASIL,
1988a), que estabelece, entre outras coisas, que é dever da União legislar sobre defesa civil.
26
COMDEC
COMDEC
CEDEC/SEDEC
COMDEC
COMDEC
CEDEC/SEDEC
CORDEC
COMDEC
COMDEC
CEDEC/SEDEC
COMDEC
COMDEC
CEDEC/SEDEC
CORDEC
COMDEC
COMDEC
CEDEC/SEDEC
COMDEC
COMDEC
CEDEC/SEDEC
CORDEC
SEDEC
CONDEC
FIG. 2.4 - Organização do SINDEC
Cabe ao SINDEC:
? planejar e promover a defesa permanente contra desastres;
? prevenir e minimizar os danos causados por desastres,
? socorrer e assistir às populações vítimas de desastres;
? reabilitar e reconstruir os cenários atingidos por desastres, sendo os Corpos de
Bombeiros Militares, entre outras atribuições, responsáveis pela execução das
atividades de defesa civil, conforme estabelecido na Constituição Federal (BRASIL,
1988b).
O SINDEC, que articula os três níveis de governo, em interação com os órgãos setoriais e
com a comunidade (CASTRO, 1997a), foi instituído com a seguinte estrutura:
? CONDEC (Órgão Superior) – Conselho Nacional de Defesa Civil. Constituído por
representantes dos ministérios e de órgãos da Administração Pública Federal,
designados pelo Ministro de Estado da Integração Nacional, ao CONDEC compete,
entre outras atribuições, a de aprovar a Política Nacional de Defesa Civil e as
diretrizes de ação governamental de Defesa Civil e de deliberar sobre as ações de
cooperação internacional de interesse do SINDEC. Ao Ministério da Integração
Nacional, representado pelo titular da SEDEC - Secretaria Nacional de Defesa Civil,
cabe a presidência do Conselho.
27
? SEDEC (Órgão Central) – Secretaria Nacional de Defesa Civil. Órgão central do
Sistema, sendo responsável por coordenar as ações de defesa civil em todo o território
nacional. Responsável pela articulação, coordenação e gerência técnica do Sistema.
Compete à SEDEC, do Ministério da Integração Nacional:
? articular e coordenar as ações de Defesa Civil;
? gerenciar tecnicamente e a fiscalizar as ações específicas desenvolvidas;
? promover a implementação das ações conjuntas dos órgãos integrantes do
SINDEC - Sistema Nacional de Defesa Civil;
? participar do Sistema de Proteção ao Programa Nuclear Brasileiro - SIPRON,
como órgão setorial encarregado da proteção da população nas emergências
nucleares e/ou radiológicas.
? CORDEC (Órgão Regionais) – Coordenadorias Regionais de Defesa Civil, cuja
vinculação e localização, por região geográfica, será estabelecida em regulamento.
Sob a supervisão técnica da SEDEC, compete aos órgãos compatibilizar e consolidar
os planos e os programas estaduais de Defesa Civil para o planejamento regional e
coordenar as ações regionais de Defesa Civil, em suas áreas de atuação (Região Norte,
Região Nordeste, Região Centro-Oeste, Região Sul, Região Sudeste)
? CEDEC/SEDEC-RJ (Órgãos Estaduais) – Coordenadorias Estaduais de Defesa Civil,
Secretaria Estadual de Defesa Civil do Estado do Rio de Janeiro, e Coordenadoria de
Defesa Civil do Distrito Federal;
? COMDEC (Órgãos Municipais) – Comissão Municipal de Defesa Civil. A
implantação é feita pela prefeitura municipal. Cabe ao prefeito determinar a criação de
uma COMDEC, iniciativa que pode partir das autoridades locais ou dos cidadãos da
comunidade; e
? Órgãos Setoriais e de Apoio – Órgãos e instituições da Administração Pública, nos
três níveis, que integram o Sistema (órgãos setoriais), e as instituições públicas,
privadas, não governamentais (ONG) e comunitárias que prestam ajuda aos órgãos
integrantes do Sistema, em circunstâncias de desastres (órgãos de apoio).
28
2.6.2 O CONTEXO BRASILEIRO
Existe uma grande diversidade de desastres naturais, humanos e mistos, conforme
classificação adotada pelo SINDEC e aprovada pelo Conselho Nacional de Defesa Civil: a
Codificação de Desastres, Ameaças e Riscos – (CODAR)(CASTRO, 1997b).
A realidade brasileira, neste contexto de desastres, pode ser caracterizada pela freqüência
dos desastres naturais cíclicos, especialmente as inundações em todo o País, seca na região
Nordeste e um crescente aumento dos desastres humanos, devido ao crescimento urbano
desordenado, às migrações internas e pelo fenômeno da urbanização acelerada sem a
disponibilidade dos serviços essenciais. Num cenário de extensão continental, com cerca de
8,5 milhões km2 , 7.367 km de litoral banhado pelo Oceano Atlântico e 167 milhões de
habitantes, o Brasil apresenta-se com características regionais de desastres, ou seja:
? Região Norte - incêndios florestais e inundações
? Região Nordeste - secas e inundações
? Região Centro-Oeste - incêndios florestais
? Região Sudeste – deslizamento e inundações
? Região Sul – inundações, vendavais e granizo.
2.6.3 A OPERACIONALIDADE
A atuação de defesa civil tem o objetivo de reduzir desastres e compreende ações de
prevenção, de preparação para emergências e desastres, de resposta ao desastre e de
reconstrução.
Aos órgãos municipais (COMDEC’s) cabem as ações de resposta imediata quando da
ameaça ou ocorrência de desastres. Esses órgãos devem possuir um completo conhecimento
sobre os riscos de desastres existentes nos municípios aos quais pertencem, bem como definir
previamente as ações que devam ser executadas por ocasião dos desastres, além de conhecer
todos os recursos necessários para o tratamento eficiente da adversidade. Esses órgãos contam
com o apoio das NUDEC's (Núcleos de Defesa Civil), que são formados por voluntários das
comunidades envolvidas em áreas de risco.
29
Aos órgãos de nível superior, cabem as ações de coordenação e articulação dos recursos,
em apoio aos órgãos municipais.
A atuação de defesa civil é multi-setorial e deve ser executada pelos três níveis de
governo – federal, estadual e municipal - com ampla participação da comunidade. A ação
organizada de forma integrada e global do SINDEC proporciona um resultado multiplicador e
potencializador, muito mais eficiente e eficaz do que a simples soma das ações dos órgãos que
o compõem.
Todos os órgãos do SINDEC têm atribuições, mas a atuação do órgão municipal de
defesa civil - Coordenadoria Municipal de Defesa Civil – COMDEC - é extremamente
importante, tendo em vista que os desastres ocorrem nos municípios. Durante um desastre,
este é o órgão responsável pela coordenação das ações dos demais órgãos envolvidos nas
áreas atingidas, conforme definido em (BRASIL, 1993).
O município deve estar preparado para atender imediatamente a população atingida por
qualquer tipo de desastre, reduzindo perdas materiais e humanas. Daí a importância de cada
município criar a sua COMDEC.
2.6.4 SITUAÇÃO PARTICULAR NO ESTADO DO RIO DE JANEIRO
No estado do Rio de Janeiro a organização da defesa civil é peculiar, existido uma
secretaria estadual (SEDEC/RJ - Secretaria Estadual de Defesa Civil) (SEDEC/RJ) ao invés
de uma coordenadoria (CONDEC), sendo o Corpo de Bombeiros Militar do Estado do Rio de
Janeiro (CBMERJ) um órgão dessa secretaria.
A SEDEC/RJ é organizada em várias sub-secretarias, que por sua vez são compostas por
departamentos. Para efeito deste estudo, o departamento mais importante é o Departamento
Geral de Apoio Comunitário (DGAC). Este departamento é o responsável em coordenar as
ações de DC no Estado do Rio de Janeiro. É neste departamento que são mapeados os riscos,
identificados os recursos, elaborados os planos, e definidas as atuações por ocasião da
ocorrência de desastres. O CBMERJ é ligado diretamente ao Secretário Estadual de Defesa
Civil, e é o órgão responsável em executar as ações de DC no Estado.
30
Portanto, as principais diferenças entre a SEDEC/RJ e os outros órgãos de DC estaduais
do país, são: o status de Secrearia de Estado, e a inclusão do Corpo de Bomberios Militar
Estadual na sua estrutura.
Esta organização dá a DC do estado Rio de Janeiro a característica de não ser apenas um
órgão coordenador, mas também executor.
2.6.5 O PROBLEMA DO COMANDO E CONTROLE
Como muitos municípios brasileiros não tem estrutura administrativa bem desenvolvida,
muitos órgãos de defesa civil municipais (COMDEC) não atuam como deveriam,
principalmente nos municípios menos favorecidos. Mesmo alguns órgãos estaduais
(CEDEC/SEDEC) apresentam dificuldades de organização, implicando em um baixo grau de
eficácia operacional.
É comum os órgãos estaduais assumirem o controle das operações, em auxílio aos órgãos
municipais menos preparados.
Observa-se também que o problema não se resume ao grau de preparo dos órgãos.
Mesmo quando uma COMDEC está preparada para atuar, pode ocorrer que a CEDEC
também atue, não apenas em cooperação, mas igualmente no comando e controle das
operações. Isto pode ser observado também em relação às ações preventivas, e planos de
operações para um mesmo risco podem existir em vários níveis de governo, acarretando numa
redundância de informações que na maioria das vezes não é tratada. Tomando como exemplo
a situação em que um desastre, uma inundação, por exemplo, abranja alguns municípios de
um estado e alguns municípios de um estado vizinho, alguns questionamentos podem ficar
sem resposta. Por exemplo, quem seria o responsável pelo comando das operações e quantos
desastres ocorreram.
Cada órgão municipal de defesa civil dos municípios envolvidos deveria ser o responsável
pelas ações locais. Os órgãos de defesa civil dos estados seriam os coordenadores e
articuladores das ações nos seus estados, ao passo que o órgão federal seria o articulador
geral. A verdade é que fica difícil imaginar o comando e o controle das operações quando
vários órgãos em diversos níveis atuam em conjunto, sem que haja uma hierarquia
31
administrativa entre eles. Na verdade são órgãos independentes, ligados a governos
independentes.
No exemplo da inundação, haveria para cada município a ocorrênc ia de um desastre. Para
cada estado haveria a ocorrência de um desastre, que abrangeria vários municípios. Para a
União, haveria um desastre abrangendo vários estados. Qual a visão correta? Qual a visão que
prevaleceria nas estatísticas? E a questão dos planos operacionais referentes a uma inundação
naquela área? Provavelmente os municípios teriam seus planos, os estados também, e talvez a
União também pudesse ter um plano para a ocorrência. Constata-se que os planos dos
diversos níveis contém ações operacionais, quando talvez somente os municipais deveriam
ter. E a redundância de informações contidas nos planos? Será que os planos municipais
servem de base para os estaduais, e estes para os federais? Ficou constatado que não. Não
existe uma padronização de processos em relação a esse questionamento. Essa constatação
não se resume aos planos, mas a todos os dados tratados pelo sistema, tais como recursos,
ações, riscos, danos, etc. O trabalho de unificação das informações é artesanal, sendo
consequentemente demorado e sujeito a imperfeições.
2.6.6 A PROPOSTA
No capítulo 4 é apresentada a modelagem de uma aplicação de software para o Sistema
Operativo de Defesa Civil (SODC), que leva em consideração as questões levantadas no ítem
anterior. Através da aplicação dos conceitos de comando e controle e do tratamento unificado
dos recursos, riscos, planos e atuações, este modelo permite aumentar a eficácia do SINDEC,
diminuindo o tempo de resposta e aumentando a qualidade da decisão.
2.7 CONSIDERAÇÕES FINAIS
Um grande esforço têm sido feito no Brasil, no sentido de se uniformizar a doutrina
nacional de DC, como pode ser visto em (CASTRO,1997a), (CASTRO,1997b), (CASTRO et
al,1997), (CASTRO et al,1996), (CASTRO,1999a) e (CASTRO,1999b7). Isto inclusive
32
gabaritou o país a coordenar os trabalhos do grupo de trabalho número 7 da (IBERO),
conforme comentado anteriormente. Porém foi constatado que não existe um processo de
comando e controle unificado, a nível nacional, para orientar as ações de defesa civil, quer
sejam de prevenção, quer de preparação, socorro ou recuperação.
Foi observado que nos Estados Unidos da América, com a utilização do NIIMS
(NIFC,1983), a questão do comando e controle está equacionada, com a adoção do ICS (ICS).
Lá, todos os órgãos do sistema adotam os mesmos procedimentos operacionais, tornando bem
fácil a interação entre eles.
Outra característica importante do sistema norte americano é que o comando das
operações sempre fica sob a responsabilidade da agência de mais alto nível hierárquico
presente nas operações, havendo um comando unificado para a gestão dos desastres.
No Brasil, não fica bem claro quando termina a ingerência do órgão municipal, e começa
a dos órgãos estaduais e federal, havendo, como já foi dito, superposição de atribuições.
Outra constatação interessante diz respeito à utilização da informática nesse processo.
Não foi encontrado qualquer esforço de modelagem para o desenvolvimento de sistemas de
defesa civil. Apesar de em (IBERO) existir um grupo de trabalho com essa finalidade, não foi
obtida qualquer informação sobre os resultados dos trabalhos desse grupo, e sequer se o grupo
já está produzindo algum resultado, apesar dos esforços em se tentar conseguí- lo.
No próximo capítulo serão vistos os conceitos relacionados à tecnologia de
desenvolvimento de aplicações de software através da utilizazação de frameworks. Esses
conceios serão utilizados no presente estudo, tanto para a definição de um modelo referente ao
domínio da DC quanto para a definição do framework de comando e controle proposto.
33
3 ESTUDO DE FRAMEWORKS
3.1 INTRODUÇÃO
À medida em que os sistemas de software ser tornam cada vez mais complexos, maior
importância é dada às técnicas de desenvolvimento de software que buscam facilitar a
produção de novos sistemas. Nesse contexto, um dos objetivos mais perseguidos pela
engenharia de software tem sido a reutilização.
Várias são as técnicas de engenharia de software que permitem a reutilização. Dentre as
mais atuais, destaca-se a utilização de frameworks. Este capítulo tem por objetivo apresentar
essa tecnologia através da sua conceituação, classificação, comparação com outras
tecnologias de reutilização de software, e da apresentação de diversas abordagens de
desenvolvimento. Por fim, também será apresentado o processo de desenvolvimento utilizado
para se obter o framework proposto no presente estudo.
3.2 CONCEITUAÇÃO
Frameworks Orientados a Objeto (OO) são uma técnica de reutilização de software,
oferecendo tanto reutilização de código quanto de projeto. Um framework descreve como um
programa é decomposto em um conjunto de classes que interagem entre si. Uma das partes
mais importantes de um framework diz respeito à maneira na qual um sistema é dividido em
seus componentes. Dessa forma, a reutilização das interfaces internas do sistema e a divisão
do sistema em seus componentes são mais importantes do que a reutilização de código
oferecida.
Framework OO é uma tecnologia promissora de desenvolvimento e implementação de
software que tem como principal objetivo reduzir custos, aumentar a produtividade e melhorar
a qualidade do produto final (FAYAD et al, 1999b). Um framework pode ser definido como
34
um modelo lógico de sistemas de software para uma determinada área. A partir deste modelo
pode-se instanciar (criar) sistemas de software implementando o comportamento necessário
para a aplicação desejada, de uma forma mais rápida do que no desenvolvimento tradicional.
Um framework apresenta, de maneira estruturada, as principais funcionalidades e
características que deverão existir nos sistemas criados a partir dele.
As diferentes aplicações referentes a um mesmo domínio diferem umas das outras em
relação a alguns conjuntos de aspectos variáveis, denominados regiões quentes (hot spots).
Uma aplicação fornece, para cada região quente, pelo menos uma possível alternativa
diferente (variabilidade), devendo o framework referente ao domínio em questão implementar
as características genéricas dessas regiões, ficando a implementação dos aspectos específicos
por conta do desenvolvedor da aplicação (SCHMID,1997).
Uma importante característica dos frameworks é a inversão de controle.
Tradicionalmente, um desenvolvedor utiliza componentes a partir de uma biblioteca,
escrevendo o programa principal que chama os componentes quando necessário. Dessa
forma, ele é o responsável pela estrutura geral do programa e pelo fluxo de controle. Em um
framework , o programa principal é reutilizado, e o código escrito pelo desenvolvedor é
chamado pelo código do framework. Assim, o framework é o responsável pelo fluxo de
controle e pela estrutura geral do programa (JOHNSON,1997).
Alguma confusão pode ocorrer entre os conceitos de padrões de projeto (design patterns)
e frameworks. Em (JOHNSON,1997) fica claro que um padrão atua em um nível de
granularidade inferior ao de um framework, descrevendo os objetos e suas interações em
relação a uma pequena parte de um sistema orientado a objeto. Já um framework descreve a
arquitetura de um sistema orientado a objeto, seus tipos de objetos e como esses objetos
interagem. Além disso, descreve como um tipo particular de aplicação, tal como um sistema
de planejamento e controle de produção ou um sistema bancário, é decomposto em objetos.
Essa descrição é feita na forma de um conjunto de classes, uma para cada tipo de objeto do
domínio da aplicação, sendo os modelos de interação e associação entre os objetos uma parte
importante do framework. Um framework normalmente utiliza diversos padrões de projeto na
sua construção. Em (SRINIVASAN,1999) é visto que documentar o framework como um
conjunto de padrões de projeto é uma maneira efetiva de obter um alto nível de comunicação
entre o desenvolvedor do framework e o desenvolvedor de uma aplicação baseada no mesmo.
Frameworks como IBM San Francisco, MacApp, Microsoft Fundation Classes (MFC),
Microsoft’s Distributed Common Object Model (DCOM), Java Soft’s Remote Method
35
Invocation (RMI) e o Common Object Request Broquer Architeture (CORBA-OMG) têm
alcançado um papel cada vez mais importante no desenvolvimento de software.
O primeiro framework utilizado amplamente e desenvolvido em meados dos anos 70, foi
o framework de interface de usuário para Smaltalk-80 chamado Model/View/Controller
(MVC). Este framework mostrava que a programação orientada a objetos era bem adaptada à
construção de Interfaces Gráficas de Usuários (GUI). Ele divide a GUI em três tipos de
componentes: modelos, visões e controles. Modelo é um objeto da aplicação que deve ser
independente da interface de usuário. Uma visão gerencia uma região da tela e mantém a
consistência com o estado do objeto do modelo. Um controle contém a maneira pela qual
uma visão responde à entrada do usuário, permitindo, dessa forma, a alteração do
funcionamento da visão sem alterar sua forma visual. Outra função do controle é tratar do
contraste entre os paradigmas da visão (dirigida a eventos - clique do mouse, toque de um
botão, etc) e do modelo (baseado no modelo objeto/mensagem).
Resumindo, a utilização metodológica de frameworks na modelagem, especificação e
implementação de sistemas, tem por finalidade otimizar o processo de desenvolvimento de
software, garantindo menor esforço e maior qualidade do produto final. A FIG. 3.1, adaptada
de (CAMERON, 1999) ilustra os conceitos de especificação e implementação referentes a um
framework .
FIG. 3.1 - Especificação e Implementação com frameworks
36
3.3 CLASSIFICAÇÃO
Existem diversas formas de se classificar um framework. Em (FAYAD et al,1997)
encontra-se a classificação que leva em consideração a abrangência do escopo:
? Framework de sistema de infra-estrutura – Simplifica o desenvolvimento de sistemas
tais como sistemas operacionais, sistemas de comunicação, GUI, etc.
? Framework midleware de integração - Normalmente usado para integrar aplicações e
componentes distribuídos. Como exemplo temos os frameworks ORB.
? Framework de aplicações de negócio – Abrange todo o domínio de uma aplicação, tais
como telecomunicações e aplicações bancárias.
Pode-se ainda classificá-los segundo a dependência de domínio, como apresentado em
(ARCO et al,1998), em framework de aplicação e framework de domínio:
? Um framework de aplicação representa uma fatia horizontal de funcionalidade
independe de um domínio em particular, podendo ser utilizado para desenvolver
aplicações de diferentes domínios. Frameworks com funcionalidades de acesso a
arquivos ou de interface gráfica são exemplos desse tipo.
? Um framework de domínio apresenta uma fatia vertical de funcionalidade referente a
um domínio em particular, como aplicações financeiras, por exemplo. É possível
observar que existe uma relação entre frameworks verticais e de aplicação de
negócios, apesar de pertencerem a classificações diferentes.
Uma outra classificação leva em consideração os conceitos de método modelo (template)
e método gancho (hook). Um método modelo é aquele que contém o fluxo geral de controle, o
comportamento abstrato ou a semântica da interação entre os objetos, e que geralmente invoca
outros métodos com funcionalidades mais específicas: os métodos gancho. São os métodos
gancho que assumem os aspectos variáveis do framework.
Essa classificação, encontrada em (FAYAD et al,1997) e (SCHMID,1997), e
representada na FIG. 3.2, diz respeito à técnica utilizada para estender o framework:
frameworks caixa preta (blackbox) e frameworks caixa branca (whitebox) são os extremos
dessa classificação.
? Os frameworks do tipo caixa branca utilizam fortemente as características das
linguagens OO, tais como herança e ligação tardia, para obter extensibilidade. A
funcionalidade oferecida é estendida e reutilizada pela criação de subclasses a partir
37
das classes existentes no framework (herança) e pela redefinição dos métodos gancho.
Esses métodos não são completamente definidos nas classes genéricas do framework
e devem ser reescritos nas classes concretas da aplicação desenvolvida e representam
os aspectos variáveis do framework. Os frameworks desse tipo requerem dos
desenvolvedores que os utilizam um profundo conhecimento da sua estrutura interna,
e normalmente produzem sistemas fortemente acoplados com os detalhes da sua
hierarquia de classes.
? Um framework do tipo caixa preta suporta extensibilidade pela definição de interfaces
para componentes que possam ser acoplados ao framework através de composição de
objetos, sendo mais fáceis de usar e estender, pois escondem do desenvolvedor os
seus detalhes internos. Além das classes abstratas que contém métodos abstratos,
esses frameworks também apresentam classes concretas, prontas para uso, e nas quais
os métodos gancho são definidos de forma completa. Dessa forma, o
desenvolvimento de frameworks do tipo caixa preta é mais difícil, pois requer do seu
desenvolvedor a definição de interfaces e de ganchos que antecipem a grande faixa de
potenciais casos de uso.
Na verdade, o que mais existem são frameworks que apresentem as característica do tipo
caixa branca e do tipo caixa preta simultaneamente (FAYAD et al,1999a).
FIG. 3.2 - Representação dos aspectos caixa branca e caixa preta de um framework
38
A FIG. 3.2 representa um framework com classes abstratas (A e B) e classes concretas
(B1 e B2). O método m da classe A é abstrato, e deve ser reescrito pelo programador que
utilizar o framework para desenvolver uma aplicação (classe A1 e o método m'). Têm-se aqui
um exemplo de um aspecto caixa branca do framework. Já as classes B1 e B2 contém os
métodos p' e q' totalmente implementados, e que se referem aos métodos abstratos p e q da
classe B. Essas classes (B1 e B2) não precisam ser reescritas, estando prontas para serem
usadas. Este é um exemplo de um aspecto caixa preta do framework.
3.4 UM PEQUENO EXEMPLO
Adaptado de (NEELAM,1999), será apresentado um framework de editor de FIG.s. Ele é
constituído de uma classe controladora concreta CF e de uma classe abstrata F, para
representar uma FIG.. A classe F representa a região quente do framework.
Os detalhes referentes a FIG. obviamente não estarão presentes na classe F, pois
dependem das necessidades da aplicação em particular, desenvolvida a partir do framework.
Nesta classe constarão apenas características genéricas presentes em todos os tipos de FIG.s.
A FIG. 3.3 apresenta o código com os membros que estariam presentes em F.
FIG. 3.3 - Exemplo da codificação para a classe abstrata F
39
Deve ser observado que os códigos referentes aos métodos possuem apenas a primeira
linha e alguma atribuição genérica, não contendo qualquer lógica de como as coisas devem
ser feitas. O desenvolvedor da aplicação deve providenciar a redefinição apropriada desses
métodos nas classes derivadas, para que eles se comportem da forma desejada para o tipo
particular de FIG. em questão.
Além disso, devem ser feitas especificações de pré e pós condições para os métodos de F.
Dessa forma, o desenvolvedor da aplicação saberá até onde pode ir na redefinição dos
métodos. A pré-condição para todos é true, e as pós condições para cada um deles são as
mostradas na FIG. 3.4. Como pode ser observado na FIG., as pós condições tratam das
variáveis x, y (coordenadas do centro da FIG.) e ch (define se a FIG. é preenchida ou não).
Por exemplo, as pós condições para o método move são: não alterar ch e fazer com que os
valores de x e y sejam acrescidos de dx e dy, respectivamente.
FIG. 3.4 - Exemplo de codificação para as pós condições da classe abstrata F
Já a classe concreta CF tem duas variáveis membros, f1 e f2, ambos do tipo F,
representando as duas FIG.s que podem ser tratadas pelo framework. Em um framework mais
realista, obviamente seria permitido ao desenvolvedor a criação de mais FIG.s simultâneas.
Isto implicaria na necessidade de inserir código para a criação de novos objetos. Como o
objetivo é apenas de exemplificação, a opção por um número fixo de FIG.s prevaleceu.
A classe contém o método run( ), que é encarregado de processar as requisições de edição
para as FIG.s. Como entrada para essas requisições, pode-se considerar as coordenadas do
cursor do mouse (mx, my), além da operação propriamente dita (preenche, npreenche, contrai,
expande, move, isIn). O código do método é apresentado na FIG. 3.5.
40
FIG. 3.5 - Exemplo de codificação para o método Run( ) da classe concreta CF
O método completo é formado apenas pela repetição do código mostrado, para cada
requisição de edição. Fica claro a importância das funções virtuais. No framework, não existe
a implementação completa do método isIn( ) (que informa se o cursor está dentro de uma
FIG.), pelo simples fato de que essa implementação depende do tipo de FIG. que se está
trabalhando no momento da execução. Apesar disso, e neste ponto reside o poder da
abordagem de desenvolvimento baseado em framework, esse método é invocado, e outros
métodos são chamados baseados no valor retornado por ele. O método run( ) é um exemplo
de método modelo (template), e os métodos chamados por ele são exemplos de métodos
gancho (hook).
Uma possível aplicação desenvolvida a partir desse framework teria duas classes
concretas derivadas a partir de F, uma classe C para círculos, e uma classe R para retângulos.
A classe R deveria conter três novos membros, enquanto que a classe C teria apenas dois
membros extras, como mostrado na FIG. 3.6.
FIG. 3.6 - Os membros extras (propriedades) das classes C e R
O método isIn( ) para C é fácil de ser definido. Basta comparar a distância de um dado
ponto com o centro. Para pertencer ao círculo, a distância deve ser menor ou igual ao raio. A
FIG. 3.7 exemplifica a codificação para esse método. A definição de isIn para R é similar.
41
FIG. 3.7 - Exemplo de codificação para o método IsIn( ) da classe C
Como as definições dos outros métodos das classes R e C dependem da utilização de
funções gráficas disponíveis com a versão da linguagem utilizada, elas não serão mostradas
neste breve exemplo.
3.5 OUTRAS TÉCNICAS DE REUTILIZAÇÃO
A reutilização na produção de software basicamente está entre dois extremos: de código
ou de projeto. As técnicas mais antigas de reutilização, tais como bibliotecas de funções, eram
baseadas em reutilização de código. Técnicas mais modernas, tais como design patterns,
propõem reutilização de projeto. Um framework está a meio caminho, possibilitando tanto
reutilização de código quanto de projeto.
Em (SZYPERSKI,1998) encontra-se uma interessante revisão das abordagens que
propõem reutilização de projeto, através do compartilhamento de elementos de projeto. A
seguir, essas técnicas serão brevemente discutidas.
3.5.1 LINGUAGENS DE PROGRAMAÇÃO
Aparecem como forma de compartilhar a consistência de um projeto, não sendo
capazes de garantir uma boa criação, mas podendo evitar coisas que provavelmente causariam
problemas se fossem implementadas. Uma linguagem de programação pode tornar algumas
coisas fáceis de serem feitas, outras difíceis, e ainda algumas impossíveis. Dessa forma, as
linguagens codificam o dogma de como as coisas deveriam ser feitas.
42
3.5.2 BIBLIOTECAS DE FUNÇÕES
Foram criadas devido a tentativa de proporcionar às primeiras linguagens de programação
funcionalidades genéricas, posibilitando o compartilhamento de fragmentos de solução.
Atualmente, tem sido observada uma clara tendência em deixar as funcionalidades específicas
fora das linguagens, em favor de características de abstração e de estrutura,. Assim, as
bibliotecas podem crescer ao longo do tempo, sem que seja necessário qualquer mudança na
linguagem.
3.5.3 INTERFACES
Proporcionam compartilhamento de contratos. Uma vez que provedores e clientes de
serviços existem separadamente e podem ser combinados livremente, o contrato de ligação
entre provedores e clientes ganha extrema importância. Uma interface permite a execução
desse contrato. Tecnicamente, uma interface é o conjunto de nomes de operações que um
cliente pode invocar, devendo existir no provedor um conjunto de operações respectivas que
implementem a interface. Dessa forma, clientes e provedores são ignorantes uns em relação
aos outros, sendo a interface o mediador que possibilita a ambos trabalharem juntos. O
contrato declara não somente o que o cliente necessita para poder usar a interface, como
também o que o provedor deve implementar para satisfazer os serviços prometidos pela
interface. A nível de operação, os dois lados de um contrato podem ser capturados pela
especificação de pré e pós condições. Por exemplo, pode-se citar os argumentos passados pelo
cliente, e o valor de retorno da operação, passado pelo provedor. As interfaces e os contratos
associados são a menor unidade contratual de um sistema.
3.5.4 PADRÕES DE PROJETO (DESIGN PATTERNS)
Permitem o compartilhamento de arquiteturas de interações individuais. Como já
dito anteriormente, um padrão de projeto descreve os objetos e suas interações em relação a
43
uma pequena parte de um sistema orientado a objeto, possuindo uma granularidade inferior a
de um framework, sendo este último formado, muitas vezes, por diversos padrões
(JOHNSON,1997) (SZYPERSKI,1998). Cada modelo descreve um problema que ocorre
várias vezes em diferentes desenvolvimentos, e o núcleo da solução do problema, de forma
que se possa usar essa solução infinitas vezes, sempre obtendo produtos diferentes.
Em (GAMMA et al,1997) é encontrado um catálogo de 23 padrões de projetos colhidos
ao longo do tempo, e baseados na experiência de desenvolvedores de sistemas orientados a
objeto. A idéia é que, uma vez tendo sido isolado e identificado o problema, um padrão
apropriado possa ser escolhido, sendo então adaptado às circunstâncias específicas.
3.5.5 ARQUITETURAS DE SISTEMAS
Possibilitam o compartilhamento da estrutura geral da aplicação. Os benefícios da
divisão da arquitetura de um sistema em camadas têm sido empiricamente validada ao longo
de tempo. A abordagem estrita determina que a implementação de um nível deve ser baseada
somente nas operações disponibilizadas pelo nível imediatamente abaixo. Essa abordagem
permite o entendimento incremental dos níveis, quer top-down ou bottom-up. Isso se deve ao
fato de que os níveis podem ser completamente compreendidos isoladamente a partir da sua
implementação, da interface com o nível inferior e das operações disponibilizadas para o nível
superior. Como desvantagem existe a dificuldade de extensibilidade, já que os serviços novos
de um nível devem ser sempre suportados pelo nível imediatamente inferior. Dessa forma, se
um novo serviço usa uma operação de um nível abaixo do nível inferior, então uma operação
deve ser inventada no nível imediatamente inferior para dar suporte à evolução.
A abordagem não estrita evita essa dificuldade, permitindo que os níveis usem serviços
proporcionados por qualquer nível inferior, e não apenas pelo imediatamente inferior. Por
exemplo, ao invés de estender a biblioteca C, uma aplicação Unix pode acessar diretamente o
kernel do sistema. Obviamente essa abordagem dificulta a visualização e o entendimento dos
níveis. Uma bibliografia completa sobre o assunto pode ser encontrada em (SEI).
44
3.5.6 COMPONENTES
Oferecem o compartilhamento de funcionalidade . Em (SZYPERSKI,1998) é feita uma
extensa discussão dessa tecnologia. Neste trabalho, componente é definido como unidades
independentes de produção, aquisição e desenvolvimento, proporcionando a criação de
softwares funcionais a partir da composição de vários componentes. Sua implementação pode
ser baseada em objetos ou em bibliotecas de funções. Finalmente, um componente não tem
um estado persistente, sendo importante saber se um componente está ou não disponível em
um determinado sistema, não havendo sentido em se determinar quantas cópias desse
componente estariam disponíveis.
3.5.7 LINHA DE PRODUTO (PRODUCT LINE)
Mais recentemente, como pode ser visto em (PRODUCT LINE), pesquisas envolvendo
linha de produtos têm oferecido grandes contribuições para a reutilização de software. Uma
linha de produtos de software é o conjunto de sistemas de software que satisfazem
necessidades específicas de uma missão ou de um segmento de mercado em particular, e que
compartilham um conjunto comum de características, sendo desenvolvidos a partir de um
conjunto comum de recursos e de uma forma pré-estabelecida.
Um novo produto é formado:
? pela aplicação de componentes disponibilizados a partir da base de recursos comuns;
? pelo uso de mecanismos de variabilidade preestabelecidos, tais como parametrização
ou herança, visando adaptação às necessidades específicas;
? pela adição de novos componentes, segundo as novas necessidades;
? e pelo uso de um processo disciplinado para montar a coleção de produtos sob o
guarda-chuva de uma arquitetura ampla e comum.
Dessa forma, a construção de um novo produto (sistema) passa a ser mais uma questão de
montagem ou geração do que propriamente de criação, e a atividade predominante passa a ser
integração, ao invés de programação.
45
Nota-se que esse mecanismo de reutilização usa todos os anteriores, pois prevê a inclusão
de padrões de projeto, biblioteca de funções, frameworks, componentes, etc. como integrantes
do núcleo de recursos de uma linha de produtos. Outra característica dessa tecnologia é a
descrição pormenorizada do processo a ser seguido no desenvolvimento de uma linha de
produtos.
3.6 ABORDAGENS DE DESENVOLVIMENTO
Apesar da crescente importância de frameworks, até bem pouco tempo não havia muitos
esforços em se definir um processo para o seu desenvolvimento. Recentemente, alguma
preocupação com a análise e o projeto de frameworks têm sido notada nos meios de pesquisa,
mas o que se vê realmente são abordagens de desenvolvimento que proporcionam somente
uma linha geral a ser seguida. Serão mostradas a seguir algumas das abordagens propostas
para desenvolvimento de framworks, sendo ao final descrito o processo de desenvolvimento
utilizado neste estudo.
3.6.1 GENERALIZAÇÃO SISTEMÁTICA
Em (SCHMID,1997) é encontrada a descrição de uma abordagem de desenvolvimento de
framework denominada de generalização sistemática. Essa abordagem tem como ponto
central a definição das regiões quentes (hot spots) do framework através da generalização
obtida a partir das classes que compõem o domínio do problema.
É proposta a redução da complexidade do projeto de um framework pela separação de
diferentes questões: definição do modelo de classes para uma aplicação do domínio do
framework ; análise e a especificação da variabilidade e flexibilidade do domínio; e passos de
implementação por uma seqüência de transformações de generalização.
Para o tratamento da variabilidade e flexibilidade do domínio, é sugerido que cada região
quente do framework seja implementada como um subsistema de aspectos variáveis,
contendo:
46
? Uma classe base (tipicamente abstrata) que define a interface para responsabilidades
comuns;
? Classes derivadas concretas, uma para cada aspecto variável da região; e
? Possibilidade de classes e relacionamentos adicionais.
Também é sugerido a divisão do projeto em cinco fases, como ilustrado na FIG. 3.8:
? Criação do modelo de classes de uma aplicação representativa do domínio em questão;
? Análise de alto nível das regiões quentes - Corresponde a identificação de todos as
regiões quentes do domínio, seguida de uma breve descrição de cada uma delas;
? Análise e especificação detalhada das regiões quentes – Nesta fase, cada região quente
é analisada e especificada separadamente. Se como resultado do processo forem
obtidos regiões quentes que apresentem muitas variações, sugere-se dividi- la em
regiões quentes ortogonais (quando os aspectos variáveis de uma região quente
podem mudar independentemente uns dos outros);
FIG. 3.8 - Atividades do Projeto de Frameworks por Generalização
? Projeto de alto nível do sub-sistema de regiões quentes – Um sub-sistema de regiões
quentes é a implementação de uma região quente através de uma classe base
(normalmente abstrata), de classes concretas (que implementam alguma
variabilidade), e de possíveis classes adicionais e de relacionamentos. As regiões
quentes que introduzem a variabilidade por herança (região quente caixa branca),
normalmente só contém classes abstratas, devendo seus métodos serem sobrescritos
47
nas subclasses criadas. Já as que introduzem a variabilidade por composição (região
quente caixa preta), normalmente contém classes adicionais que possuem métodos
templates (métodos complexos que chamam métodos de outras classes), e classes
concretas que já apresentam funcionalidade completa, ficando a cargo do usuário
apenas a escolha da classe que participará da composição desejada; e
? Transformação por generalização – Nesta fase os aspectos fixos, que formam as
regiões geladas (partes do framework que são idênticas em todas as aplicações
derivadas dele - frozen spots) da estrutura geral do framework são generalizados,
sendo complementados pelos subsistemas de regiões quentes respectivos.
3.6.2 DESENVOLVIMENTO BASEADO EM EXPERIÊNCIAS
Em (WILSON,1993) é descrito o processo de desenvolvimento baseado em experiências,
onde foram desenvolvidas duas aplicações referentes ao domínio do problema. Nelas foram
identificadas características comuns, extraindo-as para o framework. A validação é feita
desenvolvendo-se novamente as aplicações, desta vez a partir do framework. Quando aplicado
em domínios pequenos, produz algum resultado.
3.6.3 DESENVOLVIMENTO BASEADO EM ANÁLISE DE DOMÍNIO
Também em (WILSON,1993) é descrito o processo de desenvolvimento baseado em
análise de domínio. A primeira atividade é analisar o problema do domínio para identificar e
entender as abstrações relevantes. Depois de identificadas as abstrações, o framework é
desenvolvido junto a uma aplicação de teste, modificando-o se necessário. Em seguida, é
desenvolvida uma segunda aplicação baseada no framework, validando ou não o projeto.
48
3.6.4 DESENVOLVIMENTO DIRIGIDO A REGIÕES QUENTES (HOT SPOTS)
Em (PREE et al,1999) é descrita a abordagem dirigida a regiões quentes para
desenvolvimento de frameworks. O processo de desenvolvimento é dividido em quatro fases:
? Definição de um Modelo de Objetos Específico - Nesta fase o engenheiro de software
modela as informações obtidas de um especialista do domínio em questão. São
utilizadas as técnicas das metodologias de desenvolvimento orientado a objetos para
se obter um modelo de objetos (classes) que represente o domínio do problema.
Como o especialista provavelmente não compreende o significado de classes, objetos
e colaborações, a utilização de cartões de responsabilidades e colaborações de classes
(CRC Cards) (WILKINSON,1996) é altamente recomendada;
? Identificação das regiões quentes - O objetivo é capturar do especialista do domínio
quais partes do modelo podem ser gerais e quais podem ser específicas para uma
determinada aplicação. A identificação das regiões quentes proporcionam essa
informação. A utilização de cartõews de regiões quentes (hot-spots cards) pode ser de
grande valia, pois permite ao especialista no domínio pensar em termos das
funcionalidades do software, e, guiado pelo engenheiro de software, identificar quais
aspectos podem diferir se forem levadas em consideração várias aplicações referentes
ao domínio em questão. A lista dos hot-spots deve ser obtida como resultado dessa
análise;
? Projeto do Framework - Após terem sido identificados os hot-spots, o engenheiro de
software deve então modificar o modelo de objetos afim de obter a flexibilidade
desejada. Nesta fase, os padrões de projeto (design patterns) podem ser ferramentas
importantes; e
? Utilização do Framework - O Framework precisa ser utilizado diversas vezes, para
que fiquem claras as suas incorreções, ou seja, hot-spots esquecidos ou
inconvenientes.
Na FIG. 3.9 fica claro que a partir da primeira fase, as outras três são repetidas quantas
vezes forem necessárias para que se chegue a uma definição adequada do framework. Esse
ciclo expressa o processo de evolução do framework.
49
Definição de um Modelo de Objetos Específico
Identificação dos hot-spots
Projeto do Framework
Utilização do Framework
Hot-spots Cards
CRC Cards
S
N
Hot-spots Cards Hot-spots Cards
FIG. 3.9 - Processo de Desenvolvimento Dirigido a Hot-Spots
3.6.5 DIAGRAMA DE FRAMEWORK (DF)
Em (KWAN et al,1999) e (YANG et al,1998) são encontradas referências a uma
ferramenta gráfica denominada "Diagrama de Framework" (DF). Um DF é um modelo para
visualização de frameworks, mostrando as classes internas, os relacionamentos e o fluxo de
controle entre as classes.
A fig 3.10, adaptada de (KWAN et al,1999), mostra a notação de um DF. Ele consiste de
classes, relacionamentos entre classes, regiões quentes, fluxo de controle entre as classes e as
interfaces. Interfaces proporcionam o caminho para que haja comunicação do framework com
outros frameworks ou classes.
50
FIG. 3.10 - Notação do Diagrama de Framework
Dois fluxos de controle estão representados na fig 3.10, um relacionado à interface X.f1()
e outro à interface X.f3(). O primeiro fluxo é composto pelas mensagens f1()_1, f1()_2 e
f1()_3, e o outro fluxo pelas mensagens f3()_1e f3()_2. O X representa o framework em
questão.
3.6.6 TÉCNICAS PARA GERAÇÃO DO DF BASEADAS NA UML
Em (KWAN et al,1999) é feita a descrição de técnicas para se gerar o diagrama de
framework a partir dos três principais diagramas propostos em (UML). Elas consistem de seis
diretrizes que guiam a modelagem funcional, estrutural e dinâmica do framework, através do
emprego dos diagramas de casos de uso, de classes e de seqüência, respectivamente, além da
apresentação de um algoritmo para cada um dos tipos de modelagem, explicitando a aplicação
das diretrizes.
51
A TAB 3.1 e a TAB. 3.2 mostram os algoritmos dos processos propostos para a
modelagem estrutural e dinâmica.
TAB. 3.1 - Algoritmo da Modelagem Estrutural de frameworks - Geração do DF baseado na UML
1. Fazer o diagrama de casos de uso.
2. Fazer as descrições dos casos de uso.
3. Fazer os cenários de uso baseados nas descrições dos casos de uso.
4. Fazer o diagrama de classes.
5. Fazer os diagramas de seqüência baseado nos cenários.
6. Identificar as regiões quentes do framework.
7. Identificar as mensagens nos diagramas de seqüências com as tarefas citadas nas
descrições dos casos de uso.
8. Identificar os objetos receptores das mensagens obtidas no passo 7.
9. Atribuir operações e classes para as mensagens e objetos correspondentes.
10. Considerar as classes encontradas como pertencentes ao framework.
11. Encontrar os relacionamentos entre as classes e aplicá- los ao framework.
TAB. 3.2 - Algoritmo da Modelagem Dinâmica de frameworks - Geração do DF baseado na UML
1. Fazer o diagrama de casos de uso.
2. Fazer as descrições dos casos de uso.
3. Fazer os cenários de uso baseados nas descrições dos casos de uso.
4. Fazer o diagrama de classes.
5. Fazer os diagramas de seqüência baseado nos cenários.
6. Definir os fluxos de controle interno do framework.
7. Identificar as mensagens nos diagramas de seqüências com as tarefas citadas nas
descrições dos casos de uso.
8. Mapear os fluxos de mensagens dos diagramas de sequencias nos fluxos de controle
dos frameworks.
9. Encontrar os objetos relacionados aos fluxos de mensagens.
10. Identificar as classes do framework a partir dos objetos encontrados no passo 9.
11. Considerar os fluxos de mensagens entre as cla sses dos frameworks como os fluxos
de controle dos frameworks.
52
12. Encontrar os métodos que são o ponto de partida de cada fluxo de controle.
13. Considerar os métodos encontrados no passo 12 como as interfaces do framework.
Essas técnicas permitem a extração de frameworks a partir do diagrama de casos de uso; a
identificação dos hot-spots a partir do diagrama de classes e dos diagramas de seqüência; e a
identificação das classes internas do framework a partir das descrições dos casos de uso e do
diagrama de classe. O fluxo de controle e as interfaces são obtidos a partir de informações
fornecidas pelas descrições dos casos de uso e pelos diagramas de seqüência. A TAB. 3.3
apresenta os relacionamentos entre os diagramas da UML e os elementos do diagrama de
framework .
TAB. 3.3 - Relacionamentos entre os Diagramas da UML e os elementos de um Diagrama de Framework
Diagramas UML Elementos do Diagrama de Framework
Diagrama de casos de uso, descrições dos
casos de uso, diagramas de atividade
Frameworks
Diagramas de classes e de seqüência Hot spots
Descrições dos casos de uso, diagramas de
classes e de seqüência
Classes do framework
Descrições dos casos de uso e diagramas de
seqüência
Fluxo de controle e interface
A FIG. 3.11 mostra a integração dos processos de modelagem estrutural e dinâmica,
ficando claro que os cinco primeiros passos são comuns.
Uma outra contribuição interessante encontrada em (KWAN et al,1999) é a apresentação
de um metamodelo mostrando os relacionamentos existentes entre os diagramas suportados
pela UML e os elementos de um diagrama de framework. A FIG. 3.12 apresenta esse
metamodelo, na forma de um diagrama de classes.
53
Fazer diagrama de casos de uso
Fazer descrição dos casos de uso
Fazer cenários de utilização
Fazer diagrama de classes
Fazer diagramas de sequência
Extrair hot-spots
Extrair mensagensdos diag. sequência
Extrair objetosdos diag. sequência
Identificar classesno diag. classes
Identificar relac.no diag. classes
Definir fluxo de controleno framework
Extrair fluxo de mensagens dos diag. sequência
Extrair mensagensdos diag. sequência
Extrair objetosdos diag. sequência
Identificar fluxo decontrole no framework
Identificar classes no framework
Identificar insterfacesdo frameworkModelagem estrutural
Modelagem dinâmica
Gerar o diagrama de framework
FIG. 3.11 - Processo de Modelagem de Frameworks baseado na UML
FIG. 3.12 - Meta-modelo dos relacionamentos entre os diagramas UML e os elementos de um diagrama de
framework .
54
3.6.7 METODOLOGIA DE DESENVOLVIMENTO DE FRAMEWORKS ORIENTADO A OBJETO BASEADA NA UML
Em (YANG et al,1998) é apresentada uma metodologia para desenvolvimento de
frameworks orientados a objeto dividida em quatro fases: análise, projeto, implementação e
testes. Neste trabalho, o diagrama de framework também é utilizado, mas a ênfase não está na
apresentação de técnicas para obtê- lo a partir dos diagramas da UML, conforme visto em
(KWAN et al,1999), mas sim em dividir os processos ao longo de um ciclo de vida de
desenvolvimento.
A fase de análise é dividida em seis fases, como mostrado na FIG. 3.7:
1. Especificação de requisitos de aplicações similares;
2. Especificação dos requisitos do framework - a partir dos requisitos comuns;
3. Modelagem de casos de uso do framework - a partir dos requisitos do framework;
4. Nivelamento dos casos de uso - divisão dos casos de uso, de acordo com o grau de
generalidade ou especialidade de cada um, em três níveis: fundação, negócios
comuns, núcleo do negócio;
5. Agrupamento dos casos de uso - possibilita a identificação dos frameworks; e
6. Criação do diagrama de atividades para os casos de uso - auxilia na identificação de
frameworks.
Coletar Requisitosde Aplicações Similares
Definir Especificação deRequisitos do Framework
Fazer Modelagem deUse Case
Particionar Use Cases
Agrupar Use Cases
Fazer Diagrama deAtividade
FIG. 3.13 - Fases da análise da Metodologia de Desenvolvimento de Frameworks OO baseada na UML
55
A fase de projeto é dividida em dez fases, ilustradas na fi. 3.8:
1. Criação do diagrama de classes das aplicações;
2. Criação dos diagramas de sequência das aplicações;
3. Identificação das regiões quentes;
4. Criação dos diagramas de sequência dos frameworks;
5. Identificação de padrões de projeto utilizados;
6. Determinação da abordagem caixa branca ou caixa preta;
7. Criação do diagrama de framework;
8. Especificação dos códigos;
9. Revisão do projeto; e
10. Documentação do framework.
Padrões de
Fazer Diagrama deClasses
IdentificarHot Spot
Determinarblack white box
Fazer Diagrama deSequência do Framework
IdentificarProjeto
Fazer Diagrama deFramework
Especificar
Rever Projeto
Documentar
Fazer Diagrama deSequência da Aplicação
FIG. 3.14 - Fases do projeto da Metodologia de Desenvolvimento de Frameworks OO baseada na UML
As fases de implementação e testes são compostas de duas fases cada, sendo
representadas na TAB. 3.4 e visualizadas na FIG. 3.15.
TAB. 3.4 - Fases de implementação e testes da Metodologia de Desenvolvimento de Frameworks OO baseada na UML
Implementação Testes
Implementar frameworks Teste de unidade
Instanciar aplicação Teste de integração
56
FIG. 3.15 - As fases de implementação e testes da Metodologia de Desenvolvimento de Frameworks OO
baseada na UML
3.6.8 O PROCESSO DE DESENVOLVIMENTO UTILIZADO
O processo de desenvolvimento de framework utilizado neste estudo, baseou-se
principalmente nas técnicas descritas em (KWAN et al,1999) e (YANG et al,1998), e
brevemente discutidas nos itens 3.6.5, 3.6.6 e 3.6.7 deste capítulo, embora tenham sido
extraídas algumas contribuições de todas as abordagens citadas.
Inicialmente foi obtido o modelo funcional do SINDEC e a ferramenta gráfica para
representá- lo foi o diagrama de casos de uso. Para que esse modelo fosse obtido, foi
necessário a compreensão exata do funcionamento de um órgão executor de defesa civil.
Como no Brasil os órgãos de defesa civil funcionam de formas variadas, por motivos já
mencionados no capítulo 2, não foi suficiente apenas o estudo do órgão de defesa civil do
estado do Rio de Janeiro, mas o estudo de diversos órgãos de outros estados e municípios. No
capítulo 4, mais precisamente na seção 4.2, é feita a descrição de como foi possível resolver
esse problema.
A definição dos processos executados para o funcionamento padrão do órgão executor
passou pela definição da organização do órgão, produzindo a proposta de uma arquitetura
para o sistema. A partir desses subprodutos foi desenvolvido o modelo de casos de uso. Para
cada caso de uso foi feita uma descrição dos passos para a sua execução.
O próximo passo foi a obtenção do modelo estrutural, representado pelo diagrama de
classes. Esse modelo foi obtido a partir da verificação de quais classes eram necessárias para a
realização dos casos de uso, a partir de suas descrições.
Em seguida, foram definidos diagramas de sequência para os casos de uso, compondo o
modelo dinâmico. Também foram definidos cartões de CRC para cada classe do modelo.
57
A etapa seguinte foi a obtenção do modelo de classes do framework, conseguido a partir
da verificação de similaridades entre as classes do modelo estático e entre as operações do
modelo dinâmico, possibilitando a identificação das regiões quentes. A aplicação de
abstrações de generalização completou essa etapa.
Foram definidos então os diagramas de sequência do framework e os cartões de CRC,
sendo por fim obtido o diagrama de framework.
Em resumo, os passos para o desenvolvimento do framework foram os seguintes:
? Proposta de uma arquitetura para o sistema;
? Definição do modelo funcional para o domínio estudado(diagrama de casos de uso e
descrições);
? Definição do modelo estático para o domínio estudado (diagrama de classes);
? Definição do modelo dinâmico para o domínio estudado (diagramas de sequência);
? Identificação das regiões quentes;
? Definição do modelo estático do framework; e
? Definição do modelo dinâmico do framework.
3.7 CONSIDERAÇÕES FINAIS
A reutilização de software tem sido um dos objetivos a serem alcançados pelas modernas
técnicas de desenvolvimento de software. A preocupação com a reutilização se dá devido à
necessidade de se aproveitar os esforços de desenvolvimento já existentes, e que poderiam ser
utilizados em novos projetos.
Entre as ténicas que permitem algum tipo de reutilização, podem ser citadas:
? As linguagens de programação: permitem o compartilhamento da consistência do
projeto;
? As bibliotecas de funções: permitem o compartilhamento de fragmentos de soluções;
? As interfaces: permitem o compartilhamento de contratos individuais;
? Os padrões de projeto: permitem o compartilhamento de arquiteturas de interações
individuais;
58
? As arquiteturas de sistemas: permitem o compartilhamento da estrutura geral da
aplicação;
? Os componentes: permitem o compartilhamento de funcionalidades;
? As linhas de produtos: permitem o compartilhamento de recursos, características e
processos de desenvolvimentos, através do uso das demais tecnologias de
reutilização; e
? A tecnologia relacionada ao uso de frameworks: permite a reutilização tanto de código
como de projeto.
Muitas são as abordagens encontradas para o desenvolvimento de frameworks, mas, na
maioria, o processo de desenvolvimento não é realmente definido. Após a descrição de
algumas abordagens encontradas nos meios acadêmicos, foi descrito o processo de
desenvolvimento utilizado no estudo, que utilizou conceitos de todas as abordagens tratadas.
No próximo capítulo será proposto um modelo para o SINDEC, sendo definida uma
arquitetura para o sistema, além dos modelos funcional, estrutural e dinâmico. Os produtos
obtidos neste capítulo servirão de ponto de partida para a definição do framework, que será
vista em um capítulo posterior.
59
4 UM MODELO PARA O SISTEMA NACIONAL DE DEFESA CIVIL
4.1 INTRODUÇÃO
Devido a necessidade de uma melhor utilização da ciência da informática nas ações de
defesa civil, visando a minimização dos esforços e a maximização da eficiência das ações
desenvolvidas, este estudo faz uma modelagem do SINDEC, definindo:
? a estrutura de um sistema informatizado;
? os requisitos necessários;
? o modelo estático; e
? o modelo dinâmico.
O objetivo deste capítulo é a definição de um sistema operativo que possa ser utilizado de
forma integrada pelo SINDEC, em todos os níveis de governo.
4.2 A OBTENÇÃO DO MODELO DE REQUISITOS
Como já discutido no capítulo 2, o SINDEC possui uma estrutura descentralizada,
possuindo órgãos nos três níveis de governo e presentes em todo o território nacional. Esses
órgãos não possuem qualquer dependência administrativa entre si, havendo apenas o
funcionamento em conjunto quando da ocorrência de algum desastre. Isto significa que os
vários órgãos podem ser estruturados das mais variadas formas, pois apesar de haver uma
orientação em relação à estrutura e ao funcionamento dos órgãos de defesa civil
(CASTRO,1999a), essas questões são definidas pelos governos aos quais estão subordinados.
Esta característica, aliada ao fato de não ter sido notado qualquer esforço de
informatização do sistema a nível nacional, dificultou a definição de um modelo apropriado.
A definição do modelo de requisitos foi feita, inicialmente, pelo estudo do Departamento
Geral de Apoio Comunitário (DGAC) da Secretaria Estadual de Defesa Civil - RJ (SEDEC-
60
RJ), que é o órgão estadual responsável pela coordenação das ações de defesa civil no estado
do Rio de Janeiro. A partir desse estudo e das análises dos manuais de defesa civil da União
(CASTRO,1997a) (CASTRO,1997b) (CASTRO et al,1997) (CASTRO et al,1996)
(CASTRO,1999a) (CASTRO,1999b), do modelo adotado nos Estados Unidos da América
(NIFC,983) (ICS) (C3I), e do funcionamento dos órgão de defesa civil de alguns países
(CRED) (PAHO/WHO) (IAEM) (IBERO), foi definido um modelo dos processos que
deveriam nortear o funcionamento de um órgão operacional de defesa civil no Brasil,
independente do nível de governo a que esteja ligado.
Já que os órgão de defesa civil do Brasil funcionam das mais variadas formas, houve a
necessidade de validação desse modelo. Como o processo tradicional de entrevista com os
usuários se apresentava inviável, foi disponibilizada na época uma página na Internet, e o
modelo definido foi apresentado aos integrantes dos diversos órgãos brasileiros de defesa
civil. Houve então uma discussão virtual, na qual algumas questões foram colocadas em
pauta, e os interessados participaram através de mensagens enviadas por correio eletrônico e
por telefone. Após um mês de discussões, obteve-se o modelo definitivo para o sistema
operativo de defesa civil, que é mostrado nas próximas seções.
FIG. 4.1 - Estrutura de um órgão de defesa civil
61
4.3 UMA ARQUITETURA PARA O SISTEMA NACIONAL DE DEFESA CIVIL
Após o estudo da estrutura, atuação e funcionamento dos órgãos de defesa civil do Brasil,
complementados pelos estudos citados nas seção anterior, foram obtidas as conclusões em
relação às funções que um órgão executor de defesa civil deveria desempenhar. Tendo como
base essas funções, será apresentada uma proposta de arquitetura para um Sistema Operativo
de Defesa Civil (SODC).
Em (CASTRO, 1999a), é recomendado que os órgãos executores de Defesa Civil tenham
uma estrutura ternária, tendo uma divisão ou seção, conforme o nível, responsável pelas
atividades meio, e duas divisões, ou seções, responsáveis pelas atividades fim.
A Divisão de Apoio Administrativo é responsável pelo expediente e pelo desempenho
das atividades desenvolvidas pelo bloco administrativo; a Divisão de Minimização de
Desastres é responsável pelo desenvolvimento das atividades de prevenção e preparação;
enquanto a Divisão de Operações é a responsável pela implementação das ações de resposta e
reconstrução, conforme apresentado na FIG. 4.1.
A arquitetura proposta é composta de dois blocos principais: o Administrativo e o
Operativo, como mostrado na FIG.. 4.2.
PrevençãoPreparação
RespostaReconstrução
Atividade Fim
Bloco Operativo
•RP•Legislação•Manutenção eTransporte•Adm.
Atividade Meio
Bloco Administrativo
FIG. 4.2 - Blocos Administrativo e Operativo, e suas atividades
O bloco Administrativo é o responsável pelas funções administrativas, tais como:
Serviços Gerais, Administração Geral e de Pessoal, Legislação, Manutenção e Transporte,
Relações Públicas, etc. Como não é um sistema específico para a defesa civil, está fora do
escopo do estudo.
O bloco Operativo, que é o objeto do estudo, é o responsável pelas funções operacionais
É formado por uma estrutura matricial, sendo composto por módulos de planejamento,
62
atuação e avaliação, estando divididos em quatro sistemas, homônimos com as quatro fases
da DC (prevenção, preparação, resposta e reconstrução). Dessa forma, foi considerado que
todas as fases da defesa civil devem ser planejadas (planejamento), executadas (atuação) e
avaliadas (avaliação), conforme apresentado na FIG. 4.3. Essa FIG. também realça os
módulos que fazem parte do escopo do estudo. No futuro, a implementação dos demais
módulos poderá ser grandemente facilitada devido às características semelhantes existentes
entre eles e os módulos que fazem parte do escopo considerado.
FIG. 4.3 - Arquitetura do bloco operativo
Os módulos de planejamento compreendem
? a criação de planos de prevenção e o mapeamento dos riscos;
? a criação de planos de preparação;
? a criação de planos de resposta; e
? a criação de planos de reconstrução.
A atuação se caracteriza pela colocação do plano em prática, compreendendo:
? a redução de vulnerabilidades (prevenção);
63
? o desenvolvimento de recursos humanos, o aparelhamento, etc. (preparação);
? o atendimento das ocorrênc ias (resposta); e
? a recuperação dos cenários (recuperação).
Havendo ou não um plano para uma situação específica, aqueles referentes a situações
similares podem ser disponibilizados para consulta.
Após a atuação é feita a avaliação, quando as ações postas em prática são comparadas
com as ações de planejamento e até mesmo com ações de outras atuações similares, e seus
resultados são comparados. Os módulos compreendem as avaliações de prevenção, de
preparação, de resposta e de reconstrução.
As atividades do sistema de prevenção têm por objetivo impedir ou minimizar a
ocorrência de desastres, atuando sobre o ecossistema. Como exemplo podem ser citadas ações
de contenção de encostas, dragagem de rios, remoção de população de áreas de risco, etc.
As atividades do sistema de preparação têm por objetivo tornar os recursos do sistema
mais eficientes, fazendo com que as respostas às situações de emergência sejam mais eficazes.
Como exemplo podem ser citadas ações de desenvolvimento de recursos humanos e
instituciona is, desenvolvimento tecnológico, aparelhamento, etc.
As atividades do sistema de resposta têm por objetivos o controle de sinistros, o socorro
a população em risco, a assistência às populações afetadas e a reabilitação dos cenários
(limpeza, desmontagem, etc), e são executadas por ocasião dos desastres ou ameaças de
desastres.
As atividades do sistema de reconstrução têm como principal objetivo a recuperação
dos cenários, restabelecendo os serviços públicos essenciais, a economia da área afetada, o
moral social e o bem estar da população. Como exemplo de atividades podem ser citadas
obras de reforço de estruturas atingidas, relocação da população das áreas afetadas, etc.
Os módulos de planejamento dão subsídios aos módulos de atuação e de avaliação. São
os seguintes os módulos de planejamento:
a) Mapear Riscos (prevenção) - Proporciona o mapeamento dos riscos existentes na
região sob a jurisdição do órgão, bem como a identificação de possíveis danos. Para
que esse mapeamento possa ser executado, o sistema deve permitir o cadastramento de
locais, bem como conter todos os eventos adversos já definidos no CODAR
(CASTRO, 1999a). Consideramos um Risco como sendo a possibilidade de
ocorrência de um evento adverso em um local.
64
b) Mapear Recursos (preparação) - Permite o cadastramento e a consulta aos recursos
disponíveis para um determinado órgão. Um recurso pode ser humano, material,
institucional ou de instalação, sendo que os recursos materiais sempre estarão ligados
a uma instituição; os recursos humanos podem estar ligados (por exemplo: equipe de
limpeza da companhia municipal) ou não (por exemplo: médico famoso especialista
em algum tipo de praga biológica) a uma instituição; e uma instituição pode ou não
pertencer a outra instituição. Para cada recurso, o sistema deve indicar local,
disponibilidade, contato, etc.
c) Criar Planos ( prevenção, preparação, resposta e reconstrução) - Permite a criação,
alteração e consulta dos planos de prevenção (planos para redução de
vulnerabilidades), dos planos de preparação (planos para desenvolvimento de recursos
humanos, para desenvolvimento científico e tecnológico, para aparelhamento, etc), dos
planos de resposta (planos operacionais), e dos planos de reconstrução (planos para
recuperação de cenários). No modelo, foi previsto o tratamento individualizado para
cada ação de um plano. Essa foi chamada de ação de planejamento. Dessa forma,
será possível a reutilização de uma ação definida para um determinado plano em um
outro plano, como por exemplo:
? Um plano operacional para incêndio em um prédio de x andares requer a definição de
uma ação de escape da população em risco. Essa ação de planejamento pode ser
definida a partir de uma ação de escape da população já definida para a ocorrência de
incêndio em um outro prédio com características similares. O sistema deve, portanto,
permitir a consulta por ações, e não apenas por planos. Deve ser possível ao usuário,
por exemplo, consultar todas as ações de planejamento de escape da população em
risco decorrentes de incêndios em prédios altos.
Os módulos de atuação permitem a definição e o controle da execução das ações
propriamente ditas. Da mesma maneira que foi feito com as ações de planejamento, as ações
de atuação também são tratadas de forma individualizada, proporcionando ao usuário do
sistema a possibilidade de consultar as ações que tenham sido executadas em outras atuações,
e que possam de alguma forma servirem de base às ações que deverão ser executadas na
atuação em questão. São os seguintes:
a) Reduzir Vulnerabilidades (prevenção) - Permite a definição e o controle de execução
das ações realizadas para a redução da vulnerabilidade relacionada a algum risco.
65
Disponibiliza o plano respectivo, caso ele exista, bem como as ações executadas para
redução de vulnerabilidades em situações similares.
b) Desenvolver RH (preparação) - Permite a definição e o controle da execução das
ações realizadas para o desenvolvimento de recursos humanos, tais como cadastro de
cursos, treinamentos, seminários, grades curriculares, matérias, instrutores,
participantes, locais, datas, etc. Disponibiliza o plano respectivo, caso ele exista, bem
como as ações executadas para o desenvolvimento de recursos humanos em situações
similares.
c) Ciência e Tecnologia (preparação) - Permite a definição e o controle da execução das
ações realizadas para o desenvolvimento científico e tecnológico, tais como cadastro
de instituições de pesquisa, de projetos de pesquisa, de pesquisadores, de artigos, etc.
Disponibiliza o plano respectivo, caso ele exista, bem como as ações executadas para
desenvolvimento científico e tecnológico em situações similares.
d) Monitorização (preparação) - O sistema deve monitorar as áreas de risco, através de
sensores de diversos tipos, afim de possibilitar o disparo imediato dos procedimentos
de mobilização, tão logo uma situação de risco possa eclodir em desastre. Como
exemplo de sensores podemos citar barômetros, calorímetros, sismógrafos,
higrômetros, câmaras de televisão, entre outros. As informações obtidas pelos
sensores periféricos são processadas pelos centros integradores.
e) Alerta e Alarme (preparação) - Permite a caracterização de situações de alerta e
alarme a partir das informações oriundas dos sistemas de monitorização ou de
comunicação por um outro meio (telefone, por exemplo). Por alerta compreende-se a
passagem do dispositivo operacional do órgão de defesa civil da situação de
sobreaviso para a situação de prontidão. Por alarme entende-se que o dispositivo
operacional evolui da situação de prontidão para a situação de início ordenado das
operações. Quando um risco ocasiona a caracterização de uma situação de alarme ou
alerta, o sistema deve automaticamente disponibilizar o plano operacional referente
ao risco.
f) Aparelhamento (preparação) - Permite a definição e o controle de execução das ações
realizadas para o aparelhamento das equipes especializadas e dos trens de socorro, no
âmbito do SINDEC. Disponibiliza o plano respectivo, caso ele exista, bem como as
ações executadas para aparelhamento em situações similares.
66
g) Atender Ocorrências (resposta) - Permite a definição e o controle da execução das
ações referentes ao atendimento de uma ocorrência. Uma ocorrência pode ser um
desastre ou uma ameaça de desastre, já que essa última também pode colocar o
dispositivo operacional na situação de início ordenado das operações. O sistema
deve disponibilizar também o plano de operações para o risco, bem como
proporcionar o acesso às ações de planos que tratem de riscos ou locais similares.
Também deve permitir o acompanhamento dos danos e prejuízos decorrentes de uma
ocorrência, além de auxiliar na elaboração de laudos técnicos de vistorias, do
NOPRED (Notificação Preliminar de Danos) e do AVADAN (Avaliação de Danos),
que são documentos necessários para que os municípios obtenham auxílio dos
governos federais e estaduais.
h) Recuperar Cenários (Reconstrução) - Auxiliar no processo de recuperação dos
cenários, possibilitando o cadastramento das obras executadas, bem como dos órgãos
responsáveis. Para cada ocorrência poderá haver um processo de reabilitação.
Disponibiliza o plano respectivo, caso ele exista, bem como as ações executadas para
recuperação de cenários em situações similares.
Os módulos de avaliação proporcionam a retroalimentação necessária para a melhoria
do planejamento e da atuação em todos os sub-sistemas. São eles:
a) Avaliar Atuação (prevenção, preparação, resposta e reconstrução) - Permite o
feedback necessário para que as operações possam ser aprimoradas, objetivando uma
melhor operacionalidade. A idéia é comparar as ações de atuação definidas com as
ações de atuação executadas. Além disso deve compará- las com as ações de
planejamento contidas nos planos que as originaram, ou na falta destes, contidas em
planos que tratem de situações similares e/ou com ações executadas em situações
similares. A função do sistema é disponibilizar a consulta a essas ações, sendo a
comparação feita pelo usuário.
67
4.4 AS FUNCIONALIDADES DO SISTEMA
A organização de um órgão de defesa civil (FIG. 4.1), juntamente com a arquitetura
proposta (FIG. 4.2) e com os processos desemp enhados pelo bloco operativo (FIG. 4.3),
foram utilizadas para identificar as funcionalidades do sistema. Estas estão retratadas segundo
a representação do diagrama de casos de uso proposto em (UML), conforme apresentado na
FIG. 4.4.
Já que o estudo se limita apenas ao sistema de resposta, além dos módulos "Inserir
Risco" e "Inserir Recurso", que fazem parte dos sistemas de prevenção e preparação
respectivamente, os casos de uso que pertencem ao escopo do estudo estão realçados. Como
comentado anteriormante, a definição e a implementação desses casos de uso possibilitarão a
futura implementação dos demais, já que suas atividades são similares.
FIG. 4.4 - Modelo de Casos de Uso do Sistema Operativo de Defesa Civil
68
A FIG. 4.5 mostra o diagrama de casos de uso que pertencem ao escopo deste trabalho. A
descrição de cada caso de uso é apresentada no apêndice A.
Inserir Risco
Divisão de Minimizaçãode Desastres
Atender Ocorrência
Criar Planode
Resposta
Inserir Recurso
Avaliar Atuação
Divisão deOperações
FIG. 4.5 - Modelo de Casos de Uso referentes ao escopo do estudo
É possível considerar o caso de uso Atender Ocorrência como sendo executado em duas
partes: criação da ocorrência, e definição e controle da atuação. Dessa forma, esse caso de
uso pode ser considerado como equivalente aos casos de uso Inserir Risco e Criar Plano,
quando executados em sequência. Um Plano só existe se o Risco existir, e o Plano contém as
ações que deverão ser executadas pela Agência responsável, caso aquele Risco se manifeste.
Uma Atuação só existe se a Ocorrência existir, e a Atuação contém as ações que são
executadas pela Agência responsável. A FIG. 4.6 ilustra esse conceito. As diferenças entre as
funcionalidades ficam por conta da previsão e da definição dos danos e do controle feito sobre
as ações de atuação e que não ocorre com as ações de planejamento. Enquanto que no
conjunto de casos de uso Inserir Risco e Criar Planos a previsão dos danos é feita em Inserir
Risco, no conjunto de casos de uso Inserir Ocorrência e Criar Atuação, a funcionalidade
similar (definição dos danos) aparece em Criar Atuação.
Outra informação relevante é que tanto Criar Planos quanto Criar Atuação podem utilizar
consultas a outros planos e a outras atuações, além de consultas individualizadas a ações de
planejamento e a ações de atuação. Dessa forma, é possível a percepção de mais quatro casos
69
de uso: Consultar Planos, Consultar Atuações, Consultar Ações de Planejamento e Consultar
Ações de Atuação. A FIG. 4.7 apresenta essa situação.
Inserir Risco
Divisão de Minimização de DesastresCriar Plano
Divisão de Operações
Inserir Ocorrência
Atender OcorrênciaCriar Atuação
Similares
FIG. 4.6 - Similaridade entre Atender Ocorrência e Inserir Risco e Criar Plano
Criar Atuação
Consultar Plano
Consultar Ação-Plano
Consultar Atuação
Criar Plano
Consultar Ação-Atuação
FIG. 4.7 - Casos de Uso auxiliares para Criar Plano e Criar Atuação
70
4.5 O MPC2 E O SISTEMA OPERATIVO DE DEFESA CIVIL (SODC)
No capítulo 2 foi mostrado o Modelo de Processos de Comando e Controle (MPC2).
Apesar de ter sido definido para descrever o processamento das ações de comando e controle
referentes a operações de guerra, o MPC2 pode se aplicado a qualquer domínio onde haja a
intenção de alterar o ambiente a partir de informações oriundas do próprio ambiente. Sistemas
de comando e controle referentes a órgãos de segurança pública, de defesa civil, e mesmo
sistemas de apoio a decisão com finalidade tipicamente empresarial, podem ter seus processos
modelados conforme o MPC2.
No SODC, o caso de uso "Atender Ocorrência" implementa ações equivalentes às ações
de combate. Os outros casos de uso referentes ao escopo do estudo servem de apoio para que
"Atender Ocorrência" possa ser completamente executado.
Serão discutidas a seguir cada uma das funções do MPC2 e como são implementados no
SODC.
A função "Sensoriamento" envolve todos os sistemas e procedimentos usados para obter
dados a partir do ambiente. No modelo proposto essa função é tratada pelo módulo de
"Monitorização" que pertence ao subsistema de preparação. Como este módulo não faz parte
do escopo deste trabalho, não foram criados os casos de uso e demais modelos referentes as
suas funcionalidades, porém a arquitetura prevista do SODC permite que sua futura
implementação seja facilmente integrada ao restante do sistema. No SODC a saída dessa
função é tratada, pois é a partir dela que uma ocorrência é iniciada.
A função "Processamento" é composta de todos os procedimentos usados para a dedução
de eventos ou situações significantes, o que é feito a partir das informações colhidas pela
função "Sensoriamento". É também responsável em fornecer opções de linhas de ação para a
função "Decisão". No SODC isso equivale a identificar um fato a partir de um evento adverso
e um local onde ele ocorre e a disponibilizar as ações que servirão de suporte ao decisor:
ações do plano de resposta previsto para o risco equivalente; ações de planos de resposta
previstos para riscos que tratem de situações onde o evento ou o local sejam os mesmos; e
ações executadas em atuações de resposta a ocorrências referentes ao mesmo local e/ou
mesmo evento. Essa funcionalidade está presente no caso de uso "Atender Ocorrência" e é
apoiada pelos casos de uso "Criar Planos de Resposta" e "Inserir Risco".
71
A função "Análise de Inteligência" abrange uma variedade de processos especializados,
sendo responsável por duas tarefas principais:
? A primeira tarefa é obter informações sobre a organização, estrutura, capacidades e
intenções das forças inimigas, sendo que as informações políticas, econômicas e
outras questões não militares também são importantes. Essas informações formam um
arcabouço que permite atribuir significado às atividades e situações observadas. O
equivalente no SODC é a obtenção de informações referentes às vulnerabilidades do
local atingido pelo evento adverso. Na verdade, essas considerações são feitas por
ocasião do mapeamento de riscos, tratado em "Inserir Risco".
? A segunda tarefa é a previsão de mudanças na situação corrente. Essas previsões se
apoiam em experiência e deduções. No SODC essa tarefa é representada pela
possibilidade de consulta a ocorrências similares, qua ndo as ações desenvolvidas e os
danos causados podem ser avaliados e utilizados para a definição de novas ações. O
caso de uso "Avaliar Atuação de Resposta" apoia essa tarefa.
As informações e as previsões desenvolvidas por essa função guiam a função
"Sensoriamento", indicando "o que" e "onde procurar"; guiam a função "Processamento",
ajudando a identificar padrões que sinalizem eventos e situações específicas; e guiam a função
"Decisão", proporcionando avaliação e previsão em relação à situação em estudo, e estimando
as prováveis consequências das ações propostas.
TAB. 4.1 - Implementação dos processos de C2 pelo SODC Funcionalidades do MPC2 Casos de Uso do SODC
Sensoriamento (saída) Inserir Risco
Inserir Ocorrência
Processamento Criar Atuação
Criar Planos
Inserir Risco
Análise de Inteligência Criar Planos
Inserir Risco
Avaliar Atuação
Decisão Criar Atuação
Inserir Recurso
Atuação Criar Atuação
72
Um fato a ser observado é que enquanto algumas atividades dessa função são realizadas
durante as operações de combate atuais, muita coisa é feita independente da situação corrente.
O caso de uso "Criar Planos" implementa as atividades anteriores às operações.
A função "Decisão" é extremamente complexa e pouco compreendida, já que envolve
principalmente processos mentais. Em última análise, poderia ser dito que a decisão é a
escolha entre as opções oferecidas ao se levar em consideração as situações deduzidas pela
função "Processamento" e as informações e previsões fornecidas pela função "Análise de
Inteligência". É importante observar, porém, que a decisão pode levar a uma escolha não
indicada, e isto se deve ao processamento mental pouco mapeado dessa função. No SODC a
decisão é a definição das ações a serem executadas, indicando quais recursos devem ser
utilizados. Isto é feito em "Atender Ocorrência", sendo apoiado por "Inserir Recurso". É o
componente "Comando" do MPC2.
A função "Atuação" representa a interface entre o sistema controlado pelo decisor e o
ambiente. Representa o uso de meios para forçar ou influenciar mudanças no ambiente,
conforme definido pela função "Decisão". Essa função, portanto é o próprio emprego dos
meios para restaurar a situação de equilíbrio do ambiente, sendo, dessa forma, externa ao
sistema. O componente "Controle" do MPC2 é a verificação se o que está sendo feito na
função "Atuação" está de acordo com o que foi definido na função "Decisão". No caso de uso
"Atender Ocorrência" é fornecido o mecanismo de controle, ao se permitir o
acompanhamento dos estados das ações de atuação determinadas.
Em resumo, as funções do MPC2 são apoiadas pelos casos de uso "Inserir Risco", "Inserir
Recurso", "Criar Planos de Resposta" e "Avaliar Atuação de Resposta", e são implementadas
pelo caso de uso "Atender Ocorrência".
4.6 O MODELO ESTRUTURAL
O modelo estrutural tem por objetivo representar as classes presentes no domínio do
problema, além das associações existentes entre elas.
73
A partir das descrições dos casos de uso (apêndice A), obteve-se o diagrama de classes do
sistema operativo de defesa civil, mostrado por completo na FIG. 4.15. A seguir, para cada
caso de uso, serão apresentadas as classes e os relacionamentos obtidos.
4.6.1 CASO DE USO INSERIR RISCO
Quando um evento adverso ocorre em algum local têm-se um desastre. A simples ameaça
de ocorrência do evento no local já é significativa, podendo colocar o sistema de DC em ação.
Dessa forma fica claro que existe uma associação entre Evento e Local, e que pode se
concretizar ou não. A essa associação deu-se o nome de Fato.
O caso de uso Inserir Risco tem como função mapear a possibilidade de um Fato ocorrer.
Dessa forma, a classe Risco representa a possibilidade de que um Fato possa ocorrer, e um
Fato tem apenas um Risco.
ENDEREÇO BAIRRO
DANO
REGIÃO
RISCO
**
CausarFATO
1 11
Ter
EVENTO LOCAL
1
*
* *
FIG. 4.8 - Diagrama de Classes referente ao caso de uso Inserir Risco
A um Local podem estar relacionados diversos Fatos, um para cada possível Evento. A
possibiblidade de que um Fato ocorra, ou seja, o Risco desse Fato ocorrer, implica na previsão
74
de Danos. Portanto, um Risco pode prever vários Danos, e um mesmo Dano pode ser previsto
por mais de um Risco. A FIG. 4.8 apresenta a parte do diagrama de classes que representa
esses conceitos. Foi utilizado o padrão estrutural Combinação (Composite) para representar a
hierarquia existente entre os diversos tipos de locais: um local pode ser considerado como um
elemento simples (um endereço, um bairro , uma cidade, um estado), ou como uma
combinação de vários elementos, formando uma região.
Por exemplo, em relação ao Local estádio de futebol "Maracanã", podemos ter os Fatos
referentes ao Evento CODAR-21.405 (Incêndio em edificação com grande densidade de
usuários) e ao Evento CODAR-21.303 (Destruição de edificação por problemas estruturais).
A cada um desses Fatos corresponde um Risco. Provavelmente, esses dois Riscos terão
possíveis Danos em comum. Por outro lado, o mesmo evento CODAR-21.405 (Incêndio em
edificação com grande densidade de usuários) pode gerar um outro Fato no Local Teatro
Municipal, implicando automaticamente em outro Risco. O diagrama de objeto representado
na FIG. 4.9 ilustra essa situação. A inserção de um Fato e do seu consequente Risco
independe da Agência.
Fato
Local
Dano
Evento
Risco
Maracanã
CODAR-21.405
Fato 1
Fato 2
Fato 3
Teatro Municipal
Dano 2
Dano 1
Dano 4
Dano 3
Risco 3
Risco 1
Risco 2
FIG. 4.9 - Diagrama de objetos representando os riscos
75
4.6.2 CASO DE USO INSERIR RECURSO
Uma Agência, que é o órgão do SINDEC responsável em atuar nos desastres ou nas
ameaças de desastres, deve dispor de Recursos para utilizar nas emergências. Esses recursos,
na grande maioria dos casos, não pertencem à agência, mas sim a órgãos públicos ou a
empresas. A classe Disponibilidade contém informações sobre como uma instituição
disponibiliza um recurso, sempre referenciando o local da disponibilidade. Um recurso pode
ser material, humano ou um serviço, e pode ser disponibilizado por mais de uma instituição.
Instituição pode ser considerada uma agência do sistema ou um outro órgão qualquer, quer
seja governamental ou não. Em relação a esses últimos, ocorre uma relação de composição. A
FIG. 4.10 mostra a parte do diagrama de classes que representa esses fatos.
MATERIAL HUMANO
AGENCIA INST APOIO
0..*0..1
LOCAL
INSTITUIÇÃO
RECURSODISPONIBILIDADE
*
1
1
*
1
Oferecer
*
1
*
Ref.
SERVICO
Existir
FIG. 4.10 - Diagrama de Classes referente ao caso de uso Inserir Recurso
A FIG. 4.11 mostra o diagrama de objetos que representa a situação na qual a instituição
"A" dispõe do recurso "Micro-ônibus - 12 lugares" no "local 2", enquanto que o mesmo
recurso é disponibilizado pela instituição "B" no "local 1". A mesma institutição "B" ainda
76
disponibiliza o recurso "R1", mas em dois locais: "local 1" e "local 3". É importante saber
qual o Local em que o Recurso está disponível, pois isso permite escolher o recurso que mais
rapidamente pode ser empregado. Nem sempre esse Local é o mesmo local referente ao
endereço da empresa que o possui.
Recurso R1
Disp.
Micro-ônibus 12 lug.
Instituição A
Disponibilidade
Instituição B
Local 1
Recurso
Disponibilidade
Local
Disp.
Local 2
Local 3
Disp.
Instituição
FIG. 4.11 - Diagrama de objetos representando a disponibilidade de recursos
4.6.3 CASO DE USO CRIAR PLANOS
Um Fato pode ser da responsabilidade de mais de uma Agência, sendo esta
responsabilidade determinada pela área operacional da agência. Um Fato é definido quando se
percebe que o Risco daquele Fato acontecer é considerável, sendo desejável a criação de um
Plano de Resposta para o Risco respectivo. Dessa forma, referente a um risco podem haver
vários planos (um por Agência).
Os planos de respostas são compostos por ações de planejamento de resposta, que por sua
vez descrevem o que deve ser feito, e na medida do possível, como deve ser feito. Cada ação
de planejamento de resposta se refere a um elemento de planejamento, como por exemplo,
isolamento do local, resgate de vítimas, socorro médico, etc.
77
A previsão de emprego dos recursos disponíveis é representado na classe Emprego. Uma
previsão de Emprego de um Recurso por uma Ação aponta para uma ou mais
Disponibilidades daquele Recurso. Isso permite que o sistema sinalize que existe a
necessidade de se atualizar um Plano, no caso de uma Disponibilidade ser alterada. Os
objetos da classe Emprego contém informações sobre como uma Disponibilidade é
empregada, pois é possível, por exemplo, empregar somente uma parte daquilo que é
disponibilizado. Para exemplificar, será utilizado o mesmo caso da FIG. 4.9, com os Riscos
referentes ao estádio Maracanã. Se as Agências estadual (A1) e municipal (A2) do Rio de
Janeiro fizerem um Plano de Resposta para o Risco 1, teremos dois planos, cada um contendo
suas Ações de Planejamento, que por sua vez utilizarão um ou mais recursos. A parte do
diagrama de classes que representa esses fatos é mostrada na FIG. 4.12 e a FIG. 4.13 mostra o
diagrama de objetos que representa essa situação.
AGENCIA
RISCO
**
FATO 11Ter
EMPREGO
PLANO RESP
INSTITUIÇÃO
RECURSO
ACAO PLANO RESP
1
*
Compor
*
1DISPONIBILIDADE
1
*
Oferecer
1
*
Ref.
**
LOCAL
*
1
Existir
EVENTO* *
FIG. 4.12 - Diagrama de Classes referente ao caso de uso Criar Planos
78
Risco
Local
Agência
Recurso
DisponibilidadePlano
Ação Planej. Previsão
Previsão
A2
P2
...
Maracanã
CODAR-21.405
Risco 1
A1 Micro-ônibus 12 lug. Empresa A
Vila Isabel
P1
Ações
Fato 1
Fato Instituição
Ap1
Disponibilidade
FIG. 4.13 - Diagrama de objetos representando a criação de Planos para um Risco
A FIG. 4.14 mostra o diagrama de objetos que ilustra o fato de que uma Ação pode ser
composta por várias ações de menor granularidade.
Previsão
Maracanã
CODAR-21.405
Risco 1
A1
Policiamento
Btl 2
Vila Isabel
P1
Btl 1
Ação do Btl 2
Fato 1
Risco
Local
Agência
Recurso
DisponibilidadePlano
Ação Planej.
Previsão
Fato
Policiamento
FIG. 4.14 - Diagrama de objetos representando a composição de Ações
79
No exemplo, uma ação de planejamento de controle de trânsito de uma grande área pode
prever o emprego do recurso "policiamento". Os objetos da classe Emprego farão referências
às disponibilidades que representam as ofertas de policiamento de dois batalhões, por
exemplo. Se um destes batalhões definir como fará sua parte, detalhando sua ação, isso pode
ser colocado no sistema..
4.6.4 CASO DE USO ATENDER OCORRÊNCIA
Uma Ocorrência é a materialização de um Fato, e em relação a um Fato, podem existir
várias Ocorrências. Conforme verificado na seção 4.4 (Modelo Funcional), o caso de uso
Atender Ocorrência pode ser considerado como sendo formado por dois casos de uso: Inserir
Ocorrência e Criar Atuação. Foi visto também que esses dois casos de uso seriam similares
aos casos de uso Inserir Risco e Criar Planos, respectivamente, com uma pequena diferença
referente à inserção de Danos (FIG. 4.6). A FIG. 4.15 mostra a parte do diagrama de classes
que representa o caso de uso Inserir Ocorrência.
ENDEREÇO BAIRRO REGIÃO
OCORRENCIA
FATO
*
1Ter
RISCO1 1Ter
LOCAL *
1
EVENTO **
FIG. 4.15 - Diagrama de Classes referente ao caso de uso Inserir Ocorrência
O diagrama de objetos da FIG. 4.16 exemplifica uma situação onde é feita a inserção de
uma Ocorrência.
80
Maracanã CODAR-21.405
Fato 1
Ocorrência 1Dano 1
Dano 2
Fato
Local
Evento
Ocorrência
Dano
Risco 1 Risco
FIG. 4.16 - Diagrama de objetos representando a inserção de uma nova Ocorrência
O órgão do SINDEC responsável em atuar nas Ocorrências é chamado de Agênc ia. Uma
Ocorrência pode ser objeto de atuação de várias agências (por exemplo, no caso de
derramamento de óleo na Baía de Guanabara, os órgãos federal, estadual e municipais
poderão atuar). Uma ocorrência pode causar diversos danos. O mesmo dano pode ser o
resultado do somatório de efeitos de mais de uma ocorrência. Os recursos disponibilizados
pelas instituições podem ser utilizados pelas agências durante as atuações. Em resposta a uma
ocorrência, o papel de uma Agência é definir as ações a serem executadas, quais recursos
essas ações utilizarão, e, se possível, como eles serão utilizados. A Atuação de uma Agência
sobre uma Ocorrência é representada pela classe Atuação, que por sua vez é composta por
ações de atuação de resposta. Cada ação de atuação de resposta se refere a um elemento de
atuação, como por exemplo, isolamento do local, resgate de vítimas, socorro médico, etc..
Como uma ação de atuação de resposta pode apresentar vários estados (definida, executando,
executada), o padrão de projeto de comportamento Estado (State) foi empregado para
representar o este fato. Isso evita que uma ação mude de classe ao longo da sua existência. A
representação dos estados de uma ação como classe permite o controle das operações, através
da comparação dos vários estados de cada uma das ações. Portanto, uma ação de atuação de
resposta possui vários estados, sendo um deles o atual. A definição de uma Ação de Atuação
pode ser orientada por outras Ações, de planejamento ou de atuação, presentes em Planos ou
em outras Atuações. A forma de utilização dos recursos disponíveis é representado em objetos
da classe Utilização. O objetos dessa classe contém informações sobre como uma
Disponibilidade é empregada na ação, pois é possível, por exemplo, empregar somente uma
parte daquilo que é disponibilizado. Da mesma forma que ocorre com as Ações de
Planejamento, uma Ação de Atuação pode ser composta por outras. É no atendimento a uma
Ocorrência que se verificam os Danos causados.
81
A FIG. 4.17 mostra a parte do diagrama de classes que representa o caso de uso Criar
Atuação, deixando para a próxima seção, quando é discutido a generalização das ações, a
representação da ligação de orientação existentes entre as Ações de Atuação e as ações de um
modo geral. Um diagrama de objetos representando o atendimento a uma Ocorrência é
mostrado na FIG. 4.18.
EXECUTANDODEFINIDA EXECUTADA
AGENCIA
DANO
ATUACAO RESP
ACAO ATUACAO RESP
1
*Compor
*1
UTILIZAÇÃO
OCORRENCIA
*
** *
Causar
FATO
1
*
Ter
LOCAL
1
*
Ref
RECURSO
INSTITUIÇÃO
DISPONIBILIDADE
*
1
* 1*
Ref.
1
**
Oferecer
ACAOESTADO
1
1Apresentar*
1
*
*
Existir
FIG. 4.17 - Diagrama de Classes referente ao caso de uso Criar Atuação
Observando-se a FIG. 4.18 verifica-se que a Ação Atuação 1 foi orientada pela Ação
Plano 1, mas poderia ter sido orientada por outras ações (de atuação ou de planejamento). A
Utilização do Recurso 1 pela Ação Atuação 1 está ligada ao Estado da ação. Isto porque uma
ação de Atuação ao ser definida (Estado "definido"), pode determinar a utilização de alguns
recursos, mas ao ser executada (outro Estado), a utilização dos recursos pode mudar, tanto na
forma de usar quanto na utilização de recursos diferentes. A classe Utilização tem
características similares à classe Emprego.
Observa-se ainda que uma Ocorrência pode implicar em Danos, que podem ou não terem
sido previstos quando da inserção do Risco referente ao mesmo Fato.
82
Por fim, uma outra Agência pode estar atuando na mesma Ocorrência.
Ação Atuação
Risco
Local
Agência
Recurso
Disponibilidade
Item disp.
Plano
Ação Planej.
PrevisãoAtuação
Utilizaçãop.
Estado
Dano
Estados
Previsão
Maracanã
CODAR-21.405
Fato 1
A1 Recurso 1
Empresa A
Vila Isabel
P1
Ocorrência 1
Atuação 1
Outras ações
Ação Atuação 1
Ação Plano 1 Utilização
Disponibilidade
DanosA2
Atuação 2......
Risco 1
Instituição
FIG. 4.18 - Diagrama de objetos representando uma Atuação em uma Ocorrência
4.6.5 GENERALIZAÇÃO DAS AÇÕES
As ações de resposta (tanto a de planejamento como a de atuação) compreendem as
seguintes atividades gerais, como definido em (CASTRO, 1999a):
? Combate aos sinistros;
? Socorro às populações em risco;
? Assistência às populações afetadas;
? Reabilitação dos cenários dos desastres.
83
As ações de combate aos sinistros são desenvolvidas com o objetivo de limitar e controlar
os danos e prejuízos provocados por desastres. As principais são:
? Isolamento das áreas sinistradas;
? Escape das populações em risco;
? Controle de trânsito;
? Segurança da área sinistrada;
? Combate direto ao sisnistro.
As ações de socorro têm por objetivo minimizar os efeitos dos sinistros nas populações
afetadas, e são relacionadas com:
? Busca e salvamento e resgate de feridos;
? Primeiros socorros;
? Atendimento pré-hospitalar - APH;
? Atendimento médico-cirúrgico de emergência;
As ações de assistência às populações afetadas são executadas quando as populações
afetadas pelos sinistros necessitam do apoio do SINDEC, até que a situação de normalidade
seja restabelecida. As principais são:
? Atividades logísticas;
? Assistência e promoção social;
? Atividades de promoção, proteção e recuperação da saúde.
Por fim, as atividades de reabilitação dos cenários dos desastres antecedem aos projetos
de reconstrução, e têm por objetivos: iniciar a restauração das áreas afetadas, restabelecer
condições mínimas de segurança e de habitabilidade, permitir o retorno das populações as
áreas cujas condições foram reabilitadas. As principais são:
? Vigilância das condições de segurança global da população;
? Reabilitação dos serviços essenciais;
? Reabilitação das áreas deterioradas e das habitações.
Tanto uma ação de planejamento quanto uma de atuação podem orientar a definição
dessas últimas. Essa associação foi denominada Orientação, e mantém o histórico para que se
obtenha(m) a(s) ação(ões) que orientaram uma determinada ação de atuação. Outra
característica importante em relação às ações, é o fato de que uma ação pode ser composta de
outras ações menores. Por exemplo, ao definir uma ação de resgate de vítimas do local de um
desastre ecológico de grande extensão, uma agência pode determinar a utilização de vários
84
recursos institucionais, que ficarão a cargo de executá- la. Cada instituição, por sua vez,
definirá suas próprias ações, de maneira que a ação original seja efetivamente executada.
Como as ações de planejamento e as de atuação possuem muitas características em
comum, foram generalizadas em uma classe Ação, que contém as propriedades e as
funcionalidades comuns a ambas. A FIG. 4.19 mostra a parte do diagrama de classes que
representa a generalização em questão.
EXECUTADAEXECUTANDODEFINIDA
UTILIZAÇÃO
EMPREGO
PLANO RESP ATUACAO RESP
ACAO*
1
Constituir
RECURSOINSTITUIÇÃO
ACAO PLANO RESP
*1
1
*
ComporACAO ATUACAO RESP
1*
Compor
*
1
Orientar
DISPONIBILIDADE
1
*Ref.
1
Oferecer
**
ACAOESTADO
1
1
Apresentar
*
1
Possuir*
*
**
FIG. 4.19 - Diagrama de Classes referente à generalização da classe Ação
4.6.6 O DIAGRAMA DE CLASSES FINAL
A FIG. 4.20 mostra o diagrama final, no qual todas as classes do domínio do SINDEC
são representadas.
85
DEFINIDA EXECUTANDO EXECUTADA
HUMANOMATERIAL
INST APOIO
0..*0..1
UTILIZAÇÃO
EMPREGO
DANO
AGENCIA
RISCO*
*
Causar*
*
FATO1
1Ter
OCORRENCIA
*
*Causar
**
1*Ter ATUACAO RESP
ACAO
1
*
Constituir
PLANO RESP
ACAO ATUACAO RESP
1
*
Compor
*
1
Orientar
INSTITUIÇÃO
RECURSO
ACAO PLANO RESP
1
*
Compor
ACAOESTADO
1
1
Apresentar
*
Possuir
DISPONIBILIDADE
*
1
Oferecer
*1Ref.
*
*
*
*
SERVICO
LOCAL
1
*Existir
EVENTO
*
*
1
FIG. 4.20 - Diagrama de classes do sistema operativo de defesa civil
4.7 O MODELO DINÂMICO
O objetivo do modelo dinâmico é descrever como os objetos irão interagir, mostrando
quais e como as mensagens serão trocadas, e qual a funcionalidade presente em cada objeto.
A partir das descrições de cada caso de uso, e tendo como base as classes definidas no
modelo estrutural, obteve-se o modelo dinâmico, representado na forma de diagramas de
sequência. Quando necessário, foi criado um diagrama de sequência para cada caso de uso, e
um cartão de responsabilidade e colaboração de classes (CRC) (WILKINSON,1996) para
cada classe, mostrando quais as responsabilidades de cada classe (métodos) e quais
colaborações (outros métodos, normalmente de outras classes) são necessárias para que cada
responsabilidade possa ser integralmente implementada.
86
Os cartões de CRC são apresentados em uma forma tabular, sendo formados por duas
colunas contendo os nomes das responsabilidades (à esquerda) e das colaborações (à direita).
Cada responsabilidade é brevemente explicada por um pequeno texto, e como toda
colaboração é responsabilidade de alguma classe, todos os métodos citados possuem uma
descrição. Os diagramas de sequência do SODC são apresentados no apêndice B, e os cartões
de CRC no apêndice C.
4.8 CONSIDERAÇÕES FINAIS
Este capítulo definiu uma arquitetura para o sistema operativo de defesa civil, além dos
modelos funcional, estático e dinâmico desse sistema. O objetivo é a definição de um sistema
que possa ser utilizado em todo o território nacional, pelos órgãos executores de defesa civil.
Os modelos referentes ao SODC foram desenvolvidos após terem sido feitas
considerações sobre as similaridades do processamento de C2 e as funcionalidades
encontradas no modelo proposto para o SODC.
A definição do modelo de requisitos foi feita da seguinte maneira:
? estudo do órgão responsável pela coordenação das ações de DC no estado do Rio de
Janeiro;
? estudo dos manuais de DC da União;
? estudo dos modelos de DC adotados em outros países; e
? validação do modelo obtido confrontando-o com os órgãos de DC dos demais
estados, através da disponibilização de uma página na Internet.
Na definição dos diversos modelos, foram utilizados os diagramas propostos em (UML),
e o processo de desenvolvimento adotado foi obtido a partir das abordagens de
desenvolvimento de frameworks discutidas no capítulo 3.
No próximo capítulo serão definidos os modelos estrutural e dinâmico do framework a
partir do modelo obtido para o SODC. Também serão feitas considerações em relação ao
processamento de C2, objetivando validar o framework proposto.
87
5 O FRAMEWORK PROPOSTO
5.1 INTRODUÇÃO
5.2 O MODELO ESTRUTURAL DO FRAMEWORK
Como visto na seção anterior, as funcionalidades do SODC suportam os processos de
comando e controle definidos no MPC2. Sendo as classes do modelo estrutural do SODC
responsáveis por essas funcionalidades, nesta seção são feitas abstrações de generalização
sobre esse modelo, chegando-se ao modelo estrutural do framework através da identificação
das regiões quentes.
5.2.1 CLASSES EVENTO, LOCAL, FATO, DANO, RISCO E OCORRÊNCIA
A classe Risco pode ser generalizada como a Previsão de um Fato. As classes Local e
Evento são, de forma genérica, variantes ou características do Fato, sendo consideradas, dessa
forma, como especialidades de uma classe genérica denominada Característica. A função
dessa classe é especificar o fato, podendo ser em relação ao espaço (local), tempo (época,
período, estação do ano, etc), a alguma forma de categorização (evento adverso, tipo de
operação militar, etc.) ou a qualquer outra forma de especificação presente no modelo que
fizer uso do framework. A classe Ocorrência pode ser generalizada como um Acontecimento,
sendo possível, por exemplo, imaginá- la como uma Operação, para o caso de um modelo
militar de guerra. Como generalização da classe Dano, optou-se por uma classe chamada
Consequência.
Uma observação deve ser feita antes de se prosseguir com a modelagem estrutural do
framework . No modelo estrutural do SODC a classe Fato era uma classe associativa entre as
88
classes Evento e Local. Como as classes Evento e Local serão generalizadas como
Característica, e a classe Fato como Acontecimento, seria de se esperar que a classe
Acontecimento fosse uma classe associativa do auto relacionamento da classe Característica.
A FIG. 5.1 ilustra esse processo de generalização.
FATO
*EVENTO LOCAL
Generalizan
CARACTERÍSTICA
FATO
*
*
*
FIG. 5.1 - Generalização esperada das classes Evento, Local e Fato
Ocorre porém que um Acontecimento pode ter várias Características, e não faria sentido a
classe Acontecimento ser uma classe associativa, pois ela não dependerá de suas
características tomadas duas a duas, mas sim de todas simultaneamente. Para efeito da
generalização, portanto, será feita a decomposição do relacionamento entre Evento e Local, e
a classe Fato passará a ser uma classe de entidade. Dessa forma, a classe Acontecimento será
associada a Característica, resolvendo-se o problema. A FIG. 5.2 apresenta essa nova
situação.
FATO
1EVENTO LOCAL
Generalizan
CARACTERÍSTICA
FATO
1
*
*
* *
FIG. 5.2 - Obtenção das classes genéricas Acontecimento e Característica
89
A FIG. 5.3 mostra a parte do diagrama de classes do framework referente a essas
generalizações.
FATO
* *
Ref.
PREVISAO1
1
CONSEQUENCIA
*
*
ACONTECIMENTO
*1
*
*EVENTO LOCAL
TIPO DE OPERACAO OPERACAO
OCORRENCIA
DANO
RISCO
CARACTERÍSTICA
FIG. 5.3 - Generalização referentes às classes Evento, Local, Fato, Dano, Risco e Ocorrência
5.2.2 CLASSES INSTITUIÇÃO, AGÊNCIA, PLANO E ATUAÇÃO
A classe Agência, sendo o órgão responsável pelas tomadas de decisões em relação aos
fatos, é generalizada em uma classe Decisor. Essa classe pode se especializar, em outros
sistemas, em uma Organização Militar, uma Companhia, um pelotão, etc.. No modelo
estudado, uma agência não é composta por outras agências, mas no domínio militar, por
exemplo, uma instituição militar é composta por outras. Dessa forma, a generalização para a
classe Decisor pode conter também a associação de composição, bastando fazer as
cardinalidades mínimas iguais a zero. As associações da classe agência com as
especializações de Previsão e Acontecimento se mantém, existindo no framework as classes
genéricas Plano e Atuação. No modelo estudado estas classes se especializam em Plano de
Resposta e Atuação de Resposta, respectivamente, no modelo estudado. A FIG. 5.4 mostra a
parte do diagrama de classes do framework referente a essas generalizações.
90
INSTITUIÇÃO
0..*0..1
APOIO DECISOR PREVISAO**
ACONTECIMENTO
*
*
FATO11
1
*
PLANO
ATUACAOATUACAO RESP
PLANO RESP
AGENCIAOM
FIG. 5.4 - Generalização referente às classes Instituição, Agência, Plano e Atuação
5.2.3 CLASSES DISPONIBILIDADE E RECURSO
MATERIAL HUMANO SERVICO
RECURSO
INSTITUIÇÃO
0..*
0..1
DISPONIBILIDADE
1
*Ref.
1
*
Oferecer
0..*
1..*
LOCAL
CARACTERÍSTICA
FIG. 5.5 - Generalização referente às classes Disponibilidade e Recurso
No modelo estudado, a Disponibilidade de Recurso por uma Institução é associada a um
Local. No framework, esse fato é generalizado, e a classe Disponibilidade é associada a classe
Característica, pois uma Disponibilidade, além de estar associada a um Local, pode também
91
estar associada a uma época do ano, a um período determinado, etc. A FIG. 5.5 mostra a parte
do diagrama de classes do framework referente a essas generalizações.
5.2.4 CLASSES AÇÃO, EMPREGO E UTILIZAÇÃO
Em relação à parte do modelo que trata das Ações pertencentes aos Planos ou às
Atuações, e ao Emprego e Utilização dos Recursos, poucas observações são necessárias. Na
verdade, a mudança é a generalização das classes Ação de Planejamento de Resposta e Ação
de Atuação de Resposta em Ação de Planejamento e Ação de Atuação, respectivamente. A
FIG. 5.6 mostra a parte do diagrama de classes do framework referente a essas generalizações.
ACAO
*1
Constituir
UTILIZAÇÃO
RECURSO
ACAO PLANO RESPOSTA
ACAO ATUACAO RESPOSTA
EMPREGO
DISPONIBILIDADE
1*
Ref.
ACAOESTADO
**
PLANO
ACAO PLANEJAMENTO
*
*
*
1
ATUACAO
ACAO ATUACAO
1
* Orientar
*
1
Possuir
1
1
Apresentar
*
1
FIG. 5.6 - Diagrama de classes referente às ações
92
5.2.5 O DIAGRAMA DE CLASSES FINAL
Após essas considerações, é possível visualizar o diagrama de classes do framework, o
qual é mostrado na FIG. 5.7.
APOIO
CONSEQUENCIA
EMPREGO
INSTITUIÇÃO
0..*
0..1
RECURSO
UTILIZAÇÃOACAO
*
1
Constituir
ACAOESTADO
ATUACAO
ACAO ATUACAO
*
*
Orientar
*
1
Possuir
1
1Apresentar
1
*
DISPONIBILIDADE
1*
Oferecer1
*Ref.
*
*
DECISOR
VARIANTES
0..*
1..*
PREVISAO
*
*
*
*
FATO
*
*
Ref.
1
1
ACONTECIMENTO
*
*
1
*
ACAO PLANEJAMENTO
*
*
PLANO
1*
FIG. 5.7 - Diagrama de classes do framework
93
5.3 O MODELO DINÂMICO DO FRAMEWORK
O modelo dinâmico do framework foi obtido a partir do modelo dinâmico do SODC, de
forma que as classes genéricas do framework tenham as funcionalidades comuns contidas nas
classes do SODC das quais se originaram.
A representação desse modelo é feita da mesma forma que a representação do modelo
dinâmico do SODC: através da utilização de diagramas de sequência e de cartões de CRC. Os
apêndices D e E contém os diagramas e os cartões, respectivamente.
5.4 O FRAMEWORK PROPOSTO E OS PROCESSOS DE C2
No item 4.5 foi discutido a correlação entre os processos de comando e controle
propostos no MPC2 (ORR, 1983) e as funcionalidades existentes no SODC, ficando
demonstrado que essas funcionalidades implementavam aqueles processos de C2.
NewUseCase
NewClass4
NewUseCase2
Funcionalidades do SODC
1. Ambiente2. Análise deInteligência
3. Sensoriamento
8. Decisões deBaixo Nível
6. Alto Nível
4. Processamento
5. Decisão
7. Atuação
Processos de C2
Class2 Class3
Class1
Classes do SODC
Framework
é implementado é de responsabilidade
é generalizadoimplementaClass2 Class3
Class1
FIG. 5.8 - O framework proposto e os processos de C2
94
Como as classes do SODC contém as funcionalidades do modelo, e essas funcionalidades
implementam os processos de C2, é de se esperar que as classes do framework possuam
funcionalidades que implementem esses processos, já que são generalizações das classes do
SODC, como apresentado na FIG. 5.8. O objetivo deste item é mostrar que isso realmente
acontece, validando o framework no que diz respeito aos processos de C2.
Será discutido a seguir como as funções do MPC2 são implementados no framework.
Como a função "Sensoriamento" não é tratada no modelo proposto, também não é tratada
no framework, sendo utilizada apenas a sua saída. As funcionalidades do framework
envolvidas nessa utilização são "Inserir Previsao" e "Inserir Acontecimento".
A função "Processamento" tem como equivalente no framework a identificação de um
Fato a partir das suas Características e a disponibilização das Ações que possam orientar o
Decisor na tomada de decisão. Essa funcionalidade está presente no caso de uso "Criar
Atuação" e é apoiada pelos casos de uso "Criar Planos" e "Inserir Previsão".
A primeira tarefa da função "Análise de Inteligência", que é a obtenção de informações
sobre o ambiente, é mapeada no caso de uso "Inserir Previsão", e a segunda tarefa - a previsão
de mudanças na situação corrente - é apoiada pelo caso de uso "Avaliar Atuação". O caso de
uso "Criar Planos" implementa as atividades da "Análise de Inteligência" que são realizadas
antes das operações propriamente ditas.
A função "Decisão" é representada pela definição das ações a serem executadas,
indicando quais recursos devem ser utilizados. Isto é feito em "Criar Atuação", sendo apoiado
por "Inserir Recurso". É o componente "Comando" do framework.
Em relação à função "Atuação", externa ao sistema, o framework implementa o
componente "Controle" do MPC2. O caso de uso "Criar Atuação" fornece esse mecanismo ao
permitir o acompanhamento dos estados das Ações de Atuação determinadas.
A determinação de como as classes do framework são responsáveis pelas funções do
MPC2 pode ser feita no apêndice D, onde os diagramas de sequência do framework estão
representados. A TAB. 5.1 resume o exposto.
TAB. 5.1 - Implementação dos processos de C2 pelo framework Funcionalidades do MPC2 Casos de Uso do framework Classes do framework
Sensoriamento (saída) Inserir Previsão
Inserir Acontecimento
Característica, Fato, Previsão,
Consequência e Acontecimento
Processamento Criar Atuação Fato, Previsão, Plano, Ação-
95
Criar Planos
Inserir Previsão
Plano, Emprego,
Acontecimento, Atuação ,
Ação-Atuação, Ação-Estado,
Utilização e Consequência
Análise de Inteligência Criar Planos
Inserir Previsão
Avaliar Atuação
Fato, Previsão, Plano, Ação-
Plano, Emprego, Característica,
Fato, Previsão, Consequência,
Atuação e Ação-Atuação
Decisão Criar Atuação
Inserir Recurso
Acontecimento, Atuação ,
Ação-Atuação, Ação-Estado,
Utilização, Consequência,
Instituição, Recurso e
Disponibilidade
Atuação Criar Atuação Acontecimento, Atuação ,
Ação-Atuação, Ação-Estado,
Utilização e Consequência
5.5 CONSIDERAÇÕES FINAIS
Este capítulo apresentou o framework proposto pelo estudo. Em verdade, o seu processo
de desenvolvimento iniciou no capítulo dois, com o estudo dos processos de comando e
controle e do domínio da defesa civil, e continuou no capítulo quatro, onde foram
apresentados os modelos funcionais, estrutural e dinâmico do SODC.
No presente capítulo foram consolidadas as transformações de generalização sobre os
pontos variantes do domínio estudado, e que correspondem às regiões quentes do
framework . O modelo estrutural foi desenvolvido a partir do modelo estrutural do SODC.
O modelo dinâmico do framework é apresentado nos apêndices D e E, sendo
representado pelos diagramas de sequência e por cartões de CRC, e foi obtido a partir da
generalização das operações executadas pelas classes do domínio do SODC.
96
A verificação de que o framework implementa os processos de C2 é feita pela
comparação entre o procesamento de comando e controle proposto no MPC2 (ORR, 1983) e
as funcionalidades encontradas no framework proposto.
97
6 CONCLUSÃO
Atualmente grande importância tem sido dada às metodologias e técnicas da engenharia
de software que proporcionam reutilização de produtos. Ao permitir que elementos do
processo de criação de uma aplicação (requisitos, estrutura lógica, estrutura dinâmica, código,
etc) sejam reaproveitados, essas metodologias e técnicas possibilitam uma significativa
redução dos esforços de desenvolvimento, sem que haja perda da qualidade.
O uso de frameworks orientado a objetos surge como uma das mais promissoras técnicas
de desenvolvimento. Um framework OO pode ser definido como um conjunto de classes
cooperantes referentes a algum domínio em particular, sendo responsável pelas
funcionalidades genéricas relacionadas a esse domínio. Esta técnica tem como ponto forte o
compartilhamento de conceitos relacionados à análise e ao projeto, mas também é capaz de
permitir a reutilização de código.
Um domínio de especial interesse é o relacionado às operações de Defesa Civil. Em todo
o mundo organizações, governamentais ou não, se dedicam à nobre missão de auxiliar vítimas
de desastres de qualquer natureza. No Brasil, a padronização dos processos de defesa civil
seria de extrema valia para a melhoria da atuação, diminuindo a possibilidade da ocorrência e
minimizando as consequências dos desastres. O presente trabalho mostrou que a aplicação de
um modelo de processos de comando e controle no processamento da defesa civil é viável e
concorreria para melhorar a eficácia do Sistema Nacional de Defesa Civil.
Este trabalho teve por finalidade propor um framework de comando e controle a partir do
domínio da defesa civil. Foram apresentados alguns modelos de processos de comando e
controle e os conceitos de defesa civil. Comentou-se sobre a defesa civil no mundo e
principalmente no Brasil, quando foram detalhadas sua estrutura e funcionalidade.
Foi apresentado um estudo sobre a tecnologia de frameworks. As conceituações, as
formas de classificação e as abordagens de desenvolvimento foram os principais assuntos
cobertos.
O trabalho também apresentou uma modelagem para o Sistema Operativo de Defesa
Civil. As ferramentas propostas em (UML) foram utilizadas para a obtenção dos modelos
funcional, estrutural e dinâmico do SODC. A partir deste modelo foram feitas abstrações de
generalização, sendo então obtidos os modelos estrutural e dinâmico do framework.
98
Como principal contribuição deste trabalho pode-se citar a modelagem do SODC, que
além de propor uma padronização para o processamento de defesa civil no Brasil, define as
características principais de uma aplicação para a defesa civil a nível nacional. Outra
contribuição, sem dúvida, é o próprio framework proposto, o qual pode ser usado no
desenvolvimento de aplicações referentes a outros domínios que apresentem os requisitos
genéricos dos sistemas de comando e controle.
A partir desta dissertação são apresentadas algumas sugestões para trabalhos futuros:
? Desenvolvimento de uma aplicação a nível nacional para a defesa civil, permitindo
que o SINDEC opere de forma integrada. Dessa forma, os processos de defesa civil
estariam unificados e os dados referentes a desastres, recursos, planos, atuações e
ações estariam disponíveis para todos os integrantes do sistema;
? Aperfeiçoamento do framework proposto, adequando-o a outros domínios de maior
afinidade com os conceitos de comando e controle, como por exemplo as operações
militares; e
? Pesquisa visando a possibilidade da aplicação de técnicas de inteligência artificial na
implemenatção do framework proposto, permitindo automatizar, em alguns casos, a
tomada de decisões.
99
7. REFERÊNCIAS BIBLIOGRÁFICAS
ARCO, Dalebout, Jos van HILLEGRSBERG, Berend WIERENGA. Building and Using Object-Oriented Frameworks for Semi-Structured Domains. 1998. Disponível: http://dlib.computer.org/conferen/hicss/6945/pdf/69450767.pdf. [capturado em 09 mai. 2000].
BOYD, Colonel John, Patterns of Conflict. Resumo apresentado no Air War College, Maxwel Air Force Base, Ala., USA, 1981.
BRASIL, Constituição [da] República Federativa do Brasil. Brasília, DF : Senado Federal. Artigo 22, inciso XXVIII, 1988a..
BRASIL, Constituição [da] República Federativa do Brasil. Brasília, DF : Senado Federal. Artigo 144, parágrafo 5º, 1988b.
BRASIL, Decreto nº 895, de 16 de agosto de 1993, Artigo 13.
C3I - Center of Excellence in Command, Control, Communications, and Intelligence (C3I). Disponível: http://bacon.gmu.edu/c3i/index.html. [capturado em 12 set. 2000].
CAMERON Wills, Alan, Desmond D'SOUZA. Composing Modeling Frameworks in Catalysis. In: Building Application Frameworks. Wiley Computer Publishing, 1999, cap 19.
CASTRO, Antonio Luiz Coimbra , Lélio Bringel CALHEIROS, Maria Inês Resende CUNHA, Maria Luiza Nova da Costa BRINGEL. Manual de Desastres. Imprensa Nacional, Brasil, 1996.
CASTRO, Antonio Luiz Coimbra, Lélio Bringel CALHEIROS. Redução das Vulnerabilidades aos Desastres e Acidentes na Infância. Imprensa Nacional - Brasil, 1997.
CASTRO, Antonio Luiz Coimbra. Segurança Global da População. Imprensa Nacional - Brasil, 1997a.
CASTRO, Antonio Luiz Coimbra. Política Nacional de Defesa Civil. Imprensa Nacional - Brasil, 1997b.
CASTRO, Antonio Luiz Coimbra. Manual de Planejamento em Defesa Civil. Imprensa Nacional - Brasil, 1999a.
CASTRO, Antonio Luiz Coimbra. Manual para Decretação de Situação de Emergência ou de Estado de Calamidade Pública. Imprensa Nacional - Brasil, 1999b.
100
CRED - Centre for Research on the Epidemiology of Disasters. Universite Catholique de Louvain - Brussels – Belgium. Disponível: http://www.cred.be/ [capturado em 15 nov. 2000].
FAYAD, Mohamed E., Douglas C. SCHMID. Object-Oriented Application Frameworks. In: Commuinications of the ACM, v. 40, n. 10, p. 32-38, out. 1997.
FAYAD, Mohamed E., Jan BOSH, Peter MOLIN, Michael MATTSSON and Perolaf BENGTSSON. Framework Problems and Experiences. In: Building Application Frameworks. Wiley Computer Publishing, cap 3, 1999a.
FAYAD, Mohamed E., Douglas C. SCHMIDT, Ralph E. JOHNSON. Building Application Frameworks. Wiley Computer Publishing, 1999b.
GAMMA, Erich, Richard HELM, Ralph JOHNSON, John VLISSIDES. Design Patterns – Elements of Reusable Object-Oriented Software . Addison-Wesley Publishing Company, 1997.
IAEM - International Association of Emergency Managers. Disponível: http://www.iaem.com/ [capturado em 16 nov. 2000].
IBERO - Asociación Iberoamericana de Organismos Gubernamentales de Defensa y Protección Civil. Disponível: http://www.proteccioncivil.org/asociacion/aigo0.htm. [capturado em 10 nov. 2000].
ICS - Incident Command System. Disponível: http://www.uscg.mil/hq/g-m/mor/Articles/ICS.htm. [capturado em 12 dez. 2000].
JOHNSON, Ralph E.. Components, Frameworks, Patterns. In: 19 th International Conference on Software Engineering, may 1997.
KWAN Kin, Don, Hyo Taeg JUNG, Choe Kyu KIM. Thechniques for Systematically Generating Framework Diagram Based UML. Computer Software Technology Laboratory. Eletronics and Telecommunications Research Institute. Taejon, Korea, 1999.
LAWSON, Joel S.. The State Variables of Command and Control System. In: Proceedings for Quantitative Assessment of the Utility of Command and Control Systems. Washington, D. C.: National Defense University, p. 93-99, 1980.
METHODOLOGY Disponível: http://methodology.org/ [capturado em 30 mar. 2001].
NEELAM Soundarajan. Understanding Frameworks. In: Building Application Frameworks. Wiley Computer Publishing, cap 12, 1999.
NIFC - National Interagency Fire Center, Basic Incident Command System – I-220, Single or Multipe Jurisdiction. National Wildfire Coordinating Group, 1983.
IME - Instituto Militar de Engenharia. Nucleo de Projeto e Pesquisa em Tecnologia da Informação. In: Plano de Trabalho 2000 - Sistemas de Comando e Controle. 2000.
101
ORR, George E.. Combat Operation C3I: Fundamentals and Interactions . Air Universit Press, 1983.
PAHO/WHO - Pan American Health Organization , disponível em: http://www.paho.org/
PREE, Wolfgang. Hot-Spot-Driven Development. In: Building Application Frameworks. Wiley Computer Publishing, 1999, cap 16.
PRODUCT LINE Disponível em: http://www.sei.cmu.edu/programs/pls/pl_program.html. [capturado em 13 abr. 2001].
SCHMID, Hans Albert. Systematic Framework Design by Generalization. In: Comminications of the ACM, october 1997. p. 48-51. [capturado em 11 mar. 2001].
SEDEC/RJ Disponível em: http://www.defesacivil.rj.gov.br/. [capturado em 09 mar. 2001].
SEI Disponível em: www.sei.cmu.edu/technology/architecture/ [capturado em 11 mar. 2001].
SINDEC Disponível: http://www.defesacivil.gov.br/sindec/ [capturado em 11 mar. 2001].
SRINIVASAN, Savitha. Design Patterns in Object-Oriented Frameworks. In: Computer. Digital Libraries, v. 2, n. 2, p. 24-32. fev. 1999.
SZYPERSKI, Clemens. Component Software – Beyond Object-Oriented Programming. Disponível: http://dlib.computer.org/conferen/hicss/7285/pdf/72850767.pdf. [capturado em 18 mai. 2001].
UML Disponível: http://www.uml.org/ [capturado em 07 mai. 2001].
VDL - Virtual Disaster Library. Disponível: http://www.paho.org/english/ped/about-vdl.htm. [capturado em 11 nov. 2000].
WILKINSON, N.. Using CRC Cards: An Informal Approach to Object-Oriented Development. Englewood Ciffs, NJ: Prentice Hall, 1996.
WILSON, D. A., S. D. WILSON. Wrinting Frameworks - Capturing Your Expertise About a Problem Domain. In: 8th Conference on Object-Oriented Programing Systems, Languages and Applications. Washington. 1993.
YANG, Young Jong, Soon Yong KIM, Gui Ja CHOI, Eun Sook CHO, Chul Jim KIM and Soo Dong KIM. A UML-based object-Oriented Framework Development Methodology. Asia Pacific Software Engineering Conference. Taipei, Taiwan. December, 1998
102
8 APÊNDICES
103
8.1 APÊNDICE 1: DESCRIÇÃO DOS CASOS DE USO DO SODC
PROCEDIMENTO INSERIR RISCO
Descrição Define o risco da ocorrência de um evento adverso em um determinado
local.
Usuário
Sequência de Passos
1. usuário deseja definir as informações relativas a um Risco;
2. sistema mostra uma lista de Eventos Adversos;
3. sistema mostra uma lista com Locais já cadastrados, indicando a existência de Riscos
para cada Local;
4. ENQUANTO usuário desejar visualizar os Riscos relacionados a um determinado
Local É FEITO
5. usuário seleciona um Local e solicita a visualização;
6. sistema mostra os Riscos registrados para aquele Local;
7. usuário seleciona o Evento Adverso e o Local, informa os dados sobre o Risco e
solicita a criação de um novo Risco;
8. sistema valida os dados do novo Risco, armazenando as informações;
9. usuário informa os Danos possíveis referentes ao Risco;
10. sistema armazena as informações;
11. procedimento é encerrado.
PROCEDIMENTO INSERIR RECURSO
Descrição Permite a inclusão de um novo recurso no
Mapa de Recursos.
Usuário
Sequência de Passos
1. Usuário deseja incluir novo Recurso;
104
2. sistema mostra os recursos já cadastrados;
3. SE o Recurso em questão já for cadastrado
1. ENTÃO o usuário escolhe o Recurso;
2. SENÃO
1. usuário insere um novo Recurso;
2. sistema armazena o novo Recurso;
4. usuário informa a Disponibilidade do Recurso para a Agência;
5. sistema armazena a Disponibilidade;
O procedimento é encerrado.
PROCEDIMENTO CRIAR PLANO DE OPERAÇÕES
Descrição Permite a criação de um Plano de Operações para um risco já
cadastrado.
Usuário SEDEC/RJ - Funcionário do Planejamento.
Sequência de Passos
1. usuário deseja criar um novo plano de operações;
2. sistema oferece a relação de Riscos já cadastrados;
3. usuário escolhe o risco;
4. usuário informa dados gerais do Plano;
5. sistema cria o Plano e grava os dados gerais;
6. SE o usuário desejar consultar outros Planos referentes ao mesmo Local e/ou Evento
Adverso ENTÃO o sistema executa o Procedimento Consultar Planos;
7. SE o usuário desejar consultar Atuações referentes a Ocorrências relacionadas ao
mesmo Local e/ou Evento Adverso ENTÃO o sistema executa o Procedimento
Consultar Atuações;
8. ENQUANTO o usuário desejar inserir uma nova ação no plano É FEITO
1. usuário define a classe e o tipo da ação-plano;
2. SE usuário desejar utilizar alguma ação-plano existente em outro plano
ENTÃO o sistema executa o Procedimento Consultar Ação-Plano;
105
3. SE usuário desejar utilizar alguma ação de atuação ENTÃO o sistema executa
o Procedimento Consultar Ação-Atuação;
4. usuário informa os dados da ação de planejamento;
5. SE for prevista a utilização de recursos ENTÃO
1. sistema disponibiliza consulta ao mapa de recursos local;
2. usuário seleciona os recursos;
9. sistema armazena a ação de planejamento;
10. procedimento é encerrado.
PROCEDIMENTO ATENDER OCORRÊNCIA
Descrição Permite o cadastramento das informações gerais referentes a uma
ocorrência, bem como a definição e o controle das ações executadas na atuação.
Usuário
Sequência de passos
1. usuário deseja informar atendimento de ocorrência;
2. SE for ocorrência nova, ENTÃO o Procedimento Inserir Ocorrência é executado;
3. Procedimento Criar Atuação é executado
PROCEDIMENTO INSERIR OCORRÊNCIA
Descrição Define a ocorrência de um evento adverso em um determinado local.
Usuário
Sequência de Passos
1. usuário deseja definir as informações relativas a uma ocorrência;
2. sistema mostra uma lista de eventos adversos;
3. sistema mostra uma lista com locais já cadastrados, indicando a existência de
ocorrências para cada local;
106
4. ENQUANTO usuário desejar visualizar as ocorrências relacionadas a um determinado
local É FEITO
1. usuário seleciona um local e solicita a visualização;
2. sistema mostra as ocorrências registradas para aquele local;
5. usuário seleciona o evento adverso e o local, informa os dados sobre a ocorrência e
solicita a criação de uma nova ocorrência;
6. sistema valida os dados da nova ocorrência, armazenando as informações;
7. procedimento é encerrado.
PROCEDIMENTO CRIAR ATUAÇÃO
Descrição Permite a criação de uma Atuação para uma Ocorrência.
Usuário SEDEC/RJ - Funcionário do Planejamento.
Sequência de Passos
1. usuário deseja criar uma nova Atuação;
2. sistema disponibiliza uma lista com as Ocorrências;
3. usuário escolhe a Ocorrência;
4. Usuário informa dados gerais da Atuação;
5. sistema cria a Atuação e armazena os dados gerais;
6. SE houver plano de operações local associado ao risco ENTÃO o sistema mostra esse
plano, para guiar a Atuação;
7. SE o usuário desejar consultar Planos referentes ao mesmo Local e/ou Evento Adverso
ENTÃO o sistema executa o Procedimento Consultar Plano;
8. SE o usuário desejar consultar Atuações referentes a Ocorrências relacionadas ao
mesmo Local e/ou Evento Adverso ENTÃO o sistema executa o Procedimento
Consultar Atuação;
9. ENQUANTO o usuário desejar inserir uma nova ação-atuação É FEITO
1. usuário define a classe e o tipo da ação-atuação;
2. SE usuário desejar utilizar alguma ação-plano existente em algum plano
ENTÃO o sistema executa o Procedimento Consultar Ação-Plano;
107
3. SE usuário desejar utilizar alguma ação-atuação existente em outra Atuação
ENTÃO o sistema executa o Procedimento Consultar Ação-Atuação;
4. usuário informa os dados da ação-atuação;
5. SE for prevista a utilização de recursos ENTÃO
1. sistema disponibiliza consulta ao mapa de recursos local;
2. usuário seleciona os recursos;
6. sistema armazena a ação-atuação;
10. ENQUANTO houver ação-atuação sendo executada É FEITO
1. usuário informa qual ação-atuação está sendo executada, fornecendo as
informações sobre o estado atual da ação-atuação (andamento da execução da
ação);
2. sistema armazena as informações referentes ao estado atual da ação-atuação;
3. SE a ação-atuação estiver concluída ENTÃO
1. usuário fornece as informações referentes à conclusão da ação-atuação;
2. sistema armazena as informações referentes à conclusão da ação-
atuação;
11. sistema armazena as informações referentes à Atuação;
12. usuário informa os Danos referentes à Ocorrência;
13. sistema armazena as informações;
14. procedimento é encerrado.
PROCEDIMENTO AVALIAR ATUAÇÃO
Descrição Permite avaliar o atendimento a uma ocorrência.
Usuário SEDEC/RJ: Funcionário da Doutrina e Capacitação.
1. usuário deseja avaliar a atuação referente a uma ocorrência;
2. sistema disponibiliza as atuações da agência já encerradas;
3. usuário seleciona a atuação;
4. sistema disponibiliza os dados da atuação e os dados da ocorrência respectiva;
5. SE houver plano de operações local associado ao risco ENTÃO o sistema mostra esse
plano;
6. PARA cada ação de planejamento do plano de operações local É FEITO
108
1. SE existir no atendimento alguma ação de atuação respectiva ENTÃO
1. SE o usuário desejar consultar Planos referentes ao mesmo Local e/ou
Evento Adverso ENTÃO o sistema executa o Procedimento Consultar
Planos;
2. SE o usuário desejar consultar Atuações referentes a Ocorrências
relacionadas ao mesmo Local e/ou Evento Adverso ENTÃO o sistema
executa o Procedimento Consultar Atuações;
3. SE usuário desejar consultar alguma ação-plano existente em algum
plano ENTÃO o sistema executa o Procedimento Consultar Ação-
Plano;
4. SE usuário desejar consultar alguma ação-atuação existente em outra
Atuação ENTÃO o sistema executa o Procedimento Consultar Ação-
Atuação;
5. SE o usuário desejar informar avaliação sobre a ação ENTÃO o sistema
armazena a informação;
7. PARA cada ação de atuação que não tenha correspondente no plano de operações local
É FEITO
1. SE o usuário desejar consultar Planos referentes ao mesmo Local e/ou Evento
Adverso ENTÃO o sistema executa o Procedimento Consultar Planos;
2. SE o usuário desejar consultar Atuações referentes a Ocorrências relacionadas
ao mesmo Local e/ou Evento Adverso ENTÃO o sistema executa o
Procedimento Consultar Atuações;
3. SE usuário desejar consultar alguma ação-plano existente em algum plano
ENTÃO o sistema executa o Procedimento Consultar Ação-Plano;
4. SE usuário desejar consultar alguma ação-atuação existente em outra Atuação
ENTÃO o sistema executa o Procedimento Consultar Ação-Atuação;
5. SE o usuário desejar informar avaliação sobre a ação ENTÃO o sistema
armazena a informação;
8. SE o usuário desejar informar avaliação geral da atuação ENTÃO o sistema armazena
a informação;
O procedimento é encerrado.
109
8.2 APÊNDICE 2: DIAGRAMAS DE SEQUÊNCIA DO SODC
INSERIR RISCO
: Divisão deMinimização de
Desastres
: RISCO : DANO : LOCAL : FATO
AddDanos(dados)Criar(dados)
INSERIR RISCO DE FATO NÃO CADASTRADO
AddFato(evento, dados)Criar(evento, local, dados)
Criar(dados, fato)
FIG. 8.1 - Diagrama de sequência do SODC referente à inserção de um risco
110
INSERIR RECURSO
: Divisão de Operações
: RECURSO : DISPONIBILIDADE
: INSTITUIÇÃO
INSERIR RECURSO NÃO CADASTRADO
AddDisponibilidade(recurso, dados)
Criar(recurso)
Criar(instituicao, recurso, dados)
FIG. 8.2 - Diagrama de sequência do SODC referente à inserção de recursos
111
CRIAR PLANOS
: Divisão de Operações
: RISCO : FATO : PLANO RESP : ACAO PLANO RESP
: EMPREGO
AddAcao(classe, tipo, dados)Criar(classe, tipo, dados, plano)
UsarRecurso(recurso, dados) Definir(recurso, dados)
CriarPlano(agencia) CriaPlano(agencia)Criar(agencia, risco, dados)
FIG. 8.3 - Diagrama de sequência do SODC referente a criação de planos
112
INSERIR OCORRÊNCIA
: OCORRENCIA : FATO : LOCAL
AddFato(evento, dados) Criar(evento, local, dados)
AddOcorrencia(dados) Criar(fato, dados)
INSERIR OCORRÊNCIA DE FATO NÃO CADASTRADO
: Divisão deMinimização de
Desastres
FIG. 8.4 - Diagrama de sequência do SODC referente a inserção de uma ocorrência
113
CRIAR ATUAÇÃO
: OCORRENCIA : Divisão de
Operações
: ATUACAO RESP
: ACAO ATUACAO RESP
: ACAOESTADO : UTILIZAÇÃO : DANO
AdAcao(classe, tipo, dados)Criar(classe, tipo, dados, atuacao)
UsarRecurso(recurso, acaoestado, dados) DefinirUtilizacao(recurso, dados)Definir(recurso, dados)
AddEstado(dados)Criar(dados)
AddDano(dados)Criar(dados)
AddAtuacao(agencia, dados)Criar(agencia, ocorrencia, dados)
FIG. 8.5 - Diagrama de sequência do SODC referente à criação de uma atuação
114
AVALIAR ATUAÇÃO
: Divisão de Operações
: ATUACAO RESP
: ACAO ATUACAO RESP
Avaliar(dados)
Avaliar(dados)AvaliarAcao(dados)
FIG. 8.6 - Diagrama de sequência do SODC referente à avaliação de uma atuação
115
8.3 APÊNDICE 3: CARTÕES DE CRC DO SODC
AÇÃO-ATUACAO DE RESPOSTA
RESPONSABILIDADES COLABORAÇÕES
Criar(classe, tipo, dados, atuacao)
{Define uma nova Ação-Atuação para uma
Atuação em particular}
-
AddEstado(dados)
{Define um estado para uma ação-atuação de
resposta}
AcaoEstado. Criar(dados)
UsarRecurso(recurso, acaoestado, dados)
{Define a utilização de recursos, em um
determinado estado de uma ação-atuação}
AcaoEstado.DefinirUtilizacao(recurso,
dados)
Avaliar(dados)
{Armazena informações sobre a avaliação da
ação}
-
ACAO_ESTADO
RESPONSABILIDADES COLABORAÇÕES
Criar(dados) {Define um novo estado para uma determinada ação}
-
DefinirUtilizacao(recurso, dados) {Define como um recurso é (foi) utilizado por uma ação, em um determinado estado}
Utilizacao. Definir(recurso, dados)
AÇÃO-PLANO DE RESPOSTA
116
RESPONSABILIDADES COLABORAÇÕES
Criar(classe, tipo, dados, plano) {Define uma nova ação-plano, para um Plano em particular}
-
UsarRecurso(recurso, dados) {Define a utilização de um recurso por uma ação}
Emprego.Definir(recurso, dados)
ATUAÇÃO DE RESPOSTA
RESPONSABILIDADES COLABORAÇÕES
Criar(agencia, ocorrencia, dados) {Cria a atuação de resposta de uma agência para uma determinada ocorrência}
-
AdAcao(classe, tipo, dados) {Inclui uma nova ação na atuação de resposta}
Acao-Atuacao.Criar(classe, tipo, dados, atuacao)
Avaliar(dados) {Armazena informações sobre a avaliação da Atuação}
-
AvaliarAcao(dados) Acao-Atuacao.Avaliar(dados)
DANO
RESPONSABILIDADES COLABORAÇÕES
Criar(dados) {Cria um Dano novo}
-
DISPONIBILIDADE
RESPONSABILIDADES COLABORAÇÕES
117
Criar(instituicao, recurso, dados) {Define a disponibilidade de um recurso para uma determinada Instituição}
-
EMPREGO
RESPONSABILIDADES COLABORAÇÕES
Definir(recurso, dados) {Define como um recurso é utilizado em uma ação-plano}
-
FATO
RESPONSABILIDADES COLABORAÇÕES
Criar(evento, local, dados) {Cria um Fato, referente a um Local e a um Evento Adverso}
Risco.Criar(fato, dados)
CriaPlano(agencia) {Cria, para o Fato, o Plano de uma Agência em particular}
Risco.CriarPlano(agencia)
AddOcorrencia(dados) Ocorrencia.Criar(fato, dados)
INSTITUIÇÃO
RESPONSABILIDADES COLABORAÇÕES
AddDisponibilidade(recurso, dados) {Adiciona uma disponibvilidade para uma Institutição}
Recurso.Criar(recurso) Disponibilidade.Criar(instituicao, recurso, dados)
LOCAL
118
RESPONSABILIDADES COLABORAÇÕES
AddFato(evento, dados) {Adiciona um Fato a um Local, relacionado a um Evento}
Fato.Criar(evento, local, dados)
OCORRÊNCIA
RESPONSABILIDADES COLABORAÇÕES
Criar(fato, dados) {Cria uma ocorrência}
-
AddAtuacao(agencia, dados) {Adiciona a Atuação de uma Agência à Ocorrência}
Atuacao.Criar(agencia, ocorrencia, dados)
AddDanos(dados) {Adiciona danos à Ocorrência}
Dano.Criar(dados)
PLANO DE RESPOSTA
RESPONSABILIDADES COLABORAÇÕES
Criar(agencia, risco, dados) {Cria o Plano de Resposta de uma Agência para um determinado Risco}
-
AddAcao(classe, tipo, dados) {Inclui uma nova ação no plano de resposta}
Acao-Plano.Criar(classe, tipo, dados, plano)
RECURSO
RESPONSABILIDADES COLABORAÇÕES
Criar(recurso) {Cria um recurso, ainda não cadastrado}
-
119
RISCO
RESPONSABILIDADES COLABORAÇÕES
Criar(dados, fato) {Cria um Risco, referente a um Fato}
-
AddDanos(dados) {Adiciona possíveis danos ao Risco}
Dano.Criar(dados)
UTILIZACAO
RESPONSABILIDADES COLABORAÇÕES
Definir(recurso, dados) {Define como um recurso é utilizado em uma ação-atuação}
-
120
8.4 APÊNDICE 4: DIAGRAMAS DE SEQUÊNCIA DO FRAMEWORK
INSERIR PREVISÃO
: Usuario : CARACTERÍSTICA : FATO : PREVISAO :
CONSEQUENCIA
AddFato( )Criar( )
Criar( )
AddConsequencia( )Criar( )
FIG. 8.7 - Diagrama de Sequência do framework referente à inserção de uma Previsão
121
INSERIR RECURSO
: INSTITUIÇÃO : Usuario
: RECURSO : DISPONIBILIDADE
AddDisponibilidade(recurso, dados)Criar(recurso)
Criar(instituicao, recurso, dados)
FIG. 8.8 - Diagrama de sequência do framework referente à inserção de Recursos
122
CRIAR PLANOS
: Usuario : FATO : PREVISAO : PLANO : ACAO
PLANEJAMENTO : EMPREGO
CriarPlano(decisor, dados)
CriarPlano(decisor, dados)Criar(decisor, previsao, dados)
AddAcao(dados)Criar(dados, plano)
UsarRecurso(recurso, dados) Definir(recurso, dados)
FIG. 8.9 - Diagrama de sequência do framework referente à criação de um Plano
123
INSERIR ACONTECIMENTO
: FATO : ACONTECIMENTO
: Usuario
AddFato(dados)Criar( )
AddAcontecimento(dados)Criar(dados, fato)
: CARACTERÍSTICA
FIG. 8.10 - Diagrama de sequência do framework referente à inserção de um Acontecimento
124
CRIAR ATUAÇÃO
: Usuario :
ACONTECIMENTO : ATUACAO : ACAO
ATUACAO : ACAOESTADO : UTILIZAÇÃO :
CONSEQUENCIA
AddAtuacao(decisor, dados)Criar(decisor, acontecimento, dados)
AddAcao(dados)Criar(dados)
AddEstado(dados)Criar(dados)
UsarRecurso(recurso, acaoestado, dados)DefinirUtilizacao(recurso, dados)
Definir(recurso, dados)
AddConsequencia(dados)Criar(dados)
FIG. 8.11 - Diagrama de sequência do framework referente à criação de uma Atuação
125
AVALIAR ATUAÇÃO
: Usuario
: ATUACAO : ACAO ATUACAO
AvaliarAcao(dados)Avaliar(dados)
Avaliar(dados)
FIG. 8.12 - Diag. de sequência do framework referente à avaliação de uma Atuação
126
8.5 APÊNDICE 5: CARTÕES DE CRC DO FRAMEWORK
AÇÃO-ATUAÇÃO
RESPONSABILIDADES COLABORAÇÕES
Criar(dados,plano) {Cria uma nova ação de planejamento}
-
AddEstado(dados) {Insere um novo estado para a ação-atuação}
AcaoEstado.Criar(dados)
UsarRecurso(recurso, acao-estado, dados) {Define com um recurso é empregado}
AcaoEstado.DefinirUtilizacao(recurso, dados)
Avaliar(dados) {Permite avaliar a ação de atuação}
-
AÇÃO-ESTADO
RESPONSABILIDADES COLABORAÇÕES
Criar(dados) {Cria um novo estado para uma ação-atuação}
-
AÇÃO-PLANEJAMENTO
RESPONSABILIDADES COLABORAÇÕES
Criar(dados,plano) {Cria uma nova ação de planejamento}
-
UsarRecurso(recurso, dados) {Define com um recurso é empregado}
Emprego.Definir(recurso, dados)
ACONTECIMENTO
127
RESPONSABILIDADES COLABORAÇÕES
Criar(dados,fato) {Cria um novo acontecimento referente a um fato}
-
AddAtuacao(decisor,dados) {Adiciona uma nova atuação, de responsabilidade de um decisor, referente a um acontecimento, }
Atuacao.Criar( decisor, acontecimento, dados)
AddConsequencia(dados) {Adiciona uma consequência para um acontecimento}
Consequencia.Criar( )
ATUAÇÃO
RESPONSABILIDADES COLABORAÇÕES
Criar(decisor, acontecimento, dados) {Cria uma nova atuação, de responsabilidade de um decisor, referente a um acontecimento, }
-
AddAcao(dados) {Adiciona uma ação à atuação}
AcaoAtuacao.Criar(dados, planos)
AvaliarAcao(dados) {Permite a avaliação de uma das ações da atuação}
AcaoAtuacao.Avaliar(dados)
Avaliar(dados) {Permite a avaliação da atuação como um todo}
-
CARACTERÍSTICA
RESPONSABILIDADES COLABORAÇÕES
AddFato( )
{Adiciona um Fato a uma determinada
característica}
Fato.Criar( )
CONSEQUÊNCIA
128
RESPONSABILIDADES COLABORAÇÕES
Criar( ) {Cria uma nova consequência, referente ao acontecimento ou à previsão de um fato}
-
DISPONIBILIDADE
RESPONSABILIDADES COLABORAÇÕES
Criar(instituicao, recurso, dados) {Cria uma nova disponibilidade}
-
EMPREGO
RESPONSABILIDADES COLABORAÇÕES
Definir(recurso, dados) {Define o emprego de um recurso em uma ação de planejamento}
-
FATO
RESPONSABILIDADES COLABORAÇÕES
Criar( ) {Cria um novo fato}
Previsão.Criar( )
CriarPlano(decisor, dados) {Cria um plano para a previsão do fato}
Previsão.CriarPlano(decisor, dados)
AddAcontecimento(dados) {Adiciona um acontecimento referente a um fato}
Acontecimento.Criar(dados,fato)
INSTITUIÇÃO
129
RESPONSABILIDADES COLABORAÇÕES
AddDisponibilidade( ) {Adiciona uma disponibilidade de um recurso para a instituição}
Recurso.Criar( ) Disponibilidade.Criar(instituicao, recurso, dados)
PLANO
RESPONSABILIDADES COLABORAÇÕES
Criar(decisor, previsão, dados ) {Cria um novo plano}
-
AddAcao(dados) {Adiciona uma ação ao plano}
AcaoPlanejamento.Criar(dados, planos)
PREVISÃO
RESPONSABILIDADES COLABORAÇÕES
Criar( ) {Cria uma nova previsão}
-
AddConsequencia( ) {Adiciona uma consequência para uma previsão}
Consequencia.Criar( )
CriarPlano(decisor, dados) {Cria um plano para uma previsão}
Plano.Criar(decisor, previsão, dados)
RECURSO
RESPONSABILIDADES COLABORAÇÕES
Criar( ) {Cria um novo recurso}
-
130
UTILIZAÇÃO
RESPONSABILIDADES COLABORAÇÕES
Definir(recurso, dados) {Define como um recurso é utilizado em uma ação de atuação}
-