프로젝트 계획(10-1) 아키텍쳐 설계 원리 [소프트웨어공학]

이번엔 설계 원리에 대해서 다뤄보도록 하겠씁니다.

 

---

우선 설계에 근거하여 구축한 시스템이 요구를 잘 만족하였을 때 그 설계가 바르다고 할 수 있다.

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

 

그렇게 하려면 설계를 평가할 수 있는 특성과 기준을 정해야 하는데 

 

사실 정량적으로 평가할 수 있는 것이 가장 좋지만 소프트웨어 특성상 정량적 평가가 어렵다. 

그래서 다른 2가지를 평가하는데 그것이 바로

1. 효율성(efficiency)

  시스템이 사용하는 자원이 적정하고 효과적임을 의미한다.

2. 단순성(simplicity)

  이해하기 쉬운 설계를 작성하는 것, 즉 유지보수성에 직결되는 요소를 말한다.

 

하지만 두 요소는 trade-off 관계에 있다. 최적의 균형을 찾으려고 노력할 뿐이다. 

 

 

 

**아키텍쳐와 설계 원리를 표현한 그림이다

 

 

설계 원리는 도메인 분석에 사용되는 원리와 거의 비슷한데 다른점이 있긴 하다

 

1. 도메인 분석에서는 문제 도메인에 대한 모델을 구축하지만 설계에서는 솔류션 도메인에 대한 모델을 만든다.

2. 도메인 분석에서는 주어진 문제에 대하여 모델을 결정할 때 선택이 제한적이지만

    설계에서는 시스템 구축의 기초가 될 모델을 창조하기 때문에 많은 자유가 있다.

3. 도메인 분석에서 모델링의 기본 목적은 이해하는 것이나 설계에서의 모델링은 최적화하는 것이다.

 

비슷해 보이는 것은 사실이지만 다른 점이 명확히 보이는 것 또한 사실이다.

 

 

소프트웨어 설계의 중심이 되는 4가지 원리를 살펴보자

1. 추상화(Abstraction)
2. 정보은닉(Information hiding)
3. 단계적 분해(Stepwise refinement)
4. 모듈화(Modularization)

 

차차 살펴보자

 

**정보은닉은 너무 당연해서 여기서 설명하고 넘어가겠다.

정보 은닉은 한 함수 안에 특정 기능을 수행하는 데 필요한 자료만을 사용 가능하도록 규제하겠다는 원리로

다시 말해서 필요 없는 자료를 접근할 필요가 없다는 개념이다.

 

 

 

---

 

단계적 분할에 대해 알아보자

 

작은 문제를 해결하는 것은 쉽다. 큰 문제를 해결하는 것은 어렵다. 그래서 나온 것이

Divide and conquer이다. 분할 정복이라고하는데 큰 문제를 쪼개서 차례로 박살내는 것이다.

 

**그런데 분할할 때 부분적으로 해결이 가능한가 알아봐야 한다. 즉 분할을 해서 해결할 수 있는 것을 분할해야 한다.

막 다 쪼개고 그러는게 아니다. 

 

다시 말해서 단계적 분할은 복잡한 문제를 해결하기 위하여 필수적이며 설계를 계층화한다.

 

**단계적 분할을 사용한 설계는 컴포넌트를 계층으로 표현할 수 있다.

 

분할 과정은 이렇다.

 

1) 문제를 기본 단위로 나눈다.
2) 독립된 문제로 구별한다.
3) 구분된 문제의 자세한 내용은 가능한 한 뒤로 미룬다.
4) 구체화 작업이 계속 점증적으로 일어난다는 것을 보인다.

 

 

++ 소프트웨어를 이루는 모듈들을 구체적으로 설계할 때 사용하는 방법이다.

 

---

 

이번엔 추상화를 알아볼까?

 

정의는 필요한 부분만을 표현할 수 있고 불필요한 부분을 제거하여 간결하고 쉽게 만드는 작업을 뜻한다.

 

추상화는 소프트웨어뿐만 아니라 모든 분야에도 적용될 법한 개념이다.

컴포넌트 구현에 대한 자세한 사항들을 염려하지 않고 추상적인 수준으로 컴포넌트를 다루는 도구라고 할 수 있다.

 

**컴포넌트나 시스템은 외부에 서비스를 제공하는 것인데 컴포넌트를 추상시킨다는 것은 어떻게 동작하는지를 신경쓰지 않고 외부에 이렇게 동작을 보일 것이다라는 것을 표현하는 것이다.

 

++ 예를 들면 지하철 노선도는 실제 도시의 도로 지명 상관없이 그린 것이다. (추상화의 좋은 예)

 

소프트웨어 시스템을 위한 추상화 방법에는 3가지가 있다.

 

1. 기능 추상화

모듈이 수행하는 기능 측면으로 간략화 하는 방법이다. 

즉 전체 기능을 구성하는 작은 기능들로 나누는 것이다.

예를 들어서 값을 계산하는 모듈은 "계산기"라고 축약만하고 알고리즘은 생략한다

 

 

2. 자료 추상화

자료는 실세계의 어떤 엔티티를 나타낼 수 있는데 엔티티는 소속된 환경에 특정 서비스를 제공한다.

자료 엔티티의 경우 자료 자체만을 의미하는 것이 아니라 "자료에 대한 조작" 즉 오퍼레이션과 같이 정의 한다.

다시 말해서, 자료 객체 밖에서는 내부의 내용은 가려져 있고 자료에 대한 오퍼레이션만을 볼 수 있게 축약하는 것이 자료 추상화이다.

 

 

