55 comentários

• José Geraldo de Sousa Junior(usuário não autenticado)

  10 de Fevereiro de 2011, 17:45

   

  Oi Felipe,
  Eu descrevo abaixo um cenário que pode levar a um questionamento crítico desta situação.
  Considere que a execução da aplicação se encontra num momento T após a seleção do component empty0 e que property turn do noSettings está com valor x.

  No momento T, os dois links são avaliados para determinar sua validade. Neste momento, apenas a condição do primeiro link será avaliada como verdadeira.

  A ação de set executada na interface "_pos0" do component "noSettings" só é executada em um momento T', que obrigatoriamente acontece depois da condição ser avaliada. O início da seleção de empty0 já aconteceu em um momento anterior ao momento atual (T'). Então, no momento T', o segundo link não pode ser avaliado como verdadeiro, visto que neste momento não há seleção do component empty0.
  Por essa razão, na minha opinião, só pode haver reavaliação nas condições dos links após a transição no evento do primeiro bind, que leva a execução da aplicação para um momento T'. Se nesse momento T' houver outra seleção de empty0, aí sim o segundo link é disparado.

  
  

  • Felipe Almeida(usuário não autenticado)

    10 de Fevereiro de 2011, 18:06

     

    > Oi Felipe,

    Olá José Geraldo,
    > Eu descrevo abaixo um cenário que pode levar a um questionamento crítico desta situação.
    > Considere que a execução da aplicação se encontra num momento T após a seleção do component empty0 e que property turn do noSettings está com valor x.

    > No momento T, os dois links são avaliados para determinar sua validade. Neste momento, apenas a condição do primeiro link será avaliada como verdadeira.

    Isso é impossível. Não é possível ter dois eventos "ao mesmo tempo". Somente é possível que eles se sobreponham. Essa premissa é inválida. Necessariamente a avaliação dos dois ocorrerá em momentos diferentes (se sobrepondo ou não), é fisicamente impossível.

    > A ação de set executada na interface "_pos0" do component "noSettings" só é executada em um momento T', que obrigatoriamente acontece depois da condição ser avaliada. O início da seleção de empty0 já aconteceu em um momento anterior ao momento atual (T'). Então, no momento T', o segundo link não pode ser avaliado como verdadeiro, visto que neste momento não há seleção do component empty0.

    Dado que as duas avaliações não ocorreram no momento T, essa implicação necessita de maior substanciação, já que ela não implica mais que ocorrerá após as duas necessariamente.

    > Por essa razão, na minha opinião, só pode haver reavaliação nas condições dos links após a transição no evento do primeiro bind, que leva a execução da aplicação para um momento T'. Se nesse momento T' houver outra seleção de empty0, aí sim o segundo link é disparado.

     Gostaria de compreender o que a linguagem NCL especifica, se especifica. Se a mesma não especifica, então talvez essa seja uma discussão importante para o Guia de Operações.

    Obrigado,

    --

    Felipe Magno de Almeida

    
    

    • Roberto Azevedo(usuário não autenticado)

      10 de Fevereiro de 2011, 20:49

       

      Oi Geraldo e Felipe,a discussao está muito boa... Vou colocar um pouco o *MEU PONTO DE VISTA*... > > No momento T, os dois links são avaliados para determinar sua validade. Neste momento, apenas a condição do primeiro link será avaliada como verdadeira.> Isso é impossível. Não é possível ter dois eventos "ao mesmo tempo". Somente é possível que eles se sobreponham. Essa premissa é inválida. Necessariamente a avaliação dos dois ocorrerá em momentos diferentes (se sobrepondo ou não), é fisicamente impossível.Concordo que seja impossível ter dois eventos acontecendo "ao mesmo tempo" (pelo menos em um sistema que tenha um só processador).  Por outro lado, é possivel simular facilmente esse comportamento discretizando o tempo em que são realizadas os testes de condicoes e acoes resultantes. Deixe eu ser mais claro.Imaginem que temos dois testes (em elos diferentes) sobre uma variável X, que tem seu valor inicial 0. Testes esses que resultam em açôes de atribuiçâo também sobre essa variável. Por exemplo,:elo1="se x < 1 entao x = 2" e elo2="se x = 2 entao x = 3"Vamos analisar, primeiro sem discretizar o tempo: Em um único passo de avaliaçâo é facil perceber que se avaliarmos o elo1 antes do elo2 teremos como resultado final x=3. Por outro lado, se avaliarmos o elo2 antes do elo1 o resultado, depois desse unico passo de avaliaçâo, é x=2. Neste cenário, dizer que todos os elos sâo avaliados "ao mesmo tempo", entâo é uma grande inconsistencia, já que X assume dois valores "ao mesmo tempo" (X=0 e X=2). Disparando dois elos "ao mesmo tempo"...O que fazer entao para que X nao assuma dois valores "ao mesmo tempo" ?PARA MIM: isso é possivel discretizando o tempo em que sao feitas as avaliacoes de condicoes e acoes resultantes. O fato é que para testar todos os elos "ao mesmo tempo" as acoes só podem ser executadas depois que todos os elos forem avaliados (evitando que X possua diferentes valores em um mesmo passo de avaliação). Voltando ao nosso exemplo, se eu quero testar o elo1 e o elo2 "ao mesmo tempo", independente da ordem em que eu teste o valor de X ele deverá ter sempre o mesmo valor. No nosso primeiro passo de avaliaçâo, assim, independente da ordem em que eu teste elo1 e elo2, X será sempre 0. Somente depois de testar todos os elos é que eu posso entao executar as ações. Nesse exemplo atribuir x=2 (já que o elo2 nao será avaliado como verdadeiro). Segue-se entao um NOVO passo de avaliação...Se o Guia Operacional ou a Norma especificarem que a avaliacao deva acontecer ao mesmo tempo, eu acredito que esta segunda abordagem seja a mais correta. Caso não especifique nada, *ACREDITO* que ambas sejam verdadeiras (e no primeiro caso, as duas ordens de avaliacao sejam validas), deixando-se então para o próprio autor da aplicação NCL sincronizar, talvez por meio de variáveis, as ações de seus elos.Espero ter ajudado... 

      
      

      • Felipe Almeida(usuário não autenticado)

        10 de Fevereiro de 2011, 21:44

         

        > Oi Geraldo e Felipe,

        > a discussao está muito boa... Vou colocar um pouco o *MEU PONTO DE VISTA*...

        Olá Roberto,

        > > > No momento T, os dois links são avaliados para determinar sua validade. Neste momento, apenas a condição do primeiro link será avaliada como verdadeira.

        > > Isso é impossível. Não é possível ter dois eventos "ao mesmo tempo". Somente é possível que eles se sobreponham. Essa premissa é inválida. Necessariamente a avaliação dos dois ocorrerá em momentos diferentes (se sobrepondo ou não), é fisicamente impossível.

        > Concordo que seja impossível ter dois eventos acontecendo "ao mesmo tempo" (pelo menos em um sistema que tenha um só processador).

         Na verdade o que eu quis dizer é que não existe a ocorrência de dois eventos instantâneos no tempo que se possa dizer como ocorrendo "ao mesmo tempo". É como duas barras de ferro que tem o mesmo tamanho, sendo ainda pior no caso do tempo pois não existe (até onde conhecemos) uma "partícula minima de tempo" que tornaria a medição discreta ao invés de contínua. Dois eventos não instantâneos podem se sobrepor no mesmo tempo (overlap), mas o início e término dos dois nunca serão exatamente os mesmos. De qualquer forma, filosofar não vai resolver nosso problema. :)

        > Por outro lado, é possivel simular facilmente esse comportamento discretizando o tempo em que são realizadas os testes de condicoes e acoes resultantes. Deixe eu ser mais claro.

        > Imaginem que temos dois testes (em elos diferentes) sobre uma variável X, que tem seu valor inicial 0. Testes esses que resultam em açôes de atribuiçâo também sobre essa variável. Por exemplo,:

        > elo1="se x < 1 entao x = 2" e elo2="se x = 2 entao x = 3"

        > Vamos analisar, primeiro sem discretizar o tempo: 

        > Em um único passo de avaliaçâo é facil perceber que se avaliarmos o elo1 antes do elo2 teremos como resultado final x=3. Por outro lado, se avaliarmos o elo2 antes do elo1 o resultado, depois desse unico passo de avaliaçâo, é x=2. Neste cenário, dizer que todos os elos sâo avaliados "ao mesmo tempo", entâo é uma grande inconsistencia, já que X assume dois valores "ao mesmo tempo" (X=0 e X=2). Disparando dois elos "ao mesmo tempo"...

        > O que fazer entao para que X nao assuma dois valores "ao mesmo tempo" ?

        Não encontrei nada na norma nem no guia que implica que a avaliação de todas as condições devem ocorrer "ao mesmo tempo" conceitualmente (na prática já definimos que é impossível). Esse acaba também sendo um problema apenas específico de uma flexibilidade maior. Define-se na linguagem, até onde compreendi, os requisitos para que dadas notificações sejam disparadas e então define-se dada as condições como cada link deve se comportar e como cada condição deve ser considerada verdadeira. Porém, não encontrei em nenhum lugar sobre uma ordem entre cada uma dessas coisas.

        Por exemplo,

        Alguém clica no controle a tecla de ativação. Esse clique gera a execução de apenas um link. Enquanto esse link está sendo já executado (sua avaliação já terminou) alguém clica outro botão. Qual deve ser a ordem visível para o usuário? Deve a avaliação ocorrer antes, depois ou durante?

        E o outro caso é exatamente o que aparece o problema. Qual a ordem entre condições diferentes de uma mesma notificação?

        E se um link gerar novas notificações automaticamente? E assim por diante...

        Acho que o problema é que consideramos que se um bind é feito sobre uma transição, que essa avaliação é feita ao mesmo tempo com todos os outros correspondentes. Mas isso não me parece óbvio lendo a norma e guia operacional. Quer ver outro exemplo inclusive? Como se comporta se houver um delay? E se esse delay for muito pequeno? Ou então grande suficiente para que o efeito colateral tenha ocorrido?

        > PARA MIM: isso é possivel discretizando o tempo em que sao feitas as avaliacoes de condicoes e acoes resultantes. O fato é que para testar todos os elos "ao mesmo tempo" as acoes só podem ser executadas depois que todos os elos forem avaliados (evitando que X possua diferentes valores em um mesmo passo de avaliação).

        > Voltando ao nosso exemplo, se eu quero testar o elo1 e o elo2 "ao mesmo tempo", independente da ordem em que eu teste o valor de X ele deverá ter sempre o mesmo valor. No nosso primeiro passo de avaliaçâo, assim, independente da ordem em que eu teste elo1 e elo2, X será sempre 0. Somente depois de testar todos os elos é que eu posso entao executar as ações. Nesse exemplo atribuir x=2 (já que o elo2 nao será avaliado como verdadeiro). Segue-se entao um NOVO passo de avaliação...

        De fato essa é uma solução. Inclusive não é difícil de implementar para o meu formatador. Queria dar uma olhada no código da implementação de referência para provar ou desprovar uma desconfiança de que essa ordem não está implementada  de forma garantida na implementação de referência. Se não me engano quando uma avaliação é dada como verdadeira é criada uma thread para execução da ação correspondente. Isso não garante uma ordem com relação as próximas condições para o mesmo evento. (Mas não consegui acesso ao código ainda então não posso afirmar se é ou não assim).

        > Se o Guia Operacional ou a Norma especificarem que a avaliacao deva acontecer ao mesmo tempo, eu acredito que esta segunda abordagem seja a mais correta. Caso não especifique nada, *ACREDITO* que ambas sejam verdadeiras (e no primeiro caso, as duas ordens de avaliacao sejam validas), deixando-se então para o próprio autor da aplicação NCL sincronizar, talvez por meio de variáveis, as ações de seus elos.

        Eu não encontrei, mas é bem possível que eu não tenha visto. Estou aqui neste fórum exatamente querendo saber se alguém conseguiu descobrir algo a respeito.

        Talvez uma simples modificação informando que um assessment *deve* corresponder a avaliação do estado no momento da notificação. Porém vejo problemas com isso também, pois uma ação pode estar ocorrendo *durante a transição* e também seria necessário especificar *quando* uma notificação ocorre com relação aos outros efeitos colaterais ao estado do formatador.

        Também, tentei imaginar uma forma de programar em NCL que impedisse esse comportamento mesmo deixando essa questão em aberto e não encontrei até agora. Se usarmos uma variável para sincronização ainda não conseguiremos pois ela tem que necessariamente ser modificada pela ação e servir de proteção ao mesmo tempo, como dessa forma a avaliação  e execução de um link não ocorre necessariamente de forma atomica isso não me parece possível.

        > Espero ter ajudado...

         Obrigado Roberto,

         

        PS: Desculpe pelo tamanho da mensagem.

        --

        Felipe Magno de Almeida

        
        

        • Felipe Almeida(usuário não autenticado)

          23 de Fevereiro de 2011, 16:22

           

          Olá,

          Estou criando um artigo sobre o problema e desenvolvendo uma solução para o mesmo.

          soft​ware​publ​ico.​gov.​br/d​otlr​n/fi​le-s​tora​ge/v​iew/​dotl​rn_f​s_27​0018​79_r​oot_​fold​er/d​otlr​n_fs​_270​0187​9_sh​ared​_fol​der/​depe​nden​cy%2​epdf

          Está ainda no começo, vou atualizando aos poucos.

          Obrigado,

          --

          Felipe Magno de Almeida