XXX ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO

Maturidade e desafios da Engenharia de Produção: competitividade das empresas, condições de trabalho, meio ambiente.
São Carlos, SP, Brasil, 12 a15 de outubro de 2010.

ESPECIFICAÇÃO DO MODELO
CONCEITUAL EM SIMULAÇÃO DE
EVENTOS DISCRETOS: APLICAÇÃO
EM UM CASO REAL
Wilson Inacio Pereira (EEM-IMT)
wilson@maua.br
Leonardo Chwif (POLI-USP)
leochwif@usp.br

Apesar de ser uma das etapas mais importantes do processo de

modelagem em Simulação de Eventos Discretos, a etapa de modelagem
conceitual não é tratada com a devida importância, tanto na literatura
existente como em projetos práticos. O ressultado da modelagem
conceitual pode ser expresso , entre várias maneiras, por meio de um
documento denominado “Especificação do Modelo Conceitual”. O
presente trabalho pretende descrever o conteúdo deste documento e
exemplificar sua criação através de um projeto real de consultoria
realizado por um dos autores.

Palavras-chaves: Modelagem Conceitual, Simulação de Eventos

Discretos, Especificação de Modelo de Simulação
1. Introdução
A Simulação de Eventos discretos é uma importante ferramenta de análise aplicável a
diversos tipos de sistemas, como serviços públicos de saúde, sistemas de manufatura, centrais
de atendimento, sistemas logísticos e muitos outros (Banks, Carson e Nelson 1996). Para que
um estudo de simulação seja bem sucedido é necessário aplicar a metodologia de simulação
corretamente. De uma maneira geral, o processo de simulação pode ser dividido em três fases:
concepção, implementação e análise (Chwif e Medina, 2007). A Figura 1 ilustra estas etapas.

Figura 1 – Fases de um Estudo de Simulação (Fonte: Adaptado de Chwif e Medina, 2007)

De acordo com Harrel e Tumay (1995), aproximadamente 40% do tempo gasto em um estudo
de simulação deve ser dedicado à modelagem conceitual (incluindo-se coleta de dados), 20%
à implementação e 40% à verificação, validação e análise. No entanto, na prática, esta
porcentagem não se verifica: Wang e Brooks (2007a) avaliaram a realização de estudos de
simulação com estudantes divididos em duas categorias: principiantes e especialistas. O grupo
de “principiantes” era formado por estudantes de graduação, enquanto o grupo de
“especialistas” era formado por estudantes de pós-graduação, com alguma experiência em
simulação. Para ambos os grupos foi atribuída uma tarefa de conduzir um estudo completo de
simulação, baseada em casos reais. Observou-se que, desconsiderando a fase de coleta de
dados, o grupo principiante dedicou cerca de 12% do tempo total do estudo à fase de
modelagem conceitual (estruturação do problema e confecção do modelo conceitual),
enquanto o grupo de “especialistas” dedicou, em média, 36% do tempo total do estudo a estas
atividades (ou seja, 3 vezes mais do que o primeiro grupo). Este resultado indica que, em
geral, quanto mais experiência o modelador possuir, mais importância será dada ao processo
de construção do modelo conceitual.
De acordo com Robinson (2006), a modelagem conceitual em Simulação de Eventos
Discretos é um tema pouco explorado na literatura e necessita de maiores investigações.

2
Segundo Law (1991), trata-se da etapa mais difícil e menos explorada dentro do processo de
simulação. Robinson (2006) afirma, ainda, que a visão geral dos modeladores é que a
modelagem conceitual é mais “arte” do que “ciência” e, portanto, os livros de simulação
dedicam poucas páginas a este tema tão importante, quando o fazem. Um modelo conceitual
bem feito certamente levará a um bom modelo computacional, o que, conseqüentemente,
gerará um modelo operacional apropriado (ou seja, um modelo pronto para realizar
experimentos – vide Figura 1). Por outro lado, a inexistência de um modelo conceitual, ou a
utilização de um modelo mal elaborado, provavelmente levará a um modelo computacional
que poderá exigir muitos retrabalhos e/ou que não seja capaz de capturar os objetivos da
simulação.
Como este tema (modelagem conceitual) ainda é pouco explorado na literatura, não há uma
definição consagrada e totalmente aceita a seu respeito, existindo, até mesmo, definições
contraditórias (Chwif, Pereira e Barretto 2009). Algumas dessas definições podem ser
encontradas em Nance (2004), Briot e Meurrisse (2006), Fishwick (1995), Robinson (2004),
Law (2008), Pace (1999) e Lacy et al. (2001). Apesar das divergências existentes, é possível
estabelecer dois pontos em comum:
 O modelo conceitual é um dos primeiros produtos do processo de simulação;
 O modelo conceitual é independente da linguagem de simulação ou do simulador que irá
