[컴퓨터공학]/[소프트웨어공학]

[소프트웨어공학] 클래스 다이어그램(Class Diagram)

딥러닝 도전기 2022. 3. 17. 21:57

[소프트웨어공학] UML 다이어그램

이전 포스팅에서 UML기본 표기 형식 및 표현법에 대하여 다루었습니다.

https://deep-learning-challenge.tistory.com/68

 

[소프트웨어공학] UML 정의와 종류

[소프트웨어공학] UML 정의와 종류 UML 정의 UML이란 Unified Modeling Language의 약자로, 프로그램 설계를 표현하기 위하여 사용하는 "모델링 언어" 입니다. 시스템의 산출물을 규정하고 문서화하기

deep-learning-challenge.tistory.com

이번 포스팅에서는 UML다이어그램의 종류에 대해 간단히 말씀드리고, Class Diagram을 다루도록 하겠습니다. 내용이 많다 보니 여러 편으로 나누어 질 것 같습니다.

 


 

UML다이어그램은 UML(Unified Modeling Language)을 사용하여 도식화한 다이어그램입니다.

대규모 프로젝트를 진행하기 전, UML다이어그램을 그리게 되면 시스템 설계자와 개발자가 응용프로그램을 이해하고, 협업하며 개발하는데 용이합니다.

 

UML다이어그램의 종류는 다음과 같습니다.

  • 구조 다이어그램(Structure Diagram)
    • 클래스 다이어그램(Class Diagram)
    • 컴포넌트 다이어그램(Component Diagram)

 

  • 행위 다이어그램(Behavior Diagram)
    • 유스케이스 다이어그램(Use-case Diagram)
    • 시퀀스 다이어그램(Sequence Diagram)
    • 콜라보레이션 다이어그램(Collaboration Diagram)
    • 상태 다이어그램(State chart Diagram)
    • 활동 다이어그램(Acticity Diagram)

 


1. 클래스 다이어그램(Class Diagram)

  • Class diagram은 시스템의 논리적인 관점에서 Class들과 Class들 사이의 관계를 표시
  • Class diagram의 요소
    • 클래스와 그들의 구조 및 행위
    • 클래스들 사이의 관계
      1. Association (연관)
      2. Aggregation (집합연관)
      3. Dependency (의존)
      4. Inheritance (상속)
    • 개수와 상호 참조 표시자(Multiplicity and navigation indicators)
    • 역할 이름(Role names)
  • Class 표기

 

$-, +$ : 객체 외부에서 접근이 가능한지, 불가능한지 (private, public)

보통 속성은 모두 $-$ (객체 외부에서 접근 불가능), 메소드는 $+$ (객체 외부에서 접근 가능)

 

예시를 통해 클래스 다이어그램을 살펴보도록 하겠습니다.

 

클래스 다이어그램 예시

 


우선 가장 상단의 Customer - Order의 관계를 살펴보면, (양방향)연관관계로 연결되어 있습니다.

양방향 연관관계는 두 객체가 서로의 객체를 참조할 수 있음을 의미합니다. 

해당 선 위에 써있는 숫자는 다중성을 의미합니다. 

$0..*$은 0개 이상을 의미하며, Customer가 Order를 0개 이상을 가질 수 있다는 것을 의미합니다.

 


다음으로 Order - Payment 의 관계를 살펴보겠습니다. 둘 사이는 직접연관관계로 연결되어 있는 것을 확인하실 수 있습니다. 직접 연관관계는 한쪽 객체만 다른 객체를 참조할 수 있습니다.

위의 경우, Order가 Payment 객체를 참조할 수 있습니다.

동일하게 $1..*$은 "1개 이상"을 의미합니다.


다음으로 Payment와 Payment를 상속받는 Credit, Cash, Check 부분을 살펴보도록 하겠습니다.

일반화 관계는 "상속"을 의미합니다.

Credit, Cash, Check클래스가 각각 Payment라는 클래스를 상속받는 것을 알 수 있습니다.

간단하게 Skeleton code를 살펴보면 다음과 같습니다.

 

public class Payment{
 	...
}

public class Credit extends Payment{
	...
}
public class Cash extends Payment{
	...
}
public class Check extends Payment{
	...
}

OrderDetail과 Item의 관계는 위에서 다루었던 직접연관관계이니 생략하도록 하고,

합성연관으로 관계되어있는 Order와 OrderDetail 부분을 살펴보도록 하겠습니다.

 

합성연관관계는 범위가 큰 class가 사라지면 그 컴포넌트들도 사라지는 관계입니다.

Order가 사라지면 당연하게 OrderDetail또한 사라지겠죠.

(+line item 이라고 쓰여 있는 것은 역할을 명시해주기 위한 것 입니다. : role name )

 

이번 포스팅은 여기에서 마무리 하고, 다음 포스팅은 컴포넌트 다이어그램을 소개하도록 하겠습니다.

 

 

반응형