XPACE

Application Architecture	The architecture of a specific system
Domain Architecture	Baseline architecture for a family of systems within a specific domain
Architecture Style	Patterns, rules, and constraints imposed on architectures
Generic architecture model	Architecture description languages/rules based on: Linguistic model for descriptive Semantic model for analytic power

위로 갈수로 전문적이고 아래로 갈수록 일반화되는 개념이다.

Application Architecture와 Software Architecture

• Application Architecture와 S/W아키텍쳐는 프로젝트의 상황에 따라 구별되기도, 동일시 되기도 한다.
• 일반적으로 Application Architecture 는 기능 중심인 반면 S/W Architecture 는 기술 중심이다.
• 일반적으로 Application Architecture 는 Enterprise Level에서 설계되는 반면 S/W Architecture 는 모든 소프트웨어를 대상으로 한다.

Architecture and Component-Based Development

• Component-based software development entails a component architecture to ensure that components fit together forming themselves into successively larger systems. (compositional architecture)
• Large-grained, complex components usually need to be refined into successively detailed sub-architectures before implemented into executable code. (decompositional architecture)

Architecture and Framework-Based Development

• An application framework is a generic system that implements a domain architecture and can be extended into a complete application (sub)system.
• Understanding the architecture of an application framework is essential for framework-based development, as the rules and constraints for composition and interactions of its building blocks are predefined in the architecture.

Architecture and Patterns

• Patterns are proven, abstract solutions to recurring problems in specific contexts.
• Patterns are interaction abstractions captured in concrete forms.
• A pattern language is a structured collection of patterns that build on each other to transform a problem into its solution.
• A pattern language can generate a system of patterns to shape an architecture that solves a problem in a given domain.
• Therefore, an architecture can be described in terms of patterns. (Well-structured architectures are full of patterns.)

절차적 권고

아키텍쳐는 반드시 한명의 Architect나 한명의 리더를 가진 소그룹의 architect들에 의해 만들어져야 한다.

Architect (or team)는 반드시 시스템을 위한 기능 요구사항을 참조해야 한다.그리고 시스템의 목표를 만족시키기 위한 품질 속성과 그것의 우선순위를 결정해야 한다.

아키텍쳐는 최소한 하나이상의 static view와 dynamic view로 문서화되어야 하며, view를 위한 표기법은 모든 관련 당사자들이 이해하고 동의하는 방법을 사용해야 한다.

아키텍쳐는 반드시 시스템의 모든 관련 당사자들과 공유되어야 한다. 관련 당사자들은 적극적으로 아키텍쳐 review에 참가해야 한다.

아키텍쳐는 너무 늦어서 변경할 수 없기 전에 정량적으로 분석되고 평가되어야 한다.

아키텍쳐는 skeletal 시스템을 통해서 incremental 구현을 리드해야 한다.

시스템의 자원 경합은 최소화되어야 하며 자원 경합에 대한 해결은 명확히 명시되고 공유되며 유지 관리되어야 한다.

구조적 권고

아키텍쳐는 모듈화가 잘되어있어야 한다. 각 모듈의 기능적 역할이 분명해야 한다. 각 모듈은 잘 정의된 인터페이스를 가지고 있어야 한다. 인터페이스는 모듈 내부의 변경으로부터 외부모듈을 보호하며, 팀이 독립적으로 작업할 수 있게 도와준다.

품질 속성은 잘 알려진 아키텍쳐적 전략을 이용하여 성취되어야 한다.

아키텍쳐는 절대로 특정 버전의 상업적 제품이나 툴에 의존적이어서는 않 된다. 그러나 어쩔 수 없는 경우에는 반드시 다른 툴로 변경할 수 있도록 구조를 설계해야 한다.

데이터를 생성하는 모듈과 데이터를 사용하는 모듈을 분리해야 한다.. 데이터의 Producer와 Consumer가 별도로 변경되는 경우가 많기 때문에 modifiability를 높일 수 있다.

병행 프로세싱 시스템을 위해, 아키텍쳐는 프로세스나 쓰레드의 모습을 잘 정의해야 한다. 이때 쓰레드나 프로세스 구조가 모듈 구조를 반영할 필요는 없다. 모든 task나 process가 특정 processor에 할당되어야 하면 그 관계를 명확히 기술한다. 아키텍쳐에서 interaction 유형은 단순하고 숫자가 적어야 한다.

Performance

시스템의 반응 속도 : 일정 시간동안 처리되는 이벤트에 반응하는 데 필요한 시간

