문제 프레임 접근법

문제 분석 또는 문제 프레임 접근법은 소프트웨어 요건 분석 접근법입니다.그것은 영국의 소프트웨어 컨설턴트인 Michael A에 의해 개발되었다. 1990년대 잭슨.

역사

문제 프레임의 접근방식은 Jackson에 의해 그의 저서 Software Requirements & Specifications(1995)와 소프트웨어 엔지니어링에 관한 다양한 저널의 많은 기사에서 처음 설명되었습니다.이것은 그의 문제 프레임에 자세히 설명되어 있습니다. 소프트웨어 개발 문제 분석 및 구조화(2001).

제9회 요건 엔지니어링 국제 워크숍에서는 문제 프레임에 관한 세션을 실시했습니다.2003년 ^[1]오스트리아 Klagenfurt/Velden에서 열린 소프트웨어 품질 재단(REFSQ)ICSE'04의 일환으로 스코틀랜드 에든버러에서 개최된 제1회 문제^[2] 프레임의 적용과 진전에 관한 국제 워크숍이 개최되었다.이 워크숍의 성과 중 하나는 2005년 국제정보 및 소프트웨어 테크놀로지 저널의 문제 프레임에 관한 특별호입니다.

제2회 문제 프레임의 적용과 진전에 관한 국제 워크숍이^[3] ICSE 2006의 일환으로 중국 상하이에서 개최되었습니다.ICSE 2008의 일환으로 독일 라이프치히에서 제3회 IWAAPF(^[4]Applications and Advanced in Problem Frame) 국제 워크숍이 개최되었습니다.2010년 IWAAPF 워크숍은 IWAAPO(International Workshop on Applications and Advances of Problem-Orientation)로 대체되었습니다.IWAAPO는 문제 분석에 중점을 ^[5]둔 소프트웨어 개발에 대한 대안적이고 보완적인 접근방식을 포함하도록 워크숍의 초점을 넓힌다.IWAAPO-2010은 ICSE 2010의 일환으로 남아프리카공화국 ^[6]케이프타운에서 개최되었다.

오늘날 문제 프레임 접근법에 대한 연구는 많은 대학에서 이루어지고 있습니다.특히 영국의 Open University는 관련 문제와 솔루션 구조의 연구^[7][8] 테마의 일부입니다.

문제 프레임 접근법의 아이디어는 문제 지향 개발(POD) 및 문제 지향 엔지니어링(POE) 개념으로 일반화되어 있으며, 이 개념 중 문제 지향 소프트웨어 엔지니어링(POE)은 특정 하위 범주입니다.제1회 문제지향적 개발에 관한 국제 워크숍은 2009년 6월에 개최되었습니다.

개요

기본 철학

문제 분석 또는 문제 프레임 접근법은 컴퓨터 소프트웨어의 요건을 수집하고 사양을 작성할 때 사용하는 접근법(개념 세트)입니다.그 기본이념은 다음과 같이 주장하는 다른 소프트웨어 요구사항 방법과는 확연히 다르다.

• 요건 분석에 접근하는 가장 좋은 방법은 계층이 아닌 병렬로 사용자 ^[9]요건을 분해하는 프로세스를 사용하는 것입니다.
• 사용자 요건은 소프트웨어 시스템이나 소프트웨어 시스템과의 인터페이스가 아니라 실제 환경(애플리케이션 도메인)에서의 관계에 관한 것입니다.

솔루션은 컴퓨터와 그 소프트웨어 안에 있고, 문제는 바깥 세상에 있다는 것을 인식하는 것이 더 도움이 됩니다.컴퓨터는 외부 세계와 연결되어 있기 때문에 이러한 문제에 대한 해결책을 제공할 수 있습니다.^[10]

