누니의 정보창고

액터, 유즈케이스 만들기

2 .0 유즈케이스 다이어그램 만들기

액터 만들기

유 즈케이스 다이어그램 작성을 위해서 간단한 예제 시나리오를 생각해보도록 하죠. 간단한 예로 수강신청 시스템 개발을 위한 모델링을 생각해 봅시다. 우선 수강신청 시스템의 액터로 학생(Student), 교수(Professor), 수강신청 시스템 관리자(Registrar) 및 수업료 청구 시스템(Billing System) 등을 생각해볼 수 있습니다.

[새 액터 만들기]

왼쪽 상단의 브라우저의 Use Case View에 커서를 놓고 오른쪽 마우스를 클릭하고 New를 선택하면 Actor를 생성할 수 있습니다.

[액터]

문서화를 위해서나 의사소통 도구로 사용하기 위해서 각 액터에 대한 설명을 기술할 수 있습니다. 앞에 작성했던 Use Case View를 보여주는 브라우저 아래 문서창이 있습니다. 설명을 기술할 액터를 선택하고 아래 문서창에서 설명을 입력하면 됩니다. 또 다른 방법으로는 액터를 더블클릭해서 문서화 텍스트 영역에 설명을 기술할 수도 있습니다.

[액터에 관한 설명 기술]

유즈케이스 만들기

이번에는 유즈케이스들을 작성해 보죠. 유즈케이스들은 어떤 것들이 있을까요? 우선 기본적인 유즈케이스들만 뽑아서 모델을 작성해 봅시다. 우선 성적 관리 시스템의 기초가 될 수강에 관한 정보는 공유하는 마스터 데이터베이스를 이용한다고 가정합시다. 그러한 자료를 토대로 교수가 성적을 입력하고, 학생들이 이를 열람하게 됩니다. 주요 유즈케이스들은 다음과 같습니다.

• 수강할 강좌를 신청하다.(Register for courses)
  
• 강의할 강좌를 선택하다. (Select courses to teach)
  
• 강좌의 수강 학생 명단을 요청하다. (Request course roster)
  
• 강좌 정보를 관리하다. (Maintain course information)
  
• 교수 정보를 관리하다. (Maintain professor information)
  
• 학생 정보를 관리하다. (Maintain student information)
  
• 강좌 시간표를 생성하다. (Create course catalog)

[새 Use Case 만들기]

유즈케이스에 대한 설명은 액터와 동일하게 기술할 수 있습니다. 이제 유즈케이스 다이어그램을 그려봅시다. 우선 기본이 되는 Main 유즈케이스 다이어그램을 만들어야 합니다. 액터와 유즈케이스를 드래그 앤 드롭해서 오른쪽에 배치합니다. 오른쪽은 다이어그램을 편집할 수 있는 창입니다.

1 .0 액터, 유즈케이스 만들기

0 유즈케이스 다이어그램 만들기

관계 맺기

액 터와 유즈케이스를 적절히 배치했으면, 관계를 맺어 줍니다. 편집 창의 왼편에는 도구들의 아이콘이 있습니다. 꺾인 직선으로 표시된 Unidirectional Association 아이콘을 클릭하고, 액터와 유즈케이스 사이에서 드래그하면 연관 관계를 나타내는 직선이 나타납니다. 연관 관계에 대한 설명 역시 액터와 유즈케이스에서와 동일합니다. 연관을 나타내는 직선을 더블클릭하면 연관에 대한 설명은 물론 연관의 이름과 스테레오타입 등을 정해줄 수 있습니다.

[Use Case Diagram]

유즈케이스 다이어그램 만들기

Main 유즈케이스 뿐 아니라 각 액터의 관점에 따라 유즈케이스 다이어그램을 그릴 수도 있습니다. 또한 액터와 유즈케이스가 많아지면 유즈케이스 다이어그램이 복잡해지므로 이를 보기 좋게 나누기 위해서 많은 유즈케이스 다이어그램을 그릴 수도 있습니다. 여기서는 교수의 관점에서 표현되는 유즈케이스를 나타내어 보겠습니다. 새로운 Use Case View를 만들기 위해서는 Use Case View에 커서를 놓고 오른쪽 마우스를 클릭하고 New – Use Case Diagram 순으로 선택하면 새로운 유즈케이스 다이어그램을 작성할 수 있습니다.

[새로운 Use Case View]

