프로그래밍 복잡성

프로그래밍 복잡성(또는 소프트웨어 복잡성)은 소프트웨어의 많은 속성을 포함하는 용어로서, 모두 내부 상호작용에 영향을 미친다.몇몇 논평가들에 따르면, 복잡한 용어와 복잡한 용어의 구분이 있다고 한다.복잡하다는 것은 이해하기 어렵지만 시간과 노력으로, 궁극적으로 알 수 있다는 것을 의미한다.반면에 복잡성은 다수의 실체들 사이의 상호작용을 설명한다.기업의 수가 증가함에 따라, 그들 사이의 상호작용의 수는 기하급수적으로 증가할 것이고, 그들 모두를 알고 이해하는 것은 불가능한 지경에 이르게 될 것이다.마찬가지로 소프트웨어의 복잡성 수준이 높을수록 의도하지 않게 상호작용을 방해할 위험이 증가하므로 변경 시 결함을 발생시킬 가능성이 높아진다.더 극단적인 경우, 그것은 소프트웨어 수정을 사실상 불가능하게 만들 수 있다.소프트웨어의 복잡성과 소프트웨어의 유지보수를 연결한다는 생각은 그의 연구를 통해 소프트웨어 진화 법칙을 개발한 매니 리먼 교수에 의해 광범위하게 탐구되어 왔다.그와 그의 공동저자인 레스 벨라디는 소프트웨어의 상태를 측정하는 데 사용될 수 있는 수많은 가능한 소프트웨어 메트릭스를 연구했고,^[1] 결국 유일한 실용적인 해결책은 결정론적 복잡성 모델을 사용하는 것이라는 결론에 도달했다.

방안

소프트웨어 복잡성에 대한 많은 조치가 제안되었다.이들 중 다수는 복잡성을 잘 나타내지만 쉬운 측정에 도움이 되지 않는다.가장 일반적으로 사용되는 측정 지표는 다음과 같다.

• McCabe의 주기적 복잡성 메트릭
• 소프트웨어 과학 메트릭스 하프스테드
• Henry와 Kafura는 1981년에^[2] 팬 인과 팬 아웃의 함수로 복잡성을 측정하는 "정보 흐름에 기초한 소프트웨어 구조 측정 기준"을 도입했다.그들은 절차의 팬인(fan-in)을 절차로 유입되는 로컬 흐름의 수와 해당 절차가 정보를 검색하는 데이터 구조의 수로 정의한다.팬아웃은 해당 절차에서 나오는 로컬 흐름의 수와 절차가 업데이트하는 데이터 구조의 수로 정의된다.로컬 흐름은 해당 절차를 호출하거나 호출하는 절차에서 전달된 데이터와 관련된다.Henry와 Kafura의 복잡성 값은 "절차 길이에 팬 인의 제곱을 곱한 다음 팬 아웃을 곱한 것"(Length ×(팬 인 × 팬 아웃)²)으로 정의된다.
• 개체 지향 설계를 위한^[3] 메트릭스 스위트는 제목에서 알 수 있듯이 개체 지향 코드를 위한 메트릭스에 초점을 맞춘 1994년에 치담버와 케머러에 의해 도입되었다.그들은 6개의 OO 복잡성 측정 지표를 도입한다; 학급당 가중 방법, 객체 클래스 간의 결합, 클래스에 대한 대응, 자녀 수, 상속 나무의 깊이, 방법의 응집력 부족

프로그래밍 복잡성을 측정하는 데 사용할 수 있는 몇 가지 다른 메트릭이 있다.

• 분기 복잡성(소요 메트릭)
• 데이터 액세스 복잡성(카드 메트릭)
• 데이터 복잡성(계량계)
• 데이터 흐름 복잡성(측정지표계)
• 의사결정 복잡성(McCleure 메트릭)
• 경로 복잡성(Bang Metric)

Tesler's Law는 모든 어플리케이션은 제거하거나 숨길 수 없는 본질적인 양의 복잡성을 가지고 있다는 인간-컴퓨터 상호작용의 격언이다.

종류들

기존 프로그램의 복잡성과 관련되고, 이에 따라 프로그램의 변경과 관련된 복잡성이 발생한다.문제의 복잡성은 두 부분으로 나눌 수 있다.^[4]

