[펌] Software Architecture and Framework

Software Architecture and Framework

2007/08/29 08:54

http://blog.naver.com/tothesky21/40041619264

강건한 소프트웨어 아키텍처를 수립하려면 노련한 아키텍트(Architect)를 중심으로 고급기술을 가진 인력들이 상당한 노력과 고통을 감수해야 한다. 

 

먼 저 아키텍트 혹은 요구사항 수집자는 대상 시스템을 둘러싼 이해당사자들의 비기능적, 즉 품질적인 요구사항을 정리한다.  여기에는 ISO에서 정의하는 표준 품질요소를 사용하기도 하지만 다음과 같이 R. Grady가 정의한 FURPS+도 널리 사용된다[R. Grady, 1992]:

 

분류	관련 품질
Functionality(기능성)	Auditing, Authentication, Communication, Debugging, Error Management, Mail, Memory Management, Persistency 등 시스템의 전반에 걸친 기능에 관련된 요구사항으로서 이에 대응하는 Mechanism으로 연계되어 아키텍트에 의해 설계단계부터 표준화된다.
Usability(사용성)	Accessibility(사용 편리성), Aesthetics(미학), Consistency(일관성)
Reliability(신뢰성)	Accuracy(정확성), Availability(가용성), Recoverability(장애복구)
Performance(성능)	Recovery Time(장애복구시간), Response Time(응답시간), Shutdown Time(정지시간), Startup Time(구동시간), Throughput(처리량)
Supportability(지원성)	Adaptability(적응용이성), Compatibility(호환성), Configurability(구성용이성), Installability(설치용이성), Maintainability(유지보수성), Scalability(확장성), Testability(시험용이성)
Design Constraints(설계제약)	기능성에 포함된 내용들에 있어서 메커니즘에 의한 설계전략 시 준수해야 할 제약사항
Implementation Constraints	3rd party components, Language, Platform, Resource Constraints, Existing Standards
Interface Requirements	External Systems, Interface Format

표 1.  FURPS+

필자는 후자를 주로 사용하는데 이는 전자에 비해 좀더 심플하면서 포괄적이기 때문이다.  정리된 품질 시나리오 각각에 우선순위를 부여하면 초기 아키텍처를 정의할 수 있는 사전준비는 된 것이다. 

확정되어진 품질 시나리오를 기반으로 아키텍처 패턴 혹은 스타일을 결정하게 되는데, 객체지향 혹은 컴포넌트 기반의 시스템을 사용하여 재사용과 유연성 및 확장성의 품질적인 요소를 확보하려는 시스템은 대부분 레이어드 아키텍처(Layered Architecture)에 MVC(Model-View-Control)패턴을 채택하게 된다. 

레이어드 아키텍처는 나름대로의 강점이 있는 반면 현명하게 레이어를 분할하는 기준을 정의하기가 어렵고 또한 레이어가 많아질수록 성능이 떨어진다는 단점을 가지고 있어 신중한 결정을 요구한다.  성능상의 단점을 극복하기 위해 변형을 가할 필요도 있지만 이 또한 재능 있는 아키텍트의 결정을 거쳐야 한다. 

 

그림 1.    소프트웨어 아키텍처 예시 – 논리 뷰 개요

이것을 기반으로 각각의 레이어 별로 구성요소들간의 관계를 고려한 파티셔닝(Partitioning)작업을 하게 되는데 아키텍처 스타일의 원칙을 벗어나지 않으면서도 파키션 내의 응집도를 높이고 파티션 간의 결합도를 낮추는 방향으로 정의해야 한다. 

Build, Reuse, or Buy의 의사결정을 해야 하고 구현환경을 고려하여 설계에 필요한 구성요소(컴포넌트, 클래스, 페이지, EJB 등)에 대한 표준을 세운다.  또한 아키텍처적으로 중요한 메커니즘적인 요소에 대한 설계표준을 정립해야 한다. 

이러한 모든 작업들이 끝나면 물리적인 환경으로의 전환과 함께 구현 단위, 배포 단위를 결정해야 하고 이를 시스템 및 네트워크 구성환경을 고려하여 실제 하드웨어 노드 상에서의 최적의 배치를 고민해야 한다. 

 

그림 2.    소프트웨어 아키텍처 예시 – 배치 뷰

이러한 아키텍팅의 과정을 프로젝트를 수행할 때마다 아무것도 없는 상태에서 매번 새롭게 시작해야 한다면 이는 매우 비효율적이다.  따라서 그 동안의 여러 가지 프로젝트의 수행을 통해 이미 조직 내에 존재하는 베스트 프랙티스, 패턴, 프로세스들을 한데 모아 이를 설명하는 모델 및  문서를 중심으로 기반 아키텍처의 표준화를 시도하는 것이 참조 아키텍처(Reference Architecture)이다. 

 

이는 유사한 아키텍처 기반에 대한 조직적인 경험을 담은 것으로 역량 있는 아키텍트를 매 프로젝트마다 투입하여 아키텍처 의사결정(Architectural Decision)을 새롭게 다시 하는 기존방식에서 발전한 단계이다.  따라서 기반 아키텍처의 표준을 제시함으로써 프로젝트마다 고른 품질과 생산성 향상을 도모할 수 있다. 

 

그러나, 프로젝트 현장에서 아키텍트의 존재는 여전히 중요하며 참조 아키텍처는 아키텍처 기반을 수립하는 데 도움을 주게 된다.  프로젝트에서 필요한 모든 아키텍처적인 내용을 현재의 참조 아키텍처가 포함할 수는 없다. 

 

따라서 필요 시 기존 내용을 정제하거나 새로운 내용을 추가해야 하며 이는 기존의 아키텍처를 기반으로 하는 것이 바람직하다