6. 설계 원리

●요구 분석에서 설계로 

요구 분석 작업을 통하여 무엇을 개발할 것인가를 결정한 후에는 도메인 영역의 문제에 집중하여 모델링 수행

 

●설계 1

- 요구 분석 : ‘무엇을 만들것인가’를 다루는 작업

- 설계는 ‘어떻게 실현할 것인가’를 구체적으로 결정하는 활동

1) 기본 구조 설계 – 아키텍처 설계로 각 모듈의 역할과 인터페이스를 정의

2) 상세 설계 – 모듈 내부의 알고리즘, 데이터 명세화

 

●설계 2

설계자는 사용자와 개발자를 동시에 만족시켜야함

사용자는 설계를 보고 시스템이 어떤 기능을 하는지 이해할 수 있어야 함

개발자는 시스템이 어떻게 동작하고, 어떻게 구현하는지 이해할 수 있어야함

설계의 종류

+ 아키텍처 설계 : 전체적 설계, 모듈의 종류, 기능, 인터페이스 등

+ 상세 설계 : 세부적 설계, 모듈 내의 기능

 

●설계 기본 개념

설계 : 높은 수준의 의사 결정 과정의 연속, 설계 원리가 중요

전통적 설계 방법 : 분할 정복, 추상화, 합성 등의 원리 적용

최근의 방법 : 아키텍처 기반의 설계 방법

아키텍처 이해 : 서브 시스템, 모듈의 개념과 설계 작업의 관점, 설계 작업 과정에 대한 숙지 필요

 

●서브 시스템

아키텍처 : 시스템을 구성하는 컴포넌트와 컴포넌트 상호작용의 집합

서브 시스템 : 시스템의 복잡도를 줄이기 위해 분할한 것

 

●설계 관점과 표현 방법

1. 모듈 관점 : 일정한 책임을 구현한 코드 단위인 모듈과 그 관계

2. 컴포넌트 관점 : 실행될 때 동작하는 요소와 상호작용

3. 할당 관점 : S/W의 하드웨어 설치, 작업 할당, 구현, 데이터 저장에 대한 관점

 

●아키텍처 설계 과정

1. 목표 설정

2. 시스템의 타입 결정

3. 아키텍처 스타일을 적용하거나 아키텍처 설계를 커스터마이즈

4. 서브 시스템의 기능, 인터페이스 인터랙션 동작을 작성

5. 아키텍처 설계 검토

 

●설계 목표 설정

목표 설정 시 고려사항 : 변경, 유지보수 용이성, 상용 컴포넌트의 사용 여부, 시스템 성능, 신뢰성, 보안, 고장 인내성, 복구

 

●시스템 타입

대화형(Iteractive) 시스템 : 사용자와 시스템과의 상호작용에 기반한 시스템 (온라인 쇼핑몰 시스템)

이벤트 중심(Event-driven) 시스템 : 상태에 의존적이며 반응 동작을 보임(임베디드 시스템)

변환(Transformational) 시스템 : 입력을 일괄 처리 후 출력으로 변환하는 시스템(컴파일러)

객체 영속(Object Persistence) 시스템 : DB나 파일 시스템에 객체를 저장하고 검색할 수 있는 능력을 가진 시스템

 

●아키텍처 스타일

아키텍처 스타일은 소프트웨어 아키텍처들을 분류하고 그들의 공통된 특성을 정의

종류

- 계층 구조 스타일

- 클라이언트 서버 스타일

- 트랜잭션 처리 스타일

- MVC 스타일

- 이벤트 중심 스타일

- 객체 영속 스타일

 

클라이언트 서버 스타일

서버와 여러 개의 클라이언트로 구성

요청과 결과를 받기 위해 동기화 되는 일을 제외하고는 모두 독립적으로 동작

특정 서브 시스템이 다른 서브 시스템에 서비스를 제공하도록 지정할 때 유용

