목적
  • 클래스가 유스 케이스 구현이 필수로 하는 작동을 제공하는지 확인하기 위함
  • 명백하게 클래스를 구현하도록 충분한 정보가 제공되는지 확인하기 위함
  • 클래스와 연관된 비기능적 요구사항을 처리하기 위함
  • 클래스가 사용하는 설계 메커니즘을 통합하기 위함
역할:  설계자 
빈도: 각 반복당 한 번. 
단계
입력물:    결과물:   
툴 강좌:   
자세한 정보: 

워크플로우 세부사항:   

클래스는 사실상 시스템의 실제 작업을 수행하는 설계 노력의 편리한 장치입니다. 기타 설계 요소(예: 서브시스템, 패키지 및 공동 연구)는 클래스가 그룹화되는 방법 또는 상호 작용하는 방법을 설명합니다.

활성 클래스는 수동 클래스의 작동을 조정하고 구동하는 설계 클래스입니다. 활성 클래스는 인스턴스가 활성 객체로 고유의 제어 스레드를 소유하는 클래스입니다.

설계 패턴 및 메커니즘 사용페이지 맨 위

프로젝트 설계 가이드라인에 따라 클래스 또는 설계 중인 성능에 적합하게 설계 패턴 및 메커니즘을 사용하십시오.

패턴 및/또는 메커니즘 통합이 패턴 및 메커니즘에 정의된 규칙에 따라 이 활동(새 클래스, 조작, 속성 및 관계 추가)에서 많은 후속 단계를 효율적으로 수행합니다.

일반적으로 패턴 및 메커니즘은 이 활동의 첫 번째 단계로서만이 아니라 설계가 진전됨에 따라 통합됩니다. 또한 단일 클래스에만이 아니라 클래스 세트 전반에 걸쳐 자주 적용됩니다.

초기 설계 클래스 작성 페이지 맨 위

이 활동에 입력으로서 제공된 분석 클래스의 하나 또는 여러 초기 설계 클래스를 작성하고 추적 종속성을 지정하십시오. 이 단계에서 작성된 설계 클래스는 분석 클래스가 설계되는 방법을 설명하는 여러 설계 등록 정보(조작, 메소드 및 상태 시스템) 지정시 후속 단계로 세분화, 조정 또는 병합됩니다.

설계 중인 분석 클래스(경계, 엔티티 또는 제어)가 유형에 따라 초기 설계 클래스를 작성하는데 사용할 수 있는 특정 전략이 있습니다.

경계 클래스 설계

경계 클래스가 사용자 또는 기타 시스템의 인터페이스를 표시합니다.

일반적으로, 기타 시스템의 인터페이스를 표시하는 경계 클래스는 서브시스템으로 모델화됩니다. 왜냐하면 종종 복잡한 내부 작동이 있기 때문입니다. 인터페이스 작동이 단순한 경우(외부 시스템과 기존 API의 연결 장치로서만 역할), 하나 이상의 설계 클래스가 있는 인터페이스를 표시하도록 선택할 수도 있습니다. 이 경로를 선택하는 경우, 프로토콜, 인터페이스 또는 API당 단일 설계 클래스를 사용하고 클래스의 특수 요구사항에 사용한 표준에 대한 특수 요구사항을 참고하십시오.

사용자의 인터페이스를 표시하는 경계 클래스는 일반적으로 사용자 인터페이스에서 각 창에 한 경계 클래스 또는 각 양식에 한 경계 클래스의 규칙에 따릅니다. 결과적으로 경계 클래스의 책임은 상당히 상위 레벨이 될 수 있으며 이 단계에서 세분화되고 정제되어야 합니다. 사용자 인터페이스의 추가 모델 또는 프로토타입은 기타 입력 소스로 이 단계에서 고려될 수 있습니다.

경계 클래스의 설계는 프로젝트에 사용 가능한 사용자 인터페이스(UI) 개발 도구에 따라 달라집니다. 현재 기술을 사용하여 UI를 개발 도구에서 시각적으로 직접 구성하는 것이 일반적입니다. 이로써, 엔티티 클래스 및 제어 설계에 관련되어야 하는 UI 클래스를 자동으로 작성합니다. UI 개발 환경이 자동으로 지원 클래스를 작성하고 UI를 구현해야 하는 경우 설계시 고려할 필요가 없습니다. 개발 환경이 작성하지 않는 사항만을 설계합니다.

엔티티 클래스 설계

