2016-09-13 12 views
2

나는 모든 디자인 요구 사항을 문서화하고 있으며, 유스 케이스 다이어그램을 사용하여 디자인 패러다임을 처음 접하고 있습니다. 나는 전반적인 시스템 요구 사항을 포함하는 highlevel usecase 다이어그램을 가지고있다. 그리고 나서, 각각의 유스 케이스에 대한 상세 레벨 유스 케이스 다이어그램이 하이 레벨 유스 케이스 다이어그램에 정의되어 있습니다. 이제 세부 수준 다이어그램에서 시스템 자체가 트리거하는 용도를 포함 시켰습니다.세부 수준 유스 케이스 다이어그램 생성

높은 수준의 쓰임새 - 업로드 보고서 업로드 보고서 파일에 대한

상세 수준의 유스 케이스 파일 : 위의 그림에서,

enter image description here

여기를의 쓰임새 1.3, 1.4 및 1.5은 시스템이 발동된다 유스 케이스는 사용자와 직접 상호 작용하지 않습니다.

내 질문에 이러한 유형의 시스템 수준 유스 케이스가 세부 유스 케이스 다이어그램에 포함되어야합니까, 아니면 단지 사용자와 상호 작용하는 유스 케이스 만 포함해야합니까?

P. 위의 작업이 유효하지 않은 경우 (다이어그램에 표시된대로 usecase 다이어그램을 생성하는 방식) 권장 사항을 알려주십시오.

+0

Bittner/Spence를 읽는 것이 좋습니다. 유스 케이스를 만들지 않고 기능적 분해를 시도하고 있습니다. –

+0

알겠습니다. 정보를 제공해 주셔서 감사합니다. 나는 일종의 기능적인 방식으로 제작하고있는 유스 케이스를 그런 식으로 느낀다. 어쨌든, 그 대신 내가 무엇을 할 수 있는지 말해 주시면 감사하겠습니다. 내 사건에 대한 해결책을 좀 주시겠습니까? 한편, 나는 당신의 추천 도서를 공부할 것입니다. –

답변

1

음, 실제로 대답은 아니지만 조언. 여기서 문제는 지금까지 디자인을 덤프하고 처음부터 시작해야한다는 것입니다. 그리고 물론 불가능합니다. 안내 사항 :

  • 기능이 아닌 부가가치를 찾으십시오.
  • (!) include/extend를 사용하지 말고 액터와 유스 케이스 사이에 간단한 연관을 그립니다.
  • 각 유스 케이스마다 자신에게 물어보십시오. 대답이 '예'인 경우에만 풍선을 추가하십시오.
  • 각 사용 사례에 동사/주제 (결국 객체)를 붙입니다.
  • 다이어그램에 주 배우 만 사용하고 보조 액터는 사용하지 마십시오.
  • UC 다이어그램이 스파이더 웹과 닮기 시작하면 디자인이 손상 될 수 있습니다.
  • 절대 숫자는 없지만 일반적으로 소수의 배우와 수십 개의 UC로 끝납니다.
+0

귀하의 대답은 정말 분명하고 유익합니다. 고맙습니다. –