Modern Programming Languages (Object Oriented Languages), are equipped with sophisticated mechanisms to assist developers in organizing the source code. For instance, Java and Python use package names to resolve symbols. In Java, a package is a namespace declared at the top of each class or interface. There are several reasons for using packages in the source code: 1) Packages can prevent naming conflicts, (e.g., identical class name in two packages is possible with no conflict). 2) Packages can categorize the relevant and/or similar classes or interfaces in some conceptual and logical containers that assist developers in easier maintenance and a better understanding of the design of the software's architecture. 3) Structured packaging is one of the core components of a clean architecture design. Developers may apply diferent strategies to structure the packages and these diferences have repercussions in the quality and maintainability of the software architecture. In this work, we run a set of experiments on a number of open-source Java projects and analyse the packaging structures from a source-code structural and artifact (class, method, variable) names perspective. These experiments aim to investigate 1) the existence of any associations between the packaging structure and textual factors (artefact names) of the classes inside the package; and 2) what textual factors (artifact names) tend to be more associated with the package structure. The results of this research indicate that, on average, class names and inheritance (supper class names) tend to be considered as a packaging strategy. The focus on identifying 'naturally' occurring similarities in the packaging of software in the 'wild' is underpinned by the long-term objective to build developer-friendly architecture conformance protocols which help prevent architectural erosion.
level container or module, called a package.
Usually, the visual representation of a software’s archiObject oriented programming is underpinned by the idea tecture is a graph-like design where the software compoof creating classes and using objects of those classes for nents are program packages that, in their turn, may conhigher reusability and better maintenance. The object tain other packages (hierarchical packages) [1, 2]. In most oriented programming paradigm is based on bringing software architecture design practices, modules or comrelated fields and functions/methods together for a par- ponents are seen as a package or a set of packages [3, 4, 5]. ticular concept that is called a class. Diferent objects Hence, the intuition is that package structure can have a then can be instantiated from classes with diferent data direct impact on the quality of the software architecture. and implementation but they all share the same original Indeed this intuition has attracted the interest of other type, i.e., the class. For example, a class may represent researchers of the field such as Ebad et al., [6]. a car and its objects can be a hatchback or a sport utility One of the fundamental aspects of an architectural vehicle. In object oriented programming, methods and design is to consider the functionalities and interactions ifelds within a given class are expected to be logically between components at diferent granularities [7] with grouped in one container called class. a view of facilitating work among the components in a
Some of the modern object oriented languages, includ- package. ing Java and Python, have another mechanism called Researchers [8, 9, 10, 7] show that a clean software packaging that lets developers have a higher level of architecture has a direct relation to the structured packgrouping where related classes can be located in a high- aging; furthermore, they show how implicit packaging can cause architectural mismatching. They use the term ECSA2021 Companion Volume unstructured packaging as a lack of packaging strategy. ("A.fMarjsehdaad).toosi@mtu.ie (F. G. Toosi); anila.mjeda@mtu.ie For instance, all classes would be located in one package ~ or there are random packages, and classes are assigned https://www.linkedin.com/in/farshad-ghassemi-toosi-428a5852/ to them based on no particular strategy. As a result of (F. G. Toosi); https://www.linkedin.com/in/anila-mjeda-32a5064/ such packaging structure (or unstructured packaging), (A. Mjeda) there will be several of unrelated classes with no naming (A.0M00je0d-0a0)02-1105-4819 (F. G. Toosi); 0000-0003-1311-6320 and textual relevancies to each other in a package [8].
© 2021 Copyright for this paper by its authors. Use permitted under Creative Naming relevancy, in particular, is important since arteCPWrEooUrckReshdoinpgs IhStpN:/c1e6u1r3-w-0s.o7r3g CCoEmmUoRns LWiceonsrekAstthribouptionP4r.0oIncteerenadtiionnagl s(CC(CBYE4U.0)R.-WS.org) facts (class, method, variable) are meant to be named by developers according to their responsibilities and functionalities.
Java is one of the object oriented languages that ofers the packaging mechanism. Every Java class is inside of a package (unless there is no package declared, then the class will be part of the default package). In this work, we are using Java as the language of our case study to answer the following research questions: 1. Are there any existing associations between the package structure and textual factors within the package?. The textual factors in question include artefact names e.g., class, method and variable names. 2. What type of names and at what granularity tend to have more weight on influencing packaging structure?
try to discover the level of textual cohesion among components of each package to understand if there is any textual packaging structure in the project or not, and if so, what type of artefact name has a heavier role.
In large programs, it is dificult to have an architecture for a software system that conforms to the system’s packaging structure. Object-oriented software, has an inherent afinity for structure such as packages as one of its appealing promises. Albeit, that afinity does not necessarily automatically translate to a structure that is relevant to the architecture of the system. This issue has seeded research into improving the packaging structure of the software system. Shaw et al. [10] propose that the potential existing problem with reusing components of a software system is not necessarily due to the bad architectural design but the packaging strategy as well. Shaw et al., in a diferent work [ 7], emphasise the importance of a packaging strategy to enforce compatible components to be located in the same package.
The quality of the software architecture depends on several factors; one of which is the applied packaging strategy [8, 9, 10, 7]. The packaging strategy refers to the criteria that is used to combine components in packages.
One of the first empirical studies to investigate the structure of written code [11], relied on static and dynamic analysis (of FORTRAN code) and looked at it at a statement level. Existing research tends to look at improving existing package design, such as through package structure analysis [12], using package cohesion to assess organization and reusability of code [13, 14], or using artificial intelligence algorithms or multi-objective approaches based on remodularization objectives [15].
matically optimise inter-package dependencies [16]. A review of looking at object-oriented code issues in this space as refactoring opportunities, can be found in [17].
Interestingly for our research, Baxter et al [18] investigated some of the reasons behind the structures and structural relationships in Java code, while Abedeen et al. [16] proposed a set of metrics to assess modularity principles for packages in large legacy systems (namely information hiding, changeability and reusability principles) [19]. Coming up to twenty years ago, Hautus [12] proposed a tool to run a package structure analysis through Java code and highlight potential weak areas to the human with an aim to refactor the source code.
Yet, there is still no standard and unique definition of relevant and/or similar classes and developers might consider diferent criteria to insert two or more classes into a package. The latter becomes problematically evident when analysing code in the wild. Furthermore, packages typically appear in software architecture documentation as not-dividable components of package diagrams, drilling down within packages and investigate their relevancy validity within, has an added value.
It is exactly this gap that is the focus of this research. Indeed, the research reported in this paper represents the initial steps into identifying relevancy (through similarity) factors within packages (or architecture components) with a long term view of building developer-friendly architecture conformance protocols so as to prevent architectural erosion.
study and their details are represented in Table 1.
The experiment tries to find whether there are factors that can define the relation within the members of each package or not. It is worth noting that the factors are mostly textual factors (e.g., artefact names) and not the functional factors (e.g., the functionality of the artifacts) unless the functionality of the artifacts is reflected in their names. The details of these factors are discussed in Section 3.2.
The logic of the experiment is as follows:
the package structure (the left bottom rectangle in Figure 1). 2. Pairwise similarity between every pair of classes is calculated based on some similarity factor (see
Section 3.2). 3. A clustering technique is applied on the members of the class pool and clusters are generated ( is the number of packages in the project).
4. The clustering result (the right bottom rectangle (i.e., Class name, Method name and Variable/Field name). in Figure 1) is compared to the package struc- Each name will be converted to some simple-names afture of the project (the top rectangle in Figure 1), ter the pre-processing. The following list indicates the where each package can be seen as an existing required actions for pre-processing.
cluster.
All the experiments in this work are at source-code level and focus on three diferent types of artefact names: 1) Class names, 2) Method names and 3) Variable/Field names. The comparisons are based on textual/term comparison. Therefore, a simple pre-processing step is required prior to the actual comparison on each name • Camel Case removal. E.g., StudentGrade → Student Grade (StudentGrade as a name is converted to two simple-names: Student and Grade) • Snake Case removal. E.g., Employee_tax → Employee tax • Digits removal. E.g., distance100km → distance km, salary100k → salary (Note, words with one character are ignored). • All lower case. PensionCalculator → pension calculator
As mentioned earlier, the pool of classes is grouped via a clustering algorithm. Clustering algorithms work based on a similarity or dissimilarity matrix where the similarity/dissimilarity between every pair of entities (classes in this case) is known. Therefore, a similarity needs to be defined between every two classes. Each Java class has several diferent features and characteristics such as the class name, the method names within the class, field names and many more. In this work, we make use of nine diferent features of each class and use them as similarity factors for the clustering algorithm. The nine diferent factors that are examined are as follows: 3.2.2. Outgoing Methods • Class Names. Two classes are compared according to their names, (CN). • Outgoing Methods. Two classes are compared according to their outgoing method names, (OM). • Incoming Methods. Two classes are compared according to their incoming method names, (IM). • Field Declaration. Two classes are compared according to their declared fields names, ( FD). • Variable Accessed. Two classes are compared according to their accessed variables’ names, (AV). • Outgoing Class. Two classes are compared according to the class names where they were instantiated, (OC). • Incoming Class. Two classes are compared according to their instantiated class names in them, (IC). • Class Methods Names. Two classes are compared according to their method names, (CM). • Supper Class Names. Two classes are compared according to their supper class names, (SC).
sidered to measure the similarity between two classes.
For class A, all the methods that are called from class A in the project are collected and their names are preprocessed so a set of simple names is generated for class A. A similar process is repeated for Class B.
Figure 3 shows two classes with their methods and the callee (outgoing) methods inside of them. The set of simple names that can be extracted for Class A based on their callee methods is {, , } and the set of simple names for
Class B is {, , , ℎ}. There is one
Each Java program is analysed and nine diferent types simple term common within these two sets, therefore, a of information (mentioned earlier) are extracted. In or- degree of similarity exists within Class A and Class B. der to extract the details from the Java projects, a Java parser is employed. Among diferent choices of parsers, JavaParser [20] was selected due to its simplicity in implementation and high reputation. 3.2.1. Class Names Class Names (CN) is the first factor that is used for comparison. Two classes are said to be similar if their names are similar or in other words, if they share some simpleterms. Figure 2 has two packages and each package has two classes. A set of simple-terms is generated for each class in the project: 1. _ class: {, }. 2. class: {, }. 3. class: {}.
4. class: { , }.
ond class and the fourth class as they share . Likewise, the second class and fourth class have a degree of similarity while the third class is not similar to any class.
measure the similarity between two classes. This factor, similar to the last one, works based on the method calls.
Two classes are said to be similar if their contained methods are called by methods with similar name (common simple terms). 3.2.4. Field Declarations Field Declaration (FD) is another selected factor and it measures the similarity between classes based on declared fields within the class. Therefore, two classes with similarly declared field names are considered similar. Figure 4 shows two classes with their declared fields. Class A has the following set of simple-terms extracted from its declared fields {, , , } and Class B has the following: { , ℎ, }. Therefore, 3.2.7. Incoming Classes Class A and B are similar due to the existing of in both sets of simple terms.
Incoming class (IC) is another notion we use in this experiment as a similarity factor. Class A is considered as an incoming class for Class B if Class B is instantiated in Class A. In Figure 6 DrawCircle is the incoming class for PaintSurface class. Two classes are said to be similar if their classes are instantiated with the same class or classes with similar names. 3.2.5. Accessed Variables
sure the class similarities. Two classes are considered similar if they are accessing variables/fields with similar names.
(CM). Two classes are considered similar if they have 3.2.6. Outgoing Classes methods with similar names. Figure 7 shows two classes with their contained methods. Class A has the followThe next factor to measure the package similarity is Out- ing set of simple-names extracted from method names: going Class names (OC). The characterization of being {, , , } and class B has the followan Outgoing Class is a subjective role for a class. Having ing set: {, , , , }. Since there two classes (Class A and Class B), Class B is said to be is one term common in both sets, therefore, Class A and an outgoing class for Class A, if Class B is instantiated B are similar with some degree. in Class A. Figure 5 shows two classes, each class has two methods and each method instantiates another class. 3.2.9. Supper Classes The name of the instantiated classes for each class are extracted, pre-processed and compared. Class A contains Classes are also compared by their supper classes. For the following set of simple terms extracted from instanti- each class, all the super class names are collected, preated classes: {, , } and the set associated processed and a set of simple-terms is generated. Similar with Class B is: {, , , , }. As to other similarity factors, the common simple-terms shown in Figure 5, three simple terms are common within for each pair of classes is an indication of the degree of these two sets: {, , }. Therefore, Class similarity. In Figure 8, there are two classes with some A and B are similar with some degree. More details of super classes for each. The set of simple-terms for A is: how the degree of similarities is taken into account for {ℎ, } and for B is: {}. Since there comparison, will be discussed in later sections. is no common simple-term in these two sets, there is also
Clustering is a task of splitting individuals into a number of groups or clusters where the members of a cluster are more similar to other members of the same cluster than the members of other clusters. In this experiment, classes are considered as individuals, therefore, classes with more similarity would be clustered in one group. As mentioned in previous section, there are nine diferent similarity factors considered in this work, therefore, for each Java project, clustering runs nine times, each time with a diferent factor. The goal is to measure how much a given factor, as a similarity criteria, conforms to the existing packaging in the system.
Clustering is an unsupervised learning technique that has applications in many diferent fields and domains. K-Means [21], Afinity propagation [22], DBSCAN [23] and Spectral Clustering [24] are a number of clustering algorithms and the choice of algorithm depends on the nature of the data.
cluster the pool of classes (see Figure 1). Spectral Clustering algorithm is based on eigendecomposition calculation
The objective is to analyse the individual similarity factors and see how much each of them conform the packaging structure. To do this, the clustering that is resulted from each factor needs to be compared against the packaging structure. Since the clustering is done on clusters ( is the number of packages in the project), therefore, there are two sets of groups where each set contains number of groups of classes. In order to measure the similarities between two sets of groups, we make use of Normalized Mutual Information [25] technique from SKlearn in Python. Normalized Mutual Information measures the similarity between two clusterings [26] and returns a value between 0 to 1. Given two clusterings by two diferent techniques, Normalized Mutual Information specifies how much these two clustering are correlated. Figure 9 shows two clusterings where each clustering has three clusters with their members. As it is shown, there are some diferences between the results of these two techniques. For instance, the first cluster of PS contains 1, 3 and 3 and the first cluster of CR contains 1, 3 and 1. The degree of similarity between the results of these two techniques by Normalized Mutual Information is 0.2804.
ent similarity factors are separately employed to apply a clustering technique and compared against the packaging structure in the system. The nine factors are fully described in section 3.2.
54 experiments are for 6 projects and for each project 9 pFliigeudrcelu1s0t:erTihneg pteecrhcenniqtaugeeaonfdetahceh psiamckilaagriintygbsetrtuwceteunrethuesianpgindividual similarity factors are tested. We run an extra 9 similarity factors. experiment for each project where the similarity factor is the accumulative of all the 9 individual factors.
Figures 10 to 15 show the percentage similarity between the applied clustering technique (Spectral Clustering) and the packaging structure.
The very first observation from all the results indicates the association between class names and packaging. Except for the Java Parser Core project, the class name has the highest impact on the packaging. Even for Java Parser Core, the class name comes in second-highest score. The other observation that can be realized from all diagrams is the association between supper class names and packaging. Except JavaFX project and the Galaxy project, supper class names are the second ‘winners’. Method names for one project (JavaFX ) have a higher associa- Figure 11: The percentage of each similarity between the aption with the packaging compared to other projects. On plied clustering technique and the packaging structure using the other hand, class instantiation (incoming and outgo- 9 similarity factors. ing classes) on average has smaller association with the packaging.
As mentioned earlier, six extra experiments are per- 6. Conclusion formed to see the impact of overall similarity factors when they are accumulated all together. Table 2 depicts the results for each individual project. On average the Galaxy project has a strong naming association with the packaging followed by Java Parser Core and Java Parser Symbol.
six diferent Java Projects to discover the applied packaging strategy from textual and naming point of view.
Our findings (see Table 3) illustrate that there is a textual similarities among components at each package to some extend (the first research question ). On average, the textual similarity is stronger when class names are chosen as a similarity factor (the second research question).
The second factor, after class names, that shows strong packages. Method names, as the third strong factor, on similarities among packages’ components is, on average, average show relatively high similarity among the packthe super class name. This also indicates that most in- ages’ components. heritances are within the packages that is potentially an Although we can confirm that there are a couple of patindication for low cohesion and high decoupling between terns common in all projects (similarity of class names), still almost every project behaves diferently. This can [9] R. C. Martin, J. Grenning, S. Brown, Clean architecbe further confirmed by looking at the results in Table 2 ture: a craftsman’s guide to software structure and where each project shows a diferent aggregated degree design, Prentice Hall, 2018. of similarity packaging ranging from 0.36 to 0.81. [10] M. Shaw, Architectural issues in software reuse:
Looking from another angle, since class names score It’s not just the functionality, it’s the packaging, in: high in terms of similarity factors among the contents in Proceedings of the 1995 Symposium on Software a package, they can potentially be used to validate the rel- reusability, 1995, pp. 3–6. evancy within a package or other architectural construct. [11] D. E. Knuth, An empirical study of fortran proThis claim, however, requires more experimentation on grams, Software: Practice and experience 1 (1971) a larger number of subject systems. 105–133.
This research is only based on the artifact (class, [12] E. Hautus, Improving java software through packmethod and variables) names, therefore, the role of the age structure analysis, in: IASTED International developers’ naming style plays an important role in the Conference Software Engineering and Applications, results. 2002, pp. 1–5.
In future work, we plan to include other similarity [13] V. Gupta, J. K. Chhabra, Package coupling meafactors such as factors that define the functionality of surement in object-oriented software, Journal of the artefacts. This, with a long term objective of using computer science and technology 24 (2009) 273– these ’naturally’ occurring similarities in the packaging 283. of software in the ‘wild’ to build developer-friendly ar- [14] P. J. Kaur, S. Kaushal, A. K. Sangaiah, F. Piccialli, A chitecture conformance protocols which help prevent framework for assessing reusability using package architectural erosion. cohesion measure in aspect oriented systems, International Journal of Parallel Programming 46 (2018) 543–564.
References [15] A. Prajapati, J. K. Chhabra, Madhs: Many-objective discrete harmony search to improve existing pack[1] M.-A. Storey, C. Best, J. Michand, Shrimp views: age design, Computational Intelligence 35 (2019) An interactive environment for exploring java pro- 98–123. grams, in: Proceedings 9th International Workshop [16] H. Abdeen, S. Ducasse, H. Sahraoui, I. Alloui, Auon Program Comprehension. IWPC 2001, IEEE, tomatic package coupling and cycle minimization, 2001, pp. 111–112. in: 2009 16th Working Conference on Reverse En[2] M. Shaw, R. DeLine, D. V. Klein, T. L. Ross, D. M. gineering, IEEE, 2009, pp. 103–112.
Young, G. Zelesnik, Abstractions for software archi- [17] J. Al Dallal, Identifying refactoring opportunities tecture and tools to support them, IEEE transactions in object-oriented code: A systematic literature reon software engineering 21 (1995) 314–335. view, Information and software Technology 58 [3] J. Veit, Modules, Components, and Elements – Soft- (2015) 231–249.
ware Architecture Terms explained (2021). URL: [18] G. Baxter, M. Frean, J. Noble, M. Rickerby, H. Smith, https://dev.to/jessica_veit/modules- componen M. Visser, H. Melton, E. Tempero, Understandts-and-elements-software-architecture-terms-ex ing the shape of java software, in: Proceedings plained-g59. of the 21st annual ACM SIGPLAN conference on [4] Tutisani, Modular Software Architecture - Tutisani Object-oriented programming systems, languages, Consulting, 2021. URL: https://www.tutisani.com/s and applications, 2006, pp. 397–412. of tware-architecture/modular-sof tware-architec [19] H. Abdeen, S. Ducasse, H. Sahraoui, Modularizature.html. tion metrics: Assessing package organization in [5] J. T. Taylor, W. T. Taylor, Software architecture, in: legacy large object-oriented software, in: 2011 18th
Patterns in the Machine, Springer, 2021, pp. 63–82. Working Conference on Reverse Engineering, IEEE, [6] S. A. Ebad, M. Ahmed, Investigating the efect of 2011, pp. 394–398.
software packaging on modular structure stabil- [20] JavaParser.org, JavaParser - Home, 2021. URL: "htt ity, Computer Systems Science and Engineering 34 ps://javaparser.org".
(2019) 283–296. [21] J. A. Hartigan, M. A. Wong, Ak-means clustering [7] M. Shaw, D. Garlan, Formulations and formalisms algorithm, Journal of the Royal Statistical Society: in software architecture, in: Computer Science Series C (Applied Statistics) 28 (1979) 100–108.
Today, Springer, 1995, pp. 307–323. [22] K. Wang, J. Zhang, D. Li, X. Zhang, T. Guo, Adap[8] Vasiliy, 5 Most Popular Package Structures for Soft- tive afinity propagation clustering, arXiv preprint ware Projects, 2020. URL: https://www.techyourch arXiv:0805.1096 (2008). ance.com/popular-package-structures/. [23] K. Khan, S. U. Rehman, K. Aziz, S. Fong, S. Sarasvady, Dbscan: Past, present and future, in: The fifth international conference on the applications of digital information and web technologies (ICADIWT 2014), IEEE, 2014, pp. 232–238. [24] J. Liu, J. Han, Spectral clustering, in: Data Cluster
ing, Chapman and Hall/CRC, 2018, pp. 177–200. [25] R. Koopman, S. Wang, Mutual information based labelling and comparing clusters, Scientometrics 111 (2017) 1157–1167. [26] A. F. McDaid, D. Greene, N. Hurley, Normalized mutual information to evaluate overlapping community finding algorithms, arXiv preprint arXiv:1110.2515 (2011).