시스템을 이용하는 모든 사용자는 인증을 거쳐서 시스템에 접근한다고 합시다. 그러면, 사용자 인증이라는 유즈케이스가 필요합니다. 이는 모든 유즈케이스에 선행하므로 각각의 유즈케이스에 사용자 인증을 삽입하는 것 보다는 포함 혹은 사용 관계를 이용하는 것이 좋겠죠. Rose에서 이를 표기하기 위해서는 우선 유즈케이스간의 관계를 나타내는 선을 더블클릭 합니다. Association Specification 대화상자가 나타나는데 stereotype 리스트에서 include를 선택합니다. 어떤 UML 작성도구를 쓰느냐에 따라서, Rational Rose를 사용하더라도 버전에 따라서 약간은 작성방법이 달라집니다.

지금까지 유즈케이스에 대해서 간단히 살펴보고, 예제를 통해서 유즈케이스 모델을 다이어그램으로 작성하는 것을 배웠습니다. 강좌를 진행하면서 많은 경우 용어로 사용되는 원어들은 굳이 번역하지 않고 그대로 표기하도록 하겠습니다. 번역하여 사용할 경우 이해에 도움을 줄 수 있지만, 아직 UML을 지원하는 소프트웨어가 한글 버전이 흔치 않고, 또한 원어를 익혀 두는 것이 도움이 될 것 같습니다.

RUP (Rational Unified Process)

2 .0 유즈케이스, 액터, 관계

지 난 시간에는 UML의 필요성과 간단한 개념을 살펴보았습니다. 이번 시간부터는 UML을 구성하는 각종 다이어그램들을 하나씩 살펴 봅시다. 또한 깊은 이해와 함께 몸으로 익힐 수 있도록 UML 모델링 도구로 가장 유명한 Rational Rose를 이용하여 간단한 실습을 해보도록 하죠. 실습을 위한 소프트웨어는 UML 관련 책자의 부록이나 Rational 사의 웹사이트를 통해 평가판을 구하실 수 있습니다. 평가판을 다운로드 할 수 있는 웹 페이지의 URL은 다음과 같습니다.

http://www.rational.com/tryit/rose/index.jsp

본 내용을 진행하기에 앞서 다음의 서적들을 참고로 이 글을 작성했음을 밝힙니다. 더 깊은 이해를 위해서는 이들 서적을 참고하세요.

• Visual Modeling with Rational Rose and UML, Terry Quatrani, Addison Wesley
  
• UML Distilled Second Edition, Martin Fowler with Kendall Scott, Addison Wesley
  
• 초보자를 위한 UML, Joseph Schmuller, 곽용재 역, 인포북
  
• The Rational Unified Process An Introduction Second Edition, Philippe Kruchten
  
• The Unified Modeling Language Reference Manual, James Rumbaugh, Ivar Jacobson, Grady Booch, Addison Wesley

예제 화면은 rose2001A.04.00 버전을 기준으로 사용했습니다. 다른 버전을 사용하시더라도 UML을 배우는 입장에서 큰 차이는 없을 것입니다. 예제 내용은 일반적이고 검증된 것을 사용하고자 Visual Modeling with Rational Rose and UML의 예제를 인용했습니다. UML 구성 요소들의 이름을 한글로 사용할 수 있지만, 코드와의 일관성 유지 등의 목적으로 영어를 사용했습니다. 다만, 한글로 충분히 설명을 기술하도록 하겠습니다.

RUP (Rational Unified Process)

유즈케이스(Use Case)에 대해 본격적으로 설명하기에 앞서 RUP에 대한 언급을 하지 않을 수가 없습니다. UML은 모델링을 위한 표기법입니다. UML이 시스템 개발에 매우 중요하다 하겠지만, UML만으로는 아무 것도 되지 않습니다. 객체 지향으로 시스템 개발을 하겠다고 UML을 사용하면서 개발은 기존의 전통적인 방식을 따른다면 효과가 높지 않을 것입니다.

객체 지향의 시스템 개발을 하려고 한다면 개발의 방법론 역시 객체 지향을 따라야 할 것입니다. 수많은 객체 지향 방법론이 존재한다고 합니다. 이 중에 가장 부각되고 있는 것이 RUP입니다. 무엇보다 RUP는 Rational의 소프트웨어군을 이용한 개발 방법론으로서 이론 뿐만 아니라 구체적인 솔루션이 동반된다는 강점을 지니고 있습니다.

쉽게 얘기하면 Rational의 도구들과 RUP에 맞춰서 UML을 사용하여 개발 한다면 삼박자를 갖추게 된다는 매력적인 제안이죠. 우리는 RUP를 배우는 게 아니고 UML을 배우는 것이지만, 시스템을 개발하는 과정을 염두에 두지 않고 UML을 논하는 것은 공허할 수 있습니다. UML이 어떻게 쓰이는지를 생각하지 않겠다는 것이 될 수 있으니까요.

