프로젝트 계획(11) 아키텍쳐 설계 과정 [소프트웨어공학]

오늘은 설계과정 살짝 맛만보자

 

---

소프트웨어 시스템의 아키텍쳐 설계 과정은 의사 결정 과정이면서 동시에 인지적인 과정이란다.

시스템의 타입이 아키텍쳐 스타일에 큰 영향을 주는데

그래서 내가 무엇을 만드는지, 목적이 무엇인지 설계하면서 방향성을 잃지 않아야 한다.

 

아키텍쳐 설계는 반복적인 과정이다. 

 

**시스템이 서브 시스템으로 구성되어 있고 그 서브 시스템은 컴포넌트나 다른 서브 시스템으로 구성되어있으니까.

 

 

그림을 보고 이해해보자 ,아키텍쳐 설계과정이다. 

 

말로 한 번 더 설명해보자면

 

Step 1. 목표를 설정한다.

전체 시스템에 대한 설계 목표가 파악되고 결정되어야 한다.

Step 2. 시스템의 타입을 결정한다.
시스템이나 서브시스템의 타입을 결정한다. // 그래야 스타일 결정하지

 

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

아키텍쳐 스타일을 적용할 수 있는 경우가 있고 아닌 경우가 있으니까 알아서 해보자 ㅎ

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

인터페이스를 정의하고 상호작용을 위한 동작을 작성하자

Step 5. 아키텍처 설계를 검토한다.

다른 작업과 마찬가지로 요구, 설계 목표, 원리를 만족하는지 검토하자.

 

 

++방법을 알았으니 차근 차근 알아가자ㅎㅎ

 

---

우선 설계 목표를 설정하는 방법을 알아보자

 

설계는 시스템의 전반적인 구조를 정하는데 목적이 있다.

그렇지만 너무 추상적인 목적이라 설정하기 힘들 수 있다.

목표는 구체적이어야 한다. 

다시 말하면, 설계의 목표는 품질과 보안 요구가 포함된 소프트웨어 요구로부터 나온다.

 

그렇다면 소프트웨어가 요구하는 것들을 알아보면 설계 목표를 세울 수 있겠다.

 

한 번 보자

 

1. 변경, 유지보수 용이성

요구 변경이나 어플리케이션 변동 사항이 생기면 시스템도 자주 변경되어야 하나?

2. 상용 컴포넌트의 사용

상용 컴포넌트가 사용되는가? 사용된다면 얼마나 사용되는가?

3. 시스템 성능

실시간 데이터를 처리하거나 대용량의 트랙젝션을 처리하는 고성능 요구 시스템인가?

4. 신뢰성

어떠한 조건에 어느 정도로 정확히 수행해야하는가?

5. 보안

시스템은 요구하는 자원과 데이터를 어느 수준으로 보호해햐하는가?

6. 고장인내성

고장이 있더라도 시스템이 계속 운용될 수 있는 정도는 어느 정도인가?

7. 복구

시스템이 꺼진 후에 다시 원상태로 복구되기를 어느 정도로 요구하는가?

 

 

위의 7가지는 대표적인 요구를 알아본 것이고 물론 더 있을 수 있다.

 

우리는 이 정도만 참고하고 넘어가자

 

 

 

---

아까 위에서 시스템의 타입이 중요하다고 했다.

이는 아키텍쳐 스타일을 좌우할 수 있다고 말했는데

그럼 어떻게 영향을 주는지 살펴보자

 

일반적으로 타입은 4가지 정도가 있다.

 

1. 대화형 시스템
2. 이벤트 중심 시스템  // 상태에 의존적이며 반응 동작을 보인다.
3. 변환 시스템
4. 객체영속 시스템

++저장미디어를 숨기고 데이터베이스나 파일 시스템에 객체를 저장하고 검색할 수 있는 능력을 가진 시스템

 

영어로도 알아보면

1. interactive 

2. event-driven

3. transformational

4. object-persistence

 

이름도 알았으니 이제 4가지의 특징들을 알아보자

 

---

 

1. 대화형 시스템

 

-시스템과 액터 사이의 인터랙션이 비즈니스 프로세스를 수행하기 위한 것으로 액터의 요구와 시스템의 반응으로 정해져있다.

-시스템이 액터의 요구에 대하여 처리하고 반응한다.

-시스템은 사용 사례에 있는 기능을 처리할 때 한 액터와만 대화한다

-액터가 다른 시스템이나 장치가 될 수도 있으나 대화형 시스템은 주로 사람이다

-대화가 액터에 의하여 시작되고 종결된다

-액터와 시스템은 액터가 서비스를 요청하고 시스템은 서비스를 제공하는 일종의 클라이언트-서버 관계를 보인다. 액터   가 다른 시스템일 경우 클라이언트-서버가 더 표출된다.

-시스템의 상태는 사용 사례에 의하여 표현된 비즈니스 프로세스의 진행을 그대로 반영한다.

 

PC와 웹 어플리케이션이 널리 사용되면서 가장 보편적인 시스템 타입이 되었다

ex) 쇼핑몰 홈페이지

 

로그인, 결제 같은 모든 것들이 대화형 시스템이다. 

 

 

 

**대화형 시스템을 모델링하고 설계하려면 액터가 구동시키는 비즈니스 프로세스를 나타내는 사용 사례를 찾아내고 명세하는 일부터 시작해야한다.

 

 

---

2. 이벤트 중심 시스템

 

-시스템은 외부 엔티티로부터 이벤트를 받고 제어한다

- 이벤트 중심 시스템은 입력의 순서가 정해져 있지 않고 요구가 불규칙하게 시스템에 요청된다.

