데이터 흐름도

Data-flow diagram
Data flow diagram with data storage, data flows, function and interface
데이터 스토리지, 데이터 흐름, 기능 및 인터페이스를 포함하는 데이터 흐름도

데이터 흐름도는 프로세스 또는 시스템(일반적으로 정보 시스템)을 통과하는 데이터 흐름을 나타내는 방법입니다.DFD는 또한 각 엔티티와 프로세스 자체의 산출물과 투입물에 대한 정보를 제공한다.데이터 흐름도에는 제어 플로우가 없습니다.결정 규칙이나 루프가 없습니다.데이터에 근거한 특정 연산은 흐름도로 [1]나타낼 수 있습니다.

데이터 흐름도 표시에는 몇 가지 주의사항이 있습니다.위에 제시된 표기법은 구조 분석의 일부로 1979년 Tom DeMarco에 의해 설명되었습니다.

각 데이터 흐름에 대해 적어도 하나의 끝점(소스 및/또는 대상)이 프로세스에 존재해야 합니다.프로세스를 세분화한 표현은 다른 데이터 흐름 다이어그램에서 수행할 수 있으며, 이 다이어그램은 이 프로세스를 하위 프로세스로 세분화합니다.

데이터 흐름도는 구조화 분석 및 데이터 모델링의 일부인 도구입니다.UML을 사용하는 경우 일반적으로 액티비티 다이어그램이 데이터 흐름 다이어그램의 역할을 대신합니다.데이터 흐름 계획의 특별한 형태는 사이트 지향 데이터 흐름 계획입니다.

데이터 흐름 다이어그램은 반전된 페트리 네트로 간주할 수 있습니다. 왜냐하면 이러한 네트워크 내의 장소는 데이터 메모리의 의미에 대응하기 때문입니다.이와 유사하게, Petri nets로부터의 전환 의미와 데이터 흐름도 및 데이터 흐름도로부터의 기능은 동등하다고 간주해야 한다.

역사

DFD 표기법은 원래 조직의 워크플로우를 모델링하기 위해 운영 연구에 사용된 그래프 이론을 기반으로 합니다.DFD는 1970년대 말 구조 분석 및 설계 기법 방법론에 사용된 활동 다이어그램에서 유래했다.DFD 대중화에는 에드워드 유든, 래리 콘스탄틴, 톰 드마르코, 크리스 게인, 트리쉬 사슨이 [2]포함됩니다.

데이터 흐름도(DFD)는 소프트웨어 시스템 프로세스에 관련된 주요 단계와 데이터를 시각화하는 인기 있는 방법이 되었습니다.DFD는 이론적으로는 비즈니스 프로세스 모델링에 적용될 수 있지만 일반적으로 컴퓨터 시스템의 데이터 흐름을 보여주기 위해 사용되었습니다.DFD는 주요 데이터 흐름을 문서화하거나 데이터 [3]흐름 측면에서 새로운 고급 설계를 탐색하는 데 유용했습니다.

DFD 컴포넌트

Data flow diagram - Yourdon/DeMarco notation
데이터 흐름도 - Yourdon/DeMarco 표기법

DFD는 프로세스, 흐름, 창고 및 터미네이터로 구성됩니다.이러한 DFD [4]컴포넌트를 표시하는 방법은 여러 가지가 있습니다.

과정

프로세스(기능, 변환)는 입력을 출력으로 변환하는 시스템의 일부입니다.프로세스의 기호는 원, 타원, 직사각형 또는 둥근 모서리가 있는 직사각형입니다(표기 유형에 따라).그 과정은 한 단어,[2] 짧은 문장, 또는 그 본질을 명확하게 표현하기 위한 문구로 명명된다.

data 흐름

데이터 흐름(흐름, 데이터 흐름)은 시스템의 한 부분에서 다른 부분으로 정보(때로는 재료도 포함)의 전송을 나타냅니다.흐름의 기호는 화살표입니다.플로우는 이동할 정보(또는 재료)를 결정하는 이름을 가져야 합니다.예외는 이러한 흐름에 링크된 엔티티를 통해 전송되는 정보가 분명한 흐름입니다.재료 이동은 단순한 정보 제공이 아닌 시스템에서 모델링됩니다.흐름은 한 가지 유형의 정보(자료)만 전송해야 합니다.화살표는 흐름 방향을 나타냅니다(엔티티에서 송수신되는 정보가 논리적으로 종속된 경우(예: 질문과 답변) 양방향일 수도 있습니다).플로우 링크 프로세스, 창고 및 [2]터미네이터

창고

웨어하우스(데이터스토어, 데이터스토어, 파일, 데이터베이스)는 나중에 사용하기 위해 데이터를 저장하는 데 사용됩니다.저장소의 기호는 두 개의 수평선이며, 다른 표시 방법은 DFD 표기법에 나와 있습니다.창고의 이름은 복수명사(예: 주문)이며 창고의 입력 및 출력 스트림에서 파생됩니다.웨어하우스는 단순한 데이터 파일일 필요는 없지만 문서, 파일 캐비닛 또는 광디스크 세트가 있는 폴더일 수도 있습니다.따라서 창고를 DFD로 표시하는 것은 구현과는 무관합니다.웨어하우스로부터의 흐름은 일반적으로 웨어하우스에 저장된 데이터의 읽기를 나타내며, 웨어하우스로의 흐름은 일반적으로 데이터 입력 또는 업데이트(데이터 삭제도 포함)를 나타냅니다.웨어하우스는 메모리 이름이 위치한 두 개의 평행선으로 표시됩니다(UML 버퍼 [2]노드로 모델링할 수 있습니다).

