객체지향 재사용 매트릭스 Object-Oriented Reusability Metrics 홍익대학교 소프트웨어공학연구실 발 표 자 : 변 은 영 지도 교수 : 김 영 철 안녕하세요. 홍익대학교 소프트웨어 공학 연구실 변은영 입니다. ‘객체지향 재사용 매트릭스’에 대해서 발표하겠습니다. 저희 연구실에서는 소프트웨어의 아키텍처 가시화에 대한 연구를 진행해왔습니다. 제 논문에서는 기존의 가시화와 함께 객체지향 프로그램에서 어떤 모듈을 재사용할 수 있는지 식별하는 정적/동적 재사용 매트릭스를 정의하고, 이를 통해서 재사용 모듈을 자동 식별하고 가시화하는 툴체인을 구축했습니다. 이 툴체인은 사용자에게 재사용 가이드라인을 제공하고, 실제 재사용을 통해, 시간과 비용을 절감시키고 생산성과 품질을 향상시키고자 합니다.

Contents I. Motivation II. Related Works III. DROOM(Dynamic Reusability Object-Oriented Metrics) IV. Visualization Tool V. Case Study 목차는 다음과 같습니다. Ⅵ. Conclusions & Future Works

Motivation Reuse : 기존(Legacy) 시스템 확장 및 기능 개선으로 새로운 시스템 구축 ① 빠른 개발(time-to-market), ② 비용 절감, ③ 생산성 향상 이론적으로 재사용을 많이 해야 시간/비용 절감 실제 국방 프로그램에서는 새로운 시스템을 개발하기보다는 기존 시스템을 개선하는 경우가 많음 실제 오픈 소스에서 많은 코드들이 버전 업그레이드에 재사용 어떤 모듈을 재사용 하는가? 동적으로 어떤 모듈들이 재사용되는가? 확인 필요 실제 오픈 소스를 적용하여 재사용 모듈을 식별하는 매트릭스 및 시스템 제안 이 논문에서 설명하고 있는 재사용은 기존 시스템을 확장하거나 기능을 개선하여 새로운 시스템을 구축하는 것을 의미합니다. 이를 통해서, 빠른 개발, 비용 절감, 생산성 향상과 같은 효과가 있다고 이론적으로 언급되고 있습니다. 저희 랩실은 육군 정체단과 MOU 사업을 진행 했었습니다. 사용되고 있는 대부분의 국방 프로그램은 처음부터 전체를 구현하기 보다는 기존 시스템을 기반으로 개선하는 경우가 많았습니다. 이런 도메인에서 재사용은 필수적이었고, 이런 이슈로 재사용에 대한연구를 진행하게 되었습니다. 국방 프로그램은 보안상에 문제가 있기 때문에 타겟을 오픈 소스로 전환했습니다. 오픈 소스 Junit의 버전 업그레이드 시, 코드가 얼마나 재사용되는지 분석해봤습니다.

Motivation 오픈 소스의 업데이트 & 재사용율 JUnit Reuse class Junit 3.4 Junit 4.0 ActiveTestTest V 3.4 x AllTests V 4.0 AsserTest ClassLoaderTest ComparisonCompactorTest ComparisonFailureTest DoublePrecisionAssertTest ExceptionTestCaseTest ExtensionTest Failure FloatAssertTest InheritedTestCase LoadedFromJar NoArgTestCaseTest NoTestCaseClass NoTestCases NotPublicTestCase NotVoidTestCase OneTestCase OverrideTestCase Success SuiteTest TestCaseTest TestImplementorTest TestListenerTest TestTestCaseClassLoader TextRunnerTest WasRun 삭제 재사용 신규 Junit은 자바 환경에서의 단위 테스트를 도와주는 프레임워크로 자바 언어로 구현이 되어있습니다. 9 년간의 업데이트 현황을 보게 되면 작년에 제일 많은 업데이트가 이루어지면서 4에서 5로 버전 업이 있었고, 연 평균 4번, 최대 9번 수행되었습니다. 그 중에서 3.4와 4.0버전의 클래스를 비교해 보면 기존에 있었지만 삭제된 클래스, 기존 클래스를 재사용한 클래스, 새로 생성된 클래스로 구분할 수 있었습니다. 이 세 타입 중에서도 기존 클래스를 재사용한 클래스가 71%로 상당히 많은 부분이 재사용되고 있습니다. 하지만, 이 경우에도 클래스 내부의 모든 메소드를 재사용하기도 하고, 일부 메소드만을 재사용하거나, 혹은 조금씩의 수정이 이루어지기도 합니다. SuiteTest 클래스의 내부 메소드 구조를 통해 확인해보겠습니다. . Reuse The Average annual update = (7+1+5+1+0+5+3+4+9)/9 = 4 Reusability = 20/28 = 71%

Motivation Reuse Method 오픈 소스의 업데이트 & 재사용율 JUnit Project Junit 3.4 Junit 4.0 Class SuiteTest Structure Method Reuse 내부 품질 Bad………………………………… 내부 품질 Bad 외부 결합 ………………………………… 오류 발생 가능성 ↑ Dead Code ………………………………… Dead Code New New 4.0에서 두 개의 클래스는 새로 생성되었고, 대부분의 메소드가 수정되거나 그대로 재사용 되었지만, 한 개의 클래스는 재사용되지 않았습니다. 이렇게, 어떤 모듈은 재사용을 하게 되고, 어떤 모듈을 재사용하지 않게 됩니다. 이 이유는 필요가 없어졌을 수도 있지만, 재사용되는 모듈의 품질이 나쁠 경우, 그대로 재사용하게 되면 새로운 시스템에 품질에 또한 영향을 줄 수 있고, 외부와 강하게 결합되어 있는 모듈은 재사용할 경우, 오류 발생 가능성이 상당히 높아집니다. 또한, 동적 분석이 이루어지지 않으면 데드 코드를 그대로 재사용하는 실수를 하게 됩니다.

Motivation Which module do u reuse? Reusability Metrics 기존 매트릭스 조사 Issue 기존 매트릭스 문제점 도출 개선된 매트릭스 제안 재사용 모듈 식별 및 가시화 시스템 구축 Research Reusability Metrics 따라서, 어떤 모듈을 재사용할 것인가는 매우 중요한 이슈로 이들을 식별하기 위한 재사용 메트릭스가 연구되어 왔습니다. 제 논문에서는 기존 매트릭스의 문제점을 도출하고 이들을 개선한 매트릭스를 제안합니다. 또한, 재사용 모듈을 자동으로 식별하고 가시화 하는 시스템을 구축하고 실제 오픈 소스를 타겟으로 적용합니다. 오픈 소스 및 프로그램 적용