ser utilizado na fase de implementação.

Assim, neste trabalho, o modelo conceitual será definido como sendo “o resultado do
processo de modelagem/abstração, gerando uma representação independente do software.
Em outras palavras é a representação do modelo abstrato (modelo que está na nossa cabeça)
em uma forma explícita. Uma forma mais completa de se expressar o modelo conceitual é por
meio de um documento chamado "Especificação da Modelagem Conceitual". É importante
ressaltar que o modelo conceitual pode, e deve, ser alterado e revisado continuamente à
medida que o estudo de simulação se desenrola. O documento “Especificação da Modelagem
Conceitual”, citado na definição anterior, será discutido na próxima seção.
2. Especificação da Modelagem Conceitual
Diversas técnicas e métodos de representação de modelos conceituais são discutidos na
literatura. Heavey e Ryan (2006) classificaram estes métodos em métodos formais e métodos
descritivos. Segundo os autores, dentre os métodos formais pode-se citar as Redes de Petri,
DEVS (Discrete Event System Specification), State Charts, Activity Cycle Diagrams (ACD),
dentre outras. Chwif (1999) comparou diversas técnicas de representação em relação a vários
critérios (entendimento e uso, representação explícita dos objetivos da simulação e se possui
ou não representação gráfica), identificando o ACD como uma das mais intuitivas e simples
de se utilizar. Quanto aos métodos descritivos, pode-se citar o IDEF0 (Integrated Definition
for Function Modeling), RAD (Role Activity Diagrams) e o Diagrama de Estados e de
atividades da UML. Montevechi et al. (2008) propuseram um método que utiliza
conjuntamente três técnicas de representação de modelos conceituais: o IDEF0, Sipoc
(Suppliers Inputs Process Outputs Customer) e o fluxograma. Apesar de todos estes métodos
disponíveis, foi demonstrado por Wang e Brooks (2007b) que a técnica de representação de
modelo conceitual mais utilizada é o fluxograma e, em alguns casos, descrições textuais.
A proposta do presente trabalho consiste em uma documentação mais ampla do que uma
descrição gráfica, ou mesmo textual, de um modelo de simulação, onde serão descritos
diversos aspectos desta fase (modelagem conceitual). Este documento pode ser dividido em 4

3
partes, a saber:
 Parte I: Descrição do “OCER”, que é um acrônimo para Objetivos, Complexidade,
Entradas/Saídas e Rodadas.
 Parte II: Descrição do Processo, incluindo as Hipóteses Simplificadoras do Modelo.
 Parte III: Descrição do Memorial de Dados
 Parte IV: Grade de Revisões e Anexos.

2. 1. Parte I: Definição do OCER

