Interconnection Styles

Transcription

1 Interonnetion tyles oftware Design Following the Export (erver) tyle 2 M1 M4 M5 4 M3 M6 1 3 oftware Design Following the Export (Client) tyle e 2 e M1 M4 M5 4 M3 M6 1 e 3

2 oftware Design Following the Export Client / Export tyle e 2 e M1 M4 M5 4 M3 M6 1 e 3 oftware Design Following the Import tyle ort ort 2 M1 M4 M5 4 M3 M6 1 3 oftware Design Following the Import / Export tyle ort 2 M1 ort M4 M5 4 M3 M6 1 3

3 oftware Design Following the Tube tyle tube tube 1 2 M1 M3 M6 M4 M5 4 tube 3 Interonnetion tyle Formalism An IF speifiation onsists of a finite set of logi rules. There are two kinds of IF rules: Permission: Determine the syntatially legal relations between the omponents of a software design. Definition: Define new relations based on patterns of entities and relations. Interonnetion tyle Formalism (Cont d) Eah rule onsists of a finite set of entities and relations. Entities represent design omponents and relations represent interonnetions between these omponents.

4 Design View Model-Theory View Datalog View M1 2 M3 1 M4 M5 4 M6 3 et of Mathematial Relations (Interpret.) et of Datalog Fats input M1 M4 M5 2 4 M3 M6 1 3 atisfies? Union M1 M4 M5 2 4 M3 M6 1 3 M1 M4 M5 2 4 M3 M6 1 3 M1 M4 M5 2 4 M3 M6 1 3 M1 M4 M5 2 4 M3 M6 1 3 et of Logi Formulas (Theory) et of Datalog Rules satisfies style does not satisfy style model not model Wellformed? Yes/no Design Example 1.1 M3 M4 2.1 M5 M1 1 2 M6 Design Example in Datalog

5 Formal Definition of IF The syntax of IF is desribed by presenting the visual symbols of the notation. These symbols represent design: entities relations rules The semantis of IF is desribed using Datalog. Formal Definition of IF The semantis of IF is presented bottomup: semantis of IF entities and relations semantis of IF rules in terms of the semantis of entities and relations IF Entities IF entities are depited as labeled retangles. Eah IF entity represents a set of typed design omponents suh as: modules, lasses, s, et. There are three types of entities: label label label

6 Example of an IF Entity An example of an IF entity is: ubsystem Formally: () where is a free variable. Informally: The set of all s in a software design. IF Relations IF relations are depited as: labeled edges nested retangles Eah IF relation represents a relation of a software design suh as: ontainment (depited as nested retangles) ort inherit, et. IF Containment Relations e1 e2 1. Entity ontains sle entity e1 e2 2. Entity ontains transitive entity Contain(P,), (P) () rt_ontain(p,), (P) () e1 e2 1. Entity ontains permission entity

7 IF Edge Relations r e1 e2 1. le Relation r e1 e2 2. Negated le Relation r e1 e2 3. Reflexive Transitive Relation r e1 e2 4. Negated Reflexive Transitive Relation r e1 e2 5,6. Permission or Definition Relation Examples of Edge Relations (1,2), (1), (2) not((1,2)), (1), (2) rt_(1,2), (1), (2) t_r(x,y) :- r(x,y). t_r(x,y) :- r(x,z), t_r(z,y). rt_(x,y) :- X = Y. rt_r(x,y) :- t_r(x,y). not(rt_(1,2)), (1), (2) IF Rules: The Export tyle (Part 1) PERMIT PERMIT ss ss ss ss wf_(p,) :- ss(p), ss(), ontain(p,). ill_formed() :- (X,Y), not(wf_(x,y)). wf_ontain(p,) :- ss(p),ss(). ill_formed() :- ontain(x,y), not(wf_ontain(x,y)). well_formed_design() :- not(ill_formed()).

8 IF Rules: The Export tyle (Part 2) Export Client / Export tyle Import / Export tyle (Part 1)

9 Import / Export tyle (Part 2) Tube tyle (Part1) Tube tyle (Part 2)

10 On the Automati Reovery of tyle-peifi trutural Dependenies Introdution Motivation Definitions MDG Clustering Interonnetion tyles IF Examples Tool Motivation Doumentation problems: Missing or inaurate design doumentation Poorly doumented ode Original programmers not available for onsultation Program understanding. Need for high-level information Existing lustering tehniques do not produe highlevel dependenies. Design validation

11 Module Dependeny Graph Nodes represent modules Edges represent dependenies between modules (i.e. method invoation, variable referene, et) Obtained automatially with Cia, Aaia, Chava Example: Mini Tunis MDG Aggregate representation of MDG, that groups together modules that are tightly oupled Clusters represent s Obtained automatially with Bunh Clustering

12 Example: Mini Tunis after lustering A lustered system may be visualized as a tree Edges represent ontainment, and style dependenies Nodes represent modules and s Easier to visualize large systems truture Graph Interonnetion tyles Regulate the interations between modules and s High-level relations not present in soure ode or lustered system. Can be desribed formally with the Interonnetion tyle Formalism (IF)

13 Example: Export tyle Export style failitates the speifiation of interfaes. If a s a module M, M belongs to s interfae. Modules outside of an modules belonging to s interfae. Example: Export tyle M3 an M4 bea it is ed by 21 and 21 is ed by 2. M6 annot M5 bea it is not ed by 21. If M6 did M5 there would be a stylisti violation. IF Visual notation that allows speifiation of onstraints on onfigurations of omponents and dependenies Rules are represented as direted labeled graphs Nodes: modules and s Arrows: dependenies and ontainment relations