그 교훈은 명확합니다.문제를 연구하고 분석하려면 문제의 세계를 깊이 있게 연구하고 분석하는 데 초점을 맞춰야 합니다.또한 조사에서는 컴퓨터로부터 멀리 떨어진 곳으로 이동할 용의가 있어야 합니다.[전송 문제 중...]무엇이 있는지(사람과 사무실, 휴일, 사무실 이동, 책임 위임 등)와 시스템이 달성하고 싶은 효과(문제 세계)를 기술해야 합니다.A 번호에 대한 콜은 A에 도달해야 하며 [B가 휴가 중일 때] C가 D의 데스크에서 일시적으로 작업하고 있는 경우, B에의 콜 또는 C의 번호가 C에 도달해야 합니다.^[11]

이 중 어느 것도 컴퓨터와의 인터페이스에는 표시되지 않습니다.그들은 모두 그것보다 세계에 더 깊이 빠져 있다.^[12]

이 접근법에서는 세 가지 개념적 도구를 사용합니다.

특정 문제를 설명하는 도구

특정 문제를 설명하는 데 사용되는 개념에는 현상(이벤트를 포함한 다양한 종류의), 문제 컨텍스트, 문제 도메인, 솔루션 도메인(머신이라고도 함), 공유 현상(도메인 인터페이스에 존재하는 현상)이 포함됩니다.도메인 요구사항(문제 도메인에 있음) 및 사양(문제 도메인:머신 인터페이스에 있음)이 있습니다.

문제를 설명하는 그래픽 도구는 컨텍스트 다이어그램과 문제 다이어그램입니다.

문제 클래스(문제 프레임)를 설명하는 도구

문제 프레임 접근법에는 문제의 클래스를 설명하기 위한 개념이 포함되어 있습니다.인식된 문제의 클래스를 문제 프레임이라고 합니다(설계 패턴과 거의 유사합니다).

문제 프레임에서 도메인은 일반적인 이름이 부여되고 그 중요한 특성에 따라 설명됩니다.예를 들어 도메인은 인과관계(결정론적, 사건에 대한 예측 가능한 방식으로 반응) 또는 비더블(사건 대응을 위해 입찰 또는 요청할 수 있지만 항상 예측 가능하고 결정론적 방식으로 사건에 반응할 것으로 기대할 수는 없다)로 분류될 수 있다.(Biddable 도메인은 보통 사람으로 구성됩니다.)

문제 프레임을 나타내는 그래픽 도구는 프레임 다이어그램입니다.프레임 다이어그램은 몇 가지 사소한 차이점을 제외하고는 일반적으로 문제 다이어그램과 비슷합니다.도메인은 특정이 아닌 일반적인 이름을 가집니다.도메인을 나타내는 직사각형에 주석을 달아 도메인의 유형(원인 또는 Biddable)을 나타냅니다.

인식된 문제 클래스 목록(문제 프레임)

잭슨에 의해 식별된 문제 프레임의 첫 번째 그룹은 다음과 같습니다.

1. 필수 동작
2. 명령된 행동
3. 정보 표시
4. 단순 공작물
5. 변용

그 후, 다른 연구자들은 추가적인 문제 프레임을 설명하거나 제안했습니다.

문제의 설명

문제의 콘텍스트

문제 분석에서는 소프트웨어 애플리케이션을 소프트웨어 기계의 한 종류로 간주합니다.소프트웨어 개발 프로젝트는 소프트웨어 머신을 생성하여 문제 상황에 추가하여 문제 상황을 변경하는 것을 목표로 하며, 여기에서 원하는 특정 효과를 가져옵니다.

특정 문제와의 관련성에 관심이 있는 문제 콘텍스트의 특정 부분(문제의 콘텍스트를 형성하는 문제 콘텍스트의 특정 부분)을 애플리케이션 도메인이라고 합니다.

소프트웨어 개발 프로젝트가 완료되고 소프트웨어 머신이 문제의 컨텍스트에 삽입되면 문제의 컨텍스트에는 애플리케이션 도메인과 머신이 모두 포함됩니다.이 시점에서 상황은 다음과 같습니다.

