Quant Developer

Financial library
-price financial instruments
-add new pricing functionality
   -add new financial instruments
   -add new means of pricing an existing instrument

위 조건들을 만족하는 quantlib의 설계에 대하여 설명할 것이다.

2.1 The Instrument class
이쪽 도메인에서 Financial instrument가 base class로 만드는 것은 자연스러운 결정이다.
장점: 모든 instruments를 일괄적으로 처리 할 수 있다. ex. 포트폴리오 가치 평가시

2.1.1 Interface and requirements
여러가지의 상품들이 서로 불필요한 요건이 존재하기 때문에, 일반적인 공통 함수는 매우 적다.

returning its present value (possibly with an associated error estimate)
indicating whether or not the instrument has expired

반드시 vitual일 필요는 없다. 
calculated_ : 계산이 완료가 되었고 유효한지 알려준다.
update : observer 인터페이스를 구현하고 calculated_를 false로 셋팅함으로써 직전의 결과를 무효로 만든다.
calculate : Template Method pattern으로 구현한다.
변하지 않는 부분(이 경우, 저장된 결과의 관리 부분)을 base 클래스로 구현한다. 
그리고 다양한 부분(여기서는, 실제 계산하는 부분)은 virtual 함수(performCalculations)를 이용하여 위임한다. 위임된 함수는 base 클래스의 body에서 호출된다.
즉, 파생 클래스는 저장(caching)부분은 신경쓸 필요없이 자신의 특정 계산 부분만을 신경쓰면 된다.

the logic of the caching : 만약 현재 결과가 유효하지 않으면, 파생 클래스는 계산을 진행하고, 새로운 결과로 대체한다. 만약 현재의 결과가 유효하다면, 아무것도 하지 않으면 된다.

calculated_를 셋팅하는데 왜 try 블럭을 넣었어야했는지, 
그리고 handler가 예외처리를 하기 전에 롤백하는 것에 대하여 궁금할 것이다.

다음과 같이 저장과 예외처리 부분을 제외하여 간단히 구현할 수 있다.
예를 들면, lazy 객체가 lazily하게 bootstrap하는 yield term structure인 경우에 performCalculations는 재귀적으로 calculate를 호출할 수 있다.

만약 calculated_가 true로 설정되어 있지 않다면, performCalculations를 다시 호출하게 될 것이며 이것은 무한 재귀호출을 하게 만들 것이다.
calculated_를 true로 설정하여 이러한 상황을 방지하며, 만약 예외가 발생하면 이것을 false로 복귀시켜야만 한다.
virtual calculate 함수가 엔진 인터페이스에 정의되어 있고 concrete 엔진들에 구현되어 있다는 것을 가정한다.
불행하게도 위의 접근은 여전히 부족한 점이 있다. 이상적으로 Instrument 클래스에서 오직 한번의 dispatching code를 구현하기를 원한다. 그러나 사용된 코드는 충분히 포괄적이지 않다.
이것은 명시된 수와 인자의 타입을 받아들이는 엔진에 의존하고 있기 때문이다.
그러나 instrument 클래스들은 수와 타입에 있어 다양한 데이터 멤버들을 갖기 때문에 이것은 명백히 받아들일 수 없다. 이것은 결과값 리턴에 있어서도 마찬가지이다. 예를 들면, interest-rate swap은 fixed rate와 floating spread의 fair value를 리턴할 수 있을 것이고 ubiquitous European option은 Greeks를 리턴할지도 모른다.
위에서 정의한 것과 같이 함수를 통하여 엔진에 인자를 전달하는 인터페이스는 생각하지 않은 두 가지 결과를 가져온다. 하나는 우리가 하나의 베이스 클래스를 정의하는 것에 방해가 되는 것으로 각각 다른 instruments를 위한 pricing 엔진이 각각 다른 인터페이스를 가지게 될 것이다. 다른 것은 엔진을 호출하는 코드가 각각의 instrument 클래스에서 복제(replicated)되어져야만 할 것이다. 이것은 미친짓이다.
우리가 선택한 해결방법은 인자와 결과들이 불투명한(opaque) 구조가 적절히 호출하는 방법으로 엔진으로부터 보내고 받아지는 것이다. 그것들(인자들과 결과들)로부터 파생되고 instrument에 특정한 데이터를 가지고 그것들(인자들과 결과들)을 호출하는 두 개의 구조는 어떤 pricing 엔진에서도 저장될수 있다; 어떤 instrument는 엔진과 정보를 교환하기 위해서 그러한 데이터를 읽고 쓸수 있다.

