활동:
|
목적
|
|
역할: 설계자 | |
빈도: 결과물: 유스 케이스 구현 설계세트에 대해 각 반복당 한 번. | |
단계 | |
입력물: | 결과물: |
툴 강좌: | |
자세한 정보: | |
워크플로우 세부사항: |
시스템 작동은 여러 기술(공동 연구 또는 상호 작용)로 설명할 수 있습니다. 이 활동은 상호 작용, 특히 순서 다이어그램을 묘사하여 시스템의 작동에 대해 설명합니다. 순서 다이어그램은 시스템 또는 서브시스템의 작동을 주로 동기적 메시지 전달로 설명할 수 있는 경우 가장 유용합니다. 특히 이벤트 구동 시스템에서 비동기 메시징은 상태 시스템 및 공동 연구 관점에서 종종 보다 쉽게 설명되어 객체 간 가능한 상호 작용을 정의하는 최소 설치 방법을 허용합니다.
결과물: 유스 케이스 구현 설계가 설계 모델의 작동에서 유스 케이스 모델로 역추적하는 방법을 제공하며 설계 모델의 공동 연구를 유스 케이스 개념을 중심으로 체계화합니다.
설계할 각 유스 케이스에 대해 설계 모델에서 유스 케이스 구현 설계를 작성하십시오. 유스 케이스 구현 설계의 이름은 연관된 유스 케이스와 동일해야 하며 관계 "구현"은 유스 케이스 구현에서 연관된 유스 케이스로 설정되어야 합니다.
각 유스 케이스 구현의 경우, 하나 이상의 순서 다이어그램을 작성하여 참여 설계 오브젝트 간 상호 작용을 설명해야 합니다. 이러한 다이어그램의 초기 버전은 활동: 유스 케이스 분석 중에 작성됩니다. 유스 케이스 구현의 이러한 "분석 버전"은 분석 클래스 간 상호 작용을 설명합니다. 설계 요소 간 상호 작용을 설명하도록 전개되어야 합니다.
순서 다이어그램 갱신에는 다음 단계가 관여됩니다.
이는 시스템 레벨 순서 다이어그램으로 최상위 레벨 설계 요소(일반적으로 서브시스템 및 서브시스템 인터페이스)가 상호 작용하는 방법을 표시함을 참고하십시오. 서브시스템의 내부 디자인을 표시하는 순서 다이어그램은 활동: 서브시스템 설계의 일부로서 별도로 생성됩니다.
활성 객체 상호 작용은 일반적으로 스펙 공동 연구 및 상태 시스템을 사용하여 설명함을 참고하십시오. 보다 큰 유스 케이스 구현에서 시스템의 기타 요소에 의해 메시지가 활성 객체에 전송되는 방법을 표시하도록 여기에서 사용됩니다. 일반적인 사용법으로 활성 객체는 유스 케이스 구현이 상호 작용하는 서브시스템 세트로 구성되도록 이 활동의 용도로 서브시스템 내에서 캡슐화됩니다. 상호 작용이 서브시스템의 책임 및 인터페이스를 정의합니다. 서브시스템에서 활성 객체가 실행의 동시 스레드를 표시합니다. 서브시스템을 사용하여 팀 간 공적 계약 역할을 하는 인터페이스로 개발 팀 사이에 작업을 나눌 수 있습니다.
서브시스템에서 나오는 메시지를 표시하는 짧은 참고사항: 인터페이스에만 대한 제한된 메시지가 모델 요소 간 결합을 감소시키며 설계의 유연성을 향상시킵니다. 가능한 경우, 이를 완수하도록 노력해야 하며 서브시스템에서 비인터페이스 모델로 나오는 메시지가 있는 경우 모델에서 분리를 향상시키도록 이러한 메시지를 인터페이스로 변경하는 기회를 찾아야 합니다.
순서 다이어그램의 객체가 수행하는 유스 케이스 작동을 문서화합니다.
객체 간 작동을 분배한 경우, 플로우가 제어되는 방법을 고려해야 합니다. 오브젝트가 유스 케이스 구현에서 특정 방식으로 상호 작용하며 특정 역할이 있음을 가정하여 해당 오브젝트를 찾습니다. 작동을 분배함에 따라 이러한 가정의 테스트를 시작할 수 있습니다. 플로우의 일부 파트에서 분산 구조를 사용할 수도 있습니다. 기타 파트에서는 집중 구조를 선호할 수도 있습니다. 이러한 다양성의 정의 및 두 유형의 구조 사용시 권장사항은 가이드라인: 순서 다이어그램을 참조하십시오.
이 시점에서 새 객체가 필요할 수도 있습니다. 예를 들어, 집중 구조를 사용하고 플로우를 제어할 새 객체가 필요한 경우입니다. 설계 모델에 추가하는 임의의 객체는 객체 모델에 작성된 요구사항을 충족해야 합니다.
활동: 구조 분석 중에 분석 메커니즘이
식별됩니다. 활동: 설계 메커니즘
식별 중에 분석 메커니즘이 설계 메커니즘으로 정제되며 분석 메커니즘에서
설계 메커니즘으로의 맵핑이 소프트웨어
구조 문서에 캡처되고 설계 메커니즘이 프로젝트
특정 가이드라인에 문서화됩니다.
이 활동 중에, 유스 케이스 설계, 임의의 적용 가능 설계 메커니즘이
유스 케이스 구현에 통합됩니다. 설계자가 사용 가능한
설계 메커니즘을 조사하여 개발 중인 유스 케이스 구현에 적용하는 사항을
판별하여 소프트웨어 구조 문서 및 설계 가이드라인에 문서화된
권장사항과 가이드라인에서 작업합니다.
주: 분석 클래스가 특정 분석 메커니즘으로 "태그"된 동안에
적용 가능한 설계 메커니즘이 활동: 유스 케이스
분석에 식별되어 기능성의 특정 부분이 설계에서 처리되어야 함을
표시합니다. 이런 경우,
적용 가능한 설계 메커니즘은 유스 케이스 구현에 관련된 분석 클래스가 태그된
분석 메커니즘과 연관됩니다.
설계자가 설계 가이드라인에 문서화된 사용 규칙에 따라 필수 설계 요소 및 설계 요소 상호 작용을 유스 케이스 구현에 포함시켜 적용 가능한 설계 메커니즘을 유스 케이스 구현에 통합합니다.
별도의 순서 다이어그램에 각 플로우 변형을 설명해야 합니다. 다이어그램이 시스템 설계시 일반적으로 원하는 세부사항 레벨을 포함해야 하는 경우 보다 쉽게 읽을 수 있으므로 순서 다이어그램이 일반적으로 의사소통 다이어그램에 선호됩니다.
가장 일반적이거나 가장 중요한 이벤트 플로우인 기본 플로우의 설명으로 시작하십시오. 그런 다음, 예외 플로우와 같은 변형을 설명하십시오. 관련 객체의 모든 조작을 사용하여 예증하는 한 모든 이벤트 플로우를 설명할 필요가 없습니다. 이와 같은 경우, 한 객체에만 관여된 플로우와 같이 매우 사소한 플로우는 생략될 수 있습니다.
유스 케이스를 학습하여 요구사항 캡처 및 분석에 이미 설명된 사항(예: 구현에 종속적인 플로우 변형) 외에 플로우 변형이 있는지 확인하십시오. 새 플로우 식별시, 각 플로우를 순서 다이어그램에 설명하십시오. 예외 플로우의 예에는 다음이 포함됩니다.
변형 대신에 선택사항 플로우로서 플로우의 대체 경로를 설명할 수 있습니다. 다음 목록에는 선택사항 플로우의 두 예가 포함됩니다.
선택사항 플로우 또는 임의의 복잡한 서브 플로우가 특별히 주목되기를 원하는 경우, 별도의 순서 다이어그램을 사용하십시오. 각 별도의 순서 다이어그램은 선택사항 또는 서브 플로우 작동이 발생하는 위치를 표시하도록 스크립트, 여백 텍스트 또는 노트를 사용하여 기본 이벤트 플로우의 순서 다이어그램에서 표시되어야 합니다.
선택사항 또는 예외적 플로우 작동이 어디서든 발생할 수 있는 경우(예: 특정 이벤트 발생시 실행하는 작동), 기본 이벤트 플로우의 순서 다이어그램이 이벤트 발생 시기와 선택사항/예외적 순서 다이어그램에 설명된 작동이 실행될 시기를 표시하도록 주석 처리되어야 합니다. 대안으로, 중요한 이벤트 구동 작동이 있는 경우, 시스템 작동을 설명하는데 상태 차트 다이어그램의 사용을 고려하십시오. 자세한 정보는 가이드라인: 상태 차트 다이어그램을 참조하십시오.
유스 케이스가 구현되면 이벤트 플로우가 일반적으로 오브젝트 실행(설계 객체 간 상호 작용) 관점에서 설명됩니다. 다이어그램을 단순화하고 재사용 가능한 작동을 식별하기 위해 서브시스템 내 이벤트의 서브 플로우를 캡슐화할 필요가 있을 수도 있습니다. 이 작업이 완료되면 순서 다이어그램의 대형 서브 섹션이 서브시스템에 단일 메시지로 대체됩니다. 서브시스템에서 별도의 순서 다이어그램이 필수 작동을 제공하는 서브시스템의 내부 상호 작용을 설명할 수도 있습니다(자세한 정보는 활동: 서브시스템 설계 참조).
순서 다이어그램 내 메시지의 서브 순서는 다음과 같은 경우 서브시스템에서 캡슐화되어야 합니다.
필요한 경우, 유스 케이스 구현이 서브시스템 계층 구조의 여러 레벨에서 설명될 수 있습니다. 중간 다이어그램의 생명선이 서브시스템을 표시합니다. 원의 상호 작용이 메시지의 응답하여 서브시스템 구성원의 내부 상호 작용을 표시합니다.
이 접근법의 이점은 다음과 같습니다.
예:
로컬 호출 유스 케이스 구현의 일부인 다음 순서 다이어그램을 고려하십시오.
이 다이어그램에서 회색 클래스는 네트워크 처리 서브시스템에 속하며 기타 클래스는 신청자 처리 서브시스템에 속합니다. 이는 해당 다이어그램이 다중 서브시스템 순서 다이어그램, 즉 해당 클래스가 다른 서브시스템에 있는지 여부에 상관없이 이벤트 플로우에 관련된 모든 객체가 포함된 다이어그램임을 의미합니다.
대안으로서 네트워크 처리 서브시스템의 작동 호출 및 해당 서브시스템의 특정 인터페이스 수행을 표시할 수 있습니다. 네트워크 처리 서브시스템이 다음과 같이 신청자 처리 서브시스템이 사용하는 ICoordinator 인터페이스를 제공한다고 가정하십시오.
ICoordinator 인터페이스는 네트워크 처리 내 조정자 클래스에 의해 구현됩니다. 이런 가정하에서 네트워크 처리 내 클래스의 인스턴스 대신 네트워크 처리 서브시스템 자체와 해당 ICoordinator 인터페이스를 순서 다이어그램에서 사용할 수 있습니다.
조정자, 숫자 정보 및 네트워크 클래스 인스턴스가 포함하는 서브시스템으로 대체됨을 참고하십시오. 서브시스템의 모든 호출이 ICoordinator 인터페이스를 통해 대신 완료됩니다.
동일한 인터페이스를 구현하는 서브시스템의 진정한 대체성을 달성하기 위해 해당 인터페이스만이 상호 작용(및 일반적으로 다이어그램)에서 가시적이어야 합니다. 그렇지 않으면 상호 작용(또는 다이어그램)은 서브시스템이 서로 대체될 때 변경되어야 합니다.
예:
순서 다이어그램에 다음과 같이 ICoordinator 인터페이스만을 포함할 수 있으며 제공하는 서브시스템은 포함할 수 없습니다.
인터페이스 생명선에 메시지를 전송하는 것은 인터페이스를 구현하는 모든 서브시스템이 다이어그램의 인터페이스에 대해 대체될 수 있음을 의미합니다. 인터페이스를 구현하는 다른 서브시스템에 다른 메시지를 전송할 수 있으므로 ICoordinator 인터페이스 생명선에는 해당 생명선에서 나오는 메시지가 없음을 참고하십시오. 그러나 인터페이스를 구현하는 모든 서브시스템에서 전송되어야 하는(또는 전송이 허용되는) 메시지를 설명하려는 경우, 해당 메시지는 인터페이스 생명선에서 나올 수 있습니다.
일부 경우에 서브시스템을 기타 서브시스템의 개발과 동시에 다소 독립적으로 개발하는 것이 적절할 수 있습니다. 이를 달성하려면 우선 서브시스템 간 인터페이스를 식별하여 서브시스템 종속성을 찾아야 합니다.
작업이 다음과 같이 완료될 수 있습니다.
순서 다이어그램을 서브시스템에 관하여 또는 해당 인터페이스에만 관하여
배열할 지 여부를 선택할 수도 있습니다. 일부 프로젝트에서 나머지 모델링을
계속하기 전에 인터페이스를 제공하는 클래스를 구현해야 할 수도 있습니다.
객체 지향 패러다임의 전체 목적은 구현 세부사항을 캡슐화하기 위함입니다. 따라서 지속성에 관해서는 일시 객체와 똑같이 지속적 객체 보기를 하고자 합니다. 객체가 지속적인지를 인식하거나 기타 객체와 달리 처리할 필요가 없습니다. 최소한 이것이 목표입니다.
실제로 어플리케이션이 다음과 같은 지속성의 여러 면을 제어할 필요가 있는 경우가 때때로 있을 수 있습니다.
다음과 같이 고려해야 할 두 가지 경우가 있습니다. 객체가 지속적 객체 저장소에 기록되는 초기 시기. 어플리케이션이 지속적 객체 저장소를 객체의 변경사항으로 갱신하려는 후속 시기.
어느 경우에든 특정 메커니즘이 지속성 프레임워크가 지원하는 조작에 따라 달라집니다. 일반적으로, 사용된 메커니즘은 지속적 객체를 작성하도록 지속성 프레임워크에 메시지를 전송해야 합니다. 일단 객체가 지속적이면 지속성 프레임워크는 후속 변경사항을 지속성 객체로 발견하고 필요한 경우(일반적으로 트랜잭션 확약 시) 해당 변경사항을 지속적 객체 저장소에 기록할 만큼 영리합니다.
작성 중인 지속적 객체의 예가 아래에 표시됩니다.
객체 PersistenceMgr는 지속성 프레임워크인 VBOS의 인스턴스입니다. OrderCoordinator가 PersistenceMgr로의 'createPersistentObject' 메시지에 인수로서 지속적 주문을 전송하여 해당 주문을 작성합니다 .
객체가 일부 이벤트 시퀀스의 특정 지점에 명시적으로 저장 중임을 아는 것이 중요하지 않은 경우 이를 명시적으로 모델화하는 것은 일반적으로 필요치 않습니다. 후속 조작이 객체를 조회해야 하는 경우, 객체가 데이터베이스에 있어야 합니다. 따라서 객체가 데이터베이스에 있는 것을 아는 것이 중요합니다.
어플리케이션이 해당 객체에 메시지를 보낼 수 있으려면 지속적 객체 저장소에서 객체 검색이 필수입니다. 객체 지향 시스템에서 해당 작업의 재호출은 메시지를 객체에 전송함으로써 수행합니다. 그러나 메시지를 전송하려는 객체가 데이터베이스에 있으나 아직 메모리에는 없는 경우, 문제점이 됩니다. 아직 존재하지 않는 것에 메시지를 전송할 수 없습니다!
간단히 말해, 데이터베이스를 조회하고 올바른 객체를 검색하며 이를 실증하는 방법을 아는 객체에 메시지를 전송해야 합니다. 그런 다음, 그리고 그런 후에야 원래 의도한 본래 메시지를 전송할 수 있습니다. 지속적 객체를 실증하는 객체는 때때로 팩토리 객체라고 합니다. 팩토리 객체는 지속적 객체를 포함하여 객체의 인스턴스를 작성하는 책임이 있습니다. 조회가 제공되면 팩토리는 조회에 일치하는 하나 이상의 객체 세트를 리턴하도록 설계될 수 있습니다.
일반적으로 객체는 해당 연관을 통해 서로 충분히 연결되므로 일반적으로 객체 그래프에서 루트 객체를 검색하는 것만이 필요합니다. 나머지는 본질적으로 루트 객체와의 연관에 의해 데이터베이스 밖으로 분명하게 '빠져나갑니다'. (좋은 지속적 메커니즘은 이를 현명하게 처리합니다. 해당 메커니즘은 객체가 필요할 때만 검색합니다. 그렇지 않으면 대다수의 객체를 불필요하게 실증하려는 노력을 종료할 수도 있습니. 필요하기 전에 객체를 검색하는 것은 극단적으로 단순화한 지속성 메커니즘으로 생긴 주된 성능 문제점 중 하나입니다.)
다음 예가 지속적 객체 저장소에서 객체 검색을 모델화하는 방법을 표시합니다. 실제 순서 다이어그램에서 DBMS는 팩토리 객체에 캡슐화되어야 하므로 표시되지 않습니다.
지속적 객체에 있는 문제점은 해당 객체가 지속적이라는 것입니다!! 일시 객체는 자신을 작성한 프로세스 소멸시 단순히 사라지는 반면 지속 객체는 명시적으로 삭제될 때까지 존재합니다. 따라서 지속적 객체가 더 이상 사용되지 않는 경우 해당 객체를 삭제하는 것이 중요합니다.
문제점은 이를 판별하기가 힘들다는 것입니다. 객체가 있는 한 어플리케이션이 완료되었으므로 모든 어플리케이션(현재 또는 장래의)이 완료된 것은 아닙니다. 또한 객체가 알지조차도 못하는 연관이 있거나 있을 수 있다고 해서 객체를 삭제하는 것이 타당한지를 알아내는 것이 항상 쉬운 것은 아닙니다.
설계시, 상태 차트를 사용하여 의미론적으로 표시될 수 있습니다. 객체가 종료 상태에 다다르면 릴리즈됨으로 나타낼 수 있습니다. 그런 다음, 지속적 클래스 구현의 책임이 있는 개발자가 상태 차트 정보를 사용하여 객체를 릴리즈하는 적절한 지속성 메커니즘 작동을 호출할 수 있습니다. 유스 케이스 구현 설계자의 책임은 객체가 삭제되기에 적절한 경우 객체가 종료 상태에 다다를 수 있게 하는 적절한 조작을 호출하는 것입니다.
객체가 기타 객체에 충분히 연결되면 객체가 삭제될 수 있는지 여부를 판별하기가 어려울 수 있습니다. 팩토리 객체가 연결된 객체뿐 아니라 객체의 구조에 대해서도 알고 있으므로 클래스의 팩토리 객체에게 특정 인스턴스가 삭제될 수 있는지 여부를 판단할 책임을 부여하는 것은 종종 유용합니다. 지속성 프레임워크가 이 성능에 대한 지원을 제공할 수도 있습니다.
트랜잭션이 원자인 조작 호출 세트를 정의합니다. 모두 수행되거나 전혀 수행되지 않습니다. 지속성의 컨텍스트에서 트랜잭션이 변경 세트를 모두 수행되거나 전혀 수행되지 않는 객체 세트로 정의합니다. 트랜잭션이 지속성을 제공하여 객체 세트가 한 지속적 상태에서 다른 상태로 이동하는지 확인합니다.
유스 케이스 구현에서 트랜잭션을 표시하는 다음과 같은 여러 선택사항이 있습니다.
텍스트로 된 주석으로 트랜잭션 경계 표시.
트랜잭션을 시작 및 중지하는 명시적 메시지를 표시하는 순서 다이어그램.
트랜잭션에 지정된 모든 조작이 수행될 수 없는 경우(일반적으로 오류가 발생하므로) 트랜잭션이 중단되고 트랜잭션이 역전되는 동안 모든 변경이 작성됩니다. 예상된 오류 조건은 종종 유스 케이스에 있는 이벤트의 예외적인 플로우를 표시합니다. 기타의 경우, 오류 조건이 시스템의 일부 실패로 인해 발생합니다. 오류 조건이 상호 작용에서도 문서화되어야 합니다. 단순 오류 및 예외가 발생하는 상호 작용에 표시될 수 있습니다. 복잡한 오류 및 예외가 고유 상호 작용을 필수로 할 수도 있습니다.
특정 객체의 실패 모드가 상태 차트에 표시될 수 있습니다. 이러한 실패 모드의 조건적 제어 처리 플로우가 오류 또는 예외가 발생하는 상호 작용에 표시될 수 있습니다.
동시성이 트랜잭션 과정의 중요한 시스템 자원에 대한 액세스 제어를 설명합니다. 시스템을 일관된 상태로 유지하려면 트랜잭션에 시스템의 일정 중요한 자원에 대한 독점적 액세스가 있는 것이 필수일 수도 있습니다. 독점성은 객체 세트 읽기, 객체 세트 쓰기 또는 객체 세트 읽기 및 쓰기 모두의 능력을 포함할 수도 있습니다.
객체 세트에 제한된 액세스가 필요할 수도 있는 이유의 간단한 예를 살펴봅시다. 간단한 주문 입력 시스템을 실행 중이라고 합시다. 사용자가 주문하기 위해 전화를 하면 차례로 우리가 주문을 처리하고 주문을 배송합니다. 주문을 일종의 트랜잭션으로 볼 수 있습니다.
동시성 제어에 대한 필요를 설명하기 위해 한 켤레의 새 등산용 신발을 주문하도록 전화를 건다고 합시다. 주문이 시스템에 입력되면 원하는 올바른 크기의 등산용 신발이 재고 목록에 있는지 확인하도록 검사합니다. 재고가 있는 경우, 해당 신발 한 켤레를 예약하여 주문이 배송되기 전에 다른 사람이 구입할 수 없도록 합니다. 주문이 배송되고 나면 신발이 재고 목록에서 제거됩니다.
주문 시기와 배송 시기 사이의 기간 동안 신발은 특별한 상태—에 있습니다. 재고 목록에 있으나 나의 주문으로 "확약"됩니다. 나의 주문이 일정 이유로 인해 취소된 경우(마음이 바뀌었거나 신용 카드가 만기됨), 신발은 재고 목록으로 리턴됩니다. 주문이 배송되고 나면 우리의 작은 회사가 한 때 신발을 소유한 적이 있음을 나타내는 기록을 유지하고 싶어하지 않을 것으로 간주합니다.
트랜잭션과 같이 동시성의 목표는 시스템이 한 일관된 상태에서 다른 상태로 이동함을 확인하기 위함입니다. 또한 동시성은 트랜잭션에 작업을 완료하는데 필요한 모든 자원이 있음을 확인하기 위해 노력합니다. 동시성 제어는 자원 잠금, 세마포어, 공유 메모리 래치 및 개인용 작업공간을 포함하여 여러 다른 방법으로 구현될 수 있습니다.
객체 지향 시스템에서 단지 메시지 패턴으로부터 특정 메시지가 객체의 상태 변경을 유발할 수도 있는지 여부를 판단하기는 어렵습니다. 또한 다른 구현이 일정 유형의 자원에 대한 액세스를 제한할 필요를 제거할 수도 있습니다. 예를 들어, 일부 구현이 트랜잭션 시작에 시스템 상태 고유 보기로 각 트랜잭션을 제공합니다. 이 경우, 기타 프로세스가 임의의 기타 실행 트랜잭션의 '보기'에 영향을 미치지 않고 객체와 해당 상태를 변경할 수도 있습니다.
구현 제한을 예방하도록 설계시 트랜잭션에 독점적 액세스가 있어야 하는 자원을 간단히 표시하고자 합니다. 이전 예제를 사용하여 주문한 신발에 대한 독점적 액세스가 필요함을 표시하고자 합니다. 간단한 대안은 어플리케이션이 객체에 대해 독점적 액세스가 필요함을 표시하여 전송 중인 메시지의 설명에 주석 처리하는 것입니다. 그런 다음, 구현자가 이 정보를 사용하여 동시성 요구사항을 구현하는 가장 좋은 방법을 판별할 수 있습니다. 독점적 액세스가 필수인 메시지에 주석 처리하는 순서 다이어그램 예제가 아래에 표시됩니다. 가정은 트랜잭션 완료시 모든 잠금이 릴리즈된다는 것입니다.
순서 다이어그램의 주석 처리된 액세스 제어를 표시하는 예.
트랜잭션에 필요한 모든 객체에 대한 액세스를 제한하지 않는 이유는
종종 오직 적은 수의 객체에 액세스 제한이 있어야 하기 때문입니다. 트랜잭션에
관련된 모든 객체에 액세스를 제한하는 것은 귀중한 자원을 낭비하고 성능
병목 현상을 예방하는 것이 아니라 작성할 수 있습니다.
이벤트 플로우가 관련 객체 간 전송되는 메시지를 단지 조사하는 것으로 아주 명확하지 않은 경우, 유스 케이스 구현의 이벤트 플로우에서 순서 다이어그램에 추가 설명을 추가해야 할 수도 있습니다. 이러한 경우의 일부 예에는 타이밍 주석, 조건부 작동에 대한 참고 또는 조작 작동의 설명이 외부 관찰자가 다이어그램을 보다 쉽게 읽도록 해야 하는 경우가 포함됩니다.
이벤트 플로우가 처음에는 활동: 유스 케이스 분석에 개요됩니다. 이 단계에서 순서 다이어그램을 명백히 설명하는데 필요한 대로 이벤트 플로우를 정제합니다.
조작의 이름은 종종 조작이 수행 중인 이유를 이해하는데 충분하지 않습니다. 다이어그램 가장자리의 텍스트로 된 참고나 스크립트는 순서 다이어그램을 명확히 설명하는데 필요할 수도 있습니다. 텍스트로 된 참고나 스크립트는 제어 플로우(예: 결정 단계, 루프 실행 및 분기 작성)를 표시하기 위해 필요할 수도 있습니다. 또한 테스트로 된 태그는 유스 케이스의 확장 위치와 순서 다이어그램의 특정 위치를 상관시켜야 할 수도 있습니다.
이 활동의 이전 예제가 순서 다이어그램의 주석 처리하는 여러 다른 방법을 설명합니다.
유스 케이스가 구현됨에 따라 식별된 설계 클래스와 서브시스템을 단일화하여 설계 모델의 동질성 및 일관성을 확인해야 합니다.
고려해야 할 점은 다음과 같습니다.
이 단계에서 설계 모델을 검사하여 사용자 작업이 올바른 방향으로 진행되고 있는지 확인하십시오. 모델을 자세하게 검토할 필요는 없으나 작업 중 설계 모델의 체크포인트를 고려해야 합니다.
특히 활동: 설계 검토의 유스 케이스 구현의 체크포인트를 참조하십시오.
프록시 클래스를 사용하여 순서 다이어그램에 서브시스템을 표시할 수 있습니다. 이 프록시 클래스는 서브시스템에 포함되며 작동 요소로서 서브시스템 및 패키지의 직접 사용을 지원하지 않는 다이어그램에서 서브시스템을 표시하는데 사용합니다. 특정 서브시스템이 메시지에 응답함을 표시하려는 경우 프록시 클래스를 사용하십시오. 이런 경우, 서브시스템 프록시에서 기타 객체로 전송 중인 메시지를 표시할 수 있습니다.
자세한 정보는 UML 1.x와
UML 2.0의 차이점을 참조하십시오.
Rational Unified Process
|