본문 바로가기
UML

[펌] rational rose를 이용한 비쥬얼 모델링

by 사우람 2010. 7. 12.

UML과 래셔널 로즈를 이용한 비쥬얼 모델링(3)

김현남
E-mail:kimhn@dreamwiz.com
동국대학교 건축공학과 대학원
Homepage:www.dongguk.ac.kr

래셔널 통합 프로세스(Rational Unified Process)는 유즈케이스 드리븐(Usecase Driven), 아키텍쳐 중심(Architecture Centric), 반복 점증 개발(Iteration and Incremental)이라는 세 가지 핵심 키 요소를 가진다. 이 중 유즈케이스 드리븐의 의미는 시스템 개발에 있어 유즈케이스 모델 이후의 모델들이 유즈케이스 모델로부터 시작된다는 것이다. 유즈케이스 모델의 내용에 의해서 분석 모델이 만들어지고, 유즈케이스 모델에 의해서 설계 모델이 만들어지고, 유즈케이스에 의해서 구현 모델이 만들어지고, 또한 테스트 케이스 모델도 만들어지게 된다. 왜 유즈케이스로부터 모든 것들이 파생되어야 하는가를 생각해보자. 소프트웨어 시스템이라는 것은 사용자에게 어떠한 서비스를 제공해주기 위해 존재하는 것이다. 바로 유즈케이스 모델이 이러한 사용자의 요구사항을 반영하는 것이기 때문에, 시스템 구축까지 사용자의 요구사항을 반영하기 위해서는 유즈케이스 중심이 되어야한다는 것은 당연한 것이 될 것이다.
지금까지 우리는 시스템의 기능적 요구사항을 찾아내는 방법인 유즈케이스 모델을 작성하는 법을 배웠다. 유즈케이스 모델을 작성하기 위해서 액터와 유즈케이스 그리고 유즈케이스 다이어그램에 대해서 배웠으며, 유즈케이스의 텍스트 표현인 이벤트 플로어에 대해서도 배웠다. 그렇다면 앞으로의 일들은 무엇이겠는가? 바로 유즈케이스의 내용에 기반 하여, 분석 모델, 설계모델, 구현모델과 테스트 케이스 모델을 만들고 시스템을 개발하는 것이다. 이때 모든 모델은 기반은 유즈케이스 모델이 되어야 한다는 것을 다시 한번 명심하길 바란다.
래셔널 통합 프로세스의 세 가지의 핵심 키에 대한 내용은 이후의 연재에 자세하게 싣도록 하겠다. 그리고 이 연재의 핵심 부분을 차지하고 있는 원서가 인터비전에서 번역이 되어 나왔다. 독자들은 필자의 글을 읽다가 번역이 매끄럽지 못한 부분들에 대해서는 번역서를 참조하면 되겠다. 그럼으로, 앞으로 필자는 번역 부분이 차지하는 글의 비율을 50%이하로 낮추려고 한다. 물론 원서에 있는 부분들을 빼는 것은 아니니 염려하지 않기를 바란다. 한 마디 더 부분과 특집 부분의 비중을 늘리고 래셔널 로즈의 사용을 쉽게 하기 위한 화면 캡쳐 부분을 좀더 추가함으로서 좀더 다양한 방면의 추가와 사용의 편의성을 고려하겠다는 것이다. 이번 호에서 필자의 글을 보시면 알겠지만, 글의 게재 양이 대폭 증가됨을 알 수 있을 것이다. 그에 비해 추가적인 부분들이 뒷부분(6장 이후)으로 갈수록 적어짐을 알 수 있을 것이다. 필자는 이 글을 작년에 작성하였고, 작성된 부분을 보강하면서 글을 작성하고 있었는데, 번역서가 출판사를 통해서 번역서로 나왔고, 독자들이 한달 이라는 기간동안 소화해 낼 수 있는 정도의 양을 실어야겠다는 의도로 분량을 늘리기로 하였다. 그 만큼 글의 질이 떨어지는 것은 양해를 바란다. 래셔널 로즈에서 스테레오 타입을 추가하고, 해당 스테레오 타입의 아이콘을 추가하는 부분에 대한 설명도 추가하려 했으나 다음 기회로 넘겨야 할 것 같다.
앞으로 필자는 인터넷 전성시대에 걸맞게 Jim Conallen의 저서 [Building Web Application with UML]을 중심으로 웹 어플리케이션 설계에 대해서도 논하려고 한다.
이번 호의 글 첫 머리에서도 독자들에게 많은 약속을 하였다. 매번 첫 머리에는 너무 많은 약속을 하고 잘 지키지 못하는 것 같아 미안하지만, 열심히 하겠다는 의지니까, 너그러히 용서하시기 바란다.

 

클래스 찾기

  • 객체란 무엇인가(What is an objects) ?
  • 상태, 행위, 식별자(State, Behavior, and Identity)
  • 클래스란 무엇인가(What is a class) ?
  • 스테레오 타입과 클래스(Stereotypes and classes)
  • 클래스 발견(Discovering classes)
  • 패키지(Packages)
  • ESU 수강등록 시스템에서의 객체와 클래스
    (Objects and Classes in the ESU Course Registration Problem)
  • 클래스 다이어그램(Class Diagrams)
  • 요약(Summary)

 

무엇이 객체인가?

객체는 현실 세계 또는 개념상의 실체에 대한 표현이다. 객체는 '김씨의 트럭'이나 내 컴퓨터'와 같은 분명한 무엇인가를 표현할 수도 있고, '화학반응', '은행거래', '주문', '내 신용기록', '이자율'과 같은 개념적인 사항들을 표현할 수도 있다.
객체는 개념, 추상화 또는 잘 정의된 범위를 갖고 있는 어떤 것(thing)이다. 특히 시스템 내부에서의 객체는 상태(state), 행위(behavior), 식별자(identity)라는 세 가지 특징을 갖는다.

 

상태, 행위, 식별자

객체의 상태는 그 객체에 존재할 수 있는 어떤 상황을 뜻한다. 객체의 상태는 특히 시간에 따라 변화하고, 속성이라 불리는 특성들의 집합으로 표현되며, 이것은 특성 값과 함께 그 객체가 다른 객체와 맺고 있을 관계까지 포함한다. 예를 들어 주위에서 흔히 볼 수 있는 자판기의 경우는 대기상태와 서비스 상태의 두 가지 상태를 갖고 있을 수 있다. 만약 어떤 사람이 500원 짜리 동전을 넣고 커피 한잔을 뽑는다면, 동전을 넣기 전에는 대기 상태에 있던 자판기가 동전을 넣음으로써 서비스 상태로 바뀌게 된다. 자판기는 커피와 잔돈을 사람에게 주고, 다시 대기상태로 돌아간다. 다른 예로는 개설과목 객체의 예에서 찾아볼 수 있는데, 개설과목은 등록가능(Open)과 등록마감(Close)의 두 상태를 가진다. 만약 개설과목에 등록한 학생이 10명 미만이라면 상태는 등록가능상태일 것이고, 학생수가 10명일 때 등록마감 상태가 된다.
행위는 객체가 다른 객체로부터의 요청에 어떻게 반응해야 할지를 결정하는 것뿐만 아니라, 객체가 할 수 있는 모든 것을 의미한다. 행위는 객체에 대한 오퍼레이션(operation) - 연산이라고 한다. - 의 집합에 의해 구현된다. 수강 등록 시스템에서 개설과목은 학생 추가와 학생 삭제라는 행위를 가진다.
식별자는 비록 다른 객체와 동일한 상태를 갖고 있어도 각각의 객체가 유일하다는 것을 의미한다. 예를 들면, 대수학 101, Section 1과 대수학 101, Section 2는 수강등록 시스템의 두 개의 객체이다. 비록 그것들 모두가 개설과목일지라도 고유한 식별자를 가진다. UML에서 객체는 그림 1처럼, 사각형으로 표시되고 객체의 이름에 밑줄을 친다.

##########0*
그림 1) 객체에 대한 UML 기호


무엇이 클래스인가?

클래스는 공통 특성(속성), 공통 행위(오퍼레이션), 다른 객체들과의 공통된 관계와 공통적 의미를 갖는 객체들의 그룹에 대한 설명이다. 그러므로, 클래스는 객체를 만들기 위한 템플릿이다. 각 객체는 어떤 클래스의 인스턴스이고, 객체들은 하나 이상의 클래스에 대한 인스턴스가 될 수 없다. 예를 들면, 개설과목 클래스는 다음과 같은 특징으로 정의되어진다.

  • 속성 - 위치, 강의 시간
  • 오퍼레이션 - 위치 알기, 개설과목에 학생 추가, 학점 알기
    대수학 101, Section 1과 대수학 101, Section 2는 개설과목 클래스에 속한 객체들이다. 각각의 객체는 속성들에 대한 값을 가지고, 개설 과목 클래스에 기술된 행위를 액세스할 수 있다.

좋은 클래스는 오직 하나의 추상적 개념을 갖는다. 이것은 클래스가 주된 주제를 하나 가진다는 것을 의미한다. 예를 들면, 학생의 정보와 한 학생이 지금까지 수강한 모든 과목에 대한 정보를 관리할 수 능력을 가진 클래스는 이것이 하나의 주요 주제를 가지고 있지 않기 때문에 좋은 클래스가 아니다. 이 클래스는 학생과 학생이력이라는 클래스로 분리되어져야 한다.
클래스의 이름을 작성하는 것은 개발자에게는 매우 어려운 일에 속한다. 왜냐하면 분석 단계의 클래스는 도메인의 용어를 사용하여 명명하여야 하기 때문이다. 클래스의 이름은 추상화하는 것을 가장 잘 표현하는 단수 명사여야 하며, 원래의 의미를 유지하기 위해 가급적 약어를 사용하지 말아야 한다. 만약 어떤 클래스를 약어로 명명한다면 원래 이름을 클래스 문서에 포함시켜야 하며, 이 경우에도 의미의 혼동이 없는 경우에 한한다. 만약 의미의 혼동이 발생될 시에는 약어를 사용하지 말아야 한다. 우리는 시스템 개발 초기에 용어정리를 해야 하는데, 이 용어 정리를 함으로서, 클래스 이름을 정하는 것과 비슷한 작업에서 시간 소비를 줄일 수 있고, 오해의 소지 또한 없앨 수 있다.
툴에 존재하는 제한 조건들은 프로젝트의 이름 작성 표준에 영향을 미칠 수도 있다. 래셔널 로즈 4.0에서 액터는 <>라는 스테레오 타입을 갖는 클래스이다. 따라서 액터라는 이름을 갖는 클래스는 쓸 수 없다. - 래셔널 로즈 98에서는 사용할 수 있다.
도메인 객체들 중 정보만을 포함하는 경우는 이름 뒤에 정보라는 말을 명기하는 것이 더욱 확실하게 느껴질 수도 있다.
클래스와 객체 사이의 구별은 종종 어려울 때가 있다. 왜 대수학 101, Section 1이 클래스가 아니고 객체인가 ? 대수학 102, Section 2와 다른 점은 무엇인가? 이러한 질문들에 대한 답은 매우 주관적이다. 그들의 구조와 행위를 조사함으로서, 둘 다 같은 구조와 행위를 가졌다는 것을 알 수 있다. 그들은 단지 학기동안에 개설되는 다른 개설과목들이다. 추가적으로 수강 등록 시스템에는 간은 구조와 행위를 가진 많은 다른 객체들이 존재한다(예를 들면, 음악 101, Section 1, 국사 101, Section 1과 국사 102 Section 2). 이것은 개설과목이라는 클래스를 만들어야한다는 결정을 이끌어 낸다.
UML에서 구획을 가진 사각형으로 표시되어진다. 제일 상위 부분은 클래스의 이름을 포함하고, 중간 부분은 클래스의 구조(속성들)를 포함하고, 제일 아래 부분은 클래스의 행위(오퍼레이션)를 포함한다. 클래스는 그림 2에서 보여주고 있다.

##########1*
그림 2) 클래스에 대한 UML 기호

 

래셔널 로즈에서 클래스 만들기

  1. 브라우저 안의 논리적인 뷰를 선택하고 마우스 오른쪽을 클릭 하여, New:Class 메뉴를 선택하라. 브라우저에 New Class라는 이름을 가진 클래스가 이름이 선택되어져서 보일 것이다.
  2. 새로운 클래스가 여전히 선택되어져 있는 상태에서 클래스의 이름을 입력하라.

    ##########2*
    그림 3) 클래스가 브라우저의 논리적 뷰에서 생성되었을 때

    ##########3*
    그림 4) 클래스의 이름을 CourseOffering으로 설정

 

 

스테레오 타입과 클래스

우리는 이미 유즈케이스 다이어그램에서 관계에 대한 스테레오 타입에 관해 언급하였다. 클래스 또한 스테레오타입을 가질 수 있다. 스테레오 타입은 새로운 종류의 모델링 요소를 만들 수 있는 기능을 제공한다. 여기에서 우리는 새로운 종류의 클래스를 만들 수 있다. 클래스에 대한 공통의 스테레오타입으로는 엔티티(entity), 바운더리(boundary), 컨트롤(control), 유틸리티(utility), 그리고 예외(exception)등이 있다. 이러한 스테레오 타입들에 대해서 도구들은 해당 아이콘을 제공하는데, 래셔널 로즈 98버전에서는 엔티티, 바운더리, 컨트롤의 아이콘을 제공하지 않았으나, 래셔널 로즈 2000버전에서는 제공하고 있다.
어떤 클래스에 대한 스테레오타입은 클래스 이름 위에 <<>> 기호 안에 표현된다. 그래픽 아이콘이나 특정색깔을 스테레오 타입에 표현에 사용할 수도 있다. 예를 들면 <>라는 스테레오타입을 갖는 모든 클래스는 붉은 색으로 그려질 수 있다.

래셔널 로즈에서 클래스 장식하기

  1. 클래스 다이어그램에서 장식하고 싶은 클래스들을 선택한다. 다중 선택 방법은 일반적인 이미지 에티터들에서와 같다(Control, Shift 키를 누르고 해당 클래스 선택 또는 범위를 선택하여 클래스를 선택하는 방법).
  2. 메뉴에서 Edit:Diagram Object Properties:Font Size, Font, Line Color, Fill Color를 사용하여 클래스를 장식할 수 있다.

##########4*
그림 5) 엔티티 클래스의 Line Color의 색을 파란색으로 설정한 경우

클래스 찾기

클래스를 찾아내는 데 요리 책과 같은 지침서란 존재하지 않는다. 부치가 이미 언급한 것처럼 클래스를 찾아내는 것은 어려운 일이다. 래셔널 유니파이드 프로세스(Unified Process)에서는 바운더리, 컨트롤, 엔티티와 같은 세 가지 유형의 클래스를 찾아보는 것으로 개발 중에 클래스를 발견하는 데 도움을 받을 수 있도록 하였다. 이 세 가지 스테레오타입은 스몰토크의 모델-뷰-컨트롤러의 관점을 따르고 있다.
분석과 설계과정이 반복적이기 때문에, 클래스 목록은 시간에 따라 변할 것이다. 초기의 클래스 집합은 최종적으로 구현하는 클래스 집합이 아닐 것이다. 따라서 초기에 나타나는 클래스들은 최종 시스템의 클래스 목록에서 제외되거나 다른 이름으로 명명될 수도 있다. 개발이 진행됨에 따라 클래스의 목록에서 찾을 수 있는 클래스의 수는 점점 증가하게 될 것이다.
반복적이 개발의 장점중의 하나는 초기 단계에서 모든 클래스를 찾아내야 하는 부담감을 가질 필요가 없다는 것이다.

한마디 더

