구조화 분석

Structured analysis
구조화 분석 [1]접근법의 예.

소프트웨어 엔지니어링에서 구조화 해석(SA) 및 구조화 설계(SD)는 비즈니스 요건을 분석하고 컴퓨터 프로그램, 하드웨어 구성 및 관련 수동 절차로 관행을 변환하기 위한 사양을 개발하기 위한 방법입니다.

구조화 분석 및 설계 기법은 시스템 분석의 기본 도구입니다.그것들은 1960년대와 1970년대의 [2]고전적인 시스템 분석에서 발전했다.

구조화 분석의 목적

구조 분석은 1980년대에 유행하여 [citation needed]오늘날에도 여전히 사용되고 있다.구조화 분석은 시스템 개념(또는 실제 상황)을 데이터 흐름도로 표현되는 제어 용어로 해석하는 것으로 구성됩니다.버블에서 데이터 저장소로 이동하는 데이터 및 제어 흐름은 추적하기 어렵고 버블 수가 증가할 수 있습니다.

한 가지 방법은 먼저 시스템이 반응해야 하는 외부 세계의 이벤트를 정의한 후 해당 이벤트에 버블을 할당하는 것입니다.상호 작용이 필요한 버블은 시스템이 정의될 때까지 연결됩니다.버블은 보통 복잡성을 줄이기 위해 더 높은 수준의 버블로 그룹화됩니다.데이터 사전은 데이터 및 명령어 흐름을 기술하기 위해 필요하며, 프로세스 사양은 트랜잭션/[3]변환 정보를 캡처하기 위해 필요합니다.

SA 및 SD에는 구조도, 데이터 흐름도 및 데이터 모델도가 표시되며, 그 중에는 Tom DeMarco, Ken Orr, Larry Constantine, Vaughn Frick, Ed Yourdon, Steven Ward, Peter Chen 등이 개발한 것도 포함됩니다.

이러한 기술은 구조화 시스템 분석 및 설계 방법, 수익성 있는 설계별 정보(PRIDE), 나스텍 구조화 분석 및 설계, SDM/70 및 스펙트럼 구조화 시스템 개발 방법론을 포함한 다양한 공개 시스템 개발 방법론에 결합되었습니다.

역사

구조화 분석은 1960년대부터 1980년대까지 소프트웨어 세계가 직면한 문제에 대응하여 개발된 분석, 설계 및 프로그래밍 기술의 집합을 나타내는 일련의 구조화 방법의 일부입니다.이 기간 동안 대부분의 상용 프로그래밍은 Cobol과 Fortran, 그리고 C와 BASIC에서 수행되었다."좋은" 설계와 프로그래밍 기법에 대한 지침은 거의 없었고, 요구사항과 설계를 문서화하기 위한 표준 기법은 없었다.시스템은 점점 더 커지고 복잡해졌으며 [4]정보 시스템의 개발은 점점 더 어려워졌습니다."

크고 복잡한 소프트웨어를 관리하기 위한 방법으로 1960년대 [4]말부터 다음과 같은 구조화된 방법이 등장했습니다.

Hay(1999)에 따르면, "정보 공학은 1970년대에 개발된 구조화된 기술의 논리적 확장이었다.구조화된 프로그래밍은 구조화된 설계로 이어졌고, 이는 구조화된 시스템 분석으로 이어졌습니다.이러한 기술은 사용자와 개발자 간의 커뮤니케이션을 지원하고 분석가와 설계자의 규율을 개선하기 위해 구조 설계를 위한 구조 차트 및 구조 분석을 위한 데이터 흐름도를 사용하는 것이 특징이다.1980년대 들어 도표 작성을 자동화하고 데이터 사전에 그려진 내용을 추적하는 도구가 등장하기 시작했다.[10]컴퓨터 지원 설계와 컴퓨터 지원 제조(CAD/CAM)의 예에 따라, 이러한 도구의 사용은 컴퓨터 지원 소프트웨어 엔지니어링(CASE)으로 명명되었습니다.

구조화 분석 토픽

단일 추상화 메커니즘

구조화 분석 예제.[11]

