예 :UML 2.0 유스 케이스간에 양방향 확장 관계를 가질 수 있습니까?
사용자가 우리 가게를 입력하고 몇 가지 음료를 주문하여 시작할 수 있습니다. 우리는 그에게 음식 아이템을 상향 판매 할 수 있습니다.
다른 방법으로도 가능합니다. 사용자가 샌드위치를 주문하고 음료수를 팔았습니다. 구매 음료는 음식을 살 수 있습니다.
이것을 모델링하는 올바른 방법일까요? 아니면 음료/구매 식품 구매를 전문으로하는 구매 품목을 갖기 때문에 일반화/전문화를 사용하는 것이 더 낫지는 않습니까?
아니면 다른 방법으로 ...?
<<extends>> (이 방법)을 사용할 때 기능 분해를 시도하고 있습니다. 유즈 케이스는 시스템의 기능적 분해가 아니라 고려중인 시스템 (SUC)이 고유 한 부가가치를 중심으로 액션을 합성하여 액터로 전달하는 경우입니다. 이 관점에서 본다. 그렇다면 SUC의 독창적 인 가치는 무엇입니까 (판매 시스템이라고 생각하십니까?). Sell Goods이고 Sell Food과 Sell Drinks 사이에 차이가 있거나 UC가 다르거 나없는 경우 두 가지 UC가 필요하지 않습니다.
확장은 결코 양방향입니다 (확장 관계는 항상 방향 지정입니다).
귀하의 경우에는 토마스 킬란 (Thomas Kilan)이 제안한 유스 케이스 하나만 있습니다.
유스 케이스가 차별화 된 상태로 계속 주장한다면 일반화가 좋은 선택이지만 대부분의 경우 불필요한 것입니다.
극히 드문 경우이지만 (분명히 귀하의 경우는 아님) 반대 방향으로 동일한 유스 케이스간에 두 가지 확장 관계를 사용하거나 (확장 관계를 사용하여 다른 형태의 사이클을 만드는 것을 금지하지는 않습니다) 시스템의 논리 (예 : 각각 별도로 또는 두 개 중 하나와 함께 시작된 것으로 처리 될 수있는 두 개의 독립 엔터티 관리). 실제로 이러한 사이클은 (미래의) 시스템 사용자와 논의하는 동안 해결 될 수 있으므로 피해야합니다. 반면에 include 관계는 결코 사이클을 만들 수 없으며 모델을 만들면 유효하지 않습니다.
어떤 시스템에 대해 "구매"와 부가 가치가 있다고 생각합니까? 배우 자체. 당신은 아마 POS를 설명하고 있습니다. 따라서 "Sell X"는 기본적으로 UC이어야합니다. –