16. How to Structure Large Models and Programs with Graph - - PowerPoint PPT Presentation

16 how to structure large models and programs with graph
SMART_READER_LITE
LIVE PREVIEW

16. How to Structure Large Models and Programs with Graph - - PowerPoint PPT Presentation

Fakultt Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie Prof. Amann - Softwaretechnologie II 16. How to Structure Large Models and Programs with Graph Structurings 1. TopSorting (Layering) Prof. Dr. U.


slide-1
SLIDE 1

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

  • 16. How to Structure Large Models and

Programs – with Graph Structurings

  • Prof. Dr. U. Aßmann

Technische Universität Dresden Institut für Software- und Multimediatechnik Gruppe Softwaretechnologie http://st.inf.tu- dresden.de/teaching/swt2 2016-0.1, 17.12.16

  • 1. TopSorting (Layering)
  • 2. Strongly Connected

Components

  • 3. Reducibility
  • 4. Summary of Structurings
  • Prof. U. Aßmann

1

slide-2
SLIDE 2

Softwaretechnologie II

Obligatory Reading

Ø

Jazayeri Chap 3. If you have other books, read the lecture slides carefully and do the exercise sheets

Ø

Roberto Bruni, Alberto Lluch Lafuente. Ten Virtues of Structured Graphs. ECEASST Vol 18 (2008)

  • http://journal.ub.tu-berlin.de/eceasst/article/view/261/246

Ø

  • F. Klar, A. Königs, A. Schürr: "Model Transformation in the Large", 6th joint meeting of

the European software engineering conference and the ACM SIGSOFT symposium on the foundations of software engineering, New York, ACM Press, 2007; ACM Digital Library Proceedings, 285-294.

Ø

http://www.idt.mdh.se/esec-fse-2007/

Ø

Tom Mens, Pieter Van Gorp. A Taxonomy of Model Transformation. Electronic Notes in Theoretical Computer Science 152 (2006) 125–142, doi:10.1016/j.entcs.2005.10.021

Ø

  • T. Fischer, Jörg Niere, L. Torunski, and Albert Zündorf, 'Story Diagrams: A new Graph

Rewrite Language based on the Unified Modeling Language', in Proc. of the 6th International Workshop on Theory and Application of Graph Transformation (TAGT), Paderborn, Germany (G. Engels and G. Rozenberg, eds.), LNCS 1764, pp. 296--309, Springer Verlag, November 1998. http://www.upb.de/cs/ag- schaefer/Veroeffentlichungen/Quellen/Papers/1998/TAGT1998.pdf

  • Prof. U. Aßmann

2

slide-3
SLIDE 3

Softwaretechnologie II

Reducibility

Ø [Tarjan74] Robert E. Tarjan. Testing flow graph reducibility. Journal Computer System Science, 9:355-365, 1974. Ø [ASU86] Alfred A. Aho, R. Sethi, and Jeffrey D. Ullman. Compilers: Principles, Techniques, and Tools. Addison-Wesley, 1986. Ø [JC97] Johan Janssen and Henk Corporaal. Making graphs reducible with controlled node splitting. ACM Transactions on Programming Languages and Systems (TOPLAS), 19(6):1031-1053, November 1997.

  • Prof. U. Aßmann

3

slide-4
SLIDE 4

Softwaretechnologie II

Further Reading

Ø

Tom Mens. On the Use of Graph Transformations for Model Refactorings. In GTTSE 2005, Springer, LNCS 4143

  • http://www.springerlink.com/content/5742246115107431/

Ø

Reducible graphs

Ø

[ASU86] Alfred A. Aho, R. Sethi, and Jeffrey D. Ullman. Compilers: Principles, Techniques, and Tools. Addison-Wesley, 1986.

Ø

Structured programming and stepwise refinement was started with Dijkstra’s famous letter to CACM about goto’s:

Ø

  • E. W. Dijkstra. GoTo Considered Harmful. Communications of the ACM. Volume 11

Issue 3, March 1968. Pages 147-148. http://dl.acm.org/citation.cfm?doid=362929.362947

