목적
  • 설계 모델 요소를 식별하도록 분석 클래스의 상호 작용을 분석하기 위함입니다.
역할:  소프트웨어 아키텍트 
빈도: 반복당 한 번 
단계
입력물:   결과물:   
툴 강좌: 
자세한 정보: 

워크플로우 세부사항:   

활동: 유스 케이스 분석으로 분석 클래스가 생기며 이는 작동을 수행할 수 있는 개념적 사항을 표시합니다. 설계에서 분석 클래스가 다음과 같은 여러 다른 종류의 설계 요소로 전개됩니다.

  • 클래스, 보다 세밀한 책임 세트를 표시
  • 서브시스템, 조잡한 책임 세트를 표시하며 서브시스템의 자세한 세트로 구성될 가능성이 있지만 궁극적으로는 클래스의 세트임
  • 활성 클래스, 시스템의 제어 스레드를 표시
  • 인터페이스, 클래스 또는 서브시스템이 제공하는 책임의 추상 선언을 표시

설계시 다음도 식별합니다.

  • 이벤트, 일반적으로(해당 사건이 주목할 만한 경우) 시스템에서 일부 응답을 필수로 하는 시간 및 공간상의 흥미로운 사건의 스펙.
  • 신호, 시스템 내 일정한 유형의 이벤트와 의사소통하는데 사용하는 비동기적 메커니즘을 표시.

이러한 분명한 구분이 다음과 같이 설계의 다른 면을 검사할 수 있게 합니다.

  • 상호 의사소통에 사용하는 이벤트 및 신호를 사용하여 시스템이 응답해야 하는 작동의 비동기적 트리거를 설명할 수 있습니다.
  • 클래스와 서브시스템을 사용하여 관련 책임을 상대적인 독립성으로 개발할 수 있는 장치로 그룹화할 수 있습니다. 클래스가 관련 책임의 아주 작은 세트를 수행합니다. 반면 서브시스템은 차례로 클래스 또는 기타 서브시스템으로 구성되는 합성 빌드 블록입니다. 서브시스템을 사용하여 개발 팀의 작업 제품을 단일, 기능성의 통합 장치를 표시하며, 그 자체로 논리 설계 요소뿐 아니라 제어 및 형상 관리 모두의 장치로 사용됩니다.
  • 활성 클래스는 시스템에서 제어 스레드를 표시하는데 사용되어 동시성 모델링을 가능하게 합니다. 활성 클래스는 종종 일반적으로(그러나 반드시는 아님) 수동적인 기타 클래스의 구성에 사용됩니다. 그런 다음 이러한 구성은 공동 작업에서와 동일한 방식으로 복잡한 작동을 모델화하는데 사용합니다.
  • 인터페이스를 사용하여 시스템의 '균열'을 조사하고 캡처하여 시스템의 구성 파트가 상호 조작되는 방법을 정확한 표현으로 정의합니다.

관심사를 분리하고 해당 개념으로 표시되는 각 문제점을 별도로 처리하여 설계 프로세스를 단순화하고 솔루션을 명백히 합니다.

추적성이 시스템 모델 간에 유지보수되려면 이 활동 중에 문서화되어야 합니다.  설계 모델 및 기타 시스템 모델 간 추적성을 문서화하는데 대한 자세한 정보는 가이드라인: 설계 모델을 참조하십시오.

이벤트 및 신호 식별 페이지 맨 위

목적 시스템이 응답해야 하는 외부 및 내부 이벤트와 신호를 식별하기 위함입니다.  

이벤트는 시스템에서 일부 조치를 유발하는 외부 및 내부 사건입니다. 이벤트 및 해당 특성이 활성 클래스와 같은 중요한 설계 요소의 식별을 구동하는데 도움이 될 수 있습니다.

외부 이벤트의 초기 목록은 유스 케이스 모델, 유스 케이스를 사용한 수행자의 상호 작용에서 파생될 수 있습니다. 내부 이벤트는 유스 케이스 플로우의 텍스트에서 파생되거나 설계가 전개됨에 따라 식별될 수도 있습니다.

