프레임워크, 디자인패턴, 아키텍처 스타일의 비교
태그 :
- 개념
- 프레임워크 - 다른 소프트웨어 프로젝트가 개발될 수 있는 뼈대 구조 - 특정 문제 해결을 위해 소스코드로 기본 골격을 만들어 놓은 플랫폼 형태의 소프트웨어 디자인 패턴 - 간단하고 재 활용이 가능한 프로그래밍 솔루션 - 프로그래머들이 유용하다가 생각되는 경험을 활용하여 객체들간의 일반적인 상호작용 방법들을 모은 목록으로 Problem Domain의 최적화된 디자인 - 프로그래머들이 유용하다고 생각되는 경험을 문제 유형별로 구체화하여 동일한 문제 유형에 대한 해결 방법의 일반화한 패턴 아키텍처스타일 - 구조적 조직의 관점에서 시스템 군을 정의함으로써 컴포넌트와 커넥터 유형의 어휘를 정의하고 이들이 결합되는 방식에 대한 제약 조건들 정의 - 소프트웨어의 주요 특징들을 결정짓는 주요 설계구조 - S/W의 구성 요소와 요소간의 인터페이스 그리고 동작방식 등의 특징들을 결정짓는 모든 설계 구조
I. 프레임워크, 디자인패턴, 아키텍처 스타일의 개요
가. 프레임워크, 디자인패턴, 아키텍처 스타일의 정의
|
프레임워크 |
- 다른 소프트웨어 프로젝트가 개발될 수 있는 뼈대 구조 - 특정 문제 해결을 위해 소스코드로 기본 골격을 만들어 놓은 플랫폼 형태의 소프트웨어 |
|
디자인 패턴 |
- 간단하고 재 활용이 가능한 프로그래밍 솔루션 - 프로그래머들이 유용하다가 생각되는 경험을 활용하여 객체들간의 일반적인 상호작용 방법들을 모은 목록으로 Problem Domain의 최적화된 디자인 - 프로그래머들이 유용하다고 생각되는 경험을 문제 유형별로 구체화하여 동일한 문제 유형에 대한 해결 방법의 일반화한 패턴 |
|
아키텍처스타일 |
- 구조적 조직의 관점에서 시스템 군을 정의함으로써 컴포넌트와 커넥터 유형의 어휘를 정의하고 이들이 결합되는 방식에 대한 제약 조건들 정의 - 소프트웨어의 주요 특징들을 결정짓는 주요 설계구조 - S/W의 구성 요소와 요소간의 인터페이스 그리고 동작방식 등의 특징들을 결정짓는 모든 설계 구조 - 아키텍처 설계 시에 요구되는 비 기능 품질 요구사항을 달성할 수 있도록 해 놓은 문서 |
나. 아키텍처 스타일, 디자인패턴, 프레임워크의 특징
|
구분 |
아키텍처스타일 |
디자인패턴 |
프레임워크 |
|
목적 |
전체 시스템의 구조나 설계모형 재사용 |
실제 구현 과정에서 해결방안으로 제시 |
시스템 구현효율성 향상과 개발편의성 제공 |
|
범위 |
모든 종류의 시스템에 적용 가능 |
모든 구현 과정 중 일관된 문제에 적용 |
하나의 시스템을 구축하기 위한 틀 |
|
조건/효과 |
- 구체적인 코드와 함께 요구변경이나 다른 제약 조건 등에 대한 대응 방안이 다름 - 구현경험 이해로 바람직한 아키텍처 설계 가능 - 구조도로써의 이해와 실제 설계작업 중 각 구현상 특징 별 구체적인 코딩방안까지 설계할 수 있어야 함. |
- 유지보수의 용의성, 이해하기 쉬운 코드로 단순화 가능 -문제에 대한 패턴 인식하여, 일치하는 디자인 패턴을 찾아 프로젝트에 적용 -어플리케이션의 확장성 향상, 비즈니스 요구사항 변화에 적시대응 -어떤 문제점에 대한 해결안 찾는 시간과 개발기간 단축 |
- class library로 프로젝트의 일부를 갖고 있음 - 정해진 설계 방식에 따라 실제 코드가 일부 작성, 프레임워크 클래스를 서브 클래싱 해서 유저 코드 작성 - 프레임워크 코드가 유저코드 호출 방식 - 실행 흐름을 프레임워크가 제어 - 객체의 연동은 구조 프레임워크가 정의함 |
II. 프레임워크, 디자인패턴, 아키텍처 스타일의 개념도 및 원칙
가. 프레임워크, 디자인패턴, 아키텍처 스타일의 개념도
1) 아키텍처 스타일의 개념도
- 아키텍처 스타일은 계층적인 구성을 이룸
2) 디자인패턴 개념도
|
패턴이름(Name) |
문제(Problem) |
결과(Consequences) |
|
해법(Solution) |
3) 프레임워크 개념도
|
응용 프로그램 플러그인(사용자 인터페이스- 개발자 영역) |
|
코어서비스 플러그인(디버그 에이전트, GUI 위젯, 커널 등) |
|
시스템 소프트웨어 |
나. 프레임워크, 디자인패턴, 아키텍처 스타일의 구성요소
|
아키텍처 스타일 |
디자인패턴 |
프레임워크 |
|
1) 이름: 아키텍처 스타일 나타내는 이름 2)아키텍처 구성도: 개괄적인 아키텍처 모형 표현 그림 3) 설명: 아키텍처 스타일의 특징 및 장단점 |
1) Name: 설계 의도 표현할 수 있도록 설계문제와 해법 대표 2) Problem: 목적에 해당, 해결하고자 하는 문제와 배경, 언제 패턴을 사용하는지 서술 3) Solution: 패턴을 구성하는 요소, 요소들 간의 관계, 책임 그리고 상호작용 서술 4) 결과(Consequences): 패턴을 적용해서 얻은 결과와 장단점 서술 |
1) 개발자가 작성하는 요소 - 프레임워크에서 제공되는 라이브러리 이용하여 개발자가 작성하는 요소 2) Framework에서 제공된 요소 - 프레임워크에서 제공하는 환경(개발, 실행, 관리, 운영) 등 3) 공통컴포넌트 요소 - 보안, 사용자 지원, 시스템 관리 등의 역할 |
III. 프레임워크, 디자인패턴, 아키텍처 스타일의 원칙
가. 아키텍처 스타일의 원칙
1) 시스템의 특성에 맞는 아키텍처 스타일을 선정
2) 각 스타일의 특성 및 제약사항 들을 검토하고, 시스템의 아키텍처적인 요구사항을 반영할 수 있는지 검토.
3) 적절한 스타일을 선정하고 이를 변형 또는 조정하거나 다른 스타일과 혼용하여 최종 아키텍처 모습을 설계
4) 구체적인 아키텍처의 구현 방법을 설계.
나. 디자인 패턴 설계의 원칙
1) 캡슐화의 원칙: 바뀌는 부분은 캡슐화
2) 상속보다는 구성(Composition)
- 포함관계, 상속으로 클래스를 사용하는 것이 아니라 내부에서 클래스로 객체를 만들어서 사용
- ‘A에는 B가 있다’의 관계로 또 다른 기능을 위임 받아 사용하여 두 개의 클래스가 합쳐짐
3) 구현이 아닌 인터페이스에 맞춰서 프로그래밍: 다형성 활용
4) 가능한 느슨한 결합의 디자인
- 서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인을 사용
- 객체 사이의 상호의존성을 최소화할 수 있음
5) 의존관계 역전 원칙(The Dependency Inversion principle)
- 고차원의 모듈은 저 차원의 모듈에 의존하면 안됨. -- 고차원 모듈과 저 차원 모듈 모두 다른 추상화된 것에 의존 해야 함
- 추상화 된 것은 구체적인 것에 의존하면 안됨. -- 구체적인 것이 추상화된 것에 의존해야 함.
6) 개방 폐쇄 원칙(The Open-closed Principle)
- 확장에 대해서는 개방되고 변경에 대해서는 폐쇄되어야 함.
- 인터페이스를 활용하여 느슨한(Loosely Coupled) 설계
다. 프레임워크 설계의 원칙
1) 의존관계 역전 원칙(The Dependency Inversion principle)
2) 인터페이스 분리 원칙(The Interface Segregation Principle)
- 최대한 작게 인터페이스를 분리
3) 리스코프 치환 원칙(The Liskov Substitution Principle)
- 상속 구조에서 모든 서브 타입은 언제나 기반 타입으로 교체 가능해야 함.
4) 단일 책임 원칙(The Single Responsibility Principle)
- 하나의 클래스의 단 하나의 책임만을 가지도록 함
5) 개방 폐쇄 원칙(The Open-closed Principle)
IV. 프레임워크, 디자인패턴, 아키텍처 스타일의 분류 또는 종류
프레임워크의 분류 – 처리 영역에 따라 분류
|
분류 |
설명 |
메타포 |
|
기능 F/W |
전체 Application의 특정 기능 부분의 구현에 사용되는 프레임 워크 |
DB만 접근 로깅담당 |
|
지원 F/W |
Applicaion안에 포함되지 않고 밖에 포함되는 프레임워크 |
빌드만 담당 |
|
통합 F/W |
여러 기능의 프레임워크를 한 곳에 모아 통합한 프레임워크 |
전자정부 프레임워크 |
디자인 패턴의 분류
|
분류 |
설명 |
사례 |
|
생성패턴 |
객체 인스턴스 생성을 위한 패턴 클래스 정의와 객체 생성 방식을 구조화, 캡슐화 한 방법 제시 |
Factory Method Abstract Factory |
|
구조패턴 |
다른 객체가 협력을 통해 수행하는 역할에 대해 객체를 조직화 하는 방식 클래스 라이브러리를 통합하는데 유용 구현하기 위해 객체를 구성하는 방식 자체에 초점을 맞춤 |
Adaptor Bridge Composit Decorator Fly weghit |
|
행위패턴 |
객체의 행위 조직화, 관리, 연합에 사용 객체간 기능 배분 등의 알고리즘 수행에 주로 이용 객체나 클래스 간의 연동에 대한 유형제시 |
Iterpreater Templet method Command Chaine of Responsibility |
– GOF의 디자인패턴 기준으로 분류함
가. 아키텍처 스타일의 대표적 종류
|
분류 |
설명 |
사례 |
|
Data Centered architectural style |
- 데이타의 무결성(integrity) 보장 - 중앙에 데이타 저장소와 다수의 클라이언트 접속으로 커뮤니케이션 이룸 - 클라이언트는 각각 독립적, 데이타 저장소 또한 클라이언트에 대해 독립적, 클라이언트가 추가될 수 있다는 측면에서 확장성(Scalability)이 높음 |
Blackboard style Repository style |
|
Data-Flow architectural style |
- 데이타 흐름처리 시스템 구조화에 유용 - pipe and filter style의 경우 data는 pipe를 통해서 전송, pipe는 filter 연결 - reusability와 modifiability가 높음 - 반면에 Performance는 매우 낮음 |
pipe and filter style |
|
Call and Return architectural style |
- 대형 소프트웨어 시스템에 주로 사용 - Layered style은 하위 작업 그룹들을 계층구조로 나눌 수 있는 application을 구조화하는데 유용 - 각 계층은 기본적으로 위 아래 계층간 통신 가능 - 여러 추상화 계층이 필요한 시스템에 적합, 한 layer에 대해 여러 구현 방법 제공으로 재사용성이 높아짐. - Layer간의 상, 하위 통신만 가능하므로 안전성을 높일 수 있고 layer간의 확장(scalability)과 수정(modifiability) 가능 |
Layered style |
|
Broker architectural style |
- 분산 소프트웨어 시스템 구조화에 유용 - 컴포넌트를 이용하여 시스템을 구조화, 이 컴포넌트는 상호간의 결합력이 약하고 원격 서비스 호출을 이용하여 다른 컴포넌트와 통신 - Broker 사용하면 컴포넌트 간의 통신을 조정하고 복잡한 컴포넌트간의 통신을 간략화 할 수 있어서 코드의 수성 용이성(modifiability) 높음 |
Broker style |
|
Mode View Controller style |
- 어플리케이션을 세가지 컴포넌트 나눔 - Controller는 비즈니스로직 - Model은 데이터로직 - View는 UI담당으로 사용자 Display 기능 |
MVC style |
- Mary Shaw, Len Bass, POSA의 분류 기반
V. 프레임워크, 디자인패턴, 아키텍처 스타일의 관계
가. 디자인 패턴은 특정 문제에 대해 해결하기 위한 방안을 제시하는 것이고 프레임워크는 여러 가지 문제에 대해 디자인 패턴들을 적용하여 개발.
나. 프레임워크를 설계하고 개발하고자 할 때 사상을 결정해서 작업을 하게 되는데 이 때 프레임워크를 개발하는 핵심적인 사상에 해당하는 부분이 아키텍처 스타일
다. 디자인 패턴과 아키텍처 스타일은 언어에 독립적으로 설계하게 되고 실제로 제품을 만들어야 하는 프레임워크는 전체적인 사상을 결정하는 아키텍처 스타일을 결정하여 특정언어로 개발하고 각 문제에 대하여 디자인 패턴을 적용
VI. 디자인 패턴과 아키텍처 스타일 비교
|
비교항목 |
디자인 패턴 |
아키텍처 |
|
정의 |
- 프로그래머 경험에 의한 객체들간의 일반적인 상호작용 방법들을 모은 목록 |
- 조직의 관점에서 시스템 군을 정의함 |
|
관점 |
- 프로그래머 개발관점 - 경험을 기반으로 모델링 |
- 조직적 구성관점 - 경험을 기반으로 아키텍처 전체 구성 |
|
대표적 종류 |
- MVC모델, Command, Factory, DAO, FACADE |
- 분산 스타일, 파이프와 필터 스타일, 데이터 중심 스타일, 규칙기반 스타일 |
VII. 디자인 패턴과 아키텍처 스타일의 예
|
예 |
개념도 |
설명 |
|
디자인패턴 (DAO) |
|
|
|
아키텍처 스타일 (데이터 중심스타일) |
|
|
VIII. 소프트웨어 설계 구조에 따른 아키텍처와 프레임워크 플랫폼의 비교
|
비교 |
아키텍처 |
프레임워크 |
플랫폼 |
|
정의 |
- 소프트웨어의 주요 특징을 결정짓는 주요 설계 구조 |
- 다른 소프트웨어 프로젝트가 개발될 수 있는 뼈대 구조 |
- 특정 소프트웨어가 실행되는 환경 |
|
특징 |
- 소프트웨어 개발에 영향이 가장 큼 - 구체적인 구현을 포함하지 않음 |
- 라이브러리, 언어, 다른 소프트웨어 구성요소를 역어 주는 역할 |
- 자신만의 실행엔진과 API개발 환경을 제공, - 다른 플랫폼에 부분적 접근 허용가능 |
|
대표적 종류 |
- MVC모델, Command, Factory, DAO, FACADE |
- 닷넷 프레임워크 - 스프링 3.0 |
- Windows O/S - 리눅스 - 자바 런타임 환경(JVM) |
|
포함 관계 |
- 프레임워크, 플랫폼에 독립적 |
- 프레임워크만으로 프로그램이 실행되지 않으므로 플랫폼에 포함 |
- 다층구조로 하위 플랫폼 포함 - 복잡도 증가 |
IX. 개발단계에서의 아키텍처와 프레임워크 관계
|
비교 |
아키텍처 |
프레임워크 |
|
산출물 완료 |
"요구사항분석 -> 시스템요구사항정리-> 개념설계 -> 상세설계 -> 구현" 설계 부분에서 아키텍처 설계가 이루어지고 아키텍처의 내용 중에서 개발자에게 필요한 부분을 정리하여 마든게 프레임워크 |
|
|
활용영역 |
|
|
|
예시 |
|
|
|
장점
|
|
|