본문 바로가기
IT 이론/소프트웨어공학

UML Class Diagram의 구성과 예제

by 지식id 2012. 11. 26.
반응형

클래스들의 관계를 도식화하여 다타낸 것

Classes : 해당 데이터 그 자체를 나타댐
Attributes : 클래스에서 사용되는 데이터, 속서들을 나타낸다. 인스턴스 변수.
Operations : 인스턴스가 수행하는 동작을 나타낸다.
Associations : 인스턴스들 끼리의 관계. 선과 짧은 어구로 표현된다.
└Aggregation : 여러 객체가 한 객체를 구성하는 관계를 나타낸다. 선과 빈 마름모(◇)로 표시된다.
└Composition : Aggregation관계이지만 더 종속관계 개념. 선과 속이 찬 마름모(◆)로 표시된다.
Generalizations : 클래스의 계승 상속관계를 나태낸다. 실선 화살표로 표현된다.
Interfaces : 객체의 행위의 일부를 정의 해 둔다. 점선 화살표로 표현된다.

 


1. Class만 표시된 것

2. ClassAttributes

3. ClassArrtibutesOperations ( operationName(parameterName: parameterType ...) : returnType )



Associations

 


 

  1. 여러명(*는 0~∞)의 직원은 회사에서 일을한다. (Many to one)
  2. 여러명의 비서는 최소 1명 이상(1..*은 1~∞)의 매니저를 상관으로 가진다.
    매니저는 비서가 있을 수도 있고 없을 수도 있다(0~∞).
  3. 하나의 회사는 하나의 이사회를 가진다.
  4. 직원에게 할당 된 사무실은 없거나 1개가(0~1) 있다.
    여러명의 직원(*)이 한 사무실을 사용 할 수도 있다.
  5. 이사회의 멤버는 없거나, 있다면 3명이상 8명 이하여야 한다.
    멤버는 여러 이사회에 속할 수 있다.



 

 

  1. 예약은 오직 한명의 승객에게만 귀속된다.
    (내가 예약 해 놓은걸 내 친구들이 사용 할 순 없다.)
    승객은 여러개의 예약을 할 수 있다. (하나도 안 할 수도 있다.)
  2. 여러개의 예약은 한 운행에 속 할 수 있다.
    (대구-서울로 가는 비행기에 탈 수 있는 승객이 200명이라면 200개의 Booking이 생길 수 있다.)
    한가지 예약으로 여러 운행을 예약 할 수 없다.
    (한개의 Booking으로 대구-서울도 가고 대구-제주도도 가는 만능표는 없다.)



 

 


클래스 사이의 연관을 짓는 클래스는 위와 같이 두가지 형태로 표현될 수 있다. 위 표현은 같은 표현이다.

 


클래스 자기 자신과 연관을 지을 수도 있다.
어떤 과목들은 어떤 과목들의 선행 과목 일수 있고, 이어지는 수업 일수도 있다.(Many to many)

 


클래스 끼리의 연관은 주로 양뱡향을 뜻하지만, 화살표를 이용해서 단방향만 표현 할 수 있다.
Day는 여러개의 Note를 가진다. Note가 Day를 가지진 않는다. (뭐지..)

Aggregation

 

 

 

자동차 부품들은 자동차를 구성하는 구성품(isPartOf - Whole)이다.
나라는 여러개의 지역으로 이루어져(Whole - Part) 있다.

Composition
Aggregation과 비슷하지만, Whole이 파괴되면 Part도 파괴되는 강한 종속을 나타낸다.

 


빌딩이 파괴되면 방도 파괴된다. 위 Aggregation과 비교하면
자동차가 파괴된다고 자동차 부품이 파괴되는 것은 아니며, 대한민국이 파괴된다고 대구가 파괴되는 것은 아니다.


그렇다면 빌딩이 미사일을 맞고 무너져 내려도 방이 다 파괴되는 것은 아니지 않냐.. 라는 사람이 있는데
현실의 관점이 아니라 프로그램 설계의 관점에서 이해 해야 한다. 예를 들어서

 

 


직원이 없어 진다고 직원의 집이 파괴되진 않는다. 현실에서는 말이 안되지만, 인사관리 프로그램에서는 직원이 퇴사하면 더이상 직원의 집 주소를 저장할 필요가 없음을 나타낸다.


자동차 설계 프로그램에서는 여러 부품들이 사용된 자동차 모델을 삭제 한다고 해서 사용된 모든 자동차 부품 인스턴스를 지울 필요는 없다. 다른 모델에서 사용 될 수도 있기 때문이다.

Generalizations


Specialize는 분류 기준에 따라 여러가지 구성이 나올 수 있다.
동물을 서식지를 기준으로 나누면 육상 동물과 해상 동물로 Specialize할 수 있다.
동물을 먹이를 기준으로 나누면 육식 동물과 해상 동물로 Specialize할 수 있다.

Interfaces
공통점이 있는 클래스들에게, 특정한 행동을 해야 한다는 것을 미리 정의해 놓는다.

 


위와 같이 두가지 방식으로 표현 될 수 있다. (위 두 표현은 같은 의미를 가진다.)
Employee와 ATM모두 Cashier라는 인터페이스를 implement한다. 이는, 직원과 ATM기계는 모두 돈을 입금 해 주고 출금 해 주는 행동을 할 줄 알아야 한다는 설계적 관점의 제약이다.

반응형

댓글