사용 사례 다이어그램에 포함과 확장의 차이점은 무엇입니까?

차이 란 include및 extendA의 사용 사례도 ?

확장 은 유스 케이스가 다른 일류 유스 케이스에 단계를 추가 할 때 사용됩니다.

예를 들어 "현금 인출"이 현금 자동 입출금기 (ATM)의 사용 사례라고 가정하십시오. "평가 수수료"는 현금 ​​인출을 확장하고 ATM 사용자가 ATM 소유 기관에서 은행을 이용할 때 인스턴스화 되는 조건부 "확장 점"을 설명합니다 . "현금 인출"기본 사용 사례는 확장없이 그대로 유지됩니다.

포함 은 여러 사용 사례에서 중복 된 사용 사례 조각을 추출하는 데 사용됩니다 . 포함 된 사용 사례는 독립형 일 수 없으며 포함 된 사용 사례가 없으면 원래 사용 사례가 완료되지 않습니다. 이것은 중복이 중요하고 의도적으로 (우연이 아닌) 의도적으로 존재하는 경우에만 드물게 사용해야합니다.

예를 들어, 모든 ATM 사용 사례가 시작될 때 (사용자가 ATM 카드를 넣고 PIN을 입력하고 주 메뉴가 표시 될 때) 발생하는 이벤트 흐름은 포함에 적합한 후보입니다.

이것은 논쟁의 여지가 있지만“항상 포함하고 확장하는 경우가있다”는 것은 사실상 사실상의 의미로 거의 받아 들여진 매우 일반적인 오해입니다. 올바른 접근 방식이 있습니다 (제 생각에 Jacobson, Fowler, Larmen 및 10 개의 다른 참조에 대해 확인했습니다).

관계는 의존성

유스 케이스 관계를 포함하고 확장하는 핵심은 UML의 나머지 부분과 마찬가지로 유스 케이스 사이의 점선 화살표가 종속성 관계임을 인식하는 것입니다. 'base', 'included'및 'extending'이라는 용어를 사용하여 유스 케이스 역할을 언급합니다.

포함

기본 사용 사례는 포함 된 사용 사례에 따라 다릅니다. 포함되지 않은 사용 사례는 항상 또는 때때로 발생할 수있는 상호 작용의 하위 시퀀스를 나타내므로 기본 사용 사례는 불완전합니다. (이것은 일반적인 시나리오에서 유스 케이스가 항상 주 시나리오에서 발생하고 때로는 대체 흐름에서 발생하는 경우가 단순히 기본 시나리오로 선택한 것에 따라 달라집니다. 유스 케이스는 다른 플로우를 나타내도록 쉽게 재구성 될 수 있습니다) 주요 시나리오로 중요하지 않습니다).

단방향 종속성의 모범 사례에서 기본 유스 케이스는 포함 된 유스 케이스를 알고 있고 참조하지만 포함 된 유스 케이스는 기본 유스 케이스에 대해 '알지'않아야합니다. 이것이 포함 된 유스 케이스가 다음과 같은 이유 일 수 있습니다. a) 자체 유스의 기본 유스 케이스 및 b) 많은 기본 유스 케이스가 공유합니다.

넓히다

확장 사용 사례는 기본 사용 사례에 따라 다릅니다. 기본 유스 케이스에 설명 된 동작을 그대로 확장합니다. 기본 유스 케이스는 확장 유스 케이스의 추가 기능없이 자체 기능 ( '포함'포함)의 완전한 기능 유스 케이스 여야합니다.

여러 상황에서 사용 사례 확장을 사용할 수 있습니다.

