오브젝트 기법 프로그래밍 보급 연구(II)

The Study on Introducing & Applying of Object Technology(II)


















인사 말씀

최근 들어 소프트웨어 시스템 기능에 대한 다양한 요구와 소프트웨어 규모 및 복잡성의 증가로 인하여 소프트웨어 개발 및 유지 비용이 크게 증가하고 있습니다. 이러한 소프트웨어 위기를 극복하기 위하여 소프트웨어 재사용을 가능하게 함으로써 개발 생산성을 높일 수 있게 하는 오브젝트 기법이 등장하게 되었습니다.

이미 선진 제국에서는 오브젝트 기법을 이용한 소프트웨어 개발 기술을 실용화 하였습니다. 그러한 세계적 추세에 부응하고, 소프트웨어 자산을 확보하여 개발 환경이 점차적으로 복잡해 지고 있는 현 상황을 극복하기 위하여 오브젝트 기법에 대한 연구를 수행되어야 한다고 생각합니다.

본 연구는 오브젝트 기법을 연구소 내에 적용하기 위한 기반 조성 및 환경 구축을 목적으로 오브젝트 개념의 실체를 파악하고, 개발 도구를 선정. 평가하였으며, 선정된 개발 도구의 적용 가능성에 대한 타당성 연구를 실시하였습니다.

본 연구를 통하여 오브젝트 기법에 대한 개념이 확산되고, 소프트웨어 개발 환경이 개선되어 개발 생산성 향상 및 비용 절감에 도움이 되리라 기대됩니다.

끝으로 오브젝트 기법을 연구소에 적용할 수 있도록 구체적인 방안과 이용을 위한 환경 구축에 대한 연구가 계속 성공적으로 수행될 것을 기대하면서 본 연구에 참여하여 힘 쓴 연구원의 노고를 치하합니다.

1996. 3.

한국전자통신연구소장 양 승 택


제 출 문

본 연구보고서는 기초연구 과제인 "오브젝트 기법 프로그래밍 보급 연구"의 결과로서, 본 과제에 참여한 아래의 연구 팀이 작성한 것입니다.

연구책임자 : 책임연구원 안병성 (소장실 기술역)

연구참여자 : 선임연구원 김인수 (정보기술개발단)

선임연구원 이용준 (정보기술개발단)

선임연구원 김경수 (이동통신연구단)

연 구 원 이병복 (이동통신연구단)

연 구 원 신경숙 (이동통신연구단)


요 약 문

1. 제목

오브젝트, 기법 프로그래밍 보급 연구

2. 연구 목적 및 필요성

■ 오브젝트 기법 프로그램 작성에서는 Class Library를 일종의 부품같이 사용할 수 있으며이것을 작성하는데 노력이 필요하지만 이것은 반복해서 사용할 수 있는 자산으로서 풍부한 Class Library를 가지고 있으면 그만큼 프로그램 작성 시간이나 노력이 감소됨

■ 현재 세계의 여러 유수 기업에서는 오브젝트 기법에 의한 프로그래밍 기술을 적용하여 생산성 향상 및 소프트웨어 자산 축적에 많은 효과를 거두고 있음

■ 우리 연구소에서도 자체의 프로그램 개발 효율을 올리기 위해서 빠른 시간 내에 오브젝트 기법 프로그램 방식을 도입하여 자체 능력을 향상시킬 필요가 있으며 이것이 우리 연구소가 확고한 지위를 갖게 하는 한 방편이 될 수 있을 것으로 생각됨

3. 연구 목표

가. 최종 목표

■ 연구소에서 사용하기에 적절한 오브젝트 기법 CASE Tool을 선정하고

■ 이 CASE Tool을 사용하는 표준 절차를 정하여

■ 연구소 내에 이를 널리 보급시킨다.

나. 당해년도 목표 (2차년도)

■ 선정된 CASE Tool의 적용 시험

■ 시험 결과의 평가

■ 프로그래밍 기법 확산

4. 연구내용 및 범위 (당해년도)

■ 오브젝트 기법 도입 단계 정립

■ 오브젝트 CASE Tool 적용 시험

■ 확대 시행을 위한 교육 실시

5. 연구 결과

■ 오브젝트 기법 도입 단계 정립

- 도입 단계 정립

▣응용에 적합한 오브젝트 개발 방법론 선택

· 오브젝트 지향 분석 및 설계 방법에는 여러 가지가 있어서 서로 적용 분야가 다르고 표현하는 기법이 다를 뿐 아니라 뛰어나게 우수한 방법이 존재하지 않으므로 우리의 응용과 현실에 적합한 방법론을 선택할 필요가 있음. 본 과제에서는 지명도 차원에서 우세하고 연구소 내에서 가장 많이 선호하고 있으며, 객체 모델, 동적 모델 및 기능적 모델로 시스템의 모든 측면을 모델링하고 있는 Rumbaugh 방법론을 오브젝트 지향 개발 방법론으로 선택

▣응용에 적합한 오브젝트 프로그래밍 언어 선택

· 오브젝트 지향 언어는 순수 오브젝트 지향 언어와 혼성 오브젝트 지향 언어로 나눌 수 있음. 순수 오브젝트 지향 언어는 프로그램 내의 모든 것들이 오브젝트라는 단위로 정의, 수행되는 언어로 Simula, Actor, Eiffel 등이 있으며, 혼성 오브젝트 지향 언어는 기존의 언어 구문에다 오브젝트 지향 구문을 추구한 것으로 C++, Objective C, Objective Pascal, Modular 3 등이 있음. 순수 오브젝트 지향 언어는 혼성 오브젝트 언어에 비해 새로운 개념이고, 널리 알려져 있지 않으므로 프로젝트를 수행하는 개발 도구로는 적절하지 않으므로 본 과제에서는 이미 많은 사람들에게 익숙해져 있고, 각종 개발 환경이 풍부한 C++를 오브젝트 지향 프로그래밍 언어로 선정

▣선택된 개발 방법론을 자동화 한 오브젝트 CASE Tool 선택

· 선택된 Rumbaugh 개발 방법론을 자동화 한 오브젝트 지향 CASE 도구는 여러 가지가 있으나 본 과제에서는 M. Gibson의 평가 항목에 의거하여 Cadre Inc.의 ObjectTeam/AF을 최종 선정

▣파이롯트 프로젝트 수행

· 새로이 선택된 오브젝트 지향 CASE를 보급하기 전에 선택된 오브젝트 지향 CASE의 효율성을 객관적으로 입증할 필요가 있으며, 실제로 오브젝트 지향 CASE를 사용하여 프로젝트를 수행하는 것이 좋음. 프로젝트의 규모는 소규모로 짧은 시일 내에 종료될 수 있는 것이어야 하고, 문제 영역이 잘 정의되고 쉽게 이해할 수 있는 것이어야 함. 본 과제에서는 잘 알려진 사례를 선택하여 ObjectTeam/AF을 사용하여 문제 분석 단계와 설계를 수행, CASE 도구 사용시 장점과 문제점을 분석

▣교육

· 선정된 오브젝트 지향 개발 방법론과 CASE 도구를 시스템 개발에 적용하기 위해서는 해당 오브젝트 지향 방법론과 도구를 충분히 이해하고 있어야 하는데, 단시일 내에 오브젝트 지향 개념을 습득하기 위해서는 해당 분야의 전문가를 초빙하여 교육을 받을 필요가 있음

- 파이롯트 프로젝트의 선정 : CASE Tool(ObjectTeam/AF)의 효용성을 판단키 위해서는 파이롯트 프로젝트의 규모는 작아서 그 내용을 완전히 이해할 수 있어야 함

- 파이롯트 프로젝트 : 자동차 판매 서비스 업무

▣고객과 고객이 소유한 자동차 기록 유지

▣각 자동차에 대하여 작업 요구 내용과 처리 결과에 대한 기록 유지

▣각 작업 요구서에는 처리되어야 할 서비스 항목이 포함되며, 각 서비스 항목은 요구되는 부품 목록이 포함됨. 서비스 항목간 처리 순서는 임의적임

- CASE Tool의 부분 시험 사용 : 선정된 파이롯트 프로젝트를 구현, CASE Tool 사용을 시험하여 다음과 같은 결론을 얻음

▣ObjectTeam/AF는 문제 해결에 있어서 Component-based Approach를 취하고 있는데, 이 방식은 Class Library 구성에 직접 연관되어 있어서 본 과제의 최종 목표에 부합되는 것으로 생각됨

▣ObjectTeam/AF는 오브젝트 모델링, 오브젝트 조합 및 부품 재사용 Tool로 구성되어 있어서 일관성 있게 Tool을 사용할 수 있음

▣CASE Tool은 사용자 인터페이스가 상당히 중요한 요소인데 ObjectTeam/AF의 사용자 인터페이스는 3개의 Tool을 조합하고 있어서 복잡한 느낌을 주는 반면 익숙한 사용자에게는 편리성을 줄 것으로 생각됨

6. 기대 성과 및 활용 계획

■ 기대 성과

- 소프트웨어 제품을 자산으로 축적할 수 있고 추후 재사용이 가능하게 함

- 우리 연구소 내에 소프트웨어 생산 능률을 향상시킬 자산을 축적할 기반 제공

- 대규모 시스템 개발에서 기능 분할을 명확하게 하며 통합 시험을 용이하게 함

■ 활용 계획

- 오브젝트 프로그래밍을 확대 보급시키는 과정에서 얻어진 경험과 발견되는 문제점을 다음 단계의 기법 개량에 활용하여 더욱 좋은 방법의 개발에 반영


Abstract

1. Title

A study on introducing and applying the object technology

2. Objectives

■ Establishing the introducing procedure of object technology

■ Using the CASE tool

3. Contents and scope

■ Establishing the introducing procedure of object technology

■ Using the CASE tool

- Project selection and preparation

- Implementation and testing

4. Results

■ Establishing the introducing procedure of object technology

① Object oriented methods :

② Object oriented programming languages

③ Object oriented CASE tool

④ Application implementation and testing

⑤ Training

■ Using the CASE tool

- Project selection and preparation

- Implementation and testing


CONTENTS

Chapter 1 Introduction

1.1 Overviews

1.2 Objectives

1.3 Scope

Chapter 2 Object-oriented CASE tools

2.1 Overview

2.2 Comparison of methodologies

2.3 Comparison of object oriented CASE methodology

2.4 Selection of CASE tool

Chapter 3 Building a sample application

3.1 Sample application

3.2 Object model

3.3 Coding and compiling

3.4 Building views and mappings using tool

3.5 Results

Chapter 4 Introducing the object technology

Chapter 5 Conclusion

References


목 차

1. 서론

1.1 연구의 필요성

1.2 연구 목적

1.3 연구 내용 및 범위

2. 오브젝트 지향 CASE 기술

2.1 오브젝트 지향 개념

2.2 오브젝트 지향 개발 방법론

2.3 오브젝트 지향 CASE 도구

2.4 오브젝트 지향 CASE 도구 선정

3. 오브젝트 지향 CASE 적용 사례 분석

3.1 요구 사항 분석

3.2 오브젝트 모델 작성

3.3 프로그램 작성

3.4 데이터베이스 연결

3.5 결과 분석

4. 오브젝트 지향 CASE 기술 활용

5. 결론

참고 문헌


표 및 그림 목차

(표 2-1) 주요 오브젝트 지향 방법론 분석

(표 2-2) 상용 오브젝트 지향 CASE 도구

(표 2-3) OMTool과 Paradigm Plus의 비교

(표 3-1) Application Factory의 장. 단점

