Hector é uma ferramenta para desenvolvedores de modelos interessados em utilizar uma abordagem de modelagem para Dinâmica de Sistemas baseada em um metamodelo com estilo orientado a objetos.
A principal motivação para a abordagem proposta é o desenvolvimento de modelos com base em conceitos de alto nível de abstração, mais próximos ao domínio do modelo do que os construtores tradicionais da Dinâmica de Sistemas (stocks, rates, and flows). Estes construtores tradicionais são bastante flexíveis, porém, por causa do baixo nível de abstração, diversas equações devem ser elaboradas para descrever completamente o comportamento de um elemento do mundo real.
Na abordagem proposta, um metamodelo descreve conceitos de alto nível, representando seus comportamentos por meio de equações estendidas da Dinâmica de Sistemas. Um conceito do metamodelo é chamado de classe (class). Cada classe é uma representação computacional de um elemento do mundo real no modelo. Desta forma, ao modelar uma sala de aula, diferentes classes representam os alunos, o professor, as cadeiras, o quadro negro e assim por diante.
Além do comportamento de cada elemento, o metamodelo descreve propriedades que caracterizam cada elemento. Uma propriedade é uma informação que é relevante sobre um elemento no contexto de um modelo. Desfa forma, uma propriedade por descrever a idade de um aluno, se esta informação for relevante para o modelo. Uma outra propriedade pode descrever o número de anos que um professor ministrou uma disicplina em particular.
Finalmente, o metamodelo descreve os relacionamentos entre os elementos do modelo. Desta forma, um aluno aprende de um professor, um professor escreve num quadro negro, e assim por diante. Relacionamentos entre elementos podem ser úteis para configurar o comportamento do modelo, modificando o comportamento de um elemento em função de seus relacionamentos estruturais com outros elementos do modelo.
O metamodelo representa um domínio, uma área de conhecimento sobre a qual diversos modelos distintos podem ser construídos. Cada modelo é proveniente de um metamodelo, indicando os elementos de interesse para o problema em particular sendo modelado e seus relacionamentos. Um modelo é chamado de instância (instance).
Cada instância de elemento em um modelo deve ser relacionada com uma classe do metamodelo. Em um modelo, podemos dizer que Maria é uma aluna e que João é um professor. Além disso, o modelo indica as relações entre as instâncias dos elementos. Desta forma, pode haver diversas instâncias para a classe Professor, mas um relacionamento torna claro que João é professor de Maria (as demais instâncias de professores podem representar professores de outros alunos).
Observe que nenhuma nova classe ou relacionamento são criadas em um modelo: o modelo apenas cria instâncias de classes do metamodelo e especializa os relacionamentos definidos no metamodelo.
Exemplo de Modelagem
Para auxiliar a apresentação da linguagem de modelagem, utilizaremos um modelo simples. O modelo se assemelha a uma banheira com fontes e ralos. A banheira é descrita por um nível d'água, que varia ao longo do tempo por causa das suas fontes e ralos. Fontes oferecem mais água enquanto ralos retiram a água da banheira. Fontes e ralos são descritos por meio de taxas de crescimento ou diminuição.
No metamodelo, a banheira, cada fonte e cada ralo são modelados por classes separadas. No modelo a seguir (construido a partir do metamodelo da banheira), temos uma única banheira com duas fontes e dois ralos. Note que um desenvolvedor de modelos pode adicionar ou remover fontes e ralos do modelo sem escrever nenhuma nova equação tradicional da Dinâmica de Sistemas.
MODEL BathtubModel
{
CLASS Bathtub
{
PROPERTY InitialLevel 100;
STOCK Level InitialLevel;
};
CLASS Sourcer
{
PROPERTY BaseGrowth 10;
RATE (SourceTub.Level) GrowthRT BaseGrowth;
};
CLASS Sinker
{
PROPERTY BaseSinker 10;
RATE (SinkerTub.Level) SinkRT -BaseSinker;
};
RELATION SourceTub Sourcer, Bathtub;
RELATION SinkerTub Sinker, Bathtub;
};
DEFINE MyBathtub BathtubModel
{
Bathtub = NEW Bathtub
Sourcer1 = NEW Sourcer
LINK SourceTub BathTub;
Sourcer2 = NEW Sourcer
SET BaseGrowth = 2;
LINK SourceTub BathTub;
Sinker1 = NEW Sinker
SET BaseSinker = 5;
LINK SinkerTub BathTub;
Sinker2 = NEW Sinker
SET BaseSinker = 3;
LINK SinkerTub BathTub;
};
|
As seções a seguir detalham a sintaxe da representação do modelo e do metamodelo.
Declaração do Metamodelo
O metamodelo é definido pela palavra-chave MODEL, que é seguida pelo nome do metamodelo. Ao definir um modelo, este deve ser referente a um único metamodelo. O nome do metamodelo é utilizado para identificar o metamodelo ao qual um modelo se refere.
MODEL BathtubModel
{
...
};
|
A definição de metamodelo é delimitada por um par de chaves. Dentro delas, classes e relacionamentos são declarados.
Declaração de Classe
Uma classe é definida pela palavra-chave CLASS, que é seguida pelo nome da classe. O nome da classe é utilizado para identificar a classe associada a uma instância de modelo. Um metamodelo não pode ter duas ou mais classes com o mesmo nome.
CLASS Bathtub
{
...
};
|
Como o metamodelo, uma classe é também delimitada por um par de chaves. A definição de uma classe contém declarações de propriedades e comportamentos.
Declaração de Propriedade
Uma declaração de propriedade é definida pela palavra-chave PROPERTY, que é seguida pelo nome da propriedade e seu valor inicial. Uma classe não pode ter duas ou mais propriedades com o mesmo nome. O nome da propriedade é utilizado em declarações de instância para identificar uma propriedade que não assume seu valor padrão para a instância corrente.
PROPERTY InitialLevel 100;
|
Geralmente, propriedades são os primeiros elementos na definição de classes. Elas são também os primeiros elementos em uma definição de instância. Toda instância de modelo receberá as propriedades definidas paa suas classes. O valor de cada propriedade pode ser modificado para cada instância no modelo. Se a propriedade é suprimida durante a declaração de instância, assume-se que para aquela instância ela terá o valor padrão.
Declaração de Comportamento
A descrição de comportamentos de uma classe utiliza construtores tradicionais da Dinâmica de Sistemas, isto é, stocks, rates, processes, e tables. A sintaxe de descrição de equações de comportamento é similar àquela utilizada na ferramenta Illium.
STOCK Level InitialLevel;
...
RATE (SourceTub.Level) GrowthRT BaseGrowth;
...
RATE (SinkerTub.Level) SinkRT -BaseSinker;
|
Apesar da descrição de sintaxe da Hector ser similar a da Illium, existem algumas diferenças. Primeiramente, taxas (rates) não têm repositórios de fontes e sumidouros, mas se referem a um único repositório, cujo nível sempre aumenta. Assim, se a taxa visa esvaziar um repositório, sua equação deve resultar em um valor negativo. Adicionalmente, um único repositório é apresentado entre parênteses após a palavra-chave RATE.
RATE (Level) TestRate -1;
|
Um repositório associado a uma taxa pode ser declarado em uma outra classe além daquela que contém a taxa. Neste caso, a classe que declara a taxa deve ter um relacionamento com a classe que contém o repositório (veja próxima seção). O repositório afetado pela taxa é declarado por meio do nome de um relacionamento, um operador ponto e o nome do repositório.
RATE (SourceTub.Level) GrowthRT BaseGrowth;
|
Taxas podem também lidar com multi-relacionamentos, isto é, relacionamentos em que diversas instâncias de uma classe são associadas a (possivelmente) uma outra classe. Se uma taxa se refere a um repositório por meio de uma taxa múltipla, é chamada de multirate. Uma taxa múltipla é uma taxa que, apesar de declarada uma única vez no metamodelo, pode afetar diferentes repositórios, dependendo do número de instâncias associadas a ela por meio dos seus relacionamentos.
Operadores específicos tratam de multi-relacionamentos. O operador COUNT recebe um multi-relacionamento como seu único parâmetro, retornando o número de instâncias associadas com a instância atual por meio deste relacionamento. O exemplo de linha de produção utiliza operadores de multi-relacionamentos.
PROC WorkCount COUNT (Working);
|
O operador GROUPSUM recebe dois parâmetros. O primeiro é um multi-relacionamento e o segundo uma equação de comportamento (process, stock, ou rate) da classe destino do relacionamento. O operador retorna a soma da equação de comportamento selecionado para as instâncias associadas a instância atual por meio do relacionamento. O exemplo da linha de produção utiliza o operador GROUPSUM.
RATE (ProducedItems) RTProduction GROUPSUM (Working, Productivity);
|
Os operadores GROUPMAX e GROUPMIN funcionam da mesma maneira, retornando, respectivamente, o valor máximo e mínimo para o comportamento selecionado das instâncias associadas.
Declaração de Relacionamentos
Relacionamentos podem ser unitários ou múltiplos. Relacionamentos unitários relacionam uma instância de classe com uma outra instância de classe, apenas. Relacionamentos múltiplos relacionam uma instância de classe a diversas instâncias de outra classe. Relacionamentos são geralmente declarados após as declarações de classe. Um relacionamento unitário é declarado por meio da palavra-chave RELATION, que é seguida pelo nome do relacionamento e sua classe destino. Uma vírgula separa as classes origem e destino.
RELATION SourceTub Sourcer, Bathtub;
|
No exemplo anterior, temos um relacionamento unidirecional, isto é, a instância de origem conhece sua instância de destino, mas a instância destino não tem visibilidade sobre a instância de origem. A visibilidade para uma instância associada permite a uma instância afetar ou consultar o comportamento da classe destino. Isto é feito por meio do relacionamento em taxas, operadores de grupo e com o operador ponto.
CLASS Sourcer
{
PROPERTY BaseGrowth 10;
RATE (SourceTub.Level) GrowthRT BaseGrowth;
};
|
Relacionamentos múltiplos são descritos por meio da palavra-chave MULTIRELATION. O exemplo de linha de produção contém relacionamentos múltiplos. A declaração segue a mesma sintaxe dos relacionamentos simples.
MULTIRELATION Working Factory, Worker;
|
Declaração de Modelo
Um modelo é geralmente definido após a definição do metamodelo. A palavra-chave DEFINE inicia uma definição de modelo que é seguida pelo nome do modelo e pelo nome do metamodelo a que o modelo se refere. O modelo é delimitado por um par de chaves, que contém as declarações de instâncias.
DEFINE MyBathtub BathtubModel
{
...
};
|
Declaração de Instância
Uma instância marca a ocorrência de uma classe no modelo. Enquanto um carro pode ser uma classe, descrevendo a informação necessária para caracterizar um carro e seu comportamento, um determinado Chevrolet Cavalier é uma instância, assim como um Audi é outra instância e assim por diante.
A definição de instância mais simples é descrita pelo nome da instância, um operador de atribuição, a palavra-chave NEW, e o nome de uma classe do metamodelo. Este comando cria uma instância da classe com todas as propriedades assumindo seus valores padrão e sem relacionamentos com outras instâncias.
Bathtub = NEW Bathtub
|
Se uma propriedade deve assumir um valor diferente do padrão, isto pode ser feito após a criação da instância. A palavra-chave SET especifica um valor para uma propriedade na instância atual. No exemplo a seguir, a propriedade BaseGrowth da fonte Sourcer2, cujo valor padrão é 10, é modificado para 2.
Sourcer2 = NEW Sourcer
SET BaseGrowth = 2;
|
Finalmente, uma instância pode ser associada a outras instâncias. Relacionamentos a nível de classe foram definidos no metamodelo, mas, na medida em que instâncias são criadas, seus elos com outras instâncias devem ser estabelecidos. A palavra-chave LINK permite a definição de relacionamentos entre instâncias, seguida pelo nome do relacionamento, como definido no metamodelo, e as instâncias associadas.
Sourcer1 = NEW Sourcer
LINK SourceTub BathTub;
|
Se mais de uma instância é associada a instância atual por meio de um relacionamento, vírgulas separam seus nomes.
MyFactory = NEW Factory
LINK Working Worker1, Worker2, Worker3, Worker4;
|
Geração de Código
Um ponto forte da abordagem do Hector é que ela é uma extensão à Dinâmica de Sistemas. Desta forma, as descrições de metamodelo e modelo podem ser traduzidos para equações tradicionais da Dinâmica de Sistemas. Um compilador é encarregado deste trabalho, gerando equações da Dinâmica de Sistemas a partir das descrições de metamodelo e modelo. O compilador está embutido na ferramenta Hector. Abaixo, as equações geradas para o exemplo da banheira.
# Simulation step
SPEC DT 1.0000;
# Code for object "Bathtub"
PROC Bathtub_InitialLevel 100.0000;
STOCK Bathtub_Level Bathtub_InitialLevel;
# Code for object "Sourcer1"
PROC Sourcer1_BaseGrowth 10.0000;
RATE (SOURCE, BathTub_Level) Sourcer1_GrowthRT1 Sourcer1_BaseGrowth;
# Code for object "Sourcer2"
PROC Sourcer2_BaseGrowth 2.0000;
RATE (SOURCE, BathTub_Level) Sourcer2_GrowthRT1 Sourcer2_BaseGrowth;
# Code for object "Sinker1"
PROC Sinker1_BaseSinker 5.0000;
RATE (SOURCE, BathTub_Level) Sinker1_SinkRT1 -Sinker1_BaseSinker;
# Code for object "Sinker2"
PROC Sinker2_BaseSinker 3.0000;
RATE (SOURCE, BathTub_Level) Sinker2_SinkRT1 -Sinker2_BaseSinker;
|
Este modelo pode ser simulado pela ferramenta Illium. Observe que o código gerado para cada instância declarada no modelo. Taxas declaradas para as fontes e ralos acessam o único repositório declarado para a banheira. Processos foram declarados para propriedades de instâncias e cada instância tem seu próprio processo para cada propriedade individual.
O exemplo da banheira, utilizado ao longo deste documento, é um modelo muito simples. Vamos considerar agora que cadaclasse no modelo é composta de mais de vinte equações, cada classe também está associada com três ou mais classes e que o modelo tem dez ou mais instâncias de cada classe... o modelo em Dinâmica de Sistemas iria crescer muito mais complexo do que a representação em modelo e metamodelo.
Considere a demanda por mudança de um relacionamento entre duas instâncias... diversas equações da Dinâmica de Sistemas teriam que ser modificadas, uma operação custosa que aumenta as chances de erros serem introduzidos no modelo. Entretanto, na representação de modelo e metamodelo, uma simples linha teria que ser modificada e o modelo recompilado: uma operação bem mais simples. Finalmente, a representação em metamodelo é mais fácil de ler, compreender e modificar.
Estas são as principais vantagens da representação em modelo e metamodelo proposta em Hecto. Desejamos que elas possam auxiliar no desenvolvimento de modelos da Dinâmica de Sistemas em que os elementos devam ser descritos em detalhes e proporcionem relacionamentos claros entre eles.
Interface com o Usuário
Hector é uma ferramenta bem simples, composta de duas janelas principais, em que modelos são editados e seus resultados são analisados. Apesar de se basear em uma representação textual de modelos, a ferramenta é fácil de utilizar. Acreditamos que uma interface gráfica com o usuário, em que classes do metamodelo sejam representadas por itens gráficos em um diagrama, poderiam ajudar desenvolvedores de modelos. Entretanto, por causa de limitações de recursos, uma interface com usuário melhor não está em desenvolvimento atualmente. Esperamos tê-la algum dia.
Apenas análises simples podem ser feitas no Hector. Entretanto, a ferramenta é capaz de gerar uma versão do modelo em Dinâmica de Sistemas, compatível com a ferramenta Illium que pode ser utilizada para análises posteriores.
A figura a seguir apresenta a janela principal do Hector. Esta janela é composta de quatro seções: barra de menu, barra de ferramentas, editor de modelos e quadro de mensagens.
A barra de menu contém quatro menus. O menu Arquivo (File) contém comandos para criação de novos modelos, abertura de modelos de arquivos, e salvamento de modelos para arquivos. O menu Edição (Edit) contém comandos básicos de editor, tais como busca de texto e comandos de clipboard. O menu Análises (Analysis) contém um comando para compilar um metamodelo para equações em Dinâmica de Sistemas e um comando para plotar um gráfico para uma variável particular ao longo do tempo. Finalmente, o menu Opções (Options) contém alguns comandos de configuração.
O modelo é editado na parte central da janela. O painel inferior apresenta mensagens do compilador, quando um ou mais erros são encontrados no processo de compilação.
No menu de Análise, o compando de compilação gera um arquivo chamado sd.txt, que contém equações da Dinâmica de Sistemas que são utilizadas para simular o metamodelo. O metamodelo, por sua vez, nunca é diretamente simulado: ele é totalmente traduzido para equações da Dinâmica de Sistemas, que são simuladas.
O comando de simulação no menu de Análise abre uma nova janela que permite ao usuário selecionar uma das instâncias do modelo e um dos seus comportamentos. Quando o usuário pressiona o botão de calcular no lado direito da janela, um gráfico apresenta o comportamento da variável selecionada ao longo do tempo. A aba de dados no painel inferior da janela exibe os valores para o comportamento sendo simulado.
