CBD 7장.pptx
CBD 개발방법론 7장 대본.docx
CBD 개발방법론 7장 발표를 맡게 된 박은진입니다. 발표 시작하겠습니다.
목차입니다. 기술 아키텍처 설계의 목적과 기술 아키텍처 설계 작업 절차인 기술
유즈케이스 정의와 실현, 프레임워크 설계, 배포 모델 설계에 대해 발표를 진행하
겠습니다.
기술 아키텍처 설계의 목적은 사용자의 비기능적인 요구사항 즉, 품질속성으로부터
기술적인 요구사항을 식별하고, 기술적인 요구사항을 시스템에 실현할 수 있는 해결
방안을 도출하는 것입니다. 또한 이들 기술적인 요구사항의 해결 방안 중에서 프로
젝트에서 공통적으로 사용할 프레임 워크를 설계하고 구현하는 작업을 수행하면서
시스템 배포 모델을 정의합니다. 기술 아키텍처 설계 작업에는 기술 유즈케이스 정의,
기술 유즈케이스 실현, 프레임 워크 설계, 배포 모델 설계가 있는데 우선 첫 번째 작업
인 기술 유즈케이스 정의부터 설명드리도록 하겠습니다.
기술 아키텍처를 설계하는 첫 번째 작업에서는 비기능적인 요구사항으로부터 도출
한 품질 속성에서 기술적인 요구사항을 도출하여 정의하는 것을 목표로 합니다. 이
작업에서 도출한 기술적인 요구사항은 기술 유즈케이스를 사용하여 정의하는데 앞
에서(5장) 나온 유즈케이스와 유사하지만, 유즈케이스가 시스템의 기능적인 요구사
항을 정의하는 수단으로 사용한다면 기술 유즈케이스는 시스템의 비기능적인 요구
사항을 정의하는 수단으로 사용합니다. 기술 유즈케이스는 그림과 같이 <<technical>>
스테레오타입을 갖는 유즈케이스로 표현됩니다.
기술 아키텍처를 설계하는 두 번째 작업은 기술 유즈케이스 실현을 통해 품질속
성의 기술적인 요구사항을 실현하는 과정을 정의하는 것입니다. 기술 유즈케이스
실현은 프레임워크를 구성하는 기초 클래스 또는 구현 클래스들의 상호작용이라
는 관점에서 기술적인 요구사항이 어떻게 실현 하는가를 시퀀스 다이어그램으로
표현합니다. 기술 유즈케이스 실현은 다음 그림과 같이 표현합니다.
프레임워크 설계 작업에서는 기술 유즈케이스 실현에서 정의된 메커니즘을 사용
하여 비즈니스 컴포넌트가 실행하는 기반을 구성하는 프레임워크 또는 공통 클래
스를 설계 및 구현합니다. 이 작업의 절차로는 기술 유즈케이스 실현에 참여하는
클래스를 설계하고 프레임워크 설계모델을 정의하며 기술 유즈케이스 실현 클래
스를 구현하여 프레임워크를 생성해야 합니다.
프레임워크 설계 방법에는 크게 화이트박스 프레임워크와 블랙박스 프레임워크
방식이 있습니다. 화이트박스 프레임워크는 주로 상속이나 동적 바인딩과 같은
객체지향 언어의 특징에 의존합니다. 이 방식에서는 프레임워크 기초 클래스를
상속하거나 미리 정의된 후크 메서드를 재정의 함으로써 프레임워크의 기능을
확장하여 사용하게 됩니다. 블랙박스 프레임워크는 객체 합성을 통해 프레임워크
안에 끼워 넣을 수 있는 컴포넌트의 인터페이스를 정의하는 방식을 사용합니다.
이 방식에서는 프레임워크에서 정의한 인터페이스를 실현하는 컴포넌트를 구현
하고 컴포넌트를 프레임워크 안에 통합시킴으로써 프레임워크의 기능을 확장하여
사용합니다.
화이트박스 프레임워크는 애플리케이션 개발자가 프레임워크의 내부 구조를 잘
알고 있어야만 하며, 프레임워크의 클래스 계층도의 세부사항과 밀접하게 결합
되어 있어 유연성이 결여된 시스템을 구축할 가능성이 많아진다는 단점을 갖습니다.
반면에 블랙박스 프레임워크는 상속성보다는 객체 합성이나 위임을 사용하여
구조화 합니다. 따라서 일반적으로 블랙박스 프레임워크가 화이트박스 프레임워크
보다 사용하거나 확장하기 쉽지만 설계하거나 구현하기는 더 어렵습니다.
배포 모델 설계 작업에서는 비기능적인 요구사항에서 도출된 품질 속성을 실현할
수 있는 분산 모델을 설계 합니다. 먼저 설계된 컴포넌트나 어플리케이션을 하나의
다중 프로세서 컴퓨터 상에 배포할 것인지, 또는 여러 서버 컴퓨터 상에 분산 배포할
것인지를 결정 합니다. 만약 여러 서버 컴퓨터 상에 분산 배포할 것을 결정했다면,
시스템의 배포 모델은 가용성, 확장성, 보안, 성능 등의 품질 속성의 요구사항을 충족
시킬 수 있도록 유연성 있게 설계해야 합니다. 이들 품질 속성을 실현하기 위해 고려
해야 할 사항이 있습니다.
티어 분산은 애플리케이션 아키텍처의 각 레이어가 기술 아키텍처의 어떤 티어에
맵핑될 것인지를 결정하는 것에서부터 출발하며 초기 아키텍처 개요 정의에서 생성된
초기 배포 모델을 확장성, 보안 등의 품질 속성을 충족시킬 수 있도록 재정의 합니다.
다음으로 로드 밸런스 클러스터링 인데, 여기서 클러스터란 두 개 이상의 서버가
서로 연결되어 하나의 단일한 가상 컴퓨팅 리소스를 구성하는 것을 의미합니다.
로드 밸런스 클러스터링은 여러 서버가 작업로드를 공유할 수 있도록 구성됩니다.
장애 복구 클러스터링은 클러스터 안에 있는 하나의 서버가 사용할 수 없게 된 경우에
다른 서버가 자동적으로 실패한 서버의 작업을 넘겨받아 처리를 계속할 수 있도록
구성됩니다. 따라서 장애 복구 클러스터링은 하나의 활성 서버와 적어도 하나이상의
대기서버를 포함해야 합니다. 트러스터 영역 또는 보안영역은 방화벽에 의해 묶여 있어
제한된 커뮤니케이션 프로토콜만 허용되는 보호된 컴퓨터의 네트워크입니다. 이 영역은
코드와 데이터의 안전을 위협할 수 있는 외부로부터의 공격에 대응하는 장벽 또는 경계를
나타냅니다. 위의 네 가지를 잘 고려해서 품질 속성을 실현하는 것이 바람직합니다.
설계 전략 정의활동에서는 설계자와 개발자가 각각 설계 단계와 구현단계에서 사용할
설계 메커니즘과 구현 메커니즘을 정의하는 작업을 수행합니다. 아키텍처 프로토타이핑
활동에서는 아키텍처를 정의한 아키텍처 팀이 프로토타이핑을 수행합으로써 설계한
아키텍처를 검증합니다. 이 활동의 작업 세부 사항은 설계, 구현, 테스트 단계에서
정의한 절차를 따르며, 프로토타이핑의 결과를 소프트웨어 아키텍처 정의서, 비즈니스
컴포넌트 설계서, 사용자 인터페이스 정의서, 데이터 베이스 설계서, 메커니즘 기술서
등에 반영합니다.
참고문헌은 다음과 같습니다.
이상으로 CBD개발방법론 발표를 마치겠습니다.