통합프로세스에서는 시스템을 보는 관점을 시스템 외부의 관점과 시스템 내부의 관점으로 나누고 있다. 시스템 외부의 관점은 시스템을 사용하는 액터의 관점에서 시스템이 만족시켜주어야 하는 요구사항들이 무엇이 있는가를 찾는 것이다. 그리고, 시스템 내부적인 관점은 이러한 요구사항을 위해서 시스템이 어떠한 일들을 수행해야 하는가에 대한 것이다. 요구사항을 만족시켜 주기 위해서는 시스템은 내부적으로 많은 정보를 사용한다. 시스템의 외부 적인 관점은 유즈케이스 모델로 표현되고, 시스템 내부적인 관점은 분석모델을 거쳐 설계모델에서 표현되어 진다.
유즈케이스를 통해서 우리는 시스템이 무엇(What)을 해야 하는가에 대해서 표현하고, 설계과정을 통해서 어떻게(How)할 것인가를 표현한다. 무엇을 해야 하는가? 에서 어떻게 해야 하는가 ?로 넘어갈 때에, 많은 부분이 차이 없이 넘어가기 위해서 다리 역할을 하는 것이 필요한데 바로 이것이 분석모델이다. 유즈케이스 기술은 사용자 중심이므로 유즈케이스 기술을 보면 사용자의 용어를 이용하여 기술하였음을 알 수 있고, 시스템 내부에서 그러한 것들을 구현하기 위해서 어떻게 해야 하는가에 대한 기술은 없다. 그에 반하여 시스템을 설계하기 위한 설계모델에서는 아키텍쳐에 관한 많은 고려가 필요하고, 시스템 내부에서 어떻게 구현하는 가에 중심이 맞추어져 있다. 그러므로 이러한 두 부분을 자연스럽게 연결하기는 매우 어렵다. 바로 이러한 연결 역할을 하는 것이 분석 모델인 것이다.
분석모델은 두 가지 부분으로 작업이 나누어진다. 첫째, 유즈케이스의 텍스트 적 설명에 해당하는 이벤트 플로어를 사용자 관점에서 개발자 관점으로 정제하는 작업을 하는 것이다. 둘째, 설계 모델에 사용될 유즈케이스에 참여하는 클래스의 초기 집합을 찾아내 다음과 같은 세 가지 타입의 클래스로 분류하는 것이다. 세 가지 타입은 클래스는 바운더리 클래스(boundary class), 엔티티 클래스(entity class), 컨트롤 클래스(control class)이다. 이 시점에서 발견된 세 가지 타입의 클래스를 분석 클래스라 한다. 이 두 개의 작업은 서로 분리되어 작업되는 것이 아니라, 서로 상호보완적인 작업이라고 보는 것이 좋다.
바운더리 클래스는 액터가 시스템과 커뮤니케이션 하기 위해 사용하는 것이고, 엔티티 클래스는 일반적으로 도메인 모델에서의 객체이고, 컨트롤 클래스는 바운더리 클래스와 엔티티 클래스 사이에 접착제로서 역할을 하는 것이다.
다시 말하면, 바운더리 클래스는 외부에 존재하는 것들(액터)에 의존적인 시스템의 부분을 모델화 하는 것이고, 엔티티 클래스와 컨트롤 클래스들은 시스템의 외부에 존재하는 것에 독립적인 부분을 모델화 하는 것이다. 그러기 때문에 GUI 또는 통신 프로토콜의 변화는 단지 바운더리 클래스의 변화를 의미하지 엔티티 클래스나 컨트롤 클래스의 변화는 의미하지 않는다.
바운더리 클래스는 우리가 인터페이스로 불리는데 사용하는 것인데, 3명의 객체지향 대가는 COM+, 자바와 같은 곳에서 사용하는 인터페이스와의 혼동을 없애기 위해서 이름을 바운더리로 바꾸었다.

♠ 이 부분에 대한 좀더 자세한 내용은 한마디 더 보다는 특집 편으로 넘기는게 좋을 것 같다.

 

엔티티 클래스

엔티티 클래스는 일반적으로 오랫동안 존재하는 정보와 연관된 행위를 모델화 한다. 이런 종류의 클래스는 실 세계의 엔티티를 반영하거나 시스템 내부의 업무를 수행하는 데 요구되어진다. 이것들은 주변 환경에 독립적이다. 즉 주변 환경이 어떻게 시스템과 커뮤니케이션 하는가에 대해서 민감하지 않다. 많은 경우에 엔티티 클래스는 애플리케이션에 독립적이며, 이것은 하나 이상의 애플리케이션에 걸쳐 재 사용되기 쉽다는 것을 의미한다.
엔티티 클래스를 찾는 첫 번째 단계는 찾아진 유즈케이스에 대한 이벤트 플로어로 문서화되어진 책임성에 대해서 조사한다. 즉 시스템이 해야 되는 일이 무엇인가를 조사한다. 엔티티 클래스는 일반적으로 시스템이 책임을 완수하기 위해 필요로 하는 클래스이다. 책임 사항을 설명하기 위해 사용되는 명사와 명사구는 좋은 후보 클래스가 될 수 있다. 명사의 초기 목록은 문제 영역에서 벗어난 명사, 단지 언어적 표현인 명사, 중복된 명사, 클래스 구조를 기술하는 명사를 포함할 수 있으므로 걸러질 것이다.
엔티티 클래스는 보통 정제 단계의 초기에 발견된다. 엔티티 클래스는 일반적으로 실 세계의 추상화를 다루기 때문에 도메인 클래스로 불리기도 한다.
이러한 엔티티 클래스를 찾는 가장 좋은 방법은 비즈니스 모델링 작업을 하는 것이다.

 

바운더리 클래스

바운더리 클래스는 시스템 주변에 존재하는 것들(액터들)과 시스템 내부간의 커뮤니케이션을 다룬다. 바운더리 클래스는 사용자나 다른 시스템에 대하여 인터페이스를 제공한다. 바운더리 클래스는 시스템 인터페이스를 모델로 만드는 데 사용된다. 즉 시스템 인터페이스가 그래픽 적인 화면이 될 수도 있지만, 단순한 텍스트 형태의 화면이 될 수도 있으며, 개발환경이나 사용할 수 있는 인터페이스 제품 라이브러리의 유무에 따라 다양한 화면으로 구현될 수 있다는 것이다.
바운더리 클래스를 발견하기 위해 각각의 액터/시나리오 쌍을 조사한다. 정제기간동안에 선택되어지는 바운더리 클래스는 전형적으로 높은 레벨에 있다. 예를 들면 여러분은 윈도우를 모델링 할 수 있지만 각각의 다이얼로그 박스나 버튼들을 모델링하지는 않는다. 이러한 시점에서 여러분은 사용자 인터페이스를 구현하는 것이 아니라, 사용자 인터페이스에 대한 요구사항을 문서화 할 수 있다.
사용자 인터페이스 요구 사항들은 분명하지 않고 모호한 경향이 있고, 개발자들에게는 어렵지만, 사용자들에게는 친숙하고 융통성 있는 용어들이 많이 사용된다. 그러나 사용자에게 친숙하다는 의미는 사람들마다 다른 의미로 쓰일 가능성이 있다. 이러한 이유 때문에 초기의 개발 단계에서는 프로토타이핑 기술과 스토리보딩(storyboarding) 기술은 매우 유용하다.

♠ 브레인 스토밍(Brainstorming), 스토리보딩(Storyboarding), 롤 플레잉(Role playing), 워크 샵(Workshop)과 같은 기술들은 시스템 개발에 유용한 기술들이다. 필자는 독자들에게 또 하나의 약속을 해야 될 것 같다. 눈치가 빠른 분은 벌써 알아 차렸을 듯 하니 자세히 이야기 하지 않겠다.

 

컨트롤 클래스

컨트롤 클래스는 하나 이상의 유즈케이스에 특화 되어진 일련의 행위를 모델화 한 것이다. 컨트롤 클래스는 유즈케이스에 기술된 행위를 실현하는데 요구되어지는 이벤트들을 조화시킨다. 순차적인 행위에 대해, 하나 또는 그 이상의 구체적인 바운더리 클래스와 엔티티 클래스들을 연결하는 역할을 한다. 컨트롤 클래스는 유즈케이스를 '수행' 또는 '실행'하는 것으로 생각해 볼 수도 있으며, 유즈케이스의 동적인 특성, 기능, 서비스를 구체적으로 표현한다.
컨트롤 클래스는 정제단계에서 액터/유즈케이스 쌍에 의해서 추가되어지고, 유즈케이스의 이벤트의 흐름에 책임을 진다.
컨트롤 클래스의 사용은 매우 주관적이다. 많은 권위자들은 컨트롤 클래스의 사용이 데이터로부터 행위를 분리하는 결과를 가져온다고 느낀다. 만약 여러분의 컨트롤 클래스가 현명하게 선택되어지지 않는다면 이러한 일이 발생할 것이다 만약 컨트롤 클래스가 순차적인 행위를 돕는 일 이상을 수행한다면, 그 컨트롤 클래스는 너무 큰 것이다. 예를 들면, 수강 등록 시스템에서 학생은 개설과목을 선택하고 만약 코스가 유용하다면 과목에 학생을 추가할 것이다. 누가 학생을 추가하는 방법에 대해서 아는가? 컨트롤 클래스인가 아니면 개설과목인가? 옳은 답은 개설과목이다. 컨트롤 클래스는 언제 학생이 추가되어지는 지 알고, 컨트롤 클래스는 어떻게 학생이 추가되어지는지 안다. 액터와 유즈케이스 쌍마다 컨트롤 클래스를 추가하는 것은 초기 산출물이고, 분석과 설계가 계속됨에 따라 컨트롤 클래스는 제거되어지고, 분리되고, 병합되어진다.

한마디 더

다음 그림은 분석 클래스들간의 관계를 보여주고 있는 것이다. 액터는 단지 바운더리 객체와만 메시지를 전달 할 수 있고, 바운더리 객체와 엔티티 객체는 단지 컨트롤 객체와만 메시지를 전달할 수 있고, 컨트롤 객체는 바운더리, 컨트롤, 엔티티 객체 모두와 메시지를 교환할 수 있지만, 액터와는 메시지를 전달하지 못한다.

##########5*

그림 6) 분석 클래스의 메시지 전달 규칙

 

위의 한마디 더 부분에 설명된 내용은 Doug Rosenberg with Kendall Scott의 저서인 「Use Case Driven Object Modeling with UML」에서 발췌한 그림이다. 래셔널 유니파이드 프로세스에서는 이 부분에 대한 접근이 좀 다르다. 그러나 독자들은 기본으로서 위에 설명된 부분에 대해서 정확히 이해하는 게 중요할 것 같아, 래셔널 유니파이드 프로세스에서 제시하는 부분은 특집 기사의 순서에 따라 연재하기로 하고 여기서는 제외하였다.

 

클래스의 문서화

클래스가 만들어질 때, 문서화되어져야 한다. 문서화는 클래스의 구조를 기술하는 것이 아니라, 클래스의 목적을 기술하는 것이다. 예를 들면, 학생클래스는 다음과 같이 문서화된다.

##########6*
그림 7) 클래스 스테레오 타입을 설정하고 학생 클래스를 문서화.

클래스 문서화를 나쁘게 한 예는 다음과 같다. "학생의 이름, 주소, 전화번호" 이러한 정의는 단지 클래스의 구조만을 말하고 있어서, 왜 내가 클래스를 요구했는가를 말하지 않는다. 클래스의 이름을 정하고 문서화하는데 어려움을 느낀다면, 이 클래스에 대해서 여러분이 추상화를 잘 하지 못했다는 것을 의미한다. 다음 리스트는 클래스의 이름을 정하고 문서화 할 때 발생하는 것들을 유형화 한 것이다.

  • 이름과 분명하고 간결하게 정의가 된다면 좋은 클래스이다.
  • 이름은 분명하나 다른 클래스와 정의가 같다면, 클래스를 조합하라.
  • 이름은 분명하나 클래스의 목적을 문서화하는 데, 책 한 권 정도의 분량이 필요하다면 이것은 너무 큰 것이므로 좀더 나누어라.
  • 이름을 정하고 정의가 어렵다면 올바른 추상화를 결정할 필요가 있으므로, 좀 더 분석 해야 한다.

 

패키지

만약 시스템이 단지 몇 개의 클래스만을 포함한다면, 여러분은 그것들을 쉽게 관리할 수 있다. 대부분의 시스템은 많은 클래스들로 구성되어 있어서 여러분은 그들을 사용하기 쉽고 관리하기 쉽고 재사용하기 위해서 그룹화 하는 메커니즘이 필요하다. 이러한 경우에 패키지의 개념은 유용하다. 모델의 논리적인 뷰에서의 패키지는 관련 패키지와 클래스들의 집합이다. 패키지 안으로 클래스들을 그룹화 함으로서 우리는 더 높은 레벨에서 모델을 볼 수 있고, 패키지 안에 포함된 것들을 자세히 살펴봄으로서 모델을 더욱 깊게 이해할 수 있다. 앞에서도 이야기했듯이 복잡한 것을 해결하는 최고의 방책은 분할 정복이라는 것을 다시 한번 상기하기 바란다.
각각의 패키지는 다른 패키지 안에 존재하는 클래스들과 커뮤니케이션하기 위한 다른 클래스에 개방되어진(public) 클래스인 인터페이스 클래스를 포함한다. 패키지 안에 존재하는 나머지 클래스들은 다른 패키지 안에 존재하는 클래스들과 커뮤니케이션 하지 않는 구현클래스들이다.
만약 시스템이 복잡하다면, 패키지들은 커뮤니케이션을 돕기 위해서 정제 단계 초기에 만들어질 것이다. 간단한 시스템에서는 분석 초기에 발견된 클래스들이 하나의 패키지로 그룹화 될 것이다. 즉, 이 패키지가 시스템 자체가 될 것이다. 분석과 디자인이 진행됨에 따라 패키지의 개념은 시스템을 만들기 위한 아키텍쳐의 개념을 수행할 필요가 있는 클래스들을 그룹화하기 위해서 사용 될 것이다.

##########7*
그림 8) 패키지에 대한 UML 기호

래셔널 로즈에서 패키지 만들고, 패키지에 클래스 할당하기

  1. 브라우저의 논리적 뷰를 선택하고, 마우스 오른쪽 버튼을 눌러 New:Package 메뉴를 선택한다.
  2. 패키지가 선택된 상태에서 패키지의 이름을 입력하라.

    ##########8*
    그림 9) 브라우저에 만들어진 People Info 패키지

  3. 브라우저에서 클래스를 선택하고 원하는 패키지로 클래스를 드래그한다.
  4. 패키지로 옮겨져야 하는 클래스마다 3의 과정을 반복한다.

    ##########9*
    그림 10) People Info 패키지에 학생 클래스를 옮긴 것


ESU 수강 등록 문제의 객체들과 클래스들

우리는 개설과목 추가라는 시나리오를 좀더 자세히 살펴볼 것이다. 이것은 개설과목 선택의 서브 플로어이다. 이 시나리오에 의해 제공되어지는 것은 주어진 학기에 가르칠 개설 과목을 교수가 선택할 수 있도록 하는 것이다.
비록 우리가 이러한 과정을 단계적인 방법으로 조사할지라도, 이러한 단계의 많은 부분은 실 세계에서는 동시에 발생할 것이다.

S-1 : 개설과목 추가
시스템은 과목 이름과 과목 번호 필드를 포함한 화면을 보여준다. 교수는 과목명과 과목번호를 입력한다(E-3). 시스템은 입력한 과목을 위한 정보를 보여준다(E-4). 교수는 제공되는 과목을 선택한다. 시스템은 교수와 과목정보를 연결시킨다(E-5). 그리고 나서 유즈케이스는 다시 시작된다.

 

바운더리 클래스 찾기

이 유즈케이스는 단지 교수 액터와만 상호 작용한다. 유즈케이스에는 또한 교수가 선택을 수정하고, 삭제하고 검토하고 프린트하는 행위 등이 기술되어져 있을 것이지만, 여기에서는 가르칠 개설 과목을 교수가 선택하는 단지 하나의 행위에 대해서만 적용해보도록 하겠다.
시스템은 교수가 개설과목을 선택할 수 있는 능력을 제공해주어야 한다. 유즈케이스에 기술되어진 교수가 이용할 수 있는 모든 선택을 포함하는 클래스는 이러한 요구를 위해 만들어 진다. 사람 액터의 바운더리 클래스의 종류는 사용자 인터페이스가 되므로, 교수가 과목을 선택할 수 있는 사용자 인터페이스가 필요하다. 이 바운더리 클래스는 교수과목선택(ProfessorCourseOption)이라고 이름지어 진다. 추가적으로 우리는 교수에게 새로운 개설과목을 추가할 수 있도록 하는 클래스를 찾아낼 수 있다. 이 클래스는 개설과목추가(AddACourseOffering)라고 이름을 정한다.

한마디 더

바운더리 클래스

