입구 시스템을위한 UML 클래스 다이어그램 만들기?

Question

등산 체육관의 입구 시스템을보고 있습니다. 고객이 건물에 입장하고 안내 원에게 세부 사항을 제공하고 안내 원이 데이터베이스에 세부 정보를 입력하고 세부 사항을 확인하며 고객이 회원이 아니고 고객이 내부에서 진행하는 경우 지불을받습니다.

고객, 접수 원, 관리자, 데이터베이스의 네 가지 수업이 있습니다. 저는 비회원이고 회원이 일반 고객입니다. 고객과 안내 원 사이에 많은 관계가 있습니다 (고객 측에서는 많은 고객이 있습니다). 접수 원과 데이터베이스 간의 일대일 관계. 안내 원과 관리자 사이의 일대일 관계.

내 클래스와 관계는 정확합니까?

Answer 1

답변하기 쉽지 않습니다. 여러분은 클래스에 대해 이야기 할 것이므로 클래스 다이어그램을 작성한다고 가정합니다. 그렇다면, 나는 (최소한 유스 케이스가 아닌) 접수 교사 수업을 포함 할 것인지 확신하지 못한다. 수신자는 데이터 흐름도에 존재할 수 있습니다. 클래스 다이어그램에서 접수 직원 클래스는 직원 로타 또는 직원 지불 프로세스 내에 존재할 수 있습니다. 프로그래밍 관점에서의 입력 시스템 내에서 고객 클래스는 접수 클래스와 어떻게 상호 작용합니까? 어떤 상호 작용을 위해 접수 계급은 어떤 방법을 포함합니까? 나는 실제 고객 접수가 실제 고객과 상호 작용하지만 응급 접수 담당자가 거래를 처리하지 않은 경우 고객 클래스가 접수 클래스와 상호 작용하지 않을 것이라고 가정하지 않습니다.

그 상황에서도 나는 그 행동을 관리하는 또 다른 클래스라고 생각할 것입니다.

실제 인간 사이의 상호 작용을 매핑하는 경우 많은 고객이 많은 개별 수신자의 도움을받을 수 있음을 제안합니다. 나는 그들이 둘 이상을 고용한다고 가정한다.

Answer 2

그래서 여기 내 관측이다 :

• 모든 속성/작업은 소문자로 시작된다 (그리고 당신은 대문자로 모든 클래스를했던 것처럼). 이것은 내가 알고있는 모든 언어 목록에 채택 된 일반적인 규칙입니다. (완료되지는 않았지만 둘 또는 그 이상입니다.)
• Member과 Non-Member의 공유 구성을 사용합니다. 이것은 일반화 관계 여야합니다. 따라서 다이아몬드 대신에 삼각형을 사용하거나 채울 필요가 있습니다.
• 연결에 역할 이름을 사용해야합니다. 즉, Administrator 클래스를 향해 administrator을 기록해야합니다. 그러면 AdministratorReceptionist 내부의 특성이됩니다.
• 초안/비즈니스 모델에서 ID 속성을 정의하지 마십시오. ID는 일반적으로 객체 주소에서 나중에 컴파일 할 때 파생됩니다. 그래서 당신은 ID가 아닌 객체 자체를 참조합니다.
• Receptionist과 Database 사이에 관계가 있습니다. 나는 그것이 현명한 디자인 결정이라고 생각하지 않는다. 데이터베이스가 어떤 용도로 사용되는지는 분명하지 않습니다. 아마 각 클래스는 어떻게 든 데이터베이스에 반영 될 것입니다. 그래서 그 클래스들은 Serializable 인터페이스를 구현하여 데이터베이스에서 미러링 할 수 있도록해야합니다. Database을 비즈니스 모델에서 클래스로 사용하는 것은 옳지 않습니다. 비즈니스 객체에만 집중하고 이후 단계에서 지속성 계층을 구현하십시오.
• 설명에서 나는 Administrator이 어디서 오는지 보지 못합니다. 접수처 당 한명의 관리자가있는 것은 상당히 편집 적으로 보입니다.