KR20080091351A - 일련의 사전 정의된 규칙을 사용하여 소프트웨어를검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의사전 정의된 규칙의 실행을 관리하는 방법 및 컴퓨터프로그램 제품 - Google Patents

일련의 사전 정의된 규칙을 사용하여 소프트웨어를검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의사전 정의된 규칙의 실행을 관리하는 방법 및 컴퓨터프로그램 제품 Download PDF

Info

Publication number
KR20080091351A
KR20080091351A KR1020087018506A KR20087018506A KR20080091351A KR 20080091351 A KR20080091351 A KR 20080091351A KR 1020087018506 A KR1020087018506 A KR 1020087018506A KR 20087018506 A KR20087018506 A KR 20087018506A KR 20080091351 A KR20080091351 A KR 20080091351A
Authority
KR
South Korea
Prior art keywords
code
context
analysis
predefined rules
execution
Prior art date
Application number
KR1020087018506A
Other languages
English (en)
Inventor
제프리 반 고흐
마이클 씨. 패닝
션 디. 샌디스
Original Assignee
마이크로소프트 코포레이션
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 마이크로소프트 코포레이션 filed Critical 마이크로소프트 코포레이션
Publication of KR20080091351A publication Critical patent/KR20080091351A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Stored Programmes (AREA)

Abstract

실시예들은 타겟 코드(target code)의 분석 검사에 적절한 형식화된 일련의 중간 분석 컨텍스트를 제공한다. 이러한 중간 분석 컨텍스트는 타겟 코드의 개발 단계, 타겟 코드의 유형 또는 상태, 타겟 코드를 조작하는 소스, 타겟 코드의 목적, 또는 기타 개발 또는 런타임 요건을 포함할 수 있지만, 이에 한정되는 것은 아니다. 그에 따라, 실시예들은 타겟 코드가 개발되고 있는 현재의 분석 컨텍스트를 동적으로 식별하고, 이어서 규칙(들)이 어느 컨텍스트에 적용될 수 있는지에 대한 지식에 기초하여 규칙들을 실행할 수 있다. 보다 구체적으로는, 분석 규칙은 (예를 들어, 메타데이터를 통해) 규칙이 실행될 수 있는 컨텍스트 조건들을 서술할 수 있다. 이러한 서술 및 현재의 컨텍스트에 기초하여, 이러한 컨텍스트 조건에 적용하도록 구성되어 있는 규칙들이 실행될 수 있다.
Figure P1020087018506
코드 분석, 컨텍스트, 분석 규칙, 타겟 코드, IDE

Description

