KR20070105167A - 임베디드 소프트웨어의 재사용율 측정 장치 및 방법 - Google Patents

임베디드 소프트웨어의 재사용율 측정 장치 및 방법 Download PDF

Info

Publication number
KR20070105167A
KR20070105167A KR1020060037278A KR20060037278A KR20070105167A KR 20070105167 A KR20070105167 A KR 20070105167A KR 1020060037278 A KR1020060037278 A KR 1020060037278A KR 20060037278 A KR20060037278 A KR 20060037278A KR 20070105167 A KR20070105167 A KR 20070105167A
Authority
KR
South Korea
Prior art keywords
reuse
function
software
reuse rate
functions
Prior art date
Application number
KR1020060037278A
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 삼성전자주식회사
Priority to KR1020060037278A priority Critical patent/KR20070105167A/ko
Publication of KR20070105167A publication Critical patent/KR20070105167A/ko

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/30Creation or generation of source code
    • G06F8/36Software reuse
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/41Compilation
    • G06F8/44Encoding
    • G06F8/447Target code generation

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

본 발명은 임베디드 소프트웨어 재사용율 측정 장치 및 방법에 관한 것으로, 재사용율 측정의 기준이 되는 기준 소프트웨어와 재사용율을 측정하기 위한 다수의 대상 소프트웨어들을 구성하는 함수 리스트를 추출하여 해당 함수들의 재사용 여부를 판단하여 재사용된 함수에 대해 함수 재사용율 측정을 수행한다.
임베디드 소프트웨어, 함수 리스트, 함수 재사용율, 컴포넌트 재사용율

Description