문제의 컨텍스트에는 시스템과 애플리케이션 도메인이 포함됩니다.머신 인터페이스는 머신과 애플리케이션 도메인이 만나 상호작용하는 곳입니다.

같은 상황은 다음과 같이 다른 종류의 다이어그램, 컨텍스트 다이어그램으로 표시할 수 있습니다.

콘텍스트 다이어그램

문제 분석가의 첫 번째 과제는 문제를 진정으로 이해하는 것입니다.즉, 문제가 설정되어 있는 콘텍스트를 이해하는 것입니다.즉, 콘텍스트 도표를 그리는 것입니다.

다음으로 문제의 컨텍스트(이 경우 브릿지가 구축되는 컨텍스트)를 조사하는 잭슨의 설명을 나타냅니다.

당신은 강을 가로지르는 다리를 건설하려는 엔지니어입니다.그래서 당신은 그 사이트를 방문한다.강의 한 둑에 서면 주변 땅과 하천 교통을 볼 수 있다.그 장소가 얼마나 노출되어 있는지, 바람이 얼마나 강하게 불고 있는지, 강이 얼마나 빨리 흐르고 있는지를 느낄 수 있다.당신은 은행을 보고 지질 조사가 암반 지형에 어떤 단층을 발견할지 궁금해 한다.구축하려는 브릿지를 상상합니다.(소프트웨어 요건 및 사양: "문제 컨텍스트")

소프트웨어 개발 문제를 이해하려는 분석가는 브리지 엔지니어와 동일한 프로세스를 거쳐야 합니다.그는 애플리케이션 도메인의 다양한 문제 영역을 조사하는 것부터 시작합니다.이러한 도메인은 계획된 시스템이 포함되어야 하는 컨텍스트를 형성합니다.그리고 나서 그는 기계가 이 상황에 어떻게 들어맞을지 상상합니다.그런 다음 설치된 기계와 함께 문제의 상황에 대한 자신의 비전을 보여주는 컨텍스트 다이어그램을 작성합니다.

콘텍스트 다이어그램은 애플리케이션 도메인의 다양한 문제 도메인, 그 연결, 머신과 문제의 도메인(일부)과의 연결을 보여줍니다.콘텍스트 다이어그램은 다음과 같습니다.

다음 그림은 다음과 같습니다.

• 제조할 기계어두운 테두리는 기계를 나타내는 상자를 식별하는 데 도움이 됩니다.
• 문제와 관련된 문제 도메인
• 실선은 도메인인터페이스를 나타냅니다.도메인이 중복되어 현상을 공유하는 영역입니다.

도메인은 단순히 우리가 관심 있는 세계의 일부분이다.그것은 현상(개인, 사건, 상황, 관계 및 행동)으로 구성됩니다.

도메인 인터페이스는 도메인이 접속 및 통신하는 영역입니다.도메인 인터페이스는 데이터 흐름이나 메시지가 아닙니다.인터페이스는 도메인이 부분적으로 중복되는 장소이기 때문에 인터페이스 내의 현상은 공유된 현상입니다.이러한 현상은 중복되는 도메인 양쪽에 존재합니다.

도메인은 원시적인 단세포 유기체(아메바와 같은)와 같다고 생각할 수 있습니다.그들은 자신의 일부를 의사동물로 확장할 수 있다.이런 두 유기체가 악수하듯 서로를 향해 뻗어나간다고 상상해보세요. 그리고 그들이 악수하는 지역의 세포 물질이 섞여서 두 유기체의 소유가 된다고 상상해보세요.이게 인터페이스예요.

다음 그림에서 X는 도메인 A와 B 사이의 인터페이스입니다.X에서 발생하는 개인 또는 사건은 A와 B에서 모두 존재하거나 발생한다.

공유 개인, 상태 및 이벤트는 공유하는 도메인과 다르게 보일 수 있습니다.예를 들어 컴퓨터와 키보드 사이의 인터페이스를 생각해 봅시다.키보드 도메인에 이벤트가 표시되었을 때 키보드 오퍼레이터가 스페이스 바를 누르면 컴퓨터는 입력 버퍼에 바이트 16진수("20")와 같은 이벤트를 표시합니다.

