Um Framework para Análise de Custo de Ciclo de Vida Baseado em Reuso e Interoperabilidade

UNIVERSIDADE FEDERAL FLUMINENSE
ESCOLA DE ENGENHARIA
PROGRAMA DE DOUTORADO EM ENGENHARIA DE PRODUÇÃO
DENIS GONÇALVES COPLE
UM FRAMEWORK PARA ANÁLISE DE CUSTO DE CICLO DE VIDA

BASEADO EM REUSO E INTEROPERABILIDADE
NITERÓI
2010

Tese apresentada ao Curso de Doutorado em

Engenharia de Produção da Universidade
Federal Fluminense, como requisito parcial
para obtenção do Grau de Doutor. Área de
concentração: Sistemas, Apoio à Decisão e
Logística.
Orientador: Prof. EDUARDO SIQUEIRA BRICK, PhD.
Niterói
2010

Tese apresentada ao Curso de Doutorado em

Engenharia de Produção da Universidade
Federal Fluminense, como requisito parcial
para obtenção do Grau de Doutor. Área de
concentração: Sistemas, Apoio à Decisão e
Logística.
Aprovada em 15 de Dezembro de 2010.
BANCA EXAMINADORA
___________________________________________________________
Prof. Dr. EDUARDO SIQUEIRA BRICK – Orientador
Universidade Federal Fluminense
____________________________________________________________
Prof. Dr. ARTUR ALVES PESSOA
____________________________________________________________
Profa. Dra. VIVIANE TORRES DA SILVA
____________________________________________________________
Prof. Dr. EDSON JOSÉ DALTO
Instituto Brasileiro de Mercados de Capitais
___________________________________________________________
Prof. Dr. EDUARDO SALIBY
Universidade Federal do Rio de Janeiro
___________________________________________________________
Prof. Dr. FERNANDO HIDEO FUKUDA
Universidade Estácio de Sá
Niterói
2010
Dedico a minha prole,
Andrew e Yasmin.
AGRADECIMENTOS
Aos Professores Eduardo Siqueira Brick e Annibal Parracho Sant’Anna, que mais do que
grandes mestres, se tornaram também bons amigos no decorrer desta pesquisa.
Aos meus pais, pelo exemplo que sempre foram para mim.
Aos meus filhos, Andrew e Yasmin, pelo simples fato de existirem.
À Universidade Federal Fluminense, pelos novos conhecimentos adquiridos e pela
oportunidade de discutir com grandes mestres.
RESUMO
Esta tese trata do problema de Análise do Custo de Ciclo de Vida (ACCV) de sistemas
técnicos, com o uso de ferramentas de simulação, sob a ótica do reuso e da interoperabilidade.
Inicialmente é feito um estudo acerca das técnicas e arquiteturas da atualidade voltadas para
reuso e interoperabilidade, tais como frameworks, elementos genéricos, anotações, arquitetura
de software e padrões de desenvolvimento, além do uso de Arquiteturas Orientadas a Serviço,
sendo estes elementos contextualizados frente às atuais necessidades pra simulações
complexas e distribuídas, e tendo como exemplo relevante destas tendências o surgimento da
High Level Architecture (HLA). São analisados os princípios básicos da ACCV e seu
relacionamento com o Modelo de Pilla e Cople para ACCV. Com base no Modelo de Pilla e
Cople, foi criado um framework para simulação de custo de ciclo de vida, utilizando-se de
instâncias dinâmicas e buscando aproveitar o poder computacional fornecido pelo
processamento paralelo e distribuído. Foram analisadas técnicas de reuso e de
interoperabilidade e as mais adequadas foram utilizadas na construção deste framework.
Também foi desenvolvida uma interface para cadastro dos dados, gerência das simulações e
análise de resultados obtidos. Um caso de teste foi estabelecido e utilizado para testar as
funcionalidades de extensão, interoperabilidade e operação do framework e da interface
desenvolvida. Esses testes demonstraram as capacidades de operação, extensão e
interoperabilidade do framework e sua interface.
Palavras-Chave: Engenharia de Sistemas, Apoio Logístico, Análise de Custo de Ciclo de

Vida, Computação Científica, Simulação, Reuso, Interoperabilidade.
ABSTRACT
This thesis deals with the technical systems Life Cycle Cost Analysis (LCCA)
problem, with the use of simulation tools, under reuse and interoperability visions. At first,
the reuse and interoperability techniques and architectures, such as frameworks, generic
elements, annotations, software architecture and design patterns in addition to the use of
Service Oriented Architecture (SOA) are reviewed and contextualized with respect to the
present requirements for complex distributed simulations, also considered by the High Level
Architecture (HLA). The ACCV basic principles are analyzed and their relationship to the
Pilla and Cople Model is established. Based on this model a LCCA simulation framework
was developed, using dynamic instances and trying to enjoy the computing power provided
by parallel and distributed computing. Reuse and interoperability techniques have been
analyzed and the best ones have been applied to the framework. An interface for data entry,
simulation manager and data analysis was also developed. A test case was designed and used
to test the reuse, interoperability and operation functionalities of the framework and the
interface developed. These tests have demonstrated the operation, extension and
interoperability capabilities of the framework and interface..
Key Words: Systems Engineering, Logistics Support, Life Cycle Costing Analysis, Scientific
Computing, Simulation, Reuse, Interoperability.
SUMÁRIO
1. Introdução ........................................................................................................................ 18
1.1 Apresentação .............................................................................................................. 18
1.2 Objetivos .................................................................................................................... 22
1.2.1 Objetivo Geral ..................................................................................................... 22
1.2.2 Objetivos Específicos .......................................................................................... 22
1.3 Justificativa ................................................................................................................ 23
1.4 Delimitação do Estudo ............................................................................................... 24
1.5 Referencial Teórico .................................................................................................... 25
1.5.1 Análise de Custo de Ciclo de Vida ....................................................................... 25
1.5.2 Simulação ............................................................................................................ 26
1.5.3 Reuso de Software ............................................................................................... 27
1.5.4 Arquitetura de Software ....................................................................................... 28
1.5.5 Interoperabilidade ................................................................................................ 30
1.5.6 Processamento Distribuído .................................................................................. 31
1.6 Estrutura do Trabalho ................................................................................................. 32
2. Simulações Computacionais, Reuso e Interoperabilidade ................................................. 33
2.1 Introdução .................................................................................................................. 33
2.2 Simulações por Eventos Discretos .............................................................................. 34
2.3 Técnicas de Reuso no Desenvolvimento de Software .................................................. 39
2.4 Arquiteturas voltadas para o Reuso ............................................................................. 42
2.5 Interoperabilidade....................................................................................................... 49
2.6 Processamento Distribuído ......................................................................................... 54
2.7 Framework de ACCV Original ................................................................................... 56
2.8 Conclusões ................................................................................................................. 60
3. Custo de Ciclo de Vida e o Modelo de Pilla e Cople ......................................................... 65
3.1 Introdução .................................................................................................................. 65
3.2 Fatores Estruturais ...................................................................................................... 67
3.3 Confiabilidade, Manutenibilidade e Disponibilidade................................................... 72
3.4 Atividades .................................................................................................................. 75
3.5 Órgãos........................................................................................................................ 79
3.6 Fatores Financeiros .................................................................................................... 82
9
3.7 Estrutura de Desdobramento de Custos....................................................................... 85

3.8 Modelo de Transportes ............................................................................................... 88
3.9 Cenário de Análise ..................................................................................................... 90
3.10 Modelo de Eventos ................................................................................................... 93
3.11 Modelo de Consumo de Recursos ........................................................................... 100
3.12 Modelo de Cálculo de Custo ................................................................................... 101
3.13 Regimes de Operação de Sistemas .......................................................................... 102
4. Arquitetura e Extensão do Novo Framework .................................................................. 105
4.1 Introdução ................................................................................................................ 105
4.2 Modificações Arquiteturais....................................................................................... 107
4.3 Processamento Distribuído ....................................................................................... 114
4.4 Uso de Anotações ..................................................................................................... 120
4.5 Elementos Genéricos ................................................................................................ 125
4.6 Arquitetura MSVC e Padrões de Desenvolvimento................................................... 129
5. Utilização do Novo Framework ..................................................................................... 136
6. Interoperabilidade e Extensão do Framework ................................................................. 149
6.1 Introdução ................................................................................................................ 149
6.2 Interoperabilidade do Framework ............................................................................. 149
6.3 Extensão do Framework ........................................................................................... 157
7. Conclusões e trabalhos futuros ....................................................................................... 169
8. Referências Bibliográficas.............................................................................................. 173
ANEXO A - Reuso de Software ......................................................................................... 194
A.1 Introdução ............................................................................................................... 194
A.2 Programação Orientada a Objetos ............................................................................ 195
A.2.1 Herança ............................................................................................................ 196
A.2.2 Polimorfismo e Elementos Abstratos ................................................................ 199
A.2.3 Avaliação do reuso na orientação a objetos ....................................................... 202
A.3 Padrões de Desenvolvimento ................................................................................... 204
A.4 Elementos Genéricos ............................................................................................... 206
A.5 Anotações................................................................................................................ 210
ANEXO B - Arquitetura de Software ................................................................................. 212
B.1 Introdução ............................................................................................................... 212
B.2 Principais Arquiteturas ............................................................................................ 214
B.3 Frameworks ............................................................................................................. 224
10
B.3.1 Frameworks voltados para Processos ................................................................ 226

B.3.2 Frameworks Orientados a Objetos .................................................................... 228
B.3.3 Java Persistence Architecture ............................................................................ 231
B.3.4 Java Enterprise Edition 5................................................................................... 234
B.4 Interoperabilidade .................................................................................................... 239
B.4.1 Web Services e Arquitetura SOA ...................................................................... 242
ANEXO C - Elementos de Simulação Por eventos ............................................................. 248
C.1 Introdução ............................................................................................................... 248
C.2 Simulação Computacional ....................................................................................... 249
C.3 Simulação por eventos Discretos.............................................................................. 256
C.4 Geradores Randômicos ............................................................................................ 266
C.5 Características Desejáveis de um Sistema de Simulação .......................................... 267
ANEXO D – Caso de Teste................................................................................................ 269
11
LISTA DE ILUSTRAÇÕES
Figura 1: Formas de estudo de um sistema. .......................................................................................26

Figura 2: Arquitetura de Software no Processo de Desenvolvimento..................................................29
Figura 3: Componente com acoplamento. ..........................................................................................35
Figura 4: Interpretação informal do Cell-DEVS. ................................................................................36
Figura 5: Mapeamento da Árvore Abstrata de Threads de Simulação. ...............................................38
Figura 6: Padrão State para DEVS atomizado expresso em UML. .....................................................41
Figura 7: Padrões de Desenvolvimento presentes no J2EE .................................................................47
Figura 8: Quadro comparativo entre alguns elementos normativos. ....................................................52
Figura 9: Visão funcional de uma simulação distribuída sob HLA. ....................................................53
Figura 10: Fluxo de utilização do framework .....................................................................................58
Figura 11: Arquitetura do framework original....................................................................................59
Figura 12: Diagrama de Classes para Recursos ..................................................................................68
Figura 13: Diagrama de Classes para Produto ....................................................................................69
Figura 14: Exemplo de Sistema Técnico............................................................................................71
Figura 15: Diagrama de Classes para Modos de Falha .......................................................................73
Figura 16: Exemplo de Modo de Falha ..............................................................................................74
Figura 17: Diagrama de Classes para Atividades ...............................................................................76
Figura 18: Diagrama de Classes para Órgão ......................................................................................79
Figura 19: Exemplo de estruturas de manutenção e abastecimento .....................................................82
Figura 20: Diagrama de Classes para Modelo de Tratamento Financeiro ...........................................84
Figura 21: Relações entre CBS, OBS e WBS.....................................................................................86
Figura 22: Estrutura da CBS..............................................................................................................87
Figura 23: Exemplo de CBS na interface cadastral do framework. .....................................................88
Figura 24: Diagrama de Classes para o Modelo de Transporte ...........................................................89
Figura 25: Diagrama de Classes Alterado para Cenário de Análise ....................................................91
Figura 26: Diagrama de Classes para Sistemas em Cenários ..............................................................92
Figura 27: Diagrama de Classes para Atividades sobre Produtos no Cenário......................................93
Figura 28: Modelo de Geração de Eventos ........................................................................................93
Figura 29: Diagrama de Classes Expandido para Modelo de Geração de Eventos ..............................95
Figura 30: Diagramas de Classes para o Plano de Execução de Atividades ........................................99
Figura 31: Diagrama de Classes para o Modelo de Consumo de Recursos ....................................... 100
Figura 32: Diagrama de Classes para Modelo de Cálculo de Custo .................................................. 101
Figura 33: Diagrama de Classes para Agenda de Operação de Sistemas ........................................... 103
Figura 34: Novo modelo de persistência .......................................................................................... 107
Figura 35: Serviços de Intermediação de Dados e Construção de Cenários ...................................... 108
Figura 36: Serviços de Extração de Resultados ................................................................................ 110
Figura 37: Arquitetura de Distribuição de Processamento ................................................................ 111
Figura 38: Serviço de Gerenciamento de Simulações ....................................................................... 112
Figura 39: Serviço de Criação de Classes ........................................................................................ 113
Figura 40: Diagrama completo da arquitetura de distribuição de simulações. ................................... 117
Figura 41: Módulos cliente e servidor para execução de simulações. ............................................... 118
Figura 42: Exemplo de anotação utilizada no framework. ................................................................ 120
Figura 43: Anotação pra definição de elemento do framework. ........................................................ 121
Figura 44: Anotação para definição de uma nova Atividade no framework. ..................................... 121
Figura 45: Anotação para definição de propriedades expostas na interface. ...................................... 122
Figura 46: Exibição de novo tipo de atividade na interface cadastral. ............................................... 122
Figura 47: Codificação de um novo tipo de atividade. ..................................................................... 123
Figura 48: Entradas criadas no banco para reconhecimento da atividade e suas propriedades. .......... 123
Figura 49: Assinatura dos métodos de GenericDAO. ....................................................................... 125
Figura 50: Exemplo de utilização do gestor genérico de acesso a banco de dados. ........................... 126
12
Figura 51: Classe para listas de objetos JPA com gravação em background. .................................... 127
Figura 52: Especialização de GenericManager. ............................................................................... 128
Figura 53: Criação da classe para gravação de movimentação de estoque. ....................................... 128
Figura 54: Criação da classe para gravação de instâncias de produtos da simulação. ........................ 129
Figura 55: Resumo esquemático do Processo de Manutenção antigo. ............................................... 131
Figura 56: Resumo esquemático do Processo de Manutenção Padrão do novo framework. ............... 132
Figura 57: Resumo esquemático do modelo de geração de eventos padrão. ...................................... 133
Figura 58: Implementação do estado padrão “Iniciado”. .................................................................. 134
Figura 59: Implementação do estado padrão “Ativo”. ...................................................................... 135
Figura 60: Tela inicial da interface cadastral. ................................................................................... 136
Figura 61: Tela principal do módulo de catálogo. ............................................................................ 137
Figura 62: Cadastro de locais geográficos........................................................................................ 138
Figura 63: Cadastro de órgãos. ........................................................................................................ 138
Figura 64: Cadastro de percursos e respectivas distâncias. ............................................................... 139
Figura 65: Cadastro de meios de transporte e respectivos fatores de custo. ....................................... 139
Figura 66: Telas de cadastro de produto. ......................................................................................... 140
Figura 67: Interface para cadastro de cenários. ................................................................................ 141
Figura 68: Algumas telas do modulo de cenário. ............................................................................. 142
Figura 69: Tela para solicitação de simulações. ............................................................................... 143
Figura 70: Fornecimento de resultados no formato SOAP pelo framework de ACCV. ..................... 144
Figura 71: Custos globais para um grupo de simulações. ................................................................. 145
Figura 72: Custos mensais para uma simulação individual. .............................................................. 145
Figura 73: Consumo de recursos mensais para um grupo de simulações. ......................................... 146
Figura 74: Disponibilidade de uma instância de sistema. ................................................................. 147
Figura 75: Acompanhamento da linha de vida de uma instância de sistema...................................... 147
Figura 76: Análise da movimentação mensal de estoque para um produto........................................ 148
Figura 77: Análise pontual da movimentação de estoque para um produto. ...................................... 148
Figura 78: Criação de aplicativo de linha de comando com C#. ....................................................... 150
Figura 79: Adição do Web Service Java ao sistema em C#. ............................................................. 152
Figura 80: Reconnhecimento do Web Service pelo C#. .................................................................... 152
Figura 81: Codificação para interpretação de parâmetros no Extrator de Resultados ........................ 153
Figura 82: Chamadas ao Web Service de Reultados a partir do C#. .................................................. 154
Figura 83: Adição do elemento COM do Microsoft Excel. ............................................................... 155
Figura 84: Código para ativação da planilha e transferência de resultados. ....................................... 155
Figura 85: Resultado da extração de resultados para o Microsoft Excel. ........................................... 156
Figura 86: Código da classe Java para Sistema de Rede. ................................................................. 159
Figura 87: Código da classe Java para Atividade de Configuração de Rede ..................................... 160
Figura 88: Código da classe Java para Atividade de Reparo com atraso........................................... 161
Figura 89: Modelo para Geração de Eventos no Processo de Manutenção com atraso ...................... 161
Figura 90: Código da classe “ProcessoManutencaoRede”. ............................................................... 162
Figura 91: Código da classe “ManutencaoAtrasoIniciadoState”. ...................................................... 163
Figura 92: Código da classe “ManutencaoAtrasoReparoState”. ....................................................... 164
Figura 93: Ambiente de registro das anotações no framework de ACCV. ......................................... 165
Figura 94: Cadastro de sistema do tipo “Sistema de Rede”. ............................................................. 166
Figura 95: Configuração das atividades extendidas. ......................................................................... 167
Figura 96: Modo de falha com utilização do novo gerador de eventos.............................................. 168
Figura 97: Resultado da simulação para o cenário de sistemas de rede. ............................................ 168
Figura 98: Exemplo de herança no Modelo de Pilla e Cople ............................................................ 197
Figura 99: Exemplo de uso do Java com instâncias de descendentes................................................ 198
Figura 100: Exemplo de polimorfismo no Modelo de Pilla e Cople ................................................. 200
Figura 101: Exemplo de utilização de interfaces na modelagem....................................................... 201
Figura 102: Elementos genéricos como facilitadores na detecção de erros em Java.......................... 206
Figura 103: Exemplo de definição de classe genérica em Java......................................................... 207
Figura 104: Exemplo de utilização de classe genérica em Java ........................................................ 207
Figura 105: Código Java para a lista de falhas simuladas ................................................................. 208
13
Figura 106: Parte do código Java para a classe de lista genérica com suporte a concorrência. .......... 209
Figura 107: Exemplo de anotação definida no framework de ACCV................................................ 210
Figura 108: Exemplo de utilização de anotações no framework de ACCV ....................................... 211
Figura 109: Relacionamento entre Modelo de Referência, Padrão Arquitetural, Arquitetura de
Referência e Arquitetura de Software .............................................................................................. 213
Figura 110: Exemplo de Arquitetura com VisiBroker ...................................................................... 213
Figura 111: Arquitetura Pipes/Filters .............................................................................................. 215
Figura 112: Arquitetura Blackboard ................................................................................................ 216
Figura 113: Domínios do Java Message Service .............................................................................. 217
Figura 114: Estilo Arquitetural de Interpretador .............................................................................. 218
Figura 115: Ambiente Java simples para Internet ............................................................................ 221
Figura 116: Arquitetura PAC (Presentation, Abstraction, Control) .................................................. 222
Figura 117: Código para geração de instâncias ................................................................................ 223
Figura 118: Arquitetura para reutilização de processos .................................................................... 228
Figura 119: Exemplo de código para bean de entidade .................................................................... 232
Figura 120: Exemplo de arquivo de configuração persistence.xml ................................................... 233
Figura 121: Exemplo de inserção de dados no JPA .......................................................................... 233
Figura 122: Exemplo de consulta JP-QL ......................................................................................... 234
Figura 123: Session Beans e Entity Beans em um aplicativo ............................................................ 236
Figura 124: Session Facade no JEE5 ............................................................................................... 237
Figura 125: Modelos de Mensagens com JMS ................................................................................. 238
Figura 126: Fragmentos de código equivalentes nos formatos DTD e XSD...................................... 243
Figura 127: Exemplo de código Java anotado para criação de Web Services .................................... 244
Figura 128: Simulador de Tráfego utilizando DEVS atomizado ....................................................... 259
Figura 129: Simulador de Tráfego utilizando DEVS com acoplamento ............................................ 260
Figura 130: Efeito da falha em E2 para o sistema de exemplo. ......................................................... 263
Figura 131: Operação Normal, sem eventos que causem indisponibilidade ...................................... 264
Figura 132: Eventos com distribuição e duração aleatórias .............................................................. 264
Figura 133: Eventos causadores de indisponibilidade com distribuição definida e duração fixa ........ 265
Figura 134: Efeito sobre um sistema com operação agendada, com deslocamento ........................... 265
Figura 135: Efeito sobre um sistema com operação agendada, sem deslocamento ............................ 265
Figura 136: Representação gráfica do Sistema de Teste. .................................................................. 270
14
LISTA DE TABELAS
Tabela 1: Exemplo de "Árvore de Produtos" .....................................................................................70

Tabela 2: Classificação de algumas das atividades do modelo, segundo os três tipos principais ..........78
Tabela 3: Exemplo de Caracterização de Órgãos ...............................................................................81
Tabela 4: Relacionamento entre Atividades e Modelos de Eventos ....................................................95
Tabela 5: Configuração de Planos de Execução de Atividades (Parcial) .............................................99
Tabela 6: Comparação entre as implementação para simulação da ACCV ....................................... 119
Tabela 7: Alguns pontos de flexibilização do novo framework ........................................................ 124
Tabela 8: Períodos de análise por Tipo de Resultado. ...................................................................... 144
Tabela 9: Chamadas ao Serviço de Fornecimento de Resultados ...................................................... 151
Tabela 10: Parâmetros do Extrator de Resultados ............................................................................ 153
Tabela 11: Custos de aquisição para as redes de exemplo. ............................................................... 158
Tabela 12: Duração das atividades e consumo de recursos para as redes do exemplo. ...................... 158
Tabela 13: Configuração e operação dos sistemas de rede. .............................................................. 165
Tabela 14: Classificação das Arquiteturas segundo Shaw e Garlan (1996) ....................................... 219
Tabela 15: Classificação das Arquiteturas segundo Buschmann et al. (1996) ................................... 219
Tabela 16: Componentes da Arquitetura MVC ................................................................................ 220
Tabela 17: Paralelo entre Web Services e outras tecnologias ............................................................ 244
Tabela 18: Classificação dos Modelos Matemáticos de Simulação. .................................................. 251
Tabela 19: Estrutura do Sistema de Teste e características dos componentes .................................... 269
Tabela 20: Operação dos Sistemas para o Caso de Teste. ................................................................. 271
Tabela 21: Preço de mão-de-obra para o caso de testes. ................................................................... 272
Tabela 22: Tempo gasto por atividade em horas, para o caso de teste............................................... 272
Tabela 23: Modelos utilizados no cenário ........................................................................................ 273
Tabela 24: Configuração da manutenção preventiva no caso de testes.............................................. 274
Tabela 25: Atividades de manutenção corretiva executadas por órgão no caso de testes ................... 274
Tabela 26: Dotação de Estoque para o Caso de Teste....................................................................... 275
15
LISTA DE EQUAÇÕES
Equação 1 .........................................................................................................................................83
Equação 2 .........................................................................................................................................83
16
LISTA DE SÍMBOLOS E ABREVIATURAS
ACCV Análise de Custo de Ciclo de Vida

ACTP Análise de Custo Total de Posse
ACVU Análise de Custo de Vida Útil
ANSI American National Standards Institute
ARS Application Requirement Specification
BPEL Business Process Execution Language
CBS Cost Breakdown Structure
CCV Custo de Ciclo de Vida
CORBA Common Object Request Broker Architecture
COTS Commercial Off-The-Shelf
CSE Coordenador de Simulações em Execução
CTP Custo Total de Posse
CVU Custo de Vida Útil
DCOM Distributed Component Object Model
DES Discrete Event Simulation
DEVS Parallel Discrete Event Simulation
DNS Domain Name System
DOD Department of Defense
DTD Document Type Definition
MOD Ministry of Defense
EIA Electronic Industry Association
EJB Enterprise Java Bean
ERP Enterprise Resource Planning
FRS Framework Requirement Specification
GSS Gerador de Solicitações de Simulação
HLA High Level Architecture
IDL Interface Definition Language
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronic Engineers
IIOP Internet Inter-Orb Protocol
INCOSE International Council for Systems Engineering
ISO International Organization for Standardization
I/O Input/Output
JDBC Java Database Connectivity
JDO Java Database Objects
JEE Java Enterprise Edition
JNDI Java Naming and Directory Interface
JPA Java Persistence Architecture
17
LCC Life Cycle Cost

LCCA Life Cycle Cost Analysis
LDAP Lightweight Directory Access Protocol
LRU Local Replaceable Unit
MDB Message-Driven Bean
MOM Message Oriented Middleware
MTBF Mean Time Between Failures
MVC Model-View-Control
NFF No Fault Found
NRTS Not Repairable This Site
OBS Organization Breakdown Structure
ODBC Open Database Connectivity
OMG Object Modeling Group
PAC Presentation-Abstraction-Control
PDES Parallel Discrete Event Simulation
PDEVS Parallel Discrete Event System Specification
P2P Peer-To-Peer
RIP Repair in Place
RMI Remote Method Invocation
RPC Remote Procedure Call
RRS Receptor de Resultados Simulados
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
SOC Service Oriented Computing
SQL Structured Query Language
SRU Shop Replaceable Unit
UDDI Universal Description, Discovery and Integration
UML Unified Modeling Language
WBS Work Breakdown Structure
WSDL Web Services Description Language
XML Extended Markup Language
XSD XML Schema Definition Language
18
1. INTRODUÇÃO
1.1 APRESENTAÇÃO
Sistemas técnicos são ativos compostos por instalações, equipamentos, softwares e

pessoas, concebidos e desenvolvidos para permitir a implementação de processos produtivos
com finalidades específicas (missão do sistema).
Esses sistemas são compostos por uma grande quantidade de ativos físicos
(instalações, equipamentos) dedicados à atividade fim e possivelmente distribuídos em várias
unidades operacionais em locais geograficamente distintos, além de sistemas capacitadores
(estruturas de manutenção e abastecimento, por exemplo), também distribuídos
geograficamente.
Quando se projeta um sistema técnico desse tipo para resolver um determinado
problema existem duas considerações a serem feitas: a eficácia do sistema e a sua eficiência.
A eficácia define o grau de alcance da finalidade do sistema, enquanto a eficiência mede a
quantidade de recursos de toda a ordem despendidos para alcançar a eficácia mínima
desejável.
Com a crescente complexidade dos sistemas técnicos da atualidade, torna-se
necessária uma pré-avaliação da implementação, operacionalização e desativação dos
mesmos, sob a ótica da eficiência e da eficácia. Para sistemas complexos, do tipo considerado
neste trabalho, o indicador de eficiência mais indicado é chamado de Custo de Ciclo de
Vida (CCV), Custo de Vida Útil (CVU), ou Custo Total de Posse (CTP). As abordagens que
visam avaliar a priori esses indicadores de eficiência são denominadas Análise de Custo de
Ciclo de Vida (ACCV), Análise de Custo de Vida Útil (ACVU), e Análise de Custo Total de
Posse (ACTP), respectivamente. A disponibilidade do sistema, ou a sua capacidade produtiva,
é um importante indicador da sua eficácia e a sua avaliação a priori também é desejável e é
um subproduto desse tipo de análise.
19
Essa metodologia de avaliação econômica de projetos, deve considerar todos os custos

relativos à aquisição, desenvolvimento, operação, manutenção e desativação, desde que os
mesmos sejam considerados potencialmente importantes para uma tomada de decisão.
As questões ligadas à ACCV são dos mais diversos tipos, envolvendo, além de
considerações acerca de custos, o estudo das configurações do sistema, da confiabilidade,
manutenibilidade e disponibilidade de equipamentos. Muitos são os modelos que podem ser
utilizados na análise, mas todos com um mesmo fim, que é estimar o custo total do sistema
durante toda a sua existência.
Devido à grande quantidade de cálculos envolvidos, à aleatoriedade intrínseca das
situações sendo analisadas e à variedade de situações a serem modeladas, simulações
computacionais do tipo Monte Carlo são indicadas. O uso de simulação para resolver
problemas desse tipo não é novidade. Entretanto, persistem dois problemas que ainda
requerem investigação e novas abordagens: o tempo necessário para realizar simulações
envolvendo comparação de uma grande quantidade de alternativas e a variedade de modelos e
dados que podem ser usados, dependendo da situação particular de cada organização que
procura aplicar o método.
O primeiro problema é de grande complexidade já que, no limite, se tem um problema
combinatório em que a avaliação de cada alternativa é feita com a realização de inúmeras
rodadas de um programa de simulação, cada uma delas podendo exigir um grande tempo de
computação. Ao problema de explosão computacional de um problema combinatório, se soma
o problema de aumento da complexidade computacional para avaliação de cada alternativa.
Mesmo considerando a grande capacidade de processamento dos computadores atuais,
têm-se muito a ganhar com a divisão do trabalho entre vários computadores.
O segundo problema também acrescenta complexidade à solução, já que uma
ferramenta computacional, que possa ser usada por diversas instituições, ou por uma mesma
instituição em épocas diferentes, para resolver este tipo de problema, tem que ser muito
flexível para acomodar modelos e dados disponíveis em cada situação. Isto leva à idéia de
construir uma ferramenta de software que seja capaz de aceitar a introdução de novos
modelos e processos de cálculo e novos tipos de dados, não contemplados inicialmente na
modelagem do problema.
A implementação de um sistema de simulação expansível para ACCV, com o
aproveitamento de toda a capacidade computacional disponível, inclusive através da detecção
de pontos onde o paralelismo computacional encontra-se como uma alternativa viável,
possibilita o estudo de novos modelos de cálculo, permitindo aos pesquisadores testar estes
20
modelos em condições próximas às reais, com a utilização de dados estocásticos e um número

considerável de simulações.
A utilização de simulações maciças, com centenas ou milhares de ocorrências
simultâneas, permite experimentar todo um grande espectro de possibilidades e a utilização de
processo de Monte Carlo para a obtenção de resultados fidelísticos.
Como os problemas ligados à ACCV são de naturezas muito diferentes e os cenários
extremamente dinâmicos, torna-se necessário avaliar a melhor forma de implementar este
ferramental de cálculo, com vistas para o reuso.
A arquitetura de framework, onde é construída uma biblioteca de ferramentas
especialistas reutilizáveis pelos programadores, aliado a técnicas de programação focadas no
reuso de código, tais como orientação a objetos, elementos genéricos e anotações, e a
padronização proporcionada pelos padrões de desenvolvimento no uso de soluções, permite
uma utilização facilitada, dinâmica e plenamente adaptável deste ferramental por parte dos
desenvolvedores de soluções para ACCV.
O reuso é de extrema importância no desenvolvimento de softwares, não só por
diminuir o custo e o tempo para a definição de um novo sistema, mas também por aumentar a
qualidade com a utilização de componentes que centralizam a manutenção e podem ser mais
amplamente testados.
Hoje, no mercado, existem muitos sistemas computacionais para o cálculo do custo de
ciclo de vida. Porém os que puderam ser analisados não são expansíveis e não tiram proveito
do paralelismo e distribuição permitidos na computação atual, os quais podem aumentar a
velocidade de cálculo, permitindo a simulação de uma quantidade muito superior de cenários
e variações em curto período de tempo na busca de um ponto ótimo à luz da ACCV. Desta
forma, o desenvolvimento de um framework flexível e adaptável a qualquer contexto de
disponibilidade de dados, usados em modelos para estimar o custo de vida útil, oferece uma
solução inovadora e relevante pois libera o analista da necessidade de usar modelos pré-
definidos.
Os primeiros passos deste estudo foram realizados por Pilla (2003), ao definir um
modelo orientado a objetos para ACCV, modelo este que passou por uma evolução no
trabalho desenvolvido por Cople (2004), onde foi desenvolvida uma versão de framework
para ACCV.
Neste trabalho inicial foi comprovada a possibilidade de construção de uma ferramenta
expansível, focada em uma metodologia orientada a objetos, com expansão de suas
funcionalidades através de XML e reflexividade computacional.
21
O modelo genérico desenvolvido por Pilla e Cople se mostrou adequado à resolução

de problemas no domínio da ACCV, como pode ser observado em Cople (2004) e Cople e
Brick (2010), sendo utilizado este mesmo modelo na nova versão implementada.
No entanto, o framework inicial apresentava várias limitações, sendo consideradas as
mais críticas a impossibilidade (ou grande dificuldade) de criar interfaces customizáveis, a
ausência de metodologias e técnicas que permitissem o uso de outras bases tecnológicas além
de Java, a impossibilidade de exportação de dados para ferramentas de análise mais
completas, agravada por uma capacidade reduzida de análise de dados, a impossibilidade de
alterar a funcionalidade básica da geração de eventos (em particular para o processo de
manutenção), a execução individual de simulações, deixando de tirar proveito das
possibilidades do processamento distribuído e o acesso a dispositivos de entrada e saída, com
prejuízo do tempo despendido nas simulações.
Com a evolução das ferramentas computacionais para desenvolvimento, que passaram
a permitir o uso de técnicas de modelagem comportamental, surgiram novas possibilidades de
desenvolvimento que permitiram resolver os problemas identificados na primeira versão,
aumentar o formalismo na definição de tipos e ampliar o reuso com expansão da capacidade
de customização dos modelos para ACCV.
Adicionalmente, o processo de Engenharia de Sistemas vem sofrendo uma grande
evolução no sentido de integrar todo o ciclo de vida de sistemas técnicos, de uma forma
semelhante à que ocorreu com relação à gestão de cadeias produtivas, com o uso de
ferramentas conhecidas como Enterprise Resource Planning (ERP). Essa evolução traz a
necessidade de integração de todos os sistemas de Tecnologia de Informação (TI) utilizados
no desenvolvimento de sistemas técnicos, visando a redução de custos e o aumento da eficácia
de todo o processo de gestão do ciclo de vida desses sistemas. Isso gerou a necessidade de
adequar o framework a esse novo requisito de interoperabilidade.
Esta nova filosofia permite que o framework seja utilizado apenas com a tarefa à qual
se propõe, ou seja, execução das simulações e persistência de dados referentes às simulações,
enquanto ferramentas externas são utilizadas para a construção de interfaces cadastrais ou
análise de resultados.
As simulações continuam a operar de maneira seqüencial, devido às características das
simulações por eventos discretos, mas passaram a executar em grupos, de maneira simultânea
e distribuída, com a utilização de clientes de execução apropriados.
22
Os vários padrões arquiteturais para a construção de softwares foram analisados,

permitindo definir uma arquitetura composta para o novo framework, focada na formalização
e melhoria da persistência, distribuição de processamento e interoperabilidade.
Todas as técnicas aqui citadas, quando utilizadas em conjunto, vieram a permitir a
construção de uma ferramenta com alto nível de reuso e interoperabilidade, satisfazendo a
uma necessidade inerente ao contexto atual, ao permitir a definição e experimentação de
simulações no domínio da ACCV com baixo esforço de desenvolvimento e grande eficiência.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
Implementar um framework para análise de custo do ciclo de vida, baseado no modelo

conceitual desenvolvido por Pilla (2003) e revisado por Cople (2004), solucionando os
problemas e deficiências identificados na versão desenvolvida por Cople (2004), além de
expandir o nível de reuso e acrescentar características de interoperabilidade e paralelismo de
simulações.
1.2.2 Objetivos Específicos
Foram objetivos específicos deste trabalho:
1. Resolver os problemas encontrados no framework antigo;

2. Expandir o nível de reuso (customização) obtido com a versão anterior;
3. Incorporar técnicas de modelagem comportamental;
4. Desenvolver uma arquitetura de cálculo com processamento distribuído,
através de um núcleo de gerência de objetos remotos e clientes de execução; e
5. Desenvolver mecanismos de extensão e interoperabilidade, de forma a permitir
integração com outras plataformas e sistemas de TI. Em particular:
• Criação de interfaces customizadas com a utilização de qualquer
tecnologia compatível; e
• Extração de dados simulados em formato compatível com
ferramentas de análise de dados e apresentação gráfica.
23
1.3 JUSTIFICATIVA
Um sistema de engenharia complexo não pode ser vislumbrado de uma forma simples,
devendo ser planejado de forma adequada, pois mudanças estruturais durante a
operacionalização do mesmo são normalmente caras, quando não impossíveis.
A ACCV é uma disciplina que visa a estimativa dos custos inerentes à construção,
operacionalização e desativação do sistema, ou seja, a sua eficiência, levando a uma melhor
definição das mudanças necessárias, ainda na fase de projeto. Como subproduto, a ACCV
permite avaliar a disponibilidade operacional ou capacidade produtiva de sistemas técnicos
em ambientes operacionais e de apoio logístico complexos.
Nesta área existem softwares de apoio, porém os mesmos, além de não serem
expansíveis, não são adequados a plataformas distribuídas, deixando de tirar proveito das
possibilidades de processamento da Internet, entre outros.
O presente trabalho justifica-se pela necessidade de comprovar a possibilidade e a
utilidade de se criar um sistema computacional expansível que aborde um domínio de
problema específico (no caso a ACCV), com a possibilidade de expansão para novas áreas de
interesse da Engenharia de Sistemas e tenha características de interoperabilidade que
favoreçam a integração dos processos de gestão do ciclo de vida de sistemas técnicos.
Uma versão anterior do framework já havia sido desenvolvida por Cople (2004).
Entretanto ela tinha objetivos muito mais limitados e apresentou os seguintes problemas e
deficiências:
• Não era possível integrar o framework com outras tecnologias, tais como, as
voltadas para a construção de interfaces para usuários, ou outras ferramentas, como
as dedicadas à análise de grandes massas de dados;
• Não era possível integrar o framework com outros sistemas de TI para gestão do
ciclo de vida de sistemas técnicos;
• Análise de resultados deficiente;
• O modelo de geração de eventos não era customizável; e
• Não aproveitava as possibilidades do processamento distribuído.
Além disso, as ferramentas de desenvolvimento evoluíram muito desde 2004,

incorporando novas técnicas e metodologias de programação que não estavam disponíveis na
época da construção do framework original, particularmente sob o foco da modelagem
comportamental.
24
Elementos genéricos e anotações, por exemplo, começaram a ser utilizados pela

linguagem Java na versão 5, lançada ao final de setembro de 2004 e popularizada em 2005.
Na linguagem C# estes elementos vieram na versão 2, em novembro de 2005.
As novas possibilidades de implementação permitiram uma completa reestruturação
do framework, onde pontos frágeis detectados anteriormente foram corrigidos e a própria
forma de programar os pontos de flexibilização se tornou menos extensiva e mais formal.
Para satisfazer às necessidades de customização de interfaces cadastrais e apresentação
de resultados mais adequada, a interoperabilidade apresentou-se como uma boa estratégia,
delegando estas tarefas a ferramentas mais especializadas, como o Flex.
Isso, aliado à necessidade de se constituir uma arquitetura bem organizada para o novo
framework, de forma a viabilizar interoperabilidade e processamento paralelo, e fazendo com
que o mesmo constitua uma solução adequada para os fins aqui já descritos, justificam todo o
esforço contido neste trabalho.
1.4 DELIMITAÇÃO DO ESTUDO
Não foi objetivo deste trabalho a análise e comparação de modelos para ACCV, pois o
propósito principal do framework é justamente a capacidade de customizar modelos de
cálculo. Por este motivo, o Modelo de Pilla e Cople foi utilizado como padrão.
O modelo de simulação implementado foi por eventos discretos seqüenciais (Discrete
Event Simulation - DES), apenas com processamento paralelo de múltiplas simulações, assim
como as tarefas de I/O são efetuadas de forma paralela, mas não foi objetivo deste trabalho a
implementação de paralelismo interno no que concerne à geração de eventos durante a
simulação (Parallel Discrete Event Simulation - PDES).
Este trabalho não teve por objetivo o estudo e otimização de técnicas de distribuição
de processamento, mas tão somente incluiu a definição de uma arquitetura que tornou
possível efetuar a distribuição de processamento com a qualidade mínima necessária, isto no
intuito de demonstrar as vantagens desta distribuição em termos de tempo de execução e
refino de resultados.
Não foi feita a integração com High Level Architecture (HLA), ou outras integrações
independentes com ferramentas de gestão do ciclo de vida do sistema, pois trataria de um
trabalho muito mais abrangente, porém a criação de Web Services para acesso às
funcionalidades do framework, com a adoção de uma arquitetura orientada a serviços, permite
que qualquer destas integrações seja efetuada com relativa facilidade.
25
1.5 REFERENCIAL TEÓRICO
Este trabalho utilizou variados referenciais teóricos para que pudesse ser realizado,
pois ele é de natureza claramente interdisciplinar. Esses referenciais são resumidos a seguir.
No intuito de facilitar a leitura do documento por pessoas com diversas formações e
que possam não estar familiarizadas com partes do conhecimento utilizado para elaborar este
trabalho, algumas informações básicas e um pouco mais detalhadas sobre alguns desses
assuntos foram incluídas nos anexos A, B e C.
No capítulo 2 procurou-se mostrar o estado atual de conhecimento sobre esses
assuntos, enquanto que o tema de ACCV mereceu um capítulo especial (Capítulo 3) onde,
também, o Modelo de Pilla Cople é descrito com detalhes.
1.5.1 Análise de Custo de Ciclo de Vida
A análise do custo do ciclo de vida de sistemas apresenta-se como uma técnica

extremamente útil na avaliação da viabilidade e na otimização de sistemas complexos. Trata-
se, na verdade, de um conjunto de processos de cálculo ligados à estrutura do sistema, seu
desenvolvimento, fabricação, operação, manutenção, gastos com desativação, fatores
financeiros, ou qualquer outro elemento de custo abordado durante toda a vida útil do sistema.
Esta metodologia de cálculo leva também a uma definição otimizada da estrutura de
apoio logístico, e outros sistemas capacitadores tais como, simuladores para treinamento,
unidades fabris, necessários para o sistema principal, considerando tanto fatores geográficos,
quanto elementos operacionais e transporte.
Pilla (2003) mapeou a complexidade deste tipo de cálculo, gerando um modelo de
entidades lógicas à luz da teoria computacional da orientação a objetos, organizando uma
família de classes para suporte ao modelo genérico de cálculo de custo de ciclo de vida. Este
modelo tira proveito tanto de elementos de composição, permitindo agrupar cálculos já
definidos como em uma linha de produção, como da herança, que permite expandir o modelo
ao gerar novos algoritmos de cálculo.
Cople (2004) expandiu os conceitos de Pilla, adequando-os à implementação de um
framework construído com uso da linguagem Java, escolhida pelo seu suporte natural ao uso
de orientação a objetos e reflexividade.
26
Estes dois trabalhos e outros abordando o mesmo tema, como Borges (2004), fazem
parte de um projeto de pesquisa mais amplo (Logística Integrada), coordenado pelo Prof.
Eduardo Siqueira Brick.
Maiores detalhes sobre ACCV e o Modelo de Pilla e Cople podem ser obtidos no
Capítulo 3.
1.5.2 Simulação
Entender melhor um sistema nas mais diversas condições permite ao gestor otimizar a
produção de resultados, minimizar custos de manutenção, prever situações críticas e definir
normas de utilização nestes contextos, entre outras possibilidades. No entanto, apenas esperar
as condições de estudo ocorrerem, de forma a prover uma base estatística, poderia demandar
muito tempo, da mesma forma que criar os mais diversos cenários e condições necessárias
para um sistema em funcionamento poderia se tornar muito caro e arriscado, com razoável
possibilidade de perda de produção.
Levando em conta estes fatores, uma solução mais favorável para o estudo
comportamental seria a construção de um modelo idealizado, abstrato (modelo matemático)
ou físico, que permita a criação dos cenários e as análises necessárias com custo muito menor.
Para tratar problemas de alta complexidade, com grande participação de fatores
estocásticos, a simulação computacional apresenta-se como a alternativa adequada. As várias
formas de analisar um sistema podem ser observadas na Figura 1.
Sistema
Experimentos no Experimentos no
Sistema Físico Modelo do Sistema
Modelo Modelo
Físico Matemático
Solução
Analítica Simulação
Figura 1: Formas de estudo de um sistema.
Adaptado de Law e Kelton (2000 p.4)

27
Existem diversos tipos de simulação, mas o foco de estudo neste trabalho são as
simulações por eventos discretos (DES) e suas variantes com execução em paralelo (PDES).
Estas simulações são formalizadas em termos de modelos do tipo Discrete Event System
Specification (DEVS) e Parallel Discrete Event System Specification (PDEVS).
Simulações por eventos discretos são discutidas na Seção 2.2 e no Anexo C.
1.5.3 Reuso de Software
Segundo Krueger (1992 p.178), reuso de software é o processo pelo qual se utilizam
artefatos de software já existentes, ao invés de construí-los do zero. Tipicamente, a
reutilização envolve a seleção, especialização, e integração de artefatos, embora diferentes
técnicas de reutilização possam enfatizar ou desaprovar o uso de alguns destes.
A modelagem orientada a objetos representou um grande avanço em termos de reuso,
principalmente devido aos relacionamentos “todo-parte”, onde uma classe pode ser criada a
partir da combinação de outras, e “generalização-especialização”, onde uma nova classe pode
ser criada a partir de outra já existente, expandindo suas funcionalidades para a adequação a
novos contextos.
Apesar de toda a organização promovida pela orientação a objetos, suas vantagens em
termos de reuso podem não ser obtidas quando a técnica é mal utilizada. Neste contexto
surgem os padrões de desenvolvimento.
A idéia inicial dos padrões foi definida por Alexander, Ishikawa e Silverstein (1977),
ao dizerem que “cada padrão descreve um problema que ocorre de forma recorrente, e então
descreve o núcleo da solução para este problema, de tal forma que esta solução pode ser
utilizada um milhão de vezes, sem a necessidade de fazê-lo da mesma maneira duas vezes”.
Existem diferentes definições para padrões de desenvolvimento, mas a idéia básica é a
de que, se uma solução é modelada e aplicada a um determinado contexto, esta solução pode
ser generalizada e utilizada em contextos semelhantes.
Para Gamma, Helm, Johnson e Vlissides (1994 p.12), os padrões de desenvolvimento
visam facilitar a reutilização de projetos bem sucedidos e arquiteturas. Expressar técnicas
aprovadas pelo mercado como padrões de projeto torna este conhecimento mais acessível aos
desenvolvedores de novos sistemas.
28
Finalmente, as técnicas voltadas para a modelagem comportamental expandiram o

reuso da modelagem orientada a objetos original, englobando neste contexto o uso de
elementos genéricos e anotações.
Classes genéricas, também chamadas de templates, não definem necessariamente uma
tecnologia nova em termos de modelagem, sendo utilizada há bastante tempo na linguagem
C++. No entanto, apenas recentemente linguagens como Java e C# passaram a utilizar esta
técnica em larga escala.
Segundo Rumbaugh, Jacobson e Booch (2000 p.130), template é um elemento
parametrizado que pode definir uma família de classes ou uma família de funções,
apresentando espaços (slots) para classes, objetos e valores.
Um elemento genérico, em última análise, acaba por viabilizar a reutilização de
algoritmos e estruturas de dados, como no caso de filas, pilhas e árvores, absorvendo para si
toda a complexidade do comportamento existente no domínio comum, enquanto delega para
as classes que vierem a utilizá-lo apenas as configurações mínimas necessárias.
Anotações, por sua vez, tratam de metadados que podem ser associados a uma classe,
método ou propriedade, sem interferir com o código-fonte, porém permitindo o
reconhecimento dos mesmos por diversas ferramentas, o que viabiliza o reuso de processos de
natureza normalmente complexa, como automatização de persistência, sincronização de
processos paralelos, exposição de serviços, entre muitos outros.
As técnicas de reuso na programação são analisadas na Seção 2.3 e no Anexo A.
1.5.4 Arquitetura de Software
Segundo Bass, Clements e Kasman (2003 p.3), arquitetura de software de um

programa ou sistema computacional é a estrutura ou conjunto de estruturas do sistema, o que
compreende elementos de software, propriedades destes elementos com visibilidade externa, e
as relações entre eles.
A posição da arquitetura de software frente às etapas do desenvolvimento do sistema
pode ser observada na Figura 2.
29
Visão do usuário acerca do problema Modelo do Usuário

Visão de software acerca do problema Requisitos
Componentes e conexões Arquitetura
Algoritmos e estruturas de dados Codificação
Mapa de memória e layout dos dados Executável
Figura 2: Arquitetura de Software no Processo de Desenvolvimento
A definição da arquitetura de software irá determinar quais tipos de componentes

podem ser interados ao sistema, e como esta integração poderá ser efetuada, sendo comum o
uso da arquitetura em camadas denominada Model-View-Control (MVC), na qual ocorre a
divisão do sistema em três áreas de interesse, a saber:
• Persistência de dados, na camada Model;

• Regras de negócio, na camada Control; e
• Interfaces de visualização, na camada View.
A adoção desta arquitetura permite o uso de componentes especializados para acesso a

dados e controle transacional, gestores de fluxo de processos de negócio, entre muitos outros,
além de dividir a responsabilidade sobre a codificação do sistema entre profissionais
especializados para cada uma das três grandes áreas citadas.
Uma das estratégias para a criação desses componentes reutilizáveis é oferecê-los
segundo a arquitetura de framework, como ocorre com o Java Enterprise Edition (JEE),
voltado para processos de negócios, e o Java Persistence Architecture (JPA), o qual trata da
integração com as diferentes bases de dados.
A arquitetura de framework é particularmente interessante para a construção de
componentes reutilizáveis, pois o próprio conceito da arquitetura define um conjunto de
funcionalidades implementadas para a solução de problemas em um domínio específico, as
quais podem ser utilizadas através dos pontos de flexibilização (hot-spots) do framework.
Segundo Fiorini (2001 p.26), os frameworks têm atraído a atenção de muitos
pesquisadores e engenheiros de software e são aplicados a uma grande variedade de
30
domínios. As principais vantagens de frameworks incluem reutilização e redução do tempo

para disponibilizar aplicações no mercado.
Os frameworks da atualidade são, em sua grande maioria, orientados a objetos, isto
devido às características de extensibilidade e reuso proporcionadas por esta técnica de
programação, sendo também comum o uso de XML como elemento de integração, tanto
interna, em termos de configuração do uso de componentes e relacionamento entre os
mesmos, como externa, permitindo a interoperabilidade com outras plataformas.
Arquitetura de software e frameworks são discutidos na Seção 2.4 e no Anexo B.
1.5.5 Interoperabilidade
Outro ponto a se considerar é que os sistemas de informática estão evoluindo muito, e

várias soluções prontas incorporam processos complexos que podem ser disponibilizados para
novos desenvolvimentos. Para tal, os sistemas devem se comunicar com facilidade, segundo o
conceito de interoperabilidade.
Um sistema interoperável deve permitir acesso a suas funcionalidades segundo
padrões de comunicação abertos, aceitos pelo mercado, de forma a tornar transparente, ou
quase, o processo de integração.
Embora seja antigo o interesse da Engenharia de Sistemas pela interoperabilidade,
inicialmente ela só ocorria ao nível dos dados, com a definição de formatos e meios de
armazenamento comuns, mas os sistemas se tornaram mais complexos, novos padrões de
comunicação com o meio externo foram definidos, e a interoperabilidade evoluiu para o nível
de processos e serviços.
O interesse de empresas e órgãos governamentais pelo tema pode ser observado pelo
grande número de normas existentes, com o objetivo de trazer padronização aos elementos
envolvidos nas mais diversas fases do ciclo de vida dos sistemas.
Dentro desse enfoque, com o objetivo de viabilizar a interoperabilidade na área de
simulação, o Departamento de Defesa dos Estados Unidos definiu o padrão arquitetural
denominado High Level Architecture, ou simplesmente HLA, o qual permite a integração de
diversos simuladores e sistemas de apoio para a execução de complexas simulações
distribuídas.
A principal estratégia de interoperabilidade atual para os sistemas computacionais é a
criação de Web Services, dentro de uma arquitetura orientada para serviços, estratégia esta
31
utilizada na concepção do novo modelo do framework, viabilizando que ferramentas como

Flex, Delphi e Visual C# passem a tirar proveito do núcleo de cálculo, criando interfaces
próprias para problemas específicos dentro do domínio, além de relatórios personalizados.
Da mesma forma, a definição dos acessos aos processos de execução de simulações
através de Web Services faz com que a integração em um ambiente HLA, também voltado
para a interoperabilidade de serviços, torne-se uma tarefa mais simples.
Interoperabilidade é discutida na Seção 2.5 e no Anexo B.
1.5.6 Processamento Distribuído
A utilização de processamentos paralelos traz vantagens tanto no uso de apenas um

processador, quando há muitas operações de I/O, quanto com a utilização de vários
processadores, quando há uma massificação do processamento.
Dentro deste enfoque surgem novos problemas, como a sincronização entre tarefas
paralelas e a totalização parcial de dados, o que exige o agrupamento das tarefas
independentes em sub-grupos que possam ser totalizados, quando necessário. Várias são as
dificuldades enfrentadas pelos analistas que se aventuram nesta área, sendo muito comum
ocorrer um travamento quando algum detalhe não é detectado.
Segundo Sedgewick (1988 p. 570), um ponto comum ao se considerar o paralelismo é
o de que se deve efetuar o máximo de tarefas diferentes simultaneamente, o que pode levar a
problemas de sincronismo, se não for organizado de maneira adequada.
Para Rumbaugh, Jacobson e Booch (2000 p.313), o problema de sincronização surge
quando mais de um fluxo de controle opera sobre um único elemento simultaneamente. Se
não houver o cuidado adequado, um fluxo interferirá com o outro, corrompendo o estado
deste elemento.
Da mesma forma que no processamento paralelo, quando é efetuada a distribuição de
processamento entre várias máquinas são obtidas vantagens no uso de recursos em paralelo,
mas ocorrem também problemas de sincronia, além dos possíveis atrasos devido às
velocidades de transmissão das redes.
Nem tudo pode ser encarado como ganho em termos de sistemas paralelos e
distribuídos. Existe uma perda com a troca de contexto e com a transmissão em rede, além do
fato de que uma tarefa muito longa, com outras tarefas dependentes, pode anular os ganhos
naquele nível de processamento.
32
Existem várias tecnologias para distribuição de processamento, podendo trabalhar

tanto com grupos de servidores, como ocorre com chamadas de procedimentos remotos, ou
Remote Procedure Call (RPC), objetos distribuídos e serviços distribuídos, quanto através de
clientes especializados, com uso de sockets comuns e redes Peer-to-Peer (P2P).
Como os sistemas de simulação costumam ser utilizados na resolução de problemas
complexos de natureza estocástica, a quantidade de cálculos envolvida justifica o esforço no
sentido de detectar tarefas independentes que possam ser executadas em paralelo ou
distribuídas entre os computadores disponíveis.
Maiores detalhes sobre processamento distribuído podem ser obtidos na Seção 2.6.
1.6 ESTRUTURA DO TRABALHO
Este trabalho está estruturado da forma que se segue.

Neste Capítulo 1 é feita uma introdução do problema abordado, apresentados os
objetivos gerais e específicos de estudo e a justificativa para sua elaboração, bem como suas
limitações e referencial teórico necessário.
Uma revisão bibliográfica é apresentada no Capítulo 2, abrangendo a maior parte do
referencial teórico, enquanto o Capítulo 3 apresenta uma revisão bibliográfica sobre ACCV
bem como o modelo usado no framework, denominado Modelo de Pilla-Cople.
Aspectos arquiteturais são observados no Capítulo 4, o qual descreve a estrutura e
extensão do framework de ACCV.
No Capítulo 5 é demonstrado como o framework pode ser usado para gerar simulações
e analisar os resultados, enquanto no Capítulo 6 são descritas as características de
interoperabilidade e como o framework pode ser extendido.
Finalmente no Capítulo 7 são apresentadas as conclusões e sugestões de trabalhos
futuros.
Algum material de apoio, para a compreensão das múltiplas áreas envolvidas por
diferentes leitores é fornecido nos anexos A, B e C.
O caso de teste usado para demonstrar o uso do framework está descrito no anexo D.
33
2. SIMULAÇÕES COMPUTACIONAIS, REUSO E INTEROPERABILIDADE
2.1 INTRODUÇÃO
Este trabalho, apesar de tratar de um domínio de problema específico (Análise de

Custo de Ciclo de Vida), é de natureza interdisciplinar, envolvendo inúmeras áreas de
conhecimento e trouxe contribuições, de importância variada, a cada uma dessas áreas. Por
esse motivo, um levantamento bibliográfico sobre os mais recentes desenvolvimentos sobre o
assunto teria que ser necessariamente amplo, por ter que cobrir, com maior ou menor
profundidade, esses variados campos de conhecimento.
O tema central (ACCV) mereceu um tratamento especial no capítulo que se segue,
onde o modelo geral usado na construção do framework também é descrito com maiores
detalhes.
Este capítulo trata do levantamento que foi feito do estado atual dos conhecimentos
sobre reuso, interoperabilidade e frameworks de simulação em geral e, também daqueles
conhecimentos que pudessem ser úteis para delinear a construção do novo framework de
ACCV e situá-lo à luz do estado da arte nas múltiplas disciplinas envolvidas.
Inicialmente é feita uma classificação dos simuladores por eventos discretos e o
formalismo utilizado, bem como as possibilidades de paralelismo observadas.
Objetivando um ambiente flexível para a construção do framework de ACCV, são
analisadas técnicas de reuso no que se refere ao estilo de programação, arquitetura do sistema
e interoperabilidade.
Finalmente, as técnicas de distribuição de processamento utilizadas na área de
simulação são analisadas, de forma a definir qual a melhor abordagem para a execução dos
cálculos seqüenciais envolvidos na ACCV.
34
2.2 SIMULAÇÕES POR EVENTOS DISCRETOS
A simulação por eventos discretos, ou Discrete Event Simulation (DES), representa

um ferramental consolidado e robusto para a resolução de problemas dinâmicos, que
permitam uma modelagem em termos de fenômenos pontuais, cujos momentos de ocorrência
possam ser estimados.
O modelo denominado Discrete Event System Specification (DEVS) foi criado por
Zeigler (1976) com o objetivo de descrever sistemas de simulação por eventos discretos,
sendo a notação amplamente utilizada até os dias atuais, segundo a seguinte representação
para o modelo atômico:
M = < X, S, Y, δint, δext, λ, ta >
X: Um conjunto de eventos externos, ou eventos de entrada.

S: Um conjunto de estados seqüenciais.
Y: Um conjunto de eventos de saída.
δint: S → S: Função de transição interna.
δext: Q × X → S: Função de transição externa.
λ: S → Y: Função de saída.
ta: S → R0→∞: Função de avanço no tempo.
Q = {(s,e) | s ϵ S, 0 ≤ e ≤ ta(s)}
Quando são tratados sistemas compostos de componentes interconectados, o modelo a

ser utilizado é denominado Coupled DEVS (CDEVS), ou DEVS com acoplamento, o qual
segue a seguinte notação:
CM = < X, Y, D, {Mi}, {Ii}, {Zi,j} >

D: Conjunto de componentes do sistema.
{Mi}: Modelo DEVS para cada componente (atômico ou acoplado).
{Ii}: Conjunto de influências do componente, caracterizado em Y.
{Zi,j}: Conexão entre a saída de Mi e a entrada em Mj para cada Ii.
35
Lee e Chi (2005) apresentam alguns exemplos simples de modelos DEVS e CDEVS,
os quais constituem a base de complexos controles de tráfego, com a adição de elementos
estocásticos e fatores externos.
Uma forma alternativa para expressar o CDEVS, exemplificada na Figura 3, segue a
seguinte notação:
CM = < X, Y, D, {Md | d ϵ D}, EIC, EOC, IC >

{Md}: Modelo DEVS para cada componente (atômico ou acoplado).
EIC: External Input Coupling representa o conjunto de conexões entre eventos
externos e entradas do componente.
EOC: External Output Coupling representa o conjunto de conexões entre as saídas do
componente e as saídas externas.
IC: Internal Coupling representa o conjunto de conexões entre as saídas de cada
componente e as entradas de outros componentes.
Figura 3: Componente com acoplamento.
Fonte: Furfaro e Nigro (2009 p.119)
O modelo CDEVS é amplamente utilizado nos sistemas de simulação, como pode ser
observado nos trabalhos de Fumarola, Seck e Verbraec (2010), Park, Park e Wang (2008),
Zia, Mustafiz, Vangheluwe e Kienzle (2007), Seo (2006), Capocchi, Bernardi, Federici e
Bisgambiglia (2006), além de servir de base para a definição de outros formalismos
derivados, tais como o Cell-DEVS.
36
A variante do DEVS denominada Cell-DEVS foi criada para a análise de espaços

celulares executáveis interdependentes, ou autômatos celulares. Estas células executam
rotinas internas que mudam seus estados de forma independente, mas o resultado da execução
destas rotinas acaba por impactar as células vizinhas, podendo ser utilizadas para modelar
problemas em diversas áreas de interesse, como controle de tráfego, incêndios florestais,
avanço de endemias em determinada região, entre muitas outras aplicações possíveis.
Segundo Wainer e Giambiasi (2001), as células são definidas a partir de modelos
atômicos, os quais apresentam fronteiras com portas de entrada e saída, sendo acopladas
posteriormente para constituir um espaço completo, composto de células atômicas conectadas
através de suas relações fronteiriças, o que pode ser observado, segundo uma interpretação
informal, na Figura 4.
Figura 4: Interpretação informal do Cell-DEVS.
Adpatado de Wainer (2004 p.50)
O modelo Cell-DEVS pode ser encontrado em muitos trabalhos, abrangendo as mais

diversas áreas, como em Holman, Kuzub e Wainer (2010), Koutitas, Pavlidou e Jankovic
(2010), Qela, Wainer e Mouftah (2009), Choi, Lee e Kang (2008), Goldstein e Wainer (2008),
Wainer (2006), Wainer e Giambiasi (2005), Ntaimo e Zeigler (2004).
O modelo DEVS era voltado apenas para simulações individuais e seqüenciais, mas
foi expandido posteriormente para as simulações por eventos discretos paralelas, ou Parallel
Discrete Event Simulation (PDES), sendo denominado neste novo contexto como Parallel
Discrete Event System Specification (PDEVS).
37
Apresentado por Chow e Zeigler (1994), o modelo PDEVS diferencia-se dos

anteriores pela presença de uma função de confluência, a qual permite a declaração da
fronteira de colisão de forma explícita, como pode ser observado na seguinte notação:
PM = < XM, YM, S, δext, δint, δcon, λ, ta >
XM = {(p,v) | p ϵ IPorts, v ϵ XP }: Um conjunto de portas de entrada e valores.

YM = {(p,v) | p ϵ OPorts, v ϵ YP }: Um conjunto de portas de saída e valores.
δext: Q × XM → S: Função de transição externa.
δcon: Q × XM → S: Função de transição confluente.
Q = {(s,e) | s ϵ S, 0 ≤ e ≤ ta(s)}
Ziegler e Sarjoughian (2003 p. 36) ressaltam três pontos principais ao diferenciar o

PDEVS do DEVS:
• Portas são representadas explicitamente, podendo ser qualquer tipo de porta capaz
de enviar e receber valores;
• Ao invés de receber uma entrada simples ou fornecer uma saída simples, o modelo
paralelo trabalha com pacotes de valores; e
• Foi adicionada a função de transição confluente δcon. Esta função decide qual o
próximo estado no caso de colisão entre eventos externos e internos.
Conforme citado por Hagendorf (2009), o modelo PDEVS permite que todos os
componentes na iminência de serem ativados enviem seus sinais de saída para outros
componentes concorrentemente, sendo múltiplas saídas combinadas em um pacote que é
processado por uma função de transição externa. Este pacote é similar a um conjunto,
contendo um grupo desordenado de elementos, mas permite múltiplas ocorrências de um
mesmo elemento.
38
Segundo HimmelSpach e Uhrmacher (2006), modelos PDEVS, são ao mesmo tempo,

modelos atômicos, que são calculados pelos simuladores, e modelos acoplados, compostos de
outros modelos (acoplados ou atômicos), que são implementados como coordenadores ou
controladores, como pode ser observado na Figura 5.
Figura 5: Mapeamento da Árvore Abstrata de Threads de Simulação.
Fonte: HimmelSpach e Uhrmacher (2006)
O modelo PDEVS organiza a estrutura funcional da simulação com a divisão em

modelos de geração seqüenciais (DEVS) atomizados e acoplados, com o objetivo de resolver
parte do problema principal de forma independente, sendo suas respostas combinadas
hierarquicamente para obter a solução completa. Esta abordagem não promove o paralelismo
interno, mas permite a execução em paralelo de módulos independentes, garantindo a
integridade da solução através da estrutura hierárquica de controle.
A utilização do modelo PDEVS pode ser observada em Sanz, Urquia, Cellier e
Dormido (2010), Schwatinski e Pawletta (2010), Röhl e Uhrmacher (2008), Klan, Röhl,
König-Ries e Uhrmacher (2008), Han e Huang (2007), Cicirelli, Furfaro e Nigro (2007).
39
2.3 TÉCNICAS DE REUSO NO DESENVOLVIMENTO DE SOFTWARE
A criação de softwares de simulação, devido às características diferenciadas para cada

cenário de análise, requer técnicas de programação que facilitem o reuso de componentes e
modelos de simulação.
Nesse âmbito, o foco de análise mais básico se refere à modelagem do sistema
segundo o paradigma orientado a objetos, o qual visa organizar a forma de programar,
aumentando o reuso através de herança e composição.
Pulecchi, Casella e Lovera (2010) descreveram o a utilização de um framework
baseado em linguagem orientada a objetos, no caso a linguagem Modelica, com o objetivo de
criar um modelo de simulação flexível para a modelagem da dinâmica aeroespacial, citando
entre os requisitos atendidos por esta abordagem:
• Desenvolvimento rápido, teste e integração de novos ambientes;

• Suporte e gerência de configurações variadas;
• Reuso e customização de modelos; e
• Garantia de visibilidade nos modelos e variáveis de estado.
Seguindo a mesma linha, Garrido, Zafra e Vázquez (2009), utilizando outra ferramenta
baseada em objetos (EcosimPro), construíram uma biblioteca de simulação de usinas
hidrelétricas, demonstrando a flexibilidade permitida pela modelagem orientada a objetos, ao
permitir múltiplas configurações com a criação de classes mais complexas a partir da conexão
de componentes atomizados do domínio do problema, ressaltando ainda o reuso propiciado
pela criação de classes.
Estes são apenas dois exemplos de autores que exploraram as possibilidades de reuso
da orientação a objetos na construção de simuladores. No entanto, apesar de toda a
organização e reuso propiciados pela orientação a objetos ter modificado a forma de
concepção dos sistemas contemporâneos, a simples adoção de uma boa metodologia de
modelagem não garante a implementação de um bom projeto.
Os padrões de desenvolvimento surgiram com o objetivo de organizar e formalizar
grande parte do conhecimento obtido na construção de sistemas diversos, definindo soluções
reutilizáveis genéricas, as quais devem ser adaptadas e combinadas para a criação de novos
40
sistemas. Este tipo de reutilização encontra-se em um nível mais estratégico que a simples
metodologia de modelagem da orientação a objetos.
Como definido por Czibula e Czibula (2008 p. 347), o tópico padrões de
desenvolvimento é um clássico moderno na literatura da orientação a objetos, oferecendo
soluções ágeis e elegantes para problemas comuns no desenvolvimento de software. São
descritos padrões para gerenciar a criação de objetos, composição de objetos em estruturas
complexas, e coordenação do fluxo de controle entre objetos.
Para Rypáček, Backhouse e Nilsson (2006 p.13), um padrão de desenvolvimento
representa uma solução preparada para um problema de projeto comum que está facilmente
disponível para os programadores. Além de sua utilidade na fase de codificação, padrões de
desenvolvimento servem também um papel importante na construção de software, descrição
de documentação e comunicação, e, como resultado, tornaram-se bem estabelecidos na prática
de desenvolvimento de software orientado a objeto. Os autores criticam, no entanto, a
ausência de um formalismo mais rigoroso na descrição dos padrões pela literatura.
Segundo Dong, Peng e Zhao (2010 p.1), para usar um padrão de desenvolvimento em
uma aplicação específica é necessário instanciá-lo com as informações de domínio do
aplicativo. Este processo de instanciação pode mudar os nomes genéricos das classes
participantes para refletir as características da aplicação, ou até mesmo a quantidade de
participantes. Entretanto, ainda segundo o autor, tais mudanças não são arbitrárias e têm de
respeitar as limitações do padrão de desenvolvimento.
O uso de padrões de desenvolvimento na área de simulação pode ser observado em
diversos trabalhos como, por exemplo, Wang, Yuan e Li (2010), Zheng, Zheng, He e Han
(2009), Liu, Huang e Han (2009), Breit et al. (2008), Capocchi, Bernardi, Federici e
Bisgambiglia (2006), Chang e Lee (2005), Gustavson, Morse, Lutz e Reichenthal (2004),
Nguyen, Ricken e Wong (2004).
Particularmente, no trabalho de Hamri e Baati (2010), é sugerido um conjunto de
padrões de desenvolvimento para a implementação de DEVS. Entre os padrões citados pelo
autor encontram-se:
• State, associado à execução do modelo DEVS, seja atomizado ou acoplado;

• Abstract Factory, o qual deve ser especializado para a o fornecimento de
executores de simulações específicos; e
• Observer e Composite, utilizados em conjunto para a coordenação das ações de
toda a hierarquia de modelos acoplados.
41
A Figura 6 apresenta a modelagem UML para o padrão de desenvolvimento State,

aplicado à criação de um executor DEVS genérico.
Figura 6: Padrão State para DEVS atomizado expresso em UML.
Fonte: Hamri e Baati (2010 p.6)
Em termos do esforço de desenvolvimento necessário, as técnicas de modelagem

comportamental, envolvendo principalmente o uso de elementos genéricos e anotações,
permitiram a criação de estruturas e processos genéricos reutilizáveis, diminuindo muito o
tamanho do código final produzido.
Segundo Chen e Xu (2009 p.305), programação genérica fornece alta capacidade de
reutilização através da parametrização de tipos de dados e funções. Também definida como
programação com conceitos, o objetivo principal da programação genérica é o de expressar
algoritmos e estruturas de dados em uma forma interoperável e amplamente adaptável via
conceitos.
Para Garcia et al. (2007), em linguagens como Java e C#, apesar da adição de suporte
à programação genérica, as técnicas de programação orientada a objetos ainda são o
mecanismo primário para a construção de abstrações, sendo os elementos genéricos utilizados
para a construção de bibliotecas de algoritmos reutilizáveis.
42
Embora a adoção de elementos genéricos pelas linguagens Java e C# tenha ocorrido

há pouco tempo, qualquer nova biblioteca ou framework aproveita-se das características de
reuso proporcionadas. Um exemplo simples foi a reestruturação completa da biblioteca de
classes para coleções em ambas as linguagens.
Quanto às anotações, elas não interferem nas abstrações utilizadas pelo sistema, mas
cumprem com o objetivo de reutilizar processos complexos externos a partir dos metadados
anexados ao código.
Nigul e Mah (2009 p. 417) citam que anotar o código fornece aos programadores
diversas vantagens, tais como: a capacidade de combinar metadados úteis com código real,
separar as preocupações entre codificação e algum domínio da semântica específica, e
permitir a reutilização mais fácil das funcionalidades existentes e do código.
O formalismo e reuso proporcionados pelas anotações fez com que grande parte das
ferramentas existentes no mercado migrasse para este estilo de integração e configuração, o
que pode ser observado nas novas versões de praticamente todos os frameworks mais
utilizados na produção de visualizações na Web pela linguagem Java, tais como Spring, Java
Server Faces e Struts.
2.4 ARQUITETURAS VOLTADAS PARA O REUSO
Robinson et al. (2004) abordaram o problema de reutilização de modelos de simulação

e chegaram a conclusões conflitantes. Eles criaram o espectro de reutilização de software
como: reutilização do modelo completo, reutilização de componentes, reutilização de funções
e clareza do código. Estes tipos de reutilização são ordenados em ordem crescente, de acordo
com a freqüência de uso e critérios, e por ordem decrescente, de acordo com os critérios de
complexidade. A conclusão a que chegaram é que, embora a reutilização de modelos seja
atraente, supostamente para reduções de custo e tempo de desenvolvimento, há uma série de
questões que podem impedir que essas vantagens sejam obtidas. Eles mencionam
explicitamente validade e credibilidade do modelo, e o custo e tempo para a familiarização,
como exemplos de tais questões. Outra conclusão é que a reutilização implica uma arquitetura
de software que a suporte.
Para Mannisto, Savolainen e Myllarniemi (2008 p.117), as características de um
problema grave podem ser relacionadas com a concepção de uma arquitetura de software,
pois não há formulação definitiva, não existe uma regra de parada indicando claramente
quando a solução foi encontrada, as soluções não são verdadeiras ou falsas, mas simplesmente
43
boas ou ruins, e finalmente, cada problema pode ser considerado como um sintoma de outro
problema. Ainda segundo os autores, arquitetura de software não é uma disciplina isolada, e
as decisões são construídas em parte pela adaptação de soluções para problemas encontrados
em outros lugares.
Gardazi e Shahid (2009 p.402) alertam que as empresas não devem subestimar a
importância do arquiteto de software. Isto se deve ao fato de que uma arquitetura adequada é
crucial para a correta implementação de todas as funcionalidades do sistema, além do que a
adoção de arquiteturas padronizadas facilita a manutenção e utilização de ferramentas de
produtividade.
A organização de um software em termos arquiteturais é uma decisão que irá interferir
em todas as fases de concepção e implementação do sistema, definindo os tipos de
componentes que poderão ser utilizados, como estes componentes deverão ser integrados,
além da forma como este sistema poderá interagir com usuários, recursos externos, serviços e
outros sistemas.
A arquitetura Model-View-Control (MVC) é uma das mais adotadas na definição de
sistemas da atualidade, caracterizando-se por dividir o aplicativo em três camadas:
• Modelo (Model), referente à camada de persistência;

• Visualização (View), responsável pela interação com o usuário; e
• Controle (Control), a qual detém as regras de negócio e faz a intermediação de
todas as solicitações efetuadas entre a visualização e o modelo.
Para Dalle, Ribault e Himmelspach (2009 p.947), o padrão MVC pode ser usado na
simulação para descrever a dependência entre uma visualização em tempo de execução
(interativa), o modelo executável, e o algoritmo de simulação, permitindo, por exemplo,
diferentes visualizações simultâneas sobre o modelo a ser criado.
Sridaran, Padmavathi, Iyakutti e Mani (2009 p.64), citam as seguintes vantagens na
adoção da arquitetura MVC:
• Múltiplas visões do mesmo modelo podem ser utilizadas simultaneamente, e novas

visões podem ser criadas a qualquer tempo;
• Impede o acoplamento forte entre os objetos, o que aumenta a reutilização das
classes ao diminuir as dependências das mesmas;
44
• A aparência dos aplicativos pode ser modificada sem alterações na lógica de

negócios ou nos dados;
• Diferentes interfaces e níveis de utilização podem ser mantidos pelo mesmo
aplicativo;
• A aplicação inteira pode ser construída ou gerenciada independentemente por
equipes distintas;
• Apresenta a solução ideal para manter um ambiente composto de diferentes
tecnologias em locais diferentes; e
• Promove escalabilidade e facilidade de manutenção.
Na área de simulação vários autores defendem a adoção da arquitetura MVC, tais

como Bonaventura, Wainer e Castro (2010), Kounev e Dutz (2009), Islam e Piasecki (2008),
Rinaldi, Dalponte, Vénere e Clausse (2007), Rodriguez, Hilaire e Koukam (2007), sempre
defendendo a divisão entre modelo de simulação, motor de cálculo e interface de visualização.
O uso de MVC se tornou tão difundido que Nutaro e Hammonds (2004) propuseram
uma arquitetura denominada Model-Simulator-View-Control (MSVC), a qual define uma
extensão do MVC na qual o simulador é tratado em uma camada específica, promovendo o
reuso do software de simulação, adição facilitada de visualizações e ferramentas de
acompanhamento, encapsulamento das mudanças de protocolo apenas ao nível das camadas
de controle e visualização, além do tratamento individualizado de modelo, simulação,
distribuição ou paralelismo, e interfaces de usuário.
Outro foco de interesse no estudo das formas de reuso são os componentes do tipo
Commercial Off-The-Shelf (COTS), que tratam de componentes comerciais reutilizáveis,
testados e aceitos pelo mercado, e integráveis com relativa facilidade.
Mesmo que um COTS apresente meios de integração padronizados, esta integração
acrescenta complexidade ao sistema. Para Egyed e Balzer (2006 p. 42) este aumento de
complexidade reside no desafio de como viabilizar o uso de COTS que podem efetuar
mudanças internas (dados ou estados) quando estas mudanças afetam o sistema como um
todo, ou seja, o principal problema de integração é adequar o comportamento do COTS sem
alterar o componente em si.
Segundo Mohamed, Ruhe e Eberlein (2008 p. 147), este problema de integração
ocorre porque componentes COTS são produtos comerciais, voltados para uma utilização
mais ampla, enquanto requisitos de projeto são específicos para o sistema. Conseqüentemente,
45
os desenvolvedores escolhem quais componentes são mais eficazes para a resolução dos
requisitos e, em seguida, tentam resolver o maior número de inadequações mediante
adaptação dos selecionadas, o que leva a uma metodologia de escolha onde devem ser
considerados o custo de adaptação e a eficácia de cada COTS.
O conceito de COTS não é novo, sendo amplamente utilizado em setores industriais
como eletrônicos, telefonia, e automotivo, entre outros, e acabou por se demonstrar essencial
na concepção dos atuais sistemas computacionais, levando em consideração a complexidade
destes sistemas, fatores ligados a interoperabilidade, e necessidade de padronização entre
diferentes equipes de desenvolvimento.
Em termos de software, a divisão em camadas do MVC permitiu a criação de
ferramentas COTS voltadas para a resolução de problemas genéricos em cada um dos três
níveis, viabilizando a rápida combinação destas ferramentas no processo de construção do
aplicativo, o que diminui o tempo e o custo de desenvolvimento, além de aumentar a
qualidade final dos sistemas produzidos.
Hoje em dia ocorre uma preocupação muito grande acerca da escolha dos COTS
adequados, levando em conta fatores como confiabilidade, manutenibilidade, eficiência,
eficácia e longevidade do componente. Trabalhos de autores como Jha, Arora, Kapur e Kumar
(2010), Gupta, Mehalawat e Verma (2010), Wanyama e Far (2008), demonstram esta
preocupação na escolha de COTS, ao definirem metodologias diversas para este fim.
Particularmente quanto à longevidade do componente, existem preocupações acerca da
freqüência de reposição devido à obsolescência, devendo ser levado em conta a existência de
similares e o custo efetivo para substituição no decorrer do ciclo de vida do sistema, como
pode ser observado no trabalho de Concho, Ramirez-Marques e Herald (2009), onde é
definido um modelo para o planejamento da evolução do sistema com o objetivo de
minimizar os custos, baseado na análise do ciclo de vida individual de componentes COTS
com funcionalidades similares.
Os vários frameworks disponibilizados no mercado de software, como o Java
Enterprise Edition (JEE) e o Java Persistence Architecture (JPA), são bons exemplos de
componentes do tipo COTS. Cada framework resolve apenas um domínio específico, como
persistência, controle de serviços transacionais, apresentação visual, etc, e os desenvolvedores
precisam saber como combiná-los na concepção de um novo sistema. É importante conhecer
também a aceitação do framework pelo mercado, pois isto irá definir sua longevidade e
manutenibilidade.
46
Um framework é constituído de um grupo de ferramentas genéricas que podem ser

utilizadas na resolução de problemas de um domínio específico, podendo ser implementado
de diversas formas, mas sendo a abordagem orientada a objetos preferida pelos
desenvolvedores da atualidade.
Frameworks diferem de aplicações comuns, pois dependem de outros aplicativos que
os utilizem, complementando as informações necessárias ao seu funcionamento em uma etapa
chamada instanciação.
Segundo Horstmann (2007 p. 312), em um framework ocorre inversão de controle, o
que significa que as classes do framework e não as classes da aplicação são responsáveis pelo
controle do fluxo da aplicação. O autor também defende a idéia de construir frameworks
orientados a objetos ao definir um framework como um conjunto de classes cooperativas que
implementam os mecanismos essenciais para um domínio de problemas específicos, ou
também, um conjunto de classes e interfaces que estruturam o mecanismo essencial de um
domínio em particular.
Conforme citado por Cople e Brick (2010 p.12), um programador que utiliza um
framework não precisa conhecer a estrutura interna, mas apenas saber como requisitar os
serviços fornecidos. Em termos de orientação a objetos, frameworks são constituídos de
classes abstratas, mas podem utilizar outros tipos de recursos, tais como protocolos de rede ou
comunicação direta entre processos.
Com estas características, a arquitetura de framework é plenamente voltada para o
reuso, até pelo simples fato de que não pode ser utilizada sem que o framework seja integrado
a um sistema, e vários softwares acabam por definir suas arquiteturas a partir da escolha dos
frameworks a serem integrados.
O framework comercial JEE pode ser interpretado como uma arquitetura Broker,
voltada para a gestão de objetos distribuídos, baseada em componentes denominados
Enterprise Java Beans (EJB), que concentra as regras de negócio de sistemas corporativos
Java e é facilmente integrável à arquitetura MVC, apresentando várias versões em uso no
mercado, mas destacando-se a versão 2 (J2EE) e a versão 5 (JEE5).
Conforme citado por Jordan (2004 p.12), o framework J2EE é muito complexo, e o
desenvolvimento de um componente EJB envolve a criação de pelo menos duas interfaces,
denominadas home e remote, além de uma classe denominada bean, que implementa as duas
interfaces.
47
Na verdade, os beans são disponibilizados em um pool, segundo o padrão Flyweight,

sendo o acesso do cliente a este pool efetuado a partir da interface remote, adotado o padrão
Proxy, diretamente relacionado à arquitetura Broker. Como a interface home é responsável
pelo processo de criação das interfaces remote, também é utilizado o padrão de fábrica
denominado Abstract Factory / Concrete Factory.
Em termos de utilização prática, como o Session Bean normalmente encontra-se entre
o cliente e a camada de persistência, representada pelo Entity Bean no J2EE, este acaba por
determinar a criação de um padrão do tipo Session Facade. Neste caso, o padrão Proxy não
precisa ser utilizado entre os dois tipos de EJBs devido ao acesso local (dentro do mesmo
container), mas o padrão de fábrica ainda é utilizado, agora com a criação de interfaces locais.
Como a localização das fábricas é feita através de Java Naming and Directory
Interface (JNDI), normalmente os aplicativos cliente utilizam o padrão Service Locator,
encapsulando toda a complexidade destas chamadas. Todo este conjunto de padrões pode ser
observado na Figura 7.
Figura 7: Padrões de Desenvolvimento presentes no J2EE

48
Como o JEE5 é bastante recente, grande parte do material encontrado na literatura

sobre o uso de JEE nos sistemas de simulação da atualidade se refere ao J2EE, como pode ser
observado em Yao, Zhang e Duan (2010), Yuan e Zhang (2010), He, Liu, Liu e He (2010),
Lim et al. (2009), Garrels, Jürgens, Schmidtmann e von Cölln (2007).
No JEE5 foi adotado um estilo de programação baseado em anotações e elementos
genéricos, o que facilita o reuso e diminui o esforço de programação, sendo também
substituído o Entity Bean, que sempre foi considerado ineficiente, por um framework de
persistência denominado Java Persistence Architecture (JPA).
Com isto, para os sistemas corporativos Java da atualidade, a arquitetura MVC
trabalha por padrão com o JEE5 na camada de controle e com o JPA na camada de
persistência, ficando a camada de visualização livre para o uso de qualquer outro COTS que
se adéqüe.
Para Caldeweyher, Pham e Zhang (2007), a utilização de JEE5, embora obrigue um
maior nível de abstração no projeto, traz vantagens como a possibilidade de utilizar
computação distribuída mais sofisticada e a integração facilitada com ferramentas de terceiros
voltadas para a Internet.
Quanto ao JPA, este é um framework que facilita muito a comunicação com banco de
dados ao utilizar anotações para efetuar o mapeamento objeto-relacional, trazendo como
vantagens a utilização de objetos simples para a representação dos dados e portabilidade na
comunicação com os mais diversos bancos de dados.
Segundo Burke e Monson-Haefel (2007 p.58), os objetos denominados entidades
representam dados no banco de dados, assim, alterações em um bean de entidade resultam em
alterações no registro do banco. Ainda segundo o autor, representar os dados como beans de
entidade pode tornar o desenvolvimento mais simples e econômico.
Feito o mapeamento entre o banco de dados os beans de entidades, as alterações
efetuadas sobre os objetos irão refletir diretamente nas tabelas do banco, por intermédio de
um contexto de persistência. Mesmo as consultas são efetuadas através de uma linguagem
própria, Java Persistence Architecture Query Language (JP-QL), mantendo a programação
sempre ao nível do código Java.
Segundo Jendrock et al. (2008 p. 735), a JP-QL define consultas a entidades e seus
estados de persistência. Esta linguagem de consulta permite a escrita de consultas portáveis,
que trabalham independentemente do meio de armazenamento subjacente.
49
Muitos produtos na área de simulação adotam a arquitetura de framework orientado a

objetos, como pode ser observado em Alfons, Templ e Filzmoser (2009), Page, Knaak e
Kruse (2007), Rossetti, Miman, Varghese e Xiang (2006), Yalcin e Namballa (2005),
García et al. (2005).
Segundo Dalle, Ribault e Himmelspach (2009 p.948), outra arquitetura de interesse
para os softwares de simulação, naquilo que se refere à distribuição de processamento, é a
arquitetura cliente-servidor, podendo ser implementada como redes Peer-To-Peer (P2P), duas
ou mais camadas, computação em nuvem, ou grids. Essa arquitetura pode ser adotada tanto
para servidores que delegam tarefas para os clientes quanto por clientes que enviam
solicitações de execução para o servidor, sendo utilizada para computação distribuída, coleta
de dados e análise de resultados.
Na distribuição do processamento obtido pela arquitetura cliente-servidor é
interessante isolar o executor de simulações das demais camadas, como sugerido pela
arquitetura MSVC, pois há maiores possibilidades de reuso e menores dificuldades nas tarefas
referentes à configuração dos executores.
2.5 INTEROPERABILIDADE
Segundo Searle e Brennan (2007 p. 3-6), assumindo que o reuso é adequado e viável
para a modelagem e simulação, pode-se observar que interoperabilidade e reutilização estão
intimamente relacionadas. A fim de reutilizar um determinado componente em um sistema
mais amplo, deve-se assegurar que ele possa interagir com os outros elementos do sistema
(pelo menos aqueles com os quais deve trocar dados e informações).
Para Chen, Vallespir e Daclin (2008 p. 2), a interoperabilidade pode abranger quatro
níveis, basicamente, dentro de um sistema corporativo:
• Interoperabilidade de dados, referindo-se ao trabalho conjunto de diferentes

modelos de dados (hierárquico, relacional, etc) e das diferentes linguagens de
consulta, para encontrar e compartilhar informações provenientes de bases
heterogêneas que, aliás, podem residir em diferentes máquinas com diferentes
sistemas operacionais e diversos sistemas de gestão de bancos de dados.
50
• Interoperabilidade dos serviços, preocupada com a identificação, composição e

funcionalidade conjunta de diversos serviços e aplicações (modelados e
desenvolvidos independentemente), resolvendo as diferenças sintáticas e
semânticas, bem como as conexões para as diversas bases de dados heterogêneas.
• Interoperabilidade dos processos, destinando-se a fazer vários processos
trabalharem de forma conjunta. Geralmente em uma empresa, vários processos são
executados em interações (em série ou paralelo). No caso da rede corporativa,
também é necessário estudar a forma de conexão entre processos internos de duas
empresas para criar um processo comum.
• Interoperabilidade de negócio, referindo-se ao trabalho de uma forma
harmonizada com os níveis da organização e da empresa, apesar de, por exemplo,
os diferentes modos de tomada de decisão, métodos de trabalho, legislação, cultura
da empresa e abordagens comerciais, etc, de modo que o negócio possa ser
desenvolvido e compartilhado entre as empresas.
A interoperabilidade dos processos envolvidos no ciclo de vida útil de sistemas

técnicos, desde a fase de concepção até a sua desativação final, tem sido o foco principal do
desenvolvimento da Engenharia de Sistemas nos últimos anos.
Muitas iniciativas, com intensa participação de governos, empresas e organizações
internacionais têm sido desenvolvidas visando o que se convencionou chamar de “Engenharia
de Sistemas Baseada em Modelagem”, a qual promove a integração de todos os processos
envolvidos no ciclo de vida de um sistema técnico, ou seja, a integração de toda a cadeia
produtiva envolvida no ciclo de vida de sistemas técnicos.
A atenção internacional ao problema de Engenharia de Sistemas Complexos, tem
resultado na elaboração de normas tratando dos seguintes temas:
• O que fazer? (Interoperabilidade de serviços, processos e negócios)

• Quão bem? (Qualidade dos produtos e processos)
• Com que dados? (Interoperabilidade de dados)
• Como modelar e representar os sistemas técnicos? (Interoperabilidade de dados
e modelos)
51
As entidades abaixo estão envolvidas no processo de criação de normas aplicáveis à

engenharia de sistemas complexos:
• ISO – International Standardization Organization

• IEC – International Electrotechnical Commission
• ANSI – American National Standards Institute
• INCOSE – International Council for Systems Engineering
• EIA – Electronic Industry Association
• DOD – Department of Defense (USA)
• MOD – Ministry of Defense (UK)
• OMG – Object Modeling Group
• IEEE – Institute of Electrical and Electronic Engineers
Normas como ANSI/EIA 632, ISSO/IEC 15228, ISO 19760 e IEEE/EIA 12207 se
referem ao que fazer, prescrevendo o ciclo de vida de sistemas técnicos, quais processos
devem ser desenvolvidos e o que deve ser feito em cada fase do ciclo de vida (foco nos
processos da Engenharia de Sistemas).
Normas como CMMI e ISO 15504 preocupam-se com o quão bem foi feito,
prescrevendo maneiras de avaliar a qualidade com que as instituições envolvidas estão
desenvolvendo sistemas técnicos (foco na capacidade e qualidade para executar os processos
da Engenharia de Sistemas).
Com relação à identificação dos dados, normas como ISO 13303 prescrevem maneiras
de representar dados relativos a entidades e atributos do sistema e do processo de Engenharia
de Sistemas, para fins de automação e troca de informações entre programas, instituições e
agentes envolvidos no processo (foco em informação).
Finalmente, para a modelagem e representação dos sistemas técnicos, normas como
OMG SYSML e DODAF prescrevem maneiras de representar, através de símbolos e
imagens, atributos e características do sistema técnico, abrangendo todas as visões, desde
requisitos, passando por funções e arquitetura, até detalhamento de componentes (foco em
linguagem).
A Figura 8 apresenta um quadro comparativo entre algumas das normas disponíveis
com foco no processo.
52
Figura 8: Quadro comparativo entre alguns elementos normativos.
Há muito tempo existe a preocupação em reutilizar os sistemas existentes na

construção de sistemas maiores e mais complexos através da interoperabilidade, o que levou à
definição de arquiteturas e metodologias que permitissem esta integração.
Um exemplo disso foi o surgimento da High Level Architecture (HLA) voltada para a
integração de módulos de simulação que podem cooperar para um objetivo comum,
executando de forma distribuída.
A definição da HLA foi iniciada pelo Departamento de Defesa dos Estados Unidos
(DOD) em 1995, sendo a responsabilidade de sua evolução delegada ao IEEE’s Simulation
Interoperability Standards Committee (SISC) no ano de 1997. A partir disto a HLA passou a
ser regulamentada pela norma IEEE 1516, Standard for Modeling and Simulation High Level
Architecture - Framework and Rules, com última revisão ocorrida no ano de 2010.
Segundo Morse et al. (2006 p.115), HLA provê uma metodologia comum para a
modelagem de sistemas de simulação distribuídos, conectando simulações e interfaces com
sistemas interativos, segundo uma abordagem contemporânea onde o modelo de dados e a
semântica da arquitetura são separados das funções e métodos para intercâmbio de
informações.
53
Strassburger (2006) define de forma resumida a arquitetura HLA, citando que

simulações individuais e outros participantes de uma simulação distribuída são denominados
federates, enquanto um conjunto de federates que supostamente atuam de forma cooperativa,
obedecendo a certas padronizações e um modelo de objetos definido, formam o que é
chamado de federation. Ainda segundo o autor, os federates utilizam a Runtime Infrastructure
(RTI) para se comunicar, enquanto o HLA define um caminho bidirecional entre os federates
e o RTI, como pode ser observado na Figura 9.
Figura 9: Visão funcional de uma simulação distribuída sob HLA.
Fonte: Strassburger (2006 p.7)
Segundo Papazoglou, Traverso, Dustdar e Leymann (2007 p.64), Service Oriented

Computing (SOC) é um paradigma que define o uso de serviços para o desenvolvimento de
aplicações distribuídas a baixo custo, de forma rápida, interoperável e evolutiva.
Este paradigma é suportado pelas Arquiteturas Orientadas ao Serviço (SOA, do inglês
Service Oriented Architecture), onde a interface padrão para disponibilização e integração de
serviços é implementada através de Web Services.
Segundo Castagna, Gesbert e Padovani (2009 p. 19-2), os Web Services são
componentes distribuídos com os quais clientes podem se conectar e se comunicar por meio
de protocolos de comunicação padrão e mensagens em formato independente de plataforma.
Autores como Jacobi e Radul (2010), Mehta, Kanungo e Chandwani (2010), Tsai, Fan,
Chen e Paul (2006), defendem a abordagem do uso de Web Services para a construção de
sistemas e arquiteturas com processamento distribuído.
54
Para Dan, Johnson e Carrato (2008 p.28), a reutilização de serviços em um ambiente

SOA proporciona muitos benefícios incluindo melhorar a agilidade na implementação de
soluções através de uma rápida montagem novos processos de negócios a partir de serviços
existentes para atender às mudanças das necessidades de mercado, reduzir os custos, não
apenas evitando duplicação de código ao reutilizar funções de negócios semelhantes ao longo
dos múltiplos processos, mas também durante todo o ciclo de vida do sistema abrangendo a
implantação de serviços e gestão, e reduzir os riscos através do reuso de código e ambiente
de execução bem testados.
Seguindo essa linha, a implementação em particular de DEVS sob SOA, com o
objetivo de distribuir o processamento, é defendida por autores como D’Ambrogio, Gianni,
Risco-Martín e Pieroni (2010), Seo e Zeigler (2009), Mittal, Risco-Martín e Zeigler (2007).
A utilização de Web Services, não apenas permite o processamento distribuído, como
também aumenta a interoperabilidade ao utilizar um padrão de mercado reconhecido, o que
faz com que ferramentas especializadas possam ser utilizadas para a implementação de cada
aspecto de um sistema complexo.
Para Fan, Zhang e Fan (2010 p. 308), a multidisciplinaridade colaborativa das
tecnologias de simulação é amplamente utilizada na definição e construção de produtos
complexos, sendo a combinação de HLA e Web Services um meio efetivo para a obtenção de
integração e interoperabilidade nas simulações distribuídas heterogêneas.
2.6 PROCESSAMENTO DISTRIBUÍDO
Mesmo que Web Services forneçam um meio padrão de comunicação entre todos os
componentes, o que por si só permite a distribuição do processamento, a diversidade de
ambientes oferecida permite que cada componente busque sua própria metodologia de
otimização no que tange aos aspectos da implementação dos serviços oferecidos pelo mesmo.
Em termos de simulações, os cálculos podem ser muito complexos e demandar um
tempo demasiado longo para sua execução, muitas vezes inviabilizando o próprio modelo de
simulação. Neste âmbito, a busca de meios que permitam melhor utilização da base
computacional existente leva a uma nova interpretação desses modelos, com a detecção de
procedimentos independentes que possam ser executados em paralelo ou distribuídos em rede.
No trabalho efetuado por Byrne, Heavey e Byrne (2010) pode ser encontrada uma
comparação entre as diversas tecnologias disponíveis para a construção de ambientes
distribuídos na Web.
55
Entre as estratégias mais comuns para distribuição de processamento estão os objetos

distribuídos, englobando tecnologias como Remote Method Invocation (RMI), Common
Object Request Broker Architecture (CORBA), Java Enterprise Edition (JEE), e Distributed
Component Object Model (DCOM).
Dentre estas tecnologias, CORBA é a mais antiga e também a mais consolidada.
Embora haja uma tendência de utilização em novos sistemas de tecnologias Java e DCOM,
autores como Wang, Lu e Gill (2008), Stout et al. (2007), Wang, Chen, Lu e Koutsoukos
(2007), Gill (2006), Carey et al. (2005), Gong (2003), ressaltam a continuidade de sua
utilização em sistemas embarcados e de tempo real.
A tecnologia RMI trata da forma padrão de processamento baseada em objetos
distribuídos oferecida pelo Java, sendo utilizada por autores como Heo (2010), Keller, Kelly e
Todd (2010).
Quanto ao JEE, já discutido anteriormente, uma característica interessante é a adoção
de um protocolo compatível com CORBA, o que faz com que haja um grande aumento da
interoperabilidade ao permitir que linguagens diferentes do Java, como Delphi e C++,
possam atuar como clientes dos objetos distribuídos.
Para Henning (2006 p. 30), a Microsoft nunca apoiou a utilização do CORBA,
tentando impor o seu próprio padrão DCOM, o que manteve grande parte do mercado
indeciso quanto à utilização de uma destas duas arquiteturas de objetos distribuídos, mas
enquanto os componentes DCOM executam apenas no sistema operacional Windows,
CORBA independe de plataforma, apresentando maior interoperabilidade.
A distribuição de processamento baseada em Socket, dentro de uma arquitetura
cliente-servidor, também é uma opção, com a vantagem particular na implementação em Java
de não necessitar de qualquer tipo de biblioteca ou estrutura adicional além das que são
instaladas por padrão com o Java Runtime Environment (JRE). Isto resume a tarefa de
configuração do cliente, e como o Java é multi-plataforma, os clientes podem ser dos mais
diversos tipos.
Em uma comparação feita por Schwarzkopf et al. (2008), os autores indicam o uso de
Sockets quando é desejável maior eficiência, enquanto Web Services permitem maior
padronização e interoperabilidade.
Na abordagem em que o cliente é executor das simulações, uma estratégia que está
sendo bastante adotada é o de utilizar sistemas peer-to-peer (P2P), como pode ser observado
nos trabalhos de Dias et al. (2010), Huang et al. (2008), Adelberger, Kurz, Eder e Heistracher
(2008).
56
2.7 FRAMEWORK DE ACCV ORIGINAL
No framework original criado por Cople (2004), para a resolução de problemas na área
de ACCV, foram adotadas algumas premissas:
• A resolução de problemas multidisciplinares como os da ACCV exigiria uma

arquitetura que permitisse um comportamento adaptativo;
• Deveria ser adotada uma linguagem que permitisse instanciar objetos através de
reflexividade, devido às possibilidades de extensão proporcionadas pela
arquitetura;
• O modelo de classes utilizado seria baseado no trabalho de Pilla (2003), podendo
haver adaptações; e
• O simulador a ser criado seguiria o estilo de simulação por eventos discretos.
Os detalhes acerca do modelo alterado, que passou a ser denominado Modelo de Pilla
e Cople, podem ser observados no Capítulo 3, sendo aqui descritos apenas aspectos
arquiteturais e funcionais do framework original.
Foi adotado um modelo de execução seqüencial, e o uso de processos paralelos para a
execução de múltiplas simulações simultaneamente, mas cada simulação atuava de forma
monolítica, onde os processos de I/O ocorriam em meio a cada execução individual, o que fez
com que as possibilidades de paralelismo não fossem realmente aproveitadas.
O framework original trabalhava com três níveis de abstração:
1. Classe Java, apresentando a base estrutural e funcional de uma família de objetos;

2. Objetos de catálogo, referentes à caracterização de elementos de um determinado
tipo, e o preenchimento de suas propriedades; e
3. Objetos de Instância, referentes a elementos utilizados na simulação, representando
elementos físicos de um mundo real, sempre associados aos elementos de catálogo,
mas com vidas independentes. Para o caso especial de produtos, estes são
acompanhados ao longo da simulação por suas linhas de vida (descritas em
maiores detalhes no Anexo C).
57
O acréscimo de classes, nessa versão inicial do framework, apenas podia ser efetuada
com a utilização de eXtended Markup Language (XML). O processamento deste arquivo pelo
framework permitia gerar e compilar uma nova classe, além de guardar suas características
estruturais no banco de dados, o que viabilizava a geração de objetos de catálogo através da
interface de cadastramento, sem alteração da codificação da mesma.
A utilização de arquivos XML permite a criação de elementos do primeiro nível,
enquanto a interface de cadastramento gera elementos do segundo nível e a simulação, por
fim, gera elementos do terceiro nível. No segundo e terceiro níveis a reflexividade é
amplamente utilizada, fato que levou a eleger a linguagem Java para a construção do
software.
O fluxo de utilização baseava-se em quatro passos:
1. Extensão do framework;
2. Cadastro de dados de catálogo;
3. Construção de cenários; e
4. Execução de simulações e análise de resultados.
O primeiro passo é opcional, envolvendo a adição de classes a partir de arquivos XML

no formato interpretável pelo framework para geração de código-fonte Java. Este é um passo
preliminar que só deve ser efetuado quando as classes já existentes não satisfazem ao domínio
do problema sob análise.
O segundo passo se refere ao cadastro de dados referentes aos tipos de componentes
disponíveis para utilização, aspectos da mão-de-obra que pode ser disponibilizada, meios de
transporte, ou quaisquer outros dados globais, que não estejam diretamente envolvidos no
cadastro do cenário de análise.
Nesta fase são cadastrados os dados fornecidos por fabricantes, modos de falha,
índices fornecidos pelo governo ou pelo mercado, estrutura hierárquica de sistemas, locais
geográficos, tipos de profissionais e valor médio de mercado, atividades e consumo de
recursos, entre muitos outros fatores.
Estando o catálogo com informações completas, os cenários de análise podem ser
definidos no terceiro passo, com a determinação da estrutura de manutenção e abastecimento,
escolha dos meios de transporte utilizados, dotação de estoque, configuração de plano de
manutenção preventiva, período de simulação, e principalmente a configuração das instâncias
dos sistemas analisados, com respectivas localizações geográficas e regras operacionais.
58
Por fim, as simulações podem ser efetuadas e os resultados analisados no quarto e

último passo, sendo todo o fluxo de utilização observável na Figura 10.
Passo 1 Passo 2 Passo 3 Passo 4

Extensão do Cadastro de Construção Simulação e
Framework Dados de Cenários Análise
Figura 10: Fluxo de utilização do framework
Para dar suporte a este fluxo, o framework original apresentava quatro módulos
principais: Integração, Catálogo, Interface e Simulação.
O módulo de integração é o nível mais baixo da arquitetura, trabalhando com
elementos de persistência, reflexividade e interpretação de arquivos XML, encapsulando o
acesso a banco de dados e a criação de classes, além de fornecer muitas funções utilitárias
para outros módulos.
O módulo de catálogo engloba as classes de entidade participantes dos cadastros e dos
processos de cálculo, delimitando as propriedades e o comportamento dos elementos
envolvidos na simulação.
O módulo de interface compreende os arquivos JSP e pacotes de conversão
necessários à criação de telas cadastrais dinâmicas no formato Web, permitindo a entrada e
visualização de informações de catálogo, persistidas por intermédio do módulo de integração.
Também é nesta interface dinâmica que os cenários são construídos e as simulações
requisitadas.
O módulo de simulação utiliza os dados armazenados na interface, assim como o
cenário criado na mesma, através de instâncias de objetos das classes do catálogo, para efetuar
as simulações e armazenar os resultados obtidos. Toda a comunicação com banco de dados
envolvida no processo é controlada pelo módulo de integração.
Estes resultados eram observados posteriormente através de sistemas extratores
criados em Delphi, com acesso direto à base de dados, mas isto provou ser uma estratégia
inadequada de visualização, sendo considerado um dos pontos mais frágeis do framework
original.
59
Essa arquitetura já havia sido descrita por Cople e Brick (2010 p.17), podendo ser
observada na Figura 11.
Sentido de Utilização
Figura 11: Arquitetura do framework original
Adaptado de Cople e Brick (2010 p.17)
A criação desta versão inicial do framework permitiu verificar a viabilidade do uso do

Modelo de Pilla e Cople para a resolução de problemas na área de ACCV, mas os problemas
detectados motivaram uma grande reestruturação do software.
O uso de Java Database Connectivity (JDBC) e instruções de consulta voltadas para o
banco de dados utilizado, no caso o Microsoft Access, fez com que o código Java
encapsulasse instruções SQL no formato texto, dificultando a manutenção do código e a
detecção de erros, além de não permitir a substituição do servidor de banco de dados sem
alterações ocasionais no código-fonte.
O único nível de interoperabilidade permitido era ao nível dos dados, o que exigia um
grande conhecimento acerca do modelo, além de fragilizar os softwares desenvolvidos, já que
60
qualquer alteração estrutural da base de dados implicaria em manutenções decorrentes em

vários pontos distintos, possivelmente em diferentes linguagens de programação.
As simulações não eram eficientes por não se utilizarem de paralelismo de forma
adequada, tão pouco de possibilidades de distribuição de processamento.
Apesar da arquitetura de framework ser voltada explicitamente para o reuso, a
ausência de uma arquitetura interna mais robusta, além da simples divisão em módulos, na
versão original, dificultava este reuso por parte dos desenvolvedores, pois exigia um
conhecimento mais profundo acerca de todo o código-fonte do sistema, e não apenas das
características dos pontos de extensão.
2.8 CONCLUSÕES
Alguns testes efetuados, inclusive com a experimentação de ferramentas utilizadas

pelos autores, como JDEVS, fez com que algumas características fossem observadas:
1. A execução das simulações obrigava uma configuração inicial completa do

ambiente, sem permitir a modificação no decorrer da mesma;
2. Os simuladores consideram apenas estados e eventos, o que faz com que um
estado que estivesse previsto para um longo período possa ser interrompido por um
evento para outro estado de duração muito menor, sem a possibilidade de recuperar
o restante da transação anterior;
3. Sem o ajuste exato das transações internas e externas, os sistemas acabam em um
estado indefinido, impedindo novas mudanças de estado; e
4. Sempre havia uma preocupação no acompanhamento da execução a cada unidade
de tempo padronizada dentro do período simulado, o que era útil para a
representação visual em tempo real durante a simulação.
Para o framework de ACCV estas não são características interessantes ou úteis,

inicialmente por que o problema sob análise não exige um acompanhamento visual em tempo
real, pois foca o problema sob aspectos financeiros, preocupando-se apenas com o custo
decorrente da execução das atividades durante a simulação, através de análises efetuadas ao
término da mesma.
61
Também ocorre a necessidade de recuperação de transações anteriores, pois no modelo

utilizado para o cálculo de ACCV uma falha pode ser decorrente do tempo de operação
acumulado, o que faz com que uma atividade de operação não possa ser simplesmente
interrompida, mas sim corrigida, após a execução da atividade de manutenção, restaurando-se
o restante da operação inicial.
Finalmente, como o framework trabalha com objetos criados dinamicamente, através
de reflexividade, sujeitos a diversos fatores estocásticos, não seria possível determinar uma
configuração inicial, para as ferramentas existentes, que fosse adaptável a qualquer variação
introduzida.
Considerando tudo isto, foi criado um gestor de simulação em linguagem Java no
novo framework, ao invés de utilizar uma biblioteca existente, baseando-se em um modelo
gerador de eventos orientado a objetos, extensível, seguindo a implementação definida pelo
padrão de desenvolvimento State.
Este é um ponto onde o novo framework diferencia-se muito de seu antecessor, onde
os modelos de geração de eventos não eram considerados pontos de extensão. Com esta nova
abordagem, o próprio aspecto comportamental da simulação pode ser alterado, abrangendo
uma quantidade muito maior de problemas dentro da ACCV.
Maiores detalhes sobre o modelo de geração de eventos definido podem ser obtidos na
Seção 4.6 e na Seção 6.3.
A análise de alguns tipos de DEVS fez com que várias idéias surgissem, na tentativa
de aumentar o paralelismo do framework de ACCV, como por exemplo, tratar cada local
geográfico referente às organizações como células do Cell-DEVS.
Ao final, o modelo DEVS padrão foi utilizado para o framework de ACCV, isto
devido à grande interdependência existente entre atividades e eventos, o que faria com que a
utilização de variantes como P-DEVS ou Cell-DEVS levasse a um grande número de
reconfigurações e acabasse por tornar a execução mais lenta.
Não houve uma formalização rígida do Modelo de Pilla e Cople em termos das
notações aqui citadas, porém as características de um DEVS podem ser facilmente
observadas, já que ocorre o tratamento de forma seqüencial dos eventos para cada simulação.
Os detalhes sobre DEVS e sobre a utilização do formalismo em termos do framework
de ACCV podem ser observados no Anexo C.
62
Apesar de utilizar um modelo de execução seqüencial, tarefas secundárias, como

totalizadores e envio de resultados ao servidor, são executadas em paralelo, o que faz com que
cada processador seja mais bem aproveitado ao priorizar os processos de cálculo da
simulação.
No modelo DEVS padrão, a execução de uma atividade pode ser interrompida por um
evento a qualquer momento dentro do período de duração da atividade, levando a uma
mudança imediata do estado do sistema e conseqüente perda do período restante de execução.
Uma grande diferença do DEVS utilizado neste framework de ACCV em relação a este
comportamento padrão é a de que, considerado o efeito da interrupção da atividade por um
novo evento, o período restante de execução da atividade, após a influência deste novo
evento, é resgatado, ocorrendo uma correção inexistente no modelo DEVS genérico.
Em termos arquiteturais, houve a preocupação de viabilizar a interoperabilidade ao
nível de serviços, segundo um formato padrão, facilmente integrável à arquitetura HLA,
característica inexistente nos softwares comerciais para ACCV analisados, o que fez com que
fosse adotada a implementação através de Web Services.
Esta estratégia não apenas permitiu alinhar o novo framework às tendências e normas
referentes à construção de simuladores integráveis, o que virá a permitir sua participação na
execução de simulações de alta complexidade, como também permitiu o uso de ferramentas
especializadas para a construção de interfaces e eliminou o problema anteriormente existente
com referência ao impacto das alterações no banco de dados sobre os softwares criados com a
utilização do framework.
A interoperabilidade ao nível de serviços permitiu a melhoria da apresentação de
resultados e a criação de interfaces em ferramentas distintas, com grande facilidade e sem
acoplamento com a base de dados, resolvendo de uma só vez dois problemas existentes no
framework original.
Os detalhes acerca do uso de Web Services e da interoperabilidade promovida por esta
estratégia podem ser observados no Capítulo 4 e no Anexo B.
Como era desejada a distribuição do processamento, havia a necessidade de tornar a
execução da simulação o mais independente possível das características de ambiente, o que
levou à adoção de uma arquitetura interna baseada no padrão MSVC, sendo enviadas para o
executor apenas as classes referentes à camada de simulação.
A estratégia de distribuição utilizada no novo framework de ACCV foi baseada em
Sockets, segundo uma arquitetura cliente-servidor comum, direcionando a execução das
simulações para clientes que recebem os objetos constituintes do cenário de forma serializada,
63
enquanto o servidor atua como gestor, acompanhando a execução dos clientes e

intermediando as chamadas necessárias aos Web Services do aplicativo corporativo, tanto para
obtenção de dados de catálogo quanto para armazenagem de resultados de simulações
efetuadas.
Não foi utilizada a estratégia P2P, haja vista que o objetivo não era a fragmentação da
simulação, mas o aumento do número de simulações executadas, assim como também não foi
adotada a estratégia de objetos distribuídos ao nível dos servidores, isto porque se desejava
aproveitar a capacidade de processamento dos executores, inclusive com o uso de simulações
paralelas para aproveitamentos dos vários processadores em cada máquina, sem que os
mesmos tivessem que suportar qualquer tipo de COTS além daqueles já constituintes do
ambiente padrão, o que torna desnecessário qualquer processo de instalação ou configuração
mais complexo.
Detalhes sobre a distribuição de processamento no novo framework podem ser
observados na Seção 4.3.
No novo framework, o uso de COTS comerciais foi adotado apenas ao nível do
servidor de simulações, tratando aqui da adoção do JEE para a implementação da camada de
controle da arquitetura interna, e do JPA para a camada de persistência.
A adoção de JPA trouxe à nova versão plena independência do tipo de servidor de
banco de dados utilizado e possibilitou remover todo o SQL anteriormente existente em meio
ao código-fonte, o que facilita a manutenção, além da vantagem adicional de eliminar a
necessidade do processo de criação de tabelas na base de dados, já que este COTS efetua esta
tarefa de forma automática, já tratando da adequação das propriedades definidas para cada
entidade da camada de persistência aos tipos de dados inerentes ao banco escolhido.
Quanto ao JEE, contando com a possibilidade de precisar responder a um grande
número de solicitações a partir dos clientes, este COTS traz ao novo framework um grande
nível de escalabilidade, podendo ser efetuada desde uma configuração simples, com apenas
um servidor, até a definição de servidores clusterizados, sem alterações no código Java.
Como vantagem adicional da escolha destes COTS, a ferramenta de implementação
utilizada (NetBeans) tem amplo suporte visual a ambos, permitindo geração de boa parte do
código, suporte às ações de refactoring, integração com servidores de aplicativos e bancos de
dados, depuradores para os mais diversos ambientes heterogêneos, entre outros.
Maiores detalhes sobre a arquitetura interna e utilização de JEE e JPA podem ser
observados no Anexo B.
64
Finalmente, com a adição de elementos comportamentais ao estilo de programação

orientada a objetos, o novo framework de ACCV possibilitou o reuso de processos e
algoritmos de forma simplificada.
A maior parte dos processos internos do framework foi transformada em classes
genéricas, centralizando a manutenção e possibilitando a criação de novos procedimentos com
pouco esforço de programação.
Seguindo a mesma linha, o uso de anotações para registro de metadados, eliminando a
necessidade de arquivos XML, trouxe maior formalismo e simplicidade aos pontos de
extensão do framework de ACCV.
Os próprios COTS utilizados na construção do framework de ACCV seguem estas
novas metodologias, pelos mesmos motivos aqui apontados que justificaram as modificações
efetuadas na versão original do framework.
Detalhes sobre elementos genéricos e anotações podem ser obtidos no Anexo A, bem
como sua utilização no framework de ACCV é descrita na Seção 4.4 e na Seção 4.5.
Todas as alterações efetuadas na nova versão tinham como objetivo principal o
aumento e a facilitação do reuso do framework de ACCV, sendo também obtido o aumento da
eficiência das simulações, com o uso de processamento distribuído e paralelismo de I/O.
As metodologias e tecnologias utilizadas estão alinhadas com as tendências atuais
observadas nos mais diversos artigos científicos, em termos de reuso e interoperabilidade,
diferenciando-se apenas nos pontos onde as necessidades inerentes aos problemas de ACCV
se sobrepõem ao padrão, como a alteração do DEVS para a recuperação de um estado anterior
à transação efetuada, ou na forma como o processamento foi distribuído, para permitir o uso
de vários processadores mesmo em um ambiente notoriamente seqüencial, como é o caso da
simulação para ACCV.
Não menos importante, a possibilidade de alteração da política de geração de eventos,
possibilitando a completa modificação do comportamento da simulação, é uma novidade em
termos de simuladores DEVS, principalmente em uma área onde as ferramentas existentes
não são tão flexíveis, como é o caso da ACCV.
65
3. CUSTO DE CICLO DE VIDA E O MODELO DE PILLA E COPLE
3.1 INTRODUÇÃO
Segundo Fuller e Petersen (1996 p.1-1), a ACCV pode ser definida como uma
metodologia de avaliação econômica de projetos, na qual são considerados todos os custos
relativos à aquisição, desenvolvimento, operação, manutenção e desativação, desde que os
mesmos sejam considerados potencialmente importantes para uma tomada de decisão.
Para Waghmode e Sahasrabudhe (2008 p. 745), a competitividade global está
obrigando as empresas manufatureiras a estimar e otimizar o custo total do ciclo de vida do
sistema com relação ao desempenho, segurança, manutenibilidade e confiabilidade.
Segundo Kshirsagar, El-Gafy e Abdelhamid (2010 p. 171), o uso de ACCV pode ser
considerado como um ferramental para gestão de ativos, porém um sistema de gestão de
informações deve ser cuidadosamente desenvolvido, e o procedimento de coleta de dados
adequado deve ser colocado em prática para que se obtenham resultados precisos.
Autores como Deutsch (2010), Kaenzig e Wüstenhagen (2010), Goedecke,
Therdthianwong e Gheewala (2007), Liebermann e Ungar (2002), defendem também a
perspectiva do consumidor, transformando a divulgação do CCV de produtos industrializados
em um elemento de marketing, ao fornecer parâmetros comparativos, os quais acabam por
aumentar a competitividade entre as empresas no que tange a aspectos de seus produtos como
custo de utilização, tempo para obsolescência, confiabilidade, estrutura de manutenção
disponível, ou impactos ecológicos. Isto no Brasil pode ser observado, por exemplo, em
termos das classificações do INMETRO para consumo energético de eletro-domésticos.
Os projetos considerados nesse trabalho são aqueles referentes ao desenvolvimento e
aquisição de ativos físicos (sistemas técnicos) destinados a implementar processos produtivos
com as mais diversas finalidades. São exemplos desses sistemas os meios de defesa
66
(aeronaves, embarcações, viaturas, armas, sensores, etc), os meios de transporte para uso civil,
as unidades fabris, as unidades de exploração de minerais, etc..
Basicamente, o CCV pode ser entendido como um somatório de todos os custos
envolvidos na concepção, projeto, desenvolvimento, construção, operacionalização, operação,
manutenção, modernizações e desativação de um sistema. Ou seja, os custos incidentes sobre
um sistema durante todas as fases do seu ciclo de vida. Os custos que são computados
dependem em grande medida do tipo de usuário da ACCV. De uma maneira geral existem
três categorias de interessados nesse tipo de análise.
A primeira categoria envolve instituições que especificam, contratam o
desenvolvimento e adquirem sistemas para seu uso muito exclusivo (tais como forças
armadas, empresas petrolíferas e de geração de energia). Para esses usuários praticamente
todos os custos relacionados a um produto, desde a fase de concepção até a desativação são
relevantes.
Uma segunda categoria é a das instituições que adquirem produtos existentes no
mercado para montar os seus processos produtivos (tais como empresas de transporte aéreo,
marítimo ou terrestre e empresas de telecomunicações). Para essas, os custos das fases iniciais
do ciclo de vida, desde a concepção inicial do produto até a sua fabricação, estão embutidos
no custo de aquisição e não precisam ser considerados com maior detalhe.
Finalmente, a última categoria é a das instituições que concebem, desenvolvem e
produzem produtos para o mercado e têm que montar estruturas pós-venda para apoiar seus
clientes e garantir seus produtos. Para esse tipo de usuário os custos de operação e desativação
não são muito relevantes.
As principais características desse domínio de problema específico foram mapeadas
por Pilla (2003) e Cople (2004) através de um modelo no qual podem ser destacados três
elementos principais:
• Produto, foco da análise, considerando os elementos sobre os quais incidirão os

custos a serem aferidos;
• Atividade, que considera as ações executadas sobre os produtos; e
• Recurso, determinando os elementos necessários para a execução das atividades e
que, conseqüentemente, irão delinear a geração de custos.
67
Pilla (2003) descreveu esse modelo, com a utilização da técnica de modelagem

conhecida como UML (Unified Modeling Language), para sistematizar o processo de cálculo
de custo de ciclo de vida. A notação da UML é analisada no Apêndice A.
No trabalho efetuado por Cople (2004), o modelo de Pilla sofreu algumas alterações,
apresentando novas soluções para a execução de muitas das etapas dos processos analisados
anteriormente, sempre focando a implementação do modelo em uma base computacional já
popularizada, de forma robusta e expansível. O modelo resultante foi denominado modelo de
Pilla e Cople.
Esse modelo baseia-se em uma idéia bastante simples, embora vise a resolução de um
problema complexo:
“Uma atividade sempre é executada sobre um produto, com o consumo de recursos.”
A partir do momento em que são definidos os elementos de custo referentes ao

sistema, os mesmos devem ser organizados hierarquicamente através de uma árvore de custos
(CBS do inglês Cost Breakdown Structure), na qual cada elemento tem um instante de
ocorrência e uma fórmula de cálculo.
Visando satisfazer a esta diversidade de situações apresentadas na operacionalização e
manutenção de sistemas, o modelo de Pilla e Cople apresenta três estruturas de cálculo
principais, que por serem orientadas a objeto podem ser extendidas para a correta
interpretação dos dados envolvidos e implementação dos processos de cálculo necessários em
cada situação:
• Modelo de Eventos, relacionado ao cálculo dos instantes em que as atividades

deverão ocorrer, podendo utilizar valores determinísticos ou estocásticos;
• Modelo de Consumo de Recursos, visando modelar as diferentes formas com que
os recursos são consumidos durante a execução das atividades; e
• Modelo de Custo, relacionado ao cálculo efetivo do custo ao longo do tempo,
levando em consideração os recursos consumidos, definidos pelo modelo anterior.
3.2 FATORES ESTRUTURAIS
Para os fins de ACCV, elementos estruturais são aqueles ligados à composição do

sistema, objetivando a definição de gastos com projeto, operação, manutenção, consumo e/ou
68
manutenção de estoques de sobressalentes, construção e desativação do mesmo. A forma

como o processo produtivo está distribuído, geográfica e organizacionalmente, entre várias
unidades (órgãos) produtivos e de apoio (manutenção e abastecimento), também podem ser
considerados como fatores estruturais que afetam o custo total de posse de um sistema.
No modelo definido por Pilla, os elementos iniciais a serem considerados são os
recursos a serem utilizados ao longo da vida do sistema. Neste ponto deve haver uma
diferenciação entre recursos consumíveis em atividades e recursos que constituem os ativos
que compõem o sistema e são exclusivos do mesmo. Estes últimos pertencem à classe
produto.
O diagrama de classes para modelagem de recursos é apresentado na Figura 12, onde
são apresentadas as classes principais do modelo, segundo o que foi definido por Pilla (2003).
Recurso ref.
Próprios Terceiros
com põe
Config uraçã o_Prod uto Serviços Tipos de Serviços
Numerário Mão de Obra M issão do Produto Produto
1..* 0..* 1..*
0..*
Mi ssão Pri ncipal Missão de Apoio Seguros Aluguel Produtos Serv. Manut enção Transportes Obtenção Armazenagem Consultoria Especializada
Sistemas Hardware Softwares Documentos Instalações Itens de Consumo Embalagens Aéreo Marítimo Rodoviário Ferroviário Pipeline
E qui pamentos Partes Ferramentas E nergia Matéria Pri ma Consumíveis
Figura 12: Diagrama de Classes para Recursos
Recursos podem ter um perfil de utilização relacionado com a missão principal, ou

podem ser usados em sistemas capacitadores, tais como de manufatura, ou de apoio, mas esta
será uma classificação dependente do cenário de análise e não uma característica inerente ao
mesmo. Da mesma forma, alguns serviços poderão ser terceirizados, ou não, em função do
cenário de análise.
O produto foco da análise neste contexto é o sistema, na execução de sua missão, ao
longo de sua vida útil. Qualquer sistema pode ser definido como um conjunto de componentes
e seus relacionamentos, com uma finalidade comum, determinando a missão do mesmo.
69
Um exemplo de sistema poderia ser uma aeronave, onde os vários componentes da

mesma apresentam funções totalmente distintas, mas em conjunto cumprem com o objetivo
maior de voar e transportar pessoas e objetos.
Para Pilla (2003, p.80), um “produto” é um item material ou imaterial que pode ser
construído, operado e mantido. São exemplos de produtos: sistemas, equipamentos, partes,
softwares, instalações, documentos e ferramentas. Parte deste modelo pode ser observada na
Figura 13, mostrando a modelagem apenas dos produtos.
Figura 13: Diagrama de Classes para Produto
Segundo o modelo, produtos podem ser compostos de outros produtos, o que pode ser
verificado na agregação “Configuração_Produto”, o que permite a criação de estruturas
hierárquicas (“árvores de produtos”).
Um “sistema” seria compreendido como o topo da hierarquia, comumente sendo
composto em um primeiro subnível por “equipamentos”. Esta não é uma restrição, pois o
sistema pode englobar também “instalações”, ou qualquer outro tipo de “produto” neste
subnível. O que caracteriza um “sistema”, de fato, não seria sua composição, mas sim, o
comprometimento com a missão principal, manufatura ou apoio.
Para Pilla, um “equipamento” pode ser entendido como um conjunto de componentes
(“partes” e “softwares”) que, normalmente, não é retirado de seu local de instalação para ser
submetido a reparos. O seu reparo pode ser feito no próprio local onde está instalado, por
meio da substituição de partes. Um “equipamento” é responsável pela execução de alguma
função específica numa aplicação (“sistema”).
70
Uma “parte”, no contexto do modelo de Pilla, pode ser entendida como um

componente capaz de sofrer ações de manutenção num determinado equipamento. A partir do
contexto onde a mesma é utilizada, uma parte pode ser classificada como LRU (Line
Replaceable Unit), quando puderem ser substituídas com facilidade e rapidez pelos próprios
operadores dos equipamentos no qual estão inseridas, ou como SRU (Shop Replaceable Unit),
quando sua substituição depende de instalações mais especializadas.
Esta abordagem é exemplificada na Tabela 1, onde é ilustrada a estrutura hierárquica
de um sistema.
Tabela 1: Exemplo de "Árvore de Produtos"
Nível Código Produto Classificação

0 1 SIST1 Sistema
1 1.1 E1 Equipamento
2 1.1.01 LRU11 Parte
3 1.1.01.01 SRU111 Parte
3 1.1.01.02 SRU112 Parte
1 1.2 E2 Equipamento
2 1.2.01 LRU21 Parte
Segundo Pilla (2003, p.83), a classe “Configuração_Produto” tem como objetivo

permitir a definição das quantidades e perfis de utilização dos “produtos-filho” com relação
aos “produtos-pai” na “árvore de produtos”. Imagine-se o caso, por exemplo, da Parte
“LRU11” que é composta pelas partes “SRU111” e “SRU112”.
Para definir o funcionamento da mesma durante o ciclo operacional do sistema, e os
impactos de possíveis falhas que venham a ocorrer durante a operação, é necessário saber:
• Quantas unidades de cada um dos componentes (SRU111 e SRU112) estão

disponíveis na “LRU11”;
• Quantas unidades de cada um dos componentes são requeridas para a operação

da “LRU11”;
• No caso da quantidade disponível ser maior que a requerida, como está

configurada a redundância (ativa ou passiva?); e
• Qual é o percentual de utilização do tempo de cada uma das partes em relação

ao tempo total de funcionamento da “LRU11”.
71
A classe “ConfiguracaoProduto” permite configurar o relacionamento entre

componente constituinte e seu detentor, incluindo propriedades como “Quantidade Existente”,
referente ao número de componentes utilizados, e “Quantidade Necessária”, referente à
quantidade mínima de componentes necessária para a continuidade da operação do sistema.
Estas duas características são importantes, pois denotam claramente a possibilidade de
utilização de redundância na configuração da estrutura do sistema e, também, a determinação
da disponibilidade operacional ou da capacidade produtiva.
O sistema de exemplo pode ser observado na Figura 14, a qual trata de um fragmento
da tela cadastral de composição de produtos do framework desenvolvido. Observa-se na
figura a estrutura do sistema de exemplo do lado esquerdo, bem como a configuração do
relacionamento com um dos componentes (SRU111) à direita.
Figura 14: Exemplo de Sistema Técnico

72
3.3 CONFIABILIDADE, MANUTENIBILIDADE E DISPONIBILIDADE
Um fator primordial para o cálculo do custo de manutenção e de estocagem de

sobressalentes é o da confiabilidade de componentes. A confiabilidade de um determinado
componente é definida pela probabilidade do mesmo estar funcionando após um dado período
de tempo, consideradas as suas características funcionais. Em se considerando um sistema, a
confiabilidade do mesmo será dada pela confiabilidade dos elementos componentes e suas
combinações estruturais.
Madu (2005 p.318) defende a idéia de que a confiabilidade e gestão de manutenção
assumem hoje um papel estratégico nas empresas, pois o atual foco na satisfação do cliente e
os esforços para melhorar continuamente a qualidade estão diretamente ligados à
confiabilidade e disponibilidade de processos necessários ao fornecimento de produtos e
serviços.
No modelo de Pilla e Cople existe uma classe principal para a modelagem dos modos
de falha, associando um produto a uma falha, a qual ocorre segundo uma distribuição
associada para aquele produto. Dada a ocorrência da falha, esta leva a um processo de
manutenção envolvendo um conjunto de atividades para o produto, incluindo a atividade de
reparo, cada qual com duração definida a partir de distribuição específica.
Segundo Pilla (2003 p.93), a ocorrência de uma falha pode impactar de diversas
formas o desempenho, não só do “produto” onde ocorre, mas, também, do sistema como um
todo. Exemplos desses impactos são:
• Perda de capacidade de produção;
• Indisponibilidade do sistema ou dispositivo;
• Geração de outras falhas;
• Danos materiais aos componentes da estrutura de operação e apoio;
• Danos a seres humanos e ao meio-ambiente.
Define-se como “modos de falha” as diferentes formas com que um componente pode
falhar ao executar determinada função do sistema. Como um sistema é composto de diversos
componentes, e os mesmos podem apresentar diferentes “modos de falha”, estas falhas podem
impactar no funcionamento não apenas do componente, mas do sistema como um todo.
73
Neste modelo, atividades sobre determinados produtos geram modos de falha e estes
modos de falha geram novas atividades, tal como a operação do sistema, que causa falhas no
funcionamento dos componentes, gerando demanda para órgãos mantenedores, os quais
deverão efetuar atividades no sentido de restabelecer a operação do sistema inicialmente
citado. O diagrama de classes para “modos de falha” pode ser observado na Figura 15.
Figura 15: Diagrama de Classes para Modos de Falha
Vale lembrar que, apesar de todo modo de falha ser causado por uma atividade, nem
toda atividade é iniciado por um modo de falha. Podem-se citar as atividades de
desenvolvimento e operação, as quais não dependem de uma falha do componente para serem
iniciadas.
Devido à aleatoriedade da ocorrência dos modos de falha, assim como de outros
elementos do modelo, surgiu também a necessidade de se construir classes para obtenção de
instantes aleatórios. Cople (2004) definiu a classe “Distribuicao”, que tem como objetivo
único o fornecimento de instantes de tempo segundo uma distribuição estatística especificada.
Esta classe é um elemento abstrato, apenas definindo o comportamento padrão de suas
descendentes, as quais caracterizam e parametrizam as diferentes distribuições consideradas
nas simulações.
74
Um exemplo de modo de falha pode ser observado na Figura 16, onde é apresentada a
interface cadastral para os modos de falha.
Figura 16: Exemplo de Modo de Falha
A partir do estudo da Manutenibilidade, o conceito de Disponibilidade pode ser

aprimorado e diferenciado para três tipos, segundo Blanchard e Fabricky (1998 p.359):
• Disponibilidade Inerente;
• Disponibilidade Alcançável; e
• Disponibilidade operacional.
A Disponibilidade Inerente (Ai) é a probabilidade do equipamento ou sistema estar

operante, dentro de um ambiente ideal. Reflete os parâmetros do fabricante apenas e não
inclui manutenções preventivas ou atrasos logísticos.
75
A Disponibilidade Alcançável (Aa) considera também o ambiente ideal, mas inclui os

tempos de manutenção preventiva.
Finalmente, a Disponibilidade Operacional pode ser definida como a probabilidade do
sistema poder operar em se considerando o ambiente real de operação e manutenção,
considerando, além de todos os tempos anteriores, os atrasos logísticos e administrativos.
3.4 ATIVIDADES
Uma atividade pode ser definida como um conjunto de ações a serem praticadas sobre
determinado produto, envolvendo recursos e tempo para a execução das mesmas. Entre as
ações executadas, podem ser encontradas outras atividades, permitindo uma organização
hierárquica das mesmas.
Segundo Pilla (2003 p.85), as atividades do nível mais analítico na estrutura
hierárquica são compostas por tarefas, que consistem nas unidades mais elementares de
trabalho a ser executado para o alcance de um determinado fim.
Cople (2004) considera as atividades como elementos atomizados, não se permitindo a
composição de atividades por outras atividades, como ocorria no modelo original. No caso da
necessidade de atividades subseqüentes, estas têm que ser seqüencializadas segundo um
modelo de eventos próprio.
Isto não significa dizer que uma atividade estaria resumida ao nível de uma tarefa. Na
verdade, tarefas aqui são definidas como ocorrências pontuais distribuídas ao longo do tempo,
e ocorrendo de forma “instantânea”, tal como pousos e decolagens, ou tiros disparados, e
serão importantes na definição do instante em que devem ser efetuadas algumas manutenções
preventivas baseadas na quantidade de tarefas executadas.
Com esta atomização das atividades, elas passaram a ser classificadas de acordo com a
seguinte divisão:
• Projeto envolve atividades de planejamento referentes à construção do sistema;
• Aquisição, quando da compra de componentes para o sistema ou para o estoque de

sobressalentes;
• Manufatura, referente às atividades necessárias à construção do sistema, após a

obtenção dos componentes necessários;
76
• Instalação, envolvendo tarefas referentes à montagem do sistema a partir de seus

componentes, após a fase de aquisição e manufatura dos mesmos;
• Treinamento, necessário à preparação dos operadores e mantenedores, sendo

determinada quando da contratação de mão-de-obra ainda não especializada, ou na
atualização do sistema;
• Operação, determinada pelo perfil de funcionamento de um determinado sistema;
• Manutenção, sendo subdividida em Manutenção Corretiva causada pelo uso do

sistema, gerada a partir das falhas dos componentes, e Manutenção Preventiva,
prevista em calendário ou por utilização;
• Abastecimento, referindo-se às atividades relacionadas à utilização de

sobressalentes existentes em estoque;
• Transporte, quando da necessidade de se mover um produto de um órgão para

outro com a finalidade de se efetuar manutenção, utilizar sobressalente ou repor o
estoque;
• Atualização, que poderia ser interpretada como uma manutenção prevista em

calendário, com a finalidade de ajustar o sistema às novas tecnologias; e
• Descarte de componentes, ocorrendo quando não há nenhuma possibilidade de

manutenção sobre um componente, ou quando da desativação de um sistema.
A Figura 17 apresenta um diagrama de classes contemplando as atividades.
Figura 17: Diagrama de Classes para Atividades

77
Inicialmente, as atividades podem ser executadas no nível de projeto e construção,

quando o sistema ainda é uma entidade virtual, não oferecendo condições de produção de um
sistema real.
A partir do momento em que se trata de um sistema implementado e operante, o
mesmo apresenta falhas decorrentes da operação, sujeitas a diferentes fatores e diferentes
formas para a contabilização do tempo necessário para tal.
Logo, estas atividades seguem uma ordem cronológica:
• Inicia-se com o projeto do sistema;
• Após o projeto, serão adquiridos os componentes necessários, efetuando-se a

manufatura dos equipamentos, sua instalação e treinamento da mão-de-obra. Serão
adquiridos também componentes para estocagem de sobressalentes. Se o sistema
for composto por equipamentos adquiridos no mercado, a fase de manufatura não é
necessária;
• Com o sistema implantado ocorrem atividades de operação, ocorrendo falhas e

atividades de manutenção e abastecimento. Neste ponto pode ocorrer descarte e
aquisição de novos componentes;
• Ainda na fase operacional, ocorrem atualizações do sistema e treinamento,

decorrente destas atualizações ou da rotatividade de mão-de-obra;
• Seguem-se as atividades de descarte, ao final do ciclo de vida do sistema; e
• Durante todas as fases após o projeto poderá haver necessidades referentes ao

transporte de componentes.
Ainda dentro deste contexto, e observando-se como as atividades foram distribuídas ao

longo do ciclo de vida, pode-se chegar à conclusão de que as mesmas podem ser divididas em
três tipos principais:
1. Atividades sobre elementos virtuais;

2. Atividades programadas sobre Instâncias; e
3. Atividades decorrentes do uso de Instâncias.
78
Apenas a título de ilustração, a Tabela 2 exemplifica a classificação de algumas

atividades cobertas pelo framework.
Tabela 2: Classificação de algumas das atividades do modelo, segundo os três tipos principais
Atividade Classificação Observação

Desenvolvimento Virtual
Manufatura Virtual Sistema é virtual, mas depende de produtos
reais para ser efetuada. Sistema se torna um
elemento físico ao final.
Aquisição Virtual Ao final da aquisição, os produtos se tornam
elementos físicos.
Instalação Programada
Descarte Programado
Treinamento Programado / Virtual Não depende de sistema, podendo ser
efetuado em sala de aula ou simuladores.
Atualização Programado
Manutenção Corretiva Decorrente do Uso Sempre ocorre de forma aleatória, segundo as
características de uma falha determinada.
Manutenção Preventiva Programado Manutenções preventivas podem ser
Decorrente do Uso determinadas em termos de tempo corrido ou
da utilização do produto.
Atividades sobre elementos virtuais são aquelas que ocorrem antes da aquisição dos
produtos relacionados, pois até este momento não existe uma ocorrência física dos mesmos,
não permitindo o acompanhamento de seus estados ao longo do ciclo de vida. Exemplos
típicos são: desenvolvimento, projeto, e solicitação de produtos (aquisição). Este modelo
considera que os produtos passam a ter uma conotação física após a atividade de aquisição.
Encontrando-se os produtos instanciados, estes estão sujeitos às atividades
programadas, programação esta baseada em regras pré-estabelecidas, tais como “Manutenção
preventiva a cada 2000 horas”, ou “Instalação na data de 02/05/2000”.
Além de estarem sujeitos às atividades programadas, os produtos cumulam horas de
operação, estando sujeitos a falhas e conseqüentes manutenções corretivas, e até mesmo, a
manutenções previstas para determinados tempos de operação. Exemplos típicos são: “LRU11
apresenta falha com MTBF=2000”, ou “Manutenção preventiva do equipamento E1 a cada
500 horas de utilização”.
Este último tipo de atividade, que é aquela decorrente do uso, depende de um
acompanhamento preciso de toda a vida do produto, observando-se os momentos em que o
mesmo está operando, para correta contabilização do tempo acumulado de operação. Esta
79
técnica de acompanhamento utiliza-se de uma estrutura denominada Linha de Vida por

Cople (2004).
Vale lembrar que, apesar da necessidade de execução de uma atividade surgir em
determinado local, devido a uma série de fatores, tais como falhas, parametrizações, ou
determinação em calendário, não necessariamente esta atividade será executada no local que
gerou esta necessidade. Este conceito é explorado de uma forma mais concisa na seção
seguinte, com a definição do conceito de “Órgão”.
3.5 ÓRGÃOS
Pilla (2003, p. 87) define “Órgão” como uma entidade ou unidade organizacional
qualquer, própria ou de terceiros, que pode demandar e/ou executar atividades ao longo do
ciclo de vida de um sistema.
Ainda segundo o autor, o conceito de “Órgão” não se limita à definição das unidades
de operação e manutenção, mas sim, refere-se às diversas unidades onde devem ser alocados
os custos envolvidos no projeto (esse conceito pode entendido como “centros de custos”).
Diferentes órgãos apresentam diferentes finalidades e executam diferentes funções,
conforme pode ser observado no modelo original de Pilla, onde foi definido o conceito de
“Tipo de Órgão”, classificando-os de acordo com sua natureza, tal como: “Órgão de
Operação”, “Órgão de Projeto”, etc. Ao contrário do modelo original de Pilla, onde cada
organização deveria responder a apenas um perfil, para Cople as organizações podem
satisfazer a um conjunto de perfis. Este modelo pode ser observado no diagrama de classes da
Figura 18.
Figura 18: Diagrama de Classes para Órgão

80
Observa-se também, pelo diagrama, que um “Órgão” está sempre associado a um

determinado “Local Geográfico”. Conforme citado anteriormente, a necessidade de uma dada
atividade é sempre gerada em um determinado local, ou de uma forma mais precisa, dentro de
um órgão situado neste local, considerado como “Gerador” da atividade, mas, em algumas
situações, esta atividade só pode ser executada por outro órgão, considerado como
“Executor”, situado em outro local.
Um exemplo deste tipo de situação seria uma manutenção que exija um órgão mais
especializado para efetuá-la, surgindo, inclusive, a necessidade de transporte de componentes
entre os órgãos, o que irá gerar novos custos, sujeitos a outros fatores, segundo o Modelo de
Transporte utilizado.
Quanto aos perfis utilizados na caracterização das organizações, estes permitem uma
determinação simplificada das atividades que podem ser executadas pelo órgão. Por exemplo,
atividades de manutenção só podem ser executadas por órgãos que tenham o perfil de
mantenedor, enquanto estoques de sobressalentes só podem ser mantidos por órgãos com
perfil de abastecimento.
Outro tipo de órgão a ser considerado é o órgão desenvolvedor, que define o projeto
do sistema, exigindo estrutura e pessoal especializado para desenvolvimento. Este tipo de
órgão será o responsável pelo Plano de Atividades de Projeto.
É comum a organização de estruturas de apoio logístico em diversos níveis, também
denominados escalões de manutenção. Uma estrutura usual é de quatro escalões:
4º escalão: Fabricante (C) – as ações de manutenção são realizadas nas instalações do

fabricante com pessoal altamente qualificado. Destinado a ações de manutenção
complexas;
3º escalão: Centro de Manutenção (D) – as ações de manutenção são realizadas em
centros de manutenção com equipamentos sofisticados e pessoal de alta
qualificação e intermediária. Destinado a ações de manutenção complexas e de
apoio ao 2º escalão;
2º escalão: Intermediário (I) – realizada em oficinas de campo ou unidades móveis,
realizada por técnicos com qualificação intermediária. Destinado a ações de
manutenção simples, mas que não podem ser realizadas no 1º escalão; e
81
1º escalão: Organização (O) – no local onde o equipamento está instalado, sendo a

manutenção realizada pelos próprios operadores. Destinado a ações de manutenção
simples, como ajustes e pequenos serviços.
A partir da determinação dos escalões de manutenção e da determinação de unidades

mantenedoras nos diferentes escalões, pode-se avaliar o custo da manutenção de determinado
componente dentro do sistema em cada uma destas unidades, levando em consideração os
fatores de manutenibilidade, gastos com transporte e embalagem, tempo necessário para o
conserto (e prejuízos decorrentes), compra de equipamentos envolvidos na atividade de
reparo, além do treinamento e custo operacional dos técnicos ligados à manutenção.
Um exemplo da classificação de órgãos, segundo o diagrama anterior, pode ser
observado na Tabela 3. O exemplo não considera atividades de manufatura.
Tabela 3: Exemplo de Caracterização de Órgãos
Órgão Local Desenvolvimento Mantenedor Abastecimento Operacional Fabricante
Manutenção Belo Horizonte Não Sim Sim Não Não

MG
Manutenção Brasília Não Sim Sim Não Não
DF
Fabricante Manaus Sim Sim Sim Não Sim
AM
Operacional Rio de Janeiro Não Sim Não Sim Não
RJ
Operacional São Paulo Não Sim Sim Sim Não
SP
As configurações de um sistema de exemplo podem ser visualizadas na Figura 19,

onde é apresentado o fragmento da tela cadastral com as estruturas de manutenção e
abastecimento. Embora neste exemplo sejam coincidentes, esta não é uma premissa para o
framework.
82
Figura 19: Exemplo de estruturas de manutenção e abastecimento
3.6 FATORES FINANCEIROS
Um dos elementos financeiros que deve ser considerado na análise de custo é a

inflação, que expressa um aumento contínuo e generalizado no nível geral de preços.
Em termos de aquisição de sobressalentes, os mesmos estão sujeitos à inflação de
custo de produção dos mesmos. Para Vasconcellos (1998, p.182), a inflação de custos pode
ser associada a uma inflação tipicamente de oferta. O nível de demanda permanece o mesmo,
mas os custos de certos fatores importantes aumentam. Com isso, ocorre uma retração da
produção, deslocando a curva da oferta de produtos para trás, provocando um aumento dos
preços de mercado.
Ainda segundo o autor, as causas mais comuns do aumento do custo de produção são:
• Aumentos Salariais;
• Aumentos dos Custos de Matérias-Primas; e
• Estrutura de Mercado (monopólios e oligopólios).
83
Os mesmos fatores podem acarretar inflação sobre o custo operacional do sistema,

como na variação do valor de mercado do profissional associado à atividade, ou o
encarecimento do treinamento em face de monopólios tecnológicos.
Cabe ao tomador de decisão definir uma projeção da inflação baseada nas tendências
do mercado, definindo um índice de correção mensal a ser aplicado nos meses decorrentes
onde ocorre o custo.
Fator de Inflação = (1 + i)n Equação 1
Onde:
i = taxa de inflação estimada por período;
n = período em que ocorre o custo.
Outro aspecto que tem influência sobre a ACCV é o desconto. A técnica usada,
segundo Langford (1995), é a de valor presente, levando em conta uma taxa de desconto, a
qual representa a importância dada ao tempo pelo tomador de decisão no que diz respeito ao
recebimento do dinheiro.
Descontos são utilizados quando o gasto será efetuado em um prazo maior que a
disponibilidade efetiva do dinheiro, de forma que o mesmo poderá ser redirecionado para
outros tipos de investimento, levando a uma diminuição do valor relativo do custo.
Fator de Desconto = 1 / (1 + d)n Equação 2
Onde:
d = taxa de desconto por período;
n = período em que ocorre o custo.
Segundo Pilla (2003, p.100), o “modelo de tratamento financeiro” tem por objetivo
permitir que os valores dos custos estimados sejam ajustados considerando-se a técnica
financeira apropriada.
84
A partir do instante de ocorrência de um “evento”, e durante o tempo definido pela

execução da “atividade” associada, ocorre a incidência de um custo definido pelo “modelo de
custo de recursos”. Como este custo apresenta-se distribuído neste intervalo, torna-se factível
a determinação de um tratamento financeiro baseado no tempo.
Assim, a associação de um “evento” com seus “elementos de custo” (representada pela
classe “elemento de custo de evento”), deve receber o tratamento financeiro adequado a fim
de dar origem ao “elemento de custo de evento ajustado”, como pode ser visto na Figura 20.
Elem ento de Custo de Evento Ajustado
Elemento de Custo de Evento Modelo de Tratam ento Financeiro
Evento 0..* 0..* Elemento de Custo
Figura 20: Diagrama de Classes para Modelo de Tratamento Financeiro
A soma de todos os custos ajustados irão definir a melhor projeção do gasto total com
o sistema ao longo de todo o seu ciclo de vida, além de permitir estimar o fluxo de caixa dos
gastos referentes ao mesmo.
Custos não ocorrem da mesma forma para todas as atividades, ou mesmo dentro da
própria atividade. Foi considerado neste modelo que os custos ocorrem segundo curvas de
distribuição ao longo do tempo para cada recurso consumido em termos de utilização,
enquanto a aquisição e os custos tabelados de transporte ocorrem de forma pontual, no início
da execução da atividade.
Estando todos os custos distribuídos ao longo do tempo, estes podem ser divididos nos
intervalos determinados para desconto, tendo seu valor recalculado e passando a determinar o
que foi denominado “Átomo de Custo”.
Os átomos de custo irão permitir definir o fluxo de caixa, cálculo de valor presente, e
outros, funcionando como fonte de informação para grande parte dos relatórios financeiros
obtidos a partir das simulações.
85
3.7 ESTRUTURA DE DESDOBRAMENTO DE CUSTOS
Segundo Pilla (2003, p.31), a identificação adequada de todos os custos a serem

incorridos ao longo do ciclo de vida de um sistema depende fundamentalmente do
desenvolvimento de uma Estrutura de Desmembramento de Custos (CBS, do inglês Cost
Breakdown Structure). Esta consiste numa espécie de “lista” ou “plano de contas”, geralmente
organizada de forma hierárquica, que apresenta todos os itens de custo a serem considerados
no processo de ACCV.
Para Tytula (1995 p.326), a CBS representa uma subdivisão lógica dos custos por
áreas funcionais e elementos principais do sistema, e deve ser montada para atender as
necessidades de cada projeto.
Lock (2007 p.185) ressalta o fato de que os elementos da CBS irão depender em
grande medida do tipo de projeto, de modo que, por exemplo, a CBS de um projeto de
construção geralmente contém um elevado custo de subcontratação, e um projeto de
mineração terá alguns custos altos com equipamentos individuais, tais como guindastes e
locomotivas.
O agrupamento dos custos em termos de uma CBS auxilia na captura de dados e
exibição de resultados para os cálculos de ACCV, pois sistemas técnicos de razoável
complexidade apresentarão uma grande diversidade de elementos de custo ocorrendo no
decorrer de todo o período analisado, e a simples listagem destes não traria nenhuma
percepção ao nível estratégico do projeto.
Através do agrupamento e categorização dos custos é possível analisar áreas e
produtos que representem pontos críticos em termos de gastos, permitindo ao nível estratégico
concentrar esforços na otimização de processos relacionados, recursos utilizados e
configurações dos produtos.
É válido lembrar que os custos de manutenção podem variar ao longo do tempo devido
à obsolescência de componentes, particularmente os eletrônicos, onde o custo de aquisição
dos mesmos costuma iniciar alto, decrescer em médio prazo e voltar a subir devido à escassez
de fabricação no longo prazo. As classes de cálculo de custo do Modelo de Pilla e Cople
viabilizam a implementação deste comportamento dinâmico.
86
Segundo Blanchard e Fabricky (1986), uma CBS deve apresentar, pelo menos, as
seguintes características:
• Todos os elementos de custo do sistema devem ser considerados;
• Cada categoria de custo é relacionada a uma função, um nível de atividade e/ou

algum item de hardware/software;
• A estrutura deve ser codificada de maneira hierárquica e as categorias devem ser

organizadas para permitir a análise de áreas específicas de interesse; e
• A estrutura de custos deve ser compatível com os procedimentos gerenciais e

contábeis utilizados na coleta dos dados de custos.
A partir da definição dos elementos de custo, os mesmos deverão ser dispostos em

uma estrutura no formato de árvore, como em um plano de contas.
Vários autores, como Lock (2007) e Hamilton (2004), defendem a construção da CBS
como uma matriz resultante do cruzamento entre os elementos de duas outras estruturas: uma
relacionada aos procedimentos efetuados e relacionamentos hierárquicos entre os mesmos,
denominada Estrutura de Desdobramento do Trabalho (WBS, do inglês Work Breakdown
Structure), e outra relacionada aos diversos setores da empresa e suas relações hierárquicas,
denominada Estrutura de Desdobramento da Organização (OBS, do inglês Organization
Breakdown Structure). Tytula (1995) também defende a compatibilidade entre as três
estruturas, embora não descreva explicitamente uma formação matricial. A Figura 21 mostra
um exemplo desta construção matricial.
Figura 21: Relações entre CBS, OBS e WBS
Adaptado de Lock (2007 p.186)

87
Outras formas de construção podem ser propostas, sem que seja desvirtuada a
finalidade principal da CBS, que é a de agrupar os custos e prover a visão estratégica dos
mesmos para todo o período considerado durante o ciclo de vida do sistema.
Para Kamauchi e Rausand (1999, p.12), a estrutura de custos deve ser definida a partir
de três eixos independentes, a saber: Fases do Ciclo de Vida, Categorias de Custo e Estrutura
de Decomposição de Hardware. Esta é uma construção particularmente interessante, pois
permite considerar a variação de um tipo específico de custo ao longo do tempo.
A visualização defendida pelos autores pode ser observada na Figura 22.
Custo de mão de obra

para um componente ao
longo do ciclo de vida
Categorias
de Custos
Estrutura de
Decomposição de
Hardware
Mão de Obra
Componente
Fases do Ciclo de
Vida Projeto e Exemplo de um elemento de
custo: “Custo de Mão de Obra
Desenvolvimento na fase de Projeto &
Desenvolvimento do
Componente X.
Figura 22: Estrutura da CBS
Adaptado de Kamauchi e Rausand (1999, p.13)
Segundo Brick e Borges (2004), para a definição de uma CBS é necessário o

desenvolvimento de uma “árvore de produtos” que compõem o sistema, uma “lista de
atividades” a serem executadas ao longo do ciclo de vida e uma “lista de recursos” a serem
consumidos na execução das atividades.
Esta abordagem faz com que a CBS apresente o relacionamento entre os elementos de
custo e os diferentes componentes do sistema, permitindo analisar quais componentes podem
apresentar maiores custos totais, o que viabiliza a modificação de configurações, como
acréscimo de elementos redundantes para a minimização da perda de produção, quando esta é
mais relevante que os custos com manutenção, ou até mesmo a troca de componentes por
similares que satisfaçam aos níveis de segurança exigidos.
88
O Modelo de Pilla e Cople segue a organização proposta por Brick e Borges (2004),
mas leva em consideração o fato de que cada atividade está relacionada aos modelos de
cálculo. Além disto, considera que cada Atividade tem um órgão gerador da mesma e um
órgão executor, sendo que o solicitante sempre arca com os custos.
A Figura 23 apresenta uma CBS de exemplo, criada através da interface cadastral do
novo framework.
Figura 23: Exemplo de CBS na interface cadastral do framework.
3.8 MODELO DE TRANSPORTES
Com produtos sendo adquiridos, manutenções sendo solicitadas em oficinas distantes,

trabalhadores tendo que se deslocar para o local de operação do sistema, entre muitas outras
situações, o transporte transforma-se em um custo considerável para o ciclo de vida. Torna-se
necessária a definição de um Modelo de Transportes.
Como todo órgão está situado em um local geográfico determinado, isto possibilita
determinar qual o percurso a ser percorrido entre os órgãos. Este percurso irá determinar,
principalmente, a distância a ser percorrida, o que irá influenciar no custo do transporte do
material e no tempo necessário para tal.
89
Além do percurso, outro fator preponderante na determinação do custo e do tempo

utilizado será o meio de transporte a ser utilizado. Convém lembrar que nem todos os meios
de transporte estarão disponíveis para os percursos, devendo ser explicitada a relação entre o
percurso e os meios de transporte disponíveis para o mesmo.
Segundo Pilla (2003 p.89), os custos referentes à utilização de “transportes” podem
variar, basicamente, em função:
• Da distância percorrida;
• Do tipo de transporte utilizado;
• Das características do item transportado (peso, volume, valor, etc.); e
• Do tipo de recurso transportado.
Não só os produtos componentes do sistema, mas qualquer recurso utilizado pelo

mesmo deverá ter seu custo de transporte avaliado, tal como o transporte de mão-de-obra, que
muitas vezes fica em alojamentos distantes do setor de produção, como em minas de extração
de minerais.
Logo, deverá haver o relacionamento entre o percurso, o transporte a ser utilizado e o
recurso transportado. Este modelo pode ser observado na Figura 24.
Figura 24: Diagrama de Classes para o Modelo de Transporte

90
3.9 CENÁRIO DE ANÁLISE
Segundo Pilla (2003, p.87), um cenário de análise corresponde a um conjunto de

suposições gerais que devem ser adotadas no cálculo do custo de ciclo de vida e definem:
• Os parâmetros gerais que devem ser considerados (por exemplo, “tempo de ciclo
de vida do projeto”, “data de início do projeto”, “taxa de inflação”, “taxa de
desconto”, etc.);
• Os órgãos que poderão demandar e executar atividades;
• A cadeia de apoio entre os órgãos (estrutura de apoio/manutenção);
• A quantidade e o perfil de funcionamento dos produtos nos órgãos operativos;
• O calendário do ciclo de vida do produto em cada órgão operativo dentro do

cenário (entrada em operação, atualizações, retirada de operação, etc.).
No trabalho desenvolvido por Cople (2004), manteve-se a caracterização inicial do

cenário, mas foram feitas várias mudanças nos elementos relacionados de forma a viabilizar a
simulação dos estoques e a política de manutenção em termos da localização geográfica, o
que facilita inclusive a simulação dos meios de transporte. Inicialmente, definem-se duas
estruturas relacionadas ao cenário, que são:
• Estrutura de Abastecimento, determinando a origem dos componentes

sobressalentes para cada órgão no cenário;
• Estrutura de Manutenção, determinando a hierarquia dos órgãos que efetuam

manutenção.
Ambas as estruturas podem ser observadas no modelo de classes da Figura 25, onde
são resumidas nos relacionamentos referentes a manutenção (mantém, é mantido) e
abastecimento (abastece, é abastecido).
91
Figura 25: Diagrama de Classes Alterado para Cenário de Análise
Dentro de um cenário são definidos os sistemas a serem construídos ou operados pela

organização, sistemas estes que funcionam como foco da ACCV. Um sistema estará
associado a um órgão, podendo ser projetado pelo mesmo, em uma fase onde se encontra
como um elemento virtual, ainda não adquirido nem instalado, ou operado pelo órgão, em
uma fase onde se encontra como um elemento físico, já instalado e sujeito às falhas
decorrentes do uso.
Outro fato a se considerar é o de que, muitas vezes, vários sistemas operam em um
mesmo local de forma idêntica, como é o caso de máquinas industriais sendo operadas com
um horário semanal pré-estipulado. Uma classe adicionada à modelagem para facilitar este
tipo de configuração foi “Grupo_Sistema”, a qual define um conjunto de sistemas de um
mesmo tipo relacionados a determinado órgão dentro do cenário, individualizados dentro do
grupo pelo número de sua instância.
92
O relacionamento entre sistemas e órgãos dentro de um cenário pode ser visto na

Figura 26. As diferentes formas como a operação pode ser controlada, o que é feito através da
classe “Agenda_Operacao”.
Figura 26: Diagrama de Classes para Sistemas em Cenários
Qualquer produto pertencente a um cenário de análise estará associado a um

determinado órgão deste cenário. Trata-se do detentor de determinado produto ou sistema,
que pode ser um estoque, ou um órgão operacional. Esta característica possibilita um melhor
mapeamento do local para envio dos componentes que sofreram manutenção ou acabaram de
ser adquiridos, com a identificação dos órgãos aos quais os mesmos pertencem.
Vale lembrar que o detentor de um determinado produto não é o mesmo durante todo
o ciclo de vida, pois durante as atividades de manutenção alguns componentes podem ser
obtidos em órgãos de estocagem, passando a funcionar junto ao sistema, e passando a
pertencer ao órgão operacional, e os elementos que sofreram manutenção podem ser
adicionados aos estoques existentes.
Definidos os sistemas e órgãos pertencentes ao cenário, torna-se necessário, para a
ACCV, a determinação das atividades que ocorrerão. Aqui o modelo original sofreu o
acréscimo de um terceiro órgão para a execução das atividades, tratando-se do detentor do
produto que será alvo da atividade.
Para Cople (2004), deve ser formalizada a distinção entre órgão executor e gerador da
atividade. Isto pode ser visualizado no diagrama de classes da Figura 27, onde a classe
“Atividade_Produto_Orgao_Cenario_Executa” se refere às atividades que podem ser
executadas no órgão, e a classe “Atividade_Produto_Orgao_Cenario_Gera” se refere às
93
atividades que podem ser geradas no órgão. As possibilidades de geração de atividades pelo
Orgao1 e execução das mesmas pelo Órgão2 serão expressas pela classe de relacionamento
“Atividade_Produto_Orgao1_Orgao2_Cenario”.
Figura 27: Diagrama de Classes para Atividades sobre Produtos no Cenário
Em um segundo nível, as possibilidades de geração e execução de atividades são

relacionadas aos componentes do sistema pertencente a um determinado órgão através do
relacionamento “Atividade_Prod_Orgao3_Gerada_Orgao1_Executada_Orgao2”.
3.10 MODELO DE EVENTOS
Segundo Pilla (2003), entende-se por “evento” uma ocorrência de execução de uma
“atividade”, relacionada a um “produto”, num determinado instante do tempo do ciclo de
vida. Um “modelo de geração de eventos” é utilizado na previsão dos instantes de tempo de
ocorrência dos diversos eventos relacionados a uma atividade ou, mais genericamente, da
quantidade de eventos a serem executados num determinado intervalo de tempo.
A Figura 28 exibe as classes básicas do modelo de geração de eventos.
ModeloGeraçãoEventos_AtividadeProduto 1 0..* Evento
Modelo de Geração de Eventos Ati vi dade_Produto_Órgão1_Órgão2_C enário

0..* 0..*
Figura 28: Modelo de Geração de Eventos

94
É o modelo de geração de eventos que irá determinar a distribuição das atividades ao

longo do tempo e, conseqüentemente, do gasto de recursos e distribuição dos custos, devido à
execução das mesmas.
Para Cople (2004), um modelo de eventos visa a determinação do instante de início de
uma determinada atividade, envolvendo um complexo conjunto de elementos. Na alteração
efetuada por Cople, os modelos de eventos foram direcionados para as atividades às quais se
relacionam.
Inicialmente considera-se que os eventos possam se referir a atividades sobre produtos
virtuais. Estes modelos baseiam-se em programações definidas pelo analista de ACCV, com
instantes de execução definidos em calendário, tempo corrido definido, ou segundo uma
distribuição estatística para tempo corrido, sem a necessidade de aquisição de produtos e,
conseqüentemente, sem interferir ou depender do estado dos mesmos.
Outra grande divisão se refere aos eventos que iniciam atividades sobre produtos reais,
os quais podem ser definidos em termos de uso ou de tempo corrido, segundo tempo
especificado ou distribuições, e, para tempo corrido, também em termos de datas.
Um comportamento especial deve ser observado no que concerne às atividades de
operação, pois as mesmas são definidas em termos de regras pré-estabelecidas, segundo o que
se espera do sistema em termos de produção, relacionando-se à geração de eventos
diretamente às regras adotadas. Este tipo de evento refere-se a instâncias de sistema já
instaladas e segue os tempos determinados pela classe “Agenda_Operação”.
Finalmente, os modos de falha definem eventos relacionados a manutenções
corretivas, dependentes da utilização do sistema e apoiados por um modelo de eventos
próprio, que obtém os instantes de ocorrência das atividades a partir das distribuições
especificadas nos relacionamentos compreendidos pela classe “Modo_Falha_Produto”.
Os modelos citados podem ser observados na Figura 29, e as atividades às quais se
aplicam, segundo o modelo atual, podem ser vistas na Tabela 4.
95
Figura 29: Diagrama de Classes Expandido para Modelo de Geração de Eventos
Tabela 4: Relacionamento entre Atividades e Modelos de Eventos
Modelo de Eventos
Atividade Data Determinado Determinado Aleatório Aleatório Falha Operação
por Tempo por Uso por Uso por Tempo
Projeto Sim Sim Não Não Não Não Não
Aquisição Sim Sim Não Não Não Não Não
Manufatura Sim Sim Não Não Não Não Não
Instalação Sim Sim Não Não Não Não Não
Operação Não Não Não Não Não Não Sim
Treinamento Sim Sim Não Não Não Não Não
Atualização Sim Sim Não Não Não Não Não
Manutenção Não Sim Sim Sim Sim Não Não
Preventiva
Manutenção Não Não Não Não Não Sim Não
Corretiva
Descarte Sim Sim Não Não Não Sim Não
96
Observa-se a ausência da atividade de transporte neste relacionamento com os

modelos de eventos. Isto se deve ao fato de que este tipo de atividade é iniciado
automaticamente quando a mesma se torna necessária, ou seja, nos momentos em que o
executor é diferente do gerador da atividade.
Assumida esta divisão dos modelos pode-se buscar um comportamento específico para
os planos de atividades a serem executadas, e as diferenças entre eles. O único modelo de
eventos que não compreende um plano de execução é o de manutenções corretivas, devido ao
fato de que as mesmas ocorrem a partir da ocorrência de falhas, sendo suas regras de
ocorrência definidas pelas mesmas.
De acordo com o perfil das atividades iniciadas, os planos de atividades podem se
subdividir em:
• Plano de Atividades de Projeto, relacionado às atividades de planejamento do

sistema, ainda em sua fase virtual;
• Plano de Aquisição, que se refere à aquisição inicial de componentes, tanto para o

sistema quanto para o estoque de sobressalentes;
• Plano de Manufatura, referente às ações de construção do sistema em si;
• Plano de Instalação, buscando organizar as atividades de construção do sistema

anteriormente projetado;
• Plano de Operação, que determinará toda a operação ideal do sistema, durante

seu ciclo de vida;
• Plano de Manutenção Preventiva por Calendário, referente às manutenções

previstas em instantes específicos;
• Plano de Manutenção Preventiva por Uso, referente às manutenções devido ao

uso do sistema;
• Plano de Descarte, referente ao descarte de componentes durante a desativação do

sistema;
• Plano de Atualização, referente às modificações efetuadas na estrutura e

funcionamento do sistema ao longo de seu ciclo de vida;
• Plano de Treinamento e Reciclagem, referente às atividades de treinamento que

ocorrem durante o ciclo de vida do sistema.
97
O “Plano de Atividades de Projeto” engloba as atividades relacionadas ao

planejamento do sistema, seus componentes e estrutura, com o objetivo de efetuar as funções
para as quais foi determinado.
Neste modelo, apenas os órgãos de desenvolvimento são capazes de desenvolver
projetos de sistemas, devendo o órgão desenvolvedor ser caracterizado como tal. Isto se deve
ao fato de que atividades de projeto exigem estruturas e pessoal especializado, não podendo
ser utilizada uma estrutura operacional simples.
O órgão de desenvolvimento pode utilizar equipamentos complexos que, segundo a
necessidade da análise considerada, podem sofrer manutenções dentro da estrutura de apoio
do cenário.
Para o “Plano de Treinamento”, não existe a necessidade da existência física do
sistema, podendo ser efetuado antes da aquisição e instalação do mesmo, porém não antes das
atividades de projeto serem completadas. É claro que existe a possibilidade de treinamento
prático, para os quais o sistema pode ser requerido para se efetuar a atividade.
O “Plano de Aquisição de Componentes” apenas escalona a aquisição dos mesmos
dentro do cenário. Assume-se que a aquisição de sistemas e a dotação inicial devem ser
direcionadas diretamente para os órgãos operacionais, não devendo passar pelo órgão de
abastecimento principal, ao contrário da reposição de sobressalentes, de acordo com a política
de aquisição adotada. Se o problema envolve a manufatura dos equipamentos que compõem o
sistema, os componentes devem ser enviados a um órgão de abastecimento ou diretamente ao
órgão de manufatura.
A aquisição de componentes envolve custos relacionados ao preço dos mesmos e à
distância dos fabricantes e meios de transporte utilizados. Além disto, pode-se considerar
também o aumento do custo de transporte de um componente pelo próprio valor do mesmo,
quando é considerada a apólice de seguro referente à carga transportada.
Vale lembrar que apenas componentes pertencentes aos sistemas analisados serão
aceitos na dotação de sobressalentes.
O “Plano de Manufatura” e o “Plano de Instalação” tratam também de planos de
escalonamento simples, considerando atividades pré-definidas para a manufatura, instalação e
configuração do sistema, com a observação de que os instantes referentes aos processos de
manufatura e instalação serão obrigatoriamente posteriores aos instantes de aquisição
determinados no “Plano de Aquisição de Componentes” para os produtos envolvidos no
processo.
98
Os planos que lidam com atividades diretamente relacionadas ao sistema trabalham

com instâncias diferenciadas do mesmo, podendo assumir diferentes modelos de eventos para
cada instância. Estes planos são: Aquisição (no que se refere a sistema), Manufatura,
Instalação, Operação, Atualização, Treinamento (apenas para treinamento prático) e Descarte.
O “Plano de Descarte” irá definir o momento em que cada instância do sistema será
desativada, assim como o “Plano de Atualização” determinará o momento para atualização,
envolvendo tanto atividades sobre elementos virtuais (que não dependem de instâncias), tais
como o projeto da atualização, como atividades sobre as instâncias em si.
Quanto à operação, definida no “Plano de Operação”, esta já se diferencia das demais
pela simples forma com que é configurada, a partir da agenda de operação.
O “Plano de Manutenções em Calendário” define os momentos em que as ocorrências
físicas de produtos instalados em sistemas, ou sistemas em si, deverão passar por atividades
de manutenção preventiva, independente da instância considerada. Ou seja, admite uma regra
geral válida para todas as instâncias.
O único plano que realmente apresenta uma grande diferença em relação aos demais é
o “Plano de Manutenções por Uso”, pois, ao considerar a utilização do equipamento, inicia
eventos de manutenção que afetam a operação do próprio sistema, alterando o instante em que
novas falhas e novas manutenções ocorrerão.
A divisão dos planos de execução de atividades pode ser observada na Figura 30,
assim como os modelos de geração de eventos aplicáveis a cada um, e a Tabela 5 exemplifica
a configuração para planos de execução de atividades.
99
Figura 30: Diagramas de Classes para o Plano de Execução de Atividades
Tabela 5: Configuração de Planos de Execução de Atividades (Parcial)
Atividade Órgão Produto Instância Modelo de Eventos Configuração

Desenvolvimento Fabricante SIST1 Tempo Corrido Instante = 2000 hrs
Determinado
Aquisição Todos de Estoque Data Instante = 01/01/2002
Abastecimento Inicial
Operacional-RJ SIST1 1,2
Operacional-SP SIST1 1,2,3,4
Operação Operacional-RJ SIST1 1,2 Eventos para Operação Opera 36 hrs / Espera 12 hrs
Operacional-SP SIST1 1 Eventos para Operação Opera 16 hrs / Espera 8 hrs
2 Eventos para Operação Opera 36 hrs / Espera 12 hrs
3 Eventos para Operação Média de 50 missões por ano,
com duração em torno de 3 dias
por missão
4 Eventos para Operação Média de 10 missões por ano,
com duração em torno de 15 dias
por missão
100
3.11 MODELO DE CONSUMO DE RECURSOS
Para a execução de atividades, são consumidos recursos, como por exemplo, horas de
trabalho de técnicos durante a manutenção, documentação necessária às atividades de
desenvolvimento, ou a utilização de embalagens específicas no transporte de componentes.
Um “modelo de consumo de recursos” define a forma como os recursos serão
utilizados ao longo da execução das atividades. Segundo Pilla (2003, p. 98), este modelo é
utilizado na previsão da quantidade total a ser consumida de um determinado recurso na
execução de um evento. Essa quantidade é representada nos objetos da classe
“RecursoRequerido_AtividadeProduto”, como pode ser observado na Figura 31.
RecursoRequerido_AtividadeProduto
Rec_Ativ_Prod_Org1_Org2_Cen 0..* 0..* Modelo de Consumo de Recurso
Figura 31: Diagrama de Classes para o Modelo de Consumo de Recursos
O único aprimoramento feito por Cople (2004) com relação ao “modelo de consumo
de recursos” foi a caracterização da utilização do recurso, sendo a mesma explicitada a seguir:
1. Recurso que depende do tempo da atividade; e

2. Recurso que não depende do tempo da atividade.
A utilização por tempo caracteriza alguns tipos de serviços, instrumentos especiais e

mão-de-obra, sendo definida pela quantidade necessária de elementos simultâneos e o
percentual da utilização dos mesmos ao longo da execução da atividade.
Este tipo de utilização terá implicação no dimensionamento da quantidade de recurso a
ser adquirido para que o sistema possa funcionar. Exemplos desses recursos são mão-de-obra,
conjuntos de ferramentas alocados à mão-de-obra e equipamentos de apoio que tem uso
compartilhado.
101
O consumo independente do tempo se refere aos elementos gastos durante a execução

da atividade, como transistores, sacos plásticos e outros.
Determinando, por este modelo, o montante do recurso que é utilizado para dado
intervalo de tempo, onde é executada a atividade, podem ser definidos os custos que incorrem
sobre o mesmo. Este é um assunto tratado nas duas próximas seções.
3.12 MODELO DE CÁLCULO DE CUSTO
Para Pilla (2003 p.99), um “modelo de custo de recursos” é utilizado na previsão dos
valores relativos a um “rec_ativ_prod_org1_org2_cen” na execução de um evento, utilizando,
em geral, os resultados do “modelo de consumo de recursos” (ou seja, a quantidade de recurso
a ser consumida na execução de um evento) e os multiplicando pelo custo unitário de
aquisição (atributo do “recurso”), como pode ser observado na Figura 32.
Elementos de Custo
R ecursoCon sumi do_AtividadeProduto Modelo de Custo de Recurso

0. .* 0..*
Figura 32: Diagrama de Classes para Modelo de Cálculo de Custo
Os custos aferidos pelo “modelo de cálculo de custo” ocorrem, de uma maneira geral,
durante todo o intervalo de tempo de duração da atividade. Este custo é obtido pelo valor do
recurso multiplicado pelas horas de utilização, para recursos que dependem do tempo, ou
quantidade adquirida do recurso multiplicado pelo preço de compra, para recursos que são
gastos durante a atividade, independentemente do tempo.
Para o caso dos recursos que não dependem do tempo, estes têm seu custo
determinado no instante inicial da atividade, tratando-se de um gasto pontual, enquanto o
custo de recursos que dependem do tempo, como o caso de mão-de-obra, por exemplo, onde
ocorre um instante inicial e um período de utilização, o custo deve ser distribuído ao longo do
intervalo segundo uma curva de distribuição de custos.
102
3.13 REGIMES DE OPERAÇÃO DE SISTEMAS
Sistemas distintos podem apresentar regimes diferentes de operação. Do ponto de vista

da ACCV, a relevância desses regimes de operação está relacionada com o impacto da
disponibilidade na capacidade produtiva do sistema e, conseqüentemente, no custo
relacionado à perda de produção.
Os tipos básicos de regimes de operação são os seguintes:
1. por missão completa;

2. operação contínua; e
3. operação agendada.
No regime de missão completa há um roteiro determinado de tarefas a serem

cumpridas pelo sistema, caracterizando ciclos completos, tais como viagens de avião e navio.
Isto se diferencia de sistemas com operação contínua, onde existe apenas uma missão, sendo
cumprida ao longo de todo o ciclo operacional do sistema, como em sistemas de segurança
24x7, plataformas de exploração “off-shore”, siderúrgicas etc.
A operação agendada caracteriza-se por ciclos de operação com início e fim definidos,
repetindo-se segundo regras pré-definidas. Exemplos deste tipo de operação são fábricas, em
geral, onde há um horário definido para o funcionamento do sistema e conseqüente utilização
dos operadores do mesmo.
Além do perfil de operação, a regra de operação pode permitir o deslocamento ou
cancelamento da operação do sistema, no caso de haver uma inoperância qualquer. Claro que,
para sistemas de missão completa, a operação só permitirá deslocamento se este não causar
uma sobreposição de missões. Pode ser definida uma faixa de segurança para evitar a junção
de missões até um tempo viável para a operacionalização do sistema.
A regra de operação adotada no software desenvolvido é a de cancelamento de trechos
de operação no caso de falhas, e o perfil de operação é controlado pela classe
“Agenda_Operacao”, responsável pela determinação dos instantes em que o sistema estará
produzindo durante todo o seu ciclo de vida, para um plano de operação ideal.
103
As classes para agendamento de operação podem ser observadas na Figura 33, e

apresentam as seguintes características:
1. “Agenda_Periodo” define os períodos em que o sistema deverá estar operando e

aqueles onde ele deverá esperar pelo próximo ciclo de operação;
2. “Agenda_Frequencia” determina o número médio de missões ao longo de cada
ano, e a duração média de cada missão, determinando as missões através de
distribuições estatísticas baseadas nestes parâmetros; e
3. “Agenda_2424” determina operação ininterrupta, iniciando na instalação e indo até
a fase de descarte.
Figura 33: Diagrama de Classes para Agenda de Operação de Sistemas
A operação do sistema é apenas uma das atividades analisadas para cálculo de ACCV,
e refere-se ao período em que o sistema está disponível e produzindo algo. As demais
atividades e sua influência sobre a operação definirão a variação do custo original de
produção.
Segundo Pilla (2003), pode-se dividir as atividades relacionadas ao sistema em três
grandes grupos:
1. Na fase de Produção/Construção os equipamentos principais e de apoio, a infra-

estrutura e os softwares previstos no projeto são adquiridos, integrados, avaliados e
testados. São realizadas, também, as atividades que pertinem à preparação do
sistema para sua introdução em serviço (aprovisionamento, instalação,
comissionamento, treinamento etc.);
2. Na fase de Operação e Apoio são executadas as atividades finalísticas de operação
e as atividades de apoio logístico (que têm como objetivo manter as condições de
104
disponibilidade do sistema principal, provendo todos os recursos necessários ao

seu funcionamento e manutenção); e
3. A fase de Retirada de Operação e Descarte representa o final do ciclo de vida e
ocorre quando as características do projeto já não permitem o atendimento dos
objetivos ou quando a sua continuidade se torna economicamente inviável.
Durante a fase de operação e apoio, pode ser necessário fazer atualizações em

componentes do sistema (modernizações), o que implica em executar atividades próprias da
fase de Produção/Construção.
As atividades de apoio logístico, executadas na fase em que o sistema está operando e,
conseqüentemente, pode apresentar falhas, terão interferência direta sobre a operação do
mesmo, causando deslocamento ou cancelamento de um período operacional, de acordo com
a regra de operação adotada. Esta alteração no planejamento de operação do sistema irá afetar
a disponibilidade do mesmo.
As falhas que ocorrem durante a operação do sistema levam à necessidade do
acompanhamento dos produtos componentes do mesmo ao longo de suas vidas através de
uma técnica aqui definida como Linha de Vida, onde ocorre o armazenamento do histórico do
componente, desde sua aquisição até o momento do descarte.
105
4. ARQUITETURA E EXTENSÃO DO NOVO FRAMEWORK
4.1 INTRODUÇÃO
Embora o Modelo de Pilla e Cople ainda seja a referência básica para a criação do
novo framework, foram efetuadas profundas mudanças em relação à versão original no que
tange ao estilo de programação, arquitetura de software e distribuição de processamento.
A mudança no estilo de programação, com a incorporação de elementos genéricos e
anotações, objetivando aumentar o nível de reuso, assim como a adoção de padrões de
desenvolvimento de forma pontual, trouxe a necessidade de uma completa reestruturação do
código original, mas os conceitos principais foram mantidos nesta nova abordagem.
O novo framework apresenta os mesmos níveis de abstração do original, bem como se
utiliza amplamente da reflexividade, porém uma novidade aqui é a utilização do padrão de
desenvolvimento Factory Method para o encapsulamento dos processos reflexivos, o que
proporciona a centralização destes processos, facilitando o uso e a manutenção.
Outra característica relevante é que, com a mudança na forma de programação da nova
versão, as classes nativas foram modificadas e, conseqüentemente, os arquivos XML não são
mais necessários para a adição de novas classes, passando a ser utilizadas anotações na
extensão do novo framework.
Em termos arquiteturais, houve grande preocupação em organizar as classes
internamente, dentro de uma arquitetura MSVC, bem como em oferecer meios que viabilizem
a interoperabilidade.
Ao contrário da versão antiga, onde existia apenas a interface cadastral criada em
Java, o novo framework está aberto para o desenvolvimento de interfaces cadastrais
customizáveis em qualquer linguagem, visando aumentar a interoperabilidade e o reuso da
ferramenta como gestora de dados e processos de cálculo. Este novo comportamento foi
obtido com o uso de Web Services.
106
Como a eficiência da execução dos cálculos da versão original e a qualidade da

apresentação de resultados não se demonstraram satisfatórios, o novo framework apresenta
modificações em três dimensões distintas:
• Processo de Cálculo, o qual passa a incorporar técnicas de processamento

distribuído em rede, permitindo a execução de um maior número de simulações no
mesmo tempo original, o que permite refinar a média de resultados globais;
• Fornecimento de Resultados Analíticos, com acompanhamento pontual dos
eventos simulados e elementos financeiros associados para cada simulação
efetuada, permitindo visualizar todo o histórico de atividades simuladas; e
• Fornecimento de Resultados Sintéticos, tanto para cada simulação individual
quanto para a média das simulações efetuadas, com os dados sintetizados em
termos de uma estrutura de desdobramento de custos.
A metodologia de cálculo do framework não foi modificada, pois se mostrou adequada

na versão original, porém a forma com que este cálculo é implementado sofreu modificações
para abranger novas possibilidades de processamento paralelo, inclusive no nível de rede.
Neste novo trabalho, embora a execução continue seqüencial, a gravação de dados em
meio à execução foi substituída pelo envio assíncrono de dados, em processos paralelos, além
de se utilizar de processamento distribuído, com o uso de várias máquinas executando
múltiplas simulações.
O fornecimento de resultados nesta nova versão utiliza formato XML, viabilizando a
criação de interfaces visuais independentes de linguagem, e permitindo que recursos gráficos
avançados e frameworks para criação de relatórios sejam utilizados para personalizar a
exibição de resultados.
Como a interface de transmissão e recepção de dados do novo framework foi
totalmente criada com base em Web Services, o tipo de dado transmitido é no formato XML
envelopado para o SOAP, permitindo a integração direta do mesmo com as mais diversas
ferramentas, inclusive com a geração automática das classes necessárias do lado cliente em de
ambientes mais avançados, como o Flex, a partir do arquivo WSDL. O Anexo B descreve o
funcionamento dos Web Services e os formatos aqui citados.
107
4.2 MODIFICAÇÕES ARQUITETURAIS
Uma mudança inicial na nova versão do framework foi a substituição do JDBC

tradicional, no módulo de integração, pelo uso de JPA, intermediado pelo JEE5, frameworks
descritos no Anexo B, segundo o padrão de desenvolvimento Session Facade, deixando o
software completamente independente da base de dados utilizada, como pode ser observado
na Figura 34. Outras alterações efetuadas no módulo de integração envolvem acréscimo de
serviços de localização (padrão Service Locator) e suporte a Web Services.
Figura 34: Novo modelo de persistência
Na nova arquitetura são mantidos os módulos originais e seus relacionamentos, porém

o uso de Web Services dentro de uma arquitetura SOA divide a funcionalidade do framework
em cinco serviços distintos, disponibilizados para o desenvolvedor:
1. Intermediação de dados cadastrais

2. Construção de Cenários
3. Execução de Simulações
4. Fornecimento de resultados
5. Geração de código-fonte
A mudança da estratégia de fornecimento de recursos, originalmente através de

interfaces Java, para Web Services, além de permitir um nível de interoperabilidade muito
alto, ainda permite o reuso de serviços através de orquestrações com BPEL, o que irá
108
viabilizar a criação de processos extremamente complexos com o uso combinado de todos os

serviços expostos.
O serviço de intermediação de dados cadastrais permite a qualquer desenvolvedor a
criação de interfaces visuais para cadastro de dados de catálogo genéricos, ou focados em
problemas específicos da empresa onde trabalha, com independência de linguagem,
garantindo a interoperabilidade com ferramentas de criação como Flex, Delphi, Visual C#, ou
qualquer outra com suporte a Web Services. A construção de cenários segue o mesmo
princípio, permitindo a criação de modelos de cenários parametrizados específicos para os
objetivos de análise de cada empresa.
Como o protocolo SOAP, utilizado pelos Web Services, baseia-se em informações no
formato XML, o framework passa a intermediar dados neste formato, com a localização de
serviços via UDDI e disponibilização do formato de chamada via WSDL. Maiores detalhes
sobre Web Services e SOA podem ser observados no Anexo B.
Os elementos arquiteturais associados aos serviços de intermediação de dados e
construção de cenários podem ser observados na Figura 35.
Figura 35: Serviços de Intermediação de Dados e Construção de Cenários

109
Para demonstrar a possibilidade de personalização de interfaces cadastrais, foi criada

uma interface cadastral para o novo framework com utilização de Flex através da IDE do
Flash Builder. Da mesma forma que a interface cadastral original, descrita em detalhes no
trabalho de Cople (2004), a nova interface é alterada dinamicamente em tempo de execução,
adaptando-se ao formato das entidades, o que viabiliza a extensão do framework sem a
preocupação de se criarem novas telas, sendo aplicável a um amplo espectro de problemas de
ACCV, mas caso haja necessidades específicas o uso do formato XML para transmissão de
dados e descrição das chamadas dos serviços do novo framework, conseqüência da utilização
de Web Services, permite aos desenvolvedores de praticamente qualquer linguagem de
mercado atual criar telas voltadas para problemas específicos.
A apresentação de resultados referentes às simulações efetuadas, que originalmente era
muito pobre, baseada em pequenos sistemas Delphi e Java com acesso direto à base de dados,
será totalmente reformulado, preocupando-se agora apenas com a exportação dos dados em
formato XML, a partir de um Web Service, mas ao mesmo tempo aumentando a
interoperabilidade, da mesma forma que a alteração efetuada no modelo cadastral, o que
permitirá exibir estes dados exportados nas mais diversas plataformas para geração de
gráficos e relatórios. Uma descrição dos extratores de dados antigos pode ser obtida no
trabalho de Cople (2004).
No novo modelo, com a utilização de paralelismo, foi implementado o conceito de
grupo de simulações para cada cenário, podendo ser observado o comportamento de uma
simulação individual do grupo em termos analíticos, com o acompanhamento dos eventos
ponto a ponto, ou de forma sintética, com a análise dos elementos financeiros aferidos com
base em uma estrutura de desdobramento de custos. Da mesma forma, a análise sintética pode
ser efetuada sobre o conjunto de simulações completo, obtendo uma média comportamental
que deverá se aproximar muito mais da situação real.
Os extratores antigos ainda poderão ser utilizados com algumas adaptações, mas se
tornaram irrelevantes perante o nível de detalhe obtido com a nova versão. A Figura 36
apresenta a nova arquitetura e o posicionamento dos extratores antigos em relação aos que
serão criados.
110
Figura 36: Serviços de Extração de Resultados
O uso de várias simulações simultâneas, com o objetivo de atingir um resultado

agregado próxima da realidade, segue a estratégia de Simulação de Monte Carlo. Para
satisfazer a este novo modelo, com um grande número de simulações sendo executadas, seria
inviável a utilização de apenas uma máquina processando as simulações.
Na versão original do framework ocorria apenas o paralelismo entre simulações
independentes no próprio servidor, aproveitando as inatividades do processador decorrentes
de acessos ao meio de armazenamento, o número de processadores do servidor, e as estruturas
internas de pipeline dos processadores atuais.
Na nova versão a intenção inicial era utilizar o processo de simulação distribuída
baseado na comunicação remota via RMI, que segue a arquitetura Broker, descrita no
Anexo B, porém foi observado que o uso de RMI aumentava a complexidade da solução de
forma desnecessária, já que não há necessidades transacionais para a transmissão de cenário e
111
recepção de resultados, além de diminuir a eficiência das transmissões, com o acréscimo de

processamento que ocorre com o uso de Stubs e Skeletons.
A solução adotada para implementar a distribuição de processamento no novo modelo
foi a utilização de Socket padrão, com máquinas cliente utilizando software de suporte
instalado, e registro destas máquinas no servidor de simulações, segundo uma arquitetura
Cliente-Servidor comum.
A estratégia de distribuição de processamento pode ser observada na Figura 37.
Figura 37: Arquitetura de Distribuição de Processamento
Cada máquina cliente executa simulações de forma independente, aproveitando ainda

o paralelismo interno de cada máquina, como ocorria na versão original em relação ao
servidor. Com isto, podem ser criados grupos de simulações, obtendo-se a média
comportamental para os mesmos.
Como Web Services não armazenam informações de estado, foi gerado um registro em
banco de dados na solicitação inicial do serviço de simulação que funciona como token, sendo
utilizado nas chamadas subseqüentes para obtenção das informações acerca do andamento da
execução das simulações dentro do novo ambiente distribuído.
O novo framework disponibiliza um serviço para solicitação de execução de grupos de
simulações, o qual também provê acompanhamento do percentual de conclusão das
solicitações. A arquitetura de fornecimento do serviço pode ser observada na Figura 38.
112
Figura 38: Serviço de Gerenciamento de Simulações
Desejava-se que o processo de adição de classes seguisse o mesmo padrão adotado na

versão original, com base em XML, desde que o formato do arquivo fosse alterado para se
tornar compatível com outros padrões de mercado, definindo um dicionário do tipo DTD ou
XSD, formatos descritos no Anexo B. Isto permitiria que desenvolvedores independentes
criassem ferramentas CASE para a geração destes arquivos XML, ou até mesmo que
ferramentas de importação e exportação fossem criadas para as ferramentas CASE atuais,
aproveitando uma base já consolidada de ferramentas de modelagem.
Infelizmente não foi possível concretizar esta etapa, devido às restrições de tempo para
a concretização do projeto, mas o uso de anotações acabou por se demonstrar bastante simples
para os desenvolvedores Java nas tarefas relativas à extensão do framework.
As classes internas são anotadas, o que permite a extensão direta em Java, com pouco
esforço computacional. Estas anotações constituem o mecanismo necessário para que o
113
framework identifique qualquer necessidade de se adicionar entradas na base de dados

representativa dos metadados das entidades, da mesma forma que ocorre no JPA.
Com isto o serviço de geração passou a receber apenas o nome completo da classe, o
identificador e o código-fonte, sendo a arquitetura idealizada apresentada na Figura 39.
Figura 39: Serviço de Criação de Classes
É através desses metadados que as telas cadastrais são criadas de forma dinâmica,
possibilitando grandes avanços estruturais sem a necessidade de esforços computacionais
referentes às interfaces. É conveniente lembrar que a busca por ambientes com maior
usabilidade e qualidade gráfica acaba por demandar esforços computacionais para o design
que podem se sobrepor àqueles ligados ao negócio em si, e isto não é uma exceção.
114
As próprias ferramentas de desenvolvimento de interfaces, como Flex e Visual C#,

apresentam ferramentas para reconstrução das classes utilizadas nas assinaturas dos métodos
expostos pelos Web Services, a partir da WSDL de cada um. Em ambas, após a configuração
de acesso ao Web Service os métodos providos são expostos na IDE, permitindo que o
desenvolvedor “arraste” o elemento visual representativo deste método até o componente
visual que será responsável pela exibição dos dados recebidos, sem a necessidade de nenhuma
programação (ou quase).
4.3 PROCESSAMENTO DISTRIBUÍDO
O principal problema enfrentado para se definir uma estratégia de distribuição neste

framework é o fato de que as novas classes criadas pelos desenvolvedores, aquelas geradas a
partir dos pontos de flexibilização, devem estar presentes no cliente de distribuição de
processamento, pois as mesmas são utilizadas no processo de simulação.
Considerando-se este fato, foi definida uma estratégia em oito fases:
1. Cliente ativa o módulo ouvinte, registra sua presença no servidor RMI e fica
disponível para receber solicitações de execução;
2. Um lote de simulações é iniciado e os clientes contatados;
3. Cada cliente contatado verifica sua versão das classes especializadas e atualiza o
que for necessário, fazendo download da versão mais atual de cada arquivo binário
cadastrado;
4. Estando atualizado, o cliente inicia o módulo de execução, o qual solicita o cenário
ao servidor;
5. Após o servidor enviar o cenário, passa a delegar tarefas para os clientes,
fornecendo apenas a semente de randomização e o identificador da tarefa para cada
simulação a ser executada;
6. Para cada semente recebida o cliente inicia uma tarefa para execução da simulação,
aproveitando o paralelismo da máquina;
7. O servidor é informado do andamento de cada tarefa, levando em consideração o
instante do evento simulado em comparação ao tempo total simulado, para cada
ponto percentual executado; e
8. Ao final de cada simulação executada os resultados são transferidos para o
servidor.
115
Este é um modelo de execução seqüencial múltipla, apoiado por processamento

paralelo e distribuído, constituindo um meio de “força-bruta” para a obtenção de uma grande
quantidade de simulações e resultados médios teoricamente mais próximos da realidade,
como no processo de Monte Carlo.
Como os clientes não utilizam servidores EJB, eles recebem apenas as classes de
catálogo e o núcleo de cálculo de simulação, agrupados em uma biblioteca denominada
“EngineACCV.jar”, além das classes definidas pelo desenvolvedor.
O mesmo acabou por ocorrer com o servidor, que segundo a arquitetura inicial deveria
acessar a camada de persistência através dos componentes EJB, recuperando os dados de
catálogo, e através do processo de reflexividade montar o cenário de simulação completo,
transmitindo o mesmo para os clientes de forma serializada.
Esta arquitetura idealizada para o servidor não obteve o sucesso esperado, e assim
como citado anteriormente neste capítulo, o uso de RMI acabou por aumentar a complexidade
sem ganhos reais. Como solução, foi criado mais um Web Service para prover os dados
necessários, e o servidor foi dividido em três serviços internos, cada um listando uma porta
específica.
Esse Web Service, denominado “UtilServer”, efetua as consultas necessárias no
ambiente JEE/JPA, criando os objetos de modelo equivalentes por reflexividade, e
serializando os resultados em seqüencias de bytes, as quais acabam por ser envelopadas no
SOAP antes da transmissão para o servidor.
Os serviços providos pelo servidor de simulações são:
• Porta 2525: Gerador de Solicitações de Simulação (GSS);

• Porta 2526: Coordenador de Simulações em Execução (CSE); e
• Porta 2527: Receptor de Resultados Simulados (RRS).
O primeiro serviço (GSS) se destina a iniciar a execução de novos grupos de

simulações para um determinado cenário, dada uma solicitação de execução efetuada a partir
da interface cadastral.
Cada cliente de simulação se conecta ao CSE, indicando estar disponível para o
servidor e entrando no pool de clientes identificados. Este mesmo serviço repassa as ordens de
execução para os clientes, juntamente com todos os dados do cenário de simulação, além de
acompanhar a evolução destas execuções, enviando a seguir as informações necessárias para a
camada de persistência.
116
O último serviço (RRS) recebe os dados simulados após o término de cada simulação
individual, replicando-os na camada de persistência, de forma a permitir as análises
visualizadas na interface cadastral.
O serviço RRS inicialmente seria uma parte do CSE, mas foi verificado que isto
interferia no acompanhamento das execuções de forma negativa, causando muitos atrasos na
atualização do estado de cada simulação. Por este motivo foi criado um serviço independente
para esta finalidade.
O serviço GSR se comunica com o “UtilServer” para a recepção dos dados do cenário
da simulação desejada, bem como informações do grupo de simulações e registro de controle
para cada simulação individual, enquanto o RRS acessa este Web Service para a transmissão
dos dados obtidos ao término de cada simulação independente. Quanto ao CSE, este utiliza o
“UtilServer” apenas para atualizar a evolução de cada simulação individual, de forma a
permitir o acompanhamento pela interface cadastral.
Este acabou por ser um bom exemplo de uso da interoperabilidade promovida pelos
Web Services, desta vez não entre diferentes linguagens de programação, mas entre dois
ambientes Java distintos: Java Enterprise Edition (JEE) e Java Standard Edition (JSE).
Com relação à cópia das bibliotecas de extensão para o cliente (passo 3 da estratégia
inicial), esta ainda não foi implementada e consta como uma das futuras evoluções a serem
efetuadas para o módulo cliente, mas isto não impede a execução das simulações, devendo
apenas ser observada a necessidade de se copiar as bibliotecas para os clientes, o que pode ser
feito através de simples arquivos script para cada sistema operacional.
Estas bibliotecas de extensão são normalmente pequenas, contando apenas com as
classes de modelo especializadas, já que o pacote de classes nativas (EngineACCV.jar) não é
alterado sem a disponibilização de uma nova versão do framework.
A arquitetura de processamento distribuído desenhada ao final do desenvolvimento
pode ser observada Figura 40.
117
Figura 40: Diagrama completo da arquitetura de distribuição de simulações.

118
A Figura 41 apresenta as telas do módulo cliente e do módulo servidor, além da

relação existente com os serviços e direção do fluxo de dados. O servidor envia solicitações e
acompanha a execução a partir do serviço CSE, que efetua toda a comunicação com a tela
principal do módulo cliente, enquanto cada simulação é executada em uma thread separada
no cliente, havendo sempre uma janela de acompanhamento visual, e o envio de dados
simulados para o servidor nestas threads é feito através do serviço RRS.
Figura 41: Módulos cliente e servidor para execução de simulações.
A thread de simulação do cliente inicialmente utilizava um banco de dados local, com

acesso via JPA para a gravação dos dados simulados antes da transmissão, sendo a gravação
efetuada em background através de outras threads de apoio, aproveitando o paralelismo do
hardware e evitando desperdiçar tempo de processamento com operações de I/O.
No entanto, o uso de banco de dados do lado cliente aumentou a complexidade da
configuração e não trouxe qualquer vantagem relevante para o processo de simulação, pois
era buscada eficiência e não robustez. Isto fez com que houvesse uma alteração no cliente,
que passou a enviar diretamente os dados para o servidor, através das threads de apoio, sem a
gravação anterior em banco de dados.
Com a finalidade de comparar a eficiência da execução foi considerado o cenário de
testes do Anexo D, com quatro processos paralelos, em uma rede interna, onde a máquina
executora da simulação utilizada foi um Phenom 3-Core, com 4GB de memória.
119
Os tempos para comparação utilizados foram o tempo de carga, o tempo de cálculo e o

tempo total de simulação, sendo que a versão original do framework permite apenas a
verificação do tempo total de simulação. Para viabilizar a comparação da versão antiga do
framework foram utilizadas quatro instâncias do software executando paralelamente, já que o
mesmo não trabalhava com paralelismo.
Para a versão nova com transmissão direta, sem JPA no cliente, foram executadas duas
rodadas de testes, onde ficou clara uma grande variação no tempo de cálculo, agora sem
interferência dos tempos de I/O, isto devido à grande aleatoriedade dos fatores estocásticos
presentes no modelo de simulação.
Ao final foi observada uma redução do tempo total na ordem de 47% para a versão
nova sem JPA no cliente, quando comparada com a versão com JPA, e de 91%, quando
comparada com a versão original do framework.
A Tabela 6 apresenta os resultados dos testes, sendo os tempos representados no
formato minutos:segundos (mm:ss).
Tabela 6: Comparação entre as implementação para simulação da ACCV
Executor Tempo de Carga Tempo de Cálculo Tempo Total
Versão Original - - 56:22
Versão Nova com JPA no cliente 00:26 04:02 09:10
Versão Nova sem JPA no cliente (R1) 00:12 00:44 04:48
Versão Nova sem JPA no cliente (R2) 00:15 01:10 04:54
Uma possibilidade que não foi implementada no decorrer deste desenvolvimento foi a
utilização do PDEVS, que diferente do DEVS utiliza o paralelismo aplicado internamente ao
processo de simulação, pois foi descartado qualquer ganho nesta estratégia devido às
múltiplas necessidades de correções nos dados quando eventos ocorrem fora da ordem
cronológica esperada. Além disto, como o framework é muito aberto, permitindo criação de
novas classes para os mais diversos pontos de flexibilização, não foi encontrada ainda uma
forma de determinar um processo paralelo interno genérico que comporte todas as variações
possíveis. As simulações do tipo DEVS e PDEVS são discutidas na Seção 2.2 e no Anexo C.
120
4.4 USO DE ANOTAÇÕES
Da mesma forma que a versão anterior do framework, a nova permitirá efetuar a

criação de novas classes a partir de arquivos XML, porém não serão feitas diretamente as
alterações do banco de dados referentes ao registro destas novas classes, mas sim criadas
anotações nas mesmas que possam ser reconhecidas pelo framework, de forma que o processo
de registro seja automatizado.
Com o uso de anotações, desenvolvedores podem criar estas classes diretamente em
código Java anotado, como na Figura 42, de forma que aplicativos personalizados de
simulação gerem os registros automaticamente na fase de implantação, além de permitir que
estas classes sejam copiadas diretamente para novos projetos, sem a necessidade de um
processo mais amplo. Anotações são discutidas na Seção 2.3 e Anexo A.
Foram criados os processos necessários para que o framework reconheça as anotações
e promova as mudanças necessárias de forma automatizada, visando a demonstração do uso
destas anotações com vias a reuso no processo de construção de entidades, as quais podem ser
consideradas como a representação das tabelas de catálogo.
Figura 42: Exemplo de anotação utilizada no framework.
O novo framework trabalha com os mesmos três níveis de abstração do original,

descritos na Seção 2.7, porém as anotações assumiram o lugar dos arquivos XML para a
representação dos metadados.
Estas anotações acabam por definir justamente os pontos de flexibilização do novo
framework, já que qualquer classe cujos metadados devam ser armazenados no banco de
dados deverá utilizá-las, permitindo o processamento e posterior exportação destes metadados
para a interface cadastral padrão ou qualquer outra que venha a ser criada.
121
A primeira anotação a ser considerada denomina-se “ClasseACCV”, cujo código é

apresentado na Figura 43, sendo obrigatória para qualquer classe criada com o objetivo de
especializar o novo framework. As informações requeridas por esta anotação são o grupo
lógico de seleção, utilizado pelas interfaces cadastrais para seleção de um tipo de componente
sem interpretações hierárquicas, e a descrição da classe, para exibição nestas mesmas
interfaces. Todas as demais informações necessárias aos metadados são obtidos pelo
framework por métodos baseados em reflexividade.
Figura 43: Anotação pra definição de elemento do framework.
Juntamente com a anotação de dados básicos, outras anotações devem ser utilizadas,
dependendo do ponto de extensão solicitado, como a anotação “AtividadeACCV”, exibida na
Figura 44, a qual requer o preenchimento de propriedades booleanas indicando se a atividade
pode ser executada sobre elementos virtuais ou instanciados, se trabalha com horas de
operação ou tempo corrido em calendário, entre outras informações.
Figura 44: Anotação para definição de uma nova Atividade no framework.
Da mesma forma, uma anotação denominada “PropriedadeACCV” é utilizada para

determinar os metadados de cada propriedade a ser disponibilizada na interface cadastral,
valendo lembrar que não só estas propriedades como aquelas expostas pela super-classe serão
exibidas. Esta anotação pode ser observada na Figura 45.
122
Figura 45: Anotação para definição de propriedades expostas na interface.
A Figura 46 apresenta um novo tipo de atividade, no caso “Transporte com Seguro”,

sendo oferecida pela interface cadastral, enquanto a Figura 47 apresenta o código Java
necessário para acrescentar esta classe ao framework e a Figura 48 apresenta algumas das
entradas criadas no banco de dados após o reconhecimento das anotações.
Figura 46: Exibição de novo tipo de atividade na interface cadastral.

123
Figura 47: Codificação de um novo tipo de atividade.
Figura 48: Entradas criadas no banco para reconhecimento da atividade e suas propriedades.
124
Os pontos de flexibilização do framework ainda são os mesmos do original, à exceção

do processo de manutenção, que agora pode ser especializado, assim como todos os modelos
de geração de eventos. Porém, a forma de utilizá-los foi modificada por completo em relação
à criação via XML defendida anteriormente por Cople (2004).
A Tabela 7 apresenta alguns dos pontos de flexibilização e requisitos atuais.
Tabela 7: Alguns pontos de flexibilização do novo framework
Ponto de Flexibilização Anotações Requeridas Ancestral Nativo

@ClasseACCV
Atividade @PropriedadeACCV Atividade
@AtividadeACCV
@ClasseACCV
Distribuição Estatística @PropriedadeACCV Distribuicao
@DistribucaoACCV
@ClasseACCV
Hardware @PropriedadeACCV ProdHardware
@HardwareACCV
@ClasseACCV
Sistema @PropriedadeACCV ProdSistema
@SistemaACCV
@ClasseACCV
Mão de Obra @PropriedadeACCV
@MaoObraACCV
@ClasseACCV
Modelo de Custo @PropriedadeACCV ModeloCusto
@ModeloCustoACCV
@ClasseACCV
Modelo de Eventos @PropriedadeACCV ModeloEvento
@ModeloEventoACCV
@ClasseACCV
Processo de Manutenção @PropriedadeACCV AbstractProcessoManutencao
@ProcessoManutencaoACCV
125
Embora existam muitos outros pontos de flexibilização no framework, o fato mais

relevante neste ponto é o de que as anotações simplificaram a escrita e promoveram a
reutilização de interfaces cadastrais, além de proporcionar a adição de novos modelos de
cálculo que se incorporam às simulações, promovendo o reuso do próprio núcleo de
simulações distribuídas em situações específicas para cada novo tipo de estudo de ACCV que
possa ser criado posteriormente.
4.5 ELEMENTOS GENÉRICOS
Muitas das classes do framework antigo foram identificadas como sendo elementos
processuais, e sua modelagem mostrou-se inadequada aos novos padrões de mercado, onde
processos reutilizáveis devem ser modelados em termos de elementos genéricos.
Um exemplo é o processo de armazenamento de dados locais com uso de JPA, que
acabam por se tornar repetitivos e não precisam ser reprogramados sempre. Foi criada uma
denominada “GenericDAO”, a qual visa determinar um padrão de desenvolvimento DAO
reutilizável, e cujos métodos podem ser observados na Figura 49.
Figura 49: Assinatura dos métodos de GenericDAO.

126
A implementação dos métodos de “GenericDAO” é bastante extenso, sendo seu

código omitido neste contexto, já que o foco é o reuso. Como exemplo da praticidade
proporcionada por esta classe, o exemplo da Figura 50 demonstra a utilização da mesma em
conjunto com uma entidade JPA.
Figura 50: Exemplo de utilização do gestor genérico de acesso a banco de dados.
A execução do exemplo faria com que um agendamento fosse adicionado ao banco de

dados, resgatado em outro objeto, alterado e finalmente removido. Observa-se que não houve
necessidade de extensos códigos para efetuar a tarefa, tão pouco de instruções SQL.
Com a alteração na forma de programar estes processos, a adaptação dos mesmos a
novos contextos será facilitada, aumentando o reuso do framework. Entre as muitas estruturas
que foram modificadas estão listas utilizadas no armazenamento de custos, bem como listas
de movimentação de estoque, listas de utilização de recursos e demais listas utilizadas durante
a simulação.
Este assunto é melhor discutido no Anexo A, onde é apresentado um exemplo de
programação genérica para a criação e utilização de listas genéricas com suporte a execução
concorrente.
Vale lembrar que elementos genéricos são classes, e como tal, os princípios de herança
e todos os demais definidos para classes aqui podem ser aplicados, aumentando ainda mais o
reuso para o nível de reutilização e extensão de processos.
127
Um bom exemplo deste princípio foi utilizado nas gravações em background

efetuadas na execução da simulação. Como muitos dados devem ser armazenados no banco
de dados, e por ser um processo repetitivo, foi definida uma classe para tal com o objetivo de
gravar o dado gerado, excluindo da lista de objetos após a gravação, de forma a remover da
memória objetos que não mais serão utilizados.
O código fonte das classes e interfaces envolvidas no processo de gravação em
background das listas é muito extenso, sendo parte das classes principais apresentadas na
Figura 51 e Figura 52, bem como um exemplo de utilização na Figura 53.
Figura 51: Classe para listas de objetos JPA com gravação em background.
128
Figura 52: Especialização de GenericManager.
Figura 53: Criação da classe para gravação de movimentação de estoque.
As tarefas executadas por “GestorEstoqueBD” são a armazenagem de todas as

movimentações de estoque durante a simulação, conversão da classe de modelo ACCV para a
classe de armazenagem JPA, executada ao nível de “GenericInstanceManager”, e gravação no
banco com conseqüente remoção do histórico da memória, executada ao nível de
“GenericManager”.
129
Este é um exemplo robusto de reuso mesclando herança e programação genérica. Para

um novo contexto, basta especializar novamente “GenericInstanceManager”, como pode ser
Figura 54: Criação da classe para gravação de instâncias de produtos da simulação.
Existem muitas outras partes do código que comportam esta mudança de estilo, o que
acaba por trazer um nível maior de complexidade no que tange à definição das classes
genéricas, mas grande simplicidade na utilização em desenvolvimentos posteriores, o que
pode ser visto claramente nos exemplos descritos. Maiores detalhes sobre o uso de elementos
genéricos podem ser obtidos na Seção 2.3 e no Anexo A.
Não é objetivo deste trabalho explicar todos os pontos das mais de trezentas mil linhas
de código do framework que utilizam elementos genéricos, mas tão somente justificar sua
utilização perante as facilidades promovidas no que tange ao reuso, como no exemplo
anteriormente descrito.
4.6 ARQUITETURA MSVC E PADRÕES DE DESENVOLVIMENTO
O objetivo da utilização de padrões de desenvolvimento neste novo framework é o

reaproveitamento do conhecimento formal de modelagem, além da utilização de um
vocabulário comum à grande maioria dos desenvolvedores, o que diminui o tempo de
aprendizagem por parte destes desenvolvedores na criação de novos aplicativos.
130
Este vocabulário comum também fornece meios para integração deste framework com
novas tecnologias envolvendo pouco esforço computacional, e permitindo que componentes
distintos utilizem frameworks externos e bibliotecas especializadas, sem a necessidade de
alterações nos demais trechos de código.
Entre os vários padrões a serem adotados, um que se destaca é o Proxy, na arquitetura
Broker, que será utilizado em dois pontos do framework: processamento distribuído via RMI
e comunicação com JEE no processo de persistência de dados.
Maiores detalhes sobre o uso de padrões de desenvolvimento podem ser obtidos na
Seção 2.3 e no Anexo A, enquanto as arquiteturas principais são discutidas na Seção 2.4 e no
Anexo B.
Com o uso da arquitetura MSVC no novo modelo do framework a responsabilidade de
armazenamento e concorrência no acesso ao banco de dados é delegada para o JPA,
utilizando-se de todas as facilidades transacionais, além do uso de JEE como fachada para a
camada de banco, segundo o padrão Session Facade, provendo um meio eficiente para a
manipulação de grandes quantidades de dados e número de acessos concorrentes. Como as
anotações não são serializáveis, o JPA provê automaticamente o padrão DAO, e o meio de
utilização dos componentes EJB segue o padrão Abstract Factory, além do que ambos os
frameworks trabalham com pools, segundo o padrão Fly Weight. Os frameworks JEE e JPA
são discutidos no Anexo B.
A grande vantagem de uma arquitetura MVC é a divisão de responsabilidades com
relação ao desenvolvimento, permitindo que a construção da camada de visualização seja
efetuada por designers, enquanto a lógica de negócios e intermediação com o banco fique sob
a responsabilidade dos programadores. A independência das camadas facilita também a
criação de Web Services, permitindo o aumento da interoperabilidade do sistema com outras
tecnologias, além de viabilizar a criação direta de uma arquitetura orientada a serviços.
Na arquitetura MSVC utilizada, acrescenta-se às vantagens apresentadas para o MVC
o fato de que o executor de simulação, ao ficar em uma camada separada, fica independente
dos demais processos executados pelo software.
Outros padrões aplicados foram o Factory Method para a construção de objetos
baseada em reflexividade, a partir do texto representativo do nome da classe, o Service
Locator, concentrando as chamadas para os componentes EJB e demais recursos
disponibilizados através de JNDI, Singleton para a gerência de tokens e demais gestores
globais do framework, além do State para a criação de processos de manutenção e demais
modelos de geração de eventos.
131
Por fim, muitos dos padrões adotados foram implementados via elementos genéricos,
aliando o vocabulário já conhecido pela maior parte dos desenvolvedores às facilidades de
criação das metodologias comportamentais.
Em termos da extensão do framework, o principal padrão a se considerar é o State,
utilizado na criação de novos modelos de geração de evento, particularmente do processo de
manutenção, o qual era um workflow fixo na primeira versão do framework e agora pode ser
criado livremente para se adequar aos mais diversos contextos.
O novo processo de manutenção encapsula uma máquina de estados genérica, segundo
o padrão State, sendo criadas as classes de base “AbstractManutencaoState” e
“AbstractProcessoManutencao”, as quais devem ser especializadas para definir um novo tipo
de processo de manutenção. Como deveria haver um processo padrão para o framework, foi
criada a classe “ProcessoManutencaoPadrao”, encapsulando o processo que é utilizado como
padrão para qualquer modo de falha, desde que o usuário do sistema não selecione outro.
Para fins de ilustração, uma visão esquemática do processo de manutenção antigo é
apresentado na Figura 55 enquanto o novo processo padrão é apresentado na Figura 56.
Figura 55: Resumo esquemático do Processo de Manutenção antigo.
Fonte: Cople (2004 p.111)

132
Figura 56: Resumo esquemático do Processo de Manutenção Padrão do novo framework.
Neste resumo geral do funcionamento do processo de manutenção padrão, os estados

são representados nas figuras com fundo amarelo, sendo que cada um deles equivale à
implementação de um descendente de “AbstractManutencaoState”, os eventos gerados a cada
estado são representados em vermelho, e em alguns pontos decisões têm de ser tomadas,
adotando-se novamente um padrão de desenvolvimento na implementação, desta vez o
Strategy.
A cada ciclo de chamada ao processo de manutenção, este executa três tarefas
principais, a saber:
1. Obtenção de uma instância de evento do tipo correto, a partir do método “gerar” de

seu estado atual;
2. Inclusão deste novo evento na lista de eventos global do simulador; e
3. Mudança para o próximo estado, obtido a partir do método “next” do estado
corrente.
133
Com a definição destas máquinas de estado foi obtida uma funcionalidade que não
existia no framework original, ou seja, agora é possível criar processos genéricos de geração
de eventos que proporcionam o reuso do framework como um todo, fazendo com que tipos
completamente diferentes de problemas possam ser modelados e ainda assim tirem proveito
do processamento paralelo e das interfaces dinâmicas já existentes.
Os demais modelos de geração de eventos também são máquinas de estado, não tão
complexas, as quais devem ser implementadas como descendentes de “ModeloEvento” e
“AbstractEventoState”. O código interno destas classes de base foge ao escopo deste trabalho,
pois acrescentaria complexidade e não ajudaria a demonstrar a importância do reuso, porém a
especialização simplificada para novos contextos é um bom exemplo da importância dos
padrões de desenvolvimento na reutilização de processos.
O processo de geração de eventos padrão é o próprio “ModeloEvento”, que pode ser
especializado pra atividades específicas, como aquisição de produto, ma também pode ser
utilizado na sua forma original, ao contrário de “AbstractProcessoManutencao”, que é uma
classe abstrata. O esquema funcional do modelo de geração de eventos padrão é apresentado
na Figura 57.
Figura 57: Resumo esquemático do modelo de geração de eventos padrão.

134
Embora o código das classes de base seja muito extenso, não cabendo aqui o
detalhamento do mesmo, a implementação dos descendentes de “AbstractState” não é tão
complexa, devendo apenas ser implementados em cada classe de estado os métodos “gerar”,
referente à geração de um novo evento do tipo adequado ao estado, e “next”, que seleciona o
próximo estado a ser utilizado.
A implementação dos estados “Iniciado” e “Ativo”, presentes na máquina de estados
da Figura 57, pode ser observada respectivamente na Figura 58 e na Figura 59.
Figura 58: Implementação do estado padrão “Iniciado”.

135
Figura 59: Implementação do estado padrão “Ativo”.
Embora não tenha sido possível implementar nesta fase do projeto, é um dos objetivos
futuros a criação de geradores automáticos de código com a concepção visual de máquinas de
estado, tanto para geração de eventos comuns quanto para processos de manutenção.
136
5. UTILIZAÇÃO DO NOVO FRAMEWORK
Esta seção visa ilustrar o processo de utilização do novo framework para a inclusão de
dados de catálogo, criação de cenários, execução de simulações e análise de resultados. Aqui
não são exploradas as técnicas de reuso e interoperabilidade descritas no decorrer de todo este
texto, mas simplesmente apresentar o framework como um sistema de simulação, utilizando
como fonte de dados o cenário do Anexo D.
Conforme pode ser observado na Figura 60, a interface cadastral divide-se em quatro
módulos:
1. Catálogo, para a inclusão dos dados cadastrais do catálogo;

2. Cenário, o qual permite a configuração de cenários de simulação;
3. Simulação, referente às solicitações de execução de simulações; e
4. Resultados, destinado à visualização dos resultados obtidos.
Figura 60: Tela inicial da interface cadastral.

137
O primeiro módulo do sistema cadastral é o cadastro de catálogo, o qual é apresentado

na Figura 61, sendo identificados:
1. Painel de Navegação;
2. Tabela de visualização e seleção de elementos;
3. Seletor de tipo;
4. Botão de inclusão;
5. Botões de alteração e exclusão; e
6. Tabela de exibição de propriedades para o elemento selecionado.
4
3
2 6
Figura 61: Tela principal do módulo de catálogo.
O primeiro passo da simulação é o cadastro de dados de catálogo, feito neste primeiro

módulo, iniciando-se com o cadastramento de locais geográficos e órgãos definidos no
exemplo do Anexo D, como pode ser observado na Figura 62 e na Figura 63.
138
Figura 62: Cadastro de locais geográficos.
Figura 63: Cadastro de órgãos.

139
A seguir foram cadastrados os percursos e meios de transporte, no caso apenas

transporte terrestre, bem como os fatores de custo por peso e volume, relacionados ao meio de
transporte especificado.
As telas deste cadastro são apresentadas na Figura 64 e na Figura 65.
Figura 64: Cadastro de percursos e respectivas distâncias.
Figura 65: Cadastro de meios de transporte e respectivos fatores de custo.

140
Os produtos também foram cadastrados, bem como atividades, modos de falha e

processos de manutenção, além da composição do sistema, o que pode ser observado na
Figura 66.
Figura 66: Telas de cadastro de produto.

141
Ao módulo de cenário compete o cadastro de cenários de simulação, como o que é

apresentado da Figura 67. Neste módulo são acessados também os cadastrados de todos os
dados complementares do cenário, tais como:
• Sistemas utilizados no cenário;

• Órgãos relacionado ao cenários;
• Estruturas de Abastecimento e Manutenção;
• Configuração de Grupos de Sistemas;
• Agendamento de operação e manutenção preventiva;
• Planos de Aquisição, Instalação e Descarte;
• Dotação de Sobressalentes;
• Escolha de meios de transporte; e
• Configuração da CBS.
Figura 67: Interface para cadastro de cenários.

142
A Figura 68 apresenta algumas das funcionalidades do módulo de cenário, incluindo a

configuração dos grupos de sistemas, planos de aquisição, instalação, operação e descarte para
o grupo ou instância, além da configuração dos meios de transporte utilizados.
Figura 68: Algumas telas do modulo de cenário.

143
Outras telas do módulo de cenário, como as estruturas de manutenção e abastecimento

e configuração da CBS podem ser observadas na Figura 19 e na Figura 23, ambas presentes
no Capítulo 3 deste trabalho.
Finalmente o módulo de execução de simulações é chamado, o cenário escolhido, bem
como o número de simulações desejado no novo grupo, e ao clicar em “Executar” todo o
processamento distribuído descrito na Seção 4.3 é ativado. O módulo de simulação pode ser
Figura 69: Tela para solicitação de simulações.
Terminadas as execuções das simulações, seus resultados podem ser obtidos através
do Web Service de fornecimento de resultados, podendo ser interpretado pelo Flex ou
qualquer outra tecnologia que interprete o SOAP.
A Figura 70 apresenta um exemplo de saída no formato SOAP, com a chamada direta
ao serviço de fornecimento de resultados do framework de ACCV.
144
Figura 70: Fornecimento de resultados no formato SOAP pelo framework de ACCV.
A interface de visualização de resultados criada em Flex apresenta os resultados, para

o grupo ou para a simulação individual, referentes aos custos, utilização de recursos,
disponibilidade do sistema, e movimentação de estoque.
O período para análise pode ser total (referente ao tempo total simulado), mensal, ou
pontual (para análise a cada instante simulado). No entanto, nem todos os temas sob análise
permitem todas as periodicidades, sendo apresentadas na Tabela 8 as combinações oferecidas.
Tabela 8: Períodos de análise por Tipo de Resultado.
Dado Analisado Escopo Total Mensal Pontual

Grupo Sim Sim Não
Custos
Individual Sim Sim Sim
Grupo Sim Sim Não
Utilização de Recursos
Individual Sim Sim Não
Grupo Sim Sim Não
Disponibilidade do Sistema
Individual Sim Sim Não
Grupo Não Sim Não
Movimentação de Estoque
Individual Não Sim Sim
145
Para a análise de custos, nenhum parâmetro em particular precisa ser fornecido, sendo
necessária apenas a escolha do escopo e periodicidade, como pode ser visto na Figura 71,
onde é apresentado um exemplo na exibição dos custos globais obtidos para o cenário de
testes com um determinado grupo de simulações, e na Figura 72, onde é apresentada a
exibição dos custos mensais para uma simulação individual.
Figura 71: Custos globais para um grupo de simulações.
Figura 72: Custos mensais para uma simulação individual.

146
Ao analisar os recursos consumidos, deve ser selecionado o recurso sob análise, como
pode ser observado na Figura 73, onde é apresentado o consumo de horas mensais de trabalho
para técnicos de nível um, dentro do cenário de testes, para um dado grupo de simulações.
Figura 73: Consumo de recursos mensais para um grupo de simulações.
Para a disponibilidade do sistema, deve ser selecionada a instância do sistema dentro

do cenário de análise, e ao contrário dos demais resultados, onde ocorre o agrupamento por
órgão do cenário, neste o agrupamento ocorre pelos três estados do sistema: disponível, em
espera e operando.
Dentro desse tema, também foi criado um aplicativo em Java para acompanhamento
da linha de vida do sistema, onde é possível selecionar uma instância específica do sistema no
cenário de análise e visualizar as variações do estado desta instância em um período
selecionado para uma dada simulação individual.
Na Figura 74 é apresentada a disponibilidade de uma instância de sistema, para um
dado grupo de simulações, enquanto o acompanhamento da linha de vida para esta mesma
instância pelo software Java pode ser observado na Figura 75, considerando uma das
simulações do grupo.
147
Figura 74: Disponibilidade de uma instância de sistema.
Figura 75: Acompanhamento da linha de vida de uma instância de sistema.
Finalmente, no que tange à movimentação do estoque, o parâmetro que deve ser

configurado é o produto de catálogo sob análise, dentro do cenário de simulação. Como
resultado, quantidade total deste produto segundo a periodicidade de análise é apresentada,
ocorrendo agrupamento por órgão onde a movimentação ocorreu.
Devido ao modelo utilizado no framework de ACCV, onde o descarte implica em uma
aquisição, para a análise mensal acaba ocorrendo um valor constante, decorrente da imediata
reposição de peças a partir do fornecedor, mas outros modelos poderão ser construídos para
que o gráfico reflita variações mensais.
148
A Figura 76 apresenta um exemplo de análise da movimentação mensal para um

produto dentro do cenário de análise, segundo os resultados obtidos para um determinado
grupo de simulações, enquanto a Figura 77 apresenta a análise pontual para outro produto, a
partir dos resultados de uma das simulações do grupo.
Figura 76: Análise da movimentação mensal de estoque para um produto.
Figura 77: Análise pontual da movimentação de estoque para um produto.

149
6. INTEROPERABILIDADE E EXTENSÃO DO FRAMEWORK
6.1 INTRODUÇÃO
Nesta seção são apresentados dois exemplos simples para a demonstração da

interoperabilidade e procedimento de extensão do novo framework de ACCV.
A primeira parte se concentra no desenvolvimento de um extrator de dados,
implementado em linguagem C#, que captura as diferentes saídas do serviço de fornecimento
de resultados e exporta diretamente para o Microsoft Excel, ferramenta amplamente utilizada
pelos mais diversos gestores, permitindo a criação de gráficos ou análises mais refinadas dos
resultados com o uso da ferramenta.
A segunda parte se concentra na criação de um cenário alternativo, referente ao uso de
redes de computadores com serviços terceirizados de manutenção, envolvendo a criação de
diversas novas classes para o framework, inclusive com a definição de um gerador de eventos
próprio para o processo de manutenção, o que acaba também por demonstrar a utilização do
padrão de desenvolvimento State nos geradores de evento.
6.2 INTEROPERABILIDADE DO FRAMEWORK
Para demonstrar a interoperabilidade do framework foi criado um extrator de

resultados para o Microsoft Excel, sem a preocupação de se criar um ambiente com janelas, ou
qualquer tipo de visualização avançada neste extrator, pois o objetivo era apenas demonstrar a
simplicidade do reuso baseado na interoperabilidade a partir das saídas do Web Service
responsável pelo fornecimento de resultados.
Inicialmente foi criado um aplicativo de linha de comando com linguagem C# dentro
do Visual Studio. Este aplicativo foi denominado “ExtratorACCV”, e os passos iniciais para a
definição do projeto se referem à escolha do tipo de aplicativo, seguindo-se a denominação do
mesmo e escolha do local onde ficarão os fontes.
150
Os passos iniciais para a criação do extrator podem ser vistos na Figura 78.
Figura 78: Criação de aplicativo de linha de comando com C#.
Com a criação do aplicativo, o passo seguinte foi o reconhecimento do serviço de

fornecimento de resultados do framework de ACCV, aproveitando-se da interoperabilidade
inerente ao mesmo.
As chamadas a esse serviço retornam como resultado listas (ou vetores) de elementos
denominados “GraphicSimpleDTO”, os quais trazem como informação as propriedades:
• label, com o descritivo do agrupamento da célula de dados;

• instante, referente ao momento da definição do dado no período simulado; e
• valor, para o valor do dado no instante considerado.
No entanto estas informações podem ter diferentes interpretações de acordo com o tipo
de chamada efetuada, bem como cada chamada aceita diferentes parâmetros, sendo necessário
o mapeamento entre os tipos de solicitações disponíveis e o retorno obtido para cada uma.
A Tabela 9 apresenta o mapeamento das chamadas de interesse para o programa de
exemplo em C#.
151
Tabela 9: Chamadas ao Serviço de Fornecimento de Resultados
Outros
Chamada Identificador Saída
Parâmetros
obterCustosGrupoGraficoTotal idGrupo - Custo Total para o Grupo
obterCustosGrupoGraficoMensal idGrupo - Custo Mensal para o Grupo
obterCustosIndividualGraficoTotal idServerCall - Custo Total Individual
obterCustosIndividualGraficoMensal idServerCall - Custo Mensal Individual
obterCustosIndividualGraficoPontual idServerCall - Custo Diário Individual
Consumo de Recursos Total

obterRecursosGrupoGraficoTotal idGrupo idRecurso
para o Grupo
Consumo de Recursos
obterRecursosGrupoGraficoMensal idGrupo idRecurso
Mensal para o Grupo
Consumo de Recursos Total

obterRecursosIndividualGraficoTotal idServerCall idRecurso
Individual
Consumo de Recursos
obterRecursosIndividualGraficoMensal idServerCall idRecurso
Mensal Individual
idOrgaoCenario
Disponibilidade Total do
obterDisponibilidadeGrupoGraficoTotal idGrupo idSistema
Sistema para o Grupo
instancia
idOrgaoCenario
Disponibilidade Mensal do
obterDisponibilidadeGrupoGraficoMensal idGrupo idSistema
Sistema para o Grupo
instancia
idOrgaoCenario
Disponibilidade Total do
obterDisponibilidadeIndividualGraficoTotal idServerCall idSistema
Sistema Individual
instancia
idOrgaoCenario
Disponibilidade Mensal do
obterDisponibilidadeIndividualGraficoMensal idServerCall idSistema
Sistema Individual
instancia
Estoque Mensal para o

obterEstoquesGrupoGraficoMensal idGrupo idProduto
Grupo
obterEstoquesIndividualGraficoMensal idServerCall idProduto Estoque Mensal Individual
obterEstoquesIndividualGraficoPontual idServerCall idProduto Estoque Diário Individual

152
Este mapeamento é reconhecido automaticamente pelo Visual Studio através da

análise do WSDL do serviço a partir da opção “Add Service Reference”, segundo o processo
que pode ser visualizado na Figura 79.
Figura 79: Adição do Web Service Java ao sistema em C#.
Após a confirmação, as classes C# responsáveis pelo encapsulamento das chamadas

são criadas, sendo reconhecidas automaticamente pelo ambiente de desenvolvimento,
inclusive com a opção de completar código, como pode ser visto na Figura 80.
Figura 80: Reconnhecimento do Web Service pelo C#.

153
Estando o ambiente de comunicação com o framework de ACCV configurado, o

próximo passo foi a definição da interação do extrator com o usuário, que por se tratar de um
aplicativo de linha de comando, é definida a partir de parâmetros passados na chamada do
aplicativo.
Os parâmetros definidos podem ser observados na Tabela 10, e o código para a
interpretação dos parâmetros encontra-se na Figura 81.
Tabela 10: Parâmetros do Extrator de Resultados
Parâmetro Valor Parâmetro Valor

1 = Custos G Id do Grupo
2 = Recursos S Id da Simulação
I
3 = Diponibilidade OC Id do Órgão
4 = Estoque SIST Id do Sistema
1 = Período Total INST Instância
P 2 = Período Mensal PROD Id do Produto
3 = Período Diário REC Id do Recurso
Figura 81: Codificação para interpretação de parâmetros no Extrator de Resultados

154
Em seguida, os parâmetros do usuário foram convertidos em chamadas para o

framework de ACCV, gerando os vetores de resultados para as diferentes combinações de
parâmetros, como pode ser observado na Figura 82.
Figura 82: Chamadas ao Web Service de Reultados a partir do C#.
Resolvida a etapa da obtenção dos dados, o passo seguinte refere-se à exportação dos
dados obtidos para o Microsoft Excel. O intercâmbio de dados com este software dentro da
tecnologia .Net é obtido com a utilização de um componente específico, denominado
Microsoft Excel Object Library.
O processo de utilização do componente é iniciado com a adição do mesmo ao extrator
através da adição da referência, da mesma forma que para os Web Services. Estando o
componente disponível ele pode ser utilizado diretamente na programação em C#.
Nesta etapa os resultados obtidos na chamada ao framework de ACCV foram
diretamente convertidos para células de uma nova planilha no Excel, permitindo a livre
manipulação destas células após a geração.
155
A adição do componente pode ser observada na Figura 83, e o código que veio a
utilizá-lo na Figura 84.
Figura 83: Adição do elemento COM do Microsoft Excel.
Figura 84: Código para ativação da planilha e transferência de resultados.
Esse foi todo o esforço necessário para a criação de uma ferramenta extratora,
demonstrando como a interoperabilidade facilitou muito o reuso do framework de ACCV em
ambientes heterogêneos.
156
A mesma metodologia poderia ser aplicada para a construção de uma camada de

integração com HLA, embora a complexidade do aplicativo a ser gerado possa ser um pouco
maior, devido à formalização inerente às normas.
Com o extrator pronto, ele foi executado a partir da linha de comando e os dados
puderam ser manipulados diretamente no Excel, como pode ser observado na Figura 85.
Figura 85: Resultado da extração de resultados para o Microsoft Excel.

157
6.3 EXTENSÃO DO FRAMEWORK
O objetivo desta seção é a demonstração da extensão do framework de ACCV, da

forma mais didática possível, sem a inclusão de processos de cálculo complexos, ou gestores
de eventos com muitos estados.
Para tal, considera-se como exemplo a avaliação de um serviço de terceirização, para o
setor de informática, que apresenta as seguintes condições contratuais para um período de
cinco anos:
• As máquinas deverão ser todas adquiridas na empresa que presta o serviço, ficando
disponíveis para o cliente apenas durante o período contratual;
• A venda ocorre em lotes de computadores com trinta, sessenta ou noventa
computadores, além dos respectivos servidores e equipamentos necessários para a
configuração das redes individualmente;
• Qualquer computador que apresenta falha no período contratual será substituída
por uma nova, de forma gratuita, sendo paga apenas a hora do técnico responsável
pela substituição; e
• Qualquer atendimento será iniciado em um prazo de duas a vinte e quatro horas,
sendo que a substituição de uma máquina é uma atividade que dura uma hora,
enquanto os serviços de manutenção de rede podem levar de duas a noventa e seis
horas.
Este perfil de serviço aproxima-se das condições contratuais de grandes fornecedores

de equipamentos, como IBM e Dell, quando o cliente também é uma pessoa jurídica de médio
a grande porte.
As configurações de rede oferecidas dispensam cabeamento, utilizando apenas
comunicação wireless, vendendo sempre a idéia de que ocorrerá o mínimo de interferência no
ambiente da empresa cliente.
As falhas em computadores cliente não causam indisponibilidade na rede, e costumam
ocorrer a uma taxa média de duas mil horas de operação, segundo uma distribuição
exponencial, enquanto os servidores e demais equipamentos de suporte à infra-estrutura de
rede podem causar a indisponibilidade da rede, apresentando diferentes taxas de falha de
acordo com a configuração escolhida, devido às possibilidades de redundância.
158
Para o exemplo considerado, o custo de aquisição de cada tipo de rede pode ser
observado na Tabela 11.
Tabela 11: Custos de aquisição para as redes de exemplo.
Sistema Composição Custo

30 clientes Phenom 4G/500G
Rede de 30 computadores Servidor Intel I7 8G/1T R$ 55.000,00
Equipamentos de suporte à rede
Rede de 60 computadores 2 Servidores Intel I7 8G/1T R$ 110.000,00
Rede de 90 computadores 4 Servidores Intel I7 8G/1T R$ 174.000,00
Os serviços oferecidos, respectivos profissionais envolvidos e custo pela hora do

serviço de cada profissional podem ser observados na Tabela 12.
Tabela 12: Duração das atividades e consumo de recursos para as redes do exemplo.
Atividade Duração Recursos

2 a 3 horas por cliente Especialista (R$ 120,00)
Configuração de rede
configurado 2 Técnicos Nível 2 (R$ 80,00)
Substituição de máquina 1 hora 1 Técnico Nível 1 (R$60,00)
Manutenção de rede 2 a 96 horas 2 Técnicos Nível 2 (R$ 80,00)
Finalmente, quanto às taxas de falha da infra-estrutura de rede, estas são de mil horas
de operação para as redes com trinta clientes, três mil horas de operação para as redes com
sessenta clientes e seis mil horas para as redes com noventa computadores.
Para dar suporte aos comportamentos aqui definidos, alguns pontos de extensão do
framework de ACCV foram explorados, de forma a direcionar a execução das simulações
para um modelo que apenas considere a avaliação do serviço terceirizado.
159
O passo inicial foi a definição de uma nova classe de sistema denominada

“ProdSistemaRede”, onde é acrescentada a propriedade “numComputadores”, referente ao
número de clientes existentes na rede.
O código-fonte da nova classe de sistema pode ser observado na Figura 86.
Figura 86: Código da classe Java para Sistema de Rede.
Para os computadores e demais componentes do sistema de rede foram utilizadas as

classes nativas do framework, bem como para toda a mão-de-obra envolvida nas atividades
aqui definidas.
Também foi definido um novo tipo de atividade, referente à configuração e
conseqüente disponibilização de cada rede, denominado “AtividadeConfiguracaoRede”, que
leva em consideração o número de computadores existentes na rede para o cálculo de duração
da atividade.
Como a atividade de configuração deixa o sistema de rede disponível para uso, acaba
por assemelhar-se à atividade de instalação padrão, podendo ser derivada da mesma, apenas
160
com a observação de que a duração desta nova atividade está relacionada diretamente ao
número de máquinas cliente na rede, como pode ser observado na Figura 87.
Figura 87: Código da classe Java para Atividade de Configuração de Rede
As manutenções de rede consideradas levaram à definição de um processo de

manutenção próprio para a geração dos eventos, o qual deve considerar o atraso no início da
atividade, além de sempre efetuar o reparo, sem considerar fatores como transporte, RIP,
NFF, ou qualquer outro do processo de manutenção padrão.
Ao contrário do padrão, este novo processo pode gerar indisponibilidade ou não,
dependendo da falha considerada, exigindo a definição de estados totalmente independentes
daqueles considerados no processo nativo.
Também deve ser levado em conta que, dentro do escopo da simulação para ACCV, a
substituição de uma máquina sem custo para o cliente, estando as falhas deste equipamento
sujeitas a distribuições como a exponencial, equivaleria a restabelecer as condições de
operação da máquina original.
161
Considerando esses pontos, foi definido inicialmente um novo tipo de atividade que
considera o atraso, sendo denominada “AtividadeReparoAtraso”, e cujo código-fonte pode ser
Figura 88: Código da classe Java para Atividade de Reparo com atraso.
O modelo de geração de eventos para atividade de reparo com atraso, no caso em que
é gerada indisponibilidade, segue o diagrama exposto na Figura 89.
Figura 89: Modelo para Geração de Eventos no Processo de Manutenção com atraso
162
Para implementar o modelo de geração de eventos proposto são necessários três

classes, a saber:
• ProcessoManutencaoRede, responsável pela definição do gerador de eventos para

manutenção considerado;
• ManutencaoAtrasoIniciadoState, referente ao estado inicial do gerador; e
• ManutencaoAtrasoReparoState, referente ao estado executor do reparo.
A única responsabilidade de “ProcessoManutencaoRede” é a escolha do estado inicial,

pois todo o resto do comportamento da classe foi definida em sua antecessora, o que pode ser
Também pode ser observada a presença das anotações necessárias ao reconhecimento
do gerador de eventos pelo framework de ACCV, as quais determinarão a possibilidade de
escolha deste gerador como processo de manutenção para determinados modos de falha
definidos na interface cadastral.
Figura 90: Código da classe “ProcessoManutencaoRede”.

163
Quanto à programação dos estados desse gerador de eventos, estes não necessitam de
anotações, pois fazem parte do processamento interno do gerador, e não são disponibilizados
na interface cadastral.
A código de “ManutencaoAtrasoIniciadoState” pode ser observado na Figura 91,
sendo sua única responsabilidade apontar o próximo estado para o gerador de eventos, ou
seja, a classe “ManutencaoAtrasoReparoState”.
Figura 91: Código da classe “ManutencaoAtrasoIniciadoState”.
Quanto ao estado de reparo, o ponto principal a ser considerado é a inclusão do atraso

para o início da atividade, o que é feito com o acréscimo do mesmo ao tempo corrente do
gerador, como pode ser observado na Figura 92.
Nota-se que não foi necessária a criação de uma classe para o estado finalizado, isto
porque o estado padrão do framework de ACCV para finalização de manutenção já efetuava
as ações necessárias para este novo modelo, sendo a classe “ManutencaoFinalizadoState”
apontada como estado seguinte pela classe “ManutencaoAtrasoReparoState”.
164
Figura 92: Código da classe “ManutencaoAtrasoReparoState”.
Como o objetivo da simulação é a avaliação do custo de contratação do serviço, não

foi necessário definir um modelo para a política de substituição de equipamentos, sendo
desconsiderado o atraso por se tornar irrelevante para o cálculo. Com isto, a substituição de
máquinas clientes foi tratada como manutenção preventiva com agendamento em termos
estocásticos, sem a necessidade de novas extensões do framework de ACCV.
O último passo para a extensão do framework envolve o registro das anotações e
conseqüente criação de entradas na base de dados, através da chamada ao método de registro
existente no serviço de gerência de classes, o qual recebe como parâmetros o identificador da
classe pai, além do pacote e do nome da classe a ser adicionada.
165
Isso teve de ser feito para todas as novas classes anotadas, sendo um exemplo de
solicitação do serviço exibido na Figura 93.
Figura 93: Ambiente de registro das anotações no framework de ACCV.
Estando todas as classes criadas e registradas, foi definido um cenário de análise para
testar a utilização dos novos elementos criados, considerando as cidades do Rio de Janeiro e
São Paulo, e tendo como início a data de 01/01/2010, com as configurações para as redes
detalhadas na Tabela 13.
Tabela 13: Configuração e operação dos sistemas de rede.
Local Rede Configuração Operação

RJ1 – 30 clientes 01/02/2010 5 dias / 2 dias
Rio de Janeiro RJ2 – 30 clientes 15/02/2010 5 dias / 2 dias
RJ3 – 60 clientes 01/03/2010 24 horas X 7 dias
SP1 – 60 clientes 05/01/2010 5 dias / 2 dias
São Paulo SP2 – 60 clientes 10/01/2010 5 dias / 2 dias
SP3 – 90 clientes 20/01/2010 24 horas X 7 dias
Inicialmente foram cadastrados dois novos produtos de hardware, representando as

máquinas cliente e servidora, além de todos os recursos necessários. Este passo não discerne
em nada do processo cadastral exemplificado no Capítulo 5.
166
A seguir, foram definidos os sistemas de rede, utilizando como base o novo tipo de
sistema criado, bem como as composições referentes ao maquinário utilizado, como pode ser
Figura 94: Cadastro de sistema do tipo “Sistema de Rede”.

167
Definidos os aspectos estruturais dos produtos, o passo seguinte foi a configuração das
atividades e modos de falha necessários, com a utilização dos novos elementos adicionados ao
framework de ACCV.
As telas que apresentam os novos elementos referentes a atividades podem ser
observadas na Figura 95.
Figura 95: Configuração das atividades extendidas.
Quanto ao modo de falha para as redes, o processo de manutenção utilizado é mais

simples que o convencional, utilizando apenas uma atividade configurável, como pode ser
168
Figura 96: Modo de falha com utilização do novo gerador de eventos.
Os demais passos necessários à configuração são apenas o cadastramento de

manutenções preventivas alusivas à troca de cliente, e a configuração do cenário, da mesma
forma que foi efetuado no Capítulo 5.
Ao final da execução da simulação, os resultados obtidos puderam ser observados no
módulo de visualização de resultados em Flex, como pode ser observado na Figura 97.
Figura 97: Resultado da simulação para o cenário de sistemas de rede.

169
7. CONCLUSÕES E TRABALHOS FUTUROS
A intenção inicial de demonstrar o reuso e a interoperabilidade em um framework de

simulação de ACCV foi alcançado, mas certamente o esforço em termos de desenvolvimento
para atingir este objetivo foi muito grande, envolvendo sistemas que contemplam um total de
mais de trezentas mil linhas de código Java e Flex.
Esta dificuldade de criação não reflete sobre os desenvolvedores de soluções que
utilizem o framework de ACCV, pois o objetivo deste, bem como qualquer outro framework,
é o de absorver a complexidade do domínio do problema para si, enquanto facilita a criação
de novas soluções.
Não é interessante desenvolver uma solução tão genérica quando o foco é a resolução
de um problema limitado, porém o uso do framework para diferentes contextos de ACCV
exige adaptações que apenas serão possíveis devido às características de reuso apresentadas.
O uso de anotações para a extensão do framework trouxe a tarefa a um nível muito
mais formal dentro do ambiente de programação. Mesmo não sendo necessário o uso de
XML, especulou-se inicialmente sua adoção em paralelo, mas a idéia foi abandonada quando
não foi verificado que haveria mais tempo para realizar as tarefas principais.
Futuramente espera-se implementar este encapsulamento em XML com objetivos mais
audaciosos. Uma das frentes de desenvolvimento que deverá continuar a partir do término
deste trabalho será a construção de uma ferramenta para definição visual de classes e
máquinas de estado compatíveis com o framework, de forma a levar sua utilização até as
pessoas totalmente leigas em termos de programação.
A utilização de elementos genéricos, aliados às anotações, aumentou o nível de reuso
do framework, pois a incorporação destas técnicas comportamentais viabilizou a criação de
novas estruturas e processos com menor esforço de programação, em termos de linhas de
código, e, juntamente com os padrões de desenvolvimento, permitiu implementar mudanças
comportamentais da simulação ao nível da própria geração de eventos.
170
Deve-se considerar aqui os dois aspectos do aumento do reuso obtido, no que tange à
incorporação de técnicas comportamentais e padrões de desenvolvimento:
• Por um lado, o framework de ACCV tornou-se mais adaptável a novos problemas,

cujos comportamentos não poderiam ser expressos sem a flexibilização da geração
de eventos; e
• Não menos importante, a diminuição do esforço de modelagem e programação
aumenta a viabilidade do framework para problemas complexos.
A completa reestruturação para uso de padrões de desenvolvimento e elementos

genéricos, inclusive muitos padrões sendo implementados como elementos genéricos, trouxe
ao framework a um vocabulário mais próximo dos ambientes de desenvolvimento atuais,
permitindo futuras integrações, como é feito com JEE5 e JPA, bem como facilitando a
compreensão dos processos de extensão atual por outros pesquisadores.
Inclusive, não seria possível criar códigos tão extensos sem boas ferramentas de
desenvolvimento. Uma conclusão que se chega é a de que a escolha da ferramenta, que no
caso foi o NetBeans para a parte Java, e Flash Builder na parte do Flex, impacta amplamente
nos prazos de desenvolvimento. Basta citar a complementação de código do NetBeans e o
reconhecimento e absorção dos Web Services pelo Flash Builder.
Um dos trabalhos futuros para este framework será a integração com o NetBeans para
que os desenvolvedores vejam a tarefa de criar novos componentes para os modelos de
simulação com “bons olhos”.
Ficou claro o nível de melhoria obtida com a implementação de um executor de
simulações distribuído, pois, baseado nos testes descritos ao final da Seção 4.3, observa-se
uma redução de tempo de simulação em torno de 90 % para o cálculo de quatro simulações
paralelas.
Os métodos de força-bruta aplicados a simuladores do tipo DEVS trouxe vantagens
em termos de número de amostragens, ao diminuir o tempo total necessário para a obtenção
destes resultados individuais, com o uso de várias simulações executando em paralelo,
embora não possibilite diminuir o tempo de processamento de simulações individuais.
A diminuição do tempo de processamento individual aqui obtida é decorrência da
utilização de processamento paralelo para as tarefas de I/O, além do uso do JPA para a
persistência dos dados, em contraposição ao JDBC padrão, o que trouxe vantagens em termos
de eficiência para as tarefas relacionadas a consultas e alterações no banco de dados.
171
Como as máquinas, individualmente, têm limitações com relação ao número de

processadores presentes, a tendência mais natural é que, com o aumento do número de
máquinas e de simulações aumente ainda mais essa distância entre a eficiência da versão
original do framework de ACCV e a da nova versão, até chegar a uma quantidade de
simulações que se tornaria inviável para o framework antigo.
Muitas estratégias foram modificadas ao longo do caminho no que tange à distribuição
do processamento. Isto não denegriu a arquitetura, pois foi obtida a funcionalidade esperada,
ou seja, executar simulações em máquinas cliente paralelamente, após a recepção dos objetos
referentes ao modelo de forma serializada, sem nenhum contato com a parte corporativa, a
qual é baseada em JEE5.
A utilização de JEE5 também é importante para a garantia da escalabilidade do
framework de ACCV, pois apesar do aumento da capacidade de processamento ocorrer com o
simples acréscimo de máquinas cliente, a recepção de dados e persistência é efetuada ao nível
do servidor, e a possibilidade de se utilizar servidores clusterizados acaba por permitir o
tratamento de grandes fluxos de dados.
Neste ponto do desenvolvimento a interoperabilidade se mostrou não como uma
vantagem, mas como uma necessidade para a viabilização do desenvolvimento dos módulos
cliente e servidor para processamento distribuído, substituindo-se a idéia inicial do uso de
RMI ou CORBA pela implementação de comunicação via Socket plano, com a concentração
das chamadas aos Web Services apenas do lado servidor.
A arquitetura orientada a serviços foi utilizada de forma conceitual, inclusive
hospedando os Web Services, em um servidor SOA (GlassFish), mas não houve necessidade
de se utilizar BPEL. Isto não impede que novos pesquisadores combinem estes serviços de
forma a gerar soluções totalmente inovadoras em trabalhos futuros, soluções estas que sequer
podem ser vislumbradas aqui.
Com a plena interoperabilidade obtida com o uso de Web Services foi possível
aproveitar as melhores características da linguagem Java em termos de processamento e
distribuição, ao mesmo tempo em que telas muito complexas e com grande requinte visual
foram construídas através do Flex. Novos sistemas poderão ser construídos em ambientes
como Visual Studio .Net, PHP, ou qualquer outra linguagem, devido às características de
comunicação e exposição de interface dos Web Services.
Isso também deixa o simulador alinhado com as tendências atuais para a criação de
simulações distribuídas, já que o modelo de utilização do framework é baseado em serviços,
172
com exposição através de um padrão amplamente utilizado, o que viabiliza a integração com
outros simuladores e ferramentas de interesse em ambiente HLA.
Outro fato a ser considerado é o de que o Modelo de Pilla e Cople satisfaz às
necessidades destas novas formas de implementação, e a divisão dos objetos pelo framework
em três níveis de abstração, com armazenamento de metadados e dados de catálogo em banco
de dados, normalmente em formato texto, e definição do comportamento em termos de código
Java, garantiu alta portabilidade em termos de sistema operacional, enquanto o uso de JPA
trouxe a mesma portabilidade em termos de bancos de dados.
Estes três níveis de abstração, aliados à reflexividade nativa da linguagem Java e o uso
de Web Services, acabam por permitir a criação de telas dinâmicas para os elementos de
catálogo em praticamente qualquer plataforma de desenvolvimento, aumentando a
interoperabilidade do framework por utilizar formatos de exportação do tipo XML, o que
satisfaz a um dos objetivos iniciais do trabalho, que era a criação de interfaces customizadas
para o framework, independentes do uso de Java.
A exportação via Web Services também foi determinante para a melhoria da análise de
resultados, demonstrada aqui através da interface em Flex, e a interoperabilidade obtida foi o
que permitiu a rápida construção do extrator de dados para Microsoft Excel, demonstrando a
possibilidade de uso de ferramentas especializadas de análise.
Espera-se que o desenvolvimento deste novo framework sirva para demonstrar a
importância de conceitos como reuso e interoperabilidade nas estratégias de pesquisa
operacional relacionadas à modelagem de sistemas e simulação computacional, aproveitando
softwares existentes e permitindo a criação de soluções em diferentes plataformas, sempre
tirando proveito de técnicas como uso de elementos genéricos, anotações e padrões de
desenvolvimento, de forma a minimizar o tempo para criação de novas soluções e maximizar
a integração entre as ferramentas, o que é indicado como ideal pelos atuais estudos na área de
Engenharia de Sistemas.
173
8. REFERÊNCIAS BIBLIOGRÁFICAS
ADELBERGER, C; KURZ, T; EDER, R; HEISTRACHER, T. Evaluation of two P2P-

Approaches for a Distributed Simulation Framework. Finlândia: The Second International
OPAALS Conference on Digital Ecosystems, 2008, 10 p.
ALEXANDER, C; ISHIKAWA, S; SILVERSTEIN, M. A pattern language: towns, buildings,

construction, Vol. 2. USA: Oxford University, 1977, 1171 p.
ALEXANDER, C. W. Discrete Event Simulation for Batch Processing. USA: Proceedings of

the 2006 Winter Simulation Conference (WSC), 2006, p. 1929-1934.
ALFONS, A; TEMPL, M; FILZMOSER, P. simFrame: An object-oriented framework for

statistical simulation. Austria: Technische Universität Wien, Forschungsbericht CS-2009-1,
2009, 25 p.
ARCINIEGAS, F. C++ XML, traduzido da versão em inglês. Brasil: Pearson, 2002.
BAILEY, J. W; BASILI, V. R. A meta-model for software development resource

expenditures. USA: IEEE, Fifth International Conference on Software Engineering, 1981,
p. 107-116.
BANKER, R. D; KAUFFMAN, R. J; ZWEIG, D. Repository Evaluation of Software Reuse.

USA: IEEE, Transactions on Software Engineering, Vol. 19, No. 4, 1993, p. 379-389.
174
BASILI, V. R; BRIAND, L. C; MELO, W. L. How reuse influences productivity in object-

oriented systems. USA: ACM, Communications of the ACM, Vol. 39, No. 10, 1996,
p. 104-116.
BASS, L; CLEMENTS, P; KASMAN, R. Software Architecture in Practice, 2nd ed. USA:

Addison Wesley, 2003.
BIEMAN J. M; ZHAO J. X. Reuse through inheritance: A quantitative study of C++

software. USA: Proceedings of the ACM SIGSOFT Symposium on Software Reusability,
1995, p. 47-52.
BIEMAN, J. M; KANG, B. K. Cohesion and reuse in an object-oriented system. USA: ACM

SIGSOFT Software Engineering Notes, Vol. 20, 1995, p. 259-262.
BLANCHARD, B. S; FABRICKY W. J. System Engineering and Analysis. 3 ed. USA:

Prentice-Hall, 1998.
BLOCH, J. Effective Java (Second Edition). USA: Prentice Hall, 2008, 384 p.
BOEHM, B. W. Software Engineering Economics. USA: Prentice-Hall, 1981.
BONAVENTURA, M; WAINER, G. A; CASTRO, R. Advanced IDE for Modeling and

Simulation of Discrete Event Systems. USA: ACM, Proceedings of 2010 Spring Simulation
Conference (SpringSim10), DEVS Symposium, 2010, 8 p.
BOOCH, G. Object-Oriented Analysis and Design with Applications. USA: The Benjamin
Cummings Publishing Co. Inc, 1994.
BORGES, R. C. Modelos para a Análise de Custo de Vida Útil. Brasil: UFF, Dissertação de
Mestrado, 2004.
BOSCH, J; BENGTSSON P. Assessing optimal software architecture maintainability.

Portugal: Fifth European Conference on Software Maintenance and Reengineering (CSMR),
2001, p. 168-175.
175
BREIT, M; VOGEL, M; HÄUBI, F; MÄRKI, F; RAPS, M. 4D Design and Simulation

Technologies and Process Design Patterns to Support Lean Construction Methods. USA:
Elsevier, Tsinghua Science and Technology, Vol. 13, No. 1, 2008, p.179-184.
BRICK, E. S; BORGES, R. C. Estrutura de Desdobramento de Custo para análise de custo de

vida útil de sistemas técnicos. Brasil: XXIV Encontro Nacional de Engenharia de Produção
(ENEGEP), 2004.
BURKE, B; MONSON-HAEFEL, R. Enterprise Java Beans 3.0, traduzido da versão em

inglês de 2006 (5ª edição). Brasil: Pearson, 2007
BUSCHMANN, F; MEUNIER, R; ROHNERT, H; SOMMERLAD, P; STAL, M.

Pattern-Oriented Software Architecture: A System Of Patterns. USA: John Wiley and Sons,
1996, 476 p.
BYRNE, J; HEAVEY, C; BYRNE, P. J. A review of Web-based simulation and supporting

tools. USA: Elsevier, Simulation Modelling Practice and Theory 18, 2010, p. 253-276.
CALDEWEYHER, D; PHAM, B; ZHANG, J. A Generic Adaptive Simulation Framework

For Outcome-Driven Collaborative Planning For Sustainability. Australia: SimTecT2007,
Simulation Industry Association of Australia Conference, 2007.
CAPOCCHI, L; BERNARDI, F; FEDERICI, D; BISGAMBIGLIA, P. BFS-DEVS: A general

DEVS-based formalism for behavioral fault simulation. USA: Elsevier, Simulation Modelling
Practice and Theory, Vol. 14, No. 7, 2006, p 945-970.
CAREY, R. W; BETTENHAUSEN, C. M; ESTES, C. M; FISHER, J. M; KRAMMEN, J. E;

LAGIN, L. J; LUDWIGSEN, A. P; MATHISEN, D. G; MATONE, J. T; PATTERSON,
R. W; REYNOLDS, C. A; SANCHEZ, R. J; STOUT, E. A; TAPPERO, J. D; ARSDALL, P.
Status of the Use of Large-Scale Corba-Distributed Software Framework for NIF Controls.
Suíça: 10th ICALEPCS Int. Conf. on Accelerator & Large Expt. Physics Control Systems,
2005.
176
CASTAGNA, G; GESBERT, N; PADOVANI, L. A Theory of Contracts for Web Services.

USA: ACM Transactions on Programming Languages and Systems, Vol. 31, No. 5, 2009,
p. 19.1-19.61.
CHANG, H; LEE, K. Applying Web Services and Design Patterns to Modeling and
Simulating Real-World Systems. Alemanha: Springer Berlin, Artificial Intelligence and
Simulation, Lecture Notes in Computer Science, 2005, p. 351-359.
CHEN, D; VALLESPIR, B; DACLIN, N. An Approach for Enterprise Interoperability

Measurement. França: MoDISE-EUS’2008, Model Driven Information Systems Engineering
-Enterprise, User and System Models, 2008, p. 1-12.
CHEN, L; XU, B. Slicing Java generic programs using generic system dependence graph.
USA: Wuhan University e Springer, Wuhan University Journal of Natural Sciences, Vol 14,
No 4, 2009, p. 304-308.
CHEN, Y. Modeling and Simulation for and in Service-Oriented Computing paradigm. USA:
ACM, Simulation Transactions, vol. 83, No. 1, 2007, p. 3-6.
CHOI, B. K; LEE, D; KANG, D. H. DEVS Modeling of Run-time Workflow Simulation and

Its Application. Chipre: Cyprus, 22nd European Conference on Modeling and Simulation,
2008, p. 3-6.
CHOW, A. C; ZEIGLER, B. P. Revised DEVS: A Parallel, Hierarchical, Modular Modeling

Formalism. USA: IEEE, Proceedings of the SCS Winter Simulation Conference, 1994,
p. 716-722.
CHUNG, L; COOPER, K. COTS-Aware Requirements Engineering and Software

Architecting. USA: Proc. Int. Workshop on Systems/Software Architectures (IWSSA’04),
2004, 7 p.
CICIRELLI, F; FURFARO, A; NIGRO, L. Conflict Management in PDEVS: An Experience

in Modelling and Simulation of Time Petri Nets. USA: Summer Computer Simulation
Conference (SCSC'07), 2007, p. 349-356.
177
CONCHO, A. L; RAMIREZ-MARQUEZ, J. E; HERALD, T. Functionally Equivalent COTS

for Optimal Component Substitution within System Evolution Planning. UK: Loughborough
University, 7th Annual Conference on Systems Engineering Research (CSER), 2009, 10 p.
COPLE, D. G. Simulação do Custo de Ciclo de Vida de Sistemas Técnicos. Brasil: UFF,

Dissertação de Mestrado, 2003.
COPLE, D. G; BRICK, E. S. A simulation framework for technical systems life cycle cost
analysis. USA: Elsevier, Simulation Modelling Practice and Theory 18, 2010, p. 9-34.
CORKILL, D. D; GALLAGHER, K. Q; JOHNSON, P. M. Achieving Flexibility, Efficiency,

and Generality in Blackboard Architectures. USA: University of Massachusetts, 1987, 14 p.
CORKILL, D. D. Blackboard Systems. USA: Blackboard Technology, 1991, 19 p. Versão

integral do artigo apresentado para AI Expert 6(9) , 1991, p. 40-47.
CZIBULA, I. G; CZIBULA, G. Identifying design patterns in object-oriented software

systems using unsupervised learning. USA: IEEE, International Conference on Automation,
Quality and Testing, Robotics, 2008, p. 347-352.
DALLE, O; RIBAULT, J; HIMMELSPACH, J. Design Considerations for M&S Software.

USA: IEEE, Proceedings of the 2009 Winter Simulation Conference, 2009, p. 944-955.
DAN, A; JOHNSON, R. D; CARRATO, T. SOA Service Reuse by Design. USA: ACM,

SDSOA'08 Proceedings of the 2nd international workshop on Systems development in SOA
environments, 2008, p. 25-28.
D’AMBROGIO, A; GIANNI, D; RISCO-MARTÍN, J. L; PIERONI, A. A MDA-based

approach for the development of DEVS/SOA simulations. USA: ACM, SpringSim'10,
Proceedings of the 2010 Spring Simulation Multiconference, 2010, 8 p.
DEITEL, H. M; DEITEL, P. J. Java – Como Programar. 3 ed, traduzido da versão em inglês.

Brasil: Bookman, 2001.
178
DEUTSCH, M. Life Cycle Cost Disclosure, Consumer Behavior, and Business Implications.
USA: Wiley, Journal of Industrial Ecology, Vol. 14, No. 1, 2010, p. 103-120.
DIAS, J; RODRIGUES, C; OGASAWARA, E; OLIVEIRA, D; BRAGANHOLO, V;

PACITTI, E; MATTOSO, M. SciMulator: Um Ambiente de Simulação de Workflows
Científicos em Redes P2P. Brasil: Editora SBC, XXVIII Simpósio Brasileiro de Redes de
Computadores e Sistemas Distribuídos, 2010, p. 45-56.
DONG, J; PENG, T; ZHAO, Y. On Instantiation and Integration Commutability of Design

Pattern. UK: Oxford University, The Computer Journal, 2010.
EGYED, A; BALZER, R. Integrating COTS Software into Systems through Instrumentation

and Reasoning. Holanda: Springer Science and Business Media, Inc, Automated Software
Engineering, Vol. 13, 2006, p. 41-64.
ERL, T. SOA: Princípios do design de serviços, versão traduzida. Brasil: Pearson, 2009.
EUGSTER, P; FELBER, P. A; GUERRAOUI, R; KERMARREC, A. M. The Many Faces of

Publish/Subscribe. USA: ACM Computing Surveys, Vol. 35, No. 2, 2003, p. 114-131.
FAN, M; ZHANG, J; FAN, Y. A heterogeneous model integration and interoperation

approach in distributed collaborative simulation environment. UK: Inderscience Publishers,
International Journal of Internet Manufacturing and Services, Vol. 2, 2010, p. 294-309.
FARLEY, J; CRAWFORD, W. Java Enterprise in a nutshell. USA: O’Reilly Media Inc, 3 ed,
2005, 896 p.
FAROOQ, U; PARSONS, E. W; MAJUMDAR, S. Performance of Publish/Subscribe

Middleware in Mobile Wireless Networks. USA: WOSP 04, 2004, p. 278-289.
FENTON, N. E; NEIL, M. Software Metrics: Roadmap. Irlanda: ICSE'00, Proceedings of the

Conference on The Future of Software Engineering, 2000, p. 357-370.
179
FIORINI, S. T. Arquitetura para Reutilização de Processos de Software. Brasil: Pontifícia

Universidade Católica do Rio de Janeiro, 2001, 243 p.
FRANÇOIS, A. R. J. Software Architecture for Computer Vision: Beyond Pipes and Filters.
USA: University of Southern California, 2003, 26 p.
FREEMAN, E; SIERRA, K; BATES, B. Head First design patterns. USA: O'Reilly Media,
Inc., 2004, 638 p.
FULLER, S. K; PETERSEN, S. R. NIST Handbook 135. USA: National Institute of Standard

and Technologies, 1996, 210p.
FUMAROLA, M; SECK, M; VERBRAECK, A. A DEVS component library for simulation-

based design of automated container terminals. Espanha: SIMUTOOLS, 2010.
FURFARO, A; NIGRO, L. A development methodology for embedded systems based on

RT-DEVS. UK: Springer London, Innovations in Systems and Software Engineering, Vol. 5,
No. 2, 2009, p. 117-127.
GAMMA E; HELM R; JOHNSON R; VLISSIDES J. Design Patterns - Elements of Reusable

Object-Oriented Software. USA: Addison-Wesley, 1994, 416 p.
GAMMA, E; HELM, R; JOHNSON, R; VLISSIDES, J. Design Patterns: Abstraction and

Reuse of Object-Oriented Design. Alemanha: ECOOP '93 - Proceedings of the 7th European
Conference on Object-Oriented Programming, 1993, p. 406-431.
GARCIA, R; JARVI, J; LUMSDAINE, A; SIEK, J; WILLCOCK, J. An extended

comparative study of language support for generic programming. UK: Cambridge University
Press, Journal of Functional Programming, Vol. 17, No. 2, 2007, p. 145-205.
GARCÍA, P; PAIROT, C; MONDÉJAR, R; PUJOL, J; TEJEDOR, H; RALLO, R. PlanetSim:

A New Overlay Network Simulation Framework. Alemanha: Springer-Verlag, 2005,
p. 123-136.
180
GARDAZI, S. U; SHAHID, A. A. Survey of software architecture description and usage in

software industry of Pakistan. Paquistão: Islamabad, ICET 2009, Emerging Technologies -
International Conference, 2009, p. 395-402.
GARLAN, D; SHAW, M. An Introduction to Software Architecture. USA: Carnegie Mellon

University Technical Report CMU-CS-94-166, 1994, 39 p.
GARRELS, T; JÜRGENS, H; SCHMIDTMANN, U; von CÖLLN, G. A Generic Approach

for the Simulation of Distributed Control Systems using J2EE Technology. USA: IEEE,
Informatics, 5th IEEE International Conference, Vol. 2, 2007, p. 805-810.
GARRIDO, J; ZAFRA, Á; VÁZQUEZ, F. Object oriented modelling and simulation of

hydropower plants with run-of-river scheme: A new simulation tool. USA: Simulation
Modelling Practice and Theory 17, 2009, p. 1748-1767.
GERVASI, V; GALILEI, G. A. Software Manipulation with Annotations in Java. Alemanha:

Springer Verlag - Advances in Software Engineering (Lecture Notes in Computer Science
Series), 2008, p. 161-184.
GILL, C. D. Resource Virtualization in Real-Time CORBA Middleware. USA: ACM,

CODES+ISSS’06, Seoul, Korea, 2006, p. 181-186.
GOEDECKE, M; THERDTHIANWONG, S; GHEEWALA, S. H. Life cycle cost analysis of

alternative vehicles and fuels in Thailand. USA: Elsevier, Energy Policy, Vol. 35, No. 6,
2007, p. 3236-3246.
GOLDSTEIN, R; WAINER, G. A. Modelling Tumor-Immune Systems with Cell-DEVS.

Chipre: Cyprus, Proceedings of the European Conference on Modelling and Simulation
(ECMS), 2008.
GONG, Y. CORBA Application in Real-Time Distributed Embedded Systems. USA: Survey

Report , ECE 8990 Real-Time Systems Design, Spring, 2003.
181
GUPTA, P; MEHLAWAT, M. K; VERMA, S. COTS selection using fuzzy interactive

approach. Alemanha: Springer Berlin, Optimization Letters, 2010, p. 1-17.
GURP, J. V; BOSCH, J. Design, implementation and evolution of object oriented

frameworks: concepts and guidelines. USA: Wiley, Software - Practice and Experience
Vol. 31, 2001, p. 277-300.
GUSTAVSON, P; MORSE, K; LUTZ, R; REICHENTHAL, S. Applying Design Patterns for

Enabling Simulation Interoperability. USA: In Proceedings of the Spring Simulation
Interoperability Workshop, 2004.
HAGENDORF, O. Simulation Based Parameter and Structure Optimisation of Discrete Event

Systems. UK: Liverpool John Moores University, 2009.
HAMILTON, A. Handbook of Project Management Procedures. UK: Thomas Telford

Publishing, 2004.
HAMRI, M; BAATI, L. On using Design Patterns for DEVS Modeling and Simulation Tools.
USA: Proceeding SpringSim'10, Proceedings of the Spring Simulation Multiconference,
2010.
HAN, S; HUANG, K. Equivalent Semantic Translation from Parallel DEVS Models to Time
Automata. Alemanha: Springer Berlin, Computational Science – ICCS 2007, Lecture Notes in
Computer Science, 2007, p. 1246-1253.
HE, Z. X; LIU, G; LIU, L; HE, L. Report Management in Performance Simulation for

Complex Mechanical Product. USA: Advanced Materials Research Vols. 97-101,
Manufacturing Science and Engineering, 2010.
HENNING, M. The Rise and Fall of CORBA . USA: ACM Queue, Vol. 4, No. 5, Component
Technologies, 2006, p. 28-34.
HEO, J. K. Distributed Cipher Services Using Object Activation. Coréia: AISS, Advances in
Information Sciences and Service Sciences, Vol. 2, No. 4, 2010, p. 115-122.
182
HEWETT, R; HEWETT M. Efficiency in pure blackboard systems. USA: IEEE, Tools with
Artificial Intelligence, 1992, p. 65-72.
HIMMELSPACH, J; UHRMACHER, A. M. Sequential processing of PDEVS models.

Espanha: Proceedings of the 3rd EMSS, 2006, p. 239-244.
HOLMAN, K; KUZUB, J; WAINER, G. A. UAV Search Strategies Using Cell-DEVS. USA:

SCS, Proceedings of 2010 Spring Simulation Conference (SpringSim10), 2010, p. 192-199.
HORSTMANN, C. Padrões e Projeto Orientados a Objetos - Segunda Edição, versão

traduzida. Brasil: Bookman, 2007, 423 p.
HUANG, B; HE, L; BAO, Y; LI, Z; LI, R. PeerMD: A P2P molecular dynamics simulation
framework based on Web services. USA: Wuhan University e Springer, Wuhan University
Journal of Natural Sciences, Vol. 13, No. 4, 2008, p. 471-474.
HUSSEY, A; CARRINGTON, D. Comparing the MVC and PAC architectures: a formal

perspective. USA: IEEE, Software Engineering, Vol. 144, No. 4, 1997, p. 224-236.
IERUSALIMSCHY, R; CERQUEIRA, R; RODRIGUEZ, N. Using reflexivity to interface

with CORBA. USA: Computer Languages, Proceedings International Conference, 1998,
p. 39-46.
ISLAM, A. S; PIASECKI, M. Ontology based web simulation system for hydrodynamic

modeling. USA: Elsevier, Simulation Modelling Practice and Theory, Vol. 16, No. 7, 2008,
p. 754-767.
JACOBI, I; RADUL, A. A RESTful Messaging System for Asynchronous Distributed

Processing. USA: ACM, WS-REST '10 Proceedings of the First International Workshop on
RESTful Design, 2010, p. 46-53.
JAIN, S. Simulation in the Next Millennium. USA: IEEE, In Proceedings of the Winter
Simulation Conference, 1999, p. 1478-1483.
183
JENDROCK, E; BALL, J; CARSON, D; EVANS, I; FORDIN, S. The Java EE 5 Tutorial for

Sun Java System Application Server 9. USA: Sun Microsystems, 2008, 1126 p.
JHA, P. C; ARORA, R; KAPUR, P. K; KUMAR, U. D. Optimal component selection of

COTS based software system under recovery block scheme incorporating execution time.
India: Springer India, International Journal of Systems Assurance Engineering and
Management, Vol. 1, No. 1, 2010, p. 77-83.
JOINES, J. A; ROBERTS, S. D. An introduction to object-oriented simulation in C++. USA:

IEEE, Winter Simulation Conference, 1997, p. 78-85.
JORDAN, M. A Comparative Study of Persistence Mechanisms for the Java Platform. USA:
Sun Microsystems, 2004, 45 p.
KAENZIG, J; WÜSTENHAGEN, R. The Effect of Life Cycle Cost Information on Consumer

Investment Decisions Regarding Eco-Innovation. USA: Wiley-Blackwell, Journal of
Industrial Ecology, Vol. 14, No. 1, 2010, p. 121-136.
KAMAUCHI, Y; RAUSAND, M. Life Cycle Cost Analysis in Oil Chemical Process

Industries. Noruega: Norwegian University of Science and Technology, 1999, 75p.
KARUNANITHI S ; BIEMAN J. M. Measuring Software Reuse in Object Oriented Systems

and Ada Software. USA: Ada Software, 1993.
KEMERER C. F. An empirical validation of software cost estimation models. USA: ACM,

Communications of the ACM, Vol. 30, No. 5, 1987, p. 416-429.
KELLER, A; KELLY, M; TODD, A. CASEsim Usability and an Actor-based Framework for

Multi-Agent System Simulations. USA: Trinity University, 2010, 15 p.
KLAN, F; RÖHL, M; KÖNIG-RIES, B; UHRMACHER, A. M. Using context information to

evaluate cooperativeness. USA: ACM New York, Q2SWinet '08 Proceedings of the 4th ACM
symposium on QoS and security for wireless and mobile networks, 2008, p. 98-105.
184
KORSON, T; McGREGOR, J. D. Understanding Object-Oriented: a Unifying Paradigm.

USA: ACM, Communications of the ACM, Vol. 33, No. 9, 1990, p. 40-60.
KOSTURIAK, J; GREGOR, M. Simulation in production system life cycle. USA: Elsevier,

Computers in Industry, 38, 1999, p. 159-172.
KOUNEV, S; DUTZ, C. QPME A Performance Modeling Tool Based on Queueing Petri

Nets. USA: ACM, ACM SIGMETRICS Performance Evaluation Review archive, Vol. 36,
No. 4, 2009.
KOUTITAS, G; PAVLIDOU, N; JANKOVIC, L. A comparative study of two alternative

wildfire models, with applications to WSN topology control. UK: WITPress, Modelling,
Monitoring and Management of Forest Fires II, 2010, p. 25-36.
KRUEGER, C.W. Software reuse. USA: ACM, ACM Computing. Survey, Vol. 24, No. 2,
1992, p. 131-183.
KSHIRSAGAR, A. S; EL-GAFY, M. A; ABDELHAMID, T. S. Suitability of life cycle cost

analysis (LCCA) as asset management tools for institutional buildings. UK: Emerald
Publishing, Journal of Facilities Management, Vol. 8, No. 3, 2010.
LANGFORD, J. W. Logistic Principles and Applications. USA: Mc-Graw-Hill, Logistics

Series, 1995.
LAW, A. M; KELTON, W. D. Simulation Modeling and Analysis. USA: Mc Graw Hill,

terceira edição, 2000, 760 p.
LEE, J. K; CHI, S. D. Using Symbolic DEVS Simulation to Generate Optimal Traffic Signal
Timings. USA: SCS, SIMULATION, Vol. 81, No. 2, 2005, p. 153-170.
LIEBERMANN, Y; UNGAR, M. Efficiency of consumer intertemporal choice under life

cycle cost conditions. USA: Elsevier, Journal of Economic Psychology, Vol. 23, No. 6, 2002,
p. 729-748.
185
LIM, S. H; SHARMA, B; NAM, G; KIM, E. K; DAS, C.R. MDCSim: A multi-tier data

center simulation, platform. USA: IEEE, Cluster Computing and Workshops, 2009, p. 1-9.
LIU, G; HUANG, Q; HAN, J. Architecture Development of Research Flight Simulator Based

on COTS. China: Information Engineering and Computer Science (ICIECS 2009), 2009,
p. 1-4.
LOCK, D. Project Management. UK: Gower Publishing Limited, 9a edição, 2007, 523 p.
MADU, C. N. Strategic value of reliability and maintainability management. UK:

International journal of quality and reliability management, Vol. 22, No. 3, 2005, p. 317-328.
MANNISTO, T; SAVOLAINEN, J; MYLLARNIEMI, V. Teaching Software Architecture

Design. Canada: Working IEEE/IFIP Conference on Software Architecture (WICSA 08),
2008, p. 117-124.
MARIA, A. Introduction to Modeling and Simulation. USA: IEEE, Winter Simulation

Conference, 1997, p. 7-13.
MEHTA, H; KANUNGO, P; CHANDWANI, M. Generic Data Access and Integration

Service for Distributed Computing Environment. Australia: International Journal of Grid
Computing & Applications (IJGCA), Vol. 1, No. 1, 2010, p. 14-21.
MEYER, C. R; RENSCHLER, C. S; VINING, R. C. Implementing quality control on a

random number stream to improve a stochastic weather generator. USA: Wiley InterScience,
Hydrological Processes 22, 2008, p. 1069-1079.
MITTAL S; RISCO-MARTÍN, J. L; ZEIGLER, B. P. DEVSML: Automating DEVS

Execution over SOA Towards Transparent Simulators. USA: DEVS Integrative M&S
Symposium DEVS'07, 2007.
MOHAMED, A; RUHE, G; EBERLEIN. A. Sensitivity analysis in the process of COTS

mismatch-handling. Alemanha: Springer-Verlag, Requirements Eng 13, 2008, p. 147-165.
186
MONTALTO, G; PASETTI, A; SALERNO, N. Application of Software Framework

Technology to an Antenna Pointing Controller. Irlanda: Data System in Aerospace (DASIA)
Conference, 2002, 10 p.
MORSE, K. L; LIGHTNER, M; LITTLE, R; LUTZ, B; SCRUDDER, R. Enabling

Simulation Interoperability. USA: Computer, Vol. 39, No. 1, 2006, p. 115-117.
MUKHAR, K; ZELENAK, C; WEAVER, J. L; CRUME, J. Beginning Java EE 5: from

novice to professional. USA: Apress, 2006, 672 p.
NARDI, A. R. Componentes CORBA. Brasil: Universidade de São Paulo, Instituto de

Matemática e Estatística, Dissertação de Mestrado, 2003.
NELSON, J. Structured Programming Using Processes. USA: ACM, Proceedings of the 2004
ACM SIGPLAN workshop on Erlang, 2004, p. 54-64.
NGUYEN, D; RICKEN, M; WONG, S. Design Patterns for Marine Biology Simulation.

USA: ACM, SIGCSE’04, 2004.
NIGUL, L; MAH, E. Software maintainability benefits from annotation-driven code. USA:

IEEE International Conference on Software Maintenance, 2009, p. 417-421.
NTAIMO, L; ZEIGLER B. P. Expression of a forest cell model in parallel DEVS and Timed
Cell-DEVS formalisms. USA: Proceedings of the 2004 Summer Computer Simulation
Conference, 2004.
NUTARO, J; HAMMONDS, P. Combining the Model/View/Control Design Pattern with the

DEVS Formalism to Achieve Rigor and Reusability in Distributed Simulation. USA: SCS,
The Journal of Defense Modeling and Simulation: Applications, Methodology, Technology,
2004, p. 19-28.
OSES, N; PIDD, M; BROOKS, R.J. Critical issues in the development of component-based

discrete simulation. USA: Elsevier, Simulation Modelling Practice and Theory 12, 2004,
p. 495-514.
187
PAGE, B; KNAAK, N; KRUSE, A. A Discrete Event Simulation Framework for Agent-

Based Modelling of Logistic Systems. Dinamarca: In GI Jahrestagung (1), Vol. 109, 2007,
p. 397-404.
PANG, G. H. Elevator scheduling system using blackboard architecture. USA: IEEE, Control
Theory and Applications, Vol. 138, No. 4, 1991, p. 337-346.
PAPAZOGLOU, M. P; TRAVERSO, P; DUSTDAR, S; LEYMANN, F. Service-Oriented

Computing: State of the Art and Research Challenges. USA: IEEE Computer Society,
Computer, Vol. 40, No. 11, 2007, p. 38-45.
PARK, S. C; PARK, C. M; WANG, G. A PLC programming environment based on a virtual

plant. USA: Springer, International Journal of Advanced Manufacturing Technology, 2008.
PEREIRA, F. M. Q. Arcademis: Um Arcabouço para Construção de Sistemas de Objetos

Distribuídos em Java. Brasil: Universidade Federal de Minas Gerais, Dissertação de
Mestrado, 2003.
PERROS, H; Computer Simulation Techniques: The definitive introduction; USA: Computer

Science Department, NC State University, 2009.
PILLA, L. H. Sistemas de Apoio à Decisão: uma Contribuição ao Estudo de Análise de Custo

de Ciclo de Vida. Brasil: UFF, Dissertação de Mestrado, 2003.
POULIN, J.S.; CARUSO, J.M. Determining the value of a corporate reuse program. USA:
IEEE, Proceedings of the First IEEE Computer Society International Software Metrics
Symposium, 1993, p. 16-27.
PULECCHI, T; CASELLA, F; LOVERA, M. Object-oriented modelling for spacecraft

dynamics: Tools and applications. USA: Elsevier, Simulation Modelling Practice and Theory
18, 2010, p. 63-86.
188
QELA, B; WAINER, G; MOUFTAH, H. Simulation of large wireless sensor networks using

Cell-DEVS. USA: IEEE, Proceedings of the Winter Simulation Conference, 2009,
p. 3189-3200.
QIN, Z; XING, J; ZHENG, X. Software Architecture. China: Zhejiang University Press,

2008, 351 p.
RINALDI, P. R; DALPONTE, D. D; VÉNERE, M. J; CLAUSSE, A. Cellular automata

algorithm for simulation of surface flows in large plains. USA: Elsevier, Simulation
Modelling Practice and Theory, Vol. 15, No. 3, 2007, p. 315-327.
ROBINSON, S; NANCE, R. E; PAUL, R. J; PIDD, M; TAYLOR, S. J. E. Simulation model

reuse: definitions, benefits and obstacles. USA: Elsevier, Simulation Practice and Theory 12,
2004, p. 479-494.
RODRIGUEZ, S; HILAIRE, V; KOUKAM, A. Towards a holonic multiple aspect analysis

and modeling approach for complex systems: Application to the simulation of industrial
plants. USA: Elsevier, Simulation Modelling Practice and Theory, Vol. 15, No. 5, 2007,
p. 521-543.
RÖHL, M; UHRMACHER, A. M. Definition and Analysis of Composition Structures for

Discrete-Event Models. USA: IEEE, Proceedings of the Winter Simulation Conference, 2008,
p. 942-950.
ROMAN, E; SRIGANESH, R. P; BROSE, G. Mastering Enterprise JavaBeans, 3rd Edition.

USA: Wiley Publishing, Inc, 2005, 839 p.
ROSSETTI, M. D; MIMAN, M; VARGHESE, V; XIANG, Y. An Object-Oriented

Framework for Simulating Multi-Echelon Inventory Systems. USA: IEEE, Proceedings of the
Winter Simulation Conference, 2006, p. 1452-1461.
RUMBAUGH, J; JACOBSON, I; BOOCH, G. UML: Guia do Usuário, 3a ed, versão

traduzida. Rio de Janeiro: Editora Campus, 2000, 472 p.
189
RUMBAUGH J; BLAHA M; PREMERLANI W; EDDY F; LORENSEN W. Object-Oriented

Modeling and Design. USA: Prentice Hall, 1991.
RYPÁČEK, O; BACKHOUSE, R; NILSSON, H. Type-Theoretic Design Patterns. USA:

ACM, WGP’06 September 16, 2006.
SANZ, V; URQUIA, A; CELLIER, F. E; DORMIDO, S. System modeling using the Parallel

DEVS formalism and the Modelica language. USA: Elsevier, Simulation Modelling Practice
and Theory 18, 2010, p. 998-1018.
SCHMIDT, J. W; TAYLOR, R. E. Simulation and analysis of industrial systems. USA: Irwin

series in quantitative analysis for business, 1970, 644 p.
SCHMIDT, J. W. Fundamentals of Digital Simulation Modeling. USA: IEEE Press,

Proceedings of the 1980 Winter Simulation Conference, 1980, p. 315-323.
SCHMIDT, J. W. Introduction to Simulation. USA: IEEE Press, Proceedings of the 16th

Winter Simulation Conference, 1984, p. 64-73.
SCHWARZKOPF, R; MATHES, M; HEINZL, S; FREISLEBEN, B; DOHMANN, H. Java

RMI versus .NET Remoting Architectural Comparison and Performance Evaluation. México:
ICN '08, 2008, p. 398-407.
SCHWATINSKI, T; PAWLETTA, T. An advanced simulation approach for parallel DEVS

with ports. USA: ACM, Proceedings of the 2010 Spring Simulation Multiconference, 2010.
SEARLE, J; BRENNAN, J. General Interoperability Concepts. França: RTO, Report

apresentado em conferência da NATO, Integration of Modelling and Simulation, Educational
Notes RTO-EN-MSG-067, Paper 3, 2007, p. 3.1-3.8.
SEDGEWICK, R. Algorithms. 2 ed. USA: Addison-Wesley Publishing, 1988, 650 p.
SEDIGH-ALI, S; GHAFOOR, A; PAUL, R. A. Engineering Metrics for COTS-Based

Systems. USA: IEEE, Computer Vol. 34, 2001, p. 44-50.
190
SEO, H. S. Network security agent DEVS simulation modeling. USA: Elsevier, Simulation
SHALLOWAY, A; TROTT J. R. Design Patterns Explained – A new perspective on object-

oriented design. USA: Addison-Wesley, 2002, 334 p.
SHAW, M; GARLAN, D. Software Architecture: Perspectives on an Emerging Discipline.

USA: Prentice Hall, 1996, 242 p.
SEO, H. S. Network security agent DEVS simulation modeling. USA: Elsevier, Simulation
SEO, C; ZEIGLER, B. P. DEVS namespace for interoperable DEVS/SOA. USA: IEEE,

WSC’09, Proceedings of the Winter Simulation Conference, 2009, p. 1311-1322.
SOUSA, F. M.; ALENCAR, F. M. R.; CASTRO, J. F. B. O Impacto dos COTS no Processo

de Engenharia de Requisitos. Argentina: Anais do WER99 - Workshop em Engenharia de
Requisitos, 1999, p. 175-186.
SRIDARAN, R; PADMAVATHI, G; IYAKUTTI, K; MANI, M. N. S. SPIM Architecture for

MVC based Web Applications. USA: Journal of Advanced Networking and Applications,
Vol. 1, No. 1, 2009, p. 63-68.
STOUT, E. A; CAREY, R. W; ESTES, C. M; FISHER, J. M; LAGIN, L. J; MATHISEN,

D. G; REYNOLDS, C. A; SANCHEZ, R. J. CORBA-Based Distributed Software Framework
for the NIF Integrated Computer Control System. USA: Lawrence Livermore National
Laboratory, Sixth IAEA Technical Meeting on Control, Data Acquisition, and Remote
Participation for Fusion Research, 2007, 5p.
STRASSBURGER, S. Overview about the High Level Architecture for Modelling and
Simulation and Recent Developments. Austria: ARGESIM / EUROSIM / ASIM, Simulation
News Europe (SNE), Vol. 16, No. 2, 2006, p. 5-14.
191
STRITZINGER, A. Reusable Software Components and Application Frameworks - Concepts,

Design Principles and Implications. Austria: Johannes Kepler Universität Linz, 1991, 128 p.
TSAI, W. T; FAN, C; CHEN, Y; PAUL, R. A service-oriented modeling and simulation

framework for rapid development of distributed applications. USA: Elsevier, Simulation
TYTULA, T. P. Design to Cost. USA: John Wiley & Sons, Cost Estimator’s Reference
Manual, 1995, p. 317-352.
VASCONCELLOS, M; GARCIA, M. Fundamentos de Economia. Brasil: Editora Saraiva,

1998, 240 p.
VINOSKI, S. CORBA: integrating diverse applications within distributed heterogeneous

environments. USA: IEEE, Communications Magazine, Vol. 35, No. 2, 1997, p. 46-55.
VINOSKI, S. Where is Middleware? USA: IEEE, Internet Computing, Vol. 6, No. 2, 2002,
p. 83-85.
WAGHMODE, L. Y; SAHASRABUDHE, A. D. Product Life Cycle Cost Modelling: A

Suggested Framework. IEEE: Emerging Trends in Engineering and Technology, ICETET '08,
2008, p. 745-748.
WAINER, G. A. ATLAS: A language to specify traffic models using Cell-DEVS. USA:

Elsevier, Simulation Modelling Practice and Theory 14, 2006, p. 313-337.
WAINER, G. A. Modeling and simulation of complex systems with Cell-DEVS. USA: IEEE
Press, Proceedings of the Winter Simulation Conference, 2004, p. 49-60.
WAINER, G. A; GIAMBIASI, N. Cell-DEVS/GDEVS for Complex Continuous Systems.

USA: SCS, SIMULATION, 2005, p. 137-151.
WAINER, G. A; GIAMBIASI, N. Timed Cell-DEVS: modelling and simulation of cell

spaces. USA: Springer, Discrete Event Modeling & Simulation, 2001, p. 187-214.
192
WANG, Q; CHATWIN, C. R. Key issues and developments in modelling and simulation-

based methodologies for manufacturing systems analysis, design and performance evaluation.
UK: Springer London, The International Journal of Advanced Manufacturing Technology,
2005, p. 1254-1265.
WANG, K; YUAN, Y; LI, J. A Simulation System for Computational Cell Models Based on
Object-Oriented Design Patterns. Canada: Computer and Information Science, Vol. 3, No. 2,
2010, p. 106-115.
WANG, X; CHEN, Y; LU, C; KOUTSOUKOS, X. FC-ORB: A robust distributed real-time

embedded middleware with end-to-end utilization control. USA: Elsevier, The Journal of
Systems and Software 80, 2007, p. 938-950.
WANG, X; LU, C; GILL, C. FCS/nORB: A feedback control real-time scheduling service for
embedded ORB middleware. USA: Elsevier, Microprocessors and Microsystems 32, 2008,
p. 413-424.
WANYAMA, T; FAR, B. H. An Empirical Study to Compare Three Methods for Selecting

Cots Software Components. Uganda: International Journal of Computing and ICT Research,
Vol. 2, No. 1, 2008, p. 34-46.
YALCIN, A; NAMBALLA, R. K. An object-oriented simulation framework for real-time

control of automated flexible manufacturing systems. USA: Elsevier, Computers & Industrial
Engineering, Vol. 48, No. 1, 2005, p. 111-127.
YAMAGUTI, M. H; PRICE, R. T. Uma Arquitetura Reflexiva Baseada na Web para

Ambiente de Suporte a Processo. Brasil: Gramado, XVI Simpósio Brasileiro de Engenharia
de Software, 2002, p. 284-299.
YANG, Y. J; KIM, S. Y; CHOI, G. J; CHO, E. S; KIM, C. J; KIM, S. D. A UML-based

Object-Oriented Framework Development Methodology. Coréia: ETRI Computer & Software
Technology Laboratory / Soongsil University, 1998, 8p.
193
YAO, H; ZHANG, H; DUAN, F. Research and design on distributed remote simulation based
on Web. USA: IEEE, Information Management and Engineering (ICIME), The 2nd IEEE
International Conference, 2010, p. 522-525.
YU, S; LI-LI, W. Research and development of message service based on JMS. USA: Journal
of Communication and Computer, Vol. 4, No. 5, 2007, p. 47-52.
YUAN, G. N; ZHANG, Z. Design and Simulation of Distributed Vehicle Monitoring System

Based on WebGIS. USA: Elsevier, Journal Applied Mechanics and Materials, Information
Technology for Manufacturing Systems, 2010, p. 1009-1014.
ZEIGLER, B. P. Theory of Modeling and Simulation. USA: Wiley-Interscience Publication,

John Wiley & Sons, 1976, 435 p.
ZEIGLER, B. P; KIM, D. Design of High Level Modelling / High Performance Simulation

Environments. USA: IEEE, Parallel and Distributed Simulation, 1996, p. 154-161.
ZEIGLER, B. P; SARJOUGHIAN, H. S. Introduction to DEVS Modeling and Simulation

with Java: Developing Component-based Simulation Models. USA: University of Arizona,
Arizona Center for Integrative Modeling and Simulation, 2003, 147 p.
ZHENG, S; ZHENG, S; HE, J; HAN, J. An Optimized Distributed Real-time Simulation

Framework for High Fidelity Flight Simulator Research. USA: IEEE, Proceedings of the
IEEE International Conference on Information and Automation, 2009, p. 1597-1601.
ZIA, M; MUSTAFIZ, S; VANGHELUWE, H; KIENZLE, J. A modelling and simulation

based process for dependable systems design. USA: Springer, Software System and
Modeling, 2007, p. 437-451.
194
ANEXO A - REUSO DE SOFTWARE
A.1 INTRODUÇÃO
O reuso de software, aliado à padronização de interfaces e formato da informação,

permite que uma mesma solução seja utilizada em ambientes diversos e novas situações,
aproveitando todos os recursos já existentes, e facilitando a evolução dos sistemas e do
conhecimento.
Para Poulin e Caruso (1993 p. 18), sempre que um componente já existente evita o
desenvolvimento de um similar em um determinado projeto, isto é considerado como reuso,
mas se este componente é utilizado numerosas vezes neste projeto, o reuso é considerado
apenas uma vez. Isto se deve ao fato de que o tempo economizado ao evitar o
desenvolvimento de um novo componente não trará mais benefícios com o uso intensivo do
mesmo no projeto.
Uma característica interessante de reuso é definida por Krueger (1992 p. 136), ao dizer
que para uma técnica de reuso de software ser efetiva, a mesma deve diminuir a distância
cognitiva entre a concepção inicial do sistema e a execução de sua implementação final.
Basili, Briand e Melo (1996 p.105) defendem o reuso de software, não só por diminuir
o tempo e custo de desenvolvimento, assim como da manutenção, mas também por aumentar
a qualidade dos softwares criados. Isto se deve principalmente ao fato de que, ao apoiar um
novo produto em componentes já testados e certificados, diminuem-se os erros de boa parte
do novo software e o tempo disponível para o desenvolvimento das partes a serem
especializadas aumenta, permitindo uma gerência mais refinada da qualidade do produto final,
o que define um ciclo de qualidade e produtividade que tende a continuar indefinidamente.
No entanto, deve-se considerar que a criação de uma biblioteca reutilizável é um
esforço computacional grande, que não teria retorno se o componente fosse aplicado apenas a
195
um sistema. O ganho com a reutilização será observado apenas quando a economia de esforço
cumulativa na criação de sucessivos sistemas e funcionalidades for menor que o esforço
adicional de se projetar os componentes iniciais pensando em reuso.
A.2 PROGRAMAÇÃO ORIENTADA A OBJETOS
Segundo Nelson (2004 p.1), a programação estruturada surgiu com o intuito de guiar
os programadores na construção de códigos corretos e de melhor manutenção, sendo baseada
em três princípios fundamentais:
• Evolução incremental;
• Estruturas de dados localizadas; e
• Decomposição modular.
Para Rumbaugh, Jacobson e Booch (2000 p.11), não existe nenhuma grande
desvantagem nessa solução, com exceção da tendência a permitir sistemas instáveis. À
medida que os requisitos se modificam e o sistema cresce, será difícil fazer a manutenção de
sistemas construídos a partir do foco em algoritmos.
A modelagem contemporânea de sistemas baseia-se em personagens, com atributos e
comportamentos definidos, os quais interagem de diferentes formas, transformando o sistema
no resultado final destes relacionamentos. Estes personagens são os objetos, sendo que um
conjunto de objetos semelhantes levará à definição de uma classe, como citado por Korson e
McGregor (1990 p.42), ou sob outro ponto de vista, um objeto seria um personagem criado a
partir das regras definidas no “molde”, que é a classe.
Segundo Rumbaugh et al. (1991 p.1), partindo de uma análise superficial, esta
metodologia olha para o sistema como uma coleção de objetos discretos que incorporam tanto
a estrutura de dados quanto o comportamento. Isto está em contraste com a programação
convencional, onde as estruturas de dados e o comportamento, definido através de processos,
são fracamente ligados.
Oses, Pidd e Brooks (2004 p.503), destacam três grandes vantagens da abordagem
orientada a objetos. “Inicialmente, a implementação é segura, já que efeitos colaterais
inesperados podem ser contidos dentro do módulo específico. Por outro lado, facilita o
processo de desenvolvimento, ao dividir o modelo em unidades menores que podem, pelo
menos em princípio, ser testadas separadamente. Finalmente, as novas classes podem herdar
196
as características das classes já existentes, evitando a necessidade de alterar o código original,

para adicionar novas funcionalidades”.
O aumento da complexidade e dimensão dos sistemas levou a uma mudança na forma
de avaliar a facilidade de manutenção. Segundo Nelson (2004 p.1), os princípios básicos
evoluíram para encapsulamento, abstração e isolamento.
• Encapsulamento proporciona uma camada protetora ao redor das estruturas de

dados para reduzir o impacto das alterações de requisitos;
• Abstração representa os recursos de um encapsulamento de forma coerente,
sem exposição da implementação interna, reduzindo a complexidade do código
que interage com o modelo de dados encapsulados; e
• Isolamento consiste em separar módulos e código para que o número de interações
seja reduzido.
A programação orientada a objetos fornece uma maneira moderna e convencional para

a implementação destes elementos básicos, particularmente com a abstração e o
encapsulamento proporcionados pelas classes, e o isolamento obtido com as interfaces.
Para Basili, Briand e Melo (1996 p.115), o reuso de classes é considerado como uma
das mais atrativas estratégias para aumentar a produtividade. Ainda segundo o autor, como a
produtividade pode ser analisada em termos de uma função exponencial associada ao tamanho
do software, uma redução da quantidade de código a ser gerada provê uma redução drástica
do custo de desenvolvimento.
Claro que, com um nível maior de abstração e regras rígidas quanto ao
encapsulamento, a complexidade e tamanho do código aumentam, tornando a orientação a
objetos interessante apenas quando utiliza ou provê o reuso de classes.
A.2.1 Herança
A herança é uma característica que permite criar novas estruturas baseadas nas
estruturas já existentes, ou seja, derivar novas classes das atuais, acrescentando outras
características, processo também chamado de especialização. Esta técnica deve ser utilizada
nos casos em que as classes já existentes satisfazem parte do problema, mas não todo,
necessitando uma adaptação maior ao contexto.
197
Para Rumbaugh et al. (1991 p.39), generalização é o relacionamento entre uma classe
e uma ou mais versões refinadas da mesma. A classe a ser refinada é denominada superclasse,
enquanto cada versão refinada é denominada subclasse. Ainda segundo o autor, este refino
pode ocorrer em um número arbitrário de níveis, denominando-se como ancestrais as classes
mais genéricas, e descendentes os refinos subseqüentes. Com o uso de herança é possível
implementar os relacionamentos do tipo generalização-especialização.
Segundo Deitel e Deitel (2001 p.386), os relacionamentos de herança formam
estruturas hieráquicas do tipo árvore. Uma superclasse existe em um relacionamento
hierárquico com suas subclasses. Uma classe certamente pode existir de forma isolada, mas,
quando é utilizada no mecanismo de herança, a mesma se torna uma superclasse, fornecendo
atributos e comportamentos para outras classes, as quais passam a ser suas subclasses.
Certamente o Modelo de Pilla e Cople tira muito proveito da técnica de herança, como
na definição de meios de transporte a serem utilizados na simulação. Como os meios de
transporte são muito diversos, e seu custo varia muito devido a distância percorrida e tipo de
combustível utilizado, custo da utilização do serviço, mão de obra especializada para a
operação do meio de transporte, entre muitos outros fatores, a utilização de herança permite o
acréscimo de um novo meio de transporte (como o ferroviário) de forma simples, sem
impactar nos demais já existentes, e podendo ser incorporado facilmente ao processo de
cálculo. O exemplo de herança aqui citado pode ser observado na Figura 98.
Figura 98: Exemplo de herança no Modelo de Pilla e Cople
O uso de herança é o que diferencia a orientação a objetos das técnicas tradicionais de

programação com o uso de bibliotecas. O reuso através da herança permite não apenas
aproveitar um componente já existente, mas também adaptá-lo a novas situações sem alterar o
modelo original, já utilizado em outros sistemas, e esta independência evolucionária permite
198
maior tranqüilidade quanto à gerência da qualidade de produtos já existentes, a partir do

momento em que seus componentes não são modificados.
Segundo Bieman e Zhao (1995 p.47), a herança é uma excelente ferramenta para a
organização de abstrações, assim como uma ferramenta de reuso. Ainda segundo o autor, o
uso de herança tem alguns custos, pois a herança aumenta a complexidade do sistema e o
acoplamento entre classes.
Este acoplamento natural pode se tornar um problema em sistemas maiores, pois
apesar da herança permitir uma rápida expansão do sistema com a criação de novas
subclasses, a manutenção de uma superclasse pode refletir sobre diversos pontos do sistema,
principalmente se houverem muitos níveis de especialização na hierarquia da árvore.
Outra característica interessante da orientação a objetos é a possibilidade de se utilizar
descendentes de uma classe no lugar da mesma dentro de qualquer operação. Isto permite que
classes refinadas participem de processos legados, impedindo a que o sistema interrompa seu
funcionamento.
Da mesma forma, é possível definir processos genéricos, baseados em classes
abstratas, nos quais as classes descendentes irão adaptar estes processos a diferentes
contextos, técnica amplamente utilizada no Modelo de Pilla e Cople, o que viabiliza a
utilização do framework nos mais diversos ambientes. Um exemplo da utilização desta técnica
é demonstrado na Figura 99, utilizando linguagem Java.
public class ExemploCustoRefinado {
public double calcularCusto (MeioTransporte transporte, double distancia) {

return transporte.getFatorCusto() * distancia;
}
public static void main (String[] args) {

ExemploCustoRefinado ecr = new ExemploCustoRefinado();
System.out.println(“Calculo do custo de transporte para 1000 Km”);
System.out.println(“De aviao: “+ecr.calcularCusto(new Aviao(),1000);
System.out.println(“De aviao: “+ecr.calcularCusto(new Navio(),1000);
System.out.println(“De carro: “+ecr.calcularCusto(new Carro(),1000);
}
Figura 99: Exemplo de uso do Java com instâncias de descendentes

199
Segundo Rumbaugh et al. (1991 p.284), um erro comum na utilização da herança

ocorre quando o uso da mesma parece incrementar o reuso de código, enquanto uma
verdadeira relação de generalização-especialização não existe. Nestes casos, a forma correta
de se estruturar o código é a utilização de delegação de responsabilidades. A operação é
encapsulada na classe desejada, e repassada para outra classe responsável pela execução.
A.2.2 Polimorfismo e Elementos Abstratos
Polimorfismo é alteração da funcionalidade de um método em diferentes níveis da

hierarquia de classes, sem alterar o formato original. Permite que os descendentes alterem a
funcionalidade de algo feito pela classe inicial, aproveitando ou não o que a mesma fazia.
O polimorfismo se aplica unicamente aos métodos herdados de uma classe base, o que
justifica a denominação, que significa “múltiplas formas”. Cada classe pode ter uma
implementação diferente para um determinado método, onde o nome e formato do método são
os mesmos, entretanto o que é executado diferencia-se a cada nível da hierarquia.
O polimorfismo apresenta um papel importante na simplificação da sintaxe ao realizar
a mesma operação sobre uma família de classes. Ele simplifica a tarefa do programador
generalizando a sintaxe de comunicação que permite tratar objetos de tipos diferentes de
modo similar.
Quando os métodos polimórficos são utilizados, o compilador não pode determinar
qual método chamar. O método específico chamado depende da classe utilizada, sendo
determinado em tempo de execução, o que é possível através de uma tecnologia chamada
“late binding”.
Deitel e Deitel (2001 p.405), ressaltam a importância do polimorfismo, a partir do
momento em que permite projetar e implementar sistemas que são mais facilmente
extensíveis. Os sistemas podem ser modelados para processar genericamente, como objetos
de superclasse, objetos de todas as subclasses existentes na hierarquia. As classes que não
existem durante o desenvolvimento do sistema podem ser adicionadas com pouca ou
nenhuma modificação da parte genérica do programa, contanto que essas classes sejam parte
da hierarquia que está sendo processada genericamente.
200
Um exemplo de polimorfismo utilizado no Modelo de Pilla e Cople pode ser

observado na Figura 100, onde ocorre a modificação do método “getFatorCusto” a cada nível
da hierarquia de classes, haja visto a diferença de cálculo de custo para cada um dos meios de
transporte ilustrados.
Figura 100: Exemplo de polimorfismo no Modelo de Pilla e Cople
Outro elemento, que passa a fazer sentido junto com o polimorfismo, é o método
abstrato, cujo formato é definido, mas não sua funcionalidade. Sempre que uma classe tem
pelo menos um método abstrato, a mesma não pode gerar objetos e torna-se uma classe
abstrata. A vantagem de lidar com elementos abstratos é a possibilidade de definição de
tratamentos genéricos para personagens que sequer existem e regras comportamentais para
famílias de classes.
Segundo Rumbaugh et al. (1991 p.61), uma classe abstrata não pode instanciar
objetos, mas cujos descendentes podem ter instâncias diretas. A condição para que isto ocorra
é a de que os descendentes implementem os métodos abstratos definidos nas ancestrais
através do uso de polimorfismo. Na Figura 100, desde que não ocorressem elementos comuns
ao cálculo de custo nas classes base, o método “getFatorCusto” poderia ser definido de forma
abstrata em “MeioTransporte”, sendo implementado apenas nas classes concretas “Carro”,
“Avião”, “Navio” e “Submarino”.
Ainda pensando em termos de elementos abstratos, outra ferramenta computacional da
orientação a objetos é a interface, que trata de um conjunto de métodos abstratos, ou
201
assinaturas de métodos, que podem ser implementados pelas classes que se proponham a tal,
permitindo às mesmas participar dos processos onde esta interface é utilizada. Apesar de se
parecer com uma classe abstrata à primeira vista, uma interface não pode conter métodos
concretos ou propriedades.
Rumabaugh et al. (2000 p.155) define interface como uma coleção de operações
empregadas para especificar o serviço de uma classe ou componente. Declarando-se a
interface é estabelecido o comportamento desejado de uma abstração independente de
qualquer implementação dessa interface.
A independência promovida pelo uso de interfaces permite garantir um grande
desacoplamento já que pode ser utilizada qualquer implementação, independente de
fornecedor ou tecnologia, desde que esta implementação satisfaça às responsabilidades e ao
contrato denotado pela interface.
Uma característica interessante do uso de interfaces é a possibilidade de
implementação da mesma em diferentes famílias de classes, não mais dependendo de uma
hierarquia determinada por uma semântica específica. Novamente a modelagem inicial
especificada na Figura 100 poderia ser modificada para a que é apresentada na Figura 101,
onde são incorporadas outras famílias de classes, além da interface comum.
Figura 101: Exemplo de utilização de interfaces na modelagem
A implementação da interface ilustrada demonstra o fato de que as classes existentes

não descendem de “IElementoCusto”, mas sim aceitam a delegação de responsabilidade
promovida por esta interface, a partir do momento em que implementam o método
“getFatorCusto”. Esta interface é utilizada no Modelo de Pilla e Cople para detectar
elementos que possam gerar custos.
202
A.2.3 Avaliação do reuso na orientação a objetos
Karunanithi e Bieman (1993 p.4) citam em seu trabalho o fato de que, como as
linguagens orientadas a objeto são projetadas para suportar o reuso, programadores devem
utilizar boas práticas da Engenharia de Software para obter o máximo de reuso. Com o
objetivo de caminhar em direção ao reuso máximo, podem ser estabelecidas métricas que
auxiliem a caracterização do reaproveitamento dos componentes de um sistema, assim como o
monitoramento dos níveis de reuso de código atual, de forma a auxiliar na criação e utilização
de artefatos e normas que facilitem esta prática.
Os tipos mais imediatos de reuso na orientação a objetos são a criação de instâncias de
classes já existentes em novas classes e a especialização através da herança. Segundo Bieman
e Kang (1995 p. 261), as métricas de reuso referentes ao uso de instâncias estão relacionadas
ao número de instâncias criadas, enquanto a herança refere-se ao número de descendentes
diretos e indiretos da classe.
Bailey e Basili (1981) defendem a idéia de que a complexidade do desenvolvimento
está associada ao tamanho do código, e descrevem o reuso em termos da quantidade de
código reutilizada e a quantidade a ser criada ou reescrita em um determinado sistema
computacional. Outros autores aprovam esta afirmativa, tais como Fenton e Neil (2000),
Kemerer (1987) e Boehm (1981).
Estes autores acabam não levando em consideração os elementos relacionados à
qualidade do código gerado, em contraposição ao tamanho do mesmo. Abstrações com boa
qualidade sugerem facilidade de reuso e integração.
Segundo Booch (1994 p. 136) as seguintes métricas podem ser utilizadas para avaliar a
qualidade da abstração:
• Acoplamento, definido como a medida da força da associação estabelecida nas

conexões entre as classes. Acoplamento forte aumenta a complexidade do sistema,
a partir do momento em que o uso e possíveis correções de uma dada classe
implicam na observação da influência das demais classes ou sobre as mesmas. O
próprio uso de herança, ao mesmo tempo em que determina um rápido reuso,
produz um forte acoplamento entre classes pai e filha.
203
• Coesão mede o nível de conectividade entre os elementos de uma dada classe ou

objeto. A mais desejável forma de coesão é a coesão funcional, onde os elementos
da classe trabalham todos juntos para fornecer algum comportamento bem
delimitado.
• Suficiência, significando que a classe captura o mínimo conjunto de características
necessárias para permitir uma interação significativa e eficiente.
• Exaustividade mede o quanto esta interface pode satisfazer aos mais diversos
clientes, ao contrário da suficiência, onde é desejada a mínima interface. Esta é
uma medida bastante subjetiva, e sujeita aos diversos aspectos do sistema.
• Primitividade, que considera o fato de que muitas operações de alto nível podem
ser compostas de elementos primitivos, sugerindo que classes fundamentais podem
também ser classificadas como primitivas.
Abstrações com maior qualidade devem apresentar alta coesão e baixo acoplamento,
satisfazer ao problema de forma exaustiva e suficiente, além de apresentar a possibilidade de
utilização de elementos primitivos, menos complexos, na implementação das operações de
alto nível.
Considerando-se a maior complexidade de desenvolvimento de classes, em
comparação com a programação tradicional, devido ao maior nível de abstração, pode-se
dizer inicialmente que a concepção desta biblioteca de classes só trará benefícios quando a
quantidade de projetos que envolvam a mesma justifique o esforço de sua criação.
Esta afirmativa não leva em conta o fato de que os ambientes de desenvolvimento
atuais (IDE, do inglês Integrated Development Environment) e ferramentas CASE (computer-
aided software engineering), devido à forma natural de modelagem promovida pela
orientação a objetos, absorvem boa parte do esforço de concepção e modificação de sistemas,
inclusive automatizando a detecção e acerto de impactos referentes a mudanças (técnica
conhecida com refactoring).
Infelizmente as ferramentas computacionais de engenharia nem sempre permitem um
comportamento tão padronizado quanto ao das ferramentas cadastrais de uso comercial, e
como as ferramentas CASE obrigam a existência de código mais robusto para obter a
generalização necessária, qualquer adaptação deste código a uma nova realidade poderá
demandar um grande esforço por parte dos analistas e programadores, de forma a satisfazer
aos modelos utilizados.
204
Segundo Banker, Kauffman e Zweig (1993 p.319), o avanço de ferramentas CASE

que enfatizam o reuso de software demonstra que grande parte do valor real dos módulos de
software será derivado do que estas ferramentas podem fazer:
• Diminuir as despesas de construção e teste, e elevar o nível geral de qualidade

percebida e confiabilidade dos sistemas que são entregues;
• Acelerar a implementação de novos sistemas enquanto oportunidades para a
vantagem competitiva continuam a existir nas áreas de negócio que o software se
destina a apoiar e
• Ser aproveitado em todos os projetos e áreas da empresa em apoio a vários
negócios.
O novo framework e sua interface cadastral de exemplo foram criados tirando proveito
das possibilidades oferecidas por duas ferramentas deste tipo: o NetBeans na construção de
toda a parte lógica e de cálculo, gestor de distribuição em rede e persistência, e o Flash
Builder (Flex) para a construção da interface cadastral.
A.3 PADRÕES DE DESENVOLVIMENTO
Acima do reuso de código, os padrões visam o reuso do conhecimento, conforme

citado por Freeman, Sierra e Bates (2004 p.xi). Ainda segundo o autor, a melhor forma de
utilizar os padrões é estudá-los, entendê-los e mantê-los na memória, de forma a reconhecer a
melhor forma de utilizá-los durante o desenvolvimento de aplicativos.
Segundo Shalloway e Trott (2002 p.86), as razões mais relevantes para o estudo dos
padrões de desenvolvimento são:
• Reutilização de soluções existentes de alta qualidade para problemas comumente

encontrados no desenvolvimento de software;
• Estabelecimento de uma terminologia comum;
• Elevação do nível de raciocínio estratégico para uma perspectiva mais elevada;
• Utilização de soluções de desenvolvimento que não apenas funcionam, mas que
são comprovadamente aplicáveis a cada contexto;
• Melhoria do aprendizado individual ou da equipe como um todo;
• Manutenção de código facilitada;
205
• Adoção de alternativas de desenvolvimento melhoradas, mesmo que os padrões

não sejam utilizados explicitamente; e
• Descoberta de alternativas para o uso de longas hierarquias de classe.
Através do reuso de soluções obtém-se um bom ponto de partida, evitando armadilhas.

O que deve ser considerado é o benefício de aprender com a experiência de outros, afinal
soluções não precisam ser reinventadas para problemas recorrentes.
Como citado por Gamma, Helm, Johnson e Vlissides (1994 p.12), os padrões de
desenvolvimento ajudam na escolha de alternativas de projeto que tornam um sistema
reutilizável, e alternativas para diminuir o nível de acoplamento.
Ao definir soluções que substituem o uso de herança ocorre também a diminuição
natural do acoplamento do código, facilitando a manutenção do sistema como um todo, pois
eventuais correções efetuadas não causam impacto sobre classes derivadas, evitando efeitos
secundários que normalmente são detectados apenas na execução do sistema.
Finalmente, o estabelecimento de uma terminologia comum permite aos grupos de
trabalho a utilização de um vocabulário básico e um ponto de vista comum sobre os
problemas. Padrões de desenvolvimento são capazes de prover um ponto de referência
comum durante as fases de análise e desenvolvimento do sistema.
Os sistemas da atualidade baseiam as soluções implementadas pelos mesmos na
combinação de padrões de desenvolvimento, como por exemplo, a criação de um pool de
respostas a solicitações de usuários, o qual poderia ser caracterizado por um FlyWeight de
Strategies para a escolha de Commands. Conforme citado por Gamma, Helm, Johnson e
Vlissides (1993 p.416), padrões de desenvolvimento são uma estratégia para reuso de
software.
Várias tecnologias trabalham baseadas em padrões de desenvolvimento, facilitando
muito a integração com os mesmos o fato do framework de ACCV utilizar também estes
padrões. Entre as tecnologias de mercado existentes, duas em particular foram utilizadas, com
o objetivo de eliminar parte do trabalho de desenvolvimento e utilizar soluções robustas já
testadas extensivamente pelo mercado: JPA, responsável pela persistência em banco de dados
através de mapeamento objeto-relacional, e JEE5, responsável pela gerência das classes de
negócios baseadas em objetos distribuídos.
206
A.4 ELEMENTOS GENÉRICOS
O objetivo maior do uso de classes genéricas é a definição de macro-processos ou

comportamentos que podem ser aplicados a qualquer tipo de objeto. Isto seria possível com
uso simples de programação orientada a objetos, desde que fossem utilizados parâmetros
derivados da classe base da linguagem (Object para o Java) e posterior conversão de tipo.
Embora Bloch (2008 p.110) aponte esta alternativa para sistemas antigos, o mesmo
indica o uso de classes genéricas para novos sistemas. Segundo o autor, é importante
descobrir os erros o mais cedo possível, de preferência em tempo de compilação, e com o uso
de elementos genéricos possíveis erros de conversão de tipo ocorridos em tempo de execução
são evitados. A Figura 102 demonstra a situação apontada por Bloch, apresentando à esquerda
o código legado, e à direita o uso de uma classe genérica, a qual permite ao compilador
apontar a linha onde ocorre o erro.
Figura 102: Elementos genéricos como facilitadores na detecção de erros em Java
A detecção de erros em tempo de compilação é economicamente mais interessante,

pois o fato de parar um sistema que já foi colocado em produção poderá causar perdas
financeiras perante a reação dos clientes, ociosidade da equipe de operacionalização, atrasos
nos processos produtivos, dados errôneos, além de ter uma manutenção muito dificultada nos
casos em que o sistema ou alguns de seus módulos não podem ser interrompidos.
Uma das maiores vantagens na metodologia de programação genérica é o máximo
reuso de classes e métodos, resultando em grande ganho de produtividade. O objetivo da
programação genérica é generalizar componentes de software, de forma a facilitar o reuso,
reduzindo o tempo de implementação, seu custo, e a necessidade de testes.
207
Um exemplo de estrutura de pilha baseada em classes genéricas, com utilização de

linguagem Java, é apresentado na Figura 103. Esta classe genérica pode ser aplicada a
qualquer outra classe, como no exemplo apresentado na Figura 104, onde são criadas pilhas
de String e Integer. Como as classes genéricas fazem parte da estrutura da linguagem, é
possível, por exemplo, criar recursivamente elementos como pilhas de pilhas.
Figura 103: Exemplo de definição de classe genérica em Java
Figura 104: Exemplo de utilização de classe genérica em Java

208
O framework de ACCV utiliza amplamente a técnica de programação genérica,

sempre visando aumentar o reuso e minimizar o tempo de desenvolvimento. Um exemplo são
as listas, ordenadas ou não, com suporte a concorrência através de semáforos. Estas listas
podem ser facilmente criadas, como pode ser observado na Figura 105, através da extensão da
classe “GenericList” criada para dar suporte à múltiplas listas existentes no processo de
simulação, e cujo código é apresentado parcialmente na Figura 106.
Figura 105: Código Java para a lista de falhas simuladas

209
Figura 106: Parte do código Java para a classe de lista genérica com suporte a concorrência.
210
A.5 ANOTAÇÕES
Anotações tratam de metadados que podem ser associados a uma classe, método ou
propriedade, sem interferir com o código-fonte, porém permitindo o reconhecimento das
mesmas pelos compiladores e frameworks. Isto permite a definição de processos complexos
que podem ser facilmente reutilizados pelas classes anotadas, tais como persistência de dados
automatizada, controle transacional, rotinas de teste de software, sincronização de processos
paralelos, entre muitas outras finalidades já observadas no mercado.
Segundo Gervasi e Galilei (2008 p.161), as anotações são uma funcionalidade recente
introduzida em linguagens como Java e C#, que permitem aos programadores anexar
arbitrariamente ao seu código metadados estruturados e tipificados.
Na linguagem Java as anotações são definidas através da criação de interfaces
específicas. Definida a anotação ela pode ser utilizada por uma classe qualquer, e
posteriormente reconhecida por algum sistema.
Um exemplo de anotação definida no framework de ACCV pode ser observado na
Figura 107, enquanto seu uso em uma classe é demonstrado na Figura 108. Neste exemplo a
utilização da anotação é reconhecida posteriormente pelo framework com o objetivo de
acrescentar no banco de dados as entradas necessárias para a definição de telas cadastrais
dinâmicas.
Figura 107: Exemplo de anotação definida no framework de ACCV

211
Figura 108: Exemplo de utilização de anotações no framework de ACCV
Na verdade, a partir do momento em que metadados são anexados ao código, estes

metadados permitem aos frameworks interagir com os sistemas de forma simples e imediata,
extinguindo a necessidade de atualizar as configurações de distribuição e empacotamento,
fases nas quais normalmente era feito o intercâmbio de dados entre o sistema e o framework.
O JPA (Java Persistence Architecture), voltado para a persistência de dados, é um
exemplo típico de framework que segue esta metodologia, sendo completamente baseado em
anotações na definição das entidades. O framework JPA é discutido em mais detalhes no
Anexo B.
212
ANEXO B - ARQUITETURA DE SOFTWARE
B.1 INTRODUÇÃO
A arquitetura de software de um sistema define sua estrutura de mais alto nível, ou

seja, denota a organização do sistema em termos de componentes interativos, e tem como um
dos objetivos diminuir a distância entre o projeto e a implementação deste sistema.
Para Bosch e Bengtsson (2001 p.168) a arquitetura de software define as decisões de
projeto mais fundamentais, e a conseqüente decomposição do sistema em seus principais
componentes e as relações entre esses componentes. Os autores ainda defendem o fato de que
os atributos de qualidade de um sistema são, em grande parte, condicionados pela sua
arquitetura.
Bass, Clements e Kasman (2003 p.24) definem três elementos básicos na identificação
e construção de arquiteturas de software:
1. Padrão Arquitetural (ou Estilo Arquitetural), compreendendo uma descrição de

elementos e tipos de relação entre eles com um conjunto de restrições sobre a
forma como eles podem ser usados;
2. Modelo de Referência, que é uma divisão da funcionalidade, juntamente com o
fluxo de dados entre os componentes; e
3. Arquitetura de Referência, a qual é definida como um modelo de referência
mapeado para componentes de software (os quais implementam a funcionalidade
definida no modelo de referência de forma cooperativa) e os fluxos de dados entre
eles.
213
Um exemplo de arquitetura é o VisiBroker, da fabricante Inprise, a qual utiliza como

arquitetura de referência o CORBA (Common Object Request Broker Arqchitecture),
referência esta baseada no modelo de objetos distribuídos, estilo Broker.
A Figura 109 apresenta a relação entre os três elementos básicos considerados,
enquanto o exemplo do VisiBroker pode ser observado na Figura 110.
Modelo de
Referência
Arquitetura de Arquitetura de
Referência Software
Padrão
Arquitetural
Figura 109: Relacionamento entre Modelo de Referência, Padrão Arquitetural, Arquitetura de

Referência e Arquitetura de Software
Adaptado de Bass, Clements e Kasman (2003 p.26)
Objetos
Distribuídos
Referência: Arquitetura:
CORBA VisiBroker
Estilo:
Broker
Figura 110: Exemplo de Arquitetura com VisiBroker
O modelo de arquitetura de um sistema pode estar de acordo com um modelo ou estilo

genérico, e a compreensão destes elementos simplifica a definição da arquitetura de software.
Entretanto, sistemas grandes são complexos e heterogêneos, levando à adoção de múltiplos
estilos arquiteturais combinados. Os principais estilos e arquiteturas de referência são
discutidos na seção seguinte.
A utilização de arquiteturas de software padronizadas e bem aceitas comercialmente
permite eliminar grande parte do esforço necessário no desenvolvimento a partir do uso de
componentes comerciais, denominados COTS (Commercial Off-The-Shelf). A filosofia
214
COTS, segundo Sousa, Alencar e Castro (1999 p.2), se concentra na produção de

componentes competitivos e fáceis de integrar, muitas vezes usando componentes de outros
fornecedores, sendo que as principais motivações para o incentivo a utilização de COTS tem
sido a proposta de redução de custos de desenvolvimento dos produtos desejados e a proposta
de redução e cumprimento dos prazos de elaboração.
O conceito de COTS não é novo, sendo amplamente utilizado em setores industriais
como eletrônicos, telefonia, e automotivo, entre outros, e acabou por se demonstrar essencial
na concepção dos atuais sistemas computacionais, levando em consideração a complexidade
destes sistemas, fatores ligados a interoperabilidade, e necessidade de padronização entre
diferentes equipes de desenvolvimento.
Segundo Sedigh-Ali, Ghafoor e Paul (2001 p.44), a reutilização de componentes em
larga escala ou a aquisição de componentes COTS pode gerar uma economia em recursos de
desenvolvimento, os quais podem ser aplicados para melhoria da qualidade, incluindo
melhorias para a confiabilidade, disponibilidade, e facilidade de manutenção. O mesmo ponto
de vista é compartilhado por Chung e Cooper (2004), os quais também ressaltam que estes
componentes oferecem soluções empacotadas que provavelmente já passaram pelas várias e
demoradas fases de análise de requisitos especificação, projeto, codificação, testes e foram
amadurecidas ao longo do tempo.
O uso de COTS em software, além de diminuir o tempo de desenvolvimento, facilita a
manutenção e evolução do sistema, através de atualizações dos componentes comerciais, os
quais tendem a se manter alinhados com as novas tecnologias do mercado. Claro que apenas
grandes empresas e comunidades de código aberto são capazes de garantir estas atualizações,
pois não são raros os casos em que uma ferramenta de menor expressão é descontinuada e
torna-se incompatível com novos sistemas operacionais e novas tecnologias.
Entre os COTS utilizados na definição da arquitetura do framework de ACCV vale
destacar os frameworks JPA e JEE5. Estes componentes da arquitetura são descritos em mais
detalhes no decorrer deste anexo.
B.2 PRINCIPAIS ARQUITETURAS
Para entender uma arquitetura é necessário entender sua finalidade, o que pode ser
observado a partir do estilo arquitetural adotado. Vários autores sugerem diferentes
classificações para os estilos arquiteturais, sendo as mais relevantes definidas por Shaw e
Garlan (1996), e Buschmann et al. (1996).
215
Uma arquitetura de software pode ser determinada simplesmente pela forma de

estruturar e programar o sistema, como no caso da programação orientada a objetos, ou a
divisão da codificação em programa principal e sub-rotinas, mas pode também envolver
elementos complexos, como a definição de meios de comunicação (brokers) entre objetos
remotos e seus clientes na concepção de arquiteturas de objetos distribuídos, ou a criação de
interpretadores, como a máquina virtual do Java.
Sistemas antigos, em sua grande maioria criados em modo texto, normalmente eram
definidos em arquiteturas do tipo processamento em lote, encontradas comumente em
mainframes, ou pipes/filters, amplamente utilizadas nos sistemas UNIX, ambas as arquiteturas
caracterizadas por serem modelos de fluxo de dados.
A arquitetura pipes/filters é caracterizada por Garlan e Shaw (1994 p.6), da mesma
forma que François (2003 p.4), como um estilo onde cada componente tem um conjunto de
dados de entrada e um conjunto de dados de saída, obtido pelo processamento dos dados de
entrada, saída esta que constitui uma instância completa de dados a ser utilizada como entrada
para o próximo componente da seqüência. Nesta arquitetura os componentes são chamados de
filters e os conectores são chamados de pipes, como pode ser observado na Figura 111.
Figura 111: Arquitetura Pipes/Filters
Adaptado de Garlan e Shaw (1994 p.7)
Com a evolução das plataformas computacionais, surgimento de grandes redes de

computadores, aparecimento de múltiplos bancos de dados e outros meios de persistência,
torna-se comum o uso de arquiteturas centradas em dados. As arquiteturas em questão são os
repositórios e a Blackboard. Enquanto um repositório apenas efetua a persistência de dados,
atuando de forma passiva, arquiteturas do tipo Blackboard podem efetuar processamentos e se
comunicar com outros componentes através de mensagens, sendo muito utilizadas em
sistemas de controle para automação industrial, como nos elevadores inteligentes.
216
Segundo Hewett e Hewett (1992 p.66), sistemas deste tipo apresentam quatro
componentes principais: blackboards, fontes de conhecimento (knowledge sources), uma
agenda e um escalonador. Ainda segundo os autores, blackboards são áreas de dados que
contêm objetos, as unidades básicas de representação, compreendendo o conhecimento do
domínio, elementos de controle e knowledge sources (KS), sendo usualmente divididos em
camadas.
Corkill (1991 p.5) defende a mesma divisão de Hewett e Hewett (1992 p.66), sendo
que a agenda e o escalonador são definidos simplesmente como unidade de controle. Segundo
Corkill, Gallagher e Johnson (1987 p.5), uma abordagem simplista para a construção de um
aplicativo Blackboard é a representação de cada nível do blackboard como uma lista
desestruturada de objetos que residem neste nível. Nesta arquitetura cada KS pode adicionar
objetos no blackboard, ou recuperar os objetos de interesse a partir do mesmo, como pode ser
Fluxo de Dados
Fluxo de Controle
Figura 112: Arquitetura Blackboard
Adaptado de Pang (1991 p.337)
As arquiteturas de componentes independentes são utilizadas em ambientes com

processamento paralelo e distribuído como, por exemplo, RPC (Remote Procedure Call), Web
Services e objetos distribuídos, assim como em sistemas baseados em eventos, tanto locais,
como nos eventos de janelas, quanto remotos, suportando comunicação síncrona ou
assíncrona, viabilizados por filas de mensagens.
217
Para Garlan e Shaw (1994 p.9), no que diz respeito às arquiteturas baseadas em
eventos (Event-Driven), a idéia por trás da invocação implícita, fundamento destas
arquiteturas, é que em vez de chamar um processo diretamente, um componente pode
anunciar um ou mais eventos. Outros componentes do sistema podem registrar interesse em
um evento e associar um procedimento com o evento. Quando o evento é anunciado o sistema
executa todos os procedimentos registrados para o evento. Assim, um anúncio de evento
“implicitamente” causa a invocação de procedimentos em outros módulos.
Um exemplo típico de arquitetura do tipo Event-Driven é a concepção de sistemas que
se utilizam de MOM (Message Oriented Middleware), onde as mensagens são enviadas do
cliente para o servidor através de filas de mensagens, levando a um processamento específico
no componente ouvinte quando ocorre um evento indicando a chegada de uma nova
mensagem. Como as mensagens independem de linguagem, os componentes tornam-se tão
independentes que podem ser criados em linguagens distintas.
Na linguagem Java, o JMS (Java Message Service) é a API responsável peso acesso
ao MOM, sendo compatível com os principais mecanismos de enfileiramento do mercado,
tais como MQ Series, JBoss MQ e MSMQ. Segundo Yu e Li-li (2007 p.48), Burke e Monson-
Haefel (2007 p.187), Eugster, Felber, Guerraoui e Kermarrec (2003 p.115), Farooq, Parsons e
Majumdar (2004 p.278), neste ambiente há dois tipos de sistemas de mensagens: o ponto-a-
ponto (point to point), que funciona de forma síncrona, sendo apoiado por filas de mensagens
entre cliente e servidor, e arquitetura de publicação e assinatura (publish/subscribe), o qual
trabalha de forma assíncrona, onde os publicadores enviam mensagens para a fila, neste caso
denominada tópico, e os assinantes que observam esta fila recebem a mensagem. Estes dois
tipos de sistemas de mensagens podem ser observados na Figura 113.
Assinante
Editor Tópico
Assinante
Publish/Subscribe
Rementente Fila Destinatário
Point to Point
Figura 113: Domínios do Java Message Service
Adaptado de Burke e Monson-Haefel (2007 p.187)

218
A linguagem Java popularizou muito as arquiteturas de máquina virtual, onde o código

compilado não é voltado para um sistema operacional específico, mas sim para um
interpretador denominado máquina virtual, o que faz com que os sistemas se tornem
independentes de ambiente.
Segundo Qin, Xing e Zheng (2008 p.76), uma máquina virtual inclui o pseudocódigo
que deve ser interpretado e o núcleo de interpretação. O pseudocódigo apresenta-se como
código fonte que precisa ser interpretado e código binário gerado pela análise do
interpretador. O interpretador, por sua vez, é composto por quatro componentes: núcleo de
interpretação, estrutura de dados para armazenamento do pseudocódigo, estrutura de dados
para armazenamento do estado atual do núcleo e finalmente, estrutura de dados para gravação
do progresso na execução do código interpretado. A Figura 114 mostra estes componentes.
Área de Armazenamento
Entrada Código Fonte a Código Binário

ser interpretado Interpretado
Tarefas de Interpretação
Estado
Saída Núcleo de
Interno do
Interpretação
Núcleo
Tarefas de Acesso a Dados
Figura 114: Estilo Arquitetural de Interpretador
Adaptado de Qin, Xing e Zheng (2008 p.77)
Nos sistemas de alta complexidade atuais, com múltiplos servidores abrangendo

diferentes necessidades do domínio, especialização das áreas de desenvolvimento, além de
ferramentas com finalidades específicas que precisam ser integradas, o estilo de camadas
torna-se interessante, sendo definido por Garlan e Shaw (1994 p.11) como um sistema
219
organizado em camadas hierarquicamente, cada camada prestando serviço para a camada

acima dela e servindo como um cliente para a camada abaixo.
Estas classificações foram bastante refinadas por Shaw e Garlan, até o lançamento do
livro “Software Architecture - Perspectives on an Emerging Discipline” em 1996. Uma visão
geral da classificação proposta por Shaw e Garlan (1996) pode ser observada na Tabela 14.
Tabela 14: Classificação das Arquiteturas segundo Shaw e Garlan (1996)
Modelo Estilo Arquitetural Modelo Estilo Arquitetural

Componentes Processos Fluxo de Dados Lote
Independentes Comunicantes
Event-Driven Pipes/Filters
Chamada e Retorno Camadas Centrada em Dados Repositório
Orientado a Objetos Blackboard
Programa Principal e Máquina Virtual Interpretador
Sub-rotina Baseado em Regras
Buschmann et al. (1996) definem outra organização dos modelos arquitetônicos no

livro “Pattern-Oriented Software Architecture - A System of Patterns”, onde algumas das
arquiteturas citadas por Shaw e Garlan (1996) são reagrupadas, além de serem definidas
novas arquiteturas como MVC e PAC, como pode ser observado na Tabela 15.
Tabela 15: Classificação das Arquiteturas segundo Buschmann et al. (1996)
Modelo Estilo Arquitetural Modelo Estilo Arquitetural

Sistemas Broker Sistemas Interativos MVC
Distribuídos PAC
Mud to Structure Camadas Sistemas Adaptáveis Microkernel
Pipes/Filters Reflexiva
Blackboard
220
A arquitetura MVC (Model-View-Control) é de particular interesse para este trabalho,

pois é nesta arquitetura que se baseia o framework de ACCV. Esta arquitetura divide os
componentes do sistema em três camadas: persistência (Model), visualização de dados (View)
e regras de negócio (Control).
Esta divisão é defendida por Buschmann et al. (1996 p. 125), quando citam que o
padrão arquitetural MVC divide uma aplicação interativa em três componentes. O modelo
contém a funcionalidade básica e os dados, visualizações exibem informações para o usuário,
e controladores lidam com os dados fornecidos pelo usuário. Visualizações e controladores
em conjunto compõem a interface de usuário.
As camadas desta arquitetura podem ser observadas na Tabela 16, juntamente com a
simbologia própria e a caracterização de cada uma.
Tabela 16: Componentes da Arquitetura MVC
Símbolo Componente Características
- Encapsula o estado do sistema

Modelo - Responde às consultas da visualização
- Expõe as funcionalidades do sistema
- Define o comportamento do sistema

Controle - Mapeia as ações do usuário para alterações no modelo
- Seleciona a visualização correta para resposta
- Exibe as informações do modelo

Visualização - Consulta o estado do sistema ao modelo
- Envia solicitações do usuário ao controle
No mercado atual a arquitetura MVC tem sido utilizada em larga escala, o que
permitiu aos desenvolvedores de ferramentas a criação de COTS voltadas para cada uma das
três camadas consideradas. Além disto, o uso de camadas especializadas permite a divisão da
equipe de desenvolvimento entre profissionais cujo perfil seja voltado para criação visual,
lógica de negócios ou banco de dados.
Em um ambiente Java para Internet, construído de forma simplificada, a camada de
visualização pode ser definida através de páginas JSP (Java Server Pages), e as camadas de
221
controle e de persistência através de classes Java. Esta arquitetura necessita de um servidor

como o Tomcat, podendo ser observada na Figura 115.
Figura 115: Ambiente Java simples para Internet
O framework de ACCV trabalha com arquitetura MVC para Internet na parte

cadastral, porém o arranjo é mais complexo, envolvendo JPA (Java Persistence Architecture)
na camada de modelo, JEE5 (Java Enterprise Edition) na camada de controle, e Web Services,
acessado por telas criadas com tecnologia Flex, na camada de visualização. Detalhes sobre
JPA, JEE5 e Web Services podem ser obtidos no decorrer deste anexo.
A arquitetura PAC (Presentation-Abstraction-Control) também trabalha com divisão
de responsabilidades, no entanto, esta divisão é aplicada a cada elemento funcional, sendo o
sistema constituído de vários conjuntos do tipo PAC, os quais são organizados
hierarquicamente, ocorrendo mensagens entre os grupos para que mantenham seus estados
atualizados a todo instante. Esta é uma arquitetura muito comum para interfaces visuais
complexas, como portais de informação e softwares voltados para a área gráfica.
Segundo Hussey e Carrington (1997 p.227), na arquitetura PAC, o componente de
apresentação (Presentation) define a aparência visual do sistema e os diferentes meios de
entrada de dados, enquanto uma abstração (Abstraction) define a representação mínima de um
estado, sendo a comunicação entre uma apresentação e uma abstração sempre feita por
222
intermédio de um controle (Control). Ainda segundo os autores, quando o usuário interage

com um componente PAC, a apresentação comunica a ação do usuário à abstração através do
controle, da mesma forma que, quando o estado da abstração muda, esta comunica a alteração
para a apresentação via controle, permitindo a atualização constante da informação visual.
Ao mesmo tempo em que esta arquitetura permite portabilidade, escalabilidade e
reuso, também traz malefícios, como aumento da complexidade na implementação e grande
overhead com a intensa transmissão de mensagens.
A Figura 116 apresenta o esquema funcional de uma arquitetura PAC.
PAC01
A C P
PAC02 PAC03
A C P A C P
PAC04
A = Abstraction, C = Control, P = Presentation
A C P
Composição baseada em mensagens
Figura 116: Arquitetura PAC (Presentation, Abstraction, Control)
Algumas arquiteturas se baseiam no conceito de reflexividade, que pode ser definido

como a capacidade de um objeto reconhecer sua estrutura interna, ou seja, suas propriedades e
a assinaturas de seus métodos, o que permite a criação dinâmica de objetos sem que seu
formato seja pré-definido na codificação.
O conceito de reflexividade também foi de grande interesse para o framework de
ACCV, pois permitiu que objetos tivessem suas características armazenadas ou recuperadas
de forma automatizada dentro do processo de simulação.
Segundo Yamaguti e Price (2002 p.285), em uma arquitetura reflexiva, baseada em
objetos, a estrutura é dividida basicamente em dois níveis: o nível base que é constituído pelos
objetos que implementam os aspectos funcionais do software, e o meta-nível que possui meta-
objetos que implementam aspectos não-funcionais e que podem inspecionar e mesmo alterar
os objetos do nível base.
223
Para Pereira (2003 p.20), este caráter introspectivo da reflexão computacional permite
a uma aplicação utilizar o conhecimento acerca do seu estado interno e do ambiente onde está
sendo executada de modo a modificar seu comportamento quando diante de novas situações.
A reflexividade é uma característica forte do Java, permitindo instanciar objetos
dinamicamente, sem nem ao menos determinar a classe, apenas pelo texto representativo do
nome da mesma, apoiado por elementos reflexivos, capazes de inferir nas estruturas internas
do objeto e descobrir as propriedades e métodos constituintes.
Inicialmente, uma instância do objeto é criada a partir do nome da mesma. Para isto
utiliza-se uma chamada ao método getInstance da classe Class. Este método, em conjunto
com o método forName, permite instanciar um objeto qualquer na memória.
Estando o objeto instanciado, é possível inferir em suas propriedades, com o auxílio de
objetos da classe Field, preenchendo com os valores armazenados da forma adequada no
banco de dados.
Após o objeto instanciado ser preenchido ele pode ser recebido por uma variável do
tipo correto através de uma conversão de tipo. Aqui vale a regra da orientação a objetos de
que qualquer filho pode ser instanciado no lugar de um pai. Logo, apesar do retorno aparentar
ser genérico, ele é do tipo especificado.
A utilização da técnica de reflexividade é ilustrada na Figura 117.
String nomeClasse = "fwk_accv.nativo.ProdSistema";

String nomePropriedade = "PRECOUNIT";
String valor = "100000.00";
ProdSistema obj = (ProdSistema) Class.forName(nomeClasse).newInstance();
Field f = obj.getClass().getField(nomePropriedade);
if(f.getType().getName().equals("double"))
f.setDouble(obj,Double.parseDouble(valor));
Figura 117: Código para geração de instâncias
Finalmente, outro foco de interesse neste trabalho é a utilização de ambientes de

objetos distribuídos, particularmente os EJBs (Enterprise Java Beans), os quais utilizam o
estilo Broker, que segundo Buschmann et al. (1996 p.99) pode ser usado para estruturar
sistemas de software distribuídos, com componentes que interagem por invocações de
serviços remotos. Um componente do tipo Broker é responsável pela coordenação da
comunicação, tais como encaminhamento das requisições, bem como para transmissão de
resultados e de exceções.
224
B.3 FRAMEWORKS
Considerando a necessidade de reusabilidade e expansibilidade neste sistema, foi

adotada a abordagem de framework com a utilização de objetos, pois o conceito principal é o
reconhecimento de elementos que podem se manter flexíveis.
Parte deste texto encontra-se originalmente na dissertação de Cople (2004), sendo aqui
replicado e expandido, no sentido de completar os fundamentos necessários à correta
compreensão do framework de ACCV.
Yang et al. (1998 p.2) citam que, ao definir um framework, algumas perguntas são
cruciais para o planejamento de sua funcionalidade:
• Quais os conceitos no domínio do problema que apresentam variações e podem ser

tratados uniformemente?
• É possível encontrar um conceito concreto que possa ser generalizado?
• Que partes do sistema precisarão mudar?
• Será possível o usuário criar código customizado dentro do framework?
Um framework não tem por objetivo solucionar um problema específico, mas sim
agrupar ferramentas genéricas que podem ser utilizadas na resolução de problemas
semelhantes. Uma utilização típica de frameworks é encontrada na área de segurança de
dados, onde os mesmos fornecem serviços de criptografia, decriptografia, assinatura e
verificação de autenticidade, mas não se resumem a uma transação específica.
Segundo Fiorini (2001 p.26), os frameworks têm atraído a atenção de muitos
pesquisadores e engenheiros de software e são aplicados a uma grande variedade de
domínios. As principais vantagens de frameworks incluem reutilização e redução do tempo
para disponibilizar aplicações no mercado.
Fiorini também ressalta as características de frameworks de aplicação, os quais devem
apresentar uma parte que é comum entre as aplicações que foram utilizadas de base para criá-
lo. Uma importante característica é que eles devem ser flexíveis, ou seja, devem ser
adaptáveis de acordo com os requisitos específicos de um determinado domínio. Os aspectos
de um domínio de aplicação, que têm que se manter flexíveis para proporcionar a
especialização, atendendo às necessidades específicas das aplicações, são conhecidos como
pontos de flexibilização do framework (hot-spots). Escolher adequadamente os hot-spots
225
influi diretamente na qualidade do framework. Portanto, eles devem estar identificados de

forma explícita no framework.
Para Montalto, Pasetti e Salerno (2002 p.2), a combinação de componentes e padrões
de desenvolvimento permite ao framework reutilização não apenas de componentes
individuais, mas de todo um sistema construído com estes componentes, juntamente com
seus relacionamento mútuos. Frameworks de software são, portanto, muito mais do que
meras coleções de componentes reutilizáveis, porque eles oferecem componentes e suas
interconexões.
O tipo mais simples de framework é aquele voltado para aplicativos, tratando-se tão
somente de um conjunto de serviços reunidos em um pacote. Frameworks mais complexos, e
com maiores possibilidades de flexibilização, são aqueles construídos a partir de
componentes voltados para processos ou objetos.
Segundo Stritzinger (1991 p.29), um framework de aplicativos é um conjunto de
construtores de aplicações, parcialmente constituído por blocos de construção
semi-finalizados. Esses blocos implementam o comportamento padrão e fornecem a estrutura
central do aplicativo em potencial. Novas aplicações podem ser construídas através da
modificação e extensão dos mesmos, além da adição de blocos customizados. Ainda segundo
o autor, o objetivo deste tipo de framework é fatorar tanto quanto possível o código comum
fora do aplicativo, transformando em componentes predefinidos e reutilizáveis.
O primeiro passo no desenvolvimento de frameworks é a determinação de elementos
comuns entre várias situações-problema. Fiorini (2001) destaca, ao longo de seu trabalho,
quatro passos para o desenvolvimento de um framework:
• Definir os elementos pertencentes ao domínio. Recomenda-se que, com base em

pelo menos dois modelos de objetos de aplicações similares, se identifique
características comuns entre eles.
• Identificar Hot-Spots. Definidos os elementos estruturais, torna-se necessária a
identificação e documentação dos pontos de flexibilização. Algumas perguntas
podem ser realizadas pelos especialistas do domínio para auxiliar na identificação
dos hot-spots: “Que aspectos diferem de uma aplicação para outra? Qual é o grau
de flexibilidade desejado? Deve ser possível mudar o comportamento flexível em
tempo de execução?”.
226
• (Re) Projetar o Framework. Neste ponto o engenheiro de software tem papel

relevante ao implementar o framework conceitual, ou modificar uma
implementação anterior.
• Adaptar o Framework. Nesta fase, o framework é utilizado em diferentes
exemplos, de forma a identificar hot-spots inúteis, ou de utilização muito difícil.
Pode ser observada também a necessidade de identificar novos hot-spots pontos de
flexibilização. Havendo necessidades de mudança, volta-se para a fase de
identificação de hot-spots e repete-se o processo a partir deste ponto.
De acordo com sua política de utilização, frameworks podem ser classificados como
“caixa-preta” ou “caixa-branca”. Frameworks “caixa-branca” focam a extensibilidade de suas
estruturas internas, gerando instâncias especializadas das mesmas, como as definições de
processos derivados ou classes descendentes, enquanto o tipo “caixa-preta” se baseia na
criação de um protocolo de comunicação. Basicamente, todos os frameworks de aplicações
são deste segundo tipo.
Para Stritzinger (1991 p.35), frameworks de componentes são classificados como
“caixa-branca”, sendo mais flexíveis por permitir a modificação e extensão através do reuso,
sem tocar no código-fonte original, permitindo um nível de abstração muito maior que
simplesmente oferecer a gerência de serviços por funções de call-back.
B.3.1 Frameworks voltados para Processos
Fiorini (2001 p.55) defende a idéia de que um framework de processo é modelado

como um processo genérico utilizado para gerar outros processos. Ele é uma generalização de
um determinado conjunto de processos de um determinado domínio. Ele possui uma parte
fixa e uma parte variável. A parte fixa é composta de atividades comuns a maioria dos
processos que podem ser instanciadas pelo framework. A parte variável (hot-spots) é
composta de atividades e elementos do processo que definem características ou caminhos
específicos de uma instância do framework. Os hot-spots são preenchidos pelo engenheiro de
processos, selecionando componentes existentes ou definindo e redefinindo a descrição dos
elementos do processo.
Ainda segundo Fiorini, os atores envolvidos na definição do framework de processos
são o engenheiro de domínio, quem faz a análise do domínio dos processos, e o engenheiro de
227
processos, quem cria o framework. O engenheiro de processos por vezes pode desempenhar
os dois papéis. A instanciação do framework, quando se gera a instância de processo, é
realizada por outros engenheiros de processos.
Processos podem ser classificados em diversos tipos, segundo sua estrutura e
utilização. São definidas três grandes divisões:
1. Processo Padrão;
2. Processo Comum; e
3. Modelo de Processo.
Processo Padrão é aquele que têm função normativa. Refletem regras que precisam de
alguma interpretação, mas que podem ser mapeadas, de forma que seu conteúdo seja expresso
dentro de um modelo de processo. Exemplos típicos de processo padrão seriam aqueles
ligados ao controle de qualidade, como processos relacionados à ISO.
Modelos de Processo referem-se a soluções já exaustivamente testadas em uma gama
de problemas recorrentes que ocorrem em um determinado contexto. Confunde-se com o
próprio conceito de framework ao gerir soluções genéricas para problemas com o mesmo
perfil, mas mantém independência de ambiente, podendo ser utilizado em vários frameworks.
A idéia por trás dos Modelos de Processo é a de que, embora não possa ser utilizado
um mesmo processo para resolver um problema em diferentes ambientes, dentro de um
determinado contexto poderá ser criado um processo que sirva como guia na resolução de
problemas similares em ambientes distintos.
Processos comuns são aqueles utilizados dentro de um contexto menor, tratando-se de
um elemento mais operacional. Segundo Fiorini (2001 p.66) eles podem ser classificados, de
acordo com sua funcionalidade, como:
1. Processos fundamentais do ciclo de vida, tais como aquisição, fornecimento,

desenvolvimento, operação e manutenção;
2. Processos de apoio ao ciclo de vida, o qual provê suporte a outro processo,
tratando de uma tarefa totalmente independente, tal como documentação,
configuração, garantia de qualidade, verificação, validação e auditoria; e
3. Processos organizacionais do ciclo de vida, tais como os de gerência, infra-
estrutura, melhoria e treinamento.
228
Outro conceito abordado por Fiorini (2001 p.56) é o de Guia de Reutilização, cujo
objetivo é o de auxiliar na reutilização e na instanciação do framework. Fiorini define dois
tipos de guias, o guia do framework e os guias de cada atividade macro. O guia do framework,
como um todo, provê uma visão das atividades macro e oferece suporte à instanciação destas
atividades. O guia de cada atividade macro fornece uma visão das respectivas atividades
detalhadas, mas funciona como referência, pois as mesmas são descritas no processo comum.
Esta estrutura é demonstrada na Figura 118, onde existe também a Linguagem de Modelagem
de Processos, que pode ser definida como uma notação formal para a modelagem dos
processos.
Figura 118: Arquitetura para reutilização de processos
Fonte: Fiorini (2001, p.46)
B.3.2 Frameworks Orientados a Objetos
Segundo Gurp e Bosch (2001 p.277), frameworks orientados a objetos estão se

tornando cada vez mais importantes para a comunidade de software, pois permitem às
empresas capturar os pontos comuns entre as aplicações para o domínio em que operam. Não
229
é de surpreender que as promessas de reutilização e criação fácil de aplicativos soem muito

atraentes para as empresas.
O desenvolvimento de um framework orientado a objetos permite utilizar as técnicas
de herança, ou utilização de objetos que preenchem de forma adequada os trechos definidos
como hot-spots no framework. Na verdade, assemelha-se aos frameworks de processos, a não
ser pelo fato de que os processos se transformam em classes e interfaces.
Yang et al. (1998) definem os passos para o desenvolvimento de um framework
orientado a objetos, baseado em quatro fases, citadas a seguir e que serão descritas ao longo
deste texto com base no trabalho do autor.
1. Análise;
2. Modelagem;
3. Implementação; e
4. Teste.
Na fase de análise, inicialmente serão coletados dados acerca de requisitos comuns às

aplicações (ARS, do inglês Application Requirement Specification). Neste ponto, podem ser
aproveitados dados já existentes das aplicações tradicionais, ou utilizar a interferência do
usuário na descrição de suas funções.
A seguir, deverá ser feita a especificação dos requisitos do framework (FRS, do inglês
Framework Requiremente Specification), baseada apenas nos elementos funcionais do ARS.
O terceiro passo seria a modelagem dos casos de uso baseada no FRS, ou, no caso do
mesmo não ter sido fornecido, a modelagem baseada no ARS para cada aplicação, com a
identificação das partes comuns e que irão gerar um terceiro modelo.
Os casos de uso encontrados serão divididos em três camadas:
1. Core Business Layer, responsável pelo fornecimento de funções comuns para um

domínio específico;
2. Common Business Layer, envolvendo objetos de negócios aplicáveis a vários
domínios; e
3. Foundation Layer, que fornece os serviços de sistema.
230
A seguir, os casos de uso são agrupados de forma a identificar os frameworks. Este

agrupamento segue o seguinte critério:
• Casos de uso que apresentam independência funcional não ficam em nenhum

grupo;
• Casos de uso com relacionamento de herança ficam no mesmo grupo; e
• Casos de uso com relacionamento de associação ficam no mesmo grupo.
Cada grupo formará um framework e o passo final compreende a concepção de um

diagrama conceitual de atividades. Analisando as seqüências de eventos encontradas nos
casos de uso, será definida a seqüência de atividades do framework.
Na fase de modelagem, o primeiro passo seria a criação do Diagrama de Classes, com
a identificação das classes candidatas e relacionamentos a partir de cada ARS e FRS
relevantes. A seguir, deverá ser criado o Diagrama de Seqüência para a Aplicação, com o
objetivo de extrair as operações das classes existentes no diagrama inicial.
A identificação de hot-spots segue o mesmo conceito do framework de processos,
buscando os comportamentos comuns entre os elementos identificados. A partir desta análise
serão definidas as classes abstratas, que deverão ser complementadas após a herança de
forma a personalizar a utilização do framework.
Após serem identificados os hot-spots, deve ser feito o Diagrama de Seqüência para o
Framework, utilizando o caso de uso do framework. Devem ser mapeadas todas as
mensagens internas das classes do framework, mensagens das aplicações e de outros
frameworks. Isto irá permitir a identificação dos Padrões de Desenvolvimento que podem ser
utilizados na implementação do framework.
Em seguida, deverá ser escolhida uma abordagem para o framework, como sendo do
tipo “caixa-branca”, onde é utilizada a herança de classes abstratas, do tipo “caixa-preta”,
onde as classes têm uma implementação fixa, ou uma combinação de ambos.
Definido o tipo de framework, deverá ocorrer a criação do Diagrama do Framework,
buscando a identificação de todas as classes, interfaces e fluxos de controle do framework. A
partir da determinação das classes e suas relações, poderá haver a definição do modelo de
classes através de pseudocódigo.
231
Após revisões do modelo e possíveis modificações, o mesmo deverá ser documentado,

seguindo-se a fase de implementação, a qual compreende apenas dois passos:
1. Implementação das classes e interfaces definidas no modelo do framework; e

2. Implementação de sistemas de teste que utilizem o framework, de forma a verificar
sua funcionalidade.
A fase final seria o teste do framework, executado em três passos:
1. Teste das classes do framework;

2. Teste das mensagens entre as classes, verificando se a execução está correta; e
3. Teste de integração do framework.
Esta é uma abordagem extremamente rígida, com a utilização de diversos elementos

da UML, seguindo definições pragmáticas, mas sempre enfocando a qualidade do framework
produzido, com a utilização de um processo de avaliação e reavaliação a partir da fase de
modelagem, e buscando sempre a robustez do produto final.
B.3.3 Java Persistence Architecture
Um dos grandes problemas no desenvolvimento de sistemas é a criação de processos

de armazenamento de dados ágeis e robustos, capazes de lidar com transações, grandes
massas de dados, pools de conexões, segurança no acesso aos dados, e demais elementos
relevantes neste domínio.
O mecanismo tradicional de persistência dos dados em Java é através do middleware
JDBC (Java Database Connectivity), mas esta é uma programação de baixo nível, com a
codificação de SQL (Structured Query Language) em meio ao código Java, apresentando
baixo nível de reutilização e alta complexidade em termos de controles transacionais, sendo
cada vez mais substituído por outras estratégias, como uso de JPA, Hibernate e JDO (Java
Database Objects).
232
O framework JPA (do inglês Java Persistence Architecture) tem como finalidade
única efetuar o mapeamento objeto-relacional, provendo um meio orientado a objetos para
acesso aos dados, sem a necessidade de utilização de SQL, e servindo como base para a
definição da camada de modelo da arquitetura MVC.
As entidades no JPA são objetos simples, normalmente denominados POJOs (Plain
Old Java Objects), acrescidos de anotações que efetuam o mapeamento objeto-relacional,
provendo à classe capacidade de persistência em banco de dados. O uso destas anotações no
JPA foram um grande avanço em relação aos complexos arquivos XML utilizados em versões
antigas do Hibernate, ou nos Entity Beans do J2EE (Java 2 Enterprise Edition), pois
fornecem um meio robusto e prático para codificar o mapeamento.
Como as anotações não são serializáveis, permanecendo no contexto de persistência
envolvido, ao contrário do objeto em si, que pode ser transmitido para as várias camadas do
modelo MVC, pode-se dizer que estas anotações controlam o relacionamento com o banco de
dados em separado da classe, definindo um padrão DAO intrínseco.
O código-fonte para um bean de entidade pode ser observado na Figura 119. Neste
exemplo, a classe é persistida em uma tabela denominada “ALUGUEL”, formada pelos
campos “CODIGO”, “DT_ENTRADA”, “DT_SAIDA” e “PLACA”.
Figura 119: Exemplo de código para bean de entidade

233
Enquanto as anotações efetuam o mapeamento, a configuração do acesso ao banco de

dados, incluindo o pool de conexões, é feita através do arquivo persistence.xml, sendo um
exemplo deste tipo de arquivo apresentado na Figura 120.
Figura 120: Exemplo de arquivo de configuração persistence.xml
Segundo Jendrock et al. (2008 p. 703), uma unidade de persistência define um

conjunto com todas as entidades gerenciadas por cada EntityManager em um aplicativo. Este
conjunto de classes de entidades representa os dados armazenados em um meio de
armazenamento simples.
A classe EntityManager é responsável por gerenciar os processos de persistência do
JPA, permitindo controle transacional e atuando tanto no modelo controlado pelas classes
Java, diretamente no código, quanto a partir dos containers WEB ou JEE, através de
anotações próprias.
Um exemplo de código-fonte para inserção de um registro no banco de dados pode ser
Figura 121: Exemplo de inserção de dados no JPA

234
Segundo Burke e Monson-Haefel (2007 p.42), as entidades são objetos Java simples
que são alocados da mesma maneira que qualquer outro objeto Java, tornando-se persistentes
apenas depois de seu código interagir explicitamente com o EntityManager.
No framework JPA é utilizada uma linguagem própria para recuperação das entidades
anteriormente persistidas em banco de dados denominada Java Persistence Query
Language (JP-QL), a qual é muito semelhante ao SQL, porém trabalha com entidades
singulares e coleções de entidades. Qualquer consulta JP-QL é transformada em SQL
apropriada ao banco de dados, conversão esta efetuada a partir das configurações definidas no
arquivo persistence.xml, e o retorno da consulta ao banco pode ser capturado em objetos de
entidade ou coleções.
Um exemplo de consulta com uso de JP-QL pode ser observado na Figura 122.
Figura 122: Exemplo de consulta JP-QL
O framework JPA permite a reutilização direta das entidades, mesmo com a troca do
servidor de banco de dados, possibilitando inclusive a criação automatizada das tabelas na
implantação do aplicativo.
B.3.4 Java Enterprise Edition 5
O Java Enterprise Edition (JEE) é um framework que trata da arquitetura corporativa

para uso de objetos distribuídos em Java. Enquanto a versão J2EE trabalhava com arquivos
XML e uma grande complexidade em termos do contrato de programação, a versão JEE5
235
trabalha com anotações, da mesma forma que o JPA, embora o mecanismo de criação e
gerência destes objetos não tenha efetivamente mudado entre as duas versões.
Enterprise Java Beans (EJBs) são os componentes criados no JEE, e definem um
modelo de referência para criação e gestão de objetos distribuídos, o qual é implementado por
diferentes servidores, tais como JBoss, GlassFish, BeA Web Logic, WebSpehre, entre muitos
outros, permitindo o reuso de componentes diretamente, mesmo que seja trocado o servidor.
Segundo Jordan (2004 p.11), em troca do uso de componentes EJB, os desenvolvedores
recebem suporte transparente para distribuição de objetos, persistência, transações e
segurança de acesso.
Os componentes EJB podem ser classificados, como citado por Mukhar, Zelenak,
Weaver e Crume (2006 p.407), Farley e Crawford (2005 p.133), Jordan (2004 p.11), em três
tipos: Session Bean, Entity Bean e Message-Driven Bean (MDB).
Segundo Farley e Crawford (2005 p.133), Session Beans são acessados por um cliente
em um determinado instante, não apresentando persistência, e sendo removidos do servidor
após o período de utilização (sessão). Servem para modelar regras de negócio e fluxos de
informação (workflows), como citado por Mukhar, Zelenak, Weaver e Crume (2006 p.408),
Roman, Sriganesh e Brose (2005 p. 79), Jordan (2004 p.11), podendo ser classificados em:
• Stateless, onde não existe informação de estado, o que impede a criação de

propriedades de instância, e gerindo apenas os parâmetros locais dos processos
encapsulados pelos mesmos; e
• Statefull, com a capacidade de preservar valores entre chamadas sucessivas do
cliente, através da criação de propriedades de instância, o que possibilita a divisão
de processos complexos em processos menores encadeados, ou a criação de
acumuladores.
Por outro lado, enquanto Session Beans modelam os processos de negócio, EJBs do
tipo Entity Bean representam as entidades do aplicativo, ficando responsáveis pela camada de
persistência no modelo J2EE. Neste modelo, cada instância de Entity Bean representa uma
linha da tabela onde os dados daquele Entity Bean são persistidos.
Para Roman, Sriganesh e Brose (2005 p. 123), a grande diferença entre estes dois tipos
de EJBs é que Entity Beans têm uma identidade e um estado visível pelo cliente, além do que
seu ciclo de vida é completamente diferente dos Session Beans, garantindo a sua existência
enquanto os dados existirem no banco de dados, ao invés de simplesmente uma sessão do
236
cliente. Como estes EJBs possuem uma identidade, a qual é representada como uma chave
primária na tabela, eles podem ser distinguidos a partir da comparação destas identidades.
Segundo Mukhar, Zelenak, Weaver e Crume (2006 p.409), em um cenário EJB típico,
quando um Session Bean precisa de acesso aos dados do banco, ele o faz através de chamadas
aos métodos dos Entity Beans.
O modelo proposto pelo J2EE pode ser visualizado na Figura 123, compreendendo as
camadas Model e Control da arquitetura MVC.
Figura 123: Session Beans e Entity Beans em um aplicativo
Adaptado de Mukhar, Zelenak, Weaver e Crume (2006 p.409)
A arquitetura do JEE baseia-se em chamadas remotas pelo protocolo RMI-IIOP,

compatível com CORBA, e seguindo a arquitetura Proxy em termos de acesso, com sistema
de localização via JNDI, dentro de robustos padrões de desenvolvimento.
Um ponto considerado ineficiente no modelo J2EE sempre foi a sua camada de
persistência, com uso de Entity Beans. Para efetuar a persistência de dados, o JEE5 passa a
utilizar o JPA, visto em detalhes na seção anterior, permitindo trabalhar no modelo anotado,
onde o container JEE fica responsável por instanciar o EntityManager no momento correto.
237
Um exemplo de código com a finalidade descrita, implementando o padrão de

desenvolvimento Session Facade pode ser observado na Figura 124.
Figura 124: Session Facade no JEE5
Finalmente, os componentes do tipo MDB são responsáveis pelo tratamento de

mensagens recebidas na arquitetura Event-Driven. Mais que simplesmente uma arquitetura
orientada a eventos, estes componentes interagem via JMS (Java Message Service) com os
diversos fornecedores de filas de mensagens do mercado, ficando responsáveis pela
integração entre o JEE e o MOM (Message Oriented Middleware).
Segundo Farley e Crawford (2005 p. 312), JMS é uma API destinada ao tratamento de
mensagens assíncronas, sendo principalmente focada no cliente, API esta que provê um meio
padrão e portável de interface para clientes Java/JEE interagirem com sistemas nativos MOM,
tais como IBM WebSphere MQ, Sonic MQ, e outros.
Com a utilização de JMS é possível construir aplicativos tanto no domínio PTP quanto
no domínio Publish-Subscribe, de acordo com a forma de envio e recepção das mensagens,
como pode ser observado na Figura 125.
238
Figura 125: Modelos de Mensagens com JMS
Adaptado de Farley e Crawford (2005 p.314)
O componente MDB não possui fábricas e interfaces de acesso, como os demais tipos
de EJBs, deixando de utilizar o protocolo RMI-IIOP e passando a estar sempre relacionado a
um MOM, de onde partem os dados a serem recebidos por este MDB e tratados em seu único
evento, denominado onMessage. Este tipo de EJB também não é capaz de guardar
informações de estado, atuando sempre no modo Stateless.
Segundo Roman, Sriganesh e Brose (2005 p. 218), são vários os fatores que motivam
a mudança de RMI-IIOP para um padrão assíncrono, baseado em mensagens, destacando-se:
• Eficiência, já que o RMI-IIOP bloqueia o cliente até o final do processamento, ao

contrário do MOM;
• Confiabilidade, já que as filas de mensagens são resistentes a quedas do servidor;
• Suporte a múltiplos emissores e receptores, ao contrário do RMI-IIOP, onde a
comunicação é sempre entre um cliente e um servidor; e
• Integração com outros sistemas corporativos, mesmo que utilizadores de
linguagens diferentes do Java, desde que também suportem MOM.
239
Um ponto de especial interesse nos MDBs passa a ser também a interoperabilidade,

foco de estudo da seção seguinte, obtida com o uso de filas de mensagens, as quais podem ser
utilizadas pelas mais diversas linguagens, criando clientes e servidores totalmente
desacoplados.
B.4 INTEROPERABILIDADE
Com a grande quantidade de softwares existentes, e as diversas formas de combiná-los

na busca de soluções empresariais, torna-se importante para qualquer novo sistema a
preocupação com fatores como a interoperabilidade.
O conceito de interoperabilidade define simplesmente que componentes e sistemas de
diferentes origens devem ser capazes de se comunicar e executar cooperativamente tarefas
mais complexas, indo além da finalidade de cada elemento individualmente. Este é um
procedimento comum na engenharia, onde sistemas complexos como aviões e navios são
projetados em termos de subsistemas que se comunicam tais como radares, armas, GPS,
propulsão, entre muitos outros.
Para Jain (1999 p. 1481), sistemas de simulação no futuro poderão, muitas vezes, ser
utilizados como parte de grandes sistemas de apoio à decisão. Na simulação presente
softwares já estão sendo incorporados na fabricação, planejamento e programação de
sistemas. O software de simulação do futuro vai ser muito aberto para permitir que tais
integrações ocorram.
A interoperabilidade em termos computacionais pode envolver tanto elementos locais,
tal como a troca de informações entre uma planilha e um editor de textos, quanto
componentes que se comunicam remotamente, como objetos distribuídos e serviços com
execução remota.
Surge neste contexto um elemento de software responsável pela intermediação entre
dois componentes de software ou tecnologias distintas, e até mesmo em alguns casos
intermediando entre software e hardware, denominado middleware, geralmente constituído
por módulos dotados com APIs de alto nível, voltadas para a integração com diversas
linguagens de programação, e interfaces de baixo nível com os dispositivos e tecnologias
alvo, objetivando mascarar a heterogeneidade e fornecer um modelo de programação mais
produtivo para os desenvolvedores de aplicativos.
240
Elementos de middleware são típicos exemplos de ferramental voltado para

interoperabilidade, apresentando-se nas formas mais diversas, indo desde simples bibliotecas
para acesso a dispositivos físicos e sistemas de armazenamento, até arquiteturas complexas
voltadas para a intercomunicação entre processos. Podem ser citados, entre os vários
exemplos existentes no mercado, os seguintes:
• JDBC, ODBC, ADO - utilizados na comunicação entre um sistema cadastral e um

servidor de banco de dados;
• RPC, MOM - para comunicação síncrona e assíncrona entre sistemas remotos;
• CORBA, RMI, DCOM - voltados para o acesso a objetos distribuídos; e
• JNDI - que permite a comunicação com serviços de nomes e diretórios, como o
LDAP e o DNS
Um exemplo típico de middleware voltado para a disponibilização de objetos

distribuídos é a arquitetura CORBA (Common Object Request Broker Architecture), a qual
define um padrão de criação de objetos distribuídos que podem ser acessados através de um
protocolo comum denominado ORB (Object Request Broker), trabalhando de forma
independente de linguagem ou plataforma.
Nardi (2003 p. 16) ressalta que no CORBA as interfaces são definidas através de uma
linguagem específica para esse fim, a IDL (Interface Definition Language). Diferentemente
das linguagens de programação, a IDL não possui construções como comandos condicionais
ou de repetição. Assim, os objetos CORBA não podem ser implementados em IDL, mas
apenas definidos de modo independente de qualquer linguagem de programação. Essa
característica é ponto chave para a utilização de CORBA em sistemas heterogêneos e
integração de aplicações desenvolvidas separadamente.
Ierusalimschy, Cerqueira e Rodriguez (1998 p. 42), também defendem a importância
da IDL para interoperabilidade, ao citarem que um dos pontos principais de sua utilização é
que a mesmo interface pode ser compilada para diferentes linguagens. Por isso, objetos
escritos em linguagens diferentes podem coexistir no mesmo sistema, interagir e trocar
informações entre eles. Para permitir essa interoperabilidade, cada linguagem alvo deve
definir um mapeamento entre as interfaces IDL e seus próprios tipos.
241
Este é o fator que levou à utilização do protocolo misto RMI-IIOP na concepção do

JEE, discutido na seção anterior, pois permite a qualquer ferramenta com suporte a CORBA,
como as linguagens Delphi e C++, se comunicar com os componentes EJB, integrando-os
como componentes remotos em suas soluções.
Segundo Vinoski (1997 p. 46), uma característica importante das grandes redes de
computadores, como a Internet e as intranets corporativas, é a heterogeneidade, a qual é
resultado de vários fatores:
• Tradeoffs de engenharia, pois raramente existe apenas uma solução simples para
um problema complexo, o que faz com que diferentes pessoas na corporação
acabem por escolher diferentes soluções;
• Custo efetivo, já que fornecedores apresentam habilidades variadas para prover o
“melhor” sistema pelo menor preço; e
• Sistemas legados, os quais podem se encontrar em pleno funcionamento, sendo
muito difíceis de substituir por novas tecnologias. Neste caso, a decisão pela
mudança ocorre apenas quando o custo de manutenção torna-se muito maior que o
custo para desenvolvimento de uma nova solução.
Em outro trabalho de Vinoski (2002 p. 83), o autor cita que entre as muitas razões para
se utilizar um middleware, todas convergem para uma, que é justamente esta heterogeneidade.
Ainda segundo o autor, sistemas crescem ao longo do tempo, o que significa que hardware e
aplicativos comprados anos atrás devem trabalhar em conjunto com aqueles que foram
adquiridos ontem. Adicionam-se a isto fatores, tais como fusões, reorganizações, mudanças de
liderança, e e-business para a imagem, aumentando a heterogeneidade do sistema global de
forma acentuada.
Com a expansão da Internet e popularização do XML, a interoperabilidade entre as
diversas plataformas de desenvolvimento invariavelmente passou a ser baseada na utilização
de Web Services, os quais constituem serviços disponibilizados na rede e que se utilizam de
entrada e saída de dados em um formato padrão, no caso o XML, o qual pode ser gerado ou
interpretado por qualquer linguagem. Este tipo de estratégia para interoperabilidade é
discutida em detalhes na seção seguinte.
242
B.4.1 Web Services e Arquitetura SOA
Como toda arquitetura de componentes que visa apresentar interoperabilidade e

capacidade de computação distribuída, Web Services também apresentam um padrão de
definição de interfaces e um serviço de registro e localização.
Segundo Erl (2009 p.30), a plataforma original de tecnologia de Web Services é
composta das principais especificações e tecnologias abertas a seguir: Web Services
Description Language (WSDL), XML Schema Definition Language (XSD), Simple Object
Access Protocol (SOAP) e Universal Description, Discovery and Integration (UDDI).
O que pode ser observado nestes padrões é que o XML é utilizado em todos os níveis
da arquitetura. No entanto, o XML sem um vocabulário é meramente uma sintaxe aberta, sem
as formalizações necessárias à definição de um protocolo de comunicação e troca de dados.
Logo, para aplicativos reais, um vocabulário deve ser definido, e as duas tecnologias
disponíveis para tal são o Document Type Definition (DTD) e XML Schema Definition
Language (XSD).
Segundo Arciniegas (2002 p.7), as DTDs são a forma básica e mais amplamente
utilizada das especificações de tipo para documentos XML. Ainda segundo o autor, estas
DTDs são formadas pela declaração de: tipo de elemento, lista de atributos, notação e
declarações de entidades.
As desvantagens no uso de DTDs residem no fato de que não permite a definição de
tipos complexos e não viabiliza a utilização de vocabulários múltiplos simultaneamente. Estas
necessidades são supridas pelo formato XSD, mas ocorre um considerável aumento de
complexidade na escrita, apesar da vantagem de utilizar a sintaxe XML, ao contrário do
formato DTD.
Conforme citado por Arciniegas (2002 p.27), o XML Schema Definition é uma
linguagem para a definição de estruturas complexas e tipos de dados para documentos XML,
permitindo definir, derivar, expandir e compor construções muito precisas, o que acaba por
fornecer uma semântica de alto nível no documento e validação automática mais abrangente a
partir do nível do analisador sintático.
243
A Figura 126 apresenta fragmentos de código referentes a ambos os formatos.
DTD XSD
Figura 126: Fragmentos de código equivalentes nos formatos DTD e XSD
Qualquer serviço criado deve ser registrado via UDDI, passando a fornecer a interface
de utilização deste serviço, envolvendo o formato das mensagens de chamada e de retorno,
através de um arquivo WSDL. Qualquer mensagem transitada entre o servidor e o usuário do
serviço deve ser envelopada segundo o formato do SOAP.
Dentro deste ambiente, os arquivos XSD têm o papel de definir estruturas complexas a
serem enviadas ou recebidas pelos serviços, sendo estes tipos utilizados na mensagem SOAP
para determinar o domínio de determinados atributos.
O processo completo para a definição e uso de Web Services envolve estes passos:
1. Criação do serviço e registro no servidor via UDDI;

2. Localização do serviço pelo cliente através do catálogo UDDI;
3. Recuperação pelo cliente do formato de chamada e retorno através do WSDL e
possíveis arquivos XSD fornecidos;
4. Preparação pelo cliente do envelope SOAP de chamada e retorno, a partir das
informações obtidas no passo anterior;
5. Envio da mensagem SOAP de chamada pelo cliente;
6. Execução do Web Service no servidor; e
7. Recepção pelo cliente da mensagem SOAP de retorno.
244
A Tabela 17 apresenta um paralelo entre os elementos funcionais de Web Services e

aqueles encontrados em outras tecnologias.
Tabela 17: Paralelo entre Web Services e outras tecnologias
CORBA RMI JEE Web Services

Registro e
COS Naming JNDI JNDI UDDI
Localização
Descritor de
IDL Java Java WSDL
Interface
Protocolo IIOP RMI RMI-IIOP SOAP
O framework JEE5 permite a criação de Web Services com o uso de anotações.

Durante a implantação do serviço programado em Java, as anotações são reconhecidas pelo
framework e o descritor de interface WSDL é gerado automaticamente.
Um exemplo de Web Service criado com o uso de anotações da tecnologia JEE5 pode
ser observado na Figura 127.
Figura 127: Exemplo de código Java anotado para criação de Web Services
De acordo com Chen (2007 p.3), SOC (Service Oriented Computing), incluindo SOA
(Service-Oriented Architecture), Web Services, e seus modelos de dados e processamento,
representam um novo paradigma computacional que muda a forma para o desenvolvimento de
sistemas e uso de software.
245
Nos ambientes computacionais voltados para a integração de serviços, não importa a

linguagem de programação que implementa cada componente, pois a interface comum
permite que cada serviço funcione como uma caixa-preta, expondo apenas os formatos de
entrada e saída de dados através desta interface para qualquer tecnologia compatível com a
mesma. A partir disto, os softwares são implementados como clientes de seqüências de
acessos a diferentes serviços, segundo um workflow determinado pelas necessidades e lógica
do sistema.
Segundo Erl (2009 p.25), os serviços são sistemas fisicamente independentes, com
características de design distintas que dão suporte à obtenção dos objetivos estratégicos
associados à computação orientada a serviços, sendo que cada serviço recebe seu próprio
contexto funcional distinto e possui um conjunto de capacidades relacionadas a esse contexto,
sendo as capacidades adequadas a invocações externas comumente expressas via contrato
público.
Para Chen (2007 p.3), o relacionamento entre os componentes constituintes no SOA é
baseado em troca de serviços, os quais retornam os dados solicitados, ao invés da importação
do código que processa os dados. O autor ainda defende a interoperabilidade, ao citar que esta
arquitetura fracamente acoplada torna o desenvolvimento independente de plataforma
possível.
Este ambiente satisfaz às necessidades de interoperabilidade dos heterogêneos
sistemas de simulação computacional atuais, levando a um novo paradigma em termos de
simulação denominado SOMSF (Service-Oriented Modelling and Simulation Framework), o
qual segundo Chen (2007 p. 4), ao se basear em SOC podem ser construídos frameworks e
ambientes de desenvolvimento que suportam simulações re-configuráveis dinamicamente,
além de diferentes composições de serviços de simulação.
Esta nova interpretação com relação ao foco de desenvolvimento permite também a
integração de sistemas de simulação antigos com novos componentes, permitindo que ocorra
um grande reuso, e a construção de novos sistemas de simulação esteja completa em um
tempo muito menor.
Segundo Erl (2009 p.49), certas vantagens com relação ao uso de SOA podem ser
enumeradas, como se segue:
• As soluções podem ser construídas eficientemente porque só precisam se

preocupar em atender um conjunto restrito de requisitos associados a um conjunto
limitado de processos de negócio;
246
• O esforço de análise é simples e direto, a partir do momento em que os analistas se

concentram em apenas um processo por vez e, desse modo, só se preocupam com
as entidades e domínios associados a este único processo;
• A criação de soluções segue um ponto de vista tático, satisfazendo ao único
propósito de automatizar um conjunto específico de processos de negócio, e esse
escopo funcional predefinido simplifica não só o desenvolvimento da solução,
como a arquitetura de aplicativos subjacentes;
• O ciclo de vida de desenvolvimento de cada solução é simplificado e relativamente
previsível; e
• Organizações que constroem repetidamente aplicações descartáveis podem se
beneficiar das últimas inovações tecnológicas a cada novo projeto.
Baseando-se em Web Services como interface de comunicação com os clientes, ao

mesmo tempo em que facilita o desenvolvimento de soluções, qualquer servidor SOA
apresenta grande complexidade em termos de sua organização interna, justificada pela
necessidade de integração de novas tecnologias e sistemas legados, dentro de uma análise de
processos, ou serviços, que trabalham de forma conjunta, independente da origem de cada um.
Serviços também podem ser combinados no servidor, segundo uma metodologia
denominada orquestração, onde é definida a seqüência e forma de chamadas de serviços
secundários, acessados por um serviço principal que faz a intermediação com o cliente. Para
organizar estas chamadas é utilizada uma linguagem denominada Business Process Execution
Language (BPEL).
Segundo Erl (2009 p.223), existem alguns pontos principais no que se refere à
composição de serviços no SOA:
• A composição de serviços associa-se estreitamente à capacidade de reuso de

serviços, já que a composição pode ser vista como uma forma de reuso;
• É necessário assegurar que os serviços sejam projetados para participar como
membros eficazes de diversas composições, mesmo que não existam requisitos
imediatos de composição; e
• A aplicação deste princípio pode afetar praticamente todas as partes de uma
arquitetura focada em serviços.
247
O framework de ACCV tem sua interface funcional o que envolve cadastro, adição de
classes, simulação e resultados, totalmente definida a partir de Web Services, o que faz com
que esteja plenamente adaptada às arquiteturas baseada em serviços, porém não foi necessário
utilizar BPEL devido à independência entre as chamadas efetuadas.
De qualquer forma, foi a adoção desta estratégia que permitiu um maior nível de
interoperabilidade e conseqüente uso de uma tecnologia robusta em termos de usabilidade e
construção visual como o Flex para a implementação da interface cadastral.
248
ANEXO C - ELEMENTOS DE SIMULAÇÃO POR EVENTOS
C.1 INTRODUÇÃO
Segundo Law e Kelton (2000 p. 3), um sistema é uma coleção de entidades, como
pessoas ou máquinas, que atuam em conjunto e interagem de forma a completar algum fim
lógico. Os autores também definem estado do sistema como o conjunto de variáveis
necessárias para descrever o sistema em um dado instante, caracterizando o mesmo frente aos
objetivos do estudo. Estas não são definições novas, pois tomam como base as caracterizações
efetuadas por Schmidt e Taylor (1970).
Na prática, a identificação do que é classificado como sistema, bem como das
variáveis que irão descrevê-lo ao longo do tempo, depende destes objetivos, já que um
sistema pode ser composto por outros sistemas, e da mesma forma que pode ser efetuado um
estudo do comportamento de uma turbina isoladamente, pode-se estudar o comportamento de
um avião que utilize esta turbina, classificando-a como um componente apenas, ou até mesmo
a logística de pousos e decolagens de uma frota de aviões.
Existem diversos tipos de modelos, aplicáveis aos mais diversos contextos, tais como
simulações matemáticas baseadas em dados estatísticos, criação de protótipos físicos de
menor porte que os projetos reais, uso de realidade virtual para simulações interativas, entre
muitos outros.
Enquanto modelos físicos envolvem custos com a construção de protótipos e
maquetes, muitas vezes não reutilizáveis após cada análise, os modelos matemáticos não
apresentam estes custos, sendo circunscritos ao custo do desenvolvimento de ferramentas
computacionais reutilizáveis.
Um modelo matemático pode representar o sistema de forma determinística, tratando
de representações estáticas, mesmo que obtidas com recursividade, sendo classificado como
modelo analítico. Estes modelos sempre apresentam um conjunto de variáveis de entrada e
249
um processo matemático que utiliza estas variáveis para obter os dados de saída desejados,
como na programação linear.
Para Wang e Chatwin (2005 p. 1254), modelos analíticos não apresentam as
características necessárias para a representação de sistemas de manufatura complexos, e as
principais deficiências apresentadas são:
• Ao analisar o sistema os elementos estocásticos não podem ser descritos com

precisão por um modelo matemático, e como a manufatura acaba sendo
caracterizada por um grande número de operações discretas que ocorrem de forma
aleatória e não linear, a mesma não pode ser avaliada analiticamente;
• Sistemas dinâmicos, como os de manufatura, envolvem aleatoriedade que muda
com o tempo, e a modelagem de sistemas mais complexos, teoricamente, requer
simplificações demais, podendo vir a invalidar os modelos obtidos; e
• Métodos puramente analíticos são insuficientes para a otimização porque um
modelo matemático só pode ser construído com base em hipóteses simplificadoras,
portanto, a precisão torna-se freqüentemente um grande problema para otimização
do sistema.
Vale lembrar que o maior problema para a solução analítica é que o tempo de
execução na busca da solução pode aumentar exponencialmente frente ao acréscimo de um
grande número de variáveis de entrada, levando à situação em que a necessidade de poder de
processamento está muito acima dos padrões atuais. Nestes casos, métodos de inferência
devem ser utilizados na busca de soluções ótimas, ou próximas das mesmas.
Segundo Wang e Chatwin (2005 p. 1255), um sistema estocástico típico apresenta um
grande número de parâmetros de controle, os quais podem ter um impacto significativo sobre
o desempenho do o sistema. Um modelo que, explicitamente, tenta capturar os componentes
com comportamentos aleatórios mais importantes do sistema, é chamado de modelo aleatório
ou estocástico, onde a solução analítica não é viável.
Esse é o contexto onde a simulação computacional torna-se a melhor opção.
C.2 SIMULAÇÃO COMPUTACIONAL
A importância das simulações, segundo Schmidt (1980 p.315), decorre da necessidade

de melhor compreensão do comportamento de determinado sistema, levando em consideração
250
o fato de que seria inviável economicamente a manipulação do sistema físico, uma vez que
poderia trazer graves conseqüências para o funcionamento do mesmo.
Este fato é defendido por Maria (1997 p. 7), ao citar que uma simulação é utilizada
antes de um sistema existente ser alterado ou um novo sistema ser construído, de forma a
reduzir as chances de ocorrência de falhas no cumprimento das especificações, eliminar
gargalos não observados inicialmente, prever sobre ou subutilização de recursos, e otimizar o
desempenho do sistema.
Schmidt (1984 p.65) define modelo como uma representação da realidade sem a
presença da mesma, enquanto Alexander (2006 p.1929) define simulação como o processo de
criação de um modelo para um sistema real ou proposto, objetivando o estudo do desempenho
deste sistema sob condições específicas.
Baseado no modelo que representa o sistema real, para cada simulação executada são
efetuadas seqüências de operações sobre este modelo no sentido de expressar da melhor
maneira possível o funcionamento do sistema.
Para Law e Kelton (2000 p.3), assim como o defendido por Schmidt (1984 p.65), os
modelos criados podem ser classificados quanto à natureza do sistema como discretos, quando
as variáveis de estado têm seus valores alterados instantaneamente em pontos separados do
intervalo, ou contínuos, quando as variáveis de estado são modificadas continuamente ao
longo deste intervalo.
Máquinas industriais são típicos modelos discretos, pois a partir de comandos
eletrônicos ou mecânicos, como “ligar” e “desligar”, o estado muda instantaneamente,
enquanto fenômenos naturais, como a formação de ciclones, normalmente são analisados em
termos de variações contínuas dos estados do modelo.
Outra classificação a ser considerada é a divisão entre modelos determinísticos, ou
analíticos, onde não são considerados elementos probabilísticos, e modelos estocásticos, onde
as variáveis do modelo permitem variações aleatórias, segundo distribuições de probabilidade.
Exemplos de modelos determinísticos são a programação linear, a programação não-linear e a
programação dinâmica, enquanto entre os modelos estocásticos podem ser encontrados a
teoria das filas e a análise de confiabilidade. Esta divisão é defendida por Perros (2009 p.2),
Law e Kelton (2000 p.6), entre outros.
O processo de simulação computacional trata dos modelos estocásticos, ao contrário
dos modelos analíticos, experimentados a partir de processos determinísticos. Um conjunto de
simulações com os parâmetros adequados e distribuições escolhidas corretamente podem
levar a uma média comportamental que se aproxima da realidade com relação ao sistema,
251
permitindo prever situações críticas, aperfeiçoar o plano de operações de sistemas

manufatureiros, ajustar detalhes da estrutura de manutenção e abastecimento, experimentar as
possibilidades de mudanças climáticas, apenas para citar alguns exemplos de utilizações.
Segundo Wang e Chatwin (2005 p. 1254), em vez de utilizar especialistas para
construir um modelo matemático extensivo usando a abordagem analítica, onde o método de
analisar o sistema é puramente teórico, a simulação baseada em computador é mais adequada
para modelos complexos. Simulação computacional é vista como uma ferramenta de negócios
completa, que dá mais flexibilidade e conveniência ao projeto, planejamento de produção e
análise de complexos processos de manufaturas e sistemas. Isto ocorre porque a modelagem e
simulação baseadas em computador têm a capacidade de representar uma estrutura estática
complexa, bem como o comportamento dinâmico do sistema.
Uma possibilidade de simulação que não pode ser menosprezada é aquela em que um
modelo analítico é testado pela variação de seus parâmetros dentro do escopo de validade,
com o objetivo de encontrar os conjuntos de valores que levam aos melhores resultados. Esta
é a típica abordagem utilizada pelas redes neurais.
Outra classificação relevante com relação ao modelo está relacionada à sua dinâmica
de execução, podendo tratar de modelos estáticos ou dinâmicos. Segundo a definição de Law
e Kelton (2000 p.5), um modelo de simulação estático representa o sistema em um instante
particular, ou sistemas nos quais o tempo simplesmente não tem uma regra especificada,
como as simulações de Monte Carlo, enquanto o modelo dinâmico trata de sistemas que
evoluem ao longo do tempo, tal como a simulação de sistemas de transporte em uma fábrica.
O tipo de simulação utilizado será definido em grande parte pela classificação do
modelo utilizado em termos de sua natureza e do comportamento dos componentes. Estas
classificações devem ser combinadas, caracterizando o modelo em três dimensões bem
definidas, e um sistema pode apresentar comportamentos heterogêneos com relação a algumas
das classificações, resumidas na Tabela 18.
Tabela 18: Classificação dos Modelos Matemáticos de Simulação.
Classificação Comportamento analisado

Discreto Contínuo Forma com que ocorre a mudança de estado
Determinístico Estocástico Presença de aleatoriedade no modelo
Estático Dinâmico Dinâmica de Execução
252
No caso da ACCV, o problema sob análise caracteriza-se inicialmente pela sua

natureza aleatória, envolvendo elementos como taxas de falhas, atrasos logísticos, fenômenos
naturais, e muitos outros.
Com relação às mudanças de estado, estas são pontuais, principalmente pelo fato de
que sistemas manufatureiros mudam instantaneamente seu estado a partir de comandos ou
ocorrência de eventos determinados, o que caracteriza um modelo discreto, transitando entre
os estados de indisponível, em repouso (stand by) e produzindo.
Por fim, as mudanças de estado do sistema, bem com de seus componentes, devem ser
acompanhadas ao longo do tempo, sendo as estruturas de manutenção e abastecimento, além
dos meios de transporte, influenciadas a cada novo evento pela execução de todas as
atividades relacionadas, caracterizando como um modelo dinâmico.
Baseado na análise efetuada, e de forma a satisfazer as três dimensões consideradas, o
presente trabalho utiliza a Simulação Discreta por Eventos como meio de investigar o
problema de ACCV, com modelagem e implementação focando as atuais técnicas de reuso de
software, visando permitir a aplicação da mesma com baixíssimo esforço computacional aos
mais diversos contextos.
Destaca-se a aplicação de simulação por eventos a contextos nos quais haja uma
seqüencia de ações interdependentes dentro do domínio do problema, as quais podem ocorrer
em tempos aleatórios ou programados, conforme a regra de formação utilizada na construção
de cada cenário de análise. Este comportamento seqüencial é observado no problema sob
análise, haja visto que cada atividade executada muda o estado de diversas variáveis da
simulação, e as atividades seguintes devem considerar a modificação no estado decorrente
desta execução.
Existe também uma tendência natural de utilização da orientação a objetos na criação
dos sistemas de simulação atuais, pois, segundo Joines e Roberts (1997 p. 78), esta
abordagem fornece um recurso muito intuitivo na criação dos aplicativos porque é muito fácil
visualizar o mundo real como uma composição de objetos. Por exemplo, no setor de
manufatura alguns objetos vêm logo à mente, tais como máquinas, funcionários,
componentes, ferramentas e meios de transporte. Além disso, roteamento, escalonamento,
bem como o plano de trabalho, podem ser interpretados como objetos.
Segundo Kosturiak e Gregor (1999 p. 163), como grandes modelos de simulação de
sistemas logísticos são concebidos e construídos com base em um projeto, as características
da simulação orientada a objetos tornam possível a co-operação da equipe no
253
desenvolvimento destes modelos. Objetos específicos da modelagem e módulos do sistema

são projetados, testados e, finalmente, integrados em um modelo comum hierárquico.
Segundo Schmidt (1980 p. 319), bem como Maria (1997 p. 8), os passos para a
concepção de uma simulação são:
1. Identificação do problema;
2. Especificação dos objetivos da análise;
3. Análise das características de funcionamento do sistema e coleta de dados que
descrevem o seu comportamento;
4. Formulação do modelo do sistema;
5. Estimativa dos valores dos parâmetros do modelo;
6. Validação preliminar do modelo;
7. Desenvolvimento dos sistemas computacionais necessários;
8. Validação do modelo final;
9. Especificação dos experimentos de simulação a ser realizado; e
10. A análise dos resultados.
O passo inicial na definição de um modelo de simulação é a enumeração dos

problemas inerentes a um dado sistema físico, produzindo os requisitos para o modelo
idealizado do sistema.
Este é um passo importante, pois requisitos desnecessários ou insuficientes podem
levar à determinação incorreta dos objetivos, ou à impossibilidade de se atingir os objetivos a
serem especificados.
No caso específico da ACCV, o problema considerado é a correta interpretação dos
custos envolvidos na concepção, utilização e descarte de um sistema qualquer, levando em
consideração todas as atividades envolvidas nas mais diversas fases de seu ciclo de vida.
Segundo Schmidt (1980 p. 319), uma vez que o problema tenha sido identificado o
analista deve delinear um procedimento que deverá levar à sua resolução. Para analisar
corretamente o problema e desenvolver procedimentos corretos os objetivos a serem
alcançados como resultado da análise deve ser cuidadosamente especificado. Além disso,
critérios devem ser definidos para analisar qual o grau de cumprimento desses objetivos pode
ser determinado. Por exemplo, o objetivo do estudo pode ser o de reduzir o tempo de
inatividade de determinada máquina. Uma solução que pretende atingir este objetivo carrega
pouca credibilidade a menos que o grau de realização possa ser previsto e medido
254
quantitativamente. Assim, a solução do problema deveria incluir uma estimativa da redução

do tempo de inatividade que irá resultar da aplicação das recomendações resultantes do estudo
ou, em geral, uma estimativa dos benefícios a serem obtidos a partir da solução proposta.
As simulações que envolvem o problema da ACCV objetivam estimar os custos
globais referentes ao ciclo de vida completo do sistema, com diferentes configurações e
operando em diferentes cenários, fornecendo uma visão estratégica da implantação do
sistema, bem como das estruturas de apoio.
A partir da determinação de objetivos, a fase de coleta de dados inicia-se, podendo
envolver muitos processos diferenciados para determinação dos parâmetros e atributos que
irão nortear o desenvolvimento do modelo. Esta fase trata da interpretação do mundo real em
termos quantitativos, com a delineação das variáveis de estado que virão a caracterizar o
sistema simulado.
Dependendo da natureza dos atributos estudados esta pode ser a fase mais cara de todo
o processo de concepção de uma simulação, podendo envolver pesquisas, outras simulações,
análise de dados históricos, entrevistas, entre muitos outros processos.
Com a correta compreensão das variáveis que definem o sistema sob análise, um
modelo matemático deve ser definido, e suas características irão determinar a estratégia de
simulação a ser utilizada. No framework de ACCV, o comportamento seqüencial e
interdependente dos mais diversos componentes levou à adoção de um modelo orientado a
objetos, com execução baseada no consumo de filas de eventos discretos.
Segundo Schmidt (1980 p.319), o desenvolvimento de um modelo válido deve ser
fundado na compreensão completa do sistema em si. Para este fim o analista deve prosseguir
uma investigação exaustiva do sistema para identificar o seu objetivo, características
operacionais e obter dados relevantes para o comportamento do sistema sob condições de
operação atuais ou do passado, além de identificar mudanças no sistema previstas para o
futuro.
A seguir, com a estimativa de valores para os parâmetros do modelo, pode ser feita
uma validação preliminar, com o objetivo de detectar possíveis falhas antes da fase de
implementação, pois qualquer alteração a ser efetuada nos processos iniciais será menos
dispendiosa que possíveis acertos no sistema já concebido. Com uma resposta positiva na
validação preliminar, as ferramentas computacionais serão escolhidas e a estratégia para
criação do software definida.
A escolha das ferramentas computacionais acaba por esbarrar em um dilema acerca da
escolha entre flexibilidade e facilidade de desenvolvimento. Ao mesmo tempo em que uma
255
linguagem de programação, como o Java ou Fortran, permite alta flexibilidade no

desenvolvimento de um sistema de simulação, exige grande conhecimento da linguagem e
demanda um grande esforço. Por outro lado pacotes de simulação especializados são muito
mais amigáveis e permitem fácil utilização por parte do usuário, mas não oferecem muita
flexibilidade no desenvolvimento. Com o sistema constituído, podem ser definidos cenários a
serem simulados, partindo para a fase de verificação e aceitação do modelo.
O planejamento de experimentos tem dois objetivos:
1. Executar diversas vezes o modelo de forma rápida e barata; e

2. Providenciar uma estrutura para o processo de aprendizado dos investigadores,
para que os mesmos possam aprender mais a respeito do sistema.
Os experimentos devem ser planejados de forma inicialmente estratégica, com o

projeto de experimentos visando alcançar as metas estabelecidas. É necessário combinar os
valores dos parâmetros que levem as variáveis de respostas aos patamares esperados, e
explicar as relações entre as variáveis de respostas e os fatores controláveis do sistema.
No nível tático são executadas as simulações Para isso devem ser definidas as
condições iniciais, e como elas afetam o equilíbrio do sistema. O pano de fundo dessa fase é a
necessidade de diminuir a variância das respostas e, ao mesmo tempo, buscar minimizar o
tamanho das amostras necessárias.
Com a execução de simulações, o modelo passa para a fase de validação final, onde a
utilidade prática e veracidade das informações geradas serão testadas, podendo levar a um
retorno às fases iniciais da concepção do modelo caso elementos críticos sejam detectados.
Segundo Schmidt (1980 p. 321), a validação final do modelo de simulação é um
processo de três estágios. O primeiro passo neste processo, chamado de verificação, é
certificar-se que o modelo de simulação está funcionando da forma esperada pelo analista. A
segunda fase de validação é muito mais difícil de lidar. Tendo verificado que o modelo está a
funcionar na sua forma pretendida, o analista deve determinar se este funcionamento está em
conformidade com a realidade. Se o modelo de simulação é usado para representar o
comportamento de um sistema operacional, os resultados da modelo de simulação muitas
vezes podem ser comparados com aqueles realizados a partir do sistema do mundo real, com a
utilização de condições exógenas equivalentes. Finalmente, a terceira e última etapa envolve a
aceitação do modelo como um previsor de condições futuras, o que pode ocorrer apenas após
a implantação do modelo, mesmo que em uma base experimental.
256
Com o modelo consolidado, verificado e aceito, o mesmo passa a fornecer dados

certificados, originando uma gama de resultados que podem ser analisados por ferramentas
adequadas, de forma gráfica ou textual.
Neste ponto, o sistema de simulação torna-se uma importante ferramenta no
planejamento estratégico e tomada de decisão, podendo se utilizar de processos complexos de
análise, como uso de inteligência artificial e redes neurais.
C.3 SIMULAÇÃO POR EVENTOS DISCRETOS
Segundo Law e Kelton (2000 p.6), a simulação por eventos discretos permite a
modelagem de um sistema que evolui ao longo do tempo por uma representação na qual as
variáveis de estado se modificam instantaneamente em instantes pontuais no tempo. No
modelo aqui defendido, a alteração do estado destas variáveis é promovida como resultado da
execução de atividades iniciadas nestes instantes de tempo.
Entre os elementos principais de uma simulação baseada em eventos discretos
encontram-se as variáveis de estado que delineiam as entidades componentes do sistema, a
lista de eventos, o relógio interno da simulação, o gerador de números aleatórios e a
configuração do cenário de análise, incluindo distribuições utilizadas, estados iniciais e
eventos decorrentes de programação prévia (eventos de entrada ou de chegada).
Deve ser levado em conta o fato de que recursos são limitados, e para a execução de
uma determinada atividade todos os recursos necessários devem estar disponíveis no instante
t simulado. Em simulações onde os recursos são considerados na execução das atividades,
listas de espera por disponibilidade de recursos devem ser utilizadas no sentido de propiciar a
suspensão do processamento de um evento qualquer até que os recursos necessários sejam
liberados ou adquiridos ao término do processamento de outros eventos.
Com o avanço do relógio interno os eventos da lista são consumidos, podendo gerar
novos eventos a serem adicionados à lista, ordenada de acordo com o instante desejado para
ocorrência dentro do período simulado, dentro de um processo onde são geradas imagens do
sistema em instantes específicos, caracterizadas pelos valores assumidos pelo conjunto de
variáveis de estado, criando um histórico passível de ser analisado por ferramentas estatísticas
textuais ou gráficas.
257
Embora exista uma grande diversidade de domínios onde a simulação por eventos
pode ser aplicada, algum componentes comuns a todos os sistemas que implementam estes
modelos de simulação foram destacados por Law e Kelton (2000 p.9):
• Estado do Sistema – A coleção de todas as variáveis de estado necessárias para

descrever o sistema em um instante particular;
• Relógio de Simulação – Uma variável contendo o valor atual do tempo de
simulação em determinado instante;
• Lista de Eventos – Uma lista contendo o próximo instante em que cada tipo de
evento irá ocorrer;
• Contadores Estatísticos – Variáveis utilizadas para armazenar informações
estatísticas sobre o desempenho do sistema;
• Rotina de Inicialização – Um subprograma para inicializar o modelo de
simulação no instante inicial;
• Rotina de Temporização – Um subprograma que determina o próximo evento da
lista e então avança o relógio de simulação para o instante em que este evento irá
ocorrer;
• Rotina do Evento – Um subprograma que atualiza o estado do sistema quando um
tipo particular de evento ocorre, existindo uma rotina diferenciada para cada tipo
de evento;
• Bibliotecas – Conjunto de subprogramas utilizado para gerar observações
randômicas sobre as distribuições de probabilidade determinadas no modelo de
simulação;
• Gerador de Relatórios – Um subprograma que processa as estimativas das
medições desejadas de desempenho a partir dos contadores estatísticos e produz
um relatório ao final da simulação; e
• Programa principal – Um subprograma que invoca a rotina de temporização para
determinar o próximo evento e transfere o controle para a rotina do evento
correspondente para atualizar o estado do sistema adequadamente. O programa
principal também verifica o término da simulação e invoca o gerador de relatórios
quando a simulação acaba.
258
Sistemas de simulação por eventos discretos são formalizados segundo a notação

DEVS, do inglês Discrete Event System Specification, criada por Zeigler. Conforme citado
por Chow e Zeigler (1994 p.2), Zeigler e Kim (1996 p.154), entre outros, um modelo DEVS
pode ser representado formalmente como se segue:
M = < X, S, Y, δint, δext, λ, ta >

δext: Q × X → S: Função de transição externa, onde Q = {(s,e) | s ϵ S, 0 ≤ e ≤ ta(s)}.
Nesta representação formal o modelo DEVS transita entre os estados representados em

S através da função de transação interna δint. Não ocorrendo nenhum evento externo, o
instante de uma mudança interna de estado é definido por ta aplicado ao estado corrente, ou
seja, ta(s). O novo estado do modelo é definido por δint(s). Claro que antes de qualquer
transição interna, o modelo pode gerar um evento de saída y, definido por λ(s), que depende
do estado antes da transação interna. Da mesma forma, a transição de estado pode acontecer
quando um evento de entrada externa ocorre também. A função δext determina o novo estado
com base no estado atual, o tempo em que o modelo permaneceu neste estado, e a entrada de
dados provida pelo cenário de análise, em outras palavras δext(s,e,x).
A fim de ilustrar uma simulação no modelo atômico é considerado aqui um semáforo
em um cruzamento viário, onde os carros que seguem de leste a oeste surgem a uma taxa de
60 carros/minuto, com velocidade constante de 40 km/h, enquanto os carros que seguem de
norte a sul surgem a uma taxa de 40 carros/minuto, com velocidade constante de 30 km/h.
A entidade sob análise é o semáforo, podendo assumir os estados “verde”, onde os
carros que seguem de norte a sul são obrigados a parar, “vermelho”, onde os carros que
seguem de leste a oeste é que param, e “intermitente”, onde não há controle de parada.
Quanto aos eventos externos, o único considerado nesse exemplo foi solicitação de
pedestre, o que poderia ser feito através de um botão a ser pressionado pelo mesmo.
259
Alguns resultados da simulação podem ser observados na Figura 128, em quatro

instantes do acompanhamento, segundo a ordem de ocorrência, tendo sido utilizados os
seguintes parâmetros:
X = {“pedestre”}
S = {“vermelho”, “verde”, “intermitente”}
Y = {“Pedestre Bloqueado”}
S0 = (“vermelho”, 15): Estado inicial “vermelho” por 15s.
δint(“verde”) = (“intermitente”, 15): Transição de verde para intermitente.
δint(“intermitente”) = (“verde”, 15): Transição de intermitente para verde.
δint(“vermelho”) = (“verde”, 15): Transição de vermelho para verde.
δext((“verde”, e), “pedestre”) = (“vermelho”, 20): Chamada de pedestre.
λ(“vermelho”) = “Pedestre Bloqueado”
Figura 128: Simulador de Tráfego utilizando DEVS atomizado
(Applet disponível em http://www.cs.gsu.edu/DEVSTutorial/)

260
O modelo DEVS com acoplamento (CDEVS) é utilizado para representar sistemas

com componentes interconectados, obedecendo à seguinte notação:
CM = < X, Y, D, {Mi}, {Ii}, {Zi,j} >

{Mi}: Modelo DEVS para cada componente (atômico ou acoplado).
{Ii}: Conjunto de influências do componente, caracterizado em Y.
{Zi,j}: Conexão entre a saída de Mi e a entrada em Mj para cada Ii.
A Figura 129 apresenta um exemplo de CDEVS, onde ocorre o acoplamento definido

pela seguinte configuração:
X = {“sinal”}
Y = {“Pedestre Bloqueado”}
D = {Sem1, Sem2}
{Mi} = {MSem1, MSem2}
{Ii} = {ISem1(“Pedestre Bloqueado”)}
{Zi,j} = {[MSem1(“Pedestre Bloqueado”), MSem2(“sinal”)]}
Figura 129: Simulador de Tráfego utilizando DEVS com acoplamento

261
Existe uma grande discussão acerca do uso de paralelismo na simulação por eventos
discretos devido à natureza seqüencial deste tipo de simulação. A versão com execução de
tarefas em paralelo é formalizada pelo PDEVS (do inglês Parallel Discrete Event System
Specification), baseado em conjuntos de modelos menores seqüenciais acoplados, e as formas
de comunicação entre estes modelos. Com a divisão em unidades menores, as mesmas podem
ser executadas de forma independente, sujeitas apenas a processos de sincronização
determinados.
Segundo Ziegler e Sarjoughian (2003 p. 35), o modelo PDEVS pode ser descrito
formalmente como se segue:
PM = < XM, YM, S, δext, δint, δcon, λ, ta >
XM = {(p,v) | p ϵ IPorts, v ϵ XP }: Um conjunto de portas de entrada e valores.

YM = {(p,v) | p ϵ OPorts, v ϵ YP }: Um conjunto de portas de saída e valores.
δext: Q × XM → S: Função de transição externa.
δcon: Q × XM → S: Função de transição confluente.
Q = {(s,e) | s ϵ S, 0 ≤ e ≤ ta(s)}: Conjunto completo de estados.
Não houve uma formalização do Modelo de Pilla e Cople em termos das notações aqui
citadas, porém as características de um DEVS podem ser facilmente observadas, já que ocorre
o tratamento de forma seqüencial os eventos para cada simulação. No entanto, a nova
implementação apresentada aproveita-se dos recursos computacionais atuais, que permitem
processos paralelos para tarefas secundárias e distribuição de processamento.
Em outras palavras, apesar de processar os eventos de forma seqüencial, o framework
de ACCV efetua tarefas como persistência ou envio de dados em processos independentes,
retirando os atrasos de gravação e transmissão do tempo necessário ao cálculo, além de
utilizar um modelo cliente-servidor, com a execução de múltiplos clientes simultaneamente,
enquanto o servidor provê cenários de simulação e captura resultados.
262
Conforme já descrito por Cople (2004 p.69), um produto, particularmente o sistema,

pode ser encarado com vários níveis de abstração. Um dos níveis possíveis é o produto como
uma entidade virtual genérica, ou forma, ou classe, possuindo determinadas características
que os sistemas reais (instâncias) devem obedecer. Nas fases iniciais do ciclo de vida
(concepção, projeto e desenvolvimento) só existe o sistema no estado virtual, determinando o
primeiro estado da simulação.
Após a fabricação dos sistemas-produto, passam a ter existência instâncias da classe
sistemas (objetos), assim como seus produtos componentes, podendo apresentar históricos de
vida diferentes.
Um produto instanciado apresenta variações em seu estado ao longo de sua existência,
apresentando três estados básicos, a saber:
0. Indisponível;
1. Disponível em Espera (Stand by); e
2. Disponível Operando
Estes quatro estados (virtual, indisponível, esperando e operando) determinam o

conjunto S de estados principais do modelo, o que não impede que outras propriedades sejam
utilizadas no decorrer da simulação, já que o reuso proporcionado pela orientação a objetos é
uma das principais vantagens obtidas.
Um produto está indisponível quando não está em condições de operar (sistema) ou
participar da operação (componentes), sujeitando-se a manutenções corretivas neste período
de tempo. No Modelo de Pilla e Cople, se não houver a quantidade mínima de componentes
de qualquer nível de composição do sistema em condições de operar, o sistema como um todo
fica indisponível.
Quando o sistema passa a operar, todos os seus componentes entram no estado
“operando”, permanecendo neste estado até o final da operação agendada, desde que não
ocorra falha em algum deles, o que pode levar o sistema e toda a hierarquia do componente
faltoso para o estado indisponível, enquanto demais componentes de outras hierarquias ficam
disponíveis em espera. Esta situação, para o sistema de exemplo é demonstrada na Figura 130.
263
Figura 130: Efeito da falha em E2 para o sistema de exemplo.
O histórico destes estados é armazenado em uma estrutura de lista definida por Cople
(2004), a qual foi denominada “Linha de Vida”, armazenando todo o histórico de cada
instância de produto no decorrer da simulação.
Como os produtos podem ser substituídos por sobressalentes, participar de operações e
sofrer manutenções de forma independente, cada instância de produto (sistema ou
componentes) tem sua própria “Linha de Vida” cada qual com resultados finais
completamente distintos, pois apenas haveria a equivalência de resultados em sistemas
perfeitos, onde nenhum componente estivesse sujeito a qualquer tipo de falha.
No Modelo de Pilla e Cople, a função de o avanço no tempo ta(s) é obtida a partir da
duração de cada atividade executada, as quais podem ser iniciadas por eventos internos ou
externos.
Nesse modelo a geração de eventos é determinada a partir do encapsulamento de uma
máquina de estados, segundo o padrão de desenvolvimento State, havendo sempre um estado
inicial, estados intermediários e um estado final. O estado inicial é determinado por
agendamentos ou modos de falha, elementos que determinam o conjunto X de eventos
externos.
As funções δext e λ(s) foram definidas no Modelo de Pilla e Cople a parir do estado
inicial para cada modelo de geração de eventos, enquanto a função δint(s) pode ser obtida a
partir da interpretação dos demais estados. Estes outros estados, além do inicial, acabam por
determinar o conjunto Y de eventos internos.
264
Um detalhamento completo do conceito de “Linha de Vida” pode ser obtido na

dissertação de Cople (2004), sendo aqui transcritos e adaptados alguns trechos que permitem
exemplificar seu funcionamento.
Inicialmente, considera-se o sistema e seus componentes como elementos perfeitos,
com sua linha de vida refletindo apenas os momentos de aquisição, instalação, ciclos
operacionais e descarte, não apresentando falhas ao longo do ciclo de vida, como pode ser
visto na Figura 29. Segundo esta análise inicial, o sistema encontrar-se-ia no estado
indisponível ou virtual apenas nos momentos anteriores à instalação e posteriores ao descarte.
Estado
2
0
20 40 60 80 100 120 140 160 180 Tempo
Figura 131: Operação Normal, sem eventos que causem indisponibilidade
Sob uma ótica inicial, os eventos podem ser expressos como pulsos efetuados em
determinados instantes da existência do sistema, com a amplitude dada pela duração total da
atividade executada. Pode haver um nível de aleatoriedade para cada uma das variáveis
consideradas.
A Figura 132 apresenta uma representação gráfica da ocorrência dos eventos e a
duração das atividades geradas.
Duração da Atividade
24
16
20 40 60 80 100 120 140 160 180 Tempo
Figura 132: Eventos com distribuição e duração aleatórias

265
Alguns tipos de atividades podem causar indisponibilidade no sistema afetando o seu

perfil de operação normal acima descrito. O impacto da indisponibilidade na operação do
sistema pode ser variado. Algumas possibilidades são:
1. Deslocamento em uma faixa do gráfico de operação do sistema; e

2. Cancelamento de trechos de operação.
Uma ilustração da primeira hipótese, considerando a operação normal mostrada na

Figura 29 e os eventos causadores de indisponibilidade da Figura 31, é apresentada na Figura
32, enquanto a Figura 33 ilustra a segunda hipótese, sob as mesmas condições.
Duração da Atividade
24
16
20 40 60 80 100 120 140 160 180 Tempo
Figura 133: Eventos causadores de indisponibilidade com distribuição definida e duração fixa
Estado
2
0
20 40 60 80 100 120 140 160 180 Tempo
Figura 134: Efeito sobre um sistema com operação agendada, com deslocamento
Estado
2
0
20 40 60 80 100 120 140 160 180 Tempo
Figura 135: Efeito sobre um sistema com operação agendada, sem deslocamento
266
No Modelo de Pilla e Cople apenas a segunda hipótese é considerada, ou seja,

havendo uma falha causadora de indisponibilidade haverá perda de produção parcial,
referente apenas ao período de manutenção ou substituição de componente.
C.4 GERADORES RANDÔMICOS
Um elemento fundamental das bibliotecas utilizadas é o gerador de números

aleatórios, pois a qualidade de uma simulação sempre está diretamente associada à qualidade
das distribuições utilizadas na execução da simulação.
Geração de números aleatórios em computadores, que processam tudo de forma
determinística, é uma tarefa impossível quando baseada apenas em software. Em aplicações
práticas, números são normalmente produzidas com regras determinísticas, implementadas
através de geradores pseudo-aleatórios de números, os quais geralmente contam com
operações aritméticas simples.
As simulações computacionais exigem geradores randômicos com boa qualidade, além
da possibilidade de se repetir um experimento nas mesmas condições e obter os mesmos
resultados. Considerando-se que os números são pseudo-aleatórios por serem baseados em
seqüências matemáticas, repetindo-se a posição inicial desta seqüência, repetem-se os valores
utilizados na simulação original, o que leva à possibilidade de se armazenar apenas este valor
inicial, denominado semente, a qual deve ser gerada a cada novo experimento com alto nível
de aleatoriedade.
Segundo Meyer, Renschler e Vining (2008 p.1069), na modelagem estocástica, dois
atributos são de especial interesse na geração de números aleatórios: a “aleatoriedade” do
fluxo de números e a reprodução fiel da distribuição estatística esperada.
A estratégia utilizada neste trabalho é a de se utilizar um algoritmo rápido e de boa
qualidade no que concerne aos números gerados, enquanto as sementes podem ser geradas
com a utilização de métodos mais robustos, e conseqüentemente demorados, ou até mesmo
por métodos realmente aleatórios, como uso de ruído eletrônico.
Isto se deve ao fato de que as simulações no framework de ACCV são executadas em
máquinas cliente, exigindo grande processamento, enquanto as sementes serão geradas no
servidor, onde o processamento é menor, havendo apenas maior I/O, e enviadas aos clientes.
A arquitetura de processamento distribuído criada pode ser vista em detalhes na Seção 4.3.
267
C.5 CARACTERÍSTICAS DESEJÁVEIS DE UM SISTEMA DE SIMULAÇÃO
Embora os sistemas de simulação apresentem numerosas características, que não serão

necessariamente as mesmas com a mudança de domínio, algumas são comuns a todos eles,
sendo agrupadas por Law e Kelton (2000 p.208) da seguinte forma:
• Flexibilidade e facilidade de uso;

• Hardware e Software necessários;
• Animações;
• Elementos estatísticos;
• Suporte e Documentação; e
• Relatórios de saída e gráficos.
Um simulador flexível deve ser capaz de efetuar algumas operações para lidar com a
complexidade da simulação em si, como por exemplo, possibilitar a mudança atributos e
variáveis, bem como de processos, permitir o uso de expressões matemáticas, e possibilitar a
criação de novos modelos, modificar os atuais e utilizar estes novos em modelos criados
posteriormente.
No que tange à facilidade de uso, os elementos principais a serem considerados são a
criação de um depurador, preocupação com velocidade de execução, criação de interfaces
amigáveis, uso de valores default, e interoperabilidade.
Mesmo com o poder dos atuais computadores e redes de computadores, simuladores
são sistemas muito complexos, que utilizam cálculos em larga escala, necessitando de
otimizações contínuas no sentido de melhorar a velocidade de execução. Neste ponto deve ser
decidido também entre o uso de uma plataforma portável, como o Java, ou uma linguagem
que irá gerar código para um sistema operacional específico, como o C++, que permite
acesso direto ao hardware voltado para aceleração de operações matemáticas.
Quanto ao uso de animações, estas podem ser em tempo de execução da simulação, o
que deve ser bem planejado, já que irá diminuir a velocidade de execução da mesma, ou
posterior à simulação, representando o histórico de estados observados durante a simulação.
No caso de simulações longas e distribuídas é necessário informar ao utilizador do
sistema qual o estágio atual de execução, informando qual o percentual completado para cada
simulação ativa, tanto na própria máquina quanto nas diversas máquinas utilizadas em
simulações distribuídas, consumo e disponibilidade de recursos de hardware, erros ocorridos
268
em determinado instante simulado, entre outras informações necessárias ao acompanhamento

da execução dessa simulação.
O tratamento estatístico é de crucial importância para o simulador, pois se o mesmo
não tem boas ferramentas de análise torna-se impossível a obtenção de resultados confiáveis
em um estudo de simulação. Um ponto de partida para a obtenção destas ferramentas é a
utilização de bons geradores de números aleatórios, que devem garantir conjuntos diferentes
de valores para cada simulação efetuada, dentro das distribuições solicitadas.
Com o resultado das várias simulações, uma análise estatística comum pode ser
efetuada, mas devem existir os métodos necessários para a construção de um intervalo de
confiança. Este método deve ser de fácil compreensão e prover bons resultados estatísticos.
O simulador deve fornecer informações estatísticas não apenas sobre o resultado das
simulações, mas também sobre os tempos de inicialização e execução, de forma a permitir o
planejamento de múltiplas simulações de uma forma otimizada, aproveitando os recursos
existentes da melhor forma possível.
Uma boa documentação deve ser criada, de forma a viabilizar o auto-aprendizado,
podendo fornecer tutoriais e pequenos exemplos que explorem as características do sistema de
simulação.
Finalmente, os relatórios de saída e gráficos irão determinar, em grande parte, o
sucesso ou fracasso do software. Relatórios padronizados devem ser fornecidos para as
estatísticas inicialmente determinadas, mas deve ser possibilitada ao gestor a criação de
relatórios customizados. Para cada medida observada, usualmente são fornecidos os valores
médio, mínimo e máximo, bem como o acompanhamento pontual.
O simulador deve ser capaz de fornecer uma boa variedade de gráficos estatísticos,
como histograma dos conjuntos de valores observados, gráfico de linhas com
acompanhamento pontual dos valores observados, além de gráficos de barras ou torta. Uma
estratégia comum é o armazenamento de resultados em bancos de dados para posterior
construção de gráficos, como é efetuado no framework de ACCV.
269
ANEXO D – CASO DE TESTE
Objetivando verificar o processamento implementado no framework, foi definido um

caso de testes simples, considerando poucos locais, uma estrutura de manutenção e
abastecimento simples, além de um sistema pouco complexo.
O sistema especificado para este caso de teste é composto de dois equipamentos, e
seus componentes apresentam a estrutura hierárquica e as características definidas na Tabela
19, enquanto a Figura 136 apresenta uma representação gráfica da estrutura deste sistema.
Tabela 19: Estrutura do Sistema de Teste e características dos componentes
Item Preço Lote Peso Vol Qtd Qtd Percentual ∆$1 MTBF2 RIP
Unitário (Kg) (m³) Util Nec Uso (%) (%)3
S1 220.000,00 1 2000 500 1 1 100 22.000,00 - -
M1 5.000 -
E1 89.000,00 1 1300 250 1 1 100 6.000,00
M2 10.000 -
LRU11 83.000,00 1 1200 220 1 1 100 3.000,00 500 20
SRU111 50.000,00 10 600 100 1 1 100 50.000,00 5.000 0
SRU112 15.000,00 5 500 100 2 2 100 15.000,00 1.000 0
E2 109.000,00 1 650 150 1 1 50 7.000,00 10.000 -
LRU21 102.000,00 1 500 120 1 1 100 102.000,00 5.000 5
1
Custo incremental para produção do componente.
2
MTBF para o modo de falha especificado, sem influência do tempo de falha dos filhos.
3
Manutenção sobre Equipamentos tem de ser feita no local.
270
Figura 136: Representação gráfica do Sistema de Teste.
Uma observação a ser feita sobre os dados da tabela é a de que o equipamento “E1”
apresenta dois modos de falha distintos, denominados “M1” e “M2”. Outro ponto a ser
considerado é o fato de que os equipamentos analisados não poderão ser retirados, não sendo
aplicável o parâmetro RIP.
As cidades consideradas na simulação são Rio de Janeiro, São Paulo, Brasília, Belo
Horizonte, e Manaus, e o meio de transporte rodoviário é utilizado como padrão para todos os
percursos entre as cidades.
Em São Paulo e no Rio de Janeiro encontram-se os órgãos operacionais, sendo que
alguns reparos podem ser feitos pela equipe técnica alocada em São Paulo, enquanto no Rio
de Janeiro apenas a retirada de alguns componentes e a manutenção dos equipamentos “E1” e
“E2” (que não podem ser retirados) podem ser realizadas.
Belo Horizonte encontra-se como Órgão de Manutenção de primeiro nível e Brasília
efetua o segundo nível de manutenção, além de efetuar as atividades de desenvolvimento do
projeto. O último nível de manutenção é definido pelo fabricante, situado em Manaus.
O cenário inicia-se na data de 01/01/2001, simulando o funcionamento do sistema
durante um período de 20 anos. Os parâmetros globais utilizados para manutenção e
transporte são NFF de 5%, NRTS de 5% e percentual de valor para seguro (no caso de
transporte de componentes) no valor de 7% do preço unitário do componente.
Em se tratando dos fatores financeiros, também foi definido um intervalo de desconto
de dois meses, a uma taxa de 0,25%.
271
Quanto ao sistema utilizado, serão instaladas duas unidades no Rio de Janeiro e quatro
em São Paulo, operando de acordo com a Tabela 20.
Tabela 20: Operação dos Sistemas para o Caso de Teste.
Funcionamento por Operação e Espera

Instância Período de Operação (hs) Período de Espera (hs) Início
RJ – 1 36 12 01/03/2002
RJ – 2 36 12 01/03/2002
SP – 1 16 8 01/03/2002
SP – 2 36 12 01/03/2002
Funcionamento por Missões

Instância Média de Missões por Ano Duração Média da Missão (dias) Início
SP – 3 50 3 01/01/2002
SP – 4 10 15 01/01/2002
Neste cenário, os sistemas de operação e espera serão instalados dia 15/02/2002, à

exceção da instância “SP-1”, instalada no dia 15/02/2003. Quanto aos sistemas que funcionam
por missão, estes serão todos instalados no dia 15/12/2001.
Os sistemas serão todos adquiridos no dia 15/11/2001 no fabricante, situado em
Manaus, e enviados em seguida para seus detentores, enquanto o estoque inicial de
sobressalentes será adquirido no dia 01/12/2001.
Quanto ao descarte, os sistemas irão parar de operar no dia 01/10/2019, à exceção da
instância “SP-1”, que terá suas atividades encerradas no dia 01/12/2019.
Para o exemplo são utilizados quatro tipos de profissionais:
• Operador, utilizado na operação do sistema;

• Técnico de Nível 1, utilizado nas manutenções mais simples;
• Técnico de Nível 2, utilizado nas manutenções mais complexas; e
• Especialista de Projeto, utilizado nas atividades de desenvolvimento.
272
A Tabela 15 mostra o custo por hora de cada profissional (impostos e encargos já

estão inclusos no custo) a ser utilizado no caso de teste.
Tabela 21: Preço de mão-de-obra para o caso de testes.
Mão-de-Obra Custo por Hora

Operador 20,00
Técnico de Nível 1 30,00
Técnico de Nível 2 50,00
Especialista de Projeto 100,00
A atividade de desenvolvimento irá exigir o consumo de 2000 (duas mil) folhas de

papel vegetal, 3000 (três mil) formulários para definição de projeto, além de um serviço
terceirizado de impressão e arte final.
O tempo gasto por atividade, em horas, foi considerado como um intervalo de tempo
com distribuição uniforme, cujos limites são mostrados na Tabela 22.
Tabela 22: Tempo gasto por atividade em horas, para o caso de teste
Retirada Recolocação Reparo

240 - 480 (M1)
E1 60 - 120 (M2)
LRU11 12 - 24 24 – 48 120 – 160
SRU111 10 - 12 2–3 200 – 240
SRU112 30 - 50 20 – 40 400 – 600
E2 480 – 600
LRU21 12 - 24 24 – 48 300 – 450
Estas atividades geram custos, e ocorrem, muitas vezes, a partir de modelos de geração
aleatórios, ou agendados, além dos modos de falha. Os modelos de geração de eventos e
cálculo de custo são definidos na Tabela 23.
273
Tabela 23: Modelos utilizados no cenário
Atividade Produto Cálculo de Custo Geração do Evento

Aquisição E1 Custo de Aquisição Processo de Manutenção (Descarte)
E2 Custo de Aquisição Processo de Manutenção (Descarte)
LRU11 Custo de Aquisição Por Agendamento (Data de Estoque)
Processo de Manutenção (Descarte)
LRU21 Custo de Aquisição Por Agendamento (Data de Estoque)
SIST1 Custo de Aquisição Por Agendamento
SRU111 Custo de Aquisição Por Agendamento (Data de Estoque)
SRU112 Custo de Aquisição Por Agendamento (Data de Estoque)
Desenvolvimento SIST1 Modelo Padrão Por Agendamento
Instalação SIST1 Modelo Padrão Por Agendamento
Operação SIST1 Modelo Padrão Calendário de Operação
Preventiva E1 Modelo Padrão Geração Aleatória
E2 Custo de Manutenção Por Agendamento
LRU11 Custo de Manutenção Quantidade de Horas
Recolocação LRU11 Custo de Manutenção Processo de Manutenção
LRU21 Custo de Manutenção Processo de Manutenção
SRU111 Custo de Manutenção Processo de Manutenção
Reparo E1 Custo de Manutenção Processo de Manutenção
E2 Custo de Manutenção Processo de Manutenção
Reparo2 E1 Custo de Manutenção Processo de Manutenção
Retirada LRU11 Custo de Manutenção Processo de Manutenção
Transporte E1 Custo de Transporte Atividade de Aquisição
Processo de Manutenção
E2 Custo de Transporte Atividade de Aquisição
LRU11 Custo de Transporte Atividade de Aquisição
LRU21 Custo de Transporte Atividade de Aquisição
SIST1 Custo de Transporte Atividade de Aquisição
SRU111 Custo de Transporte Atividade de Aquisição
SRU112 Custo de Transporte Atividade de Aquisição
274
O início das atividades de desenvolvimento foi agendado para 10/10/2001, podendo

durar de 400 (quatrocentas) a 700 (setecentas) horas.
Quanto às manutenções preventivas, suas configurações irão ser diferenciadas por
órgão, segundo a política interna de cada um. Estas configurações podem ser visualizadas na
Tabela 24.
Tabela 24: Configuração da manutenção preventiva no caso de testes
Órgão Produto Duração da Atividade (hs) Configuração de Eventos

Operacional RJ E1 50 Distribuição Exponencial com média de 600 horas
corridas, apresentando repetição.
E2 400 – 500 Uma manutenção efetuada em 01/01/2006 e outra em
01/01/2008.
Operacional SP E1 50 Distribuição Exponencial com média de 500 horas de
utilização, apresentando repetição.
LRU11 20 Efetuada a cada 200 horas corridas, com repetição.
Um determinado órgão não precisa, necessariamente, executar todas as manutenções

corretivas definidas. A Tabela 25 mostra as atividades executadas por órgão.
Tabela 25: Atividades de manutenção corretiva executadas por órgão no caso de testes
Produto/Atividade RJ SP MG DF MA
REPARO1 X X
E1 REPARO2 X X
RECOLOCAÇÃO X X
LRU11 REPARO X X X X
RETIRADA X X
RECOLOCAÇÃO X X X
SRU111 REPARO X X X
RETIRADA X X X
RECOLOCAÇÃO X X X
SRU112 REPARO X X X
RETIRADA X X X
E2 REPARO X X
RECOLOCAÇÃO / RETIRADA X X
LRU21 REPARO X X X X
275
Finalmente, quanto ao estoque de sobressalentes, este não existe no Rio de Janeiro,

existindo apenas um estoque restrito em São Paulo. Em Belo Horizonte encontra-se um
estoque mais especializado, com capacidade de abastecer as necessidades do Rio de Janeiro e
regularizar o estoque de São Paulo, além de fornecer sobressalentes para os processos de
manutenção desenvolvidos no próprio local. Já o estoque principal, este se encontra em
Brasília, sendo alimentado pelo fabricante e repassando a quantidade necessária de
sobressalentes para Belo Horizonte. A configuração da dotação de estoque utilizada pode ser
observada na Tabela 26.
Tabela 26: Dotação de Estoque para o Caso de Teste
Local LRU11 LRU21 SRU111 SRU112

Brasília 1 1 1 1
Belo Horizonte 1 2 3 3
São Paulo 2 0 1 1

Um Framework para Análise de Custo de Ciclo de Vida Baseado em Reuso e Interoperabilidade

Enviado por

Dados do documento

Título original

Direitos autorais

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Um Framework para Análise de Custo de Ciclo de Vida Baseado em Reuso e Interoperabilidade

Título original:

Enviado por

Direitos autorais:

UNIVERSIDADE FEDERAL FLUMINENSE

DENIS GONÇALVES COPLE

UM FRAMEWORK PARA ANÁLISE DE CUSTO DE CICLO DE VIDA

UM FRAMEWORK PARA ANÁLISE DE CUSTO DE CICLO DE VIDA

Tese apresentada ao Curso de Doutorado em

Orientador: Prof. EDUARDO SIQUEIRA BRICK, PhD.

UM FRAMEWORK PARA ANÁLISE DE CUSTO DE CICLO DE VIDA

Tese apresentada ao Curso de Doutorado em

Aprovada em 15 de Dezembro de 2010.

Palavras-Chave: Engenharia de Sistemas, Apoio Logístico, Análise de Custo de Ciclo de

3.7 Estrutura de Desdobramento de Custos....................................................................... 85

B.3.1 Frameworks voltados para Processos ................................................................ 226

Figura 1: Formas de estudo de um sistema. .......................................................................................26

Tabela 1: Exemplo de "Árvore de Produtos" .....................................................................................70

LISTA DE SÍMBOLOS E ABREVIATURAS

ACCV Análise de Custo de Ciclo de Vida

LCC Life Cycle Cost

Sistemas técnicos são ativos compostos por instalações, equipamentos, softwares e

Essa metodologia de avaliação econômica de projetos, deve considerar todos os custos

modelos em condições próximas às reais, com a utilização de dados estocásticos e um número

O modelo genérico desenvolvido por Pilla e Cople se mostrou adequado à resolução

Os vários padrões arquiteturais para a construção de softwares foram analisados,

1.2.1 Objetivo Geral

Implementar um framework para análise de custo do ciclo de vida, baseado no modelo

1.2.2 Objetivos Específicos

Foram objetivos específicos deste trabalho:

1. Resolver os problemas encontrados no framework antigo;

Além disso, as ferramentas de desenvolvimento evoluíram muito desde 2004,

Elementos genéricos e anotações, por exemplo, começaram a ser utilizados pela

1.4 DELIMITAÇÃO DO ESTUDO

1.5 REFERENCIAL TEÓRICO

1.5.1 Análise de Custo de Ciclo de Vida

A análise do custo do ciclo de vida de sistemas apresenta-se como uma técnica

Figura 1: Formas de estudo de um sistema.

Adaptado de Law e Kelton (2000 p.4)

1.5.3 Reuso de Software

Finalmente, as técnicas voltadas para a modelagem comportamental expandiram o

1.5.4 Arquitetura de Software

Segundo Bass, Clements e Kasman (2003 p.3), arquitetura de software de um

Visão do usuário acerca do problema Modelo do Usuário

Figura 2: Arquitetura de Software no Processo de Desenvolvimento

A definição da arquitetura de software irá determinar quais tipos de componentes

• Persistência de dados, na camada Model;

A adoção desta arquitetura permite o uso de componentes especializados para acesso a

domínios. As principais vantagens de frameworks incluem reutilização e redução do tempo

Outro ponto a se considerar é que os sistemas de informática estão evoluindo muito, e

utilizada na concepção do novo modelo do framework, viabilizando que ferramentas como

1.5.6 Processamento Distribuído

A utilização de processamentos paralelos traz vantagens tanto no uso de apenas um

Existem várias tecnologias para distribuição de processamento, podendo trabalhar

1.6 ESTRUTURA DO TRABALHO

Este trabalho está estruturado da forma que se segue.

2. SIMULAÇÕES COMPUTACIONAIS, REUSO E INTEROPERABILIDADE

Este trabalho, apesar de tratar de um domínio de problema específico (Análise de

2.2 SIMULAÇÕES POR EVENTOS DISCRETOS

A simulação por eventos discretos, ou Discrete Event Simulation (DES), representa

M = < X, S, Y, δint, δext, λ, ta >

X: Um conjunto de eventos externos, ou eventos de entrada.

Quando são tratados sistemas compostos de componentes interconectados, o modelo a

CM = < X, Y, D, {Mi}, {Ii}, {Zi,j} >

X: Um conjunto de eventos externos, ou eventos de entrada.

CM = < X, Y, D, {Md | d ϵ D}, EIC, EOC, IC >

Figura 3: Componente com acoplamento.

Fonte: Furfaro e Nigro (2009 p.119)

A variante do DEVS denominada Cell-DEVS foi criada para a análise de espaços