-이벤트 중심 시스템은 모든 입력 이벤트에 대하여 반응할 필요가 없다. // 상태에 따라 다르다.

-이벤트 중심 시스템은 대부분 동시에 여러 외부 엔티티와 상호작용을 한다

- 외부 엔티티는 사람이 아니라 주로 하드웨어 장치나 다른 소프트웨어 시스템이다.

- 시스템의 상태가 비즈니스 프로세스를 반영하지 않는다. 

-시스템이 시간 제약이나 순서 제약이 필요할 수 있다.

 

 

이벤트 중심 시스템은 주로 임베디드 시스템에서 찾아볼 수 있다.

 

**주로 상태 다이어그램으로 모델링한다

 

++임베디드 시스템은 하드웨어와 소프트웨어로 구성된 시스템에 소프트웨어가 내장된 형태를 말한다.

 

 

---

3. 변환 시스템

 

-입력을 출력으로 변환하는 정보처리 작업들로 이루어진 네트워크다

-작업 네트워크는 순차, 조건 분기, 병렬 스레드로 구성된 제어흐름으로 이루어진다

-입력이 출력으로 변환되는 동안 시스템과 액터 사이에는 액션이 없다.// 일괄처리와 같다

-상태가 존재하지 않는다

-숫자가 많은 계산 집약적인 알고리즘을 요구한다

-액터는 사람, 장치, 다른 시스템 모두 될 수 있다.

 

변환시스템은 주로 엔지니어링 분야에서 많이 볼 수 있고 요즘은 데이터 마이닝과 같은 비즈니스 어플리케이션에서도 볼 수 있다. 

 

많이 알려진 사례는 "컴파일러"다.

 

++ 원시코드에서 실행코드로 바꾸어주는 것이 컴파일러다.

 

---

4. 객체 영속 시스템

 

-데이터베이스를 시스템에서 숨기고 데이터베이스 구현에 대한 변경을 시스템이 잘 모르도록 보호한다

-다른 타입과는 달리 데이터베이스 시스템은 데이터베이스에 객체를 저장하고 검색하는 것밖에 없다

-데이터베이스 시스템은 대규모의 복잡한 데이터를 효과적으로 저장하고 검색하고 갱신할 수 있어야 한다.

 

++데이터베이스를 사용한다는 이유로 데이터베이스 시스템이라고도 불린다

 

 

**객체 영속 시스템은 저장 미디어를 숨기고 데이터베이스나 파일 시스템에 객체를 저장하고 검색하는 시스템이다.

 

 

 

---

 

그렇다면 이러한 시스템 타입을 알았으니까 표현을 어떻게 할지 생각해보자

 

아키텍쳐 표현하는 방법은 관점에 따라 다양하게 있다.

크게 3가지로 나눌 수 있다.

 

무엇을 중심 관점으로 두느냐에 따라 달라진다.

 

 

 

1. 모듈
시스템을 단위코드의 집합으로 보는 관점이다.

뷰는 코드 기반이며 시스템의 런타임 구조를 나타내지 않는다.  모듈 사이의 관계도 코드 기반이며 모듈의 코드가 다른 모듈과 어떻게 상호작용 하는지에 달려 있다. 객체지향 설계에서는 이를 정적인 모델이라 부른다. 

 

++단위 코드는 시스템의 기능 중 일부를 구현한 것이다.

++모듈A가 모듈 B의 코드를 사용하여 의존된 경우 정적인 모델이라고 한다.

 

 

 

2. 컴포넌트와 커넥션
시스템을 컴포넌트라 부르는 런타임 개체의 집합으로 보는 관점이다.

실행 되는 동안 컴포넌트는 시스템의 서비스를 지원하기 위하여 다른 컴포넌트와 상호작용이 필요할 수도 있다. 

커넥터는 이러한 상호작용의 수단을 제공한다. 

 

 

++컴포넌트는 실행되는 시스템에서 고유 식별가능한 단위이다.

++객체 집합 또는 프로세스 같은 것이 컴포넌트의 예가 될 수 있다.

++커넥터는 파이프나 소켓이다, 미들웨어를 사용한다면 미들웨어가 커넥터이다.

 

 

 

 

3. 배치
단위 소프트웨어가 어떤 하드웨어 노드에 배치되는가에 관점이다.

소프트웨어 구성 요소들과 소프트웨어가 실행되는 환경 요소 사이의 관계를 나타낸다. 어떤 프로세스가 어떤 프로세서에서 실행되는가, 시스템 파일이 파일 시스템 위에 어떻게 구성되는가 라는 구조적인 특성도 나타낸다.

 

 

 

---

이제 표현방법도 알았으니 시스템 타입에 맞춰서 스타일을 골라서 표현을 해야겠지?

그러면 스타일에 대해 알아봅시다

 

아키텍쳐 스타일이란 짧게 말하자면 오래된 관습이라고 보자.

 

다시 말하자면!

사람들이 각각 시행착오를 겪으면서 이런 타입은 이렇게 하는 것이 효율적이다. 라는 결론을 얻어서 굳어진 것이

스타일이라고 보면되겠다.

 

6가지 스타일이 대표적으로 있다.

 

**다들 똑같이 하는 것은 아니고 큰 줄기만 따라가고 나머지는 커스터마이징해서 적용들 한다

 

1. 계층 구조 스타일

2. 클라이언트 서버 스타일

3. 트랙젝션 처리 스타일

4. MVC 스타일

5. 이벤트 중심 스타일

6. 객체 영속 스타일

 

 

내용이 너무 많아져서 다음 글에서 알아보자 ㅎㅎ