이벤트의 중요한 특성은 다음과 같습니다.

  • 내부 대 외부 - 이벤트의 내부 또는 외부 여부
  • 우선순위 - 해당 이벤트가 처리되려면 기타 처리가 일시중단되어야 하는지 여부
  • 빈도 - 이벤트가 얼마나 자주 발생하는지 도수
  • 빈도 분배 - 이벤트가 정기적인 간격으로 발생하는지 또는 갑작스러운지 여부
  • 응답 요구사항 - 이벤트에 시스템이 응답해야 하는 빠르기(평균과 최악의 경우 간에 구분되어야 할 수도 있음).
  • 종류 - 호출 이벤트, 시간 이벤트, 신호 이벤트 또는 변경 이벤트인지 여부(정의는 개념: 이벤트 및 신호 참조).

이벤트의 특성은 해당 특성을 처리하는 설계 요소의 식별을 구동하도록 필요에 따라 캡처되어야 합니다. 이벤트 특성의 캡처가 반응(이벤트 주도) 시스템에서 가장 중요한 경향이 있으나 기타 시스템(예: 동시성 및/또는 비동기 메시징을 포함하는 시스템)에서도 유용할 수 있습니다.

비동기 의사소통 이벤트는 신호로 모델화되어 수반하는 데이터를 표현하거나 신호 간 관계(예: 일반화)를 표현할 수 있습니다. 일부 시스템, 특히 반응 시스템에서 외부 장치에서 받은 신호를 특정 메커니즘에 연관하는 것이 중요합니다(예: 인터럽트 또는 특정 폴링 메시지).

클래스, 활성 클래스 및 서브시스템 식별 페이지 맨 위

목적 분석 클래스를 적절한 설계 모델 요소로 정제하기 위함입니다. 

클래스를 식별하십시오. 분석 클래스가 단순하고 이미 단일 논리적 추상 개념을 표시하는 경우 1:1로 직접 설계 클래스에 맵핑될 수 있습니다. 일반적으로, 엔티티 클래스는 비교적 설계에 손상되지 않은 상태로 남습니다. 일반적으로 엔티티 클래스가 또한 지속적이므로 설계 클래스가 지속적이어야 하는지 여부를 판별하고 클래스 설명에 적절하게 기록하십시오.

클래스 식별시, 조직 및 형상 관리 용도로 사용하도록 결과물: 설계 패키지로 그룹화해야 합니다. 패키징 결정에 대한 자세한 정보는 가이드라인: 패키지 설계를 참조하십시오.

활성 클래스를 식별하십시오. 분석 객체의 컨텍스트에서 다음과 같은 시스템의 동시성 요구사항을 고려하십시오. 시스템이 외부적으로 생성된 이벤트에 응답해야 할 필요가 있는지 여부와 그런 경우, 이벤트 발생시 '활성'인 분석 클래스. 유스 케이스 모델의 외부 이벤트가 수행자로부터 생기는 자극으로 표시되며 유스 케이스와 상호 작용합니다. 해당 유스 케이스 구현을 살펴 보아 이벤트 발생시 상호 작용하는 객체를 확인하십시오. 객체를 공동 작업 객체의 자율 세트로 함께 그룹화하여 시작하십시오. 이러한 그룹화가 합성 활성 클래스를 형성할 수 있는 그룹의 초기 도안을 표시합니다.

이벤트에 캡처해야 하는 중요한 속성이 있는 경우, 해당 이벤트를 <<signal>>로 스테레오타입화된 클래스로 모델링하는 것을 고려하십시오.

활성 클래스의 인스턴스가 실행의 독립적 '논리' 스레드를 표시합니다. 이러한 실행의 '논리' 스레드가 운영 체제의 실행 스레드와 혼동되거나 사실상 맵핑되어서는 안됩니다(그러나 향후 일정 지점에서 운영 체제의 실행 스레드에 맵핑될 것임). 대신, 솔루션 공간에서 실행의 독립적 개념 스레드를 표시합니다. 설계의 이 지점에서 해당 스레드를 식별하는 목적은 솔루션을 시스템의 자연적 '동시성 이음새'를 기반으로 한 독립적 장치로 파티션을 나눌 수 있도록 하기 위함입니다. 이 방식으로 작업을 나누면 동시성을 다루는 문제점을 개념적으로 단순하게 합니다. 왜냐하면 실행의 독립 스레드가 기본 수동 클래스를 공유하는 정도까지는 제외하고 해당 클래스를 별도로 다룰 수 있습니다.