시스템의 처리량 : 일정시간동안 처리한 량

Security

정당한 사용자에게 계속해서 서비스를 제공하면서 인증되지 않은 서비스의 사용이나 거부 시도에 견디는 시스템 능력의 한계

Availability

가용성은 시스템이 살아서 작동하는 시간의 비율을 측정. 시스템이 다운되었을 경우 얼마나 빨리 운영을 재기할 수 있는가 하는 것 뿐 아니라 그 시간 간격에 의해 측정됨

Usability

Learnability : 사용자가 시스템의 인터페이스를 사용하기 위해 얼마나 빠르고 쉽게 배울 수 있는가?

Efficiency : 시스템이 사용자의 요청에 적절한 속도로 반응하는가?

Memorability : 사용자들이 시스템 용도 사이의 시스템 운영 방법을 기억할 수 있는가?

Error avoidance : 시스템이 공통적으로 발생하는 사용자 에러를 예상하고 방어하는가?

Error handling : 에러로부터 사용자가 회복되는 것을 시스템이 도와주는가?

Satisfaction : 시스템으로 인해 사용자의 작업이 쉬워지는가?

Functionality

시스템이 의도된 작업을 수행하는 능력

Modifiability

아키텍쳐로부터 직접 나오는 변경을 빨리 반영하고 비용을 효과적으로 처리하는 능력

Portability

시스템이 다른 컴퓨팅 환경에서도 작동하는 능력

Reusability

시스템의 구조나 컴포넌트 일부가 추후 개발될 어플리케이션에서도 재사용될 수 있는 능력.

Integrability

개별적으로 개발된 시스템의 컴포넌트가 함께 잘 동작하게 하는 능력

Testability

S/W가 적어도 하나의 문제가 있다고 할 때, 그 S/W가 다음 테스트 때에도 실패할 가능성

Documenting an architecture is a matter of documenting the relevant views and then adding documentation that applies to more then one view

 

1. Architectural View의 진화

Parnas(1974) observed Software consists of many structures, which he defined as partial descriptions showing a system as a collection of parts and showing relations among the parts

Perry and Wolf(1992) recognized that similar to building architecture, a variety of views of a system are required. Each view emphasizes certain architectural aspects that are useful to different stakeholders or for different purposes.

Kruchten(1995, Rational Software Co) wrote an influential paper describing 4 main views of software architecture

logical view

process view

development view

physical view And Kruchten prescribe using a small subset of important scenarios(instances of use-cases) that is the “+1” view called

use-case view

2. Model, View and Viewpoint

MODEL

A simplification of reality created in order to better understand the system being created. A complete description of a system from a particular perspective (with a particular purpose) and at a specific level of abstraction. “Complete” in this context means that you don't need any additional information to understand the system from that perspective. There is no single model (schematics) of an architecture. There are many models each representing an important aspect of the architecture. A model contains a set of model elements organized in some way. Two models cannot overlap. Some examples of models include: Analysis Model, Design Model, and Implementation Model.

VIEW

A simplified description/abstraction/projection of a model, which is seen from a given perspective or vantage point, and omits entities that are not relevant to this perspective.

Views can be tailored to address a stakeholder’s concern(s).

Views are relative to the needs of stakeholders, those individuals materially affected by the outcome of the system. This includes customers, users, architects, designers, developers and development managers, field support and systems support, etc.

VIEWPOINT

A definition (or description) of a view. The content, meaning and representation of a view. A viewpoint establishes the conventions by which a view is created, depicted and analyzed. The viewpoint determines the languages (including notations, modeling techniques, etc.) to be used to describe the view, and any associated modeling methods or analysis techniques to be applied to these representations of the view.

3. RUP 4+1 View

RUP에서 5개의 View가 필수는 아니고 단지 권고사항일 뿐이다. 따라서 필요하면 다른 View추가할 수 있다.

Sample: Non-Functional Requirements View
 

4. Siemens 4 View

Siemens에서 정의한 S/W아키텍쳐 View로써 많은 문헌에서 참조되고 있다.

 

5. 비즈니스 컴포넌트 팩토리(1999)

Technical Architecture

Component 실행 환경, 개발툴, 사용자 인터페이스 Component based시스템을 개발 실행하기 위해 필요한 기술적 문제

Application Architecture

아키텍쳐적 결정, 패턴, 가이드라인, 표준 등을 다룸

Project management Architecture