Ø

Search for these keywords at

Ø http://scholar.google.com Ø http://citeseer.ist.psu.edu Ø http://portal.acm.org/guide.cfm Ø http://ieeexplore.ieee.org/ Ø http://www.gi-ev.de/wissenschaft/digitbibl/index.html Ø http://www.springer.com/computer?SGWID=1-146-0-0-0

  • Prof. U. Aßmann

4

slide-5
SLIDE 5

Softwaretechnologie II

  • Prof. U. Aßmann

5

slide-6
SLIDE 6

Softwaretechnologie II

The Problem: How to Master Large Models

Ø

Large models have large graphs

Ø

They can be hard to understand

Ø

Figures taken from Goose Reengineering Tool, analysing a Java class system [Goose, FZI Karlsruhe]

  • Prof. U. Aßmann

6

slide-7
SLIDE 7

Softwaretechnologie II

Answer: Simon's Law of Complexity

Ø

  • H. Simon. The Architecture of Complexity. Proc. American Philosophical

Society 106 (1962), 467-482. Reprinted in:

Ø

  • H. Simon, The Sciences of the Artificial. MIT Press. Cambridge, MA, 1969.
  • Prof. U. Aßmann

7

Hierarchical structure reduces complexity. Herbert A. Simon, 1962 Remember, structuring is a basic engineering activity

slide-8
SLIDE 8

Softwaretechnologie II

Idea of Structurings

Ø

If a graph-based model is too complex, try structurings

Ø

Structurings overlay graphs with skeleton lists, trees, and dags

Ø

Structuring can be achieved with graph analysis, logic-based analysis, and graph rewriting

Ø

Example: finding a spanning tree:

  • Prof. U. Aßmann

8

....... ....... ....... root root sinks ....... ....... root root sinks .......

slide-9
SLIDE 9

Softwaretechnologie II

Idea of Structurings

Ø

Structuring allow for subsequently following the structure

Ø Sequential algorithms can be applied Ø Recursive algorithm schemas can be applied Ø Wavefronts can be applied

Ø

Structures are nice for thinking and abstraction (see Simon’s law)

Ø In particular in analysis and design

Ø

Structurings prepare further refactorings

Ø

The structural information can be exploited to further transform the code and to prove preservation of semantics

Ø

Structurings need

Ø Logics with types (e.g., F-Datalog) Ø Graph reachability analysis Ø Graph transformation

  • Prof. U. Aßmann

9

slide-10
SLIDE 10

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

16.1 Topologic Sorting of DAGs (Layering)

Overlaying a list on a dag

  • Prof. U. Aßmann

10

slide-11
SLIDE 11

Softwaretechnologie II

Topologic Sorting on Dags

Ø

If constraints for the partial order of some things are given, but no total

  • rder

Ø

It doesn’t matter in which order some things are executed

Ø May be even in parallel

Ø

There are many “legal” orderings, the topological sortings (topsorts, Totalordnung)

  • Prof. U. Aßmann

11

....... ....... .......

slide-12
SLIDE 12

Softwaretechnologie II

Partial Order for Car Departure

  • Prof. U. Aßmann

12

  • pen left door
  • pen right door

close left door close right door drive

slide-13
SLIDE 13

Softwaretechnologie II

Topological Sorts on Car Departure

  • Prof. U. Aßmann

13

1 2 3 4 5

  • pen left door
  • pen right door

close left door close right door drive

slide-14
SLIDE 14

Softwaretechnologie II

Topological Sorts on Car Departure

  • Prof. U. Aßmann

14

1 2 3 4 5

  • pen left door
  • pen right door

close left door close right door drive

slide-15
SLIDE 15

Softwaretechnologie II

Topological Sorting a Directed Acyclic Graph

Ø

Topological sorting sorts the nodes with the „least many ancestors“ first

Ø

TopSort can be described by a subtractive graph rewrite system (SGRS)

  • Prof. U. Aßmann

15

A A:depth B A

depth := gdepth