일반적으로 문제점 도메인에서 동시성 충돌 및 동시성이 있는 경우 언제나 활성 클래스가 고려되어야 합니다. 활성 클래스를 사용하여 컴퓨터의 일부 외부 동시 객체 또는 병행 활동을 표시해야 합니다. 이는 병행 활동을 모니터하고 제어하는 능력을 제공합니다.

또다른 기본 선택은 실제 엔티티가 본래 동시적이므로 컴퓨터에 연결된 외부 실제 장치의 내부 대표로서 활성 클래스를 사용하는 것입니다. 이러한 "장치 드라이버" 클래스가 대응하는 실제 장치를 모니터하고 제어하는데뿐 아니라 장치의 특정 사항에서 시스템의 나머지를 분리하는데도 사용합니다. 즉, 시스템의 나머지가 장치 배후의 기술이 전개하는 경우에도 영향을 받지 않을 수 있음을 의미합니다.

활성 클래스를 사용하는 또다른 일반 경우는 논리적 병행 활동을 표시하기 위함입니다. 논리 활동이 개념적 동시 "객체"를 표시합니다(예: 금융 재정 트랜잭션 또는 전화). 이러한 사항이 실제 엔티티로 직접 표시되지 않음에도 불구하고(비록 실제 상황에서 발생하지만) 종종 이와 같이 처리해야 하는 이유가 있습니다. 예를 들어, 동시 충돌을 피하기 위해 특정 금융 트랜잭션을 임시적으로 보류해야 할 수도 있으며 시스템의 장애로 인해 중단해야 할 수도 있습니다. 이러한 개념적 객체가 장치로 다루어져야 하므로 적절한 기능적 성능을 제공하는 고유의 인터페이스가 있는 객체로 표시하는 것이 편리합니다.

이 유형의 개념적 객체의 특정 예는 활성 객체 제어기입니다. 이 목적은 하나 이상의 기타 활성 객체를 계속적으로 관리하기 위함입니다. 일반적으로, 각 객체를 원하는 운영 상태가 되게 하고 부분 실패와 같은 여러 혼란에도 불구하고 해당 상태로 유지보수하며 기타 객체의 조작과 이 조작을 동기화하는데 관련됩니다. 이러한 활성 객체 제어기가 종종 활동: 유스 케이스 분석 중에 식별된 제어 객체에서 전개됩니다.

간단하고 명쾌하게 동시성 충돌을 해결하는 능력으로 인해 활성 클래스는 공유 자원의 보호자로서도 유용합니다. 이 경우에, 여러 병행 활동에 필수인 하나 이상의 자원이 활성 클래스 내에서 캡슐화됩니다. 내장된 상호 배제 의미론 덕분에 이러한 보호자가 동시 충돌에 대해 해당 자원을 자동으로 보호합니다.

서브시스템을 식별하십시오. 분석 클래스가 복잡한 경우, 단독으로 행동하는 단일 클래스의 책임이 될 수 없는 작동을 구체화하는 것으로 표시되는 분석 클래스가 설계 서브시스템으로 맵핑되어야 합니다. 설계 서브시스템은 서브시스템이 제공하는 서비스를 사용하는 경우에도 서브시스템의 클라이언트가 서브시스템의 내부 설계를 전혀 알 수 없는 방식으로 이러한 공동 작업을 캡슐화하는데 사용합니다.

서브시스템은 UML 구성요소로 모델화되며, 공용 요소로 인터페이스만이 있습니다. 인터페이스가 캡슐화의 계층을 제공하여 서브시스템의 내부 설계가 기타 모델 요소로부터 숨겨짐 상태로 남을 수 있게 합니다. 개념 서브시스템은 모델 요소의 의미 없는 컨테이너인 패키지와 구분하는데 사용합니다.

