CHAPTER 4: A TECHNIQUE FOR ARCHITECTURE AND DESIGN(2)


CHAPTER 4: A TECHNIQUE FOR ARCHITECTURE AND DESIGN(1)에 이어서

Identify Architecture Objectives

아키텍처 목표는 (1) 당신의 아키텍처와 설계 프로세스를 형성하는 목표와 제약조건이고 (2) exercise의 범위를 정하는 것이고 (3) 당신이 끝났을 때 당신이 결정하는 것을 돕는 것이다. 당신의 아키텍처 목표들을 식별하려고 할 때 다음의 핵심사항들을 고려하라.

  • 처음에 당신의 아키텍처 목표를 식별하라. 당신이 아키텍처 및 설계의 각각의 단계에서 소비하는 시간의 양은 이 목표들에 의존적일 것이다. 예를 들어 당신은 신규 어플리케이션을 위해 프로토타입을 만들고, 잠재적 경로를 시험하고, 혹은 오랫동안 동작하는 아키텍처적 프로세스를 착수하는가?
  • 누가 당신의 아키텍처를 사용할 것인지를 식별하라. 당신의 설계가 다른 아키텍트에 의해 사용될 것인지, 혹은 개발자나 테스터, 운영 스탭, 관리에게 사용 가능하도록 만들어질 것인지를 결정하라.
  • 당신의 제약사항을 식별하라. 당신의 기술적 옵션들과 제약사항, 사용 제약사항, deployment제약사항을 이해하라. 처음에 당신의 제약사항을 이해하여 시간을 낭비하지 않도록 하거나 나중에 어플리케이션 개발 프로세스의 뒤 부분에서 돌발상황을 마주치지 않도록 하라.

Scope and Time

당신의 아키텍처에 대한 고 수준 목표를 기반으로 하여, 당신의 설계 활동의 각각에 대한 소비해야 하는 시간의 양의 범위를 정할 수 있다. 예를 들면, prototype은 설계하기 위해 며칠이 필요한 반면, 복잡한 어플리케이션에 대한 완전하고 상세한 아키텍처는 수 개월이 걸릴 것이다.- 그리고 수 차례 반복하는 아키텍처 및 설계를 포함할 것이다. (1) 얼마나 많은 시간과 에너지를 각각의 스텝에서 소비할 것인지를 결정하기 위해 (2) 결과가 어떻게 보일지 이해하기 위해, (3) 당신의 아키텍처에서 목적과 우선순위를 명확하게 정의하기 위해 목표를 잘 이해하라.

가능한 제안들은 다음을 포함할 수 있다:

  • 완전한 어플리케이션 설계를 생성하기
  • 프로토타입을 구축하기
  • 핵심적인 기술적 리스크를 식별하기
  • 잠재적 옵션들을 시험하기
  • 시스템의 이해를 획득하기 위한 공유모델들을 구축하기

이들 각각은 설계의 다른 부분들을 강조한 결과들이고 시간에 따라 다를 수 있다. 예를 들어 만약 당신이 인증(authentication)아키텍처에서 핵심적인 리스크를 식별하길 원한다면, 많은 시간과 에너지를 들여서 인증 시나리오, 당신의 인증 아키텍처의 제약사항, 그리고 가능한 인증 기술 선택들을 식별하려고 할 것이다. 하지만, 당신이 만약 어플리케이션의 초기 단계에서 있다면, 인증은 여러 가지 해결해야 하는 것들 중에 하나일 것이다.

아키텍처 활동들의 몇몇 사례는 웹 어플리케이션을 위한 order processing UI의 피드백을 얻기 위해 프로토타입을 구축하거나 결과들을 검색하기 위해 위치 정보를 매핑하는 다른 방법으로의 시험, 보안 검토를 수행하기 위한 어플리케이션에 대한 인증 설계 및 인증 아키텍처 등이 있을 수 있다.

Key Scenarios

아키텍처와 설계의 맥락에서, 유즈 케이스는 시스템과 하나 이상의 액터(유저 혹은 다른 시스템)간의 일련의 상호작용의 기술이다. 시나리오는 유즈케이스를 통한 경로라기 보다는 광범위하고 보다 확장적인 시스템 내의 사용자의 상호작용에 대한 기술이다. 시스템의 아키텍처에 대해 생각할 때 목표는 당신의 아키텍처에 대한 결정을 내리는데 도움이 되는 몇가지 핵심 시나리오를 식별하는 거이 되어야 한다. 목표는 사용자, 비즈니스, 시스템 목표(1장 그림1에 보인 바와 같이 “아키텍처는 무엇인가?)간에 균형을 달성하는 것이다.

