[Object Oriented S/E] Chapter 6 - Architectural Design

# 범위

139 page ~ 

# 내용

## 6 Architectural Design

많은 소프트웨어들은 개발이 완료되고 수십년동안 동작한다. 그리고 그러는 사이에 많은 업그레이드를 거친다.

소프트웨어 아키텍처와 같은 요소는 system properties나 performance, efficiency,security,maintainablity와 같은 요소에 지대한 영향을 끼친다.

 

## 6.1 WHAT IS ARCHITECTURAL DESIGN?

• 소프트웨어 아키텍처 디자인은 건물의 아키텍처 디자인과 같다.
• 아키텍처 디자인은 주요시설과 하위 시스템들 그리고 그것들이 어떻게 관계되고 작동하는지에 대해서 강조한다.
• [시스템 또는 하위 시스템의 소프트웨어 아키텍처는 주요 구성 요소간의 상호 작용 및 상호 작용을 포함하는 시스템 구조의 설계 스타일을 의미한다.]
• [소프트웨어 아키텍처 설계 또는 단순한 아키텍처 설계는 개발 중인 시스템의 소프트웨어 아키텍처를 결정하기 위한 의사 결정 프로스세이다.]
• 설계 타입의 소프트웨어 아키텍처는 디자인 결정은 이미 완료됐으며, 아키텍처는 이러한 디자인 의사 결정의 결과이다.
• 설계 스타일의 아키텍처와 설계 결정 집합 사이에는 사소한 차이가 존재하고, 전자가 조금더 실체적인 것이다.

## 6.2 THE IMPORTANCE OF ARCHITECTURAL DESIGN

• 한 회사에 예를 들었다. 데이터 베이스 래퍼에 관한 이야기 였다.
• 기존 설계는 DB를 바꾸기 위해서는 다른 의존된 많은 코드를 수정해야 했기에 wrapper를 만들자는 이야기가 나왔지만 묵살됐다.
• 얼마 후 Ontologies라는 것에 의존했던 개발팀은 해당 회사가 파산하자, wrapper를 늦게나마 만들기 시작했지만 때는 늦었고 결국 회사가 망했다.

 

## 6.3 ARCHITECTURAL DESIGN PROCESS

• 어떤 종류의 시스템을 개발할것인지에 대한 것은 중요한 관심사항이다 이러한 시스템의 타입은 아키텍처 스타일에 영향을 주기 때문이다.
• 아키텍처 디자인은 재귀적인 과정이다. 그리고 sopping rule(재귀 과정을 멈추는)은 따로 없다. 이것은 불명확하고 경험에서 나온다.
• 아키텍처 설계 프로세스 - 아래 과정들이 재귀적으로 반복적으로 행해짐.
  • 1. 설계 목표를 정한다 - 이 설계는 소프트웨어 안전 및 보안 을 제공하고 성능을 극대화는 것을 목표로 한다.. 이러한 설계 목표는 요구사항에서 도출 가능하다.
  • 2. 시스템 유형을 확인한다.
  • 3. 아키텍처를 적용하거나, CUSTOM 아키텍처를 수행한다.
  • 4. 설계도롤 검토한다.

### 6.3.1 Determine Architectural Design Objectives ( 아키텍처 설계 목표 결정 )

• 어떤 좋은 아키텍처가 다른 시스템에서도 똑같이 좋은것만은 아니다.
• 다른 어플리케이션들은 다른 목표와 우선순위를 두고 있기 때문에 아키텍처를 결정하는데 영향을 끼친다.
• 고려해야할 요인들
  • 변경 및 유지보수 용이성 : 얼마나 자주 변경이 일어나는가?
  • 상용 기성품 부품의 사용 - 사용 툴들을 사용하고 있거나 금지하고 있거나
  • 신뢰성
  • 보안
  • 내결함성 - 응용 프로그램에 오류가 발생할 때 시스템이 계속 작동하도록 요구되어지는 범위가 어디인가?
  • 복구

### 6.3.2 Determine System Type

• 시스템의 유형은 분석,설계,모델링, 구현 테스트에 많은 영향을 끼친다.
• 한 프로젝트에서 잘 작동하는 모델링 디자인 방법이 다른 곳에서는 잘 작동하지 않을 수 있다. 이건 모델링과 디자인 방법론의 불일치 때문이다.
• 4가지 유형의 시스템에 대해서 고려된다. 
  • 대화형 하위시스템 
    • 시스템은 actor부터의 요청을 잘 처리해야한다.
    • 상호작용은 actor와 시작해서 끝낸다
    • 클라이언트-서버관계
  • 이벤트 기반(구동) 하위시스템
    • 외부 엔티티로부터 이벤트를 수신하고 제어한다
    • 수신 요청의 순서가 고정되어 있지 않는다. 무작위다
    • 모든 수신 이벤트에 응답할 필욛가 없다. ( 무시 가능)
    • 둘 이상의 외부 엔티티와 상호작용을 하기도 한다.
    • 타이밍(시간)제한 조건을 충족해야할 수 있다. N-밀리세컨드 안에 도착해야한다..
  • 변환 하위시스템
    • 임베디드 시스템에서 흔히 볼 수 있다
    • 정보처리활동의 네트워크로 구성
  • 데이터베이스 하위시스템
    • 데이터베이스의 나머지 부분을 숨기고 데이터베이스 구현으로부터 보호

 

### 6.3.3 Applying Archtectural Styles

