KR101905268B1 - 관점 지향 프로그래밍을 활용한 아키텍처 기반의 통합 결함 검출 방법 및 시스템 그리고 도구 - Google Patents

Abstract

관점 지향 프로그래밍을 활용한 아키텍처 기반의 통합 결함 검출 방법 및 시스템 그리고 도구가 개시된다. 컴퓨터에 의해 실행되는 아키텍처 기반의 통합 결함 검출 방법에 있어서, 아키텍처(architecture) 명세서로부터 일반 시험 아키텍처를 도출하는 단계, 상기 일반 시험 아키텍처에 기초하여 아키텍처를 구성하는 복수의 컴포넌트들 간의 주요 상호작용을 분석하는 단계, 분석된 상기 주요 상호작용을 대상으로, 통합 결함 검출에 이용하기 위한 관찰점 및 관찰제어점의 위치와 개수를 결정하는 단계, 상기 관찰점 및 관찰제어점의 위치와 개수를 기초로 관점 지향 프로그래밍을 이용하여 관찰점 및 관찰제어점을 구현하는 단계, 구현된 상기 관찰점 및 관찰제어점을 대상으로 통합 시험을 수행하는 단계, 및 상기 통합 시험 수행을 통해 생성된 로그 정보를 분석 및 필터링하는 단계를 포함할 수 있다.

Description

관점 지향 프로그래밍을 활용한 아키텍처 기반의 통합 결함 검출 방법 및 시스템 그리고 도구{METHOD AND SYSTEM FOR DETECTING INTEGRATION DEFECT BASED ON ARCHITECTURE USING ASPECT ORIENTED PROGRAMMING}

본 발명의 실시예들은 소프트웨어 시스템에서 컴포넌트들 간 상호작용 중에 관찰되는 통합 결함(Integration Defect) 검출 방법에 관한 것으로서, 더욱 상세하게는 통합 결함으로 인하여 컴포넌트들 간의 상호작용 중에 관찰되는 이상 상태가 발생하여 의도된 기능을 수행하지 못하도록 하는 소프트웨어 장애를 방지하기 위해 컴포넌트들 간의 컴포넌트들 간의 상호작용 상의 메시지 교환을 모니터링하여 통합 결함을 검출하는 기술에 관한 것이다.

관점 지향 프로그래밍(Aspect-Oriented Programming, AOP) 기법은 Gregor Kiczales가 1996년에 제록스(Xerox)의 자회사인 Palo Alto Research Center(PARC)와 Northeastern 대학의 연구진들과 함께 미국의 국방고등연구소(Defense Advanced Research Projects Agency)의 자금 지원을 받아 처음 제안하였다. 아래의 비특허 문헌 [1] [Kiczales 1996]에 제시된 바와 같이, 관점 지향 프로그래밍은 메인 프로그램의 비즈니스 로직으로부터 2차적 또는 보조 기능들을 분리시키는 새로운 개발 패러다임이다. 이처럼 관점 지향 프로그래밍은 객체 지향 프로그래밍을 잇는 새로운 프로그래밍 방법론으로, 그 우수성을 인정받아 제 14회 Jolt상을 수상한 바 있으며, MIT 에서 선정한 10대 기술에서도 선정되기도 하였다. 현재 Java 언어를 필두로 C, C++, Ruby 등의 관점 지향 프로그래밍을 지원하는 언어 및 적용 기법들이 많은 기업 또는 연구소에서 활발히 진행되고 있다.

관점 지향 프로그래밍은 객체 지향 프로그래밍을 포함한 여타 프로그래밍 방법론에서는 모듈을 관심사 또는 단순히 기능 단위로 나누어 일차원적으로 구현하던 것과 별개로, 이들과 독립적으로 다차원적으로 구현한다. 기존의 프로그래밍에서 모듈화 하지 못하던 것들을 기존 시스템에 대한 변경없이 다차원적으로 모듈화 해주는 것으로, 이를 횡단관심사(Separation of Concerns)라 하여 관심사의 분리를 허용함으로써 대상 시스템의 모듈성을 증가시켜준다. 이러한 관점 지향 프로그래밍은 프로그램을 명확한 부분으로 나누는 것을 수반한다. 모든 프로그래밍 패러다임은 이들 관심사들을 구현, 추상화, 구성하는 추상적 개념을 제공하는 분리되고, 독립적인 통로들을 통해 그룹핑(Grouping)의 같은 레벨과 관심사들의 캡슐화(Encapsulation)를 지원한다. 그러나 어떤 관심사들은 구현의 이런 형태를 거역하고, 이들이 프로그램 내에서 다중 추상적 개념들에 영향을 끼치기 때문에 횡단관심사(cross-cutting concerns)라고 불린다. 이를 위해 관점 지향 프로그래밍은 결함점(Join point), 교차점(pointcut), 충고(advice), 도입(introduction), 관점(aspect) 등의 개념과 구성물로 이뤄져 있다.

최근 들어, 기업에서 관점 지향 프로그래밍을 자사 소프트웨어 개발 및 유지보수 관점에서 활용 사례들이 폭발적으로 늘어나고 있으며, 그 대표적인 예로는 IBM 사가 있다. 2004 년도에 IBM에서 발표한 자료에 의하면 IBM은 관점 지향 프로그래밍 기법을 자사의 애플리케이션 서버인 웹스피어(Websphere)에 적용하였으며, 대표적인 횡단 관심사(cross-cutting)인 로깅, 트레이싱, FFDC(First Failure Data Capture, 장애가 발생한 가장 가까운 곳에서 관련 자료 수집), 정책 시행(좋은 관행을 사용하게 하는)에 적용하여 품질과 서비스의 향상을 보였다.

예를 들어, FFDC에 적용한 경우, 기존 110개의 소스 모듈에 산재(tangling)되어 있던 FFDC 기능을 한 개의 관점(Aspect)로 모듈화하였다. 이 관점이 241개의 캐치(catch) 블록에 적용되었다. 결과, 기존의 웹스피어(Websphere)의 관리 컴포넌트에 존재하던 355개의 에러가 수정되었으며, 웹스피어(Websphere)의 실행 컴포넌트에 존재하던 17% 이상의 에러가 수정되었다.

또한 웹스피어(Websphere)에서 EJB(Enterprise Java Bean) 컴포넌트를 분리해내는 리팩토링(refactoring)을 성공적으로 수행하였는 데, 이는 웹스피어(Websphere)를 빌드할 때 한 개의 비트 값에 따라 EJB 컴포넌트를 포함한 웹스피어(Websphere) 또는 EJB를 포함하지 않는 웹스피어(Websphere)를 제작할 수 있다는 것을 의미한다. 고객이 EJB를 전혀 사용하지 않는다면 EJB가 없는 웹스피어(Websphere)를 설치하면 된다. 이렇게 독립적으로 분리된 EJB는 웹스피어(Websphere)뿐만 아니라 다른 소프트웨어에 쉽게 포함시킬 수 있어 코드 재사용을 증진할 수 있으며 독립적으로 개발 및 발전시키기 위해 이용될 수 있다. 다음과 같은 관점 지향 프로그래밍 기법의 적용 사례의 긍정적인 효과로 인해 IBM 사는 자사의 주요한 소프트웨어(예를 들면 Tivolti, DB2, Rational, Lotus 등)에 확대 적용하고 있다.

