[24기 민경빈] CBD 개발방법론 아키텍처 설계 II

[24기 민경빈]

7.1기술 아키텍쳐 설계

기술아키텍쳐 설계의 목적은 사용자의 비기능적인 요구사항 즉. 품질속성으로부터 기술적인 요구사항을 식별하고, 기술적인 요구사항을 시스템에 실현할 수 있는 해결 방안을 도출한다. 또한 . 이들 기술적인 요구사항의 해결 방안중에서 프로젝트에 공통적으로 사용할 프레임 워크를 설계하고 구현하는 작업을 수행하며 시스템 배포 모델을 정의 한다.

기술 아키텍처 설계 작업에는 기술 유스케이스 정의, 기술 유스케이스 실현, 프레임워크설계

배포모델 설계가 있다.

7.1.1 기술 유스케이스 정의

기술 아키텍처를 설계하는 첫 번째 작업에서는 비기능적인 요구사항 품질 속성으로부터 기술적인 요구사항을 도출하고 정의하는 것을 목표로 한다. 이 작업에서 도출된 기술적인 요구사항은 기술 유스케이스를 사용하여 정의한다. 3장 요구 파악에서 강의들은 유스케이스와 유사하나

유스케이스가 기능적인 요구사항을 정의하는 수단으로 사용된다면, 기술 유스케이스는 시스템의 비기능적인 요구사항을 정의하는 수단으로 사용된다. (굳이 액터를 가질 필요가 없다)

기술 유스케이스는 다음과 같이 스테레오 타입을 갖는 유스케이스로 표현 된다.

7.1.2기술 유스케이스 실현

기술 유스케이스 실현 생성

기술 아키텍처를 설계하는 두번째 작업은 기술 유즈케이스 실현을 통해 기술적인 요구사항을 실현하는 과정을 정의한 것이다. 기술 유스케이스 실현은 솔루션 개체 사이의 상호 작용이란 관점에서 기술적인 요구사항이 어떻게 실현되는가를 시퀀스 다이어그램으로 표현한다.

여기에서 솔루션개체란 분석 클래스라기보다는 프레임워크를 구성하는 기초 클래스 또는 구현클래스로 표현한다.

기술 유스케이스 실현

MicroSoft Applcation Block for .NET 활용

기술 유스케이스 실현을 생성할 때 기존의 솔루션을 적극적으로 활용 하는 것이 바람직하다.

M/S 는 닷넷 프레임 워크를 확장하는 여러 MicroSoft Applcation Block for .NET을 제공하고 있다. 이를 이용하여 애플리케이션 블록을 기술 유스케이스 실현에 사용할 수 있다. 애플리케이션 블록은 각각이 독립적인 프레임 워크 이면서, 동시에 이들 애플리케이션 블록을 결함합으로써 더 큰 하나의 프레임 워크를 구성할 수 있다.

7.1.3 프레임워크 설계

프레임워크 설계 작업에서는 기술 유즈케이스 실현에서 정의된 메커니즘을 사용하여 비즈니스 컴포넌트가 실행되는 기반을 구성하는 프레임워크 또는 공통 클래스 설계를 구현한다.

절차로는 기술 유즈케이스 실현에 참여하는 클래스를 설계하고 프레임워크 설계모델을 정의하며 기술 유즈케이스 실현 클래스를 구현하여 프레임워크를 생성한다.

프레임워크 설계 방법에는 크게 두가지 접근 방식이 있다. 그 하나는 화이트 박스 프레임워크 방식이고 다른 하나는 블랙박스 프레임워크 방식이다.

화이트박스 프레임워크는 주로 상속이나 동적 바인딩과 같은 개체지향 언어의 특징에 의존한다.

이 방식에서는 프레임워크 기초 클래스를 상속하거나 템플릿 메서드와 같은 디자인 패턴을 사용하여 미리 정의된 후크 메서드를 재정의함으로써 프레임워크의 기능을 확장하여 사용하게 된다.

이에 대하여 블랙박스 프레임워크는 개체 합성을 통하여 프레임워크 안에 끼워 넣을 수 있는 컴포넌트의 인터페이스를 정의하는 방식을 사용한다. 이 방식에서는 프레임워크에서 정의한 인터페이스를 실현하는 컴포넌트를 구현하고 스트레티지(전략 패턴)을 사용하여 이들 컴포넌트를 프레임워크 안에 통합시킴으로써 프레임워크의 기능을 확장하여 사용하게 된다.

.화이트박스 프레임워크는 애플리케이션 개발자가 프레임워크의 내부 구조를 잘 알고 있어야만 하며, 프레임워크의 클래스 계층도의 세부사항과 밀접하게 결합되어 있는 유연성이 결여된 시스템을 구축할 가능성이 많아진다는 단점

.반면 블랙박스 프레임워크는 상속성보다는 개체 합성이나 위임을 사용하여 구조화 된다.

