[OOP/UML] Class Diagram

# UML Class Diagram

OOD에서 UML Class Diagram은 두 가지 뜻으로 쓰인다. 

1. Domain model

2. Design Class Diagram (DCD)

 

# Object 

- 소문자로 시작

- 어느 클래스에서 왔는지 적고싶으면 콜론하고 적음

- Operation은 해당 클래스는 다 같은 것을 가지므로 표시하지 않음

 

# Object Diagram

- 별거없고 관련있는 오브젝트끼리 연결한 것. 

# Attribute Syntax

+ : public (default for operation)

- : private (default for attribute)

# : protected

~ : package

/ : 값을 직접 넣는게 아니라 계산되는 값 

name : 소문자로 시작

type : String / int / Date 등 또는 Class 이름도 가능

    > primitive data type 

        - Predefined : Boolean, Integer, String 등..

        - User-defined: <<primitive>> 로 표기

        - Composite data type: <<datatype>>으로 표기

    > Enumerations

Multiplicity: String[1...*]이렇게 되어있으면 String이 한 줄 또는 여러 줄이라는 뜻 (없으면 default 한 줄)

Default Value: String="pw123" 이런 식으로 값 지정

Properties: 중괄호 안에 특성 기입

# Operation Syntax

별거없음. 언어에 따라 다른데 out은 잘 안씀. 

# Operation and Method

- Operation을 특정 언어로 구현한 것을 Method라고 함. 

- Metod는 누가 구현했냐에 따라 다를 수 있음

 

# Note Symbol

오른쪽 위가 접힌 종이 모양. 적고싶은거 다 적으면 됨. (코드, 코멘트, 제약사항 등..)

 

 

# Class Relationship

- Association이 default

# Association

한 클래스의 오브젝트가 다른 클래스의 오브젝트들과 오랫동안 같이 작동할 때 

# Binary Association - Navigability

A클래스는 B클래스의 public들을 볼 수 있다. (사용할 수 있다. )

     > private는 안됨

 

A는 B에 정의된 것을 아무것도 볼 수 없다. 

(화살표만 있어도 X가 있는 것과 같음)

 

# Association - Association Class

- Association에 점선으로 연결된게 Association Class

- Person과 Company가 1:1이 아닌 n:1일 때, Person에 넣기 애매한 정보는 Employment에 넣음

 

# Association - Singleton Class

- 클래스 당 인스턴스가 하나만 있는 경우

- 오프젝트들의 커뮤니케이션이 원활하지 않으므로 좋지 않은 패턴 (가능하면 사용하지 말 것)

 

#  Association -  Active Class

- thread가 되는 클래스

- 박스 좌우에 세로선 하나씩 더 그으면 됨. 

 

# Interface

일반적으로 아래와 같은 형태를 많이 씀. 

notation에 socket + lollipop도 있는데 이건 component diagram에서 많이 씀. 

#  Aggregation

- 한 클래스가 다른 클래스의 부분일 때 (포함)

- 두 가지 타입이 있음. 

    1. Shared Aggregation (weak)

    2. Composition (strong)

 

# Shared Aggregation

- 보통 포함관계끼리 하나가 삭제되면 다른 하나도 삭제 되어야 함. 

    > 그렇지 않고 하나가 살아남을 수 있으면 Shared Aggregation (weak belonging)

 

- B가 A를 가졌다는 표시 (혼동 주의!)

<예시>

- LabClass가 없어졌다고 학생이 없어지는게 아님. 

- Study Program이 없어지면 Course가 없을 수도 있음. (StudyProgram이 1...*이므로)

  Study Program이 있어도 Course가 없을 수 있음. (*은 0도 포함)

# Composition

- B가 A를 가졌다는 표시

<예시>

- Building이 없어지면 LectureHall도 없어짐. 

- LectureHall이 없어도 Beamer가 있을 수 있음. 

    > 하지만 LectureHall이 있다면, LectureHall이 없어지면 Beamer도 없어짐. 

- 손이 없으면 손가락이 있을 수 없음. 

- 만약 Shared Aggregation이었으면, 손이 없어도 손가락은 남아있을 수 있음. 

# Shared Aggregation and Composition

1. 차가 없어도 타이어는 있을 수 있음. (O)

    > 단, 차가 있다면 없어질 때 같이 없어짐

2. 타이어는 반드시 차가 있어야만 존재 (X) 

3. 여러 대의 차가 타이어를 공유 (X)

4. 차마다 1~2개의 타이어 "타입"을 가지고 있음. (O) 

# Generalization (Inheritance)

- public만 상속됨. private는 상속되지 않음. 

- 똑같은 이름의 attribute를 쓰면 overwrite

 

# Abstract Class

- 본인은 new해서 인스턴스를 만들지 않음. 

- child만 new해서 인스턴스를 만듦. 

- 아래의 예시에서 person은 비어있으면 안됨. 사람 속성이 다 있어야됨. 

# Multiple Inheritance

- 자바는 안되고 C++는 됨

# Class Diagram 그리기

- 자동으로 class diagram을 쉽게 그리는 방법은 없다. 

- 명사를 기반으로 찾으면 조금 더 수월하다. 

 

# QUIZ

정답: 4번. 항상 표시되어야하는건 아니다. 

단, 적혀있다면 안적힌 attribute는 private, 안적힌 operation은 public이다. 

 

3번은 엄밀히 말하면 둘다 '항상'은 아님. 둘 중 하나만 있어도 됨. 

정답: 1번. 모든게 내려가는게 아니라 public만 내려감. private는 안내려감. 

 

정답: 1번. Shared Aggregation을 표현한 다이어그램. 

4. 없을수도 있다. (0이 있으니)

5. Book이 위에있음.