A boundary class는 시스템 외부에 존재하는 것(액터)이 시스템을 사용할 수 있도록 하는 인터페이스와 같은 중간 매체이다. 바운더리 객체는 시스템 외부의 변화에 시스템을 분리시킨다. 액터가 시스템을 사용하는 방법을 바꾸었을 때, 이러한 내용은 사용자 인터페이스에 반영될 것이다. 이러한 변화는 바운더리 클래스에만 영향을 미치고, 시스템의 나머지 부분에는 영향을 미치지 않을 것이다.
시스템은 바운더리 클래스의 여러 가지 유형을 가질 것이다. 다음은 그러한 유형들이다.

  • 사용자 인터페이스 클래스 - 시스템의 인간 사용자들의 커뮤니케이션을 돕는 클래스
  • 시스템 인터페이스 클래스 - 다른 시스템과의 커뮤니케이션을 돕는 클래스
  • 장치 인터페이스 클래스 - 센스와 같은 외부 이벤트를 감지할 수 있는 장치에 대한 인터페이스를 제공하는 클래스

 

엔티티 클래스 찾기

개설과목 추가의 서브 플로어를 수행하기 위해서, 필요한 정보를 찾아보자. 먼저 과목에 해당하는 정보를 보고 위해서 과목정보가 필요하고, 시스템은 개설된 과목을 교수에게 보여주기 위해서 개설과목정보를 필요로 한다. 또한 개설과목과 개설과목을 선택한 교수와 연결을 하기 위해서 교수정보가 필요하다. 우리는 여기서 과목, 개설과목, 교수라는 엔티티를 찾았다.

한마디 더

엔티티 클래스

엔티티 클래스는 저장되어져야 하는 연관된 행위나 정보를 모델 하는 데 사용되어지는 클래스이다. 엔티티 객체(엔티티 클래스의 인스턴스)는 몇몇 현상(이벤트, 사람, 또는 몇몇 실세계의 객체)에 대한 정보를 갱신하고 유지하기 위해 사용되어진다. 그들은 일반적으로 지속되어져야 하고, 오랜 기간동안 속성과 관계를 필요로 한다. 때때로 시스템의 생명주기 동안이 될 수 도 있다.
엔티티 객체는 일반적으로 하나의 유즈케이스 실현에 국한되지는 않는다. 때때로 하나의 엔티티 객체는 심지어 시스템 자체에도 국한되지 않는다. 이것의 속성과 관계는 종종 액터에 의해 주어진다. 엔티티 객체는 또한 내부 시스템의 업무를 수행하기 위해 필요 되어진다. 엔티티 객체는 다른 객체의 스테레오타입만큼 복합적인 행동을 가질 수 있다. 그러나 다른 객체와는 다르게 이 행위는 강하게 엔티티 객체를 표현하는 현상에 관련되어져 있다. 엔티티 객체들은 환경(액터)에 독립적이다.
엔티티 객체는 개발될 시스템의 핵심 개념을 표현한다. 은행의 전형적인 엔티티 클래스의 예는 계좌와 고객이다. 네트웍 핸들링 시스템에서는 노드(node)와 링크(link)이다. 만약 여러분이 모델하기를 원하는 현상이 어떠한 다른 클래스에 의해서 사용되어지지 않는다면 이것을 엔티티 클래스의 속성으로 또는 엔티티 클래스 사이의 관계로서 모델 화하라. 반대로, 만약 현상이 디자인 모델의 다른 클래스에 의해서 사용되어진다면 이것은 클래스로서 모델 해야 한다.
엔티티 클래스들은 논리적인 데이터 구조를 보여주고, 여러분이 무슨 정보가 사용자에게 제공되어져야 하는지 이해하는 것을 도울 수 있기 때문에, 엔티티 클래스는 시스템을 이해하는 다른 견해를 준다.

위에 설명한 말들을 꼼꼼히 고심을 하면서 보지 않는다면, 무슨 말인지 잘 모를 수도 있다. 쉽게 풀어 설명하기 위한 예로서, 20대의 현재 보유한 돈의 액수가 10000원인 한 사람 김영만을 살펴보자. 이 사람은 학교 업무를 수행할 때는 학생으로, 여자친구와의 데이트에서는 애인으로, 과외를 할 때에는 선생님으로 많은 역할을 수행한다.
학교 업무를 위해서, 학용품 구입을 하기 위해서 1000원을 썼다. 보유액은 9000원이 되고, 과외에 대한 돈으로 10000원을 받았다면, 보유액은 19000원이 되고, 여자친구와 데이트를 위해서 5000원을 사용했다면, 보유액은 14000원이 되는 것이다. 여러 가지 작업에 해당되는 부분에서 이 사람은 여러 가지 역할을 한다. 그러나 그 사람의 역할은 여러 개 일지라도 실체는 김영만 한사람만 있는 것이다. 위에서도 보아 알 수 있겠지만, 김영만이라는 사람의 보유액은 저장되고 변경된다는 것을 알 수 있다. 대부분의 엔티티의 정보가 저장되어야 한다는 것을 이해할 수 있을 것이다. 그래서 우리가 찾아내는 엔티티들은 대부분 데이터베이스에 저장되는 것들이다.
여기에서 엔티티(개체)와 객체와의 차이에 대해서 궁금해 미치는 사람도 있을 것이다. 일반적인 정의로는 [객체는 식별자(identity), 행위(behavior), 상태(State)를 가지는 유형의 또는 무형의 것이다. 엔티티는 긴 생명주기를 가지는 객체이다.]라고 설명할 수 있을 것이다.
필자가 처음 객체지향 분석, 설계에 관심을 갖고 공부를 할 때 가장 의아해 했던 것은 어떻게 현실의 객체와 시스템의 객체를 같은 것으로 볼 수 있을 까? 에 대한 것이었다. 예를 들면, "수강신청이라는 업무에서 현실에 있는 사람이 학생의 역할을 하기 때문에 학생이라고 하고, 교수의 역할을 하기 때문에 교수라 한다. 그리고 조교는 학생의 역할과 교수의 역할을 동시에 하므로 조교와 교수의 클래스를 상속받아 설계한다."와 같이 배웠다. 현실세계에서는 이러한 것들은 통하지 않는다. 조교가 아니던 학생이 조교가 될 수도 있고, 공부를 열심히 해서 교수가 될 수도 있다. 이렇듯 역할은 변하게 마련이다. 역할이 변한다고 원래 그 사람도 변하는가? 그렇지 않다. 그 사람은 어제도 그 사람이고 오늘도 그 사람인 것이다. 현실 세계에 존재하는 바로 이 사람이 엔티티인 것이다. 그래서 해석도 실체 아닌가?
그럼으로 현실세계의 엔티티를 시스템으로 옮길 때에는 엔티티의 상태가 유지되어야 한다. 시스템이라는 것은 현실 세계와는 다르게 컴퓨터를 켜고 해당 프로그램을 돌릴 때만 실현되는 것이다. 그러한 이유는 현실 세계를 모방하기 위해서는 어딘가 현실세계의 엔티티를 의미하는 객체들의 상태는 저장되어 있다가 전원이 나가기 전 상태를 반영해야 한다. 왜 엔티티가 오랫동안 존재하고 시스템에 저장되어야 하는 정보이어야 하는가를 명확히 알 수 있다.
이러한 엔티티의 개념은 작은 범위의 문제를 해결하기 위한 정보 시스템을 구축하는 데에는 별로 나타나지 않으나, 큰 범위의 기업시스템과 같은 곳에서는 여러 업무를 지원해야 하기 때문에, 엔티티의 개념은 유용하게 사용된다.
위에서 이야기했던 김영만이라는 사람에 대해서 다시 생각해 보자. 이 사람이 학교를 졸업하고 소프트개발 회사에 프로그래머로 취업을 했다면, 그 사람은 소프트웨어 개발이라는 업무에서 프로그래머의 역할을 해야 할 것이다. 사람 자체는 변하지 않으므로 역할만을 추가하면 된다. 시스템을 이러한 개념으로 분석하고 설계하는 것의 장점은 재사용 성이다. 하나의 엔티티를 가지고 여러 업무에 확장하여 사용할 수 있다는 것이다.

♠ 이러한 개념은 컴포넌트 설계에 반영되고 있다. 컴포넌트 설계에서는 역할을 타입으로 설계한다. 실제 컴포넌트의 구현의 의미에서는 타입은 인터페이스로 엔티티는 컴포넌트로서 설계하고 있다.
(컴포넌트 설계에 관심 있는 독자라면, Desmond F. D'Souza와 Alan C. Wills의 저서 [Objects, Components, And Frameworks with UML The Catalysis Approach]을 반드시 읽어보시기 바란다. 여러분의 사고를 확장해 주는 훌륭한 책이 될 것이다.)

자 이제 엔티티의 개념이 확실해 졌는가? 이견이 있거나, 다른 좋은 생각이 있으신 분은 저에게 메일을 보내 주세요.

 

컨트롤 클래스 찾기
우리는 유즈케이스의 이벤트의 흐름을 다루기 위한 하나의 컨트롤 클래스를 추가할 수 있다. 이 클래스의 이름은 교수과목관리자(ProfessorCourseManager) 이다.
찾아진 클래스들(스테레오 타입을 가진 엔티티, 컨트롤, 바운더리 클래스)은 그림 11과 같이 모델에 추가되어진다. 이미 교수라는 액터의 이름이 존재하기 때문에 래셔널 로즈는 여러분이 교수라는 클래스를 만들 때 이미 교수라는 이름이 존재한다는 것을 알려준다.

##########10*
그림 11) 개설과목 추가 시나리오를 위한 클래스들

한마디 더

유즈케이스 기술 보강 분석 클래스를 찾는 작업의 입력으로 유즈케이스가 사용된다. 그러나, 각각의 유즈케이스의 설명이 그들의 분석 클래스와 그들의 객체를 발견하는데 충분하지는 않다. 고객은 일반적으로 시스템 내부에서 발생하는 것에 대한 정보를 찾는 것에는 관심이 없어서 유즈케이스의 설명은 그러한 정보를 빼 먹는다. 이러한 경우에 유즈케이스의 설명은 블랙박스와 같은 것이 되어 버린다. 유즈케이스를 수행하는 객체를 찾기 위해서, 여러분은 내부적인 관점에서 시스템이 무엇을 행하는가에 대한 화이트 박스의 설명을 가질 필요가 있다.
예를 들자면, ATM(Automated Teller Machine)에서, 시스템의 고객은 사용자 인증이라는 시스템의 행위를 설명하기 위해서 "ATM은 은행 고객의 카드의 유효성을 평가한다." 와 같이 말하기를 좋아 할 것이다. 이것은 고객에게는 충분할 지 모르지만 ATM이 카드의 유효성을 평가할 때 내부에서 실제 발생되는 일이 무엇인가에 대한 실제 생각은 없다.
객체를 식별한 만한 세부기술의 레벨에서 시스템이 실제 어떻게 작용하는지에 대한 내부적 그림을 작성하기 위해서는 우리는 추가적인 정보가 필요하다. ATM 카드의 유효성 평가 행위를 가지고 확장된 설명은 다음과 같다.
"ATM은 고객의 계좌 번호와 암호를 ATM 네크웍에게 유효성을 평가할 수 있도록 보낸다. ATM 네트웍은 만약 고객의 번호와 비밀번호가 정확하다면, 고객에게 트랜잭션을 수행할 수 있도록 인증 할 것이다. 그렇지 않으면 ATM 네트웍은 실패를 리턴 할 것이다.
이러한 세부 레벨에서 우리는 무슨 정보가 요구되어지는지에 대해 분명하게 알 수 있고, 누가 인증에 대한 책임을 지고 있는지도 분명하게 알 수 있다. 이러한 정보로부터 우리는 두 가지 가능한 객체들(계좌 번호와 비밀번호를 가진 고객 객체와 ATM 네트웍 인터페이스)과 그들의 책임성을 찾아낼 수 있다.

 

패키지 만들기

다음 단계는 패키지 안으로 클래스들을 그룹화 하는 것이다. 이 시기에 우리는 과목, 개설과목, 교수, 교수과목선택(ProfessorCourseOptions), 개설과목추가(AddACourseOffering), 교수과목관리자(ProfessorCourseManager)의 여섯 개의 클래스를 찾아냈다.
그것들은 세 개의 논리적인 그룹으로 나뉘어 진다. 그룹은 대학에 고유한 것들, 사람에 대한 정보를 포함하는 것들, 액터의 인터페이스에 관한 것이다. 각각의 패키지는 인터페이스(Interfaces), 대학 관련물(University Artifacts), 사람 정보(People Info)와 같이 이름 붙이고, 클래스들은 찾아진 패키지로 옮긴다. 그림 12에서 패키지들과 그들에 할당된 클래스들을 보여주고 있다.

##########11*
그림 12) 브라우저에서의 패키지

그림 13은 로즈 2000에서 작성한 것이다. 스테레오 타입의 아이콘들을 제공해주기 때문에 우리는 좀더 직관적으로 바운더리 클래스와 엔티티 클래스, 컨트롤 클래스를 구별할 수 있다.

##########12*
그림 13) 로즈 2000에서 작성된 패키지

클래스 다이어그램

점점 클래스가 모델에 추가되어감에 따라, 클래스의 텍스트적 표현(클래스의 이름)만으로는 충분하지 못하다. 클래스 다이어그램은 모델에서 클래스의 몇몇 또는 모든 것의 그림 또는 뷰를 제공하기 위해 만들어진다.
모델의 논리적인 뷰에서 메인 클래스 다이어그램은 전형적으로 시스템 안에 있는 패키지의 그림이다. 각각의 패키지는 또한 자신의 메인 클래스 다이어그램을 가지고 있고, 이곳에는 전형적으로 패키지의 개방(public) 클래스를 위치시키고, 다른 다이어그램들은 필요에 의해 만들어진다. 다른 다이어그램은 전형적인 사용은 다음과 같다.

  • 패키지 안에 존재하는 모든 구현 클래스에 관한 뷰
  • 하나이상의 클래스의 행위와 구조에 관한 뷰
  • 상속관계에 관한 뷰

래셔널 로즈에서 메인 클래스 다이어그램

로즈는 자동적으로 모델의 논리적인 뷰에 메인 클래스 다이어그램을 만든다. 메인 클래스 다이어그램에 패키지 추가하기

  1. 브라우저 안에 있는 메인 다이어그램을 더블 클릭하여 메인 다이어그램을 연다.
  2. 브라우저에서 패키지를 선택하고 다이어그램에 드래그 한다.
  3. 계속해서 다른 패키지에 대해서 2의 단계를 반복한다.

    ##########13*
    그림 14) 메인 클래스 다이어그램


수강등록 시스템의 메인 클래스 다이어그램은 그림 14에서 보여주고 있다.

래셔널 로즈에서 패키지의 메인 클래스 다이어그램 만들기

  1. 클래스 다이어그램의 패키지를 더블 클릭 한다.
  2. 로즈는 패키지를 열면서, 패키지의 메인 클래스 다이어그램을 만들고 보여 준다.
  3. 브라우저에서 클래스를 선택하고 다이어그램으로 클래스를 드래그 한다.
  4. 다이어그램에 위치시킬 클래스에 대해서 3의 단계를 반복한다.

    ##########14*
    그림 15) 대학관련(University Artifacts) 패키지의 메인 클래스 다이어그램

##########15*
그림 16) 래셔널 로즈 2000에서 작성


대학관련(University Artifacts) 패키지를 위한 메인 클래스 다이어그램은 그림 15와 그림 16에서 각각 로즈 98과 로즈 2000으로 작업한 그림을 보여주고 있다. 그림 16은 좀더 분석클래스를 명확히 보여 주고 있다.
개설과목 클래스가 빠져있는 것을 발견할 수 있을 것이다. 이것은 구현 클래스이므로 우리는 패키지의 메인 클래스 다이어그램에서는 빼기로 결정하였다. 패키지와 클래스가 추가됨에 따라 추가적인 다이어그램은 필요에 따라 만들어진다.

한마디 더

로즈에서 클래스 많을 때, 클래스를 일일이 클래스 다이어그램으로 옮기는 작업이 귀찮을 때가 있다. 이러할 때에 메뉴에서 Query:Add Classes... 메뉴를 선택하여 작업을 수행할 수 있다.

 

래셔널 로즈에서 가시성(Visibility) 표시 설정하기

가시성 표시의 기본 값을 설정하기 위해서는

  1. 메뉴에서 Tools:Options 선택하고, Diagram 탭을 선택 한다.
  2. Show Visibility 체크박스를 선택해서 기본 값을 모든 클래스의 가시성 보여주기로 설정한다.

    ##########16*
    그림 17) 가시성 디스플레이 기본 값 설정

