박준휘
남서울대학교 컴퓨터학과 겸임 교수
1. 개요
최근에 컴퓨터의 이용이 증가함에 따라 소프트웨어에 대한 수요의 증가로 소프트웨어의 개발, 유지보수 비용은 급속한 속도로 증가하고 있다. 품질 좋은 소프트웨어를 개발하기 위한 소프트웨어 방법론이 많은 연구되고 있다. 현재 많이 이용되는 구조적 개발 방법론은 소프트웨어 재사용이나 모듈화, 개발된 소프트웨어를 유지보수하는 데는 효과적이지 못하다는 결점을 가지고 있다. 그러므로 적은 규모의 소프트웨어를 개발하는 데는 적합하지만 대규모 소프트웨어를 개발하는 데는 적합하지 못하다.
조직개발 방법론의 대안으로 객체 지향 개발 방법론이 대두되었다. 종래의 구조적 개발 방법론은 소프트웨어의 동적인 기능 측면에 초점을 맞추고 있는데 비해, 객체 지향 개발 방법론은 소프트웨어의 정적인 데이터 측면과 동적인 기능 측면을 모두 중시한 시스템을 개발할 때 요구되는 여러가지 강력한 모델링 개념과 캡슐화 개념 등을 잘 지원하고 있다. 이러한 객체 지향 방법론은 구조적 개발 방법론에 비해 소프트웨어 분석, 테스트, 유지보수, 확장 등을 쉽게 해주며, 분명하면서도 잘 이해할 수 있는 설계 결과를 만들어 낸다. 즉 클래스는 자연스럽게 소프트웨어 모듈의 한 단위가 되고 객체 지향 설계 과정은 그러한 객체 지향 사이의 복잡도를 적절히 관리해 준다.
본 고는 객체 지향 분석 및 설계(object- orient analysis and design: OOAD) 방법론을 비교 분석하는데 있다.
OOAD의 평가요소를 동일하게 하여 다양한 OOAD기술과 표현 방법들을 비교하고 분석하며, 또한 OOAD 방법론의 장단점을 비교 분석하여 현재까지 연구된 OOAD 방법론을 평가, 비교하기 위한 프레임워크를 구성하고, 구성된 프레임워크는 완전한 OOAD 방법론 개발을 위한 많은 연구들이 융합될 수 있는 토대를 마련하도록 한다.
본 고의 구성은 2장에서는 객체 모델링에 대해서 알아보고, 3장에서는 객체 지향 분석 및 설계에 대해서 비교 분석하고, 4장에서는 결론을 맺는다.
2. 객체 지향 모델링
가. 객체 모델링 방법론
소프트웨어 개발의 큰 문제점은 복잡성, 요구의 변화, 개발 기간의 시간적인 제약성이다. 이러한 문제 해결에 제안된 기본적인 개념으로 분해 기법과 추상화 기법을 들 수 있다.
분해 기법은 복잡한 문제를 작고 단순한 서브 프로그램들로 나눈다. 나누어진 문제는 전체 문제보다 해결하기 쉽고, 서브 프로그램들을 다시 결합하면 원래 의도한 문제를 해결할 수 있다[8].
추상화 기법은 다양하고 복잡한 개념을 단순 개념으로 사상하는 과정으로 서로 다른 많은 사항들을 무시한 채 같은 것으로 취급함으로써 복잡한 방법을 줄이는 것이다. 객체 지향 방법론는 두가지 개념을 바탕으로 소프트웨어를 개발한다[8].
객체 지향 방법론은 해 영역의 실제에 의미를 부여하고 실제를 객체로 추상화시키는 의미 객체 모델링(정적 모델) 방법과 처음부터 동적 모델을 고려한 객체 추출을 기반으로 하는 객체 모델링 방법으로 나눈다.
(1) 의미 정의에 대한 객체 모델링
정보처리 시스템은 문제 영역 P에 대한 해 영역 S를 양식으로 나타낸 것으로 P⊂S인 관계로 나타낸다. 실세계에서 문제의 의미를 분석하여 기술하고, 양식에 의한 설계를 하여 해를 기술한다. 또한 P는 의미 객체를 포함한 집합으로써 P의 객체들은 해 보다는 문제를 기술하는 개념으로 사용한다.
시스템의 의미 객체는 고객, 주문, 항목, 피고용자들로서 주어진 시스템의 실체들이 된다. S는 문제 영역 P 이외에도 인터페이스, 응용, 기본 객체들을 포함한다.
인터페이스 객체는 사용자와 정보처리 시스템 간의 인터페이스를 설명하고 문제 영역 자체를 설명하지 않는다. 즉 의미 객체에 대한 사용자의 관점에서 기술한다.
응용 객체는 정보처리 시스템에 관한 제어 메카니즘이다. 유도기능을 가지고 개발된 시스템의 기능들을 순차적으로 제어한다. 즉 시스템의 주된 모듈로서 다른 객체들에 대한 메시지와 메뉴를 전달한다[8].
기본 객체는 문제 영역이나 응용되는 독립된 객체이다.
의미 객체 모델을 바탕으로 객체 지향 분석을 하는 과정은 의미 자료 모델을 갖추어야 할 자료의 추상화, 의미 객체의 식별, 집합관계, Classification과 Instantiation, 속성의 승계, 그리고 서브 클래스와 슈퍼 클래스를 정의하여 수행한다[8].
분석 단계는 문제점을 기술함으로 의미 객체별 요구와 양식 중심으로 기술하고 설계 단계는 그 해를 기술한다. 객체 지향 분석은 문제 영역을 모델링하기 위하여 의미 객체의 집합을 식별하여 그 양식을 정하고 시스템 요구에 의해서 관련성을 기술한다. 객체 지향 설계는 해 영역을 모델링하는데 의미 클래스, 응용 및 기본 클래스를 설계한다.
결과적으로 실체를 식별하여 의미 객체로 추상화하고 객체들의 속성과 관련성, 집합관계를 기술하여 의미 자료 모델링을 하고, 여기에 객체 지향 프로그랭 언어가 가진 특성, 즉 속성의 외부 서비스, 객체 간의 인터페이스 메시지, Classification 및 행위의 승계, 그리고 정보 은닉과 캡슐화를 추가하여 객체 지향 분석 및 설계를 수행한다.
(2) 객체 모델링
객체 모델링은 문제 분석과정부터 객체를 추상화시켜서 클래스로 정의하고, 관련성을 분석하여 상속성을 정의하는 분석 과정이다[8].
① 객체
객체는 사람, 장소, 물건 등과 같이 물리적이거나 온도, 액수, 구좌 등과 같이 개념적일 수 있다. 또한 실체 시스템의 구성요소와 일대일 대응관계를 갖는다. 그러나 객체는 개개의 요소를 의미하는 것이지 항목들의 일반적인 범주나 그룹을 의미하는 것은 아니다. 객체는 하나의 고유 식별자를 갖는 것을 의미한다.
행위는 객체가 제공하게 될 서비스와 수행하게 될 책임을 의미하는 것으로 외부에서 객체를 사용하는 방법과 시스템에서 주어진 일을 수행하는 방법이 된다. 임의의 조건 하에서 어떠한 사건이 발생할 때 취하는 객체의 행동 파악이 필요하다. 행위는 또 다른 사건을 유발할 수도 있고 객체를 생성 또는 파괴하기도 하며 메시지의 교환일 수도 있다. 또한 객체는 상태를 갖고 이상태는 시간에 따라 변화를 일으킨다. 상태란 객체의 현재 상황이나 전체 흐름에서의 단계를 의미한다. 객체에 대한 상태를 정의하는 방법으로는 여러가지가 있을 수 있으나 가장 가능한 방법으로는 현재 가동중인 시스템인 경우 시스템 운영의 흐름 내에서 객체 관찰을 통해서 그리고 수행되고 있는 시스템이 없는 경우 전체의 흐름을 가정하여 파악하는 것이다[7].
② 객체 클래스
서로 비슷한 객체들끼리 하나의 추상화된 것으로 만들 필요가 있다. 또한 분류작업으로 간주할 수 있다. 각 객체 클래스는 이름을 갖게 되면 이들이 포함하게 될 객체의 일반적인 성질을 갖게 된다.
③ 관련성
객체는 서로 다른 객체와 어떠한 형태로든 관련성을 갖고 있다. 즉 객체들 간의 논리적 관계를 가지고 있다.
일반화(Is-A 관련성 집합) 관계는 한 객체가 다른 객체의 상위 집합인지 하위 집합인지를 정의한다. 이때 상위 집합을 일반화라고 하고 하위 집합을 상세화라고 한다. 이는 집합의 개념으로 판단하는 것으로 집합에 속하는 원소들을 고려하여 하위 집합에 속하는 객체가 상위 집합에 속할 수 있어야 한다.
상속 관계에서 하위 집합의 원소는 상위 집합의 원소라고 정의한다. 이는 일반화가 지닌 모든 관련성 집합에 새로 정의된 상세화가 포함됨을 의미한다. 상세화는 일반화가 지닌 모든 관련성을 상속 받는다. 어떤 경우는 하나의 객체 클래스가 두가지 이상의 일반화의 상세화일 수 있다. 이때 하위집합은 여러 개의 상위집합이 지닌 모든 관련성을 상속 받는다. 이를 다중 상속이라고 정의한다.
집성화 관계는 한 객체가 또 다른 객체를 자신의 서브 파트나 부품으로 구성한 경우 이들 상호간에 집성화 관계가 존재한다고 한다. 이 집성화 관계에는 참가 제한 사항이 추가된다
Is-Member 관계에서는 하나의 객체로 취급하려는 객체와 그들 원소들간의 관계를 말한다. 즉 이진 관계이다.
나. 객체 모델링의 단계
객체 지향 분석은 시스템의 시나리오에 나타난 객체를 식별하고 그들 간의 상호 작용을 파악한 다음, 각 객체에 부과된 책임(행위)을 분석한다. 객체의 행위 분석은 인터뷰하기 전부터 시작할 수 있으므로 시스템의 시나리오를 문서로 작성한 이유도 객체 추출을 쉽게 하기 위한 것이다. 여기에서 중점을 두어야 할 내용은 시스템을 개발하게 된 동기가 무엇이며, 동기별로 어떤 사건이 일어날 것인가 하는 점이다. 즉 기술 문서와 함께 객체와 그들의 속성 및 행위를 식별하는 것이 객체 지향 분석의 중요한 과제이다
(1) 분석 단계
분석 단계는 기본 단계로서 분석을 위한 계획서 작성, 행위에 초점을 맞춘 행위 분석, 객체를 추출하고 그 행위의 기술, 객체들 간의 관련성 파악, 동적 모델링으로 구분할 수 있다
기본 단계는 분석의 계획 단계이다. 시스템의 시나리오를 바탕으로 살펴보면 개념적 모델링, 외부 양식, 구현의 과정을 정하고 시스템의 시나리오에 나타난 목표를 설정하고, 시스템의 범위와 문제 공간의 기술, 분석을 위한 자료의 선정, 그리고 분석 단계의 계획을 세운다. 시스템의 범위와 문제 공간의 기술은 시스템의 환경과 조건을 파악하고 문제 분석의 공간 영역이 어디까지인가를 결정한다. 분석을 위한 자원 식별은 사용자의 파악과 영역을 설명할 수 있는 전문적인 지식 그리고 적당한 참고문서 등을 찾아낸다. 이상과 같이 분석과정의 상위 단계에서 나타난 행위를 설명하고 다음에 연결되는 1 단계부터 4 단계까지의 분석을 위한 계획을 세우고, 모델의 개념을 정립한다[8]. 기본 단계에서 기술되는 문서는 분석계획, 현 시스템의 목표, 요구 정의, 품질 목표, 면담내용의 기술로서 시스템의 시나리오와 비교하여 모순점이 없는가를 평가할 수 있는 문서와 객체 모델링의 전과정에 관한 계획문서이다. 요구정의와 품질목표, 면담 등은 인터뷰와 참조문서를 바탕으로 해서 이루어 지는데 객체들의 활동을 설명하는 시나리오, 에러조건과 처리방법, 모델에 포함된 서비스, 서비스의 수행 책임자인 행위자의 식별의 내용을 포함해야 한다. 시스템의 목표와 계획이 세워지면 개념적인 모델링 단계에 들어가는데 이 과정으로 문제분석, 객체의 추출, 그리고 객체의 관련성 정의에 들어간다[8].
문제 분석 단계에서는 시스템의 기능을 정하고 그 기능을 누가 수행하며, 누구의 도움을 받아서 집행할 것인가를 결정한다. 시스템 기술에서 나타난 동기와 사건을 중심으로 야기되는 문제를 파악하고 그 해답 영역을 찾는다. 그리고 나서 해당 영역별로 어떤 활동이 일어날 것인가를 예측하고, 활동할 객체를 선정한다. 선정된 객체는 어떤 역할을 담당할 수 있는가를 분석하여 그 객체의 행위와 속성을 정의한다. 끝으로 행위자의 활동을 중심으로 하여 객체들의 행위를 결정하여 기술 문서를 작성한다. 기술 문서의 내용은 객체와 속성, 그리고 요구자의 행위와 행위자의 서비스를 기술한다. 활동 기술서는 요구자와 행위자의 객체가 수행하는 활동을 의미한다. 객체가 식별되면 요구자의 행위는 행동이라고 하고, 행위자의 행위는 서비스라고 정한다.
(2) 활동 기술 단계
객체 추출과 활동의 기술 단계는 문제 분석에서 추출된 모든 객체의 역할을 정하고, 객체의 속성과 행위를 비교 분석하여 미비점과 모순점을 찾아낸다. 그 다음에 객체들을 구분하여 요구자인지, 행위자인지를 식별하고 각각의 행위를 기술한다. 끝으로 트레이스의 방법을 기술하면 객체의 기초적인 모델링은 끝난다. 객체의 속성은 논리적인 특성이기 때문에 객체활동에 관련된 성질을 정의하면 된다. 객체의 행위는 객체의 책임이 무엇인가를 파악하고, 그 객체가 제공할 서비스와 다른 객체에 요청할 서비스를 구분하여 정해 나간다. 모든 참여자가 객체로 나타나는데 참여자는 동기를 부여하고 서비스를 요청하는 요구자와 서비스를 수행할 행위자로 나눌 수 있다. 그러나 한 개의 객체가 요청과 수행의 두가지 기능을 같이 가질 수 있다. 이럴 때는 객체 기능은 두 가지로 구분해서 설명할 수 있는 활동을 정의해야 된다. 객체는 요구자와 행위자가 되는데 요구자의 활동은 능동적인 행동을 의미하고, 행위자의 활동은 수동적인 서비스를 의미한다. 본 단계의 활동 기술서에서는 활동 기술서를 구별하여 설명하는 과정이 중요하다.
(3) 관련성 기술 단계
객체의 관련성 기술 단계에서는 객체의 관련성을 추상화에 의한 일반화, 특성화에 의한 집합관계, 그리고 링크와 결합에 의한 연결관계를 찾아서 객체들을 그룹으로 나누는 단계이다.
추상화는 객체에 어떤 기능을 부여할 것인지를 기술함으로써 외부적 관점에서 설명하고자 하는 것으로 구현에 의해서도 그 기능이 변하지 않은 캡슐화를 시도할 수 있다. 또 공통된 특성과 행위를 특성화시켜서 다른 객체에 승계시켜 줄 수 있도록 일반화시키고 추상화된 객체를 새로운 객체(새로운 특성과 행위를 추가시켜서)로 재정의하는 특성화를 통해 보다 차원 높은 추상화를 유도해 낼 수 있다. 즉 추상화된 객체를 일반화와 특성화를 통해서 재차 추상화시킴으로써 승계를 위한 차원 높은 추상화 객체에 대해서 집합관계를 설계할 수 있다.
집성화 관계는 a-part-of 나 partwhole로 표현되는 객체의 그룹화를 위한 관계 정의를 하는 분석과정이다. 자원관리의 BM구조와 같이 제안된 방법으로 설계할 수 있는 DB 에서 쉬운 예를 찾아볼 수 있다. 링크와 결합을 사용자가 정의하는 내부 레코드의 관계와 DB에서 parent-child 관계와 같이 정의한다. 관계의 비중을 나타내는 차수와 대응수, 그리고 종속성이 정의된다. 객체 모델에서 일반화, 집합관계 및 링크와 결합관계는 매우 중요하다.
(4) 동적 모델링 단계
동적 모델링 단계에서는 앞 단계에서 설명한 문제분석, 객체 추출과 행위 기술, 그리고 객체들 간의 관련성을 중요하게 생각하는 분석이 정적 모델링이라고 한다면, 시스템 전체의 생명주기를 모델링하는 것을 동적 모델링이라고 할 수 있다. 동적 모델링에서는 객체의 상태가 변화되어 가는 과정을 중요시한다. 객체의 상태는 기술문서에 나타난 전후 조건들로부터 파악된다. 정적 모델링이 객체의 구조만 관심을 두고, 시간 조건을 배제한 환경에서 설계된다면, 동적 모델링은 시간에 따라서 변하고 시스템의 관점에서 객체를 관찰하게 된다. 따라서 두 가지 모델링의 관점은 서로간에 균형을 유지할 수 있도록 설계되어야 한다. 동적 관점의 설계 내용은 각 객체에 대한 상태를 정의하고 동적 행위를 가진 객체의 상태가 객체의 생명에 어떤 영향을 줄 수 있는가를 정의한다.
다. 여러가지 객체 모델링의 비교 분석
(1) Edwards
분석결과에서 C++로 코딩할 수 있고 정적 및 정적 차원에서 지원할 수 있으나 승계 정의를 고려하지 않았다. 정적 차원의 지원에서는 클래스, 인터페이스, 관계, 기능(관계)이 있고, 동적차원의 지원에서는 다중 객체로 일어난 이벤트를 중심으로 분석하고, 단순 이벤트는 STD에 의해 분석한다. 이벤트의 5개 영역은 객체 생성, 용어의 정의, 클래스 확장, 클래스 재구성, 객체의 재분류 등이 있다.
여기서 클래스의 확장과 재구성, 객체 분류는 객체를 클래스로 구분하는 과정이다.
(2) Page와 Jones의 이벤트 영역 분류
이벤트의 영역 분류를 통해서 객체를 모델링하는 과정은 다음과 같다.
② 용어 정의
③ 객체 정의와 분류에 의한 클래스 정의
④ 단계와 반복 순서
⑤ 재분류
⑥ 관계의 재정의
⑦ 서로 다른 객체의 표준화와 동향
(3) Shlaer와 Mellor의 OOA
객체의 상호 관련은 이벤트를 통해서 정의되고 이때 활동을 통해서 이벤트를 생성한다. 전이는 이벤트가 발생할 때 일어난다.
활동을 확장할 때 DFD를 채용하며, DFD는 외부 속성을 표현한다. STD에 의해서 객체의 라이프 싸이클을 결정한다.
(4) Rumbaugh의 OMT
Rumbaugh는 활동 상태와 활동을 구분하여 설명하고 있다. 활동은 전이 가능한 이벤트와 동시에 일어나고, 활동상태는 상태가 추가된 연산과정으로 생각한다. 객체의 상태는 객체가 가지고 있는 다른 객체들 간의 결합으로 모은 집합이다. 활동상태는 전이 가능한 이벤트에서 끝나고, 항상 활동으로 바꿀 수 있다. 그래서 자료 동적 및 정적 성질을 표현하는데 중점을 두고 있다.
객체 지향 분석은 다음과 같이 4가지 과정을 반복해서 이루어진다.
① 객체 모델링
② 동적 모델링
③ 기능 모델링
④ 모델 간의 관계정립
특히 Booch와 Gibson은 서브 시스템을 사용하여 객체를 정의함으로써 설계과정의 단계를 상세하게 추가하고 있다. 즉 확장 가능한 객체를 서브 시스템에 정의하고 그 자료구조를 설계하고 행위의 알고리즘을 설계하면서 새로운 객체를 식별하는 기회를 갖게 한다.
본 연구에서는 Rumbaugh, Booch와 Gibson의 방법을 참조하면서 객체 모델링 방법을 설명하였다.
3. 객체 지향 분석 설계에 대한 비교 분석
가. 객체 지향 분석 및 설계 프로세스
OOAD 프로세스에서는 객체를 의미, 인터페이스, 응용, 베이스/유틸리티 클래스들로 분류하여 나타낸다. 그리하여 OOAD프로세스에서는 클래스로 정제하는 활동을 한다. 이것은 공통된 행위에 대한 클래스의 추상화와 애트리뷰트에 대한 구조를 조사하는 것이다. 또한 설계자의 관점에서는 클래스가 완벽하고 올바르다는 것을 확인할 수 있으며 “메소드에 누락된 것이 있는가,” “메소드와 애트리뷰트가 올바른 위치에 있는가”에 대해서 클래스를 정제하는 작업이다. 많은 연구자들에 의해 OOAD 프로세스에 대한 연구가 이루어졌는데 그 중에서 Booch, Coad and Yourdom, Rumbaugh, Bulmn 등이 OOAD프로세스에 대한 많은 부분을 설명하였다. 특히, Bulman은 인터페이스, 응용, 베이스, 유틸리티 객체에 중점을 두고 설명하였다.
나. OOAD 방법
표현은 크게 정적인 관점과 동적인 관점 그리고 표기법에 관한 관점으로 구분할 수 있다. 객체 지향 정적모델은 객체 지향 동적 모델보다 많은 종류의 모델이 있으며, 동적 모델 중에서 구성요소 대부분이 객체 모델에서 행위로 매핑되거나 번역되는 상태 전이도로 구성된다. 표기법에 관한 관점은 관계의 표현을 포함하는 것으로써 대부분의 표현들은 일반화 관계로 지원된다. 집단화 관계도 지원되지만 아직까지 널리 이용되고 있지 않다.
다. OOAD 복잡도 관리
몇몇 연구자들이 방대한 OOAD 복잡도를 관리하기 위한 개념적인 메커니즘을 제공하고 있는데 이 메커니즘의 대부분은 구조적인 복잡도에 대하여 처리하고 있다. 예를 들어 Coad and Youndom’s의 서브젝트와 Wirfs-Brock et al의 서브 시스템이 있는데 서브젝트는 어떤 루트 구조나 서브스트락처에서 객체를 캡슐화하는 매카니즘이며 루트로부터 구조를 상속받아 구성되므로 복잡도가 감소한다. 반면에 서브 시스템은 루트구조에 기반을 두지 않고 상위 레벨 기능을 달성하기 위해 구성된 다른 서브 시스템이나 클래스로 이루어져 있다.
라. OOAD 장단점
현재의 OOAD에 접근하는 일반적인 세 가지 방법은 다음과 같다.
(1) 결합에 의한 접근
객체 지향, 기능 지향 그리고 동적 지향 기술을 단독으로 모델 구조, 기능성, 동적행위로 이용하고 다른 모델을 통합하기 위한 방법론을 제공한다. 그러나 이 결합에 의한 접근은 다른 관점을 객체 지향 설계방법으로 통합할 때 내용이 변경될 수 있다.
(2) 적용될 수 있는 접근
기존의 기술을 객체 지향에 이용하거나 객체 지향 기술을 포함하여 확정한다.
(3) 순수한 객체 지향 접근
객체구조, 기능성, 동적행위를 모델화하기 위해 새로운 기술을 이용한다.
OOAD를 지원하기 위한 정형화된 방법은 아직 표준화되어 있지 않으나 지금까지 기술한 OOAD에 대한 장담점은 <표 1>과 같다.
4. 결론
OOAD방법론에 많은 연구자들이 관심을 가지고 연구하고 있는 분야이다.
따라서 본 고는 OOAD 방법론에 관한 연구들을 비교 평가하기 위한 프레임워크를 구성하여 현재까지 개발된 객체 지향 설계 방법론 구성요소인 프로세스, 표현, 복잡도 관리를 이용하여 구성한 프레임워크를 통해 살펴보았다. 그러나 이와 같은 설계 방법론이 우수하다고는 말할 수 없다.
OOAD 방법론 중에서 프로세스, 표현, 복잡도 관리에 대한 모든 것을 지원하는 방법론이 제시되지 않았기 때문이다. 향후 연구는 지금까지 연구되어진 OOAD 방법론들을 기반으로 프로세스, 표현, 복잡도 관리가 모두 지원될 수 있는 OOAD 방법론을 개선하는데 있다.
<참 고 문 헌>
[2] 송영제, 객체 지향 소프트웨어 설계법에 관한 연구, 대한전자공학회.
[3] 원유현, 객체 지향 언어의 주요 개념, 석사학위논문.
[4] 류형규 외 3인, UML기반 객체 지향 클라이언트/서버구축, 홍릉출판사.
[5] APPLYING UML AND PATTERNS(An Introduction to object- oreiented analysis and design and the unified procss).
[6] R.F.SINCOVEEC: Modular Software construction And Object-Oriented Design Using Ada Journal Of PASCAL/ Ada & Modula-2.
[7] R. Pricto-Diaz And P.Frecman: Classfying Software For Reusability IEEE Software.
[8] 정보과학회지, 제11권 2호(통권52호), ISSN 1015-9908.
(0) 
(0)Posted by 좐군