1. 기본 유스 케이스는 프로젝트의 "필수"기능을 나타내며 확장 유스 케이스는 선택적 (should / could / want) 동작을 나타냅니다. 선택적이라는 용어는 관련이있는 곳입니다. 때로는 기본 유스 케이스 시퀀스의 일부로 실행되는지 여부는 선택적이 아니라 빌드 / 제공 여부입니다.
2. 1 단계에서는 해당 시점의 요구 사항을 충족하는 기본 사용 사례를 제공 할 수 있으며 2 단계에서는 확장 사용 사례에서 설명하는 추가 기능을 추가합니다. 여기에는 2 단계가 전달 된 후 (일반적인 오해와는 달리) 항상 또는 때때로 수행되는 시퀀스가 ​​포함될 수 있습니다.
3. 기본 유스 케이스의 서브 시퀀스를 추출하는 데 사용할 수 있습니다. 특히 자체 흐름으로 '예외'복잡한 동작을 나타내는 경우에 사용됩니다.

고려해야 할 한 가지 중요한 측면은 확장 된 사용 사례는 포함 된 사용 사례처럼 단일 장소가 아니라 기본 사용 사례 흐름의 여러 위치에서 동작을 '삽입'할 수 있다는 것입니다. 이러한 이유로, 확장 사용 사례가 하나 이상의 기본 사용 사례를 확장하기에 적합하지 않을 가능성이 높습니다.

종속성과 관련하여 확장 사용 사례는 기본 사용 사례에 종속되며 다시 단방향 종속성입니다. 즉, 기본 사용 사례는 시퀀스에서 확장 사용 사례에 대한 참조가 필요하지 않습니다. 그렇다고 템플릿의 다른 곳에서 확장 점을 보여 주거나 확장 사용 사례에 x-ref를 추가 할 수는 없지만 기본 사용 사례는 확장 사용 사례없이 작동 할 수 있어야합니다.

요약

“포함은 항상, 때로는 확장이다”라는 일반적인 오해가 잘못되었거나 가장 단순하다는 것을 보여 주었기를 바랍니다. 이 버전은 오해가 나타내는 화살표의 방향성에 관한 모든 문제를 고려할 때 실제로 더 의미가 있습니다. 올바른 모델에서는 의존성이며 유스 케이스 컨텐츠를 리팩토링해도 변경되지 않습니다.

나는 종종 이것을 사용하여 두 가지를 기억합니다.

나의 유스 케이스 : 나는 도시로 간다.

포함-> 자동차 운전

연장-> 휘발유 채우기

"연료 충전"은 항상 필요하지는 않지만 차에 남아있는 가솔린의 양에 따라 선택적으로 필요할 수 있습니다. "자동차 운전"은 전제 조건이므로 제가 포함합니다.

사용 사례는 행동을 문서화하는 데 사용됩니다 (예 :이 질문에 대답).

행동은 행동에 추가 될 수는 있지만 행동의 일부일 필요는없는 경우 다른 것으로 확장됩니다 (예 : 답 연구).

또한 질문에 대답하지 않으면 답을 연구하는 것이 의미가 없습니다.

동작이 포함 동작의 일부인 경우 다른 동작에 포함됩니다 (예 : 로그인하여 스택 교환으로).

명확히하기 위해 그림은 스택 오버플로에서 여기에 대답하려는 경우에만 적용됩니다 :).

이들은 UML 2.5 페이지 671-672 의 기술적 정의입니다 .

나는 내가 중요하다고 생각하는 것을 강조했다.

연장

확장은 확장 UseCase (확장) 에서 확장 UseCase에 정의 된 동작을 확장 UseCase에 정의 된 동작에 삽입 할 수있는 방법과시기를 지정하는 확장 UseCase ( extendCase ) 와의 관계 입니다 . 확장은 확장 된 UseCase에 정의 된 하나 이상의 특정 확장 점에서 발생합니다.

Extend는 하나 이상의 UseCases에 정의 된 동작에 조건부 로 추가해야하는 추가 동작이있을 때 사용됩니다 .

확장 유스 케이스는 연장 유스 케이스와 독립적으로 정의되고 독립적으로 연장 유스 케이스의 의미이다 . 반면, 확장 된 UseCase는 일반적으로 반드시 의미가있는 행동을 정의 합니다 . 대신, 확장 된 UseCase는 특정 조건에서 확장 된 UseCase의 실행을 향상시키는 모듈 식 동작 증분 세트를 정의합니다.

...

포함