대부분의 웹 기반 애플리케이션과 파일 서버, 전송 프로토콜 포함

 

트랜잭션 처리 스타일

입력을 하나씩 읽어 처리하며 입력은 시스템에 저장되어 있는 데이터를 조작하는 명령들, 즉 트랜잭션

트랜잭션을 어디서 처리하는지 결정하는 디스패처(Dispatcher)라는 컴포넌트가 필요

디스패처는 프로시저 호출이나 메시지를 통해 요청된 트랜잭션을 처리할 컴포넌트에 배치

 

MVC(Model-View-Controller) 스타일

사용자 인터페이스를 시스템의 다른 부분과 분리하여 결합도를 낮추기 위한 아키텍처 스타일

모델 서브 시스템 : 도메인 지식을 저장 및 보관

뷰 서브 시스템 : 사용자에게 보여줌

제어 서브 시스템 : 사용자와의 상호 작용을 관리

 

이벤트 중심 스타일

상태 기반 컨트롤러와 제어 대상이 되는 여러 컴포넌트로 구성

 

미들웨어 아키텍처

소프트웨어 컴포넌트를 연결하기 위한 준비된 인프라 구조 제공

일반적이며 환경에 따라 바꿀 수 있는 융통성을 가짐

- 애플리케이션의 여러 컴포넌트들의 연결 방법 제시

- 여러 컴포넌트를 1대1, 1대다, 다대다 등 여러 가지 연결 형태로 연결

- 사용자는 미들웨어를 인지하지 못하고 애플리케이션과 상호 작용함

 

애플리케이션 서버

N-tier 아키텍처의 중간층에 위치하면서 분산 통신, 보안, 트랜잭션, 영속성을 제공하는 컴포넌트 기반의 서버 기술

인터넷 기반의 애플리케이션을 구축하는데 널리 이용

 

●품질 목표

비기능적인 요구를 설계 목표로 구체적으로 명시

이를 만족시키기 위해 설계 안을 만들고 그 중에 최적 안을 골라내는 작업

 

●전통적인 설계 원리

단순성, 효율성, 분할.계층화, 추상화, 모듈화

 

●설계 원리

설계 작업의 목표는 시스템을 개발하는 조건이나 운용될 환경 조건의 제약 안에서 가능한 여러 설계 중에서 최적의 설계 안을 발견하는 것

- 설계를 평가하기 위한 특성과 기준 명시(정량적)

- 효율성 : 시스템이 사용하는 자원이 적정하고 효과적임

- 단순성 : 이해하기 쉬운 설계를 작성하는 것

소프트웨어 설계의 중심이 되는 원리

- 추상화(Abstraction) : 자세한 부분을 강조하지 않고 컴포넌트 정의에 치중

- 정보 은닉(Information Hiding) : 설계 과정에서 모듈의 어느 정보를 누구에게 보 여줄 것인지를 결정

- 단계적 분해(Stepwise Refinement) : 다루기 쉬운 덩어리로 분리하여 계층화

- 모듈화(Modularization) : 각 모듈이 외부와의 결합이 낮고 내부 요소가 응집되도록 함

 

단계적 분할

1. 문제를 기본 단위로 나눈다.

2. 독립된 문제로 구별한다.

3. 구분된 문제의 자세한 내용은 가능한 한 뒤로 미룬다.

4. 구체화 작업이 계속 점증적으로 일어난다는 것을 보인다.

추상화(Abstracion)

- 대상에 대하여 특정한 목적에 관련된 정보에 집중하고 나머지 정보는 무시하는 관점

- 데이터나 절차적인 동적 관점으로 정의(클라이언트와 서버의 정보 교환을 주고 받는 메시지의 추상화)

캡슐화

- 추상화된 대상이 제공하는 서비스를 쉽게 접근하게 하는 개념. 서비스를 수행하는 핵심만을 도출

- 정보 은닉

모듈화