분석 중에 엔티티 클래스가 조작된 정보 단위를 표시합니다. 해당 단위는 종종 수동적이고 지속적이며 지속성의 분석 메커니즘으로 식별되고 연관될 수도 있습니다. 데이터베이스 기반 지속성 메커니즘의 설계에 대한 세부사항은 활동: 데이터베이스 설계에서 다룹니다. 성능 고려사항이 지속적 클래스의 재분석을 실행하여 역할: 데이터베이스 설계자역할: 설계자 간에 공동으로 의논한 설계 모델에 변경을 할 수 있습니다.

지속적 클래스의 설계 문제에 대한 보다 광범위한 논의는 나중에 지속적 클래스 식별이라는 표제 아래에서 제공합니다 .

제어 클래스 설계

제어 객체는 유스 케이스의 플로우를 관리할 책임이 있으므로 대부분의 조치를 조정합니다. 제어 객체는 특히 사용자 인터페이스 문제(경계 객체) 또는 데이터 엔지니어링 문제(엔티티 객체)와 관련되지 않은 논리를 캡슐화합니다. 이 논리는 때때로 어플리케이션 논리 또는 비즈니스 논리라고 합니다.

제어 클래스 설계시 다음 문제를 고려하십시오.

  • 복잡도 - 경계 또는 엔티티 클래스를 사용하여 복잡하지 않은 제어 또는 조정 작동을 처리할 수 있습니다. 그러나 어플리케이션의 복잡도가 커짐에 따라 다음과 같은 이 접근법의 중요한 약점이 나타납니다.
  • 유스 케이스 조정 작동이 UI에 임베드되어져 시스템 변경을 어렵게 함
  • 동일한 UI를 어렵지 않게 다른 유스 케이스 구현에서 사용할 수 없음
  • UI가 추가 기능으로 부담이 가중되어 성능을 저하시킴
  • 엔티티 객체가 유스 케이스 특정 작동으로 부담이 가중되어 보편성이 저하됨

이러한 문제점을 피하도록 제어 클래스가 도입되어 이벤트 플로우 조정과 관련된 작동을 제공합니다.

  • 확률 변경 - 이벤트 플로우 변경의 확률이 낮거나 비용이 대수롭지 않은 경우, 추가 제어 클래스의 복잡도 및 추가 소요 경비가 정당화되지 않을 수도 있습니다.
  • 분배 및 성능 - 다른 노드 또는 다른 프로세스 공간에서 어플리케이션의 파트를 실행해야 하므로 설계 모델 요소를 특수화해야 합니다. 이 특수화는 종종 제어 객체 추가하고 경계 및 엔티티 클래스에서 작동을 제어 클래스로 분배하여 성취합니다. 해당 작업 수행시, 경계 클래스는 전적으로 UI 서비스를 제공하도록 이주되며 엔티티 클래스는 완전히 데이터 서비스를 제공하는 방향으로 이동하고 제어 클래스가 나머지를 제공합니다.
  • 트랜잭션 관리 - 트랜잭션 관리는 전형적인 조정 활동입니다. 트랜잭션 관리를 처리하는 프레임워크 없이 하나 이상의 트랜잭션 관리자 클래스가 트랜잭션의 무결성을 사용자가 유지보수하는지 확인하도록 상호 작용해야 합니다.

후자의 두 경우에서 제어 클래스가 별도의 제어 스레드를 표시하면 활성 클래스를 사용하여 제어 스레드를 모델화하는 것이 적절할 수도 있습니다.

지속적 클래스 식별페이지 맨 위

영구적 매체에 상태를 저장해야 하는 클래스는 지속적이라고 부릅니다. 상태를 저장하는 것은 시스템 실패의 경우 백업용 또는 정보의 교환용으로 클래스 정보의 영구적인 기록을 위한 것입니다. 지속적 클래스에는 지속적이고 일시적인 인스턴스 모두가 있을 수 있습니다. 클래스를 지속적으로 레이블하는 것은 단지 클래스의 일부 인스턴스가 지속적일 필요가 있을 수도 있음을 의미합니다.

분석 중에 발견한 지속성 메커니즘에 대응하는 설계 메커니즘을 통합하십시오. 예를 들어, 클래스가 필수로하는 사항에 따라 지속성의 분석 메커니즘이 다음과 같은 설계 메커니즘 중 하나로 구현될 수도 있습니다.

  • 메모리 내 기억장치
  • 플래시 카드
  • 2진 파일
  • DBMS

지속적 객체는 엔티티 클래스에서만 파생되는 것이 아닐 수 있습니다. 지속적 객체는 일반적으로 비기능적 요구사항을 처리하는데 필요할 수도 있습니다. 예제는 프로세스 제어 관련 정보를 유지보수하거나 트랜잭션 간 상태 정보를 유지보수하는데 필요한 지속적 객체입니다.

