현재의 소프트웨어 개발 기술은 인터넷과 엔터프라이즈를 중심으로 매우 빠르게 발전하고 있다. 그리고, 이를 지원하기 위한 많은 소프트웨어 개발 인프라들이 제공되고 있다.
인터넷 관련 응용 프로그램은 주로 서버에서 동적으로 웹 페이지를 생성하는 서버 페이지 기술과 이 페이지로부터 서버 응용 프로그램과 연동하게끔 해주는 서버 컴포넌트 기술을 사용하게 된다. 컴포넌트 기술은 기업형 소프트웨어에 핵심적인 네트워크, 보안, DB 트랜잭션 등의 기능을 컴포넌트에 서비스 형태로 제공하는 것을 말한다.
이러한 기능은 전자상거래 및 기업 전산화와 같은 도메인에서 수시로 사용된다. 프로그램(컴포넌트)은 이들 기능을 프로그램 내부에 구현하지 않고 단순히 속성을 지정함으로써 사용할 수 있고, 도메인에 중요한 기능만 집중할 수 있게 되었다. 10여년 전의 소프트웨어 개발은 객체지향 프레임워크를 이용한 패키지 프로그램을 대상으로 했지만, 인터넷 기술의 발달과 전자상거래와 같은 인터넷 기반 시장의 성장을 통해 응용 프로그램 서버를 이용한 컴포넌트 기반 인터넷 프로그램 개발로 주 대상이 바뀌었다.
CASE 도구는 소프트웨어 개발에 관련된 작업들을 자동화하거나 보조하기 위한 도구이다. CASE 도구는 분석 및 설계뿐만 아니라 형상관리, 품질보증, 프로젝트 관리 등의 소프트웨어 개발 과정에 관련된 모든 기능들을 포괄하는 의미이나, 본 기사에서는 분석, 설계에 관련된 기능을 지원하는 도구의 의미로 사용한다. 분석-설계를 위해 CASE 도구가 지원하는 기능은 일차적으로 개념 수립 과정을 통해 명확하지 않은 개념을 이끌어내고 이를 다이어그램으로 시각화하는 것이다.
객체지향 분석-설계의 장점 중에 하나는 실세계의 개념이 프로그램 코드에 반영된다는 것이다. 이를 위해 객체지향 방법론은 요구사항 문서로부터 명사들을 뽑아내 클래스화하고 동사 부분을 메쏘드로 추출하는 작업을 포함하고 있다.
소프트웨어 모델링은 개념 수립 과정에서 시작된다. 두 번째로, 이렇게 작성된 모델을 프로그램 개발의 템플릿으로 사용하기 위해 코드 생성 기능을 제공한다. 현재까지의 도구들은 분석, 설계 및 코드 생성 작업까지를 지원 범위로 하며, 역공학을 통해 코드로부터 설계 모델을 추출하는 기능을 제공했다.
본 기사에서는 현재 엔터프라이즈 소프트웨어 개발을 지원하고, 분석-설계의 기본 기능에 코딩, 배치, 디버깅, 테스팅과 같은 개발자 또는 구현자 측면의 기능을 강화한 XDE(Rational eXtended Development Experience for Java 2.1, 이하 XDE)와 TCC(Borland Together ControlCenter 6.01, 이하 TCC)를 살펴보고자 한다. 국내에서도 컴포넌트 기반 엔터프라이즈 환경에 대한 도구 개발 및 방법론 연구가 진행 중에 있으며, CASE 도구로 한국전자통신연구원(ETRI)에서 연구 중인 COBALT 도구가 있고, 컴포넌트 개발방법론으로 마르미가 있다.
CASE 도구의 기능
두 도구는 인터넷 엔터프라이즈 응용 프로그램 개발 지원 기능을 제공한다. 기존 CASE 도구들이 플랫폼에 독립적인 분석-설계 위주의 기능을 제공하지만, XDE와 TCC는 J2EE 및 닷넷과 같은 엔터프라이즈 플랫폼의 특성들을 도구에서 지원하며, 응용 프로그램의 분석, 설계, 구현, 배치, 디버깅, 테스팅까지를 하나의 도구에서 작업할 수 있게 한다.
두 번째로, 객체지향 도구지원 신기술로 디자인 패턴, 라운드 트립 공학(RTE) 기능이 도구에 포함됐다(라운드 트립 공학은 기존의 순공학, 역공학의 단방향 및 배치 형태의 변환 작업을 넘어서 설계 모델과 구현 코드 각각의 변경을 즉각적이고 상호적인 방식으로 서로에 반영하는 기술을 말한다). 세 번째로, 개념 표현 및 코드로의 변환과 같은 개발자 위주의 기능에 덧붙여 CASE 도구를 소프트웨어 개발 공정에 적절하게 운용할 수 있는 개발 프로세스와 팀 단위 작업 지원, 품질 보증 및 문서화 등의 개발 기능이 지원된다.
인터넷 엔터프라이즈 응용 프로그램 개발 지원
인터넷 엔터프라이즈 응용 프로그램 개발은 J2EE 기술과 닷넷 기술을 기반으로 하여 이뤄지며, 응용 프로그램의 아키텍처는 이들 핵심 플랫폼 아키텍처에 의한 개발 환경에서 작성된다. CASE 도구는 플랫폼 아키텍처가 가정하는 여러 개념들(JSP, 서블릿, EJB)을 잘 표현할 수 있어야 하며, 구현 코드로 잘 변환될 수 있어야 한다. XDE와 TCC는 모두 이러한 표현 방법을 제공하고 있고 분석, 설계, 구현 및 배치에 걸치는 모든 개발 공정상의 작업들을 지원하고 있다.
<그림 1> 인터넷 엔터프라이즈 응용 프로그램 개발 기술의 일반적 구성
일반적인 J2EE 응용 프로그램의 구성은 <그림 1>과 같다. 응용 프로그램은 사용자에게 보여지는 화면 위주의 구현을 위한 프레젠테이션 층, 계좌이체나 입출금의 과정과 같은 응용 프로그램의 주된 로직을 구현하고 있는 비즈니스 층, 데이터베이스나 ERP와 같이 다른 기업 솔루션 등과 연결되어 결과를 반영하게 되는 통합 층으로 구성된다.
프레젠테이션 층은 일반 자바 응용 프로그램(J2SE App)도 가능하지만 주로 웹 페이지 구현 기술이 사용된다. JSP나 서블릿은 웹 요청에 따라 웹 서버에서 수행시에 생성되는 페이지를 위한 기술이다. 비즈니스 층에서는 EJB 컴포넌트와 응용 프로그램 서버에서 제공하는 서비스 기술이 사용된다.
서비스는 J2EE 플랫폼에 의해 사용가능한 엔터프라이즈에서 공통적으로 사용되는 기능들에 대한 스펙으로, 데이터베이스 연동(JDBC), 트랜잭션 처리(JTA), 메일 기능(JavaMail)이 있고, ERP와 같은 기존의 기업 정보시스템과의 연동을 위한 커넥터 아키텍처(JCA) 등이 있다.
EJB 컨테이너(응용 프로그램 서버)는 빈의 생성과 소멸에 관련된 구현, 트랜잭션 관리, 보안, 저장 기술 등에 관련된 모든 구현 사항을 포함하고 있다. 통합 층에서는 관계형 데이터베이스 상의 테이블 구성과 같은 여러 엔터프라이즈 정보 시스템(EIS) 상의 작업을 위한 기술이 사용된다.
J2EE 플랫폼 하에서 응용 프로그램에는 JSP와 서블릿을 사용해 프로그램의 화면을, EJB 기술을 사용해 프로그램의 로직을 구현하고, 서비스를 통해 데이터베이스에 접근하는 형태가 가장 단순한 형태일 것이다. 일반적으로 이러한 응용 프로그램을 개발할 때 분석, 설계 과정을 거치고, 이를 기반으로 구현 코드 템플릿을 생성하고 여기에 구현한 다음, 컨테이너 제공 업체의 통합 개발 환경을 통해 컴포넌트로 묶은 다음 이를 웹 서버 및 응용 프로그램 서버(EJB 서버)에 배치하는 과정을 거친다.
따라서 분석 및 설계를 위한 모델링 도구, 컴파일 및 빌드를 위한 개발 도구, 컨테이너에 배포하기 위한 도구를 각각 사용해야 했다. 소개되는 XDE와 TCC는 이들 개발 과정을 하나의 개발 환경에 포함시키고 있다. 즉, CASE 도구를 벗어나지 않으면서 분석-설계 작업뿐만 아니라 구현을 할 수 있고, 구현을 디버깅해볼 수 있으며, 배포 및 테스팅까지의 작업을 수행할 수 있다.
객체지향 도구 신기술 지원
XDE와 TCC는 개념이 소개된 지는 10여년이 되었으나 CASE 도구의 지원 기능으로 포함되지 못했던 설계 및 구현 과정에서의 디자인 패턴 사용을 지원하고 있다. 과거의 도구에서는 객체지향 디자인 패턴은 소프트웨어 개발 과정 중 객체지향 설계 및 구현 과정에서의 반복적인 문제들에 대한 검증된 해결책을 카탈로그 형태로 제공하는 일종의 지식 베이스 또는 지식 자산이라고 볼 수 있다(이와 같이 패턴화된 지식은 여러 소프트웨어 개발 과정에서 축적될 수 있고, 설계 과정 외의 다른 공정에서도 요구 패턴, 프로세스 패턴, 테스트 패턴 등이 제안되어 왔다).
잘 알려진 패턴으로, 객체지향 설계 과정에서 자주 발생될 수 있는 재사용성 및 유지보수성에 관련된 여러 문제들과 해결책을 카탈로그화한 GoF 디자인 패턴이나 J2EE 기반 응용 프로그램 작성시 발생될 수 있는 확장성, 가용성 및 성능에 관련된 문제들과 해결책을 정리한 J2EE 패턴이 있다. 이 두 패턴은 두 도구에서 공통적으로 지원하고 있다.
설계 패턴의 적용은 기존의 설계 모델에 패턴화된 코드 구조를 반영하는 방식으로 이뤄진다. 예를 들어, 클래스를 빈(Bean) 컴포넌트로 변환하는 것도 일종의 패턴화된 코드이며, 빈이 되기 위해 필요한 홈 인터페이스, 리모드 인터페이스를 생성하고, 해당 클래스에 활성화 및 비활성화 등에 관련된 빈 관련 메쏘드를 추가하는 등의 과정을 통해 클래스가 빈 컴포넌트로 변환되게 된다.
CASE 도구가 디자인 패턴을 지원함으로써 이미 정의되고 검증된 패턴들을 적용할 수 있고 패턴 구현 코드를 재사용할 수 있게 하여 개발 생산성을 높일 수 있다. 두 도구는 디자인 패턴 적용 과정을 자동화하는 기능과 패턴 지식 베이스에 개발 과정에서 새로 발견된 디자인 패턴을 추가하는 기능을 탑재하고 있다.
<화면 1>은 XDE에서 Observer 패턴을 설계 모델에 적용하기 위한 다이얼로그로, 현재 Observer 패턴의 참여 클래스 중 ConcreteSubject에 해당하는 클래스 이름을 다이얼로그를 통해 지정하는 작업을 보여주고 있다. 디자인 패턴의 적용 대상 클래스를 현재 설계 모델로부터 선택할 수 있도록 모델 구성요소를 보여주고 있다.
현재는 ClockTimer 클래스가 ConcreteSubject 클래스로 사용된다. <화면 2>는 디자인 패턴 탐색기로 디자인 패턴을 새로 정의하거나 패턴이 적용되었을 때 수행될 정보를 기술하고 있다. Observer 패턴의 내용을 보면, ConcreteSubject에 해당하는 클래스는 Subject 해당 클래스를 상속받고 Object 해당 클래스를 사용하며, getState, setState 오퍼레이션을 가짐을 알 수 있다.
즉, 앞에서 ClockTimer 클래스는 Observer 패턴이 적용됐을 때 Subject로 설정된 클래스와 상속 관계를 가지고 Object에 해당하는 클래스를 소스코드에서 임포트하며 getState, setState 메소드가 자동 생성된다.
라운드 트립 공학
라운드 트립 공학(RTE)은 순환공학이라고도 불리운다. 설계 모델 작성시 구현 코드를 통해 작업의 결과를 볼 수 있고, 구현 코드 변경시 설계 모델로 즉시 반영되는 것을 의미한다. 기존의 CASE 도구에서는 설계자가 설계 모델을 작성하고 이에 해당하는 구현 코드가 생성되면, 이를 기반으로 구현자가 코드를 채워나가는 방식을 지원했다.
하지만, 설계 과정에서 설계자가 구현 결과의 상세한 부분까지 고려하는 것이 어렵고, 구현 과정에서 구현자가 설계자의 의도를 정확하게 이해하는 것이 힘들기 때문에, 이전에 작성된 설계 모델과 구현 결과물과는 불일치하기 마련이다.
구현 완료 후 설계 모델과의 비교, 검토를 통해 서로를 일치시켜야 했고, 그렇지 못하면 설계 모델은 더 이상 소프트웨어를 표현하는 문서로서의 기능을 수행하지 못한다. 또한 구현 완료 후 새로운 요구사항을 반영해야 한다든가, 새로운 개발자가 소프트웨어를 이해하려고 하는 경우에 설계 모델이 이러한 작업에 도움을 줄 수 없게 된다.
순환공학은 설계 모델을 작성하고 이를 프로그램 코드로 변환하는 순공학(Forward Engineering)적 측면과 프로그램 코드로부터 설계 모델을 추출하는 역공학(Reverse Engineering)적인 측면을 모두 포함하고, 설계 모델과 구현 코드가 서로 동기화되어 변환과 추출이 즉시적으로 수행된다.
이러한 기능은 프로그래머가 코드를 작성하는 과정에서 바로 바로 모델 정보로 반영되어 코드의 의미를 설계 관점에서 즉시 살펴볼 수 있다는 점에서 획기적이라고 할 수 있다. 설계 모델과 구현 코드가 동기화되지 못한 경우, 대부분 설계 모델은 소프트웨어를 이해하는 데 도움을 주는 문서가 되기보다는 단순히 소프트웨어에 대한 철 지난 문서로서의 기능만을 가지게 된다.
또한, 코드에 따라 설계 모델을 갱신하는 것은 프로젝트 진행의 부담으로 남게 된다. RTE 기능은 이러한 문제를 도구 차원에서 해결한 것이라고 볼 수 있다.
물론, 구현 코드 모두가 설계 모델과 동기화되지는 않는다. 크게 클래스 다이어그램으로 표현되는 구조적인 측면과 시퀀스 다이어그램에 표현되는 일부 행위적인 측면이 동기화될 수 있다.
이는 코드가 설계 모델보다 많은 정보를 가지기 때문이다. 예를 들어, 코드 상에 메쏘드 정의 내에 있는 반복문이나 지정문과 같은 세부 구현 내용들은 설계 모델에 반영될 이유도 없고 반영되지도 않는다(설계 단계에서 고려돼야 하는 정보는 구현 단계의 정보보다 높은 추상성을 가져야 한다.
구현자는 하나의 클래스에 대해 작업하지만, 설계자는 시스템을 구성하는 모든 클래스를 한 눈에 볼 수 있어야 하기 때문이다). 하지만 구현자는 구현 코드만을 보고 코딩하는 것이 아니기 때문에, 설계적인 부분에 대해 공부해야 한다. 클래스 다이어그램에 기술된 설계 모델을 보면서 다른 클래스들과의 관계와 현재 구현하는 클래스의 책임이 무엇인지를 파악하고 이를 에디터를 통해 작성해야 한다.
개발 프로세스 및 개발 지원 기능
CASE 도구가 아무리 많은 기능을 제공한다 하더라도 이를 어떻게 적절하게 사용하는 가가 더 중요한 문제다. 실제로 CASE 도구로 여러 관점을 모델링한다 하더라도 소프트웨어 개발 전 공정에서 각 산출물이 어떻게 사용되고 변경되는가에 대한 계획이 없다면, 모델을 작성하기 위한 노력이 허비될 수밖에 없다(모델의 의미를 모른 채 쓸모없는 모델을 작성해 다시 보지 않을 불필요한 설계 모델을 작성할 수 있다).
UML은 소프트웨어를 보는 여러 관점을 다이어그램 형태로 제공하기 위한 언어를 제공하고 있고, CASE 도구는 이 언어를 잘 표현할 수 있도록 제공하는 도구이며, 이 언어 및 도구를 소프트웨어 개발 과정에서 어떻게 사용하는 가에 대한 원칙이나 가이드라인을 포함한 로드맵을 제시하는 것이 개발 프로세스이다.
많은 객체지향 소프트웨어 개발을 위한 프로세스가 존재한다. 예를 들어, Use Case Driven 방법론이나, RUP, 마르미 등이 있다. 특히, 최근에는 RUP를 J2EE 응용 프로그램 개발의 특수성을 고려하여 커스터마이즈한 개발 프로세스를 기술하고 있는 책(Peter Eeles, Kelli Houston, Wojtek Kozaczynski, Buliding J2EE Applications with the Rational Unified Process, Addison-Wesley, 2003)이 소개됐다.
실제 RUP는 2～3년 정도가 걸리는 대규모 프로젝트를 위한 것이라는 비판이 있지만, 특정 플랫폼에서 이뤄지는 소프트웨어 개발을 위해 불필요한 부분을 제외한 핵심적 프로세스를 기술할 수 있다.
개발 공정은 설계 및 구현 공정 외에 여러 공정들이 있다. 예를 들어, 요구사항 분석, 테스팅, 유지보수 등의 공정이 있다. 또한, 문서화 작업이나 소프트웨어 품질 측정 작업과 같은 여러 개발 지원 작업들이 있다. CASE 도구는 이러한 공정 및 작업들을 역시 지원할 수 있어야 한다.
<화면 3>은 TCC를 사용하여 메트릭을 측정한 결과를 그래프로 보여주고 있다. 오른쪽 그래프는 CashSale이라는 클래스에 대한 여러 메트릭 값을 Kiviat 그래프로 보여주고 있다. 원 안으로 들어온 메트릭은 임계치 안으로 들어온 것을 말한다.
예를 들어, CashSale 클래스가 다른 클래스들과 얼마나 복잡하게 얽혀있는 가를 나타내는 CBO(Coupling Between Objects) 값은 정해진 임계치 안으로 들어와 있으므로 녹색 점으로 표시되고 전체 복잡도에 그다지 큰 영향을 미치지 않음을 알 수 있다. 왼쪽의 바 그래프는 특정 패키지 내에 있는 클래스의 McCabe Cyclomatic 복잡도를 표시하고 있다. 클래스 내에 분기문이 얼마나 많은가를 통해 소프트웨어가 얼마나 복잡한가를 보여준다.
<화면 3> TCC를 사용해 메트릭을 측정한 결과
XDE와 TCC 도구 비교
XDE는 래쇼날 로즈 모듈이 MS 비주얼 스튜디오 닷넷 환경과 IBM의 Websphere Studio Workbench(이하 WSW)/Websphere Studio Application Developer(이하 WSAD) 환경에 내장되어 있는 통합 환경 에디션과 본 기사에서 다루는 XDE for Java 에디션이 있다(<화면 4>). TCC와 마찬가지로 XDE 역시 모델링 도구를 개발 환경에 내장함으로써 요구사항 분석에서부터 설계, 개발, 테스트 및 배포의 소프트웨어 전 개발 공정이 하나의 단일화된 작업 환경에서 이뤄지도록 해 준다.
이를 통해 서로 다른 도구를 사용함으로 발생할 수 있는 번거로움을 줄일 수 있을 뿐만 아니라 분석가나 설계자, 개발자 상호간의 의사소통을 보다 원활하게 하고, 더불어 소프트웨어 개발 전 공정의 문서화를 지원할 수 있는 도구라고 할 수 있다. 본 기사에서는 J2EE를 중심으로 기능들을 살펴보기 때문에, 소개되는 XDE는 이클립스 IDE를 기반으로 하는 일반 자바 응용프로그램 개발 지원 에디션이다.
XDE은 닷넷에 대해 별도의 에디션을 제공하여, 비주얼스튜디오 닷넷 개발환경에서 XDE의 기능을 수행할 수 있게 했다.
<화면 4> XDE 화면
TCC는 비주얼 모델링과 통합 개발 환경을 동시에 제공하는 툴로 최근 투게더 소프트웨어가 볼랜드에 인수되면서 보다 공격적인 마케팅 전략을 구사해 시장에서 주목받고 있는 제품이다(<화면 5>).
앞서 이미 언급했듯 TCC는 분석, 설계, 개발 및 배치 그리고 테스트까지를 동일한 환경에서 지원함으로써 시스템 분석가, 설계자, 개발자 모두를 만족시킬 수 있다. 또한 분석, 설계 단계에서의 모델과 개발 단계 소스와의 순공학&역공학을 완벽하게 지원함으로써 보다 쉽게 분석, 설계 단계의 산출물과 개발된 소스와의 일관성을 유지할 수 있다. 따라서, 산출물을 위한 별도의 불필요한 작업을 줄여줄 뿐 아니라 소프트웨어 품질 향상을 가능하도록 한다.
<화면 5> TCC 화면
기능 비교
두 도구 모두 UML 1.3에서 지원되는 대부분의 다이어그램(클래스 다이어그램, 유스 케이스 다이어그램, 시퀀스 다이어그램, 상태 다이어그램, 컴포넌트 다이어그램, 배치 다이어그램 등)을 작성할 수 있는 기능을 가지고 있다. J2EE 플랫폼에서는 프리젠테이션을 위해 JSP, 서블릿으로 작성된 웹 응용 프로그램 개발을 필요로 한다.
따라서 JSP 및 서블릿을 CASE 도구 상에 표현할 수 있어야 한다. 두 도구 모두 이러한 표현 방법을 제공하고 있다. 또한, 웹 응용 프로그램 파일(war) 및 EJB 어셈블리(ear)와 같은 배치 관점의 모델 요소들을 표현할 수 있다.
XDE는 여러 프로젝트 및 모델을 동시에 작업할 수 있도록 해주며, 다이어그램 상에 다양한 스테레오 타입 아이콘을 정의하여 사용할 수 있다. TCC는 기본적으로 개별 프로젝트 단위의 개발을 지원하고, 개발 도구적인 특성이 많이 포함되어 자바 응용 프로그램의 윈도우 설계와 같은 UI 작성 기능을 포함하고 있다.
시장에는 여러 J2EE 개발 도구들이 나와 있고 J2EE 기반 응용 프로그램을 개발, 테스팅, 디버깅, 배치하기 위한 기능을 제공하고 있다. XDE와 TCC는 이러한 J2EE 개발 환경과 연동하기 위해 JSP, 서블릿, EJB와 같은 인터넷 엔터프라이즈 응용 프로그램 개발, 테스팅 및 디버깅 기능, 데이터베이스 모델링 및 엔티티 빈과의 맵핑, JSP 및 서블릿과 같은 웹 응용 프로그램과 EJB 응용 프로그램 등을 배치할 수 있는 기능 등을 포함하고 있다.
XDE는 IBM의 웹스피어 개발도구 및 닷넷 개발도구 등을 위한 에디션을 제공하고 있으며, TCC의 경우 J빌더 및 웹스피어를 위한 TCC 에디션을 제공하고 있다. CASE 도구 내에서 코드 구현 및 빌드 작업을 제공하기 위해, XDE는 자바 개발도구로 대중적으로 사용되는 이클립스를 기반으로 한 개발 IDE를 포함하고 있고, TCC도 자체적인 개발 IDE를 제공한다. XDE와 TCC 모두 IBM 웹스피어 응용 프로그램 서버, BEA 웹로직 서버, SUN J2EE 서버로의 배포가 가능하다. TCC의 경우, JBoss와 같은 서버로도 배포 가능하다.
XDE은 엔터프라이즈 응용 프로그램 개발 기술의 또 하나의 축인 MS 닷넷에 대해 별도의 에디션을 제공해 비주얼스튜디오 닷넷 개발 환경에서 XDE의 기능을 수행할 수 있게 하였다. 또한, 닷넷용 디자인 패턴 지원이나 C#, VB.NET, ASP.NET등의 언어 및 프로젝트 템플릿 지원과 같이 닷넷만을 기능들을 지원하고 있다.
XDE, TCC 모두 설계와 구현을 동시에 수행할 수 있는 모델-코드 동기화 기능과 기존 코드로부터 모델 정보를 추출하는 역공학 기능을 제공하고 있다.
XDE는 동기화의 적용 여부를 수동 및 자동으로 지정할 수 있도록 하여, 구현 과정 동안 모델의 변경을 막아둘 수 있다. 이는 설계 과정과 구현 과정에서의 작업의 성격이 다르므로, 각 과정에서의 결정 사항을 리뷰할 수 있도록 수동 동기화 기능을 지원하는 것이라고 볼 수 있다.
TCC는 프로그램 코드로부터 시퀀스 다이어그램을 추출할 수 있는 기능을 탑재하고 있다. 시퀀스 다이어그램은 객체간의 메시지 전달을 표현하기 위한 다이어그램이며, 이를 추출하기 위해서는 메쏘드 블럭 내부의 문장들을 처리해야 한다.
시퀀스 다이어그램은 원래 수행 시점에서의 중요한 시스템 행위를 서로 상호 작용하는 객체들의 메시지 전달 관계를 표현하기 위해 작성되나, 모든 시스템의 행위를 시퀀스 다이어그램으로 표현하는 것은 간단한 시스템이 아닌 경우 불가능하다.
하지만, 하나의 클래스 내에서 추출된 시퀀스 다이어그램이 시스템 내의 여러 클래스간의 연동을 표현해야 하는 설계 작업에 실제적인 도움을 줄 수 있는 지는 의문이다.
두 도구 모두 검증된 설계 패턴들인 GoF의 디자인 패턴들과 J2EE 패턴들을 제공하고 있다. 또한, 설계 패턴 베이스의 확장 기능을 제공하고 있다. XDE는 설계 모델 관점에서 새로운 디자인 패턴을 정의할 수 있는 다이얼로그를 제공해 보다 쉽게 접근할 수 있고, TCC는 코드 기반으로 패턴 템플릿을 정의하기 때문에, 디자인 패턴을 정의하기 위해서는 패턴 정의를 위한 설계 및 구현에 관련된 지식이 더 필요하다.
XDE는 분석 모델, 설계 모델과 같이 추상 수준이 다른 여러 모델들을 동시에 열어 작업할 수 있고 모델 간의 추적성을 부여할 수 있어, 개발 진행 단계별 모델 사이의 연결 관계를 관리할 수 있다. 예를 들어, 사용자 요구사항의 특정 항목이 분석/설계 단계에서 어떻게 반영되고, 구현의 어떤 부분과 연결되는 지를 표시하는 것은 요구 사항 변경 처리나 재사용 측면에서 매우 중요한 부분이다.
또한, 여러 개의 프로젝트를 동시에 관리할 수 있는 기능을 제공함으로써 프로젝트간 공통 모델을 공유 가능해 조직 차원에서의 효과적인 소프트웨어 재사용 관점을 부여한다.
XDE는 RUP를 개발 도구에 포함시키고 있다. 개발 프로세스는 개발 도구의 여러 기능들을 어떻게 사용하는 가를 기술하기 때문에, 개발 프로세스의 각 작업에 대한 도구 지원이 더 직관적이고 자연스러울 수 있다. TCC는 도구 차원에서 가정하고 있는 별도의 개발 프로세스는 없지만, 개발을 위한 모든 작업에 맞춰 적절히 사용될 수 있다.
개발 지원 기능으로 작성된 여러 다이어그램을 문서화시켜 주는 것이 필요하다. XDE의 경우 Javadoc 및 사용자 정의 태그 및 값을 사용해 모델과 코드에 대한 문서 자동화 기능을 제공하고, TCC는 HTML 외에 RTF, PDF와 같은 다양한 형식의 문서를 모델로부터 자동생성할 수 있으며, 문서 템플릿을 작성할 수 있도록 문서 커스터마이징을 위한 다이얼로그를 제공한다.
XDE와 TCC 모두 다중 사용자가 하나의 모델에 대해 병렬적으로 작업할 수 있는 기능을 제공하며, 산출물의 버전을 별도로 관리하기 위해 형상 관리 도구와 연동할 수 있는 기능을 탑재하고 있다. XDE는 개발 공정에서 작성된 여러 모델을 병렬적으로 관리할 수 있도록 각 모델을 별도의 파일로 분리할 수 있는 기능을 제공한다.
또한, 여러 프로젝트를 동시에 작업할 수 있어 조직 차원에서 개발 공정을 관리할 수 있다. XDE와 TCC 모두 래쇼날 클리어케이스를 기본적으로 지원하며, TCC는 CVS나 SCCS 호환 도구와 연동 가능하다.
TCC는 소프트웨어의 품질 보증을 위한 기능을 제공하고 있다. 코딩 표준 및 지침에 대한 준수 여부 등을 체크할 수 있도록 해주는 감사 기능과 코드의 복잡도를 측정하는 메트릭 지원 기능을 가지고 있다.
메트릭에 기반해 소프트웨어의 잘못된 구조를 파악하고 프로그램 소스를 리팩토링(일반적으로 리팩토링은 프로그램 코드에서 메쏘드의 삭제, 변수 이름의 변경 등을 위한 프로그램의 행위 보존 원칙을 말한다. 예를 들어, 어떤 변수의 이름을 변경하면 이 변수를 사용하는 모든 문장에서의 이름도 역시 변경돼야 한다).을 수행함으로써 코드의 품질을 높일 수 있는 방법을 제공한다.
개발자 중심의 개발 및 설계 지원
지금까지 최근의 소프트웨어 개발 경향인 컴포넌트 기반 응용 프로그램 개발을 위한 인터넷 엔터프라이즈 응용 프로그램 개발 지원 기능, 객체지향 도구지원 신기술, 개발 지원 기능을 중심으로 두 도구를 살펴봤다. 두 도구가 정도의 차이가 있지만, 기존의 CASE 도구와는 달리 개발자 즉, 구현자를 중심으로 기능을 제공하고 있다.
이러한 이유는 시장을 선점하기 위해 소프트웨어 개발 시간이 날로 촉박해지고, 다양한 요구를 반영하기 위해 요구사항의 변경이 수시로 일어나는 현재의 소프트웨어 개발의 환경에서 개발자의 역할이 보다 강조되기 때문일 것이다.
하지만, 이러한 도구를 사용할 때 주의해야 할 점이 있다. 구현 도구와 개발 도구가 통합되고, 소스 코드를 중심으로 소프트웨어를 바라볼 수 있게 되었지만, 소프트웨어 개발이 구현 코드 중심으로만 이뤄지지 않는다는 점이다.
소프트웨어를 바라보는 입장은 이해 관계에 따라 고객, 프로젝트 관리자, 개발자, 품질 보증 담당자, 아키텍트, 하드웨어 구매 담당자 등 여러 역할을 가진 사람들이 있다. 소프트웨어는 이러한 여러 이해 당사자들의 요구들이 적절하게 타협되고 반영돼야 성공할 수 있다.
CASE 도구는 이러한 요구들을 표현할 수 있는 다이어그램을 작성해 소프트웨어를 다각도로 분석할 수 있는 모델을 작성할 수 있도록 해준다. 이상적인 경우라면, 작성된 다이어그램을 코드 생성을 통해 소프트웨어를 작성할 수 있는 기능을 제공해야 하겠지만, 기능적인 측면이 아닌 성능, 신뢰도, 가용성, 보안 등의 요소는 프로그램 코드와 일대일로 맵핑이 어렵다.
이러한 요소는 분석, 설계 과정을 통해 소프트웨어가 가져야 하는 다양한 측면들을 살펴보는 과정에서 식별되어 진다. 하지만, 개발자가 이러한 과정 없이 바로 구현 코드로 접근하게 되면 개발 과정에서 많은 문제 상황에 부딪힐 것이다. 개발자 중심의 분석 및 설계 지원 CASE 도구의 출현은 분명 획기적인 발전이라고 할 수 있지만, 소프트웨어 개발이 바로 코드로부터 시작되지 않는다는 점에 유의해야 한다.
최신 기술은 분명 소프트웨어 개발을 보다 체계적이고 효율적으로 지원하지만, 기술을 배워야 하고 이를 실현해야 하는 입장에서는 그리 달가운 일이 아닐지 모른다.
J2EE 기술에 능숙한 사람은 객체지향 분석 설계에 대한 지식을 갖고 있을 것이라고 기대되지만, 소개된 두 CASE 도구를 잘 사용하기 위해서는 자바 구현 및 J2EE 플랫폼에 대한 지식, 객체지향 분석 및 설계 지식을 갖고 있어야 한다. 또한, 설계 모델의 구현 코드로의 맵핑 관계에 대해 잘 알고 있어야 할 것이다.
하지만 하나의 도구를 통해 J2EE 응용 프로그램을 분석, 설계, 구현, 배치, 디버깅, 테스팅까지 수행할 수 있다는 것은 개발자들에게 개발 공정의 연속성을 부여할 수 있는 장점을 가진다. 더우기 이러한 통합이 단순히 여러 기능을 끌어 모은 것이 아니라 서로 동기화되어 하나의 소프트웨어를 표현할 수 있다는 점이 중요하다.
여기에 형상 관리 및 품질 보증, 문서화 등의 개발 지원 공정까지를 한 도구에서 지원하게 됨으로써 소프트웨어 개발을 보다 체계적이고 일관되게 관리할 수 있다. 개발자들이 공부해야 하는 것이 더 많아졌지만, 소프트웨어를 전체적으로 바라보고 자신이 작업하는 부분이 어떻게 맞춰 들어가는 지에 대한 관점을 가지게 되었다는 데 의의를 두고 싶다.@