A seguir, serão explicitados os itens que compõe a parte I do documento de especificação.
a) Objetivos. Neste item, os objetivos do estudo devem ser definidos claramente.
Geralmente os objetivos são: a identificação de problemas (gargalos, filas excessivas,
baixa produtividade, nível de serviço inadequado etc) ou a verificação do atendimento de
metas de produtividade ou níveis de serviço, seja em expansões de sistemas existentes ou
em projetos de sistemas novos. É importante notar que o desenvolvimento de um modelo
de simulação nunca é um objetivo final do estudo. Outro detalhe importante é que o
objetivo é sempre pontual. Um exemplo de objetivo pode ser: “Definir o número de
atendentes de uma central de atendimento, de modo a atender os clientes com um nível de
serviço 90/20 (90% dos clientes sendo atendidos em menos de 20 segundos)”.
b) Complexidade. Neste item, define-se o escopo do modelo e o seu nível de detalhe. O
escopo define a abrangência do estudo. Exemplo de definição de escopo: “O modelo
abrangerá as etapas de fabricação, esmaltação e montagem do processo produtivo,
desconsiderando os processos de recebimento e expedição”. A definição do nível de
detalhe é um pouco mais sutil e especifica o grau de profundidade do modelo. Exemplo:
“O modelo considerará as máquinas do processo de fabricação, levando em conta apenas
o tempo total de processamento nas máquinas”. A presença de animação gráfica também
representa um item importante no detalhamento do modelo. Exemplo: “A animação da
movimentação das pontes rolantes não será mostrada em detalhe”.
c) Entradas/Saídas. Entradas são informações que alimentam o simulador. Idealmente, este
item deve ser complementado por um “memorial de dados de entrada”, identificando o
dado. Exemplo: “Dado de entrada 1: tempo entre chegadas sucessivas de clientes”. Pode-
se ainda descrever o status da coleta/processamento dos dados de campo. Se os dados
ainda não foram coletados e/ou processados, deve-se informar que estes deverão ser
coletados em campo e que será feito, posteriormente, um tratamento dos dados (por
exemplo, um ajuste de curvas). De fato, não é preciso coletar nenhum dado para que a
versão inicial do documento de especificação fique pronta. Por outro lado, se os dados já
tiverem sido coletados, tanto melhor! Em alguns casos, a própria coleta de dados pode
modificar a especificação do modelo conceitual. Por exemplo, um processo de duração
muito pequena poderá ser desprezado no modelo computacional, por não afetar
significativamente as medidas de desempenho. Por fim, as saídas são definidas em função
das medidas de desempenho de interesse. Exemplos: produtividade da fábrica, tempo
médio de espera em fila, taxa de utilização dos operadores etc.
d) Definições de rodadas. Neste item, serão definidos os cenários a serem simulados e,
quando aplicáveis, definições de planejamento experimental ou otimização. Um cenário é
um conjunto fixo de dados de entrada. Exemplos de definições de cenários: “Serão
consideradas 5 configurações de layout para a simulação” ou “Serão considerados 3
condições de fluxo de clientes: situação de calma, normalidade e pico”. Em alguns tipos
de modelos, pode-se adotar procedimentos de planejamento experimental (D.O.E.). Neste

4
 caso, deve-se definir quais serão os fatores, as respostas e o tipo de planejamento a ser
adotado (por exemplo, planejamento 2k). Se o estudo necessitar de simulação-otimização,
deverão ser definidas as variáveis de decisão adequadas, bem como a função objetivo. Por
fim, as definições do regime de simulação (simulação em regime ou simulação terminal) e
o tempo de simulação também devem ser colocados neste item do documento.

2. 2. Parte II: Definição do Processo e Hipóteses

Há várias formas de se ilustrar a definição do processo. Uma destas formas consiste em
utilizar uma técnica de representação de modelos descritas no início da sessão 2, como por
exemplo, o ACD ou o IDEF0. Como, infelizmente, muitos modeladores não conhecem tais
técnicas, pode-se, alternativamente, definir o processo por meio de um fluxograma de
processo ou um layout esquemático. Mesmo contando com uma representação gráfica do
processo, o ideal é que este item do documento contenha um texto descrevendo toda a
seqüência do processo.
Esta parte do documento deve conter, ainda, uma lista de Hipóteses Simplificadores do
Modelo. Uma hipótese é uma premissa, uma suposição que se assume verdadeira. Exemplo:
“Como o fluxo da máquina 1 para a máquina 4 é muito baixo, adotar-se-á que a máquina 1 irá
enviar produtos somente para as máquinas 2 e 3”. As hipóteses, geralmente, levam a
simplificações do modelo, o que faz com que alguns analistas inexperientes as confundam
com características de operação sistema em análise. Por exemplo, a sentença “A máquina 1
alimentará as máquinas 2, 3 ou 4”, apenas descreve parte do funcionamento de um sistema,
não podendo ser entendida como uma hipótese.
Existe uma forte correlação entre a definição das hipóteses e o nível de detalhe do modelo.
Por exemplo, a hipótese “Não haverá absenteísmo dos operadores” ajuda a corroborar uma
simplificação como: “Somente o modo de falha principal da máquina será levado em
consideração, através dos dados MTBF (Mean Time Between Failure) e MTTR (Mean Time
to Repair). Supõe-se que os outros modos de falha da máquina, que incluem a falta de
operador, ocorrerão raramente”.
2. 3. Parte III: Descrição do Memorial de Dados de Entrada
Como comentado anteriormente, esta parte descreve os dados de entrada do modelo,
incluindo dados fixos (como número de operadores, número de equipamentos de transporte
etc) e a modelagem das variáveis aleatórias envolvidas. Este trecho do documento pode, e
deve, ser atualizado à medida que o processo de coleta e análise dos dados está sendo
realizado. Inicialmente, servirá de “guia” para a coleta de dados de campo.
2. 4. Parte IV: Grade de Revisões e Anexos
Como um documento vivo que só é “congelado” ao fim do estudo de simulação, a
especificação conceitual deve possuir uma grade de revisões contendo o número da revisão e
a pessoa (ou pessoas) que a fez. É interessante também indicar se a revisão foi submetida ao
grupo do projeto de simulação e foi aprovada.
Esta documentação permite adicionar como anexos quaisquer informações adicionais
relevantes ao estudo, como representações do processo utilizando técnicas diferentes das
anteriores, documentos técnicos, atas de reuniões, enfim, tudo que o analista considere
importante para o estudo de simulação.
3. Exemplo de aplicação
A proposta de documentação feita neste trabalho será exemplificada pelo estudo de um

