KR20160058768A

KR20160058768A - 공유 모듈 환경 내의 모듈 특정 트레이싱 기법

Info

Publication number: KR20160058768A
Application number: KR1020167005793A
Authority: KR
Inventors: 데츠오 세토; 알렉산더 지 고나레스; 루셀 크라제크
Original assignee: 컨큐릭스 코포레이션
Priority date: 2013-09-04
Filing date: 2014-03-27
Publication date: 2016-05-25
Also published as: EP3042314A4; KR102202923B1; CN105723357B; WO2015033235A1; EP3042314B1; CN105723357A; EP3042314A1

Abstract

모듈 특정 트레이싱 메커니즘은 모듈 개발자를 대신하여 모듈의 사용을 트레이싱할 수 있다. 모듈은 다수의 애플리케이션 개발자에 의해 이용될 수 있고, 트레이싱 시스템은 상이한 애플리케이션 각각 내의 모듈에 대한 데이터를 수집하고 요약할 수 있다. 데이터는 사용 데이터는 물론 성능 데이터를 포함할 수 있다. 사용 데이터는 모듈이 기동되고 호출될 수 있는 매번에 대한 익명화된 데이터를 포함할 수 있고, 성능 데이터는 처리 시간, 메모리 소비 및 다른 메트릭을 포함할 수 있다. 모듈 특정 트레이싱은 애플리케이션 개발자에 의해 가능화되거나 불능화될 수 있다.

Description

공유 모듈 환경 내의 모듈 특정 트레이싱 기법{MODULE SPECIFIC TRACING IN A SHARED MODULE ENVIRONMENT}

관련 출원에 대한 상호 참조

이 특허 출원은 "Module Specific Tracing in a Shared Module Environment"라는 표제로 2013년 9월 4일 출원된 미국 임시 특허 출원 제61/873,773호, "Tracing System for Application and Module Tracing"라는 표제로 2013년 9월 6일 출원된 미국 임시 특허 출원 제61/874,929호 및 "Module Database with Tracing Options"라는 표제로 2013년 9월 6일 출원된 미국 임시 특허 출원 제61/873,773호(그것들 모두는 그것들이 개시하고 교시하는 전부에 대한 참조로써 본 문서에 의해 명시적으로 포함됨)에 대한 우선권 및 이의 이익을 주장한다.

애플리케이션 트레이싱(application tracing)은 애플리케이션을 이해하고 모니터링하는 하나의 메커니즘(mechanism)이다. 트레이싱은 애플리케이션이 실행되는 동안 데이터를 수집하는 메커니즘이다. 몇몇 쓰임새에서, 애플리케이션 트레이싱은 애플리케이션의 진행중인 수행을 모니터링하기 위해 이용될 수 있다. 다른 쓰임새에서, 애플리케이션 트레이싱은 애플리케이션을 이해하고, 어떠한 문제라도 식별하며, 애플리케이션을 개선하기 위해 개발자에 의해 이용될 수 있다.

많은 컴퓨터 언어 및 커뮤니티에서, 어떤 코드는 모듈, 라이브러리, 또는 다른 재사용가능(reusable) 컴포넌트로서 배포될 수 있다. 이들 모듈은 소스 코드(source code), 중간 코드(intermediate code), 실행가능 코드(executable code), 또는 어떤 다른 형태로서 배포될 수 있으나, 모두 다 많은 상이한 애플리케이션에서 다른 프로그래머에 의해 그 모듈들이 재사용될(reused) 수 있다는 특성을 공유할 수 있다.

모듈 특정 트레이싱 메커니즘(module-specific tracing mechanism)은 모듈 개발자를 대신하여 모듈의 사용(usage)을 트레이싱할(trace) 수 있다. 그 모듈은 다수의 애플리케이션 개발자에 의해 이용될 수 있고, 트레이싱 시스템은 상이한 애플리케이션 각각 내의 그 모듈에 대한 데이터를 수집하고 요약할(summarize) 수 있다. 그 데이터는 사용 데이터(usage data)는 물론 성능 데이터(performance data)를 포함할 수 있다. 사용 데이터는 그 모듈이 기동되고(invoked) 호출될(called) 수 있을 매번에 대한 익명화된 데이터(anonymized data)를 포함할 수 있고, 성능 데이터는 처리 시간, 메모리 소비 및 다른 메트릭(metric)들을 포함할 수 있다. 모듈 특정 트레이싱은 애플리케이션 개발자에 의해 가능화되거나(enabled) 불능화될(disabled) 수 있다.

트레이싱 시스템은 애플리케이션들 및 그것들의 모듈들을 트레이싱할 수 있고, 모듈 특정 데이터(module-specific data)를 다양한 인터페이스들을 통해 이용가능한(available) 것으로 할 수 있다. 트레이싱 시스템은 애플리케이션이 실행되는 동안 트레이서 데이터(tracer data)를 수집할 수 있고, 그 데이터를 애플리케이션 특정(application-specific) 및 모듈 특정(module-specific) 데이터베이스들 내로 전처리할(preprocess) 수 있다. 분석 엔진(analysis engine)은 또한 그 데이터 내로의 애플리케이션 특정 뷰(application-specific view)들 및 모듈 특정 뷰(module-specific view)들을 생성하기 위해 이들 데이터베이스를 분석하고 처리할 수 있다. 애플리케이션 특정 뷰들은 애플리케이션의 개발자를 위해 의도된 것일 수 있는 반면, 모듈 특정 뷰들은 누구에게든 액세스가능한(accessible) 것인 공용 버전(public version) 및 모듈 개발자에게 유용할 수 있는 추가 상세사항을 포함할 수 있는 모듈 개발자 버전(module developer version)을 가질 수 있다.

트레이싱 컴포넌트를 애플리케이션에 추가하는 것에 의해서는 물론, 트레이싱 컴포넌트를 모듈 자체에 추가함으로써 모듈 성능의 데이터베이스가 생성될 수 있다. 모듈은 다수의 애플리케이션에 걸친 재사용(reuse)을 위해 이용가능하게 될 수 있는 재사용가능 코드(reusable code)일 수 있다. 트레이싱이 애플리케이션 레벨(application level)로 수행되는 경우, 각 모듈로부터 수집된 데이터는 모듈 특정 데이터베이스 내에 요약될 수 있다. 모듈 특정 데이터베이스는 애플리케이션 개발자가 다양한 작업을 위해 모듈을 선택하는 데에 도움이 될 수 있는 공용 데이터베이스일 수 있다. 모듈 특정 데이터베이스는 사용 및 성능 데이터는 물론, 안정성(stability) 및 강인성(robustness) 메트릭, 에러 로그, 그리고 유사한 모듈의 분석을 포함할 수 있다. 그 데이터베이스는 웹사이트 또는 다른 저장소(repository)를 통해서 뿐만 아니라, 모듈 서술 페이지 및 저장소 내의 링크를 통해서 액세스될(accessed) 수 있다.

이 개요는 상세한 설명에 추가로 후술되는 개념 중 선택된 것을 단순화된 형태로 소개하기 위해 제공된다. 이 개요는 청구된 대상(claimed subject matter)의 중요 특징 또는 필수적 특징을 식별하도록 의도된 것이 아니며, 청구된 대상의 범주를 한정하는 데에 이용되도록 의도된 것도 아니다.

도 1은 애플리케이션 및 모듈을 트레이싱하기 위한 시스템을 보여주는 실시예의 도해 예시(diagram illustration)이다.
도 2는 애플리케이션 및 모듈 트레이스 데이터(trace data)를 수집하고 볼 수 있는 디바이스가 있는 네트워크 환경을 보여주는 실시예의 도해 예시이다.
도 3은 모듈 트레이스 데이터를 위한 사용자 인터페이스(user interface)를 보여주는 예시적인 실시예의 도해 예시이다.
도 4는 예시적인 트레이스 커버리지 그래프(trace coverage graph)를 보여주는 실시예의 도해 예시이다.
도 5는 예시적인 모듈 토폴로지 그래프(module topology graph)를 보여주는 실시예의 도해 예시이다.
도 6은 애플리케이션을 생성하기 위한 방법을 보여주는 실시예의 흐름도 예시이다.
도 7은 모듈 트레이싱이 있는 애플리케이션 실행을 위한 방법을 보여주는 실시예의 흐름도 예시이다.
도 8은 애플리케이션 트레이싱이 있는 애플리케이션 실행을 위한 방법을 보여주는 실시예의 흐름도 예시이다.
도 9는 트레이서 데이터를 전처리하기 위한 방법을 보여주는 실시예의 흐름도 예시이다.
도 10은 모듈 트레이스 데이터를 처리하기 위한 방법을 보여주는 실시예의 흐름도 예시이다.
도 11은 모듈 데이터에 대한 요청을 처리하기 위한 방법을 보여주는 실시예의 흐름도 예시이다.

모듈 특정 트레이싱 시스템(Module Specific Tracing System)

트레이싱 시스템은 다수의 애플리케이션 내에 포함될 수 있는 모듈에 관한 데이터를 수집할 수 있다. 모듈은 개발자들 사이에 배포될 수 있는 코드(code)의 공유된 세트일 수 있고, 개발자는 자신의 애플리케이션 내에 포함시킬 다양한 모듈을 선택할 수 있다.

모듈 중 몇몇은 트레이싱 메커니즘을 포함할 수 있는데, 이는 모듈의 동작을 트레이싱하고 트레이서 데이터를 저장할 수 있다. 트레이서 데이터는 사용 데이터를 포함할 수 있는데, 이는 이용의 횟수, 이용에 대한 타임스탬프, 모듈이 이용된 조건, 그리고 다른 사용 데이터를 기술할 수 있다. 트레이서 데이터는 또한 성능 데이터, 예를 들어 실행하는 데 걸린 시간의 양, 실행 동안에 소비되는 계산상 리소스, 메모리 리소스, 네트워크 리소스, 또는 다른 리소스의 양을 포함할 수 있다.

모듈 특정 트레이싱 시스템은 모듈 개발자를 위해 그리고 다른 사용자를 위해 원 데이터(raw data)를 통합할(consolidate) 수 있다. 몇몇 실시예는 모듈 개발자를 위한 데이터의 상세화된 뷰(detailed view) 및 다른 사용자를 위한 덜 상세화된 뷰(less detailed view)를 포함할 수 있다. 모듈 개발자는 미흡하게 실행되고 있거나 어떤 다른 문제점을 가질 수 있는 모듈의 부분을 식별하는 데에 트레이서 데이터를 이용할 수 있다. 다른 사용자는 모듈의 성능의 일반적인 관념(notion)을 판정하기 위해 모듈 트레이싱 데이터를 검사할 수 있고, 하나의 모듈을 다른 것을 두고 비교 및 선택하기 위한 기준의 일부로서 트레이싱 데이터를 이용할 수 있다.

하나의 이용 시나리오에서, 모듈 개발자는 모듈 내에 트레이싱 메커니즘을 포함시킬 수 있다. 트레이싱 메커니즘은 모듈의 한도 내에서 동작하고 모듈 내의 코드를 트레이싱할 뿐일 수 있다. 많은 경우에, 트레이싱 메커니즘은 모듈이 실행되었던 환경에 관한 일부 메타데이터(metadata)를 모으는 것이 가능할 수 있다.

트레이싱 메커니즘은 모듈이 애플리케이션 내에서 실행되는 동안 트레이싱 데이터를 모을 수 있다. 트레이싱 메커니즘은 트레이싱 데이터를 분석을 위해 데이터베이스로 송신할 수 있다. 많은 경우에, 트레이싱 메커니즘이 처음에 모듈 개발자에 의해 포함되고 구성되었을 수 있을지라도, 애플리케이션 개발자는 트레이싱 메커니즘을 끌(turn off) 옵션을 가지거나 트레이싱 메커니즘에 대한 다양한 옵션을 설정할 수 있다.

이용 시나리오에서, 트레이싱 메커니즘은 모듈 개발자가 모듈을 개선하는 데에 이용할 수 있는 사용 및 성능 데이터를 모을 수 있다. 이들 트레이서 데이터는 모듈 개발자가 모듈의 어느 부분이 다른 것보다 더 빈번히 이용되는지 이해하는 것을 도울 수 있는데, 이는 모듈 개발자가 가장 많이 이용된 부분을 개선하기를 우선시하는 것을 도울 수 있다. 트레이서 데이터는 또한 다른 코드보다 덜 신뢰할 만한 코드를 식별하는 데에 도움이 될 수 있고, 그 데이터는 개별 기능(function)의 강인성 또는 취약성(fragility) 측정을 생성하는 데에 이용될 수 있다.

다른 이용 시나리오에서, 애플리케이션 개발자는 특정한 애플리케이션 내에서 모듈을 사용할지 여부를 판단하기(gauge) 위해 모듈 특정 데이터를 액세스할 수 있다. 개발자는 특정한 목적에 기여할 수 있는 여러 모듈을 식별하였을 수 있고, 이후 모듈들 중에서 선택하기 위한 하나의 메트릭으로서 트레이서 데이터를 이용할 수 있다. 애플리케이션 개발자는 성능 및 사용 데이터를 봄으로써 모듈의 신뢰성(reliability) 및 강인성을 조사할 수 있다.