선택된 클래스에 대한 가시성 설정하기

  1. 다이어그램에서 클래스를 선택하고 오른쪽 마우스 버튼을 눌러 메뉴를 보이게 한다.
  2. Options:Show Visibility를 선택한다.
##########17*
그림 18) 가시성 설정

가시성 보여주기를 설정했을 때의 클래스 다이어그램은 그림 19에서 보여주고 있다. 해당 패키지의 요소가 아닌 것들은 (from 패키지명)과 같이 가시성이 표시되고 있다.

##########18*
그림 19) 가시성이 설정된 상태에서의 클래스 다이어그램

##########19*
그림 20) 로즈 2000에서 작성

요약

  1. 객체(object)는 실세계에 있는 것이든 창조되어진 것이든 간에 엔티티(entity)의 컴퓨터 적인 표현이다. 객체는 개념이고, 추상이고, 또는 어플리케이션에 위한 분명한 경계와 의미를 가지는 것이다. 시스템 안에 있는 각각의 객체는 세 가지 특징을 가지는데 그것은 상태(state), 행위(behavior), 식별자(identity)이다. 객체의 상태는 객체가 존재할 때의 가능한 조건이다. 상태의 표현은 결국 속성들의 조합으로 이루어지며, 업무 규칙이나 제약사항으로 구현 시에 반영된다. 각각의 객체가 고유하다는 것을 기술하는 것이 식별자이다.
  2. 클래스는 공통의 속성과 공통의 행위와 다른 객체와 공통의 관계와 공통의 의미를 가지는 객체들의 그룹의 설명이다. UML에서 클래스는 3개의 부분으로 나누어져 있는데, 클래스 이름, 클래스의 구조(속성), 클래스의 행위로 나누어진다. 클래스가 만들어지면, 그것들은 문서화되어야 한다. 문서는 클래스의 목적을 기술하는 것이지 구조를 기술하는 것이 아니다.
  3. 스테레오타입들은 모델링의 새로운 요소를 만드는 능력을 제공한다. 스테레오타입들은 UML 메타모델의 부분인 요소들에 기반 해야 한다. 분석동안 3개의 클래스의 스테레오 타입이 이용되는데, entity, boundary, control 이다. 이러한 스테레오 타입은 개발기간동안 시스템을 위해 필요로 하는 클래스를 정의하는데 유용하게 사용되어 진다.
  4. 패키지는 모델의 논리적인 뷰 로서, 관련된 패키지와 클래스의 모임이다. 패키지로 클래스들을 그룹화 함으로서, 우리는 더 높은 레벨에서 모델을 바라볼 수 있다. 우리는 패키지 별로 좀더 자세히 관찰함으로서 모델에 대해 더 깊이 이해할 수 있을 것이다.
  5. 클래스 다이어그램은 모델 안에 있는 몇몇 또는 모든 클래스에 대한 그림 또는 뷰를 제공한다. 클래스 다이어그램은 또한 모델의 유즈케이스 뷰 안에서 만들어질 수 있다. 이러한 다이어그램은 전형적으로 유즈케이스에 붙여지고, 유즈케이스 참여하는 클래스의 뷰를 포함한다.

객체의 상호작용 발견하기(Finding Object Interaction)

  • 유즈케이스의 실현(Use Case Realization)
  • 시나리오 문서화(Documentation Scenarios)
  • 시퀀스 다이어그램(Sequence Diagrams)
  • 시퀀스 다이어그램과 바운더리 클래스(Sequence Diagrams and Boundary Classes)
  • 복잡성과 시퀀스 다이어그램(Complexity and Sequence Diagrams)
  • 컬레보레이션 다이어그램(Collaboration Diagrams)
  • 왜 두 개의 다른 다이어그램이 있을까?(Why are There Two Different Diagrams?)
  • ESU 수강등록 시스템을 위한 다이어그램 (Sequence Diagram for the ESU Course Registration System)
  • 요약(Summary)

유즈케이스 실현(Use Case Realization)

유즈케이스 다이어그램은 시스템에 대한 외부적인 관점을 나타내는 것이다. 유즈케이스의 기능은 이벤트의 플로우 안에서 얻어진다. 시나리오는 어떻게 유즈케이스가 객체의 상호작용에 의해서 실현되는지를 설명하기 위해서 사용된다. 유즈케이스의 이벤트 플로어는 여러 가지 대안적인 플로어와 예외 플로어들이 존재하기 때문에, 많은 경로를 가지게 된다. 하나의 시나리오는 유즈케이스의 이벤트 플로어에서의 하나의 경로에 대한 인스턴스이다. 시나리오는 유즈케이스에 의해 기술된 하나의 기능을 수행하기 위해 필요한 객체, 클래스, 객체들간의 관계를 발견하는 것을 돕는데 사용되어 진다. 시나리오는 어떻게 유즈케이스에서 기술된 책임성을 시스템의 객체와 클래스에 분산하느냐에 대한 것이다. 또한 요구사항 분석 시 고객과 개발자간의 효과적인 의사소통을 돕는 훌륭한 매개체로 사용되어진다. 시나리오들은 사용자, 업무의 전문가의 입장에서 기술되어져야한다. 그렇게 함으로서, 개발자가 사용자의 요구사항을 진정으로 반영할 수 있도록 시스템에 대해 바라는 고객의 기대를 기술하는 수단을 제공한다.

한마디 더

시나리오와 스냅 샷
우리는 영화의 시나리오에 대해서 잘 알 것이다. 하나의 시나리오를 진행해 나가는 데에는 여러 명의 주인공과 그에 관련된 많은 관련 물들이 이용된다. 시나리오에는 "허준이 예진낭자와 말을 타고 한양에 가다."와 같이 실제 객체들을 사용한다. 여기서 "남자와 여자가 말을 타고 도시에 가다."와 같이 대표성을 가진 클래스로 이야기하는 것이 아니라, 실제 객체로서 기술해 나간다는 것을 주목해야 한다. 객체지향의 시나리오도 마찬가지이다. 유즈케이스의 이벤트 플로어에 대한 하나의 시나리오를 진행해 나가는 것은, 실제 객체들을 이용해서 이야기를 전개해 나가는 것을 말한다. 그래서 우리는 실제 업무에서 그러한 시나리오를 위해 필요한 객체들을 찾고, 그러한 객체들이 어떻게 상호작용을 하여 하나의 시나리오를 마치게 되는지를 알아야 한다. 객체들의 실제 객체들과 그들의 상호작용에서 클래스를 추출해 낼 수 있을 것이다. 우리는 허준의 시나리오에서 사람(허준, 예진낭자) 클래스와 운송수단(말)과 도시(한양)과 같이 클래스를 추출해 낼 수 있을 것이다. 시나리오를 이용하여 클래스를 찾아내는 것은 매우 유용한 것이다. 시나리오를 이용할 때 스냅 샷(snap shot : 영화에서의 한 장면을 이야기한다.)을 이용하면 객체들의 다 수성을 찾아내는 훌륭한 도구로 사용할 수 있다.


각각의 유즈케이스는 시나리오가 거미줄처럼 연결되어 있는데, 시나리오는 일차적(primary) 시나리오와 이차적(secondary) 시나리오로 되어 있다. 일차적 시나리오는 무엇을 해야 하는가에 대하여 기술한 것이고, 이차적 시나리오는 조건에 의해 분기되는 부분에 대하여 기술한 것이다.
분석초기에는 각각의 발견된 유즈케이스에 대하여 일차적 시나리오를 발견하는 정도로 만족하는 것이 좋다. 여러분이 새로운 시나리오를 발견해 냈을 때, 이전에 식별된 시나리오로부터 많은 단계가 반복되어진다면, 이것은 시나리오 발견의 마감 선에 도달했다는 것을 의미한다. 분석기간에 일단 팀이 2차 시나리오의 대표적인 것들의 선택과 함께, 시스템의 1차 시나리오의 약 80%를 정제해 왔다면 마감할 때가 온 것이다.

한마디 더

용어의 번역
번역시 대부분의 사람들이 느끼는 어려움은 용어에 대한 번역을 어떻게 할 것인가에 대한 것이다. 이미 한글화되어 있는 경우는 좀 쉽겠지만, 이 경우에도 표준적으로 정해지지 않았다면, 이미 존재하는 한글화된 용어를 그대로 따르는 것과 원어에 충실하는 것 두 가지 선택의 기로에서 매우 힘들어 할 것이다. 물론 필자도 그러한 어려움에 직면한 적이 한 두 번이 아니다. UML의 한글 서적과 번역서적이 많이 출간되면서, UML 용어의 한글화의 진행이 빨리 되어가고 있는 것 같다. 특히 UML 사용자 가이드와 같은 곳에서는 고심의 흔적이 많이 보이고 있다. 그러나 필자는 여기서 그러한 한글화된 용어를 그대로 사용하지 않았다. 그래서 순차도, 또는 협력도와 같은 용어보다는 시퀀스다이어그램, 컬레보레이션 다이어그램과 같이 사용하고, 그 용어의 원어를 가로를 사용하여 같이 보여주고 있다. 물론 부분적으로 한글화를 적용한 부분도 있다. 그러나 이런 부분에서 필자는 어색한 느낌을 버릴 수 없었다. 용어의 한글화는 정말 어려운 것 같다. 앞으로 좀더 정리해 나가면서, 이러한 부분들을 보강해 나가도록 하겠다.


로즈 98에서는 유즈케이스 실현에 대한 아이콘을 제공하지 않고 있지만, 로즈 2000에서는 아이콘을 제공하고 있다.
래셔널 통합 프로세스(Rational Unified Process)에서는, 유즈케이스 실현은 모델의 논리적 뷰에 포함되어져 있다. 우리는 여기서 다시 스테레오 타입을 사용할 것이다. 그 이유는 우리가 이미 만든 유즈케이스 뷰에 존재하는 유즈케이스와 논리적 뷰에 존재하는 유즈케이스가 같은 이름을 가지고 있고, 논리적 뷰에 존재하는 유즈케이스가 논리적인 뷰에 존재하는 유즈케이스에 대한 실현이라는 것을 보여주기 위해서 이다. UML에서 유즈케이스 실현은 점선의 달걀모양으로서 그려지는데 그림 21에서 보여주고 있다.

##########20* ##########21*
그림 21) 유즈케이스 실현(use case realization) - 로즈 2000과 로즈 97에서

래셔널 로즈에서 논리적인 뷰에 유즈케이스 다이어그램 만들기

  1. 브라우저에서 논리적 뷰 패키지를 선택하고 마우스의 오른쪽 버튼을 눌러 New:Use Case Diagram을 선택한다. 이것은 NewDiagram이라는 이름을 가지고 브라우저에 추가되어진다.
  2. NewDiagram의 이름이 여전히 선택되어있는 상태에서 'Realizations'이라는 이름을 입력하라. Realizations 유즈케이스 다이어그램은 그림 22에서 보여주고 있다.

    ##########22*

    ##########23*
    그림 22) Realizations 유즈케이스 다이어그램 추가
    - 로즈 2000(상), 로즈 97(하)


래셔널 로즈에서 유즈케이스의 실현 만들기

  1. 다이어그램을 열기 위해서, 브라우저에서 'Realizations' 유즈케이스 다이어그램을 더블 클릭 한다.
  2. 툴바에서 유즈케이스 아이콘을 선택하고, 유즈케이스를 위치시키기 위해서 유즈케이스 다이어그램 창 위에다 클릭을 한다. 새로운 유즈케이스가 다이어그램 위와 브라우저에 추가되어질 것이다.
  3. 유즈케이스 상세 창(use case specification window)을 열기 위해서 유즈케이스를 더블 클릭하자.
  4. Name 필드에 유즈케이스 이름을 유즈케이스에 뷰에서 사용한 유즈케이스의 이름과 같은 이름으로 입력한다. 여기서 주의 할 점은 여러분이 반드시 래셔널 로즈에서 제공하는 이름공간에 대한 지원을 받기 위해서는 상세 창 또는 브라우저에서 이름을 입력해야 한다는 것이다. 만약 여러분이 유즈케이스 다이어그램에서 이름을 입력하면, 래셔널 로즈는 유즈케이스의 뷰에서 사용하고 있는 유즈케이스와 같은 것으로 여긴다. 유즈케이스 뷰에서의 유즈케이스와 논리적인 뷰에서의 유즈케이스를 다른 것으로 사용하기 위해서는 위의 원칙을 잘 지켜야 한다.
  5. Stereotype 필드에서 드롭다운 메뉴를 보일 수 있게 하기 위해서 화살표를 클릭하고, use-case realization을 선택한다.

    Realizations' 유즈케이스 다이어그램은 그림 23에서 보여주고 있다.


    ##########24*

    ##########25*
    그림 23) Realizationszations 유즈케이스 다이어그램
    - 로즈 2000(상), 로즈 97(하)


논리적인 뷰에서 유즈케이스와 유즈케이스 뷰 안에 있는 유즈케이스 사이의 추적가능성(traceability)은 유즈케이스 뷰의 유즈케이스를 'Realizations' 다이어그램에 추가하고 그들을 스테레오 타입 <> 을 가진 일 방향 연관(unidirectional association)을 사용하여 그들의 실현에 연결한다. 여기서 추적가능성이라는 말은 작업의 진행 과정에서 하위 단계의 작업에 대한 상위 작업을 찾아낼 수 있어야 한다는 것을 의미한다.
그림 24는 'Realizations' 유즈케이스 다이어그램의 추적가능성을 보여주고 있다.

##########26*

##########27*
그림 24) 유즈케이스의 실현의 추적가능성(traceability)을 보여주는 다이어그램
- 로즈 2000(상), 로즈 97(하)

 

시나리오 문서화(Documenting Scenarios)

유즈케이스의 이벤트 플로어는 텍스트로 기술되는데 반하여 시나리오는 상호작용(Interaction) 다이어그램으로 표현된다. 상호작용 다이어그램은 두 가지 종류가 있는 데, 시퀀스 다이어그램과 컬레보레이션 다이어그램으로 나누어진다. 각각의 다이어그램은 시나리오의 그래픽적 뷰이다.

- 시퀀스 다이어그램(Sequence Diagrams)
시퀀스 다이어그램은 시간적인 순서로 정렬된 객체들의 상호작용을 보여준다. 이것은 시나리오의 기능을 수행하기 위해 필요한 객체, 클래스와 그들 사이에 존재하는 메시지를 갖는다는 특징을 가지는데, 전형적으로 개발 중에 시스템의 모델에서 유즈케이스와 연관되어 있다. 래셔널 통합 프로세스에서는 시퀀스 다이어그램을 시스템의 논리적인 뷰에 존재하는 유즈케이스 실현과 연관시키고 있다.

한마디 더

래셔널 로즈 98에서는 유즈케이스 실현에 대한 아이콘을 제공하지 않고, 또한 거기에 따른 스테레오 타입도 기본적으로 제공하고 있지 않다. 그러나 우리는 앞에서도 이야기했듯이, 이러한 스테레오 타입을 만들어서 사용할 수 있다. 물론 아이콘도 만들어 사용할 수 있다. 로즈 98을 사용한다고 해서, 기죽을 것은 없다. 단지 기본적인 스테레오 타입으로서 지원과 해당 아이콘을 제공하지 않는다고 해서 하지 못한다는 것은 말이 안되기 때문이다. 2000에서 새롭게 지원하고 있는 액티비티 다이어그램의 경우도 마찬가지이다. 툴을 사용할 수 는 없지만 종이를 사용하면 되지 않는가?

UML에서는, 시퀀스 다이어그램에 존재하는 객체는 사각형으로 표시되고, 객체의 이름에는 밑줄이 그려진다.
시퀀스 다이어그램에서 하나의 객체는 세 가지 방법으로 표현될 수 있다. 이 세 가지 표현 방법은 그림 5-5과 같다.

  1. 객체이름만 표시하는 경우
    ##########28*
  2. 객체와 클래스 이름을 같이 표시하는 경우
    ##########29*
  3. 클래스명만 표시하는 경우
    ##########30*

그림 25) 시퀀스 다이어그램에서의 객체 표현 방법

객체의 이름은 위에서 보는 거와 같이 어떤 특정한 것(Algebra 101, Section 1과 같은 것)으로 표현될 수도 있고, 일반적인 것(a course offering와 같은 것)으로도 표현될 수 있다.
각각의 객체는 또한 객체의 아래로 점선으로 그려진 생명선을 가지고 있고, UML에서는 시퀀스 다이어그램에서의 메시지는 클라이언트(메세지를 보내는 객체)로부터 공급자(메세지를 받는 객체)를 향한 화살표로 표현되어진다. 시퀀스 다이어그램에서의 메시지와 객체에 대한 기호는 그림 26에서 보여주고 있다.

