MethodChain

아래와 같은 유스케이스(Use Case)가 있다고 가정하겠습니다.
1. 사용자가 수량, 단가를 입력한다.
   1.1 시스템은 수량에 단가를 곱해 금액을 산출한다.
   1.2 시스템은 산출한 금액을 표시한다.
2. 사용자가 할인 금액을 입력한다.
   2.1 시스템은 할인 금액의 적정성을 체크한다.
        2.1.1 할인 금액이 산출 금액보다 크면 메시지를 표시한다.

1번 요구사항은 Calculator 메커니즘으로 대응할 수 있습니다.
2번 요구사항에 대응하기 위한 것이 Operator 메커니즘이며 아래와 같이 쉬도우 코드 형태로 작성합니다.
operator: [
    'dc_amount', '>', 'amount', {title:'할인금액 오류', msg:'할인금액이 산출금액보다 클 수 없습니다.'}
]
#dc_amount 엘리먼트 값이 #amount 엘리먼트 값보다 크면 msg 내용이 메시지 박스에 표시됩니다.
Operator에 지정할 수 있는 연산자는 ==, !=, ===, !==, <, >, <=, >= 입니다.
custom function을 지정할 수도 있습니다.

Operator 메커니즘은
별도로 프로그램을 작성하지 않고 값을 비교, 체크할 수 있습니다.

비록 간단한 체크이지만 이를 프로그램으로 작성하면
if (#dc_amount.value > #amount.value){ }만을 작성하는 것은 아닐 것입니다.
전처리, 후처리, 에러가 발생한 Grid 위치에 메시지를 표시해야 하는 등의 코드를 작성해야 합니다.
이에 따른 개발 시간/비용이 필요하며 유수보수 비용 또한 증가될 것입니다.

요구사항이 Calculator 메커니즘과 Operator 메커니즘의 범주라는 전제 조건이 있습니다만,
웹 애플리케이션 개발의 패러다임이 바뀔 것으로 MethodChain 개발자는 생각합니다.
나아가서 어쩌면 시스템 개발의 패러다임도 바뀔 수 있다고 생각합니다.

사용자가 요구사항을 변경하는 것은 애플리케이션 개발이 완료된 후에 오퍼레이션을 해 볼 수 있기 때문입니다.
엄밀하게 보면 요구사항을 변경하는 것이 아니라 그때 가서 요구사항을 제시하는 것이라고 할 수 있습니다.
왜냐하면 실행이 되지 않는 prototype에는 사용자의 피부에 와 닫는 User Interface가 없기 때문입니다.

사용자의 입장에서 보면 오퍼레이션을 해보면서 요구사항을 제시하는 것이 어쩌면 당연하다는 생각도 듭니다.
팜플렛만 보고 핸드폰을 사는 사람은 흔하지 않을 것입니다.
그런데, 시스템 개발 현장에서는 이런 모습이 보여지고 있습니다.

MethodChain은 분석가가 작성한 prototype이 실행이 되는 prototype이므로
프로그램 개발이 완료된 후에 해 볼 수 있는 오퍼레이션을 할 수 있습니다.
이는 요구분석 단계에서 완전하게 요구사항을 제시, 검증할 수 있다는 의미가 됩니다.

또한 Calculator와 Operator 메커니즘을 적용하여 실질적인 계산 및 에러 체크도 해 볼 수 있습니다.
이는 클라이언트에서 처리할 수 있는 비즈니스 로직이 prototype에 포함된다는 의미이며
사용자가 오퍼레이션을 통해 이를 확인할 수 있으므로 요구사항을 확정할 수 있습니다.

여기서 중요한 것은 웹 애플리케이션에 대한 기능적 요구사항은 이것으로 구현까지 끝난다는 것입니다.
요구분석이 끝남과 동시에 프로그램 개발이 끝난다는 것, 상상으로 가능했던 것이 현실로 나타나고 있습니다.

아울러 시스템 개발에 필요한 많은 사항들이 결정될 것입니다.
핵심적인 데이터 모델링, 클라이언트와 접목하는 서버용 애플리케이션,
이를 지원하기 위한 애플리케이션 등 많은 사항이 결정될 것입니다.
이로 인해 시스템 개발 방법도 바뀌게 될 지도 모르겠습니다.

•  이와 같은 개념을 통칭한 것이 클라이언트 컴퓨팅이며, MethodChain의 중심 사상이자 발전 방향입니다.

이전 페이지      다음 페이지