Large 시스템을 위한 Large Team을 셋업하고 관리하기 위한 개념, 가이드라인, 원리 등을 기술

Functional Architecture

시스템의 기능 명세와 구현 등의 문제를 다룸

Architectural structure의 종류는 3개의 그룹으로 분류할 수 있다.:

Module structures : 이 구조에서 구성 요소는 모듈이라는 구현 단위이다. Module structure들은 시스템에서 필요한 코드 기반의 표현이다.

Component-and-connector structures : 시스템의 구성 요소는 실행 component와 connector이다. component는 컴퓨팅 단위이고 connector는 component간의 통신 경로이다.

Allocation structures : S/W 요소와 외부(non-software) 요소와의 관계를 보여준다. S/W는 하나나 그 이상의 외부 요소에서 만들(개발환경)어지고 실행(실행환경)된다.

Module Structure

• Decomposition structure : 모듈 구성을 보여줌. 모듈들은 “is-a-submodule-of” 관계에 의해 연관됨.
• Uses structure : 모듈들간의 관계를 보여줌. 여기서 하나나 여러 개의 모듈이 다른 모듈의 데이터나 서비스를 사용.
• Layered structure : 모듈의 계층구조를 표현함. 계층구조에서 모듈은 하향 참조만 가능함.
• Class structure or generalization : 여기서 모듈은 클래스를 의미하며 이 structure에서는 클래스나 그들 간의 관계(“inherits-from” or “is-an-instance-of)를 표현함

Component-and-Connector Structure

• Process structure : 시스템의 동적인 측면을 다룸. 구성요소는 thread나 process를 말함.
• Concurrency structure : 리소스의 경합과 같은 시스템의 동시성 문제를 표현하기 위해 사용.
• Shared data (repository) structure : 데이터의 생성, 저장, 조회를 수행하는 component와 connector에 대한 구조를 표현.
• Client-server structure : 시스템이 client-server 형태로 구현된 경우에 사용. 이때 client와 server를 component라 하고 connector는 component가 공유하는 protocol과 message를 말함.

Allocation Structure

• Deployment structure : S/W가 어떻게 H/W나 통신 element에 할당되었는지를 표현한다. Element는 software, hardware, 그리고 communication 경로이다
• Implementation structure : S/W요소가 시스템의 development, integration 또는 configuration제어에서 file 구조에 어떻게 mapping되었는지를 보여준다.
• Work assignments structure : 모듈의 개발 혹은 통합을 책임질 담당자 혹은 팀을 할당한 내역

Project manager를 위한 View

• A top-level context diagram [ module ]
• A decomposition, uses, and/or layered view [ module ]
• A work assignment view [ allocation ]
• A deployment view [ allocation ]
• Overall purpose and constraints

 개발 팀을 위한 View

• A context diagram containing the module(s) he or she has been assigned[ module ]
• A decomposition, uses, and/or layered view [ module ]
• A view showing the component(s) the developer is working on and how they interact with other components at runtime [ C&C ]
• A mapping between views, showing the module(s) as components [ module, C&C ]
• The interface specification(s) of the developer’s element(s) and the interface specifications of those elements with which they interact [ module, C&C]
• The variability guide to implement required variability [ module ]
• An implementation view to find out where the assets he or she produces must go [ allocation ]
• A generalization view showing other modules that the developer can use to accomplish his or her work assignment [ module ]
• A deployment view [ allocation ]
• The documentation that applies beyond views, including a system overview
• Rationale and constraints

 Tester 혹은 integrater를 위한 View

• A context diagram showing the module(s) to be tested or integrated [ module ]
• The interface specification(s) and behavior specification(s) of the module(s) and the interface specifications of those elements with which they interact [ module, C&C ]
• An implementation view to find out where the assets that build the module are [ allocation ]
• A deployment view [ allocation ]

 다른 시스템의 디자이너를 위한 View

• A top-level context diagram [ module and/or C&C]
• Interface specifications for those elements with which their system will interact [ module, C&C ]

 Maintainer를 위한 View

• The views as mentioned for the developers of a system
• A decomposition view [ module ]
• A layered view [ module ]
• Rationale and constraints

 Customer를 위한 View

• A work assignment view, no doubt filtered to preserve the development organization’s confidential information [ allocation ]
• A deployment view [allocation ]
• Analysis results [ module, C&C ]
• A top-level context diagram in one or more C&C views [ C&C]

End User를 위한 View