애플리케이션 및 모듈 트레이싱을 위한 트레이싱 시스템(Tracing System for Application and Module Tracing)

트레이싱 시스템은 몇몇 차이가 있기는 한 유사한 기법 및 메커니즘을 사용하여 애플리케이션 및 모듈에 대한 트레이싱을 제공할 수 있다. 트레이싱 시스템은 애플리케이션이 실행되는 동안 트레이싱 데이터를 모을 수 있고, 해당 데이터는 애플리케이션 개발자, 모듈 개발자, 그리고 잠재적인 모듈 사용자인 더 광범위한 관람자층(audience)과 공유될 수 있다. 몇몇 경우에, 더 광범위한 관람자층은 일반 대중일 수 있다.

세 관람자층 각각은 상이한 보안 문제(security concern)들 및 트레이서 데이터에 대한 상이한 용도들을 가질 수 있다. 애플리케이션 개발자는 애플리케이션을 영업 비밀로서 여길 수 있고, 어떤 트레이서 정보가 애플리케이션을 개발하는 팀의 외부에 공유되는 것을 바라지 않을 수 있다. 모듈 개발자는 모듈이 어떻게 수행되는지에 대한 데이터를 수집하기를 바랄 수 있지만, 동작의 몇몇 상세사항이 일반 공중에 개시되는 것을 바라지 않을 수 있다. 일반 대중은 자기 자신의 애플리케이션을 제작하고 있을 수 있는 개발자를 포함할 수 있고, 이들 개발자는 모듈이 그들의 이용에 적합한지 여부를 판정하기 위해 모듈 특정 데이터를 보기를 바랄 수 있다.

애플리케이션 개발자는 트레이싱이 자신의 애플리케이션 상에서 수행되기를 요청할 수 있다. 그러한 트레이싱 데이터는 전유적(proprietary)일 수 있는 트레이싱 정보, 예를 들어 애플리케이션에 의해 다루어지는 데이터 요소의 값, 애플리케이션 아키텍처 및 기능, 애플리케이션의 소스 코드, 그리고 다른 정보를 포함할 수 있다. 애플리케이션 개발자는 이것을 비밀 또는 전유적인 것으로 간주할 수 있기 때문에, 그러한 정보는 처리되어 데이터베이스 내에 저장될 수 있는데 그것은 모듈 개발자 및 일반 대중과 공유될 수 있는 데이터와 별개일 수 있다.

각 모듈에 대해 수집되는 데이터는 애플리케이션이 실행되는 경우에 수집될 수 있다. 따라서, 모듈 특정 데이터 수집은 이용가능한 데이터의 서브세트(subset)일 수 있는데 모듈 특정 데이터는 애플리케이션 개발 팀이 아닌 다른 당사자일 수 있는 모듈 개발자와 공유될 수 있기 때문이다. 몇몇 경우에, 모듈 개발자는 자기의 애플리케이션 내에서 모듈을 이용할 수 있는 자를 알지 못하고서 모듈을 생성하고 유포할(disseminate) 수 있는 제3자일 수 있다.

모듈 특정 데이터는 애플리케이션을 실행하는 것의 일부로서 수집될 수 있으나, 애플리케이션 개발자가 수집되도록 허용할 수 있는 데이터의 해당 서브세트만 실제로 수집될 수 있다. 많은 경우에, 애플리케이션 개발자는 어떤 유형의 데이터가 수집될 수 있게 하거나 그렇지 못하게 할 수 있는 구성 설정의 세트를 가질 수 있다. 몇몇 경우에, 어떤 데이터 요소는 모듈 특정 트레이싱을 위해서는 전혀 수집되지 않을 수 있다.

몇몇 경우에, 애플리케이션 개발자는 애플리케이션 레벨 트레이싱을 불능화하거나 이를 설치하지 않을 수 있지만 모듈 개발자로 하여금 모듈이 애플리케이션 내에서 실행될 때 트레이서 데이터를 수집하도록 허용할 수 있다. 그러한 상황에서, 애플리케이션은 트레이싱 없이 실행될 수 있으나, 모듈이 실행되는 경우, 트레이싱은 모듈 내에서만 일어날 수 있다. 그러한 모듈 특정 트레이싱은 처리되고 모듈 개발자에게, 그리고 몇몇 경우에는 더 광범위한 관람자층에게, 이용가능한 것이게 될 수 있다. 그러한 경우에, 모듈 특정 트레이싱은 만약 애플리케이션 개발자가 전체 애플리케이션에 대해 트레이싱을 가능화한 경우보다는 범주에 있어서 훨씬 더 한정될 수 있다.

애플리케이션 개발자가 전체 애플리케이션에 대한 트레이싱을 가능화하고 개별 모듈에 대한 트레이싱을 허용하는 경우, 애플리케이션 개발자는 각 모듈에 관련된 데이터의 완전한 세트를 보는 것이 가능할 수 있는데, 데이터의 서브세트는 모듈 특정적인 방식으로 송신되고 처리된다. 이러한 상황에서, 애플리케이션 개발자는 모듈 개발자가 액세스할 수 있을 특정 모듈에 대한 데이터의 수퍼세트(superset)로의 액세스를 가질 수 있다.

트레이싱 옵션이 있는 모듈 데이터베이스(Module Database with Tracing Options)

모듈 데이터베이스(module database)는 모듈의 서술을 수식하는(decorate) 데에 트레이싱 데이터를 이용할 수 있다. 모듈 데이터베이스는 애플리케이션 내에 포함될 수 있는 다양한 모듈을 나열할(list) 수 있다. 수식은 성능 및 사용 데이터는 물론, 모듈을 평가하는 것 및 모듈을 서로에 대해 비교하는 것에 유용할 수 있는 요약 및 다른 데이터를 포함할 수 있다.

모듈 데이터베이스는 애플리케이션이 모듈을 실행하는 동안 모아진 트레이서 데이터를 분석함으로써 구축될(constructed) 수 있다. 트레이서(tracer)는 실행 동안에 모듈에 대한 성능 및 사용 데이터를 모을 수 있고, 이들 데이터는 사용자가 훑어보도록(browse) 취합되고, 요약되며, 디스플레이될 수 있다.

트레이서 데이터는 제3자에 의한 모듈에 실제 사용은 물론, 모듈이 다양한 애플리케이션 내에 포함되었던 방식을 포함할 수 있다. 애플리케이션 개발자는 모듈을 선택하고 이용할 수 있지만, 모듈의 기능성의 서브세트를 행할 뿐일 수 있다. 많은 경우에, 모듈은 많은 상이한 기능, 방법, 객체, 또는 다른 컴포넌트를 가질 수 있지만, 애플리케이션 개발자는 컴포넌트의 하나의 작은 서브세트를 이용할 수 있다.

제3자 사용은 애플리케이션이 최종 사용자(end user)에 의해 이용되는 경우에 모아질 수 있다. 예컨대, 애플리케이션은 데이터센터(datacenter)내의 서버 상에서 실행되는 백엔드(backend) 컴포넌트와 함께 모바일 디바이스 상에서 구동되는 앱(app)으로 이루어질 수 있다. 최종 사용자는 많은 상이한 방식으로 애플리케이션을 행할 수 있는데, 그 중 몇몇은 모듈을 행할 수 있고, 그 중 몇몇은 그렇지 않을 수 있다.

사용 데이터는 모듈의 다양한 컴포넌트의 인기도(popularity) 및 유용성(usefulness)을 반영할 수 있다. 이들 데이터가 모듈 개발자에게 또는 다른 애플리케이션 개발자에게 제시될 수 있는 경우, 데이터는 인기도 점수 또는 백분율로서 배열될(arranged) 수 있다.

사용 데이터는 어느 애플리케이션이 계속해서 모듈을 사용하는지 및 어느 모듈이 다양한 애플리케이션에서 포함되고 제거되고 있는지를 판정하기 위해 시간에 걸쳐 추적될(tracked) 수 있다. 많은 경우에, 애플리케이션 개발자는 모듈을 선택하고, 단기간 동안에 모듈을 이용하며, 이후 다른 모듈로 전환할(switch) 수 있다. 그러한 상황에서, 애플리케이션 개발자는 한 모듈에서 다른 모듈로 전환하기 위해 의도적 결정(conscious decision)을 행하였는데, 제1 모듈에 우선하여 제2 모듈에 대한 애플리케이션 개발자의 선호를 나타낸다. 이 선호는 제1 모듈의 이용을 고려하고 있을 수 있는 다른 애플리케이션 개발자에게 가치 있을 수 있다.

모듈 내의 다양한 기능 또는 컴포넌트에 대한 성능 데이터는 각 기능에 대한 신뢰성 또는 강인성 메트릭을 개발하는 데에 이용될 수 있다. 신뢰성 또는 강인성 메트릭은 기능이 얼마나 취약할 수 있는지의 지시자(indicator)일 수 있고 애플리케이션 개발자에게는 자신의 애플리케이션 내에의 포함을 위해 특정 기능을 선택하는 경우에 유용할 수 있다. 신뢰성 또는 강인성 메트릭은 성능 메트릭 또는 다른 인자의 분산(variance)에 기반할 수 있다.

모듈 데이터베이스는 모듈의 아키텍처의 그래픽적이거나 다른 지시자를 포함할 수 있다. 많은 경우에, 모듈은 애플리케이션이 실행되는 경우 각각 기동될 수 있는 여러 다른 모듈을 포함할 수 있다. 그러한 복잡한 상호작용은 소스 코드를 판독하는 것으로부터 또는 다른 소스로부터 선뜻 명백하지 않을 수 있다. 모듈의 그래픽 표현(graphical representation)은 애플리케이션 개발자에게 모듈 및 다양한 종속체(dependency)들의 복잡도의 시각적 표시(visual indication)를 줄 수 있다.

모듈 데이터베이스는 주어진 모듈에 대한 데이터를 생성하기 위해 모듈의 종속체에 관한 다양한 메트릭을 모아들이거나(roll up) 취합할(aggregate) 수 있다. 모듈의 다양한 이용 및 성능 데이터는 기저의(underlying) 기능을 실제로 수행하는 다양한 모듈에 배분될(apportioned) 수 있다. 예컨대, 모듈은 어떤 작업을 수행하기 위해 제2 모듈을 호출할(call) 수 있고, 그 작업들 중 하나는 제3 모듈에 의해 수행될 수 있다. 그러한 경우에, 제1 모듈의 기능은 제2 및 제3 모듈의 기능, 그리고 종속체 각각으로부터 수집된 데이터와 함께 디스플레이될 수 있다.

이 명세서 및 청구항을 통틀어, 용어 "모듈"은 애플리케이션 내에 포함될 수 있는 재사용가능 코드의 그룹을 정의하는 데에 이용된다. 모듈은 '라이브러리'(library), '서브루틴'(subroutine), 또는 어떤 다른 관념으로 알려질 수 있다. 이 명세서 및 청구항의 목적을 위하여, 이들 용어는 동의어로 간주된다.

"모듈"은 다수의 애플리케이션이 서로와의 연결을 전혀 갖지 않을 수 있더라도 그 애플리케이션들이 코드를 액세스할 수 있는 방식으로 배열된 코드일 수 있다. 일반적으로, "모듈"은 재사용되도록 구성된 코드일 수 있다. 몇몇 경우에, 모듈은 커다란 애플리케이션의 범주 내에서 재사용될 수 있으나, 다른 경우에, 모듈은 이질적이고 연결되지 않은 애플리케이션 내에서 모듈을 이용할 수 있는 다른 애플리케이션 개발자에게 공유될 수 있다.

많은 프로그래밍 언어 및 패러다임은 "모듈" 또는 라이브러리의 관념을 가지는데, 여기서 모듈은 정의된 인터페이스(이를 통해 애플리케이션이 모듈을 기동하고 이용할 수 있음)를 가질 수 있다. 몇몇 패러다임은 애플리케이션이 작성되고 배치된 후에 모듈 코드가 더 변경되지 않도록, 프로그래머로 하여금 정적 방식으로 모듈을 포함시킬 수 있도록 할 수 있다. 몇몇 패러다임은 동적 라이브러리를 가능하게 할 수 있는데, 이는 런타임(runtime)에 또는 심지어 실행이 시작된 후에도 로딩되고(loaded) 기동될 수 있다. 동적 라이브러리는 애플리케이션이 배포될 수 있었던 후에 업데이트되고 변경될 수 있으나, 라이브러리 또는 모듈을 기동하는 방식은 동일하게 남아 있을 수 있다.

모듈은 소스 코드, 중간 코드, 실행가능 코드로, 또는 어떤 다른 형태로 배포될 수 있다. 몇몇 경우에, 모듈은 애플리케이션 프로그래밍 인터페이스(application programming interface)를 통해 기동될 수 있는 서비스일 수 있다.

