Ferreira 2011

Valida c ao do Fluxo Excepcional a partir do Diagrama de Atividades da UML 2.
Este exemplar corresponde a ` reda ca o da Disserta ca o apresentada para a Banca Examinadora antes da defesa da Disserta ca o.
Campinas, 12 de dezembro de 2010.
Eliane Martins (Orientadora)
Disserta ca o apresentada ao Instituto de Computa ca o, unicamp, como requisito parcial para a obten ca o do t tulo de Mestre em Ci encia da Computa ca o.
Instituto de Computa c ao Universidade Estadual de Campinas
Valida c ao do Fluxo Excepcional a partir do Diagrama de Atividades da UML 2.0

Jeferson Ferreira
Mar co de 2011
Banca Examinadora:
Eliane Martins (Orientadora) Charlie Brown Donald Duck Era Stoteles Fairy Tail
Departamento de Apicultura Subterr anea Computacional
ii
Jeferson Ferreira, 2010.
Todos os direitos reservados.
iii
Resumo
O resumo deve conter no m aximo 500 palavras, digitar aqui com a ca o...
Abstract
The abstract must contain at most 500 words...
vii
Agradecimentos
Eu gostaria de agradecer a...
ix
Sum ario
Resumo Abstract Agradecimentos 1 Introdu c ao 2 Parte I - Fundamenta c ao Te orica 2.1 Tratamento de Exce c oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 An alise de Fluxo de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Parte II - A Abordagem Proposta 3.1 Diagrama de Atividades . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Atividades e A co es . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Sem antica de A co es da UML 2.0 . . . . . . . . . . . . . . 3.1.3 Tratamento de exce co es no DA . . . . . . . . . . . . . . . 3.2 Descri ca o da Abordagem . . . . . . . . . . . . . . . . . . . . . . . 3.3 Constru ca o do Grafo de Fluxo de Controle . . . . . . . . . . . . . 3.3.1 Constru c ao do Grafo de Atividades . . . . . . . . . . . . . 3.3.2 Obten c ao do Grafo de Fluxo de Controle a partir do GA . 3.3.3 Cria c ao do Fluxo de Exce co es Intraprocedimentais . . . . 3.4 Constru ca o do Grafo de Fluxo de Controle Interprocedimental . . 3.4.1 Gerando o Grafo de Fluxo de Controle Interprocedimental 3.4.2 Constru c ao do Grafo Resumido da Interface . . . . . . . . 3.4.3 Interprocedural Exception Analysis . . . . . . . . . . . . . 3.5 Ferramenta de Valida ca o . . . . . . . . . . . . . . . . . . . . . . . xi v vii ix 1 3 3 3 4 5 5 6 11 14 17 17 17 25 31 36 37 38 39 40
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
4 Parte III - Estudos de Caso 43 4.1 Sistema de Minera c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2 Outros Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5 Conclus oes e Trabalhos Futuros Bibliograa 45 46
xii
Lista de Tabelas
3.1 3.2 3.3 3.4 Subconjunto de Atividades Permitidas . . . . . . . . . . . . . . . . Classica c ao das A c oes UML quanto ` a Escrita/Leitura de Dados . Conjunto de Deni c oes do GFC . . . . . . . . . . . . . . . . . . . Resultado da An alise das deni c oes incidentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 13 34 35
xiii
Lista de Figuras
2.1 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 Grafo de Fluxo de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de Atividades . . . . . . . . . . . . . . . . Atividades B asicas . . . . . . . . . . . . . . . . . . . Atividades Intermedi arias . . . . . . . . . . . . . . . Atividades Estruturadas . . . . . . . . . . . . . . . . Classica ca o dos Tipos de Exce c ao do Java . . . . . . Modelo de Exce c oes do DA . . . . . . . . . . . . . . Fluxo de Controle das Atividades Estruturadas . . . Especica ca o da opera ca o service() . . . . . . . . . . Grafo de Atividades da opera ca o service() . . . . . . Modelo de Dados do GA e GFC . . . . . . . . . . . . Grafo de Fluxo de Controle da opera ca o service() . . Hierarquia de Exce co es . . . . . . . . . . . . . . . . . Exceptional Control Flow in UML exception-handling Interface Summary Graph . . . . . . . . . . . . . . . Grafo de Fluxo de Controle Interprocedimental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 6 7 8 10 15 16 21 23 24 27 31 34 37 39 41
xv
Cap tulo 1 Introdu c ao

xxxxxx
Cap tulo 2 Parte I - Fundamenta c ao Te orica

Fundamenta ca o te orica ....
2.1
Tratamento de Exce co es
Tratamento de exce c oes ...
2.2
An alise de Fluxo de Dados
O grafo Def-Uso, ou Grafo de Fluxo de Dados (GFD), e uma extens ao do GFC onde s ao adicionadas as informa co es referentes ao uxo de dados, caracterizando associa c oes entre pontos do programa nos quais e atribu do um valor a uma vari avel (deni ca o da vari avel) e pontos nos quais esse valor e utilizado (refer encia ou uso da vari avel). Este grafo e obtido a partir do GFC associando-se a cada n o n : o conjunto de vari aveis com uso no v ertice n, o conjunto de vari aveis com deni c oes no v ertice n, e para cada aresta (n,m) o conjunto de vari aveis com usos na aresta (n,m). A Figura 2.1 apresenta um exemplo de GFD.
Figura 2.1: Grafo de Fluxo de Dados Cada ocorr encia de uma vari avel pode ser classicada como sendo uma deni ca o def, um uso computacional c-uso ou um uso predicativo p-uso. Por exemplo, a declara c ao y 3
Cap tulo 2. Parte I - Fundamenta ca o Te orica
= f (xi , ..., xn ) cont em c-usos de x1 , .., xn seguido de uma deni ca o de y. J a a declara ca o de transfer encia condicional if p(x1 , .., xn ) then <...> cont em p-usos de x1 , ..., xn [11]. Um par deni c ao-uso e um par de localiza co es (ln , lm ) no qual uma vari avel v e denida em ln e usada em lm . Um caminho de ln at e lm e um caminho livre de deni ca o com respeito a vari avel v se v n ao receber outro valor em nenhum dos n os do caminho. Se existe um caminho livre de deni ca o de ln at e lm com respeito a vari avel v, a deni c ao de v em ln alcan ca o uso em lm [6]. Um du-caminho e um subcaminho simples que e livre de deni c ao com respeito a v da deni c ao de v at e o uso de v. O conjunto de du-caminhos de ln at e lm com respeito a v e denido como du(ln , lm , v) [2]. Uma vez que estamos interessados em capturar o uxo de dados entre os n os, qualquer deni c ao que e usada dentro do mesmo n o em que ocorreu a deni c ao, tem pouca import ancia. Assim fazemos a seguinte distin c ao: c-uso de uma vari avel x e um c-uso global, se n ao existir nenhuma deni c ao de x precedendo o c-uso dentro do mesmo bloco. Isto e, o valor de x deve ter sido denido em algum outro bloco diferente daquele em que est a sendo usado. De outra forma isto seria um c-uso local.Como um p-uso est a associado somente com arestas, nenhuma distin c ao precisar ser feita entre p-usos locais e globais. Uma deni c ao de uma vari avel x em um n o i e uma deni c ao global se esta e a u ltima ocorr encia de x dentro do bloco associado com o n o i e existe um caminho livre de deni c ao do n o i at e o n o que contenha o c-uso global de x ou at e uma aresta que contenha um p-uso de x [11]. As informa co es de uxo de dados podem ser coletadas estabelecendo e solucionando-se sistemas de equa co es que relacionam informa co es em v arios pontos do programa. Estas equa co es s ao chamadas de equa c oes de uxo de dados. Uma equa ca o t pica possui a seguinte forma saida[B] = geradas[B ] (entrada[B ] mortas[B ]) e pode ser lida como as informa c oes ao nal de um bloco B ou s ao geradas dentro do bloco ou entram ao in cio e n ao s ao mortas ` a medida que o controle ui atrav es do bloco. As no co es de gerar e matar dependem da informa c ao desejada, isto e, do problema de an alise de uxo de dados a ser resolvido [1]. Nas se co es 3.3 e 3.4 s ao apresentados exemplos de an alises de uxo de dados que s ao utilizadas para inferir quais s ao os tipos de exce c ao que podem ser lan cadas por um determinado n o do grafo.
2.3
Trabalhos Relacionados
Trabalhos relacionados ...
Cap tulo 3 Parte II - A Abordagem Proposta

Abordagem proposta ....
3.1
Diagrama de Atividades
A UML (Unied Modeling Language) [10] e uma linguagem de modelagem e documenta c ao de software que surgiu em 1996 com o objetivo de acelerar a transi c ao para o paradigma de orienta ca o ` a objetos. Teve sua origem na compila ca o das melhores pr aticas de engenharia que provaram ter sucesso na modelagem de sistemas computacionais grandes e complexos. Os conceitos de Booch [5], Rumbaugh [12] e Jacobson [9] foram fundidos numa u nica linguagem de modelagem. Atualmente a linguagem UML e mantida pela OMG (Object Management Group). A UML e uma nota c ao amplamente utilizada para ns de documenta c ao e especica ca o durante o processo de desenvolvimento de um software. Rapidamente tornou-se um padr ao no desenvolvimento orientado a objetos. A UML e dividida em duas especica co es, estrutural e comportamental. A primeira modela os aspectos est aticos de um sistema, j a a segunda os aspectos din amicos. Neste segundo grupo se enquadram os modelos comportamentais, que especicam como os aspectos estruturais de um sistema mudam atrav es do tempo. O Diagrama de Atividades (DA) e um exemplo desse tipo de modelo, sendo considerado a escolha natural (dentro da UML) para modelar os aspectos compor utilizado para tamentais de um sistema, de uma classe ou mesmo de uma opera c ao. E ilustrar uma sequ encia de atividades que foram modeladas para representar os aspectos din amicos de um processo computacional. Este modelo detalha o uxo de controle e o uxo de dados de uma determinada atividade, mostrando as ramica co es de controle e as situa co es onde existem processamento paralelo. At e a vers ao 1.5 da UML o uxo de dados e controle eram representados pelos diagramas de estado e de intera ca o. Na vers ao 1.5 surgiu a primeira vers ao do diagrama de 5
Cap tulo 3. Parte II - A Abordagem Proposta
atividades, que herdou a forma do diagrama de estados alterando a nota ca o para parecer uma diagrama de uxo. Na vers ao 2.0 da UML esse diagrama se tornou independente, deixando inclusive de se basear em m aquinas de estados e passando a se basear em Redes de Petri, utilizadas para modelar comportamento concorrente em sistemas distribu dos. Nesta u ltima vers ao foram inclu dos v arios recursos, como: pinos para modelar o uxo de dados das atividades, par ametros em atividades, conjunto de par ametros, regi oes interrupt veis e a modelagem expl cita do uxo de objetos. Apresentamos a seguir os elementos do diagrama que ser ao utilizados nesse trabalho. O leitor interessado poder a consultar a especica ca o da UML [10] para maiores detalhes sobre o diagrama de atividades. O diagrama de atividades e decomposto em Atividades e A co es. Uma atividade e representada por um ret angulo de cantos arredondados, representa um processamento complexo, que pode ser dividido em v arias outras atividades originando um novo diagrama, por esse motivo o pr oprio Diagrama de Atividades e considerado uma atividade. A Figura 3.1 exibe um exemplo de Diagrama de Atividades com uxo de controle e dados.
Figura 3.1: Diagrama de Atividades
3.1.1
Atividades e A co es
As atividades s ao comportamentos que modelam uma execu ca o n ao-at omica, j a uma a ca o representa um processamento at omico [3]. As atividades (Activity ) coordenam as a c oes (Action ). Essa coordena ca o e capturada como um grafo, onde os n os (ActivityNode ) representam as a co es e s ao conectados por arestas (ActivityEdge ). O Fluxo de dados e representado por n os de objetos (ObjectNode ) e por arestas de uxo de dados (ObjectFlow ). O controle e os dados uem ao longo das arestas e s ao manipulados pelos n os, s ao roteados para outros n os ou s ao armazenados temporariamente. Mais especicamente, os n os de a ca o manipulam o controle e dados recebidos atrav es das arestas do grafo e prov eem controle e dados para outras a c oes; os n os de controle roteiam o controle e dados atrav es do grafo; os n os de objetos armazenam os dados temporariamente at e serem mo-
3.1. Diagrama de Atividades
vidos atrav es do grafo. O termo token e utilizado para denominar o controle e os valores dos dados que uem atrav es de uma atividade. Para ser executada, uma a ca o precisa saber quando iniciar e quais s ao suas entradas. Estas condi c oes s ao determinadas pelo uxo de controle e uxo de dados. Uma a c ao pode ter entradas e sa das, que s ao chamadas de pinos. Os pinos s ao conectados por arestas de uxo de objetos, que identicam o tipo do objeto que est a sendo enviado. Na Figura 2 e poss vel observar a utiliza ca o dos pinos x e y como par ametros da a ca o x + y; a execu ca o ocorrer a somente quando os dois valores estiverem dispon veis [4]. O meta-modelo de atividades da UML est a organizado em v arios n veis. A seguir e apresentada uma breve descri ca o dos pacote relevantes e das suas atividades: Atividades Fundamentais (FundamentalActivities): O n vel fundamental dene as atividades e as a co es. Uma atividade cont em n os que podem ser a co es ou outras atividades aninhadas. Atividades B asicas (BasicActivities): Este n vel inclui o uxo de controle e de dados entre as a c oes, inclui tamb em os seguintes elementos (Figura 3.2):
N o de Inicializa c ao (InitialNode): e o n o inicial do uxo de uma atividade. Uma