(표 4-1) 오브젝트 분석(설계) 방법 비교

(표 4-2) M. Gibson의 CASE 도구 평가 항목

<그림 2-1> Car 클래스 계층

<그림 2-2> 오브젝트 CASE 구조

<그림 3-1> 주문서 입력 화면

<그림 3-2> Application Factory를 이용한 프로그램 개발 과정

<그림 3-3> 오브젝트 다이어그램

<그림 3-4> ComponentShop 검색 화면

<그림 3-5> Customer 클래스 정보

<그림 3-6> WireShop Export 화면

<그림 3-7> WireShop 검색 화면

<그림 3-8> 주문서 입력 View

<그림 3-9> Catalogitem 클래스의 Soft Wiring 예

<그림 3-10> WireShop에 의해 생성된 C++ 헤더 파일

<그림 3-11> WireShop에 의해 생성된 C++ 구현 파일

<그림 3-12> Access 테이블 정보

<그림 3-13> Access 테이블 변환한 C++ 코드


1. 서론

1.1 연구 개발의 필요성

차세대 프로그램 언어로 오브젝트 기법 프로그램을 할 수 있는 언어들이 보급되고 있다. C++, Ada, CLOS, Object Pascal 등이 그와 같은 언어이다. 그러나 그와 같은 언어를 사용했다고 해서 오브젝트 기법의 장점을 갖는 프로그램이 자동으로 작성되는 것은 아니다. 오브젝트 기법을 잘 활용하면 오브젝트 내부의 사양 변경이 외부에 영향을 주지 않게 할 수 있으며, 따라서 소스 코드를 재사용하기 쉽게 한다. 그러나 지금까지 그와 같은 언어를 도입한 여러 예를 분석해 보건대 언어만 바뀌었을 뿐 오브젝트 기법의 장점을 충분히 살리지 하고 있는 것으로 생각된다.

오브젝트 지향 언어의 잠재적 능력을 살리기 위해서는 요구 분석이나 설계 단계 같은 소프트웨어 개발의 초기 단계부터 변경의 발생이나 장래의 기능 확장을 고려하여 오브젝트를 정의할 필요가 있다. 그와 같은 요구를 충족하기 위한 여러 가지 오브젝트 지향형 CASE 도구들이 개발되고 있다.

오브젝트 프로그래밍의 장점은 프로그램 작성 대상을 그대로 프로그램으로 변환시킨다는 점과 프로그램을 구성하는 오브젝트들을 프로그래밍 부품처럼 취급하여 소스 코드 수준에서 재사용이 가능하다는 점이다. 재사용을 원활히 하기 위해서는 분석 과정부터 설계, 코딩, 시험 등과 같은 소프트웨어 개발의 전 과정을 일관된 방법론과 도구 사용에 의해 통제하는 것이 필요하다.

오브젝트 기법 프로그램 작성에서는 class library를 일종의 부품 창고처럼 사용할 수 있다. 그것을 작성하는데 노력이 필요하지만 그것은 반복해서 사용할 수 있는 자산으로서 풍부한 class library를 가지고 있으며 그만큼 프로그램 작성 시간이나 노력이 감소되고, 그것은 외부에 공개될 필요가 없는 것이기 때문에 자체 내부에 능력을 축적할 수 있다.

따라서 우리 연구소에서도 자체의 프로그램 개발 효율을 높이기 위해서 빠른 시간 내에 오브젝트 기법 프로그램 방식을 도입하고, 일정한 CASE tool에 의해 프로그램을 개발하는 환경 및 절차를 확립하는 것이 필요하다.

1.2 연구 개발 목표

■ CASE Tool의 선정 및 선정된 Tool의 적용 시험

■ 시행 결과의 평가 및 보완

■ 전 부서로 확대 시행을 위한 교육 실시

1.3 연구 개발의 내용 및 범위

가. 선택된 개발 방법론을 자동화 한 오브젝트 CASE 도구 선택

나. 오브젝트 기법 CASE tool의 적용 절차 정립

오브젝트 지향 분석 및 설계 방법에는 여러 가지가 있어서 서로 적용 분야가 다르고 표현하는 기법이 다를 뿐 아니라 뛰어나게 우수한 방법이 존재하지 않으므로 우리의 응용과 현실에 적합한 방법론을 선택할 필요가 있다.

다. 오브젝트 CASE tool 적용 타당성 평가

선택된 오브젝트 지향 CASE tool을 보급하기 전에 선택된 오브젝트 지향 CASE tool의 효율성 객관적으로 입증할 필요가 있으며, 실제로 오브젝트 지향 CASE tool을 사용하여 파이로트 프로젝트를 수행해보는 것이 좋다. 이때 프로젝트의 규모는 소규모로 짧은 시일 내에 종료될 수 있는 것이어야 하고, 문제 영역이 잘 정의되고 쉽게 이해할 수 있는 것이어야 한다.

라. 교육 실시

선정된 오브젝트 지향 개발 방법론과 CASE tool을 시스템 개발에 적용하기 위해서는 해당 오브젝트 지향 방법론과 tool을 충분히 이해하고 있어야 하는데, 단시일 내에 오브젝트 지향 개념을 습득하기 위해서는 해당 분야의 전문가를 초빙 등 기법 확산을 위한 교육 계획을 수립하여 추진하여야 한다.

1.4 연구 개발의 내용 및 범위

외국 도입 기관의 사례 분석을 통하여 소내 도입 절차 및 시행 방법을 분석하고, 소규모의 파일로트 프로젝트를 선정하여 소내 적용을 위한 절차를 정립하고, 교육 실시 및 웍샵 개최를 통하여 선정 tool의 사용을 확산한다.


2. 오브젝트 지향 CASE 기술

1960년대부터 논의되기 시작한 소위 "소프트웨어 위기론(Software Crisis)" 문제를 근본적으로 해결할 수 있는 기술로서 CASE(Computer Aided Software Engineering)가 근래에 들어와 각광을 받고 있다. CASE란 컴퓨터의 도움을 받는 소프트웨어 공학(Software Engineering) 즉, 소프트웨어의 생산성 향상을 위해 소프트웨어 라이프사이클(Life Cycle)의 전체 단계를 연결하여 자동화 시켜 주는 통합된 도구들을 제공하는 소프트웨어 기술로 정의할 수 있다.

한편 1980년대부터 출현한 오브젝트 지향(object oriented) 소프트웨어 기술은 오브젝트에 의한 캡슐화(encapsulation), 상속화(inheritance) 등과 같은 오브젝트 지향 개념을 이용하여 소프트웨어의 재사용성(reusability), 확장성(extensibility)을 크게 개선시킴으로써 소프트웨어 개발의 생산성을 혁신적으로 증대시켜 줄 수 있는 기술로서 각광 받고 있으며 오브젝트 지향 소프트웨어 공학(Object-Oriented Software Engineering)이라는 연구 분야를 탄생시켰다. 1990년대에 들어와 이러한 오브젝트 지향 소프트웨어 기술의 연구 결과로서 오브젝트 지향 소프트웨어의 분석, 설계를 위한 여러 개발 방법론(methodology)들이 출현하여 보급되었으며 C++, JAVA 등과 같은 오브젝트 지향 프로그래밍 언어의 이용이 급속히 확산되고 있는 추세이다.

오브젝트 지향 CASE 기술은 CASE 기술과 오브젝트 지향 소프트웨어 기술을 결합하여 효율적으로 소프트웨어를 개발할 수 있도록 자동화 시켜주는 기술로 정의할 수 있으며 이미 다양한 상용 CASE 도구가 개발, 판매되고 있다. 그러나 오브젝트 지향 CASE 기술 및 도구를 효과적으로 활용하기 위해서는 우선 오브젝트 지향 개념과 이를 지원하는 개발 방법론에 대한 명확한 이해가 필요하며 CASE 도구의 기능과 특성을 정확히 파악하여 수행하고자 하는 프로젝트에 적합한 도구를 선정할 수 있어야 한다.

이에 따라 본 장에서는 먼저 오브젝트 지향 개념 및 개발 방법론에 대해 전반적으로 설명하고 오브젝트 지향 CASE 도구의 일반적인 구조와 상용 CASE도구에 대해 분석해 보았다.

2.1 오브젝트 지향 개념

오브젝트 지향 개념은 SIMULA라는 시뮬레이션 프로그래밍 언어에서 근원을 찾을 수 있으나 제록스 팔로 알토(Xerox Palo Alto) 연구소에서 개발한 Smalltalk 언어에서 그 개념이 정립되었다.

오브젝트 지향 개념은 아직 하나의 통일된 개념으로 자리잡고 있지는 못하고 있으나 답변의 연구자가 합의하고 있는 공통된 기본 개념을 간략히 요약해 보면 다음과 같다.

● 오브젝트와 메시지 (object and message)

오브젝트란 실세계의 어떤 개체를 나타내는 데이터와 프로시듀어(procedure)의 합성체를 나타낸다.

오브젝트에 대한 자세한 설명을 하기 위해 먼저 기존 프로그래밍 방식을 살펴보기로 한다. 예를 들어 크기가 5인 정수 배열(array)을 크기 순으로 정렬하는 'sort" 프로그램을 생각해 보면 기존의 프로그래밍 방식에서는 데이터 구조(크기가 5인 정수 배열)와 이 데이터 구조에 대한 프로시듀어(sort 함수)를 각각 작성하고 프로그램의 실행을 위해서 적당한 데이터를 인자(argument)로 하여 해당 프로시듀어를 호출해야 한다. 그러나 이러한 방식에서는 데이터 구조와 이에 대한 프로시듀어가 별개로 작성되어 서로 간에 아무런 연관성이 표현되지 않으므로 하나의 데이터 구조나 프로시듀어를 바꾸면 이에 관련된 모든 데이터 구조나 프로시듀어를 함께 고쳐 주어야 한다.

위의 예를 오브젝트 지향 개념을 사용하여 프로그래밍한다면 'sort'라는 오브젝트가 존재하고 'sort'는 정수 배열을 저장하기 위한 데이터 구조와 이에 대한 프로시듀어를 캡슐화 하여 함께 가지고 있다. 이때 'sort' 오브젝트가 가지고 있는 5개의 숫자에 정렬을 시키고자 한다면 사용자는 이 오브젝트에 정렬을 하라는 메시지를 보낸다. 그러면 이 메시지를 받은 오브젝트는 메시지가 지시하는 동작을 수행한 후 사용자에게 결과를 그 결과를 메시지로 보낸다. 이때 오브젝트 내의 데이터 변수(variable)를 애트리뷰트라 하고 프로시듀어는 메소드(method)라고 부른다.

이와 같이 오브젝트 지향 개념에서는 오브젝트의 상태를 표시하는 애트리뷰트와 동작을 나타내는 메소드 등의 내부적인 면과 오브젝트에 대한 동작(operation)을 일으키는 메시지, 즉 외부 인터페이스를 철저히 분리하고 있다. 그러므로 오브젝트의 사용자는 오브젝트의 애트리뷰트나 메소드의 상세한 구현 방법에는 전혀 신경 쓰지 않고 추상적으로 정의된 메시지 프로토콜을 사용하여 오브젝트를 사용하면 된다. 이러한 특성을 자료 추상화(data abstraction)이라고 하며 이는 프로그램의 유지 보수나 개량(evolution)을 용이하게 하여 소프트웨어 개발 생산성을 높이는 매우 중요한 개념이다.

● 클래스(class)와 인스턴스(instance)

클래스란 동일한 애트리뷰트와 메소드를 가지고 있는 오브젝트의 집합을 말한다. 예를 들면 -3, 4, 55, 70과 같은 오브젝트가 존재한다고 할 때 이 오브젝트들은 정수라는 공통점을 가지고 있으며 따라서 동일한 애트리뷰트와 메소드를 가지는 '정수"라는 클래스로 표현된다. 이때 '정수' 클래스에 속하는 모든 오브젝트는 '정수' 클래스의 인스턴스라고 부른다.

● 상속과 클래스 계층(inheritance and class hierarchy)

실세계에 존재하는 클래스들 중에는 각 클래스가 가지고 있는 애트리뷰트나 메소드가 다른 클래스와 동일한 클래스가 있는 경우가 많으며 이러한 동일한 애트리뷰트나 메소드는 여러 유사한 클래스 간에 공유하는 것이 프로그램을 간결하게 작성하는데 유리하다. 이를 위해 오브젝트 지향 개념에서는 클래스 간에 공통된 애트리뷰트와 메소드를 모아 하나의 새로운 클래스를 만들고 유사한 클래스들은 이 새로운 클래스로부터 공통된 애트리뷰트와 메소드를 물려받는데 이를 상속이라고 한다.

<그림 2-1>의 예에서 'sports car', 'truck', 'bus' 클래스에 공통된 'engine', 'transmission', 'drive', 'park'등은 새로운 클래스 'car'에 두고 각 클래스는 이 'car' 클래스로부터 애트리뷰트와 메소드를 상속 받는다. 그리고 'sports car', 'truck', 'bus'의 각 클래스는 그 클래스에게만 존재하거나 'car' 클래스와는 다른 애트리뷰트나 메소드를 별도로 가질 수 있다. 이때 'car' 클래스를 상위 클래스(super class), 'sports car', 'truck', 'bus'클래스를 하위 클래스(sub class)라고 부른다.

이와 같이 오브젝트 지향 개념에서는 상속을 통해 이미 구성되어 있는 클래스의 애트리뷰트와 메소드를 물려 받고 필요한 부분만을 재구성하여 확장할 수 있으므로 소프트웨어의 재사용성과 확장성이 뛰어나다.

상속의 구조에는 단일 상속(single inheritance)와 다중 상속(multiple inheritance)이 있다. 단일 상속에서 하위 클래스는 오직 하나의 클래스만을 상위 클래스로 가진다. 하위 클래스는 상위 클래스로부터 받은 애트리뷰트와 메소드를 그대로 사용하거나 새로 대치(substitution)하며, 상위 클래스에 존재하지 않는 새로운 애트리뷰트와 메소드를 첨가(addition)함으로써 자신의 클래스를 형성한다. <그림 2-1>은 단일 상속의 한 예이며 상위 클래스와 하위 클래스가 트리(tree) 형태로 구성된 것을 클래스 계층이라고 한다. 다중 상속은 단일 상속과는 달리 하위 클래스가 여러 개의 클래스를 상위 클래스로 가지는 상속 구조를 말하며 클래스 계층은 그래프 형태를 이루며 이를 클래스 래티스(class lattice)라고 부르기도 한다.

2.2 오브젝트 지향 개발 방법론

2.2.1 개요

1960년대 이후 하드웨어의 가격 하락으로 인한 컴퓨터의 빠른 보급과 이에 따른 응용 분야의 확대에 따라 소프트웨어는 그 크기가 방대해지고 더욱 복잡하게 되었다. 이에 따라 소프트웨어의 공급이 수요를 따라가지 못하고 또한 개발된 소프트웨어의 품질을 의심받는 일이 잦아져 이미 60년대 후반에 "소프트웨어 위기론"까지 대두되었다.

이러한 상황에서 소프트웨어도 마치 하드웨어를 공장에서 생산하는 것과 같이 규격화하여, 그 생산성과 정확도를 높이려는 접근을 시작하였는데 이것이 본격적인 소프트웨어 공학의 태동이라 할 수 있다. 소프트웨어공학의 최종 목표는 성공적인 소프트웨어 생산품을 만드는 일이고 이를 위해 성공적인 생산 기술(즉 빠른 시간 내에 좋은 품질의 소프트웨어를 생산하는 개발 방법론)을 개발하는 것이 주요 연구 내용이다.

개발 방법론이란 간단히 말해서 소프트웨어를 효율적으로 개발하기 위한 체계적이고 정형화된 방법의 집합으로 정의할 수 있다. 그중 1970년대 초에 Yourdon, De Marco 등에 의해 제안된 구조적 방법론(Structured Methodology)은 분할 정복(divide and conquer) 개념에 의거해서 소프트웨어 전체를 기능별로 계층화된 모듈 단위로 분해하여 개발하는 방법론으로 소프트웨어 개발에 지대한 공헌을 하였다. 그러나 구조적 방법론은 소프트웨어의 재사용성이나 개발된 소프트웨어의 유지 보수 및 진화에 효과적인 해결 방법을 제시하지 못한다는 단점을 갖고 있어서 소규모 내지는 중간 규모 이하의 소프트웨어를 개발하기에는 적합한 방법이나, 대규모의 소프트웨어를 개발하기에는 근본적으로 한계를 띄고 있다.

오브젝트 지향 방법론은 이러한 구조적 방법론의 근본적 한계를 극복하기 위해 오브젝트 지향 개념을 도입한 새로운 방법론으로 오브젝트 지향 개념에 의거하여 소프트웨어를 분석, 설계, 구현한다. 최초로 오브젝트 지향 분석, 설계에 가장 근접한 연구는 Peter Chen에 의해 1980년도에 널리 알려진 정보 모델화(Information Modeling)라고 할 수 있다. 정보 모델화에 의한 분석 결과는 E-R(Entity Relationship) 다이어그램인데 이것은 먼저 분석하고자 하는 시스템의 데이터를 표현한 애트리뷰트를 나열한 후, 정렬하여 개체(entity)를 만들고 개체 간의 관계를 형성시키는 방법으로 다이어그램을 만든다. 이러한 접근 방법을 데이터 중심적(data driven)방식이라 말하며 데이터 중심적이라는 면에서 오브젝트 지향 개념과 유사하나 데이터 캡슐화, 상속화, 메시지 전달과 같은 핵심적인 오브젝트 지향 개념을 지원하지 않는다.

최초의 오브젝트 지향 방법론에 대한 연구 발표는 1988년 Shlaer와 Mellor에 의해 이루어졌으며 그후 Rumbough, Booch, Jacobson, Martin 등에 의해 여러 방법론이 제안되었으나 아직 구조적 방법론처럼 표준화된 방법론은 존재하지 않고 있다. 그러나 이러한 방법론들은 분석/설계 절차, 용어, 표기법 등은 서로 다를지라도 근본적인 개념 및 접근 방법은 유사하다.

예를 들어 어떤 문제를 해결하기 위한 시스템은 기본적으로 행위의 대상이 되는 데이터, 행위의 주체가 되는 프로세스(process), 행위의 시점을 나타내는 제어(control)의 세가지 요소로 구성된다. 기존의 구조적 방법론은 프로세스에 중점을 두고 프로세스를 먼저 분석, 설계한 후 데이터와 제어를 설계하는 프로세스 중심적(process driven) 방법론이나 오브젝트지향 방법론은 오브젝트에 중점을 두고 오브젝트의 데이터 부분을 우선 분석, 정의한 후 프로세스와 제어 부분을 설계하여 오브젝트 설계를 완성시키는 데이터 중심적 방법론이다.

오브젝트 지향 설계를 위해서는 오브젝트 및 클래스의 분석 및 정의, 클래스들 간의 계층적 구조, 클래스 재사용, 클래스 라이브러리를 이용한 응용 프로그램 구성 등에 역점을 두어야 한다. 오브젝트 지향 설계는 클래스 정의에서부터 시작된다. 오브젝트 지향 설계 과정은 무(無)에서 시작되는 경우가 거의 없고 대개 점진적(incremental)인 설계 과정이 된다. 즉, 기존의 클래스 라이브러리에 저장된 클래스를 이용하여 새로운 클래스를 유도(derivation)하거나 시스템 요구 사항에 맞게 수정하여 설계를 시작한다. 그러므로 모든 오브젝트 지향 방법론은 클래스를 인식하고, 정의하고, 구성하는 법칙과 클래스의 메소드와 메시지 인터페이스를 설계하는 법칙을 말할 때 제공한다. 또한 클래스 라이브러리를 구성하는 전략과 기존의 클래스 라이브러리에서 응용 프로그램을 구현하는 지침(guideline)이 제공되어야 좋은 방법론이라고 볼 수 있다.

모든 오브젝트 지향 방법론은 다음과 같은 네 가지 기본적인 단계를 거친다.

1. 오브젝트와 클래스를 분석하고 정의한다.

2. 클래스들간의 관계(relation)를 구성한다.

3. 클래스들의 계층 구조를 형성한다.

4. 재사용 가능한 클래스 라이브러리를 제작한다.

각 방법론에 따라 새로운 단계가 추가되거나 각 단계의 순서가 변경되지만 위의 단계를 크게 벗어나지는 않는다.

오브젝트 지향 방법론은 구조적 방법론 등과 같은 다른 방법론에 비해 다음과 같은 여러 가지 중요한 장점을 제공한다.

첫째, 오브젝트 지향 방법론에 의한 설계는 C++와 같은 오브젝트 지향 프로그래밍 언어의 장점을 최대한 발휘할 수 있게 해준다. 더구나 잘 정의된 클래스 라이브러리가 존재하지 않을지라도 그 장점이 발휘된다. 또한 설계 내용이 오브젝트 지향 프로그래밍 언어로 구현되지 않을지라도 오브젝트 지향 시스템의 장점을 나타낼 수 있게 해준다.

둘째, 구조적 방법론 보다 훨씬 적은 양의 코드, 재사용성이 뛰어난 코드, 변화에 탄력적인 코드를 생산한다.

셋째, 데이터와 프로세스가 오브젝트로 캡슐화 되어 있으므로 여러 개발팀이 서로 독립적으로 시스템을 개발하기가 용이하다.

넷째, 실세계의 문제를 오브젝트를 통해 자연스럽게 이해할 수 있으므로 시스템 개발자 뿐만 아니라 일반 사용자가 이해하기가 쉽다.

2.2.2 방법론 분석

오브젝트 방법론을 이용하여 소프트웨어를 개발하고자 할 때 여러 방법론이 존재하므로 어떤 방법론이 적합한지 정확히 판단할 수 있어야 한다. 이를 위해 여러 방법론 중 널리 알려지고 실제로 활용되고 있는 주요 방법론을 선택하여 각 방법론의 내용과 장. 단점에 대해 간략히 살펴보기로 한다.

● Booch 방법론

가장 인기 있는 방법론 중의 하나이며 많은 상용 CASE 도구에서 지원된다. 현재 Booch는 Rational Rose라는 CASE 도구를 판매하는 Rational Software사의 수석 과학자로 활동 중이며 후에 설명할 다른 방법론의 창시자인 Rumbaugh, Jacobson과 함께 새로운 개발 방법론인 "Unified 방법론"(후에 설명)을 연구 중에 있다.

Botch 방법론은 4단계로 이루어지는데 논리적 구조, 물리적 구조, 클래스 동작, 인스턴스 동작을 설계한다. 논리적 구조와 물리적 구조 설계는 시스템의 정적인 측면 즉, 데이터 구조와 프로그램 기능을 설계하며 결과물로는 클래스 도표, 오브젝트 도표, 모듈 도표, 과정 도표가 있다. 클래스 동작, 인스턴스 동작 설계는 시스템의 동적인 측면 즉, 프로그램의 처리 흐름과 사건(event)을 설계하며 결과물로는 상태 이전(state transition) 도표, 타이밍(timing) 도표가 있다.

Booch 방법론은 요구 사항 분석과 도메인(domain) 분석을 설계에 앞서 행하지만 주요 장점은 위에서 설명한 설계 단계에 있으며 설계 단계에서 정확하고 상세한 설계서가 산출된다. 그러나 복잡한 규칙을 가진 시스템을 설계할 때 상태 이전 도표가 복잡해진다는 단점이 있다. 예를 들어 상태이전 도표가 20여개 이상이 되면 다루기가 매우 힘들게 된다.

● OMT(Object Modeling Technique) 방법론

Rumbaugh에 의해서 개발된 OMT 방법론은 오브젝트 지향 설계 및 구축에는 부족한 점이 다소 있지만, 분석자와 설계자들에게 상당히 유용한 아이디어와 접근법을 다수 포함하고 있어 가장 널리 사용되는 방법론이다. OMT 방법론은 Rumbaugh의 베스트셀러 저서인 "Object Oriented Modeling and Design"에 거의 완벽하게 설명되어 있으므로 상세한 내용은 이를 참조하면 된다.

OMT는 요구 사항의 사양들이 존재한다는 가정에서부터 출발한다. OMT에서 분석 단계는 다음 세 모델로 구성된다.

◇ 오브젝트 모델(Object Model) : 클래스의 정적인 부분 즉, 데이터를 나타내는 애트리뷰트를 정의

◇ 동적 모델(Dynamic Model) : 오브젝트의 동적인 부분 즉, 시간 흐름에 따라 변하는 오브젝트 상태를 표현

◇ 기능적 모델(Functional Model) : 오브젝트의 처리 흐름을 표현하며 DFD(Data Flow Diagram)와 유사함

각 모델의 자세한 내용은 "3장 CASE 도구 적용 사례"에서 실 예를 들어 설명하기로 한다.

다른 방법론에 비해 OMT 방법론은 매우 상세하며 실제로 적용하기에 편리한 방법론이다. OMT는 기존 구조적 방법론과 호환되는 많은 전통적인 도표를 지원하며 풍부한 오브젝트 모델링 기호를 포함하고 있다. OMT의 단점 중 하나는 응용 시스템 개발시, 클래스 라이브러리 구축을 통한 재사용 기법에 대한 지침을 포함하지 않고 있다는 것이며 이러한 문제는 별도의 클래스 라이브러리 구축 방법이나 CASE 도구를 이용함으로써 보완될 수 있다.

● 오브젝토리(Objectory) 방법론

Jacobson의 완벽한 방법론인 Objectory는 다른 방법론과 유사하지만 사용사례(Use Case)란 특징적인 개념을 포함하고 있어 특히 시스템 분석 및 모델링에 강점을 가지고 있다. Objectory는 Jacobson 의 저서인 "Object Oriented Software Engineering: A Use Case Driven Approach"에 축약되어 설명되어 있으므로 이를 참조하면 된다.

사용 사례 정의는 '행위자(Actor)'와 시스템 간의 상호 동작에 대한 도표와 설명으로 구성된다. 여기서 행위자는 최종 사용자나 시스템의 다른 오브젝트 이 될 수 있다. 예를 들면 주문 입력 프로그램 사용 사례의 경우 주문 입력의 각 단계 동안에 시스템과 행위자 간의 상호 동작 방법을 순서대로 상세하게 설명하고 예외 상황에 대한 설명도 포함한다. 즉, 사용 사례는 한 행위자가 다른 행위자에게 어떤 측정할 수 있는 정보를 제공하기 위해 시스템과의 대화에서 수행하는 트랜잭션(transaction)의 순서이다.

일반적으로 사용 사례들은 사용자와의 대화를 통해 요구 사항을 추출하여 문서화하는데 사용된다. 문서화된 사용 사례는 실세계에서 추출한 오브젝트과 함께 "도메인 오브젝트 모델"을 만드는데 사용된다. "도메인 오브젝트 모델"은 OMT의 오브젝트 모델과 유사한 모델이며, 오브젝트의 동적인 측면을 나타내는 실체 오브젝트와 컨트롤(control) 오브젝트 이 추가적으로 만들어진다.

Objectory의 가장 큰 장점은 사용 사례가 이해하기가 쉽게 작성되어 있을 경우 최종 사용자와 개발자가 살펴보고 서로 의견을 교환하기가 매우 편리하다는 점이다. 반면 단점은 모든 문제를 사용 사례로 분석하여 표현할 수 없는 경우가 많아 크고 복잡한 시스템을 개발할 경우에 적합하지 않은 경우가 많다는 것이다.

● Shlaer and Mellor 방법론

가장 초기에 발표된 방법론으로 88년에 처음 발표되었으며 그 이래로 계속 진화되어 왔다. 이 방법론은 본래 E-R 모델링과 같은 데이터 모델링의 개체에 기초하여 개발된 방법론으로 개체, 애트리뷰트, 개체 간의 관계를 기술하는 정보 모델을 가지고 시작한다.

다음 단계는 상태 모델로서 오브젝트의 상태와 오브젝트들간의 상태 이전을 문서화한다. 마지막으로 데이터 흐름 도표는 과정 모델을 보여준다.

이 방법론은 데이터 모델링에 큰 비중을 할애하고 있으므로 데이터베이스 설계에 적합한 방법론이라고 볼 수 있다.

● Coad and Yourdon 방법론

Coad and Yourdon은 처음으로 실제적이고 상당히 완벽한 오브젝트 지향 분석 및 설계에 대한 책들을 발행했다(보고서 뒷면의 참고문헌 참조). 그들의 방법론은 비지니스 문제에 대한 분석에 주안점을 두고 있으며 Bootch, shlaer, Mellor 방법론 등에 비해 친숙한 기호를 사용하고 있다.

이 방법론은 분석을 위해 SOS-AS라는 다음의 5단계를 거친다.

◇ 주체(subjects) : 데이터 흐름 도표에서의 레벨이나 층과 비슷하며 5개 내지 9개의 오브젝트들을 포함하고 있다.

◇ 오브젝트 : 오브젝트 클래스들은 이 단계에서 구체화되며 몇 가지 지침이 제공된다.

◇ 구조(structures) : 분류 구조(classification structures)와 혼합 구조(composition structures)라는 두가지 유형이 있다. 분류 구조는 클래스 간의 상속 관계에 해당하며 혼합 구조는 클래스 간의 관계에 대한 또 다른 유형들을 정의한다. 그러나 이 방법론은 다른 방법론 보다 클래스 구조를 명확히 기술하지 못한다.

◇ 애트리뷰트 : 클래스 내의 데이터에 대한 속성을 기술한다.

◇ 서비스(services) : 오브젝트에 대한 메소드와 호출을 기술한다.

Coad and Yourdon 방법론은 배우고 시작하기가 쉬운 방법론으로 평가되나 너무 단순해서 대규모 프로젝트에는 적합하지 않다는 단점이 있다.

● 퓨전(Fusion)

90년에 HP에서 근무하던 콜먼(Collman)이 영국에서 팀을 구성하여 개발한 방법론이다. 콜먼은 최고의 방법론은 명료한 기호를 가진 단순한 방법론이라는 생각을 가지고 Bootch, Rumbaugh, Jacobson 등의 방법론에서 주요 아이디어를 가져와 이를 통합시켰다.

퓨전은 다른 방법론에 비해 대규모 프로젝트를 수행하는데 실용적이라고 평가되나 일반에게 널리 알려져 있지 않아 많이 이용되지는 못하고 있다.

● LBMS SEOO

SEOO(Software Engineering Object Oriented)은 영국의 LBMS사가 개발한 전용 방법론이다. SEOO는 파워 빌더(power builder)와 같은 윈도우용 4세대 언어(4th generation language)와 긴밀히 통합되어 있으며 매우 실용적이고 유용한 도구로 평가되고 있다. LBMS는 SEOO 방법론을 지원하는 CASE 도구의 판매에 주력하고 있으며 여기서 소개한 방법론 중 유일하게 공식 책자로 문서화되어 있다.

SEOO는 전용 제품이기 때문에 다른 방법론 만큼 입수할 수 있는 정보가 그리 많지 않으며 따라서 다른 방법론과 구체적으로 비교하는 것은 어렵다. SEOO의 4가지 주요 구성요소는 다음과 같다.

◇ 작업 분할 구조 및 기술

◇ 오브젝트 모델링 방법론

◇ GUI(Graphical User Interface) 설계 기술

◇ ER 모델링과 4세대 언어를 위한 관계형 데이터베이스(RDBMS) 연결 기능

SEOO는 다른 방법론과 달리 순수한 오브젝트 지향 개념을 채택하지 않고 기존의 전통적인 개념 즉, 구조적 방법론, 데이터 모델링 기법을 기반으로 하여 오브젝트 지향 개념을 가미한 방법론으로 기존 비오브젝트 지향 방법론에 익숙한 사용자가 체득하기 쉽다는 장점이 있다.

(표 2-1)은 위에서 설명한 7개 주요 방법론을 분석, 요약해 놓은 것이며 이러한 방법론을 선택할 때 가장 먼저 고려해야 할 사항은 개발하고자 하는 애플리케이션에 어떤 방법론이 적합한지 여부를 판단하는 것이다. 그 다음에 고려해야 할 것은 방법론을 사용하는데 드는 비용, 방법론의 기능상 한계, 방법론을 이용할 수 있는 기술 수준, 교육 기간 등이며 이러한 모든 면을 면밀히 비교, 검토하여 가장 적합한 방법론을 선택해야 한다.

(표 2-1) 주요 오브젝트 지향 방법론 분석

분석 방법론

모델링 방법

특 징

장 점

단 점

응용 범위

Bootch

정적, 동적, 기능적

복잡, 풍부, 실용적

설계

상태이전 도표가 복잡해짐

모든 분야

OMT

정적, 동적, 기능적

복잡, 풍부, 실용적

분석, 설계

실시간 응용에 부적합

거의 모든 분야

오브젝토리


정적, 동적, 기능적


복잡, 풍부


전체 라이프 사이클

"사용사례"를 적용하기 어려운 경우 자주발생

모든 분야


Shlaer and Mellor

정적, 동적, 기능적

복잡, 풍부

설계

동적, 기능적 모델링이 취약

실시간 응용

Coad and Yourdon

정적

단순, 제한, 실용적

분석

대규모 프로젝트에 부적합

클라이언트/서버 응용

퓨전

정적, 동적, 기능적

복잡, 풍부, 실용적

전체 라이프 사이클

인지도가 낮음

모든 분야

LBMS SEOO

정적, 동적, 기능적

중간 수준, 풍부

전체 라이프 사이클

오브젝트 지향 개념이 취약

클라이언트/서버 응용

2.3 오브젝트 지향 CASE 도구

2.3.1 CASE 구조

오브젝트 지향 CASE 도구는 오브젝트 지향 개발 방법론을 지원하는 CASE로 간략히 정의될 수 있다. 즉, 위에서 설명한 방법론을 기반으로 소프트웨어 라이프사이클 전체에 걸쳐 다양한 자동화 기능을 제공함으로써 소프트웨어 생산성을 획기적으로 향상시켜 준다.

오브젝트 지향 CASE 도구는 일반적으로 소프트웨어 라이프사이클에 적용되는 범위에 따라 라이프사이클의 일부 단계만을 지원하는 단위 CASE 도구와 전단계를 지원하는 통합 CASE 도구로 분류되며 한가지 이상의 개방법론을 지원하는데 아직 표준화된 모델이나 구조는 정립되지 않은 실정이다.