구조화 분석은 일반적으로 단일 추상화 메커니즘을 사용하여 계층을 만듭니다.구조화 분석 방법은 IDEF(그림 참조)를 채용할 수 있으며 프로세스 중심이며 목적과 관점으로 시작한다.이 방법은 전체 기능을 식별하고 반복적으로 기능을 더 작은 기능으로 분할하여 프로세스 최적화에 필요한 입력, 출력, 제어 및 메커니즘을 보존합니다.기능 분해 접근법이라고도 하며, 함수 내 응집력과 구조화된 [11]데이터로 이어지는 함수 간 결합에 초점을 맞춥니다.

구조화된 방법의 기능 분해는 시스템 동작을 기술하지 않고 프로세스를 기술하고 필요한 기능의 형태로 시스템 구조를 지시합니다.이 방법은 활동과 관련된 입력 및 출력을 식별합니다.구조화 분석이 인기 있는 이유 중 하나는 단일 시스템 또는 엔터프라이즈 수준에서 높은 수준의 프로세스와 개념을 전달할 수 있는 직관적인 능력입니다.오브젝트가 어떻게 상용화된 오브젝트 지향 개발을 위한 기능을 지원하는지 알아내는 것은 불분명합니다.IDEF와 달리 UML은 Service-Oriented Architecture(SOA;[11] 서비스 지향 아키텍처)를 기술할 때 유용한 여러 추상화 메커니즘을 사용하여 인터페이스를 구동합니다.

접근

구조화 분석은 시스템을 통과하는 데이터의 관점에서 시스템을 봅니다.시스템의 기능은 데이터 흐름을 변환하는 프로세스에 의해 설명됩니다.구조화 분석은 연속적인 분해(또는 하향식) 분석을 통해 숨겨진 정보를 활용합니다.이것에 의해, 관련하는 디테일에 주의를 집중해, 관련 없는 디테일을 보는 혼란을 피할 수 있습니다.상세도가 높아지면 정보의 폭도 작아집니다.구조 분석의 결과는 관련된 그래픽 다이어그램, 공정 설명 및 데이터 정의 세트입니다.이들은 시스템 기능 [12]요건을 충족하기 위해 필요한 변환과 데이터에 대해 설명합니다.

구조화 분석 접근법은 프로세스 객체와 데이터 [12]객체 모두에 대한 관점을 개발합니다.

De Marco의 접근방식은[13] 다음과 같은 오브젝트로 구성됩니다(그림 [12]참조).

이것에 의해, 데이터 플로우 다이어그램(DFD)은 방향 그래프이다.호는 데이터를 나타내고 노드(원 또는 버블)는 데이터를 변환하는 프로세스를 나타냅니다.프로세스는 하위 프로세스와 데이터 흐름을 보여주는 보다 상세한 DFD로 분해할 수 있습니다.서브프로세스의 기능을 쉽게 이해할 수 있을 때까지 다른 DFD 세트를 사용하여 서브프로세스를 더욱 분해할 수 있습니다.기능적 프리미티브는 더 이상 분해할 필요가 없는 프로세스입니다.기능적 프리미티브는 프로세스 사양(또는 미니 사양)으로 기술됩니다.프로세스 사양은 의사 코드, 흐름도 또는 구조화된 영어로 구성될 수 있습니다.DFD는 시스템 구조를 기능적 프리미티브로 구성된 상호 연결된 프로세스 네트워크로 모델링합니다.데이터 사전은 데이터 흐름, 데이터 요소, 파일 및 데이터베이스의 항목(정의) 세트입니다.데이터 딕셔너리 엔트리는 하향식으로 분할됩니다.다른 데이터 사전 항목 및 데이터 흐름 [12]다이어그램에서 참조할 수 있습니다.

콘텍스트 다이어그램

시스템 컨텍스트 다이어그램의 [14]예.

컨텍스트 다이어그램은 해당 [15]시스템과 상호작용할 수 있는 시스템 외부의 행위자를 나타내는 다이어그램입니다.이 다이어그램은 블록 다이어그램과 유사한 시스템의 최고 수준 뷰로, 소프트웨어 기반 시스템 전체와 외부 요소와의 입력 및 출력을 보여줍니다.