Related Works 대표적인 재사용 메트릭스 CK(Chidamber & Kemerer) Metrics “소프트웨어를 보다 재사용하기 쉽게 하는 특성을 모듈성, 저결합도, 고응집도, 캡슐화 등으로 부른다.” - DocForge, Code reuse[2017] 대표적인 재사용 메트릭스 CK(Chidamber & Kemerer) Metrics METRIC GOAL LEVEL COMPLEXITY (To develop, to test and to maintain) RE-USABILITY ENCAPSULATION, MODULARITY WMC (Weighted Methods per Class) Low ▼ ▲ DIT (Depth of Inheritance Tree) Trade-off NOC (Number of Children) CBO (Coupling Between Objects) LCOM (Lack of Cohesion of Methods) 상속 복잡도 결합도 응집도 관련 연구입니다. 대표적으로 사용되는 메트릭스 중 하나가 CK 메트릭스 입니다. 5개의 Factor를 사용해서 Complexity, Reusability, Encapsulation, Modularity를 측정합니다. 재사용성의 경우 WMC, DIT, NOC의 영향을 받는데, 2017년 DocForge의 말에 따르면 “소프트웨어를 보다 재사용하기 쉽게 하는 특성을 모듈성, 저결합도, 고응집도, 캡슐화 등으로 부른다＂고 했습니다. 즉, Modularity 또한 재사용성을 측정하는데 큰 영향을 주게 됩니다. 이렇게 모든 Factor들을 포함시키고 나면 모든 요소들이 Complexity와 동일한 것을 볼 수 있습니다.

Related Works 대표적인 재사용 메트릭스 Marko Mijac, “Reusability Metrics of Software Components : Survey” [2015] Paper Factors Factor metrics [1] Coupling, Cohesion, Inheritance CK metrics (WMC, DIT, NOC, CBO, LCOM), Regression algorithms [2] Coupling, Volume, Complexity, Regularity, Reuse Frequency McCabe's Cyclomatic Complexity, Halstead Software Science Indicator [3] Complexity, Customizability, Reuse Level CPC - Component Plain Complexity, CSC - Component Static Complexity, CDC - Component Dynamic Complexity, CCC - Component Cyclomatic Complexity, CV - Component Variability for Customizability [4] Complexity, Regularity. Volume, Reuse Frequency, Coupling McCabe's Cyclomatic Complexity, Regularity metric, Halstead Software Science Indicator, Reuse frequency metric, LCOM [5] Reuse Frequency, Understandability, Rate of modification - [6] CK metrics (WMC, DIT, NOC, CBO, LCOM), [7] Coupling, Cohesion WTcoh - Weighted Transitive Cohesion measure, WTcoup - Weighted Transitive Couping measure [8] Cohesion SBFC - Similarity-Based Functional Cohesion [9] Coupling CC - Coupling between Classes, CPC - Coupling of Component, CBC - Coupling between Components …… 2015년 Marko의 Survey 논문에 따르면 재사용 메트릭스에 대한 다양한 논문들이 있는데, 사용되는 메트릭스에는 앞에서 말씀드렸던 CK 메트릭스나 McCabe의 Cyclomatic Complexity등이 있고, 사용된 Factor들을 차트화하면

Related Works Coupling Cohesion Complexity 대표적인 재사용 메트릭스 Marko Mijac, “Reusability Metrics of Software Components : Survey” [2015] Paper Factors Factor metrics Understandability, Adaptability, Portability Existence of Meta Information (EMI), Rate of Component Customizability (RCC), Self-Completeness of Component's Return Value (SCCr) Coupling Cohesion Complexity 다음과 같습니다. Coupling, Cohesion, Complexity 가 가장 많이 사용된 Factor로, 이 논문에서도 이 세가지 요소들에 초점을 둡니다.

1 Related Works Only One 기존 재사용 메트릭스의 문제 동적 메트릭스 미비 : 정적인 관점에 편향되어 있음 Paper Factors Factor metrics [1] Coupling, Cohesion, Inheritance CK metrics (WMC, DIT, NOC, CBO, LCOM), Regression algorithms [2] Coupling, Volume, Complexity, Regularity, Reuse Frequency McCabe's Cyclomatic Complexity, Halstead Software Science Indicator [3] Complexity, Customizability, Reuse Level CPC - Component Plain Complexity, CSC - Component Static Complexity, CDC - Component Dynamic Complexity, CCC - Component Cyclomatic Complexity, CV - Component Variability for Customizability [4] Complexity, Regularity. Volume, Reuse Frequency, Coupling McCabe's Cyclomatic Complexity, Regularity metric, Halstead Software Science Indicator, Reuse frequency metric, LCOM [5] Reuse Frequency, Understandability, Rate of modification - [6] CK metrics (WMC, DIT, NOC, CBO, LCOM), [7] Coupling, Cohesion WTcoh - Weighted Transitive Cohesion measure, WTcoup - Weighted Transitive Couping measure [8] Cohesion SBFC - Similarity-Based Functional Cohesion [9] Coupling CC - Coupling between Classes, CPC - Coupling of Component, CBC - Coupling between Components …… Only One 1 기존 재사용 메트릭스에는 다음에서 설명드릴 4가지의 문제가 있습니다. 첫번째는 정적 메트릭스에 편향되어 있고 동적 메트릭스는 거의 존재하지 않습니다. Survey 논문에서도 동적인 지표는 단 한 가지 뿐이었습니다.

Related Works V(G) = 9-8+2 = 3 Cyclomatic 복잡도 메트릭스의 한계 𝑉 𝐺 =𝐸 −𝑁+2 프로그램 소스 코드에서의 독립적인 경로(Independent path)를 측정 Thomas J. McCabe가 1976년에 정의한 metric으로 Node와 Edge로 구성된 Control Flow를 기반으로 함 node 𝑉 𝐺 =𝐸 −𝑁+2 E – Number of edges N – Number of nodes Complexity Number Meaning 1-10 Structured and well written code High Testability Cost and Effort is less 10-20 Complex Code Medium Testability Cost and effort is Medium 20-40 Very complex Code Low Testability Cost and Effort are high >40 Not at all testable Very high Cost and Effort edge 두번째, Cyclomatic Complexity는 객체 지향 프로그램의 복잡도를 측정하기에는 한계가 있습니다. 이 메트릭스는 분기문을 기반으로 프로그램 소스 코드에서 독립적인 경로를 파악하고 복잡도를 측정합니다. V(G) = 9-8+2 = 3