14 Types of rules: IF (ont d) PERMIION: define the set of well-formed onfigurations DEFINITION: define new relations based on patterns of software omponents and relations. IF peifiation of Export tyle PERMIT(1) DEFINE(1) ontain ontain not equal ontain ontain ontain* ontain* * see PERMIT(2) see Example: Mini Tunis after Edge Repair

15 tyle Editor Tool Enables the r to define ustom interonnetion styles visually Edge Repair Utility Takes struture graph and style and finds the missing strutural dependenies automatially Cheks if a design satisfies stylisti onstraints Integration of Reverse Engineering Tools for (int i;...) {... } oure Code oure Code Analysis Tool Module Dependeny Graph Clustering Tool (Bunh) PERMIT(1) DEFINE(1) exp exp see tyle Definition Edge Repair Utility Clustered MDG exp Well-formed Design Edge Repair Rule Cheking Code Generation Tehniques

16 Edge Repair Given truture Graph tyle definition PERMIT(1) DEFINE(1) ontain ontain ontain not equal ontain ontain* ontain* * see PERMIT(2) see Edge Repair Goal: find the missing style dependenies suh that: Visibility between modules is minimized No dependeny (i.e., or style) violates any stylisti onstraint. Algorithms Huge searh spae (i.e. annot try all possible ombinations) Optimization methods: Hill limbing: start with a random onfiguration and find better ones by making small hanges Edge removal: start with full onfiguration and remove edges until no better solution an be found Geneti algorithm

17 Fitness Funtion Measures the quality of a onfiguration Good: Configurations with a large number of well-formed relations Bad: Configurations with a large number of ill-formed style dependenies Configurations with high visibility (many see relations) listi visibility Computing visibility is an O(N 2 ) operation Frequent operation Approah: slisti visibility Approximation to standard visibility Given by the number of style dependenies O(1) operation Drawbak: does not work for some styles Non-reursive (permission rules are not defined in terms of other permission rules) Modules are exposed by diret (i.e., non-transitive) relations with their anestors. Fitness Funtion wfs ifs 0 or ifu 0 ifs + ifu 1 quality( C) = Max + ifs = 0, ifu = 0, wfs 0 wfs Max + 2 ifs = 0, ifu = 0, wfs = 0 ifu: ill-formed dependenies ifs: ill-formed style dependenies wfu: well-formed dependenies wfs: well-formed style dependenies Max: maximum number of style dependenies in C

18 Hill Climbing tart from random onfiguration of dependenies elet an edge, to add or remove, suh that the new onfiguration is better than the urrent one Repeat until no better solution an be found Edge Removal tart from full onfiguration Remove edges that makes the urrent solution better until no better solution an be found Hill Climbing vs. Edge Removal Hill Climbing Adds relations and then removes them (might add unneessary relations) Edge Removal Always starts with a full onfiguration (even if only a few relations are required) Fewer neighbors to onsider as the algorithm advanes

19 Performane: Hill Climbing vs. Edge Removal Compiler (19 nodes) Mini Tunis (32 nodes) Grappa (117 nodes) Inl (212 nodes) Hill Climbing 0.19 s 0.8 s 8.5 s s Edge Removal 0.14 s 0.46 s 3.67 s 9.2 s Geneti Algorithm Enoding Crossover Fitness funtion k a wfu fitness = l b ifnu + visibility m Mutation Optimizations Pessimisti edge reparability: avoid proessing relations that an never exist (e.g., relations between siblings in the Export tyle) listi visibility measurement: based on the number of style dependenies in a onfiguration (redues O(N 2 ) operation to O(1)).

20 Rule Cheking Goal: hek well-formedness of a dependeny with respet to a permission rule. Can be redued to a pattern mathing problem => the rule is mathed to the struture graph. * * Pattern Mathing Invalid pattern mathes: * Pattern Mathing Algorithm Based on Depth-First earh tate: et of fixed nodes et of free nodes Goal: find a state with no free nodes Initial state: the set of fixed nodes ontains the endpoints of the relation being heked

21 N 0 N 1 Pattern Mathing Example truture Graph H E F G C D exp A B I * A!= * exp * C * A!= *!= * B E exp * exp!= * exp * H!= * exp A B A B A B A B Permission Rule N 2 N 3!= E * D!= * exp * * exp A B Choosing the Node to Fix If the node is not onneted to a fixed node, it an assume any value (i.e., N possibilities) Choose a node onneted to a fixed node to onstrain the possible values for the node Pessimisti Edge Reparability Algorithm Algorithm: based on the pattern mathing Full onfiguration with all dependenies as unknown Repeat until no more unknown dependenies exist Pik a dependeny tagged as unknown Chek if it is reparable (i.e., perform a pattern math of every related permission rule). If an unknown dependeny is found during the math, hek its reparability (i.e., reursive all of this algorithm) If a math is found and all involved dependenies are reparable, tag the relation as reparable. If not, tag it as irreparable.

22 Code Generation Java ode is generated to hek eah rule Take advantage of Java s ompile-time and run-time optimizations ome deision making is performed when the rule is translated instead of when it is heked Code Optimization Take advantage of the fat that Rules are stati earh tree depth is fixed and known for eah rule (depends on the number of nodes in the rule). to determine the order in whih rule s nodes are fixed at translation time. Code Optimization (ont d) When rules look like trees (most times), topologial sorting an give a good ordering of nodes. A * 1 B 2

23 Conlusion Tool find missing high-level dependenies in a system validate a design against a style speifiation Further researh: Optimization of edge repair algorithm (e.g., using inremental algorithms) Replae the slisti visibility measurement Repairing designs by relustering.