RUP Core workflows[4] 분석 & 설계 웍플로우

가) 목적

   분석 & 설계 웍플로우의 목표는 요구사항으로부터 시스템을 구현하는 방법을 기술하는 사양(specification)을 추출하는 데 있다. 이를 위해서는 우선 요구사항을 이해하고 최적의 구현 전략을 선택함으로써 요구사항을 시스템 설계로 변환하여야 한다. 이해하기 쉽고 구축하기 쉽고 발전시키기 쉬운 시스템을 설계하기 위해서는 먼저 프로젝트의 초기단계에서 건실한 아키텍쳐를 설정해야 한다. 그런 다음 설계를 구현환경에 알맞게 수정하는 작업이 이루어져야 한다. 이 과정에서는 성능, 안정성, 확장성, 테스트 가능성 등에 대해 고려해야 한다.

나) 작업자와 산출물

분석 & 설계 웍플로우의 작업자와 산출물의 관계

   분석 & 설계 웍플로우의 주요 작업자는 다음과 같다.

• 아키텍트(Architect) : 아키텍트는 프로젝트기간동안 기술적인 액티비티 및 산출물에 관련된 작업을 주도하고 또한 필요에 따라 조정하는 일을 담당한다. 아키텍트는 아키텍쳐의 관점에서 전체적인 구조를 설정한다. 다른 작업자와는 달리 아키텍트의 관점은 깊이보다는 넓이에 주안점을 둔다.
• 설계자(Designer) : 설계자는 클래스의 책임(responsibilities), 연산(operations), 속성(attributes)과 클래스간의 관계(relationships)를 정의하고 구현 환경에서 어떻게 적용될 것인가를 결정한다. 이외에도 설계자는 패키지나 서브시스템(subsystem)을 설계할 책임을 갖는다.

   이외에도 분석 & 설계 웍플로우에는 다음과 같은 작업자가 있을 수 있다.

• 데이터베이스 설계자(Database Designer) : 설계하는 시스템이 데이터베이스를 포함할 때 필요하다.
• 아키텍쳐 검토 담당자(Architect Reviewer) 및 설계 검토 담당자(Design Reviewer) : 분석 & 설계 웍플로우의 주요 산출물을 검토한다.

   분석 & 설계 웍플로우의 주요 산출물에는 다음과 같은 것이 있다.

• 설계 모델(Design Model) : 구축할 시스템의 주요한 청사진
• 소프트웨어 아키텍쳐 문서(Software Architecture Document) : 시스템을 아키텍쳐의 관점에서 기술한 문서

