소프트웨어 아키텍처를 설계하고 이를 문서화 하는데 표준처럼 정해진 규약은 없습니다.
정해진 규약보다는 설계한 아키텍처를 가장 잘 설명할수 있는 나름의 방식으로 문서화 하는것이 좋습니다.
종종 각 아키텍쳐를 설계하고 이를 문서화 하는 사람은 자신의 입맛에 맞는 Diagram과 Notation 방식을 사용하여 설명하며
이런 Diagram 은 기존에 알려진 UML을 비롯하여,Entity-Relationship Diagram, Data Flow Diagram 같은것들부터
Business Process Management(BPM)에서 사용하는 Fishbone, Cause&Effect 등 여러가지가 있습니다.

하지만 소프트웨어의 아키텍쳐는 내부 컴포넌트들뿐만 아니라 외부시스템들과의 연계, 이들 사이/내부에 대한 동적인 흐름도
보여주어야 하기에 UML 의 Class/Activity/Deployment.. Diagram들 만으로는 전체적인 구조를 나타내기엔 부족합니다.
UML 은 시스템의 구조보다는 소프트웨어의 구조를 나타내는데 더 어울린다고 봐야 할것입니다.

그럼 소프트웨어 개발의 단계에서 초기 요구사항 분석후에 전체적인 아키텍쳐 디자인이 이루어 지고,
그 다음에 상세설계인 클래스/시퀀스 설계단계로 이어지게 됩니다.
이때 요구사항 분석단계는 SRS(Software Requirements Specification)문서 정도로 정리된다고 보면
UML 의 Class/Sequence/Activity 다이어그램으로 이루어지는 상세설계단계까지의 기간에 공백이 생기게 됩니다.
마땅한 문서화 방법이 없어서 시스템구성도 라고 이름 덜렁 붙이고 이제까지 그냥 해왔던대로 네모/동그라미 그려서
전체적인 구성을 하거나, UML 의 Use Case / Deployment 정도 다이어그램을 가지고 표현을 하게 됩니다.

하지만 시스템이 복잡해 질수록 전체적인 아키텍쳐 디자인이 중시되고 있으며, Architectural Pattern 들에 대한 관심이
높아지면서 소프트웨어의 아키텍쳐를 나타낼수 있는 Notation 방식이 필요하게 되었으며,
분석과 상세설계사이의 Gap 을 메꾸기 위해 고안된것이 FMC(Fundamental Modeling Concepts) Notation입니다.

FMC 는 Dynamic 한 시스템의 구조를 일관되고 계획적인 방법으로 표현할수 있도록 만들어진 Notation 방법입니다.
Hasso-Plattner-Institute에서 개발하여 현재는 http://f-m-c.org/ 에서 관련자료를 배포중입니다.

FMC 는 시스템의 구조를 표현하기 위한 방법으로 3가지 Diagram 을 제시합니다.

• Compositional Structures : Block Diagram
• Dynamic Structures : Petri Net
• Value Range Structures : Entity-Relationship Diagram

위 3가지 다이어그램이 사실 새로운 형태의 표시방법은 아닙니다. 기존에 쓰여왔던 방법을 좀더 S/W 구조표현에 유용하도록
정리를 시도한것이라고 보시면 됩니다.

아래는 HTTP Server 의 구조를 Block Diagram 으로 나타낸 예제입니다.

Part 2 에서부터는 각각의 Diagram 의 표시법과 예제를 알아보도록 하겠습니다.

참고 Reference

• http://f-m-c.org/
• Quick Introduction to FMC [PDF]
• FMC & UML [PDF]
• FMC Notation Reference [PDF in Zip]

* 이글은 제가 관심이 있어서 찾아보다가 정리해본 문서입니다. 주관적인 내용이 담겨있을수 있으니 참고하시기 바랍니다. ^^
* 그리고 이글은 제 블로그의 저작권표시와는 별도로, 제 블로그외의 어느곳에도 전재를 금합니다.