Yagur의 Juggling

작성자: yagur Rev : 1

  프레임워크를 지닌 컴포넌트들의 제약으로, 일부는 하드코딩하거나 재사용이 조금 힘든 프레임워크들의 조합을 그동안은 사용하고 있었습니다. 만일 사용자가 테스트 프레임워크, 실시간 렌더링 프레임워크, 사용자 정의 GUI 프레임워크를 전부 사용해야한다면 어떠할까요. 아마 특정 프레임워크에 나머지 프레임워크를 울며 겨자 먹기로 붙여 넣기 하고 있는 분도 계실것입니다. 어떤 경우 프레임워크간의 경계가 점점 사라지고 끈끈히 결합되는 경우도 있습니다. 결합이 나쁘다는 것은 아닙니다. 단지 프레임워크간의 의존성을 명확히 하지 못하고 스파게티처럼 얽혀버리는 경우는 피해야 하기때문에, 어느정도 주의는 필요합니다.

작성자: yagur Rev : 1

 컴포넌트마다 기능과 인터페이스도 다르고, 교체가능이 불가능한 경우가 렌더링 엔진들의 현재인것 같습니다. =) 아마 NotReal로 제작했다가 GameBrother로 교체하면 렌더링 파트를 전부 다시 짜야하는 사태가 올것같군요.


 하지만 중간에 업계 표준 레이어가 존재한다면....


 지원 기능 범위, 품질, 설계가 판이하게 다르기 때문에 비현실적인 이야기입니다. 하지만 저런 추상 레이어가 존재할때의 이점은 사용자에게 매우 매력적으로 보일것입니다. 컴포넌트 제작자에겐 족쇄가 될수도 있지만 말이죠 =). 물리 엔진이나 사운드 엔진도 똑같이 그릴수 있겠군요.
 만약 저것이 현실화 된다면, 공짜 Troll로 개발해서 서비스 하다가 돈이 모이면 컴포넌트만 VendorWare로 바꾸고, 대박치면 NotReal로 교체하면 되는데 말이죠 =)
 음 DirectX나 OpenGL에 따라 달라지는 문제도 일종의 표준 레이어가 존재한다면 =) 더 수월할수도 있겠군요.

  생산성이 좋다고 하는 C#으로 제작된 Singularity란 OS의 아키텍처라고 합니다. C/C++과는 달리 버퍼 오버런 문제가 적은 언어인 C#으로 이루어져있으니 상당한 잇점이 존재할것 같습니다.

  30~40년된 기반기술로 부터 탈피해 새로운 OS를 만들고자 하는 40여명의 연구원들이 만들었다고 합니다. 학습용, 비상용 용도로 제공되는 RDK도 있다고 합니다.

 작성자: yagur Rev : 3

 프레임워크 러프 스케치

 동기, 주기, 새로운 프레임워크 디자인, 복잡도, 엔트로피, 그리고 함정에 관한것들이 이전 내용이었다. 이는 새로운 프레임워크 구성을 구상하고 구체화하기 전에 고려해야할 사항들이다. 많은 것을 고려할수 밖에 없는 이유는 프레임워크가 작성할 테스트에 사용될때 그 결합도가 높기때문이다(테스트가 프레임워크에 기반을 두고 있는점을 생각해보면 된다). 결합도가 높으면 변경의 영향력이 크다.
 프레임워크는 OCP(Open Close Principle)를 잊지 말아야한다. 일단 작성된 프레임워크는 다른 소프트웨어의 테스트에 사용되기 때문에 변경이 있을경우, 자칫 다른 테스트를 전부 변경해야하는 상황이 생기기 때문이다. 하지만 OCP때문에 프레임워크의 진화를 망설여서는 안된다, 새로운 개념을 도입하고 그에 합당한 디자인 변경이 생긴다면 해야한다. OCP는 한가지의 원칙일뿐, 도약을 방해해선 안된다. 원칙과 도약중 어느것의 가치가 큰지는 사용자가 판단할 몫이다. 하지만 원칙을 지키려 노력한 디자인는 진화의 비용을 줄여줄것이다.
 우회방법도 존재 한다. 그중 하나는 JUnit과 같이 메이저 버전을 두어 분리 시킬수 있다. 그들은 테스트 프로젝트를 만들때 JUnit3, 4를 선택할수 있게 만들어 놓았다. 하지만 이것은 근본적인 해결책은아니다.


  우리가 사용할 테스트 프레임워크가 필요로 하는 명세가 항상 같을것이면 행복할것이다. 그러나 소프트웨어는 계속 변화하는 성질을 가지고 있으며 테스트를 위한 명세는 변하게 될것이다. 명세와 계획은 바뀔것이고 프레임워크의 진화를 막긴 힘들다.
 스케치는 구체적인것을 실행하기전에 도움이 된다. 그림을 그릴때도 마찬가지이고, 프로그램을 작성할때도 마찬가지이다.
 
 지금 제작해 사용중인 테스트 프레임워크의 배치 다이어그램Deployment Diagram이며 단순 참고용으로 보면 된다. 사용자는 정의된 한가지의 프레임워크에만 의존하며 되며 그들은 사용 목적에 따라 각자의 컴포넌트를 동적 로드하고 사용하게 된다.

 테스트 프레임워크, 컴포넌트 설계(Component Design of Test Framework)

 뷰를 실시간 뷰와 정적 뷰로 나누었다. 이유는 상황에 따라 필요 컴포넌트가 다르기 때문이다. 테스트 주도 개발(TDD)을 하며 실시간 뷰를 요구할수도 있고, 자동화된 연속 통합continuous integration을 위해 단순 리포트만이 필요할수도 있기때문이다. 혹은 실시간 뷰로 보며, 테스트가 끝나면 리포트를 웹싸이트에 올리기를 바랄수도 있다. 필요에 의해 컴포넌트를 사용하면 되며 이는 사용자가 의존하는 TestFramework 컴포넌트에서 처리하면 된다.

 테스트 모델 설계(Model of Test Framework)

 실제로 사용하고 있는 모델이며, 단순 사례로 참고하길 바란다. 프레임워크 사용자는 자세히 몰라도 되거나 Factory나 몇몇 매크로에 의존하게 된다. 다중 상속이 싫거나, 언어에서 지원이 되지 않는다면 위임Delegation을 활용하면 된다. TestNode에서 수많은 노드 타입들로 확장을 하고 있는것이 싫다면, 속성을 활용하도록 디자인을 변경할수 있다.
 위의 디자인은 테스트 노드가 하위 Node 혹은 Leaf, 그리고 Depedency를 연결을 할때 상세한 정책Policy을 두기를 원해서이다. 정책 결정을 다른 객체에 위임하기위한 Proxy로서 확장Extend을 하였다.(여기서 정책의 예로 한가지 들어보자면 Class Test의 하위 테스트로 System Test가 될수 없는것과 같은것이다.)
 TestSuite와 TestObject는 상속과 집합 환계로 이루어져 있는데 이것은 Composite Pattern이고 TestObject는 Observable이며 View 컴포넌트 객체들은 Observer가 될것이다.


 부트 스트랩 (Boot Strap)

 부트 스트래핑은 스스로 자기의 신발끈을 당겨서 자신을 공중에 띄워야 하는 것과 같은 모순적 상황을 일컫는다. 바퀴를 재발명해 기능을 추가하여 사용하려면 대상의 테스트가 필요하다. 테스트를 하기위한 프레임워크를 테스트하라니? 좀 모순된 상황처럼 받아들일수 있다. 일종의 자기 참조Self Referencial 프로그래밍이 될수 있는데, 이럴때는 구조적인것이 아니며 가장 단순한 형태인 함수만 활용하는것도 하나의 방법이다. 각 객체 단위별 검증을 위한 함수를 작성하여 실행하면 일정 부분 검증이 된다. 이런 형태로 커버리지를 전체로 늘려 나가면 된다. 복잡한 구조를 띌 필요가 없는 장점이 있이 있으나, 절차적Procedural이기 때문에 실행 순서를 수동적으로 고민해야한다.
 다른 방법으로는 가장 간단한 테스트 프레임워크로부터 시작해 다음 세대 프레임워크를 검증하면된다. 이것은 마치 컴파일러 작성을 위해 이전 세대의 컴파일러를 활용하는것과 같다. 그리고 다음 세대 컴파일러는 이전 세대의 컴파일러로 작성된다. 그리고 이들은 계속 이전 세대의 것을 활용해 다음 세대의 것으로 진화할것이다.


 테스트 프레임워크도 같은 원리로 진화할수 있다.