3. 제어 추상화

프로그램의 액션에 대하여 간략하게 표현한 것을 말하는데

액션이란 서브프로그램 안의 제어 흐름과 같은 개념으로 흐름도나 의사 코드 등으로 축약 표현 가능하다.

 

---

 

이제 모듈화에 대해서 알아보자

 

시스템을 모듈로 분할하면 각각의 모듈을 별개로 만들고 수정할 수 있기 때문에 좋은 구조가 된다.

(변경이 쉽다는 얘기겠지?)

 

그렇지만 모듈로 잘라놓았다고 해서 소프트웨어 시스템이 모듈화 되는 것은 아니다.

모듈화가 되려면 추상성을 잘 정의하고 모듈 사이에 인터랙션하는 인터페이스를 명확히 해야한다. 모듈성은 추상화와 함께 분할이 잘 이루어질 때 가능한 것이다. 

 

설계 과정에 독립된 모듈로 분할하기 위해서는 기준이 있는데 2가지가 있다.

더 자세히 말해서 기능 추상화 기법을 사용하는 시스템에서 2가지가 있다.

 

1. 결합 (Coupling)

2. 응집(Cohesion)

---

 

모듈간의 결합에 대해서 알아보자면 

 

우선 두 모듈이 상대가 존재하지 않아도 잘 작동하면 독립적이라고 할 수 있다. 하지만 시스템의 모든 모듈이 서로 독립적일 수는 없다. (만약 다 독립적이면 처음부터 소프트웨어공학이란 단계까지 넘어올 필요가 없었다.)

*시스템의 기능을 제공하기 위해서는 상호 작용이 필요하다. 

 

연결이 많을수록 이해하기 힘들다.

따라서 모듈 사이에 연결을 적게 하고 단순화 할수록 다른 모듈의 이해 없이 다룰 수 있다. 

 

++결합도란 모듈 간에 상호 의존하는 정도를 말한다.

 

 

즉 결합도는 차이가 있고 결합도가 강할수록 조금 어려운 부분이 생기게 된다.

 

각각의 결합을 살펴보자면

 

1. 자료결합이란 모듈간의 인터페이스가 자료 요소로만 구성된 경우를 말한다.

 

2. 모듈간의 인터페이스로 배열이나, 레코드 등의 자료 구조가 전달되는 경우는 스탬프 결합이 된다.

 

3. 한 모듈이 다른 모듈에게 제어 요소(function code, switch 등)를 전달하는 경우는 제어 결합이 된다.

 

4. 여러 모듈이 공동 자료 영역을 사용하는 경우를 공통 결합이라고 한다.

 

5. 한 모듈이 다른 모듈의 일부분을 직접 참조 또는 수정하는 경우에 이를 내용 결합이라고 한다.

(딱 봐도 결합도 강해보인다 )

 

 

 

결합도에 영향을 주는 것은 3가지 정도가 있는데

 

 

++결합도를 낮추려면 모듈 사이의 인터페이스 수를 줄이고 각 인터페이스의 복잡도를 낮추어야 한다. 

++모듈을 호출하는 방법을 정의하고 간단한 정보를 파라미터로 넘기는 형태는 결합도가 낮다.

++ 제어 정보를 전달한다는 것은 모듈의 동작이 다른 모듈에서 생성하여 전달한 제어 정보에 좌우된다는 의미로 결합도가 높아진다. 

 

---

모듈의 응집에 대해서 알아보자

 

응집 어디서 많이 본 것 같은데?? 글을 쓸 때 응집성있게 쓰란 말을 많이 들었다... ㅇㅇ그렇다고

 

응집성이 뭐냐 다시 말해보자면 얼마나 관련된 것 끼리 모여있느냐를 뜻한다.

시스템을 이루는 모듈들은 공통의 목적을 가져야 한다. 모듈을 이루는 각 요소들이 공통의 목적을 달성하기 위하여 얼마나 관련 있는 가? 가 응집성이다.

 

**모듈 설계의 목표는 강력한 응집력을 갖는 모듈을 만드는 것이다. 이론적으로는 하나의 모듈이 전체 시스템이 갖는 여러 기능 중에 하나의 기능을 갖도록 설계하는 것이 좋다.

 

또 종류를 보자면 7가지가 있다.

 

 

 

1. 잘 정의된 하나의 기능은 기능적 응집이 될 수 있다.

 

2. 순차적 응집을 가진 모듈은 모듈 안에 있는 하나의 소작업에 대한 결과가 다른 작업의 입력이 된 경우다.

 

3. 교환적 응집은 동일한 입력과 출력을 사용하는 소작업들이 모인 모듈에서 볼 수 있다.

 

4. 절차적 응집은 모듈 안의 작업들이 큰 테두리 안에서 같은 작업에 속하고 입출력을 공유하지도 않지만 순서에 따라 수

행될 필요가 있는 경우를 말한다

 

5. 시간적 응집은 프로그램의 초기화 모듈 같이 한 번만 수행되는 요소들이 포함된 형태를 말한다.

 

6. 유사한 성격을 갖거나 특정 형태로 분류되는 처리요소들로 하나의 모듈이 형성되는 경우 논리적 응집이라 한다.

 

7. 아무 관련 없는 처리 요소들로 모듈이 형성되는 경우를 우연적 응집이라고 한다.

 

 

또한 응집력을 판단하는 기준도 따로 있다. 한 번 보자.

 

 

 

 

여기서 끝내고 다음에는 아키텍쳐 설계 과정을 한 번 공부해보자