자료의 흐름과 처리를 중심으로 하는 요구 분석 방법.

도형 중심의 분석용 도구와 분석 절차를 이용하여 사용 자의 요구 사항을 파악하고 문서화하는 체계적인 분석 기법이다.

• 도형 중심의 문서화 도구를 사용함으로써 분석자와 사용자 간 대화가 용이하다.
• 시스템 분석 시 사용자의 참여 기회를 확대하여 사용자의 요구 사항을 정확하게 작성할 수 있다.
• 시스템을 하향식으로 세분화하므로, 분석의 중복성을 배제할 수 있다.
• 사용자의 요구 사항을 논리적으로 표현하여 전체 시스템을 일관성 있게 이해할 수 있다.
• 시스템 개발의 모든 단계에서 필요한 명세서를 작성할 수 있다.

• 추상화의 원리 (Principle of Abstraction)
• 정형화의 원리 (Principle of Formality)
• 분할과 정복의 원리 (Principle of Divide and Conquer)
• 계층화 원칙 (Hierarchical Structure Concept)

1. 현행 시스템의 물리적 모형화
2. 현행 시스템의 논리적 모형화
3. 새로운 시스템의 논리적 모형화
4. 새로운 시스템의 물리적 모형화
5. 대안 선택
6. 구조적 명세서 작성

버블 차트(Bubble Chart)라고도 한다.

시스템의 처리 과정을 자료의 흐름에 중점을 두어 기술하는 분석용 도구.

• 시스템의 활동적인 구성 요소 및 그들 간의 연관 관계를 모형화하는 것으로 논리적으로 일관성이 있어야 한다.
• 하향식 분할의 원리를 적용하여 그림(도형) 중심으로 표현한다.
• 기능별로 분할하여 다차원적으로 표현한다.

• 처리 (Process)
• 자료 흐름 (Data Flow)
• 자료 저장소 (Data Store)
• 단말 (Terminator)

• 개발 대상 업무의 작업 흐름을 쉽게 이해할 수 있다.
• 사용자의 요구 사항을 정확하게 파악할 수 있다.
• 사용자와 분석가 사이의 의사소통을 위한 공용어 역할을 한다.

메타 데이터(Meta Data)/ 데이터의 데이터)라고도 한다.

자료 흐름도의 대상이 되는 모든 자료에 대한 기본 사항들을 더 자세히 정의하기 위해 사용되는 도구.

• 자료 흐름도에 시각적으로 표시된 자료에 대한 정보를 체계적이고 조직적으로 모아 개발자나 사용자가 편리하게 사용할 수 있다.

• 자료 흐름(Data Flow)를 구성하는 자료 항목
• 자료 저장소(Data Store)를 구성하는 자료 항목
• 자료에 대한 의미
• 자료 요소(Data Element)의 단위 및 값

• 이름을 이용해 정의를 쉽게 찾을 수 있어야 하며, 중복되지 않아야 함.
• 갱신하기 쉬워야 하며, 정의하는 방식이 명확해야 함.
• 중복된 정의가 없어야 함.

• =
• ()
• {}
• |

자료 흐름도 상의 최하위 처리 절차를 상세하게 기술하는 데 사용하는 도구.

• 자료 흐름도를 지원하기 위하여 작성한다.
• 수작업 부분과 자동화 부분을 분리하는 내용이나 설계 내용을 미리 판단하기 위한 내용이 포함되어서는 안 된다.
• 소단위 명세서는 구조적 언어, 의사 결정표(판단표), 의사 결정도를 이용하여 기술한다.

시스템에서 처리되는 개체(자료)와 개체의 구성과 속성, 개체 간의 관계를 표현하여 개체를 모델화하는 데 사용된다.

• 개체 (Entity)
• 관계 (Relationship)
• 속성 (Attribute)

1. 주요키를 포함하여 개체(Entity) 속성을 모두찾아낸다.
2. 기본적인 개체와 주요키를 정의하며, 개체 사이의 관계를 정의한다.
3. 1:M 관계를 단순화시키기 위해 속성 개체를 추가하며, 연관 관계를 정의하여 M:N 관계를 표현한다.
4. 각 개체를 정규화, 누락된 개체 점검 및 클래스 구조가 필요한지 결정한다.

시스템에 어떤 일이 발생할 경우 시스템의 상태와 상태의 변화를 모델링하는 것.

상태 전이도를 통해 개발자는 시스템의 행위를 정의할 수 있다.

• 시스템의 상태란 시스템이 수행중인 상태를 의미하는 것으로 직사각형으로 나타낸다.
• 상태의 변화란 시스템이 어떤 상태에서 다른 상태로 변환되는 과정을 의미하는 것으로 화살표로 나타낸다.
• 상태의 변화를 일으키는 조건과 그 조건이 상태를 변화시킬 때 시스템이 취하는 행동을 제시해야 한다.
• 화살표의 시작은 상태 변화를 일으키는 사건을 의미하며, 화살표의 끝은 사건의 결과로 발생하는 내용(행동)이다.