• 4가지 다른 유형의 어플리케이션 시스템을 확인했다. 이에 따른 아키텍처가 필요로 하다.
• N계층 아키텍처
  • 클라이언트의 요청은 한계층에서 다른 계층으로 전송 된다. 하위 계층에서 상위 계층으로 전송은 피해야한다.
  • 대화형 시스템의 객체를 여러 계층으로 분할하고 해당 계층에 책임을 할당한다.
  • 대화형 뿐만 아니라 네트워크에 쓰이는 7계층, 보안에도 많이 쓰인다.
• 클라이언트-서버 아키텍처
  • 공항 수화물 처리 시스템과 같은게 클라이언트-서버 아키텍처이다.
  • 서버는 클라이언트의 요청을 처리하고 결과를 응답한다.
  • 클라이언트는 서버의 존재를 알지만 서버는 클라이언트의 존재를 모른다.
• 메인 프로그램과 서브루틴 아키텍처
  • 하나의 메인프로그램과 다수의 서브루틴으로 이루어져 있다. (트리 형식)
  • 메인프로그램은 다수의 하위서브루틴을 호출하고 하위 서브루틴은 하위서브루틴을 호출한다.
• 이벤트 기반 시스템 아키텍처
  • 상태 의존적이다. ( 에어컨 )
  • 제어의 문제
    • 적절한 상태가 아니면 요청을 무시할 수 있음( 클라이언트-서버는 그렇지 못함 )

• 영속성 프레임워크 아키텍처
  • 데이터베이스는 서로 다른 공급업체로부터 제공 될 수 있다.
  • 각 비즈니스 개체들은 다른 업체의 데이터베이스에도 접근할 수 있어야 한다. 그렇기 위해서는 구성 방식을 알야아하고 복잡성이 증가한다. 
  • 인터페이스를 제공하고 데이터베이스 매니저가 요청을 위임한다.

 

## 6.4ARCHITECTURAL STYLE AND PACKAGE DIAGRAM

• 개념화
• 구조화
• 매니징
• 발전

## 6.5 APPLYING SOFTWARE DESIGN PRINCIPLES

• 1970년대 다른 기능들의 수천줄의 코드가 한모듈에 작성됐으며 이런건 이해하기 어렵고 테스트 관리 하기 어렵다. 기능적 응집도가 낮다고 설명할 수 있다.
• 높은 결합도 문제 중하나이다. 서로 복잡하게 얽혀있으면 서로가 서로에게 복잡한 영향을 끼친다.

 

### 6.5.1 What Are Software Design Principles?

• [소프트웨어 설계 원칙은 소프트웨어 설계를 위한 지침으로 널리 받아들여지고 있다. 이러한 원칙을 올바르게 적용하면 소프트웨어를 크게 향상 시킬 수 있다.]

### 6.5.2 Design for Change ( 변경을 위한 설계 )

• 변화는 매우 자주 일어나는 상황이다. 어떤 도메인에서던지.
• 좋은 디자인은 변화하기 쉽고 적용하기 쉬운 디자인이다.

### 6.5.3 Separation of Concerns ( 관심 분리 )

• 고립된 한 측면에 문제에만 초점을 둔다. 모든 측면을 동시에 다루지 않는다.
• 높은 수준에서는 전반적인 설계 과정을 어떻게 진행할지에 대한 고려를 한다.
• 하위수준에는 개별 구성요소들을 설계하는 방법과 관련이 있다.
• 아키텍처가 전체 설계 프로세스의 한측면에만 집중하고 다른 측면은 일시적을 중지해야 한다.
• N-계층 아키텍처도 관심사의 분리가 행해진것이다. 다른 관심사의 책임을 다른 하위 시스템에 할당해야 한다. 
• 높은 응집력과 하위시스템의 이해와 재사용을 촉진시킨다.

 

### 6.5.4 Information Hiding

• 클래스의 데이터멤버를 숨기고 인터페이스를 제공함으로써 안정적으로 유지할 수 있다.
• 클라이언트는 둘이상의 구현이 있으면 어떤 구현이 사용될지 알지 못한다. 인터페이슬 활용하면 이러한 문제를 해결 할 수 있고 결국 정보의 은닉에서부터 나온다.

### 6.5.5 High Cohesion ( 높은 응집력 )

• 모듈형 설계에서 비롯됐다. 상위 레벨 모듈이 하위레벨 모듈을 호출하고 하위 레벨 모듈에서 반환된 결과를 합성하는 트리와 같은 모듈
• 높은 응집력은 소프트웨어 재사용 및 소프트웨 어 유지보수를 용이하게 한다.

### 6.5.6Low Coupling ( 낮은 결합도 )

• 런타임에만 알려지기는 요소들은 높은 결합도를 띄면 테스트, 디버깅시 어려움이 발생한다.
• 모듈간 의존성과 상호작용으로 인한 런타임 효과.
• 세개 이상의 값을 갖는 관리 변수를 피해라, 변경 및 정보 은닉화 설계를 해라

### 6.5.7 Keep It Simple and Stupid(KISS 원칙)

• 간단하고 멍청하여 이해하기 쉬운 설계를 선호한다.

## 6.6 GUIDELINES FOR ARCHITECTURAL DESIGN

• 가능하면 아키텍처를 적용해라
• 소프트웨어 디자인 원칙을 적용해라
• 디자인패턴을 적용해라
• 설계 목표와 설계 원칙을 대조해라
• 필요할때까지 반복해라

## 6.7 ARCHITECTURAL DESIGN AND DESIGN PATTERNS

## 6.8 APPLYING AGILE PRINCIPLES

• [포괄적인 문서보다 작동하는 소프트웨어에 집중한다.]
• [20/80 룰을 적용해라. 그거면 됐다. 충분하다면 된거다]-