IBM 에서의 대표적인 관점 지향 프로그래밍의 적용 성공 사례에서 보듯이 여러 기업에서도 이 기법에 대한 이해와 채택의 단계를 거쳐 소프트웨어 품질 향상 및 제품 리엔지어링 단계의 성공을 거두고 앞으로 소프트웨어 엔지니어링 자체를 리엔지니어링하며 나아가 신제품군 개발에 이를 적용해나가는 추세이다. 현재 IBM 사를 포함 여러 소프트웨어 개발 기업들의 개발자들이 회사의 요구나 설득에 의해서가 아니고 관점 지향 프로그래밍의 혜택을 입은 개발자들이 자발적으로 관점 지향 프로그래밍을 사용하여 소프트웨어 개발 및 유지보수 활동에 적용하고 있다.

현재 관점 지향 프로그래밍 기법은 2002년도 이후로 Eclipse로 이양되어 현재까지 여러 학계 및 기업에서 적용해가면서 유지 보수되며 관리되고 있지만, 가지고 있는 진보성과 그 확장성 에 비해 그 적용 및 활용 사례가 미비한 상태이다.

소프트웨어 아키텍처(Software Architecture)는 IEEE 표준(IEEE 1471)에 의하면 "시스템의 근본적인 조직 형태로 그것은 구성 컴포넌트들과, 그들 서로의 관계와 환경과의 관계 그리고 그 설계와 진화를 관장하는 원칙들로 실체화되어 있다". 소프트웨어 아키텍처는 이해관계자들의 관심사에 따라 여러 관점들로 표현이 되는데, 크게 실행측면과 코드측면으로 구분되며 이는 추상화 수준에 따라 개념적, 논리적, 물리적, 배치 수준으로 나누어 구분된다.

소프트웨어 아키텍처는 소프트웨어의 품질들을 검증하는데 결정적이고, 커넥터의 구분을 통해 아키텍처 수준에서의 재사용성을 극대화하도록 도와준다. 소프트웨어 아키텍처는 아래의 비특허문헌 [2] Clements 2010에 제시된 바와 같이, 일반적으로 컴포넌트와 커넥터로 구성이 된다. 아래의 비특허 문헌 [3] [Hofmeister 2000], [4] [Taylor 2010], [5] [Rozanski 2011] 및 [6] [Bass 2013] 에서 제시된 바와 같이, 소프트웨어 아키텍처에서 컴포넌트(component)는 주요한 기능(functionality, responsibility)을 수행(processing)하는 단위(units) 그리고/또는 (관련된) 데이터를 저장하는 단위를 의미한다.

코드 측면 아키텍처의 경우에는 주로 시스템을 구현 가능하고 재사용성이 높게 하위 시스템들로 분할하고 기능적 요구사항들을 수행하는 단위(예, 기능, 서브 시스템, 계층)나 작업 분할의 기반이 되는 수준의 모듈(예, 폴더, 패키지, 파일, 클래스, 인터페이스, 메소드) 또는 가장 낮은 추상화 수준으로 소스, 바이너리, 실행파일, 구성파일, 코드 그룹 등이 컴포넌트가 되고, 그들간의 관계로 데이터 흐름, 사용관계, 포함관계, 인터페이스 제공/요구 관계가 커넥터로써 코드 측면 아키텍처 관계 요소(즉, 컴포넌트)가 된다

그리고, 실행 측면 아키텍처의 경우에는 주로 실행 시의 인스턴스들(예컨대, 오브젝트(object), 스래드(thread), 프로세스(process), 클라이언트(client), 서버(server) 등)이 컴포넌트가 되고, 아래의 비특허문헌 [4] [Taylor 2010]에 따르면, 커넥터(connector)는 컴포넌트들 사이의 제어(control) 그리고/또는 데이터(data)를 전송(transfer)하는 아키텍처 요소를 의미한다. 좁은 의미로는 프로시져 콜(Procedure call)에서부터 넓은 의미로는 컴포넌트와 커넥터의 조합으로 구성된 시설 컴포넌트(Facilitate component)까지 포함한다.

기존의 통합 결함 검출 방법은 실행 측면 아키텍처의 시나리오 관점으로 순차도(Sequence Diagram), 커뮤니케이션 다이어그램(Communication Diagram) 또는 상태 머신 다이어그램(State-machine Diagram)을 기반으로 수행된다. 이에 따라, 기존의 통합 결함 검출 방법은 특정 시나리오의 실행 측면에서 노출된 컴포넌트들 간의 상호작용만을 중심으로 시험 항목을 작성하는 방법으로 통합 오류 검출 방법을 수행하기 때문에, 통합 오류의 원인인 통함 결함을 찾기 위해서는 시험 대상 시스템의 규모가 크고 통합된 컴포넌트들의 수가 커질수록 비례하여 필요한 노력과 시간이 증가한다.

또한, 기존의 아키텍처 기반의 시험 방법들의 경우, 대부분 명시된 요구사항에 대해서 구현된 시스템이 의도대로 구현되었는지 확인하는 일치성(Conformance) 확인 목적으로 수행되고 있다. 즉, 결함 검출보다는 의도한 요구사항들 및 아키텍처가 구현과의 일치를 확인하는 것에 집중하였기 때문에, 효율적인 통합 오류 및 결함 검출율을 달성하지 못한다. 또한 기존의 아키텍처 기반의 시험 방법들은 통합된 모듈들 혹은 전체 시스템을 대상으로 하는 통합 시험 특성상, 통합 오류 검출 후에 오류를 수정하기 위한 원인 분석과 결함 위치를 찾는 노력이 더 요구됨에도 이에 대한 방법 제시가 없다. 즉, 관찰된 통합 오류의 원인 검출을 위해서 아키텍처 정보가 중요한 역학을 할 수 있음에도 현재까지는 이를 쉽게 활용할 수 있는 체계적이고 구체적인 방법이 제시되고 있지 않다.

또한, 통합 오류 원인 분석을 위한 컴포넌트들 간의 정보 관찰 및 제어 장치 구현에 대항 시험 시스템 코드의 변조 등과 같은 많은 노력과 시간이 필요한 어려움이 존재한다.

따라서, 시험자에게 기존 코드 및 로직의 변조 등을 통해 통합 결함을 찾는 등의 노력과 시간을 낭비하지 않고, 아키텍처 정보를 이용하여 통합 결함을 검출하는 체계적이고 구체적인 방법을 제시하는 기술이 요구되고 있다. 한국공개특허 제10-2011-0088958호는 소프트웨어에서의 상호작용 패턴을 이용한 결함 검출 방법을 제시하고 있다.

[1] [Kiczales 1996] G., Kiczales, Aspect-oriented programming. ACM Computing Surveys (CSUR), 28(4es), 154, 1996. [2] [Clements 2010] P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, P. Merson, R. Nord, J. Stafford, Documenting Software Architecture: Views and Beyond, 2nd Edition. Addison-Wesley. [3] [Hofmeister 2000] C. Hofmeister, R. Nord, D. Soni, Applied Software Architecture. Addison-Wesley Professional, 2000. [4] [Taylor 2010] R. N. Taylor, N. Medividovic, E. M. Dashofy. Software Architecture: Foundations, Theory, and Practice. Wiley, 2010. [5] [Rozanski 2011] N. Rozanski and E. Woods. Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives, 2nd Edition. Addison-Wesley Professional, 2011. [6] [Bass 2013] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice. Addison-Wesley, 2013.