일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙의 실행을 관리하는 방법 및 컴퓨터 프로그램 제품{CONTEXT BASED CODE ANALYSIS}
대부분의 소프트웨어는 각각이 하나 이상의 태스크를 수행하도록 설계되어 있는 다수의 재사용가능한 소프트웨어 객체로서 개발된다. 소프트웨어는 물론 소프트웨어를 실행하는 컴퓨팅 시스템의 효용 및 기능은 프로세서에 의해 실행하기 위해 컴파일 또는 인터프리트(interpret)되는 소스 코드의 적절한 코딩에 의존한다. 코딩 에러는 보통 소프트웨어의 예상된 기능으로부터의 벗어남을 야기하며 아마도 컴퓨터 시스템의 다른 부분들(예를 들어, 다른 애플리케이션, 데이터베이스, 운영 체제, 기타)에 영향을 줄 수 있다. 이러한 코딩 에러는 소프트웨어에 대한 사용자의 컴퓨팅 경험을 망칠 뿐만 아니라, 컴퓨터 시스템 전체에 걸쳐 원하지 않는 결과를 야기할 수도 있다. 따라서, 고품질 소프트웨어의 제작자는 그의 소프트웨어 내의 에러를 제거하기 위해 상당한 테스트 및 분석 노력을 기울인다.
그렇지만, 시장의 요구 및 프로그래머 및 디자이너의 창의성은 점점 더 복잡한 - 그렇지만 강력한 - 소프트웨어를 가져왔다. 소프트웨어의 복잡도가 증가함에 따라, 종종 그 소프트웨어를 구현하는 데 필요한 소스 코드의 라인 수도 증가한다. 직접적인 결과로서, 소스 코드에 에러가 있을 가능성이 계속 증가한다. 그에 따 라, 소프트웨어는 종종 소프트웨어가 의도한 대로 동작하도록 하는 데 도움을 주기 위해 (출시 전후에) 여러번 다양한 방식으로 테스트 또는 분석되어야만 한다.
어떤 분석 환경에서, 검사자(tester)는 소프트웨어의 하나 이상의 부분의 동작을 검증하는 자동화된 규칙 또는 테스트(본 명세서에서 서로 교환되어 사용될 수 있음)를 개발한다. 예를 들어, 규칙은 그래픽 사용자 인터페이스 내에서 입력 필드값을 입력하는 것, 다양한 입력 파라미터로 광범위한 조건 하에서 소프트웨어 객체를 호출하는 것, 그 결과 얻어지는 출력을 수집하는 것, 및 테스트에 합격했는지 불합격했는지를 판정하는 것을 자동화할 수 있다. 검사자(테스트 개발자이거나 아닐 수 있음)는 이어서 테스트 중인 객체 또는 타겟 코드가 합격인지 불합격인지(따라서 객체가 의도한 대로 동작하고 있는지)의 표시를 제공하는 테스트 케이스(test case)를 실행할 수 있다.
현재, 테스트 개발자들은 서로 다른 소프트웨어 검증 레벨, 즉, 객체 또는 코드가 합격인지 불합격인지를 판정할 때 각각의 규칙이 수행하는 분석량에 대해 개별적인 규칙들을 작성한다. 소프트웨어를 테스트하는 규칙의 검증 레벨은 수많은 인자들에 따라 크게 달라진다. 그에 따라, 일반적으로 규칙 또는 테스트 케이스를 실행하는 데 걸리는 시간량과 소프트웨어가 얼마나 철저하게 테스트되느냐 간에 트레이드오프가 있다. 상세하게는, 발생되고 분석되는 출력이 적을수록, 테스트에 걸리는 시간이 적어진다. 예를 들어, 테스트 개발자는 소프트웨어의 스트레스(stress) 또는 부하(load)를 간단히 테스트하는 규칙을 작성할 수 있다. 이러한 경우에, 테스트 케이스의 결과 출력이 무시될 수 있고, 소프트웨어 또는 시스템이 실행 정지(crash)되지 않는다면 객체 또는 타겟 코드가 합격한 것으로 간주된다. 이러한 형태의 분석이 소프트웨어의 신속한 테스트를 고려한 것이지만, 소프트웨어에 의해 야기되는 모든 결과에 대한 완전한 판정을 제공하지 않는다. 그 자체로서, 각각의 규칙이 소프트웨어를 적절히 분석하는 데 필요한 검증 레벨을 결정하는 데 보통 많은 논의 및 고려가 필요하다.
광범위한 테스트 검증 레벨에 대비하기 위해, 소프트웨어 개발자가 문제점 및 모순이 있는지 그의 코드를 검사하는 반자동 메카니즘을 제공하는 코드 분석 도구(예를 들어, 정적 코드 분석 도구)가 개발되었다. 보다 구체적으로는, 테스트 개발자는 소프트웨어의 정확성, 완전성 및/또는 품질을 확인하기 위해 소프트웨어 소스, 객체 또는 바이너리 코드를 분석하기 위한 다양한 검증 레벨을 갖는 일련의 규칙들을 이러한 도구에 추가(populate)한다. 이들 도구는 통상적으로 다양한 형태의 구성을 통해 제어되는 모놀리딕 동작(monolithic operation)으로서 소프트웨어의 분석을 수행 또는 실행한다. 환언하면, 코드에 적용되는 특정의 검사 또는 규칙이 소스 제어식(source control expression)(#pragma 등)에 의해, 도구 명령줄 옵션(tool command-line option)을 통해, 또는 별도의 제어 파일에 제공된 설정에 의해 인에이블 또는 디스에이블된다. 이것이 검사자에게 개발 프로세스의 다양한 단계들에서 어떤 유형의 규칙을 실행시킬지에 대한 얼마간의 제어를 제공하지만, 여전히 이러한 접근 방법에 대한 몇가지 단점 및 한계가 있다.
예를 들어, 코드를 적절히 테스트하기 위해, 검사자(즉, 정적 코드 분석 도구의 사용자)는 어떤 단계에서 또한 어떤 조건 하에서 규칙들이 적용되어야만 하는 지(이에 한정되지 않음)를 비롯하여 다양한 규칙들에 대해 광범위한 지식을 가지고 있어야만 한다. 그렇지만, 모든 테스트 케이스에 대한 이러한 지식은 통상적으로 대부분의 코드 개발자의 기본 자질(skill set)을 넘어선다(왜냐하면 이들이 통상적으로 전문적인 테스트 개발자가 아니기 때문이다). 그 자체로서, 검사자가 적절한 때에 적절한 조건 하에서 규칙을 적용하지 않을 수도 있다. 게다가, 이러한 테스트가 통상적으로 본질상 정적이기 때문에(즉, 이들 테스트가 보통 검사자로부터의 명확한 제스처(gesture)에 의해 실행되기 때문에), 이러한 테스트를 실행할 때 다양한 시간 비효율(time inefficiency)이 있다. 예를 들어, 동일한 검사가 여러번 반복하여 실행될 수 있고, 프로세스의 부적절한 시점(inappropriate juncture)에서 문제들이 야기될 수 있으며(예를 들어, 이들 문제가 반복하여 무시되거나 연기되는 경우), 및/또는 에러 또는 결함이 개발 프로세스에서 충분히 이른 시기에 식별되지 않을 수 있다(즉, 문제가 식별되거나 위치 확인되는 곳이 체크인(check-in)에서 멀수록, 해결하는 데 비용이 더 많이 든다는 것은 명백하다). 그에 따라, 통상적인 코드 분석 도구의 이들 및 다른 관련 단점들이 종종 과중한 업무, 사용자 및 개발자 좌절, 성능 문제, 식별되지 않은 에러 또는 결함, 시간 비용, 기타 등등의 다수의 문제를 야기할 수 있다.
현재의 코드 분석 도구의 상기한 결점 및 단점은 본 발명의 예시적인 실시예들을 통해 극복된다. 예를 들어, 본 명세서에 기술된 실시예들은 코드가 개발되고 있는 분석 컨텍스트(analysis context)를 동적으로 추적하고 현재의 컨텍스트 조건(context condition)에 대응하는 규칙(또는 그의 일부분)을 적용함으로써 (성능 고려사항들의 균형을 맞추기 위해) 사전 정의된 규칙 세트의 실행을 자동적으로 관리하는 코드 분석 도구를 제공한다. 유의할 점은 이하에서 상세한 설명에 더 기술되는 개념들 중 선택된 것을 간략화된 형태로 소개하기 위해 이 요약이 제공된다는 것이다. 이 요약은 청구된 발명 대상의 주요 특징들 또는 필수적인 특징들을 확인하기 위한 것이 아니며, 청구된 발명 대상의 범위를 정하는 보조 수단으로 사용되기 위한 것도 아니다.
한 예시적인 실시예는 사전 정의된 규칙 세트에 기초하여 정확성, 완전성 및/또는 품질에 대해 분석되어야 하는 타겟 코드(targeted code)를 수신하는 코드 분석 도구로 구성되어 있는 컴퓨팅 시스템을 제공한다. 타겟 코드가 개발되고 있는 현재의 코드 분석 컨텍스트를 동적으로 추적하기 위해 코드 분석 컨텍스트 정보(code analysis context information)도 개발 장치(들)로부터 수신된다. 게다가, 사전 정의된 규칙 세트로부터 선택된 규칙에 대응하는 컨텍스트 파라미터(context parameter)가 수신된다. 유의할 점은 컨텍스트 파라미터가 코드 분석 컨텍스트 정보로 규칙의 적어도 일부분에 대한 실행 조건을 기술한다는 것이다. 그 후에, 규칙의 적어도 일부분이 분석 중인 타겟 코드에 대해 실행될 수 있는지를 동적으로 판정하기 위해 현재의 코드 분석 컨텍스트를 바탕으로 규칙 컨텍스트 파라미터가 평가되며, 이에 따라 개발 프로세스의 적절한 단계에서 규칙의 적어도 일부분을 적용한다.
다른 예시적인 실시예는 타겟 코드가 개발되고 있는 현재의 코드 분석 컨텍스트를 판정하는 데 사용되는 개발 장치(들)로부터의 코드 분석 컨텍스트 정보를 수신하는 동적 컨텍스트 추적 모듈(dynamic context tracking module)을 포함하는 코드 분석 도구(code analysis tool)를 제공한다. 코드 분석 도구는 또한 코드 분석 컨텍스트 정보로 규칙의 적어도 일부분에 대한 실행 조건을 나타내는 현재의 코드 분석 컨텍스트 및 컨텍스트 파라미터를 평가하는 규칙 관리 모듈(rule management module)을 포함한다. 이 평가에 기초하여, 규칙 관리 모듈은 규칙의 적어도 일부분이 정확성, 완전성 및/또는 품질에 대해 분석되어야 하는 타겟 코드에 대해 실행될 수 있는지를 동적으로 판정한다. 그에 부가하여, 코드 분석 도구는, 규칙의 적어도 일부분이 개발 프로세스의 적절한 단계에서 적용되도록, 분석 중인 타겟 코드에 대해 규칙의 적어도 일부분을 실행하는 실행 모듈을 포함한다.
본 발명의 부가적인 특징 및 이점이 이하의 설명에 기술될 것이고 부분적으로는 이 설명으로부터 명백하거나 본 발명의 실시에 의해 알 수 있게 될 것이다. 본 발명의 특징 및 이점은 첨부된 청구항들에 상세히 언급된 수단 및 조합에 의해 실현 및 달성될 수 있다. 본 발명의 이들 및 다른 특징은 이하의 설명 및 첨부된 청구항들로부터 더 충분히 명백하게 되거나, 이후에 기술되는 본 발명의 실시에 의해 알 수 있게 될 것이다.
도 1은 예시적인 실시예들에 따라 타겟 코드가 개발되는 컨텍스트에 기초하여 소프트웨어를 동적으로 검사하도록 구성되어 있는 코드 분석 도구를 나타낸 도면.
도 2는 예시적인 실시예들에 따라 코드가 개발되는 분석 컨텍스트를 동적으로 추적함으로써 규칙(들)의 실행을 관리하는 방법의 흐름도.
본 발명의 상기한 이점 및 특징과 기타의 이점 및 특징이 달성될 수 있는 방식을 기술하기 위해, 이상에서 간략히 기술된 본 발명에 대해 첨부 도면에 도시되어 있는 본 발명의 구체적인 실시예를 참조하여 더 상세히 기술할 것이다. 이들 도면이 본 발명의 전형적인 실시예를 나타낸 것에 불과하고 따라서 본 발명의 범위를 제한하는 것으로 생각되어서는 안된다는 것을 이해하면서, 본 발명에 대해 첨부 도면을 사용하여 더 구체적이고 상세하게 기술하고 설명한다.
본 발명은 코드가 개발되고 있는 현재의 컨텍스트에 기초하여 코드 분석 도구에서의 규칙의 실행을 동적으로 관리하는 방법, 시스템 및 컴퓨터 프로그램 제품으로 확장된다. 본 발명의 실시예들은, 이하에서 더 상세히 기술되는 바와 같이, 다양한 컴퓨터 하드웨어 또는 모듈을 비롯한, 특수 목적 또는 범용 컴퓨터를 포함할 수 있다.
본 명세서에 기술되는 실시예들은 타겟 코드의 분석 검사에 관련있는 다수의 중간 분석 컨텍스트(intermediate analysis context)를 형식화한다. 그에 따라, 실시예들은 타겟 코드가 개발되고 있는 현재의 분석 컨텍스트를 동적으로 식별하고 이어서 규칙(들)이 어떤 컨텍스트에 적용될 수 있는지에 대한 지식에 기초하여 규칙(들)(또는 그의 일부분)을 실행할 수 있다. 이러한 중간 분석 컨텍스트는, 타겟 코드의 개발 단계, 타겟 코드의 유형 또는 상태, 타겟 코드를 조작하는 소스, 타겟 코드의 목적, 또는 기타 개발 또는 런타임 요건을 포함할 수 있지만, 이에 한정되는 것은 아니다. 유의할 점은 이러한 중간 분석 컨텍스트가 문자 그대로의 코드 개발 이외에 소프트웨어 개발 프로세스의 다른 단계들에 관련되어 있다는 것이다. 이러한 다른 단계들은, 예를 들어, 빌드(building) 및 패키징(packaging) 제스처(gesture), 디플로이 테스트(deployment testing), 및 문자 그대로 실행될 때, 예를 들어, 다양한 기계 및 네트워크 구성에서 실행될 때 런타임 시의 코드 분석을 포함할 수 있다. 물론, 코드 분석 컨텍스트를 정의하거나 형식화하기 위한 많은 중첩(overlapping) 및 기타 관계가 있다. 그에 따라, 용어 "코드 분석 컨텍스트"는, 본 명세서에서 정의되는 바와 같이, 이상에서 언급하고 이하의 실시예들에서 더 상세히 정의되는 임의의 수, 조합 및/또는 계층적 관계의 분석 컨텍스트를 포함하는 것으로 광의적으로 해석되어야만 한다.
유의할 점은 현재의 컨텍스트 조건에 대한 지식이 다양한 방식으로 시스템에 의해 획득될 수 있다는 것이다. 예를 들어, 이러한 컨텍스트 정보는, 통상적으로 프로젝트 유형(project type) 및 소스 언어(source language)를 전달하고 컴파일러-설정(compiler-setting) 및/또는 빌드 버전(build flavor), 기타에 대해 알고 있을 수 있는 통합 개발 환경(integrated development environment, IDE)과의 연계를 통해 획득될 수 있다. 다른 대안으로서, 또는 그와 함께, 이러한 컨텍스트 정보는 소스-기반 및 컴파일러 제공 메타데이터의 조사에 의해 및/또는 코드에 대한 바이너리(binary)를 호스트하는 기계의 조사에 의해 획득될 수 있다. 그에 부가하여, 코드 분석 정보를 제공하는 기타 컨텍스트 소스로는 기계를 호스트하는 대규모 네 트워크 시스템의 조사와 같은 것들이 있을 수 있다.
현재의 코드 분석 컨텍스트 조건이 어떻게 판정되는지에 상관없이, 이러한 조건에 관련된 규칙 세트(rule set)를 판정하기 위해, 분석 규칙(또는 기타 데이터 객체)은 (예를 들어, 메타데이터를 통해) 규칙(또는 그의 일부분)이 실행될 수 있는 컨텍스트 조건[및 선호되는 규칙 또는 기본 컨텍스트(default context) 등의 기타 정보]을 기술할 수 있다. 규칙을 실행하기 위한 컨텍스트에 관한 이러한 결정 또는 (예를 들어, 메타데이터에) 제공되는 기타 정보는 규칙 개발자에 의해 작성된 것일 수 있지만, 다른 실시예들은 또한 이러한 컨텍스트 조건을 수정하는 것, 노이즈 필터링하는 것, 및/또는 다른 방식으로 무시하는 것을 제공한다. 예를 들어, 어떤 실시예들은, IDE 내부에서의 명백한 제스처에 의해 및/또는 분석 실행과 연관된 제어 파일을 수정하는 것에 의해, 규칙이 적용될 수 있는 컨텍스트를 수정하거나 무시하는 것을 고려하고 있다. 그에 따라, 개발자가 코드 분석 옵션들을 구성하러 갈 때, 개발자는 각각의 규칙과 연관된 일련의 컨텍스트를 무시하는 옵션을 가질 수 있다. 이 정보는 이어서 사용자에 의해 설정된 기타 코드 분석 옵션을 포함하는 프로젝트 파일에 저장될 수 있다.
그럼에도 불구하고, 무시되지 않은 규칙들에 대해, 현재의 컨텍스트가 동적으로 판정되는 다양한 개발 단계 동안에, 제공된 정보 또는 메타데이터에 기초하여, 이러한 컨텍스트 조건에 적용되도록 구성된 규칙들이 실행된다. 알 수 있는 바와 같이, 이것은 코드 개발자가 개발 프로세스에서 가능한 한 일찍 잠재적인 문제점들을 통보받을 수 있도록 다양한 개발 단계 동안의 코드의 동적 분석을 고려한 것이다. 그에 부가하여, 일반적으로 규칙에 관한 보다 구체적인 지식을 가지고 있는 테스트 개발자(test developer)는 규칙이 적용되어야만 하는 컨텍스트를 고려하고 설정할 수 있다. 게다가, 조건이 변경되거나 변함에 따라(예를 들어, 타겟 코드가 개발되고 있는 형식화된 컨텍스트 조건의 변화), 다양한 메타데이터도 수정되어 최신 상태를 유지할 수 있고, 따라서 규칙이 확장가능하게 된다.
유익한 이점들에 대한 보다 구체적인 언급이 도면들을 참조하여 이하에서 더 상세히 기술되지만, 본 발명의 범위 내의 실시예들은 컴퓨터 실행가능 명령어 또는 데이터 구조를 전달하거나 저장하고 있는 컴퓨터 판독가능 매체도 포함한다. 이러한 컴퓨터 판독가능 매체는 범용 또는 특수 목적의 컴퓨터에 의해 액세스될 수 있는 이용가능한 매체라면 어느 것이라도 될 수 있다. 제한이 아닌 예로서, 이러한 컴퓨터 판독가능 매체는 RAM, ROM, EEPROM, CD-ROM 또는 기타 광 디스크 저장 장치, 자기 디스크 저장 장치 또는 기타 자기 저장 장치, 또는 컴퓨터 실행가능 명령어 또는 데이터 구조의 형태로 원하는 프로그램 코드 수단을 전달하거나 저장하는 데 사용될 수 있고 범용 또는 특수 목적의 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함할 수 있다. 정보가 네트워크 또는 다른 통신 접속(유선, 무선, 또는 유선과 무선의 조합)을 통해 컴퓨터로 전송되거나 제공될 때, 컴퓨터는 당연히 그 접속을 컴퓨터 판독가능 매체로서 간주한다. 따라서, 임의의 이러한 접속도 당연히 컴퓨터 판독가능 매체라고 한다. 상기한 것들의 조합도 컴퓨터 판독가능 매체의 범위 내에 포함되어야 한다.
컴퓨터 실행가능 명령어는, 예를 들어, 범용 컴퓨터, 특수 목적 컴퓨터 또는 특수 목적 처리 장치로 하여금 어떤 기능 또는 일군의 기능을 수행하게 하는 명령어 및 데이터를 포함한다. 본 발명이 구조적 특징 및/또는 방법적 동작과 관련한 언어로 기술되어 있지만, 첨부된 청구항들에 정의된 본 발명이 반드시 상기한 구체적인 특징들 또는 동작들로 제한되어야 하는 것은 아니라는 것을 잘 알 것이다. 오히려, 상기한 구체적인 특징들 및 동작들은 청구항들을 구현하는 예시적인 형태로서 개시되어 있는 것이다.
본 명세서에서 사용되는 바와 같이, 용어 "모듈" 또는 "컴포넌트"는 컴퓨팅 시스템에서 실행되는 소프트웨어 객체 또는 루틴을 말하는 것일 수 있다. 본 명세서에 기술되는 다른 컴포넌트, 모듈, 엔진 및 서비스는 컴퓨팅 시스템에서 실행되는 객체 또는 프로세스로서(예를 들어, 별도의 쓰레드로서) 구현될 수 있다. 본 명세서에 기술된 시스템 및 방법이 양호하게는 소프트웨어로 구현되지만, 하드웨어 또는 소프트웨어와 하드웨어의 조합으로 된 구현도 가능하고 또 생각되고 있다. 본 설명에서, "컴퓨팅 개체(computing entity)"는 본 명세서에서 이미 정의된 임의의 컴퓨팅 시스템 또는 컴퓨팅 시스템에서 실행 중인 임의의 모듈 또는 모듈의 조합일 수 있다.
본 명세서에 기술된 실시예들은 성능 고려사항들의 균형을 맞추기 위해 수많은 인자들을 고려하여 규칙의 실행을 동적으로 관리하는 코드 분석 도구를 제공한다. 예를 들어, 본 명세서의 실시예들은 어떤 규칙에 의해 발생된 메시지가 코드의 빌드 동안에 또는 그 후에 검출될 때 정정하려면 더 많은 비용이 든다는 것을 고려하고 있다. 그에 따라, 개발자는 이들 경고를 가능한 한 일찍, 통상적으로 코 드를 편집하는 동안에 통보받기를 원할 수 있다. 게다가, 어떤 규칙에 의해 발생된 메시지는 코드가 언제 체크인(check-in) 등의 다양한 개발 단계에 대한 준비가 되는지 및 개발 이정표(development milestone)가 언제 완성되는지를 알려주는 데 가장 관심이 있다. 예로서, 이정표가 완성되지 않은 동안 미사용 코드를 검출하는 분석을 수행하는 것은 그다지 의미가 없는데, 그 이유는 그 코드가 나중에 개발 프로세스에서 사용될 수 있기 때문이다. 게다가, 앞서 언급한 바와 같이, 어떤 규칙들은 실행하는 데 비용이 극도로 많이 든다. 그 자체로서, 개발자는 모든 증분 빌드(incremental build)에 또는 심지어 전체적인 재빌드(rebuild)에도 이러한 분석 비용이 드는 것을 원하지 않을 수 있다.
고려할 다른 인자들은 그의 기능에 따라 분석을 완료하는 데 다소의 바이너리 메타데이터(binary metadata)를 필요로 하는 규칙들을 형성한다. 어떤 규칙들은 소스 코드에서만 이용가능한 정보(따라서 파일이 실제로 발생될 때 컴파일되어 없어질 수 있음)를 필요로 할 수 있다. 그렇지만, 다른 규칙들은 디스크에 기록되어 있는 또는 디스크에 기록되어질 문자 그대로의 오브젝트 코드(object code)를 필요로 한다. 또 다른 실시예들은 어떤 규칙들에서는 바이너리가 개발자에 의해 클라이언트 박스(client box)에 발생되는 빌드(build)와 다른 정확한 출시 조건(true release condition)에 있어야만 한다는 것을 고려한다. 예를 들어, 개발자는 통상적으로 특정 회사의 실제 보안키(actual security key)로 서명되는 완전-서명된 바이너리(full-signed binary)를 생성하지 않는다.
참작될 수 있는 또 다른 인자들은 어떤 규칙들이 클라이언트 개발 시스템과 상당히 다른 기계 구성(들)에 의존한다는 것을 고려한다. 예를 들어, 어떤 웹 애플리케이션 분석은 웹 서버 상에 실제로 디플로이(deploy)되어 있는 코드에 대해 실행되는 경우에만 적절할 수 있다. 그에 부가하여, 어떤 규칙들은 바이너리의 실행 컨텍스트(execution context)에 관한 특별한 지식을 필요로 한다. 예를 들어, 지역화되거나 비영어 시스템(non-English system)에서 실행될 일이 없는 코드는 통상적으로 세계화/지역화(globalization/localization)와 관련된 문제에 대해 조사될 필요가 없다. 게다가, 어떤 규칙들이 대규모 네트워크 시스템에 관련된 문제들을 검증하기 위해 특수한 컨텍스트에서 실행되어야만 한다는 것을 생각해보자. 예로서, 인터넷에 디플로이된 웹 애플리케이션(들)에 대한 보안 검사는 방화벽 인트라넷(fire-wall Intranet) 밖에서 실행되어야만 할지도 모른다.
또한, 본 명세서에서는 어떤 규칙의 거동이 코드의 수명과 관련된 상황에 따라 변한다는 사실이 생각되고 있다. 예로서, 이미 외부 고객에게 출시된 바이너리가 고수준의 후방 호환성을 유지해야할 필요가 있을 수 있다. 그 자체로서, 해결하기 위해 호환성이 손상되는 변경(breaking change)을 필요로 하는 위반을 일으키는 규칙은 실행되어서는 안된다. 게다가, 어떤 규칙의 거동은 실행 거동에 대한 런타임 예상에 따라 변한다. 예로서, 어떤 성능 검사는 빈번하게 호출되는 성능에 민감한 코드에만 적절할 수 있다. 가끔 호출되는 또는 식별된 문제점을 해결하는 이점을 압도하는 실행 비용을 수반하는 코드에 대해 이러한 규칙들을 실행하는 것은 바람직하지 않을 수 있다. 상기한 바와 관련하여, 분석 타겟 코드에서 교정이 가능한지 또는 가능하지 않은지에 따라 기타 상황들에서 분석이 달라져야만 한다. 예로서, 컴파일러가 내보내는 코드 패턴(이 코드 패턴은 사용자 코드를 변경하는 것에 의해 영향을 받지 않을 수 있음)에 대해 분석이 행해질 수 있다. 그렇지만, 컴파일러 팀(compiler team)은 이들 문제를 식별하고 분석 타겟(analysis target)을 발생한 컴파일러에서 변경을 하고자 할 수 있다.
또한 어떤 실시예들에서는 어떤 규칙 거동이 타겟 바이너리 코드(targeted binary code)의 의도된 재사용(또는 비재사용)에 따라 변하는 것이 생각된다. 예를 들어, 임의의 제3자 개발자에 의해 사용될 수 있는 코드는 일관성(consistency) 및 사용성(usability)을 제공(issue)하기 위해 어떤 표준에 부합해야만 할지도 모른다. 이들 표준은 다른 코딩 표준을 시행하는 팀의 완전히 내부적인 프로젝트에 대해 무시될 수 있다. 게다가, 프로젝트 자원 고려사항에 따라 규칙 거동이 변할 수 있다. 예를 들어, 제약된 자원을 갖거나 엄격한 기한을 갖는 프로젝트의 경우, 분석이 중대한 정정 영향을 갖는 아주 확실한 결과로 제한될 필요가 있을 수 있다.
물론, 개발 프로세스에서 다양한 컨텍스트에 기초하여 규칙(들)의 실행을 관리하기 위해 본 명세서에 기술된 예시적인 실시예에 따라 설명될 수 있는 수많은 인자들 및 고려사항들이 있다. 실제로, 이하에서 더 상세히 기술되는 바와 같이, 코드가 개발되고 있는 분석 컨텍스트가 계속하여 변하기 때문에, 본 명세서에 기술되는 실시예들은 다양한 규칙들이 어떻게 관리되고 실행되는지의 확장성(extensibility)을 고려하고 있다. 그에 따라, 어떤 컨텍스트 하에서 규칙(또는 그의 일부분)이 실행되어야 하는지를 판정하기 위한 본 명세서에 기술된 고려사항들은 단지 예시를 위해 사용되며, 명시적으로 청구되지 않는 한 본 발명의 범위를 제한하거나 다른 방식으로 축소하기 위한 것이 아니다.
어쨋든, 상기한 고려사항들 중 일부를 참작하여, 도 1은 이러한 코드가 개발되고 있는 현재의 코드 분석 컨텍스트에 기초하여 규칙의 실행을 관리하는 코드 분석 도구(100)를 나타낸 것이다. 도 1에 도시된 바와 같이, 타겟 코드(120)는 개발을 위해 수많은 개발 장치(105)[IDE(110) 및 기타 컨텍스트 소스(115)로 열거되어 있는 것 등의 컨텍스트를 제공할 수 있는 기타 장치를 포함함] 중 하나 이상 간에 배포될 수 있다. 예를 들어, 타겟 코드는 소스 코드(source code) 형태로 IDE(110)에 있을 수 있거나 기계 또는 시스템 내에서 실행되는 바이너리 코드(binary code)일 수 있다. 물론, 다른 형태의 타겟 코드(120)도 본 명세서에서 생각된다. 예를 들어, 이하에 더 상세히 기술되는 바와 같이, 타겟 코드(120)는 또한 소스 코드로부터의 추상화(abstraction)인 디자인 단계(design phase)에 있을 수 있다. 그에 따라, 본 명세서에 기술된 임의의 특정 유형의 타겟 코드(120)는 적절한 개발 또는 런타임 상태에 의존하게 된다.
개발 또는 런타임 상태에 상관없이, 본 명세서의 실시예들은 본 명세서에 기술된 다양한 개발 장치들(105)로부터 코드 분석 정보(125)를 획득할 수 있는 동적 컨텍스트 추적 모듈(dynamic context tracking module)(130)을 제공한다. 이하에서 더 상세히 기술되는 바와 같이, 코드 분석 정보(125)는 타겟 코드(120)가 현재 분석 및/또는 개발되고 있는 컨텍스트에 관한 정보를 포함한다. 유의할 점은 코드 분석 정보(125), 따라서 분석 컨텍스트 정보가 코드 분석 도구(100) 또는 동적 컨텍스트 추적 모듈(130)에 의해 다양한 방식으로 획득될 수 있다는 것이다. 예를 들어, 동적 컨텍스트 추적 모듈(130)은 IDE(110)에 연계될 수 있으며, 프로젝트 유형 및 소스 언어를 전달할 수 있고, 또 컴파일러-설정(compiler-setting) 및 빌드 버전(build flavor), 기타 등등에 대해 알고 있을 수 있다.
코드 분석에서의 컨텍스트 정보(125)는 또한 소스-기반 및 컴파일러 제공 메타데이터 등의 다른 컨텍스트 소스(115)의 조사에 의해, 바이너리 또는 타겟 코드(120)를 호스트하는 기계의 조사에 의해, 및/또는 기계를 호스트하는 대규모 네트워크 시스템의 조사에 의해 획득될 수 있다. 물론, 잘 알 것인 바와 같이, 동적 컨텍스트 추적 모듈(130)에 의해 획득될 수 있는 다수의 컨텍스트 소스(115)가 있다. 실제로, 코드 분석 도구(100) 내의 모듈들[예를 들어, 규칙 실행 모듈(140)] 및/또는 심지어 규칙들 자체는 코드 분석 정보(125)를 제공할 수 있다. 그에 따라, 본 명세서에 기술한 바와 같이 코드 분석 정보(125)를 제공하는 임의의 특정의 장치, 컴포넌트, 모듈, 데이터 객체, 기타 등등은 단지 예시를 위한 것에 불과하며, 명시적으로 청구되지 않는 한, 본 명세서의 실시예들을 제한하거나 다른 방식으로 축소하려는 것이 아니다.
또한 유의할 점은 코드 분석 정보(125)가 요청-응답(request-response), 푸시-풀(push-pull), 퍼브-서브(pub-sub) 시스템, 기타 등등의 수많은 공지의 메카니즘을 통해 동적으로 획득될 수 있다는 것이다. 예를 들어, 일 실시예는 이벤트 통지 시스템을 사용하여 획득되는 코드 분석 정보(125)를 고려하고 있다. 예를 들어, 컨텍스트가 변하거나 타겟 코드(120)의 개발에 영향을 미치는 기타 이벤트가 발생할 때, 통지[통상적으로 코드 분석 정보(125) 형태로 되어 있음]가 동적 컨텍 스트 추적 모듈(130)로 전송될 수 있거나 그에 의해 다른 방식으로 수신될 수 있다. 물론, 코드 분석 정보(125)를 획득하는 수많은 방식이 있다. 그에 따라, 코드 분석 정보(125)가 어떻게 획득되는지에 대한 특정의 언급은 본 명세서에서 단지 예시를 위해 사용될 뿐이며, 명시적으로 청구되지 않는 한, 기술된 실시예들의 범위를 제한하거나 다른 방식으로 축소하려는 것이 아니다.
어쨋든, 앞서 언급한 바와 같이, 동적 컨텍스트 추적 모듈(130)은 검사에 관련된 다수의 분석 컨텍스트를 형식화한다. 그에 따라, 코드 분석 정보(125)가 어디에서 또는 어떻게 획득되는지에 상관없이, 이 정보(125)는 동적 컨텍스트 추적 모듈(130) 내에 정의된(또는 그에 의해 다른 방식으로 획득된) 컨텍스트에 기초하여 현재의 코드 분석 컨텍스트(135)를 판정하는 데 사용될 수 있다. 유의할 점은 현재의 코드 분석 컨텍스트(135)가 상기한 것 등의 수많은 고려사항들로 정의될 수 있다는 것이다. 예를 들어, 이러한 분석 컨텍스트는 타겟 코드(120)의 개발 단계, 타겟 코드(120) 상태, 타겟 코드(120)를 조작하는 소스의 유형, 타겟 코드(120)의 목적, 및/또는 기타 개발 또는 런타임 요건 및 고려사항으로 정의될 수 있다.
유의할 점은 앞서 정의된 분석 컨텍스트가 다양한 계층적 항(예를 들어, 분석이 코드의 작성으로부터 얼마나 떨어져 있는지)으로 표현될 수 있거나 표현될 수 없는 수많은 속성 또는 조건을 포함할 수 있다는 것이다. 예를 들어, 개발 단계로 정의된 코드 분석 컨텍스트는 디자인 단계, 빌드 단계, 디플로이 단계, 또는 다른 단계나 속성을 포함할 수 있다. 게다가, 분석 컨텍스트는 이전의 단계들은 물론 분석이 행해지고 있는 현재의 단계로 정의될 수 있다. 게다가, 각각의 개발 단계 는 또한 기타 서브-단계들을 통해 정의될 수 있다. 예를 들어, 빌드 단계는 편집 단계, 증분 빌드에 대한 컴파일 단계의 서브-단계, 또는 체크인 이전의 서브-단계를 포함할 수 있다. 다른 예로서, 분석 컨텍스트는 통상적으로 코드 자체에 대한 완전한 설명을 제공하지 않는, 소스 코드, 오브젝트 코드, 바이너리 코드, 또는 추상화 코드 상태 등의 그의 상태 또는 유형으로 정의될 수 있다.
또한, 유의할 점은 분석 컨텍스트(들)[예를 들어, 경우에 따라서는 현재의 코드 분석 컨텍스트(135)]가 또한 서로 간의 계층적 관계로 정의될 수 있다는 것이다. 예를 들어, 한 코드 분석 컨텍스트는 다른 분석 컨텍스트의 성공적인(또는 성공적이지 않은) 완료로 정의될 수 있다. 게다가, 고객에게 출시되는 것에 정확하게 대응하거나 대응하지 않을 수 있는 바이너리에 대한 빌드 환경으로 정의된 컨텍스트에 대한 경우와 같이 분석 컨텍스트들 간에 중첩하는 속성들이 있을 수 있다. 물론, 코드 분석 컨텍스트를 정의 또는 형식화하는 수많은 관계가 있다. 그에 따라, 상기한 바와 같이, 용어 "코드 분석 컨텍스트"[예를 들어, 현재의 코드 분석 컨텍스트(135)]는, 본 명세서에 정의된 바와 같이, 임의의 수, 조합 및/또는 계층적 관계의 분석 컨텍스트를 포함하도록 광의적으로 해석되어야만 한다.
정의되어 있는 형식화된 코드 분석 컨텍스트(들)과 상관없이, 현재의 코드 분석 컨텍스트(135)를 판정하기 위해 이러한 컨텍스트 리스트가 코드 분석 정보(125)와 함께 사용된다. 그에 따라, 규칙 관리 모듈(155)은 분석 규칙 저장소(analysis rule store)(170)에 있는 규칙들(175)의 실행을 동적으로 관리하기 위해 현재의 코드 분석 컨텍스트(135)를 사용할 수 있다. 보다 구체적으로는, 규칙 관리 모듈(155)이 현재의 코드 분석 컨텍스트(135)에 대해 실행하도록 설정된 규칙(175)을 동적으로 결정하기 위해, 각각의 분석 규칙(175)(또는 기타 데이터 객체)은 (예를 들어, 메타데이터를 통해) 규칙이 실행될 수 있는 컨텍스트 파라미터(180)를 기술한다. 통상적으로, 이러한 컨텍스트 파라미터(180)는 규칙 개발자에 의해 정의되지만, 실시예들은 또한 규칙 구성 모듈(165)을 사용하여 컨텍스트 파라미터(180)의 수정 및/또는 추가를 가능하게 해주는 것을 생각한다. 더 상세히 기술되는 바와 같이, 규칙들은 또한 기타 다양한 메카니즘을 통해 무시될 수 있다.
어쨋든, 컨텍스트 파라미터(180)는 규칙(175)이 어떤 컨텍스트에 적용될 수 있는지 여부 등의 정보를 포함할 수 있고 및/또는, 예를 들어, 지원됨(supported), 선호됨(preferred), 선택적(optional), 필수적(required), 또는 임의의 다른 공지의 우선순위 부여와 같이, 우선순위가 매겨져 있는 컨텍스트 리스트를 가질 수 있다. 보다 구체적인 예로서, 명명 규칙(naming rule) 및 케이싱 규칙(casing rule)은 모든 분석 단계를 지원하는 것으로 표시될 수 있다(즉, 명명 규칙은 어떤 개발 단계에서도 실행하기에 적합할 수 있다). 그렇지만, 양호한 실행 단계는 백그라운드 기간(background period)일 수 있다. 그에 따라, 이들 검사는 개발자가 소스를 편집하고 있는 동안에 실행되어야만 하지만, 다른 단계들에서도 실행될 수 있다.
게다가, 컨텍스트 파라미터(180)는 분석의 완료를 위한 런타임 기간, 입력할 필요가 있는 정보, 또는 그 결과 얻어지는 출력, 기타 등등의 거동(behavior)으로 규칙을 정의하는 메타데이터를 포함할 수 있다. 그에 따라, 이러한 부가적인 정보는 실행할 필요가 있는 적절한 규칙(150)을 결정하기 위해 규칙 관리 모듈(155)에 의해 (및/또는 현재의 코드 분석 컨텍스트(135)를 판정하기 위해 동적 컨텍스트 추적 모듈(130)에 의해) 사용될 수 있다. 물론, 컨텍스트 파라미터(180)는, 코드 분석 컨텍스트(들)에 대해 상기한 바와 유사한 방식으로, 중첩하는 속성, 계층적 관계, 기타 등등으로 정의될 수 있다. 예를 들어, 일 실시예에서, 규칙의 분석이 현재 지정된 단계와 같거나 그로부터 더 떨어진 어떤 단계에서도 행해질 수 있다. 예를 들어, 백그라운드 컴파일(background compilation) 동안에 실행되도록 구성된 규칙은 빌드(build), 체크인(check-in) 또는 이정표(milestone) 단계 동안에도 실행될 수 있다.
유의할 점은 일반적으로 규칙에 관한 보다 구체적인 지식을 가지고 있는 테스트 개발자가 규칙이 적용되어야만 하는 컨텍스트 파라미터(180)를 고려하고 설정할 수 있는 것이 통상적이라는 것이다. 이러한 고려사항으로는 이하의 것들(특정의 순서로 되어 있을 필요는 없음)이 있을 수 있지만, 그에 한정되는 것은 아니다. 첫째, 이 규칙에 의해 발생된 메시지가 어느 개발 단계 동안에 의미가 있는가? 둘째, 제어를 얼마나 빨리 사용자에게 돌려줘야 하는가? 예를 들어, 코드를 편집하는 동안에 행해지는 분석은 통상적으로 에디터(editor)의 인지된 성능에 영향을 주어서는 안된다. 셋째, 검사를 완료하는 데 얼마나 많은 메타데이터가 필요한가? 예를 들어, 오브젝트 디자인 다이어그램(object design diagram)에 대해 행해지는 분석은 제3자 개발자가 유형(type)을 공개적으로 볼 수 있는지 여부에 관한 정보를 제공하지 않을 수 있다. 넷째, 문제점에 대한 가능한 해결책이 호환을 손상시키는 변화(breaking change)를 구성하는가? 즉, 문제점을 해결하는 것이 수정된 애플리 케이션 프로그램 인터페이스(API)의 이전 버전의 소비자를 중단(break)시키는가? 그렇다면, 이 정보는 개발 프로세스에서 가능한 한 빨리 개발자에게 제공될 필요가 있을 수 있다. 그렇지 않고, 이미 출하된 코드에 대한 호환을 손상시키는 변화가 식별된 경우, 통상적인 해결책은 그 문제를 개발자에게 표면화시키지 않는 것이다(분석이 높은 수준의 후방 호환성을 유지하도록 구성되어 있는 것으로 가정함). 환언하면, 문제가 있는 것이 출하되고 따라서 수정하는 것이 더 이상 안전하지 않은 경우(왜냐하면 이전 버전의 소비자에 대한 중단(break)을 야기할 수 있기 때문임), 결과를 필터링하는 것이 필요하거나 요망될 수 있다. 다섯째, 문제를 해결하는 데 비용이 얼마나 드는가? 얼마나 많은 코드가 변경되는가? 분석에 얼마나 많은 시간이 걸리는가? 변경이 후퇴를 가져올 가능성이 얼마나 되는가? 문제와 관련된 소스 코드가 수정가능한가? 여섯째, 어느 특별한 바이너리, 운영 체제(OS), 기계 및/또는 네트워크 고려사항들이 규칙 거동에 영향을 주는가 및/또는 검사가 실행되어야만 하는가? 일곱째, 어느 특별한 프로젝트 고려사항들이 어떤 분석이 행해지는지에 영향을 주는가 및/또는 어느 결과가 사용자에게 반환되어야 하는가?
그에 부가하여, 앞서 언급한 바와 같이, 본 명세서의 실시예들은 컨텍스트 파라미터(180)이 수정가능하거나 또는 그렇지 않고 구성가능한 것으로 규정한다. 그에 따라, 규칙이 실행될 수 있는 분석 컨텍스트(들)를 확장하거나 다른 방식으로 제한하기 위해 규칙 구성 모듈(165)이 (규칙 및/또는 코드 개발자 중 어느 하나에 의해) 사용될 수 있다. 다른 대안으로서 또는 그에 부가하여, 규칙이 실행될 수 있는 컨텍스트가 구성 설정/제어 파일(160)을 통해 무시될 수 있다. 예를 들어, 규칙들이 IDE(110) 내에서의 명확한 제스처(explicit gesture)와 같은 것들을 통해 또는 분석 실행과 연관된 제어 파일을 수정하는 것에 의해 무시될 수 있다. 그에 따라, 일 실시예는 개발자가 코드 분석 옵션 구성(configure code analysis option)에 액세스할 수 있게 해주며, 이에 의해 개발자는 각각의 규칙과 연관된 일련의 컨텍스트를 무시할 수 있게 된다. 이것 및 다른 정보가 이어서 사용자에 의해 설정된 기타 코드 분석 옵션을 포함하는 프로젝트 파일에 저장될 수 있다.
규칙/컨텍스트의 구성과 관련하여, 본 명세서의 실시예들은 또한 어떤 구성 제스처가 검사와 관련되어 있을 수 있음을 고려하고 있으며, 따라서 본 명세서에서는 더 큰 분석 컨텍스트와 연계될 수 있는 구성 옵션들이 제공된다. 예를 들어, 본 명세서의 실시예들은 규칙이 어떤 방식으로[예를 들어, 0 내지 100% 범위에 있고 사용자에게 제공되는 노브 또는 기타 쓰로틀 제어 메카니즘(throttle control mechanism)에 의해 조정될 수 있는 노이즈 필터 설정] 조절(throttle)될 수 있게 해주어, 검토를 위한 출력을 제한하고, 고확실성 옵션(high certainty options)으로의 출력을 억제하며, 및/또는 분석 시간을 제한한다. 유의할 점은 이러한 규칙 구성 옵션이 시스템에 매끄럽게(seamlessly) 존재해야만 하고 규칙-관련 구성(rule-specific configuration)과 시스템에 의해 정의된 컨텍스트 간의 연계(coupling)가 있을 수 있다는 것이다(예를 들어, 백그라운드 분석을 실행할 때, 노이즈 레벨을 50% 확실성 이상으로 제한함).
다른 실시예들은 또한 분석 컨텍스트 구성가능성(analysis context configurability)을 프로젝트에서의 사람의 역할에 매핑하는 것을 제공한다. 보다 구체적으로는, 소프트웨어 개발 프로젝트에 참여하고 있는 개인들은 통상적으로 (1) 분석 컨텍스트를 암시하는 특정의 시점(specific juncture)에서 코드에 기여를 하고, (2) 결과를 이들에게 다소 의미있게 만들어주는 다양한 전문 지식을 가지고 있으며, (3) 자원이 어디에(또한 아마도 얼마나) 할당되는지에 관한 결정을 하는 다소간의 권한을 가지고 있다. 예를 들어, 개발자는 자기가 책임지고 있는 코드에 대해 여기서의 변경과 관련된 결과를 보아야만 한다. 반면에, 프로젝트 관리자는 특정의 분석에 전용된 개발자/테스트 사이클을 제한하기 위해 결과를 다이얼백(dial back)하도록 허용될 수 있다. 바이너리/제품 완전성(completeness)과 관련된 문제(예를 들어, 모든 바이너리가 존재하는가? 바이러스가 없는가? 오염되지 않았는가? 기타)를 식별하고 교정하는 일을 맡고 있을 수 있지만 정확성(correctness) 문제를 교정할 기술적 역량도 능력도 없는 빌드 관리자(build manager)와 이것을 대조한다. 그에 따라, 본 명세서의 실시예는 본 명세서에 기술된 분석 컨텍스트 구성이 코드 개발 및 런타임 프로세스에 관여하는 팀 및 다른 사람들의 다양한 역할에 자동적으로 매핑될 수 있게 해준다.
규칙 및/또는 분석 컨텍스트가 어떻게 구성되어 있는지에 상관없이, 현재의 코드 분석 컨텍스트(135)와 각각의 규칙(175) 내에 정의된 컨텍스트 파라미터 간의 분석에 기초하여, 및/또는 구성 설정/제어 파일(160)에 기초하여, 규칙 관리 모듈(155)은 실행하기 위한 일련의 규칙(150)을 선택할 수 있다. 그에 따라, 규칙 실행 모듈(140)은 결과(145)를 생성하기 위해 타겟 코드(120)에 대해 일련의 규칙(150)을 적용할 수 있다. 잘 알 것인 바와 같이, 이러한 결과(145)는 분석 컨텍 스트, 적용되는 규칙, 및 기타 인자들과 같은 것들에 따라 크게 달라지게 된다. 예를 들어, 결과(145)는 명명 규약 분석(naming convention analysis)과 같은 것들에 대한 인텔리센스 스퀴글리(intellisense squiggly)로서 소스 코드를 편집하는 사용자에게 즉각 보고될 수 있는 반면, 다른 규칙들(150)은, 어떤 스트레스 테스트에서와 같이, 사용자에 대한 피드백을 전혀 생성하지 않을 수 있다. 다른 결과들(140)은 추가적인 분석을 위해 파일에 보고되고 및/또는 어떤 다른 데이터 형식으로 생성될 수 있다. 물론, 본 명세서에 기술된 실시예들에 적용될 수 있는 수많은 결과들(145)이 있으며, 임의의 기술된 컨텍스트 하에서 생성된 임의의 특정의 결과들은 단지 예시를 위한 것에 불과하며 본 명세서의 실시예들의 범위를 제한하거나 다른 방식으로 축소시키려는 것이 아니다.
이하에서는 타겟 코드의 개발 단계, 타겟 코드의 유형 및/또는 상태, 타겟 코드를 조작하는 소스, 타겟 코드의 목적, 또는 기타 개발 및/또는 런타임 요건들로 정의된 중간 분석 컨텍스트(intermediate analysis context)의 어떤 예들을 제공한다. 상기한 바와 같이, 이하의 설명에서, 이들 중간 분석 컨텍스트는 또한 임의의 조합, 중첩하는 속성들, 및/또는 계층적 관계로 정의될 수 있다. 게다가, 앞서 언급한 바와 같이, 컨텍스트 파라미터(180), 정의된 분석 컨텍스트[예를 들어, 현재의 코드 분석 컨텍스트(135)], 구성 설정/제어 파일(160), 및 규칙 자체는 확장가능하며, 따라서 분석 컨텍스트 및/또는 기술된 규칙들의 이하의 리스트(및 본 명세서에 기술되는 기타 컨텍스트 또는 분석)는 총 망라하는 것으로 보아서는 안된다.
예를 들어, 규칙(175)은, 예를 들어, 개발자에게 소스 코드에 대한 변경을 알려주기 위해 IDE(110)에서의 편집 단계 동안 행해지는 백그라운드 분석의 관점에서 기술될 수 있다. 기타 분석은 컨텍스트 파라미터(180)에 의해 정의되는 각각의 증분 빌드(incremental build) 또는 전체적인 빌드(complete build)와 관련하여 행해질 수 있다. 예를 들어, 컴파일 동안에, 백그라운드 단계 및 컴파일 단계에 대해 정의된 규칙이 실행될 수 있다. 이러한 검사는 명명(naming) 및 케이싱(casing)에 적절할 수 있으며, 일반적으로 극히 성능이 좋고 및/또는 통상 즉각 해결되어야만 하는 심각한 문제에 플래깅하는 고가치 정확성 검사를 나타낸다.
컨텍스트 파라미터(180) 및/또는 현재의 코드 분석 컨텍스트(135)는 체크인 단계 이전에 행해지는 분석으로 정의될 수 있다. 예를 들어, 체크인 이전에, 백그라운드, 컴파일, 및 체크인 단계 규칙들을 롤업(roll up)하는 분석이 행해질 수 있다. 그에 따라, 특정적으로 체크인 단계를 목표로 하는 규칙(175)은 통상적으로 실행하는 데 더 오래 걸리고 통상적으로 공식 소스 베이스(official source base)에 체크인되어서는 안되는 문제점들을 플래깅하는 고가치 규칙(high-value rule)(175)이다.
다른 분석 컨텍스트는 통상적으로 명확한 사용자 제스처로 실행되는 이정표 단계로 실행되는 것으로 정의되거나 플래깅될 수 있다. 그에 따라, 특정적으로 이정표 단계를 목표로 하는 규칙들은 실행 비용이 극히 많이 드는 것일 수 있고, 고수준의 검토를 필요로 하며[즉, 다른 검사들보다 오탐지(false positive) 가능성이 높음] 및/또는 스케쥴 고려사항으로 인해 또는 작업이 일괄 작업(batch)으로 더 쉽 게 달성되기 때문에 지연되는 작업 항목들을 구성한다.
물론, 앞서 언급한 바와 같이, 코드 분석(100)의 환경이 변함에 따라, 규칙(175)이 실행되는 분석 컨텍스트도 역시 변할 수 있다. 예를 들어, 처리 속도가 증가함에 따라, 이정표 단계에서만 이미 실행된 규칙들이 이전의 단계들 중 일부 단계에서 실행될지도 모르는 것으로 판정될 수 있다. 그렇지만, 유의할 점은 분석 컨텍스트를 변경하거나 그에 영향을 줄 수 있는 많은 것들이 있으며, 이 때문에 규칙 구성 모듈(165)이 필요에 따라 시스템을 갱신 및 조정하기 위해 컨텍스트 파라미터(180)[및 현재의 코드 분석 컨텍스트(135)를 생성하는 데 사용되는 분석 컨텍스트의 체계적 서술(formulation)]를 수정하는 데 사용될 수 있다는 것이다.
다른 분석 컨텍스트는 고객에게 출시되는 것에 정확히 대응하거나 대응하지 않을 수 있는 바이너리에 대해 빌드 환경에서 행해지는 분석을 포함할 수 있다. 또한, 고객 런타임 환경에 꼭 대응하는 것은 아닌 구성에서 디플로이되는 바이너리에 대해 행해지는 분석이 있을 수 있다. 게다가, 앞서 언급한 바와 같이, 통상적으로 결과로 얻어지는 코드에 대한 완전한 설명을 제공하지 않는 추상화에 대해 행해지는 분석[디자인시의 분석(design-time analysis) 등]이 있을 수 있다. 다른 분석 컨텍스트가 디스크로 보내질 수 있는 소스 또는 오브젝트 코드에 의해 정의될 수 있다. 다른 분석 컨텍스트(들)는 현재의 빌드가 최적으로 빌드되었는지 등의 컴파일 설정을 고려하거나 참작한다. 바이너리에 대해 행해지는 다른 분석은 비영어 시스템 또는 웹 애플리케이션의 일부로서 디플로이되는 시스템에서 실행되는 것 등의 특정의 코드 목적 또는 런타임 목적을 고려할 수 있다. 그에 따라, 예를 들 어, 지역화되거나 비영어 시스템에서 실행되지 않는 이러한 코드는 세계화/지역화-관련 문제들에 대해 분석되거나 그에 대해 실행되는 규칙을 가질 필요가 없다. 다른 분석 컨텍스트 또는 컨텍스트 파라미터(185)는 인트라넷 서버 등의 특수한 환경에 또는 방화벽의 다른쪽에 디플로이되거나 디플로이되지 않는 바이너리에 대해 행해지는 분석으로 정의될 수 있다. 이러한 규칙은 통상적으로 대규모 네트워크 시스템에 관련된 문제들을 검증하기 위해 특수한 컨텍스트에서 실행된다.
이전에 출하되었거나 출하되지 않았을 수 있는, 또는 제3자에 의해 제공되거나 제공되지 않을 수 있는 코드에 대해 또 다른 컨텍스트 분석이 행해질 수 있다. 예를 들어, 컨텍스트가 제3자로부터 온 것으로 간주되는 경우, 컨텍스트 파라미터(180)로 정의된 바와 같이 바이러스 검사 또는 규칙이 실행될 필요가 있을 수 있다. 외부 또는 내부 고객에 의해 사용되거나 사용되지 않을 수 있는, 또는 비공식 팀 또는 다른 런타임 환경에서의 사용으로 제한될 수 있는 코드에 대해 또 다른 분석이 행해질 수 있다. 분석 컨텍스트는 또한 성능 또는 보안 등의 런타임 특성에 대한 엄격한 요건을 갖거나 갖지 않을 수 있는 타겟에 대한 분석으로 정의될 수 있다. 고급 보안 허가(advanced security permission)(임의적인 디스크 장소에 기록할 수 있는 것)를 필요로 할 수 있는 컴포넌트는 부분적으로 신뢰된 환경을 실행하고 있는 코드보다 덜 보안-관련된 분석을 이용한다. 또 다른 분석 컨텍스트는, 정부-승인을 받은 암호 서비스만이 인정된다는 요건과 같이, 특정의 운영 체제 구성을 갖는 시스템에 디플로이되는 타겟에 대한 분석을 포함한다. 다른 분석 컨텍스트는 유지보수 모드에 있거나 그 모드에 있지 않는 또는 엄중한 인사관리 또는 기 한 고려사항의 구속을 받는 팀에서 개발되는 타겟에 대해 정의될 수 있다.
유의할 점은 분석이 아마도 소스 코드, 바이너리 코드, 또는 어느 쪽과도 연관되지 않은 추상화로부터 수집된 정보를 참조하는 다양한 구조(construct)(즉, 타겟 코드(120))에 대해 행해진다는 것이다(클래스 다이어그램(class diagram)을 분석하는 것, 데이터베이스 테이블의 사용, 데이터베이스 스키마의 유효성을 확인하는 것, 저장 프로시저를 검증하는 것, 명명/케이싱 규약을 데이터베이스-관련 식별자에 적용하는 것, 및/또는 현재의 프로젝트 설정에 기초하여 위반을 발생하는 것 등). 게다가, 취합된 현재 컨텍스트 세트에 관련된 규칙 세트의 구성이 동적으로 행해지는 것이 통상적이다. 그에 따라, 결과가 통상적으로 소프트웨어 개발 라이프-사이클에서 정확하고 적절한 시점에 사용자에게 반환된다. 본 명세서에서 언급한 바와 같이, 올바른 결과 또는 소프트웨어 개발 라이프-사이클에서의 정확하고 적절한 시점은 코드/추상화의 현재 조건, 그의 현재 또는 추정된 기계·운영 체제·네트워크 및/또는 런타임 환경, 보안·신뢰성·후방 호환성 및 문자 그대로의 성능을 비롯한 품질의 측면들에 대한 주어진 프로젝트 요건, 주어진 프로젝트 라이프-사이클·타임라인 및/또는 자원 제약조건, 주어진 분석 시간 제약조건, 결과를 수신하는 사람의 결과를 이해하고 그에 영향을 미치는 주어진 능력, 특정의 검사에 의해 제공되는 주어진 특별한 구성, 또는 기본 구성이 사용자의 순전한 고집을 비롯한 상기하지 않은 어떤 이유로 무시되는 것, 기타 등등과 같은 것들에 따라 변하게 된다. 그에 부가하여, 분석 컨텍스트[예를 들어, 규칙(175), 컨텍스트 파라미터(180), 기타 등등]가 구성가능하고, 확장가능하며, 플러그가능하고, 기타 등등이 가능하기 때문에, 본 명세서에 기술된 실시예들은 분석에 관련된 다수의 중간 컨텍스트를 기술하는 개방형 시스템(open-ended system)을 정의한다.
본 발명은 또한 기능적 단계 및/또는 비기능적 동작을 포함하는 방법으로 기술될 수 있다. 이하는 본 발명을 실시하는 데 수행될 수 있는 단계 및/또는 동작에 대한 설명이다. 보통, 기능적 단계는 본 발명을 달성되는 결과로 기술하는 반면, 비기능적 동작은 특정의 결과를 달성하기 위한 보다 구체적인 동작들을 기술한다. 기능적 단계 및/또는 비기능적 동작이 특정의 순서로 기술되거나 청구될 수 있지만, 본 발명이 반드시 임의의 특정의 순서 또는 조합의 단계 및/또는 동작으로 제한되는 것은 아니다. 게다가, 단계 및/또는 동작의 사용은 청구항들에 (또한 도 2의 흐름도에 대한 이하의 설명에) 열거되어 있으며, 통상적으로 이러한 용어의 원하는 특정의 용도를 나타내기 위해 사용된다.
앞서 언급한 바와 같이, 도 2는 본 발명의 다양한 예시적인 실시예들에 대한 흐름도를 나타낸 것이다. 도 2에 대한 이하의 설명은 때때로 도 1의 대응하는 구성요소를 참조한다. 이 도면의 특정의 구성요소를 참조할 수 있지만, 이러한 참조는 단지 예시를 위해 사용된 것에 불과하며, 명시적으로 청구되지 않는 한, 기술된 실시예의 범위를 제한하거나 다른 방식으로 축소하려는 것이 아니다.
도 2는 성능 고려사항들의 균형을 맞추기 위해, 코드가 개발되고 있는 분석 컨텍스트를 동적으로 추적하고 현재의 컨텍스트 조건에 대응하는 규칙들의 적어도 일부분을 적용하는 것에 의해 일련의 미리 정의된 규칙의 실행을 관리하는 방법(200)의 흐름도를 나타낸 것이다. 방법(200)은 규칙이 타겟 코드에 대해 실행될 수 있는지를 동적으로 판정하는 단계(225)를 포함한다. 보다 구체적으로는, 단계(225)는 분석되어야 하는 타겟 코드를 수신하는 동작(205)을 포함한다. 예를 들어, 컴퓨팅 시스템 내의 코드 분석 도구(100), 규칙 관리 모듈(155), 규칙 실행 모듈(140), 개발 장치(105), 또는 기타 모듈 및 컴포넌트는 사전 정의된 규칙(175)에 기초하여 정확성, 완전성 및/또는 품질에 대해 분석되어야 하는 타겟 코드(120)를 수신할 수 있다.
단계(225)는 또한 코드 분석 정보를 수신하는 동작(210)을 포함한다. 예를 들어, 동적 컨텍스트 추적 모듈(130)은 타겟 코드(120)가 개발 중에 있는 현재의 코드 분석 컨텍스트(135)를 동적으로 추적하기 위해 다양한 개발 장치(105)로부터 코드 분석 정보(125)를 수신할 수 있다. 유의할 점은 현재의 코드 분석 컨텍스트(135)가 타겟 코드 개발 단계, 타겟 코드 유형 또는 상태, 타겟 코드(120)를 조작하는 소스, 타겟 코드(120)의 목적, 또는 하나 이상의 개발 또는 런타임 요건으로 정의될 수 있다는 것이다.
타겟 코드 개발 단계가 정의되어 있는 경우, 이러한 단계는 디자인(design), 빌드(build), 디플로이(deployment), 또는 기타의 단계들을 포함할 수 있다. 또한, 유의할 점은 빌드 단계가 편집 단계, 증분 빌드에 대한 컴파일 단계, 또는 체크인 단계 이전과 같은 것들을 포함할 수 있다는 것이다. 그 자체로서, 이러한 단계에 대해 정의된 규칙들은 아직 컴파일되어 디스크로 보내지지 않은 타겟 코드(120)에 대해 행해지는 백그라운드 분석일 수 있다. 게다가, 유의할 점은, 분석 기간, 요구된 입력, 요구된 출력, 높은 또는 빈번한 오검출(false positive) 빈도, 스케쥴링 고려사항 중 하나 이상의 관점에서의 그의 실행에 요구되는 비용으로 인해 또는 실행이 다른 규칙들을 갖는 배치(batch)의 일부로서 가장 쉽게 달성되기 때문에, 빌드 단계(build stage)가 규칙의 적어도 일부분을 실행하기 위해 특정의 사용자 입력을 필요로 하는 이정표 단계(milestone phase)를 포함할 수 있다는 것이다.
또한, 유의할 점은, 현재의 코드 분석 컨텍스트가 타겟 코드 유형 또는 상태로 정의될 때, 이러한 코드 유형 또는 상태가 소스 코드, 오브젝트 코드, 바이너리 코드 또는 추상화 코드 상태와 같은 것들을 포함한다는 것이다. 추상화 코드 상태의 경우, 이러한 상태는 소스 코드에 대한 완전한 설명을 제공하지 않는 타겟 코드의 디자인시의 분석일 수 있다.
단계(225)는 또한 일련의 사전 정의된 규칙들로부터 선택된 규칙에 대응하는 컨텍스트 파라미터를 수신하는 동작(215)을 포함한다. 예를 들어, 규칙 관리 모듈(155)은 현재의 코드 분석 컨텍스트(135)는 물론 규칙 세트(175)로부터 선택된 하나 이상의 규칙에 대응하는 컨텍스트 파라미터(180) 둘다를 수신할 수 있다. 유의할 점은 컨텍스트 파라미터가 규칙의 적어도 일부분에 대한 실행 조건을 (예를 들어, 메타데이터를 통해) 적어도 코드 분석 컨텍스트 정보로 정의한다는 것이다. 게다가, 컨텍스트 파라미터(180)는 분석의 완료를 위한 런타임 지속 기간, 입력할 필요가 있는 정보, 또는 그 결과 얻어지는 출력 중 하나 이상으로 된 규칙 거동에 관한 메타데이터를 포함할 수 있다. 유의할 점은 규칙의 어느 부분을 적용할지(예를 들어, 그에 대한 결과의 양 또는 유형)가, 규칙 거동에 영향을 주거나 그를 변 경하는 구성 등의 다른 인자들에 기초할 수 있다는 것이다. 앞서 언급한 바와 같이, 이러한 구성은 문자 그대로의 규칙 실행, 노이즈 필터링 또는 기타 제어 메카니즘에 의미가 있는 설정/제어 정보에 기초할 수 있다.
또한, 유의할 점은 컨텍스트 파라미터(180)가 선호됨(preferred), 선택적(optional), 필수적(required), 또는 기타 중 하나 이상에 의해 우선순위가 매겨져 있는 지원되는 코드 분석 컨텍스트의 실행 조건을 정의한다는 것이다. 그럼에도 불구하고, 실행 조건은 하나 이상의 구성 설정 및 다양한 개발 장치(105), 코드 분석 도구(100)와 연관된 제어 파일에 의해 및/또는 컨텍스트 파라미터(180)를 구성가능하도록 해줌으로써 무시될 수 있다. 그에 부가하여, 유의할 점은 컨텍스트 파라미터가 기존의 컨텍스트 조건을 확장할 수 있도록 구성가능할 수 있다는 것이다.
단계(225)는 또한 현재의 코드 분석 컨텍스트를 바탕으로 규칙 컨텍스트 파라미터를 평가하는 동작(220)을 포함한다. 예를 들어, 규칙 관리 모듈(155)은 타겟 코드(120)에 대해 실행하기 위한 규칙(150)의 일부분 또는 그 전체 규칙(150)을 동적으로 결정하기 위해 규칙 컨텍스트 파라미터(180) 및 현재의 코드 분석 컨텍스트(135)를 평가할 수 있다. 유의할 점은 개발 프로세스의 적절한 단계에서 규칙(150)을 적용하기 위해 이러한 평가가 행해질 수 있다는 것이다. 또한, 유의할 점은 현재의 코드 분석 컨텍스트(135)를 바탕으로 한 규칙(175) 컨텍스트 파라미터(180)의 평가가 코드와 분석 컨텍스트 간의 계층적 관계, 일련의 사전 정의된 규칙(175), 또는 그 둘다를 고려할 수 있다는 것이다.
본 발명은 그의 정신 또는 본질적인 특성을 벗어나지 않고 다른 특정의 형태로 구현될 수 있다. 기술된 실시예는 모든 측면에서 제한적인 것이 아닌 단지 예시적인 것으로 간주되어야 한다. 따라서, 본 발명의 범위는 이상의 설명보다는 첨부된 청구항들에 의해 나타내어져 있다. 청구항들의 등가성의 의미 및 범위 내에 속하는 모든 변경이 청구항의 범위 내에 포함되는 것으로 보아야 한다.

Claims (20)

  1. 통상적으로 구성 설정(configuration settings)을 통해 제어되는 모놀리딕 동작(monolithic operation)에 의해 실행되는 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서, 성능 고려사항들의 균형을 맞추기 위해, 코드가 개발되는 분석 컨텍스트를 동적으로 추적하는 것 및 현재의 컨텍스트 조건들에 대응하는 상기 규칙들의 적어도 일부분을 적용하는 것에 의해 상기 일련의 사전 정의된 규칙의 실행을 관리하는 방법으로서,
    일련의 사전 정의된 규칙들에 기초하여 정확성, 완전성 또는 품질 중 하나 이상에 대해 분석되어야 할 타겟 코드를 수신하는 단계,
    상기 타겟 코드가 개발되고 있는 현재의 코드 분석 컨텍스트를 동적으로 추적하기 위해 하나 이상의 개발 장치로부터 코드 분석 컨텍스트 정보를 수신하는 단계,
    상기 일련의 사전 정의된 규칙들로부터 선택된 규칙에 대응하는 컨텍스트 파라미터를 수신하는 단계 - 상기 컨텍스트 파라미터는 상기 규칙의 적어도 일부분에 대한 실행 조건을 상기 코드 분석 컨텍스트 정보로 기술하고 있음 -, 및
    개발 프로세스의 적절한 단계에서 상기 규칙의 적어도 일부분을 적용하기 위해 분석 중인 상기 타겟 코드에 대해 상기 규칙의 상기 적어도 일부분이 실행될 수 있는지를 동적으로 판정하기 위해 상기 현재의 코드 분석 컨텍스트를 바탕으로 상기 규칙 컨텍스트 파라미터를 평가하는 단계를 포함하는, 일련의 사전 정의된 규칙 을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙의 실행을 관리하는 방법.
  2. 제1항에 있어서, 상기 현재의 코드 분석 컨텍스트는 상기 타겟 코드 개발 단계, 상기 타겟 코드 유형 또는 상태, 상기 타겟 코드를 조작하는 소스, 상기 타겟 코드의 목적, 또는 하나 이상의 개발 또는 런타임 요건 중 하나 이상으로 정의되는 것인, 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙의 실행을 관리하는 방법.
  3. 제2항에 있어서, 상기 타겟 코드 개발 단계는 디자인(design), 빌드(build) 또는 디플로이(deployment) 중 하나 이상의 단계를 포함하고,
    상기 코드 유형 또는 상태는 소스 코드, 오브젝트 코드, 바이너리 코드 또는 추상화 코드 상태 중 하나 이상을 포함하는 것인, 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙의 실행을 관리하는 방법.
  4. 제3항에 있어서, 상기 추상화 상태는 상기 타겟 코드에 대한 완전한 설명을 제공하지 않는 상기 타겟 코드의 디자인시의 분석(design-time analysis)인 것인, 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙의 실행을 관리하는 방법.
  5. 제3항에 있어서, 상기 빌드 단계는 아직 컴파일되어 디스크로 보내지지 않은 상기 타겟 코드에 대해 행해지는 백그라운드 분석을 포함하고 또한 편집 단계, 증분 빌드(incremental build)에 대한 컴파일 단계, 또는 체크인 단계 이전 중 하나 이상을 포함하는 것인, 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙의 실행을 관리하는 방법.
  6. 제3항에 있어서, 상기 빌드 단계는 분석 기간, 요구된 입력, 요구된 출력, 높은 오검출 빈도, 스케쥴링 고려사항 중 하나 이상의 관점에서의 그의 실행에 요구되는 비용으로 인해 또는 실행이 다른 규칙들을 갖는 배치(batch)의 일부로서 가장 쉽게 달성되기 때문에, 상기 규칙의 상기 적어도 일부분을 실행하기 위해 특정의 사용자 입력을 필요로 하는 이정표 단계(milestone phase)를 포함하는 것인, 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙의 실행을 관리하는 방법.
  7. 제1항에 있어서, 상기 컨텍스트 파라미터에 대한 상기 실행 조건은 메타데이터에 의해 정의되고,
    상기 메타데이터는 또한 분석의 완료를 위한 런타임 지속 기간, 입력할 필요가 있는 정보, 또는 그 결과 얻어지는 출력 중 하나 이상으로 상기 규칙의 거동을 정의하는 것인, 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙의 실행을 관리하는 방법.
  8. 제1항에 있어서, 상기 컨텍스트 파라미터는 선호됨(preferred), 선택적(optional) 또는 필수적(required) 중 하나 이상에 의해 우선순위가 부여되어 있는 지원되는 코드 분석 컨텍스트들의 실행 조건을 정의하는 것인, 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙의 실행을 관리하는 방법.
  9. 제8항에 있어서, 평가는 상기 하나 이상의 개발 장치들에서의 구성 설정, 상기 코드 분석 도구와 연관된 제어 파일 중 하나 이상을 추가적으로 평가함으로써 상기 실행 조건들을 무시할 수 있게 해주거나, 상기 컨텍스트 파라미터를 구성가능하게 해줄 수 있는 것인, 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙의 실행을 관리하는 방법.
  10. 제1항에 있어서, 상기 규칙 컨텍스트 파라미터는 기존의 컨텍스트 조건들을 확장할 수 있도록 구성가능한 것인, 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙 의 실행을 관리하는 방법.
  11. 제1항에 있어서, 상기 현재의 코드 분석을 바탕으로 한 상기 규칙 컨텍스트 파라미터의 상기 평가는 상기 코드 분석 컨텍스트들 간의 계층적 관계, 상기 일련의 미리 정의된 규칙들, 또는 이들 둘다를 고려하는 것인, 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙의 실행을 관리하는 방법.
  12. 통상적으로 구성 설정(configuration settings)을 통해 제어되는 모놀리딕 동작(monolithic operation)에 의해 실행되는 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구로서,
    상기 코드 분석 도구는, 성능 고려사항들의 균형을 맞추기 위해, 코드가 개발되는 분석 컨텍스트를 동적으로 추적하는 것 및 현재의 컨텍스트 조건들에 대응하는 상기 규칙들의 적어도 일부분을 적용하는 것에 의해 상기 일련의 사전 정의된 규칙의 실행을 관리하도록 구성되어 있으며,
    상기 코드 분석 도구는,
    상기 타겟 코드가 개발되고 있는 현재의 코드 분석 컨텍스트를 판정하는 데 사용되는 코드 분석 컨텍스트 정보를 하나 이상의 개발 장치로부터 수신하는 동적 컨텍스트 추적 모듈,
    상기 현재의 코드 분석 컨텍스트 및 규칙의 적어도 일부분에 대한 실행 조건 들을 상기 코드 분석 컨텍스트 정보로 나타내는 컨텍스트 파라미터를 평가하는 규칙 관리 모듈 - 상기 평가에 기초하여, 상기 규칙 관리 모듈은 정확성, 완전성 또는 품질 중 하나 이상에 대해 분석되어야 하는 타겟 코드에 대해 상기 규칙의 적어도 일부분이 실행될 수 있는지를 동적으로 판정함 -, 및
    상기 규칙의 상기 적어도 일부분이 개발 프로세스의 적절한 단계에서 적용되도록 상기 분석 중인 타겟 코드에 대해 상기 규칙의 상기 적어도 일부분을 실행하는 실행 모듈을 포함하는 것인, 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구.
  13. 통상적으로 구성 설정(configuration settings)을 통해 제어되는 모놀리딕 동작(monolithic operation)에 의해 실행되는 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서, 성능 고려사항들의 균형을 맞추기 위해, 코드가 개발되는 분석 컨텍스트를 동적으로 추적하는 것 및 현재의 컨텍스트 조건들에 대응하는 상기 규칙들의 적어도 일부분을 적용하는 것에 의해 상기 일련의 사전 정의된 규칙의 실행을 관리하는 방법을 구현하는 컴퓨터 프로그램 제품으로서,
    상기 컴퓨터 프로그램 제품은, 상기 컴퓨팅 시스템의 하나 이상의 프로세서에 의해 실행될 때, 상기 컴퓨팅 시스템으로 하여금,
    일련의 사전 정의된 규칙들에 기초하여 정확성, 완전성 또는 품질 중 하나 이상에 대해 분석되어야 할 타겟 코드를 수신하는 단계,
    상기 타겟 코드가 개발되고 있는 현재의 코드 분석 컨텍스트를 동적으로 추적하기 위해 하나 이상의 개발 장치로부터 코드 분석 컨텍스트 정보를 수신하는 단계,
    상기 일련의 사전 정의된 규칙들로부터 선택된 규칙에 대응하는 컨텍스트 파라미터를 수신하는 단계 - 상기 컨텍스트 파라미터는 상기 규칙의 적어도 일부분에 대한 실행 조건을 상기 코드 분석 컨텍스트 정보로 기술하고 있음 -, 및
    개발 프로세스의 적절한 단계에서 상기 규칙의 적어도 일부분을 적용하기 위해 분석 중인 상기 타겟 코드에 대해 상기 규칙의 상기 적어도 일부분이 실행될 수 있는지를 동적으로 판정하기 위해 상기 현재의 코드 분석 컨텍스트를 바탕으로 상기 규칙 컨텍스트 파라미터를 평가하는 단계를
    수행하게 하는 컴퓨터 실행가능 명령어들을 저장하고 있는 하나 이상의 컴퓨터 판독가능 매체를 포함하는 것인, 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙의 실행을 관리하는 방법을 구현하는 컴퓨터 프로그램 제품.
  14. 제13항에 있어서, 상기 현재의 코드 분석 컨텍스트는 상기 타겟 코드 개발 단계, 상기 타겟 코드 유형 또는 상태, 상기 타겟 코드를 조작하는 소스, 상기 타겟 코드의 목적, 또는 하나 이상의 개발 또는 런타임 요건 중 하나 이상으로 정의되는 것인, 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙의 실행을 관리하는 방법 을 구현하는 컴퓨터 프로그램 제품.
  15. 제14항에 있어서, 상기 타겟 코드 개발 단계는 디자인(design), 빌드(build) 또는 디플로이(deployment) 중 하나 이상의 단계를 포함하고,
    상기 코드 유형 또는 상태는 소스 코드, 오브젝트 코드, 바이너리 코드 또는 추상화 코드 상태 중 하나 이상을 포함하는 것인, 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙의 실행을 관리하는 방법을 구현하는 컴퓨터 프로그램 제품.
  16. 제15항에 있어서, 상기 추상화 상태는 상기 타겟 코드에 대한 완전한 설명을 제공하지 않는 상기 타겟 코드의 디자인시의 분석(design-time analysis)인 것인, 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙의 실행을 관리하는 방법을 구현하는 컴퓨터 프로그램 제품.
  17. 제15항에 있어서, 상기 빌드 단계는 아직 컴파일되어 디스크로 보내지지 않은 상기 타겟 코드에 대해 행해지는 백그라운드 분석을 포함하고 또한 편집 단계, 증분 빌드(incremental build)에 대한 컴파일 단계, 또는 체크인 단계 이전 중 하나 이상을 포함하는 것인, 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙의 실행을 관리하는 방법을 구현하는 컴퓨터 프로그램 제품.
  18. 제13항에 있어서, 상기 컨텍스트 파라미터들은 메타데이터를 사용하여 상기 실행 조건들을 기술하고,
    상기 메타데이터는 또한 분석의 완료를 위한 런타임 지속 기간, 입력할 필요가 있는 정보, 또는 그 결과 얻어지는 출력 중 하나 이상으로 상기 규칙의 거동을 기술하는 것인, 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙의 실행을 관리하는 방법을 구현하는 컴퓨터 프로그램 제품.
  19. 제13항에 있어서, 상기 컨텍스트 파라미터는 기존의 컨텍스트 조건들을 확장할 수 있도록 구성가능한 것인, 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙의 실행을 관리하는 방법을 구현하는 컴퓨터 프로그램 제품.
  20. 제13항에 있어서, 상기 현재의 코드 분석을 바탕으로 한 상기 규칙 컨텍스트 파라미터의 상기 평가는 상기 코드 분석 컨텍스트들 간의 계층적 관계, 상기 일련의 미리 정의된 규칙들, 또는 이들 둘다를 고려하는 것인, 일련의 사전 정의된 규칙을 사용하여 소프트웨어를 검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의 사전 정의된 규칙의 실행을 관리하는 방법을 구현하는 컴퓨터 프로그램 제 품.
KR1020087018506A 2006-01-30 2006-12-28 일련의 사전 정의된 규칙을 사용하여 소프트웨어를검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의사전 정의된 규칙의 실행을 관리하는 방법 및 컴퓨터프로그램 제품 KR20080091351A (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/343,691 US8595703B2 (en) 2006-01-30 2006-01-30 Context based code analysis
US11/343,691 2006-01-30

Publications (1)

Publication Number Publication Date
KR20080091351A true KR20080091351A (ko) 2008-10-10

Family

ID=38323645

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020087018506A KR20080091351A (ko) 2006-01-30 2006-12-28 일련의 사전 정의된 규칙을 사용하여 소프트웨어를검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의사전 정의된 규칙의 실행을 관리하는 방법 및 컴퓨터프로그램 제품

Country Status (6)

Country Link
US (2) US8595703B2 (ko)
EP (1) EP1982270B1 (ko)
JP (1) JP5165591B2 (ko)
KR (1) KR20080091351A (ko)
CN (1) CN101589380B (ko)
WO (1) WO2007089349A1 (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101276308B1 (ko) * 2011-02-22 2013-06-18 서울대학교산학협력단 다중 출력 명령어를 지원하는 그래프 기반의 코드 생성 장치 및 그 코드 생성 방법
KR101530132B1 (ko) * 2013-12-10 2015-06-18 한양대학교 산학협력단 기호 실행을 이용하는 바이너리 코드 실행 경로 확장 방법 및 장치
KR20190011265A (ko) * 2016-05-25 2019-02-01 헥사곤 테크놀로지 센터 게엠베하 자본 프로젝트 설계 시스템에 대한 다중-구성요소 설계 제약의 유효성 확인

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8997246B2 (en) * 2005-10-04 2015-03-31 Disney Enterprises, Inc. System and/or method for authentication and/or authorization via a network
US7945905B2 (en) * 2006-06-02 2011-05-17 Accenture Global Services Limited Quality inspector tool
US9645915B2 (en) 2006-12-27 2017-05-09 The Mathworks, Inc. Continuous evaluation of program code and saving state information associated with program code
US8584094B2 (en) * 2007-06-29 2013-11-12 Microsoft Corporation Dynamically computing reputation scores for objects
US8627287B2 (en) * 2007-11-29 2014-01-07 Microsoft Corporation Prioritizing quality improvements to source code
US20100235730A1 (en) * 2009-03-13 2010-09-16 Microsoft Corporation Consume-first mode text insertion
US20100269032A1 (en) * 2009-04-15 2010-10-21 Microsoft Corporation Advanced text completion, such as for markup languages
US8561021B2 (en) * 2010-02-08 2013-10-15 Microsoft Corporation Test code qualitative evaluation
CN101819536B (zh) * 2010-05-14 2012-11-28 西安交通大学 一种面向粒的程序构造方法
US20110307802A1 (en) * 2010-06-10 2011-12-15 Shreyank Gupta Review of requests to modify contextual data of a programming interface
US8966446B1 (en) * 2010-09-29 2015-02-24 A9.Com, Inc. Systems and methods of live experimentation on content provided by a web site
CN102012991A (zh) * 2010-11-09 2011-04-13 北京神舟航天软件技术有限公司 基于静态分析的c语言安全规则检查方法
US20120133579A1 (en) * 2010-11-30 2012-05-31 Microsoft Corporation Gesture recognition management
GB2490702A (en) * 2011-05-10 2012-11-14 Bhaskar Peri Managing the evaluation of computer program code by selecting computer code items and rules to evaluate the items.
US20130019225A1 (en) * 2011-07-11 2013-01-17 Microsoft Corporation Incremental Inferences for Developing Data Models
US20120330878A1 (en) * 2011-06-23 2012-12-27 Microsoft Corporation Conventions for inferring data models
US8914515B2 (en) * 2011-10-28 2014-12-16 International Business Machines Corporation Cloud optimization using workload analysis
US8869106B2 (en) * 2011-12-16 2014-10-21 Microsoft Corporation Language service provider management using application context
US9047413B2 (en) * 2012-10-05 2015-06-02 Software Ag White-box testing systems and/or methods for use in connection with graphical user interfaces
US9092211B2 (en) * 2012-12-13 2015-07-28 Microsoft Technology Licensing, Llc Social-based information recommendation system
US9715440B2 (en) 2012-12-19 2017-07-25 Microsoft Technology Licensing, Llc Test scope determination based on code change(s)
JP6048957B2 (ja) * 2012-12-21 2016-12-21 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ 情報処理装置、プログラム、及び情報処理方法
US9880842B2 (en) * 2013-03-15 2018-01-30 Intel Corporation Using control flow data structures to direct and track instruction execution
US9158922B2 (en) 2013-05-29 2015-10-13 Lucent Sky Corporation Method, system, and computer-readable medium for automatically mitigating vulnerabilities in source code
US9449060B2 (en) * 2013-08-06 2016-09-20 International Business Machines Corporation Post-migration validation of ETL jobs and exception management
US9053235B1 (en) * 2013-10-22 2015-06-09 The Mathworks, Inc. Program code interface for providing program code and corresponding results of evaluating the program code
US9064052B1 (en) * 2013-10-22 2015-06-23 The Mathworks, Inc. Providing intermediate results of evaluating program code that includes a compound statement
US9053228B1 (en) * 2013-10-22 2015-06-09 The Mathworks, Inc. Determining when to evaluate program code and provide results in a live evaluation programming environment
US9792203B2 (en) * 2013-11-14 2017-10-17 Sap Se Isolated testing of distributed development projects
US10275333B2 (en) * 2014-06-16 2019-04-30 Toyota Jidosha Kabushiki Kaisha Risk analysis of codebase using static analysis and performance data
CN105446711B (zh) * 2014-08-08 2018-10-02 国际商业机器公司 获取用于软件开发任务的上下文信息的方法及装置
US9703536B2 (en) 2014-08-11 2017-07-11 International Business Machines Corporation Debugging code using a question and answer system based on documentation and code change records
US9825984B1 (en) 2014-08-27 2017-11-21 Shape Security, Inc. Background analysis of web content
US20160077831A1 (en) * 2014-09-11 2016-03-17 Microsoft Corporation Accurate and performant code design using memoization
US9378013B2 (en) * 2014-11-14 2016-06-28 Semmle Limited Incremental source code analysis
US9262132B1 (en) * 2015-04-13 2016-02-16 Semmle Limited Incremental local source code analysis
US10929008B2 (en) 2015-06-05 2021-02-23 Apple Inc. Touch-based interactive learning environment
US9710364B2 (en) * 2015-09-04 2017-07-18 Micron Technology Licensing, Llc Method of detecting false test alarms using test step failure analysis
US10025765B2 (en) 2015-10-15 2018-07-17 International Business Machines Corporation Context sensitive verification point driven inspection
US9740601B2 (en) 2015-12-01 2017-08-22 International Business Machines Corporation Globalization testing management service configuration
US9767011B2 (en) 2015-12-01 2017-09-19 International Business Machines Corporation Globalization testing management using a set of globalization testing operations
US9959097B2 (en) * 2016-03-09 2018-05-01 Bank Of America Corporation SVN interface system for heterogeneous development environments
US10339032B2 (en) 2016-03-29 2019-07-02 Microsoft Technology Licensing, LLD System for monitoring and reporting performance and correctness issues across design, compile and runtime
US10169210B2 (en) 2016-08-09 2019-01-01 International Business Machines Corporation Association between a test case and source code
US9740543B1 (en) 2016-10-27 2017-08-22 Red Hat, Inc. Multi-endpoint method implementation
US10606729B2 (en) 2017-11-28 2020-03-31 International Business Machines Corporation Estimating the number of coding styles by analyzing source code
JP6890557B2 (ja) * 2018-01-17 2021-06-18 株式会社日立製作所 分析モデル作成システム、プログラミング装置および分析モデル作成方法
US10521335B2 (en) * 2018-01-29 2019-12-31 T-Mobile Usa, Inc. Context-based device testing
CN109062784B (zh) * 2018-07-06 2021-04-27 北京大学 接口参数约束代码入口定位方法与系统
US11106448B2 (en) 2018-08-14 2021-08-31 Red Hal Israel, Ltd. Management of updates to externally managed libraries
US11119901B2 (en) * 2019-02-01 2021-09-14 Micro Focus Llc Time-limited dynamic testing pipelines
US11562136B2 (en) * 2019-06-11 2023-01-24 International Business Machines Corporation Detecting programming language deficiencies cognitively
CN111045608B (zh) * 2019-12-29 2023-12-08 北京浪潮数据技术有限公司 一种有效性代码的查找方法、装置、设备及可读存储介质
US11100009B2 (en) 2020-01-03 2021-08-24 Bank Of America Corporation Intelligent detection and ejection of unused application components
CN111475703B (zh) * 2020-04-28 2023-06-13 深圳市智佳家电子科技有限公司 一种抓取网络特定数据的分析方法

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04367934A (ja) 1991-06-14 1992-12-21 Nec Corp システム設計・開発支援ツール
EP0567137A1 (en) 1992-04-23 1993-10-27 Nec Corporation Protocol data unit encoding/decoding device
US5485618A (en) 1993-12-15 1996-01-16 Borland International, Inc. Methods and interface for building command expressions in a computer system
US5963739A (en) 1996-04-26 1999-10-05 Peter V. Homeier Method for verifying the total correctness of a program with mutually recursive procedures
US5896537A (en) 1996-05-13 1999-04-20 Siemens Corporate Research, Inc. Partition based alias analyzer for pointers
US6149318A (en) 1997-04-15 2000-11-21 Samuel C. Kendall Link-time and run-time error detection, and program instrumentation
WO1998049613A2 (en) 1997-04-30 1998-11-05 Geodesic Systems L.L.C. Automatically-maintained customizable user interfaces
JP3230467B2 (ja) 1997-09-25 2001-11-19 日本電気株式会社 Ｇｄｍｏトランスレータ及びｇｄｍｏトランスレーション方法並びにｇｄｍｏトランスレータプログラムを記録した記録媒体
JP3544462B2 (ja) 1997-10-27 2004-07-21 富士通株式会社 ソースプログラム解析装置およびソースプログラム解析プログラムを記録したコンピュータ読み取り可能な記録媒体
US6047390A (en) 1997-12-22 2000-04-04 Motorola, Inc. Multiple context software analysis
JP2001034461A (ja) 1999-07-23 2001-02-09 Toshiba Corp ソフトウェア構成管理支援装置、その方法およびソフトウェア構成管理支援プログラムを記録したコンピュータ読み取り可能な記録媒体
US6594783B1 (en) 1999-08-27 2003-07-15 Hewlett-Packard Development Company, L.P. Code verification by tree reconstruction
US6353925B1 (en) 1999-09-22 2002-03-05 Compaq Computer Corporation System and method for lexing and parsing program annotations
US7111280B2 (en) 2000-02-25 2006-09-19 Wind River Systems, Inc. System and method for implementing a project facility
US7110936B2 (en) * 2001-02-23 2006-09-19 Complementsoft Llc System and method for generating and maintaining software code
KR100433549B1 (ko) 2002-05-11 2004-05-31 삼성전자주식회사 소프트웨어 분석 방법 및 장치
JP4363868B2 (ja) * 2002-08-23 2009-11-11 株式会社東芝 検索キーワード分析プログラム及びシステム並びに方法
JP2004220269A (ja) 2003-01-14 2004-08-05 Cyx Inc 統合テスト管理システム
JP2004326337A (ja) 2003-04-23 2004-11-18 Mitsubishi Electric Corp コード解析プログラム、コード解析自動化プログラム及び自動コード解析システム
US20050114838A1 (en) * 2003-11-26 2005-05-26 Stobie Keith B. Dynamically tunable software test verification
JP2006018735A (ja) 2004-07-05 2006-01-19 Hitachi Software Eng Co Ltd コーディング規準遵守状況監視システム
US7376935B2 (en) * 2004-10-25 2008-05-20 Microsoft Corporation Design-time system and method to enable programming assistance across languages and compilation boundaries

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101276308B1 (ko) * 2011-02-22 2013-06-18 서울대학교산학협력단 다중 출력 명령어를 지원하는 그래프 기반의 코드 생성 장치 및 그 코드 생성 방법
KR101530132B1 (ko) * 2013-12-10 2015-06-18 한양대학교 산학협력단 기호 실행을 이용하는 바이너리 코드 실행 경로 확장 방법 및 장치
KR20190011265A (ko) * 2016-05-25 2019-02-01 헥사곤 테크놀로지 센터 게엠베하 자본 프로젝트 설계 시스템에 대한 다중-구성요소 설계 제약의 유효성 확인

Also Published As

Publication number Publication date
CN101589380A (zh) 2009-11-25
WO2007089349A1 (en) 2007-08-09
EP1982270A4 (en) 2010-04-07
US20140082595A1 (en) 2014-03-20
US20070180429A1 (en) 2007-08-02
JP5165591B2 (ja) 2013-03-21
EP1982270B1 (en) 2020-06-03
EP1982270A1 (en) 2008-10-22
CN101589380B (zh) 2012-07-04
US8997055B2 (en) 2015-03-31
US8595703B2 (en) 2013-11-26
JP2009525522A (ja) 2009-07-09

Similar Documents

Publication Publication Date Title
KR20080091351A (ko) 일련의 사전 정의된 규칙을 사용하여 소프트웨어를검사하는 코드 분석 도구를 갖는 컴퓨팅 시스템에서 일련의사전 정의된 규칙의 실행을 관리하는 방법 및 컴퓨터프로그램 제품
Gallaba et al. Use and misuse of continuous integration features: An empirical study of projects that (mis) use Travis CI
US8984489B2 (en) Quality on submit process
JP5671207B2 (ja) Ｉｔオペレーション／ポリシーのモデリング方法
TWI453666B (zh) 用於在團隊環境中使用協同開發資訊的方法及電腦可讀取儲存媒體
US20080104573A1 (en) Software build validation before check-in
Martin-Lopez et al. Specification and automated analysis of inter-parameter dependencies in web APIs
US9779009B2 (en) Source code equivalence verification device and source code equivalence verification method
US20070016544A1 (en) Best practices analyzer
US11900080B2 (en) Software development autocreated suggestion provenance
Slaats et al. Open to change: A theory for iterative test-driven modelling
CN108701057B (zh) 用于供应部署管道的计算机可读存储介质、系统和方法
Laranjeiro et al. A technique for deploying robust web services
Meng et al. Automating the assembly of security assurance case fragments
US20200167153A1 (en) Highlight source code changes in user interface
Samuel et al. A novel test case design technique using dynamic slicing of UML sequence diagrams
Gligoric Regression test selection: Theory and practice
US20170185504A1 (en) Scalable points-to analysis via multiple slicing
Atkinson et al. Tool support for iterative software process modeling
Laranjeiro et al. Extending test-driven development for robust web services
Gomes et al. Anticipating identification of technical debt items in model-driven software projects
US20240160442A1 (en) Working context transfer across development environments
Hagberg Improving vulnerability detection using program analysis
Mughal Advancing BDD Software Testing: Dynamic Scenario Re-Usability And Step Auto-Complete For Cucumber Framework
Ramaraj et al. Design optimization metrics for uml based object-oriented systems

Legal Events

Date Code Title Description
A201 Request for examination
SUBM Submission of document of abandonment before or after decision of registration