TopSort-R1: Numbering entry nodes with fan-in 0

B

1

TopSort-R2: Contraction: Remove entry nodes with fan-in 0

gdepth := gdepth+1

http://de.wikipedia.org/wiki/Topologische_Sortierung

slide-16
SLIDE 16

Softwaretechnologie II

Topological Sorts on Car Departure

  • Prof. U. Aßmann

16

Open door Open door close door close door Drive Open door 1 Open door 0 close door close door Drive close door close door Drive close door 3 close door 2 Drive 4 R1 R2, R2 R1, R1 ETC…

slide-17
SLIDE 17

Softwaretechnologie II

Results: Topological Sortings

Ø The derivations of the GRS TopSort result in different topological sortings

  • f the dag.

Ø For instance:

  • Prof. U. Aßmann

17

Open door Open door close door close door Drive

slide-18
SLIDE 18

Softwaretechnologie II

Benefit of TopSorts

Ø

TopSorted dags are simpler

Ø Because they structure partial orderings Ø Removing parallelism and indeterminism

Ø

Question: why are all cooking recipes sequential?

  • Prof. U. Aßmann

18

slide-19
SLIDE 19

Softwaretechnologie II

Applications of TopSort

Ø

Serialization of data structures from the heap

Ø Compute a topsort and flatten all objects in the order of the topsort

Ø

Package trees

Ø Systems with big package trees can be topsorted and then handled in this order

for differenzing between versions (regression tests)

Ø

UML activity diagrams

Ø Finding a sequential execution order

Ø

Project management: (see course “Softwaremanagement”)

Ø Task scheduling for task graphs (milestone plans): who does when what? Ø Find a topsort for the construction of your next house!

Ø

Execution of parallel processes (sequentialization of a parallel application)

Ø Execute the processes according to dependencies of a topsort

Ø

Task scheduling

Ø Find sequential execution order for parallel (partially ordered) activities

  • Prof. U. Aßmann

19

slide-20
SLIDE 20

Softwaretechnologie II

20

16.2 STRONGLY CONNECTED COMPONENTS

How to make an arbitrary relationship acyclic: overlaying a graph with a dag

  • Prof. U. Aßmann

20

....... ....... .......

slide-21
SLIDE 21

Softwaretechnologie II

Strongly Connected Components (Acyclic Condensation) Ø The acyclic condensation (AC) asks for mutual reachability of

nodes, hence for the effect of cycles in graphs

Ø A digraph is strongly connected, if every node is reachable from

another one

Ø A subgraph of a graph is a strongly connected component (SCC)

Ø If every of its nodes is strongly connected

Ø The reachability relation is symmetric

Ø All edges on a cycle belong to the same SCC

Ø How to compute reachability:

Ø Declaratively: Specification with an EARS or recursive Datalog:

sameSCC(X,Y) :- reachable(X,Y), reachable(Y,X).

Ø Imperatively: Depth first search in O(n+e)

Ø The AC has n strongly connected components

  • Prof. U. Aßmann

21

slide-22
SLIDE 22

Softwaretechnologie II

The Result of the SCC Analysis: the Acyclic Condensation

Ø

The SCC of a graph form „abstract super-nodes“

Ø

This dag of super-nodes is called acyclic condensation (AC)

  • Prof. U. Aßmann

22

SCC (super-nodes)

slide-23
SLIDE 23

Softwaretechnologie II

Applications on SCC: Attribute Evaluations on Digraphs Ø

Many algorithms need acyclic graphs, in particular attribute evaluation algorithms

Ø The data flow flows along the partial order of the nodes Ø For cyclic graphs, form an AC

Ø

Propagate attributes along the partial order of the AC (wavefront algorithm)

Ø Within an SCC compute until nothing changes anymore (fixpoint) Ø Then advance Ø No backtracking to earlier SCCs

Ø

Evaluation orders are the topsorts of the AC

  • Prof. U. Aßmann

23

slide-24
SLIDE 24

Softwaretechnologie II

A Wavefront on an AC

  • Prof. U. Aßmann

