Business Component에서 외부 Logic과 2가지 관점에서 Dependency를 갖는다. 구조적 의존성은 컴파일 타임에 검사가 되기 때문에 의외로 문제가 되지 않으나 기능적 의존성이 보다 어려운 문제이다 따라서 Dependency관리 전략이라 함은 이러한 기능적 의존성을 간결하게 하여 보다 일관된 Component를 구성하는데 목적이 있다.

Structural Dependency(Technical Dependency)
구조적이라 함은 Compile Time의 Dependency를 의미한다. 호출되는 Method명과 인터페이스의 Method명이 일치해야 한다.

Functional Dependency 
기능적인 의존관계 즉 Client가 원하는 행위를 수행해야 한다는 것이다. 만약 100볼트 전자 제품을 200볼트의 소켓에 연결하려고 하면 소켓의 모양이 않 맞다 그래서 중간에 컨버터를 꽂아서 연결한다면 과연 전자 제품이 정상적으로 동작할까? 절대 아니다. 전자제품은 바로 고장 날 것이다. 마찬가지로 Structural Dependency만을 맞춘다고 Component가 동작하는 것이 아니다
그러나 기능적 의존성은 그 자체로 비즈니스를 대변하기 때문에 정형화 한다는 것 자체가 상당히 어려움이 있고 이것은 CBD를 위한 하나의 중요한 기술 영역이라 볼 수 있다.
이러한 기능적 의존관계를 효과적으로 관리하기 위한 것은 분석적인 영역이라고 할 수 있는데 다만 아키텍쳐에서는 컴포넌트의 인터페이스가 최대한 기능적 요구를 대변할 수 있도록 만들어야 한다. 마치 100V소켓과 200V소켓의 모양이 다른 것과 같은 이치이다.
 

참고 : Business component factory p138

'아키텍처와 공학' 카테고리의 다른 글

소프트웨어 Decomposition  (0) 2009.10.26
Variability mechanism  (1) 2009.10.26
컴포넌트 구현 스타일 중에서(Instance-based style vs Service-based style)  (0) 2009.10.26
RUP 4+1 VIEW  (2) 2009.10.26
Siemens 4 Views  (0) 2009.10.26
Posted by sjokim
,