• A view emphasizing flow of control and transformation of data, to see how inputs are transformed into output [ C&C ]
• A deployment view to understand how functionality is allocated to the platforms with which the users interact [allocation ]
• Analysis results that deal with properties of interest to them, such as performance or reliability [ module and/or C&C ]

 Analyst를 위한 View

• Views of the module viewtype family [ allocation ]
• A deployment view [allocation ]
• A communicating-processes view [ C&C ]
• Applicable component-and-connector views [ C&C]

 Infrastructure support 담당자를 위한 View

• A decomposition view [module ]
• A uses view [ module ]
• A implementation view [ C&C ]
• A variability guide [ module, C&C]
• A deployment view [ allocation ]

미래의 아키텍트(후임자)를 위한 View

• 아키텍쳐 모든 것에 관심이 있으며, 전임 아키텍트의 작업을 모두 이해하고자 함

검증되지 않은 입력 값

웹 어플리케이션에서 Request 정보를 사용하기 전에 그 정보를 검증하지 않음.클라이언트로부터 웹 어플리케이션이 요청을 받았을 때 그 요청이 적절한 값인지 여부를 검증하지 않음으로 인해 백엔드에 존재하는 자원을 공격할 수 있음.

부적절한 접근 통제

인증된 사용자들만이 할 수 있는 것에 대한 통제가 올바르게 시행되지 않음. 이를 통하여 인증되지 않은 사용자가 시스템에 접근하여 중요한 파일 읽거나 권한 없는 기능들을 수행할 수 있음. 예를 들자면 허가되지 않은 사용자가 웹 요청을 통해서 유닉스 시스템의 /etc/passwd 파일을 읽거나 윈도우 시스템의 웹 루트 디렉터리를 읽을 수 있는 등의 경로 유출(Path Traversal)을 허용하는 취약점.

부적절한 인증과 세션관리

계정 자격증명(Account Credential) 과 세션 토큰이 올바르게 보호되지 않음. 공격자는 암호, 키, 세션 쿠키, 그리고 다른 토큰 등을 얻음으로써 인증 매커니즘을 무력화 시키고, 다른 사용자로 위장할 수 있음.

Cross Site Scripting (XSS) Flow

공격자가 웹 어플리케이션을 사용해서 다른 최종 사용자에게 자바 스크립트와 같은 악성 데이터를 보낼 수 있다. 다른 사용자의 세션을 끊어 버리거나, PC를 공격할 수 있고, 데이터를 위조함으로써 사용자를 속일 수 있음.

버퍼 오버플로우

입력 값을 제대로 점검하지 않는 프로그램 언어로 만들어진 웹 어플리케이션 컴포넌트들은 비정상으로 종료 될 수 있고, 때로는 프로세스를 컨트롤 하는데 사용될 수 있다. 이러한 것들에는 CGI, 라이브러리, 드라이버, 웹 어플리케이션 컴포넌트 등이 포함.

Injection Flaws

웹 어플리케이션에서 외부 시스템이나 로컬 OS에 접근할 때 파라미터를 전달함으로써, 공격자가 파라미터에 악의적인 명령어를 넣었을 경우에 외부 시스템에서 이 명령어를 실행 시킬 수 있다.웹 어플리케이션에서 HTML 형식이나 쿠키, URL 파라미터 형식으로 시스템 명령어를 삽입 허용함으로써 웹 상에서도 시스템 명령을 실행할 수 있음.

잘못된 에러 핸들링

정상적인 운영상태에서 발생하는 오류를 제대로 핸들링하지 않음. 공격자들이 웹 어플리케이션에서 핸들링하지 않는 오류를 발생시킬 수 있다면, 시스템 정보를 얻거나 서비스 거부, 보안 메커니즘을 무력화 시킬 수 있고, 심지어 서버를 망가뜨릴 수 있음.

Insecure Storage

웹 어플리케이션은 정보 및 자격증명을 보호하기 위하여 암호화 함수를 빈번하게 사용한다. 이러한 함수들과 그것을 이루는 코드들에 대해 제대로 코드화 한다는 것은 어려운 것으로 알려졌고, 결과적으로 취약한 보호 기능을 보이는 경우가 자주 있음.

서비스 거부(DoS)

공격자는 사용자가 어플리케이션을 사용하거나 접근할 수 없도록 웹 어플리케이션의 자원을 소비해버릴 수 있다. 또한 사용자 계정을 잠그거나, 심지어 모든 어플리케이션의 기능을 마비시킬 수 있음.

안전하지 않은 설정관리