atividade pode conter mais de um n o de inicializa ca o, indicando que, quando a atividade e iniciada, v arios uxos s ao iniciados tamb em.
N o Final de Atividade (ActivityFinalNode): a chegada do primeiro token a este n o

termina toda a atividade, terminando todos os uxos concorrentes, se existirem.
Figura 3.2: Atividades B asicas Atividades Intermedi arias (IntermediateActivities): Este n vel intermedi ario possibilita a modelagem de diagramas de atividades que incluem uxos de controle e de dados concorrentes e tamb em os n os de decis ao e mesclar (Figura 3.3), descritos a seguir:
N o de Decis ao (DecisionNode): direciona o uxo em uma dire c ao ou outra, dependendo da avalia ca o da express ao associada.
N o de Intercala c ao (MergeNode): tem a mesma nota c ao que um n o de ramica ca o,
a diferen ca e que chegam v arias arestas de uxos alternativos e segue apenas uma aresta.
N o de Bifurca c ao (ForkNode): divide o uxo em m ultiplos uxos concorrentes. Os

tokens de dados e controle que chegam a bifurca c ao s ao duplicados.
N o de Uni ao (JoinNode):
recebidos de cada uxo.
sincroniza os m ultiplos uxos, combinando os tokens
N o Final de Fluxo (FlowFinalNode):
destr oi o token de controle ou de dado que utilizado em uxos alcan ca o n o. Se existirem outros uxos, a atividade continua. E concorrentes.
Figura 3.3: Atividades Intermedi arias Atividades Estruturadas (StructuredActivities) e Atividades Estruturadas Completas (CompleteStructuredActivities): Estes pacotes permitem a modelagem de constru c oes tradicionais de programa c ao estruturada, como la cos e n os condicionais. Adicionam o suporte para o uxo de dados incluindo os pinos de sa das e entrada, conforme descrito a seguir:
Vari avel (Variable): Vari aveis s ao elementos utilizados para compartilhar dados en-
tre as a c oes. O resultado de uma a ca o pode ser escrito em uma vari avel e utilizado como uma entrada de uma a ca o subsequente, isto caracteriza um caminho indireto de uxo de dados. N ao h a nenhuma rela ca o pr e-denida entre as a c oes que l eem e escrevem dados nas vari aveis, estas a co es devem ser sequenciadas pelo uxo de controle para prevenir condi co es de corrida entre a co es que le em e escrevem na mesma vari avel. Todos os valores contidos por uma vari avel devem estar em conformidade com o tipo da vari avel e ter cardinalidades compat vel com multiplicidade denida pela vari avel. Uma vari avel possui um escopo, que pode ser uma atividade (propriedade activityScope ) ou um n o de atividade estruturada (propriedade scope ), mas n ao ambos. Os valores armazenados por uma vari avel podem ser acessados somente pelo grupo de a co es ou atividades pertencentes ao escopo da vari avel. As vari aveis foram introduzidas para simplicar a tradu ca o de linguagens de programa ca o comuns em modelos de atividades.
N o de Atividade Estruturada (StructuredActivityNode):
S ao n os execut aveis que podem conter outras atividades subordinadas, inclusive outros n os de atividade estruturada aninhados. Os n os subordinados devem pertencer a apenas um n o de atividade estruturada, embora possam ser aninhados. Uma atividade estruturada tamb em pode conter manipuladores de exce c ao. Um exemplo pode ser visto na Figura 3.4a.
N o Condicional (ConditionalNode):
uma atividade estruturada que representa E uma escolha exclusiva entre algumas alternativas (Figura 3.4b). Esta atividade pode possuir diversas cl ausulas, sendo que uma cl ausula e composta de duas se co es: teste (test) e corpo (body). A se ca o test deve possuir uma a c ao que retorne um valor booleano. Caso esta a ca o retorne verdadeiro a a ca o vinculada ` a se ca o body e executada. Caso contr ario a pr oxima cl ausula da atividade, se existir, e testada. A primeira cl ausula satisfeita interrompe a verica ca o das demais. No exemplo da Figura 3.4b a a ca o Test Behavior possui um pino de sa da decider que e utilizado para fazer a verica c ao; caso o valor retornado pelo pino decider seja verdadeiro, a a ca o Body Behavior e executada.
uma atividade estruturada utilizada para representar um la La co (LoopNode): E co.
Esta atividade e dividida em tr es se co es: setup onde e feita a inicializa ca o das vari aveis, test que representa o teste condicional para determinar a condi c ao de sa da do la co e body que representa o corpo do la co. A se c ao de teste pode preceder ou suceder a se ca o do corpo, o que dene a ordem e o valor boleano da propriedade isTestedFirst, se for verdadeiro o teste e executado antes da execu ca o do corpo, o valor padr ao e falso. A se c ao de inicializa c ao e executada apenas uma vez na entrada do la co, as se c oes de teste e corpo s ao executadas repetidamente at e que o teste produza um valor falso. Na Figura 3.4c a se ca o setup e representada pela a ca o Setup Behavior, a se ca o test e representada pela a c ao Test Behavior que possui um pino de sa da decider o qual e avaliado para determinar a condi ca o de sa da do la co. Por m a a ca o Body Behavior representa o corpo do la co.
Atividades Estruturadas Extras (ExtraStructuredActivities): Este n vel permite representar o tratamento de exce c oes.
Tratador de Exce c oes (ExceptionHandler): Representa uma aresta de exce ca o, indicando que uma atividade estruturada trata as exce c oes ocorridas no seu interior (Figura 3.4a). No exemplo da Figura 3.4a existe um ExceptionHandler ligando a atividade estruturada com a a c ao Body Handler que efetivamente far a o tratamento da exce c ao. Esta a ca o possui um pino de entrada e que representa a refer encia ao
10
(a)
(b)
(c)
Figura 3.4: Atividades Estruturadas objeto de exce c ao. O tipo de exce ca o capturada pela aresta de exce c ao e especicada pela propriedade Exception Type. Uma aresta de exce c ao e capaz de capturar diversos tipos de exce co es, a propriedade Exception Type especica uma cole ca o de tipos de exce ca o tratadas por esta aresta. Maiores detalhes sobre o tratamento de exce co es no DA ser ao apresentados adiante neste documento. Para reduzir a complexidade a abordagem proposta n ao ir a tratar dos uxos concorrentes e nem das a c oes com comportamento n ao-determin stico. O subconjunto das atividades permitidas e mostrado na Tabela 3.1. Tabela 3.1: Subconjunto de Atividades Permitidas
Pacote Atividades B asicas Atividades Fundamentais Atividades Intermedi arias Atividades N o Inicial (InitialNode) N o Final de Atividade (ActivityFinalNode) Atividade (Activity) A c ao (Action) N o de Decis ao (DecisionNode) N o de Intercala c ao (MergeNode) N o Final de Fluxo (FlowFinalNode) N o Condicional (ConditionalNode) La co (LoopNode) Atividade Estruturada (StructuredActivityNode) Vari avel (Variable) Tratador de Exce c oes (ExceptionHandler)
Atividades Estruturadas Atividades Estruturadas Extras
11
3.1.2
Sem antica de A c oes da UML 2.0
Uma a ca o e uma unidade fundamental de especica c ao de comportamento. Uma a ca o toma um conjunto de entradas e converte em um conjunto de sa das, embora um ou outro, ou mesmo ambos os conjuntos podem ser vazios. A co es est ao contidas em comportamentos, os quais denem o seu contexto. Comportamentos tamb em denem restri co es entre as a c oes para determinar quando as a co es executam e quais s ao as suas entradas. De um modo geral, uma a c ao pode expressar vari aveis, opera co es l ogicas e aritm eticas, e v arias outras funcionalidades b asicas de linguagens de programa ca o imperativas. O modelo de a co es da UML [10] apresenta um conjunto de a c oes com uma sem antica bem denida. No contexto de uxo de dados uma a c ao pode ser classicadas como: a c ao de escrita : aquela que faz a deni c ao de dados ou a c ao de leitura : aquela que faz uso de algum dado denido previamente. Podem existir a c oes que se enquadram em ambas ou em nenhuma das classica co es. A seguir e apresentada uma breve descri c ao das a co es relevantes ao contexto deste relat orio: identicada pelo s A c ao de chamada de comportamento (CallBehaviorAction): E mbolo em forma de tridente e representa a inclus ao de outro diagrama de atividades que detalha o seu comportamento. Quando todos os pr e-requisitos para a execu ca o da a c ao forem satisfeitos, esta a ca o faz uma chamada ao comportamento especicado. Os valores dispon veis nos pinos de entrada s ao passados como argumentos. Os pinos da a ca o devem ser equivalentes aos par ametros do comportamento em n umero, tipo, dire ca o (entrada/sa da) e multiplicidade. O comportamento chamado deve ser capaz de aceitar e retornar o controle. No caso de uma chamada ass ncrona, a a c ao e completada imediatamente sem depend encias de execu c ao entre o comportamento chamado e o comportamento onde a a ca o est a contida. Se a chamada for s ncrona, a execu ca o da a ca o e bloqueada at e receber uma resposta do comportamento chamado. Quando a execu ca o do comportamento chamado termina, os valores dos resultados s ao disponibilizados nos pinos de sa da da a c ao. Se a execu c ao do comportamento chamado produzir uma exce c ao, a exce c ao e transmitida para a a c ao CallBehaviorAction para iniciar a procura por um tratador de exce c ao. A c ao de chamada de Opera c ao (CallOperationAction): Representa a chamada de uma opera ca o do objeto alvo disponibilizado no pino de entrada target. Esta a ca o realiza a invoca c ao do comportamento associado a ` opera ca o, como por exemplo, o m etodo de uma classe que esta modelado em outro diagrama de atividades. Al em do objeto alvo, este tipo de a ca o pode ter par ametros de entrada e sa da. Os pinos de entrada representam os argumentos, j a os pinos de sa da representam os par ametros de retorno da opera ca o. Os par ametros de entrada e de sa da da opera ca o devem ser equivalentes aos pinos inclu dos na a c ao em n umero, tipo, dire ca o (entrada/sa da) e multiplicidade. Quando todos os pr e-requisitos para a execu ca o da a c ao s ao satisfeitos, as informa co es sobre a opera ca o e os argumentos de entrada s ao enviados para o objeto alvo. Caso a chamada seja s ncrona,
12
a a c ao e bloqueada e aguarda o t ermino da execu c ao da opera c ao chamada. Quando a resposta comunicando o m da execu ca o do comportamento chega at e a a ca o, os valores de retorno s ao disponibilizados nos pinos de sa da da a c ao e a execu ca o da a ca o e completada. Se a chamada for ass ncrona, o comportamento chamador avan ca imediatamente e a execu ca o da a ca o e completada. Nenhum retorno da opera ca o chamada e enviado de volta para o comportamento chamador. Se a execu c ao da opera ca o chamada produzir uma exce c ao, a exce ca o e transmitida ao comportamento chamador onde e novamente lan cada como uma exce ca o da a c ao CallOperationAction. Os poss veis tipos de exce ca o podem ser especicados na opera ca o chamada. uma a A c ao opaca (OpaqueAction): E ca o com a sem antica espec ca determinada pela sua implementa c ao; sendo utilizada para representar opera co es aritm eticas e booleanas. Esta a ca o semanticamente n ao realiza nenhum uso ou deni ca o de dados. Em rela c ao ao uxo de dados, consideramos que os usos ocorreram nas a c oes de leitura antecedentes que disponibilizam os valores nos pinos de entrada e as deni c oes ocorrer ao nas a c oes de escrita subsequentes que utilizem os resultados disponibilizados pelos pinos de sa da da a ca o. Deni c ao de caracter stica estrutural (AddStructuralFeatureValueAction): Esta a c ao e classicada como uma a c ao de escrita, ou seja, realiza uma deni ca o de dados. O pino de entrada value recebe o valor que ser a inserido em uma caracter stica estrutural (Ex: atributo de uma classe). Tamb em e poss vel utilizar o pino insertAt para identicar a posi ca o da caracter stica estrutural que receber a o valor, no caso de uma caracter stica multivalorada (Ex: uma cole ca o). O nome da caracter stica estrutural e especicado estaticamente pela propriedade StructuralFeature. A refer encia do objeto que det em a caracter stica estrutural e informada pelo pino de entrada object. Leitura de caracter stica estrutural (ReadStructuralFeatureAction): Esta a c ao e classicada como uma a ca o de leitura. O pino de sa da result recebe o valor lido de uma caracter stica estrutural (Ex: atributo de uma classe). O nome da caracter stica estrutural e especicado estaticamente pela propriedade StructuralFeature. A refer encia do objeto que det em a caracter stica estrutural e informada pelo pino de entrada object. A multiplicidade da caracter stica estrutural deve ser compat vel com o pino de sa da. Por exemplo, o modelador pode denir a multiplicidade do pino para suportar 9m ultiplos valores mesmo quando a caracter stica estrutural somente disponibiliza um u nico valor. Dessa maneira o modelo de a co es n ao ser a afetado por mudan cas na multiplicidade da caracter stica estrutural. Cria c ao de Objeto (CreateObjectAction): Cria um objeto de acordo com a classe especicada estaticamente na propriedade Classier. O objeto criado e colocado no pino de sa da e n ao possue nenhum valor em suas caracter sticas estruturais. Uma a ca o deste tipo e considerada uma a ca o de escrita, pois o objeto criado pode ser utilizado pela a ca o
13
subsequente, se esta for uma a c ao de leitura. Leitura do objeto hospedeiro (ReadSelfAction): Recupera o objeto hospedeiro da a ca o, fornecendo acesso ao objeto do contexto quando ele n ao est a dispon vel como um par ametro. A a ca o deve estar contida em um comportamento de uma classe, que represente o corpo de um m etodo; neste caso o m etodo n ao pode ser est atico. O tipo do pino de sa da deve ser do mesmo tipo do objeto hospedeiro. Tabela 3.2: Classica c ao das A c oes UML quanto ` a Escrita/Leitura de Dados
Tipo A c ao AddStructuralFeatureValue AddVariableValue CallOperation ClearStructuralFeature ClearVariable CreateLinkObject CreateObject DestroyObject Reduce RemoveStructuralFeatureValue RemoveVariableValue Unmarshall AddVariableValue CallOperation CreateLink CreateLinkObject Opaque RaiseException Reduce ReadExtent ReadVariable ReadStructuralFeature TestIdentify Unmarshall ReadSelf ValueSpecication Propriedade StructuralFeature Variable OutputPin [0..*] StructuralFeature Variable OutputPin Classier InputPin OutputPin StructuralFeature Variable OutpuPin[1..*] InputPin InputPin [0..*] InputPin[0..*] InputPin[0..*] InputPin[0..*] InputPin InputPin Classier Variable StructuralFeature InputPin[2..2] InputPin[1..1] Descri c ao Deni c ao de uma caracter stica estrutural Deni c ao de uma vari avel Deni c ao dos par ametros de retorno Deni c ao de uma caracter stica estrutural Deni c ao de uma vari avel Deni c ao de uma refer encia de objeto Deni c ao de uma refer encia de objeto Deni c ao de uma refer encia de objeto Deni c ao do resultado da redu c ao Deni c ao de uma caracter stica estrutural Deni c ao de uma vari avel Deni c ao de caracter sticas estruturais Leitura do par ametro de entrada Uso dos par ametros de entrada Uso dos par ametros de entrada Uso dos par ametros de entrada Uso dos par ametros de entrada Uso de uma refer encia de exce c ao Uso da refer encia de uma cole c ao Uso de uma refer encia de objeto Uso de uma vari avel Uso de uma caracter stica estrutural Uso dos par ametros de entrada Uso de uma refer encia de objeto
Escrita
Leitura
Nenhum
Especica c ao de valor (ValueSpecicationAction): Esta a c ao retorna como resultado o valor denido estaticamente na propriedade value. O valor e disponibilizado no pino de sa da da a c ao. O tipo do valor especicado deve ser compat vel com o tipo do pino de sa da. Esta a ca o semanticamente n ao realiza nenhum uso ou deni c ao de dados. Deni c ao de vari avel (AddVariableValueAction): A ca o de escrita, o valor fornecido no pino de entrada value e escrito na vari avel especicada estaticamente na propriedade Variable. Uma vari avel deve ser denida para ser utilizada por este tipo de a c ao. No caso de vari aveis multivaloradas, para especicar a posi c ao do elemento que deve ser atualizado
14
e utilizado o pino de entrada insertAt. uma a Leitura de vari avel (ReadVariableAction): E ca o de leitura, que recupera o valor da vari avel, denida estaticamente pela propriedade Variable, disponibilizando esse valor no pino de sa da result. No caso de vari aveis multivaloradas, a a ca o l e os valores na ordem armazenada pela cole c ao. uma a Lan camento de exce c ao (RaiseExceptionAction): E ca o que provoca a ocorr encia de uma exce c ao. A refer encia do objeto de exce ca o e colocada no pino de entrada exception e a execu ca o desta a ca o lan ca este objeto como uma exce c ao. Esta a ca o e considerada de leitura por fazer uso de uma deni ca o de um objeto de exce ca o. Quando uma exce c ao e lan cada, a execu ca o do n o estruturado ou atividade que cont em esta a ca o e imediatamente terminada, iniciando em seguida uma busca nos escopos aninhados por um tratador de exce co es correspondente ao tipo do objeto de exce c ao. A Tabela 3.2 apresenta um resumo da classica ca o das a co es da UML 2.0 quanto a ` escrita ou leitura de dados. Na primeira coluna e apresentado o tipo da classica c ao, na segunda coluna e apresentado o nome da a c ao, a terceira coluna indica o nome da propriedade da a ca o que dene o nome e o tipo de dado utilizado, a u ltima coluna descreve a ocorr encia da deni c ao ou uso gerada pela a ca o.
3.1.3
Tratamento de exce c oes no DA
Na maioria das linguagens orientadas a objetos, uma exce ca o e um evento que ocorre durante a execu ca o de um programa, interrompendo o uxo normal das instru c oes. Quando ocorre um erro dentro de um m etodo, um objeto de exce c ao e criado. Este objeto cont em informa co es sobre o erro, incluindo o tipo e o estado do programa no momento que o erro ocorreu. Quando um objeto de exce c ao e lan cado o programa procura na pilha de execu ca o por um m etodo que contenha um bloco de c odigo que possa tratar a exce ca o. Este bloco de c odigo e chamada de tratador de exce co es. A procura come ca dentro do m etodo em que o erro ocorreu e continua atrav es da pilha de execu ca o na ordem reversa em que os m etodos foram chamados. Quando um tratador de exce ca o apropriado e encontrado, o programa passa a exce c ao ao tratador de exce co es. Um tratador de exce co es e considerado apropriado se o tipo do objeto de exce ca o lan cado e equivalente ao tipo que pode ser capturado pelo tratador de exce co es [7]. Exce co es em Java pode ser classicadas como s ncronas e ass ncronas. Uma exce c ao s ncrona ocorre em um ponto espec co de um programa, podendo ser causada pela avalia ca o de uma express ao, execu ca o de uma declara c ao ou um comando throw expl cito. Por outro lado, uma exce ca o ass ncrona pode ocorrer arbitrariamente em pontos n ao determinados do programa. Uma exce ca o s ncrona pode ser classicada como vericada (checked exception ) ou n ao vericada (unchecked exception ). No caso de uma exce co es vericada,
15
o compilador deve procurar um tratador de exce co es dentro do m etodo ou deve existir uma declara ca o na assinatura do m etodo para indicar que a exce ca o ser a lan cada. Para as exce c oes n ao vericadas, o compilador n ao tenta encontrar um tratador de exce co es ou alguma declara ca o na assinatura do m etodo. Uma exce ca o s ncrona e explicita se for lan cada pelo comando throw, j a uma exce ca o s ncrona impl cita e lan cada se for causada na chamada de alguma rotina externa ao programa ou pelo ambiente de execu ca o. Na Figura 3.5 e mostrada a classica ca o das exce c oes Java.
Figura 3.5: Classica ca o dos Tipos de Exce ca o do Java A t ecnica que estamos apresentando neste documento n ao abrange as exce c oes ass ncronas e exce c oes s ncronas que s ao lan cadas implicitamente. Pois esses tipos de exce c oes n ao s ao modeladas explicitamente. Portanto, ser ao tratadas somente as exce co es s ncronas que s ao modeladas explicitamente. Fazendo uma analogia com a linguagem de programa ca o Java, a a c ao RaiseExceptionAction e equivalente ao comando throw, o n o protegido e equivalente ao bloco try, o tratador de exce c oes (ExceptionHandler ) e equivalente a uma cl ausula catch e o corpo do tratador de exce co es (CallBehaviorAction ) e equivalente ao bloco da cl ausula acionada. Na Figura 3.6 podemos observar cada uma dessas constru co es. A a c ao raise E2 e um exemplo de uso da a c ao RaiseExceptionAction. Esta a c ao recebe um objeto de exce ca o no pino de entrada e2 e lan ca uma exce ca o do tipo E2. Os n os Protected Node 1 e Protected Node 2 s ao exemplos de n os protegidos. O primeiro possui dois tratadores de exce ca o capazes de capturar exce co es do tipo E2 e E3, j a o segundo possui um tratador de exce c ao capaz de capturar exce co es do tipo E1. Cada tratador de exce c ao liga o n o protegido a uma a c ao do tipo CallBehaviorAction que abstrai o tratamento da exce c ao. As a co es Body Handler E1, Body Handler E2 e Body Handler E3 s ao exemplos dessas a c oes. Quando uma a ca o RaiseExceptionAction e executada, todos os tokens do n o protegido onde esta a c ao estiver contida s ao nalizados. Em seguida, o conjunto de tratadores de exce ca o do n o protegido s ao examinados para vericar se s ao compat veis com a exce ca o
16
Figura 3.6: Modelo de Exce co es do DA lan cada. Um tratador de exce co es e compat vel se o tipo da exce ca o e o mesmo ou e uma subclasse do tipo especicado pelo tratador. Se os tipos forem compat veis, ent ao o tratador captura a exce ca o. Se existirem m ultiplos tratadores compat veis, apenas um ir a capturar a exce ca o. Como podem haver n os protegidos aninhados, se uma exce ca o n ao e capturada por nenhum dos tratadores de exce ca o do n o protegido interno, o processo se repete, propagando a procura para o pr oximo n o protegido, onde o n o interno estiver contido. No exemplo da Figura 3.6 uma exce ca o do tipo E2 e lan cada dentro do n o protegido Protected Node 2, os tratadores de exce ca o do n o protegido s ao avaliados para vericar se s ao capazes de tratar a exce ca o. No exemplo existe apenas um tratador do tipo E1, portanto a busca e propagada para o n o protegido Protected Node 1 at e encontrar um tratador compat vel. Neste caso o tratador compat vel e encontrado e o controle e passado para a a ca o Body Handler E2 que ir a invocar o comportamento respons avel pelo tratamento da exce c ao lan cada. A a c ao que representa o corpo do tratador de exce c oes n ao possui nenhuma aresta expl cita, seja de entrada ou de sa da. Contudo, esta a c ao pertence ao mesmo contexto do n o protegido. Assim, os tokens resultantes desta a ca o tornam-se tokens resultantes do n o protegido. Qualquer aresta de controle que deixe o n o protegido recebe os tokens de controle resultantes da execu ca o da a ca o. Quando a execu c ao da a c ao e completada, e como se o pr oprio n o protegido tivesse sido completado. Tendo em vista este compor-
3.2. Descri c ao da Abordagem
17
tamento, se desejarmos modelar um bloco de naliza ca o (nally ), podemos inserir uma a ca o (CallBehaviorAction ) na sequ encia do n o protegido, inserindo tamb em uma aresta de controle ligando o n o protegido com o bloco de naliza ca o. Dessa forma, o bloco de naliza ca o e executado na sequ encia da execu c ao do n o protegido, seja uma execu c ao normal ou excepcional. No exemplo da Figura 3.6 a a ca o Body Finally e utilizada para modelar um bloco de naliza c ao.
3.2
Descri c ao da Abordagem
A descri c ao da abordagem ...
3.3
Constru c ao do Grafo de Fluxo de Controle
A constru c ao do GFC ...
3.3.1
Constru c ao do Grafo de Atividades
O Grafo de Atividades (GA) e um grafo direcionado que representa a sequ encia de execu ca o das atividades e a c oes de um procedimento modelado no DA. Este grafo e uma representa ca o intermedi aria utilizada apenas durante o processo de constru ca o do GFC. Cada n o do GA pode representar uma atividade b asica (Ex: N o de Inicializa c ao, N o Final de Atividade), um n o de controle (Ex: N o de Decis ao, N o de Intercala ca o) ou n os auxiliares que s ao criados durante a transforma c ao das atividades estruturadas. As arestas do GA representam o uxo de controle entre os n os, e s ao geradas pelo mapeamento direto de arestas de controle do DA ou pela convers ao de uma ou mais arestas de uxo de dados do DA em uma aresta de controle do GA. As principais justicativas sobre a utiliza ca o do GA s ao as seguintes: (i) o DA admite decomposi ca o, e cada atividade pode ser decomposta em outro DA; (ii) os DAs n ao s ao interconectados, e possuem atividades desconexas, como por exemplo, o n o condicional, que tem se co es que n ao est ao interligadas no DA. O processo de gera ca o do GA e dividido em tr es etapas; cada DA contido no modelo passa por essas tr es etapas at e dar origem aos grafos resultantes. No nal deste processo, cada procedimento especicado no modelo ter a gerado o seu respectivo GA. Lembrando que para modelar um procedimento podem ser necess arios v arios diagramas de atividade. A primeira etapa consiste em determinar a ordem de execu ca o das atividades e a co es contidas em um DA. O Algoritmo 1 e utilizado para realizar esta ordena c ao.
18
Algoritmo 1 OrderingActivityNodes(n, e, p, g ) Entrada: N o do DA n, Aresta do DA e, N o predecessor p. Sa da: Grafo ordenado g .