지속적 클래스의 식별은 역할: 데이터베이스 설계자에게 클래스가 실제 저장영역 특성에 특별한 주의를 필요로 함을 알리는데 사용합니다. 또한 역할: 소프트웨어 아키텍트에게 클래스가 지속적이어야 함을 알리고 지속성 메커니즘의 책임이 있는 역할: 설계자에게 클래스의 인스턴스가 지속적으로 작성되어야 함을 알립니다.

조정된 지속성 전략의 필요로 인해 역할: 데이터베이스 설계자가 지속성 프레임워크를 사용하여 데이터베이스에 지속적 클래스를 맵핑할 책임이 있습니다. 프로젝트가 지속성 프레임워크를 개발 중이면 프레임워크 개발자는 또한 설계 클래스의 지속성 요구사항을 이해할 책임이 있습니다. 이러한 개인이 필요한 정보를 제공하려면 이 지점에서 클래스가 지속적이거나 보다 정확하게 클래스의 인스턴스가 지속적임을 표시하는 것으로 충분합니다.

클래스 가시성 정의 페이지 맨 위

각 클래스의 경우, 클래스가 있는 패키지에서 클래스 가시성을 판별하십시오. public 클래스는 포함 패키지의 외부에서 참조될 수 있습니다. private 클래스(또는 가시성이 implementation인 클래스)는 동일한 패키지 내 클래스에 의해서만 참조될 수도 있습니다.

조작 정의 페이지 맨 위

조작 식별

설계 클래스의 조작을 식별하려면 다음을 수행하십시오.

  • 각 해당 분석 클래스의 책임을 연구하여 각 책임에 대한 조작을 작성하십시오. 조작의 초기 설명으로 책임의 설명을 사용하십시오.
  • 유스 케이스 구현이 조작을 사용하는 방법을 참조하도록 클래스 참여에서 유스 케이스 구현을 학습하십시오. 조작, 한 번에 한 유스 케이스 구현, 조작 정제, 해당 설명, 리턴 유형 및 매개변수를 확장하십시오. 클래스에 속한 각 유스 케이스 구현 요구사항은 유스 케이스 구현의 이벤트 플로우에서 원문대로 설명되어 있습니다.
  • 특수 요구사항 유스 케이스를 연구하여 설명되었을 수도 있는 조작의 내재적 요구사항을 유실하지 않는지 확인하십시오.

스크립트(조작에 아직 지정되지 않은 임시 메시지 스펙)가 클래스가 수행되도록 예상되는 작동을 설명하므로 조작이 순서 다이어그램에 표시되는 메시지를 지원하도록 필수입니다. 그림 1이 순서 다이어그램의 예를 설명합니다.

첨부 텍스트에 설명된 다이어그램.

그림 1: 메시지가 조작 식별용 기초를 형성

유스 케이스 구현이 모든 조작을 식별하기에 충분한 정보를 제공할 수 없습니다. 나머지 조작을 찾으려면 다음을 고려하십시오.

  • 클래스의 새 인스턴스를 연관된 기타 클래스의 인스턴스에 연결을 포함하여 클래스의 새 인스턴스를 초기화하는 방법이 있는지 여부.
  • 클래스의 두 인스턴스가 동일한지 확인하도록 테스트할 필요가 있는지 여부.
  • 클래스 인스턴스의 사본을 작성할 필요가 있는지 여부.
  • 사용하는 메커니즘이 클래스에서 임의의 조작을 필요로 하는지 여부. 예를 들어, 가비지 콜렉션 메커니즘은 임의의 사용하지 않는 자원이 사용 가능하도록 객체가 모든 참조를 기타 모든 객체에 놓을 수 있어야 할 수도 있습니다.

public 속성값을 단지 얻어서 설정하는 조작을 정의하지 마십시오(속성 정의연관 정의 참조). 대부분의 경우, 코드 생성 기능에 의해 생성되며 명시적으로 정의될 필요가 없습니다.

조작 이름 지정 및 설명

조작, 리턴 유형 및 매개변수와 해당 유형의 이름 지정시 구현 언어의 이름 지정 규칙을 사용하십시오.

