[Chap 7] Design

매우 간단하게 요약해보자

7.1 Software Design(소프트웨어 설계)

- Software design(소프트웨어 설계)란, 문제의 요구사항들을 소프트웨어 구조들로 변환하는 과정이라고 본다.

- 또는, 목표 소프트웨어를 정의하기 위해 기술들이나 원칙들을 적용시키는 과정으로 본다.

.여기서 원칙이란 여러가지가 있다.

tunnel vision에 어려움이 없어야함

Analysis model을 재추적 할 수 있어야 함

설계는 코딩이 아님

Semantic 에러를 최소화 하도록 review되어져야만 함, 기타 등등

- 설계는 명시된 모든 요구사항들을 구현해야만 한다.

- 설계는 알아보기 쉬운, 이해하기 쉬운 가이드가 되어야 한다.

- 설계는 소프트웨어의 완전한 모양을 제공해야 한다.

7.2 Fundamental Concepts(설계의 기본 컨셉)

- 설계를 위한 기본적인 몇몇의 개념들이 존재한다. 그 개념들은 아래와 같다.

- Abstraction(추상화) 

.세부사항들을 숨기고, 쉽게 이해가능 하도록 표현하는 방법

.단계가 진행됨에 따라 추상화 level은 낮아짐

.Data, Procedure 또는 Control 등을 추상화할 수 있음 

- Data Abstraction(자료 추상화)

.자료 구조에 대해 알지 못하도록 제한하는 것

.이 데이터에 대해서는 오직 미리 정

의된 프로시저를 통해서만 접근 가능하도록 하.

.Information hiding을 구현하는 수단으로서 이용됨(클라이언트들이 어느 한 모듈을 실제 인터페이스들을 통  해 이용하지만 이 모듈안에서 어떻게 동작되어 지고 있는지는 숨겨짐)

.Information hiding은 Side effect의 가능성을 줄이기이며, 또는 제어되는 인터페이스와의 커뮤니케이션을 강조하기 위해서라던가, 높은 품질의 설계를 위해 캡슐화를 잘 하기 위해 등등 이유가 있음.

- Design Patterns(설계 패턴)

.여러가지 문제에 대한 설계 사례를 분석해서 서로 비슷한 문제를 해결하기 위한 설계들을 분류하고, 각 문제 유형별로 가장 적합한 설계를 일반화시켜 패턴으로 정립한 것을 의미함

.패턴들을 이용하면 높은 추상화 단계로 communication이 가능하고, 반복되는 솔루션과 이름들을 간단히 구체화 할 수 있음

- Modular Design은 조금 더 자세히 살펴보자

7.2.2 Modular Design(모듈화 설계)

- Decomposition을 이용하여 소프트웨어를 모듈이라는 Component로 나누는 것이다.

- 무조건 많이 decomposition하는 것이 좋은가? 아래 그림을 보면 모듈 개발에 대한 비용도 있으므로 적절히 나누는 것이 중요함.

- 효과적인 모듈화 설계는 Functional Independence(기능적 독립)이 요구된다

.각 모듈들이 특정 요구사항의 부가적인 기능들을 수행할 뿐만 아니라 단순한 인터페이스도 가지고 있음

- Modular Design의 효과적인 부분은

.모듈화가 잘 되어있는 소프트웨어는 인터페이스가 단순하고 각 기능이 잘 구분되어 개발하기가 더 쉬움

.독립적인 모듈들은 유지보스와 테스팅(검사)을 더 쉽게 함(에러 전파도 낮고 모듈들이 재사용될 수 도 있으므로)

- 함수적 독립에 대해서 Cohesion(응집력), Coupling(결합력)이라는 개념들이 있다.  

 

7.2.3 Cohesion & Coupling

- Cohesion(응집력): 하나의 Module 안의 element들이 얼마나 연관성이 깊은가를 측정.

.High cohesion이라는 것은 모듈이 모든 element들이 강하게 연관되어 있다는 것.

.높을 수록 모듈이 외부와의 interaction없이 하나의 기능을 완벽히 수행하는 것으로 여겨짐.

.Cohesion의 목표는 Maximize Cohesion이다.

- Coupling(결합력): 모듈과 모듈 사이의 상관 관계가 얼마나 있는가를 측정(상대적인 독립성을 측정)

.모듈들 간의 인터페이스 복잡성에 좌우된다.

.Low coupling의 시스템은 높은 유지보수 능력을 가진다.

.목표는 Minimize Coupling이다(불필요한 관계들은 없애고, 필요한 관계들의 수도 줄임)

- 하나의 모듈안의 element들 사이에서 관계들을 측정하는(Cohesion을 측정하는) 여러 Level 이 존재