포함은 두 개의 UseCase 간의 DirectedRelationship이며 포함 된 UseCase (추가) 의 동작이 포함하는 UseCase ( includeCase)의 동작에 삽입 됨을 나타냅니다 . 또한 고유 한 UseCase (includeCase)의 컨텍스트에서 이름을 가질 수 있도록 일종의 NamedElement입니다. 포함 된 UseCase는 포함 된 UseCase를 실행하여 생성 된 변경 사항에 따라 달라질 수 있습니다. 포함 된 UseCase의 동작을 완전히 설명하려면 포함 된 UseCase를 사용할 수 있어야합니다.

포함 관계는 둘 이상의 UseCase 동작의 공통 부분이있을 때 사용됩니다. 그런 다음 이 공통 부분은 별도의 UseCase로 추출되어이 부분 이 공통 인 모든 기본 UseCase에 포함됩니다 . 포함 관계의 주요 용도는 공통 부품을 재사용하는 데 사용되므로 기본 UseCase에 남아있는 것은 일반적으로 자체적으로 완료되지 않지만 포함 된 부품에 따라 의미가 있습니다. 이것은 관계의 방향에 반영되어 기본 UseCase가 추가에 의존하지만 그 반대는 아니라는 것을 나타냅니다.

...

포함과 확장의 의도를 이해하는 것이 중요하다고 생각합니다.

는 "이 관계를위한 것입니다 포함 재사용 으로 모델링 행동 다른 사용 사례를 확장 관계를위한 것입니다 반면, 추가 사용 사례를 기존 부품 뿐만 아니라 위한 모델링 옵션 사용 사례 시스템 서비스를"(Overgaard 및 Palmkvist :. 패턴과 청사진을 애디슨 -Wesley, 2004).

이것은 나에게 다음과 같이 읽습니다.

포함 = 기능 재사용 (즉, 포함 된 기능이 사용되거나 시스템의 다른 곳에서 사용될 수 있음) 따라서 포함은 다른 사용 사례에 대한 종속성을 나타냅니다.

= 확장 추가 (재사용되지 않음) 기능과 또한 모든 옵션 기능을. 따라서 확장은 다음 두 가지 중 하나를 나타낼 수 있습니다.
1. 유스 케이스에 새 기능 / 기능 추가 (선택적 여부)
2. 선택적 유스 케이스 (존재 여부).

요약 :
포함 = 기능 재사용
확장 = 새로운 기능 및 / 또는 선택적 기능

기능이 선택 사항이 아닌 경우 대부분 확장이 아닌 유스 케이스 자체에 내장되므로 확장의 두 번째 사용법 (예 : 선택적 기능)이 가장 많이 발견됩니다. 적어도 그것은 내 경험이었습니다. (Julian C는 프로젝트가 2 단계에 진입 할 때 첫 번째 사용법 (즉, 새로운 기능 추가)이 확장되는 경우가 있음)을 지적합니다.

단순화하기 위해

...에 대한 include

1. 기본 사용 사례가 실행될 때 포함 된 사용 사례는 EVERYTIME 으로 실행 됩니다 .
2. 기본 사용 사례를 완료하려면 포함 된 사용 사례를 완료해야합니다.

일반적인 예 : 로그인과 비밀번호 확인 사이

(로그인) --- << 포함 >> --- > (암호 확인)

로그인 프로세스가 성공하려면 "암호 확인"도 성공해야합니다.

...에 대한 extend

1. 기본 유스 케이스가 실행될 때 확장 유스 케이스는 SOMETIMES 만 실행됩니다 .
2. 확장 사용 사례는 특정 기준을 충족하는 경우에만 발생합니다.

일반적인 예 : 로그인과 표시 오류 메시지 사이 (때로 만 발생)

(로그인) < --- << extend >> --- (오류 메시지 표시)

"오류 메시지 표시"는 로그인 프로세스가 실패한 경우에만 발생합니다.

msdn이 여기 에 설명 한 내용 은 이해하기 쉽다고 생각합니다 .

포함 [5]

