2011-06-13 5 views
1

질문 : 시스템 내부 프로세스 또는 모듈을 유스 케이스 다이어그램에서 시스템 자체에 대해 특정 기능을 수행하는 액터로 설명 할 수 있습니까?사용 사례 다이어그램

질문에 대한 설명이 추가되었습니다. 시스템 기능을 사용 사례로 문서화 한 다음 고객에게 제공하고 있습니다. 시스템의 일부 기능은 다음과 같습니다 (엔티티 필드 변경 이벤트에)

  • 감사합니다.

  • 시스템 개체에 정의 된 사용자 지정 규칙에 따라받은 편지함에 사용자 알림.

  • SSIS 패키지가 자동으로 실행됩니다 (개체 특성 업데이트).

우리는 다음과 같은 기능을 수행합니다 또는 우리가 '특수 시스템 기능 "에서 별도의 문서 섹션에서 이러한 기능을 선언해야합니다 배우 (시스템 프로세스)와 같은 시스템을 취급해야 하는가?

답변

2

일반적으로 없습니다. 원칙적으로 액터는 시스템 경계 외부에서 살며 유스 케이스 (및 시스템을 구현하는 시스템)는 내부에서 살고 있습니다.

그러나 더 유용한 이유는이 시나리오가있는 이유입니다. 아마 더 설명 할 수 있을까요?

+0

우리가 결정해야 할 실제 상황에 대한 설명이 추가되었습니다. – AlbertasA

+0

감사의 경우 : 감사 출력을받는 사람은 누구이며 그 사람은 어떤 작업을 수행합니까? "보안 감사인보기 (View Audit Log)"등의 유스 케이스 (Use Case)를 가진 "보안 관리자 (Security Administrator)"또는 이와 비슷한 사람을 상상할 수 있습니다. 또한 사용 사례 인 "사용자"라는 액터는 "알림 수신"및 "알림 규칙 정의"를 사용합니다. 'SSIS'가 무엇인지 모르겠다. 처음 두 배우는 배우가 시스템 외부에있는 것처럼 보일 것입니다 (내가 옳다고 생각한다고 가정 할 때). 나는 적어도 내가 그들에 대한 요구 사항을 놓치지 않았 으면 좋겠다. @Neil이 말했듯이, UML에 노예가되지 마라. 유용한 방식으로 사용하라. hth. – sfinnie

0

아마도. 예를 들어 밤마다 summarisation 기능을 수행하는 cron 작업을 액터로 표시 할 수 있습니다. 모든 UML 다이어그램과 마찬가지로, 다이어그램이 다이어그램을 사용하는 사람들에게 유용하다면 괜찮습니다.

0

UML은 명확하고 간결한 방식으로 알아야 할 사람들에게 디자인 결정을 전달하는 것에 관한 것입니다. 이 목표의 명확성에 유리한 경우 디자인의 하위 부분을 나타 내기 위해 액터를 사용합니다. 당신이 의사 소통하는 것과 이것이 모두 같은 모델의 일부라는 사실을 분명하게 밝히는 한.

예를 들어, 코드 블록이 다른 프로세서/컨트롤러 또는 다른 인클로저에서 실행될 수있는 임베디드 시스템을 설계하고 코딩 한 경험이 있습니다. 그러나 그것들은 모두 동일한 애플리케이션의 일부이며 따라서 디자인 모델입니다. 그것을보고있는 또 다른 방법은 Windows 시스템이며, 정상적인 작동을 위해 Windows 서비스에 의존하는 응용 프로그램입니다. 서비스는 GUI 애플리케이션의 액터 일 수 있으며, 애플리케이션은 서비스의 액터 일 수 있습니다.

@sfinnie는 원칙적으로 옳습니다.이 규칙을 벗어나는 통신은 유용 할 때도 있습니다. 결국 UML을 컴파일 할 필요가 없다.