RUP가 최상의 개발 방법론은 아니지만, 개발 공정에 대한 한 예로 RUP를 간단하게 엿보도록 하죠.

다음은 RUP의 개발 공정에 대한 개괄적 그림입니다.

[RUP 개발 공정]

RUP의 개발 공정은 크게 두 축으로 나눠 볼 수 있습니다. 우선 그림의 가로축으로 시간의 흐름에 따른 네 가지 단계(Phases)로 구분할 수 있고, 세로축의 9가지 웍플로우(Workflow)로 나눌 수 있습니다. 웍플로우는 컴포넌트처럼 작업의 성격에 따라 일을 분리한 것입니다.

기존의 방법론이 도입기에는 주로 타당성 검증 등을 하고, 분석 및 설계, 구현, 검증 및 배포와 같은 식으로 일원적인 관점에서 개발을 했다면 RUP는 이차원적인 관점을 갖는다고 하겠습니다. 도입기라고 할 수 있는 도입(Inception) 단계에서는 주로 비즈니스 모델링(Business Modeling)을 수행하지만 이를 위해 상당량의 요구사항 분석을 수행해야 하고, 개발 프로젝트의 타당성이나 위험도 등의 검증을 위해 프로토타입을 만들어 본다든가 하는 구현도 일부분 수행하게 됩니다. 마찬가지로 향후 프로젝트를 정교하게 발전시켜가는 정련(Elaboration) 단계에서도 요구사항 수집과 분석 설계는 물론 도입 단계에서 만들어진 비즈니스 모델링(Business Modeling)을 검증하고 더욱 정교하게 수정하는 일도 계속하게 됩니다. RUP는 이와 같은 식으로 점진적인 개발 방법을 채택하고 있습니다. 이러한 단계들과 웍플로우의 적절한 조합은 두말할 필요 없이 매우 중요하다고 하겠죠. 프로젝트 관리자에 의해서 이러한 적절한 조합이 계획되는데 이를 이터레이션(Iteration)이라고 합니다. 결국 RUP는 이터레이션의 연속으로 개발을 수행하게 되는 것이죠.

유즈케이스 이해하기

이제야 본격적으로 유즈케이스를 얘기할 차례군요. 유즈케이스는 우리말로는 쓰임새라고도 합니다. 두 가지를 동시에 사용하는 혼돈을 막기 위해서 여기서는 원어로 유즈케이스라고 표기하는 것을 원칙으로 하겠습니다.

유즈케이스라 함은 말 그대로 ‘쓰이는 경우’라던가 ‘용도’ 같은 의미로 받아들여도 큰 무리가 없다고 보여집니다. 어떤 일에 쓰느냐 하는 것이죠. 시스템이 쓰여지는 용도를 모아서 시스템을 만들어낸다면 다용도 시스템이 만들어지겠죠. 유즈케이스들을 모아서 시스템으로 매핑시키는 것을 개발 과정의 간단한 정의로 보아도 무리가 없을 만큼 유즈케이스는 가치 있는 것입니다.

제가 한국 Rational 이사님의 세미나를 들은 일이 있습니다. 그때 UML에 관한 부분에서는 유즈케이스를 유난히 강조하시더군요. 유즈케이스는 사용자 시각에 맞춘 분석입니다. 어떤 시스템을 만드느냐를 사용자 입장에서 조명하는 것이죠. 최근 비즈니스가 발전함에 따라 고객 지향 마인드가 널리 퍼져 있습니다. 당연한 결과라 하겠죠. 마찬가지로 시스템 개발에 있어서도 고객 관점에서 바라보는 시각이 부각되는 것은 당연한 일이라 하겠습니다.

객체 지향 개발 자체가 기존 개발 방법들에 비해 상당히 인간위주의 개발 방법론이라는 느낌이 드는데 유즈케이스는 이러한 휴머니즘의 선봉에 서있다고 해도 큰 비약은 아니라는 생각이 듭니다. 아무튼 유즈케이스는 시스템 보다는 그것을 사용하는 인간, 즉 사용자의 입장을 우선해서 시스템이 어때야 하는가를 알아보는 것입니다. 아무리 잘 만든 시스템도 인간에게 가치를 주지 못하면 무의미한 것이죠.

이러한 휴머니즘을 잊지 마시고, 유즈케이스를 배워 봅시다. 유즈케이스는 시스템의 행위를 결정하는 것입니다. 구체적으로는 시스템의 기능을 정의하고, 범위를 결정함으로써 시스템과 외부 환경 변수를 구분하고, 상호 관계를 정립하는 것이라고 볼 수 있습니다.