포함 사용 사례는 포함 된 사용 사례를 호출하거나 호출합니다. 포함은 사용 사례가 더 작은 단계로 어떻게 진행되는지 보여주기 위해 사용됩니다. 포함 된 사용 사례는 화살촉 끝에 있습니다.

확장 [6]

한편 확장 사용 사례는 확장 사용 사례에 목표와 단계를 추가합니다. 확장은 특정 조건에서만 작동합니다. 확장 된 사용 사례는 화살촉 끝에 있습니다.

이것을 더 명확하게합시다. 우리 include는 한 사례의 존재가 다른 사례의 존재에 달려 있다는 사실을 표현하고자 할 때마다 사용 합니다.

예 :

사용자는 자신의 계정에 로그인 한 후에 만 ​​온라인 쇼핑을 할 수 있습니다. 다시 말해, 자신의 계정에 로그인하기 전까지는 쇼핑을 할 수 없습니다.

자료가 업로드되기 전에 사이트에서 사용자를 다운로드 할 수 없습니다. 업로드 된 내용이 없으면 다운로드 할 수 없습니다.

이해하십니까?

조건부 결과에 관한 것입니다. 이전에하지 않았다면이 작업을 수행 할 수 없습니다 .

적어도 이것이 우리가 사용하는 올바른 방법이라고 생각합니다 Include. 나는 위의 노트북과 보증의 예가 가장 설득력이 있다고 생각하는 경향이 있습니다!

유스 케이스에 전제 조건이있을 때마다 include로 이동하십시오.

인증이있는 유스 케이스, 최악의 시나리오 또는 선택 사항 인 경우 확장을 수행하십시오.

예 : 입학, 예약, 항공권 예약을 원하는 유스 케이스의 경우 양식 (등록 또는 피드백 양식)을 작성해야합니다.

예 : 로그인 또는 계정 로그인을 확인하는 유스 케이스의 경우, 인증은 필수입니다. 또한 책을 반납하는 등 최악의 시나리오를 생각해야합니다. 예약을받지 않습니다. 확장이 재생되는 곳 ...

다이어그램에서 포함 및 확장을 과도하게 사용하지 마십시오.

간단하게 웃으세요 !!!

또한 UML 버전에주의하십시오 : << uses >> 및 <include >>가 << include >>로, << extends >> <<extend >> AND 일반화 가 된 지 오래되었습니다 .
나를 위해 그것은 종종 오해의 소지가 있습니다 : 예를 들어 Stephanie의 게시물과 링크는 이전 버전에 관한 것입니다.

상품 대금을 결제 할 때 배송료 지불, 페이팔 결제 또는 카드 결제를 선택할 수 있습니다. 이들은 "항목에 대한 지불"사용 사례에 대한 모든 대안입니다. 선호도에 따라 이러한 옵션 중 하나를 선택할 수 있습니다.

실제로 "항목 지불"에 대한 대안은 없습니다! 요즘 UML에서 "Pay on Delivery"는 연장되며 "Paypal을 사용한 지불"/ "Pay by card"는 전문화 영역입니다.

"포함"은 기본 사용 사례를 확장하는 데 사용되며 필수 조건입니다. 즉 기본 사용을 완료하려면 포함 된 사용 사례 실행을 성공적으로 실행해야합니다.

예 : 이메일 서비스의 경우를 고려하십시오. 여기에서 "로그인"은 이메일을 보내기 위해 실행해야하는 포함 된 사용 사례입니다 (기본 사용 사례).

반면에 "제외"는 기본 사용 사례를 확장하는 선택적 사용 사례이며 확장 사용 사례를 호출 / 호출하지 않아도 기본 사용 사례를 성공적으로 실행할 수 있습니다.

예 : 기본 사용 사례로 "랩탑 구매"를, 확장 사용 사례로 "추가 보증"을 고려하면 추가 보증없이 기본 사용 사례 "랩탑 구매"를 실행할 수 있습니다.

이것은 훌륭한 설명과 함께 훌륭한 자료입니다. 사용 사례에는 무엇이 포함됩니까? 사용시 확장이란 무엇입니까?

유스 케이스 확장은 일반적으로 선택적 동작을 정의합니다. 그것은 인 독립 연장 유스 케이스

