UML Class Diagram 을 자바 소스로 구현 기준

2005.06.15 자료 

1. Class Diagram 변환

다음은 UML( Unified Modeling Language ) 을 적용한 방법론을 채택한 프로젝트의 경우

실제 Class Diagram 을 정확히 해석하는데 도움이 될만한 부분을 나타낸다.

1.1 Attributes & Operations Setting ( Access Modifier )

사진 삭제

 

사진 설명을 입력하세요.

 

위의 Diagram 에서 Attribute 및 operation 좌측의 각각의 기호가 Java 의 Access Modifier 와

Mapping 되는 부분을 확인 할 수 있다.

 

1.2 Abstract Class

 

위와 같이 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 가

바뀌게 된다면, 그에 따라 바꾸어 주어야 한다는 내용을 내포한다. 다음과 같이 구현하면 된다.

사진 삭제

사진 설명을 입력하세요.

참조 : UML Class Diagram 을 자바 소스로 구현 기준

|

JAVA( J2EE / J2SE )

존재하지 않는 이미지입니다.

2005.06.15