JoOnG's StOrY

작성방법

 DFD의 작성방법은 다음과 같다.

업무를 분석하여 프로세스에 대한 모든 입출력 데이터흐름을 식별한다. 그리고 업무의 주변 경계에 그들을 표시한다.

데이터흐름상 필요하거나 제공되어야 할 외부엔티티를 정의한다.

입력으로부터 출력으로, 출력으로부터 입력으로, 또는 중간 지점부터의 데이터흐름을 식별한다.

모든 접속관계 데이터흐름에 주의깊게 명칭(혹은 자료 내역)을 부여한다.

프로세스에 대해 입력 데이터흐름과 출력 데이터흐름의 명칭에 따라 이름을 부여한다.

프로세스에 관련된 데이터저장소를 정의한다.

검토하고 보완한다.

상위레벨 DFD완성후 다음 하위 레벨의 DFD로 분할하여 최하위 레벨까지 그린다.

데이터 흐름도의 규모가 너무 커서 한 장의 종이에 그릴 수 없을 때는 시스템을 서브시스템(Subsystems)들로 분할한다.

 분할된 서브시스템들의 규모가 클때는 다시 분할을 계속한다. 이렇게 세분화를 계속하여 마지막에는 데이타 흐름도를 단순한 기능들만으로 그릴 수 있는 단계까지 분할한다. (일반적으로 레벨3까지면 적당하다)

배경도(Context Diagram) 

배경도는 분석하고자 하는 시스템과 외부 세계와의 접속관계를 식별하기 위한 것으로 시스템 분석의 범위를 결정하게 된다.

최하위단계 데이터 흐름도

최하위 단계의 DFD는 DFD 내의 모든 프로세스가 더 이상 하위 단계의 DFD로 분할되지 않는 데이터 흐름도를 말하며, 모든 프로세스들이 명세서를 갖는 기본단위인 것을 말한다.       상하관계

다음 그림은 분할된 데이터 흐름도의 상하관계를 보여주는데 상위 단계의 번호1로 표시된 프로세스가 다시3개의 하위 단계의 프로세스들로 분할되는 것을 보여주고 있다.

하위 단계에서는 분할된 프로세스들과 그들 간의 접속관계를 보여주며 상위 단계의 프로세스와 데이터흐름을 더욱 상세히 설명한다.

하위단계의 데이터 흐름도에서는 프로세스 분할뿐만 아니라 데이터 흐름의 변환과정도 자세히 나타나는데, 그림에서는 상위 단계의 데이터 흐름 A가 B와 C로 변환되는 과정을 상세히 설명하고 있다.

그러나 하위 단계는 상위 단계와 동일한 데이터변환을 하는 것이므로 순수입력과 순수출력은 상위와 하위 단계 모두 일치한다.

그림에서 또 유의해야 할 것은 상위 단계의 프로세스1이 분할된 하위 단계의 프로세스들은 1.1, 1.2, 1.3 등과 같은 번호를 부여받는다. 마찬가지로 하위 단계의 프로세스 1.2가 다시 분할된다면 그것의 하위 단계 데이타 흐름도는 다시 1.2.1, 1.2.2, 1.2.3 등과 같이 된다.

[그림 6] DFD의 분할

작성규칙

 DFD 만큼 애용되는 다이아그램도 없지만 또 DFD 만큼 잘못되게 그려지는 다이아그램도 없다. 많은 개발자들이 정확한 DFD의 작성 방법을 몰라서, 또는 시간이 부족해서 부실한 다이아그램을 그리고 만다.

   DFD는 일반적으로 Context Diagram을 포함해서 레벨 3까지 분할되면 적당하며, 레벨간의 데이터흐름, 외부엔티티, 데이터저장소가 반드시 일치해야 한다.

 또한 모든 데이터흐름과 데이터저장소는 프로세스에 연결되어 있어야 하고, 입력이나 출력 중 어느 하나만 있는 경우는 Blackhole과 Miracle이라 하여 옳지 않은 것으로 본다. 또한 데이터저장소간의 데이터흐름의 연결도 피해야 한다.

데이터 보존의 원칙(Conservation Rule)

어떤 프로세스의 출력 데이터흐름은 반드시 입력 데이터흐름을 이용하여 생성된 것이어야 한다는 것이다. 아래 예에서 사과라는 데이터는 쥬서라는 프로세스를 통해 사과 쥬스가 되어야 한다. 따라서 오렌지 쥬스라는 출력은 잘못된 것이다.

[그림 7] 데이터 보존의 원칙

최소데이터 입력의 원칙

최소데이터 입력의 원칙은 어떤 프로세스가 출력 데이터흐름을 산출하는데 반드시 필요로 하는 최소의 데이터흐름만을 입력해야 한다는 것이다.

