"Lack of Cohesion in Methods (LCOM)"은 객체 지향 소프트웨어 설계의 품질을 평가하는 메트릭 중 하나로, 클래스 내 메서드들이 얼마나 응집력이 없는지를 측정합니다. 응집도는 클래스의 내부 요소들이 얼마나 밀접하게 관련되어 있는지를 나타내며, LCOM은 그 반대 개념으로서 응집도가 낮을수록 LCOM 값이 높아집니다.
Lack of Cohesion in Methods (LCOM)의 정의
LCOM은 클래스 내의 메서드들이 서로 관련된 필드(속성)를 얼마나 공유하는지를 기반으로 계산됩니다. 클래스의 응집도는 클래스 내의 메서드들이 동일한 필드를 많이 공유할수록 높아지며, 공유하는 필드가 적을수록 낮아지게 됩니다.
LCOM 지표는 클래스 내의 응집도를 수치로 표현하여, 설계의 품질을 정량적으로 평가할 수 있게 해줍니다. 높은 LCOM 값은 클래스가 여러 가지 비관련 기능을 포함하고 있을 가능성을 시사하며, 이는 설계의 단점으로 간주될 수 있습니다.
LCOM 계산 방법
LCOM의 계산에는 다양한 방법이 있으며, 대표적인 방법들로 LCOM1, LCOM2, LCOM3이 있습니다.
LCOM1 : LCOM1은 클래스 내 메서드들이 클래스의 필드를 얼마나 공유하는지를 단순히 계산하는 방식으로, LCOM1이 양수인 경우 응집도가 낮으며, 0 또는 음수인 경우 응집도가 높은 것으로 평가합니다.
- P: 클래스 내에서 서로 다른 필드를 사용하는 메서드 쌍의 수
- Q: 클래스 내에서 동일한 필드를 사용하는 메서드 쌍의 수
LCOM2 : LCOM2는 LCOM1을 개선하여 클래스 내의 모든 메서드 쌍에 대한 필드 공유 여부를 평가하며, LCOM2 값이 1보다 크면 응집도가 낮다고 평가되며, 1 이하이면 높은 응집도를 의미합니다.
- P: 서로 다른 필드를 사용하는 메서드 쌍의 수
- Q: 동일한 필드를 사용하는 메서드 쌍의 수
LCOM3 : LCOM3은 메서드와 필드 간의 관계를 좀 더 정밀하게 분석하여 응집도를 계산합니다. LCOM3이 0에 가까울수록 응집도가 높고, 1에 가까울수록 응집도가 낮습니다.
- m: 클래스 내 메서드의 수
- A: 메서드와 필드 간의 연결 행렬
- μ(A): 행렬 A에서 필드와 연결된 메서드들의 평균 수
LCOM의 의미와 활용
응집도 평가
LCOM은 클래스 내 메서드들이 서로 관련된 필드를 얼마나 공유하는지를 기반으로 하여 응집도를 평가합니다. 높은 LCOM 값은 클래스가 여러 가지 비관련된 기능을 포함하고 있을 가능성을 시사하며, 이는 유지보수성이나 이해 가능성을 저하시킬 수 있습니다.
리팩토링 필요성
LCOM 값이 높다면, 클래스가 너무 많은 책임을 가지고 있거나, 비관련된 기능을 포함하고 있을 가능성이 큽니다. 이 경우 클래스를 리팩토링하여 응집도를 높이고, 각 클래스가 단일 책임 원칙을 따르도록 할 필요가 있습니다.
디자인 품질
LCOM은 객체 지향 설계의 품질을 평가하는 중요한 지표로, 특히 클래스의 역할과 책임이 명확하게 정의되어 있는지, 클래스 내 메서드들이 서로 밀접하게 관련되어 있는지를 평가하는 데 유용합니다.
LCOM의 한계
복잡한 클래스 구조
LCOM은 클래스가 복잡한 구조를 가질 때 정확한 응집도를 평가하는 데 한계가 있을 수 있습니다. 예를 들어, 클래스 내의 메서드들이 서로 다른 필드를 사용하지만 논리적으로는 관련이 있는 경우 LCOM은 이를 잘 반영하지 못할 수 있습니다.
기계적 계산
LCOM은 코드 구조에만 의존하기 때문에 실제로 클래스가 수행하는 논리적 기능이나 개발자의 의도를 완전히 반영하지 못할 수 있습니다. 따라서 LCOM은 다른 설계 지표와 함께 사용되어야 합니다.
참고문헌
- Chidamber, S. R., & Kemerer, C. F. (1994). “A Metrics Suite for Object Oriented Design.” IEEE Transactions on Software Engineering, 20(6), 476-493.
- Martin, R. C. (2003). “Agile Software Development: Principles, Patterns, and Practices.” Prentice Hall.
- Pressman, R. S. (2014). “Software Engineering: A Practitioner’s Approach.” McGraw-Hill.
'Software Engineering' 카테고리의 다른 글
소프트웨어 요구사항을 구성하는 중요 속성 10가지 (5) | 2024.09.03 |
---|---|
SW 아키텍처 모듈화: 아키텍처 결합도 측정 기법 (Coupling Between Objects, CBO) (1) | 2024.09.02 |
SW 아키텍처 모듈화: 어떻게 할 수 있을까? 고려사항은 무엇일까? (0) | 2024.09.01 |
SW 아키텍처 모듈화: 왜 필요하고, 언제 고려해야 할까? (0) | 2024.09.01 |
나쁜 소프트웨어 엔지니어의 특징 (1) | 2024.09.01 |