Job Flow는 1995년 여름 어느 날 프로젝트를 진행하던 중, 객체간의 메시지 흐름만을 명확하게 도식해 보려는 시도를 통해서 만들어진 문서형식입니다. 필자는 업무분석 및 시스템 설계에 두루 사용하고 있으며, 주요 사용 목적은 다음과 같습니다.
- 객체간 의존성 분석
- 전체 시스템의 프로세스 흐름 분석
- 설계된 시스템의 검증
- 분업을 위한 도구
객체간 의존성 분석
Job Flow는 플로우 차트와 달리 구체적인 구현이나 알고리즘에 포커스를 두지 않습니다. 객체지향 프로그래밍의 특징처럼, 개별 객체들끼리의 의존성 즉 인터페이스를 분석하는 데 집중하여야 합니다. 이러한 활동을 통해서 시스템을 구축하는 객체들 간의 상호 작용을 이해하고 효과적으로 설계하는 데 기초를 마련하게 됩니다.
전체 시스템의 프로세스 흐름 분석
책의 줄거리를 알고 있으면 이해하는데 도움이 되듯이, 시스템의 전반적인 줄거리를 알게 되면 시스템을 이해하는데 도움이 됩니다. 하지만, 너무 단순하게 하여 추상화 수준을 높이면 시스템이 애매하게 보이고, 너무 구체적으로 설명하다 보면 복잡성 때문에 시스템을 이해하기 어려워 집니다. 이럴 때, 시스템을 구축하고 있는 객체들 간의 의존적인 프로세스 흐름만을 통해서 시스템의 줄거리를 이해하는데 도움을 얻을 수 있습니다.
한편, 시스템을 구축하는 객체들의 내부 프로세스가 복잡하다면, 해당 객체를 시스템으로 보고 내부 구성 객체들 간의 Job Flow를 그려서 계층적인 설명이 가능해 집니다.
설계된 시스템의 검증
건축을 할 때에는 설계도가 준비되면 큰 무리 없이 작업을 진행할 수 있지만, 소프트웨어 경우에는 그 설계서가 개발 과정에서 훼손될 수 밖에 없습니다. 그러한 이유 때문에 소프트웨어 개발에 있어서 설계서는 개발 과정이나 결과물에 미치는 영향이 상당히 적습니다. 소프트웨어 개발에 있어서 설계서의 영향이 작은 것은 건축과 달리 대부분의 프로젝트가 이전 경험을 그대로 활용하기 어렵기 때문입니다. 따라서, 지속적인 검증과 수정이 반복되어야 합니다. 구현 있어서는 TDD(Test-Driven Development)라는 좋은 툴이 있지만, 설계에 있어서는 동적분석이 시스템을 검증하는데 도움이 됩니다. Job Flow는 의존성을 기반으로 한 시나리오 중심적 테스트를 가능하게 합니다.
동적분석(Jow Flow)를 통한 검증의 장점은 무엇보다도 낮은 비용에 있습니다. 프로토타이핑이나 점진적 개발의 경우에는 반복을 통해서 일어나는 시간적 비용이 부담 될 수가 있습니다. 물론, 동적분석으로 아주 상세한 수준의 설계를 한다는 것은 효율이나 비용 면에서 큰 부담이 될 수 있습니다. 따라서, 과잉 분석 또는 과잉 설계가 되지 않도록 조심해야 합니다. 이러한 경우에도 Job Flow는 의존성에만 집중하기 때문에 과잉 분석이나 과잉 설계가 되는 것을 방지할 수 있습니다.
분업을 위한 도구
Jow Flow는 의존성을 기반으로 하여 인터페이스 설계가 이루어지기 때문에, 분석된 객체들을 구현할 때, 다른 객체의 존재를 의식하지 않고 개발할 수 있습니다. 즉, 일단 Job Flow가 완성되면 각각의 객체의 구현에만 집중하면 되는 것 입니다.
특히 여러 명이 협력하여 프로젝트를 진행할 때, Job Flow는 훌륭한 협업 툴이 될 수 있습니다. 개발팀 구성원의 개별적인 활동이 서로에게 방해되지 않도록 분업을 이룰 수가 있습니다.
기타
- 팀장 또는 설계자가 “어떻게 개발자에게 자신의 생각을 설명해야 하는가?”에 대한 해답을 제공합니다.
- 팀 구성원 간의 커뮤니케이션의 강력한 도구로써 사용 될 수 있습니다.
- Jow Flow는 바로 소스 코드로 변환이 가능합니다. 필자의 경우에는 한 동안 자동 소스 생성기를 만들어서 사용하기도 했었습니다.
사족
꽤 많은 개발자와 업체에 분석.설계를 강의하면서 동적분석 특히 Jow Flow에 대한 시간을 많이 할애하곤 했었습니다. 지금껏 제가 만든 것 중에서 가장 애착이 가는 것이기 때문입니다. 하지만, 동적분석이 제대로 작용하려면 상당한 반복 훈련이 필요합니다. 더불어 객체지향적 프로그래밍에 대해서 어느 정도 익숙해야 합니다. 이것이 걸림돌이 되어서 제대로 활용되지 못하는 경우를 많이 보아 왔습니다. 꼭, Job Flow를 사용해야 하는 것은 아니며 UML에서도 유사한 방식의 설계가 가능합니다.