UML 사용 사례를 정의한 후 시스템 모델링

Question

...무엇 향후 계획?

어떤 행위자가 어떤 행동을하는지 정의 한 후에 어떤 방식 으로든가는 방법은 무엇입니까? 데이터베이스를 모델링합니까 아니면 클래스부터 시작하는 것을 선호합니까?

더 나은 접근 방식은 객체 간의 관계에 초점을 맞추기 위해 클래스와 같은 모델링 다이어그램으로 시작하는 것이라고 생각했습니다. 클래스를 자세히 설명하는 데 너무 깊이 들어가서 시스템이 "작동하는 것처럼 보이더라도"데이터베이스 모델링에 갔을 때 이전 단계에서 선택한 위치에 자연스럽게 맞지 않을 것입니다.

나는 사람들이 응용 프로그램 로직을 데이터베이스에 넣고 데이터 검색에 속도를 활용해야한다고 말하면서 메모리에 큰 객체를 구축하고 기본 데이터베이스의 추상화를 제공하는 것에 반대합니다. 나는 항상 DB가 내 데이터를 저장하고 액세스 할 수있는 빠른 방법을 제공 할 것이라고 생각했습니다. 그러나 아마도 내가 틀렸을 수도 있습니다. 실제로 수업 그룹에 넣을 동일한 논리 내부에있는 데이터베이스를 작성해야합니까? 데이터베이스에이를 달성하기위한 도구가 부족하지 않습니까?

데이터베이스로 시작하기로 선택하면 "내 데이터 저장 장소로 생각하기가 어렵다는 것을 알게되면 앱 로직을 더 높은 수준으로 수행하기가 어렵다고 생각합니다. "클래스로 시작하면 데이터베이스가 부 자연스러운 수업의 표현처럼 보이면 올바른 목적을 올바른 도구에 할당하지 않는 것과 같은 중요한 것을 놓친 느낌을 느낍니다.

이것을 어떻게 처리합니까? DB를 모델링 할 것인지 또는 클래스를 모델링할지 여부, 경험에서 어떤 종류의 접근 방식이 자연스럽고 깨끗한 구현으로 이어지는 것으로 입증 되었습니까?

미리 감사드립니다

Answer 1

나는 성공을 거두었 다 견고성 분석.

이 기사는 사용 사례의 이야기 텍스트를 분석하고 각 사용 사례에 참여할 첫 번째 유능한 객체 세트를 식별 한 다음 이러한 객체를 세 가지 유형으로 분류하는 견고성 분석에 중점을 둡니다.

1. 액터가 시스템과 통신하는 데 사용하는 경계 객체.
2. 일반적으로 도메인 모델의 객체 인 엔티티 객체 ( "드라이빙 설계 : 문제 도메인", 2001 년 1 월).
3. 제어 객체 (일반적으로 실제 개체가 아니기 때문에 컨트롤러를 호출하는)는 경계 객체와 엔티티 객체 사이의 "접착제"역할을합니다. 그림 1이 세 가지 유형의 객체에 대한 시각적 아이콘을 보여줍니다.

엔티티 객체는 데이터베이스에서 끝나는 개체입니다.

클래스와 데이터베이스 간의 매핑시 권장합니다. "ORM 문제"에 관한 S.Lott의 기사 (그는 또한 stackoverflow의 참가자입니다

Answer 2

테스트 중심 개발을 사용하는 경우 먼저 단위 테스트를 작성하십시오. 당신이 갈 때 수업이 요약됩니다.

테스트를 계속할 때 데이터베이스 (모의 또는 스터브 객체)없이 비즈니스 로직을 개발하거나 데이터베이스를 개발할 수 있습니다.

데이터베이스와 도메인 모델이 서로 하나를 매핑해서는 안된다는 것을 기억하십시오.