개발 공정과 연관해서 보면 도입 단계에서 주요 유즈케이스를 뽑아 내고, 차츰 이를 정련하게 됩니다.

유즈케이스를 나타내는 유즈케이스 모델(Use case Model)은 유즈케이스 다이어그램으로 표현됩니다. 유즈케이스 다이어그램은 액터(Actor, 행위자)와 유즈케이스, 그리고 관계(Relationship)로 나타냅니다.

1 .0 RUP (Rational Unified Process)

0 유즈케이스, 액터, 관계

액터(Actors)

액 터는 시스템의 일부가 아닙니다. 액터는 시스템과 상호작용을 하는 모든 것들을 나타냅니다. 시스템을 사용하게 될 사람은 물론이고, 연관된 다른 시스템도 액터입니다. 대체로 액터의 행위는 정보의 입력과 출력으로 살펴 볼 수 있습니다. 정보를 입력하거나 출력하는 액터가 있고, 입출력을 모두 행하는 액터가 있을 것입니다.

액터를 뽑아내는 일은 매우 중요한 일입니다. 모든 주요 액터를 고려해야만 모두에게 가치 있는 시스템이 될 수 있을 테니까요. Visual Modeling with Rational Rose and UML에 따르면 다음과 같은 질문들이 액터를 뽑아내는데 도움을 준다고 합니다.

• 특정 요구사항에 이해관계자는 누구인가?
  
• 어떠한 부서나 집단에서 시스템을 사용하는가?
  
• 시스템을 사용함으로써 이익을 얻는 이는 누구인가?
  
• 누가 시스템에 정보를 입력하고 사용하며 삭제하는가?
  
• 누가 시스템의 유지보수를 수행하는가?
  
• 시스템이 외부 자원을 사용하는가?
  
• 한 사람이 복수의 역할을 수행하는가?
  
• 여러 사람이 한 가지 역할을 수행하는가?
  
• 시스템이 레거시 시스템(Legacy System)과 상호 작용 하는가?

액터는 다이어그램 상에서 막대인간(stickman)으로 표현됩니다.

[액터의 UML 표기법]

유즈케이스 (Use Cases)

유즈케이스 모델은 시스템과 액터와의 의사소통을 표현합니다. 각각의 유즈케이스는 시스템이 제공해야 하는 기능을 묘사하고, 이러한 유즈케이스들이 시스템 전체의 기능을 나타냅니다. 하나의 유즈케이스는 액터가 원하는 기능을 수행하기 위해 시스템이 수행하는 일련의 처리들의 연속입니다.

Visual Modeling with Rational Rose and UML에 따르면 다음과 같은 질문들이 유즈케이스를 뽑아내는데 도움을 준다고 합니다.

• 각각의 액터의 업무는 무엇인가?
  
• 액터가 시스템의 정보를 생성, 저장, 수정, 삭제하고 읽는가?
  
• 어떠한 유즈케이스가 시스템의 정보를 생성, 저장, 수정, 삭제하고 읽는가?
  
• 액터가 돌연한 외부 변화에 대한 정보를 시스템에게 알릴 필요가 있는가?
  
• 시스템에 갑자기 발생한 일들을 액터가 알아야 하는가?
  
• 어떠한 유즈케이스들이 시스템을 지원하고 유지하는가?
  
• 유즈케이스들이 모든 요구되는 기능을 포괄하여 수행하는가?

유즈케이스의 UML 표기법은 타원(Oval)입니다.

[Use Case의 UML 표기법]

관계(Relationship)

관계는 크게 두 가지로 볼 수 있습니다. 하나는 액터와 유즈케이스의 관계이고, 다른 하나는 유즈케이스간의 관계입니다. 액터와 유즈케이스와의 관계는 연관(Association) 혹은 커뮤니케이션 연관(Communicates Association)이라고 합니다. 액터와 유즈케이스간의 의사소통을 나타내기 때문이겠죠.

연관은 양방향으로 진행될 수 있습니다. 연관의 방향성은 어느 쪽이 연관을 유발하느냐에 따라 달라집니다. 오직 액터 혹은 유즈케이스만이 연관을 유발하는 단방향 연관이 있고, 양쪽 모두에서 연관을 일으키는 양방향 연관이 있습니다.

유즈케이스간의 관계는 두 가지 형태가 있습니다. 포함(Inclusion 혹은 사용 Use)과 확장(Extension)입니다. 여러 유즈케이스들이 하나의 기능 조각을 공유할 때 이를 모든 유즈케이스에 각각 집어 넣는 것 보다는 이를 분리해두고 필요한 유즈케이스들이 이를 포함해서 사용하게 됩니다. 예를 들어 회원제를 기반으로 한 인터넷 사이트에 접속하셔서 각종 서비스를 제공받기에 앞서 늘 수행하는 회원 인증과 같은 유즈케이스가 포함 관계입니다.

확장 관계는 기본 유즈케이스에서 특정 조건이나 액터의 선택에 따라 발생하는 유즈케이스입니다. 가령, ATM에서 사용자의 메뉴 선택에 따라 달라지는 유즈케이스의 경우나 긴급 상황 시에 발생할 수 있는 유즈케이스가 확장의 예로 생각할 수 있습니다.

관계는 선으로 표기하며 관계의 방향성은 화살표로 나타냅니다. UML에는 스테레오타입(Stereotype)이라는 개념이 있습니다. 이는 기본적인 모델링 요소 이외의 새로운 타입을 나타내는 것입니다. 따라서, 확장을 가능하게 해줍니다. 스테레오타입이라는 것이 인쇄소의 연판을 나타내는 것입니다. 어느 정도 변화를 줄 수 있는 유연한 판형이라는 것이죠. 이처럼 스테레오타입은 기본 모델링 요소에 확장성을 부여할 수 있는 개념입니다.

[소프트웨어 프로그램 개발 과정]

현실 세계의 문제 해결을 위해 프로그램을 만들기 위해서 일단 현실에서의 요구 사항을 분석해야 합니다. 자신이 필요로 하는 프로그램을 만드는 것도 쉬운 일이 아닙니다. 더군다나 다른 사람을 위한 프로그램 개발자야 어떠하겠습니까? 게다가 프로그램 사용자가 다수라면 더 복잡해집니다. 간단하게 누구의 요구는 받아주고, 누구의 요구는 묵살할 수는 없는 일이니까요. 이렇듯 복잡한 현실 세계의 요구 사항을 파악하기 위해서 모델링을 합니다. 앞에 언급한 것처럼 모델링이란 현상을 단순화, 일반화 또는 추상화 하는 과정입니다. 모델을 현실과 동일하게 만드는 일은 불가능합니다. 설령 그렇게 했다고 하면 이미 그것은 모델이 아니니까요. 모델링을 할 때 가장 중요한 것은 많은 관점들을 찾아내고 조정하는 것입니다. 프로그램을 사용할 사람들의 관점에 따라 그들이 원하는 것은 판이하게 다를 것입니다. 또한, 이들 프로그램의 개발자들을 위한 모델 역시 다양할 수 있습니다. 사용자 관점은 프로그램의 가치를 반영하는 반면, 일반적으로 개발자들에 제공되는 모델이 다양할수록 개발에 대한 이해가 높아질 수 있겠죠. UML은 이러한 다양한 관점을 다룰 수 있는 효과적인 도구가 될 수 있음을 보게 될 것입니다.

UML의 역사

이제 UML에 대한 이해를 하기에 앞서 간략하게 UML의 역사를 되돌아 보도록 하겠습니다. Grady Booch, James Rumbaugh와 Ivar Jacobson, 세 사람은 80년대부터 각자의 객체지향 방법론을 연구합니다. 1994년 Booch가 세운 Rational사에 Rumbaugh가 합류하고, 일년 후 Jacobson이 합류하면서 이들의 연구는 하나로 결집되어 UML 드레프트(draft) 버전을 만들어냅니다. 이것은 소프트웨어업계에 큰 반향을 일으키며 Microsoft, Oracle, HP, DEC, TI 등 유수의 멤버로 결성된 UML 컨소시엄을 발족하게 됩니다.

1997년 UML 컨소시엄은 UML 버전 1.0을 만들어 내고 이를 OMG(Object Management Group)에 제출합니다. 그 해 말에 OMG는 이를 수정한 UML 1.1을 표준 모델링 언어로 채택하기에 이르죠. 현재 1.3 스펙에 이어 1.4 버전까지 논의되고 있습니다.

UML은 많은 모델링 도구들로 이루어져 있는데 이는 모두 새로운 개념이 아닙니다. UML은 산재한 많은 모델링 언어들을 통합해서 장점을 취합하기 위한 방안이라고 볼 수 있죠. 또한 OMG와 같은 권위 있는 표준 기구를 통해 UML을 표준 모델링 언어로 채택해서 이를 적용한 모델러가 다르더라도 모델을 통한 의사소통이 가능하게 된 것입니다.