5
processo de recebimento, fabricação e expedição de uma indústria de fabricação de material
granulado plástico (polipropileno), fruto de um projeto de consultoria realizado por um dos
autores. O escopo do processo envolve o processo de recebimento de 7 tipos de matéria-
prima, a granel ou em big-bags, o processo de manufatura e a embalagem final (em pacotes
big-bags ou de 25 kg), envolvendo os seguintes equipamentos: 7 silos externos, 3 linhas de
manufatura com 3 silos internos cada, 1 extrusora e 3 silos finais. Além disso, há 2 máquinas
de empacotamento manual, 3 equipamentos de homogeneização e 1 linha automática para o
empacotamento dos sacos de 25 kg. Por questões de sigilo, parte das informações do caso real
foi omitida. Cada parte da especificação foi colocada em uma tabela para facilitar a
visualização das informações.
A Tabela 1 especifica a definição do OCER. A Tabela 2 ilustra a descrição do processo e as
hipóteses do modelo. O diagrama de descrição do processo mostrado na Tabela 2 poderia ser
colocado, opcionalmente, nos anexos do documento de especificação. A descrição completa
do processo em linguagem natural não será colocada neste trabalho por questões de espaço.
A Tabela 3 mostra uma descrição parcial do memorial de dados de entrada. Novamente, por
questões de espaço, foram representados apenas alguns dos dados de entrada - a especificação
completa possui cerca de 15 conjuntos de dados de entrada. Na especificação mostrada na
Tabela 3, foram definidos os dados e os seus valores. Na etapa inicial de uma especificação
real, quando ainda não há dados coletados, é possível citar somente o significado do dado de
entrada e, posteriormente, incluir seu valor. Finalmente, a Tabela 4 define a grade de revisões.
No caso mostrado na Tabela 4, foram gerados 4 documentos de revisão, descrevendo revisões
em que dados foram inseridos e informações foram corrigidas. Isto mostra que, como
comentado anteriormente, esta especificação é um documento “vivo”, que pode ser alterado
até a conclusão final do projeto - obviamente é desejável que o documento seja “congelado”
logo antes da implementação do modelo computacional.

Definição do OCER Descrição

Objetivos  Identificar os gargalos e restrições na planta como um todo, em
conseqüência da implementação da terceira linha de produção;
 Identificar a capacidade produtiva do novo layout;
 Recomendar ações de melhoria para viabilizar a operação, considerando