문제 그림

문제를 설명하기 위한 문제 분석가의 기본 도구는 문제 다이어그램입니다.일반적인 문제도를 다음에 나타냅니다.

콘텍스트 다이어그램에 표시되는 종류의 것 외에 문제 다이어그램에는 다음과 같은 것이 표시됩니다.

• 문제 영역에서 특정 효과를 가져오는 요건을 나타내는 점 모양의 타원형.
• 요건 참조를 나타내는 점선: 문제 영역의 현상에 대한 요건 참조.

문제 영역을 기계에 연결하는 인터페이스를 사양 인터페이스라고 하며, 사양 인터페이스의 현상을 사양 현상이라고 합니다.요구사항 분석가의 목표는 요구사항을 충족하기 위해 기계가 기계 인터페이스에서 보여야 하는 동작에 대한 사양을 개발하는 것입니다.

다음은 간단한 문제 다이어그램의 실제 예입니다.

이 문제는 병원의 컴퓨터 시스템의 일부일 수 있습니다.병원에서 환자들은 온도와 혈압을 감지하고 측정할 수 있는 센서와 연결되어 있다.요구 사항은 간호사 스테이션의 패널에 환자 상태에 대한 정보를 표시할 수 있는 기계를 구성하는 것입니다.

요구 사항의 이름은 "Display ~ Patient Condition(디스플레이 ~ 환자 상태)"입니다.칠드(~)는 요구 사항이 패널 디스플레이와 환자 상태 간의 관계 또는 대응에 관한 것임을 나타냅니다.화살표는 패널 디스플레이 도메인에 연결된 요구 사항 참조도 요구 사항 제약 조건임을 나타냅니다.즉, 요건에는 패널 디스플레이가 충족해야 하는 일종의 규정이 포함되어 있습니다.즉, 패널 디스플레이에 환자의 상태에 일치하고 정확하게 보고하는 정보가 표시되어야 합니다.

문제 클래스 설명

문제 프레임

문제 프레임은 인식 가능한 문제 클래스의 설명으로, 문제의 클래스가 기존의 솔루션을 가지고 있습니다.어떤 의미에서 문제 프레임은 문제 패턴입니다.

각 문제 프레임에는 자체 프레임 다이어그램이 있습니다.프레임 다이어그램은 본질적으로 문제 다이어그램과 비슷하지만 특정 도메인과 요건을 표시하는 대신 도메인의 유형과 유형을 표시합니다.도메인은 특정이 아닌 일반적인 이름을 가지고 있습니다.또한 도메인의 유형(원인 또는 Biddable)을 나타내기 위해 도메인을 나타내는 직사각형에 주석을 붙입니다.

바리안트 프레임

Problem Frames(문제 프레임)에서 Jackson은 자신이 식별한 5가지 기본 문제 프레임의 변형에 대해 설명했습니다.일반적으로 배리언트는 문제의 컨텍스트에 도메인을 추가합니다.

• 기술 변형은 기술 어휘 영역을 도입한다
• 연산자 변형은 연산자를 도입한다
• 접속 바리안트는 머신과 그것이 인터페이스하는 중앙 도메인 사이의 접속 도메인을 도입합니다.
• 제어 변형은 새로운 영역을 도입하지 않는다; 그것은 인터페이스 현상의 제어 특성을 변화시킨다.

문제의 우려

Jackson은 또한 문제 프레임을 다룰 때 발생하는 특정 종류의 우려 사항에 대해서도 논의합니다.

특정 우려 사항

• 오버런
• 초기화
• 신뢰성.
• 아이덴티티
• 완전성

구성에 관한 우려 사항

• 납득할 수 있는 기술
• 일관성.
• 우선 순위
• 방해다
• 동기

인식된 문제 프레임

