1. 컴포넌트 기반 개발(Component based development)
1) 개요
(1) 특징
① 컴포넌트는 객체 클래스에 비해 훨씬 추상적(abstract)이며, 독립적으로 서비스를 제공한다고 볼 수 있다.
② 시스템이 서비스가 필요한 경우 컴포넌트를 호출한다. 이때, 호출자는 컴포넌트가 어떻게 구현되었고, 어떠한 식으로 동작하는지에 대해서는 알 필요가 없다.
③ 컴포넌트는 독립적으로 실행 가능한 개체이다. 소스 코드는 제공되지 않기 때문에 재컴파일하는 것은 가능하지 않다.
④ 컴포넌트는 인터페이스를 제공한다. 모든 상호작용은 그 인터페이스를 통해서 이루어지게 된다.
(2) 컴포넌트 인터페이스 (Component interfaces)
◆ 제공 인터페이스(provides interface): 컴포넌트에 의해 제공되는 서비스를 정의한다.
◆ 요구 인터페이스(requires interface): 컴포넌트를 사용하는 시스템이 필요로하는 서비스를 명세한다.
만약 요구 인터페이스가 제공되지 않으면 컴포넌트가 동작하지 않는다.
(3) 메이어(Meyer)의 5 단계 컴포넌트 추상화 수준(levels of abstraction)
① 기능적 추상화(Functional abstraction)
□ 컴포넌트는 수학 함수와 같은 하나의 기능(function)을 구현한다.
□ 제공 인터페이스(provides interface)는 기능(function) 그 자체가 된다.
② 케쥬얼 그루핑(Casual grouping)
□ 컴포넌트는 서로 관련이 있는 데이터 선언이나 함수들을 묶어놓은 것이다.
□ 제공 인터페이스(provides interface)는 그루핑에 속한 모든 개체들의 이름이 된다.
③ 데이터 추상화(Data abstractions)
□ 컴포넌트는 데이터 추상화나 객체지향언어에서의 클래스 등을 나타낸다.
□ 제공 인터페이스(provides interface)는 데이터 추상화(data abstraction)를 생성, 수정, 접근하는 오퍼레이션들(operations)로 구성된다.
④ 클러스터 추상화(Cluster abstractions)
□ 컴포넌트는 함께 동작하는 관련 클래스들의 묶음이다. 이러한 것들을 프레임워크(frameworks)라고도 부른다.
□ 제공 인터페이스(provides interface)는 프레임워크(framework)을 구성하는 모든 객체들의 제공 인터페이스의 조합이다.
⑤ 시스템 추상화(System abstraction)
□ 컴포넌트는 자체적으로 필요한 모든 것을 갖춘 시스템(entire self-contained system)이다.
□ 시스템 수준의 추상화를 COTS(Commercial Off The Shelf)재사용이라고도 한다.
□ 제공 인터페이스는 API(Application Programming Interface)라고 불리운다.
※ API 는 프로그램이 시스템 명령이나 오퍼레이션에 접근할 수 있도록 해주는 인터페이스이다.
(4) 컴포넌트 기반 소프트웨어 공학(CBSE) 프로세스
① 프로세스에 재사용 활동을 포함시킨다.
② 컴포넌트에 맞도록 요구사항이 수정되는 경우도 있다.
③ 프로토타이핑을 만들기 위해 컴포넌트를 스크립트 언어로 조합하기도 한다.
1. Outline system requirements: 시스템 요구사항에 대한 개요를 잡음.
2. Search for reusable components: 재사용 가능한 컴포넌트를 찾음.
3. Modify requirements according to discovered components: 발견한 컴포넌트에 적합하도록 요구사항을 수정함
4. Architectural design: 수정된 요구사항으로 아키텍쳐를 설계함.
5. Search for reusable components: 실제 구현에 사용할 수 있고 적용가능한 컴포넌트를 찾음.
6. Design system using reusable components: 재사용 컴포넌트를 기반으로 시스템을 설계함
※ 시스템 요구사항에 대한 개요를 잡고, 이와 관련하여 재사용 가능한 컴포넌트를 찾는다. 발견한 컴포넌트에 적합하도록 요구사항을 수정한다. 수정된 요구사항으로 아키텍쳐를 설계하고, 실제 구현에 사용할 수 있고 적용가능한 컴포넌트를 찾아서 재사용 컴포넌트를 기반으로 시스템을 설계한다.
2) 어플리케이션 프레임워크(Application frameworks)
객체는 너무 단위가 작고 특정 어플리케이션에 특성화되어 있다. 그렇기 때문에, 보다 큰 단위의 추상화로 프레임워크(frameworks)라는 것을 사용한다.
(1) 프레임워크(frameworks)
① 추상클래스와 구체화된 클래스 및 인터페이스들의 집합으로 구성된 서브 시스템 설계를 프레임워크라고 한다.
② 서브 시스템은 설계의 일부분을 컴포넌트를 추가해서 채우거나 프레임워크상의 추상 클래스를 인스턴스화시킴으로써 구현된다.
(2) 프레임워크(frameworks) 분류
① 시스템 인프라구조 프레임워크(System infrastructure frameworks)
□ 통신(communication), 사용자 인터페이스(user interface), 컴파일러(compiler)와 같은 시스템 인프라구조의 개발을 지원한다.
② 미들웨어 통합 프레임워크(Middleware integration frameworks)
□ 컴포넌트 통신과 정보 교환과 같은 객체 클래스들의 표준으로 구성되어 있다.
□ 예) CORBA, Microsoft 의 COM/DCOM, Java Beans
③ 기업 응용 프레임워크(Enterprise application frameworks)
□ 회계 시스템, 의료정보 시스템 등과 같은 특정 응용 도메인과 관련된다.
□ 응용 도메인 지식(application domain knowledge)과 최종 사용자 응용(end-user applications) 개발을 지원한다.
(3) 프레임워크 확장
① 프레임워크는 보다 세부적인 어플리케이션이나 서브 시스템을 만들기 위해 확장되며, 다음과 관련이 있다.
□ 프레임워크의 추상 클래스로부터 오퍼레이션을 상속받아서 구체화된 클래스를 추가한다.
□ 프레임워크에서 감지되는 이벤트에 대해 필요한 메쏘드(methods)를 추가한다.
② 프레임워크의 문제점
복잡하기 때문에 프레임워크를 효율적으로 사용하는데는 시간이 많이 걸린다.
(4) MVC 프레임워크(Model-View-Controller Frameworks)
① GUI 설계에 대한 시스템 인프라구조 프레임워크이다.
② 객체에 대한 다양한 복수개의 표현(presentation)을 허용하고, 각각의 표현에 대해
③ 독립적인 인터렉션 (interaction)을 제공한다.
④ 패턴(pattern)의 한 종류이며, Observer pattern, Strategy pattern, Composite pattern을 포함한다.
3) COTS 재사용
COTS란 Commercial Off-The-Shelf의 약자로, 데이터베이스 관리 시스템과 같이 API(Application Programming Interface)를 제공합니다. 그렇지만, COTS 시스템 통합에는 다음과 같은 몇 가지 문제점이 있습니다.
(1) COTS 시스템 통합의 문제점
① 기능과 성능에 대한 제어가 자유롭지 않다.
② 서로 다른 COTS 시스템은 통합에 대해서 다른 환경을 가정하였다.
③ 시스템 진화(evolution)에 대한 제어가 어렵다.
④ COTS 제공자로부터 지원이 중단될 수도 있다.
4) 재사용을 위한 컴포넌트 개발
① 컴포넌트는 안정화된 도메인 추상화를 반영해야한다.
□ 예) 은행 시스템에서는 도메인 추상화는 계좌, 입/출금 등이 있고, 병원 경영 시스템에서는 환자, 치료, 간호사 등이 있다.
② 컴포넌트는 상태가 표현되는 방법이 감추어져야 하고, 그 상태를 접근하고 업 데이트 시킬 수 있는 오퍼레이션(operations)이 제공되어야 한다.
□ 예) 은행 계좌를 나타내는 컴포넌트의 경우 계좌의 잔액을 확인하거나 송금하기 등과 관련한 오퍼레이션이 제공되어야 한다.
③ 컴포넌트는 가능한 독립적이어야 한다.
④ 모든 예외상황(exceptions)은 컴포넌트 인터페이스의 일부이어야 한다.
※ 재사용성(reusability)과 사용성(usability)는 Trade-off 관계이다. 즉, 인터페이스가 일반화 될수록 재사용성은 높아지지만, 더욱 복잡해지고 결국 사용성이 떨어지게 된다.
1) 어플리케이션 패밀리의 특성화(Application family specialization)
(1) 플랫폼 특성화(Platform specialization)
① 다른 플랫폼에 대해 다양한 버전의 어플리케이션이 개발된다.
② 어플리케이션의 기능은 거의 변화가 없다.
③ 하드웨어나 운영체제와 인터페이스하는 부분의 컴포넌트가 수정된다.
④ 예: Windows NT, Solaris, Linux 플랫폼
(2) 형상 특성화(Configuration specialization)
① 서로 다른 주변 장치들을 다루기 위해 다양한 어플리케이션 버전이 개발된다.
② 주변 장치와 인터페이스하는 컴포넌트가 수정되며, 장치의 특성에 따라 기능이 다양할 수 있다.
③ 예: 사용되는 전파 시스템에 따라 다양한 버전의 응급 서비스 시스템이 만들어질 수 있다.
(3) 기능 특성화(Functional specialization)
① 고객의 다양한 요구사항을 만족시키기 위해 다양한 버전의 어플리케이션이 개발된다
② 컴포넌트의 기능이 수정되거나 새로운 컴포넌트가 추가될 수 있다.
③ 예: 도서관 자동 시스템의 경우 공용 도서관인지, 참고 도서관인지, 학교 도서관인지에 따라 서로 요구하는 바가 틀릴 수 있다.
2) 어플리케이션 패밀리를 이용해서 새로운 어플리케이션을 개발하는 과정
(1) Elicit stakeholder requirements
- 일반적인 요구사항 공학 프로세스를 기반으로 두고 있다.
- 기존의 패밀리 맴버(family member)를 프로토타입으로 사용한다.
(2) Choose closest-fit family member
- 요구사항이 분석되고, 패밀리 맴버(family member) 중에서 요구사항에 맞추어 수정하기 에 적합한 것이 선택된다.
(3) Renegotiate requirements
- 요구사항이 점점 구체화되면서 기존의 시스템을 많이 변경시킬 우려가 있는 경우에는 이러한 변화를 최소화하기 위한 협상이 필요한 경우도 있다.
(4) Adapt existing system
- 기존 시스템에 대해 추가적인 모듈의 개발 없이 요구사항을 만족시키도록 한다.
(5) Deliver new family member
- 어플리케이션 패밀리의 새로운 맴버가 고객에게 전달된다. 이 과정에서 주요사항들을 꼭 문서화해두어야 한다. 이러한 기록들은 앞으로 다른 시스템의 개발에 필요한 기초자료로 활용될 수 있다.
3. 디자인 패턴(Design patterns)
1) 패턴의 구성
① 이름(Name)
- 패턴을 직관적으로 파악할 수 있을 정도로 의미가 있는 것이어야 한다.
② 문제 기술(Problem description)
- 언제 패턴이 적용될 수 있는지에 대해 설명한다.
③ 해결책에 대한 기술(Solution description)
- 디자인 해결에 대한 관계나 역할들을 기술한다. 구체적인 설계에 대한 것이 아니며 다양한 방법으로 구현될 수 있는 설계 방법에 대한 탬플릿(template)이다.
- 시각적으로 표현되는 경우가 많은데, 객체와 객체 클래스에 대한 관계를 보여준다.
④ 결과(Consequences)
- 결론과 패턴을 사용할때의 장단점에 대해 기술한다.
- 설계자가 어떠한 경우에 패턴을 사용하는 것이 효과적인지 이해할 수 있도록 한다.
[정리하기]
1. 재사용을 통한 설계는 좋은 설계와 기존의 컴포넌트를 활용한다.
2. 저렴한 비용과 빠른 소프트웨어 개발 및 위험이 낮은 것이 재사용의 장점이다.
3. 컴포넌트 기반 소프트웨어공학은 제공 인터페이스와 요구 인터페이스를 가지는 블랙박스 컴포넌트에 기반하고 있다.
4. COTS 제품은 큰 규모의 시스템 재사용에 해당한다.
5. 어플리케이션 패밀리는 공통 핵심부분 개발과 관련된다.
6. 디자인 패턴은 성공적인 설계 방법을 문서화해놓은 고수준의 추상화를 제공한다.
'정보과학 > 소프트웨어공학특론' 카테고리의 다른 글
| 크리티컬 시스템 명세 및 개발 (1) | 2023.11.28 |
|---|---|
| 신뢰성 (1) | 2023.11.28 |
| 실시간 소프트웨어 설계 (2) | 2023.11.26 |
| 분산 시스템 아키텍쳐 (1) | 2023.11.26 |
| 아키텍쳐 설계 (1) | 2023.11.25 |