Kossiakoff(2003)에 의하면, 이러한 종류의 다이어그램은, 통상, 「시스템이 중앙에 배치되어 있어 내부 구조의 상세한 것은 없고, 모든 상호작용하는 시스템, 환경, 액티비티에 둘러싸인 것을 나타내고 있습니다.시스템 컨텍스트 다이어그램의 목적은 시스템 요건과 제약조건의 완전한 세트를 개발할 때 고려해야 할 외부 요인 및 사건에 주의를 집중하는 것입니다."[15]시스템 콘텍스트 다이어그램은 데이터 흐름 다이어그램과 관련지어 시스템이 직면하도록 설계된 시스템과 다른 액터 간의 상호작용을 보여준다.시스템 콘텍스트도는 시스템이 소프트웨어 엔지니어링의 일부가 되는 콘텍스트를 이해하는 데 도움이 됩니다.

데이터 사전

데이터베이스 테이블, 추출물 및 [16]메타데이터 설계에 필수적인 엔티티 관계도.

데이터 사전 또는 데이터베이스 사전은 데이터베이스의 [16]기본 구성을 정의하는 파일입니다.데이터베이스 사전에는 데이터베이스의 모든 파일 목록, 각 파일의 레코드 수 및 각 데이터 필드의 이름과 유형이 포함됩니다.대부분의 데이터베이스 관리 시스템은 사용자가 실수로 데이터 사전을 파괴하는 것을 방지하기 위해 사용자가 데이터 사전을 숨깁니다.데이터 사전에는 데이터베이스의 실제 데이터는 포함되어 있지 않으며, 이를 관리하기 위한 장부 정보만 포함되어 있습니다.그러나 데이터 사전이 없으면 데이터베이스 관리 시스템은 데이터베이스의 [16]데이터에 액세스할 수 없습니다.

데이터베이스 사용자와 응용프로그램 개발자는 하나 이상의 데이터베이스의 [17]구성, 내용 및 규칙을 카탈로그로 작성하는 신뢰할 수 있는 데이터 사전 문서를 사용할 수 있습니다.여기에는 일반적으로 각 데이터베이스에 있는 다양한 테이블 및 필드의 이름과 설명, 각 데이터 요소의 유형 및 길이와 같은 추가 세부 정보가 포함됩니다.이러한 문서에는 상세 수준에 대한 보편적인 표준은 없지만, 주로 데이터 자체가 아니라 데이터베이스 구조에 대한 메타데이터를 추출한 것입니다.데이터 사전 문서는 데이터 요소가 어떻게 부호화되는지를 기술하는 추가 정보를 포함할 수도 있다.잘 설계된 데이터 사전 설명서의 장점 중 하나는 복잡한 데이터베이스 전체 또는 다수의 연합 데이터베이스 [18]집합에서 일관성을 확립하는 데 도움이 된다는 것입니다.

데이터 흐름도

데이터 흐름도 예시.[19]

데이터 흐름도(DFD)는 정보 시스템을 통한 데이터 흐름을 그래픽으로 표현한 것입니다.이는 컴퓨터 하드웨어가 아닌 프로세스를 통한 데이터 흐름을 나타낸다는 점에서 시스템 흐름도와 다릅니다.데이터 흐름도는 구조화 설계 개발자인 Larry Constantine이 마틴과 에스트린의 "데이터 흐름 그래프"[20] 연산 모델을 기반으로 발명했습니다.

시스템과 외부 엔티티 간의 상호작용을 나타내는 시스템 컨텍스트 다이어그램을 먼저 그리는 것이 일반적입니다.DFD는 시스템이 어떻게 더 작은 부분으로 분할되어 있는지 보여주고 이러한 부분 간의 데이터 흐름을 강조하기 위해 설계되었습니다.그런 다음 이 컨텍스트 수준의 데이터 흐름도를 "폭발"하여 모델링 중인 시스템의 세부사항을 표시합니다.

