들어가기 전
통합 모델링 언어 UML
- Unified Modeling Language
- 소프트웨어 공학에서 사용되는 표준화된 범용 모델링 언어
- 시스템을 모델로 표현해주는 대표적인 모델링 언어
UML 다이어그램의 종류
1. 구조 다이어그램
- 클래스 다이어그램
- 객체, 복합체 구조, 배치, 컴포넌트, 패키지 다이어그램...
2. 행위 다이어그램
- 활동 다이어그램, 상태 머신 다이어그램, 유즈 케이스 다이어그램, 상호작용 다이어그램
클래스 다이어그램
- 통합 모델링 언어(UML)에서 시스템의 클래스, 클래스의 속성, 동작 방식, 객체 간 관계를 표시함으로써 시스템의 구조를 기술하는 정적 구조 다이어그램
- 객체 지향 모델링의 주요 빌딩 블록
- 응용 프로그램 구조의 일반적인 개념적 모델링, 또 모델링의 프로그래밍 코드로의 세세한 모델링 변환을 위해 사용
- 데이터 모델링용으로도 사용 가능
클래스
- 동일한 속성과 행위를 수행하는 객체의 집합
- 객체를 생성하는 설계도
- 즉, 클래스는 공통의 속성과 책임을 갖는 객체들의 집합이자 실제 객체를 생성하는 설계도
- 변화의 기본 단위
UML에서의 표현
- 접근제어자
- public(+)
- 어떤 클래스의 객체에서든 접근 가능
- private(-)
- 이 클래서에서 생성된 객체들만 접근 가능
- protected(#)
- 이 클래스와 동일한 패키지에 있거나 상속관계에 있는 하위 클래스의 객체들만 접근 가능
- package(~)
- 동일 패키지에 있는 클래스의 객체들만 접근가능
- default?
- public(+)
관계
1. 연관 관계 Association
- Person ───> Car
- 오랜 시간동안 같이할 객체와의 관계
- 한 클래스가 다른 클래스와 연관 관계를 가지면 각 클래스의 객체는 해당 연관 관계에서 어떤 역할을 수행하게 된다.
- 관계의 방향성
- 양방향: 실선
- 두 클래스의 객체들이 서로의 존재를 인식한다
- 일반적인 다대다 연관관계, 그러나 대개 단방향으로 변환해 구현함
- Professor ─── Student (상담)
- 단방향: 화살표
- 한 쪽은 알지만 다른 쪽은 상대방의 존재를 모른다
- Person > Phone (가진다)
- 양방향: 실선
- <-> 의존 관계 dependency
public class Person {
private Car owns;
}2. 의존 관계 Dependency
- Car ─ ─ ─ > GasPump
- 일반적으로 한 클래스가 다른 클래스를 사용하는 경우
- 연산의 인자(참조값)로 사용될 때
- 메서드 내부의 지역객체로 참조될 때
- <-> 연관 관계 Association
- 클래스의 속성(멤버 변수)에서 참조할 때
public class Car {
...
public void fillGas(GasPump p) {
p.getGas(amount);
}
}3. 일반화 관계 Generalization
- 세탁기, TV, 식기세척기 ────▷ 가전제품
- 상속관계 (<-> 실체화 관계realization)
4. 실체화 관계 Realization
- Plane, Bird ─ ─ ─▷ Flyable
- 책임들의 집합인 인터페이스와 이 책임들을 실제로 실현한 클래스들 사이의 관계
- <-> 일반화 관계 Generalization
5. 집합 관계 (애매)
- UML 연관 관계의 특별 경우로 전체와 부분의 관계를 명확하게 명시하고자할 때 사용
5-1. 집약 관계 Aggregation
- 메인보드, cpu ────◇ 컴퓨터
- 전체 객체와 부분 객체의 생명주기가 독립적
- 전체 객체가 메모리에서 사라진다 해도 부분 객체는 사라지지 않는다
- 한 객체가 다른 객체를 포함 하는 것
public class computer {
private MainBoard mb;
private CPU c;
//생성자에서 참조값을 인자로 받아 필드를 셋팅
public Computer(MainBoard mb, CPU c) {
this.mb = mb;
this.c = c;
}
}5-2. 합성 관계 Composition
- 메인보드드, cpu ────◆ 컴퓨터
- 전체 객체와 부분 객체의 생명주기가 의존적
- 부분을 나타내는 객체를 다른 객체와 공유할 수 없다
- 전체 객체가 없어지면 부분 객체도 없어진다
public class computer {
private MainBoard mb;
private CPU c;
//생성자에서 필드에 대한 객체를 생성
public Computer() {
this.mb = new MainBoard();
this.c = new CPU();
}
}게시판 클래스다이어그램
연관관계
- BoardMain ────> IBoardService
- BoardServiceImpl ────> IBoardDao
- BoardDaoImpl ────> SqlMapClientFactory
- 좌측 클래스가 우측 클래스의 객체를 가지고 계속 메소드를 호출하며 일을 수행한다.
오랜 시간동안 같이할 연관관계!! - aggregation 관계 (─────◇) 는 아님
- main은 service를 맴버객체로 가지지만 직접적으로 new 연산을 수행하지않고 getInstance()이용해서 aggregation인가 싶었는데 여기에서는 전체,부분과 같은 집합관계보다는
연관에 더 초점을 맞췄기때문에 association으로 봐야함
- main은 service를 맴버객체로 가지지만 직접적으로 new 연산을 수행하지않고 getInstance()이용해서 aggregation인가 싶었는데 여기에서는 전체,부분과 같은 집합관계보다는
의존관계
BoardMain,
IBoardService,
BoardServiceImpl - - - - - - > BoardVO
IBoardDao
BoardDaoImpl
- 위의 다섯 클래스가 BoardVO에 의존하는 관계이다.
- 메서드를 수행할때마다 대부분 BoardVO객체를 매개변수로 사용한다.
일반화관계
- 상속관계로 이루어진 클래스 없음
실체화관계
- BoardServiceImpl - - - - -▷ IBoardService
- BoardDaoImpl - - - - -▷ IBoardDao
- 각각 Impl 클래스가 인터페이스를 구현하고 있다.
출처
- 클래스 다이어그램: https://ko.wikipedia.org/wiki/클래스다이어그램
- 간단설명★: https://ehpub.co.kr/tag/%EC%9D%BC%EB%B0%98%ED%99%94-%EA%B4%80%EA%B3%84generalization%EC%A7%91%ED%95%A9-%EA%B4%80%EA%B3%84aggregation-%EA%B5%AC%EC%84%B1-%EA%B4%80%EA%B3%84composition-%EC%A7%81%EC%A0%91-%EC%97%B0/
- 상세설명: https://gmlwjd9405.github.io/2018/07/04/class-diagram.html
- 이클립스 이용: https://m.blog.naver.com/PostView.nhn?blogId=aufcl856&logNo=221138230736&proxyReferer=https:%2F%2Fwww.google.com%2F
갈 길이 멀다