.Coincidental Cohesion: 각각의 element들이 서로 상관관계는 없는데 우연히 같은 모듈로 묶임.

.Logical Cohesion: 모듈 외부(flag)로 부터 선택되어 실행 되는 모듈

굉장히 low level의 모듈화 이며, 동시에 실행될 수 없다. 따라서 flag에 따라 분리하여 설계되야됨.

ex) I/O와 관련된 모든 것을 한꺼번에 묶음으로서 flag에 따라 모듈안의 각 기능들이 실행되도록... 

.Temporal Cohesion: 특정 활동(activities)에 연관된 element들을 시간에 대하여 모듈화

.Procedural Cohesion: 차례차례 하는 하나의 '절차'에 대하여 모듈화.

각 절차들에 있어서 서로 관련성이 없는 activities에 대해서는 제거 하는 것이 필요하다.

      

(여기서는 A와B를 나누어 두개의 Function으로)

.Communicational Cohesion: 같은 Input(또는 Output)에 대하여 묶어 모듈화

하지만 위와 같은 모듈은 caller가 필요로 하지 않는 정보까지 반환한다.

따라서 각 return value에 따라 다시 나누는 것이 필요하다.(여기서 return value를 반환하기 위한 다른 각각의 기능들도 나누는 것도 필요하다)

.Sequential Cohesion: 하나의 작업 결과과 다음의 작업 결과의 입력으로 작용 될 때의 모듈.

 이는 좋은 Coupling의 형태이며 쉽게 유지보수가 된다.

.Functional Cohesion: 모듈이 단 하나의 기능만을 가짐.

.Sequential는 Functional에 비해, 하나의 특정 기능을 완벽히 수행하는 것이 아님(재사용성이 낮음)

.각 단계를 구별하는 방법은 다음 사진과 같다.

.ex) 위험이 감지 됬을 때 모든 것을 초기화하고 task를 취소시키는 모듈....

Temporal(Procedural과 겹칠 때는 낮은 레벨을 선택)

환자의 혈압, 심박률 등의 데이터를 처리하는 모듈....

Communicational

- Coupling에서도 여러 Level이 존재

.Content Coupling: 한 모듈이 다른 모듈의 안을 참조할 때. Coupling이 세서 별로 좋지 못함. 

.Common Coupling: 같은 global data들을 참조할 때. Global data를 쓰면 모두가 같은 데이터를 쓰게 되면서 Coupling이 세짐. 이해력이 떨어지고 Ripple effect 발생 가능. 

Global data들을 Module scoped variable들로 선언함으로써 접근을 제한하는 것으로 바꿔줘야 함.

하지만 재사용의 문제가 있을 수 있으므로 이를 또 접근 함수들을 이용하도록 함(getA, setB).

.Control Coupling: 한 모듈이 매개변수로 다른 모듈의 logic을 제어할 때.

Forward control: Caller가 Callee의 내부적인 흐름을 제어 할 때

이 방식도 flag에 따라 Callee를 제어하게 되는데, 이를 각 flag에 따른 다른 모듈들로 분리할 것

Backward control: Callee가 Caller의 내부적인 흐름을 제어할 때

Callee는 Caller에게 Descriptive flag로 event에 대한 설명을 해줄 수도 있고, Control flag로 event에 데한 Action도 할 수 있지만, Descriptive flag를 해주는 것이 더 좋음

.Stamp Coupling: 모듈들이 데이터 구조체의 일부분을 위해 전체를 전달 받을 때. 

오직 필요한 필드에 대해서만 전달 할 수 있도록 바꾸는 것이 요구됨

번들링(연관업슨 데이터들을 하나의 자료구조로 모은 것)을 풀고 인터페이스를 재정의하는 것이 필요

.Data Coupling: 모듈간이 데이터 타입을 이용하여 자료를 교환할 때.

파라미터들을 이용하여 자료를 교환하며 각 파라미터들은 가장 기본적인 타입임(구조체 아님)

가장 Coupling이 약하면서도 바람직한 형태

.ex) Call Print_Label(name, address, city, state, zip

-> Data Coupling

Call Print_Label(Customer_purchase_order_record)

-> Stamp Coupling

Call Print_Label

-> Common Coupling

- 결과적으로 Maximize (High) Cohesion / Minimize(Low) Coupling이 설계의 목표임

- 다시 앞의 7.2로 돌아가서 또 하나의 설계의 기본 컨셉 중 하나

.Refactoring: 외부와의 인터페이스를 바꾸지 않고 내부의 구조 만을 바꾸는 것(개선을 위해)