이 명세서 및 청구항을 통틀어, 용어 "프로파일러"(profiler), "트레이서"(tracer) 및 "계측"(instrumentation)은 상호교환가능하게(interchangeably) 이용된다. 이들 용어는 애플리케이션이 실행되는 경우에 데이터를 수집할 수 있는 임의의 메커니즘을 나타낸다. 전형적인 정의에서, "계측"은 스텁(stub)이나 후크(hook), 또는 실행가능 코드 내에 삽입되고 이로써 실행가능 코드를 변경할 수 있는 다른 데이터 수집 메커니즘을 나타낼 수 있는 반면, "프로파일러" 또는 "트레이서"는 전형적으로는 실행가능 코드를 변경하지 않을 수 있는 데이터 수집 메커니즘을 나타낼 수 있다. 이들 용어 및 그것들의 파생물들 중 임의의 것의 이용은 다른 것을 함축하거나 암시할 수 있다. 예컨대, "트레이서"를 이용하는 데이터 수집은 실행가능 코드가 변경될 수 있는 "계측"의 전형적인 정의를 이용하는 데이터 수집뿐만 아니라 "트레이서"의 전형적인 의미에서 비접촉(non-contact) 데이터 수집을 이용하여 수행될 수 있다. 유사하게, "계측"을 통해 수집된 데이터는 비접촉 데이터 수집 메커니즘을 이용하는 데이터 수집을 포함할 수 있다.

또한, "프로파일링"(profiling), "트레이싱" 및 "계측"을 통해 수집된 데이터는, 처리 시간, 처리율(throughput), 성능 카운터(performance counter) 및 유사한 것과 같은 성능 관련 데이터(performance related data)를 포함하여, 수집될 수 있는 임의의 유형의 데이터를 포함할 수 있다. 수집된 데이터는 기능 명칭, 넘겨지는 파라미터, 메모리 객체 명칭 및 내용, 넘겨지는 메시지, 메시지 내용, 레지스트리 설정, 레지스터 내용, 에러 플래그, 인터럽트, 또는 트레이싱되는 애플리케이션에 관한 임의의 다른 파라미터 또는 다른 수집가능 데이터를 포함할 수 있다.

이 명세서 및 청구항을 통틀어, 명칭 "실행 환경"(execution environment)은 애플리케이션을 실행하는 데에 이용되는 임의의 유형의 지원 소프트웨어를 나타내는 데에 이용될 수 있다. 실행 환경의 일례는 운영 체제(operating system)이다. 몇몇 예시에서, "실행 환경"은 운영 체제와 별개로 도시될 수 있다. 이것은 애플리케이션을 위해 다양한 지원 기능을 제공하는 가상 머신(virtual machine), 예를 들어 프로세스 가상 머신을 예시하는 것일 수 있다. 다른 실시예에서, 가상 머신은 그것 자신의 내부 운영 체제를 포함할 수 있고 전체 컴퓨터 시스템을 시뮬레이팅할(simulate) 수 있는 시스템 가상 머신일 수 있다. 이 명세서 및 청구항을 통틀어, 용어 "실행 환경"은 운영 체제 및 다른 시스템(쉽게 식별가능한 "가상 머신" 또는 다른 지원 소프트웨어를 가질 수 있거나 갖지 않을 수 있음)을 포함한다.

이 명세서 및 청구항을 통틀어, 용어 "애플리케이션"은 원하는 기능을 수행할 수 있는 소프트웨어 및 하드웨어 제품의 임의의 조합을 나타내는 데에 이용된다. 몇몇 경우에, 애플리케이션은 하드웨어 플랫폼과 함께 동작하는 단일 소프트웨어 프로그램일 수 있다. 몇몇 애플리케이션은 다수의 소프트웨어 컴포넌트를 이용할 수 있는데, 이들 각각은 상이한 언어로 작성될 수 있거나 상이한 하드웨어 또는 소프트웨어 실행 환경 내에서 실행될 수 있다. 몇몇 경우에, 그러한 애플리케이션은 다수의 디바이스에 걸쳐 분산될 수 있으며 네트워크 또는 다른 통신 시스템에 의해 연결될 수 있는 소프트웨어 및 하드웨어 컴포넌트를 이용할 수 있다.

이 명세서를 통틀어, 유사한 참조 번호는 도면의 설명을 통틀어 동일한 구성요소를 뜻한다.

명세서 및 청구항에서, "프로세서"에 대한 참조는 다수의 프로세서를 포함한다. 몇몇 경우에, "프로세서"에 의해 수행될 수 있는 프로세스는 실제로 동일한 디바이스 상의 또는 상이한 디바이스 상의 다수의 프로세서에 의해 수행될 수 있다. 이 명세서 및 청구항의 목적을 위하여, "프로세서"에 대한 임의의 참조는, 달리 분명히 명기되지 않는 한, 동일한 디바이스 또는 상이한 디바이스 상에 있을 수 있는 다수의 프로세서를 포함할 것이다.

구성요소가 "연결된"(connected) 또는 "커플링된"(coupled) 것으로 지칭되는 경우, 구성요소는 함께 직접적으로 연결되거나 커플링될 수 있거나 하나 이상의 개재(intervening) 구성요소가 존재할 수도 있다. 반대로, 구성요소가 "직접적으로 연결된" 또는 "직접적으로 커플링된" 것으로 지칭되는 경우, 존재하는 개재 구성요소가 전혀 없다.

청구대상(subject matter)은 디바이스, 시스템, 방법 및/또는 컴퓨터 프로그램 제품으로서 실체화될(embodied) 수 있다. 따라서, 청구대상의 일부 또는 전부는 (펌웨어, 상주 소프트웨어(resident software), 마이크로코드(microcode), 상태 머신, 게이트 어레이 등등을 포함하여) 소프트웨어로 및/또는 하드웨어로 실체화될 수 있다. 나아가, 청구대상은 컴퓨터 사용가능(computer-usable) 또는 컴퓨터 판독가능(computer-readable) 저장 매체(명령어 실행 시스템과 관련한 또는 이에 의한 이용을 위해 매체 내에 실체화된 컴퓨터 사용가능 또는 컴퓨터 판독가능 프로그램 코드를 가짐) 상의 컴퓨터 프로그램 제품의 형태를 취할 수 있다. 이 문서의 맥락에서, 컴퓨터 사용가능 또는 컴퓨터 판독가능 매체는 명령어 실행 시스템, 장치, 또는 디바이스에 의한 또는 이와 관련한 이용을 위해 프로그램을 포함하거나, 저장하거나, 통신하거나, 전하거나, 전송할 수 있는 임의의 매체일 수 있다.

컴퓨터 사용가능 또는 컴퓨터 판독가능 매체는, 예컨대 전자(electronic), 자기(magnetic), 광학(optical), 전자기(electromagnetic), 적외선(infrared) 또는 반도체(semiconductor) 시스템, 장치, 디바이스 또는 전파 매체(propagation medium)일 수 있으나, 이에 한정되지 않는다. 한정이 아니고 예로서, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있다.

컴퓨터 저장 매체들은 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 다른 데이터와 같은 정보의 저장을 위해 임의의 방법 또는 기술로 구현된 휘발성(volatile) 및 비휘발성(nonvolatile), 탈착가능(removable) 및 비탈착가능(non-removable) 매체들을 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리(flash memory) 또는 다른 메모리 기술, CD-ROM, 디지털 다기능 디스크(Digital Versatile Disk: DVD) 또는 다른 광학 스토리지(storage), 자기 카세트, 자기 디스크 스토리지 또는 다른 자기 저장 디바이스, 또는 원하는 정보를 저장하는 데에 이용될 수 있고 명령어 실행 시스템에 의해 액세스될 수 있는 임의의 다른 매체를 포함하나, 이에 한정되지 않는다. 프로그램은, 예를 들면 종이 또는 다른 매체의 광학 스캐닝(scanning)을 통하여, 전자적으로 포착되어(captured), 필요하다면 이후 컴파일링되거나(compiled), 해석되거나(interpreted), 그렇지 않으면 적합한 방식으로 처리되고, 이후 컴퓨터 메모리 내에 저장될 수 있으므로, 컴퓨터 사용가능 또는 판독가능 매체는 프로그램이 프린팅되는 종이 또는 다른 적합한 매체일 수 있음에 유의하시오.

대상이 컴퓨터 실행가능(computer-executable) 명령어의 일반적 맥락에서 실체화되는 경우, 실시예는 하나 이상의 시스템, 컴퓨터 또는 다른 디바이스에 의해 실행되는 프로그램 모듈을 포함할 수 있다. 일반적으로, 프로그램 모듈은 특정한 작업을 수행하거나 특정한 추상적 데이터 유형을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등등을 포함한다. 통상적으로, 프로그램 모듈의 기능성은 다양한 실시예에서 요망되는 바와 같이 조합되거나 분배될 수 있다.

도 1은 트레이서 데이터 수집 시스템(tracer data collection system)을 보여주는 예시적인 실시예(100)의 예시이다. 실시예(100)는 애플리케이션으로부터 트레이서 데이터를 수집하는 프로세스의 개관일 수 있다. 트레이서 데이터는 애플리케이션 특정 또는 모듈 특정 분류에 속할 수 있고, 분류에 기반하여 상이하게 다루어질 수 있다.

트레이서는 개별 모듈 또는 전체로서의 애플리케이션 내에 포함될 수 있다. 트레이서 출력(tracer output)은 모듈 데이터베이스를 실장하는(populate) 데에 이용될 수 있는데, 이는 애플리케이션 개발자에 의해 자신의 애플리케이션을 위해 모듈을 평가하고, 비교하고, 선택하는 데에 이용될 수 있다. 모듈 데이터베이스는 각 모듈(이에 대하여 트레이싱 시스템이 데이터를 모았음)에 대한 레코드(record)들을 포함할 수 있다.

몇몇 용례에서, 모듈 개발자는 트레이싱 메커니즘을 모듈 내에 포함시킬 수 있다. 그러한 경우에, 모듈이 애플리케이션 내에 포함되고 실행될 때마다, 임베딩된(embedded) 트레이서는 해당 모듈에 대한 데이터를 수집할 수 있다. 트레이서가 달리 구성되지 않는 한, 트레이서는 해당 모듈에 대해 데이터를 모을 수 있으나 애플리케이션의 나머지에 대해서는 그렇지 않을 수 있다.

트레이서 데이터는 다수의 방식으로 액세스될 수 있다. 모듈 개발자는 자신의 모듈에 대한 트레이서 데이터를 액세스하고, 모듈에 대한 트레이서 데이터의 서브세트로의 액세스를 가질 수 있는 일반 공중보다는 더 상세화된(detailed) 트레이서 데이터를 볼 수 있다. 애플리케이션 개발자는 모듈 개발자 또는 일반 공중에게 이용가능한 것인 데이터보다는 더욱 상세화될 수 있는 애플리케이션 특정 데이터(application-specific data)를 액세스할 수 있다.

전술된 바와 같이, 세 부류의 관람자층은 상이한 보안 문제 및 데이터의 상이한 용도를 가질 수 있다. 애플리케이션 개발자에 있어서, 애플리케이션은 애플리케이션 개발자가 공유하기를 바라지 않을 수 있는 영업 비밀이나 다른 정보를 포함할 수 있는 전유 프로젝트(proprietary project)일 수 있다. 이 애플리케이션 특정 데이터는, 예컨대 애플리케이션의 제어(control)와 시퀀스(sequence), 애플리케이션에 의해 다루어지는 데이터 유형, 애플리케이션에 의해 처리되는 원 데이터, 그리고 전유적일 수 있는 다른 정보를 포함할 수 있다. 따라서, 애플리케이션 특정 데이터는 모듈 특정 데이터와는 별개인 데이터베이스 내에 저장될 수 있고 애플리케이션 특정 데이터로의 액세스는 인가된(authorized) 사용자에게 한정될 수 있다.

많은 경우에, 모듈 개발자는 애플리케이션 개발자가 모듈을 재사용할 수 있도록 모듈을 생성 및 배포하였을 수 있다. 모듈 개발자는 상업적 소프트웨어 회사는 물론 공개 소스 소프트웨어 개발자일 수 있다. 그러한 개발자는, 상업적 목적으로든 또는 커뮤니티에 기여하는 만족감을 위해서든, 사용중인 자신의 모듈을 보기를 원할 수 있다.

애플리케이션으로부터 수집되나 모듈 개발자에게 이용가능한 것이게 될 수 있는 트레이서 데이터는 무해화되거나(sanitized), 익명화되거나, 그렇지 않으면 무결화되어(scrubbed) 데이터로부터 전유 정보(proprietary information)를 제거할 수 있다. 그러한 동작은 모듈 트레이스 내 애플리케이션 특정 정보를 제한할 수 있으나, 모듈 개발자로 하여금 모듈 특정 데이터로의 액세스를 가질 수 있게 할 수 있다.