임베디드 소프트웨어의 재사용율 측정 장치 및 방법{Apparatus and method for measuring reuse ratio of embedded software}
도 1은 종래 기술에 따른 소프트웨어 재사용율 측정 장치를 도시한 도면.
도 2는 본 발명의 실시예에 따른 임베디드 소프트웨어의 재사용율 측정 장치를 도시한 도면.
도 3은 본 발명의 실시예에 따른 임베디드 소프트웨어의 재사용율 측정 방법을 도시한 도면.
도 4는 본 발명의 제 1 실시예에 따른 함수 재사용율 측정 결과를 도시한 도면.
도 5는 본 발명의 제 2 실시예에 따른 컴포넌트 재사용율 측정 결과를 도시한 도면.
<도면의 주요 부분에 대한 부호의 설명>
200: 소프트웨어 입력부 210: 함수 리스트 추출 및 재사용 판단부
220: 재사용율 측정부 230: 결과 출력부
본 발명은 임베디드 소프트웨어의 재사용율 측정 장치 및 방법에 관한 발명으로서, 재사용율 측정의 기준이 되는 기준 소프트웨어와 재사용율 측정을 위한 다수의 대상 소프트웨어들을 구성하는 함수 리스트를 추출하여 재사용 여부를 판단하고, 해당 함수들에 대한 함수 재사용율과 컴포넌트 재사용율을 측정하는 임베디드 소프트웨어의 재사용율 측정 장치 및 방법에 관한 것이다.
특정 산업용 기기의 제어를 위해 사용되던 임베디드 시스템이 유무선 통신 네트워크와 접목으로 디지털 정보가전, 의료, 항공, 군사 등 전 산업 분야로 확대되는 Embedded, Everywhere 시대가 도래하고 있다.
임베디드 시스템은 실시간 처리, 저전력 등의 물리적 특성과 하드웨어(HW)와 소프트웨어(SW)의 동시 설계, 리소스의 절제된 사용 등의 특성을 반영해야 하므로 시스템 개발 전 과정에서 이러한 특성을 만족시키는 개발체계의 구축이 필요하다. 특히, 임베디드 소프트웨어의 공통ㆍ핵심 기술을 자산화하여 체계적으로 재사용할 수 있는 환경 구축은 기술의 중복 개발을 최소화하고, 기술의 가치를 지속적으로 증대시킨다.
따라서, 고품질의 임베디드 시스템을 적시에 경제적으로 개발할 수 있는 임베디드 소프트웨어 재사용 체계의 개발 및 보급 기술은 소프트웨어 산업 경쟁력 향상에 공통적으로 필요한 기반 기술로 활용될 수 있으며, 임베디드 소프트웨어의 개발 생산성을 높이고 동일 조직에서 만들어진 소프트웨어 자산의 가치를 지속적으로 극대화시킬 수 있는 임베디드 소프트웨어의 재사용 체계를 구축하고 있다.
그러나 오늘날의 소프트웨어 산업에서 가치가 급속히 증가하고 있는 임베디 드 소프트웨어를 위한 재사용 체계는 전무한 실정이라고 할 수 있다.
도 1은 종래 기술에 따른 소프트웨어 재사용율 측정 장치의 구성을 도시한 도면이다.
종래 기술에 따른 소프트웨어 재사용율 측정 장치의 구성은 측정대상 및 환경변수 입력부(100), 아키텍쳐 및 컴포넌트 재사용 분석엔진(110), 개발 프로세스 재사용 분석엔진(120), 개발 방법 및 도구 재사용 분석엔진(130), 개발인력 재사용 분석엔진(140), 재사용성 측정 메트릭스 데이터베이스(150), 재사용 측정엔진(160), 재사용성 측정 지식 베이스(170), 통계적 재사용성 예측모델베이스(180), 측정결과 출력부(190)를 포함한다.
측정대상 및 환경변수 입력부(100)는 소프트웨어의 재사용성에 영향을 미치는 아키텍처 및 컴포넌트, 개발프로세스, 개발방법 및 도구, 그리고 개발인력에 대한 특성과 환경변수를 입력한다.
아키텍처 및 컴포넌트 재사용 분석엔진(110)은 조직이 재사용이 가능한 아키텍처 및 컴포넌트를 분석하여 재사용성에 영향을 미치는 정보를 추출한다.
재사용이 가능한 아키텍처에는 시스템 아키텍처, 기술 아키텍처, 운용아키텍처, 소프트웨어 아키텍처, 컴포넌트 아키텍처를 포함하며, 재사용이 가능한 컴포넌트는 상용 구매로 획득이 가능한 컴포넌트, 라이브러리 또는 레포지토리에 관리하는 컴포넌트, 재사용을 위하여 개발되는 컴포넌트, 시스템 유티리티로 제공되는 컴포넌트를 포함한다.
재사용 컴포넌트의 범위는 완전한 재사용과 수정 후 재사용을 포함하며, 높 은 수준의 엔지니어링 산출물 재사용과 낮은 수준의 엔지니어링 산출물 재사용을 포함한다. 여기서, 컴포넌트재사용에 영향을 미치는 요인은 컴포넌트의 단순성, 플랫폼 독립성, 접근성, 응용분야 독립성, 자기 표현력, 명료성, 모듈성 및 일반성을 포함한다.
개발 프로세스 재사용 분석엔진(120)은 개발 프로세스를 분석하여 재사용성에 영향을 미치는 정보를 추출하며, 개발 프로세스는 조직 프로세스, 관리프로세스, 엔지니어링 프로세스 및 재사용 프로세스를 포함한다.
개발 방법 및 도구 재사용 분석엔진(130)는 개발 방법 및 도구를 분석하여 재사용성에 영향을 미치는 정보를 추출한다. 재사용이 가능한 개발 방법은 절차 지향 방법, 객체 지향 방법, 컴포넌트 기반 방법 및 역공학 방법을 포함하며, 재사용이 가능한 도구에는 비쥬얼 모델링 도구, 형상 및 변경관리 도구, 시험평가 도구, 요구사항관리 도구, 재사용 지원 도구, 라이브러리를 포함한다.
개발 인력 재사용 분석엔진(140)은 개발 인력의 재사용성에 영향을 미치는 정보를 분석하여 추출한다. 여기서, 개발 인력의 개념은 프로젝트 관리자, 분석자, 설계자, 프로그래머, 레포지토리 관리자, 재사용 전문가 등을 포함하며, 개발 인력의 재사용성에 영향을 미치는 정보는 개발인력의 객체기술, 컴포넌트기술, 재사용기술 및 객체지향 프로그래밍과 관련된 경험 및 지식을 계량화한 정보를 포함한다.
재사용성 측정 메트릭스 데이터베이스(150)는 재사용성 측정기준을 제공하며, 퍼센트에 의한 재사용성 척도 및 재사용성 지수에 의한 척도를 제공한다. 여기서, 재사용성은 신규로 개발하여 획득한 소프트웨어의 규모와 조직이 일정기간에 또는 특정 프로젝트에서 획득한 소프트웨어의 규모를 비교하여 표현한다.
재사용성 측정엔진(160)은 재사용성에 영향을 미치는 정보에 의하여 재사용성을 측정하는 작업을 수행한다. 재사용성 측정엔진(160)은 통계적 재사용성 예측 모델베이스(180) 및 재사용성 측정 지식베이스(170)와 유기적으로 재사용성 측정 작업을 수행한다.
재사용성 측정 지식베이스(170)는 재사용성의 측정 또는 예측에 필요한 규칙, 지침 및 지식의 집합이다.
통계적 재사용성 예측모델베이스(180)는 식별된 재사용성에 영향을 미치는 정보를 이용하여 통계확률론과 경영과학기법을 이용하여 재사용성을 예측하는 모델들의 집합이다. 예측모델은 결정론적 문제해결방법과 비결정론적 문제해결방법을 포함한다.
측정결과 출력부(190)는 상기 재사용성 측정엔진(160)의 측정결과를 화면 또는 인쇄 방식으로 출력한다. 여기서, 필요 시 상기의 재사용성 측정 과정을 반복 할 수 있다.
이와 같은 종래 기술에 따른 소프트웨어 재사용율 측정 장치는 구성이 복잡하며, 소프트웨어 재사용율 측정 방법이 정형화되어 있지 않아서 소프트웨어 재사용율 측정의 객관성, 신뢰성 및 정확성을 확보할 수 없다.
뿐만 아니라, 복잡한 구성으로 인해 규모가 큰 소프트웨어에 적용 시 오버헤드가 발생할 가능성이 높다는 단점이 있다.
본 발명은 상기한 문제점을 개선하기 위해서 고안된 것으로, 본 발명이 이루고자 하는 기술적 과제는 재사용율을 측정하기 위한 다수의 소프트웨어들을 구성하는 함수 리스트를 추출하여 해당 함수들의 재사용 여부를 판단하여 함수 재사용율을 측정하고, 재사용된 함수를 바탕으로 컴포넌트 재사용율을 측정하는 임베디드 소프트웨어의 재사용율 측정 장치 및 방법을 제공하는 것이다.
본 발명의 목적들은 이상에서 언급한 목적들로 제한되지 않으며, 언급되지 않은 또 다른 목적들은 아래의 기재로부터 당업자에게 명확하게 이해될 수 있을 것이다.
상기 목적을 달성하기 위하여 본 발명의 실시예에 따른 임베디드 소프트웨어의 재사용율 측정 장치는 재사용율 측정의 기준이 되는 기준 소프트웨어 코드와 재사용율을 측정하기 위한 다수의 대상 소프트웨어 코드를 입력받는 소프트웨어 입력부, 기준 소프트웨어 코드를 구성하는 함수들의 리스트와 다수의 대상 소프트웨어의 코드를 구성하는 함수들의 리스트가 추출되는 함수 리스트 추출부, 추출된 리스트를 비교함으로써, 다수의 대상 소프트웨어 코드를 구성하는 함수들의 재사용 여부를 판단하여 함수 재사용율을 측정하는 재사용율 측정부를 포함한다.
상기 목적을 달성하기 위하여 본 발명의 실시예에 따른 임베디드 소프트웨어의 재사용율 측정 방법은 재사용율 측정의 기준이 되는 기준 소프트웨어 코드와 재사용율을 측정하기 위한 다수의 대상 소프트웨어 코드를 입력하는 소프트웨어 입력 단계, 기준 소프트웨어 코드를 구성하는 함수들의 리스트와 다수의 대상 소프트웨 어의 코드를 구성하는 함수들의 리스트를 추출하는 함수 리스트 추출단계, 추출된 리스트를 비교함으로써, 다수의 대상 소프트웨어 코드를 구성하는 함수들의 재사용 여부를 판단하여 함수 재사용율을 측정하는 함수 재사용율 측정단계를 포함한다.
기타 실시예들의 구체적인 사항들은 상세한 설명 및 도면들에 포함되어 있다.
본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 개시되는 실시예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시예들은 본 발명의 개시가 완전하도록 하고, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.
임베디드 소프트웨어뿐만 아니라 통상적인 소프트웨어의 테스트에는 블랙 박스(Black Box) 테스트와 화이트 박스(White Box) 테스트를 포함할 수 있다.
블랙 박스 테스트는 설계된 소프트웨어의 특수한 기능을 개발자가 알고 있을 경우 해당 소프트웨어의 작동을 테스트하는 것으로, 소프트웨어 인터페이스에서 실시되며, 테스트 항목으로는 소프트웨어의 기능의 작동 여부, 입/출력의 정확한 수용 여부, 외부 정보의 무결성 유지 등을 테스트 항목으로 포함한다.
블랙 박스 테스트에서의 테스트 결과는 부정확하거나 누락된 기능, 인터페이스 오류, 자료구조나 외부 데이터베이스 접근에 존재하는 오류, 성능 오류, 초기화 와 종료 오류 등으로 나타날 수 있다.
반면, 화이트 박스 테스트는 설계된 소프트웨어의 내부 동작을 알고 있을 경우 해당 소프트웨어 내부의 상호 연관성을 테스트하는 것으로, 소프트웨어 내부의 세부적인 절차를 테스트 한다.
화이트 박스 테스트에서의 테스트 항목으로는 모듈 안의 모든 독립된 경로가 한번 이상 실행되는지의 여부, True, False의 논리적 비교, 모든 루프의 실행, 내부 자료구조 등을 테스트 한다. 이러한 테스트의 결과는 초기화 결함, 인덱싱 및 증가의 결함, 루프의 경계선에 나타나는 경계 결함 등의 형태로 테스트 결과가 나타날 수 있다.
도 2는 본 발명의 실시예에 따른 임베디드 소프트웨어의 재사용율 측정 장치를 도시한 도면이다.
본 발명의 실시예에 따른 임베디드 소프트웨어의 재사용율 측정 장치는 소프트웨어 입력부(200), 함수 리스트 추출부(210), 재사용율 측정부(220), 결과 출력부(230)를 포함할 수 있다. 임베디드 소프트웨어의 재사용율 측정 장치는 4개의 구성요소에 국한하지 않고, 구현 방식에 따라 소프트웨어 입력부(200)와 함수 리스트 추출부(210)를 통합하거나 함수 리스트 추출부(210)와 재사용율 측정부(220)를 통합하여 3개의 모듈로 구성할 수 있으며, 재사용율 측정부(220)를 함수 재사용율 측정부(미도시), 컴포넌트 재사용율 측정부(미도시)로 세분화하여 구성할 수도 있다.
즉, 본 발명의 실시예에 따른 임베디드 소프트웨어의 재사용율 측정 장치는 구성 요소의 조합 또는 이들로부터 파생될 수 있는 모든 구성을 포함할 수 있다.
소프트웨어 입력부(200)는 재사용율을 측정하기 위한 다수의 소프트웨어를 입력하는 장치로 프로그래머가 입력 도구를 통해 직접 입력할 수도 있고, 기작성된 프로그램들의 경우 불러오기 형식으로 입력할 수도 있다.
다수의 소프트웨어들은 동일한 조직에서 동일한 프로그래머들로부터 개발된 소프트웨어들로 베이스 소프트웨어와 베이스 소프트웨어의 표준화된 공통 부분과 잘 알려진 프로세스를 재사용하여 개발된 소프트웨어들이 포함될 수 있고, C, C++, Java로 구현될 수 있다.
함수 리스트 추출부(210)는 소프트웨어 입력부(200)를 통해서 입력될 수 있는 다수의 소프트웨어들에서 해당 소프트웨어를 구성하는 함수들을 파싱(Parsing)하여 함수 리스트를 추출할 수 있다. 구성 함수 리스트의 추출은 C, C++, Java로 구현된 다수의 소프트웨어들에 대해서 상용 도구인 UFC++을 이용하여 다수의 소프트웨어에 대응되는 다수의 엑셀 파일로 추출하여 디스플레이부(미도시)에 출력될 수 있고, 인쇄 방식으로 출력될 수도 있다.
재사용율 측정부(220)는 구현 방식에 따라 화이트 박스 재사용과 같은 함수 재사용율 측정부와 블랙 박스 재사용과 같은 컴포넌트 재사용율 측정부로 세분화하여 2개의 재사용율 측정부(220)로 구성할 수 있다.
재사용율 측정부(220)를 제 1 재사용율 측정부(미도시), 제 2 재사용율 측정부(미도시)로 세분화 할 경우 제 1 재사용율 측정부에서는 함수 재사용율을 측정할 수 있고, 제 2 재사용율 측정부에서는 컴포넌트 재사용율을 측정할 수 있다.
재사용율을 측정하기 위해서는 함수 리스트를 구성하는 함수들에 대한 재사 용 여부 판단이 선행될 수 있다.
함수 리스트의 재사용 여부 판단은 추출된 함수들에서 함수 명, 파라미터, 함수 위치가 동일할 경우 해당 함수들이 재사용 되었음을 판단할 수 있으며, 함수 사이즈가 동일 할 경우 해당 함수들에 대해 함수 재사용율을 측정할 수 있다.
함수의 사이즈는 소프트웨어 코드의 라인 수(Line Of Code)로 4가지 타입으로 분류될 수 있으며, 4가지 타입은 공백 코드의 라인 수(Blank LOC), 주석 코드의 라인 수(Comment LOC), 실제 코드의 라인 수(Actual LOC), 총 코드의 라인 수(Total LOC)로 분류될 수 있다. 실제 코드의 라인 수는 공백 코드의 라인 수와 주석 코드의 라인 수를 제외한 실제로 수행될 수 있는 코드들의 라인 수를 의미한다.
재사용율 측정부(220)에서는 재사용율 측정을 위한 측정 지표로 FRR(Function Reuse Ratio) 및 BFRR(Black-Box Function Reuse Ratio) 또는 CRR(Comment Reuse Ratio)중 적어도 하나의 측정 지표를 바탕으로 함수 또는 컴포넌트의 재사용율을 측정할 수 있다.
제 1 재사용율 측정부의 함수 재사용율 측정은 함수 리스트 추출 및 재사용 판단부(210)에서 엑셀 파일로 추출되어 화이트 박스 재사용 된 함수들의 재사용율을 측정하는 것으로, 재사용 지표로
Figure 112006028966595-PAT00001
를 적용할 수 있다.
FRR이 80%인 경우 개발 소프트웨어는 베이스 소프트웨어를 구성하는 함수들 의 80%를 재사용 하여 개발 되었음을 판단할 수 있다.
제 1 재사용율 측정부에서는 앞서 언급 했듯이 함수 명, 파라미터, 함수 위치가 동일한 상태에서 함수 사이즈가 동일할 경우 화이트 박스 테스트를 통해 화이트 박스 재사용 여부를 판단하여 함수 재사용율을 측정할 수 있다.
화이트 박스 테스트는 설계된 소프트웨어의 내부 동작을 알고 있을 경우 해당 소프트웨어 내부의 상호 연관성을 테스트하는 것으로, 소프트웨어 내부의 세부적인 절차를 테스트 할 수 있으며, 화이트 박스 재사용 함수들은 일반화/상세화의 관계나 상속 구조를 통해 클래스 등을 재사용한 것을 의미한다.
제 2 재사용율 측정부의 컴포넌트 재사용율 측정은 제 1 재사용율 측정부에서 화이트 박스 재사용된 함수 쌍에 엑셀 매크로의 Diff를 적용하여 두 함수가 동일할 경우 해당 함수들의 블랙 박스 재사용 여부를 판단하고, 컴포넌트 재사용율을 측정할 수 있다.
제 2 재사용율 측정부에서는 재사용 지표로 CRR을 적용할 수 있다.
Figure 112006028966595-PAT00002
를 적용하여 해당 소프트웨어들의 컴포넌트 재사용율을 측정할 수 있다.
제 2 재사용율 측정부는 제 1 재사용율 측정부에 비해 고수준의 재사용율을 측정할 수 있으나 오버헤드가 발생할 수 있으므로, 제 1 재사용율 측정부에서의 함수 재사용율 측정이 바람직한 실시예가 될 수 있다.
결과 출력부(230)는 소프트웨어 입력부(200)를 통해 입력된 다수의 소프트웨 어들의 함수 리스트 추출 결과와 재사용 판단에 따른 재사용 여부 결과, 재사용율 측정부(220)에서의 함수 재사용율 측정 결과, 컴포넌트 재사용율 측정 출력 결과들을 인쇄 방식 또는 디스플레이부에 표시할 수 있다.
도 3은 본 발명의 실시예에 따른 임베디드 소프트웨어의 재사용율 측정 방법을 도시한 도면이다.
본 발명의 실시예에 따른 임베디드 소프트웨어의 재사용율 측정 방법은 함수 재사용율 측정과 컴포넌트 재사용율 측정을 포함할 수 있다.
먼저, 소프트웨어 입력부(200)를 통해 입력될 수 있는 다수의 소프트웨어들은 C, C++, Java로 구현된 함수들이 포함될 수 있으며, 해당 소프트웨어를 입력할 수 있다(S300).
입력된 다수의 소프트웨어들은 함수 리스트 추출부(210)에서 함수 리스트를 추출할 수 있다(S310). 함수 리스트의 추출은 입력된 복수의 소프트웨어 코드를 상용 도구 UFC++을 이용하여 해당 소프트웨어들을 구성하는 함수들을 파싱하여 대응되는 함수 리스트를 추출할 수 있다(S310).
추출된 함수 리스트는 엑셀 파일 형식으로 출력되어 엑셀 매크로를 이용하여 함수 리스트에서 대응되는 함수들의 재사용 여부를 판단할 수 있다(S320).
함수 리스트의 재사용 판단은 추출된 함수들에서 함수 명, 파라미터, 함수 위치가 동일한 상태에서 함수 사이즈가 동일할 경우 화이트 박스 재사용임을 판단할 수 있다.
함수의 사이즈는 소프트웨어 코드의 라인 수(Line Of Code)로 4가지 타입으 로 분류 될 수 있으며, 4가지 타입은 공백 코드의 라인 수(Blank LOC), 주석 코드의 라인 수(Comment LOC), 실제 코드의 라인 수(Actual LOC), 총 코드의 라인 수(Total LOC)로 분류될 수 있다. 실제 코드의 라인 수는 공백 코드의 라인 수와 주석 코드의 라인 수를 제외한 실제로 수행될 수 있는 코드들의 라인 수를 의미한다.
화이트 박스 재사용은 설계된 소프트웨어의 내부 동작을 알고 있을 경우 해당 소프트웨어 내부의 상호 연관성을 테스트하는 것으로, 소프트웨어 내부의 세부적인 절차를 테스트 할 수 있으며, 화이트 박스 재사용 함수들은 일반화/상세화의 관계나 상속 구조를 통해 클래스 등을 재사용한 것을 의미한다.
재사용 여부 판단 단계(S320)에서 화이트 박스 재사용 함수의 재사용 여부가 판단되면, 해당 함수들의 재사용율을 측정 할 수 있다(S330).
재사용율 측정은 재사용율 측정부(220)의 구현 방식에 따라 제 1 재사용율 측정부인 함수 재사용율 측정부 또는 제 2 재사용율 측정부인 컴포넌트 재사용율 측정부로 세분화하여 2개의 재사용율 측정부(220)로 구성할 수 있다.
재사용율 측정부(220)를 제 1 재사용율 측정부, 제 2 재사용율 측정부로 세분화 할 경우 제 1 재사용율 측정부에서는 함수 재사용율을 측정할 수 있고(S330), 제 2 재사용율 측정부에서는 컴포넌트 재사용율을 측정할 수 있다(S350).
현 단계(S320)에서는 화이트 박스 재사용 여부가 판단 되었으므로, 제 1 재사용율 측정부에서 함수 재사용율을 측정할 수 있으며, 측정 지표로
Figure 112006028966595-PAT00003
를 적용하여 함수 재사용율을 측정할 수 있다(S330). 제 1 재사용율 측정부에서 함수 재사용율 측정 결과가 80%인 경우 개발된 소프트웨어는 베이스 소프트웨어를 구성하는 함수들의 80%를 재사용 하여 개발 되었음을 판단할 수 있다.
즉, 재사용된 80%의 함수들의 함수 명, 파라미터, 함수 위치, 함수 사이즈가 동일한 함수임을 의미한다.
함수 재사용율이 측정되면(S330), 제 2 재사용율 측정부에서 컴포넌트 재사용율을 측정할 수 있다.
컴포넌트 재사용율은 화이트 박스 재사용 함수이면서, 해당 함수들의 컴포넌트가 동일할 경우 재사용율을 측정할 수 있다.
컴포넌트의 동일 여부는 화이트 박스 재사용 함수들에 엑셀 매크로 Diff를 적용하여 판단할 수 있다(S340).
컴포넌트들의 동일 여부가 판단되면, 해당 함수들에 대해 컴포넌트 재사용율을 측정할 수 있다(S350).
컴포넌트 재사용율 측정 시 측정 지표로
Figure 112006028966595-PAT00004
를 적용하여 컴포넌트 재사용율을 측정할 수 있다.
컴포넌트 재사용율은 블랙 박스 재사용을 의미하며, 블랙 박스 재사용은 객체 인터페이스를 이용하여 객체를 조립하고 결합하여 시스템을 구성할 수 있음을 의미한다.
도 4는 본 발명의 제 1 실시예에 따른 함수 재사용율 측정 결과를 도시한 도면이다.
본 발명의 실시예에 따른 함수 재사용율 측정 결과는 함수 재사용율 요약 정보(400), 함수 정보(410)를 포함할 수 있다.
요약 정보(400)는 재사용율 측정부(220)에서 측정된 다수의 소프트웨어의 함수 재사용율, 총 코드의 라인수, 총 함수 개수, 총 함수 평균 크기, 재사용된 코드의 라인수, 재사용된 함수 개수, 재사용된 함수 평균 크기, 변경된 함수의 재사용을 포함할 수 있다.
재사용율 측정부(220)에서 측정된 함수 재사용율, 화이트 박스 재사용된 함수에 대한 재사용율은 대략 82%가 될 수 있다.
함수 재사용율이 대략 82%가 되는 것은 베이스 소프트웨어 코드의 변경없이 재사용된 경우이며, 코드를 변경하여 재사용 한 경우 대략 35%의 재사용이 될 수 있다.
함수 정보(410)는 파일 명, 함수 명, 함수 사이즈, 속성과 함수 변경 여부가 포함될 수 있으며, 함수 공용화율이 더 포함될 수 있다.
함수 공용화율은 재사용 가능한 함수들에 대한 정보로 재사용 가능한 코드의 라인수, 재사용 가능한 함수의 개수, 재사용 가능한 함수의 평균 크기, 재사용 불가능한 함수 코드의 라인수, 재사용 불가능한 함수의 개수 등이 포함될 수 있다.
도 5는 본 발명의 제 2 실시예에 따른 컴포넌트 재사용율 측정 결과를 도시 한 도면이다.
본 발명의 제 2 실시예에 따른 컴포넌트 재사용율 측정 결과는 컴포넌트 재사용율 요약 정보(500), 컴포넌트 정보(510)를 포함할 수 있다.
컴포넌트 재사용율 요약 정보(500)에는 다수의 소프트웨어에 대한 컴포넌트 재사용율, 총 코드의 라인 수, 컴포넌트 코드의 라인 수, 재사용된 코드의 라인수, 재사용된 컴포넌트의 평균 크기가 포함될 수 있고, 개발 코드의 라인 수, 컴포넌트 수, 재사용 가능한 코드의 라인 수, 재사용 가능한 컴포넌트 평균 크기들이 포함될 수 있다.
컴포넌트 정보(510)는 컴포넌트 명, 크기, 속성, 변경 여부들이 포함될 수 있다.
즉, 도 4의 함수 재사용율 측정 결과와 도 5의 컴포넌트 재사용율 측정 결과를 바탕으로 C, C++, Java로 작성되는 소프트웨어들에 대한 재사용 현황을 파악할 수 있으며, 향후 재사용 가능성을 예측할 수 있어서 현재 개발 중인 소프트웨어의 개선 방향을 제시할 수 있다.
상기한 바와 같은 본 발명의 임베디드 소프트웨어의 재사용율 측정 장치 및 방법에 따르면 다음과 같은 효과가 하나 혹은 그 이상 있다.
첫째, 코드 레벨에서의 재사용 현황과 향후 재사용 가능성을 예측할 수 있다는 장점이 있다.
둘째, 소프트웨어들간의 재사용율을 측정함으로써 소프트웨어 저작권 침해 여부를 판단할 수 있다는 장점도 있다.