##########31*
그림 26) 시퀀스 다이어그램에서의 객체와 메시지를 위한 기호

래셔널 로즈에서 시퀀스 다이어그램을 만들기

  1. 브라우저에서 유즈케이스를 선택하기 위해서 오른쪽 버튼을 클릭하고, 시퀀스 다이어그램 메뉴에서 New:Sequence Diagram을 선택하라. 한 개의 이름 없는 시퀀스 다이어그램이 브라우저에 추가된다.
  2. 새로운 시퀀스 다이어그램이 선택된 상태에서, 시퀀스 다이어그램의 이름을 입력 하라.


    ##########32*


    그림 27) 시퀀스 다이어그램의 브라우저 뷰


래셔널 로즈에서 시퀀스 다이어그램에서 객체와 메시지 만들기

  1. 다이어그램을 열기 위해서 브라우저에서 시퀀스 다이어그램을 더블 클릭 한다.
  2. 브라우즈의 액터를 선택하고 시퀀스 다이어그램에 드래그 하여 위치시킨다.
  3. 새로운 객체를 삽입하기 위해서 툴바에서 객체 아이콘을 선택하고, 객체를 위치시키기 위해서 시퀀스 다이어그램 위에 클릭 한다.
  4. 객체가 선택되어있는 상태에서, 객체의 이름을 입력한다.
  5. 시나리오에 필요한 객체만큼 반복한다.
  6. 툴바에서 해당 메시지 아이콘을 선택하고, 메시지를 보내는 객체를 클릭하고, 메시지를 받는 객체까지 메시지를 드래그 한다.
  7. 메시지가 선택된 상태에서 메시지의 이름을 넣는다.
  8. 7단계와 9단계를 필요한 메시지만큼 반복한다.

그림 28은 Create a Course의 시나리오에 대한 시퀀스 다이어그램을 보여주고 있다.

##########33*


그림 28) 시퀀스 다이어그램


래셔널 로즈에서 시퀀스 다이어그램에 클래스 할당하기

  1. 브라우저에서 클래스를 선택하고, 클래스를 시퀀스 다이어그램의 해당 클래스의 객체가 되는 객체의 위에 끌어다 놓아라. 객체이름, 콜론(:), 클래스 이름의 순서로 클래스와 객체를 표시할 것이다. 만약 객체가 이름이 설정되지 않았다면, 이름은 :클래스 이름과 같이 설정될 것이다.

    "a course" 객체를 가진 시퀀스 다이어그램에 과목 클래스를 할당한 모습을 그림 29에서 보여주고 있다.



##########34*

##########35*
그림 29) 클래스에 할당된 객체를 가진 클래스 다이어그램

로즈 2000에서 작성, 스테레오 타입이 <> 클래스를 객체에 할당하니까, 엔티티의 아이콘으로 변한 모습을 보여주고 있다.

 

시퀀스 다이어그램과 바운더리 클래스
(Sequence Diagrams And Boundary Classes)

바운더리 클래스들은 사용자 또는 다른 시스템과의 상호작용을 보여주기 위해 시퀀스 다이어그램에 추가되어진다. 분석 초기에 바운더리 클래스를 시퀀스 다이어그램에 표시하는 이유는 어떻게 인터페이스를 구현할 것인가가 아니고, 인터페이스에 대한 요구사항을 얻고, 문서화하기 위한 것이다. 액터에서 바운더리 클래스로의 실제 메시지들은 개발 후반에 선택되어지는 어플리케이션의 프레임웍(framework)에 의존된다. 그럼으로, 아마도 바운더리 클래스들은 개발후기에 "How"에 초점을 두면서 많은 부분이 바뀔 것이다.

복잡성과 시퀀스 다이어그램

이 글의 원작자인 Terri Quatrani는 이렇게 말하고 있다. "나의 교육과정에서, 가장 많이 물어오는 질문은 '시퀀스 다이어그램을 얼마나 복잡하게 만들 것인가?' 하는 것인데, 이것에 대한 답은 나의 항상 같은 답은 간단히 유지하라는 것이다. 시퀀스 다이어그램의 최대 장점은 간단히 객체와 객체사이의 상호작용, 메시지를 표현하는 것이기 때문이다. 또 자주 묻는 질문중 하나는 '조건을 가지는 로직에 대해서 어떻게 해야 하는가?' 하는 질문이다. 이것에 대한 답은 로직이 간단할 때에는 일반적으로 하나의 다이어그램에 그리고 간단한 설명을 가진 주석(Note)을 사용한다. 그에 반하여 만약 if, then, else 로직이 복잡한 메시지들을 가지고 있다면, 다이어그램을 분리해서 그린다. if 경우에 대해서 하나, then의 경우에 대해서 하나, else의 경우 각각에 대해서 하나를 작성한다. 만약 바람직하다면, 다이어그램들은 서로 연결이 될 것이다. 이것은 사용자가 다이어그램을 집합을 통해서 이동할 수 있도록 한다.

래셔널 로즈에서 다이어그램들 연결하기 - 로즈 2000에서만 지원

  1. 툴바에서 주석(Note) 아이콘을 선택하고, 주석을 다이어그램에 위치시키기 위해서 클릭 한다.
  2. 주석의 내용을 작성하고, 브라우저에서 주석에 연결시키기를 원하는 다이어그램을 선택하고 주석으로 드래그해서 놓는다.
  3. 연결된 다이어그램으로 이동하기 위해서는 주석을 더블 클릭 하면 된다.



##########36*
그림 30) 클래스에 할당된 객체를 가진 클래스 다이어그램

로즈 2000에서만 지원하는 이 기능은 복잡한 유즈케이스의 많은 서브 플로어들에 대해서 편리하게 작업을 효율적으로 할 수 있도록 돕는 것 같다. 기존에 서브 플로어로의 연결을 단지 주석(note)으로만 표시해 놓고, 서브 플로어에 해당하는 시퀀스 다이어그램을 찾아다니는 것이 매우 귀찮은 일 이였는데, 참 편리해진 것 같다. 사용자의 요구사항을 반영한다는 것이 이런 거 아니겠는가?

 

컬레보레이션 다이어그램(Collaboration Diagram)

컬레보레이션 다이어그램(Collaboration Diagram)은 시나리오를 보여주기 위한 선택적인 방법이다. 이러한 유형의 다이어그램은 객체와 다른 객체와의 연결로 조직화된 객체들간의 상호작용을 보여주는 것이다. 컬레보레이션 다이어그램은 다음과 같은 것을 포함한다.

  1. 사각형으로 그려진 객체들
  2. 객체와 객체사이의 연결(link)
  3. 텍스트와 화살표로서 표시되는 메시지

Collaboration에서 객체와 연결과 메시지에 대한 UML notation은 그림 31과 같다.

##########37*
그림 31) 컬레보레이션 다이어그램에서의 객체, 링크, 메시지에 대한 UML 기호

래셔널 로즈에서 시퀀스 다이어그램을 이용하여 컬레보레이션 다이어그램들 만들기

  1. 다이어그램을 열기 위해서 브라우저에서 시퀀스 다이어그램을 더블 클릭 한다.
  2. Browse:Create Collaboration Diagram 메뉴를 선택하거나, F5키를 눌러 컬레보레이션 다이어그램을 생성한다.
  3. 브라우저에 있는 객체와 메시지를 정돈한다.

그림 32은 컬레보레이션 다이어그램을 보여준다.


##########38*
그림 32) 컬레보레이션 다이어그램

##########39*
그림 33) 로즈 2000에서 작성


컬레보레이션 다이어그램은 또한 시퀀스 다이어그램에서 만들지 않고, 객체들을 가지고 직접 만들 수도 있다. 그러한 경우에 시퀀스 다이어그램은 위의 예와 반대로, 컬레보레이션을 이용하여 만들 수 있다. 과정은 위의 과정과 같다.


왜 두 개의 다이어그램이 존재하는가?
(Why are There Two Different Diagrams?)

시퀀스 다이어그램은 시간 순서로 시나리오를 자세히 볼 수 있는 방법을 제공하고 있다. 그래서 무엇이 처음 발생한 것이고, 그 다음이 무엇인가에 초점을 맞춘다. 그러므로, 초기 분석과정에서 유용하다. 어떻게(How)가 설계시의 주요 테마인 것처럼, 무엇을(What) 해야 하는가를 아는가 하는 것은 소프트웨어 공학의 분석의 주요 주제이기 때문이다. 컬레보레이션 다이어그램은 객체사이의 상호작용을 나타내기 때문에, 시나리오에 대한 큰 크림을 제공한다. 이러한 다이어그램들은 여러분이 설계단계에서 관계의 구현에 대해서 디자인할 때 매우 유용한 것이 될 것이다.


ESU 수강 등록 시스템의 시퀀스 다이어그램
(Sequence Diagram For the ESU Course Registration System)

지금까지의 분석을 가지고, 개설과목 추가(Add a Course Offering) 시나리오에 대해 시퀀스 다이어그램을 작성해 보자. 그림 34는 개설과목 추가의 시퀀스 다이어그램을 보여주고 있다.

##########40*
그림 34) 개설과목 추가 시나리오에 대한 시퀀스 다이어그램

클래스 다이어그램은 또한 유즈케이스 실현에 더해 질 수 있다. 이러한 다이어그램은 유즈케이스에 참여하는 클래스에 대한 뷰를 포함할 수 있다.

래셔널 로즈에서 참여하는 클래스에 대한 뷰를 만들기

  1. 브라우저의 유즈케이스실현 에서 오른쪽 버튼을 눌러, New:Class Diagram 메뉴를 선택한다.
  2. 다이어그램이 여전히 선택되어 있는 상태에서 클래스 다이어그램이 이름을 입력하라.
  3. 브라우저에서 다이어그램을 더블 클릭 하여 다이어그램을 열고, 다이어그램에 표시하고 싶은 클래스들을 브라우저에서 선택하여, 다이어그램에 드래그 해서 놓아라.
  4. 위치시키고 싶은 클래스의 수만큼 3의 과정을 반복하라.

그림 35는 개설과목 선택에 참여하는 클래스들의 뷰인 참여 클래스의 클래스 다이어그램을 보여주고 있다.


##########41*
그림 35) 참여 클래스 클래스 다이어그램


한마디 더

지금까지 우리는 시퀀스 다이어그램을 작성하면서, 객체의 생명선(lifeline)을 사용하였다. 시퀀스 다이어그램의 그림에서 생명선을 따라, 사각형들이 드문드문 보이는데, 이것은 실행(activation)이라 부르며, 객체가 수행하는 오퍼레이션이 실행되는 실행 소요시간을 나타낸다. 이것을 고려하여 작성하는 것은 많은 소요 시간을 필요로 하며, 작성에 있어 불편하다. 이것을 없애기 위해서는 다음과 같이 하면 된다. 그렇다고 해서 필요 없다는 이야기는 아니다. 실제 구현에 있어 객체들의 메소드들의 코딩에 있어 객체의 생명선은 유용하게 사용되어진다. 그러므로 메소드의 코드 작성 시에는 객체의 생명선도 고려해서 작성하는 것이 좋다. 반복 점증의 좋은 점을 다시 한번 보여주고 있다.

  1. Tools:Options 메뉴를 선택한다.
  2. Diagram 탭을 선택한다.
  3. 그림 36와 같이 Focus of control의 체크를 없애자.

##########42*
그림 36) Options에서 다이어그램의 선택사항 변경


요약(Summary)

  1. 유즈케이스 다이어그램은 시스템의 외부 관점을 나타내고, 유즈케이스의 기능은 이벤트 플로어에서 얻어진다. 시나리오는 어떻게 유즈케이스가 객체들의 상호작용에 의해 실현되어지는가를 설명하기 위해 사용되어진다.
  2. 유즈케이스의 이벤트 플로어는 기본 플로어와 대체 플로어, 예외 플로어를 포함하는 여러 가지 경로를 가지는데, 이러한 경로 중에서 인스턴스 된 하나의 경로를 시나리오라 한다. 그러므로 각각의 유즈케이스는 시나리오들에 의해 그물 같이 연결되어 있다. 시나리오들은 객체, 클래스, 객체의 상호작용을 찾아내는 것을 돕기 위해 개발되어지는데, 이러한 객체, 클래스, 관계는 유즈케이스에 기술된 기능의 한 부분을 수행하기 위해 요구되어진다.
  3. 유즈케이스의 이벤트 플로어는 전형적으로 텍스트로 되어 있으나, 그에 비해 시나리오는 상호작용 다이어그램에 의해 얻어진다. 상호작용 다이어그램은 시퀀스 다이어그램과 컬레보레이션 다이어그램으로 구성되어 있다. 각각의 다이어그램은 시나리오의 그래픽 적 뷰이다. 시퀀스 다이어그램은 시간의 순서로 정렬된 객체의 상호작용을 보여준다. 컬레보레이션 다이어그램은 시나리오를 보여주기 위한 대안적인 방법으로 이러한 종류의 다이어그램은 객체들의 상호작용을 더욱 잘 보여준다.

관계 기술(Specifying Relationships)

  • 관계의 필요성(The Need for Relationships)
  • 연관 관계(Association Relationships)
  • 어그리게이션 관계(Aggregation Relationships)
  • 연관인가? 어그리게이션인가? (Association or Aggregation?)
  • 관계 이름 정하기(Naming Relationship)
  • 역할 이름(Role Names)
  • 다수성 표시(Multiplicity Indicators)
  • 재귀 관계(Reflexive Relationships)
  • 관계 찾기(Finding Relationships)
  • 패키지 관계(Package Relationships)
  • 요약(Summary)


관계의 필요성(The Need For Relationships)

모든 시스템은 많은 클래스와 객체들로 이루어져 있다. 시스템 행위는 시스템 안에 있는 객체들의 상호작용에 의해 행해진다. 예를 들면, 학생은 개설과목이 학생을 추가(add student)하라는 메시지를 받을 때, 개설과목 클래스에 추가되어진다. 관계들은 객체의 상호작용을 위한 통로를 제공한다. 분석기간동안 발견되는 두 가지 관계는 연관과 어그리게이션이다.


연관 관계(Association Relationships)

연관 관계는 클래스 사이의 양 방향적 의미의 연결이다. 이것은 구조적 방법론에서의 분석과 설계에서의 데이터 플로어가 아니다. 클래스 사이의 연관은 객체들 사이에 연결이 존재한다는 것을 의미한다. 예를 들면, 과목 클래스와 학생 클래스사이의 연관은 과목 클래스의 객체들이 학생 클래스의 객체와 연결되어져 있다는 것을 의미한다. 또 다른 예는 과목 클래스와 교수과목 관리자 클래스 사이의 연관은 과목 클래스의 객체가 교수과목 관리자 클래스의 객체들에 연결되어져 있다는 것을 의미한다. 연결된 객체들의 수는 다수성을 표기함으로 나타낼 수 있다. UML에서는, 연관 관계를 그림 37처럼 연관된 클래스를 연결하는 선으로 표시한다.

##########43*
그림 37) 연관 관계를 위한 UML 기호

한마디 더

도구 상자에서의 관계 설명

##########44*
그림 38) 도구상자에서의 관계 설명



래셔널 로즈에서 연관 관계 만들기

  1. 도구 상자에서 연관 아이콘을 선택하라. 만약 연관 아이콘이 도구상자에 없다면, 도구상자에 마우스 포커스를 이동시키고 오른쪽 버튼을 눌러 Customize 메뉴를 선택하고, 연관 아이콘을 추가하라.
  2. 클래스 다이어그램 위에 있는, 연관 클래스들 중 하나를 선택하고 나머지 연관 클래스로 연관 선을 드래그 하라.

그림 39는 연관 관계를 보여주고 있다.

##########45*
그림 39) 연관 관계



한마디 더

Association에 대해서