모듈 개발자는 모듈의 배치 및 이용을 모니터링하기 위해서는 물론, 모듈에 있어서의 성능 문제점을 식별하기 위해 모듈 특정 데이터를 액세스할 수 있다. 모듈 특정 데이터는 또한 더 광범위한 관람자층, 예를 들어 일반 공중에게 이용가능한 것이게 될 수 있다. 일반 공중은 모듈을 비교하고 선택하기 위해 모듈 특정 데이터를 활용할 수 있다.

모듈 개발자(102)는 애플리케이션(108)을 제작하기 위해 애플리케이션 개발자(106)에 의해 이용될 수 있는 모듈(104)을 내어줄 수 있다. 트레이싱 모듈(110)은 개별 모듈(104) 내에 또는 애플리케이션(108) 내에 포함될 수 있다. 트레이싱 모듈(110)이 하나 이상의 모듈(104) 내에 포함되는 경우, 그 모듈은 트레이싱될 수 있다. 트레이싱 모듈(110)이 애플리케이션(108) 내에 포함되는 경우, 애플리케이션(108) 내에 포함된 임의의 모듈을 포함하여, 애플리케이션(108) 전부가 트레이싱될 수 있다.

애플리케이션(108)은 실행 환경(execution environment)(112) 내에서 실행될 수 있다. 실행 동안에, 트레이서(114)는 데이터를 모을 수 있는데, 이는 프리프로세서(preprocessor)(116)로 전달될 수 있다. 많은 경우에, 트레이서(114)는 데이터를 모으고 그 데이터를 프리프로세서(116)에 주기적으로 송신할 수 있다.

프리프로세서(116)는 경량(lightweight) 분석, 포맷팅(formatting) 또는 다른 처리를 수행하여, 이후 애플리케이션 특정 데이터를 애플리케이션 데이터베이스(118) 내에 그리고 모듈 특정 데이터를 여러 모듈 데이터베이스(120) 내에 저장할 수 있다. 많은 경우에, 모듈 데이터베이스(120)는 트레이싱될 수 있는 각 모듈에 대한 별개의 데이터베이스로써 구성될 수 있다.

분석 엔진(122)은 각각 분석된 애플리케이션 데이터(124) 또는 분석된 모듈 데이터(126)를 산출하기 위해 저장된 데이터의 추가 분석을 수행될 수 있다. 분석 엔진(122)은 이력 데이터(historical data)를 분석하는 것, 사용 및 성능 통계를 요약하는 것, 데이터를 그래프화하고 차트화하는(charting) 것 및 다른 분석을 포함하여, 많은 상이한 유형의 분석을 수행할 수 있다. 몇몇 경우에, 분석 엔진(122)은 요구에 따라(on demand) 분석을 수행할 수 있는데, 분석된 데이터가 요청될 수 있는 경우에 몇몇 분석이 수행될 수 있음을 의미한다. 다른 경우에, 분석 엔진(122)은 분석된 데이터가 요청되는 경우에 손쉽게 이용가능할 수 있도록 앞서 분석을 수행할 수 있다.

모듈 개발자(102)는 분석된 모듈 데이터(128)로의 전용 액세스(private access)(130)를 가질 수 있다. 모듈 특정 데이터에 대한 모듈 개발자의 전용 액세스는 성능 및 사용에 관한 상세사항을 포함할 수 있다. 반대로, 애플리케이션 개발자(106)는 분석된 모듈 데이터(128)로의 공용 액세스(public access)(132)를 가질 수 있는데, 이는 더 적은 상세사항, 그리고 모듈 개발자(102)의 전용 액세스(130)를 통해 이용가능한 데이터의 서브세트만을 포함할 수 있다.

공용 액세스(132)는, 성능 및 사용 통계를 포함하여, 모듈에 대해 수집된 트레이서 데이터의 요약을 포함할 수 있다. 그러한 사용자 인터페이스의 일례는 이 명세서에서 나중에 찾아볼 수 있다.

애플리케이션 개발자(106)는 분석된 애플리케이션 데이터(124)로의 전용 액세스(126)를 가질 수 있다. 이 액세스는, 다양한 모듈의 성능을 포함하여, 전체로서의 애플리케이션의 성능에 관한 광범한 데이터를 포함할 수 있다. 몇몇 경우에, 애플리케이션 개발자(106)는 모듈 개발자(104)보다 더 많은 데이터 또는 상이한 세트의 데이터를 액세스하는 것이 가능할 수 있다. 예컨대, 애플리케이션 개발자(106)는 모듈에 전달된 파라미터 값을 액세스하는 것이 가능할 수 있는데, 여기서 파라미터 값은 전유적이며 모듈 개발자(104)에게는 이용가능한 것이 아닐 수 있다.

애플리케이션 개발자(106)는 어느 유형의 데이터가 모듈 데이터베이스(120)에게 이용가능한 것이게 될 수 있는지에 대해 제어를 가질 수 있다. 예컨대, 애플리케이션 개발자(106)는 모듈 특정 데이터의 어떠한 공유도 완전히 차단할 수 있으나, 그러한 데이터는 여전히 수집되고, 저장되고, 애플리케이션 개발자(106)의 전용 액세스(126)를 통해 이용가능하게 될 수 있다.

애플리케이션 개발자(106)는 모듈 데이터베이스 내에 공유될 수 있는 데이터에 다양한 제한을 둘 수 있다. 예컨대, 애플리케이션 개발자(106)는 사용 통계가 수집되도록 허용할 수 있지만, 변수의 값이 수집되도록 허용하지는 않을 수 있다. 애플리케이션 개발자(106)는 모듈 데이터베이스(120) 내에 포함되기 전에 데이터가 난독화되거나(obfuscated) 익명화될 수 있다고 정할 수 있다.

도 2는 애플리케이션이 실행되는 경우 데이터를 수집하고 수집된 데이터를 보여주는 다양한 사용자 인터페이스를 제시할 수 있는 컴포넌트를 보여주는 실시예(200)의 도해이다. 실시예(200)의 예는 트레이서 데이터를 생성하고 볼 수 있는 다중 디바이스 시스템(multi-device system)의 하나의 예일 뿐이다. 다른 아키텍처는 단일 디바이스 및 다수 디바이스 아키텍처를 포함할 수 있다.

실시예(200)의 아키텍처는 트레이서 데이터가 수집될 수 있는 디바이스(202)는 물론, 수집된 데이터의 상이한 요소를 저장하고 처리하기 위한 여러 다른 디바이스를 포함한다. 클라이언트 디바이스(client device)는 수집된 데이터를 제시하고 볼 수 있다. 다른 실시예에서, 예시된 기능 중 몇몇 또는 전부는 하나 이상의 디바이스 내에 조합될 수 있다.

도 2의 도해는 시스템의 기능적 컴포넌트를 예시한다. 몇몇 경우에, 컴포넌트는 하드웨어 컴포넌트, 소프트웨어 컴포넌트, 또는 하드웨어와 소프트웨어의 조합일 수 있다. 컴포넌트 중 몇몇은 애플리케이션 레벨 소프트웨어일 수 있으나, 다른 컴포넌트는 실행 환경 레벨 컴포넌트일 수 있다. 몇몇 경우에, 다른 컴포넌트로의 하나의 컴포넌트의 연결은 둘 이상의 컴포넌트가 단일 하드웨어 플랫폼 상에서 동작하고 있는 가까운 연결(close connection)일 수 있다. 다른 경우에, 연결은 긴 거리에 걸친 네트워크 연결 상에 조성될 수 있다. 각 실시예는 기술된 기능을 달성하기 위해 상이한 하드웨어, 소프트웨어 및 상호연결 아키텍처를 이용할 수 있다.

실시예(200)는 하드웨어 플랫폼(204) 및 다양한 소프트웨어 컴포넌트를 가질 수 있는 디바이스(202)를 예시한다. 예시된 바와 같은 디바이스(202)는 종래의 컴퓨팅 디바이스(computing device)를 나타내는데, 다만 다른 실시예는 상이한 구성, 아키텍처 또는 컴포넌트를 가질 수 있다.

많은 실시예에서, 디바이스(202)는 서버 컴퓨터(server computer)일 수 있다. 몇몇 실시예에서, 디바이스(202)는 역시 데스크톱 컴퓨터(desktop computer), 랩톱 컴퓨터(laptop computer), 넷북 컴퓨터(netbook computer), 태블릿(tablet) 또는 슬레이트(slate) 컴퓨터, 무선 핸드세트(wireless handset), 셀룰러 전화(cellular telephone), 게임 콘솔(game console) 또는 임의의 다른 유형의 컴퓨팅 디바이스일 수도 있다.

하드웨어 플랫폼(204)은 프로세서(208), 랜덤 액세스 메모리(random access memory)(210) 및 비휘발성 스토리지(nonvolatile storage)(212)를 포함할 수 있다. 하드웨어 플랫폼(204)은 또한 사용자 인터페이스(214) 및 네트워크 인터페이스(216)를 포함할 수 있다.

랜덤 액세스 메모리(210)는 프로세서(208)에 의해 신속히 액세스될 수 있는 실행가능 코드 및 데이터 객체를 포함하는 스토리지일 수 있다. 많은 실시예에서, 랜덤 액세스 메모리(210)는 메모리(210)를 프로세서(208)에 연결하는 빠른 속도의 버스(high-speed bus)를 가질 수 있다.

비휘발성 스토리지(212)는 디바이스(202)가 정지된(shut down) 후 지속되는 스토리지일 수 있다. 비휘발성 스토리지(212)는, 하드 디스크, 솔리드 스테이트(solid state) 메모리 디바이스, 자기 테이프, 광학 스토리지, 또는 다른 유형의 스토리지를 포함하여, 임의의 유형의 저장 디바이스일 수 있다. 비휘발성 스토리지(212)는 판독 전용(read only) 또는 판독(read)/기록(write) 가능한 것일 수 있다. 몇몇 실시예에서, 비휘발성 스토리지(212)는 클라우드 기반(cloud based)이거나, 네트워크 스토리지(network storage)이거나, 또는 네트워크 연결 상에서 액세스될 수 있는 다른 스토리지일 수 있다.

사용자 인터페이스(214)는 출력을 디스플레이하는 것 및 사용자로부터 입력을 수신하는 것이 가능한 임의의 유형의 하드웨어일 수 있다. 많은 경우에, 출력 디스플레이는 그래픽 디스플레이 모니터(graphical display monitor)일 수 있는데, 다만 출력 디바이스는 광 및 다른 시각적 출력, 오디오 출력(audio output), 운동 액추에이터 출력(kinetic actuator output)은 물론, 다른 출력 디바이스를 포함할 수 있다. 종래의 입력 디바이스는 키보드 및 포인팅(pointing) 디바이스, 예를 들어 마우스(mouse), 스타일러스(stylus), 트랙볼(trackball) 또는 다른 포인팅 디바이스를 포함할 수 있다. 다른 입력 디바이스는, 생체측정(biometric) 입력 디바이스, 오디오 및 비디오 입력 디바이스, 그리고 다른 센서를 포함하여, 다양한 센서를 포함할 수 있다.

네트워크 인터페이스(216)는 다른 컴퓨터로의 임의의 유형의 연결일 수 있다. 많은 실시예에서, 네트워크 인터페이스(216)는 유선 이더넷(Ethernet) 연결일 수 있다. 다른 실시예는 다양한 통신 프로토콜 상의 유선 또는 무선 연결을 포함할 수 있다.

소프트웨어 컴포넌트(206)는 다양한 소프트웨어 컴포넌트 및 서비스가 동작할 수 있는 운영 체제(218)를 포함할 수 있다. 실시예에 따라, 애플리케이션(222)은 운영 체제(218) 내에서 또는 실행 환경(220) 내에서 실행될 수 있다. 실행 환경(220)은 메모리 관리, 프로세스 스케줄링, 그리고 운영 체제(218)와 유사한 방식으로 애플리케이션 실행을 관리할 수 있는 다른 컴포넌트를 가질 수 있다.

트레이싱 수집기(tracing gatherer)(224)는 운영 체제(218)든 실행 환경(220)이든 어느 하나와 작업할 수 있다. 트레이싱 수집기(224)는 트레이서(226) 및 통신 관리기(228)를 포함할 수 있다. 트레이서(226)는 애플리케이션(222)의 동작을 모니터링할 수 있는 반면, 통신 관리기(228)는 트레이서 데이터를 프리프로세서 시스템(240)에 송신할 수 있다.

트레이서(226) 및 통신 관리기(228)는 애플리케이션(222) 내에 포함될 수 있는 트레이서의 컴포넌트일 수 있다. 애플리케이션(222)은, 모듈(234) 모두를 포함하여, 전체 애플리케이션(222)을 트레이싱할 수 있는 트레이서(230)를 가질 수 있다. 모듈 개발자가 자신의 모듈을 트레이싱하기를 바라는 경우, 트레이싱될 특정 모듈(234) 내에 트레이서(236)가 포함될 수 있다.

