## 1 Introduction  
One of the most common design issues in object-oriented systems is having a class with many responsibilities. During the maintenance and evolution activities of a system, new responsibilities may need to be added to the system. Due to time limits, software developers usually feel it is not necessary to create a separate class for a new responsibility and that responsibility can be added to one of the existing classes [1]. After several cycles of maintenance and evolution, some classes in the system will end up having many responsibilities which will increase the maintenance cost of the system because a class with many responsibilities requires more effort and time to understand and maintain. In addition, a class with many responsibilities has many reasons to change because each responsibility the class has is an axis of change [2]. Such a class needs to be refactored in order to improve its understandability and maintainability. The refactoring technique that is usually applied to overcome this issue is called Extract Class refactoring. It refers to the process of splitting a class that has many responsibilities into a set of smaller classes, each of which has one responsibility and one reason to change [1]. Manually performing the process of the Extract Class refactoring costs much time and effort. Thus, several approaches (see, e.g., in [3; 4; 5]) have been introduced in the literature to automate and support the Extract Class refactoring. These approaches conduct the Extract Class refactoring based on factors internal to the class to be refactored such as structural and semantic dependency between the methods of the class. However, this internal view of the class is inadequate in many cases to automatically determine the responsibilities of the class and to highlight potential reasons that can cause changes to the class. For instance, consider the class Circle shown in Figure 1 that has four attributes and nine methods. The class has two client classes: GeometryApp and GraphicsApp. We refer to these two classes as clients of the class Circle because they use methods in the class (see Section 3). The class GeometryApp performs some computational geometry. Thus, it uses the methods that provide geometric computations (e.g., \(area()\)) in the class Circle, but never uses the methods that provide drawing services (e.g., \(draw()\)). The other client class (i.e., GraphicsApp) uses the methods that provide drawing features in the class Circle because it draws shapes on screen including circles. It is obvious that the class Circle has two responsibilities: one responsibility is to perform computational geometry and the other responsibility is to perform drawings on the screen. This may lead to increasing the cost and effort of future changes of the class. Assume that the client class Graphics exerts a change on the method \(setColor(Color)\) in the class Circle. This change may affect the client class Geometry because it depends on the class Circle. Therefore, Geometry may need to be recompiled and retested even though it never uses the method \(setColor(Color)\). In order to address this issue, we need to perform the Extract Class refactoring by splitting these two responsibilities into two separate classes as shown in Figure 2. Existing approaches of the Extract Class refactoring may fail to suggest the refactoring solution shown in Figure 2 because they perform the Extract Class refactoring based on structural and semantic relationships between the methods of the class. The structural relationships between methods in these approaches are measured based on the shared attributes between the methods while the semantic relationships are measured based on the common vocabularies in the documents, e.g., identifiers and comments of the methods. Thus, most of the methods of the class Circle are--to some degree--structurally and semantically related to each other because they likely share attributes and vocabularies, e.g., radius.