사용자의 요구 사항과 시스템의 제약 사항을 토대로 시스템의 목적을 달성하기 위한 최적의 해결 방안을 찾도록 하는 체계화된 설계 기법

• 최상위 단계에서부터 하위 단계로 점차 구체화해 나가는 하향식 설계 기법을 사용한다.
• 구조적 설계로 만들어진 시스템은 이해하기 쉽고, 수정하기 쉬우며, 신뢰성이 높다.
• 자료의 흐름을 중심으로 하는 설계 기법이므로 자료 흐름 중심 설계 기법이라고도 한다.

1. 구조 도표 작성
   1. 변환 분해
   2. 거래 분해
2. 구조 도표 평가
3. 모듈 설계
4. 데이터베이스 설계
5. 패키징(Packaging)

설계 단계에서 생성된 구조 도표 및 모듈 명세서를 근거로 코딩과 테스트를 하는 단계.

• 코딩 (Coding)
• 테스팅 (Testing)
• 디버깅 (Debugging)

• 설계를 철저히 반영시킨다.
• 프로그램 논리를 명확하게 작성해야 한다.
• 간단 명료하게 작성해야 한다.
• 테스팅과 디버깅, 수정이 쉬워야 한다.

다익스트라(Diijkstra)가 최초로 제창해낸 신뢰성 있는 소프트웨어의 생산과 코딩의 표준화 등을 위해 개발된 방법.

• 복잡성을 줄이고 분기(GOTO) 없이 프로그래밍하여 읽고, 테스트하기 쉽다.
• 수행 시간의 효율성과 유지보수의 최소화로 프로그램의 효율성을 증진시킨다.
• 오류 없는 프로그램 구성으로 품질과 신뢰성을 향상시킨다.
• 생산성 증진으로 프로그래밍 경비가 감소된다.
• 구조적 프로그래밍의 규칙
  1. 프로그램의 제어 흐름을 선형화시킨다.
  2. 단일 입구와 단일 출구만 가지게 한다.
  3. GOTO문은 사용하지 않고, 구조화 이론의 세 가지 기본 제어 구조만을 사용한다.
     1. 순차( Sequence) 구조
     2. 선택(Selection) 구조
     3. 반복(Repetition) 구조

시스템의 구조와 설계를 구체적으로 나타네는 데 사용됨.

• 시스템을 모듈이라는 몇 개의 고유 기능으로 분할하여 나타내고, 모듈 간의 인터페이스를 계층 구조로 표현한다.
• 시스템 기능을 모듈이라는 몇 개의 고유 기능으로 분할하여 나타내고, 모듈 간의 인터페이스를 계층 구조로 표현한다.
• 시스템 기능을 모듈의 호출 관계와 인터페이스로 나타낸다.

구조 도표의 구성 요소인 각 모듈들의 세부 처리 기능을 상세히 기술하는 서술형 도구

모듈 명세서를 작성하는 과정을 모듈 설계라고 한다.

• 모든 모듈을 대상으로 구현에 필요한 모든 정보, 즉 모듈의 개요, 다른 모듈과 인터페이스 정보, 모듈의 내부 구조, 정보 처리 방법 등을 정확하게 기술한다.
• 모듈 명세서의 작성 도구에는 의사 코드와 N-S 차트가 있다.

소프트웨어 구조를 이루는 기본 단위.

하나 또는 그 이상의 논리적 기능들을 수행하는 컴퓨터 지시어들의 집합.

1. 모듈의 속성
2. 모듈의 특징
3. 모듈 설계 시 유의 사항
4. 모듈화의 이점

구조적으로 설계된 프로그램을 일정한 규칙에 맞게 자연어 형식으로 표현한 것.

• 구조 도표 상의 모든 모듈에 대해 모듈의 기본 기능 및 수행/세부 절차를 기술한다.

논리의 기술(절차)에 중점을 둔 도형식 표현 도구

• 프로그램의 논리적인 구조를 사각형 박스로 표시한다.
• 순서도의 대안으로 제시된 것으로, 상세 처리 과정의 표현 도구로 사용된다.
• 논리 구조의 기본적인 순차, 선택, 반복 구조를 시각적으로 표현한다.

두 모듈 간의 상호 의존도를 측정하는 것.

좋은 설계는 모듈 간의 결합도를 최소화하여 모듈의 독립성을 높인 것이다.

• 두 모듈 간에 교환되는 정보의 양이 적으면 두 모듈의 결합도는 약해지고, 교환되는 정보의 양이 많아질수록 결합도는 강해진다.

• 결합도의 순서

  자료 결합도 - 스탬프 결합도 - 제어 결합도 - 외부 결합도 - 공통 결합도 - 내용 결합도

• 서로 다른 모듈 간에 매개변수 또는 인수를 통해 꼭 필요한 자료만을 교환하는 경우의 결합도.
• 한 모듈의 내용을 변경하더라도 다른 모듈에는 전혀 영향을 미치지 않는 설계 품질이 가장 좋은 결합도이다.