Jackson이 발견한 첫 번째 문제 프레임은 다음과 같습니다.

1. 필수 동작
2. 명령된 행동
3. 정보 표시
4. 단순 공작물
5. 변용

그 후, 다른 연구자들은 추가적인 문제 프레임을 설명하거나 제안했습니다.

필수 동작 문제 프레임

이 문제 프레임의 배후에 있는 직관적인 개념은 다음과 같습니다.

• 물리 세계에는 특정 조건을 만족시키기 위해 행동을 제어해야 하는 부분이 있습니다.문제는 그 제어를 강제할 기계를 만드는 것이다.

명령 동작 문제 프레임

이 문제 프레임의 배후에 있는 직관적인 개념은 다음과 같습니다.

• 물리 세계에는 오퍼레이터가 발행한 명령에 따라 동작을 제어해야 하는 부분이 있습니다.문제는 오퍼레이터의 명령을 받아들이고 그에 따라 제어를 강제하는 기계를 만드는 것입니다.

정보 표시 문제 프레임

이 문제 프레임의 배후에 있는 직관적인 개념은 다음과 같습니다.

• 물리적 세계에는 특정 정보가 지속적으로 필요한 상태와 행동에 대한 부분이 있습니다.문제는 이 정보를 세계로부터 입수하여 필요한 위치에 필요한 형태로 표시하는 기계를 만드는 것입니다.

단순 공작물 문제 프레임

이 문제 프레임의 배후에 있는 직관적인 개념은 다음과 같습니다.

• 사용자가 컴퓨터 처리 가능한 특정 클래스의 텍스트나 그래픽 객체 또는 유사한 구조를 만들고 편집할 수 있도록 하는 도구가 필요합니다.이러한 구조를 나중에 복사, 인쇄, 분석 또는 다른 방법으로 사용할 수 있습니다.문제는 이 툴로서 기능할 수 있는 기계를 만드는 것입니다.

변환 문제 프레임

이 문제 프레임의 배후에 있는 직관적인 개념은 다음과 같습니다.

• 특정 필수 출력 파일을 제공하기 위해 데이터를 변환해야 하는 컴퓨터 판독 가능한 입력 파일이 있습니다.출력 데이터는 특정 형식이어야 하며 특정 규칙에 따라 입력 데이터에서 파생되어야 합니다.문제는 입력에서 필요한 출력을 생성하는 기계를 만드는 것입니다.

문제 분석 및 소프트웨어 개발 프로세스

문제 분석이 소프트웨어 개발 프로세스에 통합되면 소프트웨어 개발 라이프사이클은 문제 분석가부터 시작됩니다.문제 분석가는 상황을 조사하고 다음을 수행합니다.

• 컨텍스트 다이어그램을 만듭니다.
• 는 요건 목록을 수집하고 컨텍스트 다이어그램에 타원형 요건을 추가하여 포괄적인 '올인원' 문제 다이어그램을 작성합니다.(그러나 실제로는 올인원 문제 다이어그램을 작성하는 것은 실용적이지 않거나 도움이 되지 않을 수 있습니다.그림과 교차하는 요건이 너무 많아 매우 유용합니다.)
• 는 올인원 문제와 문제 다이어그램을 단순한 문제와 간단한 문제 다이어그램으로 분해합니다.이러한 문제는 서브셋이 아닌 올인원 다이어그램의 투영입니다.
• 는 각 문제가 인식된 문제 프레임의 인스턴스로 간주될 수 있을 정도로 단순해질 때까지 문제를 분해합니다.각 서브문제 기술에는 구축되는 기계의 사양 인터페이스에 대한 기술이 포함된다.

이 시점에서 문제 분석(문제 분해)이 완료됩니다.다음 단계는 프로세스를 되돌리고 솔루션 구성 프로세스를 통해 원하는 소프트웨어 시스템을 구축하는 것입니다.