다음은 PricingEngine 클래스의 인터페이스와 내부의 argument, results 클래스 그리고 helper GenericEngine 클래스 템플릿을 보여주고 있다. GenericEngine은 PricingEngine 인터페이스의 대부분을 구현하고 있으며, 특정 엔진들의 개발자들을 위해 calculate 함수의 구현만을 남겨두고 있다. 데이터를 드롭박스처럼 쉽게 사용하게 할 수 있도록 argument와 results 클래스들이 함수에게 주어진다. arguments::validate는 input 데이터가 유효한 범위내에 있는 값인지 확인하기 위해 쓰여진 이후에 호출된다; results::reset은 엔진이 이전의 결과를 지우기 위해서 계산을 시작하기 전에 호출된다.
이러한 새로운 클래스를 갖춤으로서 generic performCalculation 함수를 완료할 수 있다. 
먼저 언급한 Strategy pattern외에 특정한 instrument가 missing bits를 채우기 위해 Template Method pattern을 사용할 것이다. 이것은 다음과 같다.
inner 클래스 Instrument::result가 정의되는 것을 알 수 있을 것이다; 이러한 클래스는 PricingEngine::results로부터 상속하며 어떤 instrument에도 제공해야만 하는 결과를 포함한다.(Instrument::results 클래스는 pricing 엔진이 추가적인 결과를 저장할 수 있도록 std::map을 포함하며 이러한 부분은 명확성을 위해 여기서는 빠져있다.)
performCalculation 함수에 대해서 말하자면, 실제 작업은 다수의 collaborating 클래스들 사이에서 분리되는 것으로 보인다 - instrument, pricing 엔진, arguments/results 클래스들.
이러한 collaboration의 역학(dynamics)은 다음의 UML sequence 다이어그램을 이용하면 가장 이해하기 쉬울것이다; 그 다음은 클래스들(과 가능한 concrete instrument) 사이의 static한 관계를 보여준다.

*Sequence diagram of the interplay between instruments and pricing engines

*Class diagram of Instrument, PricingEngine, and related classes including a derived instrument class

instrument의 NPV 함수를 호출하면 이것의 performCalculations 함수를 호출하게 된다.(만약 instrument가 만료가 되지않고, 관련된 quantities가 계산할 필요가 있다면)
이곳이 instrument와 pricing 엔진이 상호작용하기 시작하는 곳이다.
가장 먼저 instrument는 엔진이 이용가능한지 확인한다. 만약 가능하지 않다면 계산을 중지한다.
만약 가능한 것을 찾으면 instrument는 그것으로 즉시 리셋한다. 메시지는 reset 함수에 의해 instrument-specific result structure로 보내진다; 이것이 수행된 이후에 structure는 새로운 result를 쓰기위해 clean slate상태로 대기한다. 이 시점에서 Template Method pattern가 그 상황으로 들어간다. instrument는 arguments의 포인터로서 return되는 argument structure를 위해 pricing 엔진에 문의한다. 포인터는 패턴에서 변수 부분으로 동작하는 instrument의 setupArguments 함수에 보내진다. instrument에 따라 이러한 함수는 전달된 인자가 올바른 타입인지 확인하고 올바른 값으로 데이터 멤버를 채우도록 진행한다. 마지막으로 arguments는 validate 함수를 호출함으로서 새롭게 쓰여진 값들을 확인하는 작업이 수행되는 것에 대해 질문을 받게 된다.
이제 Strategy pattern을 적용할 차례이다.
인자들이 셋팅되고 선택된 엔진은 calculate 함수에 구현된 특정 계산이 수행될지를 선택하게 된다. 이것이 진행되는 동안 엔진은 argument structure로부터 필요한 인풋을 읽을(read) 것이고, results structure로 대응되는 결과를 작성할 것이다(wrtie).
엔진이 작업을 완료한 이후에 제어는 Instrument 인스턴스로 넘어올 것이고 Template Method pattern은 계속해서 unfolding을 할 것이다. 호출된 함수인 fetchResults는 결과를 엔진에게 문의해야만하며, 포함된 데이터로 접근하기 위해 downcast하고 자신의 데이터 멤버로 해당 값을 복사한다.
Instrument 클래스는 결과를 모든 instruments로 fetch하는 default 구현을 정의하고 있다; 파생된 클래스는 특정 결과를 읽기 위해 이것을 확장할 수 있다.

