SmalltalkObjectsandDesign:Chapter 10

제 10 장 Use cases 와 동적 관계

Use cases 와 동적 관계

여태까지는 객체 지향 애플리케이션에서 정적 관계-집합, 상속, 객체의 메서드와 인스턴스 변수와 같은-에 중점을 두어왔다. 동적 관계-메서드가 실행되는 순서, 객체의 탄생과 소멸, 객체의 생(life) 중에서의 상호작용-는 디자인을 이해하는 데에 정적 관계만큼이나 중요하다. 동적 관계는 객체가 함께 무언가 실제로 행동하도록 엮이는 관계다. 동적 관계가 없다면 객체 모델은 (또는 객체 분석이나 객체 디자인) 유령의 도시처럼 빌 것이다.

객체가 생기기 오래 전부터 소프트웨어 기술자들은 동적 관계가 중요하다는 사실을 인지하고 있었다. 그들은 "순서도(flowchart)" 라는 도표를 이용해 그들의 생각을 표현하고자 했다. 객체 지향 프로그래밍이 생긴 지 20년이 되어서야 누군가 이와 동일한 생각을 객체 지향 디자인 방식으로 소개했다. (역사적 논평은 114 페이지를 참고.) 그리고 최근에서야 마침내 동적 관계가 모든 주요 객체 지향 디자인 방식의 표준 기능이 되었다.

상호 작용 다이어그램

Ivar Jacobson 에 의해 명명된 use case 는 사용자와 애플리케이션을 수반하는 시나리오다. 그의 말을 빌리자면, use case 는 "시스템과의 대화에서 행위적으로 관련된 트랜잭션(transaction)의 시퀀스이다" [Jacobson et al. 1992]. 이제 이러한 정의는 컴퓨터 과학자에겐 의미가 상통할지 모르지만 비기술적 사람들 중에선 소수만 이해할 수 있다. 그리고 비기술적 최종 사용자들은 주로 자신의 use cases 를 설명함으로써 새 문제를 이해하도록 우리를 도와야 하는 사람이다. 따라서 필자는 좀 더 접근하기 쉬운 정의, 즉 "컴퓨터가 사용자의 실행을 도울 수 있는 작업이나 활동"과 같은 정의를 선호한다. 이러한 용어는 컴퓨터 전문가와 컴퓨터 사용자 간 의미 있는 담론에 방해되지 않을 정도로 단순하다.

Use case 의 예로, "현금 자동 입출금기에 계좌의 잔고를 요청하라." 를 들 수 있겠다. 이러한 use case 의 상세한 표시는 "고객이 카드를 넣고, 기계가 PIN 을 요청한다..." 가 되겠다. 이와 같은 텍스트 설명은 번거롭거나 모호할 수 있으므로 디자이너는 아래와 같은 상호 작용 다이어그램을 그려볼 수 있다:

각 수직선은 객체를 나타낸다 (선의 제일 위쪽에 이름을 표기). 수평의 굵은 화살표는 메시지를, 점선 화살표는 메서드가 리턴하는 객체를 나타낸다. 수직 상자는 각 메서드의 실행시간(duration)을 의미한다. 시간 범위를 주목하라. 이것이 바로 이러한 상호 작용 다이어그램을 클래스 계층구조나 집합 관계의 그림으로부터 구별하는 것이다.

상호 작용 다이어그램은 앞서 pre-object-oriented (전 객체 지향) 방법론에 이용된 데이터 흐름도 또는 순서도를 포함해 어느 정적 그림보다도 동적 행위를 잘 표현한다. 디자인이 마음속에서 흐릿하게 보일 때마다 잠시 멈추고 (코드를 작성하지는 말라) use case 와 상호 작용 다이어그램을 이용해 동적 구조를 살펴보라.