따라서 본 고에서는 특정한 오브젝트 지향 CASE 도구의 구조를 설명하지 않고 일반적인 관점에서 바람직하다고 생각하는 CASE 도구의 구조와 이 구조를 이루는 각 구성 요소를 <그림 2-2>와 같이 설명한다.

● 사용자 인터페이스(User Interface)

사용자가 오브젝트 지향 CASE 도구를 편리하게 이용할 수 있는 인터페이스 역할을 한다. 예를 들어 MS Windows나 X Window 시스템 같은 상용 Window 시스템을 이용하여 CASE 도구 사용을 위한 GUI를 제공하며 나아가 멀티미디어 인터페이스 같은 첨단 인터페이스 기능을 제공한다.

● 다이어그래밍 도구(Diagramming Tool)

오브젝트 지향 개발 방법론에서 제안한 여러 가지 표기법을 지원하는 일종의 그래픽 에디터(graphic editor)이다. 예를 들어 Rumbaugh의 OMT 방법론을 지원하는 CASE 도구라면 오브젝트 다이어그램(object diagram), 상태 다이어그램(state diagram), 자료 흐름도를 작성하는 기능을 제공한다.

● 분석 및 설계 분석기(Analysis and Design Tool)

다이어그래밍 도구로 입력한 분석, 설계 정보가 방법론에 따라서 정확하게 입력되었는지를 검사함으로써 분석, 설계 단계에서 사전에 오류를 찾아내는 도구이다.

● 코드 생성기(Code Generator)

사용자가 입력한 분석, 설계 정보를 이용하여 오브젝트 지향 프로그래밍 언어로 작성된 소스 코드(source code), 예를 들면 C++ 코드를 생성해 준다. 생성되는 코드 형태는 코드 골격(skeleton) 또는 직접 컴파일이 가능한 완전한 코드로 구분된다.

● 역공학 도구(Reverse-Engineering Tool)

역공학 도구는 기존의 C, COBOL 등으로 작성된 프로그램 코드를 분석하여 오브젝트 지향 방법론에서 정의한 분석, 설계 방법에 따라서 시스템 분석서, 설계서, 소프트웨어 구성도를 다이어그램 형태로 출력해주고 C++ 코드로 자동 변환해 주는 도구이다.

● 정보 저장소(Repository)

정보 저장소는 소프트웨어 개발에 필요한 모든 정보(분석, 설계, 소스 코드, 유지 보수 정보)를 통합적으로 저장, 관리해주는 일종의 데이터베이스로서 기존 CASE 도구뿐만 아니라 오브젝트 지향 CASE 도구의 핵심 되는 구성요소이다. 특히 통합 CASE 도구에서는 라이프사이클의 각 단계에서 생성된 정보가 정보 저장소를 통해 상호 공유, 교환되어야 하므로 반드시 필요한 구성요소이다. 정보 저장소는 일반 파일 시스템이나 DBMS로서 구현될 수 있으나 오브젝트 지향 DBMS를 이용하는 방안이 보다 효율적이다.

● 재사용 도구(Reuse Tool)

CASE 도구에서 생성된 오브젝트 을 재사용할 수 있는 클래스 라이브러리(class library)와 라이브러리 관리 도구로 구성되며 대부분의 CASE 도구에서 지원된다.

● 문서 생성기(Report Generator)

사용자가 입력한 정보나 정보 저장소에 저장되어 있는 정보를 사용자가 쉽게 이해할 수 있도록 보고서 형태로 출력, 인쇄해준다. 예를 들면 클래스 구성도, 프로그램 구조도 등의 다양한 보고서를 제공한다.

● 프로젝트 관리기(Project Management Tool)

여러 사람이 공동으로 참여하는 소프트웨어 개발 프로젝트의 관리를 지원하는 도구이다. COCOMO 모델 같은 소프트웨어 비용 평가 모델 등을 이용하여 소프트웨어의 개발 기간, 비용, 투입 인력 등을 계산하고 개발 일정을 PERT/CPM chart 등을 이용하여 관리하고 작업의 분배를 수행하는 기능을 제공함으로써 프로젝트를 성공적으로 수행할 수 있도록 도와준다.

● CSCW 지원 도구(CSCW Support Tool)

LAN과 같은 네트워크로 된 분산 환경에서 효율적으로 공동 작업을 수행할 수 있도록 지원하는 CSCW 기술을 이용하여 여러 사람이 상호 떨어져서 공동으로 소프트웨어를 효과적으로 개발할 수 있도록 형상 관리(configuration management), 화상회의 등의 "공동 작업 환경"을 제공한다.

2.3.2 CASE 도구 분석

현재 상용화된 오브젝트 지향 CASE 도구는 수십 종에 이르는데 각 도구는 나름대로의 특성과 장단점을 가지고 있으므로 특정 도구가 다른 도구보다 우수하다고 단정할 수 없다. 따라서 사용자는 자신이 CASE 도구를 적용하려는 응용 분야에 적합한 CASE 도구를 선택하는 것이 바람직하며 이를 위해 CASE 도구를 선택하기 위한 선택 기준과 이 선택 기준에 따라 상용 CASE 도구를 몇 가지 종류로 분류해 보았다.

가. CASE 도구 선택 기준

● 오브젝트 지향 개념의 준수 등급

- 오브젝트 지향 개념을 정확히 지원하는지 여부

- 기존의 구조화 방법론을 지원하는 CASE 도구로 입력한 정보를 그대로 변환할 수 있는지 여부

● 지원 기능

- 오브젝트 지향 다이어그래밍 표기법에 따른 입력 기능을 제공하는지 여부

- 개발 방법론에 따라 정확하게 입력하였는지를 검사하는 의미 검사(semantic checking) 기능을 제공하는지 여부

- 완전한 소스 코드 또는 골격 코드를 생성하는지 여부

- 사용자 인터페이스 설계 기능을 제공하는지 여부

- 프로그램 테스트가 가능한 컴파일/실행 환경을 제공하는지 여부

- 프로젝트 관리 기능을 제공하는지 여부

● 외부 시스템과의 인터페이스

- 오브젝트 지향 프로그래밍 언어의 컴파일러와 접속 가능 여부

- 상용 DBMS와 접속 가능 여부

- 상용 Window 시스템의 지원 여부

- 프로그램 개발 환경의 지원 여부

● 특수 기능

- 추론 엔진(Inference Engine) 제공

- 실시간 모델링(Real-time Modeling) 기능

- CSCW 지원 기능

● 오브젝트 지향 개발 방법론

- 누구의 개발 방법론을 지원하는가?

- 한가지 이상의 개발 방법론을 지원하는지 여부

나. CASE 도구 종류

● 오브젝트 지향 다이어그래밍 도구(OO Diagramming Tools)

- 오브젝트 지향 그래픽 표기법을 지원

- 특정 오브젝트 지향 개발 방법론 만을 지원

- 가격이 저렴함

● 오브젝트 지향 CASE 도구(OO CASE Tools)

- 오브젝트 지향 그래픽 표기법을 지원

- 여러 오브젝트 지향 개발 방법론을 지원

- 소스 코드 또는 코드 골격을 자동 생성

- 대부분의 CASE 도구가 여기에 해당됨

● 오브젝트 지향 메타 CASE 도구 (OO Meta-CASE Tools)

- 여러 오브젝트 지향 개발 방법론들을 지원

- 여러 방법론들을 조합하여 사용하는 것이 가능

(예: 분석 단계는 Jacobson 방법론, 설계 단계는 OMT 방법론 사용)

- 소스 코드 또는 코드 골격을 자동 생성

● 실행 오브젝트 지향 CASE 도구(Executable OO CASE Tools)

- 특정 오브젝트 지향 개발 방법론 만을 지원

- 완전한 소프트웨어 개발 환경을 제공

(예: CASE 도구에서 생성된 코드의 컴파일과 테스트가 가능)

● 특수 오브젝트 지향 CASE 도구(Special Purpose OO CASE Tools)

- 실시간 응용(Real-time Applications) 개발에 사용

- 지식기반 시스템(Rule-based System) 응용 개발에 사용

다. 상용 오브젝트 지향 CASE 도구

위에서 분류한 방식에 따라 상용 오브젝트 지향 CASE 도구를 (표2-2)와 같이 분류하였다.

2.3.3 발전 방향

현재 개발, 판매되고 있는 상용 오브젝트 지향 CASE 도구는 <그림 2-2>와 같은 오브젝트 지향 CASE 모델의 구조와 기능을 완전히 제공하지 못하고 있으며 단지 CASE 모델의 일부 기능과 라이프사이클의 일부 단계만을 지원하는 단위 CASE 도구가 대부분이다. 또한 개발 역사가 짧고 널리 보급되어 있지 못하므로 제품의 안정성과 실용성은 미흡한 편이다.

그러나 오브젝트 지향 CASE가 "소프트웨어 위기"를 근본적으로 해결할 수 있는 최선의 기술로서 각광을 받고 있고 오브젝트 지향 소프트웨어 기술의 보급이 급격히 확산되고 있음을 볼 때 오브젝트 지향 CASE 도구의 개선, 발전이 지속적으로 이루어지리라 예상되며 시장 규모도 가까운 장래에 크게 신장되리라고 본다. 이에 따라 오브젝트 지향 CASE 도구는 미래의 소프트웨어 개발자들이 효율적인 소프트웨어 개발을 위해 필수적으로 습득해야 할 핵심 기술이 될 것이다.

현재 오브젝트 지향 CASE 기술은 다음과 같은 세가지 방향으로 발전해 나가고 있는 추세이다.

● 통합 오브젝트 지향 CASE 도구

위에서 설명한 바와 같이 현재 소프트웨어 기술은 오브젝트 지향 기술을 기반으로 한 오브젝트 지향 소프트웨어 기술로 발전해나가고 있으며 이를 이론적으로 연구하기 위한 오브젝트 지향 소프트웨어 공학이 새로이 대두되었다. 이러한 기술 동향에 따라 라이프사이클 전체를 지원하고 오브젝트 지향 소프트웨어 개발을 자동화할 수 있는 통합 오브젝트 지향 CASE 도구가 가까운 장래에 개발, 보급될 것이다.

● 지능형 오브젝트 지향 CASE 도구

상용 오브젝트 지향 CASE 도구의 가장 큰 문제점은 다이어그램을 입력, 저장하는 기능과 단순한 오류 검사 기능만을 제공할 뿐 다이어그램 형태로 입력한 분석, 설계 정보가 개발 방법론에서 정의한 규칙에 따라 정확하게 입력되었는지를 검사할 수 있는 기능이 미비하다는 점이다. 오브젝트 지향 개발 방법론은 이전의 구조화 방법론과는 달리 소프트웨어 개발시 분석, 설계가 엄격하고 정확하게 이루어져야만 효과를 발휘할 수 있다. 예를 들면 오브젝트, 클래스, 오브젝트 간의 관계, 계승 관계, 메소드가 분석, 설계 단계에서 명확히 정의되어야만 오브젝트 지향 기술의 장점인 재사용성, 확장성의 장점을 누릴 수가 있는 것이다.

이에 따라 분석, 설계 정보의 의미 검사 등과 같은 지능적인 기능이 요구되며 CASE 도구는 인공지능 기술과의 결합을 통해 고도의 지능적인 기능을 제공하는 지능형 CASE 도구로 발전되어 가는 추세이다.

● CASE 도구 표준화

상용 오브젝트 지향 CASE 도구의 또 하나의 큰 문제점은 CASE 도구 간에 호환성이 없다는 것이다. 예를 들어 A 도구로 작성한 오브젝트 다이어그램 정보를 B 도구에서 인식할 수 없을 뿐만 아니라 변환하는 것도 불가능하다. 따라서 이를 해결하기 위해서는 CASE 도구 간에 상호 운용성(interoperability)을 보증할 수 있는 표준 안이 제정되어야 하며 이 표준 안에 따라 CASE 도구가 구현되어야 한다. 특히 CASE에 대한 모든 정보를 통합하여 저장하는 repository에 대한 표준이 시급히 요구되는데 이미 1980년대에 IBM에서는 표준 repository를 기반으로 한 AD Cycle 개념을 제창하여 많은 업체의 호응을 얻었으나 여러 이유로 인해 널리 확산되지는 못하였다.

그러나 CASE 도구의 표준화는 향후 CASE 도구가 널리 보급될지 여부를 결정하는 중요한 사안이므로 가까운 장래에 표준 안이 확정되어 이에 따른 CASE 도구가 개발, 보급되리라고 예상된다.

2.4 CASE 도구 선정

본 과제의 최종 목적은 위에서 설명한 다양한 CASE 도구를 시험, 평가하여 우리 연구소에서 사용하기에 적절한 CASE 도구를 선정하고, 이 CASE 도구를 사용하는 표준 절차를 정하여, 연구소 내에 널리 이를 보급하는 일이다.

이에 따라 1차년도(1994년도) 연구에서는 먼저 오브젝트 지향 개발 방법론 및 CASE 도구에 대해 전반적으로 분석한 후, 여러 개발 방법론 중 연구소에 보급할 개발 방법론을 Rumbaugh의 OMT로 결정하고 OMT를 지원하는 CASE 도구 중에 국내에서 판매되는 OMTool과 Paradigm Plus를 선정하여 시험, 평가해 보았으며 OMTool을 실제로 사용한 간단한 파일로트(pilot) 프로젝트를 수행하였다(1994년도 연구보고서 참조). 그 결과 두 도구의특징과 장단점을 파악할 수 있었으며 이를 요약하면 (표 2-3)과 같다.

2차년도(1995년도) 연구에서는 1차년도 연구 결과를 토대로 연구소에 보급할 CASE 도구로 Cadre사의 ObjectTeam/Application Factory를 최종 선정하였으며 Application Factory를 선정한 이유는 다음과 같다.

첫째, 연구소에서 프로젝트를 수행하고 있는 연구원의 대다수가 C 및 C++ 언어를 사용하여 프로그램 코딩을 실제로 하고 있으므로 강력한 클래스 라이브러리 기능을 제공하여 "프로그램 재사용"을 효과적으로 지원할 수 있는 Application Factory가 유용하다.

둘째, Application Factory는 분석, 설계 기능 외에도 GUI 같은 주요 프로그램 구성요소를 자동 생성해 주는 기능이 뛰어난 간단한 교육만으로도 프로그램 생산성 향상에 큰 도움을 줄 수 있다.

셋째, 국내 판매원이 개발사인 미국 Cadre사와 꾸준한 협조를 통해 제품의 upgrade 및 한글화와 제품 지원을 충실히 수행하여 구입 후에도 유지, 보수가 용이하다는 점이다.

(표 2-3) OMTool과 Paradigm Plus 비교

구 분

장 점

문 제 점

OMTool

·OMT 방법론을 정확히 지원

·C++ code의 template을 자동 생성

·report 생성 기능을 제공

·자격이 저렴함

·multi platform 지원

- MS/Windows, UNIX

·소규모 프로젝트에 적합

·diagram 생성 기능이 불편함

- diagram 배열 기능이 없음

- diagram 축소 기능이 없음

·semantics 검사 기능이 없음

·Repository가 없음

·프로젝트 관리 기능이 없음

·통합개발 환경이 지원 안됨

- 자체 text editor가 없음

- compile/debug 기능이 없음

·완전한 C++ code가 생성 안됨

·manual이 부정확함

Paradigm Plus

·여러 방법론을 지원

- OMT, OMT-93, ...

·diagram 생성 기능이 우수

- diagram 배열 기능

- diagram 축소 기능

·통합 Repository 제공

·프로젝트 관리 기능 제공

·C++ code template 자동 생성

·report 생성 기능이 우수

·다중 사용자 기능 지원

- LAN상에서 운영

- file lock 기능

·multi platform 지원

·통합 개발 환경 지원

·중규모 이상의 프로젝트에 적합

·Semantics 검사 기능이 없음

·완전한 통합 개발 환경이 아님

- compile/debug 기능이 없음

·repository 정보와 diagram

정보의 불일치

·완전한 C++ code가 생성 안됨

·가격이 높음

Application Factory는 ObjectTeam이라는 통합 CASE 도구의 한 부분으로서 "프로그램 재사용"에 강점을 가진 도구이다. ObjectTeam은 Application Factory외에도 분석, 설계 기능을 강화한 ObjectTeam for OMT, ObjectTeam for Shlaer-Mellor와 프로그램 테스트 기능을 강화한 ObjectTeam ProDev라는 도구로 구성되어 있어 사용자가 자신의 프로젝트에 적합한 도구를 선택하여 사용할 수 있다. 그러나 각 도구는 서로 연결되어 있는 것이 아니라 독립적으로 활용 가능하다.

Application Factory는 다음 3부분으로 구성된다.

● DraftShop

OMT 방법론을 지원하는 오브젝트 모델링 도구로서 오브젝트 다이어그램을 GUI 화면에서 설계, 작성할 수 있다. 그러나 OMT의 오브젝트, 동적, 기능적 모델링 중 오브젝트 모델링만 지원하므로 분석, 설계 기능은 취약하다. 작성된 오브젝트 다이어그램 정보는 repository에 저장되거나 Wire-Shop으로 변환되어 export된다.

● ComponentShop

소프트웨어 부품(component)을 재사용할 수 있게 해주는 도구로서 데이터 베이스라고 부르는 repository에 오브젝트 모델 및 다이어그램, C++ 클래스 등을 저장, 관리하여 사용자가 필요에 따라 검색하여 재사용할 수 있는 기능을 제공한다.

● WireShop

소프트웨어 부품을 조립, 연결하여 프로그램을 자동 생성해주는 도구이다. 사용자 인터페이스를 위한 GUI 모듈을 생성한 후, GUI와 프로그램 로직을 연결해주는 인터페이스 코드를 생성해준다. 따라서 프로그래머는 프로그램 전체를 코딩하는 것이 아니라 WireShop에 의해 생성된 C++ 코드의 골격이 필요한 로직만을 코딩, 추가하여 프로그램을 신속히 완성시킬 수 있다.

Application Factory를 이용하여 프로그램을 작성하는 절차를 요약하면 다음과 같다.

1. 프로그램의 요구 사항을 분석한 후 DraftShop을 이용하여 오브젝트 모델 및 다이어그램을 작성한다. 다이어그램 작성시 Component Shop을 이용하여 데이터베이스에 저장된 다이어그램 정보를 검색하여 필요한 정보가 있으면 이를 가져와 재사용한다.

2. WireShop을 실행시켜 DraftShop에서 작성된 오브젝트 모델 정보를 WireShop 데이터 형식으로 변환하는데 변환된 정보는 클래스 정보와 각 클래스에 대한 view(사용자 인터페이스) 정보로 구성되어 있다. WireShop에서 이 정보를 이용하여 GUI를 설계한 후 프로그램 로직과 연결시키며, 필요에 따라 관계형 데이터베이스에 저장된 정보를 액세스할 수 있는 기능을 정의한다. 모든 작업이 완료되면 C++ 코드 골격을 생성한다.

3. WireShop에 의해 생성된 C++ 코드 골격에 필요한 로직을 추가하여 프로그램을 완성한 후, Visual C++와 같은 컴파일러를 이용하여 프로그램을 시험한다.


3. 오브젝트 지향 CASE 적용 사례 분석

오브젝트 지향 CASE 도구를 실제로 소프트웨어 개발에 적용해보기 위해 아주 간단한 주문서 입력(order entry) 프로그램을 적용 사례(case study)로 선정하였다. 이 프로그램을 개발하기 위하여 대표적인 오브젝트 지향 개발 방법론인 OMT 방법론을 이용하여 문제 분석을 수행하였으며 CASE 도구로는 2장에서 본 과제를 위해 선정한 Application Factory를 사용하였다.

Application Factory는 MS Windows 3.1 및 Windows NT에서 운용되는데 단일 사용자가 사용할 경우에는 windows 3.1용을 이용하고, 여러 사용자가 이용할 경우에는 Windows NT 서버에 Application Factory를 설치한 후 각 사용자의 PC에서 클라이언트인 Windows 3.1을 통해 공동으로 사용할 수 있다.

본 적용 사례에서는 IBM 486 PC 상에서 MS Windows 3.1용 Application Factory를 사용하였다.

3.1 요구 사항 분석

주문서 입력 프로그램을 개발하기 위해 먼저 프로그램의 기능과 이를 위한 사용자 인터페이스(user Interface)에 대한 요구 사항을 정의한다.

주문서 입력 프로그램은 <그림 3-1>와 같은 윈도우 화면을 가지는데 왼쪽화면은 주문서 데이터를 입력하는 부분이고, 오른쪽 화면 상단의 3개 버튼은 윈도우 화면의 기능을 실행시킨다.

'Enter Order'는 주문서 레코드를 입력시키고, 'Add Item'은 주문서 레코드에 포함된 주문 항목을 추가시키며, "Close"는 프로그램 수행을 종료한다. 그 외에도 왼쪽 중간 화면의 'Last Name' 항목에 고객의 姓을 키(key)로 입력하여 고객 정보를 검색할 수 있는 기능도 추가로 제공한다.

이러한 주문서 입력 프로그램의 요구 사항을 분석하여 프로그램을 설계하기 위해 OMT 방법론을 사용하였다. OMT 방법론은 여러 방법론 중 완전하고 세부적인 지침을 제공하므로 가장 널리 쓰이는 방법론이며 요구 사항 분석 단계에서 오브젝트 모델, 동적 모델, 기능적 모델의 3개 모델을 작성한다.

● 오브젝트 모델

문제로부터 오브젝트가 과클래스를 정의하고 그 들간의 관계(relationship)와 상속 관계를 정의하는 모델로서 오브젝트 클래스의 데이터 부분을 기술함으로써 문제의 정적인 구조를 표현하는 가장 안정된 모델이다. 오브젝트 모델은 오브젝트 다이어그램으로 표현되는데 오브젝트 다이어그램은 데이터베이스 모델링에 이용되는 E-R 다이어그램과 유사하며 상속관계 등을 표현하기 위해 확장된 E-R(Extended E-R) 다이어그램 표기법을 사용한다.

● 동적 모델

오브젝트 모델에서 정의된 오브젝트들이 시간의 흐름에 따라 변화되는 행위(behavior) 측면을 묘사하는 모델이다. 즉 한 시스템과 그 주변 환경사이에서 일어나는 이벤트(event)들을 찾고, 반응(response)들을 체계적으로 분석하여 상태 다이어그램으로 나타내 준다.

● 기능적 모델

오브젝트의 구조나 프로세스의 순서에 무관하게 한 시스템 내의 여러 데이터들이 어떻게 계산되고 처리되는지를 자료 흐름도를 통하여 표현한다. 이 자료 흐름도는 구조적 방법론에서 사용되는 것과 유사하다.