다) 웍플로우

   앞의 그림은 전형적인 분석 & 설계 웍플로우이다. 분석 & 설계 웍플로우에는 두 개의 상세 웍플로우가 상호 관련되어 있다. 이중 하나는 아키텍쳐에 관련된 것이고 다른 하나는 클래스와 서브시스템(subsystem)의 상세 설계에 관련된 것이다.

   먼저 아키텍쳐 관점에서 웍플로우를 살펴보면 제일 먼저 아키텍쳐 분석 액티비티를 통해 아키텍트는 아키텍쳐가 어떻게 조직되는가를 정의한다. 이 과정에서 아키텍트는 시스템을 위한 모델링 협약(convention), 주요 매커니즘, 기본적인 아키텍쳐상의 패턴을 식별한다. 예를 들어 아키텍트는 계층화(layering) 원칙, 서브시스템을 조직하는 원칙, 재사용 전략 등을 정의한다. 아키텍쳐 분석은 프로세스 계획을 위해서 반드시 필요하다.

   다음으로 충분하게 유스 케이스 분석이 수행되면 결과로 생성된 클래스를 아키텍쳐 설계 액티비티에서 사용한다. 아키텍쳐 관점에서 중요한 클래스를 식별하고 설계 패키지나 서브시스템으로 그룹화하는 일도 수행한다. 그런 다음 서브시스템을 알맞은 계층으로 조직화한다. 병행성 기술(Describe Concurrency) 액티비티는 아키텍쳐를 프로세스 관점(Process View)에서 발전시키는 작업을 의미하며 분산 기술(Describe Distribution) 액티비티는 아키텍쳐를 배포 관점(Deployment View)에서 발전시키는 작업으로 아키텍쳐 설계작업의 연장이라고 할 수 있다.

   이번에는 서브시스템의 설계 관점에서 분석 & 설계 웍플로우를 관찰해 본다. 유스 케이스의 실현(realization)에 대해 기술한 유스 케이스의 분석 결과로부터 설계자는 클래스의 특징과 관계를 식별하고 클래스를 더 자세히 정의한다. 이 과정에서 설계자는 아키텍쳐의 설계를 이용한다. 또한 서브시스템 인터페이스를 정의한다. 서브시스템의 인터페이스는 서브시스템에 포함된 클래스의 설계를 참조하여 만들어진다. 그런 다음, 유스 케이스를 다시 완전하게 설계한다. 유스 케이스의 실현(realization)은 Sequence 다이어그램이나 Collaboration 다이어그램에서 클래스 또는 서브시스템간의 상호 연산(operation)을 통해 완전하게 명시된다.

   시스템이 대규모의 데이터를 포함하고 있을 때에는 데이터베이스 설계자는 persistent 클래스를 데이터베이스의 테이블에 할당하는 등의 작업을 아울러 수행한다.

라) 도구 지원

   앞서 언급한 모델을 표현하는 데 사용되는 언어는 UML이며, 다양한 산출물과 연관된 모델링 지침도 UML로 표현되어 있다. 따라서 모델을 작성하고 관리하는 데 가장 적합한 도구는 Rational Rose이다. Rose는 다양한 프로그래밍언어로 라운드 트립 엔지니어링 기능(순공학 + 역공학)을 제공하여 설계와 코드가 완벽하게 동기화될 수 있게 한다.

   또한 Rational Unified Process는 UML과 Rose를 사용하여 올바르게 분석 & 설계할 수 있도록 유용한 정보를 제공한다. 실시간 시스템의 분석 & 설계에 사용하는 모델링 도구인 Rose RealTime은 설계한 모델의 시뮬레이션 기능도 제공한다. 또한 Rational SoDA를 이용하여 문서 또는 보고서의 작성을 자동화할 수 있다. 예를 들어 SoDA를 이용하여 RequisitePro의 요구사항 분석내역과 Rose의 설계 모델로부터 정보를 추출하여 알맞은 양식의 보고서를 생성할 수 있다.

마) 요약

• 분석과 설계를 통해 요구사항과 구현사이의 갭을 메우게 된다. 분석 & 설계 웍플로우는 유스 케이스를 사용하여 일련의 객체를 인식하고, 인식된 객체들은 클래스, 팩키지, 서브시스템으로 다듬어 진다.
• 아키텍트(큰 그림을 담당), 설계자(세부사항을 담당), 데이터베이스 설계자(persistence를 다루기 위한 지식을 필요로 하는 세부사항을 담당)가 분석 설계단계의 책임을 나누어 갖는다.
• 분석과 설계의 결과는 3가지 아키텍쳐 관점으로 추상화된 설계 모델이다. 논리적 관점(Logical View)은 시스템을 클래스, 서브시스템, 패키지, collaboration과 같은 논리적 요소로 나눈 모습을 나타내며 프로세스 관점(Process View)은 이러한 논리적 요소의 시스템의 프로세스와 쓰레드로의 매핑을 보여준다. 마지막으로 배포 관점(Deployment View)은 분산환경에서 프로세스의 실행될 노드(컴퓨터)로의 매핑을 나타낸다.
• 별도의 분석 모델이 시스템의 개략적인 모습을 표현하는 데 유용하게 쓰일 수 있는 경우도 있다.

본 글의 모든 저작권은 Rational에 있습니다.