Claims (5)

  1. 재사용율 측정의 기준이 되는 기준 소프트웨어 코드와 상기 재사용율을 측정하기 위한 다수의 대상 소프트웨어 코드를 입력받는 소프트웨어 입력부;
    상기 기준 소프트웨어 코드를 구성하는 함수들의 리스트와 상기 다수의 대상 소프트웨어의 코드를 구성하는 함수들의 리스트가 추출되는 함수 리스트 추출부; 및
    상기 추출된 리스트를 비교함으로써, 상기 다수의 대상 소프트웨어 코드를 구성하는 함수들의 재사용 여부를 판단하여 함수 재사용율을 측정하는 재사용율 측정부를 포함하는 임베디드 소프트웨어의 재사용율 측정 장치.
  2. 제 1항에 있어서,
    상기 소프트웨어 코드들을 구성하는 상기 함수 리스트는 UFC++(Understand For C++)을 이용하여 엑셀 파일로 추출하여 상기 함수들의 재사용 여부를 판단하고, FRR(Function Reuse Ratio) 또는 CRR(Comment Reuse Ratio) 중 적어도 하나의 재사용 측정 지표를 이용하여 상기 함수 재사용율을 측정하며, 상기 함수 재사용율이 측정된 함수들에 대해 컴포넌트 재사용율 측정을 더 포함하는 임베디드 소프트웨어의 재사용율 측정 장치.
  3. 재사용율 측정의 기준이 되는 기준 소프트웨어 코드와 상기 재사용율을 측정 하기 위한 다수의 대상 소프트웨어 코드를 입력하는 소프트웨어 입력 단계;
    상기 기준 소프트웨어 코드를 구성하는 함수들의 리스트와 상기 다수의 대상 소프트웨어의 코드를 구성하는 함수들의 리스트를 추출하는 함수 리스트 추출단계; 및
    상기 추출된 리스트를 비교함으로써, 상기 다수의 대상 소프트웨어 코드를 구성하는 함수들의 재사용 여부를 판단하여 함수 재사용율을 측정하는 함수 재사용율 측정단계를 포함하는 임베디드 소프트웨어의 재사용율 측정 방법.
  4. 제 3항에 있어서,
    상기 함수 재사용율 측정은 상기 함수 리스트 중 함수 명, 파라미터, 함수 위치가 동일한 상태에서, 함수 사이즈가 동일한 함수들에 대해 FRR 재사용율 측정 지표를 이용하여 상기 함수 재사용율을 측정하는 임베디드 소프트웨어의 재사용율 측정 방법.
  5. 제 4항에 있어서,
    상기 함수 재사용율이 측정된 상기 함수들에 엑셀 매크로, Diff를 적용하여 컴포넌트의 동일 여부를 판단하여 해당 함수들에 대해 CRR 재사용 측정 지표를 이용하여 컴포넌트 재사용율을 측정하는 임베디드 소프트웨어의 재사용율 측정 방법.