24

slide-25
SLIDE 25

Softwaretechnologie II

Applications

Ø SCCs can be made on every graph

Ø Always a good structuring means for every kind of diagram in design Ø SCCs form “centers” Ø Afterwards, the AC can always be topsorted, i.e., evaluated in a total

  • rder that respects the dependencies

Ø Useful for structuring large

  • Data diagrams: Class diagrams, package diagrams, object diagrams
  • Behavioral diagrams: statecharts, data-flow diagrams, Petri nets, and

UDUGs, call graphs

  • Coalesce loops into subdiagrams

Ø Wavefronts can be used for attribute calculations on graphs

Ø Analyzing statistics on graphs Ø “reduce” problems: reducing all attributes of a specific kind over all

nodes and edges of the graph

Ø Flow problems: calculating costs of paths

  • Prof. U. Aßmann

25

slide-26
SLIDE 26

Softwaretechnologie II

Applications of SCC

Ø Computing definition-use graphs (the UDG and the UDUG)

Ø Many diagrams allow to define a thing (e.g., a class) and to use it Ø Often, you want to see the graph of definitions and uses (the definition-

use graph)

Ø Definition-use graphs are important for refactoring, restructuring of

software

Ø Whenever a definition is edited, all uses must be adapted Ø A definition use graph refactoring tool automatically updates all

uses

Ø Computing Software Metrics

Ø A metric is a quantitative measure for code or models Ø Metrics are computed as attributes to source code entities, usually in a

wavefront

Ø Examples: Ø Number of instruction nodes in program graphs (instead of Lines-

  • f-code)

Ø Call graph depth (how deep is the call graph?) Ø Depth of inheritance dag (too deep is horrible)

  • Prof. U. Aßmann

26

slide-27
SLIDE 27

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

16.3 REDUCIBILITY

Has the graph a skeleton tree structure? [ASU86] (Finding a hierarchy in a graph-based model)

  • Prof. U. Aßmann

27

slide-28
SLIDE 28

Softwaretechnologie II

Why Is a UML Statechart Simple to Understand?

Ø

It is not a plain automaton

Ø

But hierarchically organized

Ø Certain states abstract substatecharts

  • Prof. U. Aßmann

28

Controlling Non Controlling Off SwitchOff SwitchOn Move Quiet On On Off SwitchOff SwitchOn

Auto Pilot

slide-29
SLIDE 29

Softwaretechnologie II

... it is a Reducible Graph

Ø

But hierarchically organized

  • Prof. U. Aßmann

29

Controlling Non Controlling Off SwitchOff SwitchOn Move Quiet On

Auto Pilot

Working Working On Off Controlling Non- Controlling

slide-30
SLIDE 30

Softwaretechnologie II

A Reducible Graph

Ø

A reducible graph has special areas with subdags and cycles, supernodes

Ø

In a reducible graph, there is a spanning tree with primary edges:

Ø

Each diamond has a secondary edge, ending in a join node

Ø

Each cycle has one backedge to a loop head node

Ø

Attention: this is not an acyclic condensation!

  • Prof. U. Aßmann

30

Loop Loop head head node node Jo Join node node Loop Loop head head node node

slide-31
SLIDE 31

Softwaretechnologie II

A Reducible Graph

Ø

Every super-node in a reducible graph has a head that represents or abstracts it

Ø All ingoing edges into the super node end in the head Ø Loop head nodes can be head nodes; join nodes not Ø The head node of a supernode is refined from a refinement node in another

supernode

  • Prof. U. Aßmann

31

Super-node Refinement nodes

He Head node node

slide-32
SLIDE 32

Softwaretechnologie II

Reducible Graphs

Ø

Reducible graphs have a hierarchical structure, expressed by their skeleton tree of super nodes with head nodes

Ø Supernodes can hide subgraphs Ø Attention: SCC have a DAG structure (different!)

Ø Reducible graphs may stem from the refinement operation applied to

refinement nodes

  • If an engineer refines, reducible structures result
  • Prof. U. Aßmann