2.2.1 Example: plain-vanilla option
위에서 기술된 것들이 instrument의 구현에 어떻게 사용되는지 살펴보자. 이것은 어쩌면 기존의 것에서 새로운 클래스를 빌드하는 것을 더 쉽게 만들며 코드를 재사용할수 있게하는 많은 instruments의 공통 개념을 찾고 추상화하는 library writer의 작업과 상충할수 있다.

???
예를들면, plain-vanilla options(간단한 call put equity options with either European, American or Bermudan exercise)를 구현하는 QuantLib에 존재하는 클래스가 클래스 계층에서 가장 밑의 leaf에 존재한다. Instrument 클래스를 root로써 갖는 이러한 계층은 Option 클래스를 가지고 첫번째로 특화한다. 그리고 하나의 기초자산을 가지고 일반화하며 우리가 관심있는 VanillaOption 클래스를 정의할 때까지하나 혹은 둘의 클래스를 통하여 passing하는 OneAssetOption 클래스를 가지고 특화한다.    
이러한 증식이 좋은 여러가지 이유가 있다. 예를들면 OneAssetOption 클래스의 코드는 Asian options로 재활용 될 수 있는 반면, Option 클래스의 코드는 모든 종류의 basket options를 구현할때 재사용된다. 불행히도 이것은 plain option을 pricing하는 코드가 상속 chain의 모든 멤버에 퍼져 있게 만든다. 이것은 극단적으로 명백한 예제로서 도움이 되지 않는다. 그러므로 타협을 해야만 한다. 이번 section에서 synthesized VanillaOption 클래스를 라이브러리에서의 어떤 것과 같은 구현을 가지고 설명할 것이다. 하지만 Instrument 클래스로부터 직접 상속할 것이다; 구현된 모든 클래스를 보여줄 것이며 상속보다는 구현으로 보여줄 것이다.

다음은 vanilla-option 클래스의 synthesized 인터페이스를 보여준다. Instrument 인터페이스에서 필요로 하는  함수와 옵션의 greeks라 불리는 추가적인 결과에 접근하는 접근자를 선언한다; 지난번 얘기했듯이 논리적으로 constant인 calculate 함수에서 값을 설정하기 위해 대응하는 데이터 멤버들은 mutable로 선언한다.
자신의 데이터와 함수들과 같이 VanillaOption은 특정 argument와 result structures 그리고 base pricing engine과 같은 accessory 클래스들을 선언한다.
그러한 클래스들은 그들과 option 클래스들의 관계를 강조하기 위해 inner 클래스들로 정의한다; 다음의 인터페이스에 나타난다. 이러한 accessory 클래스들에 두개의 코멘트를 붙일 수 있다.