각 조작의 경우, 다음을 정의해야 합니다.

  • 조작 이름 - 이름을 간단하고 조작 결과를 설명할 수 있도록 하십시오.
    • 조작의 이름은 구현 언어의 구문에 따라야 합니다. 예를 들어, find_location은 C++ 또는 Visual Basic용이며 Smalltalk에는 사용하지 않습니다(밑줄이 사용되지 않음). 모두에 대해 더 나은 이름은 findLocation입니다.
    • 조작이 수행되는 방법을 함축하는 이름은 피하십시오. 예를 들어, Employee.wages()Employee.calculateWages()보다 낫습니다. 왜냐하면 후자는 계산이 수행됨을 함축하기 때문입니다. 조작이 단순히 데이터베이스의 값을 리턴할 수도 있습니다.
    • 조작의 이름이 해당 목적을 명확히 표시해야 합니다. 리턴하는 결과에 대해 설명적이지 않은 비특정 이름(예: getData)은 피하십시오. 정확히 예상되는 사항을 표시하는 이름(예: getAddress)을 사용하십시오. 더 나은 방법으로, 단지 조작 이름을 리턴되거나 설정된 등록 정보의 이름이 되게 두십시오. 매개변수가 있는 경우 등록 정보를 설정합니다. 매개변수가 없는 경우, 등록 정보를 얻습니다. 예를 들어, address 조작은 고객의 주소를 리턴합니다. 여기서, address(aString)고객의 주소를 설정 또는 변경합니다. 조작의 getset 특성은 조작의 서명에서 내재적입니다.
    • 개념적으로 동일한 조작에는 다른 클래스가 해당 조작을 정의하는 경우나 완전히 다른 방법으로 구현되는 경우, 또는 다른 수의 매개변수가 있는 경우에도 동일한 이름이 있습니다. 예를 들어, 객체를 작성하는 조작은 모든 클래스에 동일한 이름이 있어야 합니다.
    • 여러 클래스의 조작에 동일한 서명이 있는 경우, 조작은 수신측 객체에 적절한 동일한 종류의 결과를 리턴해야 합니다. 이는 다형성 개념의 예로 다른 객체가 유사한 방식으로 동일한 메시지에 응답해야 함을 의미합니다. 예: 이름 조작 예제는 이름이 저장 또는 파생된 방법에 상관없이 객체의 이름을 리턴해야 합니다. 이 원칙에 따르면 모델을 보다 쉽게 이해할 수 있습니다.
  • 리턴 유형 - 리턴 유형은 조작이 리턴한 객체의 클래스여야 합니다.
  • 간단한 설명 - 가능한 의미 있게 작성하십시오. 조작의 이름은 종종 조작이 수행하는 사항을 이해하는데 단지 애매하게 유용합니다. 조작 사용자 관점에서 작성된 두 문장으로 구성된 간단한 설명을 조작에 제공하십시오.
  • 매개변수 - 각 매개변수의 경우, 간단한 설명적 이름을 작성하며 클래스를 결정하고 간략한 설명을 부여하십시오. 매개변수 지정시, 보다 적은 매개변수가 보다 나은 재사용 가능성을 의미함을 기억하십시오. 적은 수의 매개변수가 조작을 이해하기 쉽게 하므로 유사한 조작을 찾을 가능성이 높습니다. 여러 매개변수가 있는 조작을 여러 조작으로 나누어야 할 수도 있습니다. 조작은 사용하려는 사용자에게 이해 가능해야 합니다. 간략한 설명에는 다음 사항이 포함됩니다.
    • 매개변수의 의미(이름에서 명백히 알 수 없는 경우)
    • 매개변수가 값별로 전달되는지 또는 참조별로 전달되는지 여부
    • 값이 제공되어야 하는 매개변수
    • 선택사항일 수 있는 매개변수와 그 기본값(값이 제공되지 않은 경우)
    • 매개변수의 올바른 범위(적용 가능한 경우)
    • 조작에서 수행된 사항
    • 조작에 의해 참조 매개변수가 변경된 사항

조작을 정의한 다음에 각 메시지에 호출된 조작에 대한 정보가 있는 순서 다이어그램을 완료하십시오.

자세한 정보는 가이드라인: 설계 클래스의 클래스 조작을 참조하십시오.

조작 가시성 정의

각 조작에 대해 다음 선택사항에서 조작의 내보내기 가시성을 식별하십시오.

  • Public - 조작이 클래스 자체 이외에 모델 요소에도 가시적입니다.
  • Implementation - 조작이 클래스 자체에서만 가시적입니다.
  • Protected - 조작이 클래스 자체, 서브클래스 또는 클래스의 friends(언어 종속적)에만 가시적입니다.
  • Private - 조작이 클래스 자체 및 클래스의 friends에만 가시적입니다.

조작의 목표를 여전히 달성할 수 있는 가능한 가장 제한된 사용 가능성을 선택하십시오. 이를 수행하려면 순서 다이어그램을 보고, 각 메시지에 경우 메시지가 수신측 패키지의 외부 클래스(public 가시성 필수)에서 오는지, 패키지의 내부 클래스(implementation 가시성 필수)에서 오는지, 서브클래스(protected 가시성 필수)에서 오는지 또는 클래스 자체나 동급(private 가시성 필수)에서 오는지를 판별하십시오.