32

Super-nodes

slide-33
SLIDE 33

Softwaretechnologie II

A Reducible Graph

Ø

A skeleton tree (skeleton hierarchy) between the super-nodes results

Ø

Graph is structured and much simpler to comprehend

  • Prof. U. Aßmann

33

Head Super-node

slide-34
SLIDE 34

Softwaretechnologie II

Reducible Graphs in Software Engineering

Ø

Submodels can be abstracted into single nodes

Ø

Whole model can be abstracted into one node

Ø

Skeleton tree structures the model

Ø

Reducibility law:

Ø

Otherwise large models cannot be understood

  • Prof. U. Aßmann

34

A model should use reducible graphs to be comprehensilbe and to enable efficient algorithms Principle of structured modeling and structured programming: The refinement operation is very helpful because it results in reducible graphs and models

slide-35
SLIDE 35

Softwaretechnologie II

The Fractal-Like Behavior of Reducible Graphs

Ø

A reducible graph can be zoomed-in and zoomed-out, like a fractal

Ø

Refinement nodes can be zoomed in

Ø

Zooming-out means abstraction

Ø

Zooming-in means detailing

  • Prof. U. Aßmann

35

Zoom-In Zoom-In

slide-36
SLIDE 36

Softwaretechnologie II

Advantages of Reducible Graphs

Ø All recursion techniques on trees can be taken over to the skeleton

trees of the reducible graphs Ø

For reducible graphs, usually recursion schemas can be applied

Ø

Branch-and-bound Ø

Depth-first search

Ø

Dynamic programming

Ø Applications

Ø Organisation diagrams: if a organization diagram is not reducible,

something is wrong with the organization

Ø This is the problem of matrix organizations in contrast to

hierarchical organizations

Ø

How to Diff a Specification? Ø Text: well-known algorithms (such as in RCS) Ø XML trees: recursive comparison (with link check) Ø Dags: layer-wise comparison Ø Graphs: ??? For general graphs, diffing is NP-complete (graph

isomorphism problem)

  • Prof. U. Aßmann

36

slide-37
SLIDE 37

Softwaretechnologie II

Application: Simple Diffing in Reducible Graphs

Ø

Given a difference operator on two nodes in a graph, there is a generic linear diff algorithm for a reducible graph:

Ø Walk depth-first over both skeleton trees Ø Form the left-to-right spanning tree of an SCC and compare it to the current SCC

in the other graph

Ø

Exercises: effort?

Ø how to diff two UML class diagrams? Ø how to diff two UML statecharts? Ø how to diff two colored Petri Nets? Ø how to diff two Modula programs? Ø how to diff two C programs?

  • Prof. U. Aßmann

37

slide-38
SLIDE 38

Softwaretechnologie II

Application: Simple Coverage Testing in Reducible Control- Flow Graphs (CFG)

Ø

Coverage tests simplify in reducible programs, because all control flow to nodes goes through the representant of the supernode

Ø

The nodes reaches via the supernode.

Ø

Testing the representant of the supernode tests also also other nodes in the supernode.

  • Prof. U. Aßmann

38

slide-39
SLIDE 39

Softwaretechnologie II

Applications of Reducibility in Software Engineering

Ø

Structured programming produces reducible control flow graphs (Modula and Ada, but not C)

Ø Dijkstra‘s concern was reducibility Ø Decision tables (Entscheidungstabellen) sind hierarchisch Ø Structured Analysis (SA) is a reducible design method Ø Colored Petri Nets can be made reducible Ø UML

Ø

CBSE Course:

Ø Component-connector diagrams in architecture languages are reducible Ø Many component models (e.g., Enterprise Java Beans, EJB)

Ø

Architectural skeleton programming (higher order functional programming)

Ø Functional skeletons map, fold, reduce, bananas

  • Prof. U. Aßmann

39

If If yo you ca can, , re refactor any any pr progr

  • gram

am or

  • r mo

model in into re reducible fo form

slide-40
SLIDE 40

Softwaretechnologie II