본 발명은 상기한 문제점들을 해결하기 위한 것으로서, 기존에 명세된 아키텍처 정보를 기반으로 분석하여 도출되는 시험 아키텍처를 정의하고, 높은 통합 오류 검출율과 빠른 통합 결함 검출율 달성을 위한 관찰점 및 관찰제어점의 위치 후보군을 제시하고, 관찰점 및 관찰제어점을 관점 지향 프로그래밍을 이용하여 대상 시험 시스템 코드의 기존 내부 로직을 변조하지 않고도 쉽게 구현하는 기술에 관한 것이다.

또한, 통합 시험 수행 후 관찰점 및 관찰제어점으로부터 발생한 메시지 교환 정보를 분석 및 필터링해줌으로써, 보다 많은 통합 오류 검출과 보다 빠른 통합 결함 검출을 수행하는 기술에 관한 것이다.

컴퓨터에 의해 실행되는 아키텍처 기반의 통합 결함 검출 방법에 있어서, 아키텍처(architecture) 명세서로부터 일반 시험 아키텍처를 도출하는 단계, 상기 일반 시험 아키텍처에 기초하여 아키텍처를 구성하는 복수의 컴포넌트들 간의 주요 상호작용을 분석하는 단계, 분석된 상기 주요 상호작용을 대상으로, 통합 결함 검출에 이용하기 위한 관찰점 및 관찰제어점의 위치와 개수를 결정하는 단계, 상기 관찰점 및 관찰제어점의 위치와 개수를 기초로 관점 지향 프로그래밍을 이용하여 관찰점 및 관찰제어점을 구현하는 단계, 구현된 상기 관찰점 및 관찰제어점을 대상으로 통합 시험을 수행하는 단계, 및 상기 통합 시험 수행을 통해 생성된 로그 정보를 분석 및 필터링하는 단계를 포함할 수 있다.

일측면에 따르면, 상기 통합 시험을 수행하는 단계는, 상기 관찰점 및 관찰제어점으로부터 메시지 교환정보를 관찰 및 제어하는 통합 시험을 수행할 수 있다.

다른 측면에 따르면, 상기 로그 정보를 분석 및 필터링하는 단계는, 상기 관찰점 및 관찰제어점으로부터 로그된 메시지 교환 정보를 분석하여 필터링을 수행할 수 있다.

또 다른 측면에 따르면, 결정된 상기 관찰점 및 관찰제어점의 위치와 개수에 기초하여 해당 관찰점 및 관찰제어점을 상기 일반 시험 아키텍처에 추가함으로써 상세 시험 아키텍처로 도출하는 단계를 더 포함할 수 있다.

또 다른 측면에 따르면, 상기 상세 시험 아키텍처는, 상기 관점 지향 프로그래밍을 이용하여 통합 결함을 검출하기 위한 시험 아키텍처를 나타낼 수 있다.

또 다른 측면에 따르면, 상기 통합 시험을 수행하는 단계는, 상기 관찰점 및 관찰제어점을 미리 준비된 통합 시험 항목들과 함께 통합 시험을 수행할 수 있다.

또 다른 측면에 따르면, 상기 통합 시험을 수행하는 단계는, 상기 통합 시험 항목들 각각을 수행하면서 생성된 로그(log) 정보를 기록하는 단계

를 포함하는 것을 특징으로 하는 아키텍처 기반의 통합 결함 검출 방법.

컴퓨터로 구현되는 통합 결함 검출 시스템에 있어서, 상기 컴퓨터에서 판독 가능한 명령을 실행하도록 구현되는 적어도 하나의 프로세서를 포함하고, 상기 적어도 하나의 프로세서는, 아키텍처(architecture) 명세서로부터 일반 시험 아키텍처를 도출하고, 도출된 일반 시험 아키텍처에 기초하여 아키텍처를 구성하는 복수의 컴포넌트들 간의 주요 상호작용을 분석하는 아키텍처 명세 분석부, 분석된 상기 주요 상호작용을 대상으로, 통합 결함 검출에 이용하기 위한 관찰점 및 관찰제어점의 위치와 개수를 결정하고, 결정된 관찰점 및 관찰제어점의 위치와 개수를 기초로 관점 지향 프로그래밍을 이용하여 관찰점 및 관찰제어점을 구현하는 관찰점 및 관찰제어점 구현부, 구현된 상기 관찰점 및 관찰제어점을 대상으로 통합 시험을 수행하는 통합 시험 수행부, 상기 통합 시험 수행을 통해 생성된 로그 정보를 분석하는 구문 분석부, 및 분석된 로그 정보를 필터링하는 필터링부를 포함할 수 있다.

일측면에 따르면, 상기 통합 시험 수행부는, 상기 관찰점 및 관찰제어점으로부터 메시지 교환정보를 관찰 및 제어하는 통합 시험을 수행할 수 있다.

다른 측면에 따르면, 상기 구문 분석부는, 상기 관찰점 및 관찰제어점으로부터 로그된 메시지 교환 정보를 분석할 수 있다.

또 다른 측면에 따르면, 상기 관찰점 및 관찰제어점 구현부는, 결정된 상기 관찰점 및 관찰제어점의 위치와 개수에 기초하여 해당 관찰점 및 관찰제어점을 상기 일반 시험 아키텍처에 추가함으로써 상세 시험 아키텍처로 도출할 수 있다.

또 다른 측면에 따르면, 상기 상세 시험 아키텍처는, 상기 관점 지향 프로그래밍을 이용하여 통합 결함을 검출하기 위한 시험 아키텍처를 나타낼 수 있다.

또 다른 측면에 따르면, 상기 통합 시험 수행부는, 상기 관찰점 및 관찰제어점을 미리 준비된 통합 시험 항목들과 함께 통합 시험을 수행할 수 있다.

또 다른 측면에 따르면, 상기 통합 시험 수행부는, 상기 통합 시험 항목들 각각을 수행하면서 생성된 로그(log) 정보를 기록할 수 있다.

또 다른 측면에 따르면, 필터링된 상기 로그 정보를 텍스트 트리뷰 또는 그래프 뷰 형태로 제공하기 위한 시각처리를 수행하는 시각 처리부를 더 포함할 수 있다.

본 발명은 기존에 명세된 아키텍처 정보를 기반으로 분석하여 도출되는 시험 아키텍처를 정의하고, 높은 통합 오류 검출율과 빠른 통합 결함 검출율 달성을 위한 관찰점 및 관찰제어점의 위치 후보군을 제시하고, 관찰점 및 관찰제어점을 관점 지향 프로그래밍을 이용하여 대상 시험 시스템 코드의 기존 내부 로직을 변조하지 않고도 쉽게 구현할 수 있다.

또한, 아키텍처 기반의 통합 결함 검출 방법이 실현되면, 통합 시험 수행 후 관찰점 및 관찰제어점으로부터 발생한 메시지 교환 정보를 분석 및 필터링해줌으로써, 보다 적은 시간과 노력으로 원하는 컴포넌트 간의 메시지 교환을 관찰하거나 제어할 수 있기 때문에, 기존의 요구사항 및 코드 중심의 통합 결함 검출 방법에 비해 보다 높은 통합 오류 검출율과 보다 빠른 통합 결함 검출율을 제공할 수 있다.