첫번째는 예제의 소개부분에서 소개한 것과는 반대로 results 클래스에 모든 데이터 멤버를 inline하지 않았다. 구현의 디테일을 보여주기 위해 이렇게 했다. 이것은 사용자가 results와 관련되면서 공통으로 사용되는 것들을 갖으면서 structures를 정의하도록 할 것이다; 이러한 structures는 상속의 수단으로 재사용될 수 있으며 마지막 structure를 획득하기위한 Value를 가지고 구성되는 Greeks structure의 예제가 될수 있다. 이 경우에 Results로부터의 가상 상속은 악명높은 상속 다이아몬드를 피하도록 사용되어져야만 한다.

두번째는 (올바른 argument와 result types을 가지고 instantiated되는)클래스 템플릿 GenericEngine으로부터 상속하는 것이 특정 instrument의 pricing 엔진을 위한 베이스 클래스를 제공하기에 충분하다는 것이다. 우리는 파생된 클래스는 오직 그들의 calculate 함수만을 구현하면 된다는 것을 보게 될 것이다.

다음의 VanillaOption 클래스의 구현을 보자. 생성자는 instrument를 정의하는 몇개의 objects를 취하고 있다. 그들의 대부분은 다음의 챕터 혹은 appendix A에서 설명될 것이다. 당분간(For the time being) payoff는 strike와 right(i.e., call or put) of option를 포함할 것이며 exercise는 exercise date와 variety(i.e., European, American, or Bermudan.)을 포함하는 것으로 충분할 것이다. 보내진 인자는 대응되는 데이터 멤버에 저장될 것이다. 시장 데이터를 포함하지 않으며 다른 어딘가에 저장된다는 것을 기억하라.
expiration롸 관련된 함수는 굉장히 단순하다; isExpired 함수는 최근의 행사일이 지났는지 아닌지를 확인하며 setupExpired 함수는 base 클래스의 구현을 호출하고 instrument-specific 데이터를 0으로 설정한다.
setupArguments와 fetchResults 함수는 좀 더 흥미롭다. setupArguments는 generic argument 포인터를 필요로 하는 실제 타입으로 downcasting하고 다른 타입이 들어오면 예외를 발생시킨다. 그리고 나서 실제 작업을 시작한다. 몇 몇 경우 데이터 멤버는 대응되는 argument slots으로 그대로 복사(copied verbatim)된다. 그러나 이것은 같은 계산이 여러 개의 엔진에서 필요한 경우일 것이다; setupArguments 함수는 오직 한번 그것들을 write할 수 있는 장소를 제공한다.
fetchResults 함수는 setupArguments 함수의 dual(이중)이다(이중으로 되어있다.) 이것 역시 전달된 results 포인터를 downcasting하는 것으로 시작한다; 실제 타입을 검증한 후 자신의 데이터 멤버로 결과를 복사한다.
엔진은 다음과 같으며 European 옵션을 위한 analytic Black-Scholes-Merton 공식을 구현한다. 생성자는 present value, risk-free rate, dividend yield 그리고 volatility를 포함하는 기초자산(underlying)에 대한 시장 정보를 포함하는 Black-Scholes stochastic process를 자체로 등록하고 가진다. 실제 계산은 BlackCalculator 클래스라는 다른 클래스의 인터페이스 뒤쪽에 숨어 있다. 그러나 코드는 몇몇 관련된 것들을 보여주기에 충분히 자세하다.
함수는 몇몇 사전 조건들을 검증하는 것으로부터 시작한다. 이것은 계산의 인자가 이미 calculate함수가 호출하는 time에 의해 검증되었기 때문에 놀라움으로 느껴질지도 모른다. 그러나 주어진 엔진은 계산이 수행되기 전에 수행되어야할 더많은 요구사항들을 가질 수 있다. 우리의 엔진의 경우, 그러한 하나의 요구사항은 옵션이 유로피언 옵션이라는 것이고 payoff가 plain call/put(castdown이 필요하다)이라는 것이다.(boost::dynamic_pointer_cast is the equivalent of dynamic_cast for shared pointers.)
함수의 중간부분에서 엔진은 전달된 인자로부터 정형화되지 않은 정보를 추출한다. 여기서 보여지는 것은 기초자산의 spot price이다; 엔진에 의해 필요한 다른 quantities, e.g., 기초자산의 forward price와 만기시 risk-free discount factor 또한 추출된다. 
마지막으로 계산이 수행되며, 결과는 대응되는 results structure의 slots에 저장된다. 
이것으로 calculate 함수와 예제를 마친다.

