Software Architecture and Framework
2007/08/29 08:54
http://blog.naver.com/tothesky21/40041619264
|
분류 |
관련 품질 |
|
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. 소프트웨어 아키텍처 예시 – 배치 뷰