애플리케이션(222)은 트레이서의 상이한 파라미터를 정의할 수 있는 트레이서 구성(tracer configuration)(232)을 포함할 수 있다. 몇몇 경우에, 트레이서 구성(232)은 어느 데이터 요소가 수집될 수 있는지, 수집되는 데이터의 정확도, 어느 데이터 요소가 모듈 개발자와 공유될 수 있는지, 그리고 다른 항목을 정의할 수 있다. 몇몇 경우에, 트레이서 구성(232)은 하나의 모듈에 대한 하나의 구성을 그리고 다른 모듈에 대한 상이한 구성을 정의할 수 있다.

통신 관리기(228)는 트레이서 데이터를 패키징하고 프리프로세서 시스템(preprocessor system)(240)에 송신할 수 있는데, 이는 네트워크(238) 상에서 액세스될 수 있다. 프리프로세서 시스템(240)은 하드웨어 플랫폼(242)을 가질 수 있는데, 이는 하드웨어 플랫폼(204)과 유사할 수 있고, 이 위에서 프리프로세서(244)가 동작할 수 있다.

프리프로세서(244)는 트레이서 데이터를 수신하고 몇몇 예비적 처리(preliminary processing)을 애플리케이션 데이터베이스 서버(246) 또는 모듈 데이터베이스 서버(254) 내에 데이터를 저장하기 전에 수행할 수 있다. 많은 경우에, 프리프로세서(244)는 큰 용량의 트레이서 데이터를 다루도록 설계될 수 있다.

애플리케이션 데이터베이스 서버(246)는 하드웨어 플랫폼(248)을 가질 수 있는데, 이는 하드웨어 플랫폼(204)과 유사할 수 있되, 이 위에서 두 개의 데이터베이스가 동작할 수 있다. 애플리케이션 데이터베이스(250)는 애플리케이션 특정 트레이서 데이터를 원 형태 또는 전처리된 형태로 포함할 수 있다. 분석된 애플리케이션 데이터베이스(252)는 애플리케이션 개발자에 의한 보기를 위해 준비가 되어 있을 수 있는 분석된 애플리케이션 데이터를 포함할 수 있다.

모듈 데이터베이스 서버(254)는 하드웨어 플랫폼(256)을 가질 수 있는데, 이는 하드웨어 플랫폼(204)과 유사할 수 있되, 이 위에서 두 개의 데이터베이스가 동작할 수 있다. 모듈 데이터베이스(258)는 모듈 특정 트레이서 데이터를 원 형태 또는 전처리된 형태로 포함할 수 있다. 분석된 모듈 데이터베이스(260)는 모듈 개발자 또는 제3자에 의한 보기를 위해 준비가 되어 있을 수 있는 분석된 모듈 데이터를 포함할 수 있다.

분석 시스템(262)은 하드웨어 플랫폼(264)을 가질 수 있는데, 이는 하드웨어 플랫폼(204)과 유사할 수 있되, 이 위에서 분석 엔진(266)이 실행될 수 있다. 분석 엔진(266)은 애플리케이션 트레이서 데이터 또는 모듈 트레이서 데이터의 다양한 분석을 수행할 수 있다. 분석은 데이터를 요약하는 것, 트레이서 데이터를 다른 데이터 소스와 조합하는 것, 데이터를 시각화하는 것, 또는 데이터에 대한 다른 동작을 포함할 수 있다.

액세스 포털 시스템(access portal system)(268)은 하드웨어 플랫폼(270)을 가질 수 있는데, 이는 하드웨어 플랫폼(204)과 유사할 수 있되, 이 위에서 액세스 포털(272)이 실행될 수 있다. 액세스 포털(272)은 클라이언트 시스템(274) 상의 디스플레이를 위해 분석된 애플리케이션 데이터베이스(252) 또는 분석된 모듈 데이터베이스(260)로부터 데이터를 모을 수 있는 웹 서비스 또는 다른 애플리케이션일 수 있다. 액세스 포털(272)은 인증 시스템, 사용자 계정 및 로그인 시스템, 청구(billing) 및 정산(accounting) 시스템, 그리고 다른 기능을 포함할 수 있다.

클라이언트 시스템(274)은 하드웨어 플랫폼(276)을 가질 수 있는데, 이는 하드웨어 플랫폼(204)과 유사할 수 있되, 이 위에서 브라우저(278)가 실행될 수 있다. 브라우저(278)는 액세스 포털(272)을 액세스하고 사용자 인터페이스(280)를 생성하는 데에 이용될 수 있다. 사용자 인터페이스(280)는 사용자 및 사용자의 크리덴셜(credential)에 기반하여 상이할 수 있다. 예컨대, 애플리케이션 개발자는 제3자 또는 일반 소비에 대해 모듈 데이터베이스뿐만 아니라, 자신의 애플리케이션에 대해 애플리케이션 데이터를 보는 것이 가능할 수 있다. 유사하게, 모듈 개발자는 자신의 모듈에 대한 상세화된 모듈 특정 데이터를 보는 것이 가능할 수 있지만 다른 모듈에 대해 또는 애플리케이션에 대해서는 그렇지 않을 수 있다. 제3자는 일반 소비에 대해 허용된 모듈 정보를 보는 것이 가능할 수 있지만 애플리케이션 데이터 또는 상세화된 모듈 특정 데이터를 액세스하는 것이 가능하지 않을 수 있다.

도 3은 모듈 트레이스 데이터를 위한 사용자 인터페이스를 보여주는 예시적인 실시예(300)이다. 실시예(300)는 CONFIG로 명명된 모듈에 대한 공용으로(publically) 이용가능한 모듈 특정 사용자 인터페이스의 일례일 수 있는 사용자 인터페이스(302)이다.

사용자 인터페이스(302)는 트레이서로부터 모아진 후에 공용으로 이용가능할 수 있는 유형의 데이터를 나타낼 수 있다. 트레이서는 모듈 특정 트레이서일 수 있거나 애플리케이션 레벨 트레이서일 수 있다. 실시예(300)의 예에 보여진 유형의 데이터는 가능한 유형의 데이터, 그리고 데이터를 취합하고 디스플레이하기 위한 가능한 방법으로서 예시하는 것일 뿐일 수 있다. 다른 실시예는 상이한 유형의 데이터, 그리고 데이터를 통신하기 위한 메커니즘을 가질 수 있다.

명칭(304)은 모듈을 CONFIG로서 식별할 수 있다. 요약된 평점(306)은 모듈의 신뢰성, 인기도, 그리고 모듈이 어떤 경향을 띠고 있는지의 고수준 요약(high level summary)을 사용자에게 줄 수 있다. 신뢰성은 전체로서의 모듈의 강인성 또는 취약성을 반영할 수 있는 사용 및 성능 데이터로부터 도출되는 메트릭일 수 있다.

인기도는 모듈에 대한 커뮤니티의 사용을 반영하는 메트릭일 수 있다. 몇몇 경우에, 인기도는 전체로서의 커뮤니티에 비교해 볼 때, 필적하는 모듈에 비교해 볼 때, 또는 어떤 다른 맥락에서 모듈의 인기도를 반영할 수 있다.

경향 지시자(trending indicator)는 모듈이 전체적인 인기도 및 강인성에 있어서 증가하거나 감소하고 있는지를 나타낼 수 있다. 만약 모듈이 점점 더 적게 이용되고 있거나 모듈의 후속 출시가 이전의 출시보다 더 미흡하게 수행하고 있는 경우, 경향 지시자는 아래쪽일 수 있다. 역으로, 만약 모듈이 사용자를 얻고 있고 모듈의 각 출시가 신뢰성을 높이는 경우, 경향은 상향일 수 있다.

신뢰성, 인기도 및 경향 지시자는 특정한 모듈을 기술하는 사용자 인터페이스에 유용할 수 있는 고수준 요약 지시자의 세 가지 예일 뿐이다.

데이터세트 정보(dataset information)(308)의 세트는 디스플레이된 데이터의 기저에 있을(underlie) 수 있는 데이터의 양을 디스플레이할 수 있다. 예에서, 분석된 데이터세트의 개수는 252,000일 수 있고 모듈을 이용하는 애플리케이션의 개수는 15,000일 수 있다. 이들 개수는, 성능 및 사용 데이터가 데이터의 통계적으로 상당한 모집단(population)에 기반한다는 확신을 뷰에 주면서, 전체적인 데이터에 신빙성을 부여할 수 있다.

기능 특정 데이터(function-specific data)(310)의 세트는 모듈 내의 개별 기능에 대한 관측을 보여줄 수 있다. 많은 모듈은 다수의 기능, 객체 또는 다른 컴포넌트를 포함할 수 있는데, 이들 각각은 개별적으로 호출되거나 기동될 수 있다. 예에서, 선(314, 316, 318 및 320)은 각각 config.foo, config.bar, config.baz 및 config.qux에 대한 요약 데이터(summary data)를 예시할 수 있다.

그 유형의 기능 특정 데이터는 기능 중 어느 것이 가장 많이 이용되는지를 나타낼 수 있는 이용 백분율(use percentage)을 포함할 수 있다. config.qux의 경우에, 이용 백분율은 0일 수 있는데, 이는 그 기능에 대한 어떠한 트레이스 데이터도 존재하지 않는 경우에 발생할 수 있다. 분석 루틴의 하나의 예에서, config 모듈에 대한 소스 코드는 이용가능한 기능 각각을 식별하기 위해 판독될 수 있다. 기능 특정 데이터(310) 중 일부를 생성하기 위해 기능의 목록이 트레이서 데이터와 비교될 수 있다.

CPU 소비 및 메모리 소비뿐만 아니라, 각 기능에 대해 에러율(error rate)이 판정될 수 있다. CPU 및 메모리의 리소스 소비(resource consumption)는 표준 편차(standard deviation)과 함께 평균(mean)으로서 주어질 수 있다. 표준 편차는 기능의 안정성 또는 믿음성(reliance)의 하나의 메트릭일 수 있다. 기능에 대한 신뢰성 점수(reliability score)가 또한 포함될 수 있다. 신뢰성 점수는 리소스 소비에서의 분산을 포착할 수 있는 알고리즘(algorithm) 또는 휴리스틱(heuristic)을 이용하여 판정될 수 있다.

사용 경향(320)의 그래프는 시간에 걸쳐 기능의 사용을 보여주는 하나의 메커니즘일 수 있다. 사용 경향(320)의 그래프의 경우에, 그래프의 상위 부분(322)은 모듈을 추가하는 새로운 애플리케이션을 보여줄 수 있는 반면, 하위 부분(324)은 모듈을 더 이상 이용하지 않는 애플리케이션을 보여줄 수 있다.

몇몇 경우에, 초기 국면(initial phase) 동안에 애플리케이션에 모듈이 추가되는데, 애플리케이션 개발자가 모듈을 다른 것으로 교체하기로 선택하는 경우에는 이후에 제거될 수 있다. 이 사용 패턴은 제2 모듈이 현재 모듈보다 애플리케이션에 더 적합할 수 있음을 나타낼 수 있는 하나의 메커니즘이다. 트레이싱 시스템이 그러한 행위를 포착하거나 추론할 수 있는 경우, 제2 모듈의 바람직함은 강하게 나타내어질 수 있고 제1 모듈의 바람직하지 않음도 강하게 나타내어질 수 있다. 이들 유형의 패턴은, 모듈을 찾고 있을 수 있는 애플리케이션 개발자뿐만 아니라, 자신의 모듈을 조사하고 개선할 수 있는 모듈 개발자에게 전달될 수 있는 매우 가치 있는 피드백일 수 있다.

그래프는 상호작용적(interactive)일 수 있고, 사용자가 그래프 내의 바(bar)들 중 하나 위에서 호버링하거나(hover) 클릭하는 경우에 예시적인 상호작용적 박스(interactive box)(326)가 사용자 인터페이스 상에 놓일 수 있다. 상호작용적 박스(326)는 선택된 바에 대한 기저의 데이터를 보여줄 수 있다.

커버리지 그래프(coverage graph)(328)는 모듈(이에 대한 트레이스 데이터가 존재함)의 컴포넌트를 시각적으로 예시할 수 있다. 커버리지 그래프의 일례는 이 명세서에서 나중에 찾아볼 수 있다.

유사하게, 모듈 토폴로지 그래프(330)는 현재 모듈 및 현재 모듈이 호출할 수 있는 다른 모듈 간의 링크를 시각적으로 예시할 수 있다. 모듈 토폴로지 그래프의 일례는 이 명세서에서 나중에 찾아볼 수 있다.

