9. 소프트웨어 아키텍처(5-1)

1. 소프트웨어 아키텍처 

소프트웨어 아키텍처의 이해 

건축 설계에 비유 

 설계와 시공에 대한 가이드가 될 큰 밑그림 

 일관적인 모양과 조화를 위한 스타일을 정하는 작업 

개요 

아키텍처 스타일  

구조의 유형 

아키텍처가 중요한 이유 

일단 시스템이 개발된 뒤에는 잘못된 구조를 바로잡기가 쉽지 않음 

범위  

시스템 분할, 전체 제어 흐름, 오류 처리 방침, 

서브시스템 간의 통신 프로토콜을 포함  

소프트웨어 아키텍처 관점 

세 가지 관점 

소프트웨어 아키텍처  

소프트웨어 아키텍처는 포괄적 설계(Global Design)와 동의어 

소프트웨어 아키텍처의 세 가지 주목적 

제삼자(Stakeholder)와의 커뮤니케이션의 표현 수단  1 

조기에 설계를 결정할 수 있음  2 

시스템의 이동 가능한(Transferable) 추상 개념  3 

 아키텍처는 개발 조직에 의해 영향을 받게 됨 

 아키텍처는 그 배경과 조직화된 설계자의 전문지식에 의해 영향을 받음 

 아키텍처는 기술적이고 조직적인 환경의 영향을 받음 

소프트웨어 아키텍처의 정의  

Shaw의 정의 

“소프트웨어 시스템의 아키텍처는 그들 컴포넌트 사이에서의 상호작용과 계산을 요구하는 컴포넌트들에 

의하여 시스템을 정의한다.” 

Bass의 정의 

“소프트웨어 컴포넌트와 외적으로 보이는 그들 컴포넌트들의 속성과 그들 사이의 관계로 이루어진 시스템 

구조이다.” 

디자인 패턴(Design Patterns) 

개요 

 일반성 있는 설계문제를 해결하기 위하여 여러 클래스 사이의 전형적인 협조작업을 패턴화 한 것 

 유용한 추상화를 제공하고, 조합에서 사용되어지는 몇몇 모듈(또는 Object-Oriented Circles, Classes)의 집합 

 표준 문제를 위한 반복되는 해결책 

 패턴의 주요한 예제는, Smalltalk로부터 이미 알려진 MVC(Model-View-Controller) 패턴 

 소프트웨어 아키텍처 스타일 

디자인 패턴(Design Patterns) 

KWIC-INDEX 

ex)    제목은 Software engineering should be a compulsory topic이라고 가정 

 7개의 단어가 있으므로 7개의 행이 필요 

 두 번째 단어 'engineering'은 두 번째 행의 첫 글자가 되어야 함 

- 즉, ‘n번 shift’ 해야 함 

 그 앞에 있던 software는 두 번째 행의 맨 뒤로 빠지게 되는 것

result)    Software engineering should be a compulsory topic. 

Engineering should be a compulsory topic. Software 

should be a compulsory topic. Software engineering  

be a compulsory topic. Software engineering should  

a compulsory topic. Software engineering should be  

compulsory topic. Software engineering should be a  

topic. Software engineering should be a compulsory1 

 이전 라인의 반복은 다른 라인들과 함께 표준사전 편찬상의 순서로 저장되어지고 출력은 KWIC-index로 됨 

 KWIC는 Key Word In Context를 말함 

 제목의 일부분만 알고 있어도 KWIC-index를 사용한다면 제목검색이 쉬워짐 

 위와 같은 문제를 해결하기 위한 SW를 설계할 때, 제일 먼저 맨 위의 단계를 어떻게 분할할 것인가를 결정해야 함 

KWIC-INDEX에 의한 4가지 가능한 아키텍처 

 공유데이터를 사용하는 설계 

 표현(Representation)되는 알고리즘을 변경할 때 정보은폐를 사용하는 차이에 초점을 둠 

 암묵적 호출과 추상데이터 타입을 사용한 분할기법 

 UNIX 파이프와 필터기법을 사용한 분할기법을 설명

아키텍처 스타일의 정의와 종류 

정의 

 아키텍처 요소들을 정리하여 배치한 것 

 스타일은 아키텍처 요소들과 요소들 사이의 정렬방식에 대한 명확한 체계를 표시 