견고한 서버 설정 표준은 웹 어플리케이션을 보호하는데 매우 중요하다. 서버는 보안에 영향을 끼치는 많은 설정 옵션을 가지고 있음.

참고사이트
OWASP: A Guide to Building Secure Web Applications - http://www.owasp.org
SANS S.C.O.R.E. Web Application Checklist - http://www.sans.org/score/webappschecklist.php

어떤것을 프로젝트 성공이라하는가?

프로젝트 성공이란 프로젝트 결과로 인해 고객의 비즈니스가 만족해야 한다. 고객사의 직원을 의미하는 것은 아니다. 고객의 비즈니스와 고객 회사의 직원과는 다르다 회계담당 직원을 감원하기위해 회계시스템을 구축하는 프로젝트의 경우 프로젝트 결과가 좋으면? 고객사 직원은 직장을 잃게 된다. 그렇지만 고객사는 원하는 목적을 성취하게 되고 프로젝트는 성공했다고 할 수 있다. 그렇지만 좋은 모습의 성공은 고객이 시스템을 도입하여 새로운 사업기회를 얻고 매출이 증가하며 신규직원을 채용하는 것이라 할 수 있다.

두번째는 프로젝트 이행사(개발업체)가 이익을 남겨야 한다. 프로젝트를 잘하고 고객도 만족하는데 이행사가 그것으로 인해 망하거나, 혹은 그 프로젝트에 올인하여 다른 프로젝트가 망해서 손해를 본다면 그 프로젝트는 성공한 프로젝트라고 볼수 없다.

마지막으로 프로젝트 팀원의 만족이다. 죽도록 일해서 고객도 만족하고 회사도 수익을 남겼는데, 정작 개발자는 다시는 이 분야에서 일하지 않겠다고 생각하게된다면?? 성공이라 말할 수 있는가?

개발자가 떠나고자하는 고객사는 절대로 좋은 시스템을 갖을 수 없으며, 개발자의 불만이 높은 개발회사는 발전할 수 없다. 프로젝트 팀원의 불만족은 결국에 고객과 이행사에 부메랑이 되어 돌아오게된다.

프로젝트 성공이라함은 고객과 이행사와 참여자가 함께 만족할때 성공이라 말할 수 있다.

프로젝트 위험 신호는 이러한 현상이 보이면 대체로 프로젝트가 실패할 확률이 높아진다는 것을 의미한다.

• 아키텍쳐가 현재의 조직에 맞추도록 강요되었다.
• 아키텍쳐 상에 25개 이상의 Top-level컴포넌트가 존재한다.
• 프로젝트 규모에 비해 너무 복잡하다는 것을 의미한다. 프로젝트의 규모에 따라 컴포넌트의 Size는 달라질 수 있으나, 대체로 중/소규모 이하의 개발 프로젝트에서 컴포넌트는 Tier/Layer구분정도로 이해 할 수 있으며, 대형(100억이상) 프로젝트에서는 연동되고 있는 개별 시스템(CRM, 인사, 생상등등)이 될 수도 있다
• 하나의 요구사항이 남은 디자인 전체를 결정한다.( 또는 요구사항이 결정되어야 디자인이 진행)
• 아키텍쳐가 O/S선택에 의존적이다.
• 컴포넌트 정의가 하드웨어 구성에서 유도되었다.
• 시스템의 신뢰성에 도움이 되지않는 필요 없는 아키텍쳐 요소 존재하고 있다.
• 디자인이 예외사항에 기초하고 있다.(exception driven)
• 개발팀이 자신을 리딩하는 아키텍트를 모르거나 존재하지 않는다.
• Architect 혹은 PM이 아키텍쳐를 위한 관련당사자(stakeholder)를 정의하지 못한다.
• 개발자가 두개의 컴포넌트를 연결하는데 너무 많은 선택을 가지고 있다.
• 아키텍쳐 산출물을 요구했을 때 클래스 Diagram만을 가져 온다.
• 아키텍쳐 산출물을 요구했을 때 엄청난 양의 자동 생성된 문서들을 들고 온다.
• 관련 당사자(stakeholder)가 명확하게 정의되지 않았다.
• 업무 전문가가 Team내에 없다.
• 프로젝트에 PM/leader가 없다.
• 프로젝트 plan/schedule이 없다
• 프로그램 배포일자가 비현실적이다.
• 성공여부를 측정할 뭔가가 정의될 필요가 있다.
• S/W Architect가 없다.
• 각 영역(layer)을 위해Architect가 있는데, 전체 아키텍쳐를 총괄하는 Architect가 없다.
• 전체 아키텍쳐에 대한 계획이 문서화되지 않았다
• 기반시스템(H/W, OS..) 설치 계획이 명확하지 않다.
• 품질을 담당하는 조직이 없다
• 시스템 테스트 계획이 수립되지 않았다.
• End User가 만족하는 성능 목표가 없다
• 성능 데이터가 수집되지 않았다 (레거시, 유사 싸이트)
• 시스템 부하(traffic)에 대한 예상치가 없다
• Transaction 응답 시간이나 처리량에 대한 측정 메커니즘이 없다
• H/W Capacity에 대한 확신이 없다

