Modularity Analysis by the Laplacian Matrix

Modularity Analysis by the Laplacian Matrix

Linear Software Models: Modularity Analysis by the Laplacian Matrix Iaakov Exman and Rawi Sakhnini Software Engineering Dept., The Jerusalem College of Engineering – JCE-Azrieli, Jerusalem, Israel Keywords: Linear Software Models, Modularity Matrix, Laplacian Matrix, Connected Components, Eigenvectors, Zero-valued Eigenvalues, Bipartite Graph, Software Redesign, Coupling Resolution, Outliers. Abstract: We have recently shown that one can obtain the number and sizes of modules of a software system from the eigenvectors of the Modularity Matrix weighted by an affinity matrix. However such a weighting still demands a suitable definition of an affinity. This paper obtains the same results by means of a Laplacian Matrix, directly based upon the Modularity Matrix without the need of weighting. These formalizations are different alternatives leading to the same outcomes based upon a central idea: modules are connected components. The important point is that, independently of specific advantages of given techniques, there is just one single unified algebraic theory of software composition – the Linear Software Models – behind the different approaches. The specifics of the Laplacian Matrix technique, after its formal enunciation, are illustrated by calculations made for case studies. 1 INTRODUCTION 1.1 Modularity Matrix Concepts Software engineering is an exercise in composition Modularity is the antithesis of coupling between (Fall, 2016). A software system is composed from software components. Thus, a theory of modular subsystems, which are made of sub-subsystems and composition must clearly define coupling. An so on for each hierarchy level of the system, down to intuitive notion of coupling is given in the Design indivisible components. The problem to be solved is Patterns GoF book Glossary (Gamma et al., 1995): which components are needed to satisfy the system coupling is the degree to which software required functionalities. It is widely accepted that components depend on each other. In our Linear modularity is essential to solve this problem. Software Models, this is translated to "coupling is Our Linear Software Models approach uses linear dependence" among software components. Modularity Matrices linking component structures to To apply the theory, a Modularity Matrix their functionalities, see (Exman, 2012 and 2013). (Exman, 2014) is constructed for each software The outcome is a set of modules in the respective system. The matrix displays relations between the hierarchical level of the software system. software system architectural entities: column Recently we have shown that numbers and sizes structors, and row functionals. Structors generalize of the referred modules can be precisely obtained UML classes and functionals generalize methods. A from eigenvectors of the Modularity Matrix suitably 1-valued matrix element means that the column weighted by an affinity matrix (Exman, 2015). structor provides a functional in the respective row. In this paper we show that the same numbers and To avoid couplings, a standard Modularity sizes of modules are obtained from the eigenvectors Matrix must have all its structors and respectively all of a Laplacian Matrix, directly derived from the its functionals linearly independent. From linear Modularity Matrix, without the need of weighting. algebra it follows that the standard Modularity In this Introduction we review properties of the Matrix is square. If certain structor sub-sets provide Modularity Matrix and the Laplacian Matrix. sub-sets of functionals disjoint to other sub-sets, the matrix is strictly block-diagonal. These blocks are the desired independent modules. 100 Exman, I. and Sakhnini, R. Linear Software Models: Modularity Analysis by the Laplacian Matrix. DOI: 10.5220/0005985601000108 In Proceedings of the 11th International Joint Conference on Software Technologies (ICSOFT 2016) - Volume 2: ICSOFT-PT, pages 100-108 ISBN: 978-989-758-194-6 Copyright c 2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved Linear Software Models: Modularity Analysis by the Laplacian Matrix In a standard Modularity Matrix modules are strictly block-diagonal Modularity Matrix – the irreducible – cannot be broken into smaller modules. same results are obtained by means of the All the matrix elements outside modules are zero- eigenvectors of the Laplacian Matrix; valued, the modules are orthogonal thus mutually case of outliers – a neat procedure is formulated linearly independent. One easily shows that to highlight residual coupling. eigenvectors of a suitably weighted Modularity The argument centrepiece is that modules are Matrix precisely reflect module sizes. This spectral connected components. This is true for blocks of the approach (Exman, 2015) is illustrated in Fig. 1. block-diagonal Modularity Matrix (Exman, 2014), sub-lattices of a Modularity Lattice (Exman and Speicher, 2015) or sub-graphs obtaining a Laplacian Matrix in this paper. One follows the next steps: a) Generate a Bipartite Graph – from the Modularity Matrix; b) Obtain the Laplacian Matrix – from the generated graph; c) Software Modules are Connected Components – seen in the graph and in the corresponding Laplacian; d) Number of Modules – is set by the number of zero-valued Laplacian eigenvalues; e) Sizes of Modules – are given by the non-zero elements of Laplacian eigenvectors; Figure 1: Schematic Modularity Matrix with a fitting eigenvector – The square block-diagonal matrix has 4 f) Modules Sparsity – may demand module numbered modules (blue background). The eigenvector at splitting to assure sparsity below a threshold, the right-hand-side of the matrix precisely reflects the size thereby highlighting outlier coupling in need of of module #2 (with hatched background). redesign. The above steps will be first intuitively illustrated by 1.2 Laplacian Matrix Concepts an introductory example. Then, formal proofs will be provided in a subsequent section. A generic Laplacian matrix is defined upon a graph. For software systems the graph is undirected, and 1.4 Organization of the Paper edges link the referred architectural units – structors and functionals – where each unit is a vertex in the The remaining of this paper is organized as follows. graph. Formally the Laplacian L is given by: Section 2 mentions related work. Section 3 displays an introductory example. Section 4 formulates LDA (1) theoretical considerations. Section 5 presents case- where D is the Degree Matrix – showing the degree studies. A discussion concludes the paper. deg(vi ) of vertex vi in its diagonal element Dii – and A is the Adjacency Matrix – showing for each ij, pair of vertices whether they are adjacent in the 2 RELATED WORK graph. Adjacent vertices have a 1-valued Aij matrix 2.1 Modularity Analysis element and 0-valued otherwise. Laplacian properties of interest are: Various techniques are suitable for modularity L is symmetric; analysis. Here is a short sample of approaches. The number of zero-valued eigenvalues of the Baldwin and Clark, in their “Design Rules” book Laplacian Matrix is the number of graph (Baldwin and Clark, 2000), describe a Design connected components. Structure Matrix (DSM) upon which one adds an economic design model. DSM has also been applied 1.3 Modules as Connected Components to software engineering (Cai and Sullivan, 2006). Conceptual lattices were introduced in (Wille, This paper’s purpose is to show that for: 1982) within Formal Concept Analysis (FCA). This 101 ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends technique has been used for modularization and software system design, e.g. (Siff and Reps, 1999). In previous spectral work we have used eigenvectors of the Modularity Matrix symmetrized and weighted by an Affinity (Exman, 2015) to extract software system modules' numbers and sizes. 2.2 Laplacian Matrix Techniques Spectral techniques based upon the Laplacian Matrix Figure 2: Prototype Design Pattern Modularity Matrix – have been used in various contexts, including There are 4 structors and functionals in this matrix. These software engineering. A good survey on Laplacian form 3 modules (blue background): a- upper-left shape matrices of graphs is (Merris, 1994). role; b- middle shapes-cache role; c- lower-right the prototype client. Zero-valued matrix elements outside the A tutorial on spectral clustering, with emphasis modules are omitted for clarity in all matrix figures. on Laplacian techniques is (von Luxburg, 2007). A more recent review on clustering methodologies for As an illustration, each 1-valued element in the software engineering, of spectral methods in general Matrix originates one edge, e.g. a 1-valued element and in particular the Laplacian is (Shtern and in column S3 and row F3 of the matrix originates an Tzerpos, 2012). edge between the S3 and F3 vertices in Fig. 3. Ng et al. (Ng et al., 2001) deal with spectral clustering, analysing an algorithm, explicitly referring to the Laplacian. Shokoufandeh et al. (Shokoufandeh, 2005) extract a Module Dependency Graph (MDG) from software source code for clustering into MDG partitions. Their Modularization Quality criterion is reformulated as a Laplacian eigenvalue problem. Figure 3: Prototype Bipartite undirected Graph – It is obtained from the Modularity Matrix in Fig. 2. A structor 3 INTRODUCTORY EXAMPLE: Sj is linked to a functional Fi by a graph edge if the respective (i, j) Matrix element is 1-valued. Separate graph PROTOTYPE PATTERN modules Mk, having no common edges, are highlighted by light

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    9 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us