FMC 의 기본설명은 이전글인 Software Architecture Design with FMC – part 1을 참조하시기 바랍니다.

Compositional Structures – Block Diagram

블록 다이어그램은 기본적으로 시스템 구조를 그리는데 사용해왔던 형식입니다. FMC 에서는 정적인(Static) 시스템의 구조를
표현하는데 Block Diagram 을 사용합니다. Architectural View 로 본다면 Component & Connector 형태라고 볼수 있습니다.
(from Documenting Software Architecture : Views & Beyond )

아래는 Block Diagram 으로 나타낸 HTTP Server 의 Architecture 입니다.

표현자체가 쉬우니 그냥 보셔도 대충 이해는 될수 있겠지만, 조금 이상한 표현들이 보이는군요.
그럼 완벽한 이해를 위해 각 Element 와 구조의 표현방법 들을 알아보도록 하겠습니다.

	Active System Component를 나타냅니다. 왼편은 그냥 시스템 컴포넌트 , 사람표시가 있는건 Human Agent 입니다.
	Passive System Component를 나타냅니다. 왼편은 저장소(Storage)를 의미합니다. (Memory,Database,..) Storage 는 Agent 에 의해 데이타를 저장하기 위해 사용됩니다. 추상화된 저장영역 일수도 있습니다. 작은 원은 채널(Channel)을 뜻하며 두개이상의 Agent 들이 Communication 하기 위해 사용되는 것을 말합니다.(메시지 버스, TCP/IP 소켓, 이벤트 , 파이프 ..)
	선들은 Access Type 을 나타냅니다. Agent 가 Storage 에 Read / Write 하는 방향에 따라 화살표가 붙게되며, 채널에 Read/Write 하는경우는 화살표가 양쪽에 붙기보다 화살표가 아예 없는 선으로 나타냅니다.
	Agent A 가 Storage S에서 데이타를 읽어들입니다. Agent A 가 Storage S에 데이타를 저장합니다. Agent A 가 Storage S에 Read/Write 로 Data 를 Modify 합니다.
	정보가 Agent A1 에서 Agent A2 로 만 흘러갈수 있습니다. Agent A1 이 Agent A2 가 서로 채널을 통해 정보를 주고 받을수 있습니다.
	Agent A1 이 Agent A2 로 요청(Request)를 보내면 A2 가 응답(Response)를 보냅니다. (함수 호출이나 HTTP 의 Request/Response 같은 경우) 간략화된 버전으로 요청이 가는 방향만을 R▶ 와 같이 나타냅니다.
	Agent A1 가 Agent A2 가 공유하는 저장소로서 서로 통신이 가능해 집니다. (Shared Memory,공유DB)
	Structure Variance를 나타냅니다. 시스템 컴포넌트의 생성과 소멸을 나타내는 복합구성 입니다. A1이 A2 를 생성함으로써 점선으로 표시된 Storage를 수정하며, 생성된 A2 는 A1 과 통신하게 됩니다. 쓰레드 풀 같은 구조를 나타냅니다.

여기까지의 각 Element 설명을 보시고 다시 위의 HTTP Server 구조를 보시면 쉽게 이해가 되실것입니다.

Agent 와 Storage 라는 두개의 컴포넌트 만으로 나눴지만, 채널과 Accessing 하는 타입을 지정함으로써
시스템 전체 컴포넌트간의 정적인 구조를 표현하기 쉽고 , 이해가 빠르다는 장점을 가지고 있습니다.

참고로, Apache Modeling Project 에 나와있는 Apache 웹서버의 Unix 용 Multiprocessing/Multithreading 모델을
Block Diagram 으로 나타내면 다음과 같습니다.

참고 Reference

• http://f-m-c.org/
• Documenting Software Architecture : Views & Beyond
• Apache Modeling Project
• FMC Notation Reference [PDF in Zip]

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

소프트웨어 아키텍처를 설계하고 이를 문서화 하는데 표준처럼 정해진 규약은 없습니다.
정해진 규약보다는 설계한 아키텍처를 가장 잘 설명할수 있는 나름의 방식으로 문서화 하는것이 좋습니다.
종종 각 아키텍쳐를 설계하고 이를 문서화 하는 사람은 자신의 입맛에 맞는 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]

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