핵심 시나리오는 당신의 어플리케이션의 성공을 위한 가장 중요한 요소이다. 핵심 시나리오는 1개 혹은 그 이상의 다음의 기준을 만족시키는 시나리오로 정의될 수 있다.

  • 이슈를 표현한다. – 중요한 미지의 영역 혹은 중요한 리스크 영역
  • 아키텍처적으로 중요한 유즈케이스를 언급한다(다음에 이어지는 섹션에 기술됨)
  • 품질 속성과 기능이 서로 상충되는 부분을 표현한다.
  • 품질 속성간의 tradeoff를 표현한다.

예를 들어서, 사용자 인증을 커버하는 당신의 시나리오가 핵심적 시나리오가 될 수 있는데, 그 이유는 품질 속성(보안)과 중요한 기능(어떻게 유저가 시스템 내부에 로그를 남길 것인가)과 상충되기 때문이다. 또 다른 예는 익숙하지 않거나 새로운 기술이 중심이 된 시나리오가 될 수 있다.

Architecturally Significant Use Cases

아키텍처적으로 중요한 유즈케이스는 당신의 설계에 여러가지 관점에서 영향을 미친다. 이러한 유즈케이스들은 특별히 당신의 어플리케이션의 성공을 결정짓는데 중요하다. deploy된 어플리케이션의 인수를 위한 중요한 것들이 있으며 아키텍처를 평가하는데 유용한 설계의 충분함을 평가하는 것들이 있다. 아키텍처적으로 중요한 유즈케이스들은:

  • 비즈니스에 중요함. 유즈케이스는 높은 사용 수준이거나 다른 기능들과 비교했을 때 부분적으로 사용자 혹은 이해관계자에게 중요하며 그렇지 않으면 높은 리스크를 초래한다.
  • 중대한 영향. 유즈케이스는 기능 및 품질 속성을 intersect하거나 계층을 넘어 당신의 어플리케이션의 tier까지 end-to-end 영향을 가진다. 사례가 보안에 민감한 CRUD가 될 것이다.

당신의 어플리케이션을 위한 아키텍처적으로 중요한 유즈케이스를 선택한 후에, 당신은 그것들을 아키텍처의 후보의 성공 혹은 실패를 평가하기 위한 수단으로 사용할 수 있다. 만약 그 후보들이 더 많은 유즈케이스를 나타내거나 기존의 유즈케이스가 더욱 효과적이 되도록 한다면, 그것은 후보 아키텍처가 베이스라인 아키텍처보다 더 나음을 보여주는데 도움이 될 수 있다. 유즈케이스의 용어에 대한 정의는 아래 site에서 “what is use case?”를 참조한다. http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci334062,00.html

좋은 유즈케이스는 아키텍처의 사용과 뷰, 시스템 뷰, 비즈니스 뷰를 포함한다. 당신의 설계를 시험하기 위한 이런 시나리오들과 유즈케이스를 사용하여 어디세 이슈들이 존재하는지를 결정하라. 당신의 유즈케이스와 시나리오에 대해 생각할 때 다음의 사항들을 고려하라.

  • 프로젝트 초반에 아키텍처의 모든 계층을 exercise하는 아키텍처적으로 중요한 end-to-end시나리오를 지원하는 후보 아키텍처를 생성함으로써 risk를 줄여라.
  • 당신의 아키텍처 모델을 가이드로서 사용하고 아키텍처, 설계, 코드가 당신의 시나리오, 기능 요구사항, 기술적 요구사항, 품질 속성, 제약사항에 맞도록 변경하라.
  • 그 시점에 당신이 알고있는 것을 기반으로 아키텍처 모델을 생성하고 이후의 스토리와 이터레이션에서 해결되어야만 하는 질문들의 리스트를 정의하라.
  • 아키텍처와 설계에서 충분히 중요한 변화들을 만든 이후, 이러한 변화를 반영하고 exercise할 수 있는 유즈케이스를 생성하는 것을 고려하라.
Advertisements

“CHAPTER 4: A TECHNIQUE FOR ARCHITECTURE AND DESIGN(2)”에 대한 2개의 생각

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중