atingir a produção esperada.
Complexidade Escopo: Desde o recebimento de matéria-prima (polipropileno - PP) passando
pelos silos externos, transporte pneumático até os silos de armazenagem,
processo de extrusão com classificação, processo de homogeneização e
processo de embalagem (big-bags ou sacos de 25 kg).
Detalhe: Não se entrará em detalhe dos processos de extrusão e separação de
carga mineral.
Entradas e Saídas do Entradas:
Modelo  Previsão de consumo mensal de cada tipo de matéria-prima (PP);
 Composição da frota de caminhões (porcentagem de cada tipo possível);
 Tempo de descarga dos caminhões;
 Capacidade dos silos externos para cada tipo de matéria-prima;
 Mix de produção (porcentagem de cada família);
 Velocidade da linha de alimentação dos silos externos;
 Tempo de set-up de cada linha;
 Tempo de extrusão e classificação de cada produto;
 Tempo de parada para análise;
 Tempo de homogeneização;
 Tempo de ciclo de ensacamento;
 Mix de embalagens (tipo de embalagem de saída).

6
 Saídas:
Recebimento:
 Tempo médio e máximo de espera dos caminhões para descarga;
 Taxa de utilização da moega;
 Níveis (mínimos, médios e máximos) dos silos externos.
Alimentação:
 Utilização da linha de alimentação (possível gargalo);
 Níveis (mínimos, médios e máximos) dos silos de armazenagem.
Extrusão:
 Utilização das extrusoras.
Homogeneização:
 Utilização dos homogeneizadores.
Embalagem:
 Utilização das ensacadeiras;
 Utilização da linha de embalagem de sacos de 25 kg.
Geral:
 Produtividade geral da fábrica;
 Produção mensal total de cada família;
 Produção mensal total de cada tipo de embalagem.
Rodadas A simulação será feita em regime permanente e será considerado um tempo de
warm-up previamente calculado. Serão simulados quatro cenários:

 Cenário 1: 100% de alimentação de PP em big-bags e 100% de

ensacamento de produto acabado em big-bags;
 Cenário 2: 100% de alimentação de PP em big-bags e 100% de
ensacamento de produto acabado em sacos de 25 kg;
 Cenário 3: 100% de alimentação de PP a granel e 100% de ensacamento
de produto acabado em big-bags;
 Cenário 4: 100% de alimentação de PP a granel e 100% de ensacamento
de produto acabado em sacos de 25 kg.
Tabela 1 – Definição do OCER para a especificação do modelo

Processo e Hipóteses Descrição

7
Processo

Hipóteses  Cada caminhão transporta apenas um tipo de matéria-prima;

 Cada caminhão será carregado em sua capacidade máxima (carga fechada);
 Somente um caminhão (granel ou big-bag) poderá descarregar por vez;
 O fluxo de caminhões com carga mineral será desprezado;
 O tamanho de cada lote de produção é fixo;
 O início da produção de cada campanha ocorrerá somente quando houver
um silo vazio de produto final na linha X;
 O tempo de formulação da mistura de carga mineral será embutido no tempo
de set-up das linhas;
 O tempo de set-up de cada linha será dado pelo valor máximo entre o tempo
de enchimento dos 3 silos pulmão e o tempo de limpeza da linha;
 Perdas de materiais devido à classificação serão consideradas desprezíveis;
 O tempo de homogeneização será considerado constante, independente da
quantidade exigida na ordem de fabricação e família do produto;
 A linha de embalagem receberá material diretamente dos silos de produto
final e o tempo de transferência será considerado desprezível.
Tabela 2 – Definição do processo e hipóteses

Dados de Entrada
Dado 5: Mix de produção
Família Percentual (%)
1 7%
2 40%
3 26%
4 15%
5 11%
6 1%

8
 Dado 11: Tempo de paradas para análise
Cada ordem de produção terá um tempo de parada de linha associado, definido por uma
distribuição triangular: menor valor = 200, valor mais provável = 350 e maior valor = 550
(valores em minutos).

Dado 12: Tempo de homogeneização

Será considerado um tempo de homogeneização constante = 20 horas.
Tabela 3 – Definição dos dados de entrada

Quando Nº da revisão O Quê Quem

30/01/07 Revisão 4 Modificação do documento João
incluindo mudança de dados
referente ao fluxo de caminhões
24/01/07 Revisão 3 Modificação do documento João, a partir de e-mail
incluindo alteração de alguns recebido de Antônio
dados recebidos
18/01/07 Revisão 2 Modificação do documento João
incluindo dados recebidos
12/01/07 Revisão 1 Modificação do documento com João
base na reunião realizada
08/01/07 Revisão 0 Criação do documento João
Tabela 4 – Exemplo de grade de revisões

