[소프트웨어공학] Chapter 06. Architectural Design
Architectural design
- 시스템의 전반적인 아키텍쳐와 시스템이 어떻게 조직되어야하는지.
- 설계 과정과 요구공학 과정 간의 중요한 연결고리 ( 시스템의 메인구조 구성요소들과 그들간의 관계를 나타내기 때문 )
- 아키텍쳐 설계의 결과물은 architectural 모델인데 이는 어떻게 시스템이 조직되어있는지 서술한다 ( 구성요소 간의 관계를 통해 )
Agility and architecture ( 민첩성과 아키텍쳐 )
- 애자일 방법론과 소프트웨어 아키텍쳐 개발을 함께 고려하여 개발하는 것
- agile의 초기단계에는 전반적인 구조를 설계
- 시스템 구조를 리팩토링하는 것은 비용이 많이 든다 (시스템 안의 많은 컴포넌트에 영향을 주기때문)
Architecctural abstraction ( 아키텍쳐 추상화 )
- 좁은 영역에서는 각각의 프로그램의 아키텍쳐를 신경쓰고 각각의 프로그램이 어떻게 컴포넌트들로 나뉘는지 고려
- 넓은 영역에서는 다른 시스템들, 프로그램들, 프로그램 구성요소들을 포함하는 복잡한 기업 시스템의 아키텍쳐에 관한 고려
( 이 기업 시스템들은 다른 회사들에 의해 관리되고 소유되는 여러 컴퓨터들에 분산되어있음 )
Advantages of explicit architecture ( 명시적 아키텍쳐의 이점 )
- Stakeholder communication : 이해관계 당사자들의 토론 시 이용할 수 있음
- System analysis : 시스템이 비기능적 요구사항을 충족하는지 분석할 수 있음
- Large-scale reuse : 큰 규모의 구조 재사용
( 디테일 한 부분 제외하고 아키텍쳐는 재사용 될 수 있음. 설계 시 큰 도움을 얻음 )
Architectural representations
Box and Line diagrams
- 매우 추상적 ( 하위(sub) 시스템의 컴포넌트간의 관계를 알 수 없고 외부에서 볼 수 있는 속성을 알 수 없다)
- However, 이해관계 당사자와 소통하거나 프로젝트를 계획하는데 유용
Use of architectural models
- 시스템 설계에 대한 논의를 용이하게 하는데 쓰임
- 설계된 아키텍쳐를 문서화하는데 쓰임
Architectural design decisions
Architectural design decisions
- 아키텍쳐 설계는 창의적인 활동이며 설계 과정은 개발되는 시스템의 유형에 따라 다름
- However, 모든 아키텍쳐 디자인에 적용될 수 있고 시스템의 비기능적 특성에 영향을 주는 공통적인 결정 요소들이 있다
| 공통적인 결정 요소 1. 템플릿처럼 활용할 수 있는 아키텍쳐가 있는가? 2. 하드웨어 코어나 프로세서에 시스템이 어떻게 분배될 것인가 // 분산 시스템으로 할지 고려 3. 어떤 구조패턴이나 스타일이 적용될 것인가? // 디자인 패턴 4. 시스템을 구조화하는데 사용되는 기본적인 접근 방법이 무엇인가? 5. 시스템 상의 컴포넌트의 동작을 제어하는데 어떤 전략을 쓸 것인가 6. 시스템의 컴포넌트가 어떻게 sub 컴포넌트로 분해될 수 있는가 7. 어떤 아키텍쳐 조직이 비기능적 요구사항을 만족시키는데 좋을까 8. 시스템 아키텍쳐를 어떻게 문서화할까? |
Architecture reuse ( 아키텍쳐 재사용 )
- 같은 영역에 있는 시스템은 보통 같은 구조를 지님
- 시스템의 구조는 하나 이상의 패턴 or 스타일을 이용하여 설계된다
Architecture and system characteristics ( 성능 vs 유지보수 )
(아키텍쳐가 정해지면 비기능적 특성이 결정된다)
- Performance (성능) : 중요한 연산은 로컬에서, 통신은 최소화. 작게 모듈화 하기보다는 크게 모듈화(ex. 액정)
( 유지보수에 부담 up )
- Security (보안성) : 계층 구조를 사용하여 중요한 것들은 안쪽으로 넣는다
- Safety (안정성) : 안전이 중요한 특징은 하위 시스템으로 로컬화시킴
- Availabilty (가용성) : 중복된 컴포넌트, 매커니즘을 포함시켜, 장애 허용성(fault tolerance) 매커니즘을 적용해야함
( 시스템이 부분적인 장애 상황에서돋 중복된 컴포넌트(ex. 서버)가 있으면 해당 컴포넌트가 작동하지 않더라도 커버칠 중복된 컴포넌트가 있기에 시스템의 가용성을 유지할 수 있음 )
- Maintainability (유지보수성) : 작게 만들고 대체가능한 컴포넌트를 만들기
Architectural views
Architectural views
- 시스템 구조를 설계화, 문서화할 때 어떤 view or perspective에서 하는 것이 유용한지
- 아키텍쳐 모델을 묘사할 때 어떤 표기방법(notation)을 써야할지
- 각 아키텍쳐 모델은 오직 하나의 view or perspective을 보여줘야한다
4+1 view model of software architecture
· 논리적 관점 : 객체로 시스템의 핵심부분 추상화
· 프로세스 관점 : 런타임에 어떻게 시스템이 구성되고 소통하는지
· 개발 관점 : 소프트웨어가 어떻게 분해되는지
· 물리적 관점 : 시스템 하드웨어와 소프트웨어 컴포넌트가 어떻게 분배되는지
+1 ( 관련된 use case or scenarios )
Architectural patterns
Architectural patterns
- 패턴이란 지식을 표현하고 공유하고 재사용하는 방법을 의미
- 여러 환경에서 시도되고 테스트된 패턴은 좋은 활용의 예라고 여겨진다
- 패턴은 언제 유용하고 유용하지 않은지에 대한 정보를 가지고 있어야함
- 패턴은 표나 다른 시각적 요소 등으로 표현될 수 있다.
1. MVC pattern ( 모델-뷰-컨트롤러 패턴 )
Model - View - Controller 세가지 논리적인 컴포넌트로 구성, 이 컴포넌트들은 서로 상호작용
Model 컴포넌트 : 시스템 데이터와 해당 데이터에 대한 연산을 관리
View 컴포넌트 : 데이터가 사용자에게 어떻게 제시되는지 정의하고 관리
Controller 컴포넌트 : 사용자와의 상호작용 ( ex. keyboard input, mouse click 등 )을 관리하고 이러한 상호작용들은 view 및 model 컴포넌트에 전달
- when used : 데이터를 여러 방식으로 보여주고 상호작용 할 때
- 장점 : model과 view 컴포넌트가 분리되어있기에 데이터와 데이터의 표현방식이 독립적으로 변경될 수 있음, 같은 데이터를 여러 방식으로 표현 및 상호작용할 수 있으며 한 표현방식에서 변경사항이 생기면 다른 표현방식들 모두에도 변경사항이 적용될 수 있음
- 단점 : 데이터 모델과 상호작용이 간단할 때 추가 코드와 코드 복잡성을 유발할 수 있음
( MVC패턴을 사용하면 컴포넌트 간의 인터페이스, 메시지 전달 등을 처리하는 코드가 추가로 필요한데 데이터 모델과 상호작용이 간단한 경우, 이러한 추가 코드와 복잡성이 필요하지 않을 수 있음. 하지만 MVC패턴을 적용하면 추가코드와 코드 복잡성이 유발될 수 있음 )
2. Layered architecture pattern ( 계층화 구조 패턴 )
- 하위(sub) 시스템과의 상호작용을 모델링할 때 사용
- 서비스를 제공하는 여러 계층으로 구성 ( 각 계층은 바로 위의 계층에 서비스를 제공하며 가장 하위 계층은 시스템 전체에 자주 사용되는 핵심 서비스를 제공함 )
- 증분 발전 방식 제공 ( layer interface가 바뀌어도 인접한 계층에만 영향을 끼친다)
- when used: 데이터를 여러 방식으로보여주고 상호작용 할 때
- 장점 : 인터페이스를 유지할 수 있다면 계층은 교체 가능함. 각 계층이 독립적으로 동작할 수 있으므로 중복되는 기능들이 있으면 시스템의 신뢰성이 향상됨.
- 단점 : 실무에서 계층을 깔끔히 분리하기 어려움. 하위 계층을 건너 뛸 수 없어 delay가 걸려 성능이 저하될 수 있음.
3. Repository architecture pattern (저장소 구조 패턴)
- 시스템 내 모든 데이터는 모든 시스템 컴포넌트에 의해 접근될 수 있는 중앙 저장소(central repository)에서 관리됨.
컴포넌트들은 데이터에 직접적으로 접근할 수 없고 오직 저장소를 통해서 데이터에 접근할 수 있음
- sub시스템은 저장소에서 데이터 가져와서 interact
- 하위 시스템이 데이터를 주고 받아야한다
1) 공유 데이터 : 중앙처리방식 (중앙에 요구)
2) 분산 데이터 : 자신만의 데이터 베이스를 가지고 있다
- 많은 데이터가 공유될 때 저장소 모델이 가장 흔히 사용된다
- 진입장벽이 높지만 그 이후부터는 사용하기 편하고 유용함.
- when used: 많은 양의 정보가 생성되고 긴 시간동안 저장될 때, data-driven 시스템에서 사용됨
- 장점 : 컴포넌트들이 독립적일 수 있음. 한 컴포넌트에서 생긴 changes는 다른 컴포넌트들에 전파될 수 있음. 모든 데이터는 한 장소에 저장되어있기에 지속적으로 관리될 수 있음.
- 단점 : 문제가 생기면 전체 시스템에 영향을 줌(단일 장애 지점(signle point of failure)이 될 수 있음 ). 모든 컴포넌트들이 저장소를 통해 상호작용하기에 대량의 데이터를 처리해야할 때 데이터 요청이 많아지므로 비효율적일 수 있음. 여러 컴퓨터를 거쳐 저장소를 분산하는 것은 어려울 수 있음(데이터의 일관성 동기화를 유지하기 위해서는 많은 추가 작업이 필요하기 때문)
// 따라서 안정성, 비효율성, 분산구조의 어려움 등을 고려하여 적절한 패턴을 선택해야함
4. Client-server architecture pattern ( 클라이언트-서버 구조 패턴)
- 데이터와 프로세싱이 여러 컴포넌트에 분산되어있다 ( 하나의 컴퓨터에서 동작될 수 있다 )
- 독립적 서버는 프린팅, 데이터 관리와 같은 특정 서비스를 제공하고
- 위와 같은 서비스들은 클라이언트에 의해 호출되어 사용됨
- 네트워크를 통해 클라이언트는 서버에 접근 가능
- when used: 공유 데이터베이스가 다양한 위치에서 접근되는 경우, 서버를 복제할 수 있기에 시스템 부하가 가변적인 경우
- 장점 : 서버들은 네트워크를 통해 분산될 수 있음. 일반적인 기능들은 모든 client에서 이용가능하고 모든 서비스에서 구현될 필요는 없음. 업데이트 시 서비스를 멈추지 않고 가능함.
- 단점 : 서비스 문제 발생 시 관련된 모든 client에 영향을 줌(단일 장애 지점(signle point of failure)). 성능은 시스템과 네트워크에 따라 예측불가능함. 서버가 다른 조직에게 소유권이 넘어가면 관리 문제가 있을 수 있음.
5. Pipe and filter architecture pattern ( 파이프와 필터 구조 패턴 )
- 일련의 변환 작업을 파이프라인으로 연결하여 입출력 처리하는 방식
- 입력이 들어오면 처리 후 출력하는 기능을 가진다 - 파이프와 필터 모델 (UNIX시스템)
- 변환 작업이 연속적이면 일괄처리 순차 모델임 ( batch sequential model )
- 상호작용하는 시스템에 적절하지 않음
- when used : 데이터를 처리할 때 사용 (입력이 들어오고 과정을 거쳐 출력)
- 장점 : 이해하기 쉽고 변환의 재사용을 지원. 변환작업을 추가함으로써 업그레이드가 바로 이루어짐. 연속적이고 동시적인 시스템으로 구현가능
- 단점 : 입출력의 형식이 동일해야한다 (동일하지 않으면 오버헤드 발생하며 호환되지 않는 데이터 구조를 사용하는 기능 변환은 재사용할 수 없게 될 수 있음 )
Application architecture
Application architecture ( 어플리케이션 아키텍쳐 )
- 조직의 요구를 충족하기위해 설계됨
- 사업들은 공통된 것들이 많기에, 어플리케이션의 요구사항을 반영하는 공통된 아키텍쳐를 갖는 경향이 있음
- 일반적으로, 특정 요구사항에 맞게 기존의 것들을 구성 및 수정하여 만든 개발사항들로 구성된 시스템 유형에 대한 아키텍쳐임
Use of application architectures ( 어플리케이션 아키텍쳐의 사용 )
- 아키텍쳐 설계의 시작점으로 사용됨
- 설계 체크리스트용으로 사용됨
- 개발팀 조직하는데 사용됨
- 컴포넌트 재사용을 평가하는 방식으로 사용됨
- 어플리케이션 유형에 대해 이야기하기 위한 어휘
Examples of application types ( 어플리케이션 유형 예시 )
- 데이터 처리 어플리케이션 (데이터 기반)
- Transaction 처리 어플리케이션(데이터 중심 => 사용자의 요청을 처리하고 시스템 데이터베이스 업데이트) ex) 예약 시스템, E-commerce( 전자상거래 ) 시스템
- 이벤트 처리 시스템
- 언어 처리 시스템 ex) 컴파일러, 명령어 인터프리터
ref) 정보 시스템 구조
- 계층구조로 조직 => 데이터베이스와의 상호작용
사용자 인터페이스, communication, 정보 검색, 시스템 데이터베이스 계층으로 구성
