사양 : CRUD 사용 사례

Question

제품 요구 사항 사양을 작성 중입니다. 이 문서에서는 사용자가 매우 높은 수준에서 시스템과 상호 작용할 수있는 방법을 설명해야합니다. 이러한 작업 중 일부는 일부 개체에서 "만들기 - 읽기 - 업데이트 - 삭제"입니다.

질문은 이러한 작업에 대한 사용 사례를 작성할 때 올바른 방법이 무엇일까요? "Manage Object x"라는 하나의 유스 케이스 만 작성한 다음 이러한 작업을 유스 케이스로 포함 할 수 있습니까? 또는 작업 당 하나의 유스 케이스를 객체마다 만들어야합니까? 마지막 접근법에서 볼 수있는 문제는 문제의 이해에 실제로 기여하지 않는다고 생각되는 페이지를 많이 작성한다는 것입니다.

가장 좋은 방법은 무엇입니까?

Answer 1

유스 케이스의 원래 개념은 액터, 클래스 정의, 솔직히 모든 것 - 상속을 즐기는 것뿐 아니라 <<uses>> 및 <<extends>> 관계입니다.

사용 사례 수퍼 클래스 ("CRUD")가 적합합니다. 많은 유스 케이스는 유스 케이스에 연결된 엔티티 타입을 가진 "CRUD"에 대한 사소한 확장이다.

몇 가지 유스 케이스는 "CRUD"에 대한 변형 처리 시나리오 (예 : 검색의 일부로 멋진 검색 또는 만들기 또는 업데이트를위한 여러 단계 프로세스 또는 지우다.

유스 케이스를 단순화하고 정상화하려면 상속을 자유롭게 사용하십시오. UML 도구를 사용하는 경우 유스 케이스에 "상속"화살표가 있음을 알 수 있습니다.

Answer 2

워크 플로 사례와 리소스/개체 수명주기를 구별하는 것이 좋습니다. 그들은 상호 작용하지만 그들은 동일하지 않습니다; 둘 다 지정하는 것이 좋습니다.

사례 시나리오 또는 확장 된 워크 플로 사양은 대개 사례가 시스템 워크 플로를 진행하는 방법을 설명합니다. 일반적으로 다양한 다양한 리소스와의 상호 작용이 포함됩니다. 이러한 상호 작용은 종종 C, R, U 또는 D로 특성화 될 수 있습니다.

리소스 수명주기는 특정 (유형의) 리소스 (개체)에 발생할 수있는 프로세스 모델을 제공합니다. 그들은 종종 "C", "R", "U", "D"중 어떤 것이라도이 자원에 어떤 순서로든 일어날 수있는 사소한 "꽃"모델이기 때문에 그들 스스로별로 흥미롭지 않습니다.

둘 사이의 링크는 워크 플로의 단계와주기가 일치한다는 것입니다.

Answer 3

답변은 실제로 상호 작용이 얼마나 복잡하고 객체간에 얼마나 많은 변형이 가능한지에 달려 있습니다. 난 당신이 각 CRUD에 대한 특정 사용 사례를 개발 제안 이유를 두 가지 진짜 이유가있다

(가) 당신이 정말로 단지의 상호 작용에 대한 높은 수준의 요약을하고있는 경우 오버 헤드가 매우 작

(b) '리소스'를 수정하고 특정 객체에 대한 특정 단계를 확장/재정의하기 위해 일련의 일반적인 유스 케이스를 지정하는 것이 유용하다는 것을 알았습니다. 분명히 공통적 인 동작은 일반적인 'Resource'사용 사례에서 포착됩니다.

도메인에 대한 이해가 발전함에 따라 (비즈니스 사용자가 더 많은 요구 사항을 덤프 할 때) CRUD를 제거하는 대신 CRUD에 추가 할 확률이 높아집니다.

Answer 4

나는 이해할 만하고 표현할 수있는 한 표현력이 중요하지 않습니다. 모든 세부 사항에서 UML 사양을 준수하는 것은 특히 부적합합니다.

중요한 점은 구현에 필요한 작업 유형과 작업 유형을 명확하게 명시하고 있다는 것입니다.

• C : 어떤 삽입 작업이 존재합니다. 완전히 채워지지 않은 행을 삽입 할 수 있습니까? ID없이 행을 삽입 할 수 있습니까? 마지막으로 삽입 한 ID를 검색 할 수 있습니까? 삽입물을 선택적으로 취소 할 수 있습니까? 중복 키 또는 제약 조건이 실패하면 어떻게됩니까? 거기에 상응하는 REPLACE INTO가 있습니까?

• R : 어떤 필드를 선택할 수 있습니까? 당신은 임의적 인 집단화를 할 수 있습니까, 명령입니까? 집계 필드, 별칭을 만들 수 있습니까? 어떻게 임베디드 (많은 데이터가 있습니까?) 데이터를 검색 할 수 있습니까? 재귀 깊이 제한을 어떻게 지정합니까?

• U, D는 : R이 + C