클래스 조작 정의

대부분의 경우, 조작은 인스턴스 조작입니다. 즉, 클래스의 인스턴스에서 수행됩니다. 그러나 일부 경우 조작이 클래스의 모든 인스턴스에 적용되므로 클래스 범위 조작입니다. 클래스 조작 수신측은 클래스의 임의의 특정 인스턴스라기 보다는 사실상 메타클래스의 인스턴스입니다(클래스 자체의 설명). 클래스 조작의 예는 새 인스턴스를 작성하는(인스턴스화) 메시지를 포함하여 클래스의 모든 인스턴스 등을 리턴합니다.

조작 문자열에 밑줄이 그어져 클래스 범위 조작을 나타냅니다.

메소드 정의 페이지 맨 위

메소드는 조작의 구현을 지정합니다. 조작에 필수인 작동이 조작 이름, 설명 및 매개변수로 충분히 정의된 여러 경우에, 메소드가 프로그래밍 언어로 직접 구현됩니다. 조작의 구현이 특정 알고리즘이나 조작 설명에 제공된 것보다 자세한 정보의 사용을 필요로 하는 경우, 별도의 메소드 설명이 필수입니다. 메소드가 조작의 작업 내용뿐 아니라 방법도 설명합니다.

그런 경우, 메소드가 다음에 대해 설명해야 합니다.

  • 조작이 구현될 방법
  • 속성 구현 방법 및 조작을 구현하는데 속성을 사용하는 방법
  • 관계 구현 방법 및 조작을 구현하는데 관계를 사용하는 방법

요구사항은 경우에 따라 달라집니다. 그러나 클래스의 메소드 스펙은 항상 다음을 나타내야 합니다.

  • 요구사항에 따라 수행될 사항
  • 사용될 기타 오브젝트 및 해당 조작

보다 특정 요구사항은 다음에 관련될 수 있습니다.

  • 매개변수가 구현될 방법
  • 사용될 특수 알고리즘 내용(있는 경우)

순서 다이어그램은 중요한 소스입니다. 해당 다이어그램에서 조작 수행시 기타 객체에서 사용될 조작이 명확합니다. 기타 객체에서 사용될 조직의 스펙은 조작의 완전한 구현에 필수입니다. 그러므로, 완전환 메소드 스펙의 작성은 관련된 객체의 조작 식별 및 해당 순서 다이어그램의 조사를 필수로 합니다.

상태 정의 페이지 맨 위

일부 조작의 경우, 조작의 작동은 수신측 객체의 상태에 따라 달라집니다. 상태 시스템은 객체가 가정할 수 있는 상태 및 객체가 한 상태에서 다른 상태로 이동하게 할 수 있는 이벤트를 설명합니다(가이드라인: 상태 차트 다이어그램 참조). 상태 시스템은 활성 클래스를 설명하는데 가장 유용합니다.

간단한 상태 시스템의 예제는 그림 2에 표시되어 있습니다.

첨부 텍스트에 설명된 다이어그램

그림 2: 연료 자동 판매기의 단순한 상태 차트 다이어그램

각 상태 전이 이벤트는 조작과 연관될 수 있습니다. 객체의 상태에 따라 조작이 다른 작동을 할 수도 있으며 전이 이벤트가 이 발생 방법을 설명합니다.

연관된 조작의 메소드 설명은 조작이 수행해야 하는 각 관련 상태를 표시하는 상태 특정 정보로 갱신되어야 합니다. 상태는 속성을 사용하여 종종 표현됩니다. 상태 차트 다이어그램은 속성 식별 단계의 입력으로서 사용합니다.

자세한 정보는 가이드라인: 상태 차트 다이어그램을 참조하십시오.

속성 정의 페이지 맨 위

메소드의 정의 및 상태의 식별 중에 클래스가 조작을 수행하는데 필요한 속성이 식별됩니다. 속성이 클래스 인스턴스의 정보 기억장치를 제공하며 클래스 인스턴스의 상태를 표시하는데 종종 사용됩니다. 클래스 자체가 유지보수하는 임의의 정보는 속성을 통해 완료됩니다. 각 속성에 대해 다음을 정의하십시오.

  • 이름은 구현 언어 및 프로젝트 모두의 이름 지정 규칙에 따라야 합니다.
  • 유형은 구현 언어가 지원하는 기본 데이터 유형입니다.
  • 기본값 또는 초기값은 클래스의 새 인스턴스가 작성될 때 초기화됩니다.
  • 가시성은 다음 값 중 하나를 취합니다.
    • Public: 클래스를 포함하는 패키지의 내부 및 외부 모두에서 속성을 볼 수 있음
    • Protected: 속성을 클래스 자체, 서브클래스 또는 클래스의 동급(언어 종속적)에서만 볼 수 있음
    • Private: 속성을 클래스 자체 및 해당 클래스의 동급에서만 볼 수 있음
    • Implementation: 속성을 클래스 자체에서만 볼 수 있음
  • 지속적 클래스의 경우, 속성이 지속적(기본값)이든 일시적이든, 클래스 자체가 지속적인 경우에도 클래스의 모든 속성이 지속적일 필요는 없음