둘 이상의 사용 사례 동작의 공통 부분을 추출하는 데 사용

다이어그램 요소

• 배우 : 역할이라고도합니다. 액터의 이름과 스테레오 타입은 속성 탭에서 변경할 수 있습니다.

• 상속 : 액터 간의 세분화 관계. 이 관계에는 이름과 고정 관념이 포함될 수 있습니다.

• 사용 사례 : 확장 점을 가질 수 있습니다.

• 확장 점 : 확장을 추가 할 수있는 위치를 정의합니다.

• 연관성 : 역할과 사용 사례 간. 협회가 말하는 이름을 알려주는 것이 좋습니다.

• 종속성 : 사용 사례 간 종속성은 종종 종속성의 역할을 더 잘 정의하기 위해 고정 관념을 갖습니다. 스테레오 타입을 선택하려면 다이어그램 또는 탐색 분할 창에서 종속성을 선택한 다음 특성 탭에서 스테레오 타입을 변경하십시오. : 두 가지 특별한 종속성 종류가 있습니다 <<extend>>와 <<include>>포세이돈은 자신의 버튼 (아래 참조)를 제공하는이.

• 관계 확장 : 두 사용 사례 간의 단방향 관계. 유스 케이스 B와 유스 케이스 A 사이의 확장 관계는 B의 동작이 A에 포함될 수 있음을 의미합니다.

• 관계 포함 : 두 사용 사례 간의 단방향 관계. 유스 케이스 A와 B 간의 이러한 관계는 B의 동작이 항상 A에 포함됨을 의미합니다.

• 시스템 경계 : 시스템 경계는 실제로 UML 용 Poseidon에서 모델 요소로 구현되지 않습니다. 사각형을 그려서 배경으로 보내고 사각형에 해당하는 모든 사용 사례를 넣어 시스템 테두리로 사용할 수 있습니다.

모두 <include>와 <extend>기본 클래스에 의존하지만,<extend> 옵션 즉, 그것은 기본 클래스에서하지만 사용자의 시점에서 파생 된이 사용되거나 사용되지 않을 수 있습니다 볼 수 있습니다.

<include> 기본 클래스에 통합되어 있어야합니다. <include> 유스 케이스에 사용해야합니다. 그렇지 않으면 불완전한 것으로 간주됩니다.

예 :

ATM 기계 구성 (사용자 관점에 따라) :

1 : 출금, 현금 입금 및 계좌 확인 <extend>은 사용자의 출금 또는 입금 또는 확인 여부에 달려 있기 때문에 이루어집니다. 이들은 사용자가하는 선택 사항입니다.

2 : "핀 입력, 카드 배치, 카드 제거"이들은 <include>사용자가 카드를 배치하고 확인을 위해 유효한 핀을 입력해야하기 때문에 제공되는 것입니다 .

나는 이것을 사용하여 두 가지를 기억하지 않는 것이 좋습니다.

나의 유스 케이스 : 나는 도시로 간다.

포함-> 자동차 운전

연장-> 휘발유 채우기

차라리 당신은 다음을 사용합니다 : 나의 유스 케이스 : 나는 도시로갑니다.

연장-> 자동차 운전

포함-> 휘발유 채우기

관계 확장은 기본 수업의 행동을 계속한다고 가르친다. 기본 클래스 기능이 있어야합니다. 반면에 포함 관계는 호출 될 수있는 기능과 유사합니다. 5 월은 굵게 표시됩니다.

이는 사용 사례 모델의 민첩한 모델링 재사용에서 확인할 수 있습니다.

두 가지의 차이점은 여기에 설명되어 있습니다. 그러나 설명되지 않은 것은<<include>> 및<<extend>> 단순히 전혀 사용하지 않아야은.