동시성 경고: 이러한 상호 작용 다이어그램에 대해서는 어떤 것도 동시에 발생하지 않고, 객체 지향 또한 내재적으로 동시에 발생하지 않는다. 특히, 스몰토크와 C++ 언어에서는 어떤 것도 동시성과는 상관이 없다. 이러한 소식은 객체의 용어는 메시지, 즉 동시에 통신하는 수많은 송신자와 수신자를 상기시키는 단어를 강조하기 때문에 많은 초보자들에겐 충격적으로 들릴 수도 있겠다. 동시성은 스몰토크와 C++를 비롯해 다른 대부분의 언어에서 가능하지만, 언어가 직접 그것을 지원하는 것은 아니다. 대신 운영체제 서비스를 호출함으로써 언어 밖에서 실행해야 한다. 예를 들어, UNIX forks 와 semaphores(세마포르)를 이용하거나, C++ 또는 스몰토크로부터 OS/2 쓰레드(threads)를 생성할 수 있다.

위와 같은 상호 작용 다이어그램에서 동시에 실행되는 것처럼 보이는 쓰레드나 프로세스는 (query balance와 get balance에 해당하는 수직막대) 일반 호출-리턴 구문을 나타낼 뿐이다. 전송하는 연산(query balance)은 그것이 전송하는 메시지(get balance)가 리턴할 때까지 블록하는데 (진행하지 않는다), 이는 전형적인 프로그래밍 언어에서 호출되는 서브프로시저가 리턴될 때까지 호출 프로시저가 블록하는 것과 마찬가지다.

때로는 연구 중인 시스템의 활동이 낮은 수준에서 이루어지고 사용자로부터 너무 멀어서 활동을 use case로 설명하는 데에 애를 먹기도 한다. 하지만 이런 경우에도 상호 작용 다이어그램은 이해에 도움이 된다. 다음 예제는 저수준 스몰토크 메시지 흐름을 강조한다; 사용자의 역할은 마우스를 클릭하기만 하면 된다. 도표는 스몰토크가 이벤트를 검색하기 시작하는 시간부터 발생하는 일을 추적하는데, 이는 오리지널 운영체제 정보를 실제 스몰토크 메시지로 변환한 후 마지막으로 이 메시지를 CurrentEvents 컨테이너에 위치시켜 이 메시지를 잇따른 실행에 스케줄링함으로써 진행된다.

self로 전송되는 메시지는 진한 화살표로 표기되어 그들이 출발한 객체로 구부러져 돌아간다(hook back). 점선으로 된 구부러진 화살표는 그러한 메서드로부터 리턴된 객체를 표시한다. 연속 리턴 값이 동일한 경우, 리턴된 객체는 매번 반복되지 않는다: 예를 들어, 두 개의 구부러진 화살표에는 이름이 없지만 마지막 4개의 리턴 값은 모두 nil 객체다. 때때로 리턴 값은-종종 self의 기본 리턴 값-사용되지 않고 흥미롭지 못하다; 그러면 점선 화살표가 완전히 생략되는데, 이는 스몰토크 메시지 w b1Up: aPt 를 최종적으로 스케줄링하는 add: 메서드에서 볼 수 있다. 이러한 도표에는 표준 표기법이 존재하지 않는다; 필자는 위의 규칙을 종종 사용하지만 각자 본인에게 맞는 방식으로 사용하면 된다.

이 시나리오는 특정 스몰토크(Smalltalk/V), 특정 운영체제(OS/2), 윈도우 매니저(Presentation Manager, 또는 PM)에 적용된다. 그러한 환경에서 이벤트 처리를 염려하는 우리 중 몇몇은 이 도표를 수년간 참조용으로 사용하기도, 사용을 중지하기도 했다. 도표가 자신의 문제에 연관된 경우는 거의 없으므로 그 세부내용은 연구하지 말아야 한다. 하지만 자신만의 문제로 제한된 복잡한 시나리오에서 그 외 다른 use cases나 상호 작용 다이어그램은 자신의 개발 팀에 귀중한 자료가 될 것이다. 손으로 대충 그린 그림이라 하더라도 그릴 만한 가치가 있다. (110 페이지부터 시작되는 분석 및 디자인 논의의 예를 살펴보라.) 얼마나 기본적인지와 상관없이 자신만의 스케치를 유지하라. 다른 개발자들이 고마워할 뿐만 아니라 검사자들은 상속이나 집합 도표보다 use cases와 상호 작용 다이어그램을 더 유용하게 사용함을 발견할 것이다. 검사자들은 클래스와 객체 간 정적 관계가 아니라 소프트웨어가 하는 일을 검사한다.