모든 속성이 필요한지 확인하도록 검사하십시오. 속성이 정당화되어야 합니다. 속성이 프로세스 초기에 추가되어 근시안적인 특성으로 인해 더 이상 필요하지 않을 때까지 존속하는 것은 용이합니다. 수 천 또는 수 백만의 인스턴스로 곱해진 추가 속성은 시스템 저장영역 요구사항 및 성능에 불리한 영향을 줄 수 있습니다.

속성에 대한 자세한 정보는 가이드라인: 설계 클래스속성 섹션을 참조하십시오.

종속성 정의 페이지 맨 위

객체 간 의사소통이 필수인 각 경우에 대해 다음과 같은 질문을 하십시오.

  • 수신측 참조가 조작에 매개변수로 전달되는지 여부. 그런 경우, 두 클래스를 포함하는 클래스 다이어그램에서 송신측 및 수신측 클래스 간 종속성을 설정하십시오. 또한 상호 작용에 의사소통 다이어그램 형식이 사용되면 링크 가시성의 자격을 부여하고 이를 매개변수로 설정하십시오.
  • 수신측이 글로벌인지 여부. 그런 경우, 두 클래스를 포함하는 클래스 다이어그램에서 송신측 및 수신측 클래스 간 종속성을 설정하십시오. 또한 상호 작용에 의사소통 다이어그램 형식이 사용되면 링크 가시성의 자격을 부여하고 이를 글로벌로 설정하십시오.
  • 수신측이 조작 자체 중에 작성되고 파기된 임시 객체인지 여부. 그런 경우, 두 클래스를 포함하는 클래스 다이어그램에서 송신측 및 수신측 클래스 간 종속성을 설정하십시오. 또한 상호 작용에 의사소통 다이어그램 형식이 사용되면 링크 가시성의 자격을 부여하고 이를 로컬로 설정하십시오.

이런 방식으로 모델화된 링크는 일시적 링크로 특정 공동 연구 컨텍스트의 제한된 지속 기간동안에만 존재합니다. 이런 관점에서 해당 링크는 공동 연구에서 연관 역할의 인스턴스입니다. 그러나 클래스 모델의 관계(컨텍스트에 독립적)는 이전에 설명한 대로 종속성이어야 합니다. [RUM98]가 설명한 것처럼 임시 링크에서 "이러한 모든 링크를 연관으로서 모델화하는 것이 가능하지만, 이런 경우 연관의 조건이 매우 광범위하게 설명되어야 하며 객체의 조합을 제한하는데 있어 상당한 정밀도를 상실하게 됩니다." 이런 상황에서 종속성의 모델링은 종속성이 관계를 완전히 설명하지 않으므로 공동 작업의 관계 모델링에 비해 덜 중요합니다(존재하는 경우에만).

연관 정의 페이지의 맨 위

연관은 객체가 서로 통신할 수 있는 메커니즘을 제공합니다. 메시지가 소통할 수 있는 콘딧과 함께 객체를 제공합니다. 또한 클래스 간 종속성을 문서화하여 한 클래스의 변경사항이 다른 여러 클래스 사이에서 영향을 줄 수 있음을 하이라이트합니다.

각 조작의 메소드 설명을 검사하여 클래스의 인스턴스가 기타 객체와 통신 및 공동 작업하는 방법을 이해하십시오. 메시지를 다른 객체에 전송하려면 객체에 메시지의 수신측에 대한 참조가 있어야 합니다. 의사소통 다이어그램(순서 다이어그램의 대안 표시)이 그림 3에 설명된 대로 링크의 관점에서 객체 의사소통을 표시합니다.

첨부된 텍스트에 설명된 다이어 그램.

그림 3: 의사소통 다이어그램의 예

연관 및 집합 정의

