Introdução
Num ambiente de desenvolvimento de software com qualidade, uma das facetas de relevância é o controle das modificações que sofre um produto de software ao longo de seu ciclo de vida, tanto durante o desenvolvimento como na fase de manutenção. Para lidar com isto de forma controlada, preconiza-se definir um processo de controle de modificações, também chamado processo de controle de configuração, para garantir que mudanças no software sejam feitas de maneira racional e gerenciável. Este processo é parte de uma disciplina mais geral denominada Gerência de Configuração de Software (GCS).
Este exemplo de utilização do SNTool modela um processo de controle de modificação de forma que o modelo resultante possa servir para simulações de diferentes aspectos do processo.
O Processo de Modificação
Uma empresa de desenvolvimento de software possui um setor de manutenção dedicado exclusivamente à evolução de seu produto de software principal (talvez único). No processo estabelecido no setor, no que importa à modelagem, identificam-se 6 papéis executados pelos seus integrantes:
Responsável pela Gerência de Configuração de Software (RGCS):
Indivíduo responsável por toda a operação do processo e também pela aprovação de alguns tipos de modificações propostas.
Proponente de mudança:
Indivíduo que possui o direito de solicitar ou propor modificações no produto de software. Também é chamado Originador.
Comitê de Controle de Modificações (CCM):
Grupo de pessoas que detém a autoridade máxima de decisão sobre as modificações propostas.
Analista de viabilidade:
Indivíduo que recebe a incumbência de analisar uma modificação proposta e emitir um parecer técnico identificando sua abrangência e impacto no produto e também estimar esforço e prazo necessário. Também é chamado Elaborador de PTM.
Implementador:
Elemento da organização de desenvolvimento que é responsável pela implementação de uma modificação aprovada.
Verificador:
elemento da organização de desenvolvimento que é responsável pela verificação da implementação de uma modificação aprovada, buscando determinar se a implementação cumpriu os objetivos da modificação e que não causou efeitos colaterais indesejáveis.
Para o encaminhamento do processo, são utilizados um conjunto de formulários ou documentos, que são gerados e utilizados pelas pessoas executando os diferentes papéis, e que visam registrar as informações, provendo uma base para a organização racional do processo. Os documentos são os seguintes:
Proposta de Modificação (PM): formulário que captura a modificação proposta.
Parecer Técnico de Modificação (PTM): documento em que um analista de viabilidade registra seu parecer.
Ordem de Modificação (OM): documento que é gerado a partir de uma PM ou conjunto de PMs quando uma modificação é aprovada, e que contém informações orientando a implementação da modificação.
Descrição de Modificação (DM): formulário preparado pelo implementador relatando as modificações efetivamente realizadas.
Parecer de Verificação de Modificação (PVM): documento elaborado pelo verificador com parecer sobre a implementação realizada da modificação.
Com base nestes elementos, define-se o processo da seguinte maneira:
PMs são geradas por originadores e encaminhadas ao RGCS. Este analisa o preenchimento de cada PM, devolvendo ao originador se estiver incorreta e aceitando se corretamente preenchida.
O RGCS envia, então, a PM a um analista de viabilidade para uma análise da modificação proposta. Terminada a análise, o analista gera um PTM e o encaminha juntamente com a PM ao RGCS.
O RGCS, recebendo os documentos, em primeiro lugar anexa o PTM à PM e com base neles toma uma de três decisões: a) rejeita a modificação proposta, por considerá-la inadequada ou inoportuna; c) considera não ter a autoridade suficiente e a encaminha para o órgão superior, o CCM; ou c) aprova a modificação.
Se rejeitar a modificação, a PM é encaminhada para o arquivo de PMs rejeitadas. Se decidir pelo encaminhamento ao CCM, a PM é colocada na Agenda do CCM para ser analisada, juntamente com outras na mesma situação, na próxima reunião do CCM. Se aprovar a implementação, o RGCS gera uma OM, anexa a ela a PM e passa a aguardar o momento oportuno para enviar a OM para implementação.
Antes de se continuar a descrição do processo, é oportuno neste momento comentarem-se algumas características peculiares a ele. Uma OM, como já observado anteriormente, contém várias informações que orientam a implementação. Entre elas têm-se a indicação do implementador que será o responsável e a relação dos elementos do produto de software, i. e, documentos, arquivos-fonte, etc., que são denominados, no jargão de GCS, itens de configuração (ICs), que serão modificados. Por outro lado, este processo de modificação permite que duas ou mais modificações sejam realizadas simultaneamente, desde que não possuam ICs em comum a serem modificados. Assim, uma condição fundamental para uma OM poder se enviada para implementação é que todos os seus ICs estejam "livres", isto é, não estejam sendo modificados por outra OM. Outra condição fundamental é que o implementador esteja "desocupado", isto é, não esteja realizando a implementação de outra OM.
Retomando a descrição, uma OM, após ser gerada, fica aguardando o momento em que as condições para poder ser encaminhada para implementação estejam satisfeitas. Quando isto ocorrer, o RGCS encaminha a OM ao implementador designado. O implementador, por sua vez, ao concluir seu trabalho, gera uma DM, descrevendo as modificações realizadas e a encaminha, juntamente com a OM, ao RGCS.
Em seguida, o RGCS, anexa a DM à OM e coloca o conjunto à espera da oportunidade de ser avaliada por um verificador. Neste processo, ainda que seja possível paralelismo durante a implementação, a verificação de modificações é totalmente serializada, isto é, em cada instante apenas uma verificação pode estar andamento.
Ocorrendo as condições necessárias para a modificação entrar em verificação, o RGCS encaminha a OM ao verificador designado. O verificador, por sua vez, ao concluir seu trabalho prepara o PVM e o encaminha junto com a OM ao RGCS. O parecer do verificador indica uma de duas possibilidades: aprova a implementação da modificação, ou a reprova. O RGCS, então, recebendo o PVM, verifica qual foi o parecer: se o verificador aprovou a implementação, a modificação é incorporada definitivamente ao produto, os ICs são liberados, o implementador fica "desocupado" e a OM é encaminhada para o arquivo de OMs implementadas; se a modificação foi reprovada o RGCS a encaminha imediatamente de volta ao implementador para retrabalho. Note-se que durante a verificação tanto os ICs como o implementador continuam ligados à OM, sendo liberados apenas ao término da implementação.
O modelo de Rede de Agentes Semiônicos
A modelagem do processo compõem-se de um conjunto de objetos representando os formulários que transitam em sua execução, por um conjunto de sêmions que representam os indivíduos e seus papéis, por um conjunto de lugares que representam os postos de trabalho dos indivíduos ou, então, repositórios e áreas de espera para os formulários, e, por fim, por um conjunto de arcos orientados que representam os encaminhamentos dos formulários. As atividades do CCM não foram consideradas no modelo.
Para a modelagem das situações de decisão, definiu-se serem elas simuladas como escolhas não determinísticas com probabilidades bem definidas. Para isto, fez-se a importação para o modelo da classe java.util.Random.
Definiram-se as classes PM, PTM, OM, DM e PVM para os objetos representando os documentos do processo, e as classes Originador, RGCS, ElaboradorPTM, Implementador e Verificador para os sêmions representando o pessoal envolvido.
Descrevem-se a seguir os sêmion, com ênfase nas suas funções.
A classe Originador possui duas funções:
geraPM
: gera um objeto PM simbolizando o envio de uma nova proposta de modificação ao RGCS.wait
: não faz nada, apenas consome "tempo"
As funções de avaliação destas funções garantem que suas indicações de ativação (bid) sejam mutuamente excludentes de forma a garantir um ciclo de: a) definição de tempo de espera, b) realização de espera e c) geração de PM. A definição do tempo de espera foi concebida para permitir a incorporação na modelagem da imprevisibilidade do momento em que uma modificação é proposta. Para controlar está característica, a classe possui 2 estados internos, tmin e tmax, que definem o intervalo de tempo dentro do qual é escolhido aleatóriamente o tempo para a geração da próxima PM. O tempo é medido em número de iterações do simulador. Para facilitar a configuração destes valores, a função init da classe possui as constantes TMIN e TMAX que definem os valores destes estados. Estabelecendo-se valores iguais para tmin e tmin define-se uma taxa fixa de geração de PMs.
A Classe ElaboradorPTM possui três funções de transformação:
pegaPM
: absorve uma PM encaminhada ao sêmion e estabelece um tempo para simular a elaboração do PTM.elaboraPTM
: não faz nada, apenas consume o tempo de elaboraçãogeraPTM
: gera objeto PTM simbolizando o parecer e encaminha o PTM e a PM, previamente absorvida, ao RGCS.
As funções de avaliação destas funções garantem que suas indicações de ativação (bid) sejam mutuamente excludentes de forma a garantir um ciclo de: a) obtenção de PM e definição de tempo de elaboração de parecer, b) elaboração de parecer e c) geração de PTM. Da mesma maneira que na classe Originador, esta classe também define os estados internos tmin e tmax para permitir tanto a flexibilidade de configuração como para realizar a modelagem da imprevisibilidade. Adicionalmente, a classe foi concebida de forma a se associar um identificador único a cada instância para permitir que se possa simular a remessa de PMs para um elaborador de PTMs específico.
A Classe Implementador possui três funções de transformação:
pegaOM
: absorve uma OM encaminhada ao sêmion e estabelece um tempo para simular a implementação.implementaOM
: não faz nada, apenas consume o tempo definido, simulando a implementação.geraDM
: gera objeto DM e encaminha a DM e a OM, previamente absorvida, e ao RGCS.
As funções de avaliação correspondentes garantem que as indicações de ativação (bid) sejam mutuamente excludentes de forma a garantir um ciclo de: a) obtenção de OM e definição do tempo de implementação, b) realização da implementação e c) geração de DM. Como nas classes anteriores, definem-se também os estados internos tmin e tmax para permitir a flexibilidade de configuração e a modelagem da imprevisibilidade. Também como no caso de outras classes, esta classe foi concebida de forma a cada instância possuir um identificador único para que se possa a simular a remessa de OMs para um implementador específico.
A Classe Verificador, de maneira muito similar à classe implementador, possui três funções de transformação:
pegaOM
: absorve uma OM encaminhada ao sêmion e estabelece um tempo para simular a verificação.verificaOM
: não faz nada, apenas consume o tempo definido, simulando a verificação.geraPVM
: gera objeto PVM e encaminha o PVM e a OM, previamente absorvida, ao RGCS.
As funções de avaliação correspondentes garantem que as indicações de ativação (bid) sejam mutuamente excludentes de forma a garantir um ciclo de: a) obtenção de OM e definição do tempo de verificação, b) realização da verificação e c) geração de PVM. Como nas classes anteriores, definem-se também os estados internos tmin e tmax para permitir a flexibilidade de configuração e a modelagem da imprevisibilidade. Adicionalmente, o resultado do parecer emitido é escolhido de maneira não determinística com 70% de probabilidade de a modificação ser aprovada e 30% de ser reprovada.
A classe RGCS possui 11 funções de transformação:
aceitaPM
: pega PM encaminhada por originador, numerando-a, e coloca em área para posterior encaminhamento para elaboração de PTM.recusaPM
: pega PM encaminhada por originador e a devolve, simulando preenchimento incorreto.solicPTM
: encaminha PM para elaborador de PTM, bloqueando-o para outras elaborações.rejeitaPM
: encaminha PM para o arquivo de PMs rejeitadas, liberando elaborador de PTM.encImpl
: efetua o encaminhamento de PM aprovada: gera OM, define ICs que serão modificados, determina o implementador da modificação e coloca a OM no estado de espera por modificação para posterior encaminhamento ao implementador.encCCM
: encaminha PM para a Agenda de CCM.solicImpl
: encaminha OM para implementador realizar o trabalho de implementação, bloqueando tanto os ICs que fazem parte da OM como o implementador.procResImpl
: pega OM e DM encaminhadas por implementador ao final de implementação de OM, anexa DM à OM e coloca OM no estado de espera por verificação para posterior encaminhamento ao verificador.solicVerif
: encaminha OM para o verificador realizar o trabalho de verificação, bloqueando-o.consolidModif
: encaminha OM para arquivo de OMs implementadas e libera todos os recursos bloqueados pela OM: ICs, implementador e verificador.solicReImpl
: encaminha OM para implementador para retrabalho.
As funções de avaliação das funções aceitaPM e recusaPM garantem que as indicações de ativação (bid) sejam mutuamente excludentes e a escolha e uma ou de outra é feita de maneira não determinística com 80% de probabilidade de a PM ser aceita.
A função de avaliação da solicPTM, havendo PM aceita em sua entrada, somente exige para a sua ativação que haja um elaborador de PTM disponível.
As três funções seguintes (rejeitaPM , encImpl, encCCM ) correspondem à decisão de encaminhamento do RGCS após receber o PTM do analista. Assim, suas funções de avaliação garantem que as indicações de ativação sejam mutuamente excludentes e a escolha de qual delas fornecerá o bid é realizada de maneira não determinística com as seguintes probabilidades: 60% para aprovação da PM, 30% para o encaminhamento ao CCM e 10% para a rejeição.
A função solicImpl, para ser elegível para ativação, exige para uma dada OM que esteja em sua entrada, que os ICs a serem modificados pela OM estejam livres e que o implementador destacado esteja disponível.
A função procResImpl não estabelece nenhuma condição, além da existência de OM e DM em suas entradas, para ser elegível para ativação.
A função solicVerif, para ser elegível para ativação, exige, além da existência de OM em sua entrada, que não haja nenhuma verificação em andamento.
As funções consolidModif e solicReImpl correspondem ao encaminhamento do RGCS após receber PVM do verificador e, portanto, são mutuamente excludentes e a escolha indicação de ativação é feita nas funções de avaliação correspondentes com base no resultado do parecer indicado no PVM.
A partir da discussão dos casos de exclusão mútua de ativação comentados nos parágrafos anteriores, não é difícil perceber que se pode agrupar as 11 funções em 7 grupos de forma que em cada iteração do simulador, pode haver simultaneamente até 7 funções elegíveis para ativação, com no máximo uma de cada grupo. Para evitar tanto uma escala de preferências para as funções, que seria artificial demais, quanto a delegação ao algoritmo de escolha subjacente ao simulador, definiu-se um mecanismo que, ao que tudo indica, permite uma distribuição equalitária das ativações. Este mecanismo estabelece um conjunto de 7 valores de bid, variando de 0.4 a 1.0 que são atribuídos ciclicamente a cada função ao longo do tempo. Assim, cada função de avaliação ao fazer uma indicação de ativação não oferece um valor fixo de bid, mas o valor que cabe à função naquele momento. A rotação dos valores de bid é realizada de maneira idêntica em todas as funções de transformação, no final de cada uma delas.
A classe RGCS possui também o controle do número de ICs que compõe o produto de software bem como o controle do número máximo de ICs que podem ser alterados numa modficação. Os estados internos totICs e maxICsOM contêm os valores destas características. Para facilitar a configuração destes valores, a função init da classe possui as constantes TOTICS e MAXICSOM que definem os valores destes estados.
A figura 1 a seguir exibe a rede de agentes semiônicos que compõe o modelo. A rede foi definida como possuindo 1 RGCS, 1 originador de PM, 5 elaboradores de PTM (analistas de viabilidade), 7 implementadores e 1 verificador. Através da função de iniciação da rede pode-se variar facilmente o número de originadores. O número de elaboradores de PTM e implementadores exige também alteração de valores de iniciação da classe RGCS. O RGCS e o verificador são sempre únicos.
Figura 1.
Uma Sessão de Simulação Na seqüência de telas a seguir, mostra-se uma sessão de simulação do modelo. Cada tela corresponde a uma fotografia instantânea da rede semiótica num instante selecionado. Utilizaram-se os seguintes valores para as características parametrizáveis:
Tempo para geração de PM: 5 iterações
(Classe Originador: TMIN
= 5 e TMAX = 5)
Tempo para elaboração de PTM: 1 iteração
(Classe
ElaboradorPTM: TMIN = 1 e TMAX = 1)
Tempo para implementação de OM: 10 iterações
(Classe Implementador: TMIN = 10 e TMAX = 10)
Tempo de verficação de OM: 1 iteração
(Classe Verificador: TMIN =
1 e TMAX = 1)
Número de ICs do produto: 20
(Classe RGCS:
TOTICS = 20)
Número máximo de ICs por OM: 2
(Classe RGCS:
MAXICSOM = 2)
Tela 1: Estado inicial da rede semiótica logo após sua iniciação, antes da 1ª iteração.
Tela 2: Nesta situação, que corresponde à 6ª iteração o originador gera uma PM e a coloca no lugar pmsIniciais para posteriormente ser retirada pelo RGCS.
Tela 3: Em seguida, através da função aceitaPM o RGCS retira a PM do lugar pmsIniciais, estabelece um identificador único para ela e a coloca no lugar pmsAguardPTM para posterior remessa a um elaborador de PTM. Note-se o estado interno lastIDPM, que contabiliza os identificadores de PM fornecidos, que avançou uma unidade em relação à tela anterior. Note-se também o estado interno vetBids que é o vetor dos bids dos grupos de função do RGCS. Comparando-se esta tela com a anterior percebe-se o deslocamento circular dos valores da estrutura que ocorre a cada execução de função do RGCS.
Tela 4: O RGCS então, através da função solicPTM seleciona um elaborador de PTM e encaminha a PM para elaboração de PTM, retirando o formulário do lugar pmsAguardPTM e colocando-no em cxElaboradoresPTM. Note-se o estado interno do RGCS vetElabsPTMLivres que contém o conjunto de elaboradores de PTMs disponíveis. Retirou-se desta estrutura o elemento de número 1, indicando que o elaborador de PTM correspondente está ocupado.
Tela 5: Esta tela corresponde à iteração seguinte à da tela anterior e mostra que o elaborador de PTM, através de sua função pegaPM, retirou a PM que estava na sua caixa de entrada e iniciou elaboração do PTM.
Tela 6: Algumas iterações depois, o elaborador, terminando a elaboração do PTM, através da função geraPTM deposita o PTM gerado no lugar ptmsElaborados e a OM previamente absorvida no lugar pmsUtilElabPTMs, sem modificações.
Tela 7: Esta Tela mostra que foi ativada a função encCCM do RGCS, que pega a PM e o PTM, anexa o PTM à PM e coloca esta última no lugar agendaCCM, simulando a decisão do RGCS de encaminhar a PM ao CCM. Adicionalmente, o elaborador de PTM é liberado, o que é mostrado no estado interno do RGCS vetElabsPTMLivres que recebe de volta o elemento 1, o qual retorna no final da lista para garantir rotatividade dos elaboradores de PTM. Adionalmente, uma nova PM é gerada pelo originador e depositada no lugar pmsIniciais.
Tela 8: Algumas iterações à frente e temos a situação em que o PTM de uma outra PM acaba de ser gerado.
Tela 9: Em seguida, é ativada a função encImpl para a PM, que pega a PM e o PTM depositados pelo elaborador de PTM, anexa o PTM à PM, cria uma OM, identifica-a, anexa a PM a ela, escolhe os ICs que serão modificados pela OM e, por fim, coloca a OM no lugar omsEmEsperaImplem que representa a fila de espera para implementação.
Tela 10: Em seguida, como as condições para a implementação da OM estão satisfeitas, pois há implementador disponível e seus ICs não estão em modificação por outra OM, é ativada a função solicImpl que destaca um implementador, bloqueia os ICs da OM e encaminha a OM para o implementador. Note-se o estado inteno vetEstICs, que registra os IC livres e os bloqueados, que agora está com valor 1 nas posições do vetor correspondentes aos ICs da OM (IC06 e IC17) indicando que estão bloqueados. Note-se também o estado interno vetImplsLivres, que é uma lista representando os implementadores livres, da qual foi retirado o elemento 1, que é o implementador destacado para a OM.
Tela 11: Algumas iterações à frente, e é mostrado que o trabalho do implementador terminou, foi gerada DM e a OM que fora absorvida no início da implementação é devolvida. A tela tabém mostra que durante o período da implementação uma outra PM foi gerada e recusada pelo RGCS, tendo sido depositada no lugar pmsrecusadas.
Tela 12: Na iteração seguinte, é ativada a função procResImpl que pega a OM e a DM gerada pelo implementador, anexa a DM à OM e coloca a OM na fila de espera por verificação, personificada pelo lugar omsEmEsperaVerif.
Tela 13: Em seguida, como o verificador está desocupado, é ativada a função solicVerif que retira a OM da fila de espera e a encaminha para verificação. Note-se o estado interno do RGCS indicVerif que passou a registrar o valor 1 indicando que há uma verificação em andamento.
Tela 14: Três iterações depois, o verificador termina seu trabalho, depositando o PVM gerado no lugar pvmsElaborados e devolvendo a OM absorvida no início da verificação, depositando-a no lugar omsUtilVerif.
Tela 15: Esta tela que corresponde à mesma iteração da tela anterior, mostra o conteúdo do PVM gerado. O estado interno do parecer com o valor 2 indica que o trabalho de implementação foi reprovado, devendo o implementador proceder ao retrabalho.
Tela 16: Esta tela mostra que em conseqüência do parecer emitido, foi ativada a função solicReImpldo RGCS que encaminha a OM de volta ao implementador que deverá proceder ao retrabalho. Observe-se que não há necessidade de a OM passar pela fila de espera por implementação pois tanto os seus ICs como o implementador continuam bloqueados para ela.
Tela 17: Para ilustrar uma conclusão de modificação, esta tela mostra uma outra OM, algumas iterações depois, que acabou de passar pela verificação com PVM favorável como mostra o campo parecer do PVM.
Tela 18: Em conseqüência, é ativada função consolidModif que cuida de liberar todos os recursos bloqueados pela OM, neste caso o IC15 e o implementador 3 e a coloca, com o PVM anexado, no lugar arquivoOMsImplementadas. Comparando-se os campos vetEstIcs e vetImplsLivres do sêmion RGCS exibidos nesta tela com os exibidos na tela anterior, é possível perceber os recursos que foram liberados.
Utilização do Modelo
O modelo de rede de agentes semiônicos pode ser utilizado para o estudo do comportamento do processo para diferentes situções. Um dos aspectos interessantes é a identificação de "gargalos" durante a sua execução.
É fácil perceber que as características do processo de se permitir a ocorrência de no máximo uma verificação em cada instante e de o bloqueio de ICs e de implementador perdurar até o término da modificação, estabelecem nitidamente dois pontos de congestionamento do processo nas filas de espera por implementação e de espera por verificação, representadas no modelo pelos lugares omsEmEsperaImplem e omsEmEsperaVerif, respectivamente.
Assim, como exemplo de aplicação do modelo apresentam-se a seguir um pequeno estudo de como se comportam as filas de espera conforme varia a relação entre o tempo de implementação e o tempo de verificação.
O estudo é composto por três simulações em que varia-se apenas o tempo de verificação, mantendo-se as outras características constantes. As características básicas constantes são:
Tempo para geração de PM: 5 iterações
(Classe Originador: TMIN
= 5 e TMAX = 5)
Tempo para elaboração de PTM: 1 iteração
(Classe
ElaboradorPTM: TMIN = 1 e TMAX = 1)
Tempo para implementação de OM: 10 iterações
(Classe Implementador: TMIN = 10 e TMAX = 10)
Número de ICs do produto: 20
(Classe RGCS:
TOTICS = 20)
Número máximo de ICs por OM: 2
(Classe RGCS:
MAXICSOM = 2)
Nos três casos de estudo, o processo é simulado para 10000 iterações e verifica-se o contúdo das filas ao final das iterações.
No caso 1, define-se o tempo de verificação de OM como 1 iteração (Classe Verificador: TMIN=1 e TMAX=1) representando a situação em que em média o tempo de verificação de modificação representa 10% do tempo de implementação. No caso 2, o tempo de verificação é de 5 iterações, representando 50% do tempo de implementação. Por fim no caso três, o tempo de verificação é de 10 iterações, representando uma situação limite em que os tempos de verificação de modificações são em média iguais aos tempos de implementação.
As figuras a seguir mostram os resultados das simulações.
Caso 1
Tempo de verificação = 1, 10% do tempo de implementação
Caso 2
Tempo de verificação = 5, 50% do tempo de implementação
Caso 3
Tempo de verificação = 10, 100% do tempo de implementação
Precebe-se pelos resultados, que no caso 1 não ocorre congestionamento das filas, mostrando que para tempos pequenos de verificação com respeito a implementação, as restrições impostas pelo processo são aceitáveis. Ns casos 2 e 3 as simulações mostram que o "gargalo" se estabelece na fila de espera por implementação e que o congestionamento na fila de verificações é muito pequena e praticamente constante com a variação do tempo de verificação.
Este exemplo mostra que a modelagem do processo de modificação utilizando-se o SNTool pode ser efetivamente útil para entender melhor o seu comportamento antes de colocá-lo em execução real num ambiente de produção de software.