아래 그림에서 보는 바와 같이 실급여액 계산이란 프로세스가 필요로 하지 않는 근무시간은 이 처리를 통과하지 않고 지나친 다는 것을 보여주고 있다.

[그림 8] 최소데이터 입력의 원칙

지속성의 원칙

프로세스는 입력 데이터흐름이 들어오기만 한다면 항상 수행할 준비를 갖추고 있어야 한다는 것이다. 다음 그림에서 보는 한영번역 처리는 어떤 개인용 컴퓨터에서 실행할 수 있는 소프트웨어로 구매할 수도 있다. 이 때 번역 프로그램을 수행시키면 항상 번역을 실행할 준비를 하고 한글단어가 입력되기를 기다리고 있다는 점에서 지속성을 갖게 된다.

[그림 9] 지속성의 원칙

순차처리의 원칙

순차처리의 원칙은 데이터흐름 또는 데이터저장소로부터 입력되는 데이터에 대한 처리 순서를 설명하는 데, 데이터흐름을 통해 입력되는 데이터는 도착되는 순서대로 처리하는 반면, 데이터저장소로는 어떤 순서에 의해 접근하여도 무방하다는 것을 의미한다. 다음 그림에서 주목해야 할 것은 한영사전이란 프로세스에서 보는 것처럼 한글단어 데이터흐름의 첫번째 단어인 책이 맨 먼저 처리되어 book이란 단어로 데이터저장소에 저장되는데, 이들은 접근 순서에 무관하게 저장되어 있다.

[그림 10] 순차처리의 원칙

영구성의 원칙

영구성의 원칙은 데이터흐름의 데이터는 처리된 후 없어지지만 데이터저장소의 데이터는 아무리 읽어도 없어지지 않는다는 것을 말한다.

데이터변환의 원칙

분석시 불명확한 점의 하나는 어떤 종류의 프로세스를 데이터 흐름도 상에 나타내야 하는지 판단하기가 어렵다는 것이다. 이러한 경우에 도움이 될 수 있도록 4가지 종류의 프로세스 형태가 존재한다. 데이터본질의 변환, 데이터합성의 변환, 데이터관점의 변환, 데이터구성의 변환 등이 있다.

데이터본질의 변환

아래 그림에서 보는 바와 같이 데이터흐름 본질의 변환은 일반적으로 입력 데이터흐름에 편집, 계산 등을 하여 출력 데이터흐름을 산출하는 것을 의미한다. 아래 그림에서 소득증가율 계산이라는 프로세스는 금액으로 표시된 소득의 값을 입력으로 받아 퍼센트로 표시된 증가율로 변환을 한다.

[그림 11] 데이터본질의 변환

데이터합성의 변환

아래 그림에서 예금처리라는 프로세스는 입력데이터의 본질을 변화시키지 않는다. 이러한 형태의 프로세스는 단순히 하나의 입력데이터를 여러가지 구성요소로 분리하여 2개 이상의 출력을 산출한다. 반대로 2개 이상의 입력 데이터흐름에 대하여 데이터합성의 변환이 발생할 수도 있는데, 그림에서와 같이 수표와 입금표라는 데이터항목이 합성되어 입력 트랜잭션이라는

       하나의 출력 데이터 흐름을 산출한다.

[그림 12] 데이터합성의 변환

  데이터관점의 변환

아래 그림에서 보는 것처럼 데이터관점의 변환은 데이터에 대해 실제적으로 변경을 하지는 않는다. 이러한 형태의 처리에서 입력 데이터 흐름은 동일하게 출력 데이터흐름으로 나타나게 된다. 그림에서 주문서 확인은 주문서에 대해 변경을 하지 않고 그대로 출력으로 내보내게 된다. 따라서 출력 데이터흐름의 이름을 적합한 주문서라 하였으며, 데이터사전에서도 주문서가 정의되어 있는 한 새롭게 정의할 필요가 없다.

[그림 13] 데이터관점의 변환

  데이터구성의 변환

데이터구성의 변환에서는 출력데이터가 입력데이터와 동일하지만, 데이터의 구성형태가 변환되게 된다. 구성의 변환은 포맷팅(Formatting) 또는 정렬(Sort) 등을 위한 처리를 필요로 하게 된다. 이러한 처리형태의 출력은 다른 데이터흐름으로 생각될 수도 있고 아닐 수도 있다.

다음 그림에서 판매보고서는 데이터사전에 새로운 데이터흐름으로 들어갈 수 있는데 보고서의 실물모형(Mock-Up)이 될 것이다. 만일 처리가 정렬을 위한 것이라면 출력을 입력과 다른 데이터흐름으로 간주하여 정렬된 판매데이터라 할 수 있다.

[그림 14] 데이터구성의 변환