Using Graph Rewriting to Specify Software Architectural Transformations

 Blaze Chambers
 7 months ago
 Views:
Transcription
1 Using Graph Rewriting to pecify oftware Architectural ransformations Hoda Fahmy Richard C. Holt Dep t. of Computer cience Dep t. of Computer cience University of oronto University of Waterloo Abstract In order to understand, analyze and possibly modify software, we commonly examine and manipulate its architecture. For example, we may want to examine the architecture at different levels of abstraction or repair the architecture if it has deviated from our mental model of the software. We can view such manipulations as architectural transformations, and more specifically, as graph transformations. In this paper, we use graph rewriting to specify these transformations so that we can work towards automating them. pecifically, we use the PROGRE tool to formulate executable graphrewriting specifications for various architectural transformations in order to demonstrate the strengths of using graph rewriting. We have applied our executable specifications to small graphs and our results confirm the following: Graph rewriting offers a highlevel, visual notation that can be used to neatly specify graph modifications as well as support prototype implementation. It also provides a convenient and intuitive framework for exploring various architectural transformations. Keywords: software architecture, graph rewriting, software maintenance, program understanding 1. Introduction In reengineering a software system, one of the first steps is to extract from the code the depencies amongst the lowlevel software components. Just as important, we need to determine the system hierarchy: how are the modules grouped into subsystems and how are the subsystems grouped into higher level subsystems? It is our position that the component interactions, together with the system hierarchy, define the software s structure or architecture. Upon obtaining the system structure via some extraction tool such as Acacia[5], Rigi[10], or PB[13], we can use a directed typed graph G to represent it (Figure 1). Each node in the graph represents a component in the system, while each edge represents a relation between components. We can have different types of nodes such as module nodes and subsystem nodes; we can have different types of relations such as contain and use. he contain relation defines the system hierarchy, whereas the use relation defines various types of depencies. e c W a b d Figure 1. Graphical representation of a software architecture. Nodes representing subsystems have thick lines; nodes representing modules have thin lines. In this example, contains subsystems and V; contains module e and subsystem W; subsystem W contains modules c and d; and subsystem V contains modules a and b; module a uses b, c and d; c uses b; and d uses e. We often need to manipulate the information provided by the extraction tools in order to understand, analyze and possibly modify the software. In doing so, we are in fact performing transformations on the graph G. he transformations, which are commonly applied to the graph models of the software architectures, can be classified into three classes [6]: V
2 (1) ransformations for understanding. We use these transformations when we wish to explore and understand the software structure. For example, we may want to create different views of the structure. (2) ransformations for analysis. We use these transformations to discover various kinds of information about the software system. For example, we may want to know what modules interact in a cyclic pattern. his kind of information is commonly used to determine how we will go about modifying the system. (3) ransformations for modification. We use these transformations to change the system structure. For example, we may want to transform the architecture to meet new requirements [4], or we may want to repair the structure if, from our analysis, we find unexpected interactions between subsystems. able 1 lists the transformations which commonly occur during reengineering; they can all be described in terms of graph transformations [6]. ince it would be desirable to automate these transformations, we need to capture these transformations in a mechanical way. Feijs uses a relational approach to model some of these transformations [7], and similarly, Holt uses arski s algebra [8]. In this paper, we use a graphrewriting formalism to specify these graph transformations since graph rewriting is useful in computations where a graph data structure needs to be modified. Its main advantage over the other approaches is that it offers a highlevel, graphical and expressive notation. Each architectural transformation can be specified using a graphrewrite rule or a set of graphrewrite rules. he application of a graphrewrite rule to a host graph G (1) identifies a pattern in G, and then (2) transforms G based on that pattern. We demonstrate the usefulness of graph rewriting using PROGRE, a visual language based on graph rewriting, to formulate executable specifications for these architectural transformations. ection 2 provides an introduction to graph rewriting and PROGRE; ection 3 describes a scenario to which we apply graph rewriting; ection 4 describes the prototype tool developed; ection 5 gives some conclusions. 2. Graph Rewriting & PROGRE Graph rewriting is a promising formalism in which the transformation of graph structures can be modeled and studied [2]. Graph rewriting, or more accurately, graph grammars, were proposed in [12] as an extension to string grammars to manipulate multidimensional patterns. Before getting into the details of graph rewriting, we provide an informal description of the way graph rewriting works. able 1. Architectural ransformations Commonly Occurring during Reengineering Class ype Description Architecture Understanding Architecture Analysis Architecture Modification Lifting Hide Interior/ Exterior Diagnostic ifting Forward Repair Reverse Repair Lift lowlevel use edges up the system hierarchy in order to study the structure at different levels of abstraction [7,8,11] Eliminate information to make the structure more understandable by zooming in and out to concentrate on views of interest [8] Given highlevel unexpected edges, lower them down the system hierarchy to identify lowlevel unexpected edges [7,11,15] Mark components that play some role in the desired change of the software structure [6] Alter the extracted architecture (or concrete architecture) to be more consistent with the mental model of the software (i.e, conceptual architecture) [15] Alter the conceptual architecture to be more consistent with the concrete architecture [15] Each graphrewrite rule minimally consists of LH RH, where LH (Left Hand ide) and RH (right hand side) are graphs. uccessful application of the rule to a graph G performs a local update on G by replacing a subgraph that matches LH by a copy of RH. Refer to Figure 2. If several subgraphs matching LH are found, one subgraph is chosen randomly. Due to the multidimensionality of graphs, there are many ways of attaching the copy of RH to the host graph; thus each graphrewrite rule needs to specify an embedding. he embedding refers to the way in which a copy of RH is to be attached to the host graph. Figures 2c and 2d show two possible embeddings when rule 2a is applied to graph shown in 2b. If the embedding associated with the rule
3 LH RH V W e W d a (a) An example of a graphrewrite rule specifying the deletion of a Wlabeled node (b) he host graph. hown shaded is a subgraph matching LH. V V e e d a d a (c) he result of applying the rule shown in (a) to the graph shown in (b) if the embedding specifies that the labeled node adopts the edges of the Wlabeled node as well. (d) he result of applying the rule shown in (a) to the graph shown in (b) if the embedding specifies that the labeled node does not adopt any new edges Figure 2. Application of a graphrewrite rule. he graphrewrite rule shown in (a) is applied to the host graph shown in (b). his transforms the graph in (b) into a result such as (c) or (d), deping on how the copy of RH is embedded in the graph. Note that we use the same notation as the graph shown in Figure 1, and that the graph shown in (b) is in fact a subgraph of that shown in Figure 1. shown in Figure 2a specifies that the node not only retains its edges, but also adopts the node W s edges, the result is the graph shown in Figure 2c. If the embedding specifies that the node gains no new edges, the result is the graph shown in Figure 2d. here are many ways to specify graphrewrite rules [1]. Here, we choose to use the visual graphrewriting language PROGRE [2,9,14], since the PROGRE programming environment is the most mature tool currently available for the specification and execution of graphrewriting systems. Its name is an acronym for
4 PROgrammed Graph REwriting ystems. One of its main strengths lies in the fact it uses a graphical syntax where appropriate (e.g., for entering LH and RH) but does not exclude textual syntax when it is more natural and concise. Its integrated programming environment offers means for syntaxdirected editing, type checking, interactive debugging, graph browsing, and rapid prototyping activities. he remainder of this section will highlight graph rewriting in the context of architectural transformations using PROGRE. In order that the reader understand the basic concepts in graph rewriting, we introduce a minimal set of PROGRE features, and thus, the PROGRE specifications provided in this paper are not very efficient. ection 2.1 describes the PROGRE graph schema; ection 2.2 describes PROGRE rules and ection 2.3 discusses how we can control the order of application of the rules in PROGRE PROGRE Graph chema PROGRE supports the manipulation of directed, attributed, typed graphs, where: Each node has a type. hroughout this paper, we assume we have two types of nodes: modules and subsystems. Each node type belongs to a node class, and node classes are arranged in a is_a hierarchy. For example, the module and subsystem node types belong to the COMPONEN class. Each node class may be associated with a set of attributes. Attributes store information that is not conveniently expressed within the graph structure itself. Attributes may be of any type, including integer, real, and string. hus, each node has a type as well as a (possibly empty) set of attributes. For example, in this paper, nodes belonging to the node class COMPONEN are associated with a name attribute storing the name of the subsystem or module, as well as two boolean attributes, InWrong and InteractsWithOne, which are by default set to false. (InWrong (i.e., in wrong subsystem) is true if there is reason to believe the software component is in the wrong subsystem. InteractsWithOne (i.e., interacts with one subsystem) is true for component x if all the components which use x and is used by x all belong to the same subsystem. We will see in ection 3.2 how these node attributes are used in the repair of a software structure.) Each edge has a type. Parallel edges between nodes are allowed, provided that they are of different types or different directions. hroughout this paper, we assume we have three edge types: contain, use and unexpected. and unexpected edges are permitted between module and subsystem nodes. ubsystem nodes are permitted to have module and subsystem nodes as children (i.e, they can have outgoing contain edges to module and subsystem nodes); however module nodes cannot have any nodes as children PROGRE Rules A PROGRE graphrewrite rule begins with the keyword production followed by the rule name and parameters. (ee Figure 3.) Next come the graphs LH and RH. Within a production, LH nodes are referred to as `1, `2, `3,... and RH nodes are referred to as 1, 2, 3,... he programmer uses LH and RH to test and modify the graph structure. Attributes are tested by the condition clause and modified by the transfer clause. For example, consider the rule HideInterior (Figure 3). he condition clause states that the Name attribute for node `1 should equal Name, which is passed as a parameter. his rule does not have a transfer clause; refer to Figure 5 for a rule that does. he production rule can be applied to a subgraph only if that the subgraph is isomorphic to LH and also satisfies the condition clause. As was illustrated in Figure 2, a production needs to specify the embedding that should be used for RH. In PROGRE, by default, embeddings use node preserving notation such as 1 =`1 in RH of production HideInterior. his notation means that LH node `1 and RH node 1 refer to the same node in the host graph. his host graph node is not deleted, and it is not recreated when a copy of RH is made. Instead, this node is preserved during the graph transformation. here is no change to the node type, attribute values, or embedding edges. If the user wishes to define a more general embedding, he or she can use the embedding clause of a production. In production HideInterior, the embedding clause specifies that all the incoming and outgoing contain, use, and unexpected edges of node `2 are to be redirected to node 1. It is sometimes necessary to test for the existence of paths between two nodes of LH, where a path is a sequence of edges. PROGRE allows one to do this by defining path conditions. he path condition can be built using sequences, alternatives, and iterations of traversal operations. For instance, we can define an Ancestor path between two component nodes to consist of a sequence of one or more incoming contain edges. If we want to test if node a is an ancestor of node b, we can do this graphically by using an Ancestorlabeled double arrow from node b to node a. (ee example in Figure 4.)
5 production HideInterior(Name: string) = condition `1: ubsystem `2: COMPONEN `1.Name = Name; embedding redirect > from `2 to 1 ; redirect < from `2 to 1'; redirect > from `2 to 1'; redirect < from `2 to 1'; redirect Unexpected> from `2 to 1'; redirect <Unexpected from `2 to 1'; Figure 3. he HideInterior rule using PROGRE notation. his rule is used to implement the Hide Interior transformation (able 1). We use this transformation when we are not interested in details of a particular subsystem. he goal is to hide the interior of the subsystem while showing how it interacts with the rest of the system. his rule takes as a parameter the name of the subsystem whose interior we would like to hide. he LH of the rule contains two nodes: node `1 must be a subsystem node, while node `2 must belong to the COMPONEN node class (i.e., it may be a module or subsystem node). he RH contains just one node. he 1 =`1 notation means that node `1 of LH and node 1 of RH refer to the same node in the host graph. he embedding clause specifies that any contain/use/unexpected incoming/outgoing edges from node `2 are to be redirected to node 1. hus, if we apply this rule passing as a parameter ( ) to the graph shown in Figure 2(b), the result is the graph shown in Figure 2(c), if node `2 matches the Wlabeled node. (Note that node `2 of LH may also match node e of Figure 2(b)). 1 =`1 ometimes we need to test for the nonexistence of nodes, edges, and paths. For example, consider the rule ModuleInWrong shown in Figure 5. his rule determines if a module is not used by and does not use any other component within the same subsystem. We test this in PROGRE by using crossed out nodes. he nonexistence of edges and paths can be tested using the condition clause of the production or tested graphically in the LH by using crossed out edges or paths. Refer to Figure 4. In summary, for a rule to be successfully applied, we need to find a subgraph in G which matches LH (testing for the existence and nonexistence of nodes as well as the existence and nonexistence of edges and paths). Once a match is found, the condition clause is evaluated. If it is evaluated to true, then we can replace the matched subgraph by a copy of RH, embedding it in the host graph using the embedding specified in the rule. We can then use the transfer clause, if one exists, to modify or set the attribute values of the replacement nodes Organizing the Rules ometimes, we need to control the order of application of the rules. In PROGRE, this is done using transactions. A transaction, beginning with the keyword transaction, is very much like a procedure in other languages. ransactions can have input parameters, output parameters, and call other transactions (including itself). ransaction Lifting given below specifies that we apply production Lift_ (Figure 4) repeatedly until it fails (i.e., no successful match is found) upon which the loop terminates: transaction Lifting = loop begin Lift_ ince we do not pass any parameters, this transaction is applied to the whole graph. Applying Lifting to the graph shown in Figure 1 results in the graph shown in Figure 6. his completes our introduction of graph rewriting and PROGRE. We now turn to an example showing how we can apply graph rewriting to a typical softwaremaintenance problem.
6 production Lift_ `1:ubsystem `3:ubsystem 1 =`1 3 =`3 `2:Module Ancestor `4:Module Ancestor 2 =`2 4 =`4 condition not (`1 in `3.Ancestor) or not (`3 in `1.Ancestor); Figure 4. he Lift_ graphrewrite rule using PROGRE notation. his rule is used to implement a lifting transformation (able 1). We use this transformation to raise lowlevel use relations to higher levels in the system hierarchy in order to study the architecture at different levels of abstraction. pecifically, this rule specifies that if module x uses module y, and x is a descant of PX and y is a descant of PY, then we lift the use edge (x,y) to (PX,PY) only if PX and PY are distinct nodes and PX is not a descant or ancestor of PY. he Ancestorlabeled double arrow is used to test for the existence of an Ancestor path between nodes `2 and `1 as well as nodes `4 and `3. he crossedout uselabeled edge between nodes `1 and `3 is used to ensure that we only form a new use edge if one does not already exist. he condition clause tests that node `1 is not an ancestor/descant of node `3. We could have tested this condition graphically by using crossedout Ancestorlabeled double arrows. production ModuleInWrong = `1:ubsystem 1 =`1 `3:Module `4:Module `2:Module 2 =`2 condition `2.InWrong = false; transfer 2'.InWrong := true; Figure 5. he ModuleInWrong graphrewrite rule using PROGRE notation. his rule is used to implement a sifting transformation (able 1). his rule determines those modules which do not use and are not used by any other module within its subsystem. his suggests that the module has been misplaced and should be moved to another subsystem. Each node in the graph has a boolean attribute InWrong which by default is false. he crossedout nodes are used to test the nonexistence of a sibling of node `2 which uses/is used by node `2, while the condition clause tests that the InWrong attribute is still false. uccessful application of this rule sets InWrong to true via the transfer clause. We will see in ection 3 how this sifting transformation is used during the repair of an architecture.
7 e c W a b d Figure 6. Applying the Lifting ransaction to the graph shown in Figure 1. Edges resulting from lifting the lowlevel use relations are shown as thick dashed edges. For example, since c uses b, subsystem W uses subsystem V. 3. Application of Graph Rewriting to Architecture Repair In order to demonstrate the use of architectural transformations in software maintenance, and specifically to demonstrate the potential role of graph rewriting in automating these transformations, we describe a typical scenario in reengineering. In this scenario, we have extracted the structure from a software system and represented it as a graph G. he goal is to repair the structure if it has deviated from our mental model of the system 1. We assume that the extraction process has provided us with only modulemodule depencies. Our mental (or conceptual model) contains depencies amongst subsystems, rather than modules. Hence, we need to lift the modulemodule depencies to the subsystem level for comparison with the conceptual model. If there are discrepancies, then we need to determine their causes (i.e., at the module level). We can then try to minimize the discrepancies by restructuring the architecture. In summary, we need to complete the following subtasks: (1) Lifting: We need to lift the lowlevel uses to the high level in order to determine the subsystemsubsystem depencies. 1 We are currently concentrating on automating repair at the architectural level, not at the sourcecode level. hus, any modification to the source code reflecting the change at the architectural level needs to be performed manually. V (2) Diagnosis: At this point, we want to identify any unexpected depencies at the subsystem level, and determine the lowlevel modulemodule depencies that are causing the unexpected depencies. (3) Repair: Finally, we want to try to minimize the unexpected depencies. here are a variety of lifting functions we can apply to the input graph [7,8,11]. In the last section, we described one such function which is implemented by the Lifting transaction; it repeatedly applies the Lift_ graphrewrite rule (Figure 4) to the input graph until it is no longer applicable. Applying this Lifting transaction to the graph shown in Figure 1 results in the graph shown in Figure 6. Having shown how we can automate lifting, this rest of this section will describe how we can automate diagnosis (ection 3.1) and repair (ection 3.2) using executable graphrewriting specifications Diagnosis Given only the modulemodule interactions, it is difficult to determine whether the concrete model of the software is consistent with our conceptual model of the software. However, if we perform lifting to determine how the subsystems interact (Figure 6), it becomes easier to determine the inconsistencies. After examining the graph shown in Figure 6, let us assume that we have determined that subsystem unexpectedly deps on V; we expected that uses V but not vice versa. We can use the parameterized graphrewrite rule Make_Unexpected to change the label of the edge from to V from use to unexpected. his rule is illustrated in Figure 7. We now want to identify lowerlevel edges which are causing the highlevel unexpected edge. We do this by applying the Lower_Unexpected transaction (not shown here) which does the opposite of the lifting transformation. pecifically, if there is an unexpected edge (x,y), then any use edge from x or any of x s descant, to y, or any of y s descants, is changed to an unexpected edge. We define a transaction named Diagnosis to describe this two step process: transaction Diagnosis( Name, Name : string) = Make_Unexpected ( Name, Name ) & Lower_Unexpected Applying transaction Diagnosis(, V ) to the graph shown in Figure 6 results in the graph shown in Figure 8. We can apply this transaction for each highlevel unexpected depency identified by the user.
8 production Make_Unexpected (Name, Name: string) = condition (`1.Name = Name) and (`2.Name= Name); Figure 7. he Make_Unexpected graphrewrite rule. It is used to convert a uselabeled edge to an unexpectedlabeled edge. he parameters define the source and target node names of the uselabeled edge to be converted. e c W a b d Figure 8. Applying the Diagnosis ransaction to the graph shown in Figure 6. he problematic or unexpected relations are shown as thick dashed edges. Once we assert that should not use V, then this information is lowered down the system hierarchy. We find out that W should not use V and c should not use b Repair `1:COMPONEN `1=Node Unexpected `2:COMPONEN `2=Node In our scenario, we have analyzed the system and determined that there are inconsistencies between it and V our conceptual model. Now we would like to repair the structure to make it more consistent with the conceptual model. One way to do this is to perform kidnapping [15]. Kidnapping moves a module or subsystem from its original subsystem to a new one. It is a safe transformation because it does not modify the source code, and so the code s semantics are not changed. ran [15] performed kidnapping to repair Linux. For example Linux has seven toplevel subsystems, two of which are the Network Interface subsystem and the Process cheduler subsystem [3]. he Process cheduler subsystem unexpectedly deped on the Network Interface, and ran determined that the inet.h module, which is only used by modules in the Network Interface subsystem, was the cause of this depency. By having the Network Interface subsystem kidnap inet.h, the unexpected depency was eliminated. his type of action is ideal for automation. We will now illustrate how we can automate the kidnapping of modules from one subsystem to another using graph rewriting. First of all, we need to determine good kidnapping candidates. One possibility is to consider those modules which do not use and are not used by any module within its subsystem. hose modules have perhaps been misplaced. he question becomes, which subsystem should kidnap the misplaced module? If the misplaced module x uses and is used by modules which all belong to the same subsystem Y, then subsystem Y should kidnap module x. We can apply sifting transformations (able 1) to determine these ideal kidnapping candidates; specifically we can define a PROGRE transaction named ifting which applies the rule ModuleInWrong shown in Figure 5 as well as the transaction ModuleInteractsWithOne, not given here. As mentioned in ection 2.1, the COMPONEN node class has two boolean attributes, InWrong and InteractsWithOne, which by default are set to false. Applying the rule ModuleInWrong repeatedly to the graph sets the InWrong attribute to true for all misplaced modules. he transaction ModuleInteractsWithOne sets the InteractsWithOne attribute to true for all modules which interact with only one subsystem. Once we determine which modules are good candidates to be kidnapped into another subsystem, we can apply a kidnapping transformation to actually move the module from one subsystem to another if it is involved in an unexpected depency. his transformation is expressed in the rules KidnapModule1 and KidnapModules2. (Only KidnapModule1 is shown in Figure 9; KidnapModule2 is similar to KidnapModule1 except node `2 is the target of an unexpectedlabeled edge rather than the source.) Once the module is kidnapped, its InWrong value is set to false (refer to the transfer clause), and the unexpectedlabeled edge becomes a uselabeled edge (RH of the production). After we minimize
9 the lowlevel unexpectedlabeled edges by applying KidnapModule1 and KidnapModule2 rules, we need to eliminate highlevel unexpectedlabeled edges which are no longer relevant. o do so we can apply the graphrewrite rule FixUnexpectedEdges not shown here. In summary, assuming, we have applied the transaction ifting, our repair transformation takes the form of the following PROGRE transaction: transaction aferepairbykidnapping = loop begin KidnapModule1 or KidnapModule2 & loop begin FixUnexpectedEdges ince the kidnapped modules are not used by and do not use any modules outside of their new subsystem, we do not run the risk of creating new unexpected depencies by performing this type of repair. However, it could very well be that successful application of the transaction aferepairbykidnapping does not remove any highlevel unexpectedlabeled edges. Applying aferepairby Kidnapping to the graph shown in Figure 8 results in the graph shown in Figure 11. In this case, there is only one possible place to apply the kidnapping transformation (KidnapModule1) ubsystem V kidnaps module c from ubsystem W. his results in the removal of unexpected edges (c,b), (W,V) and (,V). here are many types of repair that we may perform to help minimize the unexpected depencies. In this section, we have chosen a simple one in order that the graphrewriting concepts presented in this paper are made clear. Other types of repair are discussed in [15] and are beyond the scope of this paper ummary In this section, we illustrated how we can use graph rewriting to specify and automate various architectural transformations. We demonstrated the potential use of graph rewriting by describing a problem and showing how we can help solve it using graph rewriting. Here, we summarize the solution by defining the PROGRE transaction MAIN, which calls the various transactions given in this section: transaction MAIN = Lifting & ifting & Diagnosis(Name,Name) & aferepairbykidnapping production KidnapModule1 = condition `2.InWrong = true and `2.InteractsWithOne = true; transfer 2'.InWrong := false; Figure 9. A Graphrewrite rule to implement kidnapping. his rules moves a module which is involved in an unexpected depency to another subsystem if it does not use or is not used by any module within its subsystem and yet the modules it uses/is used by all belong to the same subsystem. e `1:ubsystem `2:Module `1:ubsystem `2:Module W a c b d Unexpected `3:ubsystem `4:Module Figure 10. Repairing the system shown in Figure 8. We have applied the aferepairbykidnapping transaction to the graph shown in Figure 8. When we kidnap c from subsystem W to subsystem V then W and no longer use V. Note that component c has all its original use edges. V `3:ubsystem `4:Module
10 his transaction is applied to a graph representing a software architecture where only lowlevel use relations are provided (such as that shown in Figure 1). 4. Prototype Generation and Results We used the PROGRE tool to automatically generate C code for the specifications we formulated. After compiling the code, we obtained a prototype system, which allowed us to execute the specifications. he prototype allows us to read in and display an input graph and apply the various architectural transformations to it. Each rule and transaction specified appears as a menu item within the prototype environment and the user can choose the rule or transaction which she or he wants applied to the graph. For example, we can choose the rule Lift_ (Figure 4) which results in just one application of the rule if a successful match is found. Or, we can choose the transaction MAIN given above, which results in the application of the Lifting, ifting, Diagnosis 2 and aferepairbykidnapping transactions all in that order. We applied the transformations outlined in this paper to graphs, consisting of less than one hundred nodes, which allowed us to test for the correctness of our specifications. Although we made use of many PROGRE features to increase efficiency, PROGRE is not able to manipulate larger graphs efficiently. his is an obvious obstacle if one is to use this tool to perform software architectural transformations, especially since most software systems consist of hundreds of modules. Much research in the graph rewriting community is currently focussed on the development of efficient graphrewriting tools [2]. Regardless of PROGRE performance, our results confirm that graph rewriting offers a highlevel, visual notation that can be used to neatly specify graph modifications as well as support prototype implementation. It also provides a convenient an intuitive framework for describing architectural transformations in a unified way. 5. Conclusions In order to automate the architectural transformations that commonly occur during reengineering, we need to specify them in a formal way. In this paper, we have successfully shown how we can specify them using graph rewriting. By testing our specifications on small graphs using the PROGRE tool, we have demonstrated graph rewriting s main strength. It provides a clear, intuitive, highlevel, visual description of architectural transformations. Having obtained such a description, we can now work 2 If the parameters of the Diagnosis transaction are not given explicitly (e.g., "","V"), then the user is prompted for them. towards automating many of the transformations. Perhaps as more research focuses on the development of efficient graphrewriting tools, we will be able to use these tools to perform transformations on architectures of large software systems. References [1] D. Blostein, H. Fahmy, A. Grbavec. Issues in the Practical of Graph Rewriting, Lecture Notes in Computer cience, Vol. 1073, 1996, pp [2] D. Blostein and A. chürr. Computing with Graphs and Graph ransformations, oftware Practice and Experience, Vol. 29(3), pp , [3] I.. Bowman, R.C. Holt, and N.V. Brewster. Linux as a Case tudy: Its Extracted oftware Architecture, Proceedings in the 21 st International Conference on oftware Engineering, Los Angeles, May [4].J. Carriere,. Woods, and R. Kazman. oftware Architectural ransformation, Proc Working Conference on Reverse Engineering, Oct [5] Y.F.Chen, M.Y. Nishimoto, and C.V. Ramamoorthy. he C Information Abstraction ystem, IEEE ransactions on oftware Engineering, Vol. 16, pp , [6] H. Fahmy and R.C. Holt. oftware Architecture ransformations, to appear in the Proceedings of the International Conference on oftware Maintenance, an Jose, Oct [7] L. Feijs, R. Krikhaar and R. Van Ommering. A Relational Approach to upport oftware Architecture Analysis, oftwarepractice and Experience, Vol. 28(4), pp , April [8] R.C. Holt. tructural Manipulations of oftware Architecture Using arski Relational Algebra, Proceedings of the 5th Working Conference on Reverse Engineering 1998, Honolulu, Hawaii, October 1214, [9] C.E. Hrischuk. Implementing Angio race Analysis using the Graph Rewriting ool PRORE. Available at [10]H. Muller, O. Mehmet,. illey, J. Uhl. A Reverse Engineering Approach to ubsystem Identification, oftware Maintenance and Practice, Vol. 5, pp , [11] G.C. Murphy, D. Notkin, and K. ullivan. oftware Reflexion Models: Bridging the Gap Between ource and HighLevel Models, Proceedings of the hird ACM ymposium on the Foundations of oftware Engineering, Oct [12] J.Pfaltz and A. Rosenfeld, Web grammars, Proc. 1 st Int. Joint Conf. Artificial Intelligence, Washington, 1969, pp [13]Portable Bookshelf (PB) tools. Available at [14] PROGRE. Available at [15]J.B. ran and R.C. Holt. Forward and Reverse Repair of oftware Architecture, Proceedings of the IBM CA Conference, Nov
11
Using Architectural Models at Runtime: Research Challenges
Proceedings of the European Workshop on Software Architectures, St. Andrews, Scotland, May 2004. Using Architectural Models at Runtime: Research Challenges David Garlan and Bradley Schmerl Department of
More informationLecturer 2: Spatial Concepts and Data Models
Lecturer 2: Spatial Concepts and Data Models 2.1 Introduction 2.2 Models of Spatial Information 2.3 ThreeStep Database Design 2.4 Extending ER with Spatial Concepts 2.5 Summary Learning Objectives Learning
More informationModule 1 Lecture Notes 2. Optimization Problem and Model Formulation
Optimization Methods: Introduction and Basic concepts 1 Module 1 Lecture Notes 2 Optimization Problem and Model Formulation Introduction In the previous lecture we studied the evolution of optimization
More informationTransformation of structured documents with the use of grammar
ELECTRONIC PUBLISHING, VOL. 6(4), 373 383 (DECEMBER 1993) Transformation of structured documents with the use of grammar EILA KUIKKA MARTTI PENTTONEN University of Kuopio University of Joensuu P. O. Box
More informationMaximal Monochromatic Geodesics in an Antipodal Coloring of Hypercube
Maximal Monochromatic Geodesics in an Antipodal Coloring of Hypercube Kavish Gandhi April 4, 2015 Abstract A geodesic in the hypercube is the shortest possible path between two vertices. Leader and Long
More informationmapping IFC versions R.W. Amor & C.W. Ge Department of Computer Science, University of Auckland, Auckland, New Zealand
mapping IFC versions R.W. Amor & C.W. Ge Department of Computer Science, University of Auckland, Auckland, New Zealand ABSTRACT: In order to cope with the growing number of versions of IFC schema being
More informationITERATIVE MULTILEVEL MODELLING  A METHODOLOGY FOR COMPUTER SYSTEM DESIGN. F. W. Zurcher B. Randell
ITERATIVE MULTILEVEL MODELLING  A METHODOLOGY FOR COMPUTER SYSTEM DESIGN F. W. Zurcher B. Randell Thomas J. Watson Research Center Yorktown Heights, New York Abstract: The paper presents a method of
More informationLL(k) Parsing. Predictive Parsers. LL(k) Parser Structure. Sample Parse Table. LL(1) Parsing Algorithm. Push RHS in Reverse Order 10/17/2012
Predictive Parsers LL(k) Parsing Can we avoid backtracking? es, if for a given input symbol and given nonterminal, we can choose the alternative appropriately. his is possible if the first terminal of
More informationUNITIV BASIC BEHAVIORAL MODELINGI
UNITIV BASIC BEHAVIORAL MODELINGI CONTENTS 1. Interactions Terms and Concepts Modeling Techniques 2. Interaction Diagrams Terms and Concepts Modeling Techniques Interactions: Terms and Concepts: An interaction
More informationKeywords: Abstract Factory, Singleton, Factory Method, Prototype, Builder, Composite, Flyweight, Decorator.
Comparative Study In Utilization Of Creational And Structural Design Patterns In Solving Design Problems K.Wseem Abrar M.Tech., Student, Dept. of CSE, Amina Institute of Technology, Shamirpet, Hyderabad
More informationEclipse Support for Using Eli and Teaching Programming Languages
Electronic Notes in Theoretical Computer Science 141 (2005) 189 194 www.elsevier.com/locate/entcs Eclipse Support for Using Eli and Teaching Programming Languages Anthony M. Sloane 1,2 Department of Computing
More informationTable : IEEE Single Format ± a a 2 a 3 :::a 8 b b 2 b 3 :::b 23 If exponent bitstring a :::a 8 is Then numerical value represented is ( ) 2 = (
Floating Point Numbers in Java by Michael L. Overton Virtually all modern computers follow the IEEE 2 floating point standard in their representation of floating point numbers. The Java programming language
More informationER Model. Hi! Here in this lecture we are going to discuss about the ER Model.
ER Model Hi! Here in this lecture we are going to discuss about the ER Model. What is EntityRelationship Model? The entityrelationship model is useful because, as we will soon see, it facilitates communication
More informationOntology Matching with CIDER: Evaluation Report for the OAEI 2008
Ontology Matching with CIDER: Evaluation Report for the OAEI 2008 Jorge Gracia, Eduardo Mena IIS Department, University of Zaragoza, Spain {jogracia,emena}@unizar.es Abstract. Ontology matching, the task
More informationPolicy Analysis and Verification by Graph Transformation Tools
GraBaTs 04 Preliminary Version Policy Analysis and Verification by Graph Transformation Tools Yujie Zhao and Francesco ParisiPresicce George Mason University  USA Abstract Policies are used to control
More informationINTRODUCING A MULTIVIEW SOFTWARE ARCHITECTURE PROCESS BY EXAMPLE Ahmad K heir 1, Hala Naja 1 and Mourad Oussalah 2
INTRODUCING A MULTIVIEW SOFTWARE ARCHITECTURE PROCESS BY EXAMPLE Ahmad K heir 1, Hala Naja 1 and Mourad Oussalah 2 1 Faculty of Sciences, Lebanese University 2 LINA Laboratory, University of Nantes ABSTRACT:
More informationJOURNAL OF OBJECT TECHNOLOGY
JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2003 Vol. 2, No. 6, NovemberDecember 2003 UML 2 Activity and Action Models Part 3:
More informationFunctional Dependency: Design and Implementation of a Minimal Cover Algorithm
IOSR Journal of Computer Engineering (IOSRJCE) eissn: 22780661,pISSN: 22788727, Volume 19, Issue 5, Ver. I (Sep. Oct. 2017), PP 7781 www.iosrjournals.org Functional Dependency: Design and Implementation
More information1. NUMBER SYSTEMS USED IN COMPUTING: THE BINARY NUMBER SYSTEM
1. NUMBER SYSTEMS USED IN COMPUTING: THE BINARY NUMBER SYSTEM 1.1 Introduction Given that digital logic and memory devices are based on two electrical states (on and off), it is natural to use a number
More informationBasic Structure of Denotational Definitions
asic Structure of Denotational Definitions This chapter presents the format for denotational definitions. We use the abstract syntax and semantic algebra formats to define the appearance and the meaning
More informationStatistics Case Study 2000 M. J. Clancy and M. C. Linn
Statistics Case Study 2000 M. J. Clancy and M. C. Linn Problem Write and test functions to compute the following statistics for a nonempty list of numeric values: The mean, or average value, is computed
More informationFMA901F: Machine Learning Lecture 6: Graphical Models. Cristian Sminchisescu
FMA901F: Machine Learning Lecture 6: Graphical Models Cristian Sminchisescu Graphical Models Provide a simple way to visualize the structure of a probabilistic model and can be used to design and motivate
More information5 The Control Structure Diagram (CSD)
5 The Control Structure Diagram (CSD) The Control Structure Diagram (CSD) is an algorithmic level diagram intended to improve the comprehensibility of source code by clearly depicting control constructs,
More informationNOTES ON OBJECTORIENTED MODELING AND DESIGN
NOTES ON OBJECTORIENTED MODELING AND DESIGN Stephen W. Clyde Brigham Young University Provo, UT 86402 Abstract: A review of the Object Modeling Technique (OMT) is presented. OMT is an objectoriented
More information
Automatic Test Markup Language Sept 28, 2004
Automatic Test Markup Language Sept 28, 2004 ATML Document Page 1 of 16 Contents Automatic Test Markup Language...1 ...1 1 Introduction...3 1.1 Mission Statement...3 1.2...3 1.3...3 1.4
More informationCompiler Design. Subject Code: 6CS63/06IS662. Part A UNIT 1. Chapter Introduction. 1.1 Language Processors
Compiler Design Subject Code: 6CS63/06IS662 Part A UNIT 1 Chapter 1 1. Introduction 1.1 Language Processors A compiler is a program that can read a program in one language (source language) and translate
More informationAbout the Tutorial. Audience. Prerequisites. Copyright & Disclaimer. Compiler Design
i About the Tutorial A compiler translates the codes written in one language to some other language without changing the meaning of the program. It is also expected that a compiler should make the target
More informationUNIT V SYSTEM SOFTWARE TOOLS
5.1 Text editors UNIT V SYSTEM SOFTWARE TOOLS A text editor is a type of program used for editing plain text files. Text editors are often provided with operating systems or software development packages,
More informationWorkflow Modeling for Virtual Processes: an OrderPreserving ProcessView Approach
In: Information Systems Workflow Modeling for Virtual Processes: an OrderPreserving ProcessView Approach DuenRen Liu Minxin Shen Institute of Information Management, National Chiao Tung University 1001
More informationReducing Directed Max Flow to Undirected Max Flow and Bipartite Matching
Reducing Directed Max Flow to Undirected Max Flow and Bipartite Matching Henry Lin Division of Computer Science University of California, Berkeley Berkeley, CA 94720 Email: henrylin@eecs.berkeley.edu Abstract
More informationDATA MODELS FOR SEMISTRUCTURED DATA
Chapter 2 DATA MODELS FOR SEMISTRUCTURED DATA Traditionally, real world semantics are captured in a data model, and mapped to the database schema. The real world semantics are modeled as constraints and
More informationSimulating Task Models Using Concrete User Interface Components
Simulating Task Models Using Concrete User Interface Components David Paquette Department of Computer Science University of Saskatchewan dnp972@cs.usask.ca April 29, 2004 Abstract Interaction Templates
More informationInterprocess Communication By: Kaushik Vaghani
Interprocess Communication By: Kaushik Vaghani Background Race Condition: A situation where several processes access and manipulate the same data concurrently and the outcome of execution depends on the
More informationHarvard School of Engineering and Applied Sciences Computer Science 152
Harvard School of Engineering and Applied Sciences Computer Science 152 Lecture 17 Tuesday, March 30, 2010 1 Polymorph means many forms. Polymorphism is the ability of code to be used on values of different
More informationSQL Functionality SQL. Creating Relation Schemas. Creating Relation Schemas
SQL SQL Functionality stands for Structured Query Language sometimes pronounced sequel a veryhighlevel (declarative) language user specifies what is wanted, not how to find it number of standards original
More informationJava Learning Object Ontology
Java Learning Object Ontology MingChe Lee, Ding Yen Ye & Tzone I Wang Laboratory of Intelligent Network Applications Department of Engineering Science National Chung Kung University Taiwan limingche@hotmail.com,
More informationComplexity Theory. Compiled By : Hari Prasad Pokhrel Page 1 of 20. ioenotes.edu.np
Chapter 1: Introduction Introduction Purpose of the Theory of Computation: Develop formal mathematical models of computation that reflect realworld computers. Nowadays, the Theory of Computation can be
More informationOn Meaning Preservation of a Calculus of Records
On Meaning Preservation of a Calculus of Records Emily Christiansen and Elena Machkasova Computer Science Discipline University of Minnesota, Morris Morris, MN 56267 chri1101, elenam@morris.umn.edu Abstract
More informationLecture 5. Logic I. Statement Logic
Ling 726: Mathematical Linguistics, Logic. Statement Logic V. Borschev and B. Partee, September 27, 2 p. Lecture 5. Logic I. Statement Logic. Statement Logic...... Goals..... Syntax of Statement Logic....2.
More informationPutting Static Analysis to Work for Verification
Putting Static Analysis to Work for Verification A Case Study Tomasz Dudziak Based on a paper by T. LevAmi, T. Reps, M. Sagiv, and R. Wilhelm 23 June 2010 Topic Goal A very capable shape analysis that
More informationDERIVING SPATIOTEMPORAL RELATIONS FROM SIMPLE DATA STRUCTURE
DERIVING SPATIOTEMPORAL RELATIONS FROM SIMPLE DATA STRUCTURE Ale Raza ESRI 380 New York Street, Redlands, California 9373800, USA Tel.: +909793853 (extension 009) Fax: +9093073067 araza@esri.com
More informationThe Use of Process Clustering in DistributedSystem Event Displays
The Use of Process Clustering in DistributedSystem Event Displays David J. Taylor Abstract When debugging a distributed application, a display showing the events causing interactions between processes
More informationUnit 4 Relational Algebra (Using SQL DML Syntax): Data Manipulation Language For Relations Zvi M. Kedem 1
Unit 4 Relational Algebra (Using SQL DML Syntax): Data Manipulation Language For Relations 2014 Zvi M. Kedem 1 Relational Algebra And SQL SQL is based on relational algebra with many extensions Some necessary
More informationOBJECT ORIENTED PROGRAMMING USING C++ CSCI Object Oriented Analysis and Design By Manali Torpe
OBJECT ORIENTED PROGRAMMING USING C++ CSCI 5448 Object Oriented Analysis and Design By Manali Torpe Fundamentals of OOP Class Object Encapsulation Abstraction Inheritance Polymorphism Reusability C++
More informationAn Object Model for Multiparadigm
1 of 7 03/02/2007 15:37 http://www.dmst.aueb.gr/dds/pubs/conf/1994oopslamultipar/html/mlom.html This is an HTML rendering of a working paper draft that led to a publication. The publication should always
More informationA Catalog of While Loop Specification Patterns
A Catalog of While Loop Specification Patterns Aditi Barua and Yoonsik Cheon TR #1465 September 2014 Keywords: functional program verification, intended functions, program specification, specification
More informationCS106X Handout 03 Autumn 2012 September 24 th, 2012 Getting Started
CS106X Handout 03 Autumn 2012 September 24 th, 2012 Getting Started Handout written by Julie Zelenski, Mehran Sahami, Robert Plummer, and Jerry Cain. After today s lecture, you should run home and read
More informationXETA: extensible metadata System
XETA: extensible metadata System Abstract: This paper presents an extensible metadata system (XETA System) which makes it possible for the user to organize and extend the structure of metadata. We discuss
More informationCS 411 Midterm Feb 2008
CS 411 Midterm Feb 2008 Exam number: P1: / 9 P4: / 10 P2: / 4 P5: / 9 Student Name: P3: / 7 P6: / 8 P7: / 8 SUBTOTALS: / 20 / 35 Student ID number: TOTAL: / 55 READ THIS CAREFULLY BEFORE PROCEEDING DO
More informationSpecification of ContentDependent Security Policies
Specification of ContentDependent Security Policies David L. Spooner Mathematical Sciences Department Rensselaer Polytechnic Institute Troy, NY 12181 Abstract: The protection of information from unauthorized
More informationA Fitness Function to Find Feasible Sequences of Method Calls for Evolutionary Testing of ObjectOriented Programs
A Fitness Function to Find Feasible Sequences of Method Calls for Evolutionary Testing of ObjectOriented Programs Myoung Yee Kim and Yoonsik Cheon TR #757 November 7; revised January Keywords: fitness
More informationSTRUCTURES AND STRATEGIES FOR STATE SPACE SEARCH
Slide 3.1 3 STRUCTURES AND STRATEGIES FOR STATE SPACE SEARCH 3.0 Introduction 3.1 Graph Theory 3.2 Strategies for State Space Search 3.3 Using the State Space to Represent Reasoning with the Predicate
More informationModeling software evolution by evolving interoperation graphs
Annals of Software Engineering 9 (2000) 235 248 235 Modeling software evolution by evolving interoperation graphs Václav Rajlich Department of Computer Science, Wayne State University, Detroit, MI 48202,
More informationProgramming with Math and Logic
.. Programming with Math and Logic an invitation to functional programming Ed Morehouse Wesleyan University The Plan why fp? terms types interfaces The What and Why of Functional Programming Computing
More informationCapturing and Formalizing SAF Availability Management Framework Configuration Requirements
Capturing and Formalizing SAF Availability Management Framework Configuration Requirements A. Gherbi, P. Salehi, F. Khendek and A. HamouLhadj Electrical and Computer Engineering, Concordia University,
More informationLet us dene the basic notation and list some results. We will consider that stack eects (type signatures) form a polycyclic monoid (introduced in [NiP
Validation of Stack Eects in Java Bytecode Jaanus Poial Institute of Computer Science University of Tartu, Estonia email: jaanus@cs.ut.ee February 21, 1997 Abstract The Java language is widely used in
More informationFlexFlow: Workflow for Interactive Internet Applications
FlexFlow: Workflow for Interactive Internet Applications Rakesh Mohan, Mitchell A. Cohen, Josef Schiefer {rakeshm, macohen, josef.schiefer}@us.ibm.com IBM T.J. Watson Research Center PO Box 704 Yorktown
More informationPerspectives on User Story Based Visual Transformations
Perspectives on User Story Based Visual Transformations Yves Wautelet 1, Samedi Heng 2, and Manuel Kolp 2 1 KU Leuven, Belgium yves.wautelet@kuleuven.be, 2 LouRIM, Université catholique de Louvain, Belgium
More informationConfiguration Management for Componentbased Systems
Configuration Management for Componentbased Systems Magnus Larsson Ivica Crnkovic Development and Research Department of Computer Science ABB Automation Products AB Mälardalen University 721 59 Västerås,
More information3D Object Scanning to Support ComputerAided Conceptual Design
ABSTRACT 3D Object Scanning to Support ComputerAided Conceptual Design J.S.M. Vergeest and I. Horváth Delft University of Technology Faculty of Design, Engineering and Production Jaffalaan 9, NL2628
More informationFundamental Concepts. Chapter 1
Chapter 1 Fundamental Concepts This book is about the mathematical foundations of programming, with a special attention on computing with infinite objects. How can mathematics help in programming? There
More informationChapter 3. Set Theory. 3.1 What is a Set?
Chapter 3 Set Theory 3.1 What is a Set? A set is a welldefined collection of objects called elements or members of the set. Here, welldefined means accurately and unambiguously stated or described. Any
More informationLECTURE 6: INTRODUCTION TO FORMAL METHODS. Software Engineering Mike Wooldridge
LECTURE 6: INTRODUCTION TO FORMAL METHODS Mike Wooldridge 1 What are Formal Methods? Formal methods is that area of computer science that is concerned with the application of mathematical techniques to
More informationFast Introduction to Object Oriented Programming and C++
Fast Introduction to Object Oriented Programming and C++ Daniel G. Aliaga Note: a compilation of slides from Jacques de Wet, Ohio State University, Chad Willwerth, and Daniel Aliaga. Outline Programming
More informationReliability Allocation
Reliability Allocation Introduction Many systems are implemented by using a set of interconnected subsystems. While the architecture of the overall system may often be fixed, individual subsystems may
More informationTopk Keyword Search Over Graphs Based On Backward Search
Topk Keyword Search Over Graphs Based On Backward Search JiaHui Zeng, JiuMing Huang, ShuQiang Yang 1College of Computer National University of Defense Technology, Changsha, China 2College of Computer
More information/ Approximation Algorithms Lecturer: Michael Dinitz Topic: Linear Programming Date: 2/24/15 Scribe: Runze Tang
600.469 / 600.669 Approximation Algorithms Lecturer: Michael Dinitz Topic: Linear Programming Date: 2/24/15 Scribe: Runze Tang 9.1 Linear Programming Suppose we are trying to approximate a minimization
More informationAN EFFICIENT IMPLEMENTATION OF NESTED LOOP CONTROL INSTRUCTIONS FOR FINE GRAIN PARALLELISM 1
AN EFFICIENT IMPLEMENTATION OF NESTED LOOP CONTROL INSTRUCTIONS FOR FINE GRAIN PARALLELISM 1 Virgil Andronache Richard P. Simpson Nelson L. Passos Department of Computer Science Midwestern State University
More informationA SIMULATION ARCHITECTURE DESCRIPTION LANGUAGE FOR HARDWAREINLOOP SIMULATION OF SAFETY CRITICAL SYSTEMS
A SIMULATION ARCHITECTURE DESCRIPTION LANGUAGE FOR HARDWAREINLOOP SIMULATION OF SAFETY CRITICAL SYSTEMS YUJUN ZHU, ZHONGWEI XU, MENG MEI School of Electronics & Information Engineering, Tongji University,
More informationObjectOriented Software Engineering Practical Software Development using UML and Java
ObjectOriented Software Engineering Practical Software Development using UML and Java Chapter 5: Modelling with Classes Lecture 5 5.1 What is UML? The Unified Modelling Language is a standard graphical
More informationLecture 4 Searching Arrays
Lecture 4 Searching Arrays 15122: Principles of Imperative Computation (Spring 2018) Frank Pfenning One of the fundamental and recurring problems in computer science is to find elements in collections,
More informationFast Discovery of Sequential Patterns Using Materialized Data Mining Views
Fast Discovery of Sequential Patterns Using Materialized Data Mining Views Tadeusz Morzy, Marek Wojciechowski, Maciej Zakrzewicz Poznan University of Technology Institute of Computing Science ul. Piotrowo
More informationReview for Mastery Using Graphs and Tables to Solve Linear Systems
31 Using Graphs and Tables to Solve Linear Systems A linear system of equations is a set of two or more linear equations. To solve a linear system, find all the ordered pairs (x, y) that make both equations
More informationAdvanced Algorithms Class Notes for Monday, October 23, 2012 Min Ye, Mingfu Shao, and Bernard Moret
Advanced Algorithms Class Notes for Monday, October 23, 2012 Min Ye, Mingfu Shao, and Bernard Moret Greedy Algorithms (continued) The best known application where the greedy algorithm is optimal is surely
More informationDITA for Enterprise Business Documents Subcommittee Proposal Background Why an Enterprise Business Documents Sub committee
DITA for Enterprise Business Documents Subcommittee Proposal Background Why an Enterprise Business Documents Sub committee Documents initiate and record business change. It is easy to map some business
More informationA Short Summary of Javali
A Short Summary of Javali October 15, 2015 1 Introduction Javali is a simple language based on ideas found in languages like C++ or Java. Its purpose is to serve as the source language for a simple compiler
More informationPropositional Calculus. Math Foundations of Computer Science
Propositional Calculus Math Foundations of Computer Science Propositional Calculus Objective: To provide students with the concepts and techniques from propositional calculus so that they can use it to
More informationWeb Page Classification using FP Growth Algorithm Akansha Garg,Computer Science Department Swami Vivekanad Subharti University,Meerut, India
Web Page Classification using FP Growth Algorithm Akansha Garg,Computer Science Department Swami Vivekanad Subharti University,Meerut, India Abstract  The primary goal of the web site is to provide the
More informationJournal of Information Technology Impact
Journal of Information Technology Impact Vol. 3, No. 1, pp. 2544, 2003 Bogdan D. Czejdo 1 Loyola University Louisiana, USA The Impact of UML Class Diagrams on Knowledge Modeling, Discovery and Presentations
More informationHeadingBased Sectional Hierarchy Identification for HTML Documents
HeadingBased Sectional Hierarchy Identification for HTML Documents 1 Dept. of Computer Engineering, Boğaziçi University, Bebek, İstanbul, 34342, Turkey F. Canan Pembe 1,2 and Tunga Güngör 1 2 Dept. of
More informationRelational Databases
Relational Databases Jan Chomicki University at Buffalo Jan Chomicki () Relational databases 1 / 49 Plan of the course 1 Relational databases 2 Relational database design 3 Conceptual database design 4
More informationCSC 501 Semantics of Programming Languages
CSC 501 Semantics of Programming Languages Subtitle: An Introduction to Formal Methods. Instructor: Dr. Lutz Hamel Email: hamel@cs.uri.edu Office: Tyler, Rm 251 Books There are no required books in this
More informationMultivariate probability distributions
Multivariate probability distributions September, 07 STAT 0 Class Slide Outline of Topics Background Discrete bivariate distribution 3 Continuous bivariate distribution STAT 0 Class Slide Multivariate
More informationNONCENTRALIZED DISTINCT LDIVERSITY
NONCENTRALIZED DISTINCT LDIVERSITY Chi Hong Cheong 1, Dan Wu 2, and Man Hon Wong 3 1,3 Department of Computer Science and Engineering, The Chinese University of Hong Kong, Hong Kong {chcheong, mhwong}@cse.cuhk.edu.hk
More informationENTITIES IN THE OBJECTORIENTED DESIGN PROCESS MODEL
INTERNATIONAL DESIGN CONFERENCE  DESIGN 2000 Dubrovnik, May 2326, 2000. ENTITIES IN THE OBJECTORIENTED DESIGN PROCESS MODEL N. Pavković, D. Marjanović Keywords: object oriented methodology, design process
More informationChapter 2: Number Systems
Chapter 2: Number Systems Logic circuits are used to generate and transmit 1s and 0s to compute and convey information. This twovalued number system is called binary. As presented earlier, there are many
More informationOverloading, Type Classes, and Algebraic Datatypes
Overloading, Type Classes, and Algebraic Datatypes Delivered by Michael Pellauer Arvind Computer Science and Artificial Intelligence Laboratory M.I.T. September 28, 2006 September 28, 2006 http://www.csg.csail.mit.edu/6.827
More informationChapter 2 Overview of the Design Methodology
Chapter 2 Overview of the Design Methodology This chapter presents an overview of the design methodology which is developed in this thesis, by identifying global abstraction levels at which a distributed
More informationIntro to semantics; Smallstep semantics Lecture 1 Tuesday, January 29, 2013
Harvard School of Engineering and Applied Sciences CS 152: Programming Languages Lecture 1 Tuesday, January 29, 2013 1 Intro to semantics What is the meaning of a program? When we write a program, we use
More informationCombining Different Business Rules Technologies:A Rationalization
A research and education initiative at the MIT Sloan School of Management Combining Different Business Rules Technologies:A Rationalization Paper 116 Benjamin Grosof Isabelle Rouvellou Lou Degenaro Hoi
More informationUnit 7. Functions. Need of User Defined Functions
Unit 7 Functions Functions are the building blocks where every program activity occurs. They are self contained program segments that carry out some specific, well defined task. Every C program must have
More informationFacet Folders: Flexible Filter Hierarchies with Faceted Metadata
Facet Folders: Flexible Filter Hierarchies with Faceted Metadata Markus Weiland Dresden University of Technology Multimedia Technology Group 01062 Dresden, Germany mweiland@acm.org Raimund Dachselt University
More informationChapter S:II. II. Search Space Representation
Chapter S:II II. Search Space Representation Systematic Search Encoding of Problems StateSpace Representation ProblemReduction Representation Choosing a Representation S:II1 Search Space Representation
More informationPointtoPoint Synchronisation on Shared Memory Architectures
PointtoPoint Synchronisation on Shared Memory Architectures J. Mark Bull and Carwyn Ball EPCC, The King s Buildings, The University of Edinburgh, Mayfield Road, Edinburgh EH9 3JZ, Scotland, U.K. email:
More informationHorizontal Aggregations in SQL to Prepare Data Sets Using PIVOT Operator
Horizontal Aggregations in SQL to Prepare Data Sets Using PIVOT Operator R.Saravanan 1, J.Sivapriya 2, M.Shahidha 3 1 Assisstant Professor, Department of IT,SMVEC, Puducherry, India 2,3 UG student, Department
More informationCMSC 330: Organization of Programming Languages
CMSC 330: Organization of Programming Languages Context Free Grammars and Parsing 1 Recall: Architecture of Compilers, Interpreters Source Parser Static Analyzer Intermediate Representation Front End Back
More informationUC Irvine UC Irvine Previously Published Works
UC Irvine UC Irvine Previously Published Works Title Differencing and merging within an evolving product line architecture Permalink https://escholarship.org/uc/item/0k73r951 Authors Chen, Ping H Critchlow,
More informationISO/IEC INTERNATIONAL STANDARD. Information technology  Syntactic metalanguage  Extended BNF
INTERNATIONAL STANDARD ISO/IEC First edition 1996l l 5 Information technology  Syntactic metalanguage  Extended BNF Technologies de / information  Mbtalangage syntaxique  BNF &endu Reference number
More informationChapter 1: Principles of Programming and Software Engineering
Chapter 1: Principles of Programming and Software Engineering Data Abstraction & Problem Solving with C++ Fifth Edition by Frank M. Carrano Software Engineering and ObjectOriented Design Coding without
More informationRDGL Reference Manual
RDGL Reference Manual COMS W4115 Programming Languages and Translators Professor Stephen A. Edwards Summer 2007(CVN) Navid Azimi (na2258) nazimi@microsoft.com Contents Introduction... 3 Purpose... 3 Goals...
More information