솔루션 구성 프로세스는 아직 잘 이해되지 않았으며 여전히 많은 연구 주제입니다.소프트웨어 요건과 사양의 힌트를 바탕으로 추정하면 소프트웨어 개발 프로세스는 개발자에게 계속 진행되며, 개발자는 다음과 같이 됩니다.

• 복수의 서브 문제의 머신 사양을, 고객의 모든 요건을 만족시키는 소프트웨어 머신의 사양인, 단일 올인원 머신의 사양으로 구성합니다.이것은 간단한 작업이 아닙니다.구성 프로세스에서는 해결해야 할 구성 문제가 발생할 수 있습니다.
• 기존 코드/테스트/도입 프로세스를 통해 올인원 머신을 구현합니다.

같은 어프로치

몇 가지 점에서 문제 분석과 유사한 소프트웨어 개발 아이디어가 몇 가지 있습니다.

• 디자인 패턴의 개념은 문제 프레임에 대한 Jackson의 개념과 유사합니다.설계 패턴은 설계상의 문제(C++나 Java와 같은 특정 객체 지향 프로그래밍 언어에서의 설계상의 문제)를 인식하고 처리하는 데 사용되는 것이 아니라 설계상의 문제라는 점에서 다릅니다.또한, 한 가지 차이점은 문제 프레임에 문제가 있을 때 설계 패턴이 솔루션을 커버한다는 것입니다.그러나, 설계 패턴은 또한 구현될 프로그래밍 언어에 고유하지 않은 의미적 결과도 설명하는 경향이 있다.또 다른 차이점은 문제 프레임은 문제의 영역에 대한 네이티브 메타 알림인 반면 설계 패턴은 언어 구현자가 남긴 기술적 부채의 카탈로그라는 것입니다.
• AOP(Aspect-oriented Software Development, AOSD라고도 함)도 마찬가지로 병렬 분해에 관심이 있으며, 이를 통해 AOP 지지자들이 횡단 우려 사항 또는 측면을 해결합니다.AOP는 요구사항 분석 단계보다 설계 및 코드 생성 단계에 훨씬 가까운 문제에 대처합니다.
• AOP는 ITU-T Z.151 User Requirements Notation(URN; 사용자 요건 표기법) 등의 요건 엔지니어링 표기법으로 이행했습니다.URN에서는 AOP는 모든 의도적인 요소 위에 있습니다.또한 AOP는 휴리스틱으로 문제 프레임을 사용하는 요구사항 모델링에 적용할 수 있다.URN 모델은 문제 프레임 사고에 의해 구동되며 측면과 상호 작용하여 요건 모델에 아키텍처 전술을 포함할 수 있습니다.
• 마틴 파울러의 저서 Analysis Patterns는 패턴을 찾는 데 있어서 문제 분석과 매우 유사합니다.그러나 새로운 요구사항 분석 방법을 실제로 제시하지는 않습니다.문제 분석에 매우 중요한 병렬 분해 개념은 Fowler의 분석 패턴의 일부가 아닙니다.
• Jon G. Hall, Lucia Rapanotti는 잭슨과 함께 문제 프레임의 기초를 공유하는 문제 지향 소프트웨어 엔지니어링(POSE) 프레임워크를^[13] 개발했습니다.2005년부터 Hall과 Rapanoti는 POSE를 Problem Oriented Engineering(POE; 문제 지향 엔지니어링)으로 확장하여 개발 프로세스 모델과 보증 주도 설계를 ^[14]포함한 엔지니어링 설계의 프레임워크를 제공하고 있습니다.다수의 이해관계자가 포함되어 소프트웨어나 교육 제공 ^[15]등 다양한 엔지니어링 분야를 조합한 프로젝트로 확장할 수 있습니다.

레퍼런스

외부 링크

• http://mcs.open.ac.uk/mj665/은 Michael A입니다. 잭슨의 홈페이지
• http://www.jacksonworkbench.co.uk/stevefergspages/pfa/index.html에는 문제 프레임 접근법에 관한 논문과 기사가 게재되어 있습니다.