• Modularity and Coupling and Cohesion
  • 모듈?
  • Why modularize a system? _{왜 시스템을 모듈화하는가?}
  • Information hiding_Parnas
  • What is an Interface?
  • Further Principles
  • Degrees of Cohesion
  • 모듈의 평가 기준
    • Levels of Coupling
      • Content Coupling
      • Common Coupling
      • Control Coupling
      • Stamp Coupling
      • Data Coupling

Modularity and Coupling and Cohesion

구조설계의 결과_Module를 평가하는 기준

• Coupling
• Cohesion

Design Quality(설계 품질)은

• Modularity
• Coupling and Cohesion

로 이루어진다.

분석에서 명세된 내용은 설계에서 올바르게 구현(반영)되어야 한다.

Specification(DFD에서 나온 DD, mini-spec)

functional_기능적 및 non-functional_비기능적 요구사항을 모두 만족하는가?

• 프로젝트 관리를 기초로 한다.

• 산출해 낼 수 있다.

• Be minimal_{최소화 되어야 한다.}

• Be clear and understandable_{명확하고 이해가 쉬워야 한다}

• 유지보수가 쉽고 확장 가능해야 한다.

따라서, 관리를 위해서는 모듈 디자인이 필요하다.

모듈?

• 일반적인 견해

  • 코드 조각
  • 한정적

• 컴파일 가능한 유닛

• Collection of programming units(프로시저, 클래스 등)

  전체 시스템ㅇ에서 목적을 갖고 있는 잘 정의된 인터페이스

  따라서 개발자에게 독립적으로 할당될 수 있다.

Why modularize a system? _{왜 시스템을 모듈화하는가?}

• Management_{쉽게 관리가 가능}: Divide and conquer를 통해 전반적인 노력을 감소

• Evolution_{이미 만들어 놓은 모듈은 서로 영향을 미치지 않고 독립적이다}: 전체 시스템의 일부를 분리(=Divide and conquer)

  각 영역은 독립적이며, A에서 변화가 일어나도 다른 파트 B에는 반영되지 않음

  • 하나(또는 그 이상)의 요구사항에 대해 하나의 모듈을 만들어라

    요구사항엔 기능적, 비기능적 요구사항이 있는데 기능적이 많겠죠. 가장 이상적인 것은 이 각각의 요구사항들에 대해 1대1에 대응하는 모듈을 만들어라. 라는 거죠.

  • 전역 변수 / 지역 변수에 대한 원칙 (Module 1 및 Module 2가 공용 데이터에 접근할 때는 위에서 설명한 “독립적” 이라는 것이 위배가 됩니다. 그러므로 그냥 변수를 Module 1 및 Module 2 각각에 넣어라_localization=> 캡슐화 및 정보은닉)

• UnderStanding_{이해하기 쉬워지는 레후}: 시스템을 이해하기 쉽게 한다농

  as composition of mind-size chunks, e.g., the 7 플마 2_{사람이 복잡함을 느끼지 않는 사이즈가 5~9개}

  얘는 “관점의 분리”이다에요.

그래서, 기준이 뭐냐~?

Information hiding_Parnas

비밀을 숨겨라. 비밀이 뭐냐면

• 데이터
• Property
• Implementation of world models
• Mechanisms that support policies

Try to localize future change

• 세부 사항은 숨기십시오

• 서로 다른 변화율이 있을 것 같으면 분리시켜라

  그니까 변화가 자주 일어날 거 같으면 분리시키라는거임…

• 변화가 있을것같지 않을거같으면 interface로 드러내라~

What is an Interface?

Interface는 일종의 “약속” 이다. 따라야 할 규칙.

• Provided Interface_{제공되는 인터페이스}

  모듈

• Required Interface_{요구되는 인터페이스}

  모듈이 다른 모듈에 종속적일 때

• ex) 모듈A와 모듈B가 있다고 칩시다. 모듈 B에서 모듈 A에서 제공하는 일부 기능을 필요로 한다. 이 때 A는 제공되는 인터페이스, B는 요구되는 인터페이스인 겁니다.

Syntactic Interfaces

• How to call operations
  • List of operation signatures
  • Sometimes also valid orders of calling operations_{기능들의 나열}

Semantic Interface

• 기능이 뭘 하는지

  • Pre-and-post conditions

    ex)

    • precondition: x, y 값을 읽는다
    • postcondition: x~y 합

  • Use cases

  로 표현

