이 타스크에 대한 입력으로 주어진 분석 클래스에 대한 하나 이상의 초기 디자인 클래스를 작성하고 추적 종속성을 지정하십시오. 이 단계에서 작성된 디자인 클래스는 분석 클래스가 디자인되는 방법을 설명하는 다양한
디자인 특성(예: 오퍼레이션, 메소드 및 상태 머신)이 지정되는 후속 단계에서 정제, 조정, 분할 또는 병합됩니다.
디자인되는 분석 클래스의 유형(경계, 엔티티 또는 제어)에 따라서 초기 디자인 클래스를 작성하는 데 사용할 수 있는 특정 전략이 있습니다.
경계 클래스는 사용자 또는 다른 시스템에 대한 인터페이스를 표시합니다.
일반적으로 다른 시스템에 대한 인터페이스를 표시하는 경계 클래스는 종종 복잡한 내부 동작을 갖기 때문에 서브시스템으로 모델링됩니다. 인터페이스 동작이 단순한 경우(외부 시스템에 대한 기존 API의
통과(pass-through)로서만 동작하는 경우) 하나 이상의 디자인 클래스로 인터페이스를 표시할 수 있습니다. 이 라우트를 선택하는 경우 프로토콜, 인터페이스 또는 API별로 단일 디자인 클래스를 사용하고
클래스의 특별 요구사항에 사용한 표준에 대한 특별 요구사항을 기록하십시오.
사용자에 대한 인터페이스를 표시하는 경계 클래스는 일반적으로 사용자 인터페이스에서 각 창에 대해 하나의 경계 클래스 또는 각 양식에 대해 하나의 규칙을 따릅니다. 결국 경계 클래스의 책임이 상당한 상위 레벨에 있을
수 있으며 이 단계에서 정제 및 세부화되어야 합니다. 사용자 인터페이스의 추가 모델 또는 프로토타입은 이 단계에서 고려해야 하는 다른 입력 소스일 수 있습니다.
경계 클래스의 디자인은 프로젝트에 사용할 수 있는 사용자 인터페이스(UI) 개발 도구에 의존합니다. 현재 기술을 사용할 때 UI가 개발 도구에서 직접 시각적으로 구성되는 것이 일반적입니다. 그러면 제어 및 엔티티
클래스의 디자인과 관련되어야 하는 UI 클래스가 자동으로 작성됩니다. UI 개발 환경이 자동으로 UI를 구현하기 위해 필요한 지원 클래스를 작성하는 경우 디자인에서 이들을 고려할 필요가 없습니다. 개발 환경이
사용자를 위해 작성하지 않는 것만 디자인하십시오.
분석 중에 엔티티 클래스는 조작되는 정보 단위를 표시합니다. 엔티티 클래스는 종종 수동이고 지속적이며, 지속성을 위해 식별되어 분석 메커니즘과 연관될 수 있습니다. 데이터베이스 기반 지속성 메커니즘의 세부사항은
타스크: 데이터베이스 디자인에서 다룹니다. 성능 고려사항 때문에 지속적 클래스의 몇몇 리팩토링이 시행될 수 있어서 역할: 데이터베이스 디자이너와 역할: 디자이너 사이에 공동으로
논의되는 디자인 모델이 변경될 수 있습니다.
지속적 클래스에 대한 디자인 문제의 폭넓은 논의는 지속적 클래스 식별 표제 아래에서 나중에 제공됩니다.
제어 오브젝트는 유스 케이스의 플로우를 관리할 책임을 갖고 있으며 따라서 조치의 대부분을 조정합니다. 즉 제어 오브젝트는 사용자 인터페이스 문제(경계 오브젝트) 또는 데이터 엔지니어링 문제(엔티티 오브젝트)와
특별하게 관련되지 않는 로직을 캡슐화합니다. 이 로직을 때로는 응용프로그램 로직 또는 비즈니스 로직이라고 부릅니다.
제어 클래스를 디자인할 때 다음 문제를 고려하십시오.
-
복잡도 - 경계 또는 엔티티 클래스를 사용하여 복잡하지 않은 제어 또는 조정 동작을 처리할 수 있습니다. 그러나 응용프로그램의 복잡도가 커지면 다음과 같이 이 접근 방식의 상당한 결점이
드러납니다.
-
유스 케이스 조정 동작이 UI에 임베디드되어 시스템 변경을 더 어렵게 함
-
서로 다른 유스 케이스 실현(realization)에서 동일한 UI를 어려움 없이 사용할 수 없음
-
추가 기능성으로 인해 UI의 성능이 저하됨
-
유스 케이스 특정 동작으로 인해 엔티티 오브젝트의 일반성이 축소됨
이러한 문제점을 막기 위해, 이벤트 플로우 조정과 관련된 동작을 제공하기 위해 제어 클래스가 도입됩니다.
-
변경 확률 - 이벤트 플로우 변경 확률이 낮거나 비용을 무시할 수 있는 경우 추가 제어 클래스의 여분의 비용과 복잡도가 입증되지 않을 수 있습니다.
-
분배 및 성능 - 서로 다른 노드 또는 서로 다른 프로세스 공간에서 응용프로그램 파트를 실행하기 위해서는 특수한 디자인 모델 요소가 필요합니다. 이 특수성은 종종 제어 오브젝트를 추가하고 경계
및 엔티티 클래스의 동작을 제어 클래스에 분배하여 수행됩니다. 이를 수행할 때 경계 클래스는 순수하게 UI 서비스를 제공하는 쪽으로 이주하고, 엔티티 클래스는 순수하게 데이터 서비스를 제공하는 쪽으로
이동하며 제어 클래스는 나머지를 제공합니다.
-
트랜잭션 관리 - 트랜잭션 관리는 전통적인 조정 활동입니다. 트랜잭션 관리를 처리하는 프레임워크가 없이, 하나 이상의 트랜잭션 관리자 클래스가 트랜잭션의 무결성을 유지보수함을
보장하기 위해 상호작용해야 합니다.
후자의 두 경우에 제어 클래스가 별도의 제어 스레드를 표시하는 경우 활성 클래스를 사용하여 제어 스레드를 모델링하는 것이 보다 적합할 수 있습니다. 실시간 시스템에서는 중간 산출물: 캡슐의 사용이 선호하는 모델링 접근 방식입니다.
|