경쟁 모듈 영역(competing modules area)(332)은 현재 모듈과 유사하거나 경쟁적인 모듈을 나열할 수 있다. 나열된 모듈은 핫 링크(hot link), 버튼(button), 또는 다른 메커니즘(사용자 인터페이스로 하여금 해당 모듈로 바뀌게 할 수 있음)을 가질 수 있다. 경쟁 모듈은 다른 모듈의 상대적 세기(strength), 모듈의 경향, 또는 몇몇 다른 지시자를 보여주는 지시자를 포함할 수 있다.

도 4는 트레이스 커버리지 그래프를 보여주는 실시예(400)의 예시적인 도해이다. 그래프(402)는 모듈의 다양한 기능 또는 컴포넌트를 그래프의 노드로서 보여줄 수 있다. 그래프의 에지(edge)들은 노드의 실행의 시퀀스 또는 연결을 반영할 수 있고, 커버리지 그래프를 생성하기 위해 이용되었던 데이터의 양을 반영하도록 그려질 수 있다.

많은 실시예에서, 그래프(402)의 노드 각각은 노드 각각에 의해 표현되는 실행가능 코드와 관련하여 라벨표시될(labeled) 수 있다. 도면에서 단순성을 위하여, 그러한 라벨은 제거되었다.

실시예(400)의 예에서, 노드(404, 406, 408 및 410)는 굵은 묵직한 선으로써 연결될 수 있다. 그러한 선은 많은 양의 트레이스 데이터가 해당 실행 시퀀스에 대해 존재할 수 있음을 나타낼 수 있다. 반대로, 노드(404, 412, 414 및 416)의 시퀀스는 훨씬 더 적은 지지(supporting) 데이터를 가질 수 있다. 노드(418, 420, 422 및 424)의 경우에, 파선은 어떠한 트레이스 데이터도 이용가능하지 않을 수 있음을 나타낼 수 있다. 그러한 경우에, 노드(418, 420, 422 및 424)는 연관된 코드는 애플리케이션에 의해 전혀 행해지지 않았을 수 있다.

그래프(402)는 상호작용적 그래프일 수 있다. 상호작용의 일례로서, 사용자는 노드(404)를 호버링하거나, 클릭하거나, 선택하거나, 그렇지 않으면 지시할 수 있고 상호작용적 컴포넌트(426)가 디스플레이될 수 있다. 상호작용적 컴포넌트(426)는 노드에 관한 추가적인 기저의 데이터를 디스플레이할 수 있다.

도 5는 모듈 토폴로지 그래프를 보여주는 실시예(500)의 예시적 도해이다. 그래프(502)는 모듈 및 그것의 종속체(이는 기반 모듈에 포함되거나 그로부터 호출될 수 있는 다른 모듈일 수 있음)를 보여줄 수 있다. 그래프의 노드는 기반 모듈 및 그것의 종속체를 반영할 수 있다. 그래프의 에지들은 종속적인 모듈들로의 연결들 또는 기능 호출(function call)들을 반영할 수 있다.

그래프(502)는 모듈의 호출 구조(call structure)의 시각적 이미지일 수 있고, 모듈의 복잡성 및 종속체의 그래픽 뷰(graphical view)를 사용자에게 주기 위해 이용될 수 있다.

모듈 config(504)는 음영표시되거나(shaded) 강조된(highlighted) 노드로서 보여질 수 있다. 이 노드는 그래프를 위한 기반 노드를 나타낼 수 있다. 노드(506, 508, 510, 510, 512, 514, 516 및 518)는 각각 모듈 alpha, beta, gamma, delta, epsilon, zeta 및 eta를 나타낼 수 있다. 상호연결은 모듈 간 기능 호출 또는 다른 종속체를 보여준다.

실시예(500)의 예에서, 모듈 config(504)는, 다음에 노드(514)(모듈 epsilon)를 호출하는 노드(510)(모듈 gamma)를 호출하는 것으로 도시된다. 모듈 epsilon(노드 (514))은 노드(516 및 518)에 의해 표현되는 모듈 zeta 및 eta를 호출한다. 이 구조는 노드(518) 상의 모듈 eta가 모듈 config(514)에 어떻게 관련되는지를 보는 이(viewer)에게 전할 수 있다.

도 6은 애플리케이션을 생성하기 위한 방법을 보여주는 실시예(600)의 흐름도 예시이다. 실시예(600)는 하나 이상의 모듈 또는 라이브러리를 포함하는 애플리케이션을 생성하기 위해 애플리케이션 개발자가 이용할 수 있는 일반적인 방법을 예시한다.

개발자는 블록(602)에서 애플리케이션을 코딩하기 시작할 수 있다. 코딩하면서, 개발자는 블록(604)에서 기능을 식별할 수 있는데 이는 기능을 수행할 수 있는 모듈에 대하여 블록(606)에서 탐색을 유도할(prompt) 수 있다. 블록(606)에서의 후보 모듈의 목록으로부터, 개발자는 블록(608)에서 각각의 후보를 평가할 수 있다.

개발자는 후보 모듈 각각에 대해 블록(610)에서 모듈 특정 트레이스 데이터를 검사할 수 있다. 그러한 데이터의 일례는 실시예(300)의 사용자 인터페이스에서 찾아볼 수 있다. 이들 데이터로부터, 개발자는 블록(612)에서 적절한 모듈을 선택하고 블록(614)에서 모듈을 애플리케이션 내에 포함시키는 것이 가능할 수 있다.

만약 모듈 개발자가 블록(616)에서 트레이싱을 추가한 경우, 애플리케이션 개발자는 블록(618)에서 모듈에 대한 다양한 트레이싱 파라미터를 구성하는 것이 가능할 수 있다. 트레이싱 파라미터는 애플리케이션 개발자로 하여금 트레이서에 대한 상이한 옵션을 선택할 수 있도록 할 수 있다.

트레이싱 파라미터는 애플리케이션 개발자로 하여금 모듈이 어떻게 트레이싱될 수 있는지를 제어할 수 있게 하도록 많은 상이한 방식으로 구성될 수 있다. 모듈 트레이싱은 모듈 개발자가 가질 수 있는 특정 목표를 다루기 위해 모듈 개발자에 의해 요청될 수 있지만, 애플리케이션 개발자는 모듈 트레이싱이 어떻게 일어날 수 있는지에 대한 최종 승인 및 제어를 가질 수 있다. 많은 경우에, 애플리케이션 개발자는 모듈에 대한 트레이싱을 완벽히 불능화하는 것은 물론, 트레이서가 수집할 수 있는 파라미터 중 몇몇을 제한하거나 확대하는 것이 가능할 수 있다.

트레이싱 빈도(tracing frequency)는 트레이서 구성의 일부일 수 있다. 많은 실시예에서, 트레이싱은 처리 및 메모리 리소스를 소비할 수 있다. 따라서, 트레이싱은 샘플링 단위로(on a sampling basis) 수행될 수 있거나 트레이싱에 의해 소비되는 리소스의 양을 제한하는 다른 아키텍처를 가질 수 있다.

모듈 트레이싱 데이터는 모듈을 개선하는 것에 도움이 되기 위해서는 물론, 모듈을 위한 공용 데이터베이스를 추가로 실장하기 위해 모듈 개발자에게 도로 공급될 수 있기 때문에 애플리케이션 개발자는 모듈에 대한 트레이싱을 허용하도록 동기를 부여받을(incented) 수 있다. 이 시점에서, 애플리케이션 개발자는 블록(610)에서 공용 데이터베이스를 이미 액세스하였을 수 있고 모듈 트레이싱을 허용함으로써 커뮤니티에 반환하기를 바랄 수 있다.

만약 블록(620)에서 모듈 내에 구현될 수 있는 다른 기능을 애플리케이션 개발자가 식별하는 경우, 프로세스는 블록(604)으로 돌아갈 수 있고, 그렇지 않으면 프로세스는 블록(622)으로 이어질 수 있다.

블록(622)에서, 애플리케이션 개발자는 애플리케이션 특정 트레이싱을 추가하기를 바랄 수 있다. 만약 그렇다면, 블록(624)에서 트레이싱 모듈이 추가될 수 있고 애플리케이션 특정 트레이싱은 블록(626)에서 구성될 수 있다.

애플리케이션 개발자는 블록(628)에서 코드를 컴파일링하고 블록(630)에서 코드를 실행할 수 있다.

도 7은 모듈 트레이싱과 함께 애플리케이션을 실행하는 방법을 보여주는 실시예(700)의 흐름도 예시이다.

다른 실시예는 유사한 기능을 성취하기 위해 상이한 순차, 추가적인 또는 더 적은 단계, 그리고 상이한 명명법 또는 용어를 이용할 수 있다. 몇몇 실시예에서, 다양한 동작 또는 동작의 세트가, 동기(synchronous) 방식으로든 또는 비동기(asynchronous) 방식으로든, 다른 동작과 병렬로 수행될 수 있다. 여기서 선택된 단계는 동작의 몇몇 원리를 단순화된 형태로 예시하기 위해 선택되었다.

실시예(700)는 애플리케이션이 어떻게 모듈 특정 트레이싱과 함께 실행될 수 있는지를 예시한다. 모듈 특정 트레이싱은 모듈이 실행되는 경우에만 일어날 수 있고 애플리케이션의 다른 부분이 실행되는 경우에는 동작하지 않을 수 있다.

애플리케이션은 블록(702)에서 수신되고 블록(704)에서 실행을 시작할 수 있다. 실행 동안에, 블록(706)에서 모듈이 직면될(encountered) 수 있다. 모듈은 블록(708)에서 로딩되고(loaded) 블록(710)에서 실행을 시작할 수 있다.

만약 블록(712)에서 모듈이 트레이싱을 포함하는 경우, 블록(714)에서 트레이싱이 켜질(turned on) 수 있다. 트레이싱은 별도의 쓰레드(thread) 또는 프로세스에 의해 수행될 수 있거나, 모듈 그 자체와 함께 단일 쓰레드 내에 포함될 수 있다. 만약 트레이싱이 모듈 내에 포함되지 않은 경우, 트레이싱은 켜지지 않을 수 있다.

블록(716)에서 모듈이 실행되는 동안, 블록(718)에서의 모듈 트레이서 동작이 수행될 수 있다. 모듈 트레이서는 블록(720)에서 트레이싱 데이터를 수집할 수 있고 블록(722)에서 트레이서 데이터를 프리프로세서에 보낼 수 있다. 많은 실시예에서, 트레이서 데이터는 주기적으로, 예를 들어 1초마다, 몇 초마다, 1분마다, 또는 어떤 다른 빈도로 프리프로세서에 보내어질 수 있다.

모듈 처리는 블록(716)으로 되돌아감으로써 블록(724)에서 계속될 수 있다. 블록(724)에서 모듈이 완료된 경우, 처리는 블록(726)으로 이어질 수 있다. 블록(726)에서 다른 모듈과 직면되는 경우, 프로세스는 블록(706)으로 되돌아갈 수 있다. 처리가 완료되는 경우, 애플리케이션은 블록(728)에서 종료할 수 있다.

도 8은 애플리케이션 및 모듈 트레이싱 양자 모두와 함께 애플리케이션을 실행하는 방법을 보여주는 실시예(800)의 흐름도 예시이다.

다른 실시예는 유사한 기능을 성취하기 위해 상이한 순차, 추가적인 또는 더 적은 단계, 그리고 상이한 명명법 또는 용어를 이용할 수 있다. 몇몇 실시예에서, 다양한 동작 또는 동작의 세트가, 동기 방식으로든 또는 비동기 방식으로든, 다른 동작과 병렬로 수행될 수 있다. 여기서 선택된 단계는 동작의 몇몇 원리를 단순화된 형태로 예시하기 위해 선택되었다.

실시예(800)는 애플리케이션이 어떻게 애플리케이션 특정 및 모듈 특정 트레이싱과 함께 실행될 수 있는지를 예시한다. 애플리케이션 특정 트레이싱은 애플리케이션이 실행되는 동안 일어날 수 있고 모듈 특정 트레이싱은 다양한 모듈이 실행되는 동안 일어날 수 있다. 실시예(800)는 모듈 특정 트레이싱이 애플리케이션 특정 트레이싱 없이 일어날 수 있는 실시예(700)와 비교될 수 있다.

애플리케이션은 블록(802)에서 수신되고 블록(804)에서 실행을 시작할 수 있다. 블록(806)에서 애플리케이션이 트레이싱을 포함하는 경우, 블록(808)에서 애플리케이션 트레이싱이 시작될 수 있다. 트레이서의 동작은 블록(810)에서 예시될 수 있다.

애플리케이션은 블록(814)에서 실행될 수 있다. 애플리케이션이 블록(814)에서 실행되는 동안, 트레이서는 블록(812)에서 애플리케이션 특정 트레이서 데이터를 수집할 수 있다.

블록(816)에서 애플리케이션이 모듈과 직면하는 경우, 모듈은 블록(818)에서 실행될 수 있다. 블록(818)에서 모듈이 실행되는 동안, 트레이서는 블록(820)에서 트레이서 데이터를 수집할 수 있다.