• preformance

  어느 정도 속도가 날 수 있는가? (성능이 어느정도인지?)

• reliability

  신뢰성: 뭐 예외처리 같은 거

프로그램으로 표현할 수 있는 건 구문과 의미 뿐.

Further Principles

• Explicit interfaces_{명시적인 인터페이스}

  인터페이스를 명시적으로 표현하라

  모듈 간의 모든 종속성들을 명시해라.

• Low coupling_{커플링은 짝이므로 영향을 미친다. 즉, 가능하면 영향을 미치지 않게 하라} - few interfaces

  즉! 독립적으로 만들어라! coupling = dependency

• 가능하면 하나의 모듈은 하나의 독립된 기능만을 갖고 있어라

다시,

구조설계의 결과_Module를 평가하는 기준

• Coupling: 종속

  모델 간의 결합도. M1과 M2가 얼마나 끈끈하게 결합되어 있는가

• Cohesion: 응집력

  하나의 모듈 내에서, 얼마만큼 그 기능이 단단하게 으으으응집되어 있느냐

Degrees of Cohesion

참고하셈

모듈의 평가 기준

• 모듈의 평가 기준

  • Coupling_결합: 모듈 간에 얼마만큼 종속성이 존재하느냐?

  • Cohesion_응집: 하나의 모듈이 관련된 일을 얼마나 수행하고 있는가?

  • 굳이 하나 더 넣자면 Fan-out_{내가 제어하는 모듈의 개수} / Fan-in_{나를 제어하는 모듈의 개수}

    가능하면 Fan-out이 high하고, Fan-in이 low 한 것이 좋다고 한다.

Levels of Coupling

모델은 Independent한 게 좋은데요.

Content Coupling (High Coupling => Bad)

Common Coupling

Control Coupling

Stamp Coupling

Data Coupling (Low Coupling => Good)

❗ ❗ 순 서 외 우 셈 ❗ ❗

CCCSD

객체지향에서 정보교환

1~5번은 모듈 간의 정보 교환을 어떤 식으로 하는지에 대한 방법들이다.

3, 2, 1번은 정해진 채널(메서드의 시그니처)

매개변수가 뭐냐에 따라서 data니 stamp니 control인지 찾을 수 있다

4, 5번은 공유 내용이라 그런 게 없다

Content Coupling

정보의 교환 방식이 덩어리로 이루어진 레후

하나의 모듈이 다른 모듈의 내용을 직접 참조하는 겁니다.

그렇기에, 모듈 1이 모듈 2의 문장을 직접 변경시킬 수도 있는 겁니다.

정보 은닉이 하나도 이루어지지 않고 있는 겁니다…!

어셈블리에서는 이러한 방법이 가능하지만, 하이레벨 랭귀지에서는 불가능하다(고작 변수 바꾸는 게 고작)

Common Coupling

M1과 M2에 글로벌 변수를 두어서, 각 모듈에서 접근을 할 수 있도록 하는 거를 말합니다.

Common coupling is problematic in several areas of design/maintenance.

(여러가지 문제를 야기시킨다)

따라서, 프로그램이 이해하기 어려워진다(모듈 모든 곳에서 글로벌 변수를 알 필요가 있으니까)

그니까 글로벌 변수를 쓰지 마세요

5번, 4번은 비 공식적인 채널을 통해서 정보교환을 하는거에요.

Control Coupling

여기서부턴, 매개변수를 이용해 정보교환을 합니다.

모듈 A에서 모듈 B로 데이터를 넘겨줄 때,

데이터로 B를 제어할 수 있으면 Control Coupling

필요로 하는 데이터 이상을 넘겨주면_{순수한 데이터가 아닌 데이터 전체를 넘겨주면} Stamp Coupling

순수한 데이터만을 넘겨주면 Data Coupling

white문이나 switch문 같은 경우, 값에 따라 모듈 B가 제어되기 때문에

Control이라고 하는겁니다.

Stamp Coupling

B입장에서 전체정보가 필요한게 아니죠?

ex) 배열을 통째로 넘겨주는 것

entire

Data Coupling

모듈이 필요로하는 단순한 데이터만 넘겨준당

simple

결국에 매개변수가 뭔지에 결정되는 게아니라, 모듈 B에서 무슨일을 하는지에 대해서 Control인지 Stamp인지 Data인지 결정되는거임