- 문제를 소프트웨어의 구성요소가 될 만한 수준으로 분할하는 과정

- 소프트웨어를 작은 구성 요소, 즉 패키지 또는 클래스로 나누는 것

- 설계 과정에 돌깁된 모듈들로 분할하기 위해 모듈 선택에 사용하는 기준

+ 결합도와 응집도

+ 모듈의 응집도는 높게, 모듈간의 결합도는 약하게 설계

 

●응집도와 결합도

모듈을 어떻게 만들것인가? 어떻게 모듈을 구성할 것인가?

- 모듈(내) 응집도(intra relationship)은 강하게

- 모듈(간) 결합도(inter relationship)은 약하게

- 모듈의 응집도 : 모듈 내 기능/요소들이 갖는 관계

- 모듈의 결합도 : 모듈 간의 관계

 

●모듈 응집도(Cohesion)

- 모듈 안의 구성 요소들이 공동의 목적을 달성하기 위해 관련되어 있는 정도

- 하나의 모듈은 전체 시스템이 갖는 여러 기능 중에 하나의 기능을 갖도록 설계

- 모듈 내의 모든 요소는 하나의 목적을 가지고 있는 것이 바람직

 

●모듈 결합도(Coupling)

- 모듈 간의 상호 의존하는 정도를 의미

- 모듈은 하나의 블랙 박스로 다른 모듈과의 독립성이 높아야함

- 독립적인 모듈이 되기 위해서는 다른 모듈과의 결합도가 약해야함(loosely coupled)

- 의존성의 종류

+ 제어 의존성(Control Dependence)

+ 자료 의존성(Data Dependence)

결합도가 약한 시스템은 유지보수가 용이함

+ 시스템에 대한 이해가 용이

+ 파급 효과(Ripple Effect) 예방

결합도를 최소화하기 위해 불필요한 모듈간 관계를 제거, 필수적인 모듈 관계를 줄임

 

●결합

내용 결합(content coupling) : 한 모듈이 다른 모듈의 내용을 직접 참조

공통 결합(common coupling) : 한 모듈이 다른 모듈이 읽은 전역 변수 값을 쓰거나 변경

제어 결합(control coupling) : 한 모듈이 다른 모듈의 제어 흐름 경로 결정

스탬프 결합(stamp coupling) : 복합 데이터 구조의 일부만 사용하는 모듈에 복합 데이터 구조 전달할 때

데이터 결합(data coupling) : 모듈들이 주고받는 매개변수가 간단한 타입이거나 레코드 안의 필드이더라도 단순 타입인 경우

 

자료 결합도(Data Coupling)

어떤 모듈이 다른 모듈을 호출할 때 필요한 데이터만 교환

두 모듈이 매개변수, 인수를 이용해 필수적인 데이터만 교환(매개변수, 인수는 데이터이고 제어 정보는 아님)

입력된 데이터는 가공되어 반드시 출력의 일부로 참여

수행 논리가 분명하고 독립성이 높기 때문에 최상의 결합

다른 결합을 갖는 모듈은 데이터 결합을 갖도록 조정

ex) add(3,5), sort(a)

 

스탬프 결합도(Stamp Coupling)

모듈이 복합 데이터 구조(구조체, 레코드, 배열)를 매개변수로 사용할 때 발생가능

모듈이 사용하지 않는 데이터까지 교환된다면

+ 논리적으로 관련 없는 모듈간의 의존성 증가

+ 모듈간의 불필요한 연관 관계를 형성

필수 데이터만 교환하는 데이터 결합을 갖도록 조정

ex) print_salary(인사 기록 레코드)

주의 사항 : 복합 데이터 구조의 일부만 사용되는 경우 전체 복합 데이터 구조를 매개변수로 전달하지 말 것

 

제어 결합도(Control Coupling)

다른 모듈을 호출할 때 스위치, 태그, 플래그, 기능 코드 등의 제어 정보를 매개 변수로 교환하면서 결합 또는 연결