도 1은 본 발명의 일실시예에 있어서, 아키텍처 기반의 통합 결함 검출 방법을 설명하는 흐름도이다.
도 2는 본 발명의 일실시예에 있어서, 통합 결함 검출 시스템의 내부 구성을 도시한 블록도이다.
도 3은 본 발명의 일실시예에 있어서, 도 2의 시험 아키텍처 도출부 및 통합 시험 로그 분석 도구부의 상세 구성을 도시한 블록도이다.
도 4는 본 발명의 일실시예에 있어서, 관점 지향 프로그래밍을 이용하여 아키텍처 기반의 결함 검출 방법을 개념적으로 도식화한 도면이다.
도 5는 본 발명의 일실시예에 있어서, 아키텍처 기반의 통합 결함 검출을 수행하는 시스템의 네트워크 환경을 도시한 도면이다.
도 6은 본 발명의 일실시예에 있어서, 아키텍처의 명세 정보를 분석하는 과정을 설명하기 위해 제공되는 도면이다.
도 7은 본 발명의 일실시예에 있어서, 상세시험 아키텍처의 예시를 도시한 도면이다.
도 8은 본 발명의 일실시예에 있어서, 관찰점 및 관찰제어점이 구현되는 예를 도시한 도면이다.
도 9는 본 발명의 일실시예에 있어서, 통합 시험을 수행함에 따라 발생하는 로그 정보의 예를 도시한 도면이다.
도 10은 본 발명의 일실시예에 있어서, 로그 정보를 필터링 룰에 따라 그래프 형태로 필터링하는 통합 시험 로그 분석 도구부에서 제공하는 도구 화면의 예시도이다.
도 11은 본 발명의 일실시예에 있어서, 필터링된 로그 정보를 시각화하여 제공하는 도구 화면의 예를 도시한 도면이다.

이하, 본 발명의 실시예를 첨부된 도면을 참조하여 상세하게 설명한다.

본 실시예들은 통합 결함(Integration Defect)으로 인해 발생하는 소프트웨어 장애를 방지하기 위해, 컴포넌트들(components) 간의 상호작용 상의 메시지 교환을 관점 지향 프로그래밍(AOP)을 이용하여 쉽게 모니터링하거나 제어함으로써, 통합 결함의 위치를 검출하는 기술에 관한 것이다. 여기서, 소프트웨어 장애는 통합 결함(Integration Defect)으로 인하여 컴포넌트들 간의 상호작용 중에 관찰되는 이상 상태가 발생하여 의도된 기능을 수행하지 못하도록 하는 장애를 나타낼 수 있다.

본 실시예들에서, 아키텍처를 구성하는 컴포넌트는, 아키텍처 요소로 표현될 수 있다. 그리고, 아키텍처에서의 컴포넌트(component)는 주요한 기능(functionality, responsibility)을 수행(processing)하는 단위(units) 그리고/또는 (관련된) 데이터를 저장하는 단위를 의미할 수 있다. 여기서, 주요 기능은, 시험하고자 하는 시스템의 주요 기능 요구 사항을 의미하는 것으로서, 예를 들어, 시험하고자 하는 시스템이 ATM 시스템인 경우, 주요 기능은 입금, 출금, 이체 기능 등을 포함할 수 있다. 예컨대, 도 7에서, CATM 컴포넌트가 주요한 기능을 수행하는 단위로 구성될 수 있다.

본 실시예들에서, 일반 시험 아키텍처는 관찰제어점 및 관찰점의 구현 가능 후보 위치군이 시험 대상 시스템 아키텍처 상에 설계되어 시험자 컴포넌트와의 관계만이 표시된 아키텍처를 의미하는 것으로서, 시험 오라클(oracle), 시험 항목들로 구성된 시험자 컴포넌트(tester component), 시험 대상 시스템의 컴포넌트들, 상기 컴포넌트들 간의 관계(예컨대, 상호작용 채널), 그리고 시험자 컴포넌트와 상호작용 채널 간의 관계로 구성될 수 있다.

본 실시예들에서, 상세 시험 아키텍처는, 시험자 컴포넌트와의 관계만이 표시된 아키테처에서 시험 컴포넌트들을 시험자가 시험 목적 등을 고려하여 관찰제어점 및 관찰점의 수와 종류를 결정하여, 선택된 관찰제어점 및 관찰점만이 남은 아키텍처를 의미할 수 있다.

도 1은 본 발명의 일실시예에 있어서, 아키텍처 기반의 통합 결함 검출 방법을 설명하는 흐름도이고, 도 2는 본 발명의 일실시예에 있어서, 통합 결함 검출 시스템의 내부 구성을 도시한 블록도이다.

본 실시예에 따른 통합 결함 검출 시스템(200)은 프로세서(210), 버스(220), 네트워크 인터페이스(230), 메모리(240) 및 데이터베이스(250)를 포함할 수 있다. 메모리(240)는 운영체제(241) 및 통합 결함 검출 루틴(242)를 포함할 수 있다. 프로세서(210)는 시험 아키텍처 도출부(211) 및 통합 시험 로그 분석 도구부(212)를 포함할 수 있다. 다른 실시예들에서 통합 결함 검출 시스템(200)은 도 2의 구성요소들보다 더 많은 구성요소들을 포함할 수도 있다. 그러나, 대부분의 종래기술적 구성요소들을 명확하게 도시할 필요성은 없다. 예를 들어, 통합 결함 검출 시스템(200)은 디스플레이나 트랜시버(transceiver)와 같은 다른 구성요소들을 포함할 수도 있다.

메모리(240)는 컴퓨터에서 판독 가능한 기록 매체로서, RAM(random access memory), ROM(read only memory) 및 디스크 드라이브와 같은 비소멸성 대용량 기록장치(permanent mass storage device)를 포함할 수 있다. 또한, 메모리(240)에는 운영체제(241)와 통합 결함 검출 루틴(242)을 위한 프로그램 코드가 저장될 수 있다. 이러한 소프트웨어 구성요소들은 드라이브 메커니즘(drive mechanism, 미도시)을 이용하여 메모리(240)와는 별도의 컴퓨터에서 판독 가능한 기록 매체로부터 로딩될 수 있다. 이러한 별도의 컴퓨터에서 판독 가능한 기록 매체는 플로피 드라이브, 디스크, 테이프, DVD/CD-ROM 드라이브, 메모리 카드 등의 컴퓨터에서 판독 가능한 기록 매체(미도시)를 포함할 수 있다. 다른 실시예에서 소프트웨어 구성요소들은 컴퓨터에서 판독 가능한 기록 매체가 아닌 네트워크 인터페이스(230)를 통해 메모리(240)에 로딩될 수도 있다.

버스(220)는 통합 결함 검출 시스템(200)의 구성요소들 간의 통신 및 데이터 전송을 가능하게 할 수 있다. 버스(220)는 고속 시리얼 버스(high-speed serial bus), 병렬 버스(parallel bus), SAN(Storage Area Network) 및/또는 다른 적절한 통신 기술을 이용하여 구성될 수 있다.

