06. Class Diagram
OOP/OOAD/UML에 대해 알아보자
06. Class Diagram
2.2 Class Diagram
위와 같이 Class Diagram의 전반적인 Notation을 다를 예정이다 우선 순서대로 하나씩 보자
- OOA/OOD 단계에 따라 관점이 다르게 작성됨
- OOA : 도메인 모델 작성에 사용
- Attribute/Behabor 생략하고 Association도 실선 한개만 그리고 두리뭉실하게 그림
- OOD : DCD(Design Class Diagram)로 작성됨
- 코드 레벨로 구현할수 있도록 위 생략된 부분들을 구체화 시켜 적음
- OOA : 도메인 모델 작성에 사용
- Class Diagram UML에서 Object을 위와 같이 표현이 가능
-
소문자(+밑줄도 가능)
: Object -
소문자(+밑줄도 가능):Class
: Object/Class - ‘:Class’ : Anonymouse Class(현재 시점에 오브젝 이름을 지칭할수 없을때사용)
- 자세하게 Value까지도 표현 가능
-
- Object Diagram으로 특정 시점의 존재하는 객체의 관계를 표현 가능
- 특정 시점에 HelenLewis는 oom/iprog를 듣고 있고, mikefox는 iplog만 듣는게 확인 가능
- Class Diagram으로 그려본다면 녹색과 같이 표현이 됨
- Object에서 Class로 넘어갈떄 표현 방법
- Class Attribute 표현,
:
타입만 작성- 추가로 Attribute/Operations들을 Class를 정의함
- Object는 Attribue,
=
값 작성, `Operation은 작성할 필요 없음!
- Class Attribute 표현,
Default 표기 (Attribute는 -, Operation는 +)
+/age
:Derived Attribue
로 다른 값에 의해 계산되어 나오는 값임을 나타냄dob(date of birth) : 값을 통해서 매년 값이 바뀌는 age를 계산하도록 함
attribute는 소문자로 시작
- 타입은 데이터 타입과 클래스 타입이 있음(예시엔 클래스 타입은 안보임)
- 데이터 타입의 경우 Primitive data/Enumerations(열거형) Type 이 있음
- Primitive data 위 표처럼 쓰면 됨
- 사용자 정의 타입을 적고자 할 경우 스테레오 타입 표기로
<<primitive>>
로 하고 attribute/operation 다 적어주기 가능 - Composite data type (Structure를 말함) : Operation이 없음. C의 Struct랑 동일하다 생각하면 되며 Operation이 있으면 Class가 됨.
- 사용자 정의 타입을 적고자 할 경우 스테레오 타입 표기로
- Class Diagram이 아닌 Attribute의 Multiplicity 표현이 가능
- 기본은 1이나
String[1...*]
와 같이 표기된 경우 여러개가 올수도 있다는 뜻임- address의 경우 한줄로만 적을수도 있으나 2줄 이상으로 적을수도 있어 1…*로 표현
- 거의 사용하진 않으나 특정 attribute의 초기값을 적어 놓기 가능
- 특징들을
{}
안에 적어놓을 수 있음- 구현단계에서 코드 생성 시 참고용으로 notation을 적는 거임
- Operation 파라미터 Syntax
- C++/Java 등과 같은 문법을 고려하지 않고 사용하고 있지 않아 애매함. 포인터가 없는 언어의 경우 out을 구현하기 힘듦
- 따라서 in만 사용하여 작성함
- default는 in
- Operation는 디자인 클래스 다이어 그램까지만 사용하고,
- 코드 구현이 되었다면 Methods라고 사용해야함
- Operation : 함수 이름만 정의하고 body를 채우지 않은 상태
- Method : 구현한 결과물
- class용 Variable/Operation를 사용할수 있음
- static으로 인스턴스 생성 없이도 사용되는 변수/함수로 Attribute/Operation에 밑줄을 그어 표기
- ex. 모든 객체가 공유해야하는 인스턴스 수 or 클래스 자체에 동작시켜야하는 로깅 시스템 초기화/유틸리티 함수 등
- static으로 인스턴스 생성 없이도 사용되는 변수/함수로 Attribute/Operation에 밑줄을 그어 표기
- private variable에 대해서 getter/setter를 두어 조작하도록 함(Information Hiding)
- private var이 생길때마다 getter/setter를 작성하기 귀찮음으로 UML Tool에서 자동으로 생성 또는 필터링 해주는 기능들이 요즘 있긴함
- UML에 Note를 작성하는 방법 (접힌 종이 표기 후 쫙 적으면 됨)
- 그떄 그떄 상황에 맞춰 그려주면 됨
- 5 종류의 클래스 관계가 있으며, 오른쪽으로 갈수록 강하게 Coupled 되어 있음
-
Aggregation
은 주로 (Shard Aggregation)으로 표현 -
Default는 Association
이 default임 -
Dependency
: 구현 직전인 Composition Diagram에만 주로 보이고 그 이전엔 잘 안씀- ex. 다른 객체로 부터 값을 전달 받아 사용하는 경우, 객체 ref를 전달 받아 local 변수로 copy해서 사용 시 해당 객체는 local 변수로 copy하는 순간 해제됨. 따라서 특정 시간이 아닌 work brief로 사용되는 경우에 표현
-
Association
: 다른 클래스의 object와 특정 시간 같이 일을 하는 경우 Association 관계 표현(Has-a 관계로 생각해도 된다고 함) -
Shard Aggregation(하얀 마름모)
: obj life cycle동안 삭제해도 다른 obj와 shared 하는 녀석이라 삭제하지 않는 obj -
Composition(검은 마름모)
: obj life cycle동안 쭉 함께하는 관계 -
Inheritance(상속)
: 상속 받는 경우(is a 관계)
-
- Association
-
A->B
A는 B의 public한걸 다 볼수 있으나 B는 A의 걸 다 못봄
- 선으로 다 표현하기 어려움으로 주로 +로 적는걸 많이 씀
- 최종적인 가이드라인
- 일반적인 타입은 - default니 attribute를 적어주나,
- custom or 다른 클래스인 경우 Association line으로 적어주는걸 권고함
- 비지니스 프로세스 개발할떄 사용, SW에선 잘 안씀
- 클래스 Association에 붙는 Association Class
- 거의 잘 안쓰나 알아두면 좋음
- Employment 정보를 company/person 두개중 어느곳에 놓아도 구조가 좋지 않음
- company측에 들고 있자니 person은 너무 많음
- person측 company는 1:1 관계가 아니라 1:N이라 person측에도 들고 있기 좋지 않음
- 따라서 별도의 관계 클래스를 만들어서 Attribute를 표현. (구현은 HashTable로 salary를 가져오도록 구현)
- 클래스당 obj이 1개만 나올 경우 싱클톤의 표현 오른쪽 위에 1을 표현
- OOAD에선 클래스내 오브젝트관계에 collaborate가 원활하게 일어나야 좋음으로 singletone은 좋지 않음
- active class : Thread가 되는 클래스를 말함 (양쪽에 선을 그어버리면 됨)
- 클래스 다이어 그램 수준에서 인터페이스 클래스의 Implementation은 점선 화살표 연결
- socket +lolipop 표현도 있음 (오른쪽에 있는거임)
Aggregation
- Aggregation 관계는 2가지가 있음
- Shared Aggregation : obj이 같이 del 될 필요가 없으면 흰색 마름모
- Composition : obj이 같이 del 되어야하면 검은색 마름모(composition)
Aggregation - Shared Aggregation
- B가 A를 가지고 있는 거임
- LabClass가 없다고 해서 Student가 다 없어지진 않음
Aggregation - Composition
- B가 A를 가지고 있는 거임
- Building이 없어지면 LectureHall도 사라지며 Beamer도 없어짐
- 하나의 차가 타이어 4개를 가지고 있을 떄 없어지면 타이어도 없어지니 첫번쨰는 맞음
- 정비소가만 타이어만 있을수 있음으로 0/1 표기가 없는 composition 관계는 옳지 않음
- 차가 타이어 4개를 공유하는 구조는 없음
- 1개 또는 2개의 타입을 하나의 차가 공유는 가능(바퀴 교체할때 앞에만 교체하는 경우도 있음) => 추후 디자인 패턴 때 Aggregation에 따른 관계를 더 자세히 다룰 예정. 지금은 사라지냐/안사라지냐로 알고 있어도 될듯함
Generalization
- 가장 강한 관계(Inheritance)
- parent class의 모든 Association 관계 + Attribute/Operation들을 다 SubClass가 물려 받음
Generalization - Abstract Class
- child만 new instance를 해서 사용하는 경우를 말함
- (abstract)를 써도 되고 기울기 표기로 표시해도 됨
Generalization - Multiple Inheritance
- 자바는 양쪽에서 상속을 받는게 안됨. C++는 가능
- Generalization을 사용하면 이해는 쉬우나 클래스 개수가 더 늘어남
- 적절하게 사용하면 됨
- Class Diagram을 한번에 잘 그리는 방법은 없음.(There are no silber bullet in SW Architecture)
- 명사는 클래스를 말하고, 형용사는 어트리뷰트, 동사는 operation을 말한다곤 하지만 경험을 잘 살려 작업해야함
- 정도가 없이 수단과 방법을 가리지 않고 작성해야함
Quiz
Ans
- 정답 4번, Attribue default private, operation default public!
Ans 1
- 부모 클래스의 Public한 Attribue/Opertion만 내려감. Private한건 내려가지 않음
Homework
Ans 가게 하나에 오더 한개씩은? 의문이 좀 드는 부분 만든사람의 의도를 알 있고, student랑 강의실이랑 연결되어야하는데 안되어 있음.(빨간색 줄) 추가로 제일 왼쪽이랑 밑이랑 구성도 몇대몇인지 how to many 개수도 안적어 놓음 이건 그냥 참고용으로 이런 그림도 나올수 있음을 참고하라
![]()
This post is licensed under
CC BY 4.0
by the author.