KR1020060037278A 2006-04-25 2006-04-25 임베디드 소프트웨어의 재사용율 측정 장치 및 방법 KR20070105167A (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020060037278A KR20070105167A (ko) 2006-04-25 2006-04-25 임베디드 소프트웨어의 재사용율 측정 장치 및 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020060037278A KR20070105167A (ko) 2006-04-25 2006-04-25 임베디드 소프트웨어의 재사용율 측정 장치 및 방법

Publications (1)

Publication Number Publication Date
KR20070105167A true KR20070105167A (ko) 2007-10-30

Family

ID=38818764

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020060037278A KR20070105167A (ko) 2006-04-25 2006-04-25 임베디드 소프트웨어의 재사용율 측정 장치 및 방법

Country Status (1)

Country Link
KR (1) KR20070105167A (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20210035363A (ko) * 2019-09-23 2021-04-01 국방기술품질원 소프트웨어의 신뢰성 시험 시스템 및 시험 방법
KR20210037628A (ko) * 2020-05-07 2021-04-06 베이징 바이두 넷컴 사이언스 앤 테크놀로지 코., 엘티디. 코드 재사용 처리 방법, 장치, 전자 기기, 컴퓨터 판독 가능 저장 매체 및 컴퓨터 프로그램

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20210035363A (ko) * 2019-09-23 2021-04-01 국방기술품질원 소프트웨어의 신뢰성 시험 시스템 및 시험 방법
KR20210037628A (ko) * 2020-05-07 2021-04-06 베이징 바이두 넷컴 사이언스 앤 테크놀로지 코., 엘티디. 코드 재사용 처리 방법, 장치, 전자 기기, 컴퓨터 판독 가능 저장 매체 및 컴퓨터 프로그램

Similar Documents

Publication Publication Date Title
Schieferdecker et al. Model-based testing.
Immonen et al. Survey of reliability and availability prediction methods from the viewpoint of software architecture
US10169002B2 (en) Automated and heuristically managed solution to quantify CPU and path length cost of instructions added, changed or removed by a service team
Theiler et al. Semantic description of structural health monitoring algorithms using building information modeling
CN100428243C (zh) 用于在模型上实现动作的方法和系统
Debbarma et al. Static and dynamic software metrics complexity analysis in regression testing
Nelson et al. What makes a code review trustworthy?
KR20070105167A (ko) 임베디드 소프트웨어의 재사용율 측정 장치 및 방법
JP2009099111A (ja) 規則検査プログラム、規則検査方法および規則検査装置
Nair Product metrics for IEC 61131-3 languages
Vierhauser et al. From requirements monitoring to diagnosis support in system of systems
US11928047B2 (en) Contextual data generation for application testing in mixed reality simulations
Svoboda et al. Static analysis alert audits: Lexicon & rules
Suprunenko et al. Improving the efficiency of dynamic analysis of the combined simulation model for software with parallelism
Marín et al. A tool for automatic defect detection in models used in model-driven engineering
MacKenzie et al. Verification technology potential with different modeling and simulation development and implementation paradigms
Filax et al. Building models we can rely on: requirements traceability for model-based verification techniques
Albeanu et al. Total quality for software engineering management
Pigoski SWEBOK Knowledge Area Description for Software Evolution and Maintenance (version 0.5)
Lind et al. CompSize: A model-based and automated approach to size estimation of embedded software components
Fadhel et al. Striffs: Architectural component diagrams for code reviews
Berezowski et al. Recommendations for Developing Safety-Related Systems with Graphical Languages.
Schöpp et al. Requirements-based code model checking
Baouya et al. A formal approach for maintainability and availability assessment using probabilistic model checking
Hoang et al. Quantum Software Analytics: Opportunities and Challenges

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E601 Decision to refuse application