네트워크 인터페이스(230)는 통합 결함 검출 시스템(200)을 컴퓨터 네트워크에 연결하기 위한 컴퓨터 하드웨어 구성요소일 수 있다. 네트워크 인터페이스(230)는 통합 결함 검출 시스템(200)을 무선 또는 유선 커넥션을 통해 컴퓨터 네트워크에 연결시킬 수 있다.

데이터베이스(250)는 아키텍처 명세 정보, 시험 항목, 시험 대상 시스템의 소스 코드들을 저장 및 유지하는 역할을 할 수 있다. 도 2에서는 통합 결함 검출 시스템(200)의 내부에 데이터베이스(250)를 구축하여 포함하는 것으로 도시하고 있으나, 이에 한정되는 것은 아니며 시스템 구현 방식이나 환경 등에 따라 생략될 수 있고 혹은 전체 또는 일부의 데이터베이스가 별개의 다른 시스템 상에 구축된 외부 데이터베이스로서 존재하는 것 또한 가능하다. 예컨대, 아키텍처 명세 정보, 시험 항목, 시험 대상 시스템의 소스 코드 각각은 별개의 데이터베이스로 구축될 수도 있다.

프로세서(210)는 기본적인 산술, 로직 및 통합 결함 검출 시스템(200)의 입출력 연산을 수행함으로써, 컴퓨터 프로그램의 명령을 처리하도록 구성될 수 있다. 명령은 메모리(240) 또는 네트워크 인터페이스(230)에 의해, 그리고 버스(220)를 통해 프로세서(210)로 제공될 수 있다. 프로세서(210)는 등록부(211)와 인식부(212) 및 제공부(213)를 위한 프로그램 코드를 실행하도록 구성될 수 있다. 이러한 프로그램 코드는 메모리(240)와 같은 기록 장치에 저장될 수 있다.

시험 아키텍처 도출부(211) 및 통합 시험 로그 분석 도구부(212)는 도 1의 단계들(110 내지 160 단계)을 수행하기 위해 구성될 수 있다.

110 단계에서, 시험 아키텍처 도출부(211)는 아키텍처 명세서로부터 일반 시험 아키텍처를 도출할 수 있다. 즉, 시험 아키텍처 도출부(211)는 데이터베이스(250)에 미리 저장된 아키텍처 명세 정보로부터 일반 시험 아키텍처를 도출할 수 있다.

120 단계에서, 시험 아키텍처 도출부(211)는 일반 시험 아키텍처에 기초하여 아키텍처를 구성하는 복수의 컴포넌트들(components) 간의 주요 상호작용을 분석할 수 있다. 예컨대, 시험 아키텍처 도출부(211)는 일반 시험 아키텍처를 대상으로, 통합 결함을 관찰 또는 제어하기 위해 이용되는 관찰점 및 관찰제어점을 구현하기 위한 분석을 수행할 수 있다.

130 단계에서, 시험 아키텍처 도출부(211)는 통합 결함 검출을 위한 관찰점 및 관찰제어점의 위치 및 개수를 결정할 수 있다.

예컨대, 시험 아키텍처 도출부(211)는 도출된 일반 시험 아키텍처의 명세서로부터 아키텍처 요소(즉, 컴포넌트들) 간의 상호작용들 중 주요 상호작용을 선택할 수 있다. 여기서, 주요 상호작용은 시험자가 선택할 수도 있다. 그러면, 시험 아키텍처 도출부(211)는 선택된 주요 상호작용들을 분석하고, 분석된 주요 상호작용들 중에 통합 결함 검출을 위해 상호작용의 메시지 교환을 관찰 또는 제어를 수행할 관찰점 및 관찰제어점의 위치와 개수를 결정할 수 있다. 여기서, 관찰점 및 관찰제어점을 구현할 위치와 개수를 선택하는 자세한 동작은 도 7에서 후술하기로 한다.

140 단계에서, 시험 아키텍처 도출부(211)는 일반 시험 아키텍처와 상기 관찰점 및 관찰제어점의 위치와 개수에 기초하여 상세시험 아키텍처를 도출할 수 있다. 여기서, 상세시험 아키텍처는 실질적으로 관점 지향 프로그래밍으로 구현될 통합 결함 검출을 위한 시험 아키텍처를 나타낼 수 있다. 즉, 상세시험 아키텍처가 도출됨에 따라 실질적으로 상기 관점 지향 프로그래밍을 이용하여 통합 결함 검출을 위한 시험 아키텍처가 준비될 수 있다.

150 단계에서, 상세시험 아키텍처가 준비됨에 따라, 시험 아키텍처 도출부(211)는 관점 지향 프로그래밍을 이용하여 관찰점 및 관찰제어점을 구현할 수 있다.

예컨대, 시험 아키텍처 도출부(211)는 상세시험 아키텍처를 대상으로 관점 지향 프로그래밍을 이용하여 해당 요소들을 구현할 수 있다. 이때, 관점 지향 프로그래밍을 이용하는 경우, 시험 아키텍처 도출부(211)는 도 8과 같이 컴포넌트들 간의 관계 정보로써 피호출자 관점으로 관찰점 및 관찰제어점을 구현할 수 있다. 그리고, 시험 아키텍처 도출부(211)는 구현된 관찰점 및 관찰제어점에 대한 수행 정보를 로깅(logging)하는 요소로 구현할 수 있다.

160 단계에서, 시험 아키텍처 도출부(211)는 구현된 관찰점 및 관찰제어점에 기초하여 통합 시험을 수행할 수 있다.

161 단계에서, 시험 아키텍처 도출부(211)는 관찰점 및 관찰제어점과 관점 지향 프로그래밍을 이용하여 구현된 관점 지향 프로그래밍 코드와 데이터베이스(250)에 저장된 통합 시험 항목(즉, 시험 항목)을 함께 통합 시험을 수행할 수 있다.

162 단계에서, 시험 아키텍처 도출부(211)는 통합 시험을 수행하면서 생성되는 로그 정보를 기록할 수 있다.

170 단계에서, 통합 시험 로그 분석 도구부(212)는 통합 시험 수행을 통해 생성된 로그 정보를 분석하고, 분석된 로그 정보를 필터링할 수 있다.

171 단계에서, 통합 시험 로그 분석 도구부(212)는 컴포넌트 간의 메시지 교환 정보를 분석할 수 있다. 즉, 통합 시험 수행을 생성된 로그 정보는 컴포넌트들 간의 메시지 교환 정보를 포함할 수 있다. 예컨대, 도 9와 같이, 메시지 교환 정보로서, 메소드(method) 간 파라미터 또는 아규먼트(argument) 정보 등이 이용될 수 있다.

172 단계에서, 통합 시험 로그 분석 도구부(212)는 로그 정보를 통합 시험 항목 별로, 관찰점 및 관찰제어점 별로, 그리고 아키텍처 관계 정보 별로 필터링할 수 있다. 기록된 로그 정보는 시험자가 쉽게 읽을 수 없는 정보이므로, 통합 시험 로그 분석 도구부(212)는 상기 로그 정보를 시험자가 읽을 수 있는 정보의 형태로 제공하기 위해, 통합 시험 항목 별로, 관찰점 및 관찰제어점 별로, 그리고 아키텍처 관계 정보 별로 필터링할 수 있다. 예를 들어, 아키텍처 관계 정보는 아키텍처를 구성하는 컴포넌트들 간의 관계 정보(즉, 커넥터 정보)로서, 컴포넌트들 간의 데이터 흐름 정보, 사용 관계, 포함 관계, 인터페이스 제공, 요구 관계, 의존 관계, 상속 관계 등을 포함할 수 있다.

