1. 시스템 구조화(System structuring)
[아키텍쳐 설계(architectural design) 개요]
■ 아키텍쳐 설계(architectural design)
① 시스템 설계 과정의 초기 단계에 이루어진다.
② 명세(specification)와 설계(design) 과정의 연결고리 역할을 한다.
③ 명세 활동과 병행되어 이루어지기도 한다.
④ 시스템의 주요 구성요소(components)와 통신관계(communication)를 파악하는 작업.
□ 장점
① 프로젝트 참여자 의사소통 수단
② 시스템 분석(특히 비기능적 요구사항의 만족여부를 판단)에 용이
③ 대규모 재사용(Large-scale reuse)이 가능
□ 설계 과정
1. 시스템 구조화(System structuring): 서브 시스템으로 분해하고 이들간의 통신관계를 파악
2. 제어 모델링(Control modeling): 시스템의 다양한 부분의 제어 관계에 대한 모델
3. 모듈 분해(Modular decomposition): 서브 시스템을 다시 세부 모듈로 분해
※ 서브 시스템(sub system)은 다른 서브 시스템에서 제공되는 서비스와는 독립적인 오퍼레이션(operation)을 제공하며, 모듈(module)은 독립성과는 상관없이 다른 구성요소(component)에 필요한 서비스를 제공해주는 시스템 구성요소이다.
■ 아키텍쳐 모델(Architectural models)
① 정적 구조 모델(static structural model): 시스템의 주요 구성요소(component)를 보여줌
② 동적 프로세스 모델(dynamic process model): 실행시 시스템 프로세스의 구성을 보여줌
③ 인터페이스 모델(interface model): 서브 시스템의 인터페이스를 정의함
④ 관계 모델(relationships model): 서브시스템 간의 데이터 흐름 관계를 보여줌
■ 아키텍쳐 속성(Architectural attributes)
① 성능(performance): 서브 시스템 간의 통신(sub-system communication)을 최소화하기 위해 오퍼레이션을 지역화(큰 컴포넌트 몇 개로 중요 오퍼레이션을 지역화 함)
② 보안(security): 계층형 아키텍쳐(layered architecture)를 사용하고 주요한(critical) 요소는 내부 레이어(layer)에 놓는 것이 좋다.
③ 안전성(safety): 안전성이 필요한 컴포넌트는 고립화(isolation)시키는 것이 좋다.
④ 유효성(availability): 아키텍쳐에 컴포넌트를 중복(redundant)시키면 된다. (결함-내성 시스템 아키텍쳐)
⑤ 유지보수성(maintainability): 변경이 용이하게 컴포넌트를 작게(fine-grained), 독립적(self- contained) 으로 만들고, 데이터 공유를 피해야 함.
1) 시스템 구조화(System structuring)
① 전체 시스템을 상호작용하는 서브 시스템(sub-system)으로 분해(decomposition)하는 작업
② 아키텍쳐 설계(architectural design)은 일반적으로 블록 다이어그램(block diagram)으로 표현되며, 시스템 구조의 개요를 보여준다.
③ 세부적인 모델의 경우는 서브 시스템이 어떻게 데이터를 공유하고, 분산되어 있으며, 다른 서브 시스템과의 인터페이스는 어떤식으로 구성되어 있는지에 대한 정보까지 보여준다.
예) 포장 로봇 제어 시스템의 블록 다이어그램
2) 저장소 모델(The Repository model)
서브 시스템은 서로 데이터를 공유해야 하는데, 데이터 교환 방법으로 다음과 같은 2 가지 방법이 있다.
① 공유된 데이터는 모두 중앙 데이터베이스(central database)에 보관되고, 모든 서브
시스템이 이곳에 접근할 수 있다. 이러한 공유된 데이터베이스에 기반한 시스템 모델을 저장소 모델(repository model)이라고 한다.
② 각각의 서브 시스템이 독립적인 데이터베이스를 가지고 동작한다. 서브 시스템들간의 데이터 교환은 메시지(messages)를 통해 이루어진다.
※ 대규모 데이터를 공유하는 경우 대부분의 경우 저장소 모델(repository model)을 사용한다.
저장소 모델(repository model)의 예: CASE toolset 아키텍쳐
□ 장점
① 대규모 데이터를 공유하는데 효율적이다.
② 서브 시스템이 데이터가 생성되는 방법에 독립적이다. 즉, 데이터가 어떻게 생성되는지에 대해 알 필요가 없다.
③ 공유 모델은 저장소 스키마(repository schema)을 통해 쉽게 확장 가능하다.
□ 단점
① 서브 시스템은 저장소 모델에 맞도록 구성되어야 한다. 이러한 이유 때문에 성능이 저하되거나 특정 데이터 모델의 경우 호환이 어려울 수도 있다.
② 데이터 진화(data evolution)가 어려워 데이터 모델의 변경에 비용이 많이 든다.
③ 모든 서브 시스템들에 대해 동일한 정책을 강요한다. (실제로 각각의 서브 시스템은 다양하고 특화된 보안, 백업 등에 대한 정책을 사용할 수 도 있다.)
④ 저장소 데이터를 분산하기 어렵다. ( 데이터 중복이나 불일치의 문제가 발생할 수도 있다.)
3) 클라이언트-서버 모델(The client-server model)
데이터와 처리를 컴포넌트를 사용하여 분산시키는 모델로 다음 3 가지로 구성된다.
1. 프린팅이나 데이터 관리와 같은 특정 서비스를 제공하는 독립형 서버들 (stand-alone servers)의 집합
2. 이러한 서비스를 요청하는 클라이언트들(clients)의 집합
3. 클라이언트가 서버에 접근할 수 있도록 하는 네트워크(Network)
클라이언트-서버 모델의 예: 멀티미디어 라이브러리 시스템의 아키텍쳐
□ 장점
① 데이터의 분산이 용이하다.
② 네트워크 시스템의 효율적 사용이 가능하다.
③ 새로운 서버를 추가하거나 기존의 서버를 업그레이드하기 쉽다.
□ 단점
① 공유된 데이터 모델이 없으며, 데이터의 교환이 비효율적이다.
② 모든 서버가 각각 데이터 관리(백업/ recovery)책임을 가진다.
③ 이름이나 서버가 중앙에 등록되지 않기 때문에 어떠한 종류의 서비스가 있는지 알기 어렵다.
4) 추상 머신 모델(Abstract machine model)
① 서브 시스템의 인터페이스를 모델링하는데 사용된다.
② 시스템을 계층(layer)의 집합으로 구성하고, 각각의 레이어는 서비스를 제공한다.
③ 서브 시스템의 점진적 개발(incremental development)을 지원한다.
④ 특정 계층의 인터페이스(interface)가 변경되는 경우 인접한 계층만 영향을 받는다.
⑤ 실제로 시스템을 계층형 구조로 만들기가 어려우며, 성능 저하가 문제가 되기도 한다.
2. 제어 모델(Control models)
[들어가기]
서브 시스템들간의 제어의 흐름과 관련한 모델이며, 일반적으로 다음의 2 가지 모델이 있다.
1) 중앙 제어(Centralized control)
하나의 서브 시스템이 다른 서브 시스템의 제어에 대한 모든 책임을 지게 된다. 순차적 또는 병행적 처리가 가능한 지에 따라 두 종류가 있다.
□ 호출-응답 모델(The call-return model)
① 서브루틴(subroutine) 계층의 최상위(top)에서 제어가 시작되어 아래쪽으로 전파되어 가는 모델
② 순차적 시스템(sequential system)에 적용
③ 장점 : 제어 흐름에 대한 분석이 용이
④ 단점 : 예외상황(exceptions)에 대한 처리가 어려움.
□ 관리자 모델(The manager model)
① 하나의 시스템 컴포넌트가 다른 시스템의 프로세스를 제어하는 모델
② 순차 또는 병행 시스템(concurrent system)에 적용
③ 시스템 상태 변수를 두고, 계속적으로 루프(loop)를 돌면서 이벤트나 상태 변화를 감시하기 때문에 이벤트 루프 모델(event-loop model)이라고도 함.
④ 상태 변수는 일반적으로 case 문을 사용하여 구현됨.
2) 이벤트 유도 시스템(Event-driven systems)
각각의 서브 시스템이 외부 서브 시스템이나 시스템의 환경으로부터 발생하는 이벤트 반응하여 동작한다.
□ 장점: 시스템 진화(evolution)이 비교적 쉽다.
□ 단점: 서브 시스템은 이벤트의 발생 여부나 언제 발생할지에 대해서는 알 수 없다.
□ 브로드캐스트 모델(Broadcast model)
① 이벤트가 모든 서브 시스템에 전달, 이벤트를 받은 서브 시스템이 그 이벤트를 처리할 수 있는 경우 처리하는 방식으로 동작한다. (processing 오버헤드 큼)
② 네트워크에 물려있는 다른 컴퓨터상의 서브시스템을 통합하는데 효과적이다.
③ 시스템 진화(evolution)가 비교적 쉬움. (이벤트를 생성하는 서브시스템은 그것을 처리하는 서브시스템의 이름과 위치를 알 필요 없음)
④ 서브 시스템은 이벤트의 처리 여부나 처리 시점에 대해서는 알 수 없음.
□ 인터럽트 유도 모델(Interrupt-driven model)
① 이벤트에 대한 반응이 빠르기 때문에 실시간 시스템에 주로 사용된다.
② 인터럽트 처리기(interrupt handler)에 의해 인터럽트가 감지되어 처리를 위해 다른 컴포넌트에 전달된다.
③ 인터럽트 수의 제한으로 시스템 변경이 어려움.
④ 모델을 프로그램(programming)하거나 검증(validation)하기가 어렵다.
3. 모듈 분해(Modular decomposition) [들어가기]
구조적 아키텍쳐(structural architecture)가 설계된 후에는 서브시스템(sub-system)을 모듈(module)로 분해(decomposition)하는 과정이 필요하다. 서브 시스템을 모듈로 분해하는 2 가지 모델에 대해 간략히 살펴보기로 한다.
1) 객체 지향 모델(Object-oriented model)
① 시스템이 통신 가능한 객체들의 집합으로 분해된다.
② 객체들간의 통신을 위해 인터페이스가 잘 정의되어야 한다.
③ 객체 클래스를 찾고, 속성과 오퍼레이션을 찾는 것이 주요 작업이다.
④ 구현되었을 경우 객체는 클래스로부터 생성되며, 객체들의 오퍼레이션을 통제하기 위해 제어 모델(control model)이 사용되기도 한다.
(아래 예에서 Invoice 클래스가 객체간의 상호작용을 조정함)
2) 데이터 흐름 모델(data-flow model)
시스템의 입력 데이터들이 변환 프로세스들을 거쳐 결과 데이터로 변환되는 과정의 기능 모듈들로 분해됨
파이프(pipe) 또는 필터(filter) 모델이라고도 불린다.
상호작용이 중요시 되는 시스템(interactive systems)에는 적합하지 않다.
[ 정리하기 ]
■ 소프트웨어 아키텍쳐는 구조, 제어, 서브 시스템의 분해 모델에 대해 다루는 것이다.
■ 시스템 구조화에 쓰이는 모델로는 저장소 모델(repository model), 클라이언트-서버(client-server model) 등이 있다.
■ 제어 모델(control model)에는 중앙 제어(centralized control)와 이벤트 유도(event-driven) 모델이 있다.
■ 모듈 분해 모델(modular decomposition model)에는 객체 지향 모델(Object-oriented model)과 데이터 흐름 모델(data-flow model)이 포함된다.
'정보과학 > 소프트웨어공학특론' 카테고리의 다른 글
| 실시간 소프트웨어 설계 (2) | 2023.11.26 |
|---|---|
| 분산 시스템 아키텍쳐 (1) | 2023.11.26 |
| 시스템 모델 (1) | 2023.11.25 |
| 요구 공학 프로세스 (2) | 2023.11.25 |
| 소프트웨어 요구사항 (1) | 2023.11.25 |