나머지 메시지가 연관 또는 집합을 사용하여 통신하는 두 클래스의 인스턴스 간 관계를 지정합니다. 적당한 표현을 선택하는데 대한 정보는 가이드라인: 연관가이드라인: 집합을 참조하십시오. 이러한 두 연관 모두의 경우, 의사소통 다이어그램에서 링크 가시성을 필드로 설정하십시오. 기타 타스크에는 다음이 포함됩니다.

  • 연관 및 집합의 탐색 가능성을 설정하십시오. 상호 작용 다이어그램에서 링크 예시에 필수인 탐색 가능성을 고려하여 이를 수행할 수 있습니다. 탐색 가능성은 기본값으로 true이므로 연관에 있는 클래스의 모든 오브젝트의 모든 상반된 링크 역할이 탐색 가능성을 필요로 하지 않는 연관(및 집합)만을 찾으면 됩니다. 이러한 경우, 클래스 역할에서 탐색 가능성을 false로 설정하십시오.
  • 연관 자체에(연관 클래스로 표시됨) 속성이 있는 경우, 연관 클래스를 표시하도록 적당한 속성과 함께 설계 클래스를 작성하십시오. 이 클래스를 기타 두 클래스 사이에 두고 연관 클래스 및 기타 두 클래스 간에 적절한 다양성으로 연관을 설정하십시오.
  • 연관 종료순서 지정되어야 하는지 여부를 지정하십시오. 연관의 다른 종료에서 한 객체와 연관된 객체에 보존되어야 하는 순서가 있는 경우입니다.
  • 연관된(또는 집합된) 클래스가 현재 클래스에 의해서만 참조되는 경우, 클래스가 중첩되어야 하는지 여부를 고려하십시오. 클래스 중첩의 이점은 보다 빠른 메시징 및 보다 단순한 설계 모델을 포함합니다. 불리한 점은 중첩 클래스의 인스턴스가 있는지 여부에 상관없이 고정되게 할당된 중첩 클래스의 공간이 있거나 포함된 클래스와 별개인 객체 ID의 결여 또는 포함된 클래스 외부에서 중첩 클래스 인스턴스의 참조 무능력을 포함합니다.

연관과 집합은 연관된 클래스를 묘사하는 클래스 다이어그램에 가장 잘 정의되어 있습니다. 클래스 다이어그램은 연관된 클래스를 포함하는 패키지가 소유해야 합니다. 그림 4가 연관 및 집합을 묘사하는 클래스 다이어그램의 예를 설명합니다.

첨부 텍스트에 설명된 다이어그램.

그림 4: 클래스 간 일반화, 집합 및 연관을 표시하는 클래스 다이어그램의 예

분석 클래스 간 연관-둥록 처리

분석 클래스 간 등록-연관은 클래스 간 이벤트 종속성을 식별하는데 사용합니다. 설계 모델에서 사용 가능한 이벤트 핸들러 프레임워크를 사용하거나 사용자 고유의 이벤트 핸들러 프레임워크를 설계 및 빌드하여 해당 이벤트 종속성을 명시적으로 처리해야 합니다. 일부 프로그래밍 언어(예: Visual Basic)에서 이는 간단합니다. 해당 이벤트를 선언, 제기 및 처리합니다. 기타 언어에서는, 등록 및 이벤트를 처리하기 위해 재사용 가능 기능의 일부 추가 라이브러리를 사용해야 할 수도 있습니다. 기능성을 구입할 수 없는 경우 기능성을 설계 및 빌드해야 합니다. 가이드라인: 등록-연관 또한 참조하십시오.

내부 구조 정의 페이지 맨 위

일부 클래스가 복잡한 추상을 표현하고 복잡한 구조가 있을 수 있습니다. 클래스를 모델링하는 동안 설계자가 내부 관련 요소 및 해당 관계를 표시하여 구현자가 해당 클래스 내에서 발생하는 공동 작업을 적절히 구현하도록 할 수도 있습니다.

UML 2.0에서 클래스는 내부 구조 및 포트가 있는 성능의 구조화된 클래스로 정의됩니다. 그런 다음, 클래스는 차례로 세분화될 수도 있는 연결된 파트의 콜렉션으로 분해될 수도 있습니다. 클래스는 선언된 인터페이스에 따라 작동하는 포트를 통해 전달되도록 외부로부터의 의사소통을 강제 실행하여 캡슐화될 수도 있습니다.

복잡한 구조의 복잡한 클래스를 찾은 경우, 해당 클래스에 대해 합성 구조 다이어그램을 작성하십시오. 해당 클래스 작동의 역할을 수행할 파트를 모델화하십시오. 커넥터를 사용하여 파트가 함께 '연결'되는 방법을 설정하십시오. 해당 클래스의 다른 클라이언트가 해당 클래스가 제공하는 작동의 특정 부분을 액세스하도록 하려면 선언된 인터페이스가 있는 포트를 사용하십시오. 또한 해당 클래스의 내부 포트를 해당 환경에서 완전히 분리하도록 포트를 사용하십시오.