많은 사람들이 자주 묻는 질문 중 하나는 연관과 어그리게이션의 차이이다. 객체들을 살펴보면, 객체들은 그들이 이루어야 하는 목적(보통 책임성으로 표현한다)을 가지고 있다. 이러한 목적은 단일의 객체 자신에서도 이룰 수 있지만, 대 부분 많은 객체들과 상호작용을 함으로써, 이룰 수 있다. 이러한 상호작용을 위해서는 서로 어떠한 관계를 가지고 있어야 하는데, 이러한 관계에는 많은 종류가 있다. 넓게 의미로 보았을 때는 물리적으로 연관된 것과 논리적으로 연관된 것들을 볼 수 있다. 예를 들면, 부모님과 나와는 부모와 자식의 관계를 갖는데, 나는 부모님으로부터 물리적으로 유전자와 기타 이외의 것들을 물려받아 태어났다. 그에 비해 물리적으로는 아무런 관계가 없는데, 어떠한 문제의 범위에 들어감으로서 논리적으로 관계를 맺는 것을 연관이라 한다. 예를 들면, 초와 전등은 물리적으로 관계를 맺고 있지 않지만, 파티라는 범위에서 장식으로 사용될 때, 이것들은 논리적으로 연관을 맺게 된다. 물론 연관과 어그리게이션의 명확한 구분은 해결해야 하는 문제의 범위의 고려 없이 정확하게 말할 수는 없다. 자동차와 타이어가 자동차 정비 서비스에 관한 문제에서 적용될 때와, 자동차 부품 생산에 관한 문제에 적용될 때를 고심해 보면 명확한 해답을 얻을 수 있을 것이다.

 

어그리게이션 관계(Aggregation Relationship)

어그리게이션 관계는 연관관계의 특별한 경우로, 전체가 부분에 연관되어 있는 특별한 형태이다. 어그리케이션은 "a part of" 또는 "containment" 관계로 알려져 있다. 어그리게이션 관계를 표현하는 UML 기호는 다이어몬드 모양을 전체에 해당하는 클래스 쪽에 둠으로 표시한다. 그림 40는 어그리케이션 관계를 보여주고 있다.

##########46*
그림 40) 어그리게이션 관계에 대한 UML 기호

다음과 같은 테스트는 연관이 어그리게이션이 될 수 있는지를 결정하는 데 사용하는 테스트이다.

  1. "Part of" 구문이 관계를 설명하는데 사용되어 지는가?
  2. 전체에 해당하는 부분의 오퍼레이션의 일부가 수행될 때, 자동적으로 부분이 되는 부분 에 적용되는가? 예) 과목을 삭제시키면, 그에 따라 모든 개설과목이 삭제된다.
  3. 하나의 클래스가 다른 클래스에 종속되는가?

예를 들면, 과목(Math 101)은 학기 동안 다른 시간에 제공되어 질 것이다. 각각의 개서과목은(예를 들면, Math 101, Section 1 and Math 101, Section 2)과 같이 표현되어 질 것이다. 과목과 개설과목의 관계는 "하나의 과목은 여러 개의 과목을 가진다(has)"와 같이 어그리케이션 관계가 된다.

래셔널 로즈에서 연관 관계 만들기

  1. 도구상자에서 어그리게이션 아이콘을 선택하고, 부분의 역할을 하는 클래스를 선택하고 어그리게이션 선을 전체의 역할을 하는 클래스 쪽으로 드래그 한다. 어그리게이션 관계는 그림 41에서 보여주고 있다.

##########47*
그림 41) 과목과 개설과목 사이의 어그리게이션 관계 표현

 

연관인가? 어그리게이션인가?

만약 두 개의 클래스들이 전체와 부분의 관계로 밀접하게 묶여 있다면, 관계는 전형적으로 어그리게이션이다. "어그리게이션을 사용하기 위한 결정은 판단의 문제이고 종종 자기 주관적이다. 종종 연관으로 모델링 해야 할지, 어그리게이션으로 모델링 해야 할지 결정을 하기가 모호한 경우가 종종 있다. 만약 여러분의 모델링 활동이 지속적이고, 주의 깊은 판단으로 진행되었다면, 연관과 어그리게이션 사이의 정확하지 않은 구분은 실제에서는 중요한 문제가 아니다." 관계가 연관 또는 어그리게이션인지는 종종 문제영역에 의존한다. 차와 차의 타이어를 살펴보면, 만약 적용 부분이 서비스센터이고, 여러분이 타이어에 관심을 갖는 이유가 서비스하는 차의 일부이기 때문이라면, 이 관계는 어그리게이션이 된다. 그와는 다르게, 타이어 창고라면, 차에 독립적으로 타이어에 주의를 기울여야 한다. 이러한 관계는 연관이 될 것이다.


관계 이름 정하기(Naming Relationship)

연관은 이름이 붙여지는데, 그 이름은 일반적으로 관계의 의미를 전달하는 능동의 동사구로 되어있다. 동사구는 일반적으로 읽는 방향을 암시하기 때문에 왼쪽에서 오른쪽으로 위에서 아래로 올바르게 읽게 하도록 연관의 이름을 정하는 것은 바람직하다. 단어들은 다른 방향에서는 연관을 읽는 것이 바뀌어야 할 것이다. 예를 들면, "교수는 과목을 가르친다. 과목은 교수에 의해 가르쳐진다." 와 같이 될 것이다. 연관의 이름을 기록하는 것은 선택적이라는 것을 명심하기 바란다. 만약 모델의 의미를 좀더 분명하게 하려할 때, 연관의 이름이 필요하다면 이름을 추가하라. 연관 관계의 이름을 붙이기 위해서 너무 많은 시간을 소비하지 않기를 바란다. 어그리게이션의 관계 이름은 일반적으로 붙여지지 않는다. 왜냐하면 어그리게이션은 "has", "contains"를 사용하여 읽혀지기 때문이다.

래셔널 로즈에서 관계 이름 정하기

  1. 클래스 다이어그램에서 관계 선을 선택하고, 바로 관계의 이름을 입력하라.

##########48*
그림 42) 과목과 교수과목관리자의 연관 관계의 이름을
관리(manages)라고 작성


역할 이름(Role Names)

클래스에 연결된 연관의 끝 부분에 연관의 역할을 작성한다. 역할의 이름은 연관 이름 대신에 사용할 수 있다. 역할의 이름은 하나의 클래스가 다른 클래스에 연관된 것에서의 목적 또는 자격을 의미하는 명사이다. 역할의 이름은 해당 클래스의 연관 관계선상에 표시된다. 역할의 이름은 연관 관계의 선상의 양쪽 끝이나 한쪽 끝에 놓일 것이다. 역할의 이름과 연관관계의 이름을 둘 다 가질 필요는 없다.

래셔널 로즈에서 역할 이름 만들기

  1. 역할의 이름을 정하고 싶은 클래스 가까이 가서, 관계선 위에서 오른쪽 버튼을 클릭하고, Role Name 메뉴를 선택하라.
  2. 역할 이름을 작성하라.

##########49*
그림 43) 교수와 개설과목과의 관계에서 교수의 역할을 Teacher로 작성


그림 43에서 보여주는 관계는 두 방향에서 읽혀진다.

  • 선생의 역할을 하는 교수는 개설과목과 관련되어져 있다.
  • 개설과목은 선생의 역할을 하는 교수와 관련되어져 있다.

연관에서 관계의 이름을 사용하는 경우와, 역할 이름을 사용하는 경우에 대한 표준은 없다. 그러나, 연관의 역할을 사용하는 것이 더 구체적이고 방향성이 있기 때문에 대부분의 사람들은 오늘날 연관의 이름을 사용하는 것보다 역할의 이름을 많이 사용한다. 양방향성 관계를 사용할 때, 양방향에서 모두 옳게 연관 관계의 이름을 생각해내는 것은 대단히 어려울 때가 있다. E-R 모델을 작성해본 독자들이라면, E-R모델의 관계 이름을 정할 때의 어려움에 대해서 생각해 보면 위의 설명에 쉽게 공감할 것이다. 그림 6-7에서 연관 관계의 이름이 사용되어질 동사구는 무엇인가? 역할의 이름을 사용함에 따라서, 의미는 양방향에서 분명해 질 것이다.
연관은 관계의 이름 또는 역할의 이름이 의미를 분명히 하는데 사용되어질 경우에만 필요에 의해 사용되어 진다. 만약 회사와 사람이 관계를 가지고 있다면, 연관의 이름을 "고용한다(employs)"또는 역할의 이름을 "고용인(Employer)"과 "피고용인(Employee)"를 사용할 수 있다. 만약 클래스가 고용인(Employer)과 피고용인(Employee)이라고 이름 붙여진다면, 관계의 의미가 클래스에서 분명하기 때문에 연관관계의 이름이나 역할의 이름을 기술할 필요가 없다.

다수성 표시(Multiplicity Indicators)
비록 다수성이 클래스를 위해 기술된다고 할 지라도, 이것은 관계에 참여하는 객체들의 수를 정의한다. 다수성은 다른 객체에 링크 되어 있는 객체의 수를 나타낸다. 연관이나 어그리게이션의 다 수성은 관계를 맺고 있는 두 클래스의 각각의 끝의 관계 선 위에 표시하며, 다 수성을 표현하는 방법에는 여러 가지가 있다.

  • 1 - 정확히 한 개를 의미한다.
  • 0..* - 없을 수도 있고 여러 개 있을 수도 있다.
  • 1..* - 하나 또는 그 이상을 의미한다.
  • 0..1 - 하나도 없거나 하나가 존재함을 의미한다.
  • 5..8 - 특별한 범위를 나타낸다. (5, 6, 7, 8)
  • 4..7,9 - 조합을 나타낸다(4, 5, 6, 7이거나 또는 9)

래셔널 로즈에서 다수성 표시하기

  1. 상세 창(specification window)을 활성화시키기 위해서 관계 선을 더블 클릭 한다. 래셔널 로즈에서 시퀀스 다이어그램에서 객체와 메시지 만들기
  2. Role A Detail과 Role B Detail을 각각 선택하여 Cardinality 필드에 원하는 다 수성을 작성하라.

##########50*
그림 44) 연관의 상세 창 그림

##########51*
45) 교수와 개설과목 사이의 다 수성 표시


그림 45는 다음과 같은 방법으로 읽혀 질 것이다.

  • 하나의 개설과목 객체는 정확히 하나의 선생 역할을 하는 교수와 관련이 되어 진다. 예를 들면, Math 101, Section 1(개설과목 객체)은 스미스 교수(교수 객체)와 관련 되어져 있다.
  • 선생 역할을 하는 하나의 교수 객체는 0에서 4개까지의 개설과목과 관련이 되어있다. 예를 들면, 스미스 교수(교수 객체)는 수학 101,Section 1, 대수학 200, Section 2, 미 적분학 1, Section 3(개설과목 객체들)과 관련되어져 있다.

다수성의 범위가 0에서 4이기 때문에, 최저 0에서 최대 4까지의 객체를 가진다.

재귀 관계(Reflexive Relationships)

같은 클래스에 속한 다수의 객체들은 서로 의사소통을 할 수 있어야 한다. 이것은 클래스 다이어그램에 재귀적인 관계를 표현하는 연관이나 어그리게이션으로 표현되어 진다. 재귀 관계를 타나내는 데는 일반적으로 연관 관계 이름보다는 역할 이름이 사용된다.

래셔널 로즈에서 다수성 표시하기

  1. 도구 상자에서 연관 또는 어그리게이션 아이콘을 선택하고, 재귀 관계를 가질 클래스를 선택한다. 선택점이 재귀 관계 선의 시작점이 되는 것이다.
  2. 재귀 관계는 자신의 클래스에 대한 관계이므로, 상태 클래스가 존재하지 않기 때문에 빈 공간을 선택한다. 빈 공간은 원하는 모양을 만들기 위해서 여러 번 선택해도 된다.
  3. 다시 자신의 클래스를 선택한다.
  4. 역할의 이름을 기록하고, 각각의 재귀 연관의 끝에 다 수성을 표시하라. 다수성도 관계 선을 선택하고 오른 쪽 버튼을 누른 Multiplicity 메뉴를 선택하여서 작성할 수 있다.

##########52*
그림 46) 교수와 개설과목 사이의 다수성 표시


그림 46에서 보여지는 재귀 관계는 다음과 같은 용어를 사용함으로 읽혀질 것이다.

  • 선수과목(Prerequisite)의 역할을 하는 과목 객체는 0 또는 여러 개의 과목과 관련 되어 있다.
  • 하나의 과목 객체는 0또는 여러 개의 선수과목의 역할을 하는 과목 객체와 관련되어 있다.


관계 찾기(Finding Relationships)

시나리오들은 관계가 두 개의 클래스 사이에 존재하는지를 결정하기 위해 조사된다. 객체들 사이의 메시지는 객체가 서로 커뮤니케이션을 한다는 것을 의미한다. 연관과 어그리게이션은 커뮤니케이션을 위한 통로를 제공하며, 관계들은 또한 메시지의 흐름에서 발견되어 진다.

ESU 수강 등록 문제에서 찾아진 관계들

개설과목 추가(Add a Course Offering) 시나리오에서의 관계 유형 결정에 대한 내용은 표 -1에서 보여주고 있다.

메시지 전송 클래스 메시지 수신 클래스 관계 유형
교수과목선택 (ProfessorCourseOption) 개설과목추가 (AddACourseOffering) 어그리게이션
개설과목추가 (AddACourseOffering) 교수과목관리자 (ProfessorCourseManager) 연관
교수과목관리자 (ProfessorCourseManager) 과목 (Course) 연관
과목(Course) 개설과목(CourseOffering) 어그리게이션

표-1) Class Relationships

그림 47은 추가된 관계를 가진 클래스 다이어그램을 보여준다.

##########53*
그림 47) 개설과목 시나리오에 추가된 관계 표현


패키지 관계(Package Relationships)

패기지 관계 또한 모델에 추가되어 진다. 관계 유형은 의존 관계인데, 그림 48 처럼, 의존 패키지를 향해 점선 화살표로서 나타내어진다. 패키지 A가 패키지 B에 의존적이라는 것은 패키지 A의 하나 또는 그 이상의 클래스가 패키지 B에 있는 하나 또는 그 이상의 개방(public)클래스와 상호작용 한다는 것을 의미한다. 이 경우 패키지 A를 클라이언트 패키지, 패키지 B를 서버패키지라고 한다. 패키지 관계는 시스템의 시나리오나 클래스 관계를 살펴보면 찾아낼 수 있다. 이러한 과정은 반복적인 것으로, 관계들은 분석, 설계가 진행됨에 따라 바뀔 것이다.

##########54*
그림 48) 패키지 관계

수강 등록 문제에서의 패키지 관계들

개설과목 추가 시나리오에서 개설과목추가(AddACourseOffering) 클래스는 교수과목관리자 (ProfessorCourseManager)클래스에 메시지를 보낸다. 이것은 인터페이스(Interfaces) 패키지와 대학관련(UniverityArtifacts) 패키지가 관련이 있다는 것을 암시한다. 이 시점에서, 우리는 사람 패키지와의 관계를 발견할 수 없다.

래셔널 로즈에서 패키지 관계 만들기

  1. 도구상자에서 의존 관계 아이콘을 선택하고, 클라이언트 패키지에서 공급자 패키지까지 드래그 한다.

수강 등록 시스템의 패키지 관계는 그림 49에서 보여주고 있다.

##########55*
그림 49) 인터페이스 패키지와 대학관련 패키지 사이의 관계를 표시



요약(Summary)

  1. 관계들은 객체의 상호작용을 위한 통로를 제공한다. 분석기간동안 발견되어지는 클래스 관계의 두 가지 유형은 연관과 어그리게이션이다.
  2. 하나의 연관은 클래스들 사이의 양방향의 의미적 연결이다. 어그리게이션은 전체와 부분의 관계를 나타내는 것으로 연관의 특별한 형태이다. 연관은 일반적으로 관계의 이름을 갖는데, 이름은 능동적 동사나 동사구로서 표현되어진다. 역할들은 관계의 이름 대신에 사용되어지는 데, 역할들의 이름은 다른 것과 연관된 클래스의 목적과 자격을 의미하는 명사를 사용한다.
  3. 다수성은 관계에 참여하는 인스턴스의 수이다. 각각의 연관과 어그리게이션을 위한 다수성의 표현은 관계를 맺는 클래스의 각각의 끝에 표시되어진다. 같은 클래스에 속해 있는 다수의 객체들은 서로 커뮤니케이션 해야 하는데, 이것은 재귀적 연관, 재귀적 어그리게이션으로 표현되어 진다.
  4. 시나리오는 두 클래스 사이의 관계를 결정하기 위해 조사되어진다.
  5. 패키지의 관계는 의존 관계로 표현되어 진다.