이처럼, 로그 정보가 분석되어 필터링되면, 필터링된 로그 정보들은 텍스트 트리뷰(text treeview) 또는 그래프 뷰(graph view) 형태로 시각 처리되어 시험자에게 제공될 수 있다.

도 3은 본 발명의 일실시예에 있어서, 도 2의 시험 아키텍처 도출부 및 통합 시험 로그 분석 도구부의 상세 구성을 도시한 블록도이다.

도 3을 참고하면, 도 2의 프로세서(210)는 시험 아키텍처 도출부(211, 310), 통합 시험 로그 분석 도구부(212, 320)를 포함할 수 있으며, 시험 아키텍처 도출부(211, 310)는 아키텍처 명세 분석부(311), 관찰점 및 관찰제어점 구현부(312), 그리고 통합 시험 수행부(313)를 포함할 수 있다. 통합 시험 로그 분석 도구부(212, 320)는 구문 분석부(321), 필터링부(322), 및 시각 처리부(323)를 포함할 수 있다.

도 2 및 도 3에서, 통합 결함 검출 방법은 소프트웨어 개발 및 시험을 지원할 수 있는 통합 개발 환경을 기반으로 수행될 수 있으며, 통합 결함 검출을 지원하는 도구인 통합 시험 로그 분석 도구부(212, 320)는 독립적으로 동작하는 프로그램 형태로 구현되거나 혹은 통합 개발 환경의 플러그인(plug-in) 형태로 구성되어 통합 개발 환경과 함께 동작이 가능하도록 구현될 수 있다.

아키텍처 명세 분석부(311)는 시험 대상 시스템의 아키텍처 명세 정보(251, 401)에 따라 아키텍처를 구성하는 컴포넌트와, 컴포넌트들 간의 관계 정보를 나누어 구분하는 작업을 수행할 수 있다. 예를 들어, 아키텍처 명세 분석부(311)는 아키텍처 명세 정보(251)를 대상으로, 컴포넌트 구성 정보와 컴포넌트들 간의 관계 정보인 커넥터 정보를 분리할 수 있다. 여기서, 시험 대상 시스템의 아키텍처 명세 정보는 UML, SysML, SDL, ADL, xADL 등과 같은 아키텍처 명세 기법으로 표현될 수 있다. 그러면, 아키텍처 명세 분석부(311)에서 분리된 커넥터 정보는 통합 시험 수행 시, 통합 결함을 관찰 또는 제어하기 위해 이용되는 관찰점 및 관찰제어점을 구현하기 위한 위치의 후보군이 될 수 있다. 그리고, 컴포넌트 구성 정보는 해당 컴포넌트를 구성하는 하위 컴포넌트들과 하위 컴포넌트들 간의 관계 정보 혹은 하위 컴포넌트들의 추상 수준 정보를 포함할 수 있다. 예를 들어, 시험 대상 시스템의 언어 종류에 따라 컴포넌트 구성 정보는 폴더 및 패키지의 집합, 폴더/패키지, 파일/클래스들의 집합, 파일/클래스 등을 포함할 수 있다.

관찰점 및 관찰제어점 구현부(312)는 아키텍처 명세 분석부(311)에서 분석된 컴포넌트들 간의 상호작용 상에 시험자 목적에 따라 선택된 상호작용의 메시지 교환을 관찰만 할지, 또는 관찰과 함께 메시지 교환값에 수정을 가하는 제어를 수행할지 여부를 결정할 수 있다. 그리고, 관찰점 및 관찰제어점 구현부(312)는 관찰 또는 제어 수행의 결정 여부를 기반으로 관점 지향 프로그래밍을 이용하여 관찰점 또는 관찰제어점으로 나누어 구현할 수 있다. 예를 들어, 관점 지향 프로그래밍은 대상 시스템 구현 언어 또는 환경에 따라 AspectJ, AspectC/C++, SpringAOP 등을 포함할 수 있다.

통합 시험 수행부(313)는 미리 작성되어 저장된 통합 시험 항목(즉, 시험항목, 253)과 관찰점 및 관찰제어점 구현부(312)를 통해 구현된 관점 지향 프로그래밍 코드와 함께 통합 시험을 수행할 수 있다.

예를 들어, 통합 시험 수행부(313)는 통합 시험 항목들이 수행되면서 앞서 정의된 관찰점 및 관찰제어점을 지나는 경우, 해당 구현된 내용에 따라 컴포넌트들 간의 메시지 교환값을 추가, 제거 또는 수정 등을 수행할 수 있다.

통합 시험 로그 분석 도구부(212, 320)는 통합 시험 환경에서 독립적으로 동작하는 프로그램 형태로 구현되거나 혹은 통합 개발 환경의 플러그인(plug-in) 형태로 구성되어 통합 개발 환경과 함께 동작이 가능하도록 구현될 수 있다. 통합 시험 수행부(313)를 통해 발생한 시험 결과와 함께 발생한 관찰점 및 관찰제어점의 로그 정보 그리고 시험 아키텍처 명세 정보를 입력값으로 가질 수 있다.

구문 분석부(321)는 통합 시험 수행부(313)에서 통합 시험을 통해 기록된 로그 정보를 아키텍처 관계 정보 또는 통합 시험 항목 별로 분석할 수 있다.

필터링부(322)는 분석된 로그 정보들을 대상으로, 아키텍처 관계 정보, 관찰점 및 관찰제어점, 그리고 통합 시험 항목 별로 필터링할 수 있다.

시각 처리부(323)는 필터링된 로그 정보들을 텍스트 트리뷰(text treeview) 또는 그래프 뷰(graph view) 형태로 시각화하여 시험자에게 제공할 수 있다. 예컨대, 시험자가 소지한 전자기기의 디스플레이에 시각화된 로그 정보들이 표시될 수 있다. 예컨대, 전자기기는 데스크탑 PC, 노트북 등을 포함할 수 있다.

도 4는 본 발명의 일실시예에 있어서, 관점 지향 프로그래밍을 이용하여 아키텍처 기반의 결함 검출 방법을 개념적으로 도식화한 도면이다.

아키텍처 명세 분석부(311)는 아키텍처 명세 정보(즉, 아키텍처 명세서, 401)로부터 일반 시험 아키텍처(402)를 도출하고, 일반 시험 아키텍처(402)를 기반으로 아키텍처를 구성하는 컴포넌트들과, 컴포넌트들 간의 관계 정보를 구분할 수 있다. 그리고, 아키텍처 명세 분석부(311)는 구분된 컴포넌트들 간의 주요 상호작용(즉, 일반 시험 아키텍처를 구성하는 컴포넌트들 간의 주요 상호작용)을 분석할 수 있다.