1. 우발적 복잡성: 선택한 소프트웨어 엔지니어링 도구로 인해 프로그래머가 직면하는 어려움과 관련됨.더 잘 맞는 도구 집합이나 더 높은 수준의 프로그래밍 언어는 그것을 줄일 수 있다.우발적인 복잡성은 또한 해결책의 형태, 즉 코드의 형태를 형성하기 위해 도메인을 사용하지 않은 결과인 경우가 많다.^{[citation needed]}우발적인 복잡성을 방지하는 데 도움이 될 수 있는 한 가지 관행은 도메인 중심의 설계다.
2. 필수 복잡성:해결해야 할 문제의 특성에 의해 발생하며 줄일 수 없다.

치담버와 케머러 메트릭스

이 글은 목록 형식이지만 산문으로 더 잘 읽힐 수 있다. 적절한 경우 이 기사를 변환하여 도움을 줄 수 있다. 편집 도움말 사용 가능.(2017년 8월)

치담버와 케머러는^[3] 많은 측정과 학술 논문에서 널리 사용되는 일련의 프로그램 복잡성 지표를 제안했다.이들은 아래에 설명된 WMC, CBO, RFC, NOC, DIT 및 LCOM이다.

• 클래스당 WMC 가중 방법
  • ${\displaystyle WMC=\sum _{i=1}^{n}c_{i}}}}$
  • n은 클래스의 메서드 수입니다.
  • ${\displaystyle c_{}}$ i ${\$는 방법의 복잡성
• CBO - 객체 클래스 간의 결합
  • 커플링(사용 또는 사용 중)된 기타 클래스 수
• RFC - 클래스에 대한 응답
  • ${\displaystyle R}$ ${\displaystyle F}$ ${\displaystyle C}$= ${\displaystyle R}$ ${\displaystyle S}$ $displaystyle RFC= RS }$ 여기서$$
  • ${\displaystyle RS=\{M\}\cup _{all\ i}\{R_{i}\}}}}$
  • ${\displaystyle R_{}}$ ${\displaystyle i_{}}$ ${\$는 메서드 i에 의해 호출되는 메서드의 집합이다.
  • ${\displaystyle M}$ ${\displaystyle M}$은(는) 클래스의 메서드 집합임
• NOC - 자녀 수
  • 이 클래스 또는 그 하위 클래스를 상속하는 모든 클래스의 합계
• DIT - 상속 트리 깊이
  • 이 클래스에 대한 상속 트리의 최대 깊이
• LCOM- 방법의 응집력 부족
  • 클래스 메서드에 의해 공통으로 사용되는 속성의 교차점 측정
  • ${\displaystyle LCOM={\begin{case}P - Q ,&{\text{if{}}P > Q \0,{\text{otherwise }}}{\text}}}}}$
  • 여기서 $P{\displaystyle }$=${\displaystyle }${ (${\displaystyle I_{}}$ I ${\displaystyle j_{}}$) ${\displaystyle I{}_{}}$ ${\displaystyle {}_{}}$ ${\displaystyle {}_{}}$ ${\displaystyle j_{}}$= ${\displaystyle \mathrm{\varnothing }}$ ∅${\displaystyle }$} ${\displaystyle$ P$=\{(I_{i})$$I_{j} I_{i}\cap I_{j}=\emptyset \}}}}}$
  • 그리고 $Q{\displaystyle }$=${\displaystyle }${ (${\displaystyle I_{}}$ ${\displaystyle {}_{}}$ ${\displaystyle j_{}}$) ${\displaystyle I_{}}$ ${\displaystyle {}_{}}$ ${\displaystyle {}_{}}$ ${\displaystyle j_{}}$ ${\displaystyle {}_{}}$ ∅ ${\displaystyle \mathrm{\varnothing }}$ }${\displaystyle }$} ${\displaystyle$ Q$=\{(I_{i},$$I_{j} I_{i}\cap I_{j}\neq \emptyset \}}}}}$
  • ${\displaystyle I_{}}$ ${\$를 사용하는$$ 경우 $클래스$의$$i {\$displaystyle$i} -th$$ 메서드에 의해 액세스(읽기 또는 쓰기)되는 속성 집합(인스턴스 변수)

참고 항목

• 소프트웨어 위기(및 후속 프로그래밍 패러다임 솔루션)
• 소프트웨어 메트릭 - 프로그램의 일부 속성에 대한 정량적 측정.

참조