연습

제 7장과 8장에서 당신은 거래(transaction)를 로그로 (SortedCollection 클래스의 인스턴스) 추가했고, Transaction 클래스에 대한 <= 메서드만 지원되었으며, 로그는 시간순으로 거래 내역을 정렬했다. 많은 학생들에게 이것은 이해하기 힘든 사건이다.

❏ 객체 상호작용에 익숙해질 때까지는 단순한 시나리오를 작업하라. 각 시나리오에 상호 작용 다이어그램을 그려볼 수 있지만 객체들의 의인화도-객체들을 사람, 연필 또는 동전으로 표현하는 것이-똑같이 효과적일 수 있음을 발견할 것이다. 상호 작용 다이어그램을 그린다면 예쁜 그림을 그리는 것보다는 이것저것 생각해보는 데에 가치가 있음을 명심한다.

해결책과 논의

아래의 상호 작용 다이어그램을 살펴보기 전에 우선 객체와 그들의 정적 관계에 대해 타당한 직관을 발전시키는 것이 중요하다. 슬프게도 상호 작용 다이어그램에는 정적 정보를 재구성하도록 도와줄 만한 것이 없기 때문이다. 이 정적 정보를 살펴보자. 해당 내용의 검토는 85, 86 페이지의 그림을 참조하라.

SortedCollection 의 인스턴스에 해당하는 로그(log)는 기본적으로 비교 메서드 <=를 이용해 정렬한다. 그것으로 새 transaction 을 추가하면 이는 새 transaction 을 삽입할 올바른 위치를 찾을 때까지 transaction 에게 자신을 (<=를 이용해) 이미 존재하는 transactions 에 한 번에 하나씩 비교하도록 요청한다. 이러한 새 transaction 은 자신을 다른 transactions 와 비교하기 위해 무엇을 사용할까? 고유의 일자를 이용하여 그것을 다른 transaction 의 일자와 비교한다. 일자가 transactions 내부에 캡슐화된다는 점은 정적 정보의 핵심이다. 로그는 transactions 를 포함하고, 각 transaction 는 자신의 일자를 캡슐화하며, transactions 는 캡슐화된 일자로 접근하기 위해 getDate getter 를 (종종 date 라고 불림) 갖는다는 사실을 유념하라. 이 모든 정보는 정적이다. 이러한 정보를 모두 엮은 상호 작용 다이어그램은 다음과 같다:

Transaction 의 두 인스턴스가 도표에 표시되어 있음을 주목하라. 비교를 설명하려면 최소 두 개는 필요할 것이다. 또 trans2 의 일자인 date2 가 이 상호작용에 중요하게 참여하지만 이러한 세부 수준에서는 메시지를 수신하거나 초기화하는 것을 볼 수 없다.

분석에서 use cases와 상호 작용 다이어그램

Use cases 는 새로운 문제를 분석하는 초기 단계에서 매우 귀중하다. 여기 두 가지 예를 들어보겠다.

1. 새로운 약국 애플리케이션에 대해 서브시스템을 빌드하기 위해 우리는 기존 애플리케이션의 사용자들에게 컴퓨터가 도와주었으면 하는 작업을 생각해보도록 요청했다. 먼저 그들은 네 가지 작업, "약물 주문 입력하기"와 "약물 조제하기"와 같은 작업을 네 가지 열거했다. 이 둘 다 use cases에 해당한다. 수많은 객체를 확인하는 데에 이미 CRC 카드를 사용했으므로 상호 작용 다이어그램을 작업하기 시작했다. 예상을 못한 것은 아니지만, 그들은 초기 use cases에 중요한 몇 가지 변형(variations)이 있음을 발견했다. 우리는 그들이 추가 uses cases임을 확인했다. 예비 조사를 완료하자 그들은 문제가 되는 서브시스템에 8개 정도의 use cases를 발견했고, 우리 모두는 주요 객체와 그들의 상호작용에 대해 괜찮은 의견을 가질 수 있었다. CRC 카드를 이용해 서브시스템의 대략적 모형(mockup)을 개발하는 데에 필요한 정보를 수집하였다.