= ≠ Related Works Cyclomatic 복잡도 메트릭스의 한계 [Class]Document - Case #1(Content Coupling) [Class]Document - Case #2(Data Coupling) class Document { private Content content; private Title title; private Heading heading; public void setContent(Content aContent) { setTitle(aContent.title); setHeading(aContent.heading); } public void setTitle(Title aTitle) { title = aTitle; diplayText(title); public void setHeading(Heading aHeading) { heading= aHeading; displayText(heading); public void displayText(Object aObject) { … class Document { private Content content; private Title title; private Heading heading; public void createContent(String title, String heading) { setTitle(title); setHeading(heading); } public void createTitle(String aTitle) { title = aTitle; diplayText(title); public void createHeading(String aHeading) { heading= aHeading; displayText(heading); public void displayText(String aObject) { … 이 메트릭스의 문제를 확인하기 위해 두 개의 Sample Code를 구현했습니다. 이 두 코드는 동일한 기능을 수행하지만, 다르게 코딩 되어 있습니다. 이 코드들의 구조를 그리면 동일하게 나타납니다. 따라서 Cyclomatic Complexity는 2로 동일한 수치가 나옵니다. 하지만, Case1 코드의 경우 모든 호출이 내용 결합도로 이루어져 있고 Case2 코드는 자료 결합도로 이루어져있어 결합도 수치는 30과 6으로 매우 큰 차이를 나타냅니다. 즉, Cyclomatic Complexity는 코드의 Statement에서의 복잡도를 측정하는데 에서는 적합하지만 메소드 간의 복잡도나, 객체간, 컴포넌트 간의 복잡도를 측정할 때에는 결합도가 더 정확한 수치를 계산할 수 있습니다. = Cyclomatic Complexity : V(G) = 6-6+2 = 2 Cyclomatic Complexity : V(G) = 6-6+2 = 2 ≠ Coupling : CO(G) = 6+6+6+6+6 = 30 Coupling : CO(G) = 2+1+1+1+1 = 6

Related Works 상속성과 재사용성 절차 지향과 가장 큰 차이를 보이는 특성 객체 지향 프로그램에서는 호출관계만으로 재사용성 식별 불가 프로그램을 쉽게 확장 할 수 있도록 해주는 강력한 수단 프로젝트 내부의 재사용성 향상, 중복제거, 유지보수 효율성, 프로 그램 확장 용이 하지만, 레거시 시스템의 코드를 재사용하기 위해서는 클래스들간 객체지향 관계 고려 A class inheritance Reuse B C Composition D E F Association G References H 세번째는 상속성과 재사용성입니다. 객체 지향의 가장 대표적인 특성이 상속성으로 인해, 절차 지향 프로그램과는 다르게 호출관계만으로 재사용성 식별이 불가능 합니다. 상속성은 프로젝트 내부에서는 재사용성을 향상시키고, 여러 장점을 가지고 있지만, 레거시 시스템의 코드를 재사용하는 과정에서는 이 관계 또한 고려해야 하는 문제입니다. 만약 ,왼쪽 구조에서 해당 클래스를 재사용하고자 한다면, 이 클래스가 다른 클래스와 어떤 관계를 갖는지를 고려해야 합니다. Aggregation I J

Related Works 다형성과 재사용성 상속을 통해 기능을 확장/변경하는 것을 가능하게 해줌 Overriding : 슈퍼클래스를 상속받은 서브클래스에서 슈퍼 클래스의 메소드를 같은 이름, 같은 리턴타입, 같은 인자로 메소드 내 로직을 새롭게 정의 Overloading : 하나의 클래스에서 같은 이름의 메소드들을 여러 개 선언 Overloading은 대상이 되는 함수를 컴파일 시점에 지정하고, Overriding은 런타임 시점에 정의 따라서, Overriding의 동적 바인딩은 프로그램의 런타임 시, 동적 분석을 통 해서 이루어짐 객체지향 프로그램에서 동적 분석의 필요성 A void Func (int x) class inheritance B C D void Func (int x) void Func (int x) void Func (int x) 네번째로 다형성에는 대표적으로 Overriding과 Overloading이 있습니다. 그 중에서 Overriding은 대상이 되는 함수를 런타임 시점에 정합니다. 따라서, 오버라이딩에서의 동적 바인딩은 프로그램 런타임 시, 동적 분석으로만 식별이 가능합니다. 다음의 클래스의 Function 함수를 호출할떄, 해당 클래스 내부의 함수를 호출하는 것인지, 상속받은 슈퍼클래스의 함수를 호출하는 것인지는 동적 분석을 통해서만 식별이 가능합니다.

DROOM(Dynamic Reusability Object-Oriented Metrics) Metrics Level Level Method Level Class Level Class-Object Level Object Level Component Level component A Object method Class Level class References class call inheritance inheritance inheritance Composition Composition Association Structure Composition call Association 다음은 Dynamic Reusability Object-Oriented Metrics입니다. 메트릭스의 레벨은 총 5가지로 구분됩니다 이 논문에서는 메소드, 클래스, 오브젝트 레벨만을 다루고 있고, 다른 레벨의 매트릭스는 현재 연구 진행 중입니다. Association References call component B Object Aggregation References Object Level Aggregation

DROOM(Dynamic Reusability Object-Oriented Metrics) 정의한 메트릭스는 다음과 같습니다. 위쪽에 정적 메트릭과 아래쪽에 동적 메트릭으로 구성이 되고 왼쪽에 메소드 레벨과 중간에서 위쪽엔 클래스, 아래쪽은 오브젝트를 의미합니다. 노란색으로 마크된 부분은 CK매트릭스를 확장한 지표들이고, 파란색은 기존 매트릭스를 개선하여 새롭게 정의한 지표입니다.

DROOM(Dynamic Reusability Object-Oriented Metrics) CK Metrics DROOM Class Level Static Metrics 복잡도 WMC CCE 상속 DIT x NOC 결합도 CBO CCO 응집도 LCOM Dynamic Metrics DOCE DCBO DOCO Method Level CBM MCO LCOS MCE Dynamic Metrics DCBM DMCO Improved Extended 다양한 매트릭스들이 있지만, CK메트릭스와 제안한 메트릭스를 비교해본 결과는 다음과 같습니다. CK 매트릭스는 객체 지향 프로그램의 설계에 초점을 두었기 때문에 정적인 클래스 레벨에서의 매트릭스로 구성 되고, 동적 지표는 고려하지 않았습니다. 이 논문에서 설명하는 메트릭스는 CK매트릭스를 기반으로 확장되었거나 개선된 지표들로 구성되었습니다. 동적 매트릭스의 경우, 정적 매트릭스를 동적인 환경에서 측정한 것으로, 매트릭스의 개념은 동일합니다. 따라서, 동적 지표는 제외하고, CK매트릭스의 WMC, CBO, LCOM과 비교하여 개선된 매트릭스들을 설명하겠습니다. http://staff.unak.is/andy/staticanalysis0809/metrics/wmc.html