Bittner / Spence를 읽으면 사용 사례가 분석이 아니라 합성에 관한 것임을 알 수 있습니다. 유스 케이스를 재사용하는 것은 말도 안됩니다. 도메인을 잘못 자랐 음을 분명히 보여줍니다. 추가 된 값은 고유해야합니다. 내가 아는 부가 가치의 유일한 재사용은 프랜차이즈입니다. 버거 사업을하고 계시다면 좋습니다. 그러나 어디에서나 BA로서 당신의 임무는 USP를 찾으려고 노력하는 것입니다. 그리고 그것은 좋은 사용 사례에서 제시되어야합니다.

사람들이 그러한 관계 중 하나를 사용하는 것을 볼 때마다 기능적 분해를 시도 할 때입니다. 그리고 그것은 명백한 잘못입니다.

간단히 말해서 : "I done ..."을 주저하지 않고 상사에게 대답 할 수 있다면 "..."은 돈을 벌기 때문에 유스 케이스입니다. 또한 "로그인"이 사용 사례가 아님을 분명히 알 수 있습니다.

이와 관련하여 포함되거나 다른 사용 사례를 확장하는 자체 사용 사례를 찾는 것은 거의 불가능합니다. 결국 <<extend>>시스템의 선택 사항 (예 : 일부 라이센스의 사용 사례를 포함하거나 생략 할 수있는 라이센스 스키마)를 표시하는 데 사용할 수 있습니다. 그러나 그렇지 않으면-그냥 피하십시오.

연장 은 사용 사례가 너무 복잡하다는 것을 이해할 때 사용됩니다. 따라서 복잡한 단계를 자체 "확장"사용 사례로 추출합니다.

포함 은 두 가지 사용 사례에서 일반적인 동작을 볼 때 사용됩니다. 따라서 일반적인 동작을 별도의 "추상적 인"사용 사례로 추상화합니다.

(참조 : Jeffrey L. Whitten, Lonnie D. Bentley, 시스템 분석 및 설계 방법, McGraw-Hill / Irwin, 2007)

는 포함 관계는 하나 개의 사용 케이스는 다른 사용 사례의 단계를 포함 할 수있다.

예를 들어 Amazon 계정이 있고 주문을 확인하려고한다고 가정하면 먼저 계정에 로그인하지 않고 주문을 확인하는 것은 불가능합니다. 이벤트 흐름은 다음과 같습니다.

확장 관계는 일반적으로 선택적인 단계 인 사용 경우의 유동에 여분의 공정을 추가하는 데 사용된다 ..

우리가 여전히 귀하의 아마존 계정에 대해 이야기하고 있다고 상상해보십시오. 기본 사례는 Order 이고 확장 사례는 Amazon Prime 이라고 가정합니다 . 사용자는 항목을 정기적으로 주문하거나 Amazon Prime을 선택하여 주문이 더 높은 비용으로 더 빨리 도착할 수 있습니다.

그러나 사용자는 Amazon Prime을 선택할 필요가 없으며 이는 단지 옵션 일 뿐이며이 사용 사례를 무시하도록 선택할 수 있습니다.

"포함"을 기본 유스 케이스의 필수 전제 조건 / 반주로 생각합니다. 이는 기본 유스 케이스에 포함 된 유스 케이스가 없으면 기본 유스 케이스를 완료된 것으로 간주 할 수 없음을 의미합니다. 고객에게 상품을 판매하는 전자 상거래 웹 사이트의 예를 들겠습니다. 먼저 해당 항목을 선택하여 장바구니에 넣지 않으면 항목에 대해 지불 할 수있는 방법이 없습니다. 이는 사용 항목 "Pay for Item"에 "select item"이 포함되어 있음을 의미합니다.

확장의 용도는 다양하지만 사용하거나 사용하지 않을 수있는 대안으로 생각합니다. 예를 들어 여전히 전자 상거래 사이트에 있습니다. 상품 대금을 결제 할 때 배송료 지불, 페이팔 결제 또는 카드 결제를 선택할 수 있습니다. 이것들은 "항목에 대한 지불"사용 사례에 대한 모든 대안입니다. 선호도에 따라 이러한 옵션 중 하나를 선택할 수 있습니다.

더 명확하고 사용 사례와 관련된 규칙을 보려면 여기에서 내 기사를 읽으십시오.

http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics