글 박세환 (한국과학기술정보연구원 전문연구위원)
소프트웨어 리팩토링(Refactoring)은 소프트웨어의 구조를 변화시켜 그 기능을 개선하는 것으로서 소프트웨어의 효율을 향상시킬 수 있는 장점이 있다. 다만 구조 변환 시 결정적인 오류가 발생하지 않도록 주의해야 한다. 그간 대형 프로세스 정보시스템을 수용하기 위해 대용량 저장장치들이 개발되었다. 이러한 대형 프로세스 모델이 실제 산업현장에 효과적으로 적응하기 위해서는 다양한 요구사항들을 수용할 수 있도록 리팩토링 되어야 한다. 즉, 새로운 프로세스 모델 도입에 따른 위험부담이나 불필요한 복잡성을 최소화해야 한다. 특히 소프트웨어 구조 변경 시 오류가 발생하지 않도록 보다 단순한 프로세스 모델링이 필요하다. 이러한 문제를 해결하기 위해 다양한 소프트웨어 리팩토링 기법들이 개발되어 소프트웨어공학(Software Engineering)에 적용되어 왔다. 이는 최첨단 비즈니스 프로세스에도 변화를 주어 표준 도메인이 개발되는 결과를 낳았다. 모든 프로세스 모델에 동일하게 적용하기에는 한계가 있겠지만 프로세스 모델의 카탈로그 리팩토링 기법에 따라서는 적절한 분야에 적용할 수 있다.
이 연구에서는 소프트웨어 리팩토링 기법에 따른 대용량 저장장치의 프로세스 모델을 제시한다. 제시된 리팩토링 프로세스 모델은 소프트웨어 설계자가 간단하게 프로세스를 모델링할 수 있도록 모델의 복잡성을 최소화 하였다. 이를 헬스 케어(healthcare) 분야 및 자동차 설계 분야에 적용하여 프로토타입(prototype)을 구현하고 기능을 시험한 결과를 분석한다.
1. 개요
1.1. 문제제기
수많은 프로세스 모델로 구성된 대형 프로젝트에서 PAIS(Process-Aware Information System: 프로세스 인식 정보시스템)는 프로세스 모델링에 있어 가장 중요한 핵심 기술이다. 다중 프로세스 모델로 구성된 대형 프로젝트는 품질관리 측면에서 오버타임(over time)의 문제 및 기존 프로세스에 대한 새로운 요구사항 등 여러 가지 문제를 일으킬 수 있다. 소프트웨어의 구조를 변화시키는 리팩토링의 경우 프로세스 모델의 구조 변경 과정에서 새로운 프로세스 모델의 산업적 적용 시 특히 다음과 같은 품질관리 문제를 강조한다.
프로세스 모델 재구성을 고려하는 프로젝트는 태스크 관리기능 등을 실행하는 데 필요한 저장장치의 유연성을 3.3%에서 최대 37.5%까지 광범위한 확장성이 필요하다고 강조하고 있다.
Software Engineering(소프트웨어공학)에서는 다양한 개발자에 의해 컴퓨터 프로그램의 소스코드(source code)가 수정되거나 증가될 때 시간이 지나면서 점차 기능이 퇴화된다고 알려져 있다. 다수의 사용자가 단일 저장장치를 액세스하기 때문에 소프트웨어 프로그램의 급속한 진화에 따른 품질관리 문제가 대두될 수 있다는 것이다.
소프트웨어 리팩토링 기술은 프로그래머가 소프트웨어의 구조를 변경하지 않고서도 소프트웨어의 코드블록(code block)들의 유효성을 유지할 수 있어야 한다. 이는 중복성을 제거하고 가독성(understandability)을 단순화하여 소프트웨어 설계기술을 향상시키거나, 확장성(유연성)을 증가시켜 소스코드의 품질을 향상시키는데 기여한다. 소프트웨어공학 측면에서 중요성을 시사하고 있는 리팩토링 기법은 중복코드를 감소시키고 기존의 코드 블록으로부터의 새로운 코드를 추출함으로써 소스코드 블록의 유효성 및 가독성을 향상시키는 것이다.
새로운 정보를 생산하기 위한 프로세스 모델과 컴퓨터 프로그램은 기업의 프로젝트의 복잡도 등에 따라 순차적 실행(consecutive executions), 병행성(concurrency) 및 조건부 라우팅(conditional routings) 등 실행처리 플로우가 다양하게 나타날 수 있다. 컴퓨터 프로그램은 모듈(module) 및 클래스(class)로 분할된다. 각 모듈은 수많은 텍스트로 구성되며, 모든 텍스트는 변수/상수/프로세스 모델링/연산 동작 등으로 구성된다. 이처럼 프로세스 모델과 컴퓨터 프로그램은 다양한 관점에서 서로 유사한 기능 구조를 갖고 있다.
1.2. 연구의 목적
이 연구에서는 생산공정 모델링에 소프트웨어공학의 리팩토링 개념을 적용한다. 이를 위해서는 첫째, 소프트웨어 리팩토링 확인을 용이하게 할 수 있는 프로세스 모델을 제시해야 한다. 둘째, 제시한 프로세스 모델을 기반으로 소프트웨어 리팩토링 기술을 도입해야 한다.
리팩토링 기술은 read(판독/해독)와 maintain(유지보수) 기능을 용이하게 실행함으로써 프로세스 모델의 품질을 향상시킬 수 있다. 그러나 이는 프로세스 모델의 의미론 또는 외부 행동에는 영향을 미치지 않는다. 왜냐하면 생산공정 설계자나 최종 의사결정자는 소프트웨어 리팩토링 기능을 특정한 상황에 적용하여 결과에 대한 모니터링을 중요시하기 때문이다. 그런 의미에서 제안된 리팩토링 기술은 프로세스 모델 설계과정 상의 오류를 최소화하기 위한 단계라고 볼 수 있다. 나아가 프로세스 재설계와 적용방식 등에 대한 이전 작업의 미비점을 보충하는 것이다.
소프트웨어 리팩토링과 프로세스 재설계는 필요 시 프로세스 모델의 변경을 요구할 수도 있다. 특히 프로세스 재설계 범위를 보다 더 광범위하게 구조적 적용을 실행함으로써 소프트웨어의 성능을 향상시킬 수 있는 것으로 나타났다. 따라서 프로세스 재설계는 종종 PAIS(프로세스 인식 정보시스템)의 외부적 품질에 영향을 미치게 되고, 이는 결국 고객의 수요를 어느 정도 수용할 수 있느냐에 따라 QoS(Quality of Services)가 좌우될 수 있다. 소프트웨어 리팩토링 기술은 주로 PAIS의 내부적 품질에 영향을 줄 수 있는 무결성, 확장성 및 보전성 등을 촉진시킬 수 있다.
2. 연구의 사전준비
2.1. 프로세스 저장장치의 메타 모델
프로세스 저장장치의 가장 본질적인 요소는 프로세스 모델이다. 프로세스 모델링 언어에는 EPC(Event-driven Process Chain), BPMN(Business Process Modeling Notation) 및 Work-flow Nets 등이 대중화되어 있다. 이들은 각기 의미론적인 차이를 갖고 있다. 프로세스 모델 설계자는 이러한 콘텍스트 기반의 흐름제어(flow control)로부터 생성되는 일련의 실행결과들을 게이트웨이(gateway)를 통해 프로세스 모델을 결정하게 된다. 이때 게이트웨이는 분할된 노드(node)의 경로를 제공하는 역할을 한다. 여기에는 XOR-split/XOR-join, AND-split/AND-join, OR-split/OR-join 등 3가지 연산방식이 있다.
쪾XOR(배타적 논리합)은 하나의 입력 브랜치(branch)를 통해 다수의 출력을 통합하여 활성화시키는 기능을 갖는다. 즉, AND-split의 분산을 XOR-join을 통해 이들을 서로 연결시키게 되는 것이다.
쪾AND(논리곱)은 여러 분산된 입력 브랜치들을 동시에(병렬방식으로) 연산하여 하나의 출력을 생성하는 기능을 갖는다. 즉, AND-split의 분산을 AND-join을 통해 이들을 서로 연결시키게 되는 것이다.
쪾OR(논리합)은 다중의 입력 브랜치들을 순차적으로(직렬방식으로) 연산하여 하나의 출력을 생성하는 기능을 갖는다. 즉, OR-split의 분산을 OR-join을 통해 이들을 서로 연결시키게 되는 것이다.
대부분의 프로세스 모델은 main-sub 관계형으로 구현된다. 즉, 다수의 활성화 상태의 서브-프로세스 모델들이 전술한 3가지 연산방식을 통해 메인-프로세스 모델로 연결되어 최종 결과를 출력하게 된다. 이러한 다양한 프로세스 모델 트리(process model tree) 구조는 비 순환 방식으로 연산이 실행될 수 있도록 프로그래밍 되어야 한다.
2.2. 프로세스 모델과 리팩토링
Opdyke에 의해 제안된 소프트웨어 리팩토링은 소스코드의 외부 실행을 변경하지 않고 내부 구조를 향상시킬 수 있는 방법으로 소프트웨어 시스템 구조 변환(transform ation)에 자주 이용된다. 중요한 것은 구조 변환 시 결정적인 오류가 발생하지 않아야 한다는 것이다. 아울러 프로세스 모델링을 통해 기능성, 가독성, 보전성 및 적응성을 향상시킬 수 있어야 한다. 그러므로 프로세스 모델링을 통한 소프트웨어 리팩토링은 설계과정에 필수적인 저장장치의 품질을 향상시킬 수 있도록 반복적으로 프로세스를 모델링 한다. 소프트웨어 리팩토링 관련 2004년의 연구에 의하면 다음과 같은 다양한 특징적 프로세스에 의한 리팩토링을 규정하고 있다("A survey of software refactoring", T. Mens, T. Tourwe, 2004).
쪾리팩토링 기회 검증
쪾리팩토링 적용분야 결정
쪾적용된 리팩토링 모델 준수
쪾프로세스 모델 저장장치의 품질 특성에 다른 리팩토링 효과 분석 등
3. 리팩토링 기회의 검증
3.1. 연구 방법론
소스코드에 의한 소프트웨어 리팩토링 기회를 소프트웨어 공학에 기반하여 검증한 결과가 보고된 바 있다(T. Men s, T. Tourwe, 2004). 이 연구에 사용된 소프트웨어 리팩토링 기회 검증을 위한 데이터 소스들을 <표 1>에 나타낸다[1]. 프로세스 모델링을 통해 설정된 7개의 데이터 소스들은 전술한 가독성 및 보전성에 초점을 맞추어 수집된 소스들이다. 데이터 소스들은 헬스 케어(healthcare) 분야(소스 1~4) 및 자동차 설계 분야(소스 5~7)에 적용하여 프로토타입(prototype)을 구현하고 기능에 대한 시험결과를 분석한 것이다.
3.2. 데이터 소스 파라미터
소스 1은 대형 헬스 케어 프로젝트의 매뉴얼에서 증명된 여성의 5대 질병(출산/입원환자의 화학요법 치료/외래 환자의 화학요법 치료/암 수술/난소 수술)에 대한 클리닉 핵심 공정을 분석한 것이다(M. Reichert, P. Dadam, B. Schultheiss, I. Konyen, "Analysis of healthcare pr ocesses in a woman's clinic". DBIS No.27, 28, 29, 16, 15, 14, 7, 6, 5, 1996~997). 이러한 핵심 공정은 EPC(Ev ent Process Chain) Activity Diagram 관점에서 나타난 70개의 프로세스 모델로 구성되며, 각 프로세스 모델은 2~18개의 Activity Diagram을 포함한다.
소스 2는 의학적 가이드라인과 임상실험 결과를 내과학(internal medicine)적으로 표현된 46개의 프로세스 모델로 구성된다.
소스 3은 PAIS(프로세스 인식 정보시스템)을 통해 실행된 요로결석(clinical guideline for urinary stone) 진단을 위한 임상실험 결과로 구성된다.
소스 4는 임상센터로부터 수집된 84개의 프로세스 모델로 구성되며, 각 프로세스 모델은 7~17개의 Activity Diagram을 포함한다.
소스 5는 자동차 개발 프로젝트의 핵심 공정으로서 50개의 매우 복잡한 프로세스 모델의 시각화 연구(R. Bobrik, 2008)를 통한 제품기획 공정을 분석한 것이다.
소스 6은 독일의 자동차 개발 프로젝트에서 ECM(El ectronic Change Management) 사례연구 결과를 분석한 것이다. 이는 EPC Activity Diagram 관점에서 나타난 60개의 프로세스 모델로 구성된다.
소스 7은 자동차 정비 프로젝트의 핵심 공정을 분석한 것이다(A. Hallerbach, T. Bauer, M. Reichert, 2009). 이를 기반으로 68개의 비즈니스 프로세스 모델을 개발하였으며, 약 900개의 프로세스 모델로 변경할 수 있는 것으로 나타났다.
3.3. 프로세스 모델
소프트웨어 리팩토링 기회 검증을 위해 사용된 7개의 데이터 소스(<표 1> 참조)로부터 확인된 프로세스 모델을 <표 2>에 나타낸다[1]. 이는 각 데이터 소스와 관련된 프로세스 모델의 품질을 결정하게 되는 중요한 것이다.
3.4. 프로세스 모델 파라미터
PM 1은 활성화 프로세스 모델의 목적을 나타내는 소스 1의 70개 프로세스 모델을 분석한 것이다. 예를 들면, 16번째 프로세스 모델은 헬스 케어(healthc are) 프로젝트의 의료 시술 스케줄링을 다루는 Activity를 나타낸 것이다.
PM 2는 프로세스 모델 내의 흐름제어 로직(control-flow logic)을 나타내는 것으로서 이해하기 어려운 소프트웨어 로직의 복잡성을 좀 더 간단하게 재구성하여 프로세스 저장장치에 저장하는 것이다. 즉, 전술한 EPC/BP MN/Work-flow Nets 등의 프로세스 모델링 언어들이 갖는 의미론적인 차이를 XOR-split/XOR-join, AND-split/AND-join 및 OR-split/OR-join 등 3가지 연산방식 기반의 흐름제어를 통해 간단한 프로세스 모델을 설정하는 것이다.
PM 3는 다양한 프로세스 모델에 맞는 흐름제어 로직으로 변경하여 프로세스 모델링을 통해 설정된 데이터 소스들의 보전성을 보장하기 위한 것이다. 예를 들면, 여성의 5대 질병에 대한 클리닉 핵심 공정을 나타낸 데이터 소스 1의 경우 70개의 프로세스 모델이 갖는 다양성에도 불구하고 이들을 적절한 반복적 절차를 거쳐 의학적 리포트를 생성하게 하는 것이다.
PM 4는 자동차 개발 프로젝트의 스케줄링을 다루는 50개의 매우 복잡한 프로세스 모델을 시각화하여 800개 이상의 Activity를 통한 제품기획 공정에 관한 프로세스이다. 프로세스 모델 수의 증가와 함께 소프트웨어의 규모가 기하급수적으로 커지는 것을 막아 프로세스 모델의 가독성 및 정확성/무결성(correctness)을 보장하는 것이다.
PM 5는 소프트웨어의 사이즈나 복잡성에 따라 증가되는 저장장치의 보전성을 보장하기 위한 것이다. 예를 들면, 소스 6의 60개 프로세스 모델 중 15번째 모델은 단지 3개의 Activity만을 이용하여 제품기획을 실행함으로써 소프트웨어 로직의 복잡성을 좀 더 간단하게 재구성하는 것이다.
PM 6은 다양한 프로세스 모델들이 갖는 수많은 Activity를 상세하게 규정함으로써 프로세스 모델의 가독성을 향상시키고, 소프트웨어의 보전성을 보장하기 위한 것이다.
PM 7은 특별한 프로세스 인스턴스(process instance)를 실행을 요구하는 프로젝트에서 프로세스 모델에 미리 정의된 프로세스 모델의 흐름제어 로직으로 변경함으로써 전술한 데이터 소스들의 보전성 및 정확성/무결성을 보장하기 위한 것이다. 예를 들면, 헬스 케어 프로젝트에서 효과적인 환자 진료를 위한 임상 지침의 중요성을 들 수 있다. 이를 기반으로 의학적 의사결정을 얻어내는 것이다.
PM 8은 다중 프로세스 모델의 변형체까지 모두 저장할 수 있는 모델의 저장장치를 확장함으로써 데이터 소스들의 보전성을 보장하는 것이다. 예를 들면, 헬스 케어 프로젝트에서 임상센터의 사례연구의 경우 의료시술 분야의 80개의 프로세스 모델이 변형체를 생성할 수 있어 이에 대한 보전성이 필요한 것이다.
4. 리팩토링 기술
4.1. 개요
프로세스 모델의 품질을 향상시키고 핵심 공정을 효과적으로 설계할 수 있는 11가지 리팩토링 기술을 <표 3>에 나타낸다[1]. 이는 헬스 케어 분야(<표 1>의 데이터 소스 1~4) 및 자동차 설계 분야(<표 1>의 데이터 소스 5~7)에 적용하여 구현한 프로토타입의 기능에 대한 시험결과 확인된 리팩토링 기술들이다. 각 리팩토링 기술은 3개의 그룹으로 구분되어 있으며, 각 그룹은 단일 또는 전체 프로세스 모델 트리 항목에 적용될 수 있다. 이는 참조 모델(Reference model)의 핵심공정 설계를 효과적으로 실행할 수 있도록 프로세스 변형체에도 적용될 수 있다.
4.2. 리팩토링 파라미터
RF 1은 프로세스 모델의 구조 변경(Rename)에 따른 Activity로서 임의의 Activity 명칭으로 라벨링되지 않아야 하는 것을 필수조건으로 하고 있다.
RF 2는 프로세스 모델의 구조 변경(Rename)에 따른 프로세스 개요를 나타낸다. 이는 임의의 프로세스 모델이 존재하지 않을 것을 필수조건으로 하고 있다.
RF 3는 리팩토링으로 인한 대체 프로세스 플래그 생성 알고리즘으로서 소스코드의 디자인을 향상시키기 위한 것이다. 이러한 시나리오는 소프트웨어 실행 시 불필요한 복합적 흐름제어를 좀 더 단순하게 할 수 있다고 보고된 바 있다(M. Fowler et al, 1999).
RF 4는 대체 프로세스 플래그 생성 알고리즘(RF 3)을 실행시켜 도출된 프로세스 모델의 각 플래그들을 의미한다.
RF 5는 전체 프로세스 모델 트리 항목에 적용된 참조 모델(Reference model)에 의한 대체(Replace) 프로세스 모델의 각 플래그들을 의미한다. 특히 대체 프로세스 모델은 보조 핵심공정 기능을 갖는 프로세스의 참조 모델을 대체하여 리팩토링 기술을 실행시킴으로써 소스코드의 설계기능을 향상시킬 수 있는 것으로 보고된 바 있다("Refacto ring: Improving the Design of Existing Code", M. F owler et al, 1999).
RF 6은 소프트웨어 실행과정에서 나타날 수 있는 오버헤드(overhead)를 정당화시키기 위한 프로세스 모델의 즉시처리(inline) 플래그들을 의미한다. 이는 설계자가 라벨링을 반복하여 프로세스 모델 트리 항목의 계층을 재구성함으로써 소프트웨어 설계의 복잡성을 감소시킬 수 있다.
RF 7은 프로세스 모델의 구조 변경에 따른 라벨(식별용 문자)의 집합들이다. 이들은 소프트웨어 공학적으로 유사한 리팩토링 개명(rename) 클래스로 분류된다.
RF 8은 중복된 잉여(Redundancy) 프로세스 모델들로서 제거할 대상들을 의미한다.
RF 9는 소프트웨어 실행 시 빈번하게 발생할 수 있는 다양한 변화를 일반화하기 위한 기능을 의미한다. 이는 중복된 잉여 프로세스 모델(RF 8)의 제거비용을 감소시키기 위한 핵심공정 중의 하나이다. 예를 들면, 헬스 케어 프로젝트에서 환자의 진단에서부터 치료절차를 결정하고 사후관리에 이르는 제반 Activity 프로세스에 대한 의사결정 구조를 의미한다. 특히 RF 9는 소프트웨어 실행 시 파생된 기준모델(Reference model)의 변형체(variants)를 효과적으로 처리하기 위한 프레임워크를 필요로 한다. 이에 프로세스 변형체의 면밀한 분석을 위해 데이터 마이닝 알고리즘(Data mining algorithm)을 적용할 수도 있다.
RF 10은 프로세스 저장장치의 가장 본질적인 요소인 프로세스 모델링을 통한 콘텍스트 기반의 흐름제어로부터 생성된 입력 브랜치 중 사용되지 않는(불필요한) 브랜치들을 제거하는 기능을 의미한다. 특히 RF 10은 불필요한 변경된 프로세스 프래그들을 표준 공정 마이닝 기술로 구현하여 각 프로세스 모델의 흐름제어 복잡성을 감소시킬 수 있다.
RF 11은 소프트웨어 실행 시 빈번하게 발생되는 인스턴스(Instance)를 일반화하기 위한 기능을 의미한다. 특히 RF 11은 소프트웨어 리팩토링에 의한 구조 변환 시 발생할 수 있는 오류를 최소화 할 수 있는 기능을 갖는다.
5. 구현
5.1. RTC(Refactoring Tool component)의 구조
SecServ 플랫폼(SecServ platform / http://qe-uib k.ac.at/secserv)의 RTC(Refactoring Tool Component) 어플리케이션을 실행시켜 소프트웨어 리팩토링 툴(Refact oring tool)을 구현하였다. 구현한 리팩토링 툴의 프로토타입은 <표 3>에 나타낸 모든 리팩토링 기술들을 지원하기 위한 프로세스이다. 소프트웨어 사용자 및 설계자를 모두 효과적으로 지원하기 위해서는 프로토타입은 적절한 전제조건을 이행해야 한다. 즉, 선별적 품질 메트릭스에 대해 리팩토링 효과를 입증할 수 있어야 한다. 이러한 흐름제어를 실행할 수 있는 RTC(Refactoring Tool component)의 구조를 <그림 1>에 나타낸다[1].
RTC는 SecServ 플랫폼(SecServ platform)의 확장 포인트 메커니즘(Extension point mechanism)에 따라 프로세스 편집기를 거쳐 프로세스 모델링 언어의 콘텍스트 기반 흐름제어로 생성된 일련의 실행결과들을 게이트웨이(gateway)를 통해 프로세스 모델을 결정하게 된다. 프로세스 편집기는 대중화되어 있는 WINDOWS 기반의 GUI (Graphical User Interface) 플랫폼으로 구현하였다.
5.2. 프로토타입의 주요 기능
리팩토링 툴의 프로토타입의 주요 기능은 VFR(Visual Flight Rule) 버전을 기반으로 하고 있으며, 다음과 같은 전제조건이 필수적이다.
파일럿(pilot)은 아울러 비행경로/이륙 및 비행시각/비행거리/비행시간 등 기본적인 비행계획을 면밀히 검토한 후 비행지역의 기후를 반드시 체크하여야 한다.
항공기의 엔진상태/연료주입 상태/각종 조명장치 등 항공기의 각종 상태를 점검한다.
공항 통제실의 지시에 따라 지상 활주로를 설정하고 이륙한다.
이러한 항공기의 비행 시뮬레이션을 이 연구의 핵심 사례인 헬스 케어 분야 및 자동차 설계 분야에 동일한 접근방법으로 적용하여 프로토타입을 구현하고 기능시험 결과를 분석하여 의사결정이 이루어지는 것이다. 프로세스 모델은 갑작스런 프로세스 변화에 따른 데이터 마이닝을 즉시 적용할 수 있어야 한다. 즉, 소프트웨어 실행과정 상의 오버헤드를 즉시 처리(inline)하기 위한 플래그(<표 3>의 RF6)의 라벨링을 반복하여 프로세스 모델 트리 항목의 계층을 재구성함으로써 소프트웨어 설계의 복잡성을 감소시켜 계획한 대로 비행을 마칠 수 있는 것이다. 항공기의 비행 시뮬레이션에 기반한 프로토타입의 주요 기능을 <그림 2>에 나타낸다[1].
6. 맺음말
PAIS(프로세스 인식 정보시스템) 기술은 다중 프로세스 모델로 구성된 대형 프로젝트의 품질관리 측면에서 발생할 수 있는 많은 요구사항들을 수용할 수 있다. 특히 기하급수적으로 증가하고 있는 프로세스 모델의 효과적인 관리를 위한 저장장치는 소프트웨어의 실행 품질을 결정하는 요인이 되고 있다. 이 연구에서는 헬스 케어 분야 및 자동차 설계 분야의 대형 프로젝트에 존재하는 수많은 프로세스 모델의 품질을 향상시킬 수 있는 방법을 설명하였다. 이를 위해 8가지 프로세스 모델에 대한 프로토타입을 개발하고 각 프로세스 모델에 대한 11개의 리팩토링 기술들을 핵심 공정에 적용시켰다. 접근방법으로는 SecServ 플랫폼의 RTC(Refactoring Tool component) 어플리케이션을 실행시켜 소프트웨어 리팩토링 툴을 구현하였다. 소프트웨어 사용자 및 설계자를 모두 효과적으로 지원하기 위한 전제조건으로 선별적 품질 메트릭스에 대해 리팩토링 효과를 입증할 수 있는 흐름제어 기반의 RTC 구조를 모델링 하였다. 리팩토링 툴의 프로토타입을 항공기의 비행 시뮬레이션을 통해 헬스 케어 분야 및 자동차 설계 분야에 적용하여 프로토타입의 기능시험 결과를 분석하여 의사결정이 이루어지는 과정을 설명하였다.
7. 분석자 결론 및 시사점
소프트웨어 리팩토링 목적은 소프트웨어의 구조를 변화시켜 소프트웨어의 효율을 향상시키고자 하는 것이다. 이를 효과적으로 수행하여 대형 프로세스 정보시스템을 수용하기 위한 대용량 저장장치들이 개발되고 있으며, 다양한 기법들이 소프트웨어공학에 적용되어 비즈니스 프로세스에 변화를 주도하고 있다. 이 연구에서는 PAIS(프로세스 인식 정보시스템) 기술 기반의 소프트웨어 리팩토링에 따른 대용량 저장장치의 프로세스 모델을 제시하여 헬스 케어 및 자동차 설계분야에 적용하여 프로토타입을 구현하고 기능을 시험하였다.
이 연구의 방법론을 보면, 헬스 케어 및 자동차 설계분야의 7개 데이터 소스와 각 소스 당 다수의 프로세스 모델을 적용하여 프로토타입을 구현한 점이 기술적 가치가 있다. 아울러 프로세스 모델의 품질 향상을 위한 11가지 리팩토링 기술을 제시하고 있다. 이는 Reference model의 핵심공정 설계를 효과적으로 실행할 수 있도록 프로세스 변형체에도 적용될 수 있는 점 역시 기술적 가치가 있다.
리팩토링은 소프트웨어의 성능을 향상시킬 수 있는 매우 유용한 기술이지만 여러 가지 오류가 발생할 수 있어 세심하게 다뤄져야 한다. 특히 소스코드가 변경되는 위험을 감소시키기 위해서는 소스코드를 모듈 별로 테스트할 수 있는 방법과 Eclipse의 리팩토링 기능같은 자동화된 툴을 사용하여 수행하는 것이 필요하다[2]. 이 툴은 소스코드의 이름과 물리적 조직의 변경, 재 명명(rename) 필드/변수/클래스/인터페이스의 추가, 패키지와 클래스 옮기기 기능 등을 구현함으로써 가능할 것으로 판단된다. 이 연구에서도 이러한 주요 기능을 잘 설명하고 있다.
객체지향 소프트웨어의 유지보수성 / 확장성/ 재사용성 등의 품질을 향상시키기 위해서 소프트웨어 리팩토링이 필요하다. 특히 소스코드와 프로세스 모델이 임의로 변경됨으로 인해 소프트웨어의 품질 저하, 재사용의 어려움, 확장 및 유지보수의 어려움, 비싼 비용 지불 등의 문제를 해결하기 위해 일찍이 OPDYKE W.F가 제안한 바 있다[3].
특히 대형 프로젝트의 경우 수많은 프로세스 모델의 요구사항을 수용하기 위해서는 필수적이다. 소프트웨어의 높은 의존도에 따라 소프트웨어의 품질은 매우 중요한 요인으로 부각되고 있다.
이에 소프트웨어 리팩토링 기술이 많은 전문가에 의해 개발되고 있으나 모든 리팩토링 규칙을 적용한다고 해서 소프트웨어의 품질을 향상시킬 수 있다고 보기에는 아직은 한계가 있는 것 같다. 지식경제부에서 발표한「국내 2011년도 SW산업 육성대책」을 보면 한국 SW산업의 구조적 문제점을 다음과 같이 진단하고 있다[4].
국내 패키지SW 시장을 MS/오라클 등 글로벌 기업이 대부분 장악(2009년 국내시장의 64.4% 점유)하고 있어 국내 SW시장의 생태계 악순환이 지속되어 해외시장 진출에 애로가 있다.
국내 기업들은 공공시장 등 글로벌 기업과의 경쟁이 적은 시장에 의존하고 있으나, 다수의 참여자로 인해 저가격화 및 과당경쟁이 야기되고 있는 실정이다.
소프트웨어 인력수급 악순환으로 인해 기술/가격경쟁력 부족→수익성 악화→R&D/인력투자 저조→처우/보상 미흡→우수인력 이탈→경쟁력 저하로 이어지고 있다고 진단하고 있다.
이러한 국내 SW산업 생태계로 인해 중국 등 후발 산업국과의 경쟁력이 효과적으로 확보되지 못할 우려가 있다. 이러한 탈 추격 형 SW산업 선진국으로 도약하기 위해서는 근본적인 발전전략이 필요한 시점이다.
참고문헌
1. Barbara Weber, Manfred Reichert, Jan Mendling, Hajo A. Reijers, Refactoring large process model repositories, Computers in Industry 62, 2011, pp.467~486.
2. David Gallardo, "Eclipse의 자동화 리팩토링 기능", 2003. 9.
(http://www.ibm.com/developerworks/kr/library/os-ecref/)
3. 배정호 외, "객체 지향 품질 모델을 이용한 소프트웨어 리팩토링의 효용성 평가에 관한 실험적 연구", 2009 한국소프트웨어공학기술 합동워크샵 발표자료, 2009. 7. 23~25.
4. "2011년도 SW산업 육성 대책", 지식경제부, 2011. 2. 22.
회원가입 후 이용바랍니다.
개의 댓글
댓글 정렬
BEST댓글
BEST 댓글
답글과 추천수를 합산하여 자동으로 노출됩니다.
댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
그래도 삭제하시겠습니까?
댓글수정
댓글 수정은 작성 후 1분내에만 가능합니다.
내 댓글 모음