DROOM(Dynamic Reusability Object-Oriented Metrics) Class Level Static Metrics CK Metrics Extensive/Improved Metrics Weighted Methods per Class : WMC It is an indicator of how much effort is required to develop and maintain a particular class. It focus on the complexity of a method. Class Cohesion : CCE It is an indicator of how much effort is required to develop and maintain a particular class. It focus on the complexity of a class. New C1 C1 m1 m2 m3 m4 m5 m1 m4 m2 m5 m3 Complexity CC (Cyclomatic Complexity) + + + + = WMC CC CC CC CC CO (Coupling) + + + + = CCE CO CO CO CO 먼저 WMC는 클래스 내부의 모든 메소드들의 Cyclomatic Complexity를 측정하고, 이들을 합산한 것을 의미합니다. 이 지표는 특정 클래스를 개발 또는 유지보수 시에 필요한 노력을 판단합니다. 하지만, 실제 CC는 메소드 레벨에 초점을 두고 있다는 모순을 갖게 됩니다. 반대로, Class Cohesion은 클래스 내부의 메소드들이 얼마나 결합되어 있는지를 측정함으로써, 복잡도를 판단하고자 합니다. 이 지표는 WMC와는 다르게 클래스 레벨에 초점을 두고 있습니다. http://staff.unak.is/andy/staticanalysis0809/metrics/wmc.html

DROOM(Dynamic Reusability Object-Oriented Metrics) Class Level Static Metrics CK Metrics Extensive/Improved Metrics Lack Cohesion Of Methods : LCOM It is an indicator of whether a class represents a single abstraction or multiple abstractions. It is difficult to establish a clear mechanism for measuring it. So, it represents a ‘better’ situation. Class Cohesion : CCE It is an indicator of how much strong the coupling of methods in a particular class. New C1 C1 a1 a2 a3 a4 a5 m1 m4 m2 m5 m3 m1 m2 m3 m4 m5 Cohesion CO (Coupling) + + + + = CCE CO CO CO CO #1 #2 #3 CCE는 Ck 매트릭스의 LCOM을 대신해 응집도를 측정하는 지표로 사용 될 수 있습니다. LCOM는 클래스 내부의 메소드들이 전역 변수에 접근하는 구조를 통해서 측정하게 됩니다. 연결되지 않은 노드들을 그룹화하여 그 개수로 응집도를 판단합니다. 이 지표를 통해서 해당 클래스가 추상화가 적절하게 되었는지를 측정하게 되는데, 응집도라는 지표는 clear하게 정의하기 매우 어렵다고 언급하고 있고, 이 결과를 통해서 정확한 결과 보다는 조금 더 낫다는 것을 판단할 수 있는 기준이라고만 언급을 합니다. 이 논문에서는 이 응집도의 개념을 내부 메소드들의 결합도로 전환 시켰습니다. 따라서, 특정 클래스 내부 메소드들의 결합도를 합산하여 클래스의 내부 메소드들이 얼마나 응집되어 있는가를 판단했습니다. http://eclipse-metrics.sourceforge.net/descriptions/pages/cohesion/LackOfCohesionInMethods.html

DROOM(Dynamic Reusability Object-Oriented Metrics) Class Level Static Metrics CK Metrics Extensive/Improved Metrics Coupling Between Object Classes : CBO It is an indicator of independence in the class. It is a count of the number of other classes to which it is coupled. Class Coupling : CCO It is an indicator of independence in the class. It can classify the types of a coupling. New #1 C1 C2 C1 #Data C2 m4 m4 m5 m3 m5 m3 m1 m1 C3 #Content C3 m2 m2 Coupling m5 m5 #External 결합도를 측정하기 위해서 CK매트릭스에서는 CBO를 사용합니다. 이 지표는 특정 클래스와 결합도 클래스의 개수를 측정하여 결합도를 판단합니다. 이 경우는 클래스 간의 호출 횟수를 고려하지 않습니다. 클래스 C1이 2개의 클래스와 결합되어 있지만, C2와는 3번, C3와는 1번 호출되므로 결합도의 세기는 다르다는 것을 알 수 있지만, 이 지표에서는 이를 고려하지 않고, 전달되는 파라미터를 통해서 여러 종류로 나누어지는 결합도의 세기도 고려하지 않는 오류를 갖게 됩니다. 이 문제를 해결하기 위해서, Class Coupling 에서는 호출 횟수와, 결합도 타입을 구분하여 조금 더 정확한 결합도를 측정하고자 합니다. #2 http://staff.unak.is/andy/staticanalysis0809/metrics/wmc.html