2.2.2 Alternative designs
여전히 downcasting이 없어질수 있는지 궁금할수 있다; 이것은 이것의 가치보다 더 큰 대가를 필요로 할 수 있다.
특정 instrument가 정확한 타입의 인자를 전달받기 위해서 그리고 포괄적인 방법으로 관련 함수를 작성하기 위해서는 template programming과 같은 것이 절대적으로 필요하다; 더욱이 Template Method pattern의 사용은 polymorphism과 같은 것을 필요로 한다. Curiously Recurring Template pattern을 사용하기를 제안한다(파생 클래스(derived class)에서 기반 클래스(base class)의 기능을 재정의하여 기반 클래스의 구현을 파생클래스의 구현으로 대체하는 것을 함수 오버라이딩(function overriding)이라고 한다. 파생 클래스가 기반 클래스의 함수를 오버라이드하기 위해서 일반적으로 가상 함수(virtual function)를 사용하는데 여기에는 두가지 단점이 있다.
1) vtable(virtual function table)을 위한 추가 공간이 필요하고 2) 함수 호출 과정이 vtable을 거쳐 함수 포인터를 참조하므로 오버헤드가 증가한다. 만약 컴파일 타임에 정적으로 기반 클래스의 함수를 오버라이드할 수 있다면 가상 함수를 사용할 때의 오버헤드를 줄일 수 있을 것이다. 템플릿을 사용하여 정적으로 오버라이딩할 수 있는 기법이 바로 Curiously Recurring Template Pattern (CRTP) 이다.); 이것의 가능한 구현은 다음과 같다.
GenericEngine 클래스를 수정해서 inspectors들이 불투명한 base 클래스들 대신에, 특정인자나 result structures를 리턴하게 만들수 있다. 이것은 downcasting의 필요성을 제거할 수 있다; 그러나 이것은 instrument가 타입을 정확히 맞춰야 하도록 강요한다.
그러므로 특정 argument와 results 타입은 Instrument 클래스에 특정 instrument 타입과 함께 template argument로 전달된다. 더이상 Instrument 인터페이스에 선언되지 않는 setupArguments 함수와 이것의 dual fetchResults 함수는 제외하고 대부분의 클래스는 변하지 않은 상태로 남게 된다. 이런 이유로 performCalculations 함수의 body는 반드시 수정되어야 한다: this pointer는 반드시 특정 instrument 타입으로 정적 cast되어야만 한다. 그래서 이러한 함수를 호출하는 것은 제한되어야한다(can be bound). 마지막으로 instrument의 개발자는 cycle을 close해야만 한다: 특정 instrument는 Instrument로부터 상속되어져야만 하며 같은 클래스로 template argument로써 전달되야 한다. 그리고 필요한 함수는 반드시 정의되어야만 한다. 또한 argument와 result structures는 template instantiation 시점에서 이용가능하도록 하기 위해 instrument 이전에 선언되어야만 한다.
비록 동작할지라도 이 구현은 실제로 장점을 제공하는 것 같지 않다. 이것은 오히려 새로운 instruments를 생성하는데 있어 개발자를 더욱 번거롭게 만든다. 또한 이것은 template cycle이closed될 때 클래스로부터 파생되는 것을 불가능하게 만든다; 예를 들면 파생된 fixed-coupon bond 클래스와 자체로 사용가능한 bond class(bond class usable on its own) 이 두개를 코딩하는 것으로부터 한개를 방해할지도 모른다. 이러한 측면에서 현재 Instrument의 구현은 변하지 않고 그대로 두는 경향이 있다.