활동:
|
목적
|
|
역할: 설계자 | |
빈도: 유스 케이스 세트 및/또는 유스 케이스 시나리오(현재 반복에서 개발 중)에 대해 반복당 한 번. | |
단계
다음은 현재 반복의 각 유스 케이스에 대해 수행됩니다. 다음은 반복당 한 번 수행됩니다. 주: 위의 단계는 논리적 순서로 표시되지만 각 단계를 대체하거나 일부 단계를 병행하여 수행해야 할 수도 있습니다. |
|
입력물: | 결과물: |
툴 강좌: | |
자세한 정보: |
워크플로우 세부사항: |
목적 | 유스 케이스의 작동을 표시하는데 사용하는 모델링 요소를 작성하기 위함입니다. |
유스 케이스가 대부분의 초기 분석 및 설계 작업의 중심을 형성합니다. 요구사항 중심 활동과 분석/설계 중심 활동 간의 변환을 위해 결과물: 유스 케이스 구현이 브릿지 역할을 수행하여 분석 및 모델 설계의 작동을 다시 유스 케이스 모델로 추적할 수 있는 방법을 제공하고 유스 케이스 개념 관련 공동 작업을 구성합니다.
구현이 없는 경우, 유스 케이스용 분석 모델에 분석 유스 케이스 구현을 작성하십시오. 분석 유스 케이스 구현의 이름은 연관된 유스 케이스와 동일해야 하며 "구현" 관계는 분석 유스 케이스 구현에서 연관된 유스 케이스로 설정되어야 합니다.
유스 케이스 구현에 대한 자세한 정보는 가이드라인: 유스 케이스 구현을 참조하십시오.
목적 | 시스템의 고객용으로 작성된 유스 케이스 설명에서 누락되었을 수도 있는 시스템의 필수 내부 작동을 이해하기 위해 필요한 추가 정보를 캡처하기 위함입니다. |
각 유스 케이스의 설명은 분석 클래스 및 해당 객체를 찾는데 항상 언제나 충분하지는 않습니다. 일반적으로 고객은 시스템 내부에서 발생한 사항에 대한 정보에는 관심이 없으므로 유스 케이스 설명은 이러한 정보를 생략할 수 있습니다. 이러한 경우, 유스 케이스 설명은 '블랙박스' 설명과 같이 해석됩니다. 여기에서 시스템이 수행자의 조치에 응답하여 수행한 사항에 대한 내부 세부사항은 생략되거나 매우 개략적으로 설명됩니다. 유스 케이스를 수행하는 객체를 찾으려면 내부 Perspective에서 시스템이 수행하는 사항에 대한 '화이트 박스' 설명이 있어야 합니다.
예
ATM(Automated Teller Machine)의 경우, 시스템의 고객이 다음과 같이 말하고자 할 수도 있습니다.
"ATM이 은행 고객 카드의 유효성을 확인합니다."
시스템의 사용자 인증 작업을 설명하기 위함입니다. 고객에게는 충분할 수 있지만 카드의 유효성을 확인하기 위해 ATM 내부에서 실제로 발생하는 사항에 대한 실제 개념을 제공하지는 않습니다.
객체를 식별할 수 있는 충분히 자세한 레벨에서 시스템이 작동하는 방법에 대한 내부 그림을 형성하려면 추가 정보가 필요할 수도 있습니다. ATM 카드 유효성 확인 활동을 예로써 확장된 설명은 다음과 같습니다.
"ATM이 고객 계정 번호와 PIN의 유효성을 확인하도록 ATM 네트워크에 전송합니다. ATM 네트워크가 고객 번호 및 PIN이 일치하고 고객이 트랜잭션을 수행하도록 권한이 부여된 경우 성공을 리턴하며, 그렇지 않은 경우 ATM 네트워크가 실패를 리턴합니다. "
이 레벨의 세부사항이 필수 정보 사항(계정 번호 및 PIN)과 인증에 책임이 있는 대상(ATM 네트워크, 유스 케이스 모델의 수행자)에 대한 명확한 개념을 제공합니다. 이 정보에서 두 잠재 객체(계정 번호 및 PIN 속성을 가진 고객 객체와 ATM 네트워크 인터페이스) 및 해당 책임을 식별할 수 있습니다.
유스 케이스 설명을 검사하여 시스템의 내부 작동이 명확히 정의되었는지 확인하십시오. 시스템이 수행해야 하는 사항을 확실히 하도록 시스템의 내부 작동이 명백해야 합니다. 해당 작동을 수행하는 책임이 있는 시스템 내 요소(객체)를 설명할 필요가 없습니다. 단지 완료되어야 하는 사항에 대한 명확한 설명만이 필요합니다.
이 세부사항에 대한 정보의 소스에는 시스템이 수행해야 하는 사항을 정의하는데 도움을 줄 수 있는 도메인 전문가가 포함됩니다. 시스템의 특정 작동 고려시 질문해야 할 좋은 질문은 "시스템이 해당 사항을 수행하는 것이 무슨 의미가 있습니까?"입니다. 시스템이 작동을 수행하기 위해 시행하는 사항이 해당 질문에 답을 줄만큼 제대로 정의되지 않은 경우, 알아야 할 정보가 더 있을 가능성이 큽니다.
다음 대안은 이벤트 플로우의 설명을 보충하기 위해 존재합니다.
목적 | 유스 케이스에 설명된 작동을 수행할 수 있는 모델 요소(분석 클래스)의 후보 세트를 식별하기 위함입니다. |
분석 클래스의 후보 세트를 찾는 것이 필수 작동의 단순한 표현에서 시스템 작동 방법의 설명으로 시스템을 변형하는 데 있어 첫 단계입니다. 이 노력에서 분석 클래스를 사용하여 유스 케이스가 지정한 기능적 요구사항 및 보충 요구사항이 지정한 비기능적 요구사항을 이행하는 필수 작동을 제공하는 모델 요소의 역할을 표시합니다. 프로젝트의 초점이 설계로 이동해 감에 따라 해당 역할은 유스 케이스를 구현하는 설계 요소의 세트로 전개됩니다.
유스 케이스 분석에 식별된 역할은 주로 도메인 특정 작동 및 시스템 어플리케이션 특정 작동의 최상위 계층의 작동을 표현합니다. 경계 클래스 및 제어 클래스는 일반적으로 어플리케이션 계층 설계 요소로 전개되는 반면 엔티티 클래스는 도메인 특정 설계 요소로 전개됩니다. 낮은 계층의 설계 요소는 일반적으로 여기서 식별된 분석 클래스가 사용하는 분석 메커니즘에서 전개됩니다.
여기에서 설명된 기술이 시스템의 세 가지 다른 Perspective를 사용하여 후보 클래스의 식별을 구동합니다. 세 가지 Perspective는 시스템 및 수행자 간의 경계, 시스템이 사용하는 정보 및 시스템의 제어 논리입니다. 대응하는 클래스 스테레오타입, 경계, 엔티티 및 제어는 분석 중에 사용되고 설계시 없어지는 편리한 사항입니다.
클래스 식별은 간단히 몇 문장으로 식별되고 이름지정되며 설명되어야 함을 의미합니다.
분석 클래스 식별에 대한 자세한 정보는 가이드라인: 분석 클래스를 참조하십시오. 분석 유스 케이스 구현에 대한 자세한 정보는 가이드라인: 유스 케이스 구현을 참조하십시오.
특정 분석 메커니즘 및/또는 분석 패턴이 프로젝트 특정 가이드라인에 문서화된 경우, 분석 클래스에 "영감"을 주는 기타 소스로 사용되어야 합니다.
목적 | 공동 작업 분석 클래스의 관점에서 유스 케이스 작동을 표현하기 위함입니다. 분석 클래스의 책임을 판별하기 위함입니다. |
각 독립적 하위 플로우(시나리오)의 경우 다음을 수행하십시오.
유스 케이스 적립금 항목 받기의 의사소통 다이어그램.
특정 분석 메커니즘 및/또는 분석 패턴이 프로젝트 특정 가이드라인에 문서화된 경우, 결과 상호작용 다이어그램 및 책임 할당에 반영되어야 합니다.
목적 | 유스 케이스 작동에서 식별된 객체 클래스의 책임을 설명하기 위함입니다. |
책임은 객체가 제공하도록 요청될 수 있는 사항의 표현입니다. 책임은 설계시 클래스의 한(일반적으로 하나 이상) 조작으로 전개됩니다. 다음과 같은 특성이 있습니다.
각 분석 클래스에는 여러 책임이 있어야 합니다. 오직 한 책임이 있는 클래스는 너무 간단할 가능성이 있는 반면 12개 이상이 있는 클래스는 책임의 한계를 넘으므로 잠재적으로 여러 클래스로 분리되어야 합니다.
모든 객체가 작성되고 삭제될 수 있다는 것은 언급할 가치도 없습니다. 객체가 작성되고 삭제될 때 일부 특수 작동을 수행하지 않는 한 명백한 사항을 다시 설명하지 마십시오(특정 관계가 있는 경우 일부 객체가 제거될 수 없음).
책임은 상호작용 다이어그램의 메시지에서 파생됩니다. 각 메시지에 대해 메시지가 전송될 객체의 클래스를 검사하십시오. 책임이 아직 없는 경우, 요청된 작동을 제공하는 새 책임을 작성하십시오.
기타 책임은 비기능적 요구사항에서 파생됩니다. 새 책임 작성 시, 적용되는 관련 요구사항이 있는지 확인하도록 비기능적 요구사항을 검사하십시오. 책임의 설명을 증대하거나 새 책임을 작성하여 이를 반영하십시오.
책임이 책임에 대한 짧은 이름(최대 몇 단어)과 짧은 설명(최대 몇 문장)으로 문서화됩니다. 설명은 객체가 책임을 이행하기 위해 수행하는 사항 및 책임 호출시 리턴되는 결과를 설명합니다.
목적 | 분석 클래스가 의존하는 기타 클래스를 정의하기 위함입니다. 클래스가 반드시 알아야 하는 기타 분석 클래스의 이벤트를 정의하기 위함입니다. 분석 클래스가 유지보수할 책임이 있는 정보를 정의하기 위함입니다. |
해당 책임을 수행하기 위해 클래스가 자주 기타 클래스에 의존하여 필수 작동을 공급합니다. 연관이 클래스 간의 관계를 문서화하고 클래스 결합을 이해하는데 도움이 됩니다. 클래스 결합을 더 잘 이해하고 가능한 경우 결합을 감소하여 보다 탄력적인 시스템을 잘 빌드하는데 도움을 줄 수 있습니다.
다음 단계가 클래스 간의 연관 및 클래스 속성을 정의합니다.
속성은 클래스가 정보를 저장하는데 사용합니다. 특히, 속성은 정보가 다음과 같은 경우 사용됩니다.
한편, 정보에 복잡한 작동이 있거나 둘 이상의 객체가 공유하거나 둘 이상의 객체 간에 "참조별"로 전달되는 경우 정보는 별도 클래스로 모델화되어야 합니다.
속성 이름은 속성이 보유하는 정보를 분명히 설명하는 명사여야 합니다.
속성의 설명은 속성에 저장될 정보를 설명해야 합니다. 저장된 정보가 속성 이름으로부터 분명한 경우 선택사항일 수 있습니다.
속성 유형은 속성의 단순 데이터 유형입니다(예: 문자열, 정수, 숫자).
분석 클래스에 작동 분배에 작성된 상호작용 다이어그램의 링크를 학습하여 시작하십시오. 클래스 간의 링크가 두 클래스의 객체가 유스 케이스를 수행하기 위해 서로 의사소통해야 함을 표시합니다. 시스템 설계를 시작하고 나면 이러한 링크가 다음과 같은 여러 방법으로 구현될 수도 있습니다.
그러나 이 클래스 "라이프"의 초기 지점에서는 이러한 사항을 판별하는 것이 너무 이릅니다. 제대로 교육된 결정을 하기에는 아직 정보가 충분하지 않습니다. 결과적으로, 분석에서 연관 및 집합을 작성하여 두 클래스의 객체 간의 전송되어야 하는 임의의 메시지를 표시(및 "전달")합니다. 특별한 양식의 연관인 집합은 "전체/일부" 연관에 관련된 객체를 표시합니다(가이드라인: 연관 및 가이드라인: 집합 참조).
활동: 클래스 설계에서 이러한 연관과 집합을 정제합니다.
각 클래스에 대해 각 클래스와 다른 클래스의 연관을 표시하는 다음과 같은 클래스 다이어그램을 그리십시오.
주문 입력 시스템의 일부에 대한 분석 클래스 다이어그램 예제
유스 케이스를 구현하는데 필요한 연관에만 집중하십시오. 상호작용 다이어그램을 기반으로 필수인 경우가 아니면 존재할 "수도" 있다고 생각되는 연관은 추가하지 마십시오.
연관 역할 이름과 다양성을 제공하십시오.
연관의 간략한 설명을 작성하여 연관이 사용되는 방법 또는 연관이 표시하는 관계를 표시하십시오.
때때로 객체가 일부 "대상" 객체에서의 이벤트 발생 시기를 알아야 하며 "대상"은 이벤트 발생시 통보되어야 하는 모든 객체를 알 필요가 없습니다. 이 이벤트 통보 종속성을 표시하는 약칭으로서 등록-연관을 사용하여 압축되고 간결한 방법으로 이 종속성을 표현할 수 있습니다.
두 객체 간의 등록-연관은 등록된 객체에서 특정 이벤트 발생시 등록 객체에게 알려야하는 것을 표시합니다. 등록-연관에는 신청자에게 알려야 하는 이벤트를 정의하는 조건이 있습니다. 자세한 정보는 가이드라인: 등록-연관을 설명하십시오.
등록-연관의 조건은 특정 속성 또는 조작의 관점이 아니라 추상 특성의 관점에서 표현되어야 합니다. 이런 식으로, 연관 객체가 변경될 가능성이 있는 연관된 엔티티 객체의 컨텐츠에 독립적으로 유지됩니다.
다음의 경우 등록-연관이 필수입니다.
'등록 대상'인 객체는 일반적으로 엔티티 객체입니다. 엔티티 객체는 일반적으로 정보 저장영역 책임과 연관된 임의의 작동이 있는 정보의 수동 저장 영역입니다. 종종 기타 여러 객체가 엔티티 객체의 변경 시기를 알아야 합니다. 등록-연관이 엔티티 객체가 이러한 기타 모든 객체에 대해 알아야 함을 예방합니다. 이러한 객체는 엔티티 객체에 흥미를 단순히 '등록'하고 엔티티 객체가 변경되면 통보됩니다.
이제 이것은 모두 '분석 역량'일뿐입니다. 설계시 이 통보가 작동하는 정확한 방법을 정의해야 합니다. 통보 프레임워크를 구입하거나 스스로 설계 및 빌드해야 할 수도 있습니다. 그러나 현재로서는 통보가 있음을 단지 기록하는 것으로 충분합니다.
연관의 방향은 등록 객체만이 두 객체 간의 관계를 알고 있음을 표시합니다. 등록의 설명은 전적으로 등록 객체 내에 있습니다. 차례로 연관된 엔티티 객체는 기타 객체가 이 활동에 흥미가 있을 수도 있음을 고려하지 않고 일반적인 방식으로 정의됩니다. 이는 또한 등록 객체가 등록하는 대상 객체를 변경하지 않고 모델에 추가되거나 제거될 수 있음을 함축합니다.
목적 | 개별 분석 유스 케이스 구현을 조정하고 일관된 관계에 있는 분석 클래스의 세트를 식별하기 위함입니다. |
분석 유스 케이스 구현은 특정 유스 케이스를
분석한 결과로서 개발되었습니다. 이제 개별
분석 유스 케이스 구현이 조정되어야 합니다. 각 분석
유스 케이스 구현에 정의된 지원 연관 및 분석
클래스를 검사하십시오. 불일치를
식별하고 해결한 다음 임의의 중복을 제거하십시오. 예를 들어,
두 다른 분석 유스 케이스 구현에는 개념적으로 동일한 분석 클래스가 포함될
수도 있습니다. 그러나 분석 클래스가 다른 설계자에
의해 식별되므로 다른 이름이 사용됩니다.
주: 소프트웨어 아키텍트가 초기 구조를
잘 정의하면 분석 유스 케이스 구현에 걸친 중복은 상당히 감소될 수
있습니다(활동: 구조 분석 참조).
모델 요소 조정시, 해당 요소 간의 관계를 고려하는 것이 매우 중요합니다. 두 클래스가 병합되거나 한 클래스가 다른 클래스를 대체하는 경우, 새 클래스에 원래 클래스의 관계를 전달하도록 하십시오.
소프트웨어 아키텍트가 분석 유스 케이스 구현의 조정에 참여해야 합니다. 왜냐하면 문제점과 솔루션 도메인을 가장 잘 표시하는 분석 클래스가 선택될 수 있도록 해당 구현이 소프트웨어 구조 및 설계의 일부 전망뿐 아니라 비즈니스 컨텍스트의 이해도 요구하기 때문입니다.
클래스에 대한 자세한 정보는 가이드라인: 분석 클래스를 참조하십시오.
목적 | 분석 클래스가 사용하는 분석 메커니즘(있는 경우)을 식별하기 위함입니다. 분석 클래스가 분석 메커니즘에 적용되는 방법에 대한 추가 정보를 제공하기 위함입니다. |
이 단계에서 식별된 각 분석 클래스에 적용된 분석 메커니즘이 검사됩니다.
분석 클래스가 하나 이상의 분석 메커니즘을 사용하는 경우, 이제 캡처된 추가 정보가 소프트웨어 아키텍트와 설계자를 도와 구조적 설계 메커니즘에 필수인 성능을 판별합니다. 분석 클래스의 인스턴스 수, 크기, 액세스 빈도 및 예상 수명 범위는 적절한 메커니즘을 선택하는데 설계자를 도울 수 있는 중요한 특성입니다.
분석 클래스가 사용하는 각 분석 메커니즘의 경우, 적절한 설계 및 구현 메커니즘 선택시 고려되어야 하는 관련 특성을 검증합니다. 메커니즘의 유형에 따라 달라집니다. 적절한 경우 또는 여전히 불확실성이 많은 경우 범위를 제공하십시오. 다른 구조적 메커니즘에 다른 특성이 있으므로 이 정보는 순전히 설명적이며 정보를 캡처하고 전달하는데 필요한 정도로만 구조화되어야 합니다. 분석 중에, 일반적으로 이 정보는 매우 추론적이지만 확실치 않은 추측값이 더 자세한 정보가 밝혀짐에 따라 교정될 수 있으므로 캡처하는 것은 가치가 있습니다.
클래스 및 연관된 특성이 사용하는 분석 메커니즘은 공식적인 방식으로 캡처될 필요가 없습니다. 다이어그램에 첨부된 주 또는 클래스의 설명에 대한 확장이 정보를 전달하는데 충분합니다. 클래스 전개에서 이 지점의 특성 정보는 매우 유동적이고 추론적이므로 메커니즘의 정의를 형식화하기 보다는 예상 값을 캡처하는 데 중요성이 있습니다.
예
항공편 클래스가 사용하는 지속성 메커니즘의 특성은 다음과 같이 규정될 수 있습니다.
세분성: 항공편당 2 - 24KB
볼륨: 최대 100,000
액세스 빈도:
- 작성/제거: 시간당 100번
- 갱신: 시간당 3,000번 갱신
- 읽기: 시간당 9,000번 액세스
예
임무 클래스가 사용하는 지속성 메커니즘의 특성은 다음과 같이 규정될 수 있습니다.
세분성: 임무당 2 - 3MB
볼륨: 4
액세스 빈도:
- 작성/삭제: 하루에 1번
- 갱신: 하루에 10번
- 읽기: 시간당 100번
목적 | 분석 모델 및 기타 모델 간의 추적성 관계를 유지보수하기 위함입니다. |
프로젝트의 프로젝트 특정 가이드라인이 분석 모델 요소에 필수인 추적성을 지정합니다.
예를 들어, 사용자 인터페이스의 별도 모델이 있는 경우, 화면 또는 해당 모델의 사용자 인터페이스 요소를 분석 모델의 경계 클래스로 추적하는 것이 유용할 수도 있습니다.
목적 | 분석 객체가 시스템에 작성된 기능적 요구사항을 충족하는지 확인하기 위함입니다. 분석 객체 및 상호작용이 일치하는지 확인하기 위함입니다. |
워크샵의 마지막에서 검토를 활동: 유스 케이스 분석의 결론뿐 아니라 동기화 지점으로서 비공식적으로 수행하십시오.
이 활동으로 결과물 출력에 대한 체크포인트를 사용하십시오.
Rational Unified Process
|