1. 은행 업무 애플리케이션을 위한 요구조건 분석에서, 중요한 CRC 카드와 uses cases를 반복하여 발전시키긴 했으나 소프트웨어 개발자들과 은행가들은 use case에 대한 상호작용 다이어그램을 작업한 후에야 실질적으로 합의를 볼 수 있었다. 은행가들은 그들이 개념화한 객체들이 어떻게 서로에게 메시지를 전송함으로써 작업하는지를 처음으로 인지했고, 개발자들은 은행가들이 실제로 생각하는 것과 우리가 그 문제를 해결하기 위해 어떻게 소프트웨어를 디자인해야 했는지를 볼 수 있었다. 양쪽 당사자들에게 이는 카타르시스적인 순간이었다.

이러한 경험은 하나의 객체 지향 분석 기법을 보여준다. 첫 두 단계는 (순서는 중요하지 않다) CRC 카드를 도출하고 사용자로부터 use cases를 사용하는 것이다. 그리고, 개발자와 사용자는 함께 메시지 흐름을 작업함으로써 CRC 카드와 uses cases를 모두 개선하여 객체 지향 요구조건의 초기 단계를 생성할 수 있다. 전반적인 논의는 기술적 복잡화 없이도 발생할 수 있다-누구도 클래스, 상속 또는 다형성과 같은 단어를 사용해선 안 된다. 모두들 카드(객체), 활동(use cases), 전보 또는 메시지(상호 작용 다이어그램)를 이용해 통신할 수 있다.

분석에 관한 일반적인 면: 훌륭한 분석가는 유연하고 즉흥적인 사람들이다. 그들은 사용자들이 당혹스러워함을 감지할 때 장치를 전환할 수 있어야 한다. 사용자 그룹이 클수록 문제는 악화된다. 각기 다른 사람들은 서로 다른 방식으로 사고하고, 다른 이유로 당혹스러워한다. 인간의 인지에 대한 가변성에 적응하는 것이 바로 성공적인 분석에 있어 핵심이 된다. 한 사람에게 영감을 주는 기법은 다른 기법을 억누른다. 그리고 문제에서 한 가지 측면만 작업하는 기법은 다른 측면을 해결하지 못한다. 위의 은행 업무 애플리케이션에서 객체와 시나리오를 이용한 여러 회의 성공적인 수업을 받은 후에 하나의 모호한 영역이 남았다. 은행가는 우리 개발자들만큼이나 자신도 당혹스러웠음을 우리에게 이해시켜야 했다. 따라서 우리는 객체에 관한 이야기를 전적으로 멈추고 창 레이아웃을 그려 어떻게 서로 상관되는지 알아보고자 했다. 이러한 사고의 전환은 "아니, 그쪽이 아니지....맞아, 맞아, 좋아!"라는 식의 전환적인 반응을 이끌어냈다. 물론, 개발자들은 창 아래(under window)의 객체를 상상하였고 그에 따라 우리는 무의식적으로 객체 지향 요구조건을 수집하고 있었지만 대화의 범위가 객체에서 벗어나면서 모두에게 이익이 된 것은 분명했다.

창을 그리는 것이 분석의 교착 상태에서 보편적인 해결책이 된다는 주장을 하려는 것은 아니다. 단지 그 문제의 그 측면에 작업하는 사람들에게 효과가 있었을 뿐이다. 그것이 바로 중요한 점이다. 각 사람마다, 문제마다 다른 접근법이 효과가 있을 것이다. 성공적인 분석가에겐 하나의 접근법이 가까운 상황에 효과가 있을 때까지 여러 접근법을 시도할 수 있는 낙관과 창의성이 필요하다. 방법론은 도움이 되지 않는다.

상호작용 다이어그램으로 메시지 흐름을 문서화하는 데에 얼마든지 시간을 투자할 수 있다는 말은 아무리 반복해도 지나치지 않는다. 물론 모든 메시지 흐름(message flow)이 컴퓨터에서 작동하는 데에 소요되는 시간을 받을 자격이 있는 것은 아니다:

실제 분석 수업에서 상황은 너무나 악화되기 때문에 우리는 수동으로 메시지 흐름을 포착해야 한다-창의적인 인간의 상호작용에 대한 역학 관계를 다루기엔 컴퓨터는 너무 느리다. 때로는 메시지를 전송하고 수신하는 객체를 충분히 생각할 사치조차 누리지 못한다. 화이트보드에 아래와 같은 소중한 낙서를 완성하여 수업을 나온다면 우리는 더할 나위 없이 기쁠 것이다:

급하게 손으로 그린 흐름은 읽기가 가능하거나 공유가 가능한 상태는 아니다. 반면 도표를 컴퓨터로 기록하는 것은 나에게 주어진 일정 이상의 시간이 소요될 수 있다. 게다가 많은 다이어그램에서 주요 혜택은 훌륭한 그림의 모습보다는 그것이 생성된 인간의 교환을 통해 발생한다. 일반 요인들-공유 가능성, 프로젝트 표준, 유효 직원, 경영진 기대-을 고려한 후에는 매력적으로 컴퓨터화된 형태로 기록하는 데 드는 비용만큼 가치가 있는 스케치의 수가 얼마나 되는지를 결정해야 할 것이다.

한계

상호 작용 다이어그램에는 그로부터 너무 많은 기대를 할 경우 당혹스럽게 만들거나 실망시킬 수 있는 한계가 몇 가지 있다.

• 상호 작용 다이어그램은 루프와 조건문을 표현할 수 없다. 도표를 하나의 경로를 가진 시나리오로 제한하거나 텍스트를 이용해 도표에 비형식적으로 주석을 단다. 단일 경로의 가정은 수용 가능한 것이 보통인데, 그것이 바로 당신이 밝히고자하는 주요 프로세싱이기 때문이다. Non-branching 도표를 생성하는 또 다른 방법은 고도로 branching한 도표를 다수의 작은 non-branching 한 도표로 분해하는 방법이다; 이렇게 작은 도표들은 그와 닮은 다른 복잡한 도표를 재조립하는 데에 재사용 가능한 단위(unit)로 밝혀졌다.
• 모든 것이 메시지는 아니다. 스몰토크 디자이너에게 지정(assignment)은 주범이다. 상호 작용 다이어그램은 객체들 간 메시지를 잘 표현하지만 그것뿐이다. 지정은 객체에게 메시지가 아니므로 상호 작용 다이어그램화에 가담하지 않는다. (balance :=2500 의 도표화를 시도해보라.) C++ 디자이너에게 이러한 상황은 더 악화된다: 선호되는 수신자 객체가 결여된 일반 함수 호출도 메시지가 아니다. 당신은 일반 함수 호출을 상호 작용 다이어그램, 즉 잘 정의된 전송 및 수신 객체를 요하는 다이어그램에 표현할 수 없다.
• 상호 작용 다이어그램은 그래픽하지만 인상적이지는 않다. 객체가 상단 모서리를 거쳐 하나의 영역에만 나타나도록 제한하기 때문에 각 객체의 아래, 위, 가깝게 또는 멀리 객체를 위치시키는 공간적 이익이 손실되고, 연결선은 가령 집합 관계와 같은 것을 가리킨다. 다시 말해, 상호 작용 다이어그램은 시간은 멋지게 표현할지 모르나 정적 정보는 사실상 전혀 없다.

앞의 두 가지 한계는 대부분 저수준 상호 작용 다이어그램에서 문제가 된다. 이번 장의 첫 번째 예제, 계좌 잔액 문의(account balance query)와 같이 고수준에 머무는 경우라면 이러한 제약을 피할 수 있다.

요약

필자는 복잡한 애플리케이션의 디자인을 비정상의 다차원적 블롭(blob)이라고 생각한다. 블롭(blob)을 설명하거나 이해하기 위한 간단한 공식이란 없다; 다만 다른 방식으로 쪼개보고 그 구조를 이해하기 위해 단면도를 살펴보는 수밖에 없다. 가장 익숙한 조각들은 정적이다; 이들은 주로 책임, 상속, 집합, 그 외 관계를 보여주는 클래스 도표이다.

