지금의 Eclipse plug-in인 mylyn의 시초가 된 논문.
저자 Mik Kersten은 자신이 만든 mylyn과 관련된 논문으로 박사를 졸업했다.
회사까지 따로 차려서 mylyn을 계속 발전시켜나가고 있고, Gail Murphy 교수는 programmer productivity에 많은 공을 들이고 있는 듯 하다.

1. Background

 Modularity는 소프트웨어 개발 환경에 다양한 장점을 가지고 있다. 전체 시스템을 작은 부분으로 나누어 개발할 수 있기 때문에 훨씬 적은 시간에 대형 시스템을 개발하고, 또 관리할 수 있다. 이러한 Modularity는 프로그래머들의 task를 도와 줄 수 있는 시스템의 다양한 관점으로 나타낼 수 있다. 예를 들어, 일반적으로 자바 코드에 접근하기 위해서 프로젝트, 패키지, 파일, 그리고 클래스 단위의 모듈 구조를 보여주는 Eclipse IDE의 Package Explorer를 사용하게 된다. 현재의 개발 환경은 프로그래머들이 이러한 모듈 구조를 찾아가면서 전체 시스템에서 그들이 진정으로 원하는 부분(모듈)을 찾아야 할 것이며, 이러한 관심 포인트가 식별되면 앞으로는 이 모듈에만 집중하여 쉽게 수정작업을 수행 있어야 한다.

2. Problem statements

 하지만 Mylar(=Mylyn)은 이러한 가정에서 발생되는 두 가지 문제점으로부터 시작한다.

첫째, 시스템을 수정하기 위해서 신경써야 할 모듈이 결코 하나에만 국한 되지 않는 다는 점.

둘째, 심지어 몇몇 형태의 모듈 안(예를 들어 자바의 package)에서만 변경된 코드라 할지라도, 프로그래머들은 이 모듈이 전체 시스템에서 어떻게 동작하고 있는지 알 필요가 있다. 따라서 프로그래머들은 다른 모듈들과 그 상호작용이 어떻게 이루어지는지 알아내기 위해 IDE의 모듈기반 뷰를 사용하여 다양한 정보들에 접근한다.

엎친데 덮친격으로 대부분의 프로그래머들은 일반적으로 하나의 업무만을 담당하고 있지 않기 때문에, 현재 IDE 상에 펼쳐진 정보(쉽게 말해 모듈)들의 구조와 프로그래머가 원하는 모듈이 일치 하지 않을 경우가 허다하다. 따라서 이런 업무들이 모두 마무리 될 때까지 필요한 특정 정보들을 지속적으로 찾고, 작업공간을 세팅하는 등의 비슷한 작업을 수도 없이 반복 해야 한다.

3. Pain & needs

결국 이런 반복적인 task context의 재생성은 프로그래머들의 생산성을 떨어뜨리게 된다.
따라서 본 논문에서는 이러한 task context간의 mismatch를 줄이고, 프로그래머의 생산성을 향상시킬 수 있는 방법을 제안한다. DOI(degree-of-interest) 가중치를 통해 프로그래머가 시스템 artifact와 어떻게 상호작용하는지에 대한 데이터를 만들고, 이런 가중치를 어떻게 이용하여 시스템의 모든 모듈을 보여주는 대신에 뷰나 에디터에 관련된 모듈만을 집중하게 하는 IDE(Eclipse) 화면 모듈 구조를 만드는지 보여준다.

JCreator