관찰점 및 관찰제어점 구현부(312)는 주요 상호작용 분석을 통해 획득된 후보군 중 통합 결함 검출에 활용할 관찰점 및 관찰제어점의 위치와 개수를 사용자로부터 선택받을 수 있다(404). 그리고, 관찰점 및 관찰제어점 구현부(312)는 선택된 해당 관찰점 및 관찰제어점을 일반 시험 아키텍처에 추가하면서 상세시험 아키텍처(405)를 도출할 수 있으며, 상세시험 아키텍처와 관점 지향 프로그래밍을 이용하여 관찰점 및 관찰제어점을 구현(406)할 수 있다.

통합 시험 수행부(313)는 구현된 관찰점 및 관찰제어점으로부터 컴포넌트들 간의 메시지 교환 정보를 관찰하고 제어하는 통합 시험을 통합 시험 항목에 따라 수행할 수 있다(407). 통합 시험을 수행하는 과정에서 로그 정보가 발생하며, 발생된 로그 정보가 메모리 등에 기록될 수 있다. 예를 들어, 통합 시험을 수행하는 과정에서 컴포넌트들 간에 발생하는 메시지 교환 정보, 예컨대, 메소드 간 파라미터 또는 아규먼트 정보 등이 로그 정보로서 기록될 수 있다(408).

통합 시험 로그 분석 도구부(320)는 기록된 로그 정보, 즉, 로그된 메시지 교환 정보를 분석하여 사용자가 읽을 수 있는 형태로 필터링할 수 있다(409). 예컨대, 필터링 룰은 시험 항목 별 필터링, 관찰점 및 관찰제어점 별 필터링, 아키텍처 관계 정보 별 필터링 등을 포함할 수 있으며, 상기 필터링 항목들 중 사용자로부터 선택된 항목에 해당하는 필터링이 수행될 수 있다. 이때, 하나의 항목만 선택되어 필터링을 수행하는 것뿐만 아니라, 복수개의 항목이 선택되어 필터링이 수행될 수도 있다. 예컨대, 아키텍처 관계 정보 별 필터링 및 시험 항목 별 필터링이 함께 선택되어 필터링이 수행될 수도 있다.

도 5는 본 발명의 일실시예에 있어서, 아키텍처 기반의 통합 결함 검출을 수행하는 시스템의 네트워크 환경을 도시한 도면이다.

도 5에 따르면, 본 발명에서 제안하는 시스템을 지원하는 도구인 VFT는 Eclipse IDE 상의 플러그인 형태로 구현되어 Eclipse IDE에서 지원하는 기능들을 활용하여 시험자와 통신을 수행하며(즉, 시험자로부터 특정 기능 실행을 위한 입력을 제공받고), 시험 수행부인 Java Testing Tool과 시험 대상 시스템 아키텍처 분석부인 아키텍처 분석부(Architecture Analyzer)의 결과 산출물들을 받아 필터링하고 시각 처리하여 시험자에게 제공함으로써 통합 결함 검출 수행을 지원함을 알 수 있다.

도 6은 본 발명의 일실시예에 있어서, 아키텍처의 명세 정보를 분석하는 과정을 설명하기 위해 제공되는 도면이다.

610을 참고하면, 시험 대상 시스템의 컴포넌트 정보, 즉, 아키텍처 관계 정보는 컴포넌트의 인터페이스 정보와 내부 요소들 간의 동작 정보를 포함할 수 있다. 610은 시험 대상 시스템의 아키텍처를 도시한 것으로서, 상기 아키텍처를 텍스처 형태인 XML 형태로 나타내면 620과 같을 수 있다.

610에서, 상기 내부 요소들은 system type ATMSimulation을 구성하는 ATM, Bank, Simulation의 세 개의 컴포넌트들을 포함할 수 있다. 그리고, 내부 요소들 간의 동작 정보는 각 컴포넌트들 간에 주고받는 동작 정보(예컨대, 메시지 등)를 나타내는 것으로서, 예컨대, chAs, chSa, chBA, chAB, chSB 등을 포함할 수 있다. 이에 따라, chAS를 통해 CATM에서 CSimulation으로의 동작이 존재함을 확인할 수 있다. 도 6에서, chAS 상단에 네모박스 형태로 있는 reqDisplayInfo, reqLogInfo와 같은 정보들이 상세 동작 정보들에 해당할 수 있으며, 해당 상세 동작 정보를 관찰점 및 관찰제어점으로 관찰함으로써 메시지 등과 같은 정보가 관찰 및 제어될 수 있다.

모듈 관점 아키텍처에서는, 컴포넌트들은, 모듈, 코드, 코드들의 논리적 그룹, 패키지들 등을 포함할 수 있다. 그러면, 모듈 관점 아키텍처의 경우, 시험 대상 시스템의 아키텍처의 커넥터 및 컴포넌트들 간의 관계 정보는 사용 관계(use, dependency, import), 인터페이스 제공/요구 관계(specialize/generalize), 포함 관계(nested) 등을 포함할 수 있다.

도 7은 본 발명의 일실시예에 있어서, 상세시험 아키텍처의 예시를 도시한 도면이다.

도 7을 참고하면, 해당 예시 상세시험 아키텍처는 (1) 시험 대상 시스템(ATM Simulation System)의 컴포넌트들과 (2) 해당 컴포넌트들간 상호작용에 위치한 관찰점 및 관찰제어점 그리고 (3) 관찰점 및 관찰제어점과 시험자 컴포넌트간의 관계들로 구성될 수 있다. 시험자 컴포넌트(Test System/Tester)는 관계를 가지고 있는 관찰점 및 관찰제어점으로부터 시험 수행 중에 발생한 메시지 교환 정보를 취합하는 역할을 한다. 즉, CATM-CSimulattion, CATM-CBanking, CSimulation-CBanking 사이에서 발생하는 모든 메시지 교환 정보에 대해서 관찰 및 제어할 수 있도록 해당 상세 시험 아키텍처가 설계되어 있음을 알 수 있다.

도 7을 참고하면, 위의 130 단계에서 설명한 바와 같이, 관찰점 및 관찰제어점 구현 가능 위치가 동그라미(특정 모양의 표시정보)로 시험 대상 컴포넌트간 상호작용 위치에 표시될 수 있다. 즉, 해당 위치에 모두 설치할 것인지 그 종류가 무엇인지에 따라 그 조합이 달라질 수 있다. 예를 들어, 도 7과 같이 3개의 컴포넌트를 설치할 경우, (PO, PO, PO), (PO, PO, PCO), (PO, PCO, PCO), (PO, PCO, PO), (PCO, PCO, PCO), (PCO, PCO, PCO) 와 같은 6개의 상기 구현 가능 위치의 조합이 존재할 수 있다. 이때, 상기 조합이 2개나 1개일 경우, 도 7의 3개의 후보 위치(도 7의 동그라미로 표시된 부분) 중에 적어도 하나가 사용자로부터 입력 인터페이스를 통해 선택될 수 있다. 그리고, 종류 선택에 따라 4개와 2개의 조합으로 선택이 가능할 수 있다.

도 10은 본 발명의 일실시예에 있어서, 로그 정보를 필터링 룰에 따라 그래프 형태로 필터링하는 통합 시험 로그 분석 도구부에서 제공하는 도구 화면의 예시도이고, 도 11은 본 발명의 일실시예에 있어서, 필터링된 로그 정보를 시각화하여 제공하는 도구 화면의 예를 도시한 도면이다.