Visualization Tool APACHE Tool-Chain 구조 Step1 (Input/Running) Static Analysis DROOM(Dynamic Reusability Object-Oriented Metrics xCodeParser Generate DB From ASTM Source Code (*.java) Step1 (Input/Running) ASTM File (*.astm) Static Analysis Result 대상이 되는 프로그램을 입력/실행한다. MySQL Step2 (Analyzing) JPS Generate DB From JMap JVM (Java Virtual machine) ExJmap 도구를 사용하여 정적/동적 분석을 수행한다. Step3 (Store) JMap Command Prompt Output Real-Time Dynamic Analysis Result 분석 결과에 재사용 메트릭을 적용하고 그 결과를 데이터베이스에 저장한다. Hprof Generate DB From Hprof Step4 (Reconstructing) GenerateVIS (GoJS) 데이터베이스에 저장된 데이터를 GoJS 문법에 맞게 재구성한다. Dynamic Analysis Text File (*.txt) Dynamic Analysis Result Visualization 다음은 정의한 매트릭스를 자동으로 측정하고 가시화하는 Visualization Tool입니다. 5개의 단계로 구성되어있고 그 구조는 오른쪽 그림과 같습니다. 각각에 대해 설명 드리겠습니다. Step5 (Visualization) Visualization Apache 웹서버를 통해 가시화한다. APACHE

Visualization Tool APACHE 구조 ① Static Analysis ② Tool-Chain 구조 Static Analysis Static Analysis 실제 실행 없이 소스 코드 분석 ① DROOM(Dynamic Reusability Object-Oriented Metrics xCodeParser Generate DB From ASTM Source Code (*.java) Step1 (Input/Running) ASTM File (*.astm) Static Analysis Result 대상이 되는 프로그램을 입력/실행한다. MySQL Step2 (Analyzing) ② Real-Time Dynamic Analysis 실행 중인 프로그램 분석(실시간 결과 출력) JPS Generate DB From JMap JVM (Java Virtual machine) ExJmap 도구를 사용하여 정적/동적 분석을 수행한다. Step3 (Store) JMap Command Prompt Output Real-Time Dynamic Analysis Result 분석 결과에 재사용 메트릭을 적용하고 그 결과를 데이터베이스에 저장한다. ③ Dynamic Analysis 실행 중인 프로그램 분석(실행 종료 후 결과 출력) Hprof Generate DB From Hprof Step4 (Reconstructing) GenerateVIS (GoJS) 데이터베이스에 저장된 데이터를 GoJS 문법에 맞게 재구성한다. Dynamic Analysis Text File (*.txt) Dynamic Analysis Result Visualization 먼저 첫번째 Input/Running에서는 대상이 되는 프로그램을 입력/실행합니다. 실제 실행 없이 소스 코드를 분석하는 Static Analysis, 실행 중인 프로그램을 분석하고 실시간으로 결과를 출력하는 Real-Time Dynamic Analysis, 실행 중인 프로그램을 분석하고 실행 종료 후 결과를 출력하는 Dynamic Analysis를 수행합니다. Step5 (Visualization) Visualization Apache 웹서버를 통해 가시화한다. APACHE

Visualization Tool APACHE Tool-Chain 구조 Step1 (Input/Running) Static Analysis DROOM(Dynamic Reusability Object-Oriented Metrics xCodeParser Generate DB From ASTM Source Code (*.java) Step1 (Input/Running) ASTM File (*.astm) Static Analysis Result 대상이 되는 프로그램을 입력/실행한다. MySQL Step2 (Analyzing) JPS Generate DB From JMap JVM (Java Virtual machine) ExJmap 도구를 사용하여 정적/동적 분석을 수행한다. Step3 (Store) JMap Command Prompt Output Real-Time Dynamic Analysis Result 분석 결과에 재사용 메트릭을 적용하고 그 결과를 데이터베이스에 저장한다. Hprof Generate DB From Hprof Step4 (Reconstructing) GenerateVIS (GoJS) 데이터베이스에 저장된 데이터를 GoJS 문법에 맞게 재구성한다. Dynamic Analysis Text File (*.txt) Dynamic Analysis Result Visualization 두번 째 Analyzing은 도구를 사용하여 정적/동적 분석을 수행합니다. 앞에서 말씀 드렸던 Static, Real-Time Dynamic, Dynamic에서 사용되는 도구들에 대해 설명 드리겠습니다. Step5 (Visualization) Visualization Apache 웹서버를 통해 가시화한다. APACHE

Visualization Tool xCodeParser [기존 Parser] [xCodeParser] Static Analysis 실제 실행 없이 소스 코드 분석 input Source Code (*.java) output ASTM File (*.astm) 연구실에서 자체 개발한 Parser AST(Abstract Syntax Tree)의 통합모델인 ASTM(Abstract Syntax Meta Model) 생성 이종 코드로 변환 가능 [기존 Parser] [xCodeParser] Complecate Simple java Java Parser Java AST java 먼저 Static Analysis를 수행하는 xCodeParser입니다. 이 도구는 소스 코드를 입력받아 정적 분석을 수행하고, 그 결과로 ASTM파일들을 출력하게 됩니다. xCodeParsers는 저희 연구실에서 자체 개발한 파서로, 여러 언어들의 AST(Abstract Syntax Tree)의 통합모델인 ASTM(Abstract Syntax Tree Meta Model)을 생성합니다. 아래 그림에서 기존의 파서들로는 이종 언어 간의 코드 변환이 매우 복잡하여 어려움이 있었지만, xCodeParser의 경우는 통합 모델 ASTM을 사용하므로 이종 코드 간의 변환을 심플하게 합니다. C/C++ C/C++ Parser C/C++ AST C/C++ xCodeParser ASTM others Parser others others AST others

Output (Dynamic Object) Visualization Tool JPS : JVM에서 실행 중인 프로세스 ID 데이터 수집 JMap : 해당 ID에서 사용하고 있는 JVM Heap 데이터 수집 ExJmap Source Code (*.java) ③ JPS는 JVM에서 실행 중인 프로세스의 모든 ID 데이터 수집 Running Process ID Real-Time Tool JPS Run input ② ExJmap 실행 후, JPS 실행 Target Process ID ExJmap JVM (Java Virtual machine) Real-Time Dynamic Analysis 실제 중인 프로그램 분석(실시간 결과 출력) ⑥ Jmap 실행 결과 입력 ① JVM은 소스 코드를 전달받아 프로그램 실행 input Run JMap Command Prompt Output 다음은 Real-Time Dynamic Analysis를 수행하는 ExJmap입니다. 실시간으로 결과를 출력하는 만큼 그 과정이 복잡한데, ExJmap이 제가 구현한 Real-Time Tool입니다. 먼저, JVM은 소스 코드를 입력 받아서 프로그램을 실행시킵니다. 그 후에, ExJmap을 실행하고, JPS를 순서대로 실행합니다. JPS는 JVM에서 실행 중인 프로세스의 모든 ID 데이터를 수집합니다. ExJamp은 그 중에서도 타겟 프로그램의 프로세스 ID를 획득 한 후에, 해당 ID를 타겟으로 Jmap을 실행합니다. Jmap에서는 해당 ID에서 사용하고 있는 JVM heap 데이터를 수집한 후에 그 결과를 커맨드 창에 출력하게 되고, 그 결과를 다시 ExJamp이 입력으로 사용합니다. JVM heap Output (Dynamic Object) ④ JPS로 부터 타겟 프로그램의 프로세스 ID 획득 후, 해당 ID를 타겟으로 Jmap 실행 ⑤ Jmap은 해당 ID에서 사용하고 있는 JVM heap의 데이터 수집 후, 그 결과를 Command Prompt에 출력

(Java Virtual machine) Visualization Tool Hprof Source Code (*.java) input Hprof JVM (Java Virtual machine) output Text File (*.txt) IBM에서 제공하는 프로파일러로 Thread, Heap, CPU 프로파일링 정보 제공 command 창에서 java 명령어를 통해 간단하게 실행 어플리케이션의 종료 시점에 분석 결과 파일 생성 생성된 데이터는 텍스트 또는 바이너리 형식 Dynamic Analysis는 Hprof를 사용하여 수행합니다. 이 도구는 소스코드를 JVM에 올려서 실행할 때, hprof를 백그라운드 프로그램으로 같이 실행하게 되고, 그 결과로 텍스트 파일을 출력합니다. 이 도구는 IBM에서 제공하는 프로파일러로 Thread, Heap, CPU 프로파일링 정보를 제공합니다. 하지만, 어플리케이션의 종료 시점에 분석 결과 파일을 텍스트 또는 바이너리 형식으로 출력하게 됩니다. Hprof 실행 분석 결과 파일

Visualization Tool APACHE Tool-Chain 구조 Step1 (Input/Running) Static Analysis DROOM(Dynamic Reusability Object-Oriented Metrics xCodeParser Generate DB From ASTM Source Code (*.java) Step1 (Input/Running) ASTM File (*.astm) Static Analysis Result 대상이 되는 프로그램을 입력/실행한다. MySQL Step2 (Analyzing) JPS Generate DB From JMap JVM (Java Virtual machine) ExJmap 도구를 사용하여 정적/동적 분석을 수행한다. Step3 (Store) JMap Command Prompt Output Real-Time Dynamic Analysis Result 분석 결과에 재사용 메트릭을 적용하고 그 결과를 데이터베이스에 저장한다. Hprof Generate DB From Hprof Step4 (Reconstructing) GenerateVIS (GoJS) 데이터베이스에 저장된 데이터를 GoJS 문법에 맞게 재구성한다. Dynamic Analysis Text File (*.txt) Dynamic Analysis Result Visualization 세번쨰 Store는 분석 결과에 재사용 메트릭을 적용하고 그 결과를 데이터베이스에 저장합니다. Step5 (Visualization) Visualization Apache 웹서버를 통해 가시화한다. APACHE

Result of Static Analysis Visualization Tool Store the Result of Static Analysis MySQL Generate DB From ASTM ASTM File (*.astm) input input Result of Static Analysis 먼저 정적 분석 결과를 저장하는 Generate DB From ASTM이라는 프로그램을 구현 했습니다. 실제 ASTM의 구조는 아래와 같이 복잡한 트리로 생성이 됩니다. 이 데이터를 기존에 정의했던 데이터베이스의 구조대로 파싱을 해서 데이터를 구성하고 저장합니다. Parsing ASTM DB 구조

Result of Real-Time Dynamic Analysis Visualization Tool Store the Result of Real-Time Dynamic Analysis MySQL Generate DB From JMap ExJmap input input input Result of Real-Time Dynamic Analysis Command Prompt Output jmap -histo 8180 num #instances #bytes class name (module) ------------------------------------------------------- 1: 1011 785680 [I (java.base@9.0.1) 2: 8337 558680 [B (java.base@9.0.1) 3: 374 240392 [C (java.base@9.0.1) 4: 6846 164304 java.lang.String (java.base@9.0.1) 5: 4598 147136 java.util.HashMap$Node (java.base@9.0.1) 6: 1856 126992 [Ljava.lang.Object; (java.base@9.0.1) 7: 913 111512 java.lang.Class (java.base@9.0.1) … 311: 2 48 A 428: 1 16 B 429: 1 16 C Total 43706 2980800 DynamicObj object varchar(30) num integer Real-Time 동적 분석에서도 ExJmap은 JVM Heap 데이터를 텍스트 형식으로 입력을 받고 데이터베이스 테이블대로 데이터를 구조화해서 저장합니다. 이 과정은 실시간이기 때문에 1초 간격으로 데이터를 업데이트를 하고 있습니다. Parsing Jmap Command Prompt Output DB 구조

Result of Dynamic Analysis Visualization Tool Store the Result of Dynamic Analysis MySQL Generate DB From HProf Text File (*.txt) input input Result of Dynamic Analysis 동적 분석 결과 또한 텍스트 형식으로 출력되기 떄문에 데이터 베이스 테이블대로 구조화해서 데이터를 파싱하고 저장합니다. Parsing Hprof output DB 구조

Visualization Tool APACHE HTML JavaScript HTML Tool-Chain 구조 Static Analysis DROOM(Dynamic Reusability Object-Oriented Metrics xCodeParser Generate DB From ASTM <Method> Static <Method> Dynamic Source Code (*.java) <Class> Static <Class> Dynamic Step1 (Input/Running) ASTM File (*.astm) Static Analysis Result HTML 대상이 되는 프로그램을 입력/실행한다. MySQL Step2 (Analyzing) JavaScript JPS Generate DB From JMap Data Selection JVM (Java Virtual machine) ExJmap 도구를 사용하여 정적/동적 분석을 수행한다. Style Template Step3 (Store) <Project> Static < Project > Class-Object < Project > Dynamic JMap Command Prompt Output Real-Time Dynamic Analysis Result 분석 결과에 재사용 메트릭을 적용하고 그 결과를 데이터베이스에 저장한다. Hprof HTML Generate DB From Hprof Step4 (Reconstructing) GenerateVIS (GoJS) 데이터베이스에 저장된 데이터를 GoJS 문법에 맞게 재구성한다. Dynamic Analysis Text File (*.txt) Dynamic Analysis Result Visualization 마지막으로 Visualization에서는 아파치를 기반으로 웹서버를 통해서 가시화를 합니다. 앞에서 정의했던 메트릭스 대로 메소드의 정적/동적, 클래스의 정적/동적/ 컴포넌트의 정적/클래스와 오브젝트/동적 각각에 대한 템플릿을 미리 정의해둡니다. 위 아래의 HTML은 스타일 템플릿을 의미하고 중간에 위치한 자바 스크립트는 데이터베이스에 접근해서 실제 출력할 데이터를 select 해 옵니다. Step5 (Visualization) Visualization Apache 웹서버를 통해 가시화한다. APACHE

Case Study – JUnit Junit 3.4 vs 4.0 JUnit3.4 JUnit4.0

Case Study – JUnit Junit 3.4 vs 4.0 JUnit3.4 JUnit4.0

Case Study – JUnit Junit 3.4 vs 4.0 Reusability = 20/28 = 71% class ActiveTestTest V 3.4 x AllTests V 4.0 AsserTest ClassLoaderTest ComparisonCompactorTest ComparisonFailureTest DoublePrecisionAssertTest ExceptionTestCaseTest ExtensionTest Failure FloatAssertTest InheritedTestCase LoadedFromJar NoArgTestCaseTest NoTestCaseClass NoTestCases NotPublicTestCase NotVoidTestCase OneTestCase OverrideTestCase Success SuiteTest TestCaseTest TestImplementorTest TestListenerTest TestTestCaseClassLoader TextRunnerTest WasRun Reusability = 20/28 = 71%

Case Study – JUnit

Conclusion & Future works 결론 객체지향 메커니즘 기반의 정적/동적 재사용 매트릭 정의 재사용 모듈 자동식별하기 위한 Tool-Chain 구축 정적/동적 분석 결과를 Apache를 기반으로 웹 환경에서 가시화 재사용에 적합한 모듈/클러스터의 자동 식별을 통해 재사용성 향상 및 가이드라인 제공 재사용을 통해 신뢰성, 생산성, 품질 개선 향후 연구 재사용 매트릭스의 기준 설정을 위한 분석 테스트 케이스에 따라 다른 결과를 보이는 동적 재사용 매트릭의 개선 방법 연구 요구사항 추적성 연구를 기반으로 재사용 메커니즘을 요구사항 재사용으로 확장 마지막으로 결론 및 향후연구 입니다. 객체지향 메커니즘 기반의 정적/동적 재사용 메트릭을 정의했습니다. 특히, 클래스와 오브젝트 레벨에서의 재사용성을 측정했습니다. 재사용 모듈/클러스터를 자동으로 측정하고 식별하기 위한 툴체인을 구축했습니다. 따라서 재사용성을 향상 시키고 사용자에게 재사용 가이드라인을 제공하고자 합니다. 실제 재사용을 통해 신뢰성, 생산성, 품질을 개선할 수 있을것이라고 기대합니다. 향후에는 테스트 케이스에 따라 다른 결과를 보이는 동적 재사용 메트릭스를 어떻게 개선할지에 대해 연구하고, 요구사항 추적성 연구를 기반으로 재사용 메커니즘을 요구사항 재사용으로 확장할 예정입니다.

DROOM(Dynamic Reusability Object-Oriented Metrics) Method Level Static Metrics Factor Criteria Metrics Structure Coupling CBM(Coupling Between Method) #Number of call other method MCO(Method Coupling) 1 𝑛 𝑖=0 𝑛 𝑐𝑜 𝑖 = 𝑐𝑜 𝑑 + 𝑐𝑜 𝑠 + 𝑐𝑜 𝑐 + 𝑐𝑜 𝑒 + 𝑐𝑜 𝑚 + 𝑐𝑜 𝑛 𝑛 CBM : CK 매트릭스 CBO(Coupling Between Object Classes)를 메소드 레벨로 확장 MCO : 개선한 매트릭스 CCO(Class Coupling)를 메소드 레벨로 확장 [예시 코드] [구조] public static void createDoc(Document aDocument) { aDocument.buildDisplay(); aDocument.display(); } ① ② CBM = 2 메소드 레벨에서의 Coupling에는 CK 매트릭스의 CBO를 메소드 레벨로 확장한 CBM과 앞에서 정의한 CCO를 메소드 레벨로 확장한 MCO를 정의합니다. CBM은 단순히, 해당 메소드가 몇 개의 메소드를 호출했는지를 count 합니다. 아래 예시에서는 createDoc함수에서 builDisplay와 displa함수를 호출하므로, CBM 은 2입니다.

DROOM(Dynamic Reusability Object-Oriented Metrics) Method Level Static Metrics Factor Criteria Metrics Structure Coupling CBM(Coupling Between Method) #Number of call other method MCO(Method Coupling) 1 𝑛 𝑖=0 𝑛 𝑐𝑜 𝑖 = 𝑐𝑜 𝑑 + 𝑐𝑜 𝑠 + 𝑐𝑜 𝑐 + 𝑐𝑜 𝑒 + 𝑐𝑜 𝑚 + 𝑐𝑜 𝑛 𝑛 CBM : CK 매트릭스 CBO(Coupling Between Object Classes)를 메소드 레벨로 확장 MCO : 개선한 매트릭스 CCO(Class Coupling)를 메소드 레벨로 확장 절차지향 결합도 객체지향 결합도 점수 Data Coupling 모듈 간 파라미터로 기본 자료형 전달 메소드 간 호출 파라미터로 기본 자료형 전달 1 Stamp Coupling 모듈 간 파라미터로 기본 자료형이 아닌 복잡한 자료 구조 전달 메소드 간 호출 파라미터로 배열, 오브젝트 등 전달 2 Control Coupling 호출 시에 전달되는 파라미터가 모듈의 제어를 지시하는 데이터로 사용 호출 시에 전달되는 파라미터가 if/switch문과 같은 분기 조건으로 사용 3 External Coupling 외부 자료 공유 호출 파라미터에 File, Font, HTTP와 같은 외부 데이터를 전달 4 Common Coupling 공유되는 공통 데이터 영역을 여러 모듈이 사용 호출 시 static으로 선언된 메소드 호출 5 Content Coupling 특정 모듈이 다른 모듈의 내부 기능이나 내부 자료 참조 호출 시 get/set 메소드를 호출하고 해당 메소드가 있는 클래스에 private 형 변수 6 CBM은 같은 메소드 일지라도 몇번을 호출했는지는 고려하지 않고, 실제로는 자료, 스탬프, 제어, 외부, 공유, 내용 결합도의 각 종류를 고려하지 않습니다. MCO는 기존에 제가 진행했던 논문에서 절차지향 관점의 결합도를 객체지향으로 개선한 메트릭 입니다. Data Coupling이 제일 약하고, Content Coupling이 제일 강하기 때문에서 1에서 6으로 점수를 정의했습니다.

DROOM(Dynamic Reusability Object-Oriented Metrics) Method Level Static Metrics Factor Criteria Metrics Structure Coupling CBM(Coupling Between Method) #Number of call other method MCO(Method Coupling) 1 𝑛 𝑖=0 𝑛 𝑐𝑜 𝑖 = 𝑐𝑜 𝑑 + 𝑐𝑜 𝑠 + 𝑐𝑜 𝑐 + 𝑐𝑜 𝑒 + 𝑐𝑜 𝑚 + 𝑐𝑜 𝑛 𝑛 CBM : CK 매트릭스 CBO(Coupling Between Object Classes)를 메소드 레벨로 확장 MCO : 개선한 매트릭스 CCO(Class Coupling)를 메소드 레벨로 확장 [예시 코드] [구조] void Control_Caller() { con.Control_Callee(s,s2); } void Control_Callee(String s, String s2) { if(s.equals("TRUE")){ ... if(s2.equals("TRUE")){ 수정 Stamp Coupling *2 예시 코드에서는 스탬프 결합도가 2개, 제어 결합도가 2개 이므로, Control Caller와 Controler_callee간의 호출에서는 2.82라는 결합도가 측정됩니다. Control Coupling *2

DROOM(Dynamic Reusability Object-Oriented Metrics) Method Level Static Metrics Factor Criteria Metrics Structure Cohesion LCOS(Lack of Cohesion of Statements) 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑎𝑐𝑐𝑒𝑠𝑠 𝑡𝑜 𝑒𝑥𝑡𝑒𝑟𝑛𝑎𝑙 𝑎𝑡𝑡𝑟𝑖𝑏𝑢𝑡𝑒 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑎𝑐𝑐𝑒𝑠𝑠 𝑡𝑜 𝑎𝑡𝑡𝑟𝑖𝑏𝑢𝑡𝑒 MCE(Method Cohesion) 1 𝑛 𝑖=0 𝑛 𝑐𝑒 𝑖 = 𝑐𝑒 𝑓 + 𝑐𝑒 𝑠 + 𝑐𝑒 𝑚 + 𝑐𝑒 𝑝 + 𝑐𝑒 𝑡 + 𝑐𝑒 𝑙 + 𝑐𝑒 𝑐 𝑛 LCOS : CK 매트릭스 LCOM(Lack of Cohesion of Methods)를 메소드 레벨로 확장 MCE : 개선한 매트릭스 CCE(Class Cohesion)을 메소드 레벨로 확장 [예시 코드] [구조] private String title; private Vector headings = new Vector(); private Vector textSegments = new Vector(); private Vector display = new Vector(); public void buildDisplay() { display.addElement(getATitle(title)); for(int i=0;i<headings.size();++i) { String heading = (String)headings.elementAt(i); display.addElement(getAHeading(heading, i+1)); String text = (String)textSegments.elementAt(i); display.addElement(new Text(text));; } 수정 메소드 레벨에서의 응집도에는 CK 매트릭스의 LCOM을 메소드 레벨로 확장한 LCOS와 앞에서 정의한 CCE를 메소드 레벨로 확장한 MCE를 정의합니다. 기존의 LCOM은 클래스 내부의 메소드들이 전역 변수에 접근하는 데이터를 통해서 응집도를 측정했지만, LCOS에서는 각 Statement들이 입력된 파라미터를 사용하고 있는지를 통해서 응집도를 판단합니다. 전체 파라미터의 개수에서 사용된 파라미터의 수를 빼서 측정을 하게 됩니다. 사용하지 않은 파라미터의 수가 많아질 수록 LCOS의 수치 또한 증가합니다.

DROOM(Dynamic Reusability Object-Oriented Metrics) Method Level Static Metrics Factor Criteria Metrics Structure Cohesion LCOS(Lack of Cohesion of Statements) 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑎𝑐𝑐𝑒𝑠𝑠 𝑡𝑜 𝑒𝑥𝑡𝑒𝑟𝑛𝑎𝑙 𝑎𝑡𝑡𝑟𝑖𝑏𝑢𝑡𝑒 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑎𝑐𝑐𝑒𝑠𝑠 𝑡𝑜 𝑎𝑡𝑡𝑟𝑖𝑏𝑢𝑡𝑒 MCE(Method Cohesion) 1 𝑛 𝑖=0 𝑛 𝑐𝑒 𝑖 = 𝑐𝑒 𝑓 + 𝑐𝑒 𝑠 + 𝑐𝑒 𝑚 + 𝑐𝑒 𝑝 + 𝑐𝑒 𝑡 + 𝑐𝑒 𝑙 + 𝑐𝑒 𝑐 𝑛 LCOS : CK 매트릭스 LCOM(Lack of Cohesion of Methods)를 메소드 레벨로 확장 MCE : 개선한 매트릭스 CCE(Class Cohesion)을 메소드 레벨로 확장 절차지향 응집도 객체지향 응집도 점수 가중치 Functional Cohesion 모듈 내 모든 구성요소들이 한 가지 기능과 연관 메소드 내 동일한 변수가 반복적으로 사용 7 1 Sequential Cohesion 모듈 내 한 구성요소의 출력이 다른 구성요소의 입력 메소드 리턴 값이 다음 메소드의 입력 값으로 사용 6 0.86 Communicational Cohesion 모듈이 여러 가지 기능을 수행하며 모듈 내 구성요소들이 동일한 입력 자료 이용 메소드 호출 입력 값에 공통된 변수 입력 5 0.71 Procedural Cohesion 모듈 내 구성요소들이 연관되어 있고 특정 순서대로 실행 하나의 클래스에 있는 메소드 여러 개 호출 4 0.57 Temporal Cohesion 모듈 내 구성요소들이 서로 다른 기능을 같은 시간에 실행 메소드 호출 없이 변수 초기화만 실행 3 0.43 Logical Cohesion 모듈 내 구성요소들이 논리적으로 연관된/비슷한 기능 수행 switch문이 쓰여 case에 따라 다른 작업 수행 2 0.29 Coincidental Cohesion 모듈 내 구성요소들이 서로 관련 없는 기능 수행 모든 응집도에 포함되지 않음 0.17 MCE는 기존에 제가 진행했던 논문에서 절차지향 관점의 결합도를 객체지향으로 개선한 메트릭 입니다. Functional Cohesion이 제일 강하고, 우연적 응집도가 제일 강하기 때문에서 7에서 1으로 점수를 정의했습니다.

DROOM(Dynamic Reusability Object-Oriented Metrics) Method Level Static Metrics Factor Criteria Metrics Structure Cohesion LCOS(Lack of Cohesion of Statements) 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑎𝑐𝑐𝑒𝑠𝑠 𝑡𝑜 𝑒𝑥𝑡𝑒𝑟𝑛𝑎𝑙 𝑎𝑡𝑡𝑟𝑖𝑏𝑢𝑡𝑒 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑎𝑐𝑐𝑒𝑠𝑠 𝑡𝑜 𝑎𝑡𝑡𝑟𝑖𝑏𝑢𝑡𝑒 MCE(Method Cohesion) 1 𝑛 𝑖=0 𝑛 𝑐𝑒 𝑖 = 𝑐𝑒 𝑓 + 𝑐𝑒 𝑠 + 𝑐𝑒 𝑚 + 𝑐𝑒 𝑝 + 𝑐𝑒 𝑡 + 𝑐𝑒 𝑙 + 𝑐𝑒 𝑐 𝑛 LCOS : CK 매트릭스 LCOM(Lack of Cohesion of Methods)를 메소드 레벨로 확장 MCE : 개선한 매트릭스 CCE(Class Cohesion)을 메소드 레벨로 확장 [예시 코드] [구조] void processGrade() { numberGrade = getGrade(); letterGrade = computeLetter(numberGrade); displayLetter(letterGrade); } 해당 예시는 특정 파라미터의 output이 다음 호출의 입력 값으로 사용되는 절차적 응집도를 갖고 있고, 앞에서 정의한 점수에 따라서 응집도가 계산됩니다.