공동 작업 분석 클래스 세트에서 서브시스템을 작성하는 결정은 주로 공동 작업이 별도의 설계 팀에 의해 독립적으로 개발될 수 있거나 개발되는지 여부를 기반으로 합니다. 공동 작업이 공동 작업 클래스와 함께 패키지 내에 완전히 포함될 수 있는 경우, 서브시스템은 단순 패키지가 제공하는 양식보다 보다 강한 캡슐화 양식을 제공할 수 있습니다. 서브시스템 내 컨텐츠와 공동 작업은 하나 이상의 인터페이스 뒤에서 완전히 분리되므로 서브시스템의 클라이언트가 인터페이스에만 의존합니다. 그런 다음, 서브시스템의 설계자가 외부 종속성에서 완전히 분리됩니다. 설계자(또는 설계 팀)는 인터페이스가 구현되는 방법을 지정해야 하지만 외부 종속성에 영향을 미치지 않고 완전히 자유롭게 내부 시스템에 변경을 합니다. 주로 독립적인 팀이 있는 대형 시스템에서 공적 인터페이스가 제공하는 구조적 실행과 결합된 이 분리 정도는 단순 패키지에 대한 서브시스템의 선택에 있어 강력한 인수입니다. 설계 요소로서 서브시스템을 사용하는 선택에 영향을 주는 인자에 대한 자세한 정보는 가이드라인: 설계 서브시스템을 참조하십시오.

서브시스템 인터페이스 식별 페이지 맨 위

목적 시스템의 이음새를 형성하는 설계 요소를 식별하기 위함입니다.  

인터페이스가 일부 분류자로 구현되는 조작 세트를 정의합니다. 설계 모델에서 인터페이스는 주로 서브시스템의 인터페이스를 정의하는데 사용합니다. 인터페이스가 클래스에도 사용될 수 없음을 말하려는 것이 아니라 일반적으로 단일 클래스에 대해 사실상 '인터페이스'를 정의하는 클래스의 공용 조작을 정의하는 것으로 충분함을 이야기하려는 것입니다. 인터페이스가 작동의 구현(인터페이스를 구현하는 서브시스템의 특정 클래스)에서 작동의 선언(인터페이스)을 분리하도록 하므로 인터페이스는 서브시스템에 중요합니다. 이 분리가 시스템의 다른 파트에서 작업하는 개발 팀의 독립성을 증가시키는 방법을 제공하는 한편 이러한 다른 파트 간 '계약'의 정확한 정의를 보유합니다.

각 시스템에 대해 후보 인터페이스 세트를 식별하십시오. . 이전 단계에서 식별된 그룹화된 공동 작업을 사용하여 공동 작업 시작시 '활성화'되는 책임을 식별하십시오. 그런 다음 이 책임은 '클라이언트'가 제공해야 하는 정보와 공동 작업이 완료되면 리턴되는 정보를 판별하여 정제됩니다. 이러한 정보 세트는 프로토타입 입력과 출력 매개변수 및 서브시스템이 구현하는 조작의 리턴값이 됩니다. ../artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated website결과물: 프로젝트 특정 가이드라인에 정의된 이름 지정 규칙을 사용하여 이 조작의 이름을 정의하십시오. 서브시스템이 구현하는 모든 조작이 정의될 때까지 이를 반복하십시오.

다음으로 관련 책임에 따라 함께 조작을 그룹화하십시오. 큰 그룹보다는 작은 그룹이 선호됩니다. 왜냐하면 그룹에 조작이 보다 적은 경우 공통 책임의 결합된 세트가 있을 가능성이 크기 때문입니다. 재사용에도 유의하십시오. 관련 재사용 가능 기능성을 보다 쉽게 식별하게 할 수 있는 유사성을 찾으십시오. 동시에, 이상적인 책임의 그룹화를 찾는데 대단히 많은 시간을 소비하지 마십시오. 이는 단지 처음 배정된 그룹화일 뿐이며 구현화 단계를 통해 정제가 반복적으로 진행됩니다.

