[소프트웨어 프로그램 개발 과정]
현실 세계의 문제 해결을 위해 프로그램을 만들기 위해서 일단 현실에서의 요구 사항을 분석해야 합니다. 자신이 필요로 하는 프로그램을 만드는 것도 쉬운 일이 아닙니다. 더군다나 다른 사람을 위한 프로그램 개발자야 어떠하겠습니까? 게다가 프로그램 사용자가 다수라면 더 복잡해집니다. 간단하게 누구의 요구는 받아주고, 누구의 요구는 묵살할 수는 없는 일이니까요. 이렇듯 복잡한 현실 세계의 요구 사항을 파악하기 위해서 모델링을 합니다. 앞에 언급한 것처럼 모델링이란 현상을 단순화, 일반화 또는 추상화 하는 과정입니다. 모델을 현실과 동일하게 만드는 일은 불가능합니다. 설령 그렇게 했다고 하면 이미 그것은 모델이 아니니까요. 모델링을 할 때 가장 중요한 것은 많은 관점들을 찾아내고 조정하는 것입니다. 프로그램을 사용할 사람들의 관점에 따라 그들이 원하는 것은 판이하게 다를 것입니다. 또한, 이들 프로그램의 개발자들을 위한 모델 역시 다양할 수 있습니다. 사용자 관점은 프로그램의 가치를 반영하는 반면, 일반적으로 개발자들에 제공되는 모델이 다양할수록 개발에 대한 이해가 높아질 수 있겠죠. 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 로고]
| 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)이라는 개념이 있습니다. 이는 기본적인 모델링 요소 이외의 새로운 타입을 나타내는 것입니다. 따라서, 확장을 가능하게 해줍니다. 스테레오타입이라는 것이 인쇄소의 연판을 나타내는 것입니다. 어느 정도 변화를 줄 수 있는 유연한 판형이라는 것이죠. 이처럼 스테레오타입은 기본 모델링 요소에 확장성을 부여할 수 있는 개념입니다.
| 액티비티 다이어그램 그리기 |
| 2 .0 의사결정 지점 (Decision Points) |
| 3 .0 동기화 막대(Synchronization Bars) |
| 4 .0 구획면(Swimlanes) |
| 5 .0 시작 및 종료 액티비티(Initial and Final Activities) |
| |
액티비티 다이어그램(Activity Diagram)은 활동 다이어그램이라고도 합니다. 액티비티 다이어그램은 시스템에서 액티비티와 액티비티 간의 제어의 흐름을 보여주는 웍플로우를 나타내는 흐름도입니다. 액티비티 다이어그램은 순차적인 제어의 흐름뿐 아니라, 병렬적으로 수행되는 활동과 분기가 이루는 대안들에 대해서도 표현해줍니다. 유즈케이스 다이어그램을 작성한 후 하나의 유즈케이스 내에서의 흐름을 표현해주는 액티비티 다이어그램을 작성할 수 있습니다. 나중에는 특정 오퍼레이션(Operation) 내에서의 웍플로우 표현을 위해 액티비티 다이어그램을 사용할 것입니다.
액티비티 다이어그램은 액티비티, 전이(Transition), 의사결정 지점(Decision Point)과 동기화 막대(Synchronization bar)등으로 구성되며 각각의 UML 표기법은 그림 4-1과 같습니다.
[액티비티 다이어그램 요소를 위한 UML 표기법]
액티비티 다이어그램 만들기
액티비티 다이어그램을 작성하기 위해서는 브라우저의 Use Case View 폴더 위에서 오른쪽 마우스를 클릭해 New - Activity Diagram 단축키를 선택합니다. 액티비티 다이어그램을 생성하면 새로 만들어진 다이어그램이 선택됩니다. 선택된 상태에서 다이어그램에 이름을 부여합니다. 다이어그램을 더블클릭하면 다이어그램을 편집할 수 있는 창이 열립니다.
[액티비티 다이어그램 만들기]
액티비티(Activities)
액티비티는 웍플로우상의 특정 작업 단계를 나타냅니다. 액티비티는 모서리가 둥근 직사각형으로 나타냅니다. 액티비티를 만들기 위해서는 우선 액티비티 다이어그램을 선택합니다. 툴바에서 액티비티 아이콘을 선택하고 다이어그램에서 액티비티가 놓일 위치를 클릭합니다. 액티비티를 클릭하여 액티비티의 이름을 입력합니다.
[액티비티 만들기]
전이(Transitions)
전이는 액티비티에서 액티비티로 제어의 흐름이 넘어가는 것을 나타낸다. 일반적으로 제어를 넘기는 액티비티의 종료가 뒤 따르는 액티비티를 유발시킵니다.
툴바에서 state transition 아이콘을 선택하고, 전이를 유발시키는 액티비티에서 다음 액티비티로 드래그합니다.
[전이 만들기]
| 1 .0 액티비티 다이어그램 그리기 |
| 0 의사결정 지점 (Decision Points) |
| 3 .0 동기화 막대(Synchronization Bars) |
| 4 .0 구획면(Swimlanes) |
| 5 .0 시작 및 종료 액티비티(Initial and Final Activities) |
| |
워크플로우가 의사결정 지점을 기준으로 분기할 때가 있습니다. 의사결정 지점은 감시 조건(guard condition)을 포함하고, 감시 조건에 따라 웍플로우 상에서 여러 가지 대안을 표시하는 것이 가능합니다.의사결정 지점을 만들기 위해서는 툴바에서 Decision 아이콘을 선택하고 다이어그램 창에서 의사결정 지점이 놓일 위치를 클릭합니다. 의사결정 지점을 다시 클릭하여 이름을 설정하고, 액티비티와의 전이를 표현하기 위해서 State Transition 아이콘을 선택하여 드래그합니다.
감시 조건에 따른 전이를 만들기 위해서는 전이를 더블클릭하여 Specification 대화상자를 엽니다. Detail 탭을 선택하고 Guard Condition 필드에 해당 감시 조건을 입력합니다. 전이를 나타내기 위해 드래그 할 때
[의사결정 지점 만들기]
[감시 조건을 이용한 전이]
전이를 나타내는 꺾인 선을 선택한 상태에서 Format – Line Style 메뉴에서 Rectilinear를 선택하면 직선으로 표현됩니다.
[Rectilinear 스타일의 전이]
| 1 .0 액티비티 다이어그램 그리기 |
| 2 .0 의사결정 지점 (Decision Points) |
| 0 동기화 막대(Synchronization Bars) |
| 4 .0 구획면(Swimlanes) |
| 5 .0 시작 및 종료 액티비티(Initial and Final Activities) |
| |
동기화 막대는 웍플로우 상에서 동시에 병렬 수행되는 액티비티들을 표현하기 위해 사용합니다. 가령, 두 개의 선행 액티비티가 종료해야 이어지는 액티비티가 수행되는 경우나 하나의 액티비티의 종료가 뒤따르는 복수의 액티비티가 동시에 수행되기 위한 조건일 때 동기화 막대를 사용하여 나타냅니다.
동기화 막대를 나타내기 위해서는 툴바의 Horizontal Synchronization이나 Vertical Synchronization 아이콘을 선택하고 다이어그램 창의 원하는 위치를 클릭합니다. 동기화 막대의 크기를 조절하려면 막대를 클릭하여 모서리에 핸들이 나오게 하고 핸들을 드래그 하면 크기를 조절할 수 있습니다. 정확히 핸들을 드래그하지 않으면 동기화 막대가 이동합니다.
State Transition 아이콘을 선택하여 전이를 표현합니다. 선들을 직선으로 만들고자 하는 경우에는 앞에 보았던 방법으로 Format – Line Style 메뉴를 이용하시면 됩니다. 이를 적용한 예가 다음 그림입니다.
동기화 막대 만들기
| 1 .0 액티비티 다이어그램 그리기 |
| 2 .0 의사결정 지점 (Decision Points) |
| 3 .0 동기화 막대(Synchronization Bars) |
| 0 구획면(Swimlanes) |
| 5 .0 시작 및 종료 액티비티(Initial and Final Activities) |
| |
구획면은 액티비티 다이어그램을 분할하기 위해 사용합니다. 구획면 안에 포함된 액티비티들에 대한 책임을 갖는 특정 조직이나 사람을 표현합니다.
구획면을 나타내기 위해서는 툴바에서 Swimlane 아이콘을 선택하고 다이어그램 창에 클릭합니다. NewSwimlane이라는 임시로 부여된 이름을 더블클릭하여 구획면의 이름, 즉 책임자나 해당 조직명을 부여합니다. 액티비티들을 구획면에 적절히 배치한다. 이를 적용한 예가 다음 그림입니다.
구획면으로 나눈 액티비티 다이어그램
| 1 .0 액티비티 다이어그램 그리기 |
| 2 .0 의사결정 지점 (Decision Points) |
| 3 .0 동기화 막대(Synchronization Bars) |
| 4 .0 구획면(Swimlanes) |
| 0 시작 및 종료 액티비티(Initial and Final Activities) |
| |
하나의 웍플로우에서 시작하는 웍플로우나 끝나는 웍플로우는 다른 표기법을 사용합니다. 시작 액티비티(Initial Activities)의 경우 채워진 원(solid filled circle)을 사용하여 나타내고, 종료 웍플로우(Final Activities)는 빈 원안에 채워진 원을 넣은 이른바 bull’s eye로 표기합니다.
시작 액티비티와 종료 액티비티
계속해서 UML을 학습하기에 앞서 Rational Rose에 대해 간단히 소개를 하도록 하겠습니다. 본 강좌는 UML에 대한 것으로 특정 도구 사용에 국한되지 않으려고 Rose 사용법을 자세히 언급함 없이 강좌를 진행했습니다. 그렇지만, 소개도 없이 Rose의 화면 구성 요소나 메뉴에 대해 언급하는 것이 불편하셨을 것입니다. 여기서는 우선 앞으로 자주 사용하게 될 Rose의 전체적인 화면 구성 요소를 살펴보는 것에 주안점을 두겠습니다. 구성요소를 칭하는 명칭은 Rose가 한글판이 없는 이상 굳이 번역함 없이 원어를 사용하도록 하겠습니다.
Application Window
Rational Rose의 전체 창을 애플리케이션 윈도우(Application Window)라고 합니다. 아래 그림은 Rational Rose의 애플리케이션 윈도우의 화면 구성을 보여줍니다.
화면의 가장 상단에는 ‘Rational Rose – 파일명.mdl’의 형태의 타이틀을 보여주는 타이틀 바(Title Bar)가 존재합니다. 또한 다이어그램 윈도우의 타이틀 바는 현재 보여지는 다이어그램의 유형을 알리는 타이틀이 나타납니다. 타이틀 바 아래에는 각종 메뉴들이 늘어선 메뉴 바(Menu Bar)를 볼 수 있습니다. 메뉴 바는 현재 작업 중인 다이어그램에 따라 메뉴 구성이 달라집니다.
메뉴 바 아래에는 표준적인 툴바(Toolbar)가 존재합니다. 작업중인 다이어그램의 유형과 무관하게 자주 사용되는 도구들로 구성되어 있습니다. 툴바 아래의 화면은 좌우로 분할되어 있습니다. 좌측 상단에는 브라우저가 있고, 하단에는 다큐멘테이션 윈도우가 존재하며, 우측에는 다이어그램 윈도우가 놓여질 작업 공간이 존재합니다. 또한 이들 두 영역 사이에는 툴박스가 존재합니다.
브라우저(Browser)는 각종 모델링 요소들을 계층적으로 살펴보는 것을 가능하게 해줍니다. 다큐멘테이션 윈도우(Documentation Window)는 모델링 요소들에 대한 설명에 사용합니다. 모델링 요소의 역할, 키, 제약조건, 목적이나 핵심 행위 등을 기술합니다. 다큐멘테이션 윈도우에서 직접 이것들을 기술할 수도 있고, 스페시퍼케이션 윈도우(Specification Window)의 다큐멘테이션 필드에서 이를 입력할 수도 있습니다.
브라우저 및 다큐멘테이션 윈도우와 작업 영역 사이에는 툴박스(Toolbox)가 존재합니다. 상단의 툴바가 다이어그램의 종류에 무관하게 공통적으로 필요한 도구들을 모아놓은 반면 툴박스는 현재 작업 중인 다이어그램에 알맞은 도구들을 제공합니다. 툴박스에 기본적으로 제공하는 것 이외에도 사용자가 편의에 의해서 이를 수정할 수 있습니다. 툴박스에서 오른쪽 마우스 클릭을 하고 팝업 메뉴에서 Cusomize…를 선택하면 툴박스를 자신에게 맞게 구성할 수 있습니다.
오른쪽 작업 영역에는 다이어그램 윈도우(Diagram Window)가 놓입니다. 다이어그램 윈도우는 선택한 다이어그램을 그래픽 환경에서 생성하고 수정하는 것을 가능하게 합니다. 다이어그램 윈도우에 나타나는 모델링 요소를 선택하고, 오른쪽 마우스를 클릭하여 나타난 팝업 메뉴에서 Open Specification…을 선택하거나, 요소를 더블클릭하면 스페시퍼케이션 윈도우를 볼 수 있습니다. 여기에는 해당 모델링 요소에 대한 모든 정보들이 나타납니다. 애플리케이션 윈도우의 가장 하단에는 로그 윈도우(Log Window)가 있는데 여기에는 진행 결과나 오류등에 관한 사항이 출력됩니다.
지금까지 Rational Rose의 개괄적인 모습을 살펴보았습니다. 익숙하지 않으신 분들은 앞으로 실습을 같이 하시면 곧 익숙해지실 것입니다. 앞으로는 여기서 언급한 구성 요소들을 다시 설명함 없이 사용하도록 하겠습니다.
Rational Rose의 Application Window
| 0 객체와 클래스 |
| 2 .0 객체의 특성과 표기법 |
| 3 .0 클래스와 그 표기법 |
| 4 .0 Rose에서 클래스 만들기 |
| 5 .0 클래스 뽑아내기 |
| |
클래스 다이어그램을 배우기에 앞서 객체와 클래스에 대한 개념을 짚고 넘어가겠습니다. 제 경우는 C++과 자바 같은 객체지향 언어를 공부하고 UML을 접한 터라 이들 개념을 이해하는데 큰 무리가 없었습니다.분석 및 설계를 공부하시는 분들 중에는 구현(프로그래밍)을 단순 작업 정도로 치부하는 분들이 있습니다. 그러나, 구현이 없는 설계는 공허한 것입니다. 같은 맥락에서 어떻게 구현되는지 모르면서 이상적인 설계만을 고집한다면 많은 문제를 낳을 것입니다.
적어도 배우는 과정에서는 개발과정 전체를 아우르는 이해가 어느 정도는 필요하다 점입니다. UML을 공부하시는 분들께서도 틈틈이 객체지향언어에 대한 이해도 갖추어야 할 것입니다. 향후 강좌 진행에 있어서 간간이 자바를 통해 여러분들을 조금이나마 도울 수 있도록 노력하겠습니다.
그림 7-1. 붕어빵과 붕어빵 틀
그림 7-1은 붕어빵과 붕어빵을 만드는 틀의 그림입니다. 객체를 설명할 때 가장 흔하게 쓰는 비유입니다. 붕어빵이라는 객체를 만들기 위해서는 붕어빵을 찍어 낼 틀(Template)이 필요합니다. 이것이 클래스라고 할 수 있죠.
비록 초보적인 수준에서 사용되는 비유이긴 하지만 나름대로 꼼꼼히 바라보면 많은 것을 얻을 수 있습니다. 같이 한번 살펴보죠. 100개의 붕어빵을 만들기 위해서 100개의 붕어빵 틀이 필요한 것은 아니죠? 단 하나의 붕어빵 틀로도 수없이 많은 붕어빵을 만들어 낼 수 있습니다. 마찬가지로 하나의 클래스로 수많은 객체를 만들어낼 수 있는 것이죠.
그러나 하나의 붕어빵 틀로는 한가지 모양의 붕어빵밖에는 얻을 수 없습니다. 만일 다른 모양의 붕어빵을 얻고자 한다면 모양이 다른 붕어빵 틀이 필요하겠죠. 붕어빵을 만드는 사람 입장에서 붕어빵 틀을 또 만들거나 구입하는 것은 돈이 드는 일입니다. 그렇지만, 새로운 형태의 붕어빵을 만든다면 히트를 쳐서 더 많은 수입을 올릴 수도 있는 일이죠.
마찬가지로 객체들을 만들어내기 위한 클래스를 어떻게 정의하느냐는 명확한 정답이 없는 문제입니다. 경험과 직관을 요하는 일이죠.
붕어빵과 붕어빵 틀의 관계를 잘 이해하셨다면 어느 정도는 객체와 클래스의 관계를 이해하실 수 있었을 것입니다. 다음과 같은 수식으로도 양자의 관계를 설명할 수도 있습니다.
| 객체:클래스 = 인스턴스:템플릿 |
인스턴스(Instance)라는 말은 하나의 예가 될 수 있는 일, 상황이나 사람을 의미합니다. 템플릿(Template)은 지침이 되는 틀을 칭하는 것입니다. 따라서, 템플릿(클래스)는 인스턴스(객체)의 공통점을 뽑아낸 것이죠. 같은 붕어빵 틀로 찍어낸 붕어빵들도 모양이나 맛이 조금씩 틀린 것처럼 하나의 템플릿에 의해 만들어진 인스턴스라 할지라도 고유한 면을 갖게 됩니다.
| 1 .0 객체와 클래스 |
| 0 객체의 특성과 표기법 |
| 3 .0 클래스와 그 표기법 |
| 4 .0 Rose에서 클래스 만들기 |
| 5 .0 클래스 뽑아내기 |
| |
앞에서 다소 장황하게 설명했지만, 객체(Object)는 눈에 보이는 것이든 개념적인 것이든 어떠한 개체(Entity)들을 표현한 것입니다. 붕어빵들도 객체이지만, 내 컴퓨터도 객체이고, 여러분의 예금계좌도 객체입니다.
객체는 일반적으로 세 가지 특징을 갖고 있습니다. 상태, 행위와 아이덴터티입니다.
- 상태(State)는 객체가 존재하는 상태에 대한 정보를 말하는 것입니다. 상태는 속성(attribute 혹은 property)값으로 표현합니다.
- 행위(Behavior)는 객체가 다른 객체의 요청에 대해서 어떠한 반응을 보이는지, 무엇을 할 수 있는지를 정의한 것입니다. 행위는 객체의 오퍼레이션(Operation)들로 구현됩니다.
- 아이덴터티(Identity)는 각각의 객체들은 고유하다는 것을 의미합니다. 겉으로 보아서 붕어빵이 동일하게 보여도 이 둘은 서로 다른 붕어빵이죠. 마찬가지로 상태와 행위가 동일하다고 해도 두 객체는 고유한 아이덴터티를 지닙니다. 구현 단계에서는 이를 위해 키(Key) 등으로 불리는 속성을 두어 아이덴터티를 나타냅니다. (아이덴터티를 고유성, 유일성 등으로 번역하면 오해의 소지가 있을 것 같아 앞으로도 용어의 번역이 모호한 경우에는 가능한 원어의 한글발음을 사용하는 것을 원칙으로 하겠습니다.)
객체에 대한 UML 표기법은 이름에 밑줄을 그은 직사각형입니다. 만일 코리아인터넷닷컴의 UML 포럼을 객체로 표현할 경우 다음과 같이 표기할 수 있습니다.
| UML 포럼 |
그림 7-2. 객체에 대한 UML 표기법
| 1 .0 객체와 클래스 |
| 2 .0 객체의 특성과 표기법 |
| 0 클래스와 그 표기법 |
| 4 .0 Rose에서 클래스 만들기 |
| 5 .0 클래스 뽑아내기 |
| |
앞에 설명한 것과 같이 클래스는 객체의 공통점을 뽑아낸 것입니다. 보다 명확하게 말하자면 객체의 공통적인 속성과 행위를 기술해 놓은 것입니다. 일반적으로 하나의 클래스에 속하는 모든 객체는 동일한 속성과 행위를 갖고 있습니다. 그러나, 각각은 고유한 속성값들을 갖게 됩니다. 고유하다는 말은 다른 것을 의미하지는 않습니다. 실제 구현단계에서는 메모리 영역이 다른 것을 의미하게 되는 것이죠.
클래스의 UML 표기법은 구획면으로 나눠진 직사각형을 사용합니다. 상단에는 클래스 이름이 나오고, 가운데는 상태를 나타내는 속성들이, 마지막 하단에는 행위를 표현하는 오퍼레이션들이 기술됩니다.
코리아인터넷닷컴에는 ‘UML 포럼’ 이외에도 ‘HTML 포럼’, ‘디자인 포럼’, ‘비즈니스 포럼’ 등 많은 수의 포럼이 존재합니다. 이들 각각의 포럼을 객체라고 하면 ‘포럼’이라는 클래스를 정의할 수 있을 것입니다. 클래스 이름은 ‘포럼’이라고 할 수 있죠? 속성들은 포럼 이름, URL, 작성자 등을 생각해 볼 수 있고, 오퍼레이션으로는 글을 추가하는 것과 삭제하는 것들을 생각해 볼 수 있습니다. 오퍼레이션은 궁극적으로 메소드로 구현되기 때문에 작명에 있어서도 일반적인 메소드 작명법(Naming Convention)을 따르는 것이 좋습니다. ‘글을 추가하기’와 ‘글을 삭제하기’를 각각 addArticle(), deleteArticle()이라고 이름 지어보죠.
자 그럼, 앞에서 만든 포럼 클래스를 UML을 이용하여 표기해 봅시다.
포럼 |
포럼이름 |
addArticle() |
그림 7-3. 클래스의 UML 표기법
| 1 .0 객체와 클래스 |
| 2 .0 객체의 특성과 표기법 |
| 3 .0 클래스와 그 표기법 |
| 0 Rose에서 클래스 만들기 |
| 5 .0 클래스 뽑아내기 |
| |
그림 7-4. 클래스 만들기
그림 7-4 와 같이 브라우저의 Logical View를 선택하고 오른쪽 마우스를 클릭하여 팝업 메뉴를 나타나게 한다. [New]-[Class] 순으로 선택하면 클래스가 만들어지면서 NewClass라는 이름이 반전상태가 되는데 이때 클래스 이름을 입력한다.
| 1 .0 객체와 클래스 |
| 2 .0 객체의 특성과 표기법 |
| 3 .0 클래스와 그 표기법 |
| 4 .0 Rose에서 클래스 만들기 |
| 0 클래스 뽑아내기 |
| |
클래스를 뽑아내는 것은 그야말로 ‘Art’의 영역이라고 할 만큼 어려운 일이다. 정답도 없고, 공식도 없는 문제를 푸는 일이다. RUP에서는 엔터티 클래스(Entity Classes), 바운더리 클래스(Boundary Classes)와 컨트롤 클래스(Control Classes)를 찾아내는 방법을 제시하고 있다. 이것은 MVC(Model-View-Controller) 패턴의 관점에 따른 것으로 완전한 해결책은 아니지만 실제로 클래스를 찾아내는 작업을 상당히 수월하게 해준다. 이들 주요 클래스에 대해 알아보자.
- 엔터티 클래스(Entity Classes): 실세계의 개체(Entity)를 반영하는 것으로서 시스템 내부의 일을 수행한다. 대체로 긴 수명을 지니는 정보나 행위를 정의한다. 시스템이 속한 업무 영역에 관계된 클래스가 일반적이어서 도메인 클래스(Domain Classes)라고 불리기도 한다. 대개 시스템의 ‘무엇을 해야 하는지’를 명확히 하는 과정에서 발견된다. 가령, 수강신청 시스템은 학생의 강좌 정보를 유지해야 하기 때문에 ‘학생’, ‘강좌’ 등의 엔터티 클래스를 찾아낼 수 있다.
- 바운더리 클래스(Boundary Classes): 시스템과 환경과의 의사소통 인터페이스 역할을 하는 클래스이다. 유즈케이스 다이어그램을 그리고 나면 액터별 시나리오가 나타나기 마련이다. 이때 액터와 시스템이 접하는 부분에서 각 액터에 맞는 바운더리 클래스를 정의할 수 있다. 가령, 학생은 일정한 폼(화면)을 통해서 수강신청 시스템과 상호작용 할 수 있는데 이러한 폼이 바운더리 클래스이다.
- 컨트롤 클래스(Control Classes): 시스템에서 발생되는 일의 흐름을 제어하는 역할을 하는 클래스이다. 일(Event)의 순서를 결정하고 조정하게 된다. 일반적으로 액터별 시나리오마다 흐름을 제어하기 위한 컨트롤 클래스를 추가된다.
| 0 클래스와 스테레오 타입 |
| 2 .0 클래스에 주석 달기 |
| 3 .0 패키지(Package) |
| |
유즈케이스를 공부할 때 스테레오타입에 대해 언급했었죠. 앞 절에서 살펴 봤던 클래스의 다양한 유형들도 스테레오타입을 이용하여 표현할 수 있습니다. Rose에서는 클래스에 대하여 기본적으로 엔터티 클래스, 바운더리 클래스 및 컨트롤 클래스를 포함하여 11개의 스테레오타입을 지원합니다. 그러나, 이들 외에도 필요에 따라 얼마든지 스테레오타입을 정의하여 사용할 수 있습니다.
스테레오타입 지정은 클래스 스페시퍼케이션 윈도우에서 할 수 있습니다. 클래스를 더블 클릭하거나 오른쪽 마우스를 클릭하여 ‘Open Specification…’을 클릭하면 스페시퍼케이션 윈도우가 나타납니다. 스테레오타입 텍스트 필드에 원하는 스테레오타입을 타이핑 합니다. Rose에서 지원하는 스테레오타입은 드롭다운 버튼을 눌러 선택할 수 있습니다.
그림 8-1. 클래스의 스테레오타입 결정하기
Rose에서 지원하는 스테레오타입들은 클래스의 모양이 RUP에서 사용하는 아이콘으로 변형됩니다. 사용자 정의 스테레오타입은 이중 꺽쇠(<<>>; guillemets)로 표기됩니다. 그림 8-2는 다양한 스테레오타입의 적용 예입니다.
그림 8-2. 여러 가지 스테레오 타입
| 1 .0 클래스와 스테레오 타입 |
| 0 클래스에 주석 달기 |
| 3 .0 패키지(Package) |
| |
다른 UML 요소와 마찬가지로 클래스에 설명을 붙일 수 있습니다. 클래스가 선택된 상테에서 다큐멘테이션 윈도우에 직접 설명을 입력해 넣을 수도 있고, 스페시퍼케이션 윈도우에서 타이핑 할 수도 있습니다.
클래스가 어떠한 상태와 행위를 갖는 지를 기술하는 우를 범하는 경우가 많습니다. 그러나, 이러한 것들은 UML을 통해 충분히 시각적으로 표현되기 때문에 굳이 기술할 필요가 없습니다.
주석 내용은 클래스의 목적을 명기하는 것이 가장 중요합니다. 개발과정이 진행됨에 따라 클래스는 더욱 복잡해지기도 하고, 불필요하게 여겨져서 없어지기도 하고, 생겨나기도 합니다. 당연히 수많은 고민에 부딪히게 되겠죠. 많은 의사결정을 해야 하니까요.
이때 클래스가 왜 필요한지 목적을 명확하게 하는 것이 의사결정자의 도움을 한결 덜게 해줄 것입니다. 그림 8-3 은 주석을 달아놓은 클래스 예제입니다.
그림 7-3. 클래스에 주석 달기
| 1 .0 클래스와 스테레오 타입 |
| 2 .0 클래스에 주석 달기 |
| 0 패키지(Package) |
| |
시스템의 클래스가 많지 않을 때는 관리하는데 큰 어려움이 없습니다. 그러나, 복잡한 시스템의 경우 클래스가 많아지면 난처하게 됩니다. 컴퓨터를 사용하면서 디렉토리(폴더)에 파일이 너무 많으면 관리하기가 힘들어 디렉토리를 만들어 클래스를 정리하죠.
패키지는 디렉토리와 동일한 개념입니다. 다만, 디렉토리에는 파일이 들어있지만 패키지에는 클래스가 들어가는 것이 차이죠.
UML 표기법은 윈도우의 폴더 아이콘과 유사합니다.
그림 8-4. 패키지의 UML 표기법
Rose에서 패키지를 사용하는 방법은 간단합니다. 우선 패키지를 만드는 것은 클래스를 만드는 방법과 마찬가지로 Logical View에서 오른쪽 마우스 클릭을 합니다. 팝업 메뉴에서 [New]-[Package] 순으로 선택하면 NewPackage라는 패키지 이름이 반전 상태가 되는데 이때 원하는 패키지 이름을 입력하면 됩니다.
그림 8-5. 패키지 만들기
클래스를 패키지에 넣는 방법은 그야말로 탐색기에서 파일을 폴더에 넣는 것과 동일합니다. Logical View가 아닌 패키지를 선택한 상태에서 클래스를 만들면 해당 패키지에 속하는 클래스가 만들어집니다.
그림 8-6. 패키지로 정리된 클래스들
그림 8-6은 패키지를 이용하여 클래스들을 정리한 후 브라우저의 모습입니다. 패키지를 만들게 되면 클래스 단위가 아닌 패키지 단위로 모델을 살펴볼 수 있게 됩니다. 복잡한 시스템을 개발하는 경우에는 이렇게 패키지 단위의 다이어그램을 통해 세밀한 기능보다는 전체적인 구조나 주요 기능을 가늠해 볼 수 있게 됩니다.
또한, 각 패키지에 의사소통을 담당하게 될 인터페이스 역할을 하는 클래스를 둔다면 패키지 단위의 재사용까지도 가능해집니다. 쉽게 생각하면 작은 레고 블록을 모아서 성을 만들어둔다면 레고 블록을 처음부터 쌓을 필요 없이 성이 필요할 때 미리 마련해둔 성을 꼽으면 되는 이치죠. 이때, 다른 레고 블록과 성이 맞닿는 지점이 바로 인터페이스가 되는 것입니다. 그림 8-7은 패키지 단위의 다이어그램입니다. Rose에는 패키지 다이어그램이 따로 있는 것이 아니라, 클래스 다이어그램에 패키지를 놓는 방식으로 그릴 수 있습니다.
그림 8-7. 패키지 단위의 다이어그램
| 0 유즈케이스 리얼리제이션(Use Case Realization) |
| 2 .0 유즈케이스 리얼리제이션 다이어그램(Use Case Realization Diagr |
| 3 .0 시나리오 |
| |
유즈케이스는 시스템의 외부에서 바라본 관점을 반영합니다. 시스템의 가치는 결국 이를 사용하는 사람에 의해 결정되거나 혹은 관련된 시스템이 있는 경우, 얼마나 잘 연동 되는지에 따라서 시스템을 평가할 수 있을 것입니다. 아무리 잘 만들었다고 하더라도 사용자가 불편하면 결코 좋은 시스템이라고 말할 수 없겠죠. 수백억을 들여 만든 영화도 관객의 시선을 끌지 못한다면 실패한 영화로 보여지기 마련입니다.
강좌의 서두에서도 유즈케이스의 중요성을 재차 언급했던 것으로 기억합니다. 유즈케이스가 시스템 개발 과정에서 주도적인 역할을 하는 경우가 일반적이라 할 수 있습니다. 그런 맥락에서 시스템의 주요 기능, 시스템을 구성하는 객체와 클래스, 또 객체간의 상호작용을 뽑아내는 데에도 유즈케이스를 출발점으로 사용하는 것은 좋은 방안입니다.
그러나, 아무리 유즈케이스를 잘 뽑아내고, 완벽하게 사용자의 요구를 분석했다고 하더라도 실제로 구현되지 않으면 아무 소용이 없겠죠. 설계도가 좋다고 무조건 훌륭한 건물이 보장되는 것은 아니듯이 말입니다. 이렇게 유즈케이스를 시스템으로 만들어 나가는 첫 단계가 ‘Use Case Realization’입니다. 유즈케이스 실현 혹은 유즈케이스 실체화 등으로 번역할 수 있겠네요.(이하에서는 ‘유즈케이스 리얼리제이션’으로 표기 하도록 하겠습니다.)
유스케이스 리얼리제이션의 UML 표기법은 그림 9-1과 같이 점선으로 된 타원입니다.
그림 9-1. 유즈케이스 리얼리제이션의 UML 표기법
Rose에서 유즈케이스 리얼리제이션을 만들어 볼까요. 유즈케이스를 만들 때와 방법은 동일합니다. 다른 것은 유즈케이스는 Use Case View에서 오른쪽 마우스 클릭을 하여 만들지만, 유즈케이스 리얼리제이션은 클래스와 같이 Logical View에서 오른쪽 마우스 클릭을 해서 만들 수 있습니다.
이렇게 만들어진 유즈케이스를 더블 클릭하여 스페시퍼케이션 윈도우를 띄운 다음 스테레오 타입에서 use-case realization을 선택합니다.
그림 9-2. Use Case Realization 스테레오타입
이를 적용하면 브라우저의 유즈케이스도 점선형태의 타원으로 나타나게 됩니다. 그림 9-3은 유즈케이스 리얼리제이션의 스테레오타입을 적용한 후의 브라우저의 모습입니다.
그림 9-3. 브라우저에 나타난 유즈케이스 리얼리제이션
| 1 .0 유즈케이스 리얼리제이션(Use Case Realization) |
| 0 유즈케이스 리얼리제이션 다이어그램(Use Case Realization Diagr |
| 3 .0 시나리오 |
| |
유즈케이스 리얼리제이션과 마찬가지로 유즈케이스 리얼리제이션 다이어그램도 Logical View에서 오른쪽 마우스 클릭한 후 New – Use Case Diagram 메뉴를 이용하여 만들 수 있습니다. 그림 9-4는 유즈케이스 리얼리제이션 다이어그램의 예입니다.
그림 9-4. 유즈케이스 리얼리제이션 다이어그램
| 1 .0 유즈케이스 리얼리제이션(Use Case Realization) |
| 2 .0 유즈케이스 리얼리제이션 다이어그램(Use Case Realization Diagr |
| 0 시나리오 |
| |
유즈케이스 작성 후에 각 유즈케이스에 대한 시나리오를 도출합니다. 코리아인터넷닷컴의 UML 채널을 예로 들어 볼까요? 우선 액터가 회원 혹은 독자님들인 경우, “강좌 읽기”, “게시판에 글 쓰기”, “답변하기” 등의 유즈케이스를 생각할 수 있죠. 강좌 사이트를 관리하는 관리자 측면에서 보면 “강좌 올리기”, “강좌 수정하기” 등의 유즈케이스를 생각해 볼 수 있습니다.
이러한 각각의 유즈케이스는 하나 혹은 그 이상의 시나리오를 만들어냅니다. 시나리오는 영화 시나리오와 유사한 것입니다. 액터와 시스템 사이에서 어떤 일들이 어떠한 순서를 일어나는가를 기술하는 것입니다.
유즈케이스에 대한 명세서를 만들었다고, 이 명세서가 시나리오 작성에 도움이 될 것입니다. 시나리오의 예를 들어볼까요? 가령, “강좌 읽기”의 경우를 생각해 봅시다. 첫째로, UML 채널을 보기 위한 메뉴를 선택하겠죠. 그러면 강좌의 리스트를 액터(회원 혹은 독자)에게 보여줍니다. 다음으로 독자가 원하는 컬럼 제목을 선택합니다. 그렇게 하면 글이 화면에 보여지게 되는 것이죠.
이와 같은 시나리오를 위에 제가 서술한 것처럼 늘여 쓰면 보기에 무척 지루합니다. 그래서 다음과 같이 순번을 매기는 방법으로 명확하게 표현할 수 있습니다.
“강좌 읽기”의 시나리오
- 액터가 UML 채널 보기 메뉴를 선택한다.
- 화면에 강좌 목록이 나열된다.
- 액터가 원하는 강좌의 제목을 선택한다.
- 화면에 선택된 글이 보여진다.
위의 시나리오는 “강좌 읽기” 유즈케이스에 있어서 주가 되는 메인 시나리오입니다. 그러나, 수많은 예외 상황이 있을 수 있습니다. 또한, 액터의 선택에 따라 분기가 이뤄지는 지점도 있을 것입니다. 다음의 경우를 봅시다.
“강좌 읽기”의 시나리오
- 액터가 UML 채널 보기 메뉴를 선택한다.
- 화면에 강좌에 대한 소개와 메뉴가 보여진다.
- 액터가 원하는 메뉴를 선택한다.
- 액터가 강좌 메뉴를 선택한 경우
- 화면에 강좌 목록이 보여진다.
- 액터가 원하는 강좌를 선택한다.
- 선택된 강좌가 보여진다.
- 화면에 강좌 목록이 보여진다.
- 액터가 게시판 메뉴를 선택한 경우 …
- 액터가 다른 채널을 선택한 경우
- 액터가 강좌 메뉴를 선택한 경우
위의 경우처럼 단계를 구분하여 표현할 수 있습니다. 단계가 너무 깊어져서 보기 어려우면 새로운 시나리오로 취급할 수도 있습니다. 또한, 오류에 대한 것도 고려해야 하겠습니다.
그러나, 시나리오가 복잡해질 경우 글보다는 그림을 이용하는 것이 이해하기에 수월합니다. 이러한 이유로 시나리오를 표기하기 위한 다이어그램이 존재합니다.
시퀀스 다이어그램(Sequence Diagram)과 코레보레이션 다이어그램(Collaboration Diagram)이 있습니다. 코레보레이션 다이어그램 보다는 협력 다이어그램이라는 표현이 더 자연스러운 듯도 하네요. 그러나, 일관성 유지를 위해서 용어는 가능한 원어를 그대로 쓰도록 하겠습니다.
Rose에서는 유즈케이스 리얼리제이션을 만든 후에 이들 다이어그램을 작성할 수 있습니다. 또한, 이들 두 다이어그램을 모두 작성해야 하는 것이 아니라, 하나만 작성하면 나머지는 Rose가 자동 생성해 줍니다.
| 0 Sequence Diagram vs. Collaboration Diagram |
| 2 .0 Sequence Diagram |
| 3 .0 Sequence Diagram 만들기 |
| 4 .0 Collaboration Diagram 만들기 |
| |
이번 강좌에서는 시퀀스 다이어그램과 코레보레이션 다이어그램을 배우도록 하겠습니다. 우선 이들 다이어그램이 무엇이고, 왜 필요한지 살펴보고 작성 방법을 알아 보도록 하죠.
Sequence Diagram vs. Collaboration Diagram
시퀀스 다이어그램과 코레보레이션 다이어그램은 둘 다 객체의 상호작용(Object Interaction)을 나타냅니다. 유즈케이스를 뽑아내면 사용자가 원하는 것이 무엇인가를 알 수 있고, 이것이 어떠한 흐름으로 일어날지를 기술하는 시나리오가 뒤따릅니다.
시나리오는 결국 객체들의 상호작용으로 나타내어지게 됩니다. 결국 객체들이 모여서 프로그램, 소프트웨어 혹은 시스템을 이루게 되니까요.
따라서, 객체들의 상호작용을 정확하게 파악하는 일은 매우 중요합니다. 세세한 사항을 글로 나열하면 전체적인 내용을 이해하기가 어려워집니다. 이러한 이유로 객체의 상호작용을 표현하는 다이어그램들이 필요한 것이죠.
이들 두 다이어그램의 가장 큰 차이는 시퀀스 다이어그램은 이름에서도 알 수 있듯이 시간의 흐름에 따른 객체의 상호작용을 보여주는 반면, 코레보레이션 다이어그램은 상호작용의 내용과 순서만을 나타낸다는 것이죠.
그림 10-1. Sequence Diagram의 예
그림 10-1과 10-2는 각각 객체의 동일한 상호작용에 대한 시퀀스 다이어그램과 코레보레이션 다이어그램입니다.
그림 10-2. Collaboration Diagram의 예
| 1 .0 Sequence Diagram vs. Collaboration Diagram |
| 0 Sequence Diagram |
| 3 .0 Sequence Diagram 만들기 |
| 4 .0 Collaboration Diagram 만들기 |
| |
Sequence Diagram
시퀀스 다이어그램은 앞에 설명한 것처럼 객체간의 상호작용을 시간의 흐름에 따라 보여줍니다. 시퀀스 다이어그램에는 객체, 클래스 혹은 객체나 클래스가 될 후보들이 나타나고, 유즈케이스 혹은 시나리오에 나타나는 기능들을 수행하기 위해 교환되는 메시지들이 표현됩니다.
모호한 용어들을 좀 정리하고 진도를 나가도록 하죠. 후보(Candidate)의 의미를 아시겠습니까? RUP를 설명할 때 언급을 한 것처럼 객체지향 방법론을 적용하여 개발하는 경우에는 반복적인 개발이 일어납니다. 초기에 클래스나 객체로 뽑은 것들도 개발이 진행되면서 사라지거나, 쪼개지는 경우가 자주 발생할 것입니다. 이러한 연유로 초기의 클래스나 객체는 후보가 되기도 하는 것입니다.
다음으로 메시지에 대해서 좀 더 말씀을 드리죠. 실제 구현이 된 연후에 메소드 혹은 함수가 불려짐으로 해서 기능이 수행됩니다. 모델링 단계에서 메소드 혹은 함수를 호출하는 과정이 메시지의 교환으로 나타나는 것입니다. 그림 10-2의 경우를 예로 들면, 강좌를 입력하기 위한 폼(a course form)이 강좌를 관리하는 객체(the manager)에게 강좌를 추가해 달라는 메시지(add course)를 전달합니다. 구현 시에는 manager.addCourse(…)와 같은 식이 되는 것이죠.
그림 10-3. Sequence Diagram에서 객체의 표기
그림 10-3은 각각 식별을 위한 객체의 이름만 있는 객체, 객체의 이름과 클래스 이름이 붙여진 객체와 클래스 이름만 있는 익명(Anonymous) 객체의 UML 표기법입니다.
객체는 자신의 타임라인을 갖습니다. 타임라인에 객체의 수명이 표현되기도 하죠. 이러한 타임라인은 점선으로 표시합니다. 객체 사이에서 오고 가는 메시지는 화살표로 표시합니다. 화살표는 그림 9-1과 같이 메시지를 보내는 객체의 타임라인에서 메시지를 받는 타임라인으로 향하게 됩니다.
| 1 .0 Sequence Diagram vs. Collaboration Diagram |
| 2 .0 Sequence Diagram |
| 0 Sequence Diagram 만들기 |
| 4 .0 Collaboration Diagram 만들기 |
| |
Sequence Diagram 만들기
이제 시퀀스 다이어그램을 작성해 볼까요? 그림 10-4와 같이 유즈케이스 리얼리제이션을 선택한 상태에서 오른쪽 마우스를 클릭하여 팝업 메뉴가 나타나게 합니다. 팝업 메뉴에서 New – Sequence Diagram 메뉴를 선택합니다.
그림 10-4. 시퀀스 다이어그램 만들기
NewDiagram이라는 이름으로 나타나는 새로운 시퀀스 다이어그램을 선택하고 적당한 이름으로 수정합니다.
이제 다이어그램에 객체와 메시지를 표현할 차례군요. 우선 새로 만든 시퀀스 다이어그램을 더블클릭하여 다이어그램 윈도우에 해당 시퀀스 다이어그램이 나타나게 합니다. 많은 경우 액터가 시퀀스를 시작하게 되죠. 브라우저에서 액터를 선택하여 이를 다이어그램 윈도우로 드래그 합니다. 객체의 경우 툴바에서 객체 아이콘을 선택하고, 객체가 놓일 위치를 클릭하면 새로운 객체가 표현됩니다.
객체는 자신의 타임라인과 함께 나타나게 됩니다. 메시지는 툴바에서 화살표를 선택한 상태에서 메시지를 보내는 객체의 타임라인에서 클릭을 하고, 메시지를 받는 객체의 타임라인까지 드래그 합니다.
그림 10-5. 시퀀스 다이어그램 작성
개발 과정이 진행되면 발견되어진 객체들에 의해서 클래스가 정의되는 경우도 있고, 반대로 이미 정의된 클래스를 객체에 할당할 필요성이 생기게 됩니다. 이러한 경우 시퀀스 다이어그램에도 이를 적용할 수 있습니다. 브라우저에서 할당할 클래스를 선택하여 해당 객체까지 드래그합니다.
그림 10-6. 객체에 클래스 할당하기
| 1 .0 Sequence Diagram vs. Collaboration Diagram |
| 2 .0 Sequence Diagram |
| 3 .0 Sequence Diagram 만들기 |
| 0 Collaboration Diagram 만들기 |
| |
Collaboration Diagram 만들기
Rose에서는 시퀀스 다이어그램을 작성하면 코레보레이션 다이어그램을 자동으로 생성해줍니다. 이미 시퀀스 다이어그램에는 코레보레이션 다이어그램 작성에 필요한 모든 정보가 포함되어 있으니까요. 물론 반대도 가능합니다.
브라우저에서 더블클릭 해서 시퀀스 다이어그램을 열고 난 후 메뉴바에서 Browse – Create Collaboration Diagram 메뉴를 선택합니다. 단축키는 F5 기능키입니다. 두 가지 다이어그램이 이미 존재할 때는 F5키를 누르면 두 다이어그램을 번갈아 보여줍니다.
| 0 Relationship이란? |
| 2 .0 Association Relationship |
| 3 .0 Aggregation Relationship |
| 4 .0 Relationship의 선택? 및 Reflexive Relationship |
| |
Relationship은 클래스 사이의 ‘관계’를 뜻합니다. Relationship이 왜 필요할까요? 독자님들도 고민을 한번 해보시죠. 우선 모델링이 현실의 문제를 추상화 하여 그려내는 것이라는 관점에서 바라보죠. ‘학사관리’라는 문제를 모델링 하는 가운데 등장하는 다양한 개체들 사이에는 어떠한 관계가 존재합니다. 가령, ‘학생’, ‘강좌’나 ‘교수’와 같은 개체들은 서로 관계를 지니고 있습니다. 이러한 관계를 표현하기 위한 것이 Relationship입니다.
주의하실 것은 객체(Object) 사이의 관계를 명시하는 것이 아니라 클래스 사이에 존재하는 관계가 Relationship이라는 점입니다. 앞에 살펴본 것처럼 객체 사이에는 상호작용(interaction)이 존재합니다. 정확하게 말한다면 객체 사이의 관계 역시 클래스의 Relationship으로 정의해야 합니다.
객체는 클래스를 인스턴스화 한 것입니다. 관계는 ‘있었다가 없었다가’ 하는 동적인 것이 아니라 ‘있거나 없는’ 정적인 것입니다. 객체 사이의 관계는 결국 클래스에 정의되어 있는 관계라는 것이죠. 객체 사이의 상호작용도 결국 클래스의 Relationship을 통해서 일어나는 것입니다.
“객체 사이의 메시지가 오고 가는 통로”가 클래스의 Relationship이라고 할 수 있습니다. 머리가 복잡하신가요? 클래스와 객체의 관계와 차이점을 명확하게 알아야 이해할 수 있는 부분이죠. 당장 이해가 안 된다 하더라도 걱정하실 필요는 없습니다. 우선 클래스 사이에 Relationship이 존재한다는 것만 기억하십쇼.
Relationship은 번역서에서 ‘관계’라고 번역하기도 합니다. Relationship은 크게 두 가지 형태로 존재합니다. 첫째는 Association Relationship이고, 다른 하나는 Aggregation Relationship입니다. 이제 각각에 대해서 자세히 알아보도록 하죠.
| 1 .0 Relationship이란? |
| 0 Association Relationship |
| 3 .0 Aggregation Relationship |
| 4 .0 Relationship의 선택? 및 Reflexive Relationship |
| |
Association은 ‘연관’이라고 번역하기도 합니다. Association은 클래스 사이에 존재하는 의미상 연결을 의미합니다. Association의 표기는 그림 11-1과 같습니다.
그림 11-1. Association Relationship의 표기법
그림 11-1의 Association을 살펴 볼까요? ProfessorCourseManager는 액터인 교수의 입력을 받아서 교수의 강좌(Course)를 처리하는 클래스입니다. 반대로 Course 클래스는 ProfessorCourseManager 클래스에 의해서 관리가 됩니다. 이렇듯 의미상 연결을 갖고 있는 것이 Association Relationship입니다.
이들 클래스는 서로 ‘관리’하고, ‘관리’되는 관계입니다. 따라서, 위의 Association에 Manages와 같은 이름을 붙일 수도 있겠죠? 많은 경우 관계의 이름은 동사를 사용합니다. Rose에서는 Association의 Specification Window(더블클릭 하면 나타나는 거 아시죠?)에서 이름을 입력할 수 있습니다.
동일한 Relationship에 참여한 클래스들은 서로 상반된 입장에 놓이게 됩니다. 다시 말하면 한쪽이 “관리하는” 역할을 수행한다면 반대편 클래스는 “관리되어지는” 역할을 수행하게 되죠. 따라서, Relationship에 이름을 붙일 때에도 “Manages”로 할 수도 있지만, “Be managed”가 될 수도 있습니다.
따라서, 일관적인 규칙이 필요합니다. 보통 좌측에서 우측으로 혹은 위에서 아래로 관계가 성립되도록 작명을 합니다. 예를 들어 관리하는 클래스가 좌측이나 상단에 나오고, 관리 되어지는 클래스가 우측이나 하단에 놓인다면 Relationship의 이름은 “Manages”가 됩니다.
또한 Association에서 서로의 역할을 명시하여 관계를 더욱 명확하게 할 수 있습니다. 이는 Role 탭에서 입력이 가능하며, Association뿐만 아니라 모든 Relationship에서 가능합니다.
이름이나 역할은 필수적인 것은 아닙니다. Relationship을 분명히 하기 위해 추가적으로 표기할 뿐입니다. 또한, Aggregation Relationship은 포함 관계가 일반적이기 때문에 통상 Relationship의 이름을 생략하는 것이 일반적입니다.
Association에 참여하는 객체의 숫자를 정의하기도 합니다. 이를 Multiplicity Indicator라고 합니다. 아래는 Multiplicity Indicator의 예입니다.
1 한 개
0 .. * 없거나 혹은 한 개 이상
1 .. * 한 개 이상
0 .. 1 없거나 혹은 한 개
5 .. 8 5 ~ 8개
5,6 5 혹은 6
위에서 보는 것과 같이 ‘..’은 범위를 나타내고, ‘,’는 ‘또는’을 의미합니다. Rose에서는 Role Detail 탭에서 Multiplicity Indicator를 설정할 수 있을 것입니다. 유의하실 것은 ‘*’ 심볼 대신에 ‘n’을 쓴다는 점입니다. 이를 적용하면 그림 11-2와 같이 나타납니다.
그림 11-2. Association의 Multiplicity Indicators
| 1 .0 Relationship이란? |
| 2 .0 Association Relationship |
| 0 Aggregation Relationship |
| 4 .0 Relationship의 선택? 및 Reflexive Relationship |
| |
Aggregation Relationship과 Association Relationship은 전혀 별개의 것은 아닙니다. Aggregation Relationship역시 의미상 연결 관계를 지닌다는 점에서 특수한 Association Relationship으로 분류할 수 있을 것입니다. 아무튼 Aggregation Relationship은 하나의 클래스가 다른 하나의 클래스에 속하거나 포함하는 관계입니다.
Aggregation Relationship은 “part-of”관계, 포함관계 혹은 집합연관이라는 말들로도 불립니다. 두 클래스가 Aggregation Relationship의 관계에 있을 때는 한쪽이 다른 한쪽의 클래스를 포함하고 있는 것과 동시에 한쪽 클래스가 다른 클래스의 일부가 되어 포함되어 지기 때문이죠.
그림 11-3은 Aggregation Relationship의 UML 표기법입니다.
그림 11-3. Aggregation Relationship의 UML 표기법
| 1 .0 Relationship이란? |
| 2 .0 Association Relationship |
| 3 .0 Aggregation Relationship |
| 0 Relationship의 선택? 및 Reflexive Relationship |
| |
동일한 클래스가 있다고 참여한다고 해도 Relationship의 유형이 반드시 같은 것은 아닙니다. 각각이 처한 환경 혹은 문맥(Context)에 따라서 클래스 사이의 관계도 달라질 것입니다.
가령, 도서관과 책이라는 두 개의 클래스가 있다고 가정해봅시다. 만일 도서관리 프로그램의 경우라면 도서관 클래스와 책 클래스는 Aggregation Relationship을 갖게 될 것입니다.
반면에 출판사 입장에서 책을 공급하는 도서관을 관리하는 프로그램이라고 한다면, 도서관과 책 클래스는 Aggregation Relationship 관계보다는 Association Relationship을 갖는 것이 일반적일 수 있습니다.
적절한 예가 될지는 모르겠습니다만 아마 다들 이해하셨으리라 믿어집니다. 중요한 것은 이렇게 Relationship이라는 것은 해당 업무 영역(Domain)에 따라 정해지는 것이라는 점입니다.
Reflexive Relationship
동일한 클래스의 복수의 객체가 서로 관계를 갖는 경우가 있습니다. 가령, 선수과목을 생각해보죠. 선수과목 아시죠? ’UML’이라는 과목을 들으려면 ‘자바’ 과목을 먼저 들어야 한다는 식의 학교 규정에 따라 미리 들어야 할 과목을 선수과목이라고 하죠.^^;
선수과목의 경우 하나의 선수과목에 또 다른 선수과목이 있을 수 있습니다. 가령, ‘OOAD’라는 과목을 들으려면 ‘UML’을 먼저 수강했어야 한다면, ‘UML’이라는 선수과목이 ‘자바’라는 또 다른 선수과목과 Association Relationship을 갖게 되는 것입니다.
이러한 관계를 Reflexive Relationship이라고 합니다. 그림 11-4는 Reflexive Relationship의 UML 표기법입니다.
그림 11-4. Reflexive Relationship의 UML 표기법
| 0 반복적인 개발에 대한 이해 |
| 2 .0 Waterfall Development와 Iterative Development |
| 3 .0 요약 |
| |
이번 장은 Behavior와 Structure를 배울 차례인데 순서대로 강좌를 따라오신 분이라면 상당히 머리가 복잡할 수 있을 것 같아서요. 저도 그랬고, 사실 아직도 혼란스럽거든요. 방법론에 대해 거의 언급함이 없이 UML 자체만 배우다 보니 도대체 이걸 왜 하는가 하는 의문을 가지게 되는 독자님들도 계실 듯 합니다. 그래서 이때쯤 객체지향 방법론의 가장 특징적인 점인 Iterative Development 즉, 반복적인 개발에 대해 언급하고자 합니다.
반복적인 개발에 대한 이해
객체 지향적인 개발은 대체로 반복적인 방법을 채택합니다. 폭포수 모형 혹은 Waterfall Model이란 것을 들어보셨나요? 분석을 다 하고 나서, 설계를 하고, 그리고 구현을 하는 식으로 일목요연하게 단순하게 개발을 해나가는 방법을 모형화 것입니다.
이러한 방법은 이해하기에는 수월하지만 많은 문제점을 드러냈습니다. 그 중 하나가 고객의 요구를 제대로 파악하지 못해서 생기는 점이죠. 고객이 실제 프로그램을 보지 않은 상태에서 프로그램이 어떻게 동작했으면 좋겠다고 상상하는 일은 쉽지 않습니다.
결국 다 만들고 나서 보니 고객이 자신이 원하는 어떤 기능이 빠져있는 것을 발견하고는 이를 요청할 수 있습니다. 그런데 대부분의 경우 그러한 기능을 추가하려면 상당부분 수정이 필요한 경우가 비일비재합니다.
그래도 고객의 요구에는 맞춰야 하니 임시방편으로 해당 기능을 추가해주고, 또 그렇게 되면 자연히 처음의 설계 의도와 달라져서 유지보수가 어렵게 되는 것이죠. 아래의 그림은 강좌 초반에 보여드렸던 RUP의 개발 공정에 관한 그림입니다.
그림 12-1. RUP의 개발 공정
전에도 말씀 드린 것처럼 RUP는 대표적인 객체지향 개발 방법론입니다. RUP에 대해서 잠시 살펴보겠습니다. RUP 자체에 대해 배우고자 함이 아니라, 이를 통해서 반복적인 개발이 왜 필요하고, 어떤 흐름으로 진행되는지를 살펴보자는 것이죠.
우선 왼쪽의 Workflows 구분을 봅시다. 상단은 Process Workflows라고 이름이 붙여져 있고, 아래쪽은 Supporting Workflows라고 명명되어 있네요. Process Workflows는 또 다른 말로 Core Workflows라고도 합니다. 실제 프로젝트 수행의 핵심적이 부분이 되는 일들이죠.
Supporting Workflows는 프로젝트 수행 과정에서 환경적인 측면을 관리하는 일들입니다. 가령, Management라는 workflow는 프로젝트 관리를 의미하는 것이구요. Configuration Management는 최근 부각되고 있는 형상관리 이고, Environment라면 개발자들의 작업공간이나 개발 중간의 결과물에 대한 저장공간과 같은 제반 사항들에 대한 지원을 의미하죠.
Supporting Workflows는 본 강좌와는 크게 관계가 없으니 차치하도록 하구요. Process Workflows 부분을 살펴보죠. 그림 12-2는 RUP에서 Process Workflows만을 보여줍니다.
그림 12-2. RUP의 개발 공정
우선 반복적인 개발에 대해 이해하기에 앞서서 무성한 용어들에 대해 간단히 알아야 할 것 같습니다. Business Modeling이란 것은 업무를 명확히 하는 것입니다. 고객이 무엇을 하는지 명확해야 만들고자 하는 프로그램이 무엇을 할지 알 수 있는 것이니까요.
Requirements는 요구사항을 파악하는 것이죠. Analysis & Design은 말 그대로 분석 및 설계이고, Implements는 구현, Test가 있고, 마지막으로 Deployment는 설치 혹은 배포하는 과정입니다.
| 1 .0 반복적인 개발에 대한 이해 |
| 0 Waterfall Development와 Iterative Development |
| 3 .0 요약 |
| |
Waterfall Development와 Iterative Development
이해를 돕기 위해 Waterfall Model을 잠시 살펴 보죠. 그림 12-3은 Waterfall Model입니다.
그림 12-3. Waterfall Model
RUP의 Process Workflows를 위에서 아래로 본 것과 상당히 유사하다는 것을 눈치 채셨나요? 그러나 RUP에서는 시간의 흐름을 표현한 것이 위에서 아래가 아니라 좌에서 우로 가는 방향의 Phases입니다. Inception -> Elaboration -> Construction -> Transition의 순서로 개발이 진행되어 가는 것이죠.
Waterfall 방식에서는 순서대로 했던 것을 RUP와 같은 반복적인 개발에서는 섞어서 하게 됩니다. 이러한 것이 어떤 의미를 갖을까요? 다음 그림을 볼까요?
그림 12-4. Iterative Development의 특징
그래프의 두께는 일의 양을 표현합니다. Requirements와 Analysis & Design은 거의 유사한 시기에 행해지는 것을 볼 수 있습니다. 과거 Waterfall 방식에서 고객의 요구사항을 먼저 다 수집해놓고 분석과 설계를 하게 되어 수집하지 않았던 요구사항은 고려할 수 없었습니다.
그러나, Iterative Development를 하게 되면 요구사항을 토대로 분석과 설계를 하다가 미처 고객이 생각하지 못했던 요구사항을 고려해 볼 수 있죠.
그러한 분석 및 설계한 내용을 토대로 다시 요구사항을 수정하면서 좀더 완전하게 요구사항을 수집할 수 있게 된 것입니다. 또한, 요구사항 수집, 분석 및 설계가 끝나기도 전에 이미 구현을 합니다. 구현된 결과를 보면서 고객의 요구사항과 분석, 설계한 내용이 제대로 실현되어 가는지를 검증할 수 있고, 문제가 발생하면 이를 적용하여 구현 초기에 수정이 가능하게 되는 것이죠.
이렇게 유연하고 반복적인 개발을 통해서 실패에 대한 위험을 줄이는 것입니다. 또한, 고객과 의사소통이 중요하게 되고, 중간 결과가 일찍 나오기 때문에 고객과의 신뢰 측면에서도 매우 좋다고 할 수 있습니다.
이제 정리를 해야겠군요. RUP의 경우도 시간의 흐름과 일의 비중을 잘 보면 대체로 Waterfall 형태를 완전히 벗어나지는 않은 것을 볼 수 있습니다. 결국 완전히 새로운 개발 방법론이 아니라, 과거의 경험을 토대로 새로운 것을 추구해 놓은 것이라고 할 수 있습니다. 그림 12-5의 대각선으로 그어진 화살표를 보면 Waterfall과 같음을 알 수 있습니다.
그림 12-5. RUP 와 Waterfall
| 1 .0 반복적인 개발에 대한 이해 |
| 2 .0 Waterfall Development와 Iterative Development |
| 0 요약 |
| |
요약
왜 반복적인 개발을 하는지 이해하셨나요? 정 이해가 안가셨으면 한마디로 요약을 해드리죠. Waterfall(폭포)는 꺼꾸로 흐르지 않습니다. 한방에 모든 것을 거는 것이죠. 극단적으로 말씀 드리면 ‘모 아니면 도’가 될 수도 있습니다. 실패의 위험이 많다는 것이죠.
반대로 반복적인 개발은 중간중간 잘 되어 가고 있는 점검을 해보면서 조심스럽게 전진해 나가는 방식입니다. 이제는 다들 이해하셨겠죠? 이보다 더 쉬울 순 없다!
갑작스레 방법론을 언급한 것은 강좌의 순서가 혼란스럽다는 느낌을 받으시는 분들이 많을 것입니다. 대체로 개발 순서에 맞춘 것이라 그렇습니다. 클래스를 할 요량이면 클래스를 쭉 하고, 객체에 대해서 하려면 객체에 대한 얘기를 다 하고 넘어가야지 마구 왔다 갔다 하는 거 아니냐 하는 느낌을 받으신 분도 있을 것입니다.
중도에 포기하고 읽기를 그만 두신 독자님들이 더 많다고 생각이 됩니다. 그래서 방법론을 언급했습니다. 이러한 개발 하에서 UML도 여러 개의 다이어그램이 병렬적으로 서로 도와 가면서 진행해 나가는 것입니다.
유스케이스 따로, 클래스 다이어그램 따로, 객체의 상호작용을 보여주는 다이어그램이 독립적으로 그려지는 것이 아니라, 이렇듯 다른 다이어그램을 그려나가는 과정에서 미처 알지 못했던 것들을 알아 가고, 그러면서 서로 하나의 시스템 혹은 프로그램을 구체화 시켜 나가는 과정입니다.
| 0 Behavior and Structure |
| 2 .0 Behavior and Structure의 표현 |
| 3 .0 Class Refinement |
| |
지난 강좌에서는 iterative development에 대해 이야기 해 보았습니다. 이번에는 객체의 Behavior와 Structure를 찾아서 클래스의 속성과 operations를 뽑아 보도록 하죠. 이전까지 모델링 한 클래스가 뼈대라고 하면 거기에 살을 붙이는 것이라고 할 수 있습니다.
Behavior and Structure
클래스는 책임을 내포하고 있습니다. 시스템 개발 과정에서 대개 요구사항을 담고 있는 유즈케이스의 기능을 시스템을 구성하는 클래스에 나누어줘야 한다는 것이죠. 가령, 시스템을 전통적인 가정에 빗대어 본다면 ‘아버지’라는 클래스는 ‘가장의 역할’이라는 이름으로 뭉뚱그려진 어떤 책임들을 갖고 있죠. 중요한 결정을 한다던가 돈을 벌어 온다던가 하는 식이죠.
그리고, ‘어머니’라는 클래스는 ‘주부의 역할’이라는 이름으로, 아이들을 교육을 책임지거나 살림을 도맡게 되죠. 물론, 고리타분한 사고방식에서 나온 모습이니까 예제의 내용으로 너무 분개하지 마시고…^^;
클래스가 그런 책임을 내포하게 되고, 클래스가 실체와 되어서 객체가 되고, 이들 객체가 클래스에서 정의한 책임들을 잘 수행하게 된다면 시스템이 잘 돌아가겠죠. 우리나라의 가정(시스템)이 잘 돌아가려면 가족 구성원(객체)들이 각자 자기가 맡은 역할(클래스의 책임)을 다 해야 하는 것과 같은 이치죠. ‘수신제가 치국평천하’
한번에 필요한 모든 클래스를 찾아내고, 이들의 Behavior와 Structure를 다 추가 시킨다는 것은 힘든 일입니다. 자신이 뻔히 아는 일이라면 몰라도 모르는 분야에 대해서 시스템을 개발할 때는 더욱 그렇겠죠. 그래서 지난 강좌에 말씀 드린 것과 같이 반복적으로 이러한 작업을 해나갑니다.
클래스의 책임을 결국 operation들로 수행되게 되죠. 따라서, 클래스의 책임은 각각의 operation에 나눠지게 됩니다. 예를 들어, 강좌를 표현하는 CourseOffering 클래스를 생각해볼까요? CourseOffering은 기본적으로 학생을 추가하거나 제거해야 하는 책임을 갖고 있습니다. 이러한 책임은 궁극적으로 addStudent와 removeStudent와 같은 operation들로 수행이 되는 것이죠.
그림 13-1. 클래스의 attributes와 operations
객체의 구조(structure)는 속성(attributes)로 표현됩니다. 각각의 속성들은 또한 클래스의 멤버 데이터로 정의가 되지요. 클래스가 객체로 인스턴스가 만들어지면 각각의 속성들은 고유한 값을 같게 됩니다. 여기서 고유하다는 것은 객체마다 하나의 값을 갖게 된다는 의미입니다. 동일한 클래스에 속한 객체들의 동일한 속성에 대한 값이 전부 달라야 한다는 말은 아닙니다. ^^;
| 1 .0 Behavior and Structure |
| 0 Behavior and Structure의 표현 |
| 3 .0 Class Refinement |
| |
Behavior and Structure의 표현
UML에서 Behavior and Structure의 이름은 기호나 코드가 아닌 자연어(일상적인 언어)를 사용하게 됩니다. 따라서, 모델링을 수행하는 사람마다 천차만별의 이름을 붙일 수 있습니다. 요즘처럼 개성이 강한 시대에는 정말 황당한 이름도 볼 수 있을 것 같네요.^^;
그러나, 대부분의 프로젝트 혹은 시스템 개발은 공동작업이기 때문에 이름을 정하는 일정한 규칙이 필요하게 됩니다. 스타일 가이드(style guide)라고도 하고, 더러는 네이밍 컨벤션(Naming Convention)이라는 말을 사용하기도 합니다.
특별하게 UML 자체에서 규정하는 규칙이 있다고 하기 보다는 특정 집단에서 정하게 되는 것이죠. 그러나 대부분 객체지향 언어에서 지켜져 왔던 네이밍 컨벤션을 따르는 것이 좋겠죠. 다들 아시겠지만 혹시 모르시는 분들을 위해 아래 정리를 좀 해놓죠.
- 클래스 이름은 대문자로 시작한다.
- 속성(attribute)이나 operation의 이름은 소문자로 시작한다.
- 단어가 이어질 때는 뒤 따라오는 단어의 첫번째 알파벳을 대문자로 한다.
- 클래스와 속성은 명사 표현을 사용한다.
- Operation은 동사 표현을 사용한다.
이렇게 스타일 가이드를 만들어 두고 이를 따르게 되면 어떤 장점이 있을까요? 다음의 세 가지 장점을 열거해 볼 수 있습니다.
- 모델과 코드의 일관성(consistency)을 유지할 수 있다.
- 모델과 코드의 가독성(readability)을 높인다.
- 모델과 코드의 유지보수가 용이(maintainability)하다.
이런 장점들이 궁극적으로는 프로젝트 혹은 개발과정의 생산성(productivity)을 높여 줍니다. 시간과 비용을 줄일 수 있다는 것이죠. 개발 경험이 있으신 분들은 쉽게 알 수 있으시리라 생각이 드네요. 제가 아는 분이 프로젝트 경력이 8년이라는데 표준화가 제일 중요하더란 말을 하시더군요.
요즘 자바 관련 사이트에 보면 개발 프레임워크에 대한 이야기들이 심심치 않게 오르고 있더군요. RUP도 하나의 개발 프레임워크라고 볼 수 있죠. 요즘 미국에서 선풍적인 인기를 구가한다는 XP도 그렇구요. 얼마 전에 ‘자바 메가트렌드’에 갔었는데 L사의 선임연구원이라는 분이 자사의 방법론 구체화 과정에 대해 설명하는 세션을 들었습니다.
그림 13-2. XP 관련 서적
개발 경험이 별로 없던 저였지만 모델 주도의 개발을 해보려다가 쓰디쓴 경험을 해서 그런지 뼈에 사무치는 경험담을 해주시더군요. L사는 모델 주도로 개발을 해보다가 자사에 맞지 않는다는 것을 깨닫고는 XP를 도입해 자사에 맞게 정제해 나가고 있었습니다.
종종 개발 방법론이나 프로세스에 대해 질문을 하시는 분들이 계셔서 이참에 좀 더 얘기를 드리면 RUP에 대한 환상부터 버리시길 바랍니다. RUP는 거대한 프로젝트에 적합한 방법론이고, 웹에서 쉽게 가르쳐 줄 수 있는 부분이 아닌 것 같습니다. 학부 때도 소프트웨어공학을 배우고, 현재도 또 소프트웨어공학을 객체지향 관점에서 다시 공부하고 있는 제 입장에서 느껴지는 것은 좋은 이론은 배우되 반드시 소화를 해야 하겠다는 생각이 들더군요.
RUP나 XP가 좋은 모델이 될 수는 있지만 이를 그대로 활용하려면 일단 사고방식부터 미국인들처럼 바꿔야 하겠죠? 이론을 답습은 하되 “자기화”하는 과정 혹은 “창조적인 재해석”이 필요하다 하겠습니다.
그림 13-3. RUP Builder 화면
| 1 .0 Behavior and Structure |
| 2 .0 Behavior and Structure의 표현 |
| 0 Class Refinement |
| |
Class Refinement
객체의 Behavior and Structure를 뽑아내고 이를 통해 적절하게 클래스를 정의하다 보면 이전의 뽑아낸 클래스가 문제가 있음을 발견하기도 합니다. 하나의 클래스로 정의해야 할 것을 특정 클래스의 속성들로 섞어 두기도 하고, 반대로 속성에 지나지 않을 것을 클래스로 뽑아놓은 것들도 있죠.
이런 문제점들은 클래스를 찾는 과정에서 보다 객체의 Behavior and Structure를 뽑아내는 과정에서 더 잘 드러나기 마련입니다. 이러한 점이 지난 강좌에 언급한 반복적인 개발의 장점이라고 할 수 있습니다. 속성과 operations이 없이 개념적인 수준에서만 찾아낸 클래스(Conceptual Class)들에 살을 붙여 나가는 과정에서 이들이 더욱 더 정제되는 것이죠.
이러한 정제 과정 역시 한번으로 끝나는 것이 아니라, 계속적으로 반복되면서 진화하게 되는 것이죠. 이런 이유로 개발 과정에서 나타나는 클래스들은 ‘Candidate Class’나 ‘Class Draft’라고 부르기도 합니다.
| 0 객체 사이의 메시지 |
| 2 .0 Operation 생성 |
| |
지난 강좌에서는 객체의 behavior와 structure가 클래스에 어떤 영향을 미치는지를 살펴보고, behavior와 structure 각각에 대해 살펴 보았습니다. 찾아낸 behavior는 클래스의 operation을 생성하게 된다고 했죠. 마찬가지로 여러분들이 찾아낸 structure는 클래스의 속성이 되지요. 이번 강좌에서는 이들을 어떻게 만들어 내는지 살펴 보도록 하겠습니다.
객체 사이의 메시지
sequence diagram이나 collaboration diagram과 같은 객체의 상호작용을 표현한 다이어그램에 나타나는 메시지는 일반적으로 메시지를 받는 객체의 operation이 되는 경우가 많습니다. 전에도 언급했었지만 이러한 상호작용은 메시지를 보내고 받는 일로 이뤄지는데 메시지를 보내는 일이란 받는 객체의 operation을 호출하는 것이 되죠.
그림 14-1. 메시지를 보내고 받는 객체의 표현
그러나, interaction diagram에 나타나는 모든 메시지가 operation이 되지는 않습니다. 일반적으로 Boundary 클래스와 액터가 주고 받는 메시지는 객체 사이의 메시지와는 구분해서 다룰 필요가 있습니다.
액터가 사람인 경우와 연동 시스템인 경우로 나눠서 살펴 봅시다. 우선, 액터가 사람인 경우에는 메시지는 액터가 GUI 콘트롤을 선택하는 경우가 일반적입니다. 가령, 로그인 하는 경우를 생각해 보면 액터가 자신의 ID와 패스워드를 타이핑하고 ‘확인’과 같은 버튼을 누르는 것으로 메시지 전달이 되지요.
이런 경우는 메시지가 operation이 되지 않고, 사용자가 버튼을 누르는 것이 메시지 전달이 되는 것이죠. 따라서, operation이 되는 것이 아니라 사용자 매뉴얼 같은 곳에 기록해두어야 합니다.
그림 14-2. 액터와 객체 사이의 메시지 교환
그렇다면 액터가 연동하는 시스템인 경우는 어떻게 될까요? 대부분의 경우 이종의 시스템은 다른 메커니즘을 갖게 됩니다. 즉, 작동 방식이 틀리게 되는 것이죠. 따라서, 프로토콜이 다른 경우가 대부분입니다. 이러한 경우는 메시지가 프로토콜을 처리하는 클래스가 됩니다. 프로토콜 처리기(Protocol Handler)가 필요한 것이죠. 이미 Boundary 클래스를 뽑아내면서 프로토콜 처리기를 뽑아낸 경우는 예외가 되겠죠.
| 1 .0 객체 사이의 메시지 |
| 0 Operation 생성 |
| |
Operation 생성
Operation 역시 자연어를 이용한 작명을 하기 때문에 이름을 지을 때 신중한 것이 좋습니다. 개발팀 사이에서 일정한 네이밍 룰(Naming Rule)은 정하는 것이 좋겠죠. 객체지향 언어에서 쓰이는 일반적인 네이밍 컨벤션(Naming Convention)은 여기서 언급하지 않겠습니다. 그 외에 두 가지 사항 정도를 염두에 두시길 바랍니다.
첫째는 operation은 클래스의 멤버이기 때문에 해당 클래스가 수행하게 되는 것입니다. 따라서, 해당 클래스의 입장에서 능동 표현이 되어야 적합합니다. 클래스가 무엇 무엇을 해야 한다는 식이면 곤란하다는 것입니다. 또한, operation은 명사보다는 동사 표현이 적합하겠죠? 동사, 동사구나 동사+목적어 형태가 적절할 듯 하네요.
둘째로 operation은 구현 내용을 반영하는 이름은 적절하지 않습니다. 구현은 자주 변할 수 있기 때문이죠.
그림 14-3 Operation 만들기
그림14-3에서 보는 바와 같이 메시지를 선택한 후 오른쪽 마우스를 클릭하면 팝업 메뉴에서
그림 14-4 Operation 만들기
옵션을 선택하면 그림 14-4과 같이 specification window가 나타납니다. 이제 적절한 이름을 입력합니다. Operation을 만드는 것은 collaboration diagram에서는 물론이고 sequence diagram에서도 가능합니다.
Collaboration diagram이나 interaction diagram을 보고 operation을 찾아내는 방법을 “Collaboration”을 이용한 유스케이스의 Realization이라고 합니다. 사용자가 원하는 유스케이스를 통해서 클래스를 찾고, 클래스의 속성과 행위를 찾겠다는 접근 방식이죠.
그러나, 때로는 업무의 분석과 설계 과정에서 직관적으로 operation을 찾아낼 수도 있습니다. 그런 경우는 그림 14-5와 같이 브라우저에서 해당 클래스를 더블클릭하여 specification window를 나타낸 후 operation을 입력할 수도 있습니다.
그림 14-5 Class Specification 창에서 operation 추가하기
이렇게 생성한 operation은 interaction diagram에 묘사되는 메시지와 연관을 갖지 않습니다. 직관적으로 뽑아낸 operation을 특정 메시지와 연결시키는 일은 간단합니다. 메시지를 받는 클래스에 operation을 갖고 있는 경우 메시지에서 오른쪽 마우스 클릭을 할 때 팝업에 해당 operation이 나타납니다.
그림 14-6 operation과 메시지의 연결
무결성 유지를 위해서는 메시지와 연결이 안 되는 operation이 없어야 올바른 모델링이라는 생각이 언뜻 떠오를 수도 있겠죠. 그러나, 반드시 모든 operation이 메시지와 연결될 필요는 없습니다. 편의를 위해 객체 내부에서 사용되는 operation 들도 있으니까요.
| 0 Operation 상세화 |
| 2 .0 속성 추가하기 |
| |
지난 강좌에는 Operation을 찾아내는 것까지 살펴 보았습니다. 이어서 Operation에 대해 좀 더 알아본 뒤에 Attribute를 추가하는 것을 살펴 보도록 하죠.
Operation 상세화
객체 간에 오고 가는 메시지는 결국 서비스를 하는 Operation이 됩니다. 향후에 응용 프로그램의 기능도 결국을 이들 객체 사이에서 호출하거나 호출 되는 Operation을 기반으로 제공되는 것이죠. 반면에 객체 내부에서 사용할 목적으로 쓰이는 Operation도 있었습니다.
여기까지의 단계에서는 매우 추상적으로 Operation을 찾아낸 것이죠. 이러한 Operation을 점차 구체화 시키는 과정이 차츰차츰 반복됩니다.(Iterative Development!!) 상세화는 보통 두 가지를 생각해 볼 수 있습니다.
첫째는 Operation에 대한 설명을 기술하는 것이고, 둘째는 Operation Signature를 정의하는 것이죠. Operation Signature란 Operation의 이름과 입출력 데이터 들을 함께 가리키는 말입니다.
그림 15-1. 브라우저의 Operation
먼저 Operation에 설명을 기술하는 것을 배워보죠. Rose에서 Operation에 설명을 기술하는 것은 다른 모델링 요소의 경우와 일치합니다. 그림 15-1에 보이는 것처럼 브라우저에서 Operation을 선택하고, 오른쪽 마우스를 클릭하면 나타나는 메뉴에서 Open Specification을 선택합니다. Operation을 더블클릭해도 동일한 효과를 냅니다.
그림 15-2. Operation Specification Window
그림 15-2는 Operation Specification Window의 모습입니다. Documentation에 설명을 기술합니다. 설명을 기술할 때 유의할 점은 해당 Operation이 무엇(What)을 해야 하는지를 명시해야 합니다. Operation의 목적을 잃어버리지 않기 위한 것이죠.
기술적인 백그라운드를 가진 개발자들이 가장 오류를 범하기 쉬운 부분이 바로 분석 과정에서 “기술 지향적(Technology-Oriented) “으로 문제를 바라볼 수 있다는 점입니다. 그럴 경우에 자꾸 근원적인 문제를 해결하는 쪽이 아니라 자꾸만 소스코드를 향해 달려(?) 가려고 하기 쉽다고 많은 전문가들이 지적을 하더군요.
Operation의 설명을 기록하는 과정에서도 기술 지향적인 개발자들은 입출력 값을 중요시 여겨 이것만 기록하려고 하기도 합니다. 그러나, 입출력 값은 Operation Specification Window에서 이를 적절히 정의할 수 있는 곳이 존재합니다. Operation은 입력 값은 Arguments의 형태를 띄어 Detail Tab에서 찾아볼 수 있고, 출력 값은 그림 15-2에서 나타나는 Return Type에서 선택이 가능합니다. 물론, 편의상 입출력 값을 기술할 수 있습니다만 중요한 것은 Operation이 무엇을 하기 위한 것이냐는 질문에 대한 대답이 Documentation에 꼭 기술되어 있어야 한다는 사실이죠.
이번에는 Operation의 Signature를 어떻게 찾아내는지 살펴 보도록 하겠습니다. 물론 Operation Signature를 직관적으로 도출할 수도 있습니다. 경험이 많은 개발자이거나 익숙한 도메인에서 수행하는 개발인 경우에는 이러한 일이 많겠죠.
그러나, 그렇지 못한 경우에는 클래스의 Relationship이 도움을 줍니다. 개발이 진척되면서 Relationship도 정제(refinement)되는 과정을 거치게 되죠. 그러면서 Relationship은 일반화 혹은 상속 관계가 되는 경우가 아닌 경우에는 대부분 Operation Signature의 많은 부분을 보여줍니다.
그림 15-3. System Architecture를 바라보는 4+1 View
객체지향 분석 및 설계 과정에서 가장 힘든 것 중에 하나가 바로 ‘딱딱 떨어지지’ 않는다는 점입니다. 복잡한 산수 계산을 할 때에도 딱딱 맞아 떨어지는 경우는 수월한데 나누기 했더니 몫이 소수점 몇 자리까지 내려가고 하면 골치가 아픕니다. 과거의 방법론이나 기술은 딱딱 떨어지게끔 만들어졌습니다. 방법론만 해도 객체지향 방법론에 비하면 따라 하기 수월했었죠. 그런데 그러한 기술이나 개방 방법론으로는 매우 복잡한 문제를 해결하는데 한계가 보였다고 합니다.
그래서, 객체지향 기술이 나왔고, 이에 맞는 방법론이 등장했죠. 객체지향 방법론에서는 ‘두루두루 둘러봐서’ 알아내는 전략을 취합니다. 그림 15-3는 Rational의 Philippe Krutchten이 복잡한 시스템을 바라보는 관점으로 제시한 ‘4+1 Model View’입니다.
복잡한 문제는 한가지 관점으로만 봐서는 해결이 안 된다는 논리죠. 동의 하시나요? 현행범을 잡은 경우에 형사는 고민을 하지 않지만, 미지에 빠진 사건을 조사하는 형사는 다양한 관점에서 사건을 바라보게 되죠.
일단 사건 현장을 조사하며 단서를 찾기도 하고, 목격자의 진술을 들어보기도 하고, 법의학의 도움을 받기도 하죠. 용의자가 나타나면 심문을 하기도 하지만, 과거의 범죄 기록을 살피기도 하죠.
소프트웨어 역시 매우 복잡한 경우에는 다양한 관점을 동원함으로써 한쪽에서 못 봤던 것을 다른 관점으로 바라보면서 발견해낼 수 있습니다. 여기서 이 얘기를 왜 장황하게 늘어놓느냐고 물으실 분들이 계실지 모르겠네요.
Operation을 살피다가 돌연 클래스의 Relationship을 논하는데 마치 점프를 하는 느낌을 받으실 분들이 계실 듯 해서죠. 동적인 성향의 Sequence Diagram에서 메시지를 찾아낸 것을 정적인 클래스에 다시 적용시키게 되는 것처럼 다양한 관점을 아울러서 개발이 진척되는 것을 이해하시라는 의도입니다.
저도 이 부분이 가장 이해하기 힘들었고, 많은 분들이 이 부분을 가장 힘들어 하십니다만 객체 지향 분석과 설계의 묘미는 공교롭게도 바로 여기에 있는 듯 합니다. 복잡한 일을 다양한 관점을 통해 바라봄으로 해서 해결한다. 그러나, 최종 산출물은 단일한 결과로 존재해야 합니다. 다양한 관점의 이면에는 통합성(Integration)이 존재한다는 것 또한 잊으시면 안됩니다.
| 1 .0 Operation 상세화 |
| 0 속성 추가하기 |
| |
속성 추가하기
속성은 Operation처럼 Sequence Diagram이나 여타 다이어그램에 명시적으로 드러나지는 않습니다. 오히려 여기저기 많이 산재해 있죠. 해당 업무를 잘 이해해야만 속성을 제대로 뽑아낼 수 있는데 그런 면에서 쉬운 일은 아니죠. 요구사항을 정의한 문서들이나 이벤트의 흐름을 기술한 시나리오 내지는 이를 다이어그램으로 표현한 Activity Diagram 등이 좋은 소스가 될 수 있겠죠.
그림 15-4. 클래스에 속성(Attribute) 추가하기
클래스에 속성(attribute)을 추가하는 방법에도 여러 가지가 있습니다. 우선 브라우저에서 클래스를 선택한 후 그림 14-1와 같이 팝업메뉴에서 [New]-[Attribute] 순으로 선택한 후에 이름을 입력하여 생성할 수도 있습니다. 다른 방법으로는 클래스를 더블 클릭하여 나타나는 Class Specification Window에서 Attributes탭을 선택한 뒤에 추가하는 방법도 존재합니다.
| 0 속성 설명하기 |
| 2 .0 클래스 다이어그램에서 속성과 오퍼레이션 |
| |
지난 강좌까지 학습을 하셨다면 클래스에 Operation과 Attribute를 추가하실 수 있으시겠죠? Behavior and Structure라는 제목으로 오랜 시간을 할애했습니다. 그만큼 중요한 내용이라 여겨집니다. 이번 강좌에서는 마무리를 해보죠.
속성 설명하기
남의 나라 기술을 차용해서 쓰는 입장에 대해 딱히 생각해 본 적이 없었습니다. 그런데 글을 쓰게 되면서 종종 답답한 마음이 들더군요. 바로 위의 글만 해도 Attribute라고 했다가 속성이라고 썼다가.
속성이란 말로 Attribute란 단어를 어느 정도 대체할 수 있어서 번역한 말을 썼지만 이번 강좌의 첫번째 문장을 보세요. 오퍼레이션(Operation)을 우리말로 번역할 적당한 단어가 없습니다. ‘운영’은 얼토당토않고, ‘연산’도 어색하기 짝이 없죠? 독자님들의 이해를 바랍니다.
속성(Attribute) 역시 다른 모델링 요소처럼 설명을 기술할 수 있습니다. Documentation을 한다고 하죠.
그림 16-1. 속성에 설명을 기술하기
브라우저나 클래스의 Specification Window에서 설명을 기술하고자 하는 속성을 찾아 더블 클릭을 하면 Attribute Specification Window가 나타납니다. 여기에 설명을 기록합니다. 물론, 속성을 선택한 후 브라우저 하단의 Documentation Window에 직접 설명을 기술하는 것도 가능하죠.
기본적으로 Rose에서 Documentation 절차는 모든 모델링 요소에 동일합니다. 사용자 편의를 위해 어찌 보면 아주 기본적인 사항을 잘 지켜준 프로그램이죠. 속성이든 클래스이든 동일한 방법으로 설명을 넣을 수 있습니다.
속성의 설명 시 중요한 사항은 해당 속성이 무엇(What)을 하기 위한 것인지 명확히 기록하는 것입니다. 해당 속성의 데이터 타입이나 제약 사항들은 그림 15-1에서 보이는 바와 같이 정형화된 틀에 맞게 표기하는 것이 좋습니다. Documentation에는 해당 속성이 무언지를 쉽게 알 수 있는 내용을 적어두는 것이 좋겠죠?
그림 16-2. OMG의 MDA
| 1 .0 속성 설명하기 |
| 0 클래스 다이어그램에서 속성과 오퍼레이션 |
| |
클래스 다이어그램에서 속성과 오퍼레이션
처음 모델링을 할 때 자주 오해하는 것이 다이어그램을 작성하기 위해 모델링을 하는 주객이 전도된 경우입니다. 다이어그램은 하나의 뷰(View)에 지나지 않습니다. 시스템을 나타내는 모델의 일면 만을 보여주는 것이죠.
다이어그램이 오히려 복잡한 시스템을 더 잘 모델링 하기 위해 사용되는 것입니다. 아리송하신가요? 여기서 다시 Iterative Development라는 성격이 여실히 보여지네요. 모델을 찾아내기 위해 지금까지 찾아낸 모델을 이용해서 다이어그램을 찾아내고, 다이어그램에 새로운 모델을 추가하면서 전체적이 모델이 갱신되는 것이죠.
모델링을 하면서 ‘어떤 다이어그램을 작성할 필요가 있을까?’하는 정형적인 질문을 누구나 떠올리기 마련입니다. 다이어그램은 필요에 따라 맘껏 그리시면 됩니다. 보지도 않는 다이어그램을 구색을 맞추려고 그릴 필요는 없겠죠.
중요한 것은 시스템을 만들기 전에 시스템에 관한 어느 정도는 구체화 된 실체를 찾아내는 것입니다. 그렇다고 해도 구현을 하기 전까지는 추상적인 것이니까 모델이라고 부르는 것이겠죠.
클래스 다이어그램 역시 여러 가지 용도로 쓰일 수 있습니다. 10강에서인가요? 클래스간의 관계를 표현하려고 사용했었습니다. 그림 16-3과 같은 다이어그램이죠.
그림 16-3. 클래스 다이어그램
그림 16-3의 다이어그램에서는 클래스의 속성이나 오퍼레이션을 보이지 않습니다. 클래스 간의 관계를 보는 것이 목적인 다이어그램에서 모든 클래스의 속성과 오퍼레이션이 나타내어지면 너무 복잡해질 수 있습니다. 용도에 맞는 것이 가장 적합한 다이어그램이 되겠죠.
따라서, 클래스의 속성과 오퍼레이션을 보기 위한 다이어그램을 작성할 수도 있는 일이겠죠. 그림 15-3의 다이어그램에서 관계를 보이지 않게 하고, 속성과 오퍼레이션을 보이게 하는 연습을 해볼까요? 기억하실 것은 다이어그램은 뷰일 뿐이라는 점입니다.
뷰(View)라는 단어에 익숙하지 않은 분들 계신가요? 뷰라는 것은 복사본이라고 생각하시면 수월합니다. 데이터베이스에 익숙하신 분들은 잘 아시겠죠? 다이어그램에서 관계를 없애도 해당 다이어그램에서만 보이지 않을 뿐이라는 것입니다.
메뉴에서 [Query]-[Filter Relationships] 순으로 선택하십시오. 그러면 그림 16-4와 같은 다이얼로그가 나타납니다.
그림 16-4. Relations 다이얼로그
Type 항목에서 None을 선택하시고 OK를 클릭합니다. 관계를 나타내던 선들이 모두 사라졌죠. 이제 클래스들을 선택하시고, 오른쪽 마우스 클릭을 한 후 [Options]-[Show …] 순으로 선택을 하시면 됩니다. 보고 싶지 않으신 경우에는 해당 [Show …] 항목에 체크가 사라지게 하면 되겠죠. 관계를 사라지게 하고, 속성과 오퍼레이션을 나타나게 한 다이어그램이 그림 15-6의 클래스 다이어그램입니다.
그림 16-5. 속성과 오퍼레이션 나타내게 하기
그림 16-6. 속성과 오퍼레이션을 나타낸 클래스 다이어그램
| 0 상속(Inheritance) |
| 2 .0 일반화(Generalization)와 전문화(Specialization) |
| 3 .0 상속도(Inheritance Tree) |
| 4 .0 상속(Inheritance)과 집합(Aggregation) |
| |
이번 시간에는 상속(Inheritance)에 대해 알아보도록 하겠습니다. 객체 지향 모델링에서 상속은 클래스 사이에서 갖는 관계의 일종이죠. 지난 시간까지 클래스들의 주요 속성과 행위를 찾아낸 것이 개별 클래스 수준에서 묘사가 되었다면 상속은 이들을 다시 클래스 단위로 정리하는 것이라고 이해할 수 있습니다.
상속(Inheritance)
상속은 하나 이상의 클래스 사이에서 구조나 행위를 공유하는 관계를 말합니다. “is-a” 관계 혹은 “is-a-kind-of” 관계라고도 하죠. 객체지향 기술에서 기본적인 재사용 메커니즘 중에 하나입니다. 하위 클래스가 상위 클래스를 상속 받으면서 그 속성이나 오퍼레이션들을 모두 이어 받는 것이죠.
객체지향 언어를 잘 모르신다면 사실 상속을 제대로 이해하기도 어렵다는 생각이 드네요. 최근 CBD(Component-Based Development)라고 하는 컴포넌트를 기반으로 하는 재사용 바람이 거세게 불고 있습니다. 객체지향이라는 주류를 놓아 두고도 이러한 기술이 트렌드를 이루는 데는 다 그 나름의 이유가 있겠죠.
상속을 통한 재사용은 이론에서처럼 제대로 적용되지는 못했습니다. 그렇다고 근본적으로 상속을 대체하는 것이 컴포넌트라고 보기는 힘들 것 같습니다. 그저 좀더 좋은 해결책을 찾기 위한 노력이라고 보는 것이 옳겠죠. 아무튼 상속이 좋은 아이디어임에는 틀림없습니다. 상속의 UML 표기법은 그림 17-1과 같습니다.
그림 17-1. 상속의 UML 표기법
UML에서 상속은 특수한 형태의 관계(Relationship)로 분류할 수 있습니다. 일반적인 관계와는 달리 관계의 이름을 붙이지 않고, 역할 이름이나 다중도(multiplicity)를 적용하지 않습니다. 이러한 속성들은 이미 ‘상속’이라는 의미 속에 녹아 들어가 있기 때문입니다.
상속 관계를 갖는 두 클래스의 관계를 많은 경우 부모와 자식 사이로 비유하는 표현을 사용합니다. 이에 따라 상위 클래스(super class)를 부모 클래스(parent class), 하위 클래스(subclass)를 자식 클래스(child class)라고도 하죠.
| 1 .0 상속(Inheritance) |
| 0 일반화(Generalization)와 전문화(Specialization) |
| 3 .0 상속도(Inheritance Tree) |
| 4 .0 상속(Inheritance)과 집합(Aggregation) |
| |
일반화(Generalization)와 전문화(Specialization)
복잡한 시스템을 분석하고 설계할 때 상속 관계를 알아내는 일은 쉽지 않습니다. 특히 익숙하지 않은 분야의 일이라면 더욱 그러하겠죠. 상속 관계를 끌어내는 방법 중에 하나로 일반화(generalization)가 있습니다.
다수의 클래스 사이의 공통점을 발견하는 방법입니다. 공통점이 발견된 클래스들 사이에서 공통점은 상위 클래스로 정의하고, 이를 제외한 각각의 차이점만 모아서 개별적인 클래스들을 정의할 수가 있겠죠.
월드컵이 다가옴에 따라 우리나라 대표팀의 베스트11에 대한 관심과 예상들이 많습니다. 그러나, ‘상황에 따라 다른’ 전략을 보여줄 것이라는 것이 아직은 중론인 것 같습니다. 상황에 따라 다르다. 참 묘한 말입니다.
축구에서 정해진 포지션이라면 심판뿐이라고도 말할 수 있을 것입니다. 공격 성향의 축구를 하다 보니 종종 골키퍼가 최후방 수비수의 역할도 하니까요. 마찬가지로 모델링에서도 딱히 정답이 있는 경우는 극히 일부에 지나지 않습니다.
예를 들어, Student 클래스와 Professor 클래스가 있다고 해봅시다. 이들 사이에 공통점이 존재할까요? 절대적인 정답은 존재하지 않습니다. 상황에 따라, 구현할 시스템이 어떠한 영역(Domain)에서 사용되느냐에 따라서 모델은 달라질 것입니다.
도움이 될만한 기법이 있다면 ‘언어의 모호성’에 각별히 주의를 하셔야 한다는 점입니다. 가령, 의미는 같은데 다른 단어를 사용한 경우나 의미가 다른데 같은 단어를 사용하는 경우가 있습니다. 특히 팀으로 작업을 하는 경우 발생하기 쉬운 일이죠. 이런 경우 프로젝트 용어집 혹은 프로젝트 사전 등을 이용하여 쓰이는 말을 표준화할 필요가 있습니다.
일반화와 반대로 모호한 클래스를 명확하게 하기 위해 하위 클래스를 생성하는 경우가 있습니다. 이를 전문화(specialization)이라고 합니다. 일반화와 전문화 중에 어떤 방법이 더 좋다고 할 수는 없습니다. 자신에게 알맞은 방법을 적절히 쓰면서 상속 관계를 철저히 분석하는 것이 목표일 뿐이죠.
| 1 .0 상속(Inheritance) |
| 2 .0 일반화(Generalization)와 전문화(Specialization) |
| 0 상속도(Inheritance Tree) |
| 4 .0 상속(Inheritance)과 집합(Aggregation) |
| |
상속도(Inheritance Tree)
그림 17-2. 상속 관계 표현하기
그림 17-2처럼 클래스 다이어그램을 이용하여 상속 관계를 표현할 수 있습니다. 상속 관계를 표현하기 위한 새로운 다이어그램을 나타낼 수도 있고, 기존의 다이어그램에 상속 관계를 명시할 수도 있겠죠. 다이어그램 작성에 원칙은 없습니다. 다이어그램을 그리는 목적이 바로 우리가 구현하고자 하는 시스템을 설명해주는 모델을 바로 이해하기 위한 것이기 때문에 사람이 이해하는데 적합한 형태로 작성하면 좋은 다이어그램이라 할 수 있는 것이죠.
상속도를 표현하는 방법은 도구상자에서 Generalization 아이콘을 선택한 상태에서 하위 클래스에서 상위 클래스로 드래그 합니다. 화살표 방향이 혼돈을 가져오기 쉬운데 영문 어순을 생각하시면 쉽습니다. UML도 영어 문화권에서 개발된 언어니까요. 예를 들어 위의 그림에서, “Professor는 RegistrationUser(등록된 사용자)를 상속한다”와 같이 읽을 수 있겠죠.
상속관계를 표현할 때 만일 두 개의 하위 클래스와 모두 관계를 맺고 있는 클래스는 어떻게 표현해야 할까요?
그림 17-3. 상속 관계도
그림 17-3을 보면 CourseOffering 클래스가 각각의 하위 클래스와 개별적으로 관계를 표현하고 있습니다. 이렇게 하지 않고, CourseOffering 클래스와 RegistrationUser 사이의 관계로 표시할 수도 있겠죠?
그렇습니다. 상황에 따라서 둘 중 하나가 효과적일 때가 있는 것이죠. 가령, 해당 클래스가 각각의 하위 클래스와의 관계가 같은 경우는 상위 클래스와의 관계로 표현하는 것이 더욱 이해하기에 좋을 것입니다. 그러나, 위의 경우처럼 다중도(multiplicity)가 다르거나, 관계가 틀린 경우에는 이들을 따로 표현하는 것이 더 효과적일 수도 있습니다.
| 1 .0 상속(Inheritance) |
| 2 .0 일반화(Generalization)와 전문화(Specialization) |
| 3 .0 상속도(Inheritance Tree) |
| 0 상속(Inheritance)과 집합(Aggregation) |
| |
상속(Inheritance)과 집합(Aggregation)
위임(Delegation)이라는 디자인 패턴이 있습니다. 특정한 경우에 상속을 대체하기 위한 개념입니다. 클래스간의 상속 관계가 문제가 되는 경우가 있습니다. 상속은 기본적으로 정적인 바인딩(Static Binding)을 합니다. 프로그램 실행 이전에 이미 클래스의 타입이 결정되는 것이죠. 따라서, 실행 중에 타입을 변환하는 일은 무척 어렵습니다.(상속 관계에 따라 위, 아래로 변하는 경우는 예외죠) 위임은 집합 관계로 표현이 됩니다.
수강신청 예제에서 다음과 같은 경우를 생각해보죠. 해당 학교의 교수진은 전임교수와 시간 강사가 있다고 합시다. 그런데 시간 강사던 사람을 학교측에서 전임교수로 임명했다고 합시다. 그러면 클래스를 바꿔줘야 하는데 이를 어떻게 할까요? 시스템이 지원하지 않으니까 시스템 상에는 시간 강사로 놓아둘까요? 아니면 시스템을 수정할까요? 좋습니다. 시스템을 수정해야 겠죠. 그런데 그 사람이 개인 사정으로 다시 시간 강사직을 맡겠다고 합니다. 이번에는 어떻게 할까요?
그렇습니다. 상속은 정적인 바인딩을 하는 탓에 유연성이 떨어집니다. 이런 경우에 시간 강사인지 전임교수인지를 구분해주는 역할(Role)을 다른 클래스에 위임(Delegation)해서 문제를 해결할 수 있습니다. 이렇게 하면 실행 중에 해당 강사의 역할에 따라 동적으로 바인딩이 가능하게 되는 것이죠. 이를 표현한 다이어그램이 그림 17-4입니다.
그림 17-4. 상속과 집합
| 0 Object Behavior |
| 2 .0 상태(State) |
| 3 .0 상태 천이(State Transition) |
| 4 .0 Statechart 상세화 |
| |
유스케이스(Use case)는 시스템 레벨의 행위(Behavior)를 표현한 것입니다. 유스케이스에서 출발해서 이들 행위를 달성해야 하는 시스템의 책임(Responsibility)을 객체들에 나눠주고 이들 간의 협력(Collaboration)이 모여서 시스템 레벨의 행위를 달성하게 되는 것이죠.
자, 시스템 레벨의 행위는 유스케이스에, 이를 세분화 시켜서 객체들의 집합이 보여주는 행위는 협력을 보여주는 시퀀스 혹은 협력 다이어그램(Collaboration Diagram)에 표현되었습니다. 그렇다면 더 낮은 수준의 분석은 필요가 없을까요?
결국 객체지향 기술에서 시스템을 이루는 단위는 ‘객체’입니다. 객체의 행위 수준까지 분석을 해야 한다는 것이죠. 이번 강좌는 객체의 행위에 대해 다루도록 하겠습니다.
Object Behavior
그림 18-1. Statechart Diagram 만들기
유스케이스는 사용자와 시스템과의 상호작용 행위를 집약한 것입니다. 유스케이스는 결국 객체들이 메시지를 주고 받거나, 특정한 관계를 맺으면서 실현됩니다. 객체 사이에 오고 가는 메시지는 결국 객체 내부에서 어떠한 처리를 하게 됩니다. 따라서, 객체 내부에서 어떠한 행위를 필요로 한다는 것이죠.
이러한 행위는 객체 내부의 상태로 표현되는데 Statechart Diagram으로 나타냅니다. 그림 18-1은 Rose에서 Statechart Diagram 다이어그램을 만드는 순서를 나타냅니다. Statechart를 나타낼 클래스에서 오른쪽 마우스를 클릭한 후에 [New]-[Statechart Diagram]순으로 선택을 합니다.
객체의 모든 행위들에 대하여 Statechart Diagram을 그릴 필요는 없습니다. Statechart Diagram에 표현된 것들은 구현 과정에서 객체의 메소드내지는 함수의 알고리즘이 됩니다. 따라서, 간단한 행위에 대해 알고리즘을 다이어그램으로 표현할 필요는 없을 것입니다.
중요한 행위에 대해 Statechart Diagram를 표기하거나, 다른 타입의 클래스보다 상대적으로 이해하기에 어려운 컨트롤 클래스에 대해 다이어그램을 작성합니다. 또한, 집합연관(Aggregation)을 갖는 클래스에서 쓰기도 하죠. 요는 반드시 이해해야 하거나 이해하기 어려운 경우에 이를 돕는 것이라는 점이죠.
| 1 .0 Object Behavior |
| 0 상태(State) |
| 3 .0 상태 천이(State Transition) |
| 4 .0 Statechart 상세화 |
| |
상태(State)
상태(State)는 객체의 컨디션(condition)을 말하는데 이는 하나 이상의 속성 값으로 표현이 되죠. 쉬운 예로 전화기의 상태를 살펴 보면 ‘전화를 기다리는 상태(idle)’와 ‘전화기가 쓰이는 상태(active)’ 둘로 나눠 볼 수도 있겠죠.
그림 18-2. 상태에 대한 UML 표기법
그림 18-2는 상태에 대한 UML 표기법입니다. 상태는 모서리가 둥근 직사각형으로 표현합니다. Rose에서 상태는 표현하는 일은 매우 간단합니다. 상태 아이콘을 선택하여 다이어그램에 놓일 위치를 클릭하면 되는 것이죠.
상태의 중요한 특성 하나는 상태는 객체가 주고 받는 메시지들 사이에서 표현된다는 점입니다. 가령, 전화기에 벨이 울리는 메시지가 있다고 합시다. 이 메시지를 받기 전과 후에는 상태가 변하겠죠?
또, 한가지 상태 중에는 복합 상태(Composite State)라는 것이 있는데 하나의 상태를 세부적인 상태들로 나눌 수 있는 경우를 말합니다. 더 자세한 것은 UML Specification 등을 참조하셔야 할 것 같네요. 무한정 이야기를 늘여 나갈 수는 없으니까요.^^;
| 1 .0 Object Behavior |
| 2 .0 상태(State) |
| 0 상태 천이(State Transition) |
| 4 .0 Statechart 상세화 |
| |
상태 천이(State Transition)
State Transition은 객체의 상태가 변화되는 것입니다. Transition은 전이(轉移)라고 번역되는 경우가 많은데, 전이란 원래 ‘자리를 이동한다’는 의미로 적합한 표현이 아닙니다. Transition을 굳이 우리말로 바꾼다면 ‘천이’ 혹은 ‘변이’와 같이 바꿀 수가 있겠죠. 그렇지만 중요한 것은 ‘천이’냐 ‘전이’냐가 아니라 Transition이 무엇이냐 하는 것이죠.
그림 18-3 CourseOffering의 States와 State Transitions
상태 천이는 특정 액션 혹은 이벤트와 연관을 갖습니다. 상태를 변화시키는 요인이 무엇이냐 하는 것이죠. 그림 18-3은 수강 신청 예제의 CourseOffering(강좌) 클래스에 대한 State Transition을 표현한 다이어그램입니다.
| 1 .0 Object Behavior |
| 2 .0 상태(State) |
| 3 .0 상태 천이(State Transition) |
| 0 Statechart 상세화 |
| |
Statechart 상세화
그림 18-4는 Rose에서 State Transition을 상세하게 설명하는 사항을 나타내는 모습입니다. ‘이벤트 이름[감시 조건]/액션’ 혹은 ‘^클래스 이름.보내는 이벤트’의 형태로 표기합니다. Rose에서는 Transition에 대한 Specification 창에서 이벤트 이름은 General 탭의 Name 항목에 나머지 상세한 사항은 Detail 탭에 기술합니다.
그림 18-4. State Transition Detail 나타내기
감시 조건은 Guard Condition 항목에, 액션은 Action 항목, 대상 클래스 이름은 Send target, 보내는 이벤트는 Send event 항목에 각각 기술하면 UML 표기법에 맞게 다이어그램에 표기됩니다.
여기에서 액션과 이벤트를 구분할 필요가 있겠네요. 액션은 전이가 일어날 때 나타나는 행위입니다. 가령, 위의 경우 세부적으로는 count를 0으로 만드는 액션이 일어났습니다. 그와 동시에 다른 클래스인 CourseRoster에게 create 메시지가 호출됩니다. 이러한 메시지 호출은 액션과 구분하여 이벤트라고 합니다. 여기서 또 혼돈이 올 수 있죠. 이들이 하나의 Transition에 따른 것이기 때문에 이들을 묶어서 표현할 이름이 필요한데 그것이 여기에서는 add student입니다.
마지막으로 State Transition뿐만 아니라 State도 더욱 세분화 하여 표기할 수 있습니다. State에 대한 Specification 창을 열면 Actions 탭이 있습니다. 여기에서 insert를 하여 State를 상세히 설명하는 액션이나 이벤트를 표기할 수 있습니다. insert 명령을 수행하면 디폴트로 On Entry 액션을 생성합니다. 이를 더블 클릭하면 그림 18-5와 같이 Action Specification 창이 뜹니다.
그림 18-5. Action Specification Window
타입 옵션에서 Action과 Send Event 중에 하나를 선택할 수 있습니다. Name 항목에 액션이나 이벤트의 이름을 표기하고, 언제 이러한 행위가 일어날 지에 대해서는 네 가지 옵션을 선택할 수 있습니다. 각각의 세부 사항에 대해서는 UML User Guide나 UML Spec을 참고하세요.
| 0 아키텍쳐(Architecture)란? |
| 2 .0 아키텍쳐를 조망하는 중요한 5가지 View |
| |
사실 System Architecture를 논하는 것은 너무 시기 상조가 될 수도 있습니다. 이제 UML을 처음 배우는 입장에서 과연 아키텍쳐에 대해 얼마나 이해를 할 수가 있겠습니까마는 그래도 그 중요성이 크기 때문에 ‘음~ 이런 것이구나!’하는 정도로 이해해보도록 합시다.
아키텍쳐(Architecture)란?
아키텍쳐에 대해서는 많은 정의가 있습니다. 그만큼 한마디로 정의를 내리기가 쉽지 않다는 반증이겠죠. 우선 아키텍쳐를 설계(Design)와 빗대어 생각해볼까요? 설계가 시스템의 필수적인 기능의 구현을 위한 논리적인 구성에 대해 다룬다면 아키텍쳐는 그와는 다른 점들을 고민한다고 할 수 있습니다.
가령, 기능적으로 볼 때 여러 가지 대안이 있을 수 있습니다. 늘 답은 하나가 아니기 마련이죠. 아키텍쳐 측면에서는 시스템의 성능이나 유연성 측면, 생산성이나 비용까지 고려하여 이들 대안 중에 하나를 고르게 되는 것이죠. 또 다른 측면으로 이해를 도울 그림을 하나 보죠.
그림 19-1. 아키텍쳐의 4+1 View
그림 19-1은 전에도 살펴보았던 그림이죠? 이번에는 아파트 건축에 비유해서 생각해봅시다. 만일 당신이 아파트 건축을 책임진 사람이라고 합시다. 당신이 아파트의 실내 인테리어 담당자나 배선, 도색 등의 일부 역할을 맡은 사람이라면 아파트의 특정한 모습만 상상하면 될 것입니다.
인테리어 담당자라면 실내 공간의 크기와 모양을 계산하고, 인테리어를 적용한 모델만 만들어내면 되겠죠. 배선 담당자라면 아파트 한 동의 높이와 길이를 알아내고, 각각 방이나 거실 등의 위치를 알아내어 배선도를 작성하면 크게 문제가 없을 것입니다. 도색을 담당한 사람도 이와 비슷하겠죠.
그렇지만, 건축 전체를 맡은 사람이라면 다각적인 이해를 해야 합니다. 아무리 배선이 잘 되었더라도 건물이 부실하다면 좋은 아파트가 아니며, 아무리 실내 인테리어가 뛰어나더라도 물이 제대로 안 나오거나 전기나 가스 공급이 제대로 이뤄지지 않는다면 매우 곤란하겠죠.
이렇듯 모든 측면을 고려하는 사람을 아키텍트(Architect)라고 합니다. 이러한 아키텍트가 아키텍쳐를 만들어냅니다. 건축에 있어서의 아키텍트도 배선이나 인테리어 담당자가 맡고 있는 업무를 동일한 수준까지 알아야 할 필요는 없겠죠. 이들 일은 그들의 몫이니까 아키텍트는 전체적인 상황을 파악하는 것이 더 중요합니다.
즉, 좀더 추상화 된 이해를 필요로 한다는 것이죠. 건물 내부에서 건물을 보면 자세히 관찰할 수는 있지만 전체적인 모습을 보기란 매우 힘듭니다. 반면, 높은 곳에서 건물을 내려다 보면 자세한 정보를 얻기는 힘들지만 다양한 측면에서 건물을 관찰할 수 있습니다. 이렇듯 아키텍쳐는 높은 곳에서 바라본 모델이라고 말할 수 있습니다.
그림 19-1은 이처럼 시스템 아키텍쳐가 시스템을 다각도로 바라볼 수 있다는 것을 나타낸 것입니다. Philippe Krutchten이 제안한 것으로 RUP에서 아키텍쳐를 조망하는 중요한 5가지 View를 제시한 것입니다.
한번의 강좌로 이들 각각에 대해 깊이 있는 논의를 하는 것은 무리입니다. 다만, 이들 각각에 대해 주요한 시사점을 파악하는데 주력하도록 하죠.
| 1 .0 아키텍쳐(Architecture)란? |
| 0 아키텍쳐를 조망하는 중요한 5가지 View |
| |
논리적 관점(Logical View) 혹은 디자인 관점(Design View)
논리적 관점에서의 아키텍쳐는 시스템의 주요한 기능적인 요구사항에 대한 것입니다. 그림 19-2는 수강신청 시스템 예제의 논리적인 관점에서의 아키텍쳐를 나타내는 다이어그램입니다.
그림 19-2 수강신청 시스템의 논리적인 아키텍쳐
논리적인 관점의 아키텍쳐와 설계의 주된 차이점은 기능적인 요구사항 하나 하나를 다루는 것이 설계라면 아키텍쳐에서는 전체적인 시스템의 기능에 영향을 미치는 설계 전략(design strategy)을 결정하는 것이 아키텍쳐라고 하겠습니다.
가령, 구현 언어를 결정한다던가 사용할 DB를 결정하는 일, GUI를 결정하는 일은 설계자의 역할이기 보다는 아키텍트 혹은 아키텍쳐를 담당하는 팀의 몫이겠죠.
구현 관점(Implementation View)
구현관점의 아키텍쳐는 실제 소프트웨어 모듈의 조직에 관한 것입니다. 논리적인 것이 아니라 실제로 구동하는 시스템의 모습에 관한 것이죠.
논리적 관점에서의 패키지가 논리적인 기능별 묶음이었다고 하면 구현관점에서의 패키지는 물리적인 묶음으로 변모합니다. 이러한 패키지들은 보통 잘 정의된 인터페이스에 의해 나누어지면서 층(Layer)을 이루게 됩니다. 이러한 층(Layer)은 J2EE와 같은 응용프로그램 개발 프레임워크에서 제시하는 Tier와 일맥상통하는 것이죠.
그림 19-3. J2EE의 응용 프로그램 모델
한편, 설계에서의 하나 이상의 클래스는 구현관점에서 하나 이상의 컴포턴트로 나타내어지게 됩니다. 하나의 클래스가 하나의 컴포넌트가 되기도 하지만, 더러는 패턴을 이루는 클래스들이 하나의 컴포넌트가 되기도 하죠. 최근 불고 있는 디자인 패턴 열풍은 바로 아키텍쳐 관점에서 좋은 소프트웨어 설계를 위한 노력의 일환이라고 볼 수 있습니다.
그림 19-4. 컴포넌트 다이어그램
Rose에서 구현관점은 ‘Component View’ 패키지 내에서 컴포넌트 모델로 표현됩니다.
프로세스 관점(Process View)
프로세스관점은 구현관점과 유사합니다. 다만, 구현관점이 개발 과정에서의 소프트웨어 구조라면 프로세스관점은 실행 시(run-time)를 다룬다는 것이 차이점이죠. 따라서, UML 표현은 구현관점과 프로세스관점 모두 동일한 방식을 취합니다. 모델의 차이는 실제 구현 시에 어떠한 형태를 띄느냐 하는 것이죠. 가령, ‘EXE로 구동하느냐’, 아니면 ‘DLL 형태로 구동하느냐’ 하는 것들이죠.
배포 관점(Deployment View)
배포관점은 그야말로 시스템이 실제 배치되는 모습에 관한 것입니다. 인터넷과 무선 통신 등의 발달로 점차 프로그램이 분산화 되는 측면에서 갈수록 중요성이 강화되는 측면이라고 하겠죠. Rose에서는 ‘Deployment View’라는 다이어그램을 기본적으로 갖고 있어 배포도를 나타내도록 하고 있습니다.
유스케이스 관점(Use Case View)
19-1의 그림을 보면 유스케이스 관점은 다른 관점들을 묶으며 이들 가운데 위치하게 됩니다. 유스케이스 관점의 키워드는 ‘통합’입니다. 앞서 언급한 관점들은 각기 다른 시사점을 제시합니다. 이들 중 어느 하나의 관점을 강조하면 다른 하나의 관점에서는 상대적으로 악영향을 미칠 수가 있습니다. 가령, 성능을 높이기 위해 프로세스 관점에서 변화를 주자 논리적인 관점에서 설계 모델의 유연성이 떨어졌다고 합시다. 이것은 올바른 의사결정인가요?
이러한 관점의 차이에서 오는 마찰을 어떻게 극복할 것인가? 이들을 통합해주는 유스케이스에 그 답이 있다는 것이죠. 시스템의 가치는 유스케이스로 평가 받습니다. 즉, 평가는 고객의 몫이라는 것이지 단순히 성능이나 유연성, 유지보수성 등으로만은 이야기할 수 없습니다. 아키텍쳐에 대한 이들 각각의 관점은 결국 유스케이스 관점에서 평가하고, 검증할 수 있다는 것입니다.
앞서 강좌에서도 반복적인 개발에 대해 언급했습니다. RUP를 비롯한 모든 객체지향 방법론은 반복적인 접근법을 선택합니다. 마치 계절이 한번 돌아 한 해가 되듯이 프로젝트는 iteration의 반복으로 구성됩니다. Iteration은 어떻게 나누며 어떠한 순서로 계획해야 하는지 알아보도록 하죠.
이번 강좌에서는 강좌 초기에 말씀 드린 참고문헌 외에 다음 두 권의 서적을 참조했음을 밝힙니다.
Developing Enterprise Java Applications with J2EETM and UML…Khawar Zaman Ahmed, Cary E. Umrysh, Addison Wesley
UML User Guide … Grady Booch 외, Addison Wesley
iteration 계획하기
객체지향 분석 및 설계의 대가인 Booch에 따르면 iteration 계획에는 기본적으로 다음의 세 가지 사항이 명시되어야 한다고 말합니다.
Capabilities being developed
Risks being mitigated during this iteration
Defects being fixed during this iteration
첫째로, ‘Capabilities being developed’란 해당 iteration에서 무엇을 발전시켜 나갈 것인가를 정의하는 것입니다. 프로젝트의 초기에는 프로젝트 전체를 통해 만들어낼 것-이를 Capabilities라고 이해할 수 있습니다.-을 명확히 정의해야 합니다. 이를 프로젝트 영역(Project Scope)을 확립한다고 하죠. 이러한 영역을 각각의 iteration에 적절히 할당해야 합니다.
두 번째인 ‘Risks being mitigated during this iteration’는 iteration에서 제거할 위험 요소를 말합니다. 프로젝트 계획 시에는 프로젝트를 실패로 빠뜨릴 주요 위험 요소를 찾아내야 합니다. 프로젝트의 주적을 찾아내는 것이죠. 주적을 찾아내어 각각의 iteration에서 하나씩 제거해 나가면 승리를 하게 되는 것이죠.
마지막으로 ‘defects being fixed during this iteration’는 진화(evolution)하는 측면을 잘 보여줍니다. 지난 iteration에서의 문제점을 파악하고 이번 iteration에서 그러한 문제점을 해결하는 것이죠.
그림 20-1은 iteration 계획 프로세스를 나타낸 것입니다. 초기에 설정한 프로젝트 영역과 위험 요소(initial risks, initial project scope)를 기초로 프로젝트를 계획합니다. 가장 위험한 요소부터 제거하는 방향으로 iteration을 설정한(Define iteration to address the highest risks) 뒤에 iteration을 계획하고 진행하면서 발전시켜 나갑니다(Plan and develop the iteration). 해당 iteration이 종료되면 되짚어 보아야 합니다.(Assess the iteration)
그림 20-1. Iteration 계획 프로세스
제거된 위험 요소(Risks eliminated)를 확인한 뒤에 위험 요소를 관리하는 목록을 수정해야 하겠죠(Revise project plan). 그리고 나서 최종적으로 프로젝트 계획서를 수정합니다(Revise project plan). 이렇게 하나의 Iteration이 종료가 되고, 수정된 위험 요소 목록과 프로젝트 계획서는 다음 Iteration을 계획하는 자료가 되는 것이죠.
보통 Iteration을 나눌 때에는 유스케이스에 근거해서 나누게 됩니다. 이들 유스케이스들을 위험 정도, 고객에 있어서의 중요성과 선행 작업 필요성 여부 등을 고려해서 우선순위를 설정합니다. 그런 후에 우선순위가 높은 것부터 초기의 Iteration에서 다루게 되는 것이죠.
UI 설계
요구사항 수집과 업무를 분석하는 과정에서 사용자 인터페이스에 대한 요구가 구체화되어져 가기 마련입니다. 초기에 사용자 마음에 쏙 들고, 사용자의 업무 수행에 딱 들어맞는 인터페이스를 만들 수는 없을 것입니다.
따라서, 프로토타이핑(prototyping) 기법과 같은 것들이 쓰이게 되는 것이죠. 프로토타이핑이란 개발과정에서 최종적인 시스템의 모습의 일부를 보여주는 샘플-프로토타입(prototype)이라고 하죠-을 만드는 것입니다.
주요 UI를 찾아내고 사용자가 UI를 이용해 업무를 수행하는 이동경로의 파악, UI를 통해 시스템과 주고 받는 데이터를 파악하는데 많은 노력이 기울여집니다. 분석 단계에서 논리적인 UI 객체들을 뽑아내는데 설계단계가 되어 구체적인 사용기술이 결정되면 그림 20-2와 같은 모델과 관계가 드러나게 됩니다.
그림 20-2. JSP를 사용한 UI 관련 객체 모델링
그림 20-2를 보면 우선 장바구니 화면에서 ‘결제하기’와 같은 메뉴를 선택하면 Checkout이라는 JSP 객체로 링크가 됩니다. Checkout JSP 객체는 ShopingCartBean을 이용해서 장바구니에 담긴 정보를 확인하고, 결제 확인을 위한 클라이언트 페이지를 만들어내게 됩니다. 해당 화면 내에는 결제 정보를 입력할 수 있는 양식(Form)이 포함되어 있겠죠.
클래스 디자인
초기에는 클래스 자체만을 추출하는 개념적인 수준으로 수행하게 됩니다. 이러한 클래스를 Conceptual Class라고 하죠. 일반적으로 사용자와의 상호작용이 많은 시스템의 경우는 MVC 모델을 이용하여 클래스를 추출하는 것이 보편적입니다.
분석 단계에서 해당 업무 영역(Domain)에 적합한 클래스를 뽑아냅니다. 아직까지는 특정 기술에 국한된 것은 아니죠. 이렇게 분석 모델을 도출한 이후에 어떠한 기술을 사용하는 것이 적절한가를 결정한 이후에 이를 적용한 설계 모델을 만들어냅니다.
설계 단계에서의 클래스는 특정한 기술에 한정된 것입니다. 그림 20-2의 경우도 자바기술에 한정된 설계단계의 다이어그램이죠. 개념적인 클래스가 적절히 도출되면 이들 사이의 관계를 묘사합니다. 관계는 집합(Aggregation), 상속(Inheritance)과 의존(Dependency)과 같은 정적인 관계와 메시지를 통한 동적인 관계인 연관(Association)으로 크게 나눌 수 있습니다.
그림 20-3. 속성과 오퍼레이션이 추가된 설계 단계의 클래스 다이어그램
클래스가 도출되고 관계가 묘사된 이후에는 속성과 오퍼레이션이 추가되는 순서로 자세한 설계가 진행됩니다. 그림 20-3은 속성과 오퍼레이션이 추가된 이후의 설계 모델의 모습이죠. Rose의 경우에는 위와 같이 기본적인 EJB 오퍼레이션은 자동으로 생성해 줍니다.
[Tools]-[Java/J2EE]-[New EJB] 메뉴를 선택하면 그림 20-4와 같이 EJB Specification 창이 나타납니다. 여기에서 적절히 옵션을 선택하고, BeanName이름을 작성하면 이에 맞춰서 EJB 클래스들이 생성됩니다.
그림 20-4. EJB Specification 창
드디어 강좌의 종착역에 도달했군요. 마지막으로 UML에 대해서 정리를 해보고 어떻게 이용할 수 있을지 운을 띄우도록 하겠습니다. 실제로 UML을 활용해서 각자가 원하는 가치를 만들어내는 것은 여러분들의 몫이 될 테니까요.
모델링 언어 UML
UML(Unified Modeling Language)이란 말 그대로 모델링을 위한 언어를 통합시킨 것입니다. 특징적인 점은 그래픽 요소가 강한 표준 언어라는 점이죠. 굳이 소프트웨어 개발을 위해서만 UML을 쓸 수 있는 것은 아니지만, 주로 소프트웨어 개발을 위해 도움을 주는 방향으로 발전되어 왔습니다. 그러나, 모델링을 능숙하게 하기 위해서는 다양한 현상이나 개념들을 UML로 표현해 보는 방법도 좋은 수련이 된다고 할 수 있겠죠.
UML이 있기 이전에도 소프트웨어 개발을 위한 요구사항 수집이나 분석 및 설계 등을 위해 모델링이 쓰이기 시작했습니다. 글로만 작성된 문서는 내용이 많아지면 전체를 한눈에 파악하기가 상당히 힘들어집니다. 또한, 다른 사람과 의사소통 하는데 상당히 어려움을 갖게 되죠.
소프트웨어 개발 과정에서 모델링을 이용하기 이전에 이미 많은 분야에서 모델링이 쓰였습니다. 여러분도 건축에서 쓰이는 많은 도면을 한번쯤은 보신 일이 있으시리라 생각이 듭니다. 디자이너들이 의상을 모델링 한 도면을 언뜻 보신 분도 있을 듯 하구요. 이른바 샘플이라고 하는 것들은 모델과 유사한 것들이죠. 또한, 수학이나 과학의 공식들도 하나의 모델이라고 볼 수 있습니다.
그림 21-1. OMG의 로고
UML은 흔히 Booch, Rumbaugh와 Jacobson이 만든 것으로 오인하는 분들이 많습니다. 앞의 세 분들이 UML의 초안을 만들어내고 발전하는데 많은 기여를 한 것은 사실입니다. 그러나, UML에는 이미 존재해있던 많은 지적 자산들이 축적되어 있다고 볼 수 있습니다.
UML의 많은 모델링 요소들과 다이어그램은 개발 현장에서 필요성을 인정 받아 널리 쓰이던 것들이 UML이라는 이름으로 꾸러미 지어진 것입니다. 기왕 모델링 하는 김에 서로 통일된 언어로 하자는 것이죠. 1997년 후반 UML1.1이 OMG에 의해 표준으로 채택된 이래 발전을 거듭하여 현재는 UML 1.4버전까지 등장했습니다.
우리가 UML을 단순히 기술로써 다룬다면 제대로 써보지 못할지 모릅니다. UML의 심장을 이루고 있는 진정한 쓰임새를 알아야 우리에게 가치를 줄 수 있을 것입니다. 모델링은 복잡한 개체나 현상을 이해하기 위한 방편입니다. UML은 그러한 모델링을 해나가는데 아주 유용한 도구입니다.
UML은 모델링을 하기 위해 단순히 도구들-즉, 클래스나 관계와 같은 모델링 요소들만을 제공하는 것이 아닙니다. 모델링 요소와 이들 간의 규칙, 다이어그램들 안에는 문제 해결에 유용한 선조들의 자산이 녹아 있습니다.
물론 우리나라 선조님들은 아니죠. 소프트웨어 개발을 위해 다양한 문제 해결을 하려고 고민했던 이들이 많은 모델 표기법이나 규칙을 만들었고, 다양한 경험과 지식들이 UML이라는 이름으로 녹아 들어 하나의 모습을 하게 된 것입니다.
통합을 위한 언어 UML
소프트웨어 개발을 바라보는 시각은 무척 다양합니다. 우선 고객과 개발자의 관점은 확연하게 다릅니다. 개발자의 경우는 시스템의 기능이나 기술에 관심이 많지만, 고객은 풍부한 기능보다는 자신의 업무에 유용한지를 더 생각할 것입니다. 또한, 고객 측면에서는 어떠한 기술이 사용되었는지는 크게 중요하지 않을 수도 있습니다.
UML은 유스케이스(Use Case)와 유스케이스 실체화(Use Case Realization)를 통해 고객의 관점과 개발자의 관점을 연결시켜줍니다. 시스템 개발의 궁극적인 목적은 고객의 요구를 충족시켜주는 것입니다. 그러한 면에서 유스케이스를 실현하는 일은 시스템이 제대로 만들어졌는지를 검증하는 일이라 하겠습니다.
UML에서는 그림 21-2와 같이 추적 다이어그램을 통해 유스케이스와 유스케이스 실체화 간의 추적 기능을 제공합니다. 이를 통해 시스템의 모델이 유스케이스를 충족했는지 검증하는 역할을 수행할 수 있습니다.
그림 21-2. 유스케이스 추적 다이어그램
유스케이스 실체화는 Collaboration으로 연결됩니다. 그림 21-2에서 점선으로 연결된 타원은 유스케이스 실체화를 나타내기도 하지만, Collaboration을 묘사하기도 합니다. Collaboration이란 하나 이상의 객체가 작용해서 어떠한 기능을 수행하는 모습을 모델링 한 것입니다.
결국 고객의 요구 사항에 대한 시스템의 기여를 나타내는 유스케이스는 객체들이 모여서 만들어내는 Collaboration에 의해 수행된다는 것이죠.
개발자 사이에서도 다양한 관점이 존재합니다. 소규모 개발에 있어서는 굳이 역할을 구분함 없이 목표를 향해 무조건 개발하게 되어 있습니다만 그 규모가 커지면 이러한 접근법은 성공하기 어렵습니다. 따라서, 명확히 역할을 구분하고, 이에 따라 책임을 분산하게 됩니다.
이렇게 되면 시스템을 바라보는 시각도 단편적이 될 수 있습니다. 대형 프로젝트를 수행하게 되면 개개인의 역할과 개인적 성향에 따라 서로 다른 수많은 관점으로 시스템을 바라봅니다. 이를 조율할 수 있는 도구가 필요한데 이것이 또한 UML입니다.
UML은 시스템을 모델링 할 수 있는 다양한 관점을 제공합니다. 기본적으로 RUP에서 크게 구분하는 관점은 전에도 말씀 드린 것처럼 5가지 관점입니다. 분석과 설계 과정에서 시스템의 정적인 측면과 동적인 측면을 동시에 바라보는 논리적인 관점이 있습니다. 그림 21-3에 보이는 Design View가 이를 나타낸다고 볼 수 있습니다.
논리적인 요소들 즉, 클래스, 인터페이스나 이들을 묶은 Collaboration을 컴포넌트로 매핑시켜 구현을 위한 모델을 만들게 되는데 이를 Implementation View라고 합니다. 실제 구동 환경을 살펴본 모델인 Process View가 있습니다. 또한, 시스템이 실제로 설치되고, 배치되는 모습을 표현한 Deployment View가 있습니다. 여기에 이들 모두를 검증하고 통합시켜주는 수단인 Use Case View가 있죠.
그림 21-3. 4+1 View
시스템 분석 및 설계를 담당한 사람이라면 Design View에만 관심이 집중될 것입니다. 구현을 담당한 프로그래머라면 Implementation View에 초점을 맞추거나, 더러는 Process View쪽에 비중을 두는 역할자도 있을 것입니다. 시스템 배포 전문가나 시스템 엔지니어라면 Deployment View의 모델에만 관심을 갖을 것입니다.
그러나, 이들 모두는 결국 고객이 원하는 시스템의 가치를 만들어내는 것이 최종 목적입니다. 따라서, 이들 다양한 관점 사이에 충돌이 생길 경우에 이를 조정하고 통합시키는 수단이 Use Case View라고 볼 수 있습니다.
UML은 이들 관점 모두를 표현할 수 있는 도구를 제공함과 동시에 UML에 흡수된 규칙과 관습 등을 통해 위에서 설명한 통합의 기초를 제공해준다고 말할 수 있습니다. 실제로 이러한 통합을 수행하는 사람이 필요한데 이러한 지휘자를 아키텍트(Architect)라고 부릅니다.
결론적으로 UML은 단순히 모델링 언어를 통일시킨(Unified) 언어일 뿐만 아니라 시스템을 바라보는 다양한 관점까지 통일시킨 유용한 도구라고 할 수 있습니다. 이러한 측면에서 UML을 이해하고 사용해야만 유익한 결과를 얻을 수 있을 것입니다.
참고 문헌
마지막으로 제가 이 강좌를 쓰면서 참고했던 서적과 웹 사이트를 언급하죠. 좀 더 깊은 이해를 원하시는 분들이라면 해당 서적이나 사이트가 많은 도움을 줄 수 있을 것입니다.
참고 서적
Visual Modeling with Rational Rose and UML, Terry Quatrani, Addison Wesley
UML Distilled Second Edition, Martin Fowler with Kendall Scott, Addison Wesley
The Rational Unified Process An Introduction Second Edition, Philippe Kruchten
The Unified Modeling Language Reference Manual, James Rumbaugh, Ivar Jacobson, Grady Booch, Addison Wesley
The Unified Modeling Language User Guide, James Rumbaugh, Ivar Jacobson, Grady Booch, Addison Wesley
Developing Enterprise Java Applications with J2EETM and UML, Khawar Zaman Ahmed, Cary E. Umrysh, Addison Wesley
초보자를 위한 UML, Joseph Schmuller, 곽용재 역, 인포북
유용한 사이트
OMG UML Resource Page… http://www.omg.org/uml/
Cetus Links … http://www.cetus-links.org/
'기타잡동산이' 카테고리의 다른 글
| 특수문자들의 명칭 ^^ (0) | 2011.10.14 |
|---|---|
| [펌] 아웃룩을 빽업해보자 (0) | 2011.10.14 |
| [펌] vi 사용방법 (0) | 2011.10.14 |
| [펌] 오픈소스 트래픽 테스트 툴「시즈」 (0) | 2011.10.14 |
| 정보시스템 개발 방법론 (0) | 2011.10.14 |