터미네이터

터미네이터는 시스템과 통신하는 외부 엔티티로 시스템 외부에 있습니다.예를 들어, 모델 시스템에 속하지 않는 다양한 조직(예: 은행), 사람 그룹(예: 고객), 당국(예: 세무서) 또는 동일한 조직의 부서(예: 인적 자원 부서)가 될 수 있다.터미네이터는 모델링된 시스템이 [2]통신하는 또 다른 시스템일 수 있습니다.

DFD 작성 규칙

엔티티명은 더 이상의 코멘트 없이 이해할 수 있어야 합니다.DFD는 시스템 사용자와의 인터뷰를 바탕으로 분석가가 만든 시스템입니다.한편, 시스템 개발자는 프로젝트 청부업자를 위해 결정되므로, 엔티티 이름은 모델 도메인, 아마추어 사용자 또는 전문가용으로 수정해야 합니다.엔티티 이름은 일반(예를 들어 활동을 수행하는 특정 개인)이어야 하지만 엔티티를 명확하게 지정해야 한다.특정 프로세스에 대한 매핑 및 참조가 용이하도록 프로세스에 번호를 매겨야 합니다.번호는 랜덤이지만 모든 DFD 수준에서 일관성을 유지해야 합니다(DFD 계층 참조).DFD는 명확해야 합니다.1개의 DFD의 최대 프로세스 수는 6 ~9가 권장되기 때문에 1개의 DFD에서 [1][2]최소 3개의 프로세스가 권장됩니다.예외는 이른바 컨텍스트 다이어그램입니다.이 경우 유일한 프로세스는 모델 시스템과 시스템이 통신하는 모든 터미네이터를 상징합니다.

DFD 일관성

DFD는 시스템의 다른 모형(실체 관계도, 상태 전이도, 데이터 사전 및 공정 규격 모형)과 일치해야 합니다.각 프로세스에는 이름, 입력 및 출력이 있어야 합니다.각 흐름에는 이름이 있어야 합니다(예외 "흐름" 참조).각 데이터 저장소에는 입력 및 출력 흐름이 있어야 합니다.입력 및 출력 흐름은 1개의 DFD에 표시할 필요는 없지만 같은 시스템을 설명하는 다른 DFD에 존재해야 합니다.단, 시스템이 [2]통신하는 시스템(외부 스토리지) 외부에 있는 창고는 예외입니다.

DFD 계층

DFD의 투명성을 높이기 위해(즉, 프로세스가 너무 많지 않음) 다단계 DFD를 생성할 수 있습니다.상위 레벨의 DFD는 상세하지 않습니다(하위 레벨의 보다 상세한 DFD를 집약).컨텍스트 DFD는 계층 내에서 가장 높습니다(DFD 작성 규칙 참조).이른바 제로 레벨은 프로세스 번호부여(예: 프로세스 1, 프로세스 2)부터 시작하여 DFD 0이 뒤따릅니다.다음으로 이른바 제1레벨인 DFD 1의 번호부여가 계속됩니다.예: 프로세스 1은 DFD의 첫 번째 세 가지 레벨로 나뉘며, 번호는 1.1, 1.2 및 1.3입니다.마찬가지로 두 번째 레벨(DFD 2)의 프로세스에는 2.1.1, 2.1.2, 2.1.3 및 2.1.4 등의 번호가 부여됩니다.수준 수는 모형 시스템의 크기에 따라 달라집니다.DFD 0 공정의 분해 수준 수가 같지 않을 수 있습니다.DFD 0에는 가장 중요한(집약된) 시스템 기능이 포함되어 있습니다.가장 낮은 수준에는 대략 A4 페이지 1개에 대한 프로세스 사양을 작성할 수 있는 프로세스가 포함되어야 합니다.mini-specification이 더 길어야 할 경우 여러 프로세스로 분해되는 프로세스에 대해 추가 레벨을 생성하는 것이 적절합니다.전체 DFD 계층의 명확한 개요를 위해 수직(단면) 다이어그램을 작성할 수 있습니다.창고는 처음 사용된 곳의 가장 높은 레벨과 모든 낮은 레벨에 표시됩니다.[2]

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b Bruza, P. D.; van der Weide, Th. P. (1990-11-01). "Assessing the quality of hypertext views". ACM SIGIR Forum. 24 (3): 6–25. doi:10.1145/101306.101307. ISSN 0163-5840. S2CID 8507530.
  2. ^ a b c d e f g h Yourdon, Edward (1975). "Structured programming and structured design as art forms". Proceedings of the May 19–22, 1975, National Computer Conference and Exposition on - AFIPS '75: 277. doi:10.1145/1499949.1499997. S2CID 36802486.
  3. ^ Larman, Craig (2012). Applying UML and patterns : an introduction to object-oriented analysis and design and iterative development (3rd ed.). New Delhi: Pearson. ISBN 978-8177589795. OCLC 816555477.
  4. ^ Řepa, Václav (1999). Analýza a návrh informačních systémů (Vyd. 1 ed.). Praha: Ekopress. ISBN 978-8086119137. OCLC 43612982.

참고 문헌

외부 링크