• 서로 다른 모듈이 동일한 자료 구조를 참조하는 경우의 결합도이다.
• 포맷이나 구조 같은 자료구조의 변화는 그것을 조회하는 모든 모듈 및 변화되는 필드를 실제로 조회하지 않는 모듈에게까지도 영향을 미친다.

서로 다른 모듈 간에 교환하는 매개변수(Parameter)가 제어 정보인 경우의 결합도이다.

• 어떤 모듈에서 외부(External)로 선언되어 있는 자료(변수)를 다른 모듈에서 참조하는 경우의 결합도.
• 참조되는 데이터의 범위를 각 모듈에서 제한할 수 있다.

• 서로 다른 모듈들이 하나의 기억장소에 설정된 공통의 데이터 영역을 공유하는 경우의 결합도.
• 공통 데이터 영역의 내용을 조금만 수정해도 이를 사용하는 모든 모듈에 영향을 미치게 되어 모듈의 독립성을 약하게 만든다.

• 한 모듈이 다른 모듈의 내부 자료를 직접적으로 참조하는 경우의 결합도.
• 결합도 중 의존도가 가장 높고, 순서 변경이 다른 모듈에 영향을 주기 쉽다.

한 모듈 내에 있는 구성 요소들 간의 기능적 관련성을 평가하는 기준으로, 응집도가 높을 수록 모듈의 독립성은 높아진다.

모듈 내부의 모든 기능 요소가 한 가지의 작업만을 수행하는 경우의 응집도.

모듈 내부의 한 기능 요소에 의한 출력 데이터가 다음 기능 요소의 입력 데이터로 제공되는 경우의 응집도.

동일한 입·출력 데이터를 이용하여 서로 다른 기능을 수행하는 요소들로 구성되며, 요소 사이에 데이터를 주고받거나 데이터를 똑같이 공유한다.

• 일정한 순서에 의해 처리되어야 할 요소들을 하나의 모듈로 구성한 경우의 응집도.
• 전달 데이터와 반환 데이터 사이에 관련이 없고, 처리 기능보다는 실행 순서에 의해 연결된다.

특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 구성한 경우의 응집도로, 기능 사이의 관련성은 저거다.

• 논리적으로 서로 관련 있는 요소들을 모아 하나의 모듈로 작성하여, 그 모듈의 기능이 매개변수에 따라 처리 내용이나 처리 루트가 달라지는 경우의 응집도.
• 모듈 내부 로직이 복잡해져 모듈 자체의 디버깅이나 유지보수 및 확장이 어렵다.

모듈 내부의 각 요소들이 서로 관계 없는 것끼리 모인 경우의 응집도.

시스템의 집행 기능과 실무 기능을 단계별로 분리하는 것을 의미.

• 모듈을 분해하는 이유는 모듈의 크기를 줄임으로써 시스템에 대한 이해를 쉽게 하기 위해서이다.
• 모듈을 분해하면 한 기능이 두 개 이상의 모듈에서 수행되는 것을 막을 수 있으며, 구현이 쉬워진다.

의사 결정 분리(Decision Split)란 의사 결정 과정 중 조건 인식 부분에서 필요한 데이터와 그에 따라 실행하는 부분에서 필요한 데이터가 서로 다른 모듈에 분리되어 있는 상태를 의미한다.

• 의사 결정 분리는 가능한 한 피하는 것이 좋으며, 꼭 필요한 경우에는 조건 인식 모듈의 제어 영역(Fan-Out) 내에 포함되도록 설계한다.

하나의 모듈이 호출(제어)할 수 있는 모듈의 수를 의미.

• 한 모듈의 제어 영역(Fan-Out)은 7±2 범위를 벗어나지 않는 것이 좋다.

하나의 모듈을 호출(제어)하는 상위 모듈의 수를 의미.

• 공유 영역이 높다는 것은 모듈 분해가 잘 되었음과 모듈이 제한적이 아님을 의미하지만, 지나치게 높은 공유 영역은 유지보수를 어렵게 만들고 공유된 모듈의 변경 사항이 여러 개의 상위 모듈에 영향을 미치므로 알맞게 설계해야 한다.

오류 메시지를 처리하는 방법에는 오류가 발생한 모듈에서 처리할 수 있는 분산 처리 방법과 오류 처리만을 전담하는 모듈을 별도로 두어 종합적으로 처리하는 방법이 있다.

• 오류 전담 모듈을 사용하는 종합 처리 방법은 복잡한 대형 시스템에서 효율적이다.

모듈은 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 분해하며, 보통 50~100Step 정도로 분해한다.

• 모듈이 너무 크면 모듈의 논리를 설계하거나 수정, 유지보수하기가 매우 어렵고 개발 비용이 많이 소모된다.
• 모듈이 너무 작으면 모듈 사이의 인터페이스가 많아져 개발 비용이 많아진다.