한 기능이 여러 모듈로 분산되어 흩어질 때 발생

유사한 기능들이 한 모듈에 뒤섞이는 경우에 발생

모듈 내부의 수행 논리가 외부에 공개되어 독립성이 훼손

하위 모듈이 상위 모듈에 지시하는 하극상도 발생

ex) integer_operation(‘+’,3,5) : ‘+’가 입력되므로 더하기 연산 수행

 

공통 결합도(Common Coupling)

모듈들이 공통 또는 전역의 기억 장소를 이용, 간접적으로 정보를 교환

자료 영역의 보호가 어렵고, 자료 구조 변경 시 파급 효과가 큼

ex) C/C++ 등에서 global 변수 사용

 

내용 결합도(Content Coupling)

한 모듈이 다른 모듈의 수행 논리를 직접 참조(다른 모듈 내부로 분기하여 다른 모듈의 내부를 조회 및 변경)

모듈 독립성이 훼손되어 유지보수가 어려움

고급언어가 아닌 기계어에서 발생하는 결합 유형

발생하는 경우

+ 다른 모듈로 제어를 분기할 때

+ 다른 모듈의 내부를 직접 수정 및 참조할 때

 

●응집

하나의 모듈 안에서 수행되는 작업들이 서로 관련된 정도

모듈 안의 여러 요소들이 하나의 목적을 위해 유기적으로 관련되어 있는 것이 제일 좋음

높은 응집(재사용하기도 쉽고 이해하기도 좋으며 수정에 의해 받는 영향이 적다)

 

기능적 응집도(Functional Cohesion)

모든 명령들이 한 가지의 문제 해결을 위한 작업만 수행

+ 하나의 기능을 수행하는데 필요한 명령문만 포함

+ 모듈의 목적과 기능이 명확하여 단일 목적어와 단일 동사

구조도의 최하위 모듈에서 많이 발생

가장 강력하고 이상적인 응집의 유형

기능 응집을 갖는 모듈은 재사용 촉진, 모듈화 프로그래밍 가능(다른 유형의 응집을 가지면 기능 응집을 갖도록 명령문 재구성)

 

순차적 응집도(Sequential Cohesion)

어떤 기능 요소의 작업 수행 결과가 다른 기능 요소의 입력으로 사용

동일한 데이터를 여러 명령문이 연쇄적으로 처리하는 경우 발생

처리 순서에 따라 완전히 다른 결과가 생성될 수 있음(반드시 정해진 순서에 따라 명령문 수행)

모듈의 기능을 기능별로 묶어 2개 이상의 모듈로 분리(기능적 응집을 갖는 모듈로 재구성)

 

교환적 응집도(Communicational Cohesion)

서로 다른 기능 요소들이 동일한 데이터를 사용(데이터에 대한 처리 절차가 완전히 다르고 서로 관계없는 경우)

데이터 사용이 처리 순서와 관계없는 점이 순차 응집과 차이

명령문들이 동일한 입력을 사용, 출력을 생성하는 현상(레코드와 같은 복합 데이터를 처리할 때 주로 발생)

실행 순서에 관계없이 항상 동일한 결과 생성

 

절차적 응집도(Procedural Cohesion)

서로 관련 없는 기능 요소들이 배열된 순서(절차)로 수행

+ 한 기능 요소에 다음 기능 요소로 데이터가 아닌 수행 제어만 전달

+ 시간적 응집을 갖는 명령문들이 일정한 순서로 수행

처리하는 데이터에 공통성이 없는 별개 명령문들이 수행

특수한 상황이나 시기를 전후하여 발생하므로 완전 제거는 곤란

 

시간적 응집도(Temporal Cohesion)

서로 관련 없는 기능 요소들이 순서에 관계없이 특정 시점에서 수행(모듈을 구성하는 명령문들이 동일한 시점에서 수행)