Example: UML Restructuring

Ø

Structure UML Class Diagrams

Ø

Choose an arbitrary UML class diagram

Ø

Calculate reducibility

Ø If the specification is reducible, it can be collapsed into one class Ø Reducibility structure gives a simple package structure

Ø

Test dag feature

Ø If the diagram is a dag, it can be layered

Ø

TopSort the diagram

Ø A topsort gives a linear order of all classes

Ø

UML Packages are not reducible per se

Ø Large package systems can be quite overloaded Ø Layering is important (e.g., 3-tier architecture) Ø Reducible packages can be enforced by programming discipline. Then, packages

can better be reused in different reuse contexts

Ø

UML statecharts are reducible

Ø

UML component, statecharts and sequence diagrams are reducible

  • Prof. U. Aßmann

40

slide-41
SLIDE 41

Softwaretechnologie II

41

16.3.2 COMPUTING REDUCIBILITY WITH GRAPH REWRITING

Reducibility relies on the theory of “graphs without forbidden minors”

41

  • Prof. U. Aßmann
slide-42
SLIDE 42

Softwaretechnologie II

Computing Reducibility with T1-T2 Graph ReductionSystem

Ø

A reducible digraph is a digraph, that can be reduced to one node by the following graph rewrite rules [Tarjan74]

Ø

Specification with a subtractive GRS (SGRS):

  • Prof. U. Aßmann

42

A A

Reducibility-T1: Remove reflective edges

A B AB

1

Reducibility-T2a: Merge successors with no fan-out and fan-in 1 (collapse rule a)

slide-43
SLIDE 43

Softwaretechnologie II

Computing Reducibility with T1-T2 Graph Reduction System

  • Prof. U. Aßmann

43

A B AB

1

Reducibility-T2b: Merge successors with fan-in of 1 and fanout (collapse rule b)

Side condition of Reducibility-T2: If there is a node B, that has a unique predecessor, A, then m may consume n by deleteing B and making all successors C of B (including A, possibly) be successors of A.

C C

slide-44
SLIDE 44

Softwaretechnologie II

Example: T1 – T2 Reduction

Ø

On every level, in the super nodes there may be cycles

Ø T2 shortens these cycles Ø T1 reduces reflective cycles to super nodes

Ø Example: Reduction of a finite state automaton

  • Prof. U. Aßmann

44

a b c d a b cd a b cd ab cd abcd

=> => => =>

T1 T2 T2 T2

slide-45
SLIDE 45

Softwaretechnologie II

Ø Reduction of an IF structure

  • Prof. U. Aßmann

45

A:If b c

=>

T2

Join

A:If c

B Join

=>

T2 A:If

B Join C A B Join C

=>

T2

slide-46
SLIDE 46

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

16.3.2 MAKING GRAPHS REDUCIBLE

Restructuring an arbitrary graph to be reducible

  • Prof. U. Aßmann

46

slide-47
SLIDE 47

Softwaretechnologie II

Every Graph Can Be Made Reducible

Ø

By duplicating shared parts of the graph that destroy reducibility structure

Ø Builds a skeleton tree

Ø

The process [JC97] is called node splitting:

Ø If the reducability analysis yields a limit graph that is other than a single node, we

can proceed by splitting one or more nodes

Ø If a node n has k predecessors, we may replace n by k nodes. Ø The ith predecessor of n becomes the predecessor of ni only, while all successors

  • f n become successors of all the ni’s.
  • Prof. U. Aßmann

47

slide-48
SLIDE 48

Softwaretechnologie II

Example: Node Splitting with Subtree Replication

Ø

If a loop is irreducible, node has two ancestors. For instance, a join node may also be a loop head node

Ø

Remedy

Ø

Separate the loop from the join node

Ø

Duplicate the irreducible node in an irreducible loop (even with subtrees)

Ø

Most often, the join and loop head node can be taken

  • Prof. U. Aßmann

48

1 2 3 1 2a 3

2b

1,2a 2b,3 1,2a,2b,3

=> => =>