따라서 일반적으로 블랙박스 프레임워크가 화이트박스 프레임워크보다 사용하거나 확장하기 쉽지만 설계하거나 구현하기는 더 어렵다.

7.1.4 배포 모델 설계

배포 모델 설계 작업에서는 도출된 품질 속성을 실현할 수 있는 분산 모델을 설계 한다 . 먼저 설계된 컴포넌트나 어플리케이션을 하나의 다중 프로세서 컴퓨터 상에 배포할 것인지, 또는 여러 서버 컴퓨터 상에 분산 배포 할 것인지를 결정한다. 만약 여러 서버 컴퓨터 상에 분산 배포할 것을 결정했다면, 시스템의 배포 모델은 기용성, 확장성, 보안, 성능 등의 품질 속성의 요구사항을 충족 시킬 수 있도록 유연성 있게 설계되어야 한다.

품질 속성을 실현하기 위하여 고려 할 사항이 있다.

티어 분산은

어플리케이션 아키텍처의 각 레이어가 기술 아키텍처의 어떤 티어에 맵핑될 것인지를 결정하는 것에서부터 출발하며 초기 아키텍쳐 개요 정의 활동에서 생성된 초기 배포 모델을 확장성 보안 등의 품질 속성을 충족 시킬 수 있도록 재정의 한다.

(로드밸런스 클러스터링, 장애복구 클러스터링) 클러스터링

여기서 클러스터 란 하나의 통합된 컴퓨팅 리소스로 사용되는 상호 연결된 전체 컴퓨터들로 구성된 병렬식 혹은 분산형 시스템을 말한다.

즉 두 개 이상의 서버가 서로 연결되어 하나의 단일한 가상 컴퓨팅 리소스를 구성하는 것을 의미한다.

로드밸런스 클러스팅

- 여러 서버가 작업로드를 공유할 수 있도록 구성된다.

장애 복구 클러스팅

- 클러스터 안에 있는 하나의 서버가 사용할 수 없게 된 경우에 다른 서버가 자동적으로 실패한 서버의 작업을 넘겨받아 처리를 계속할 수 있도록 구성된다. 따라서 이는 하나의 활성 서버와 하나이상의 대기서버를 포함해야한다.

방화벽과 트러스트 영역은

트러스트 영역 또는 보안영역은 방화벽에 의해 묶여 있어 제한된 커뮤니케이션 프로토콜만 허용되는 보호된 컴퓨터의 네트워크 이다.

이 영역은 코드와 데이터의 안전을 위협할 수 있는 외부로부터의 공격에 대응하는 장벽 또는 경계를 나타낸다.

7.2 데이터 베이스 설계

데이터 베이스 설계 활동에서는 지속성을 요구하는 데이터의 논리 및 물리 모델을정의 하는 작업을 수행하며, 이 활동에서 산출되는 논리 데이터 모델과 물리 데이터 모델은 데이터 아키텍쳐를 구성하는 요소가 된다.

7.2.1 논리 데이터 모델설계

비즈니스 객체 모델을 기반으로 , 이중 지속성 처리를 요구하는 객체를 대상으로 하여 정규화 과정을 수행하여 논리 데이터 모델을 구성하는 작업을 수행한다.

1. 비즈니스 객체 모델에서 지속성 처리를 요구하는 비즈니스 객체를 식별하고 엔터티로 정의한다.

엔터티 정의

엔터티는 데이터가 수집되고 저장되는 것을 말한다. 엔터티는 물리 데이터 모델에서 테이블로 정의 되며, 엔터티의 인스턴스는 테이블의 로우로서 저장된다.

비즈니스 객체 모델에서 지속성 처리를 요구하는 비즈니스 객체를 식별함으로써 엔터티를 정의 할 수 있다.

2. 비즈니스 객체 모델을 참조하여 엔터티 사이의 관계를 식별한다.

엔터티 관계 식별

비즈니스 객체 모델을 참조하여 엔터티 사이의 관계를 식별한다. 이때 기수성과 선택성도 함께 표현한다. 기수성이란 관계를 맺는 각 엔터티에 허용되는 엔터티 인스턴스의 개수를 지정하는 것이며, 일반적으로 기수성에는  세 가지 유형이 있다.

1대 1 - 엔터티의 하나의 인스턴스가 다른 엔터티의 하나의 인스턴스와 관계를 갖는다.

1 대 다 - 엔터티의 하나의 인스턴스가 다른 엔터티의 0개 이상의 인스턴스와 관계를 갖는다.

다 대 다 - 엔터티의 하나 이상의 인스턴스가 다른 엔터티의 하나 이상의 인스턴스와 관계를 갖는다.

3. 각 엔터티에서 기본키와 외래키를 식별한다.

키식별

키는 데이터 모델에서 엔터티의 각 인스턴스에 부여되는 값을 식별하게 하며, 또한 엔터티를 서로 묶어주는 메커니즘을 제공한다.