인터페이스 간 유사성을 찾으십시오. 인터페이스의 후보 세트에서 유사한 이름, 유사한 책임 및 유사한 조작을 찾으십시오. 동일한 조작이 여러 인터페이스에 있는 경우, 공통 조작을 새 인터페이스에 추출하여 인터페이스를 다시 분석하십시오. 기존 인터페이스도 살펴보아 가능한 경우 재사용하도록 하십시오. 목표는 인터페이스 간 여분의 조작을 제거하는 동안 인터페이스의 결합력을 유지보수하는 것입니다. 이로써, 인터페이스를 이해하고 계속 전개하기 쉽게 됩니다.

인터페이스 종속성을 정의하십시오. 매개변수와 각 인터페이스 조작의 리턴값에 각각 특정 유형이 있습니다. 특정 인터페이스를 구현하거나 단순 데이터 유형의 인스턴스여야 합니다. 매개변수가 특정 인터페이스를 구현하는 객체인 경우, 인터페이스와 해당 인터페이스가 의존하는 인터페이스 간 종속성 관계를 정의하십시오. 인터페이스 간 종속성 판별이 소프트웨어 아키텍트에게 유용한 결합 정보를 제공합니다. 왜냐하면 인터페이스 종속성이 설계 모델의 요소 간 주된 종속성을 정의하기 때문입니다.

인터페이스를 서브시스템에 맵핑하십시오. 인터페이스가 식별되고 나면 서브시스템과 서브시스템이 구현하는 인터페이스 간 구현 연관을 작성하십시오. 서브시스템에서 인터페이스로의 구현은 인터페이스의 조작을 구현하는 서브시스템 간 하나 이상의 요소가 있음을 표시합니다. 나중에, 서브시스템이 설계되면, 서브시스템 설계자가 인터페이스의 조작을 구현할 서브시스템 내 특정 요소를 지정하여 이러한 서브시스템 인터페이스 구현을 정제합니다. 이러한 정제된 구현은 서브시스템 설계자만이 볼 수 있습니다. 시스템 클라이언트 관점에서 서브시스템 인터페이스 구현만이 가시적입니다.

인터페이스가 지정한 작동을 정의하십시오. 인터페이스가 종종 인터페이스를 구현하는 요소의 내재적 상태 시스템을 정의합니다. 인터페이스의 조작이 특정 순서로 호출되어야 하는 경우(예: 데이터베이스 연결이 사용되기 전에 열려야 함) 인터페이스를 구현하는 임의의 설계 요소가 지원해야 하는 공개적으로 가시적인(또는 추론된) 상태를 설명하는 상태 시스템이 정의되어야 합니다. 이 상태 시스템은 인터페이스의 사용자가 인터페이스를 보다 잘 이해하는데 도움이 되며 인터페이스를 구현하는 요소의 설계자가 해당 요소의 올바른 작동을 제공하는데 도움이 됩니다.

인터페이스 패키지. 인터페이스는 소프트웨어 아키텍트가 소유합니다. 인터페이스의 변경사항은 언제나 구조적으로 중요합니다. 이를 관리하려면, 인터페이스는 소프트웨어 아키텍트가 소유한 하나 이상의 패키지로 그룹화되어야 합니다. 각 인터페이스가 단일 서브시스템에 의해 구현되면 인터페이스가 서브시스템과 동일한 패키지에 놓일 수 있습니다. 인터페이스가 둘 이상의 서브시스템에 의해 구현되면 소프트웨어 아키텍트가 소유한 별도의 패키지에 위치해야 합니다. 이로써, 인터페이스가 서브시스템 자체에 독립적으로 관리 및 제어될 수 있습니다.

UML 1.x 표시페이지 맨 위

UML 1.5에 따르면, 서브시스템은 사실상 공용 요소로서 인터페이스만이 있는 패키지의 특별한 종류입니다. 인터페이스가 캡슐화의 계층을 제공하여 서브시스템의 내부 설계가 기타 모델 요소로부터 숨겨짐 상태로 남을 수 있게 합니다. 개념 서브시스템은 모델 요소의 의미 없는 컨테이너인 "일반" 패키지와 구분하는데 사용됩니다. 서브시스템이 클래스와 같은(작동의) 등록 정보가 있는 패키지의 특정 사용법을 표시합니다.

자세한 정보는 UML 1.x와 UML 2.0의 차이점을 참조하십시오.

 

Rational Unified Process   2003.06.15