종류 

1. 저장소

2. 클라이언트 / 서버 구조   

3. 계층구조 

4. 파이프 / 필터 구조 

저장소 

구조 

 서브시스템들이 단일 중앙 저장소의 자료를 접근하고 변경  

 서브시스템들은 독립적이고 중앙 자료 저장소를 이용하여 상호 대화  

• 급여 시스템 

• 은행 시스템과 같은 데이터베이스 관리 시스템  

클라이언트 서버 

구조 

서버는 클라이언트에게 서비스를 제공  

서비스의 요구 

 원격 호출 메커니즘 

 CORBA나 Java RMI의 공통 객체 브로커  

클라이언트 

 사용자로부터 입력을 받아 범위를 체크 

 데이터베이스 트랜잭션을 구동하여 필요한 모든 데이터를 수집 

서버 

 트랜잭션을 수행 

 데이터의 일관성을 보장 

계층 

구조 

각 서브 시스템이 하나의 계층이 되어 하위층이 제공하는 서비스를 상위층의 서브시스템이 사용  

추상화의 성질을 잘 이용한 구조  

대표적인 예는 OSI 구조  

장단점 

장점 

 각 층을 필요에 따라 쉽게 변경할 수 있음 

단점

 성능 저하를 가져올 수 있음 

파이프 필터 

구조 

서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업이 반복  

서브시스템을 필터라고 하고 서브시스템 사이의 관계를 파이프라 함 

대표적인 예는 Unix 쉘 

디자인 패턴의 정의 

정의 

특정 문맥 내의 보편적인 설계 문제를 해결하기 위한 컴포넌트들과 의사소통 하는 순환적인 구조 

Recurring Structure 

하나의 완전한 시스템 구조를 나타내지 않는 점에서 아키텍처 스타일과 구별 

디자인 패턴은 하나의 컴포넌트, 모듈 또는 프로시저 그 이상으로 강조 

디자인 패턴의 원형적인 예  

Model-View-Controller(MVC) 패턴 

Interactive Systems은 사용자의 입력을 처리하고 데이터를 보여주는 Computational Elements들로 구성 

I / O를 처리하는 계산요소를 분리해내는 설계를 요소로부터의 분리는 MVC 패턴이 수행 

MVC 

세 가지 컴포넌트를 포함 

모델 

 시스템 데이터와 데이터의 작동들을 캡슐화 

 Model 컴포넌트는 입력이 어떻게 되는지 데이터가 어떻게 표현되는지는 관련이 별로 없음 

뷰 

모델 컴포넌트로부터 얻은 데이터를 보여주며, 하나 이상의 뷰 컴포넌트가 존재할 수 있음 

컨트롤러 

 입력활동(Action)을 제어 

 이런 입력활동은 컨트롤러가 모델에게 요청 

 예를 들면 데이터의 갱신, 그것의 뷰, 스크롤 등 

분리하는 이유 

사용자 인터페이스, 즉 뷰와 제어가 도메인 지식을 나타내는 모델보다는 더 자주 변경될 수 있기 때문 

특징 

MVC는 Smalltalk 환경에서 먼저 사용 

다양한 GUI 플랫폼에서 컨트롤러와 뷰의 차이가 많이 완화된 경우들에 다양성이 적용 

이러한 다양성은 Document–View패턴[KRU96]이라고 불림 

속성 

 패턴은 특정한 설계 상황에서 생기며, 재발하는 문제를 나타내고 그 해결책을 제시 

 패턴은 반대작용(Opposing Forces)과 균형을 유지해야 함 

 패턴이라는 것은 개발되는 것이 아니라 존재하는, 잘 증명된 설계들을 문서화하여 만들어지는 것 

 패턴은 개개의 컴포넌트 레벨 위에서 추상화를 확인하고 명세함 

 패턴은 설계 규칙을 위해 공통적인 어휘와 이해를 제공 

 패턴은 문서화의 하나의 수단  

 패턴은 한정된 속성을 가지고 있는 소프트웨어를 개발하는 것을 지원 

– 반면에, MVC는 상호작용하는 시스템 개발을 위한 스켈레톤을 제공 

– 그러나 MVC는 또한 사용자 인터페이스의 유연성과 변화가능성 같은 비기능적인 요구사항도 제시