Using Graph Rewriting to Specify Software Architectural Transformations

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "Using Graph Rewriting to Specify Software Architectural Transformations"

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 graph-rewriting 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 high-level, 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 low-level 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 graph-rewriting 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 high-level, graphical and expressive notation. Each architectural transformation can be specified using a graph-rewrite rule or a set of graph-rewrite rules. he application of a graph-rewrite 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 multi-dimensional 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 low-level 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 high-level 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 graph-rewrite 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 graph-rewrite 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 graph-rewrite rule specifying the deletion of a W-labeled 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 W-labeled 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 graph-rewrite rule. he graph-rewrite 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 graph-rewrite rules [1]. Here, we choose to use the visual graph-rewriting language PROGRE [2,9,14], since the PROGRE programming environment is the most mature tool currently available for the specification and execution of graph-rewriting 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 syntax-directed 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 graph-rewrite 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 Ancestor-labeled 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 W-labeled 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 non-existence 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 non-existence of nodes as well as the existence and non-existence 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_ graph-rewrite rule using PROGRE notation. his rule is used to implement a lifting transformation (able 1). We use this transformation to raise low-level 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 Ancestor-labeled 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 crossed-out use-labeled 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 crossed-out Ancestor-labeled 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 graph-rewrite 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 crossed-out nodes are used to test the non-existence 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 low-level 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 module-module depencies. Our mental (or conceptual model) contains depencies amongst subsystems, rather than modules. Hence, we need to lift the module-module 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 low-level uses to the high level in order to determine the subsystem-subsystem depencies. 1 We are currently concentrating on automating repair at the architectural level, not at the source-code 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 low-level module-module 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 graph-rewriting specifications Diagnosis Given only the module-module 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 graph-rewrite 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 lower-level edges which are causing the high-level 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 high-level 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 graph-rewrite rule. It is used to convert a use-labeled edge to an unexpected-labeled edge. he parameters define the source and target node names of the use-labeled 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 top-level 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 unexpected-labeled edge rather than the source.) Once the module is kidnapped, its InWrong value is set to false (refer to the transfer clause), and the unexpected-labeled edge becomes a uselabeled edge (RH of the production). After we minimize