이 주제 및 합성 구조 다이어그램의 예제에 대한 자세한 정보는 개념: 구조화된 클래스를 참조하십시오.

일반화 정의 페이지 맨 위

클래스가 공통 작동 및 공통 구조를 반영하도록 일반화 계층 구조로 체계화될 수도 있습니다. 수퍼클래스가 정의될 수 있으며, 해당 클래스에서 수퍼클래스가 작동 및 구조 모두를 상속할 수 있습니다 . 일반화는 공통 구조 및 작동을 한 위치에 정의하고 반복된 작동 및 구조를 찾는 경우 재사용하도록 하는 표기상의 편이입니다. 관계 일반화에 대한 자세한 정보는 가이드라인: 일반화를 참조하십시오.

일반화를 찾는 경우, 공통 속성, 연관, 집합 및 조작을 포함하는 공통 수퍼클래스를 작성하십시오. 공통 수퍼클래스의 서브클래스가 될 클래스에서 공통 작업을 제거하십시오. 서브클래스에서 수퍼클래스로 일반화 관계를 정의하십시오.

유스 케이스 충돌 해결 페이지 맨 위

이 단계의 목적은 둘 이상의 유스 케이스가 잠재적으로 설계 클래스를 동시에 일치하지 않는 방법으로 액세스할 수 있는 경우 야기되는 동시성 충돌을 예방하기 위함입니다.

설계 프로세스에 걸친 유스 케이스별 진행의 어려움 중 하나는 둘 이상의 유스 케이스가 잠재적으로 충돌하는 방식으로 설계 객체에서 조작을 동시에 호출 시도할 수 있다는 것입니다. 이러한 경우에, 동시성 충돌은 명시적으로 식별되고 해결되어야 합니다.

동기 메시징이 사용된 경우, 조작의 실행은 조작이 완료될 때까지 객체로의 후속 호출을 차단합니다. 동기 메시징은 메시지 처리에 있어 먼저 들어온 메시지를 먼저 처리함을 함축합니다. 이로써, 특히, 모든 메시지에 동일한 우선순위가 있거나 모든 메시지가 동일한 실행 스레드 내에서 실행하는 경우 동시성 충돌이 해결될 수도 있습니다. 객체가 다른 실행 스레드(활성 클래스로 표시)에 의해 액세스될 수도 있는 경우, 명시 메커니즘이 동시성 충돌을 예방 또는 해결하도록 사용되어야 합니다.

동일한 객체의 다른 조작이 동시성 충돌없이 다른 실행 스레드에 의해 동시에 호출될 가능성도 있습니다. 고객의 이름 및 주소 모두 충돌없이 동시에 수정될 수 있습니다. 두 개의 다른 실행 스레드가 충돌이 일어나는 객체의 동일한 등록 정보를 수정하려는 경우에 한합니다.

다른 실행 스레드에 의해 동시에 액세스될 수도 있는 각 객체에 대해 동시 액세스로부터 보호되어야 하는 코드 섹션을 식별하십시오. 구현화 단계의 초기에 특정 코드 세그먼트의 식별이 불가능합니다. 보호되어야 하는 조작이 충분합니다. 다음으로, 적절한 액세스 제어를 선택 또는 설계하여 충돌하는 동시 액세스를 예방하십시오. 이러한 메커니즘의 예에는 액세스를 일련화하는 메시지 큐, 한 번에 하나의 스레드에만 액세스를 허용하는 세마포어나 토큰 사용 또는 잠금 메커니즘의 기타 변형이 포함됩니다. 메커니즘의 선택은 구현 종속적인 경향이 높으며 일반적으로 프로그래밍 언어와 운영 환경에 따라 다양합니다.

일반적인 비기능적 요구사항 처리 페이지 맨 위

설계 클래스가 에 표시된 대로 일반 비기능적 요구사항을 처리하도록 정제됩니다. 이 단계의 중요한 입력에는 특수 요구사항 및 책임에 이미 설명되었을 수 있는 분석 클래스의 비기능적 요구사항을 포함합니다. 이러한 요구사항은 종조 클래스 구현에 필요한 구조적(분석) 메커니즘의 관점에서 지정됩니다. 그런 다음, 이 단계에서 클래스가 이러한 분석 메커니즘에 대응하는 설계 메커니즘을 통합하도록 정제됩니다.

사용 가능한 설계 메커니즘이 ../artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated website프로젝트 특정 가이드라인의 소프트웨어 아키텍트에 의해

Rational Unified Process   2003.06.15