1.1 가설기반 문제해결

성능 문제를 해결하기 위해서는 현상을 수집하고 그것을 기반으로 가설을 수립하며 이것을 검증하는 과정을 반복함으로써 해결될 수 있다.

해결해야 할 문제가 발생하면 먼저 현상/Fact를 수집한다. 각종 현상들 로그 기록들 혹은 테스트결과들은 모두 팩트로 정리될 수 있다. 팩트는 가능한 풍부하고 정확해야 문제 해결을 빠르게할 수 있다.

그 다음에는 수집된 팩트를 기반으로 가설을 수립한다. 의미 있는 가설 수립을 위해서는 튜너의경험과 지식이 요구된다. 가설을 최종적으로 해결해야 할 문제의 원인을 해결하거나 해결에 도움이 되어야 한다. 검증되어도 문제를 풀어가는데 도움이 않되는 가설은 검증할 필요가 없다.

주의)가설은 팩트가 아니다 즉 검증되기 전까지는 가설일 뿐이다. 만약 관리자나 고객에게 가설이 팩트 처럼 전달된다면 튜닝은 엉뚱한 방향으로 진행되거나 큰 위협에 빠질 수 있다. 즉 튜너는 문제해결 능력을 심각하게 의심받게 된다.

검증은 가설로부터 추정되는 이미 발생한 다른 현상을 찾아내거나 재현함으로써 가능하다. 검증은 문제 해결에서 가장 시간이 많이 소요되며 가설 수립과 마찬가지로 경험과 지식이 필요하다. 하나의 가설로부터 추정될 수 있는 현상들은 여러 가지일 수 있으며 이러한 현상을 많이 생각해 낼수록 검증 시간은 단축될 수 있다.

검증된 가설은 새로운 팩트로 편입된다. 가설이 FACT로 확정되면 이를 기반한 새로운 현상들도 유추될 수 있으며, 새로운 가설 수립을 위한 Input으로 활용된다.

이렇게 현상/팩트->가설->검증을 반복해 감으로써 최종적으로 문제의 근본원인을 찾아간다.

1.2 RR다이어그램

그런데 해결해야 할 문제가 한가지가 아닌 경우가 많고 포괄적인 경우에는 근본 원인 또한 한가지가 아니고 여러 가지가 존재할 수 있다. 이때는 모든 문제를 해결하였는지를 증명할 필요가발생하게 되는데 이때 사용하는 툴이 RR(Reason and Result)다이어그램[1]이다 RR다이어그램은 원인과 결과의 주종관계를 도식화하는 것이다.

먼저 REASON과 RESULT은 증명된 가설에서 도출된다. 예를 들어 “IIOP 통신 때문에 CPU사용량이 높다”라면 “IIOP 통신”는 REASON이되고 “CPU 사용량이 높다” 라는 것은 RESULT가 된다.

 검증된 가설들이 RR다이어그램으로 도식화되고 나면 그 다음에는 수집된 다른 현상들을 RR다이어그램에 추가하여 주종관계를 연결한다.

RR다이어그램에서 “결과 A” 처럼 어떠한 결과는 다른 결과를 유도하는 원인으로써 역할을 할수도 있다. 그래서 모든 현상들은 원인으로부터 유도되어야 한다.

그런데 “현상D”처럼 어떠한 REASON도 연결되지 않은 RESULT가 존재하는 경우가 있는데 그것은 아직 해결하지 못한 문제가 존재한다는 것을 의미한다. 더 많은 노력을 통해 “원인 Y”를 찾아야 한다.

RR다이어그램은 복잡한 문제의 현상과 결과들에 대한 상관관계들을 도식화 함으로써 이해당사자들이 문제의 원인과 결과를 쉽게 공유할 수 있게 한다.