Embora ilustre apenas uma parte do que foi feito no projeto real, este exemplo permite que se
tenha uma idéia das informações principais contidas no documento de especificação
conceitual, cuja finalidade é auxiliar o analista a definir o modelo computacional antes da sua
implementação. Na próxima seção serão discutidos alguns aspectos vantajosos de se construir
um documento deste tipo.

4. Comentários e discussões
Apesar da construção e manutenção deste documento demandar um tempo adicional no
processo de modelagem, existem inúmeras vantagens em se criá-lo:
a) Este documento pode permitir a subcontratação de uma pessoa que desenvolverá o
modelo computacional. Sem este documento, não é possível informar de forma adequada
para uma terceira pessoa como o modelo deverá ser construído.
b) Este documento pode ser validado com o cliente em uma, ou mais, reuniões de validação
conceitual. De fato, de acordo com Law (2008), o processo de leitura passo a passo do
modelo conceitual para os “Stakeholders” (processo chamado pelo autor de “Walk-
through”) e a troca idéias são ações importantíssimas.
c) O analista estará mais “resguardado” caso o cliente reclame posteriormente do modelo
operacional. Por exemplo, se o escopo do modelo que foi acordado entre o cliente e o
analista mudar e o cliente não estiver satisfeito com o modelo computacional por este
motivo, o analista poderá recorrer à especificação original do modelo conceitual. Por isso,
a cada revisão, é importante gerar um documento que confirme que o cliente concorda
com o que foi escrito. De preferência, o cliente deve participar da reunião de “Walk-
through” da especificação.

9
d) É mais fácil corrigir erros na especificação do modelo do que no modelo computacional.
Como as informações da especificação estão “no papel”, é mais fácil alterá-las do que
mudar uma lógica de programação ou elementos do modelo. Com isso, mesmo sendo
gasto um tempo adicional na criação da especificação inicial, ganha-se tempo no estudo
de simulação, pois o modelo computacional tende a apresentar menos erros.
e) Trata-se de um documento formal do processo de modelagem, que pode ser resgatado
futuramente para uma simples verificação ou mesmo para um processo de pós-auditoria,
caso ocorra algum problema no estudo de simulação.
f) O documento de especificação pode ser utilizado como base para uma métrica de
dimensionamento do esforço de implementação, em termos do número de horas que
deverão ser gastas na implementação do modelo computacional. Embora ainda que
preliminarmente, um dos autores está trabalhando em um modelo para gerar tal
estimativa.

Para o caso da fábrica de material granulado, 90% do documento foi aprovado após a reunião
de “leitura” (criação da revisão 1 - vide tabela 4). Obviamente, alguns ajustes foram
necessários até que o documento atingisse a forma final (revisão 4). A partir daí, a
implementação se baseou integralmente no documento de especificação, gerando o modelo no
software Simul8 ilustrado na Figura 2.

Figura 2 – Implementação do modelo computacional no software Simul8

Após a implementação e geração dos resultados experimentais, o desenvolvimento do projeto

ocorreu de forma praticamente linear, sem as idas e vindas que geralmente ocorrem em
projetos sem uma especificação sólida. Logo, para este caso os pontos b) e d) descritos
anteriormente se aplicaram de maneira integral. O sucesso e entrega deste projeto no prazo
combinado pode, em grande, parte ser atribuído a uma correta especificação do modelo. Outra

10
questão relevante é que, no momento da implementação, todas as informações necessárias ao
modelo estavam disponíveis, evitando atrasos no projeto por falta de informações.
5. Conclusões e recomendações para trabalhos futuros
O presente artigo discutiu a fase de construção do modelo conceitual em simulação, que
apesar da sua importância é deixada de lado por muitos analistas. Foram discutidas as
definições existentes de modelo conceitual e proposto um documento denominado
“Especificação do Modelo Conceitual”. A seguir, este documento foi exemplificado por meio
de um projeto real de consultoria realizado por um dos autores. Vale ressaltar que, embora a
confecção desta documentação demande um tempo razoável, há um ganho de tempo
significativo nas fases subseqüentes do projeto de simulação, já que os retrabalhos são
evitados e/ou minimizados.
Face ao exposto, pode-se concluir que a construção do modelo conceitual, especialmente para
casos complexos, não reverte apenas em ganho em tempo com eliminações de retrabalhos e
melhoria no alinhamento de conceitos, mas é fundamental para o sucesso da implementação
do modelo computacional.
A proposta deste documento está sendo aprimorada continuamente e, para trabalhos futuros,
pretende-se desenvolver uma metodologia que permita utilizar o documento de especificação
conceitual para estimar o tempo necessário para as etapas de implementação e análise do
modelo computacional.