데이터베이스 논리 설계에서 물리 설계로 이동할 때 키를 사용하여 데이터 모델 안에 있는 엔터티의 각 인스턴스를 유일하게 식별할 수 있으며, 부모 엔터티 테이블의 키를 자식 엔터티 테이블에 추가함으로써 공통키 값으로 두 엔터티를 묶을 수 있다.

기본키 - 엔터티 인스턴스를 유일하게 식별할 수 있는 값을 갖는 속성이다. 따라서 키본키 값은 엔터티의 모든 인스턴스에대하여 유일해야만 한다.

그렇지 않으면 킷값을 사용하여 엔터티의 어 하나의 인스턴스를 식별할 수 없게 된다.

외래키 - 자식 엔터티 안에 존재하며 대응되는 부모 엔터티와의 관계를 형성하는값이다. 부모엔터티는 적절한 외래키로 자식 엔터티의 인스턴스를 검색함으로ㅆ 관련된 모든 자식 엔터티를 찾을 수 있다.

4. 정규화를 수행한다.

정규화 과정

데이터 베이스에서 중복된 데이터를 제거하도록 논리 모델을 정제하는 과정이다. 일반적으로 정규화는 데이터 베이스를 여러 개의 테이블로 분할하고, 이들 테이블 사이의 관계를 정의하는 과정을 포함한다.

7.2.2 물리 데이터 모델 설계

설계된 논리 데이터 모델은 선택된 관계형 데이터 베이스에 적합한 물리적인 데이터 모델로 설계 및 구현 되어야 한다.

물리 데이터 모델 섥{ 작업의 절차

1. 논리 데이터 모델을 물리 데이터 모델로 전환시킨다

2. 데이터 최적화를 수행한다.

3. 데이터 무결성을 설계한다.

물리 데이터 모델로의 전환

논리 데이터 모델의 엔터티와 속성을 각각 물리 데이터 모델의 테이블과 컬럼으로 맵핑 시키고, 1:1 관계와 다 대 다 관계를 해소시키는 작업 들이 포함된다.

먼저 논리 데이터 모델의 엔터티를 물리 데이터 모델의 테이블로 맵핑시킨다. 또한 논리 데이터 모델의 속성은 물리 데이터 모델의 컬럼으로 맵핑시킨다. 그 다음에는 논리 데이터 모델의 1대 1관계와 다대 다 관계를 구현하는 작업을 수행한다. 1:1 관계인 경우 만일 두 엔터티 관계가 필수라면 하나의 테이블로 통합을 하던지 두 개의 테이블로 유지를 하는 방법으로 표현 할 수 있습니다.

하나의 테이블 - 분리된 테이블을 관리할 필요가 없어 오버헤드가 줄고 저장영역을 효율적으로 활용할 수 있게 된다.

두 개의 테이블 - 엔터티 사이에는 부모 -자식관계가 이루어지며 부모 엔터티는 자식 엔터티를 소유하기 때문에 부모 엔터티 안에 외래키로서 자식 엔터티의 기본키를 추가해야 한다. 이것은 한 엔터티의 각 인스턴스가 다른 엔터티의 오직 하나의 인스턴스만 관계를 가질 수 있게 한다.

만약 두 엔터티의 관계가 선택이라면 부모 엔터티가 자식 엔터티의 관련된 인스터스가 없어도 존재할 수 있다는 의미이므로, 각 엔터티를 각각의 테이블로 생성하고 외래키를 사용하여 관계를 구현해야한다.

테이블 사이에 다대 다관계가 있다면 이 관계를 분석하여 중간적인 새로운 교차 테이블을 식별하여 이 테이블과 두 개의 1대 다 관계로 해소해야한다.

데이터 최적화

데이터 최적화의 목적은 각 질의(쿼리)에 대하여 응답 시간을 최소화하고, 네트워크 트래픽이나 디스크 입출력, 프로세서 시간 등을 최소함으로써 전체 데이터베이스 서버의 처리량을 최대화하는 것이다.

데이터 생성 최적화

데이터 추출 최적화

데이터 갱신 최적화

데이터 삭제 최적화

데이터 무결성 설계

데이터의 일관성과 정확성을 말한다. 데이터 베이스 설계에서 중요한 작업 중의 하나가 바로 이러한 무결성을 어떻게 보장할 것인가를 결정하는 것이다.

데이터 무결성은 3가지 유형으로 구분된다

도메인 무결성

-칼럼에 대하여 정확한 데이터 값의 범위를 지정하며, 널 값이 허용되는지 여부를 결정한다.

엔터티 무결성

-테이블에 있는 모든 로우가 유일한 식별자 즉, 기본키 값을 가질 것을 요구한다.

참조 무결성

-부모테이블의 기본키와 자식 테이블의 외래키 사이의 관계가 항상 유지된다는 것을 보장한다.

7장 아키텍쳐.pptx