Willingness to Pay for Access

O ambiente irá realizar as ações através dos métodos colocados à disposição pelas classes pertencentes à tabela de classes do ambiente, enquanto que o SCSP irá realizá-lo através dos métodos colocados à disposição pelas classes da tabela de classes do SCSP.

Para cada ação, necessitamos definir qual parte do ambiente e qual parte do SCSP participam da ação, bem como seus papéis. Os papéis são diferenciados entre aquele que solicita a ação (em linguagem natural, o sujeito da ação) e aquele que recebe a solicitação da ação (em linguagem natural, objeto indireto da oração). Passamos a identificar estes papéis pela prática que adotamos de colocá-lo ao lado esquerdo, iniciando a oração com um sujeito, ao passo que a outra classe (sofre a ação) é colocada à direita na oração. As duas classes serão diferenciadas do restante das palavras pelo uso do negrito em seus nomes.

Precisamos inicialmente distinguir quais classes desempenham papel de ambiente do ponto de vista da especificação de uma classe particular do SCSP, correspondente a uma determinada partição. Ao definir a especificação de uma classe do SCSP, tanto o ambiente prévio ao SCSP como todas outras classes do SCSP são considerados externos à classe especificada. Portanto, ao especificar uma classe do SCSP, podemos empregar outras classes do SCSP nos papéis complementares das ações em que participa uma classe do SCSP em especificação.

Utilizando o caso simplificado deste capítulo para exemplificar, quando estivermos modelando a partição do controle de recursos de transformação (CNT_REC_TRANSF), serão considerados como parte do ambiente:

• as classes do ambiente que fazem fronteira com o SCSP, que são REC_TRANSF e PLAN_PROD e

• todas outras classes do SCSP que não a classe modelada, que é CNT_PROC.RECX. Toda ação descrita ao longo do caso de uso equivale a um evento, o qual estabelece implicitamente uma respectiva condição (pós-condição do evento). No entanto, conforme o papel da classe modelada na ação (solicita ou recebe a solicitação da ação), o evento mencionado pode ou não constituir um método desta classe; onde a classe do SCSP solicita a ação, o método definido pela ação é pertinente à outra classe, e a condição alterada não é relativa ao da classe solicitante. Portanto, não constitui um evento relativo à modelagem da classe em questão, e sim ao ambiente.

Dentro do caso simplificado, suponhamos que estamos modelando a classe CNT_REC_TRANSF. Para a modelagem desta classe, a seguinte ação é exemplo da situação do parágrafo anterior:

Neste exemplo, a classe CNT_REC_TRANSF solicita o método LiberaProducao para a classe CNT_PROC.RECX. Desta forma, o método é pertencente a uma classe do ambiente (do ponto de vista de CNT_REC_TRANSF), e sua condição não é alterada (o evento é pertinente à classe do ambiente cujo método foi invocado).

Por outro lado, quando o papel da classe modelada do SCSP é de receber a solicitação da ação, o evento constitui um método da própria classe, alterando sua condição. Nesta segunda situação, a pós-condição é, também implicitamente, uma pré-condição para o evento seguinte no qual a classe recebe solicitação de uma ação.

Dentro do mesmo caso simplificado, continuaremos a modelagem da classe CNT_REC_TRANSF. Nesta segunda situação, a seguinte ação é exemplo:

• CNT_PROC.RECX SolicitaAlocaçao a CNT_REC_TRANSF.

Neste exemplo, a classe CNT_PROC.RECX solicita o método SolicitaAlocaçao para a classe CNT_REC_TRANSF. Desta forma, o método é pertencente à classe modelada, e então sua condição é alterada e o evento em questão lhe é pertinente, em atendimento ao método invocado.

A tabela 6.3 relaciona as posições das classes dentro das ações de um caso de uso em função do controle da ação realizado pelo ambiente ou pelo SCSP (capítulo 5), através de suas classes.

Nas ações onde a classe do SCSP modelada invoca um método de outra classe, não existe alteração da condição dentro da respectiva partição do SCSP. O que existe é a solicitação de método de uma classe externa. Analisando os elementos disponíveis no E-MFG com comunicadores, identificamos nesta situação a interface de envio, onde a condição não é alterada e é utilizada uma mensagem solicitando método externo.

Utilizando o caso simplificado do capítulo, na especificação da classe CNT_REC_TRANSF, a ação ‘CNT_REC_TRANSF LiberaProducao a CNT_PROC.RECX’ é convertida em interface de envio.

Tabela 6.3. Posição das classes dentro das ações do caso de uso

Papel na ação Posição na ação de classe do ambiente (tabela de

classes do ambiente)

Posição na ação da classe do SCSP (tabela de

classes do SCSP) Ambiente controla ação não

compartilhada com SCSP Esquerda, Direita (**) - Ambiente controla ação

compartilhada com SCSP

Esquerda Direita

Classe do SCSP controla ação

compartilhada com ambiente Direita Esquerda

Classe do SCSP controla ação compartilhada com outra classe

do SCSP

- Esquerda, Direita (*)

(**) duas classes distintas do ambiente (*) duas classes distintas do SCSP

Por outro lado, nas ações onde a classe do SCSP modelada é invocada através de um método por outra classe, existe alteração da condição da partição respectiva do SCSP, e o evento é pertencente à classe em questão. Analisando os elementos disponíveis no E-MFG com comunicadores, identificamos nesta situação a interface de recepção, onde a condição é alterada.

Ainda utilizando o caso simplificado do capítulo, na especificação da classe CNT_REC_TRANSF, a ação ‘CNT_PROC.RECX SolicitaAlocaçao a CNT_REC_TRANSF’ é convertida em interface de envio.

A conversão da ação em elementos sintáticos do E-MFG é diferenciada em função da identificação de um dos dois tipos de eventos (ações) através da posição da classe modelada do SCSP na ação:

• quando à direita da ação, o evento é pertinente ao seu contexto e origina um par formado pela transição e respectiva pós-condição e

• quando à esquerda da ação, o evento é externo ao seu contexto e origina uma interface de envio, a qual é conectada a condição presente.

Figura 6.3. Exemplo da conversão do fluxo de eventos de caso de uso em modelo E-MFG com comunicadores

Na figura 6.3, encontramos em exemplo com três ações que permite identificar as duas situações acima, convertendo as ações do caso de uso nos respectivos elementos sintáticos do E-MFG com comunicadores, onde uma classe relativa a uma partição de um SCSP considerado neste exemplo é a classe modelada (controlador do magazine).

Fluxo de eventos:

1. Unidade produtora 1 envia produto ao magazine

2. Magazine informa produto ao ambiente.

3. Unidade produtora 2 recebe produto do magazine Recebe1 MFG Caso de uso Seqüência implícita do caso de uso Seqüência implícita do caso de uso OBJ2.x Recebe2