Patterns of Tracing Software Structures and Dependencies

More documents

Recommendations

Info

In many cases, a client can directly use a parser’s outputs and, for instance, interpret them asan event flow. The advantage of this is that the client has much control over trace informationextraction. But when trace information extraction requires more complex, application-specificinterpretation, the corresponding extraction code is tangled in the client. That means the clientcode gets more complex. It also means in many cases that the interpretation code in the clientit is not reusable for other clients. If it is necessary to traverse or navigate through the traceinformation, flow-based output formats can be cumbersome to work with.SolutionTherefore: Parse the source language documents with the (given) source language parserand use its outputs to create a parse tree. Provide a suitable interface for tree traversal.Then use this interface to build an application-specific PARSE TREE INTERPRETER that offersoperations to extract the required trace information. If trace information modificationis required, the tree traversal interface additionally provides means to modify the parsetree elements and structure, and the PARSE TREE INTERPRETER offers operations to modifythe trace information application-specifically.Source Documentdoc13a) read document 3b) add tokenParserParse Tree Builder1) parse document("doc1") 2) parse document3c) create token tree elementClient4a) query trace informationParse Tree Interpreter4b) get trace informationToken TreeA typical PARSE TREE INTERPRETER parses a source document and builds someknowledge representation of the trace information contained in the document. Italso provides an application-specific API for querying the trace information.ExampleDiscussionConsider again you want to extract the Java class structure. Parsers for Java are available.Consider your parser creates a token stream, one token for each lexical element in the Javacode. After a scanner has scanned the code for all tokens, a method nextToken of a tokenizerclass extracts the next lexical token as a string.In a token tree builder [GHJV94], this method is repetitiously called with a loop and all relevantstatements are extracted. For each token containing a statement, the builder creates a newnode for the parse tree. In case of a statement in which other statements can nest (like a classstatement), we have to create all nested statements as child nodes. The builder can use existingtree and traversal API implementations (like a DOM [W3C00] tree).The PARSE TREE INTERPRETER uses the parser and tree builder to create its internal parse treerepresentation. For clients it provides operations for extracting the Java class structure, such asgetClasses, getSuperclass, or getInterfaces. Note that these operations provide applicationspecificinterpretations of the trace information in the parse tree.To build a PARSE TREE INTERPRETER the parser’s output has to be converted into a tree representation.There are different parser outputs possible, such as token or event streams, parse trees,
and others. Some tree-based parser outputs offer a suitable parse tree representation, othershave to be converted. Token or event streams also have to be converted into a tree representation.If a conversion of the parsed data is necessary, we have to walk through the wholeparsed data in the order of appearance in the source document, and call factories [GHJV94] orbuilders [GHJV94] for the targeted tree representation.The pattern parser/builder [Ber96] reads in data from a stream and builds up a respective,generic object structure using a factory [GHJV94]. The pattern can be used for the parsingpart of a PARSE TREE INTERPRETER if there is a need to interpret a raw data stream with a generictree structure.The parse tree representation should be “suitable,” meaning that the tree’s node structuresshould represent the language structure and that the offered tree traversal methods should supportthe application-specific requirements of the application effectively and efficiently:• Regarding the tree’s node structure, in case of a programming language, typically onenode object per statement is created (it is also possible to create one node per lexicaltoken, but this is usually overkill). Nested statements are represented as child nodes.Attributes of statements are represented as node object properties. Each node objecttype represented one kind of statement in the source language.• Regarding the offered tree traversal methods the parse tree can either offer a tree traversalAPI to navigate through the tree and/or a visitor [GHJV94] that step-by-step visits allnodes of a (sub-)tree.The interpretation step following the parsing step is implemented on the PARSE TREE INTER-PRETER class. This class uses the domain knowledge about the interpreted language and therequired trace information to effectively and efficiently extract (and perhaps modify) the traceinformation. Note that different, application-specific PARSE TREE INTERPRETER classes can reusethe same parse tree and parser implementations.If modification of data is supported, usually an operation to write the modifications back intothe source language is supported. This can be done with a visitor that visits all elements of thetree and converts them into the source language format.A PARSE TREE INTERPRETER avoids implementing a new parser for the source language. However,some existing parsers have very complex outputs, bugs, or other practical problems that causemore work than writing a simple PARTIAL INTERPRETER would cause. A PARSE TREE INTERPRETERcan only extract information that are (statically) given in the source documents.Indirection LayerContextProblemYou want to extract trace information from a system or sub-system.Trace information can consist of information in electronic documents (such as the sourcecode), but also of information derived from dynamic invocation data (and data flows).It is hard to integrate these two kinds of trace information, as the former is staticallyprovided in the sources, whereas the later is obtained from the running system. How togather and integrate all relevant static and dynamic trace information in a unique way?
Page 1 and 2: Patterns of Tracing Software Struct
Page 3 and 4: Trace InformationTracing structures
Page 5: extractstaticallyextractstaticallyT
Page 9 and 10: it is necessary anyway. For instanc
Page 11 and 12: mechanism for application objects t
Page 13 and 14: All TRACE CALLBACK operations are o
Page 15 and 16: can be a domain-specific set of a f
Page 17 and 18: Source Document...void setName(Stri
Page 19 and 20: RECTION LAYER?ProblemDetailsSolutio
Page 21 and 22: MESSAGE INTERCEPTOR is only invoked
Page 23 and 24: eturn infoVars();...Sub-classes (e.
Page 25 and 26: InvocationContext ic = getCurrentIn
Page 27 and 28: ExampleConsider again documenting i
Page 29 and 30: endings. In a simple MESSAGE REDIRE
Page 31 and 32: Usually the adaptation defined in t
Page 33 and 34: (i.e. an INDIRECTION LAYER is used)
Page 35 and 36: [HT99][KdRB91][KHH + 01][KLM + 97][

Patterns of Tracing Software Structures and Dependencies

Create successful ePaper yourself

Delete template?

Save as template?