https://sundaland.tistory.com/153
UML은 다이어그램을 사용하여 시스템이나 데이터베이스를 시각화하는 방법이다.
소프트웨어 시스템을 계획하기 위해 자주 사용된다.
UML Class Diagram
UML 클래스 다이어그램은 소프트웨어 시스템의 클래스들과 그들 간의 관계를 시각적으로 표현되는 도구이다. UML 클래스 다이어그램은 주로 객체 지향 소프트웨어 개발 과정에서 사용되며, 시스템의 구조를 분석하고 설계하는데 중요한 역할을 한다.
클래스 다이어그램은 시스템의 초기 설계 단계에서 매우 유용하며, 개발자들이 시스템의 구조를 명확하게 이해하고, 객체 간의 상호작용을 쉽게 파악할 수 있게 도와준다. 또한, 클래스 다이어그램은 시스템은 문서화 과정에서도 중요한 역할을 하며, 새로운 팀원이나 외부 이해관계자들이 시스템을 더 쉽게 이해할 수 있도록 돕는다.
Vital components of a Class Diagram
Upper Section
UML 다이어 그램에서 클래스는 보통 세 개의 수평 섹션으로 나누어진다. 이 섹션들은 각각 클래스의 이름, 속성(Attributes), 메서드를 나타낸다. 그중 가장 위에 위치한 섹션을 Upper Section이라고 한다. 여기서 클래스 이름이 표시된다.
- 클래스 식별 : 해당 클래스의 이름을 표시함으로써, 다이어그램에서 클래스를 식별할 수 있게 한다. 이 이름은 클래스의 인스턴스가 가질 수 있는 객체 유형을 정의한다.
- 클래스 범주화 : 이름을 통해 클래스가 어떤 객체들을 나타내는지 명확히 한다.
- 시각적 식별 : 다이어그램 상에서 다른 클래스들과 구별하기 쉡게 해주며, 복잡한 시스템에서도 클래스를 쉽게 찾을 수 있게 돕는다.
디자인 관례적으로 클래스으 이름은 대문자로 시작하는 카멜 케이스를 사용하는 것이 일반적이다.
간결하고 명확하게 클래스의 이름만을 표함하여, 특별한 상황을 제외하고 다른 정보는 포함하지 않는다.
Middle Sectiom
클래스의 속성을 나열하는 부분으로, 속성은 클래스의 인스턴스가 가지는 데이터 필드를 의미한다. 객체의 상태를 정의하며, 각 속성에는 명시된 데이터 타입이 있어 객체가 저장하고 관리할 수 있는 정보의 유형을 표시한다.
- 속성 이름 : 각 속성의 이름을 명시
- 데이터 타입 : 속성이 저장할 수 있는 데이터의 종류를 나타낸다.
- 디폴트 값 : 필요한 경우, 속성의 디폴트 값을 설정할 수 있다. 이는 객체가 생성될 때 해당 속성이 초기화되는 값을 제공한다.
- 객체의 상태 정의 : 속성들은 객체의 현재 상태를 기술하는 정보를 담고 있으며, 이 정보는 객체의 행동에 직접적인 영향을 미친다.
- 데이터 관리 : 속성들은 클래스가 처리할 데이터를 구체적으로 명시함으로써, 객체가 어떤 정보를 관리하고 처리할 수 있는지를 정의한다.
- 타입 안정성 제공 : 각 속성에 데이터 타입을 명시함으로써, 해당 데이터 타입에 맞는 값만을 속성에 할당할 수 있도록 한다. 이는 데이터의 정확성과 프로그램의 안정성을 향상시킨다.
디자인 관례적으로 속성을 이렇게 표현한다.
- 접근 제어자 : 속성의 접근성을 제어한다. public(+), private(-), protected(#)
- 이름 : 속성의 이름을 나타낸다.
- 타입 : 속성이 저장할 데이터의 타입을 나타낸다.
- 기본값 : 선택적으로, 속성이 기본적으로 가질 값을 명시할 수 있다.
이렇게 클래스의 구조적인 특성과 데이터 관리 방식이 명확하게 드러나며, 개발자는 객체가 어떤 정보를 내포하기 있는지 쉽게 이해할 수 있다.
Lower Section
클래스의 메서드를 나열하는 부분이다. 섹션은 클래스 인스턴스의 행동이나 기능을 정의한 메서드를 포함하여, 객체가 수행할 수 있는 작업들을 나타낸다.
- 메소드 이름 : 각 메서드의 이름을 명시한다.
- 파라미터 : 메서드가 받아들이는 입력 값들을 나타낸다. 파라미터는 괄호 안에 표시되며, 각 매게변수의 이름과 데이터 타입을 포함한다.
- 반환 타입 ** : 메서드가 실행 후 반환하는 데이터의 타입을 명시한다. 이는 메서드의 결과를 나태내며, 어떤 타입의 값을 반환할지를 지정한다.
- 행동 정의 : 메서드는 클래스의 행동을 정의한다.
- 상호작용 구현 : 메서드는 클래스가 다른 객체나 시스템의 다른 부분과 상호작용하는 방식을 구현한다. 으를 통해 객체 간의 커뮤니케이션 및 데이터 교환을 가능하게 한다.
- 기능 제공 : 객체가 수행할 수 있는 구체적인 작업이나 계산 등을 제공한다. 이는 객체가 어떤 서비스나 기능을 외부에 제공할 때 중요하다.
디자인 관례적으로 메서드를 이렇게 표현한다.
- 접근 제어자 : 메서드의 접근성을 제어한다.
- 이름 : 매서드의 이름을 나타낸다.
- 매게변수 : 메서드에 전달되는 인자의 타입과 이름을 포함한되.
- 리턴 타입 : 메서드가 실행 후 반환할 데이터의 타입을 명시한다.
이를 통해 클래스의 객체가 어떤 작업을 수행할 수 있는지, 그리고 어떻게 다른 객체와 상화작용할 수 있는지 명확하게 이해할 수 있으며, 개발자는 이를 통해 객체의 행동을 적절하게 설계하고 구현할 수 있다.
Implementation Perspective
UML에서는 소프트웨어 개발 프로세스의 한 부분으로, 시스템의 실제 구현 단계와 관련된 요소들을 다룬다.
이 관점을 소프트웨어가 설계 단계에서 어떻게 구체화되고 실제로 작동하는 코드로 변환되는지를 중점적으로 보여주는데 사용된다.
- 코드 구현 : 설계된 모델을 실제 프로그래밍 언어로 전환하는 과정이다. 이것은 클래스 다이어그램에서 보여진 클래스들이 실제 코드 내에서 어떻게 정의되고 구현되는지를 포함한다.
- 컴포넌트 및 패키지 : 시스템이 구성되는 더 큰 구조적 단위인 컴포넌트와 패키지를 모델링한다. 이들은 코드의 물리적은 구성을 나타내며, 어떤 파일들이 어떻게 조직되어 있는지, 또 서로 어떻게 연결되어 있는지를 설명한다.
- 배포 다이어그램 : 소프트웨어가 어떻게 다양한 하드웨어 리소스에 배포되는지를 보여주는 다이어그램이다. 이는 실행 가능한 파일, 라이브러리, 시스템 설정 등이 실제 서버나 클라이언트 기기에서 어떻게 배치되어야 하는지를 나타낸다.
- 인터페이스 정의 : 시스템의 다양한 부분 사이의 상호작용을 가능하가 하는 인터페이스를 구현한다. 이는 클래스와 컴포넌트가 어떻게 서로 통신하고 데이터를 교환할 수 있는지에 대한 멩세를 제공한다.
- 실제 구현과 연계 : 이 관점은 개발자들이 설계 문서를 실제 작동하는 코드로 변환하는데 필요한 세부 정보를 제공한다. 개발자는 이 정보를 통해 정확하고 효율적인 구현을 보장할 수 있다.
- 효율적인 배포 및 관리 : 배포 다이어그램과 같은 요소들은 시스템이 실제 운용 환경에서 어떻게 설치되고 관리되어야 하는지에 대한 중요한 정보를 제공한다.
- 시스템의 완성도 및 안정성 증진 : 모든 설계가 코드로 잘 옮겨지고, 모든 컴포넌트가 적절히 배포되며, 모든 인터페이스가 잘 정의되어 있으면 시스템의 완성도가 높아지고 안정성이 강화된다.
UML을 사용하여 복잡한 시스템을 개발할 때 필수적인 요소 중 하나로, 이를 통해 설계와 실제 구현 사이의 간극을 메울 수 있다. 이러한 접근 방식은 특히 대규모 프로젝트나 다양한 하드웨어와 소프트웨어 구성 요서가 통합되는 시세틈에서 매우 중요하다.
# 직선 아래에 관계 상태를 표시한다. 1대1 관계면 숫자 1을, 1대다 관계면 1..* 을, 다대다 관계면 * 를 사용한다.
연관 관계 (Association)
두 클래스 또는 객체 사이의 관계를 나타내는 중요한 모델링 개념이다. 이 연관 관계는 한 클래스의 객체들이 다른 클래스의 객체들과 어떻게 상호작용하는지를 설명하며, 데이터 모델이 소프트웨어 시스템의 구조적인 측면을 표현할 때 사용된다.
- 양방향성 : 대부분의 경우 양방향성을 가진다.
- 다중성(카디널리티) : 각 연결 끝에서의 다중성을 명시할 수 있다. 다중성은 연관된 객체들의 사이의 가능한 인스턴스 수를 나타낸다.
- 역할 : 각 연결 끝에는 역할 이름이 붙을 수 있다. 해당 클래스가 연관 관계에서 어떤 역할을 하는지 설명한다.
- 내비게이션 : 연관은 내비게이션이 가능할 수 있다. 한 클래스에서 다른 클래스로의 접근 경로를 표시할 수 있다. 내비게이션은 종종 화살표로 표현되어 어느 방향으로 데이터가 흐르는지 나타낸다.
- 집합과 합성의 관계 : 더 특정한 형태의 집합(Aggregation)과 합성(Composition)으로 세분화될 수 있다. 집합은 전체와 부분의 관계를 약하게 나타내며, 합성은 더 강한 종속적 전체와 부분의 관계를 나타낸다.
UML 다이어그램에서는 직선으로 표현(ㅡ>) 한다
일반화/상속 관계 (Generalization)
객체 지향 프로그래밍의 상속 개념을 표현하는 방법이다. 일반화는 한 클래스(하위/자식)가 다른 클래스(상위/부모)의 속성과 행동을 상속받는 관계를 나타낸다.
이를 통해 코드 재사용성을 높이고, 시스템의 계층적 구조를 명확하게 만들어 유지보수와 확장성을 개선한다.
- 계층적 관계 : 클래스간의 계층적 관계를 설립합니다. 상위 클래스는 공통의 속성과 메서드를 정의하며, 하위 클래스는 이를 상속 받아 추가적인 특성이나 행동을 구현할 수 있다.
- 재사용성 및 확장성 : 상위 클래스의 코드를 재사용하여 각 하위 클래스가 필요로 하는 특수한 기능만 추가함으로써, 개발 시간을 절약하고 시스템의 확장성을 향상시킬 수 있다.
- 타입 계층 : 하위 클래스는 상위 클래스의 타입을 유지한다. 이는 다형성을 가능하게 하여, 상위 클래스 타입으 변수가 하위 클래스의 인스턴스를 참조할 수 있게 한다. 이로 인해 더 일반적인 코드 작성이 가능해지며, 다양한 실행 시나리오에서 유연성을 제공한다.
- 추상화 : 종종 상위 클래스는 추상 클래스로 구현된다. 추상 클래스는 인스턴스화될 수 없으며, 하나 이상의 추상 메서드를 포함할 수 있다. 이러한 메소드는 하위 클래스에서 구현되어야 한다.
- UML 표기법 : UML 다이어그램에서 일반화/상속 관계는 하위 클래스에서 상위 클래스로 향하는 빈 화살표 (ㅡ▷)로 표현된다. 이 화살표는 일반적으로 하위에서 상위로의 상속을 나타내며, is a 관계를 설명한다.
일반화/상속 관계는 시스템의 설계를 단순화하고 코드의 재사용성을 극대화하는 중요한 방법으로, 객체 지향 설계의 핵심 요소 중 하나이다. 이를 통해 개발자는 보다 깔끔하고 관리하기 쉬운 코드를 작성할 수 있다.
실체화/구현 관계 (Realization)
한 요소가 다른 요소의 사양이나 계약을 구현할 때 사용되는 관계를 나타낸다. 일반적으론 인터페이스와 그 인터페이스를 구현하는 클래스 사이간의 관계로 표현된다. 이 관계는 인터페이스의 모든 메서드를 구현해야 함을 의미한다.
- 인터페이스 구현 : 클래스가 인터페이스의 사양을 구현한다는 것을 나타낸다. 인터페이스는 메서드의 시그니처만을 제공하고, 실제 메서드의 본체는 클래스에서 정의된다.
- 계약 준수 : 클래스는 인터페이스에 정의된 모든 메서드를 구현해야하며, 이는 클래스가 인터페이스가 요구하는 계약을 준수해야 함을 의미한다.
- 다형성 지원 : 인터페이스를 사용하면 다양한 클래스가 동일한 인터페이스를 구현할 수 있으므로, 다형성을 통해 코드의 유연성과 재사용성을 높일 수 있다. 이는 다양한 객체가 같은 인터페이스를 공유할 수 있으므로, 코드 내에서 객체를 교체하기 쉬워진다.
- UML 표기법 : 실현/구체화 단계는 점선으로 된 화살표와 함께 화살표 끝에 빈 삼각형 (- - -▷)을 사용하여 표현된다. 화살표는 구현 클래스에서 인터페이스로 향한다.
- 유연성과 확장성 : 인터페이스의 구현은 코드의 유연성을 높이고, 새로운 클래스가 시스템에 쉽게 추가될 수 있도록 한다.
- 유지보수성 : 인터페이스를 통해 시스템의 다양한 부분을 독립적으로 개발하고 수정할 수 있어 유지보수가 용의해진다.
- 재사용성 : 인터페이스를 구현하는 새로운 클래스를 만들 때 기존의 인터페이스를 재사용할 수 있으므로, 코드 중복을 줄이고 전체적인 프로젝트의 일관성을 유지할 수 있다.
객체 지향 설계의 중요한 부분으로, 클래스의 기능을 모듈화하고, 시스템의 다양한 구성 요소간에 명확간 계약을 설정하여, 전체적인 시스템 설계의 품질을 향상시킨다.
의존/주입 관계 (Dependency)
두 모델 요소간의 관계를 나타내며, 한 요소가 다른 요소에 의존하는 경우 사용된다. 의존성은 주로 한 요소의 변경이 다른 요소에 영향을 줄 수 있음을 의미한다. 이 관계는 일반적으로 임시적이거나 약한 결합을 나타내며, 변경의 전파 가능성을 표현한다.
- 약한 결합 : 시스템 내의 다른 요소들 사이의 약한 결합을 나타낸다. 의존하는 요소는 의존 대상 요소 없이는 그 기능을 완전히 수행할 수 없다.
- 변경 전파 : 한 요소가 변경될 떄 의존하고 있는 다른 요소에도 영향을 미칠 수 있다. 예를 들어, 한 클래스가 다른 클래스의 메서드를 호출하면, 호출되는 클래스의 메서드에 변경이 생길 경우 호출하는 클래스도 옇양르 받을 수 있다.
- 방향성 : 방향성을 가지는데 이는 한 요소가 다른 요소에 의존한다는 것을 나타내며 UML 다이어그램에서는 점선 화살표 (- - ->)로 표현된다. 화살표는 의존하는 요소에서 의존 받는 요소로 향한다.
- 사용 시나리오 : 한 클래스에서 다른 클래스의 인스턴스를 사용하는 경우 (Use), 한 클래스가 다른 클래스의 인스턴스를 생성하는 경우 (Create), 한 클래스의 메서드가 다른 클래스의 메서드를 호출하는 경우 (Call), 한 요소의 값이 다른 요소의 값에 의해 파생되는 경우 (Derive)
이는 다이어그램을 보는 사람에게 한 요소가 다른 요소의 구현이나 행동에 직간접적으로 의존한다는 것을 명확하게 보여준다.
시스템 설계에서 중요한 요소간의 관계를 명확히하고, 시스템의 설계를 이해하며 리팩토링이나 확장시 결정을 내리는 데 중요한 역할을 한다. 시스템의 유연성과 유지보수성을 높이기 위해 종종 의존성을 최소화하는 방향으로 설계를 고려한다. 이런 관계를 명확하게 모델링하고 관리함으로써, 시스템 내의 요소들이 서로 어떻게 상호작용하는지, 그리고 어떤 요소가 시스템의 다른 부분에 어떤 영향을 미칠 수 있는지 이해할 수 있다.
집합 관계 (Aggregation)
특별한 형태의 연관 관계로, 전체-부분 (Whole-Part) 관계를 나타낸다. 이 관계는 한 객체가 다른 객체를 포함하지만, 포함되는 객체가 독립적인 생명주기를 갖는다는 것을 의미한다.
즉, 전체 객체가 소멸해도 부분 객체는 그대로 존재할 수 있다.
- 전체와 부분의 관계 : 객체 간에 전체와 부분의 관계를 나타내며, 이는 한 객체(전체)가 다른 하나 또는 여러 객체(부분)을 포함하는 것을 말한다. # 책은 도서관이 없어도 존재할 수 있다.
- 독립적인 생 명주기 : 부분 객체가 전체 객체에 속해있지만, 자신의 생명주기를 독립적으로 갖는다. 이는 부분 객체게 전체 객체와 함께 생성되거나 소멸할 필요가 없다는 것을 의미한다.
- 공유 가능성 : 부분 객체게 여러 전체 객체에 공유될 수 있음을 나타낼 수 있다.
- UML 표기법 : UML 다이어그램에선 실선과 함께 빈 다이아몬드(ㅡ◇)로 표현된다. 화살표는 전체 객체에서 부분 객체로 향하며 빈 다이아몬드는 전체 객체의 끝에 위치한다.
시스템 설계에서 객체 간의 관계를 명확하기 정의하고, 객체의 구조와 상화작용을 효율적으로 관리하기 위해 중요한 모델링 도구이다. 이를 통해 시스템 설계자와 개발자는 객체들 간의 관계를 더 잘 이해햐가, 시스템을 구조를 효과적으로 계획할 수 있다.
포함 관계 (Composition)
객체 간의 강한 전체-부분 관계를 나타낸다. 이 관계는 집합 관계보다 강한 형태로, 부분 객체는 전체 객체의 생명주기와 완전히 종속되어 있음을 의미한다. 즉 전체 객체가 소명하면 그와 연결된 부분 객체들도 함께 소멸한다.
- 강한 전체-부분 관계 : 전체 객체와 부분 객체간의 강한 의존성을 나타낸다. 부분 객체는 전체 객체에 속해있으며, 전체 객체 없이 존재할 수 없다.
- 독점적 소유 : 전체 객체는 부분 객체를 독점적으로 소유한다. 부분 객체는 다른 어떤 전체 객체와도 공유되지 않는다.
- 생명주기의 종속성 : 부분 객체의 생성과 소멸은 전체 객체의 생성과 소멸에 직접적으로 연결되어있다. 이는 전체 객체가 관리하는 자원이나 구성 요소가 전체 객체와 동일한 생명주기를 갖는다는 것을 의미한다.
- UML 표기법 : UML 다이어그램에선 실선과 함께 채워진 검은 다이아몬드로 표시되는 화살표(---◆)로 나타낸다. 화살표는 전체 객체에서 부분 객체로 향하며, 채워진 다이아몬드는 전체 객체의 끝에 위치한다.
시스템 설계에서 전체 객체와 그에 속하는 부분 객체 간의 강력한 연결을 명확히 할 필요가 있을 때 사용된다. 이러한 모델링은 시스템의 구조적 무결성을 보장하고, 객체 관리와 자원 해제를 더욱 효과적으로 할 수 있게 도와준다. 시스템의 유지보수와 확장성에 중대한 영향을 미치며, 개발자가 객체 간의 관계를 더 명확하게 이해하고 정확히 구현할 수 있도록 한다.
'Toby Spring 3.1' 카테고리의 다른 글
관심사의 분리 (Separation of Concerns) (0) | 2024.08.08 |
---|---|
아티팩트, DAO, JAVA Bean (0) | 2024.08.08 |
원칙과 패턴 (Open-Closed Principle) (0) | 2024.08.08 |