수행 순서에 관계없이 항상 같은 결과를 생성(명령문들이 가공하는 데이터가 서로 다름)

동일한 시간에 수행되는 특징(초기화 작업, 종결처리)

특정 시점이나 상황이 사라지지 않는 한 완전히 제거 곤란

 

논리적 응집도(Logical Cohesion)

동일한 범주(성격, 특성)에 속하는 유사한 기능들을 한 모듈에서 수행(모듈을 참조할 때 사용하는 매개변수에 따라 처리 내용/경로 변경)

버퍼, 코드, 상수 및 매개변수 등을 공유하려는 목적으로 사용(일부만이 실행되어 모듈의 실행 효율이 떨어짐)

기능을 중심으로 명령문들을 적절히 분류(보다 높은 응집도인 기능 또는 순차 응집도를 갖도록 모듈을 분리하여 재구성)

 

우연적 응집도(Coincidental Cohesion)

모듈을 구성하는 각 요소들이 서로 상관없는 명령문들만으로 구성

모듈 개념이 상실되어 이해 및 유지보수가 힘든 단점

수행 기능의 고려 없이 관리할 때 많이 발생

소프트웨어를 일정 크기 단위로 단순하게 분할하면 발생

해결 방법 : 기능을 중심으로 명령문들을 분류, 강력한 기능 응집을 갖는 모듈로 분해, 주변 모듈에서도 우연적 응집 가능->주변 모듈의 재구성 여부 검토

 

●객체지향 설계 원리(SOLID)

단일 책임의 원리(Single Responsibility Principle, SRP)

개방 폐쇄의 원리(Open-Closed Principle, OCP)

리스코프 교체의 원리(Liskov Substitution Principle, LSP)

인터페이스 분리의 원리(Interface Segregation Principle, ISP)

의존 관계 역전의 원리(Dependency Inversion Principle, DIP)

 

인터페이스와 구현의 분리

인터페이스 : 공개된 메소드의 프로토타입만을 정의해 놓은 것

공개된 메소드를 인터페이스로 따로 정의하고 이를 구현하거나 인터페이스 상속

컴포넌트의 공개 인터페이스와 구현을 분리

 

단일 책임의 원리

클래스의 역할과 책임을 단일화 하여 클래스를 변경해야할 이유를 하나로 제한

 

개방 폐쇄의 원리

소프트웨어 개체(클래스, 모듈, 기능 등)가 확장을 위해서는 열려 있어야 하지만 수정을 위해서는 닫혀야함

소프트웨어 개체는 소스 코드에 대한 수정없이 행위 확장이 가능하도록 설계 필요

상속 : 다형성이 적용되어 서로 대체할 수 있는 인터페이스를 구현

 

리스코프 교체의 원리

클래스 B가 클래스 A에서 상속받은 하위 유형이라면 프로그램의 동작을 방해하지 않고 A를 B로 대체

하위 클래스는 클라이언트의 관점에서 기능을 손상시키지 않는 방식으로 상위 클래스 메소드를 대체

 

인터페이스 분리의 원리

클라이언트가 사용하지 않는 인터페이스를 강제로 구현해서는 안됨. 즉, 사용하는 인터페이스만 구현

+ 비만 인터페이스(fat interface)

+ 오염된 인터페이스(polluted interface)

 

의존 관계 역전의 원리

복잡한 논리를 제공하는 높은 수준의 모듈은 재사용이 가능하고 낮은 수준의 모듈 변경에 의해 쉽게 영향을 받지 않도록 설계

구체화 된 모듈이 추상화 된 모듈에게 의존이 역전되도록 설계

 

●설계 메트릭

WMC : 클래스 당 가중 메소드

DIT : 상속 트리의 깊이

NOC : 자식 노드의 개수

CBO : 클래스 사이의 결합

RFC : 클래스의 책임

LCOM : 메소드의 응집 결핍