Referências
BANKS, J.; CARSON, J.S. & NELSON, B.L. Discrete-Event System Simulation, 2nd ed. Upper Sadle River,
NJ: Prentice-Hall, 1996.
BRIOT, J.-P. & MEURISSE, T. A Component-based Model of Agent Behaviors for Multi-Agent-based
Simulations, 7th International Workshop on Multi-Agent-Based Simulation (MABS’06), Antunes L., Takadama
K. (ed), 5th International Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS’2006),
Hakodate, Japan, p. 183-190, mai 2006.
CHWIF, L. & MEDINA, A.C. Modelagem e Simulação de Eventos Discretos: Teoria e Aplicações, 2ª Ed.
Bravarte, 2007, p. 12.
CHWIF, L. Redução de Modelos de Simulação de Eventos Discretos na sua Concepção: Uma Abordagem
Causal, Tese de Doutorado. Escola Politécnica da USP. Departamento de Engenharia Mecânica, 1999.
CHWIF, L.; PEREIRA, W.I.; BARRETTO, M.R.P. Uma Proposta de Padronização para a Especificação do
Modelo Conceitual em Simulação de Eventos Discretos. IV Simpósio de Engenharia de Produção do Nordeste -
SEPRONe, 2009.
FISHWICK, P.A. Simulation Model Design and Execution: Building Digital Words. Prentice-Hall, Upper
Saddle River, N.J. 1995.
HARREL, C. & TUMAY, C. Simulation Made Easy – a Manager´s Guide, Norcross, Georgia, USA: Industrial
Engineering and Management Press, 1995.
HEAVEY, C. & RYAN, J. Process Modelling Support for the conceptual Modelling phase of a Simulation
Project, Proceedings of the 2006 Winter Simulation Conference, p. 801-808, 2006.
LACY, L.W.; RANDOLPH, W..; HARRIS, B.; YOUNGBLOOD, S.; SHEEHAN, J.; MIGHT, R. &
METZ, M. Developing a Consensus Perspective on Conceptual Models for Simulation Systems. Proceedings of
the 2001 Spring Simulation Interoperability Workshop, 2001.
LAW, A. M. Simulation Model´s Level of Detail Determines Effectiveness. Industrial Engineering, vol 23, n.10,
p. 16-18, 1991.

11
LAW, A. M. How to Build Valid and Credible Simulation Models. Proceedings of the 2006 Winter Simulation
Conference, p. 39-47, 2008.
MONTEVECCHI, et al. Combined use of Modeling Techniques for the Development of the Conceptual Model
in Simulation Projects. Proceedings of the 2008 Winter Simulation Conference, p. 987-995, 2008.
NANCE, R.E. The Conical Methodology and the Evolution of Simulation Model Development. Annals of
Operations Research, v. 53, p. 1-45, 1994.
PACE, D.K. Development and Documentation of a Simulation Conceptual Model. Proceedings of the 1999 Fall
Simulation Interoperability Workshop, 1999. Disponível em: <http:// www.sisostds.org> Acesso em: 12 abr.
2010.
ROBINSON, S. Conceptual Modeling for Simulation: Issues and Research and Requirements. Proceedings of
the 2006 Winter Simulation Conference, p. 792-800, 2006.
ROBINSON, S. Simulation: The Practice of Model Development and Use. Wiley, Chichester, U.K., 2004.
WANG, W. & BROOKS, R.J. Improving the Understanding of Conceptual Model. Journal of Simulation, v. 1,
n. 3 , p. 153-158, 2007a.
WANG, W. & BROOKS, R.J. Empirical Investigations of Conceptual Modeling and the Modeling Process.
Proceedings of the Winter Simulation Conference, p. 1601-1609, 2007b.

12