Irreducible graph:

Duplicate a node with fan-in 2 Reduce with Reducibility-T2 Reduce with Reducibility-T2

slide-49
SLIDE 49

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

16.4 SUMMARY OF STRUCTURINGS

  • Prof. U. Aßmann

49

slide-50
SLIDE 50

Softwaretechnologie II

50

Structurings Producing Lists and Graphs

More Structurings Producing Lists

Ø

Layering

Ø

Overlaying a list of layers onto a dag

Ø

”same generation problem”

Ø

Standard Datalog, DL, EARS problem

More Structurings Producing Trees

  • Dominance Analysis
  • Overlays a dominator tree to a graph
  • A node dominates another if all paths

go through it

  • Applications: analysis of complex

specifiations

  • Planarity
  • Finds a skeleton tree for planar

drawing

  • A graph is planar, if it can be drawn

without crossings of edges

  • Computation with a reduction GRS,

i.e., planarity is a different form of reducibility

  • Application: graph drawing
  • Graph parsing with context-free

graph grammars

  • Overlaying a derivation tree
  • Rules are context-free
  • Prof. U. Aßmann

50

slide-51
SLIDE 51

Softwaretechnologie II

More Structurings Producing Dags

Ø

Stratification

Ø Layers of graphs with two relations Ø Normal (cheap) and dangerous (expensive) relation Ø The dangerous relation must be acyclic Ø And is layered then Ø Applications: negation in Datalog, Prolog, and GRS

Ø

Concept Analysis [Wille/Ganter]

Ø Structures bipartite graphs by overlaying a lattice (a dag) Ø Finds commonalities and differences automatically Ø Eases understanding of concepts

  • Prof. U. Aßmann

51

slide-52
SLIDE 52

Softwaretechnologie II

52

Comparison of Structurings

  • Prof. U. Aßmann

52

Implementation of process diagrams Order x TopSort Structure Forward flow Wavefronts x Strongly conn. components Structure Hierarchy x Graph parsing Structure Layering x Stratification Comparison Commonalities x Concept analysis Drawing Hierarchy x Planarity Visit frequency Importance of nodes x Dominance Structure Hierarchy x Reducibility Layers Order x Layering Purpose Concept Dag Tree List

slide-53
SLIDE 53

Softwaretechnologie II

Simple Models in Software Engineering

Ø

Models and specifications, problems and systems are easier to understand if they are

Ø Sequential Ø Hierarchical Ø Acyclic Ø Structured (reducible)

Ø

And this hold for every kind of model and specification in Software Engineering

Ø Structurings can be applied to make them simpler Ø Structurings are applied in all phases of software development: requirements,

design, reengineering, and maintenance

Ø Forward engineering: define a model and test it on structure Ø Reverse engineering: apply the structuring algorithms

  • Prof. U. Aßmann

53

slide-54
SLIDE 54

Softwaretechnologie II

Other Software Engineering Applications

Ø

Structured Programming (reducible control flow graphs), invented from Dijkstra and Wirth in the 60s

Ø

Description of software architectures (LeMetayer, 1995)

Ø

Description of refactorings (Fowler, 1999)

Ø

Description of aspect-oriented programming (Aßmann/Ludwig 1999)

Ø

Virus detection in self-modifying viruses

  • Prof. U. Aßmann

54

slide-55
SLIDE 55

Softwaretechnologie II

The End: What Have We Learned

Ø

Understand Simon’s Law of Complexity and how to apply it to graph-based models

Ø

Techniques for treating large requirements and design models

Ø

Concepts for simple software models

Ø

You won't find that in SE books

Ø

.... but it is essential for good modelling in companies

  • Prof. U. Aßmann

55

slide-56
SLIDE 56

Softwaretechnologie II

16.5 BIGRAPHS

  • Prof. U. Aßmann

56

slide-57
SLIDE 57

Softwaretechnologie II

Ø A bigraph consists of a carrier forest (place graph) and a link graph of connections Ø A bigraph is reducible

  • Prof. U. Aßmann

57