1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38:
if n.visited = false then outgoings n.outgoingsEdges incomings n.incomingsEdges if n is an Action then if incomings.size > 1 then incomings incomings e if incomings.size = 0 then n.visited true for all i in incomings do g.nodes g.nodes n source i.source g.edges g.edges Edge(source, n) for all o in outgoings do next o.target OrderingActivityNodes(next, o, n, g ) else if outgoings.size > 1 then g.nodes g.nodes n g.edges g.edges Edge(p, n) for all o in outgoings do next o.target OrderingActivityNodes(next, o, n, g ) else n.visited true g.edges g.edges Edge(p, n) if n is an Action then for all output in n.outputP ins do OrderingActivityNodes(output, null, n, g ) else if n is an InputP in then if n.owner is an Action then if n.owner.visited = false then inputs n.inputP ins n n.owner.visited true else inputs inputs n if inputs.size = 0 then g.nodes g.nodes n.owner g.edges g.edges Edge(p, n.owner) OrderingActivityNodes(n.owner, null, n, g )
3.3. Constru c ao do Grafo de Fluxo de Controle
19
O grafo de atividades resultante e um grafo direcionado, onde cada n o representa uma atividade ou a ca o mapeada do DA e cada aresta representa o uxo de controle entre os n os. Nesta etapa, as arestas de uxo de controle e de uxo de dados do DA s ao utilizadas para identicar as depend encias de controle e as depend encias de dados entre as a co es. Para come car a executar, uma a c ao deve saber quando come car e quais s ao as suas entradas. Estas condi co es representam as depend encias de controle e dados, respectivamente. Uma a c ao come ca executar quando todas as suas entradas de controle e dados estiverem dispon veis. A nalidade do grafo e representar a ordem de execu ca o poss vel entre as atividades e a co es do DA, de acordo com as depend encias de controle expl citas (arestas de uxo de controle) e as depend encias de controle impl citas pela depend encia de dados (arestas de uxo de dados). Na segunda etapa, cada DA existente no modelo e visitado novamente; os n os internos s ao visitados de acordo com a ordena ca o gerada na primeira etapa. Essa segunda etapa permite criar a representa ca o das atividades estruturadas do DA, quais sejam os n os condicionais (ConditionalNode ) e os la cos (LoopNode ). Para cada DA existente no modelo ser a gerado um subgrafo de atividades correspondente. Para cada atividade estruturada contida em um DA, ou aninhada dentro de outra atividade estruturada, tamb em ser a um gerado subgrafo de atividades. O Algoritmo 2 e respons avel pela gera ca o dos subgrafos de cada DA e tamb em de suas atividades estruturadas aninhadas. No caso das atividades estruturadas N o Condicional (ConditionalNode ) e La co (LoopNode ), n os e arestas auxiliares s ao inseridos para ligar as se c oes da atividade estruturada, mostrando explicitamente a representa ca o do uxo de controle que antes era impl cita. A Figura 3.7 mostra os n os e arestas auxiliares utilizados para representar o uxo de controle dessas atividades. A Figura 3.7a apresenta um N o Condicional ConditionalNode e o seu respectivo uxo de controle gerado durante a transforma c ao dos modelos. Neste subgrafo, os n os begin e end representam o n o inicial e o n o nal e os demais n os representam uma cl ausula condicional.Uma cl ausula e formada por um par de se co es: test e body. Os n os test e body representam respectivamente as se co es test e body de uma cl ausula condicional. Quando a condi ca o da a ca o test e verdadeira o uxo de controle segue pela aresta (test body ). A aresta (test end ) representa o uxo de controle quando a condi ca o testada e falsa, e por m a aresta (body end ) representa o m da execu c ao de um n o condicional, quando o uxo de controle sai da a c ao body e segue para o n o end. Um n o condicional pode conter diversas cl ausulas, as se c oes test s ao examinadas at e que uma condi ca o seja satisfeita, quando isto ocorre o uxo segue para a se ca o body correspondente. A execu ca o de uma cl ausula implica na execu ca o do n o condicional, mesmo se houverem mais cl ausulas neste n o condicional, as demais n ao ser ao examinadas.
20
Algoritmo 2 ProcessAD(activity, graphs) Entrada: Diagrama de Atividades activity Sa da: Grafo de Atividades graph.
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25:
graph ActivityGraph(activity ) nodes activity.nodes edges activity.edges structuredN odes activity.structuredN odes {Processa cada n o da atividade} for all n in nodes do graph.nodes graph.nodes ActivityGraphN ode(n) OrderingActivityNodes(next, o, n, g ) dataF lowM apping (n) {Efetua o mapeamento do uxo de dados} {Processa cada atividade estruturada aninhada} for all s in structuredN odes do graph.nodes graph.nodes ActivityGraphN ode(s) {Efetua o mapeamento do uxo de dados} if s is a uml2.ConditionalN ode then {Cria os n os auxiliares para cada se ca o do n o condicional} else if W is an uml2.LoopN ode then {Cria os n os auxiliares para cada se ca o do la co} else ProcessAD(s,graphs) {Processa cada aresta da atividade} for all e in edges do graph.edges graph.edges e OrderingActivityNodes(next, o, n, g ) dataF lowM apping (n) {Efetua o mapeamento do uxo de dados} graphs graphs graph
A representa ca o gr aca de um La co LoopNode e o seu respectivo uxo de controle s ao exibidos na Figura 3.7b. Da mesma forma que na atividade anterior os n os begin e end representam o n o inicial e o n o nal. Nesta atividade existe um n o para cada se ca o setup, test e body. O la co e representado pelo par de arestas (test body ) e (body test ). A aresta (test end ) representa a condi ca o de sa da do la co quando a a ca o test retornar um valor falso. O subgrafo apresentado na Figura 3.7b, representa um la co com a propriedade isTestedFirst setada com valor true. Esta propriedade determina se o teste da condi c ao de sa da do la co ser a executado antes da execu c ao do corpo ou n ao, o valor padr ao e falso. Cada se c ao de uma atividade estruturada e representada no GA por uma a ca o do tipo
21
(a) N o Condicional (ConditionalNode)
(b) La co (LoopNode)
Figura 3.7: Fluxo de Controle das Atividades Estruturadas CallBehaviorAction o que implica a inclus ao de outro diagrama de atividades. Na Figura 3.7 as se c oes s ao representadas por um c rculo duplo, para indicar que estes n os ser ao substitu dos posteriormente pelo subgrafo da atividade vinculada. A terceira etapa do processo consiste na substitui c ao dos n os do GA correspondentes a `s atividades estruturadas e a co es CallBehaviorAction pelos seus respectivos subgrafos. Cada grafo gerado na etapa anterior e percorrido. Quando um n o correspondente a uma a ca o CallBehaviorAction e encontrado, este n o e substitu do pelo subgrafo do comportamento vinculado ` a a ca o. O n o e retirado do grafo original, as arestas de entrada do n o substitu do s ao direcionadas para o n o inicial do subgrafo, e as arestas de sa da do n o substitu do s ao transferidas para o n o nal do subgrafo. Na Figura 3.7 e poss vel observar que cada se c ao de uma atividade estruturada, representada por um c rculo duplo, pode conter uma a ca o CallBehaviorAction. Cada um destes n os e removido e substitu do pelo subgrafo correspondente. Para os n os correspondentes a `s a c oes estruturadas o procedimento e similar, ou seja, os n os tamb em s ao substitu dos pelos respectivos subgrafos. Este processo e feito recursivamente at e que n ao existam mais n os para serem substitu dos. No nal deste processo cada opera c ao (procedimento) existente no modelo ter a o seu GA completo. Formalmente um n o do GA pode ser denido como: ActivityN ode {Action, BasicActivity, ControlN ode, AuxiliaryN ode} onde: Action a ca o UML
22
BasicActivity atividade b asica (InitialNode, ActivityFinalNode ) ControlN ode n o de controle (DecisionNode, MergeNode ) AuxiliaryN ode n o auxiliar gerado na transforma c ao de uma atividade estruturada
J a uma aresta do GA pode ser denida como: ActivityEdge {N ormalEdge, AuxiliaryEdge} onde: N ormalEdge AuxiliaryEdge aresta de uxo de controle entre n os ActivityN ode aresta de uxo de controle entre n os AuxiliaryN ode, gerada na transforma c ao de uma atividade estruturada
O Grafo de Atividades e denido formalmente pela seguinte tupla: ActivityGraph = N odes,iN ,f N ,Edges
<
>
onde: N odes ActivityN ode, conjunto de todos os n os internos do GA iN , f N n o inicial e n o nal do GA Edges ActivityEdge, conjunto de todos as arestas do GA
Para demonstrar o processo de constru ca o do GA vamos apresentar a especica ca o da opera ca o service(), composta pelo conjunto de atividades mostrados na Figura 3.8. Este exemplo modela o comportamento de um componente de software abstrato que possui um u nico servi co. A Figura 3.8(a) apresenta a atividade principal desse servi co, que recebe como entrada dois inteiros, representados pelos par ametros a e b. Os par ametros s ao repassados para os n os internos atrav es de arestas de uxo de dados que ligam o par ametro at e o pino de entrada do n o destino. A atividade service() e constitu da por uma atividade estruturada (s1 ). Esta atividade e um n o protegido que permite a utiliza ca o de tratadores de exce c ao. Neste caso, existem dois tratadores de exce c ao que ligam o n o protegido com as a c oes respons aveis pelo tratamento: h1 e h2. As a c oes que representam o corpo do tratador de exce co es s ao do tipo CallBehaviorAction, ou seja, abstraem um comportamento especicado em outra atividade. As atividades que especicam o tratamento das exce co es s ao mostradas nas Figuras 3.8(e) e 3.8(f). A atividade estruturada s1 possui tr es n os condicionais internos: cn1, cn2 e cn3. Cada um deles possui apenas uma cl ausula, ou seja, um par de se co es. A primeira se c ao correspondente ao teste condicional e a segunda se ca o corresponde ao corpo do n o condicional. Cada corpo e constitu do por uma a ca o do tipo CallBehaviorAction. As Figuras
23
Figura 3.8: Especica c ao da opera c ao service()
3.8(b), 3.8(c) e 3.8(d) s ao as atividades correspondentes aos corpos dos n os condicionais cn1, cn2 e cn3 respectivamente. Por quest oes de espa co as atividades que correspondem a `s se c oes de teste t1, t2 e t3 n ao s ao apresentadas, para facilitar o entendimentoe, as condi co es de teste foram colocadas como r otulo das a co es. Submetendo o conjunto de atividades da Figura 3.8 como entrada para os Algoritmos 1 e 2, obtemos o grafo de atividades mostrado na Figura 3.9. O grafo resultante e a combina c ao dos subgrafos individuais de cada atividade e representa o uxo de controle da opera c ao service().
24
Figura 3.9: Grafo de Atividades da opera c ao service()
25
3.3.2
Obten c ao do Grafo de Fluxo de Controle a partir do GA
No segundo passo, o GA gerado no passo anterior e transformado em um Grafo de Fluxo de Controle (GFC). Cada n o do GFC representa um bloco b asico de atividades do GA, o qual n ao possui nenhum desvio de controle no seu interior, exceto ao nal do bloco. Assim, um conjunto de n os do GA podem ser agrupados em um u nico n o do GFC. Durante a constru ca o do GFC alguns n os do GA s ao mapeados para n os exclusivos no GFC, s ao eles: i) CallOperationAction : esta a ca o representa a chamada de um procedimento, no GFC este n o representa um n o de chamada a outro procedimento; ii) DecisionNode e MergeNode : estes dois n os representam respectivamente a ramica ca o e a jun ca o do uxo de controle; iii) AuxiliarNode : representa o n o auxiliar inserido no GA para representar o desvio do uxo de controle de uma atividade estruturada; iv) RaiseExceptionAction : esta a ca o representa o lan camento de uma exce ca o, e o n o correspondente indica o in cio do uxo de exce ca o; v) Exceptional Exit : n o de sa da excepcional criado quando uma exce ca o n ao e capturada por nenhum dos tratadores de exce ca o denidos dentro da opera ca o. Os n os de chamada de procedimento CallOperationAction e o n o de sa da excepcional Exceptional Exit s ao criados para permitir a representa ca o do uxo de controle e de exce co es interprocedimental. No nal deste processo cada opera c ao (procedimento) existente no modelo ter a o seu GFC gerado. Os Algoritmos 3 e 4, apresentados a seguir s ao utilizados na constru ca o do GFC. Algoritmo 3 GenerateCFG(graphs, cf gs) Entrada: Conjunto de grafos de atividades (GA) graphs Sa da: Conjunto de grafos de uxo de controle (GFC) graph.
1: 2: 3: 4: 5: 6: 7: 8: 9:
{Processa cada grafo de atividades} for all ag in graphs do cf g ControlF lowGraph() node N ode() cf g.nodes cf g.nodes node f irst ag.f irstN ode {Recupera o primeiro n o do GA} ProcessCFG(f irst, node, cf g ) cf gs cf gs cf g return cf gs Formalmente um GFC pode ser representado pela tupla: ControlF lowGraph = CF GN odes,CF GEdges
<
>
onde CF GN odes e CF GEdges s ao novamente particionados em respectivas metaclasses que s ao apresentadas a seguir:
26
CF GN odes = N ,iN ,f N ,EN
<
>
onde: N conjunto de n os do GFC iN , f N n o inicial e n o nal do GFC EN conjunto de n os de sa da excepcional
CF GEdges = P E, EE
<
>
onde: P E EE
conjunto de arestas normais entre os n os do GFC conjunto de arestas de exce ca o entre N e EN
Algoritmo 4 ProcessCFG(m, n, cf g ) Entrada: Conjunto de grafos de atividades (GA) graphs Sa da: Conjunto de grafos de uxo de controle (GFC) graph.
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14:
a m.activity {Atividade UML associada ao n o do GA} predecessor n if a is a uml2.CallOperationAction or a is a uml2.DecisionN ode or a is a AuxiliaryN ode then n N ode() cf g.nodes cf g.nodes N ode() cf g.edges cf g.edges Edge(predecesso, node) else n.activities n.activities m n.uses n.uses m.uses n.def initions n.def initions m.def initions {Percorre cada aresta do GA} for all e in m.edges do target e.target ProcessCFG(target, n, cf g )
27
Figura 3.10: Modelo de Dados do GA e GFC A Figura 3.10 mostra o diagrama de classes utilizado para modelar o Grafo de Atividades e o Grafo de Fluxo de Controle. Mostra tamb em as classes que representam as informa co es de uxo de dados, como vari aveis, tipos de dados e tamb em o relacionamento destas classes com os n os do GA e GFC. O pacote model e a base para a deni c ao dos grafos, nele est ao contidas as classes abstratas Graph, GraphNode e GraphEdge, que modelam respectivamente, um grafo, seus n os e suas arestas. A classe Graph possui um relacionamento bidirecional com a classe GraphNode denindo o atributo nodes que representa o conjunto de n os do grafo. Do lado
28
da classe GraphNode este relacionamento dene o atributo owner que identica o grafo que o n o est a contido. A classe GraphNode possui um relacionamento bidirecional com a classe GraphEdge denindo o atributo edges que representa o conjunto de arestas que partem do n o. Do lado da classe GraphEdge este relacionamento dene o atributo owner que identica o n o que a aresta est a contida. A classe GraphEdge ainda possui outras duas refer encias para a classe GraphNode que denem os atributos source e target, que identicam respectivamente, os n os de origem e destino da aresta. Neste pacote tamb em e denida a classe Model, que serve como container para o modelo. Esta classe possui um relacionamento bidirecional com a classe Graph denindo o atributo graphs que representa o conjunto de grafos contidos no modelo. Do lado da classe Graph, este relacionamento dene o atributo owner que indica o modelo que o grafo est a contido. No pacote activityGraph s ao denidas as classes utilizadas para modelar um GA. A classe ActivityGraph especializa a classe abstrata Graph denindo o pr oprio GA. A classe ActivityGraphNode especializa a classe abstrata GraphNode denindo um n o do GA. Esta classe tamb em possui uma refer encia para a classe ActivityNode do pacote org.eclipse.uml2.uml, que representa um n o do diagrama de atividades. Para cada n o do DA existe um n o correspondente no GA, mas o inverso n ao e verdadeiro, pois alguns n os estruturados do DA acabam gerando mais de um n o no GA. Por exemplo, no mapeamento das atividades estruturadas LoopNode e ConditionalNode para o GA, o n os auxiliares inseridos para representar o in cio e m do uxo de controle dos grafos resultantes n ao possuem atividade correspondente no DA (Figura 3.7). A classe AuxiliarNode especializa a classe ActivityNode denindo um n o auxiliar. As classes InitialAuxiliarNode e FinalAuxiliarNode s ao subclasses de AuxiliarNode. Tamb em s ao denidas neste pacote as classes Scope e Handler, a primeira e utilizada para representar uma regi ao protegida do DA (Por exemplo: Atividade Estruturada, La co ou N o Condicional) e a segunda e utilizada para representar um tratador de exce c oes. Como uma regi ao protegida pode estar aninhada em outras, um determinado n o do GA pode estar contido em v arias regi oes protegidas. O relacionamento entre a classe ActivityGraphNode e a classe Scope dene o atributo scopes, que representa uma pilha de escopos (regi oes protegidas) na qual o n o do GA est a contido. A classe Scope por sua vez possui um relacionamento com a classe Handler denindo o atributo handlers que identica o conjunto de tratadores de exce c ao que est ao associados com a regi ao protegida. As arestas do GA s ao representadas pela classe ActivityGraphEdge que especializa a classe abstrata GraphEdge. O pacote cfg dene as classes utilizadas para modelar um GFC. A classe ControlFlowGraph especializa a classe abstrata Graph denindo o pr oprio GFC. A classe CFGOperation representa a opera c ao que est a associada ao GFC, esta classe possui uma refer encia a classe Operation do pacote org.eclipse.uml2.uml. A classe CFGNode especializa a classe
29
abstrata GraphNode para modelar um n o do GFC. A classes CFGInitialNode e CFGFinalNode especializam a classe GraphNode para modelar, respectivamente, o n o inicial e o n o nal do GFC. As classes CFGCallNode e CFGReturnNode tamb em s ao subclasses de GraphNode e representam o n o de chamada e n o de retorno de uma chamada de opera ca o. As classes CFGRaiseNode, CFGRaiseVariableNode e CFGCatchNode tamb em especializam a classe CFGNode e s ao os n os respons aveis pelo uxo excepcional do GFC. Os dois primeiros respons aveis pelo lan camento e o u ltimo respons avel pelo tratamento de uma exce ca o. A classe CFGNode tamb em possui um relacionamento entre as classes CFGNode e ActivityGraphNode denindo o atributo activityGraphNodes que identica o conjunto de n os do GA que est ao contidos em um n o do GFC. A classe CFGEdge especializa a classe abstrata GraphEdge para modelar uma aresta do GFC. A classe CFGExceptionalEdge e uma subclasse de CFGEdge e representa uma aresta de uxo excepcional ligando o n o que lan ca a exce ca o at e o n o correspondente ao tratador de exce c oes ou sa da excepcional. A classe CFGCallEdge tamb em e uma subclasse de CFGEdge e representa uma aresta de chamada interprocedimental que liga o n o de chamada ao n o inicial do grafo correspondente a opera c ao chamada. No pacote dataow s ao denidas as seguintes classes: MyType dene um tipo de dado de uma vari avel; Variable dene um vari avel; AnalysisDataFlowSets possui um relacionamento com a classe CFGNode e dene quatro conjuntos de vari aveis que s ao utilizados pelos n os durante uma an alise de uxo de dados; DataFlowInformation e uma classe abstrata que dene uma informa c ao de uxo de dados; Denition e Use especializam a classe DataowInformation para representar, respectivamente, um deni ca o e uso de uma vari avel; DataFlowSets possui um relacionamento com as classes ActivityGraphNode e CFGNode para especicar os conjuntos de usos e deni c oes das vari aveis pelos n os .A classe DataFlowInformation possui um relacionamento com a classe Variable para identicar a vari avel associada com a deni c ao ou uso. A classe Denition possui um relacionamento com a classe MyType, este relacionamento dene o atributo instanceType, que determina o tipo de dado da inst ancia do objeto referenciado pela vari avel. A obten ca o das informa c oes de uxo de dados est a impl cita no processo de gera c ao do GA (Algoritmo 2. Durante este processo cada a ca o do DA e avaliada e todas as informa co es referentes ao uxo de dados s ao capturadas. As deni co es e usos das vari aveis capturadas s ao adicionadas ao n o de atividade correspondente. No passo seguinte, quando o GA e transformado em um GFC, cada n o do GFC representa um agrupamento de n os do GA. Todas as deni co es e usos desse conjunto de n os s ao transferidas para o n o do GFC. Para representarmos uma deni c ao formalmente utilizamos uma qu adrupla: Def = di : ref erence : type : object
<
>
30
onde: di ref erence type object
identicador da i - esima ocorr encia de uma deni ca o nome da vari avel ou pino de sa da que sofreu a deni ca o tipo de dado da refer encia tipo de dado do objeto referenciado
A representa ca o utilizada para um c-uso ou p-uso e mais simples, ambos podem ser representada pela tripla:
U se = ui : ref erence : type
<
>
onde: ui identicador da i - esima ocorr encia de uso ref erence nome da vari avel ou pino de entrada que foi utilizado type tipo de dado da refer encia
Na Figura 3.11 e apresentado o GFC resultante da execu c ao dos Algoritmos 3 e 4. As deni co es geradas pelos n os s ao exibidas no conjunto de deni co es def, estas deni co es ser ao utilizadas nas an alises de uxos de dados para gerar tanto o uxo de exce co es intraprocedimental quanto o uxo de interprocedimental.
31
Figura 3.11: Grafo de Fluxo de Controle da opera ca o service()
3.3.3
Cria c ao do Fluxo de Exce co es Intraprocedimentais
O primeiro passo para a cria ca o do uxo de exce co es intraprocedimentais no GFC e a identica c ao dos tipos de exce ca o que podem ser lan cados por um n o determinado n o. O que determina se um n o do GFC lan ca uma exce c ao e a ocorr encia de uma a c ao do tipo RaiseExceptionAction. Sempre que uma a ca o deste tipo e encontrada no GA, durante a gera ca o do GFC, um n o exclusivo para esta a c ao e criado, conforme descrito no t opico 3.3.2. A partir deste n o ter a in cio o uxo de exce co es. No caso de uma exce ca o
32
que e tratada dentro do pr oprio procedimento, uma aresta de exce ca o ir a ligar este n o com o n o correspondente ao tratador de exce ca o compat vel. No caso da exce ca o n ao ser tratada, uma aresta de exce c ao ir a ligar este n o com o n o correspondente a ` sa da excepcional do procedimento. De acordo com o modelo denido (Figura 3.10), no GFC existem dois tipos de n os que podem lan car uma exce c ao, o primeiro e o CFGRaiseNode e o segundo e o CFGRaiseVariableNode. O que determina se um n o do GA, que cont em uma a c ao do tipo RaiseExceptionAction, ser a mapeado para um n o do GFC do tipo CFGRaiseNode ou CFGRaiseVariableNode, e o tipo de a c ao que antecede a a ca o RaiseExceptionAction no DA. Por exemplo, na Figura 3.8(d) a a c ao que fornece o objeto de exce ca o e do tipo ReadVariableAction. Neste caso, o n o criado no GFC e do tipo CFGRaiseVariableNode, pois a a c ao ReadVariableAction l e o conte udo de uma vari avel e passa este valor como entrada para a a ca o que lan ca a exce ca o, o que implica na depend encia da deni ca o da vari avel para a identica ca o do tipo de exce c ao que pode ser lan cada. Caso a a ca o que fornece o objeto de exce ca o seja do tipo CreateObjectAction, n ao existe a depend encia de uma vari avel. Assim, o n o criado no GFC ser a do tipo CFGRaiseNode, pois o tipo de exce ca o lan cada pode ser determinado diretamente pelo tipo do objeto criado pela a ca o CreateObjectAction. Para determinar quais s ao os tipos de exce c ao que podem ser lan cados por um n o do tipo CFGRaiseVariableNode, utilizamos uma an alise de uxo de dados sobre o GFC. Esta an alise consiste no c omputo das deni co es incidentes (reaching denitions). Deni c ao: uma deni ca o d incide num ponto p se existir um percurso do ponto que se segue imediatamente a d at e p, tal que d n ao seja morta ao longo do percurso. Intuitivamente, se uma deni c ao d de alguma vari avel a incide em um ponto p, d poderia ser o local no qual o valor de a usado em p teria sido denido. Matamos uma deni ca o de uma vari avel a se, entre dois pontos ao longo do percurso, existir uma nova deni c ao de a [1]. Para computar as deni c oes incidentes utilizamos o cl assico algoritmo iterativo proposto por Aho et al. [1]. A seguir s ao apresentados os conjuntos e a equa ca o de uxo de dados utilizados pelo algoritmo: geradas[n] = deni c oes geradas pelo n on mortas[n] = deni co es mortas pelo n on entrada[n] = saida[P ]
P predecessores[n]
saida[n]
= geradas[n]
(entrada[n] mortas[n])
Neste tipo de an alise somente os conjuntos de deni c oes s ao utilizados. As deni co es geradas em um n o matam as deni co es correspondentes a ` mesma vari avel nos demais n os.
33
Ap os o c omputo das deni co es incidentes, precisamos inferir quais s ao os tipos de exce co es que podem ser lan cados e quais s ao os poss veis tratadores de exce c ao que podem capturar essas exce co es. Para isso, utilizamos tamb em as informa c oes do contexto das regi oes interrupt veis, das atividades estruturadas e das informa co es dos tratadores de exce ca o extra das do modelo. No caso da ocorr encia de uma vari avel do tipo Exception, a diculdade para inferir o tipo de exce ca o que pode ser lan cada e o fato desta vari avel poder armazenar uma refer encia de qualquer umas das exce c oes que s ao subclasses concretas de Exception. O problema a ser resolvido e identicar, em um dado n o do GFC que lan ca uma exce c ao a partir do uso de uma vari avel e do tipo Exception, quais s ao os tipos de exce co es que podem ser lan cados. Para isso, precisamos computar quais s ao as deni c oes da vari avel e que incidem neste n o. A solu ca o adotada foi a seguinte: como cada deni ca o possui a informa ca o do tipo de dado da inst ancia do objeto referenciado, a partir do conjunto de deni c oes incidentes identicamos o conjunto dos tipos de exce co es que podem estar associados a vari avel e e consequentemente obtemos o conjunto dos tipos de exce c oes que podem ser lan cados pelo n o. Al em de determinar quais tipos de exce ca o podem ser lan cados a partir de um determinado n o, precisamos saber quais tratadores de exce c ao podem capturar a exce c ao lan cada. Como um tratador de exce c ao (ExceptionHandler ) pode estar associado a qualquer atividade estruturada, e necess ario empilhar os contextos (atividades estruturadas) em que cada a ca o est a inclu da. Dessa forma, quando uma a c ao do tipo RaiseExceptionAction e identicada, cada contexto empilhado deve ser analisado para vericar a exist encia de tratadores de exce c ao. Se existir algum, e preciso vericar se e capaz de capturar alguma, dentre as poss veis exce co es lan cadas. Caso exista um tratador de exce c ao equivalente, ou seja, que trate um tipo de exce ca o igual ou mais gen erico daquele que foi lan cado, uma aresta de exce ca o e criada ligando o n o que lan ca a exce ca o com o n o que faz o tratamento da mesma. Caso n ao exista um tratador de exce c ao equivalente, um n o de sa da excepcional e criado. Para demonstrarmos a constru ca o do uxo de exce c oes intraprocedimental voltamos ao exemplo do componente de software abstrato mostrado na Figura 3.8. Apresentamos agora a hierarquia das exce co es contidas no modelo (Figura 3.12). O diagrama de classes cont em onze exce co es, as exce co es internas ao componente s ao identicadas pelo prexo I, j a as exce c oes externas, ou seja, aquelas que s ao propagadas pelo componente, s ao identicadas pelo prexo E.
34
Figura 3.12: Hierarquia de Exce co es No caso do GFC da opera ca o service, mostrado na Figura 3.11, o n o raise e1 lan ca uma exce ca o baseado na vari avel e1. Considerando que esta vari avel e do tipo Exception, podemos armar que pode ser denida por inst ancias de qualquer subclasse de Exception. Como as classes Exception,I Exc, I Exc A, E Exc e E Exc A s ao abstratas e n ao podem ser instanciadas, restam as classes concretas I Exc A1, I Exc A2, I Exc B, E Exc A1, co es n ao s ao sucientes para identicarmos E Exc A2 e E Exc B. Somente estas informa quais destas exce co es de fato podem ser lan cadas pelo n o raise e1, para isso temos que executar uma an alise de uxo de dados. Apresentamos a seguir o resultado do c omputo das deni co es incidentes (reaching denitions ), realizado sobre o GFC da Figura 3.11. Na Tabela 3.3 podemos ver os conjuntos de deni co es globais geradas em cada n o do GFC e na Tabela 3.4 apresentamos o resultado da an alise de uxo de dados. Tabela 3.3: Conjunto de Deni c oes do GFC
n service 4 10 11 begin h1 12 begin h2 13 deni c oes[n] <d1 : e1 : Exception>, <d2 : a : int>, <d3 : b : int> <d9 : output1 : I Exc B : I Exc B >, <d10 : e1 : Exception : I Exc B > <d7 : return : I Exc A : I Exc A >, <d8 : a : int> <d6 : e1 : Exception : I Exc A > <d21 : e : I Exc A > <d4 : e : I Exc A : I Exc A> <d22 : e : I Exc B > <d20 : e : I Exc B : I Exc B > geradas[n] d1, d2, d3 d9, d10 d7, d8 d6 d21 d4 d22 d20 mortas[n] d1 d2 d1, d10 d4 d21 d20 d22
O conjunto de deni c oes incidentes que alcan ca o n o raise e1 e o seguinte: entrada[raise e1] = d1, d2, d3, d6, d7, d8, d9, d10
35
Tabela 3.4: Resultado da An alise das deni c oes incidentes

n service 1 10 11 2 3 4 5 6 7 raise e1 9 begin h1 12 begin h2 13 exit service in[n] d1, d2, d3 d1, d2, d3 d1, d3, d7, d8 d1, d2, d3, d6, d7, d8 d1, d2, d3, d6, d7, d8 d1, d2, d3, d6, d7, d8 d1, d2, d3, d6, d7, d8, d9, d10 d1, d2, d3, d6, d7, d8, d9, d10 d1, d2, d3, d6, d7, d8, d9, d10 d1, d2, d3, d6, d7, d8, d9, d10 d1, d20, d21, d22, d2, d3, d4, d6, d7, d8, d9, d10 d21 d22 d1, d2, d3, d4, d6, d7, d8, d9, d10, d20, d21, d22 out[n] d1, d2, d3 d1, d2, d3 d1, d3, d7, d8 d3, d6, d7, d8 d1, d2, d3, d6, d7, d8 d1, d2, d3, d6, d7, d8 d1, d2, d3, d6, d7, d8 d1, d2, d3, d6, d7, d8, d9, d10 d1, d2, d3, d6, d7, d8, d9, d10 d1, d2, d3, d6, d7, d8, d9, d10 d1, d2, d3, d6, d7, d8, d9, d10 d1, d20, d21, d22, d2, d3, d4, d6, d7, d8, d9, d10 d21 d4, d21 d22 d20, d22 d1, d2, d3, d4, d6, d7, d8, d9, d10, d20, d21, d22
Desse conjunto apenas as deni c oes d1, d6 e d10, que s ao deni c oes da vari avel e1, s ao examinadas para determinar os poss veis tipos de exce co es lan cadas pelo n o. A deni c ao d1 foi gerada pela inicializa ca o da vari avel e1, representada pela a c ao write e1 (Figura 3.10(a)). Neste caso foi atribu da uma refer encia nula a vari avel, por este motivo a deni ca o d1 n ao possui tipo de dado da refer encia. J a a deni c ao d6 foi gerada pela atribui c ao do retorno do m etodo get Exc A(). Como o tipo de retorno desta opera c ao e uma classe abstrata (I Exc A) que possui outras duas subclasses (I Exc A1 e I Exc A2), n ao podemos determinar neste momento o tipo de dado da refer encia. Esta deni c ao somente ocorrer a ap os a execu ca o da an alise de uxo de dados interprocedimental. Dessa forma, a u nica deni ca o v alida e d10 : e1 : Exception : I Exc B , portanto apenas a exce c ao I Exc B foi identicada pela an alise intraprocedimental.
<
>
O pr oximo passo para a constru ca o do uxo excepcional e a procura por um tratador de exce ca o (ExceptionHandler ) compat vel com o tipo I Exc B. Esta procura come ca pela a ca o do tipo RaiseExceptionAction respons avel pelo lan camento da exce c ao no DA. A Figura 3.8(d) mostra a atividade b3 onde a a c ao raise e1 est a contida. Esta atividade e chamada pela a c ao cn3 body, que representa a se ca o do corpo do n o condicional cn3 da atividade service mostrada na Figura 3.8(a). O n o condicional cn3 e a primeira regi ao protegida que o n o raise e1 est a contido, como este n o n ao possui tratadores de exce ca o a busca pelo tratador de exce c oes compat vel continua. A pr oxima regi ao protegida que encapsula o n o condicional e a atividade estruturada s1. Esta atividade possui dois tratadores de exce c ao. o primeiro Exc A est a associado ao tipo de exce ca o I Exc A que
36
n ao e compat vel com o tipo procurado, j a o segundo Exc B tratador est a associado ao tipo de exce ca o I Exc B que e exatamente o tipo de exce ca o identicado pela an alise de uxo de dados. O passo nal e a cria ca o da aresta de exce ca o que liga o n o origem, onde a exce c ao foi lan cada, com o n o destino, respons avel pelo tratamento da exce c ao. No nosso exemplo o n o raise e1 e a origem e o n o destino e identicado a partir do tratador de exce c ao Exc B. Como o tratador de exce ca o invoca a atividade h2, o n o destino e o n o begin h2, que corresponde ao n o inicial da atividade h2.
3.4
Constru c ao do Grafo de Fluxo de Controle Interprocedimental
Quando uma exce c ao e lan cada dentro de uma regi ao protegida, o controle e transferido para um tratador de exce co es capaz de manipular a exce ca o lan cada. Mas, se o tratador de exce co es n ao estiver presente na opera c ao chamada, o objeto de exce ca o e propagado para a opera ca o chamadora. A propaga ca o das exce co es pela pilha de chamada cria o uxo de controle interprocedimental. O uxo de controle interprocedimental e representado pelo Grafo de Fluxo de Controle Interprocedimental (GFCI). Um GFCI para um programa P consiste em um conjunto de GFCs para cada opera ca o em P ; cada n o de chamada e conectado ao n o de entrada da opera ca o chamada por uma aresta de chamada e cada n o de sa da da opera ca o chamada e conectado a um n o de retorno correspondente por uma aresta de retorno. A Figura 3.13 apresenta o uxo de controle interprocedimental no n vel de bloco que mostra a opera ca o chamada, B , no topo e a opera ca o chamadora, A, abaixo. A chamada de B dentro da regi ao protegida de A e mostrada pelo n o de chamada. Se B completar sua execu c ao normalmente, o controle retorna para A atrav es da sa da normal de B . Por outro lado, se B propagar uma exce ca o, o retorno retorna de B atrav es de uma sa da excepcional. Seguindo a sa da excepcional de B , o uxo de controle pode seguir para dois lugares: (i) se o bloco protegido de A tiver um tratador de exce c ao associado, e o tratador de exce c oes for compat vel com a exce c ao lan cada em B , o uxo segue para este tratador; (ii) opera ca o A tamb em sai pela sa da excepcionall, e a procura por um tratador continua na opera c ao que chamou A. Assim, na presen ca de constru c oes para o tratamento de exce c oes, um GFCI cont em arestas adicionais para representar o uxo de controle interprocedimental, que partem de um n o de sa da excepcional do m etodo chamado e terminam no n o do tratador de exce co es ou na sa da excepcional do chamador deste m etodo. Estas arestas s ao chamadas de aresta de retorno excepcional.
3.4. Constru c ao do Grafo de Fluxo de Controle Interprocedimental
37
Figura 3.13: Exceptional Control Flow in UML exception-handling constructs
3.4.1
Gerando o Grafo de Fluxo de Controle Interprocedimental
Um GFCI para um modelo M consiste em um GFC para cada opera ca o contida em M ; cada n o de chamada call node e conectado ao n o de entrada entry node da opera c ao chamada por uma aresta de chamada call edge, e o n o de sa da exit node da opera c ao chamada e conectado com o n o de retorno return node correspondente por uma aresta de retorno return edge. Para representar o uxo de controle interprocedimental, o GFCI cont em arestas de retorno de exce c oes. Uma aresta de retorno de exce ca o e uma aresta interprocedimental que conecta um n o de sa da excepcional exceptional-exit node da opera c ao chamada com o n o de captura de exce c ao catch node ou com outro n o de sa da excepcional da opera c ao chamadora. Se uma opera ca o propaga uma exce c ao que e capturada pelo chamador daquela exce c ao, o n o de sa da excepcional para aquele tipo de exce c ao e conectado com o n o apropriado na opera ca o chamadora por uma aresta de retorno de exce ca o. Uma opera ca o pode propagar uma exce ca o que n ao e tratada na opera c ao chamadora imediata, mas e tratada em uma opera ca o que ca mais acima na cadeia de chamadas. O algoritmo de constru ca o iterativo determina, para cada opera c ao, quais os tipos de exce co es propagadas s ao lan cadas indiretamente na opera ca o, adicionando n os de sa da excepcional para cada tipo de exce ca o ao GFC da opera ca o.
38
3.4.2
Constru c ao do Grafo Resumido da Interface
A an alise de uxo de dados interprocedimental computa informa co es sobre o uxo de dados causado pelos objetos al em dos limites da opera ca o. A abordagem proposta e uma extens ao do m etodo apresentado por Harrold e Soa [8], incluindo o uxo de controle e dados causado pelos tratadores de exce ca o. Esta t ecnica analisa individualmente as opera co es contidas em um modelo com objetivo de abstrair as informa co es intraprocedimentais que s ao utilizadas para construir o Grafo Resumido da Interface (GRI). Um GRI cont em um subgrafo para cada opera ca o. Cada subgrafo representa as informa co es locais sobre a opera c ao que e abstra da para a an alise interprocedimental, incluindo as informa co es sobre os par ametros formais da opera c ao e dos par ametros atuais utilizados pelos n os de chamada da opera ca o. O grafo e constru do considerando as informa co es que vinculam os par ametros formais e atuais para conectar os subgrafos. A abordagem proposta usa quatro tipos de n os, originalmente denidos no trabalho pr evio [8], s ao eles: (en) n o de entrada, (ex) n o de sa da, (cn) n o de chamada, and (rn) n o de retorno. Al em destes n os, esta abordagem dene alguns n os complementares para representar as opera c oes com par ametros de retorno e tamb em n os utilizados para representar a sem antica do modelo de exce co es da UML, s ao eles: (rsn) n o do resultado, (rvn) n o de retorno de valor, (ee) n o de sa da excepcional, (er) n o de retorno de exce ca o, (thn) n o de lan camento e (ctn) n o de captura de exce co es (Figure 3.14). Em um GRI, os pontos de entrada e sa da de uma opera ca o s ao denotados, respectivam m mente, pelo n os enf e exf , ambos criados para cada par ametro formal f de cada opera c ao mn mn m. A chamada e retorno de uma opera ca o s ao representados pelos n os cnx e rnx , respectivamente, ambos os n os s ao criados para cada par ametro x de cada chamada da opera ca o m para a opera ca o n. Os par ametros de retorno de uma opera ca o s ao denotados n ametro de retorno r da chamada de uma opera ca o pelos n os rsnr , criados para cada par mn n e os n os rvns s ao criados para cada par ametro de resultado s da opera ca o m. Uma vez que, cada n o representa uma simples vari avel, os conjuntos de deni co es de um n o correspondem a um simples par ametro formal, atual, de retorno ou de resultado. A propaga ca o de exce c oes entre opera co es s ao denotadas pelos n os een e ermn , onde estes n os representam o conjunto de todas as deni c oes de exce c oes que s ao propagadas entre as opera co es. Finalmente, a propaga ca o de deni c oes de exce co es do n o de lan camento para rh h os n os de captura s ao denotadas pelos n os thne e ctne , e ambos s ao criados para cada par ametro de exce c ao e que e lan cado a partir do n o de lan camento r no bloco protegido h. Intraprocedural, or local information is computed about denitions of formal and actual parameters that reaches these control points and is attached to the appropriate nodes in the subgraph. At entry and exit points of a operation, local denitions information is abstracted for formal parameters, while at call and return nodes, local denition infor-
3.4. Constru c ao do Grafo de Fluxo de Controle Interprocedimental
39
Figura 3.14: Interface Summary Graph mation is abstracted about actual parameter involved in the call. Reaching edges (Figure 3.14) abstract the control information from the operation. For example, reaching edge from an entry node to a call node indicates that a denition of the formal parameter that reaches the beginning of the operation also reaches the call site where it is used as an actual parameter. The interaction among the operations is used to connect the subgraphs. Binding edges correspond to the bindings of the formal and actual parameters, and the bindings of exception parameters of exception handling constructs. Interreaching edges from call nodes to return abstract the control information about the called procedures at call sites. This edge indicates that a denition that reaches the procedure call may be preserved after the return from the procedure. The interreaching edges allow the calling context of the called procedures to be preserved during propagation.
3.4.3
Interprocedural Exception Analysis
Our approach is a combination of the intraprocedural and interprocedural data-ow analysis. This approach rst performs the intraprocedural analysis, and following propagates
40
the results to the Interface Summary Graph nodes for perform the interprocedural analysis. Finally, we construct the interprocedural exceptional control-ow. Interprocedural reaching denitions are obtained by propagating the local denition information. The propagation of the denitions is in the forward direction throughout the ISG, taking into account the calling context of called procedures. Indef [n] and Outuse [n] refer to the reaching denitions sets associated with node n. To preserve the calling context of called procedures and ensures that only possible control paths in the program are considered, these sets are computed in two phases. Thus, in phase one of the propagation, cn, rn, ex, thn, er, rsn, rvn nodes and all edges are considered, while in phase two, all nodes are considered, but edges are restricted to call binding, reaching, and interreaching. Propagation must be restricted to these edges to prevent transversal of paths through the ISG that do not represent control paths through the program. Propagation over the call binding edges is a problem, the interreaching edges facilitate the propagation of the uses to the call and entry nodes without transversing the call binding edges. The dataow equation for interprocedural reaching denitions is the same presented for intraprocedural analysis and the dataow equation for exception propagation, used in the er node for an operation o, are: gen[er] = set of exception types that can be raised by o kill[er] = set of caught exception types within o in[er] = out[P ]
P predecessors[er]
out[er] = gen[er]
(in[er] kill[er])
3.5
Ferramenta de Valida c ao
A ferramenta de valida ca o ...
3.5. Ferramenta de Valida c ao
41
Figura 3.15: Grafo de Fluxo de Controle Interprocedimental
Cap tulo 4 Parte III - Estudos de Caso

Apresenta ca o dos estudos de caso ....
4.1
Sistema de Minera c ao
O primeiro caso de estudo ...
4.2
Outros Modelos
O segundo caso de estudo ...
43
Cap tulo 5 Conclus oes e Trabalhos Futuros

Trabalhos futuros .... A an alise de uxo de dados auxilia n ao s o na cria ca o do GFC com uxo de exce co es, mas auxilia tamb em para determinar as anomalias nesse uxo. Assim, por exemplo, o modelador pode ser informado sobre as exce co es que n ao s ao tratadas na opera c ao, e determinar se elas ser ao lan cadas para serem tratadas pela opera ca o que efetuou a sua chamada. Outra alternativa de valida ca o e comparar os tipos de exce co es que s ao efetivamente lan cados, com os tipos de exce co es lan cados na modelagem das opera co es.
45
Refer encias Bibliogr acas

[1] Alfred V. Aho, Ravi Sethi, and Jerey D. Ullman. Compilers-Principles, Techniques, and Tools. Addison-Wesley, Boston, MA, 1986. [2] Paul Ammann and Je Outt. Introduction to Software Testing. Cambridge University Press, 2008. [3] Conrad Bock. Uml 2 activity and action models. Journal of Object Technology, 2(4), July-August 2003. [4] Conrad Bock. Uml 2 activity and action models part 2: Actions. Journal of Object Technology, 2(5), September-October 2003. [5] G. Booch. Object-oriented analysis and design with applications, 2nd ed. BenjaminCummings Publishing Co., 1993. [6] Marcio Eduardo Delamaro, Jos e Carlos Maldonado, and Mario Jino. Introdu c ao ao Teste de Software. Editora Campus, 2007. [7] James Gosling, Bill Joy, Guy Steele, and Gilad Bracha. Java(TM) Language Specication, The (3rd Edition). Addison-Wesley Professional, 2005. [8] Mary Jean Harrold and Mary Lou Soa. Ecient computation of interprocedural denition-use chains. ACM Transactions on Programming Languages and Systems, 16(2):175204, 1994. [9] I. Jacobson, M. Christerson, and L. L. Constantine. The OOSE method: a usecasedriven approach. SIGS Publications Inc., 1994. [10] OMG. Uml 2.1.2 superstructure specication, November 2007. [11] Sandra Rapps and Elaine J. Weyuker. Selecting software test data using data ow information. IEEE - Transactions on Software Engineering, 11(4), 1985. 47
48
REFERENCIAS BIBLIOGRAFICAS
[12] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-Oriented Modeling and Design. Prentice Hall, 1990.

Ferreira 2011

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ferreira 2011

Загружено:

Авторское право:

Доступные форматы

Valida c ao do Fluxo Excepcional a partir do Diagrama de Atividades da UML 2.

Campinas, 12 de dezembro de 2010.

Eliane Martins (Orientadora)

Instituto de Computa c ao Universidade Estadual de Campinas

Valida c ao do Fluxo Excepcional a partir do Diagrama de Atividades da UML 2.0

Departamento de Apicultura Subterr anea Computacional

Jeferson Ferreira, 2010.

Todos os direitos reservados.

Cap tulo 1 Introdu c ao

Cap tulo 2 Parte I - Fundamenta c ao Te orica

Tratamento de exce c oes ...

An alise de Fluxo de Dados

Cap tulo 2. Parte I - Fundamenta ca o Te orica

Trabalhos relacionados ...

Cap tulo 3 Parte II - A Abordagem Proposta

Cap tulo 3. Parte II - A Abordagem Proposta

Figura 3.1: Diagrama de Atividades

3.1. Diagrama de Atividades

N o de Inicializa c ao (InitialNode): e o n o inicial do uxo de uma atividade. Uma

N o Final de Atividade (ActivityFinalNode): a chegada do primeiro token a este n o

N o de Intercala c ao (MergeNode): tem a mesma nota c ao que um n o de ramica ca o,

Cap tulo 3. Parte II - A Abordagem Proposta

N o de Bifurca c ao (ForkNode): divide o uxo em m ultiplos uxos concorrentes. Os

sincroniza os m ultiplos uxos, combinando os tokens

N o Final de Fluxo (FlowFinalNode):

3.1. Diagrama de Atividades

N o de Atividade Estruturada (StructuredActivityNode):

uma atividade estruturada utilizada para representar um la La co (LoopNode): E co.

Cap tulo 3. Parte II - A Abordagem Proposta

Atividades Estruturadas Atividades Estruturadas Extras

3.1. Diagrama de Atividades

Sem antica de A c oes da UML 2.0

Cap tulo 3. Parte II - A Abordagem Proposta

3.1. Diagrama de Atividades

Cap tulo 3. Parte II - A Abordagem Proposta

Tratamento de exce c oes no DA

3.1. Diagrama de Atividades

Cap tulo 3. Parte II - A Abordagem Proposta

3.2. Descri c ao da Abordagem

A descri c ao da abordagem ...

Constru c ao do Grafo de Fluxo de Controle

A constru c ao do GFC ...

Constru c ao do Grafo de Atividades

Cap tulo 3. Parte II - A Abordagem Proposta

Algoritmo 1 OrderingActivityNodes(n, e, p, g ) Entrada: N o do DA n, Aresta do DA e, N o predecessor p. Sa da: Grafo ordenado g .

3.3. Constru c ao do Grafo de Fluxo de Controle

Cap tulo 3. Parte II - A Abordagem Proposta

3.3. Constru c ao do Grafo de Fluxo de Controle

(a) N o Condicional (ConditionalNode)

Cap tulo 3. Parte II - A Abordagem Proposta

3.3. Constru c ao do Grafo de Fluxo de Controle

Figura 3.8: Especica c ao da opera c ao service()

Cap tulo 3. Parte II - A Abordagem Proposta

Figura 3.9: Grafo de Atividades da opera c ao service()

3.3. Constru c ao do Grafo de Fluxo de Controle

Obten c ao do Grafo de Fluxo de Controle a partir do GA

Cap tulo 3. Parte II - A Abordagem Proposta

CF GN odes = N ,iN ,f N ,EN

onde: N conjunto de n os do GFC iN , f N n o inicial e n o nal do GFC EN conjunto de n os de sa da excepcional

conjunto de arestas normais entre os n os do GFC conjunto de arestas de exce ca o entre N e EN

3.3. Constru c ao do Grafo de Fluxo de Controle

Cap tulo 3. Parte II - A Abordagem Proposta

3.3. Constru c ao do Grafo de Fluxo de Controle

Cap tulo 3. Parte II - A Abordagem Proposta