그러나 Application Factory는 OMT 방법론을 지원하지만 오브젝트 모델 작성을 위한 자동화 기능 만을 제공할 뿐 동적 모델과 기능적 모델을 제공하지 않는다. 따라서 사용자는 동적 모델과 기능적 모델을 수작업으로 작성하여 설계에 반영하거나, 이를 무시하고 오브젝트 모델만을 작성한 후 Application Factory의 프로그램 자동 생성 기능을 이용하여 직접 프로그램을 개발해야 한다.

Application Factory를 이용하여 프로그램을 개발하기 위해서는 다음과 같은 세부 절차를 거친다.

1. DraftShop을 이용하여 오브젝트 모델을 작성한다. 오브젝트 모델 작성시, 이전에 이미 작성되어 ComponentShop에 의해 데이터베이스로 저장된 오브젝트 모델 정보를 재사용할 수 있다.

2. DraftShop에 의해 작성된 오브젝트 모델 정보를 WireShop으로 export하여 변환시킨다.

3. WireShop에서 사용자 인터페이스, 즉 GUI를 자동 생성한다.

4. Wireshop에서 GUI 화면에 표시된 데이터 항목과 항목 처리를 위한 함수(function)를 서로 연결시켜 프로그램의 골격을 완성시킨다. 이러한 절차를 Soft Wiring이라고 부른다.

5. Wireshop에서 C++ 코드를 생성시킨다. 생성시 원하는 컴파일러의 종류를 지정할 수 있으나 기본적으로 Visual C++ 코드가 생성된다. 생성되는 화일은 구현 화일(*.cpp), 헤더 화일(*.hpp), 컴파일 및 링크를 위한 프로젝트 화일(*.mak)이며 각 클래스 별로 생성된다.

6. 생성된 골격 화일에 필요한 부분을 코딩하여 C++ 프로그램을 완성시킨 후 시험한다.

7. 데이터 베이스가 필요한 프로그램인 경우에는 MS Access 같은 관계형 데이터베이스를 이용하여 테이블을 생성하거나 이전에 만들어진 데이터베이스 테이블로부터 C++ 코드를 자동 생성한 후, 프로그램에 연결시켜 사용할 수 있다.

<그림 3-2>는 이러한 과정을 도표로 요약하여 나타낸 것이다.

3.2 오브젝트 모델 작성

주문서 입력 프로그램을 위한 오브젝트 모델을 다음과 같은 절차에 의해 작성하였다.

1. 문제 분석으로부터 주문서 입력 프로그램의 클래스 오브젝트를 추출하였는데 클래스는 Customer, Order, OrderItem, CatalogItem이다.

2. Customer는 Order를 주문한다(places)라는 관계가 성립한다.

3. Order와 OrderItem 사이에는 1:n의 관계가 존재한다.

4. OrderItem은 CatalogItem을 참조한다(references)라는 관계가 성립한다.

5. 각 클래스는 여러개의 애트리뷰트를 포함한다.(그림 3-3 참조)

<그림 3-3>은 작성한 오브젝트 모델의 다이어그램을 DraftShop으로 입력한 것이다.

이러한 오브젝트 다이어그램의 작성시 ComponentShop을 효과적으로 이용할 수 있다. 즉, DraftShop을 이용해서 Order, OrderItem만을 작성하고 Customer, CatalogItem은 ComponentShop에 의해 저장된 데이터베이스에 이미 존재하는 클래스이므로 이를 재사용하여 신속하고 편리하게 오브젝트 다이어그램을 완성할 수 있다.

먼저 원하는 클래스가 데이터베이스에 존재하는지 알기 위해서 Componet-nentShop을 이용하여 검색한다. <그림 3-4>는 ComponentShop에 의해 저장된 데이터베이스를 나타낸다.

사용자가 데이터베이스 정보를 검색하기 위해서는 keywords 박스에 나타난 키워드를 선택한 후, Search 버튼을 누르면 된다. 오른편 화면의 Domain/Class Hierarchy는 데이터베이스에 저장된 전체 클래스의 계층 구조를 나타내는 것으로 이를 통해 전체 정보를 쉽게 파악할 수 있다.

<그림 3-5>는 <그림 3-4>에서 선택한 Customer keyword에 의해 검색된 Customer 클래스에 대한 정보이다. Customer 클래스가 포함하고 있는 애트리뷰트, 다른 클래스와의 관계 등의 상세한 정보를 알 수 있다.

원하는 클래스 정보가 검색되면 ComponentShop에서 이를 그대로 복사하여 DraftShop의 오브젝트 다이어그램 설계 화면으로 가져올 수 있으며 이러한 작업을 반복함으로써 주문서 입력 프로그램의 오브젝트 다이어그램을 완성한다. 완성된 오브젝트 다이어그램은 WireShop으로 export되어 변환된다.

<그림 3-6>은 WireShop으로 오브젝트 다이어그램을 export하기 위한 화면이며 좌측 상단의 메뉴에서 Export 옵션을 선택한다. 또한 오브젝트 다이어그램을 위한 보고서(report)를 생성하거나 C++ 코드를 생성할 수도 있다.

3.3 프로그램 작성

WireShop에서는 DraftShop으로부터 export된 오브젝트 모델 정보를 이용하여 프로그램을 자동 생성하는 전체 프로그램을 생성하는 것이 아니라 주로 화면을 구성하는 "사용자 인터페이스"와 연결된 프로그램 로직(program logic)의 골격이다.

이를 위해 WireShop은 DraftShop에서 정의한 클래스, 애트리뷰트, 클래스간의 관계, 메소드에 대한 정보를 가지고 있을 뿐만 아니라 "user interface view"라고 부르는 새로운 정보를 가지고 있다.

view는 각 클래스 마다 존재하며 클래스가 포함하는 애트리뷰트에 대한 입력 항목, 각 메소드를 위한 버튼으로 구성된다. 다시 말해서 view는 클래스를 위한 입력 화면이라고 볼 수 있으며 WireShop에 의해 자동 생성된다. <그림 3-7>은 WireShop에서 CatalogItem 클래스가 가지고 있는 정보를 검색한 화면으로 오른쪽 끝의 connections 항목이 CatalogItem의 view를 나타내는 항목이다.

View는 WireShop에 의해 기본적으로 생성되나 사용자가 view의 형식이나 모양을 다르게 만들기를 원하는 경우에는 새로 설계, 작성하는 것이 가능하다. View는 각 클래스 마다 작성된 후 마지막으로 전체 프로그램을 위한 view가 작성된다. <그림 3-8>은 주문서 입력 프로그램의 전체 view를 나타낸 것이다.

WireShop에서 view의 작성이 끝나면 view에서 정의한 입력 항목과 항목을 위한 메소드(함수) 사이의 연결 동작을 정의하는 "Soft Wiring"절차를 수행한다. <그림 3-9>는 CatalogItem 클래스를 위한 Soft Wiring 화면을 표시한 것으로 'Connection Composer'화면의 하단에 표시된 'Mappings' 항목에 CatalogItem의 애트리뷰트인 itemNumber와 findCatalogitem 함수 사이의 연결 동작이 정의되어 있다. 여기서의 연결동작은 itemNumber 애트리뷰트가 view에서 변경될 때 findCatalogitem이 자동으로 호출(call)된다.

WireShop에서 프로그램 작성이 끝나면 마지막으로 C++ 코드를 자동 생성하며 <그림 3-10>과 <그림 3-11>은 WireShop에서 자동 생성된 C++ 프로그램 코드의 예를 보인 것이다. 이 코드는 완전한 프로그램 코드가 아닌 코드골격으로서 클래스를 정의한 헤더 화일(header file)과 멤버 함수(member function)를 정의한 구현 화일(implementation file)로 구성된다. 프로그램 작성자는 멤버 함수를 정의한 파일 내에 각 함수의 알고리즘을 코딩하여 추가함으로써 프로그램을 완성시킬 수 있다.

이러한 WireShop의 프로그램 생성 절차를 요약해 보면 DraftShop에서 적성한 오브젝트 모델 정보를 이용하여 먼저 GUI를 설계, 생성한 후 GUI와 프로그램 로직을 연결하는 부분을 추가로 정의하는 것이며 이러한 점을 볼 때 일종의 4세대 언어 기능을 제공한다고 볼 수 있다.

3.4 데이터베이스 연결

상용 소프트웨어를 개발할 경우 데이터베이스를 사용하는 경우가 많으므로 대부분의 상용 오브젝트 지향 CASE 도구에서는 데이터베이스 연결 기능을 제공한다. Application Factory에서는 데이터베이스 연결을 위해 여러 다양한 기능을 제공하는데 특히 관계형 데이터베이스를 C++ 프로그램과 연결시키는 기능은 데이터베이스 응용 프로그램을 개발하는데 매우 유용하다.

주문서 입력 프로그램에서는 Customer 클래스와 Catalogutem 클래스를 위한 정보를 <그림 3-12>와 같이 MS Access 관계형 데이터베이스를 이용하여 저장하고 있다.

<그림 3-12>에는 두개의 테이블에 대한 스키마 정보가 표시되어 있는데 dbcustomer 테이블은 Customer 클래스에 대한 DB 정보를, dbcatalog 테이블은 CatalogItem에 대한 DB 정보를 나타난다.

이러한 테이블 정보는 Application Factory에서 제공하는 C++ Class Generator에 의해 C++ 코드로 변환되어 앞에서 작성된 프로그램과 연결(link)됨으로써 테이블에 저장된 정보를 C++ 프로그램에서 액세스(검색, 입력, 변경)하는 것이 가능하게 된다.

<그림 3-13>은 C++ Class generator에 의해 C++ 코드로 변환된 테이블 정보를 나타낸 것이다.

3.5 결과 분석

주문서 입력 프로그램을 적용 사례로 채택하여 Application factory를 적용해 본 결과 Application Factory의 장점과 단점을 알 수 있었으며 이를 요약해 보면 (표 3-1)과 같다.

오브젝트 지향 CASE 도구를 사용해 본 결과 도구의 다이어그램 생성 기능, 보고서 생성 기능, 코드 자동 생성 기능 등이 소프트웨어 개발에 매우 유용하다는 사실을 알 수 있었으나 CASE 도구의 많은 제약점으로 인해 소프트웨어 라이프사이클의 모든 단계에서 적용할 수는 없었으며 보다 CASE 도구가 확산되기 위해서는 CASE 도구의 지속적인 보완, 개선이 수반되어야 한다고 생각된다.

또한 오브젝트 지향 CASE 도구는 오브젝트 지향 개발 방법론을 구현한 도구에 지나지 않으므로 이 도구를 효과적으로 활용하기 위해서는 개발 방법론에 대한 정확한 이해와 소프트웨어 개발에 CASE 도구를 적용시킬 수 있는 능력과 경험이 배양되어야 한다고 본다.

(표 3-1) Application Factory의 장단점

구 분

장 점

문 제 점



Application

Factory 분석

·풍부한 Repository 제공

·오브젝트 모델 및 코드 재사용 기능이 뛰어남

·GUI 설계 기능 제공

·C++ code의 template을 자동 생성

·데이터베이스 연결 기능 제공

·오브젝트 분석 기능이 취약

- 동적 모델링 기능이 없음

- 기능적 모델링 기능이 없음

·Semantics 검사 기능이 없음

·프로젝트 관리 기능이 없음

·통합 개발 환경이 지원되지 않음

- 자체 Compile/Debug기능이 없음

·완전한 C++ code가 생성되지 않음




4. 오브젝트 지향 CASE의 활용

4.1 오브젝트 지향 CASE의 도입 절차