UML의 구성

UML은 다양한 모델링 도구로서의 다이어그램 들을 통일시킨 것입니다. 다음은 UML의 주요 다이어그램의 명칭들을 나열한 것입니다.

• 클래스 다이어그램(Class Diagram)
  
• 객체 다이어그램(Object Diagram)
  
• 쓰임새 다이어그램(Use-case Diagram)
  
• 상태 다이어그램(State Diagram)
  
• 시퀀스 다이어그램(Sequence Diagram)
  
• 활동 다이어그램(Activity Diagram)
  
• 협력 다이어그램(Collaboration Diagram)
  
• 컴포넌트 다이어그램(Component Diagram)
  
• 배치 다이어그램(Deployment Diagram)

이들 다이어그램은 시스템(소프트웨어라고 할 수도 있으나 좀더 명확한 표현을 위해 시스템이란 용어를 사용)의 정적인 구조를 보여주는 것과 동적인 행동을 나타내는 것으로 크게 양분할 수도 있습니다.

UML은 왜 이렇게 많은 다이어그램을 포함하고 있는 것일까요? 그 이유는 다양한 관점을 반영하여 개발하고자 하는 시스템에 대한 많은 뷰(View)를 제공하기 위함이죠. 시스템 개발에는 많은 이해관계자가 존재합니다. 시스템 개발을 의뢰한 고객이나 장차 이를 사용하게 될 사용자를 비롯해서, 다양한 역할을 갖는 개발자와 프로젝트 관리자 등 많은 사람들이 관여하게 되는 것은 당연한 일이죠.

UML은 이들 중 누구 하나의 관점만을 표현한다면 가치가 낮아질 것입니다. 따라서, 많은 이해 관계자들의 관점에 맞는 뷰를 보여주는 것입니다. 고객이 바라볼 때 이 시스템은 어떤 모습이 될 것인지를 보여주고, 개발자가 바라볼 때 이 시스템이 어떤 구성과 동작으로 이뤄질 지를 보여주는 것입니다. 고객 역시 하나의 관점을 지니지는 않습니다. 음료수 자동판매기 시스템의 이용자는 대부분 음료수를 뽑아 마시길 원하지만, 수금을 하고, 음료수를 채워넣는 사람들도 시스템의 이용자라고 볼 수 있죠. 마찬가지로 개발자 역시 자신이 맡은 부분에 따라 시스템을 상이한 수준에서 바라볼 것입니다. 전체적인 아키텍쳐를 결정할 사람은 보다 높은 수준에서 시스템을 추상적으로 보길 원할 것이고, 직접 코딩을 할 사람들에게는 이러한 모호한 다이어그램보다는 상세한 객체의 구조와 상호작용을 보여주는 모델을 필요로 할 것입니다.

UML에 이렇게 많은 다이어그램이 존재하게 됨으로 해서 또 한가지 중요한 것은 이들 간의 통합 혹은 무결성(Integrity) 보장입니다. 서로 다른 뷰를 제공하지만 결국 시스템은 하나입니다. 따라서, 이들 다양한 다이어그램이 서로 개별적으로서만 의미를 지니는 것이 아니라, 상호 연관성이 있어야 하고, 때에 따라서는 변환도 가능해야 합니다. UML 모델링 지원 도구인 Rational Rose의 경우 이러한 다이어그램간의 무결성을 보장합니다.

UML을 이용한 모델링, 어떻게 할 것인가?

그렇다면 이러한 모델링을 어떻게 어느 정도까지 수행해야 할 것인가? 일반적으로 시스템을 개발하는 프로젝트는 시간과 예산의 제약을 받으면서 고객의 요구를 충족시켜 줄 수 있어야 합니다. 고객의 요구를 파악하기란 쉬운 일이 아니죠. 오늘날의 시스템은 다수의 사용자를 갖게 되고 통합화 되는 추세라, 고객의 요구사항을 파악하는 것은 더욱 어려워지고 있습니다.

요구사항을 정확히 파악하기 위해서는 반복적인 분석과 설계 과정을 행하는 것이 좋죠. 그렇게 되면 모델링에 많은 노력이 가해집니다. 많은 모델을 만들어낼수록 상대적으로 많은 뷰를 나타낼 수 있고, 요구사항에 근접해간다고 볼 수 있습니다. 그러나, 모델링 작업은 시간과 자원을 필요로 합니다. 분석 전문가나 모델러가 필요하고, 고객 및 개발자와 오랜 시간의 공동작업도 필요하게 되죠.