블록(810)의 트레이서 동작 동안에, 트레이서는 블록(822)에서 트레이서 데이터를 프리프로세서에 보낼 수 있다. 트레이서 데이터는 예컨대 주기적으로 송신될 수 있다.

블록(824)에서 더 많은 코드가 실행되어야 할 때, 프로세스는 블록(814)으로 되돌아갈 수 있고, 그렇지 않으면 애플리케이션은 블록(826)에서 종료할 수 있다.

도 9는 트레이서 데이터를 전처리하는 방법을 보여주는 실시예(900)의 흐름도 예시이다. 실시예(900)는 트레이서 데이터를 모으고 데이터를 적절한 데이터베이스에 발송하기 위해 수행될 수 있다. 일단 데이터가 데이터베이스 내에 있으면 데이터는 분석 엔진에 의해 추가로 처리되고 분석될 수 있다.

실시예(900)는 프리프로세서의 하나의 예이다. 많은 실시예에서, 프리프로세서는 큰 용량의 데이터를 다룰 수 있다. 따라서, 프리프로세서는 한정된 양의 분석을 수행할 수 있고 경량 방식으로 동작할 수 있다. 실시예(900)의 동작은 트레이서로부터 보내지는 각각의 패킷 또는 메시지에 대해 수행될 수 있다.

트레이스 데이터는 블록(902)에서 수신될 수 있다. 많은 경우에, 트레이스 데이터는 패킷, 메시지 또는 다른 형태(트레이서에 의해 모아진 한 그룹의 관측, 메타데이터 및 다른 정보를 포함할 수 있음)로 유입될 수 있다.

만약 블록(904)에서 트레이스 데이터가 애플리케이션 트레이스 데이터인 경우, 모듈 특정 데이터는 블록(906)에서 추출되고, 블록(908)에서 익명화되며, 블록(910)에서 모듈 프리프로세서로 보내질 수 있다. 만약 블록(904)에서 트레이스 데이터가 모듈 트레이스 데이터인 경우, 트레이스 데이터는 모듈 프리프로세서로 보내진다.

블록(906 및 908)에서의 모듈 특정 데이터의 추출 및 익명화는 애플리케이션을 식별할 수 있는 데이터, 애플리케이션에 의해 다루어지는 데이터, 또는 애플리케이션에 관련될 수 있는 다른 정보를 제거할 수 있다. 이들 데이터는, 몇몇 경우에, 전유적인 것으로 간주되고 따라서 모듈 데이터베이스에 추가되기 전에 제거된다.

모듈 프리프로세서의 동작은 블록(912)에서 예시된다. 모듈 특정 데이터의 초기 분석이 블록(914)에서 수행될 수 있다. 새로운 데이터는 블록(916)에서 기존의 모듈 데이터 내에 취합될 수 있고, 모듈 데이터베이스는 블록(918)에서 업데이트될 수 있다. 모듈 데이터베이스 내의 데이터는 일반 공중을 포함할 수 있는 더 광범위한 관람자층뿐만 아니라 모듈 개발자가 볼 수 있는 데이터를 생성하기 위해 분석 엔진에 의해 추가로 처리될 수 있다.

애플리케이션 특정 데이터는 블록(920)에서 예시된 바와 같이 애플리케이션 프리프로세서에 의해 처리될 수 있다. 애플리케이션 프리프로세서는 블록(922)에서 애플리케이션 데이터에 대해 초기 분석을 수행하고, 블록(924)에서 기존의 애플리케이션 데이터 내에 새로운 데이터를 취합하며, 블록(962)에서 애플리케이션 데이터베이스를 업데이트할 수 있다.

도 10은 트레이서 데이터를 분석하는 방법을 보여주는 실시예(1000)의 흐름도 예시이다. 실시예(1000)는 분석된 모듈 데이터베이스 내에 모듈 트레이스 데이터를 포함시키기 위해 분석 엔진에 의해 수행될 수 있다. 분석된 모듈 데이터베이스로부터, 데이터는 실시예(300)의 사용자 인터페이스와 같은 사용자 인터페이스로써 사용자에게 제시될 수 있다.

전처리된 트레이스 데이터가 블록(1002)에서 수신될 수 있다. 모듈 메타데이터는 블록(1004)에서 데이터로부터 추출될 수 있다.

만약 블록(1006)에서 모듈이 분석된 모듈 데이터베이스 내에 있지 않은 경우, 블록(1008)에서 시작하여 데이터베이스에 모듈을 추가하기 위해 프로세스가 실행될 수 있다.

블록(1008)에서, 분석된 모듈 데이터베이스 내의 엔트리(entry)가 생성될 수 있다. 모듈을 위한 소스 코드는 블록(1010)에서 인출되고(retrieved) 이출된(exported) 기능 및 다른 객체의 위치를 파악하기(locate) 위해 블록(1012)에서 파싱될(parsed) 수 있다.

블록(1014)에서의 이출된 기능 또는 다른 이용가능한 객체 각각에 대하여, 블록(1016)에서 그 기능 또는 객체는 분석된 트레이스 데이터베이스에 추가될 수 있다. 프로세스는 블록(1018)에서 계속될 수 있다.

만약 블록(1006)에서 모듈이 데이터베이스 내에 있는 경우, 블록(1018)에서 모듈 레벨 데이터 요소가 데이터로부터 추출될 수 있고 분석된 모듈 데이터베이스는 블록(1020)에서 업데이트될 수 있다.

데이터 내의 기능 또는 다른 객체는 블록(1022)에서 식별될 수 있다. 블록(1024)에서의 각각의 기능에 대하여, 기능에 관련된 통계는 블록(1026)에서 업데이트될 수 있고 통계는 분석된 모듈 데이터베이스를 블록(1028)에서 업데이트하기 위해 이용된다.

전체로서의 모듈에 대한 임의의 통계가 블록(1030)에서 업데이트될 수 있고 블록(1032)에서 업데이트는 분석된 모듈 데이터베이스 내에 발행될(published) 수 있다.

도 11은 분석된 트레이스 데이터로부터의 데이터에 대한 요청에 대처하는(servicing) 방법을 보여주는 실시예(1100)의 흐름도 예시이다. 실시예(1100)는 클라이언트 디바이스로부터의 요청에 응답하여 포털 서버에 의해 수행될 수 있다.

블록(1102)에서 특정한 모듈에 대한 요약 데이터에 대하여 요청이 수신될 수 있다. 만약 블록(1104)에서 사용자가 인증된 사용자가 아닌 경우, 모듈에 대한 일반 데이터가 블록(1106)에서 인출되고 블록(1108)에서 사용자에게 송신될 수 있다. 만약 블록(1104)에서 사용자가 인증된 사용자인 경우, 모듈 개발자 데이터가 블록(1110)에서 인출되고 블록(1108)에서 송신될 수 있다.

실시예(1110)의 예에서, '페이지'(page)로서 전달되는 데이터의 관념은 웹 페이지의 형태로의 데이터의 전달의 일례를 나타낼 수 있다. 몇몇 실시예는 사용자 인터페이스 내에서 사용자에게 렌더링되거나(rendered) 제시될 다른 방식으로 데이터를 송신할 수 있다.

대상의 전술한 설명은 예시 및 설명의 목적으로 제시되었다. 그것은 철저하도록 또는 대상을 개시된 바로 그 형태로 한정하도록 의도된 것이 아니고, 위의 교시에 비추어 다른 수정 및 변형이 가능할 수 있다. 실시예는 발명의 원리 및 그것의 실제적인 적용을 가장 잘 설명하여 이로써 당업자로 하여금 고려된 특정한 이용에 적합한 다양한 실시예 및 다양한 수정에서 발명을 가장 잘 활용할 수 있게 하기 위해서 선택되고 기술되었다. 부기된 청구항은 선행 기술에 의해 한정되는 한인 것 외에는 다른 대안적 실시예를 포함하도록 해석되어야 한다고 의도된다.

Claims