소프트웨어 복잡성 증대와 비용의 급증에 대한 해결책으로 오브젝트 지향 개발 기술을 도입해야 한다는 인식은 어느 정도 공감대를 형성하고 있으나, 현재 익숙해 있는 개발 방법을 버리고 전혀 새로운 방법론을 어떤 단계적인 절차 없이 도입한다는 것은 과제를 수행하고 있는 과제 참여자의 반대나 수행 중인 프로젝트의 실패를 초래할 우려가 있다. 따라서 오브젝트 지향 기술의 도입 단계를 전략적으로 정의할 필요가 있다.

일반적으로 오브젝트 지향 기술을 도입한다고 하면 가장 쉬운 직접적인 방법으로 기존의 사용 중인 개발 언어만을 오브젝트 지향 프로그래밍 언어의 구문으로 대치하는 것을 생각할 수 있다. 그러나 이것은 오브젝트 지향 기술에 대한 이해 없이 프로그램 텍스트만을 대치하는 꼴로 오브젝트 지향 기술이 장점으로 하고 있는 소프트웨어 재사용, 자연적인 모델링, 유지 보수의 용이성 등에 대한 충분한 효과를 거둘 수 없다. 다음 단계로 오브젝트 지향 기술의 핵심 개념을 이해하고 응용에 적당한 오브젝트 지향 개발 방법론에 의해 분석과 설계를 실시한 후 오브젝트 지향 언어로 구현하는 방법을 고려할 수 있다. 그러나 이 방법은 오브젝트 지향 기술에 의해 분석과 설계를 실시하므로 오브젝트 지향 기술의 장점을 충분히 발휘할 수 있으나 분석과 설계 단계에서 발생한 오류로 인한 시행 착오의 어려움을 극복할 수 없다. 따라서 이러한 분석과 설계 단계에서의 절차상 오류를 극복하기 위하여 분석과 설계, 구현 등을 자동화 한 오브젝트 지향 CASE 도입의 필요성이 자연스럽게 제기된다.

오브젝트 지향 CASE란 오브젝트 지향 방법으로 소프트웨어를 개발하는 전 과정에서 사용하는 개발 도구나 개발 방법론들을 상호 연결하여 자동화 한 것으로 오브젝트 지향 개발 툴킷(tool-kit), 오브젝트 지향 개발 방법론 지원 도구, 객체 지향 프로젝트 관리 도구 등으로 세분화 할 수 있다.

이와 같은 오브젝트 지향 CASE를 소프트웨어 개발의 전 과정에 도입하여 소프트웨어 생산성의 향상을 꾀할 수 있겠으나 본 과제에서는 오브젝트 지향 기술을 연구소에 성공적으로 도입하고 널리 확산시키기 위한 오브젝트 지향 기술의 보급에 필수적인 오브젝트 프로그래밍 언어, 오브젝트 지향 개발 방법론 지원 도구 등의 도입 절차에 대해서만 다음과 같이 정의하였다.

● 응용에 적합한 오브젝트 지향 개발 방법론 선택

● 응용에 적합한 오브젝트 지향 프로그래밍 언어 선택

● 선택된 개발 방법론을 자동화 한 오브젝트 지향 CASE 도구 선택

● 프로젝트 수행

● 교육

4.2 개발 방법론 선택

오브젝트 지향 분석 및 설계 방법에는 여러 가지가 있지만 (표4-1)과 같이 각 방법마다 서로 적용 분야가 다르고 표현하는 기법이 다를 뿐 아니라 뛰어나게 우수한 방법이 존재하지 않으므로 우리의 응용과 현실에 적합한 방법론을 선택할 필요가 있다. 따라서 본 과제에서는 지명도 차원에서 우세하고 연구소 내에서 가장 많이 선호하고 있으며, 객체 모델, 동적 모델 및 기능적 모델로 시스템의 모든 측면을 모델링하고 있는 Rumbaugh 방법론을 오브젝트 지향 개발 방법론으로 선택하였다.

4.3 프로그래밍 언어 선택

오브젝트 지향 언어는 순수 오브젝트 지향 언어와 혼성 오브젝트 지향 언어로 나눌 수 있다. 순수 오브젝트 지향 언어는 프로그램 내의 모든 것들이 오브젝트라는 단위로 정의, 수행되는 언어로 Simula, Actor, Eiffel 등이 있다. 혼성 오브젝트 지향 언어는 기존의 언어 구문에다 오브젝트 지향 구문을 추가한 것으로 C++, Objective C, Objective Pascal, Modular 3 등이 있다. 순수 오브젝트 지향 언어는 오브젝트라는 개념을 배제하고는 프로그램을 구성할 수 없으므로 오브젝트 지향 개념을 이해하는데는 상당한 도움을 줄 수 있으나, 일반적으로 널리 알려져 있지 않으므로 프로젝트를 수행하는 개발 도구로는 적절하지 않다. 따라서 본 과제에서는 이미 많은 사람들에게 익숙해져 있고, 각종 개발 환경이 풍부한 C++를 오브젝트 지향 프로그래밍 언어로 선정하였다.

4.4 CASE 도구 선택

선택된 Rumbaugh 개발 방법론을 자동화 한로서 오브젝트 지향 CASE 도구는 여러 가지가 있으나 본 과제에서는 M. Gibson의 평가 항목(표 4-2)에 의거하여 OMTool과 ObjectTeam/AF를 최종 선정하였으며, 각각의 도구를 사용하여 분석과 설계를 수행하였다.

(표 4-2) M. Gibson의 CASE 도구 평가 항목

1. 인간과 기계의 접속성

2. 화면/ 보고서 정의

3. 프로토타이핑 지원

4. 도형 지원

5. 문서 편집 기능 지원

6. 개방성 (외부와의 접속이 개방 구조인가 )

7. 자동 코드 생성 지원

8. 공급사의 지원과 안정도

9. 분석/설계 단계 지원

10. 코딩/유지 보수 단계 지원

11. 구매와 유지 보수 비용

4.5 프로젝트 수행

오브젝트 지향 CASE는 기존의 구조적 방법과 전혀 다르므로 오브젝트 지향 CASE 도입에 어느 정도 공감대를 형성하고 있다고 하더라도 결과에 대한 확신이 없다면 쉽게 시스템 개발에 적용할 수 없다. 따라서 새로이 선택된 오브젝트 지향 CASE를 보급하기 전에 선택된오브젝트 지향 CASE의 효율성을 객관적으로 입증할 필요가 있다. 오브젝트 지향 CASE의 효율성을 입증하는 가장 좋은 방법으로는 실제로 오브젝트 지향 CASE를 사용하여 프로젝트를 수행하는 것이다. 프로젝트의 규모는 소규모로 짧은 시일 내에 종료될 수 있는 것이어야 하고, 문제 영역이 잘 정의되고 쉽게 이해할 수 있는 것이어야 한다. 해당 프로젝트의 주목표가 오브젝트 지향 CASE의 효율성을 입증하는 것이기 때문이다. 문제 영역이 잘 정의되고 쉽게 이해할 수 있는 것으로는 구조화 기법으로 구현되어 있지만 요구 사항의 변경 및 증가로 다시 구현할 필요가 있는 소규모의 소프트웨어 시스템을 선택하는 것이 좋다. 이렇게 함으로써 문제에 대한 이해와 정의에 드는 시간을 줄일 수 있을 뿐만 아니라 오브젝트 지향 CASE를 적용한 결과를 객관적으로 입증할 수 있다. 본 과제에서는 잘 알려진 사례를 선택하여 OMTool과 ObjectTeam을 사용하여 각각 문제 분석 단계와 설계를 수행하였으며, 그 결과를 토대로 CASE도구 사용시 장점과 문제점을 분석하였다.

4.6 교육

선정된 오브젝트 지향 개발 방법론과 CASE 도구를 시스템 개발에 적용하기 위해서는 해당 오브젝트 지향 방법론과 도구를 충분히 이해하고 있어야 한다. 따라서 단시일 내에 오브젝트 지향 개념을 습득하기 위해서는 해당 분야의 전문가를 초빙하여 교육을 받을 필요가 있다.


5. 결 론

본 연구 총 3개년도 과제 중 2차년도 과제로서 당해년도의 연구 목표는 다음과 같다.

■ 선정된 CASE Tool의 시험 적용

■ 시행 결과의 평가 및 보완

■ 전 부서로 확대 시행을 위한 교육 실시

상기한 목표 달성을 위하여

■ 국외 도입 사례 분석 및 도입 단계 정립하였으며,

■ CASE tool 을 선정하여 적용 방법을 시험하였다.

각 연구 내용별로 연구 결과를 보면 다음과 같다.

■ 국외 도입 사례 분석 및 도입 단계 정립

- 국외 도입 사례 분석

▣Toshiba, Mitsubishi, NEC 등의 도입, 적용 사례 검토

- 도입 단계 정립

① 응용에 적합한 오브젝트 지향 개발 방법론 선택

② 응용에 적합한 오브젝트 지향 프로그래밍 언어 선택

③ 선택된 개발 방법론을 자동화 한 오브젝트 지향 CASE tool 선택

④ 파이롯트 프로젝트 수행

⑤ 교육

■ CASE tool을 선정하여 적용 방법을 시험

- 파이롯트 프로젝트의 선정

- CASE tool의 부분 시험 사용

본 연구가 당초의 계획대로 진행되기는 하였으나 당초 계획에 의하면 '95년 11월 또는 '96년 2월경 선정된 Cadre Inc.의 ObjectTeam/AF에 대한 소내 사용자 교육을 실시할 예정이었으나 선정된 Tool의 Release가 예상보다 늦어짐에 따라 교육 Tool 확보가 지연되어 당초 계획한 바대로 교육을 실시할 수 없었다. 이에 대하여 관련 업체에서는 본 과제의 3차 년도에 CASE tool 시험 평가팀을 대상으로 교육을 실시키로 하였다.


참 고 문 헌

[1] 김수동, "소프트웨어 위기의 돌파구, 오브젝트 지향기술", 마이크로 소프트, 1992

[2] 김수동, "오브젝트 지향 소프트웨어 공학", 정보과학회지, Vol. 11, No. 2, pp. 5-21, 1993. 4.

[3] 김원, "오브젝트 지향(OODB) 기술", 하이테크, 1992

[4] 정보과학회 소프트웨어공학연구회, 오브젝트 지향 소프트웨어 공학, 1995년 추계단기강좌, 1995

[5] 양해술, "I-CASE의 도구통합과 방법", 정보과학회지, Vol. 12, No. 2, pp. 19-27, 1994. 3.

[6] 우치수, 김갑수, "오브젝트 지향 방법론을 지원하는 CASE의 구성요소", 정보과학회지, Vol. 11, No. 2, pp. 75-83, 1993. 4.

[7] ObjectTeam Application Factory Tutorial, Cadre Inc., 1995

[8] B. Stroustrup, The C++ Programming Language, 2nd ed., Addison Wesley, 1993

[9] D. Champeauz and P. Faure, "A Comparative Study of Object Oriented Analysis Methods", Journal of Object-Oriented Programming, Vol.5, No.1, 1992

[10] G. Booch, Object-Oriented Design with Application, The Benjamin/Cummings Publishing Co., 1991

[11] James Martin and J. Odell, Object-Oriented Analysis & Design, Prentice-Hall, 1992

[12] J. Jacobson and M. Christerson, et al., Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992

[13] OMTool User's Guide, Advanced Concepts Center, 1994

[14] Rumbaugh J., et al., Object-Oriented Modeling and Design, Prentice-Hall, 1991

[15] R.S. Pressman, Software Engineering: A Practitioner's Approach, 3rd ed., McGraw-Hill, 1993