Software Magic !

1. Edge에 의해서 표현되는 Entity간의 연관 관계가 의미있는 정보를 가지고 있다.

"input", "output", "expand", "use", "inherit", "up" and so on.

2. DATA entity

Control/Data Flow Diagram 내에서 data object (변수)를 나타낸다. 이름(Object Name)과 타입

(Object Class)를 속성으로 가진다.

Property : Object Name, Object Class

Relation : input, output, expand (해당 Data class 정의로의 연결)

3. PROCESSOR entity

Data object들을 입력으로 받아서 실제 작업을 처리하는 부분이다. 작업의 결과로서 새로운

data object들을 생성할 수 있다. Code fragment로 구현할 수도 있고, 또 다른 CDF를 이용하여

구현할 수도 있다. PROCESSOR 또한 class로 구현되며, 사용되는 PROCESSOR entity는

해당 PROCESSOR class의 한 instance로 간주된다.

Property : Processor Name, Processor Class.

Relation : input, output, expand (해당 PROCESSOR class 정의로의 연결)

Considerations...

CDF Diagram (DPD Model) 내에서 사용되는 Entity들은 class가 아닌 object들이다. 다시 말하면, 해당 DATA 혹은 PROCESSOR에 대한 class들이 어딘가에 정의되어 있고, 그것들의 instance들을 이용하여 CDF를 구성한다는 말이다. 눈에 보이는 CDF는 object들의 집합이며, 이 object들은 자신들이 속한 class에 대한 연결을 유지한다. 새로운 데이터 타입이 필요한 경우, 그 타입의 class 정의를 따로 작성한 다음, CDF에서 object를 생성해야 한다.

class들은 CDF와는 분리되어 정의되며, UML에서 사용하는 class model을 사용하여 정의할 수 있다. Class는 멤버 변수와 메쏘드들의 집합이며, class간에는 상속 관계가 형성될 수 있다. 한 class에 대해 이름이 다른 여러 개의 object를 생성하는 것이 가능하므로, CDF에서 같은 class의 DATA나 PROCESSOR를 여러 개 사용하는 것이 가능하다.

프로그래머는 CDF에 포함된 각 element들로부터 "expand" 관계를 따라 class 정의로 이동할 수 있다. (일종의 hyper-link라고 생각하면 된다). 이런 방법으로 프로그래머는 쉽게 CDF 디자인과 class 정의를 오가면서 작업을 수행할 수 있을 것이다. (프로그래밍은 결국 CDF의 내용과 class의 내용을 작성하거나 수정하는 것이 된다.)

또한 각 class는 자신에 속하는 object들의 리스트를 관리할 수 있다. 이 기능이 과연 필요할 것인지는 좀 더 고민을 해보아야 겠다.

-> Do it simple, Do it easy !