모델링을 어느 정도 까지 해야 한다는 정답은 없습니다. 경험에 의존해야 하고, 각 조직의 환경이 반영되기 마련이죠. 따라서, 이들 다이어그램을 익히고 나서 프로젝트에 필요한 UML 다이어그램의 적절한 조합을 만들어내는 일이 필요하겠습니다.

[UML 로고]

모델링(Modeling)이란? 1 .0 모델링(Modeling)이란?

0 모델링의 특성과 다양한 계층의 언어들

모 델(Model)은 소프트웨어 개발에 훌륭한 안내자 역할을 할 수 있습니다. 그렇지만 모델은 그저 모델일 뿐입니다. 즉, 아무리 자세한 모델도 실제 소프트웨어를 정확하게 나타낼 수는 없죠. 모델은 근본적으로 실제 현상이나 사물을 단순화 시킨 것입니다. 실물과 정확히 똑같은 모델을 만들었다고 하면 그것은 이미 모델이 아니죠.

또 한가지, 모델은 잘된 것인지 아닌지 판별하기가 상당히 힘듭니다. 모델에는 모델링 작업을 수행한 모델러(Modeler)의 가치관이 반영되기 때문에 객관적으로 이를 평가하기란 결코 쉬운 일이 아닙니다. 다수의 사람들에게 자동차의 모형을 요구하면, 그들은 각각 서로 다른 모형을 만들어낼 것입니다. 자동차의 외관에 관심이 많은 사람은 디자인과 색상 등을 정확하게 묘사하기 쉽고, 내부구조에 관심이 많은 사람은 내부 구성도를 그려낼 수도 있습니다. 그렇지만, 이들 중 어떤 것이 잘된 것이라고 평가하는 일은 쉬운 것이 아닙니다.

모델링을 하는데 있어서 위의 두 가지 특성 즉, 태생적인 단편성이나 주관적 특성을 잘 이해하고 있어야 합니다. 복잡한 소프트웨어를 개발하는 프로젝트일수록 모델의 단순함을 극복하기 위해 다양한 묘사를 제공하는 다수의 모델이 필요할 수 있습니다. 또한, 해당 소프트웨어의 사용자가 다수이고, 개발자 역시 많다고 하면, 참여자의 필요에 맞는 특정 모델이 요구됩니다. 따라서, 많은 이해관계자가 결부된 프로젝트의 경우에는 다양한 관점을 반영한 모델이 제시되어야 하는 것입니다.

우리가 이제 배우게 될 UML에는 다년간 연구의 축적으로 이러한 모델링에 대한 깊은 이해가 녹아 있다고 볼 수 있습니다.

다양한 계층의 언어들

JAVA, C++, Python, XML, IDL, HTML, WML, UML,… 정말 실로 수많은 언어들이 있습니다. UML에 대해 전혀 무지한 사람들 중에는 UML과 XML 등을 어떤 비슷한 것이겠거니 생각할 수도 있을 것입니다. 이에 따라서 UML에 대해 본격적으로 살펴보기에 앞서 UML이 어떠한 계층에 위치하는 언어이며 어떠한 용도로 쓰이는 것인지를 확실히 하기로 하죠.

우리가 살아가는 세상에 수많은 언어가 존재하는 것처럼 프로그래밍 세계에도 수많은 언어가 존재합니다. 일반적으로 프로그래밍 언어라고 하면 BASIC, COBOL, C, C++, JAVA와 같은 것들을 떠올립니다. 이들 3세대 언어는 컴파일러를 이용하는 언어들인데, 이는 기계어나 어셈블리 등과 같은 1,2세대 언어와 SQL과 같은 4세대 언어와 함께 일반적인 프로그래밍 언어로 분류됩니다. 이들은 어떠한 처리를 수행하게 하는 언어들이죠.

웹의 발전에 따라 표현을 위한 언어인 HTML(Hyper Text Markup Language)이 등장합니다. 이는 데이터의 처리보다는 주로 어떻게 화면에 보여질 것인가 하는 표현을 나타내는 언어입니다. 네트워크의 발전이 계속되면서 데이터의 구조화와 원활한 데이터 교환을 위한 언어인 XML(Extensible Markup Language)이 등장했으며, 서로 다른 프로그래밍언어로 작성된 객체간의 통신을 위해 IDL(Interface Definition Language) 같은 언어가 등장하기도 합니다.

이들 언어들은 프로그램의 처리를 위한 언어와는 분명히 구분되는 것들 입니다. 계층 혹은 위치하는 레이어(Layer)가 다르다고 볼 수 있죠. 가령, HTML과 같은 경우에는 서버상에서 주로 구동 되는 프로그램과 달리 사용자의 컴퓨터로 다운로드 되어서 어떻게 브라우저에 데이터를 표현할 것인가를 처리하는 언어입니다. XML 역시 프로그래밍 언어와 달리 데이터를 구조적으로 담아내는 일을 처리하고, IDL은 이미 프로그래밍 언어로 만들어진 프로그램 간의 의사소통을 위한 언어로서의 역할을 지니는 것입니다.

UML(Unified Modeling Language)은 이름처럼 모델링을 위한 언어입니다. 즉, 모델을 표현하기 위한 도구들과 기법의 집합이라 할 수 있는 언어죠. 그러나, UML과 프로그래밍 언어는 사용되는 계층이 다른 것이지 전혀 무관한 것은 아닙니다. UML이 설계를 위한 모델링 언어라면, 프로그래밍언어는 실제 구현을 위한 언어죠. 설계와 구현은 전혀 다른 작업은 아닙니다. 설계의 결과물인 모델에 따라 구현이 이루어는 것이죠. 만일 설계된 것이 어떠한 방법으로 구현되는지 명확히 제시된다면 UML로 표기된 모델을 프로그래밍언어로 변환할 수 있을 것입니다. 실제로 Rational Rose와 같은 CASE 도구는 이러한 일을 할 수 있는 소프트웨어 개발 도구입니다.

2 .0 모델링의 특성과 다양한 계층의 언어들

UML 에 관해 논하기에 앞서 모델링에 대하여 살펴보죠. 모델링은 현실 세계의 단면을 추상화 혹은 일반화하는 작업이라고 할 수 있습니다. 다음 그림은 자동차를 모델링 한 결과물인 모델입니다. 이것은 자동차의 모든 면을 표현 하지는 못하지만 어느 정도까지는 실제 자동차의 특성을 보여줍니다. 이러한 모델과 모델을 만들어내는 모델링은 많은 곳에서 사용되고 있습니다. 건설업의 예를 보면, 우선 건축에 앞서 조감도를 그리기도 하고, 설계도를 작성하기도 합니다. 이러한 그림들 역시 모델로 볼 수 있습니다. 조감도는 실제로 건물이 지어졌을 때 어떠한 모습을 드러낼지를 보여주게 되는 모델이 될 수 있고, 설계도는 실제 건물의 건축을 위한 구조, 재료와 치수 등에 고려해서 표현한 모델이 될 수 있습니다. 또 다른 예로 분양 여부를 결정하기 위해서 사람들이 찾아가는 모델하우스가 있습니다. 자신들이 살게 될 집이 어떠한 모습인지 이러한 모델을 보고 정보를 얻게 됩니다.

이렇듯 모델들은 하나의 현상이나 사물에 대해서도 다양한 모습을 보입니다. 또한, 앞의 예에서처럼 관점에 따라 다양한 용도로 사용될 수 있습니다. 하나의 아파트에 대해서 조감도, 설계도와 모델하우스가 각각 모델로 존재하는 것처럼 말입니다.

오늘날 하드웨어 성능의 급격한 발전과 이에 따른 가격 하락으로 소프트웨어는 갈수록 편리한 기능을 통해 인간에게 많은 편의를 제공해주고 있습니다. 그러나, 이러한 편리한 소프트웨어를 만들어야 하는 개발자는 갈수록 복잡한 프로그래밍을 요구 받습니다. 또한, 소프트웨어가 점차 대형화 되고, 통합화 되면서 소프트웨어의 개발이 프로젝트 형식을 띄게 됩니다. 이에 따라 위험성도 함께 높아지게 되죠. 이러한 위험에 맞서 적절히 소프트웨어를 개발하고자 하는 소프트웨어 공학이 발전하여 소프트웨어 개발 프로젝트도 건축 프로젝트와 같은 기존의 공학적인 프로젝트처럼 관리되어지게 됩니다.

예전처럼 소프트웨어를 바로 코딩을 한다던가 계획 없이 즉흥적으로 개발하는 일은 오늘날의 커다란 프로젝트에서는 상상할 수 없는 일입니다. 건축 프로젝트에서 도면을 그리고, 일정을 세우고 거기에 맞춰나가듯이 소프트웨어의 개발에서도 그러한 절차와 규칙을 따르게 되죠. 이러한 과정에서 모델링 혹은 그 결과물인 모델이 필요하게 되는 것입니다.

소프트웨어 개발을 시작할 때에는 대체로 다음과 같은 질문을 던질 수 있습니다.