행위와 구조 추가하기(Adding Behavior and Structure)

  • 행위와 구조 표현(Representing Behavior and Structure)
  • 오퍼레이션 생성(Creating Operation)
  • 오퍼레이션의 문서화(Documenting Operation)
  • 관계와 오퍼레이션 (Relationships and Operation)
  • 속성 생성(Creating Attributes)
  • 속성의 문서화(Documenting Attributes)
  • 속성과 오퍼레이션 보여주기(Displaying Attributes and Operation)
  • 연관 클래스(Association Classes)
  • 요약(Summary)


행위와 구조 표현(Representing Behavior and Structure)

클래스는 클래스의 객체의 행위를 정의하는 책임들(responsibilities)의 집합을 통합한다. 여기서 책임이란 해당 클래스가 해야만 하는 일을 말한다. 책임들은 클래스를 위해 정의된 오퍼레이션에 의해 수행되어진다. 여기에서 우리는 유즈케이스의 책임이 클래스로 분할되고, 클래스 책임이 오퍼레이션으로 분할된다는 것을 알 수 있다. 분할 정복의 원리를 또 한번 사용하고 있다. 하나의 오퍼레이션은 단지 하나의 일만을 해야 하며 잘 해야만 한다. 예를 들면, 하나의 개설과목 클래스는 학생을 추가하고 삭제하는 능력이 필요하다. 이러한 책임성은 두 개의 오퍼레이션(학생 추가, 학생 삭제 오퍼레이션)에 의해 표현되어 진다. 두 개의 연산에서 하나는 학생을 추가시키는 방법을 알고, 다른 하나는 학생을 삭제하는 방법을 안다. 클래스의 모든 인스턴스들은 클래스가 가지고 있는 오퍼레이션 모두를 수행하는 능력을 가지고 있을 것이다.
클래스를 위해 정의되어지는 객체의 구조는 클래스의 속성에 의해 설명되어 진다. 각각의 속성은 클래스의 객체들이 갖는 데이터정의이다. 클래스를 위해 정의되어진 객체는 클래스의 모든 속성 값을 가지고 있다. 예를 들면, 하나의 과목 클래스는 이름, 정의, 학점의 속성을 가진다. 이것은 모든 과목 객체가 각각의 속성을 위한 값을 가질 것임을 암시한다. 속성 값은 고유하지 않다. - 대학의 코스에는 많은 3학점 코스들이 있다.
좀더 읽기 쉽고 유지하기 쉬운 오퍼레이션을 정의할 때에 스타일을 사용하는 것이 도움이 될 것이다. 이러한 하나의 사례로서 속성들과 오퍼레이션들은 소문자로 시작하고, 연결되는 부분의 처음 글자는 대문자로 시작한다는 스타일을 사용할 것이다. 예를 들면, numberOfStudents()와 같이 사용하는 것이다. 이러한 스타일 규칙은 모든 속성과 오퍼레이션에 이용되어져야 하기 때문에 주의를 기울여야 한다. 이러한 스타일의 사용은 클래스 전체에 걸쳐 일관성을 제공해 주고, 모델과 코드를 더 쉽게 읽고 관리할 수 있도록 해준다.
만약 어떤 클래스 내에 속성이나 오퍼레이션을 필요치 않는 객체가 존재한다면, 클래스의 존재 또는 클래스의 범위에 대해서 고려해 보아야 한다. 이것은 이 클래스가 응집력이 없다는 의미이기 때문이다. 예를 들어 개설과목 클래스는 다음과 같은 속성을 가지고 있다. 개설과목 번호, 위치, 수업시간, 학과, 학과에서 부여한 번호와 같은 속성들을 가질 것이다. 개설과목은 학과에 대해서 주의를 기울여야 하지만, 학과에서 부여한 번호와 같은 것에는 주의하지 않아도 된다. 더 좋은 모델은 개설과목 클래스를 부서 클래스와 관계를 맺는 것이다. 이것은 클래스가 한가지의 주요 주제만을 가져야 한다는 일반적인 규칙을 지킨 것이다.


오퍼레이션 생성(Creating Operations)

인터랙션 다이어그램에서의 메시지들은 전형적으로 메시지를 받는 클래스의 오퍼레이션으로 설정되어 진다. 그러나, 메시지가 오퍼레이션이 되지 않는 특별한 경우들도 존재한다. 만약 메시지를 받는 클래스가 GUI 타입에 사용하는 바운더리 클래스이라면 이러한 메시지는 GUI에 대한 요구사항의 기술이다. 메시지의 이러한 타입들은 일반적으로 GUI 컨트롤의 몇몇 형태로 구현되어지고(예를 들면, 버튼), 이러한 행위가 GUI 컨트롤 자체에 의해 수행되어지기 때문에 오퍼레이션으로 매핑 되지 않는다. 예를 들면 교수 액터는 개설과목 추가 시나리오를 시작하기 위해 패스워드를 입력하여야 한다. 이것은 바운더리 클래스 교수과목선택 클래스에 대한 메시지로서 나타내 진다. 이것은 결코 사용자 인터페이스 클래스의 오퍼레이션이 되지 않을 것이다. 이것은 윈도우상의 텍스트 필드와 유사한 것이 될 것이다. 액터로부터 또는 액터로의 메시지는 또한 특별한 고려가 있어야 한다. 액터가 인간 액터라면 메시지는 인간 사용자가 해야 하는 일이므로, 사용자 매뉴얼에 포함되는 내용이 된다. 개설과목 추가 시나리오에서, 교수는 암호를 가지고 시스템을 활성화시킬 것이다. 이것은 사용자 매뉴얼에서 중요하게 다루는 부분이다. 사용자가 시스템을 사용할 시에 어떻게 해야 한다는 내용은 사용자 매뉴얼에 포함되어져야 하는 내용이다. 만약 메시지를 보내는 외부 액터가 시스템이라면 메시지 교환에 따른 프로토콜을 유지하기 위한 클래스가 만들어져야 한다. 이러한 경우에는 클래스 메시지는 클래스의 오퍼레이션으로 매핑 되어진다.
오퍼레이션의 이름은 기능을 수행하기를 요구하는 클래스의 관점에서가 아니라, 오퍼레이션을 수행하는 클래스의 관점에서 이름이 정해져야 한다. 예를 들면, 개설과목에 학생을 추가하는 오퍼레이션의 이름은 addStudent()라고 정하는 것이 좋다. 추가적으로, 구현은 시간에 의해 변할 것이기 때문에 오퍼레이션의 이름을 구현을 반영하여 정하는 것은 좋지 않다. 예를 들면, 각각의 개설과목 객체는 최대 10명의 학생까지 수용할 수 있다. 여러분은 개설과목 객체에게 얼마나 많은 학생이 묻는 시점에서 수강 신청을 했는지 알고자 할 때가 있을 것이다. 이것은 지금 시점에서 개설과목 객체에 연결된 학생 수를 조사하여 계산되어진 수이다.
calculateNumberOfStudents()라고 오퍼레이션의 이름을 작성했을 때, 거기에는 어떠한 계산이 있음을 암시한다. 이것이 지금 시점에서는 사실이지만, 나중(다음 해)에는 사실이 아닐지도 모른다. 우리는 다음해의 구현에서 파일에 값들을 저장하는 것으로 바꾸었다면, 이 이름은 옳지 않은 것이 될 것이다. 이 오퍼레이션에 더 좋은 이름은 getNumberOfStudent()일 것이다. 이것은 어떻게 오퍼레이션이 구현되는가를 암시하지 않기 때문에 더 좋은 이름이 된다.

래셔널 로즈에서 새로운 오퍼레이션에 메시지 매핑하기

  1. 메시지를 오퍼레이션에 매핑 하려면, 먼저 객체에 해당하는 클래스를 할당해야 한다. 만약 전에 객체에 클래스를 할당하지 않았다면 클래스를 할당하라.
  2. 메시지 화살표에서 오른쪽 버튼을 클릭하고 메뉴를 선택하라. 이것은 오퍼레이션의 상세 창을 활성화시킬 것이다.
  3. 오퍼레이션의 이름을 입력한다.


오퍼레이션을 가진 시퀀스 다이어그램은 그림 50과 같다.


##########56*
그림 50) 오퍼레이션을 가진 시퀀스 다이어그램

모든 시나리오가 다이어그램으로 나타내어지는 것은 아니기 때문에, 오퍼레이션은 또한 인터렉션 다이어그램과는 독립적으로 만들어질 수 있다. 다른 오퍼레이션을 돕기 위해 오퍼레이션을 만드는 경우도 있을 것이다. 예를 들면, 과목은 선생으로서 교수를 추가하기 전에 과목을 가르칠 수 있는 자격을 가지고 있는지에 대한 인증 절차를 거쳐야 한다. validateProfessor()라는 오퍼레이션은 이러한 행위를 수행하기 위해서 만들어져야 한다.

래셔널 로즈에서 클래스에서 직접 오퍼레이션 만들기

  1. 브라우저에서 클래스를 선택하고, 오른쪽 버튼을 클릭 하여 New:Operation 메뉴를 선택한다.
  2. 새로이 만들어진 오퍼레이션에 대해서 원하는 이름을 넣어라.

Course 클래스를 위한 오퍼레이션은 그림 51에 보여진다.

##########57*
그림 51) 개설과목 클래스에 오퍼레이션 추가


Documenting Operation

각각의 오퍼레이션들은 모델을 읽는 사람들이 오퍼레이션의 목적을 쉽게 알 수 있도록 문서화되어야 한다. 문서는 오퍼레이션에 의해 수행되어지는 기능성을 기술해야 하며, 또한 오퍼레이션에 필요한 어떠한 입력 값과 오퍼레이션에 의한 결과 값이 기술되어진다. 이러한 정보는 초기에는 알려지지 않을 것이며, 라이프 사이클동안 클래스에 대해서 더욱 많은 것을 알았을 때 추가될 것이다.

래셔널 로즈에서 오퍼레이션 문서화

  1. 브라우저에서 원하는 클래스의 오퍼레이션을 보기 위해서, +를 클릭 하여 트리를 확장한다. 오퍼레이션을 선택하고 문서 창안에다 오퍼레이션을 위한 설명을 작성한다.

setProfessor() 오퍼레이션의 설명은 그림 52에서 보여주고 있다.

##########58*
그림 52) getOfferings() 오퍼레이션의 문서화



한마디 더

클래스 상세 창에서 직접 오퍼레이션 생성하기

그림 53과 같이 브라우저에서 오퍼레이션을 추가하기를 원하는 클래스를 더블 클릭 하여 상세 창을 활성화시킨다. 오퍼레이션 탭을 선택하고 오퍼레이션의 리스트 부분을 선택하고, 오른쪽 버튼을 눌러, Insert 메뉴를 선택하고 원하는 오퍼레이션의 이름을 입력한다.

##########59*
그림 53) 클래스 상세 창

 

관계와 오퍼레이션(Relations and Operation)

오퍼레이션의 인자나 리턴 값들은 관계를 가르킬 것이다. 만약 오퍼레이션의 인자를 위한 또는 오퍼레이션으로부터 리턴을 위한 클래스가 문자열과 같은 기본 클래스들(정수, 실수, 불린, 문자 등 기본적으로 제공되는 데이터 형들)이라면, 이들과의 관계는 일반적으로 다이어그램에 표시되지 않는다. 다른 클래스(기본 클래스가 아닌 것들)에 대해서 위와 같은 경우에는 이들과의 관계가 전형적으로 하나 또는 그 이상의 클래스 다이어그램에서 보여진다. 예를 들면, 과목 클래스의 setProfessor() 오퍼레이션은 두 가지 입력으로 교수(교수 클래스)와 개설과목(개설과목 클래스)을 가진다. 이것은 과목과 교수, 과목과 개설과목 사이에 관계가 존재한다는 것을 보여준다. 초기에 오퍼레이션의 기반 하여 관계들은 시스템이 성숙되어감에 따라 의존 관계로 구체화되어진다.
패키지 관계들은 또한 오퍼레이션의 인자나 리턴 값에 기반 한 관계가 모델에 추가되어야 하는지 검토되어져야한다. 예를 들면, 우리는 과목과 교수 클래스 사이의 관계를 추가하였다. 이것은 대학관련 패키지와 사람 패키지 사이에 의존 관계가 있다는 것을 암시한다.


속성 만들기(Creating Attributes)

클래스의 많은 속성들은 문제 기술서에서, 시스템 요구사항의 집합에서, 이벤트 플로어 문서에서 발견되어 진다. 클래스에 대한 정의를 할 때, 속성들은 또한 발견되어진다. 마지막으로 업무 전문가는 클래스의 속성을 찾아내기 위한 좋은 대상이 된다. 예를 들어 요구사항에서 찾아 낼 수 있었던, 과목 이름, 설명, 학점은 학기의 과목 카탈로그 안에서 이용될 것이다. 이것은 이름, 설명, 학점이 과목 클래스의 속성이라는 것을 암시하는 것이다.

래셔널 로즈에서 속성 만들기

  1. 브라우저에서 원하는 클래스를 선택하고, 오른쪽 버튼을 눌러 New:Attribute 메뉴를 선택한다.
  2. 브라우저에 Name 이라는 속성이 만들어진다.
  3. 새로이 만들어진 속성을 선택하고, 원하는 이름을 입력한다.

과목에 대한 속성들은 그림 54에서 보여주고 있다.

##########60*
그림 54) 과목의 속성 추가

♠ 클래스의 상세 창을 이용하여, 직접 작성하는 방법은 오퍼레이션 부분을 참조하기 바란다.

 

속성의 문서화(Documenting Attributes)

속성들 또한 분명하고 간결한 정의를 가지고 문서화되어야 한다. 정의는 속성의 구조가 아니라 목적을 기술해야 한다. 예를 들면 과목 클래스의 과목 이름에 대한 속성에 대한 나쁜 정의는 "길이 15의 문자열"과 같이 정의하는 것이다. 더 좋은 정의는 "모든 대학에서 사용되는 과목의 이름"과 같이 정의하는 것이다. ♠ 속성의 문서화 부분의 로즈 사용법은 오퍼레이션 부분과 같다.


속성과 오퍼레이션 보여주기(Displaying Attributes and Operations)

속성들과 연산들은 클래스 다이어그램에 표시되어질 것이다. 종종 하나의 클래스 다이어그램은 패키지 안의 클래스들의 구조와 행위를 보여주기 위한 목적을 위하여 특별하게 만들어진다. 전형적으로 이러한 다이어그램에서는 관계는 보여지지 않는다.

래셔널 로즈에서 속성과 오퍼레이션 보여주기

* 패키지의 오퍼레이션과 속성을 보여주기 위한 클래스 다이어그램 만들기

  1. 브라우저에서 패키지를 선택하고 오른쪽 버튼을 클릭하고, New:Class Diagram 메뉴를 선택한다. 브라우저에 NewDiagram이라는 이름을 가진 클래스 다이어그램이 추가되어진다. 새로운 다이어그램을 선택하고, 이름을 입력한다.

* 쿼리 메뉴를 이용하여 다이어그램에 클래스 추가하기
이미 앞부분에서 설명한 부분이다.

  1. 브라우저에서 다이어그램을 열기 위해 다이어그램을 더블 클릭 한다.
  2. Query:Add Classes 메뉴를 선택하고, 원하는 패키지를 선택한다.
  3. 원하는 클래스들을 선택하고 >>>> 버튼을 클릭 하여 추가하거나, All >> 버튼을 클릭 하여 다이어그램에 모든 클래스를 추가한다.

* 필터링(Filtering) 관계

  1. 다이어그램을 열기 위해 브라우저에서 다이어그램을 더블 클릭 한다.
  2. Query:Filter Relationships 메뉴를 선택한다.
  3. 열려진 다이어그램에 모든 관계를 숨기기 위해서 Type 필드에서 None을 선택한다.

* 스테레오 타입 보여주기 설정하기

  1. 다이어그램에서 해당 클래스를 선택하고, 오른쪽 버튼을 눌러 Option:Stereotype Display 메뉴를 선택한다. 세부 선택 사항으로 None, Label, Icon이 있을 것이다. 원하는 것을 선택하면 된다. None은 스테레오 타입을 보여주지 않고, Label은 <<스테레오 타입명>>와 같이 보여지고, Icon은 아이콘을 지원하는 스테레오 타입일 경우 아이콘으로 표시된다.