도 10을 참고하면, 로그 정보인 메시지 교환 정보가 상기 화면 상의 여러 필터링 항목들(1010) 중 필터링을 적용할 항목을 사용자로부터 선택받을 수 있다. 그리고, 선택된 필터링 항목, 예컨대, 통합 시험 항목 별 필터링이 선택된 경우, 통합 시험 항목 별로 필터링이 수행될 수 있다. 이외에, 관찰점 및 관찰제어점 별 필터링, 아키텍처 관계 정보 별 필터링 등이 선택될 수 있다.

이처럼, 로그 정보들이 선택된 필터링 항목에 따라 필터링이 수행되면, 필터링된 로그 정보들은 도구 화면(1100)에 텍스트 트리뷰 형태로 표시될 수 있다. 이때, 텍스트 트리뷰 이외에 그래프 뷰 형태로 표시될 수도 있다.

실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다.

이상과 같이 실시예들이 비록 한정된 실시예와 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기의 기재로부터 다양한 수정 및 변형이 가능하다. 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다.

그러므로, 다른 구현들, 다른 실시예들 및 특허청구범위와 균등한 것들도 후술하는 특허청구범위의 범위에 속한다.

Claims (15)

1. 컴퓨터에 의해 실행되는 아키텍처 기반의 통합 결함 검출 방법에 있어서,
   아키텍처(architecture) 명세서로부터 일반 시험 아키텍처를 도출하는 단계;
   상기 일반 시험 아키텍처에 기초하여 아키텍처를 구성하는 복수의 컴포넌트들 간의 주요 상호작용을 분석하는 단계;
   분석된 상기 주요 상호작용을 대상으로, 통합 결함 검출에 이용하기 위한 관찰점 및 관찰제어점의 위치와 개수를 결정하는 단계;
   결정된 상기 관찰점 및 관찰제어점의 위치와 개수에 기초하여 해당 관찰점 및 관찰제어점을 상기 일반 시험 아키텍처에 추가함으로써 상세 시험 아키텍처로 도출하는 단계;
   상기 관찰점 및 관찰제어점의 위치와 개수를 기초로 관점 지향 프로그래밍을 이용하여 관찰점 및 관찰제어점을 구현하는 단계;
   구현된 상기 관찰점 및 관찰제어점을 대상으로 통합 시험을 수행하는 단계; 및
   상기 통합 시험 수행을 통해 생성된 로그 정보를 분석 및 필터링하는 단계
   를 포함하는 것을 특징으로 하는 아키텍처 기반의 통합 결함 검출 방법.
2. 제1항에 있어서,
   상기 통합 시험을 수행하는 단계는,
   상기 관찰점 및 관찰제어점으로부터 메시지 교환정보를 관찰 및 제어하는 통합 시험을 수행하는 것
   을 특징으로 하는 아키텍처 기반의 통합 결함 검출 방법.
3. 제1항에 있어서,
   상기 로그 정보를 분석 및 필터링하는 단계는,
   상기 관찰점 및 관찰제어점으로부터 로그된 메시지 교환 정보를 분석하여 필터링을 수행하는 것
   을 특징으로 하는 아키텍처 기반의 통합 결함 검출 방법.
4. 삭제
5. 제1항에 있어서,
   상기 상세 시험 아키텍처는, 상기 관점 지향 프로그래밍을 이용하여 통합 결함을 검출하기 위한 시험 아키텍처를 나타내는 것
   을 특징으로 하는 아키텍처 기반의 통합 결함 검출 방법.
6. 제1항에 있어서,
   상기 통합 시험을 수행하는 단계는,
   상기 관찰점 및 관찰제어점을 미리 준비된 통합 시험 항목들과 함께 통합 시험을 수행하는 것
   을 특징으로 하는 아키텍처 기반의 통합 결함 검출 방법.
7. 제6항에 있어서,
   상기 통합 시험을 수행하는 단계는,
   상기 통합 시험 항목들 각각을 수행하면서 생성된 로그(log) 정보를 기록하는 단계
   를 포함하는 것을 특징으로 하는 아키텍처 기반의 통합 결함 검출 방법.
8. 컴퓨터로 구현되는 통합 결함 검출 시스템에 있어서,
   상기 컴퓨터에서 판독 가능한 명령을 실행하도록 구현되는 적어도 하나의 프로세서
   를 포함하고,
   상기 적어도 하나의 프로세서는,
   아키텍처(architecture) 명세서로부터 일반 시험 아키텍처를 도출하고, 도출된 일반 시험 아키텍처에 기초하여 아키텍처를 구성하는 복수의 컴포넌트들 간의 주요 상호작용을 분석하는 아키텍처 명세 분석부;
   분석된 상기 주요 상호작용을 대상으로, 통합 결함 검출에 이용하기 위한 관찰점 및 관찰제어점의 위치와 개수를 결정하고, 결정된 관찰점 및 관찰제어점의 위치와 개수를 기초로 관점 지향 프로그래밍을 이용하여 관찰점 및 관찰제어점을 구현하는 관찰점 및 관찰제어점 구현부;
   구현된 상기 관찰점 및 관찰제어점을 대상으로 통합 시험을 수행하는 통합 시험 수행부;
   상기 통합 시험 수행을 통해 생성된 로그 정보를 분석하는 구문 분석부; 및
   분석된 로그 정보를 필터링하는 필터링부
   를 포함하고,
   상기 관찰점 및 관찰제어점 구현부는,
   결정된 상기 관찰점 및 관찰제어점의 위치와 개수에 기초하여 해당 관찰점 및 관찰제어점을 상기 일반 시험 아키텍처에 추가함으로써 상세 시험 아키텍처로 도출하는 것
   을 특징으로 하는 통합 결함 검출 시스템.
9. 제8항에 있어서,
   상기 통합 시험 수행부는,
   상기 관찰점 및 관찰제어점으로부터 메시지 교환정보를 관찰 및 제어하는 통합 시험을 수행하는 것
   을 특징으로 하는 통합 결함 검출 시스템.
10. 제8항에 있어서,
    상기 구문 분석부는,
    상기 관찰점 및 관찰제어점으로부터 로그된 메시지 교환 정보를 분석하는 것
    을 특징으로 하는 통합 결함 검출 시스템.
11. 삭제
12. 제8항에 있어서,
    상기 상세 시험 아키텍처는, 상기 관점 지향 프로그래밍을 이용하여 통합 결함을 검출하기 위한 시험 아키텍처를 나타내는 것
    을 특징으로 하는 통합 결함 검출 시스템.
13. 제8항에 있어서,
    상기 통합 시험 수행부는,
    상기 관찰점 및 관찰제어점을 미리 준비된 통합 시험 항목들과 함께 통합 시험을 수행하는 것
    을 특징으로 하는 통합 결함 검출 시스템.
14. 제13항에 있어서,
    상기 통합 시험 수행부는,
    상기 통합 시험 항목들 각각을 수행하면서 생성된 로그(log) 정보를 기록하는 것
    을 특징으로 하는 통합 결함 검출 시스템.
15. 제8항에 있어서,
    필터링된 상기 로그 정보를 텍스트 트리뷰 또는 그래프 뷰 형태로 제공하기 위한 시각처리를 수행하는 시각 처리부
    를 더 포함하는 것을 특징으로 하는 통합 결함 검출 시스템.
    

Images