데이터 흐름도(DFD)는 구조화 시스템 분석 및 설계 방법(SSADM)의 세 가지 중요한 관점 중 하나입니다.프로젝트 스폰서와 최종 사용자는 시스템 발전의 모든 단계에서 브리핑을 받고 상담을 받아야 합니다.데이터 흐름도를 통해 사용자는 시스템 작동 방식, 시스템 실행 내용 및 시스템 구현 방법을 시각화할 수 있습니다.기존 시스템의 데이터 흐름도를 작성하여 새로운 시스템의 데이터 흐름도와 비교하여 보다 효율적인 시스템을 구현하기 위한 비교를 도출할 수 있습니다.데이터 흐름도를 사용하여 최종 사용자가 입력한 데이터가 최종적으로 디스패치부터 리코크까지 시스템 전체의 구조에 미치는 영향을 최종 사용자에게 제공할 수 있습니다.시스템 개발 방법은 데이터 흐름도를 통해 확인할 수 있습니다.

구조도

구성 시스템 구조 [21]차트.

구조도(SC)는 구성 시스템의 관리 가능한 최저 [21]수준까지 분석을 보여 주는 차트입니다.이 차트는 프로그램 모듈을 트리 구조로 배열하기 위해 구조화된 프로그래밍에서 사용됩니다.각 모듈은 모듈 이름이 포함된 상자로 표시됩니다.트리 구조는 모듈 [22]간의 관계를 시각화합니다.

구조도는 구조 분석에서 컴퓨터 프로그램의 고급 설계 또는 아키텍처를 지정하기 위해 사용됩니다.설계 도구로서 프로그래머가 큰 소프트웨어 문제를 분할하고 극복하는 데 도움이 됩니다. 즉, 문제를 인간의 뇌가 이해할 수 있을 만큼 작은 부분으로 반복적으로 분해합니다.이 공정을 하향식 설계 또는 기능 분해라고 합니다.프로그래머는 구조도를 사용하여 건축가가 청사진을 사용하여 집을 짓는 것과 유사한 방식으로 프로그램을 만듭니다.설계 단계에서는 차트를 그려 클라이언트와 다양한 소프트웨어 설계자가 소통하는 방법으로 사용합니다.프로그램의 실제 구축(실장) 중에 차트는 계속 마스터 [23]플랜이라고 불립니다.

구조화 설계

구조화 설계(SD)는 모듈의 개발과 소위 "모듈 계층"[24]에서의 이들 모듈의 합성과 관련이 있습니다.최적의 모듈 구조와 인터페이스를 설계하기 위해서는 다음 두 가지 원칙이 중요합니다.

  • "기능적으로 관련된 프로세스를 특정 [12]모듈로 그룹화하는 것과 관련된 응집력" 및
  • 커플링은 모듈 간에 전달되는 정보 또는 파라미터의 흐름과 관련이 있습니다.최적의 결합을 통해 모듈의 인터페이스를 줄이고 결과적으로 소프트웨어의 복잡성을 줄일 수 있습니다."[12]

구조화 설계는 1960년대 후반 Larry Constantine에 의해 개발되었으며, 1970년대에 [5][6]공동작업자들과 함께 수정 및 출판되었습니다. 자세한 내용은 Larry Constantine: 구조화 설계를 참조하십시오.Page-Jones(1980)는 다음과 같은 세 가지 주요 객체로 구성된 자신만의 접근방식을 제안했다.

  • 구조도
  • 모듈 사양
  • 데이터 딕셔너리

구조도는 "모듈 계층 또는 모듈의 호출 시퀀스 관계"를 표시하는 것을 목적으로 합니다.구조도에 표시된 각 모듈의 모듈 사양이 있습니다.모듈 사양은 의사 코드 또는 프로그램 설계 언어로 구성될 수 있습니다.데이터 사전은 구조화 분석의 사전과 같다.소프트웨어 개발 라이프 사이클의 이 단계에서는 해석 및 설계가 실행된 후 데이터 타입 선언"[25] 및 프로시저 또는 서브루틴 [12]템플릿을 자동으로 생성할 수 있다.

비판

