마인드맵과 모델링의 관계
서로의 강점을 살리자
여기 떠오르는 생각이 있다.
이 떠오르는 생각에 연상되어 떠오르는 생각을 연결하며 뻗어나간다. 때로는 저쪽 가지와의 연결도 된다.
어느 정도 생각이 뻗어나가면 이제 정리를 해야 한다. 그 정리는 그것을 가장 잘 표현할 수 있는 모델링으로 접근한다.
소프트웨어공학에서 사용하는 UML(Unified Modeling Language)의 예를 들어보자면 Use Case Diagram으로 시스템을 이용하는 주체와 객체, 시스템의 범위, 시스템의 기능을 표현할 수 있다. Dialog Map을 통해 화면의 종류와 이동순서, 정보의 전달 등을 그려볼 수 있다.
또 State Diagram을 통해 이전 상태에서 다음 상태로 넘어가는 트리거를 표현할 수 있다. Entity Relationship Diagram을 통해 개체와 개체간의 관계, 그리고 그 객체의 속성에 대해 알아볼 수 있다.
UML만 모델을 표현하는 도구는 아니다. Functional Formular를 통해서는 함수를 변수와 상수로 인과, 비례, 반비례 관계 등을 표현할 수 있다. Level of Abstraction은 서로 다른 추상화 수준의 관계를 표현하여 단계적인 접근이 가능하도록 도와준다.
주의할 사항이 있다.
각 가지마다 하나씩 모델링을 할 필요는 없다. 전체를 해석하기 위한 모델링이면 족하다.
꼭 Diagram으로 정리하지 않아도 된다. 마인드맵 자체도 모델링 도구이므로 그 자체로 잘 정리가 되었다면 모델링 과정을 거친 것이다. 그동안 이 책에서 제시한 그림들을 보았는가. 그 자체로 마인드맵모델링을 한 것이다.
정형화된 모델링 기법을 사용하지 않아도 된다. 그것은 그 기법을 잘 사용하는 사람들이면 그렇게 하면 좋다는 예시였다.
나만의 모델링 기법을 만들어도 된다. 충분히 그 개념을 잘 표현하면 되는 것이다.
몇가지 사례의 모델링 기법을 언급했는데 Use Case Diagram을 그리면서 Class Diagram을 그리고, Dialog Map을 그리면서 State Diagram을 같이 그리는 등 굳이 한가지에만 얽매일 필요없이 같이 그려넣는 것도 좋다. 목적은 전체를 이해하는 것이다.
마인드맵의 원칙과 기법들을 지키지 않아도 된다. 이것도 위와 같은 이유이다. 목적은 전체를 이해하는 것이다.
이렇게 정리하다보면 전체 그림이 완성되며, 모호하던 생각이 실체화되어 생명을 가지게 된다. 우리가 그동안 단편적으로 접근했던 것의 문제점이 바로 생각의 단절 혹은 불충분이었던 바, 마인드맵모델링에서는 마인드맵이 그 부분의 연결고리 역할을 한다고 볼 수 있겠다.
