1. Class Diagram 변환
다음은 UML( Unified Modeling Language ) 을 적용한 방법론을 채택한 프로젝트의 경우 실제 Class Diagram 을 정확히 해석하는데 도움이 될만한 부분을 나타낸다.
1.1 Attributes & Operations Setting ( Access Modifier )
위와 같이 Abstract Class 의 경우 다음과 같이 구현한다.
1.3 Class Inheritance
클래스 상속의 경우 다음과 같이 구현 한다 .
1.4 Interface Implementation
인터페이스 구현의 경우 다음과 같이 MyInterface interface 의 interfaceMethod 를 implements 하는
class 인 ImplClass 에서 구현한다 .
1.5 Association
Car class 와 Person class 의 관계는 Association 이다. Association 의 경우 한 Class 가 다른 Class 를
사용하는 것이기 때문에 두 Class 사이의 life time 과는 전혀 상관이 없다. 각각 독립적으로 생성되고 어떤 상태에
서로 연결되었다가 상태가 지나면 차후에 연결되지 않을 수도 있다. 다음과 같이 구현한다.
1.6 Aggregation
Car class 와 Engine class 의 관계는 Aggregation 이다. Aggregation 의 경우 Aggregation 관계로
표현되는 전체 객체의 생성 시기가 꼭 동일할 필요는 없고 소멸시에도 Aggregation 관계의 부분 Class 들이
다른 객체(전체 class 객체)에 의해 공유 될 수 도 있으므로 전체 객체가 소멸되는 것이 아니므로 다음과 같이 구현한다.
1.7 Composition
Car class 와 Engine class 의 관계는 composition 이다. Compositon 의 경우 객체의 생성과 소멸의 시기
( Object life Cycle ) 이 동일하므로 Car class 의 생성자 내에서 Engine class 를 생성 한다.
1.8 Dependency
Car class 와 AirCon class 는 dependency 관계를 갖는다. Dependency의 경우 객체의 생성과 소멸의 시기
( Object life Cycle ) 과는 상관 없다. 상대 Class 의 Method 를 호출할 경우 상대 Class 에서 method 의 정의가
바뀌면 호출하는 Class 쪽에서도 그에 따라 바꾸어야 하므로 Depwndency 관계를 갖게 되는 것이다.
위의 예를 들면 , Car class 에서 AirCon Class 의 method 를 호출하고 AirCon Class 의 turnOn method 가
바뀌게 된다면, 그에 따라 바꾸어 주어야 한다는 내용을 내포한다. 다음과 같이 구현하면 된다.