데이터 흐름도에는 다음과 [3]같은 문제가 있습니다.

  1. 적절한 버블 선택
  2. 의미있고 상호 합의된 방식으로 버블을 분할하고,
  3. 데이터 흐름을 이해하기 위해 필요한 문서 크기
  4. 데이터 흐름도는 본질적으로 매우 기능하기 때문에 자주 변경될 수 있습니다.
  5. '데이터' 흐름은 강조되지만 '데이터' 모델링은 강조되지 않기 때문에 시스템의 주제를 거의 이해하지 못합니다.
  6. 고객이 데이터 흐름 및 버블에 대한 개념 매핑 방법을 이해하는 데 어려움을 겪고 있음
  7. 설계자는 DFD 조직을 구현 가능한 형식으로 전환해야 합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Tricia Gilbert (2006) 테크놀로지 평가를 위한 FCS 평가 기준 요소 2008-09-18 Wayback Machine 아카이브
  2. ^ 에드워드 유든(1986년).구조화 기술 관리: 1990년대 소프트웨어 개발 전략Yourdon Press 35페이지
  3. ^ a b FAA(2000).FAA 시스템 안전 핸드북, 부록 D.2000년 12월 30일
  4. ^ a b Dave Levitt(2000).faculty.inverhills.edu/dlevitt의 「구조화 분석 및 설계 소개」를 참조해 주세요.2008년 9월 21일 취득.더 이상 온라인 2017이 아닙니다.
  5. ^ a b 스티븐스, 마이어스 & 콘스탄틴 1974년
  6. ^ a b 1979년 Yourdon & Constantine.
  7. ^ McMenamin, Stephen M.; Palmer, John F. (1984). Essential Systems Analysis. Yourdon Press. ISBN 978-0-13-287905-7.
  8. ^ Gavriel Salvendy (2001).산업공학 핸드북: 테크놀로지 및 운용관리..페이지 508.
  9. ^ Yourdon, Edward (1989). Modern Structured Analysis. Prentice-Hall. ISBN 978-0-13-598632-5.
  10. ^ 데이비드 C.Hay(1999) 오브젝트 오리엔테이션에 관한 유행어 준거 달성 2008-10-20 Wayback Machine Essential Strategies, Inc.에서 아카이브 완료2008-10-20
  11. ^ a b c DoD 아키텍처 프레임워크 작업 그룹(2003).DoDAF 1.5 제2권, 2003년 8월 15일
  12. ^ a b c d e f g Alan Hecht와 Andy Simmons(1986)는 Ada Programming Support Environments와 자동 구조 분석 및 설계를 통합했습니다.NASA 1986.
  13. ^ 톰 데마르코(1978년).Structured Analysis 및 시스템 사양.1978년 뉴욕 유든 프레스입니다
  14. ^ NDE 프로젝트 관리 Wayback Machine(NPOESS) 데이터 이용 웹 사이트에서 2008-11-07년에 아카이브되었습니다.2008.
  15. ^ a b 알렉산더 코시아코프, 윌리엄 N스위트(2003년).시스템 엔지니어링: 원칙과 프랙티스 페이지 413.
  16. ^ a b c Data Integration Glossary Archived 2012-02-18 미국 교통부 웨이백 머신, 2001년 8월
  17. ^ TechTarget, SearchSOA, 데이터 사전이란 무엇입니까?
  18. ^ AHIMA 연습 개요, 데이터 사전 개발 가이드라인, AHIMA 77 저널, 제2호(2006년 2월): 64A-D.
  19. ^ 존 아졸리니(2000).시스템 엔지니어링 프랙티스 소개2000년 7월
  20. ^ W. Stevens, G. Myers, L. Constantine, "구조화 설계", IBM Systems Journal, 13(2), 115-139, 1974.
  21. ^ a b 구성 관리: IRS 리소스 파트 2 IT 27장 구성 관리.2008년 11월 14일에 액세스.
  22. ^ 제임스 마틴, 카르마 L. 맥클루어(1988)구조화 기술: 사례의 기초프렌티스 홀 56페이지
  23. ^ David Wolber "Wayback Machine에서 2009-02-19로 아카이브된 구조 차트:보충 노트 구조 차트 및 상향 구현: Java 버전.
  24. ^ 페이지존 1980.
  25. ^ Belkhouche, B.와 J.E. Urban.(1986년)."추상 사양에서 추상 데이터 유형의 직접 구현"입력: 소프트웨어 엔지니어링에 관한 IEEE 거래 페이지 549-661, 1986년 5월.

추가 정보

외부 링크

Wikimedia Commons에는 구조화된 분석과 관련된 미디어가 있습니다.