시스템으로서,
적어도 하나의 프로세서와,
트레이싱 데이터베이스(tracing database)와,
프리프로세서 시스템(preprocessor system)과,
트레이싱 데이터 서버(tracing data server)와,
모듈 개발자에 의해 액세스가능한 제1 사용자 인터페이스와,
제3자에 의해 액세스가능한 제2 사용자 인터페이스를 포함하고,
상기 프리프로세서 시스템은 복수의 애플리케이션으로부터 트레이싱 출력을 수집하되, 상기 애플리케이션 각각은 제1 재사용가능 모듈 및 트레이싱 메커니즘을 포함하고, 상기 트레이싱 메커니즘은 상기 제1 재사용가능 모듈로부터 트레이싱 데이터를 모으도록 구성되며, 상기 프리프로세서 시스템은 상기 트레이싱 데이터를 상기 트레이싱 데이터베이스 내에 저장하고,
상기 트레이싱 데이터 서버는 모듈 트레이싱 데이터에 대한 요청을 수신하고, 상기 요청에 응답하여 상기 트레이싱 데이터의 적어도 일부분을 회신하되, 상기 트레이싱 데이터의 상기 적어도 일부분은 복수의 사용자 인터페이스 중 하나 상에 디스플레이가능한(displayable) 것이며,
상기 제1 사용자 인터페이스는 상기 모듈 개발자로부터 인증(authentication)을 수신한 후 액세스가능하고, 상기 제1 사용자 인터페이스는 상기 복수의 사용자 인터페이스 중 하나이며,
상기 제2 사용자 인터페이스는 인증 없이 액세스가능하고, 상기 제2 사용자 인터페이스는 상기 복수의 사용자 인터페이스 중 하나이며,
상기 제1 사용자 인터페이스는 트레이싱 데이터의 제1 세트를 포함하고,
상기 제2 사용자 인터페이스는 트레이싱 데이터의 상기 제1 세트의 서브세트를 포함하는
시스템.
제1항에 있어서,
상기 트레이싱 메커니즘은 상기 모듈 내로부터 기동되는(invoked)
시스템.
제1항에 있어서,
상기 트레이싱 메커니즘은 상기 모듈 외부로부터 기동되는
시스템.
제1항에 있어서,
상기 트레이싱 메커니즘은 상기 복수의 애플리케이션 각각 내의 설정으로부터 구성가능한
시스템.
제1항에 있어서,
상기 트레이싱 데이터는 익명화되는(anonymized)
시스템.
제5항에 있어서,
상기 트레이싱 데이터는 상기 트레이싱 데이터가 수집되는 경우 상기 프리프로세서 시스템에 의해 익명화되는
시스템.
제1항에 있어서,
상기 트레이싱 데이터는 성능 데이터(performance data)를 포함하는
시스템.
제7항에 있어서,
상기 성능 데이터는 리소스 사용(resource usage)을 포함하는
시스템.
제8항에 있어서,
상기 트레이싱 데이터는 사용 데이터(usage data)를 더 포함하는
시스템.
제9항에 있어서,
상기 사용 데이터는 상기 모듈 내의 복수의 기능 각각에 대한 사용 데이터를 포함하는
시스템.
제10항에 있어서,
상기 사용 데이터는 상기 모듈을 포함한 상이한 애플리케이션의 개수의 카운트를 포함하는
시스템.
제1항에 있어서,
상기 제2 사용자 인터페이스는 배지(badge)를 포함하되, 상기 배지는 상기 모듈 트레이서 데이터로부터 도출되는 적어도 하나의 메트릭(metric)을 포함하는
시스템.
제12항에 있어서,
상기 적어도 하나의 메트릭은 상기 모듈 트레이서 데이터 내의 관측의 개수인
시스템.
제13항에 있어서,
상기 관측은 상기 모듈의 실행인
시스템.
제13항에 있어서,
상기 관측은 상기 모듈을 포함하는 상기 애플리케이션의 개수인
시스템.
적어도 하나의 컴퓨터 프로세서 상에서 수행되는 방법으로서,
복수의 애플리케이션으로부터 트레이싱 출력을 수집하는 단계 - 상기 애플리케이션 각각은 제1 재사용가능 모듈 및 트레이싱 메커니즘을 포함하고, 상기 트레이싱 메커니즘은 상기 제1 재사용가능 모듈로부터 트레이싱 데이터를 모으도록 구성됨 - 와,
상기 트레이싱 데이터를 트레이싱 데이터베이스 내에 저장하는 단계와,
모듈 트레이싱 데이터에 대한 제1 요청을 수신하는 단계와,
상기 제1 요청이 인증됨을 판정하는 단계와,
상기 제1 요청에 응답하여 상기 트레이싱 데이터의 제1 서브세트를 포함하는 제1 사용자 인터페이스를 회신하는 단계와,
모듈 트레이싱 데이터에 대한 제2 요청을 수신하는 단계와,
상기 제2 요청이 인증되지 않음을 판정하는 단계와,
상기 제2 요청에 응답하여 상기 트레이싱 데이터의 제2 서브세트를 포함하는 제2 사용자 인터페이스를 회신하는 단계를 포함하되, 상기 트레이싱 데이터의 상기 제1 서브세트는 상기 트레이싱 데이터의 상기 제2 서브세트보다 더 큰
방법.
제16항에 있어서,
상기 제2 사용자 인터페이스 상에 디스플레이되는 데이터의 상기 제2 서브세트의 적어도 일부분을 익명화하는 단계를 더 포함하는
방법.
제17항에 있어서,
데이터의 상기 제1 서브세트는 익명화되지 않은(non-anonymized) 데이터를 포함하는
방법.
제16항에 있어서,
상기 트레이싱 출력을 수집하기 위해 애플리케이션 개발자로부터 허가를 수신하는 단계를 더 포함하는
방법.
제19항에 있어서,
상기 트레이싱 출력을 수집하기 전에 상기 애플리케이션 각각으로부터 트레이싱 구성을 판정하는 단계를 더 포함하는
방법.
시스템으로서,
적어도 하나의 프로세서와,
애플리케이션 트레이스 데이터베이스(application trace database)와,
모듈 트레이스 데이터베이스(module trace database)와,
상기 적어도 하나의 프로세서 상에서 실행되는 데이터 프리프로세서(data preprocessor)와,
분석 엔진(analysis engine)을 포함하되,
상기 데이터 프리프로세서는, 애플리케이션 특정 코드(application specific code) 및 재사용가능 모듈 코드(reusable module code)를 포함하는 애플리케이션으로부터 트레이싱 데이터를 수집하고, 모듈 트레이스 데이터를 식별하고 상기 모듈 트레이스 데이터를 상기 모듈 트레이스 데이터베이스 내에 저장하며, 애플리케이션 트레이스 데이터를 식별하고 상기 애플리케이션 트레이스 데이터를 상기 애플리케이션 트레이스 데이터베이스 내에 저장하며,
상기 분석 엔진은, 상기 애플리케이션 트레이스 데이터의 제1 애플리케이션 특정 뷰(application-specific view)를 생성하고, 상기 모듈 트레이스 데이터의 제1 모듈 특정 뷰(module-specific view)를 생성하는
시스템.
제21항에 있어서,
상기 모듈 특정 뷰는 복수의 애플리케이션으로부터 수집된 모듈 트레이스 데이터를 포함하는
시스템.
제22항에 있어서,
상기 모듈 특정 뷰는 상기 모듈에 대한 성능 메트릭을 포함하는
시스템.
제23항에 있어서,
상기 성능 메트릭은 상기 모듈을 위한 리소스 사용을 포함하는
시스템.
제24항에 있어서,
상기 성능 메트릭은 상기 모듈 내에 포함된 복수의 기능 각각에 대해 정의되는
시스템.
제22항에 있어서,
상기 모듈 특정 뷰는 상기 모듈에 대한 사용 메트릭을 포함하는
시스템.
제26항에 있어서,
상기 사용 메트릭은 상기 모듈 내에 포함된 복수의 기능 각각에 대해 정의되는
시스템.
제27항에 있어서,
상기 사용 메트릭은 상기 복수의 애플리케이션 각각에 대해 정의되는
시스템.
제21항에 있어서,
상기 모듈 특정 뷰는 신뢰성 메트릭을 포함하는
시스템.
제29항에 있어서,
상기 신뢰성 메트릭은 상기 모듈에 대한 단일 메트릭인
시스템.
제29항에 있어서,
상기 모듈 특정 뷰는 상기 모듈 내의 복수의 기능 각각에 대한 신뢰성 메트릭을 포함하는
시스템.
시스템으로서,
애플리케이션 내에 포함된 모듈에 대한 이용 데이터 및 성능 데이터를 포함하는 모듈 특정 데이터베이스 - 상기 모듈은 저장소(repository) 내 이용가능한(available) 재사용가능 코드를 포함함 - 와,
상기 애플리케이션에 대한 이용 데이터 및 성능 데이터를 포함하는 애플리케이션 특정 데이터베이스와,
모듈 특정 데이터에 대한 제1 요청을 수신 - 상기 제1 요청은 제1 모듈에 대한 요청을 포함함 - 하고, 상기 제1 요청이 인증된 요청이 아님을 판정하고 상기 제1 모듈에 대한 통계의 제1 요약 세트를 회신하며, 상기 모듈 특정 데이터에 대한 제2 요청을 수신 - 상기 제2 요청은 상기 제1 모듈에 대한 요청을 포함함 - 하고, 상기 제2 요청이 인증된 요청임을 판정하고 상기 제1 모듈에 대한 통계의 상세화된 세트를 회신하도록 구성된 액세스 포털(access portal)을 포함하는
시스템.
제32항에 있어서,
상기 액세스 포털은 애플리케이션 특정 데이터에 대한 제3 요청을 수신 - 상기 제3 요청은 제1 애플리케이션을 식별함 - 하고, 상기 제3 요청이 인증된 요청임을 판정하고 상기 제1 애플리케이션에 대한 통계의 상세화된 세트를 회신하도록 또한 구성된
시스템.
시스템으로서,
적어도 하나의 프로세서와,
애플리케이션 트레이스 데이터베이스와,
모듈 트레이스 데이터베이스와,
상기 적어도 하나의 프로세서 상에서 실행되는 데이터 프리프로세서와,
분석 엔진을 포함하되,
상기 데이터 프리프로세서는, 애플리케이션 특정 코드 및 재사용가능 모듈 코드를 포함하는 애플리케이션으로부터 트레이싱 데이터를 수집하고, 모듈 트레이스 데이터를 식별하고 상기 모듈 트레이스 데이터를 상기 모듈 트레이스 데이터베이스 내에 저장하며, 애플리케이션 트레이스 데이터를 식별하고 상기 애플리케이션 트레이스 데이터를 상기 애플리케이션 트레이스 데이터베이스 내에 저장하며,
상기 분석 엔진은, 상기 애플리케이션 트레이스 데이터의 제1 애플리케이션 특정 뷰를 생성하고, 상기 모듈 트레이스 데이터의 제1 모듈 특정 뷰를 생성하는
시스템.
제34항에 있어서,
상기 모듈 특정 뷰는 복수의 애플리케이션으로부터 수집된 모듈 트레이스 데이터를 포함하는
시스템.
제35항에 있어서,
상기 모듈 특정 뷰는 상기 모듈에 대한 성능 메트릭을 포함하는
시스템.
제36항에 있어서,
상기 성능 메트릭은 상기 모듈을 위한 리소스 사용을 포함하는
시스템.
제37항에 있어서,
상기 성능 메트릭은 상기 모듈 내에 포함된 복수의 기능 각각에 대해 정의되는
시스템.
제35항에 있어서,
상기 모듈 특정 뷰는 상기 모듈에 대한 사용 메트릭을 포함하는
시스템.
제39항에 있어서,
상기 사용 메트릭은 상기 모듈 내에 포함된 복수의 기능 각각에 대해 정의되는
시스템.
제40항에 있어서,
상기 사용 메트릭은 상기 복수의 애플리케이션 각각에 대해 정의되는
시스템.
제34항에 있어서,
상기 모듈 특정 뷰는 신뢰성 메트릭을 포함하는
시스템.
제42항에 있어서,
상기 신뢰성 메트릭은 상기 모듈에 대한 단일 메트릭인
시스템.
제42항에 있어서,
상기 모듈 특정 뷰는 상기 모듈 내의 복수의 기능 각각에 대한 신뢰성 메트릭을 포함하는
시스템.
적어도 하나의 컴퓨터 프로세서에 의해 수행되는 방법으로서,
애플리케이션으로부터 모아진 트레이싱 데이터를 수신하는 단계 - 상기 애플리케이션은 애플리케이션 특정 코드 및 재사용가능 모듈 코드를 포함함 - 와,
모듈 트레이스 데이터를 식별하고 상기 모듈 트레이스 데이터를 모듈 트레이스 데이터베이스 내에 저장하는 단계와,
애플리케이션 트레이스 데이터를 식별하고 상기 애플리케이션 트레이스 데이터를 애플리케이션 트레이스 데이터베이스 내에 저장하는 단계와,
상기 애플리케이션 트레이스 데이터의 제1 애플리케이션 특정 뷰를 생성하는 단계와,
상기 모듈 트레이스 데이터의 제1 모듈 특정 뷰를 생성하는 단계를 포함하는
방법.
제45항에 있어서,
상기 모듈 트레이스 데이터를 저장하기 전에 상기 모듈 트레이스 데이터를 익명화하는 단계를 더 포함하는
방법.
제46항에 있어서,
상기 익명화는 상기 모듈 트레이스 데이터의 적어도 일부분을 난독화함(obfuscating)으로써 수행되는
방법.
제47항에 있어서,
상기 애플리케이션 트레이스 데이터의 상기 제1 애플리케이션 특정 뷰에 대한 제1 요청을 수신하는 단계와,
상기 제1 요청이 인증된 요청임을 판정하는 단계와,
상기 애플리케이션 트레이스 데이터의 상기 제1 애플리케이션 특정 뷰로써 상기 제1 요청에 응답하는 단계를 더 포함하는
방법.
제48항에 있어서,
상기 제1 요청은 애플리케이션 개발자에 의한 인증된 요청인
방법.
제48항에 있어서,
상기 모듈 트레이스 데이터의 상기 제1 모듈 특정 뷰에 대한 제2 요청을 수신하는 단계와,
상기 모듈 트레이스 데이터의 상기 제1 모듈 특정 뷰로써 상기 제2 요청에 응답하는 단계를 더 포함하는
방법.
시스템으로서,
애플리케이션 내에 포함된 모듈에 대한 이용 데이터 및 성능 데이터를 포함하는 모듈 특정 데이터베이스 - 상기 모듈은 저장소 내 이용가능한 재사용가능 코드를 포함함 - 와,
상기 애플리케이션에 대한 이용 데이터 및 성능 데이터를 포함하는 애플리케이션 특정 데이터베이스와,
모듈 특정 데이터에 대한 제1 요청을 수신 - 상기 제1 요청은 제1 모듈에 대한 요청을 포함함 - 하고, 상기 제1 요청이 인증된 요청이 아님을 판정하고 상기 제1 모듈에 대한 통계의 제1 요약 세트를 회신하며, 상기 모듈 특정 데이터에 대한 제2 요청을 수신 - 상기 제2 요청은 상기 제1 모듈에 대한 요청을 포함함 - 하고, 상기 제2 요청이 인증된 요청임을 판정하고 상기 제1 모듈에 대한 통계의 상세화된 세트를 회신하도록 구성된 액세스 포털을 포함하는
시스템.
제51항에 있어서,
상기 액세스 포털은 애플리케이션 특정 데이터에 대한 제3 요청을 수신 - 상기 제3 요청은 제1 애플리케이션을 식별함 - 하고, 상기 제3 요청이 인증된 요청임을 판정하고 상기 제1 애플리케이션에 대한 통계의 상세화된 세트를 회신하도록 또한 구성된
시스템.
제52항에 있어서,
통계의 상기 상세화된 세트는 기능의 리스트(list) 및 기능의 상기 리스트 내의 각각의 기능에 대한 통계의 세트를 포함하는
시스템.
제53항에 있어서,
각각의 기능에 대한 통계의 상기 세트는 각각의 기능에 대한 사용 통계를 포함하는
시스템.
제54항에 있어서,
각각의 기능에 대한 통계의 상기 세트는 각각의 기능에 대한 성능 통계를 포함하는
시스템.
제55항에 있어서,
통계의 상기 상세화된 세트는 상기 제1 모듈에 대한 토폴로지 그래프(topology graph)를 포함하는
시스템.
제55항에 있어서,
통계의 상기 상세화된 세트는 상기 제1 모듈에 대한 사용 통계를 포함하는
시스템.
제53항에 있어서,
통계의 상기 상세화된 세트는 신뢰성 인자(reliability factor)를 포함하는
시스템.
제58항에 있어서,
통계의 상기 상세화된 세트는 기능의 상기 리스트 내의 각각의 기능에 대해 상기 신뢰성 인자를 포함하는
시스템.
제59항에 있어서,
통계의 상기 상세화된 세트는 상기 모듈에 대한 단일 신뢰성 인자를 포함하는
시스템.
제60항에 있어서,
통계의 상기 상세화된 세트는 상기 모듈에 대한 인기도 인자(popularity factor)를 포함하는
시스템.
제61항에 있어서,
통계의 상기 상세화된 세트는 상기 모듈에 대한 경향 인자(trending factor)를 포함하는
시스템.
제62항에 있어서,
통계의 상기 상세화된 세트는 데이터세트 정보(dataset information)를 포함하는
시스템.
제63항에 있어서,
상기 데이터세트 정보는 통계의 상기 상세화된 세트를 생성하기 위해 분석된 데이터세트의 개수를 포함하는
시스템.
제64항에 있어서,
상기 데이터세트 정보는 통계의 상기 상세화된 세트를 생성하기 위해 분석된 애플리케이션의 개수를 포함하는
시스템.