Modularity is one of the most important principles in software engineering and a necessity for every practical software. Since the design space of software is generally quite large, it is valuable to provide automatic means to help modularizing it. An automatic technique for software modularization is object- oriented concept analysis (OOCA). X-ray view of the class is one of the aspect of this Object oriented concept analysis. We shall use this concept in a java environment.
Concept Analysis (CA) is a branch of lattice theory that allows us to identify meaningful groupings of elements (referred to as objects in CA literature) that have common properties (referred to as attributes in CA literature). These groupings are called concepts and capture similarities among a set of elements based on their common properties. In the specific case of software reengineering, the system are composed of a big amount of different entities (classes, methods, modules, subsystems) and there are different kinds of relationships among them. It also represents dependencies among the classes or entities. X-Ray views -a technique based on Concept Analysiswhich reveal the internal relationships between groups of methods and attributes of a class. X-Ray views are composed out of elementary collaborations between attributes and methods and help the engineer to build a mental model of how a class works internally.
Within object oriented software, the minimal unit of development and testing is a class. Usually, a class is composed of instance variables used to represent the state, and methods used to represent the behavior of the classes. Then, understanding how a class works means identifying several aspects: How the methods are interacting together (coupling between methods) How the instance variables are working (or not) together in the methods (coupling between instance variables) Which methods are using (or not) the state of the class if there are methods that form a cluster and define together a precise behaviour of the class Which methods are considered as interfaces Which methods are used as entry points (methods that are considered as interfaces and communicate with other methods defined in the class) Which methods and instance variables represent the core of the class Which methods are using all the state of the class In paper [1], the authors have given an idea of concept analysis. Mathematically, concepts are maximal collections of elements sharing common properties. To use the CA technique, one only needs to specify the properties of interest on each element, and does not need to think about all possible combination of these properties, since these groupings are made automatically by the CA algorithm. The possibility of capturing similarities of elements in groups (concepts) -based on the specification of simple properties allow to identify common features of the elements. When we are able to characterize the entities in terms of properties, and we can detect if these characteristics are repeated in the system, then we can reduce the amount of information to analyze and we can have an abstraction of the different parts of a system. These abstractions help us to start to see how the parts are working, how they are defined and how they are connected to other parts of the system .The elements are the instance variables and the methods defined in the class, and the properties are how they are related between themselves.
If we have the set of instance variables {A, B}, and the set of methods {P, Q, X, Y} defined in a class, the properties we use are: B is used by P means that the method P is accessing directly or through an accessor / mutator to the instance variable B. Q is called in P means that the method Q is called in the method P via a self-call. It also shows indirect dependencies between elements if exists. They have also shown different types of relations and dependencies through some notations. {E1, ..,En} R {M1, ..,Mp} means that the entities {E1, ..,En} depend exclusively on {M1, ..,Mp}. This means that {M1, ..,Mp} are the only entities that are related through the property R to {E1, ..,En}. {E1, ..,En} R {M1, ..,Mp} means that the entities {E1, ..,En} do not depend exclusively on {M1, ..,Mp}. {E1, ..,En} R*{M1, ..,Mp} means that the entities{E1, ..,En} depend exclusively and transitively on {M1, ..,Mp}. This means that {M1, ..,Mp} are the only ones that are related to {E1, ..,En} through the property R and R1, where R1 is an intermediate property, because there is a set {N1, ..,Nk} such that: {E1,..,En} R {N1, ..,Nk} R1 {M1, ..,Mp}. {E1, ..,En} R {M1, ..,Mp} means that the entities {E1, ..,En} do not depend exclusively but transitively on {M1, ..,Mp}. This means that {M1, ..,Mp} are not the only ones that are related to {E1, ..,En} through the property R and R1, where R1 is an intermediate property, because there is a set {N1, ..,Nk} such that: {E1, ..,En} R {N1, ..,Nk} R1 {M1, ..,Mp}.
A special case: {E1, ..,En} ¬R {M1, ..,Mp} means that the entity {E1, ..,En} has any dependencies on {M1, ..,Mp}. This is only applicable on exclusive dependencies.
In paper [2], the authors have discussed different types of X-ray views which will be helpful for our future work. In paper [3] there is a concept on modularization using the conceptual analysis on object oriented environment.
Our idea is now to use the above said concepts in the environment of java and to way out the modularization in j
This content is AI-processed based on open access ArXiv data.