하지만 정적 조각은 애플리케이션이 사용자를 위해 어떤 일을 해야 하는지 외에는 아무 것도 알려주지 않는다. 따라서 당신은 동적 조각이 필요한 것이다. 가장 간단한 동적 조각은 한 문장으로 된 use case이고, 그 다음으로는 use case의 확장(expansion)이 문(statement)들의 시퀀스가 해당하며, 마지막으로 그 객체와 메시지와 함께 상호 작용 다이어그램이 온다. 이러한 조각들은 애플리케이션의 기능성을 설명한다.

분석과 디자인의 초기 시절, 동적 조각은 정적 조각을 명료하게 했다. 동적 조각을 작업하다 보면 CRC 카드 또는 클래스 도표에 다양한 객체와 책임이 누락되어 있음을 깨닫기 때문이다. 후에 블롭(blob)이 어느 정도 안정되면 동적 조각은 시스템 검사자들을 위한 테스트 사례가 된다: use case 또는 상호 작용 다이어그램이 문서화된 것처럼 작동하지 않을 경우 검사자는 무언가 잘못되었음을 알게 된다. (정적 도표는 시스템이나 상호작용 검사자에겐 거의 무용지물인데, 다시 말하지만, 애플리케이션을 검사해야 하는 이유에 관해서는 아무 것도 알려주지 않기 때문이다.)

무언가를 좀 더 다른 관점에서 생각하다보면 주로 가치가 있는 것을 학습하게 된다. 동적 영역을 충분히 생각하다 보면 보통 블롭(blob)의 흐릿한 영역이 명확해진다. 디자인 문제가 당신을 당황하게 만든다면, use case 또는 상호 작용 다이어그램의 윤곽을 그려보라; 이 전술은 적어도 문제에 대해 신선한 관점을 제공할 수 있을 것이다. 그리고 흐릿한 영역을 규명해줄 것이다.

불행히도 많은 블롭(blob)에 있어서는 약간의 기록문서도 존재하지 않지만 어쨌든 스몰토크에서 인지되어왔다. 당신은 머잖아 이러한 블롭(blob)을 이해해야 할 것이다. 유일하게 생존하는 결과가 코드이기 때문에 그것을 조각내는 방법 밖에는 선택의 여지가 없다. 브라우저로 메서드 호출을 드릴 다운함으로써 정적으로 조각내는 수도 있다 (Browse Messages > Implementors를 계속 이용). 마지막으로, 실험조건을 준비하고, 디버거를 이용해 실행 경로를 거침으로써 동적으로 조각내야 할 것이다. 이러한 절차는 현미경으로 능숙하게 표본을 조사하는 것과 같다: 조직 박편을 선택하고 적절한 염색제를 준비하는 대신, 훌륭한 디버거 수업을 위해 적절한 객체를 모아 조건을 준비하는 셈이다. 사실상 당신은 상호 작용 다이어그램이 만일 있다면 당신에게 말해주었을 법한 내용을 재구성하고 있는 것이다.

논평: 역사적 주기

문제의 동적인 면의 이해에 대한 가치는 객체가 유명해지기 오래 전부터 인정되었다. 소프트웨어 공학자들은 순서도를 사용했고, 하드웨어 공학자들은 타이밍 다이어그램(timing diagram)을 사용하였다. 놀라운 점, 혹은 당혹스러운 점은 객체 기반의 변형(variation)이 나타나기까지 얼마나 많은 시간이 걸렸는지와 관련된다. Jacobson이 가장 먼저 [Jacobson 1987]에서 use cases를 언급하였다. 현재까지 모든 주류 객체 지향 디자인 방법은 애플리케이션의 역학 관계를 나타내는 일부 기법들을 옹호한다. 이러한 기법들은 다음과 같은 여러 이름으로 불린다: 상호 작용 다이어그램, 메시지 흐름 도표, 이벤트 추적 [Rumbaugh et al. 1991], 타이밍 다이어그램 [Booch 1994], 시나리오 [Reenskaug 1996], 또는 스크립트 [Gibson 1990; Rubin and Goldberg 1992].

그 외 애플리케이션 역학 관계에 대한 고수준적 관점은 [Burh and Casselman 1992]의 타임쓰레드(timethreads)를 참고한다.