티스토리 뷰

아키텍처를 설계를 배우면서 끊임없이 듣는 단어인데 Module과 Component는 의미도 왠지 비슷해 보이고 차이가 있는 것 같지만 그걸 설명하기 어려웠다.

아래에서 부터는 참고 자료를 통해 얻은 두 용어 차이에 대한 요약이다.

이 두 용어는 다른 많은 용어들과 마찬가지로 소프트웨어가 아닌 다른 필드에서도 많이 사용이 되고 있는데다 모두 소프트웨어 공학에서 동작과 관련되어 나오기 때문에 구분하기가 힘들다.

먼저 각 용어의 배경에 대해 알아보자.

1960년대 그리고 70년대에 들어서면서 소프트웨어가 더 이상 한 사람이 감당하기 힘들 만큼 복잡해지고 커져 새로운 해결책이 필요했다.
이 문제에 대한 지배적인 해결책은 
  • 캡슐화 Encapsulation
  • 정보 숨김 Information hiding
  • 추상 데이터 타입 Abstract data types
이 세가지 였는데 이때까지만 해도 컴퓨터 프로그램이 올바른 답을 계산하는 부분에 초첨을 두고 있다가
이제 어떻게 코드를 구조화하는지가 시스템의 다른 중요한 속성들을 결정을 내린다는 생각이 나오기 시작하면서 Module이라는 개념도 같이 나오게 되었다. 그러면서 70~80년대에 Module Interconnection Language가 도래한다.
대표적으로 Modula modules, Smalltalk 클래스, Ada 패키지, 그리고 오늘날의 지배적인 설계 패러다임인 Object Oriented Programming도 모듈 컨셉을 가지고 있다.

한편 Component는 컴포넌트기반 소프트웨어 공학과 소프트웨어 아키텍처 필드에서 Componenet-and-Connector로 각광을 받고 있다.

두 용어 모두 목적은 전체 시스템을 구성하는 부분 부분으로 분해시키는 것인데 Module의 경우 가장 첫 번째 그리고 가장 맨 앞에 위치하는 구현의 단위이다. Parnas (1972) 의 모듈 설계에서 기본적인 작업은 '정보 숨김'을 기준으로 사용하는 것이었다. 시간이 지날 수록 변하는 정보 예를 들면 데이터 구조나 알고리즘은 모듈에 할당되고 모듈은 접근을 가능하게 하는 인터페이스를 가진다. 모듈은 오랜시간 소스코드와 관련있었지만 정보 모델, XML 파일, config 파일, BNF 파일 등 다른 구현 산출물도 모듈로 적합하다.
Component는 런타임 개체를 참조한다. Szyperski (1998)는 컴포넌트를 "독립적으로 배포될 수 있고 써드 파티로부터의 결합 대상"이라고 말한다. 실제로 운용 모델에서는 컴포넌트가 오직 실행 가능한 바이너리형식으로 전달된다고 한다.
즉, 모듈은 구현 단위와 산출물을 제안는 반면 매체의 전달과 런타임에 일어나는 일은 강조하지 않는다. 컴포넌트는 소프트웨어 활동 단위로 구현 구조에는 가시성이 없다.

좀 더 이해를 명확하게 하려면 Client-Server 시스템의 예를 보면 된다.
하나의 서버가 10개의 클라이언트에게 정보를 제공할 때, 모듈은 2개를 가지지만 컴포넌트는 11개가 된다. 



모듈은 하나의 컴포넌트 또는 여러 개의 컴포넌트로 표현될 수 있고, 컴포넌트도 마찬가지로 하나의 모듈 또는 여러 개의 모듈로 표현될 수 있다. 때로는 모듈과 컴포넌트가 one-to-one 매핑이 될 수 있지만 그럼에도 불구하고 그 둘은 다른 요소라는 것은 분명하다.

[출처]
Clements, Paul, et al. Documenting software architectures: views and beyond. Pearson Education, 2002.


댓글