몇 개의 속성, 오퍼레이션만 보이게 하기

  1. 다이어그램 위에 존재하는 클래스를 선택하고, 오른쪽 버튼을 클릭 한다.
  2. Options:Select Compartment Item을 선택한다.
  3. 보여주고자 하는 속성과 오퍼레이션을 >>>> 버튼을 이용하여 추가한다. 이때 주의해야 할 것은, 선택한 오퍼레이션과 속성만을 보여주기 위해서는 당연히 그림 55처럼 모든 속성 보기와 모든 오퍼레이션 보기의 선택을 해제해야 할 것이다.

##########61*
그림 55) 선택 사항 메뉴



연관 클래스(Association Classes)

객체들 간의 관계는 또한 구조와 행위를 가져야 하는 경우가 있다. 어떠한 정보가 하나의 객체에 대한 내용이 아니라 링크 된 두 개의 객체에서 다루어져야 할 필요가 있을 때, 관계에 그러한 정보를 표현해야 한다.
다음과 같은 예를 생각해 보자. 한 명의 학생이 4개의 개설과목을 선택하고, 하나의 개설과목은 3명에서 10명의 학생을 가진다면, 각각의 학생은 개설과목에 대한 학점(grade)을 받아야 한다. 어디에 성적을 연결할 것인가? 하나의 학생은 아마도 다른 과목에 다른 성적을 가지고 있을 것이기 때문에, 이것은 학생에 넣을 수 없고, 또한 학생에 따라 성적이 다르므로, 개설과목에도 넣을 수 없다. 이러한 정보는 학생과 개설과목 사이의 연결에 속해 지며, 하나의 연관 클래스로서 모델 되어진다. 연관 클래스는 다른 클래스처럼 행동할 수 있기 때문에, 관계를 가질 수 있다. 우리의 예를 본다면, 학생은 각 학기마다 성적표를 받는다. 이 성적표는 학생들을 위한 모든 성적 객체와 연결되어 있다.

래셔널 로즈에서 연관 클래스 만들기

몇 개의 속성, 오퍼레이션만 보이게 하기

  1. 도구 상자에서 클래스 아이콘을 선택하고, 클래스를 다이어그램에 위치시킨다.
  2. 클래스가 선택되어진 상태로 이름을 입력하고, 속성과 오퍼레이션을 추가한다.
  3. 도구 상자에서 연관 클래스 아이콘을 선택하고, 연관 클래스를 연결시켜줄 연관 관계를 맺고 있는 다른 두 개의 클래스의 연관 선에서부터 연관 클래스로 연관 클래스 선을 드래그 한다.

##########62*
그림 56) 연관 클래스 관계에 해당하는 도구 상자의 관계 표시와
연관 클래스 학점을 표시



한마디 더

속성이나 오퍼레이션의 아이콘 바꾸기
클래스를 표시할 때, 속성은 ##########63*, 오퍼레이션은 ##########64*로 표시된다. 또한, 접근 자에 따라 기호가 붙여진다. Private ##########65*일 경우 , Protected일 경우 ##########66*, Public일 경우는 없다. 이러한 표시는 보기는 좋지만, 출력해서 모델링 자료로 보여줄 때는 별로 좋지 않다. 그 보다는 단지 Public 일 경우에는 +, Private일 경우는 -, Protected일 경우는 #으로 표시하는 것이 보기 좋다. 메뉴 Tools:Options를 선택해서 Options 대화상자를 활성화시키고, Notation 탭을 선택한다. 그림 57에서와 같이 Visibility as Icons의 체크를 없애라. 이미 다이어그램에 작성된 클래스들은 다이어그램에서 없애고, 다시 작성할 때 적용된다. 적용되었을 때의 모습은 그림 58에서 보여주고 있다.

##########67*
그림 57) 클래스 상세 창

##########68*
그림 58) 개설과목 클래스의 속성과 오퍼레이션의 아이콘을 제거한 그림

 

요약(Summary)

  1. 클래스는 클래스의 객체의 행위를 정의해야 하는 책임들을 가지고 있다. 책임성은 클래스에 정의되어진 오퍼레이션에 의해 수행되어진다. 객체의 구조는 클래스의 속성에 의해 설명되어 진다. 클래스를 위해 정의되어진 객체들은 클래스의 모든 속성 값을 가진다. 클래스를 위해 정의되어지는 속성과 연산은 개발되어지는 어플리케이션 안에서 의미를 가지는 것들이다.
  2. 상호작용 다이어그램에서의 메시지들은 메시지를 받는 클래스의 오퍼레이션에 매핑 되어져야 한다
  3. 클래스의 많은 속성들은 문제 기술서, 요구사항 집합, 이벤트 플로어 문서에서 발견되어진다. 그들은 또한 클래스의 정의를 통해서 지원되어지고, 마지막으로 도메인 전문가는 또한 클래스의 속성에 대한 정보를 제공해 주는 주요 자원이 될 것이다.
  4. 두 개의 클래스 사이에 정보를 저장해야 할 경우가 발생될 경우 연관 클래스를 사용한다. 연관 클래스와 연관 관계를 맺고 있는 두 개의 클래스의 관계는 두 개의 클래스의 연관 선에서 연관 클래스로 연결하여 만들어진다.

 

비즈니스 모델링


지난 호의 특집이었던 「비즈니스 모델링을 이용한 정보시스템 구축」을 읽은 독자들은 비즈니스 모델의 필요성에 대해서 생각할 수 있었던 시간 이였을 것이다. 이번 호 에서는 실제 비즈니스 모델링을 수행하는 과정에 대해서 설명하려고 한다. 비즈니스 모델링 부분에서 얻게 되는 지식들은 후에 시스템 개발과정에서 다시 사용되게 되므로, 잘 익혀 두기 바란다. 이번 호에서는 비즈니스 모델링의 첫 번째 과정으로서 비즈니스 모델링에 대한 소개와 비즈니스 모델링의 업무활동들에 대한 전체적인 흐름을 소개한다. 또한 앞으로의 연재에 필요한 용어를 익히는 과정으로 비즈니스 모델링의 상세 내용에 들어가기 위한 준비 단계로 삼겠다.

비즈니스 모델링(Business Modeling)에 대한 소개

1. 전체 살펴보기(Overview)

##########69*
그림 1) 비즈니스 모델링 전체 플로어 살펴보기
[출처 : Rational Unified Process 5.5]

비즈니스 모델링의 전체 플로어를 살펴보면 그림 1과 같이, 시스템의 개발 성격에 따라 완벽한 비즈니스 모델링을 할 것인가? 도메인 모델만을 할 것인가를 정하는 것이 처음 출발점이 된다.
완벽한 비즈니스 모델링을 하기로 결정했다면, 비즈니스 모델링을 하기 위해 비즈니스 프로세스를 발견하고, 발견된 업무 프로세스를 정제하는 과정을 통해서 비즈니스 유즈케이스 모델을 만든다. 비즈니스 유즈케이스 모델에 변화가 발생하면, 다시 변경된 비즈니스 프로세스를 발견한다. 비즈니스 유즈케이스 모델을 만든 뒤에 비즈니스 객체 모델을 만들기 위해서 역할과 책임을 찾아내고, 역할과 책임을 정제한다. 비즈니스 객체모델이 변화하면, 다시 역할과 책임을 찾는 작업을 수행한다. 또한 이 시점에서 비즈니스 유즈케이스 모델이 변경되었다면, 다시 비즈니스 프로세스를 찾아낸다.
독자들은 그럼 언제 비즈니스 모델링을 하고, 언제 도메인 모델링만을 수행해야 하는지 궁금해 질 것이다. 필자는 여기서 그러한 사항에 대해서는 일체 언급하지를 않을 것이다. 물론 상황에 맞는 작업을 수행하는 것은 개발 시 필요한 부분이지만, 필자는 반드시 비즈니스 모델링을 수행하라고 권하고 싶다. 비즈니스 모델링에 투여되는 시간은 비즈니스 모델링의 이면의 장점을 생각하면 결코 아까운 시간이 아니기 때문이다.

2. 비즈니스 모델링의 목적

비즈니스 모델링의 목적은 우리가 개발하고자 하는 시스템에 대한 조직의 구조와 행위를 이해하고, 고객, 최종사용자, 개발자가 조직에 대한 공통적인 이해를 가질 수 있도록 하기 위해서 수행한다.
또한 조직을 지원하기 위한 시스템이 가져야할 요구사항을 파생시키기 위해서 수행한다. 이러한 목적을 달성하기 위해서, 비즈니스 유즈케이스 모델과 비즈니스 객체모델은 개발되어진다. 이러한 모델들에 대한 보안 적인 것으로서 비즈니스 기술서, 용어정리가 있다.
여기서 우리가 명심해야 할 것은 비즈니스 모델링 작업의 수행은 올바른 시스템(업무를 제대로 반영하는 시스템)을 만드는 초석이 된다는 것이다. 또한 개발 후 업무의 변경이나, 시스템 자체의 변경, 기술의 변경 등에 대해서 업무, 시스템과 기술 사이에 서로를 정확히 반영할 수 있도록 돕는다. 이것은 어느 한 부분이 변경되었을 때, 다른 부분에서도 변경 부분에 해당하는 부분을 변경시킬 수 있음을 말하고 있다. 하나의 예를 들자면, 기존 업무에서는 중앙 집권적인 조직으로 업무를 수행하던 조직이, 통신 기술의 발달로 분산적인 조직을 가지고 업무를 수행할 수 있게 되기 위해서는 업무가 변경이 되어야 한다. 또한 업무의 변경이 시스템에도 변경되어야 한다. 이러한 변경이 제대로 반영되기 위해서는 비즈니스 모델은 필수적인 것이 된다.

 

비즈니스 모델링 단계

비즈니스 모델링은 다음과 같이 총 4개의 업무활동으로 나누어진다.

  1. 비즈니스 프로세스를 찾기
  2. 비즈니스 프로세스를 정제
  3. 역할과 책임을 찾기
  4. 역할과 책임을 정제

비즈니스 시스템을 보면, 이전의 연재에서 정보 시스템에 대해서 생각할 때와 같이, 시스템 외부적 관점과 외부적 관점이 존재한다.
시스템 외부적 관점은 시스템 외부에 존재하는 어떤 목적을 가진 행위자(비즈니스 액터)가 목적을 달성하기 위해서 시스템과 상호작용을 하는 것으로, 비즈니스 액터의 관점에서 시스템을 바라보는 것이다.
시스템 내부적 관점은 이러한 비즈니스 액터가 원하는 목적을 달성하도록 돕기 위한 시스템 내부의 작업 중심으로 바라보는 것이다. 그러므로, 비즈니스 모델링을 하기 위해서는 시스템 외부적 관점에 대한 모델인 비즈니스 유즈케이스 모델과 시스템 내부적 관점에 대한 모델인 비즈니스 객체모델에 대해서 모델을 만들어야 한다는 것을 알 수 있다. 비즈니스 모델링 단계 1과 2가 비즈니스 유즈케이스 모델을 만드는 작업에 해당하고, 단계 3과 4가 비즈니스 객체 모델을 만드는 작업에 해당한다.
다음은 비즈니스 모델링의 네 개의 업무활동에 대한 개략적인 설명과 각각의 업무활동에 대한 그림을 보여주고 있다.

작업1 비즈니스 프로세스를 찾기는 결국 비즈니스 액터와 비즈니스 유즈케이스를 찾고 비즈니스 유즈케이스 모델과 부수적인 비즈니스 기술서를 만드는 작업을 말한다. 부수적인 기술서에 대해서 궁금한 독자들이 있을 것이다. 자주 이야기하는 말이지만, 지금은 전체적인 프로세스를 바라보는 관점을 가져야 한다. 세부적인 것은 그 다음으로...

##########70*
그림 2) 비즈니스 프로세스 찾기에 대한 업무 활동
[출처 : Rational Unified Process 5.5]

작업2 비즈니스 프로세스를 정제는 작업 1의 결과물인 비즈니스 유즈케이스 모델을 구조화하고, 비즈니스 유즈케이스를 좀더 상세하기 작성하고, 마지막으로 비즈니스 유즈케이스 모델을 검토하는 과정이다.

##########71*
그림 3) 비즈니스 프로세스 정제 업무 활동
[출처 : Rational Unified Process 5.5]

작업3 역할과 책임을 찾기는 시스템의 내부적 관점에서의 비즈니스 객체모델을 만드는 과정이라는 것은 이미 앞에서 이야기했다. 비즈니스 액터의 목적을 달성하기 위해서 비즈니스 시스템 내부에서는 작업자가 이용할 수 있는 비즈니스 엔티티를 가지고 업무를 수행한다. 이때 작업자들은 서로 상호작용을 하기도 한다. 역할과 책임 찾기는 좀더 풀어서 이야기하면, 비즈니스 액터의 목적을 달성하도록 돕기 위해서, 비즈니스 시스템 내부에서 누가(어떤 작업자) 어떠한 엔티티(정보나 이용할 수 있는 자원)를 가지고 해당 역할과 그 역할에 대한 책임을 갖는가를 찾는 것이다. 결국 비즈니스 작업자와 비즈니스 엔티티를 찾는 것이다.

##########72*
그림 4) 역할과 책임 찾기 업무 활동
[출처 : Rational Unified Process 5.5]

작업4 역할과 책임 정제는 찾아진 비즈니스 작업자와 엔티티를 좀더 세부적으로 기술하고, 이것들을 검토하는 작업을 말한다.

##########73*
그림 5) 역할과 책임 정제 업무 활동
[출처 : Rational Unified Process 5.5]

 

비즈니스 모델링 관련 용어 익히기

비전(Vision)

  • 비전은 프로젝트 승인 프로세스에 입력으로 제공되어 진다. 비전은 프로젝트를 수행함으로서 얻을 수 있는 기회(기술적, 경제적)와 위험요소가 무엇인지를 기술함으로서, 프로젝트 수행여부를 결정하는 중요한 문서로서 작용한다. 또한 비전에는 프로젝트에 참여하는 이해관계자들의 요구사항을 기술하는데, 이것은 더욱 세부적인 기술적 요구사항에 대한 계약의 근거가 된다.
    비전의 작성자는 시스템 분석가이고, 유즈케이스 모델링을 하는 매니저, 재정 담당자, 작업자와 일반적으로 개발자에 의해 읽혀 질 것이다.
  • 프로젝트 도입단계 초기에 만들어지고, 비즈니스 케이스(Business Case)와 위험 리스트(Risk List)의 초기버전에 사용된다. 또한 유즈케이스 모델의 입력으로 사용되고, 프로젝트 전반에 걸쳐 분리된 작업 물로서 갱신되고, 관리되어진다.
  • 비전은 유즈케이스에 의해 실현되어진다.

용어정리(Glossary)

시스템을 위한 용어 정리는 많은 개발자들에게 중요한데, 특히 그들이 특별한 프로젝트의 용어의 사용에 있어, 용어의 이해는 매우 중요하다.
용어 정리는 프로젝트 초기에 공통적인 용어에 대한 동의를 얻어야 하기 때문에, 도입단계와 전개단계에 중요하게 개발되어진다. 초기의 용어의 정의는 비즈니스 관점에서 기술하는 것으로, 후에 발생하게 될 용어를 정의하는 어려움을 제거할 수 있는 잇점을 제공한다.
시스템 분석가는 용어를 통합할 책임을 가지며, 시기 적절하게 일관성 있도록 용어를 작성하고 유지해야 할 책임이 있다.

이것으로 우리는 전체적인 비즈니스 모델링에 대한 업무활동들에 대하여 개괄적인 이해를 하였다. 필자는 독자들을 위하여 래셔널 유니파이드 프로세스에 대한 상세 연재 계획을 아래와 같이 정하였다.

  1. 비즈니스 모델링 개괄(7월)
  2. 래셔널 유니파이드 프로세스의 기본 개념, 비즈니스 모델링 업무활동 상세 설명(8월)
  3. 수강신청에 대한 비즈니스 모델링, 요구사항 분석 개괄(9월)
  4. 요구사항 분석 업무활동 상세 설명, 수강신청에 적용(10월)
  5. 분석 설계 (11월)
  6. 구현, 테스트(12월)

♠ 일정에 대한 의문사항은 kimhn@dreamwiz.com으로 보내주십시요.

 oonewsletter - 2000/7/29


 

'UML' 카테고리의 다른 글

[펌] RUP (Rational Unified Process)  (0) 2010.07.12
[펌] Relationships  (0) 2010.07.12
[펌] Class Diagram  (0) 2010.07.12
[펌] CBD 개론.  (0) 2010.07.12
[펌] [안영회의 UML 강좌21] - Summary  (0) 2010.07.12

관련글

티스토리툴바