프로젝트 계획(11-1) 아키텍쳐 스타일 [소프트웨어공학]

6가지는 이전 글에서 설명했으니 

첫 번째 부터 차차 살펴볼까?

 

---

계층 구조 스타일

 

그림을 보면 살짝 감이 오겠지만

 

고전적인 방법으로 

각 서브시스템이 하나의 계층이 되어 하위층이 제공하는 서비스를 상위층의 서브시스템이 사용하도록 구성된다.

 

즉 상위층은 클라이언트가 되며 하위층이 서버처럼 작동하고 미리 정의된 API를 이용하여 상호작용을 한다.

 

++N-tier 아키텍쳐 스타일은 각 층을 보다 개선된 버전으로 교체할 수 있다.  예를 들어 시스템을 여러 플랫폼에 이식할 때 사용자 인터페이스 층을 교체할 수 있다. (물론 어떤 층의 교체가 하위층에 영향을 주어서는 안된다.)

 

++N -tier 아키텍쳐 스타일은 대화형 시스템을 위한 스타일로 자주 사용된다. 

(꼭 대화형 시스템만을 위한 것은 아니다. 대부분 운영체제가 N-tier 스타일로 구축된다)

 

 

계층 구조의 장점은

층과 층 사이의 인터페이스 제약만 어기지 않으면 각 층을 필요에 따라 쉽게 변경할 수 있다는 것이 가장 크고

또한 연결된 층의 인터페이스만 맞추면 특정 계층을 쉽게 재사용할 수 있는 것이다.

 

물론 시스템을 계층 구조로 설계하는 것이 어려울 때도 있다. 

각 서브 시스템 사이에 복잡하게 관계를 맺고 있어 이를 독립적인 층으로 분리 추상화하기 어려울 때가 있어서 그렇다.

또한 과다한 계층 분할은 서브시스템 사이의 인터페이스로 인하여 성능의 저하를 가져온다.

 

---

클라이언트 서버 스타일

 

 

 

서버와 여러 개의 클라이언트로 구성되어있는데

서버는 클라이언트라 불리는 서브시스템에게 서비스를 제공한다. 

클라이언트는 사용자와 대화해야 한다. 

 

++서비스의 요구는 원격 호출 메커니즘이나 여러 종류의 미들웨어에 의하여 이루어진다. 

 

클라이언트나 서버의 제어흐름은 요청과 결과를 받기 위하여 동기화 되는 일을 제외하고는 모두 독립적이다.

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

서비스를 받는 서브시스템은 대부분 다른 컴퓨터에 존재한다. 필요한 서비스가 대부분 서비스에서 제공된다면 클라이언트는 매우 가벼워 진다. 

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

 

---

트랙젝션 처리 스타일

 

 

트랜잭션 처리 아키텍처는 입력을 하나씩 읽어 처리한다. 

입력은 시스템에 저장되어 있는 데이터를 조작하는 명령들, 즉 트랜잭션이다.

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

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

 

위의 그림을 보면 트랙젝션은 새 항공편 추가, 항공권 예약, 예약 변경, 예약 취소 같은 것들을 처리한다.

 

++ 다형성을 가진 메소드의 동적 바인딩과 같이 트랜젝션을 묵시적으로 표현하고 원격 처리 서버와 연결한다.

 

 

 

 

 

---

MVC 스타일 (Model-View-Controller)

 

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

 

MVC의 구조는 사용자 인터페이스를 담당하는 계층의 응집력을 높일 수 있고 여러 개의 다른 UI를 만들어 그 사이에 결합도를 낮출 수 있다. 

MVC 스타일은 시스템의 기능을 담당하는 층을 사용자 인터페이스의 두 가지 측면 View, Controller 를 담당하는 컴포넌트와 분리해버린다.  아니면 위의 그림처럼 세 가지 요소가 별도의 컴포넌트 또는 스레드로 구성될 수 있다.

 

 

모델:사용자에게 보이고 조작될 수 있는 중요한 클래스의 인스턴스들을 가지고 있다

뷰: 모델에 있는 데이터를 사용자 인터페이스에 보이는 역할을 담당하고 또한 사용자가 상호작용할 수 있는 여러 가지 제어를 디스플레이 한다.

제어:  사용자가 뷰와 모델과 인터랙션하는 것을 제어하는 객체를 포함한다. 사용자가 입력 필드에 입력하고 마우스를 클릭하면 반응하는 로직을 가진다.

 

 

++흔히 모바일 어플리케이션에서 볼 수 있음

 

---

이벤트 중심 스타일

 

이벤트 중심 시스템 아키텍처는 상태 기반 컨트롤러와 제어 대상이되는 여러 컴포넌트로 구성된다.

 

 

이벤트 중심 시스템은 상태에 의존하는 동작을 앞에서 말했다. 이런 동작들은 컨트롤러에 의하여 구현된다.

제어 대상이 되는 컴포넌트들은 컨트롤러에 이벤트를 보내고 시스템이 어떤 상태에 있느냐에 따라 이벤트가 처리되고 제어 대상 컴포넌트에 명령이 전달된다.

 

++이러한 제어 문제를 N-tier로 구축한다면 이전 상태를 기억하고 다음 상태가 무엇인지 알 수 없다. 

 

 

 

---

객체 영속 스타일 (Object Persistence System)

 

비즈니스 시스템은 데이터베이스에 객체를 저장하고 나중에 이를 검색할 필요가 있음. 그래서 이러한 스타일을 쓴다.

 

 

 

영속 아키텍쳐 프레임워크를 사용하지 않는다면 비즈니스 객체들은 서로 다른 회사의 다른 타입의 데이터베이스를 어떻게 접근하는지 모른다.

또한 비즈니스 객체들은 데이터가 데이터베이스 안에서 어떻게 구성되어 있는지 모른다.

이러한 부분이 비즈니스 객체를 더욱 복잡하게 만든다.

 

이러한 구조는 DB관리자를 이용하여 비즈니스 객체에서 객체지향 인터페이스를 제공한다. 

 

**이렇게 하면 여러 회사의 다른 타입의 데이터베이스와 통신할 수 있고  비즈니스 객체의 설계와 구현, 테스팅과 유지 보수를 단순화 할 수 있게 된다.  

 

 

---

다음에는 미들웨어에 대해서 알아보자