9 the low-level unexpected-labeled edges by applying KidnapModule1 and KidnapModule2 rules, we need to eliminate high-level unexpected-labeled 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 high-level unexpected-labeled 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 graph-rewriting 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 Graph-rewrite 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 low-level 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 high-level, 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, high-level, 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 graph-rewriting 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, oftware-practice 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 12-14, [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 High-Level 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

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 information

Lecturer 2: Spatial Concepts and Data Models

Lecturer 2: Spatial Concepts and Data Models Lecturer 2: Spatial Concepts and Data Models 2.1 Introduction 2.2 Models of Spatial Information 2.3 Three-Step Database Design 2.4 Extending ER with Spatial Concepts 2.5 Summary Learning Objectives Learning

More information

Module 1 Lecture Notes 2. Optimization Problem and Model Formulation

Module 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 information

Transformation of structured documents with the use of grammar

Transformation 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 information

Maximal Monochromatic Geodesics in an Antipodal Coloring of Hypercube

Maximal 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 information

mapping 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 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 information

ITERATIVE MULTI-LEVEL MODELLING - A METHODOLOGY FOR COMPUTER SYSTEM DESIGN. F. W. Zurcher B. Randell

ITERATIVE MULTI-LEVEL MODELLING - A METHODOLOGY FOR COMPUTER SYSTEM DESIGN. F. W. Zurcher B. Randell ITERATIVE MULTI-LEVEL 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 information

LL(k) Parsing. Predictive Parsers. LL(k) Parser Structure. Sample Parse Table. LL(1) Parsing Algorithm. Push RHS in Reverse Order 10/17/2012

LL(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 information

UNIT-IV BASIC BEHAVIORAL MODELING-I

UNIT-IV BASIC BEHAVIORAL MODELING-I UNIT-IV BASIC BEHAVIORAL MODELING-I CONTENTS 1. Interactions Terms and Concepts Modeling Techniques 2. Interaction Diagrams Terms and Concepts Modeling Techniques Interactions: Terms and Concepts: An interaction

More information

Keywords: Abstract Factory, Singleton, Factory Method, Prototype, Builder, Composite, Flyweight, Decorator.

Keywords: 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 information

Eclipse Support for Using Eli and Teaching Programming Languages

Eclipse 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 information

Table : 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 = (

Table : 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 information

E-R Model. Hi! Here in this lecture we are going to discuss about the E-R Model.

E-R Model. Hi! Here in this lecture we are going to discuss about the E-R Model. E-R Model Hi! Here in this lecture we are going to discuss about the E-R Model. What is Entity-Relationship Model? The entity-relationship model is useful because, as we will soon see, it facilitates communication

More information

Ontology Matching with CIDER: Evaluation Report for the OAEI 2008

Ontology 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 information

Policy Analysis and Verification by Graph Transformation Tools

Policy Analysis and Verification by Graph Transformation Tools GraBaTs 04 Preliminary Version Policy Analysis and Verification by Graph Transformation Tools Yujie Zhao and Francesco Parisi-Presicce George Mason University - USA Abstract Policies are used to control

More information

INTRODUCING 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 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 information

JOURNAL OF OBJECT TECHNOLOGY

JOURNAL 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, November-December 2003 UML 2 Activity and Action Models Part 3:

More information

Functional Dependency: Design and Implementation of a Minimal Cover Algorithm

Functional Dependency: Design and Implementation of a Minimal Cover Algorithm IOSR Journal of Computer Engineering (IOSR-JCE) e-issn: 2278-0661,p-ISSN: 2278-8727, Volume 19, Issue 5, Ver. I (Sep.- Oct. 2017), PP 77-81 www.iosrjournals.org Functional Dependency: Design and Implementation

More information

1. NUMBER SYSTEMS USED IN COMPUTING: THE BINARY NUMBER SYSTEM

1. 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 information

Basic Structure of Denotational Definitions

Basic 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 information

Statistics Case Study 2000 M. J. Clancy and M. C. Linn

Statistics 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 information

FMA901F: Machine Learning Lecture 6: Graphical Models. Cristian Sminchisescu

FMA901F: 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 information

5 The Control Structure Diagram (CSD)

5 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 information

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN NOTES ON OBJECT-ORIENTED 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 object-oriented

More information

Automatic Test Markup Language Sept 28, 2004

Automatic Test Markup Language <ATML/> 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 information

Compiler 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 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 information

About the Tutorial. Audience. Prerequisites. Copyright & Disclaimer. Compiler Design

About 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 information

UNIT V SYSTEM SOFTWARE TOOLS

UNIT 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 information

Workflow Modeling for Virtual Processes: an Order-Preserving Process-View Approach

Workflow Modeling for Virtual Processes: an Order-Preserving Process-View Approach In: Information Systems Workflow Modeling for Virtual Processes: an Order-Preserving Process-View Approach Duen-Ren Liu Minxin Shen Institute of Information Management, National Chiao Tung University 1001

More information

Reducing Directed Max Flow to Undirected Max Flow and Bipartite Matching

Reducing 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 information

DATA MODELS FOR SEMISTRUCTURED DATA

DATA 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 information

Simulating Task Models Using Concrete User Interface Components

Simulating 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 information

Interprocess Communication By: Kaushik Vaghani

Interprocess 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 information

Harvard School of Engineering and Applied Sciences Computer Science 152

Harvard 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 information

SQL Functionality SQL. Creating Relation Schemas. Creating Relation Schemas

SQL Functionality SQL. Creating Relation Schemas. Creating Relation Schemas SQL SQL Functionality stands for Structured Query Language sometimes pronounced sequel a very-high-level (declarative) language user specifies what is wanted, not how to find it number of standards original

More information

Java Learning Object Ontology

Java Learning Object Ontology Java Learning Object Ontology Ming-Che 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 information

Complexity Theory. Compiled By : Hari Prasad Pokhrel Page 1 of 20. ioenotes.edu.np

Complexity 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 real-world computers. Nowadays, the Theory of Computation can be

More information

On Meaning Preservation of a Calculus of Records

On 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 information

Lecture 5. Logic I. Statement Logic

Lecture 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 information

Putting Static Analysis to Work for Verification

Putting Static Analysis to Work for Verification Putting Static Analysis to Work for Verification A Case Study Tomasz Dudziak Based on a paper by T. Lev-Ami, T. Reps, M. Sagiv, and R. Wilhelm 23 June 2010 Topic Goal A very capable shape analysis that

More information

DERIVING SPATIOTEMPORAL RELATIONS FROM SIMPLE DATA STRUCTURE

DERIVING SPATIOTEMPORAL RELATIONS FROM SIMPLE DATA STRUCTURE DERIVING SPATIOTEMPORAL RELATIONS FROM SIMPLE DATA STRUCTURE Ale Raza ESRI 380 New York Street, Redlands, California 9373-800, USA Tel.: +-909-793-853 (extension 009) Fax: +-909-307-3067 araza@esri.com

More information

The Use of Process Clustering in Distributed-System Event Displays

The Use of Process Clustering in Distributed-System Event Displays The Use of Process Clustering in Distributed-System Event Displays David J. Taylor Abstract When debugging a distributed application, a display showing the events causing interactions between processes

More information

Unit 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 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 information

OBJECT ORIENTED PROGRAMMING USING C++ CSCI Object Oriented Analysis and Design By Manali Torpe

OBJECT 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 information

An Object Model for Multiparadigm

An Object Model for Multiparadigm 1 of 7 03/02/2007 15:37 http://www.dmst.aueb.gr/dds/pubs/conf/1994-oopsla-multipar/html/mlom.html This is an HTML rendering of a working paper draft that led to a publication. The publication should always

More information

A Catalog of While Loop Specification Patterns

A Catalog of While Loop Specification Patterns A Catalog of While Loop Specification Patterns Aditi Barua and Yoonsik Cheon TR #14-65 September 2014 Keywords: functional program verification, intended functions, program specification, specification

More information

CS106X Handout 03 Autumn 2012 September 24 th, 2012 Getting Started

CS106X 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 information

XETA: extensible metadata System

XETA: 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 information

CS 411 Midterm Feb 2008

CS 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 information

Specification of Content-Dependent Security Policies

Specification of Content-Dependent Security Policies Specification of Content-Dependent Security Policies David L. Spooner Mathematical Sciences Department Rensselaer Polytechnic Institute Troy, NY 12181 Abstract: The protection of information from unauthorized

More information

A Fitness Function to Find Feasible Sequences of Method Calls for Evolutionary Testing of Object-Oriented Programs

A Fitness Function to Find Feasible Sequences of Method Calls for Evolutionary Testing of Object-Oriented Programs A Fitness Function to Find Feasible Sequences of Method Calls for Evolutionary Testing of Object-Oriented Programs Myoung Yee Kim and Yoonsik Cheon TR #7-57 November 7; revised January Keywords: fitness

More information

STRUCTURES AND STRATEGIES FOR STATE SPACE SEARCH

STRUCTURES 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 information

Modeling software evolution by evolving interoperation graphs

Modeling 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 information

Programming with Math and Logic

Programming 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 information

Capturing and Formalizing SAF Availability Management Framework Configuration Requirements

Capturing 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. Hamou-Lhadj Electrical and Computer Engineering, Concordia University,

More information

Let us dene the basic notation and list some results. We will consider that stack eects (type signatures) form a polycyclic monoid (introduced in [NiP

Let 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 e-mail: jaanus@cs.ut.ee February 21, 1997 Abstract The Java language is widely used in

More information

FlexFlow: Workflow for Interactive Internet Applications

FlexFlow: 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 information

Perspectives on User Story Based Visual Transformations

Perspectives 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 information

Configuration Management for Component-based Systems

Configuration Management for Component-based Systems Configuration Management for Component-based 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 information

3D Object Scanning to Support Computer-Aided Conceptual Design

3D Object Scanning to Support Computer-Aided Conceptual Design ABSTRACT 3D Object Scanning to Support Computer-Aided Conceptual Design J.S.M. Vergeest and I. Horváth Delft University of Technology Faculty of Design, Engineering and Production Jaffalaan 9, NL-2628

More information

Fundamental Concepts. Chapter 1

Fundamental 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 information

Chapter 3. Set Theory. 3.1 What is a Set?

Chapter 3. Set Theory. 3.1 What is a Set? Chapter 3 Set Theory 3.1 What is a Set? A set is a well-defined collection of objects called elements or members of the set. Here, well-defined means accurately and unambiguously stated or described. Any

More information

LECTURE 6: INTRODUCTION TO FORMAL METHODS. Software Engineering Mike Wooldridge

LECTURE 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 information

Fast Introduction to Object Oriented Programming and C++

Fast 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 information

Reliability Allocation

Reliability 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 information

Top-k Keyword Search Over Graphs Based On Backward Search

Top-k Keyword Search Over Graphs Based On Backward Search Top-k Keyword Search Over Graphs Based On Backward Search Jia-Hui Zeng, Jiu-Ming Huang, Shu-Qiang 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

/ 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 information

AN 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 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 information

A SIMULATION ARCHITECTURE DESCRIPTION LANGUAGE FOR HARDWARE-IN-LOOP SIMULATION OF SAFETY CRITICAL SYSTEMS

A SIMULATION ARCHITECTURE DESCRIPTION LANGUAGE FOR HARDWARE-IN-LOOP SIMULATION OF SAFETY CRITICAL SYSTEMS A SIMULATION ARCHITECTURE DESCRIPTION LANGUAGE FOR HARDWARE-IN-LOOP SIMULATION OF SAFETY CRITICAL SYSTEMS YUJUN ZHU, ZHONGWEI XU, MENG MEI School of Electronics & Information Engineering, Tongji University,

More information

Object-Oriented Software Engineering Practical Software Development using UML and Java

Object-Oriented Software Engineering Practical Software Development using UML and Java Object-Oriented 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 information

Lecture 4 Searching Arrays

Lecture 4 Searching Arrays Lecture 4 Searching Arrays 15-122: 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 information

Fast Discovery of Sequential Patterns Using Materialized Data Mining Views

Fast 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 information

Review for Mastery Using Graphs and Tables to Solve Linear Systems

Review for Mastery Using Graphs and Tables to Solve Linear Systems 3-1 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 information

Advanced 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 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 information

DITA for Enterprise Business Documents Sub-committee Proposal Background Why an Enterprise Business Documents Sub committee

DITA for Enterprise Business Documents Sub-committee Proposal Background Why an Enterprise Business Documents Sub committee DITA for Enterprise Business Documents Sub-committee Proposal Background Why an Enterprise Business Documents Sub committee Documents initiate and record business change. It is easy to map some business

More information

A Short Summary of Javali

A 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 information

Propositional Calculus. Math Foundations of Computer Science

Propositional 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 information

Web 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 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 information

Journal of Information Technology Impact

Journal of Information Technology Impact Journal of Information Technology Impact Vol. 3, No. 1, pp. 25-44, 2003 Bogdan D. Czejdo 1 Loyola University Louisiana, USA The Impact of UML Class Diagrams on Knowledge Modeling, Discovery and Presentations

More information

Heading-Based Sectional Hierarchy Identification for HTML Documents

Heading-Based Sectional Hierarchy Identification for HTML Documents Heading-Based 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 information

Relational Databases

Relational 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 information

CSC 501 Semantics of Programming Languages

CSC 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 information

Multivariate probability distributions

Multivariate 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 information

NON-CENTRALIZED DISTINCT L-DIVERSITY

NON-CENTRALIZED DISTINCT L-DIVERSITY NON-CENTRALIZED DISTINCT L-DIVERSITY 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 information

ENTITIES IN THE OBJECT-ORIENTED DESIGN PROCESS MODEL

ENTITIES IN THE OBJECT-ORIENTED DESIGN PROCESS MODEL INTERNATIONAL DESIGN CONFERENCE - DESIGN 2000 Dubrovnik, May 23-26, 2000. ENTITIES IN THE OBJECT-ORIENTED DESIGN PROCESS MODEL N. Pavković, D. Marjanović Keywords: object oriented methodology, design process

More information

Chapter 2: Number Systems

Chapter 2: Number Systems Chapter 2: Number Systems Logic circuits are used to generate and transmit 1s and 0s to compute and convey information. This two-valued number system is called binary. As presented earlier, there are many

More information

Overloading, Type Classes, and Algebraic Datatypes

Overloading, 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 information

Chapter 2 Overview of the Design Methodology

Chapter 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 information

Intro to semantics; Small-step semantics Lecture 1 Tuesday, January 29, 2013

Intro to semantics; Small-step 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 information

Combining Different Business Rules Technologies:A Rationalization

Combining 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 information

Unit 7. Functions. Need of User Defined Functions

Unit 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 information

Facet Folders: Flexible Filter Hierarchies with Faceted Metadata

Facet 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 information

Chapter S:II. II. Search Space Representation

Chapter S:II. II. Search Space Representation Chapter S:II II. Search Space Representation Systematic Search Encoding of Problems State-Space Representation Problem-Reduction Representation Choosing a Representation S:II-1 Search Space Representation

More information

Point-to-Point Synchronisation on Shared Memory Architectures

Point-to-Point Synchronisation on Shared Memory Architectures Point-to-Point 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 information

Horizontal Aggregations in SQL to Prepare Data Sets Using PIVOT Operator

Horizontal 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 information

CMSC 330: Organization of Programming Languages

CMSC 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 information

UC Irvine UC Irvine Previously Published Works

UC 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 information

ISO/IEC INTERNATIONAL STANDARD. Information technology - Syntactic metalanguage - Extended BNF

ISO/IEC INTERNATIONAL STANDARD. Information technology - Syntactic metalanguage - Extended BNF INTERNATIONAL STANDARD ISO/IEC First edition 1996-l -l 5 Information technology - Syntactic metalanguage - Extended BNF Technologies de / information - Mbtalangage syntaxique - BNF &endu Reference number

More information

Chapter 1: Principles of Programming and Software Engineering

Chapter 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 Object-Oriented Design Coding without

More information

RDGL Reference Manual

RDGL 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