Issuu on Google+

Chapter

01

객체지향

4 ⛣ ૸⮏⢛㒀#૷╯ 5 ⛣ ૸⮏⢛㒀#ഋᯓ ૷ါ 6 ⛣#૸⮏⢛㒀#῿ட#▫ⴴ

㐴←ᦄ㌷# Φ 객체지향의 등장 배경을 살펴본다. Φ 객체지향의 기본 개념을 학습한다. Φ 객체지향 설계 원칙을 학습한다.


1장에서는 객체지향 기술이 등장하게 된 배경을 알아보고 객체지향 기 본 개념과 설계 원칙을 학습한다. 기본 개념은 캡슐화, 상속, 추상, 다형성 등이 있으나, 객체지향의 꽃이 라고 할 수 있는 다형성이 가장 중요하다. 설계 원칙에는 단일 책임의 원칙(SRP : The Single Responsibility Principle ), 개방 폐쇄의 원칙(OCP : The Open-Closed Principle), 인 터페이스 분리의 원칙(ISP : Interface Segregation Principle), 리스코프 치환의 원칙(LSP : Liskov Substitution Principle), 의존 관계 역전의 원 칙(DIP : Dependency Inversion Principle) 등이 있다.


제1장 객체지향

1.1

CHAPTER 1

1

객체지향 개요

객체지향등장 배경

객체지향 1960년대 3세대 컴퓨터가 출현하면서, 하드웨어의 가격이 급속히 하락했다. 따라서, 컴퓨터의 이용 분야가 급속히 늘어나면서 다양한 소프트웨어가 필요했고, 하드웨어의 성능이 급속히 발전하면서 대규모의 소프트웨어 시스템을 효율적으로 구축해야 하는 문제가 발생했다.

기존 소규모 시스템에 적용하던 개발 방법은 적절치 않았기 때문에 기존 방법을 확장 할 수 없었다. 많은 프로젝트 개발이 계획한 기간보다 지연되었고, 개발 비용도 예상 을 초과했으며, 신뢰도도 낮아졌다.

결국, 체계적인 개발 방법이 필요했으며, 이때 등장한 개념 중의 하나가 ‘객체지향’이 다.

1.2

패러다임의 변화

프로그래밍 관점에서의 패러다임은 모듈화 프로그래밍 (Bottom-up) 방식에서 구조적 프로그래밍 (Top-down) 방식으로, 다시 객체지향 프로그래밍 (Incremental) 방식으로 변화했다. 데이터 관점에서 보면, 프로그램 자체 내에 자료를 보관하는 방식에서 파일 시스템을 이용하여 저장하는 방식으로, 그리고 데이터베이스를 이용하여 자료를 보관하는 방식

9


UML기반 분석/설계

으로 변화했다. 소프트웨어 공학 관점에서 생각해 보면, 구조적 방법론을 이용한 개발에서 객체지향 방법론을 이용한 개발로 변화했다. 기존의 구조적 관점에서 본 프로그래밍은 일정한 절차에 따라 자료를 생성/조회/저장/ 갱신하며 작업을 수행하는 것으로 바라보고 프로그래밍한다. 반면, 객체지향 프로그래 밍은 시스템 내의 모든 것(Thing)들을 객체로 보고, 그들 객체 간에 메시지를 주고받 으며 시스템의 기능을 수행하는 것으로 바라본다.

1.3

객체지향 방법론

41614#૸⮏⢛㒀#ᬄ᭰᜻♏ᙛB#

객체지향 방법론은 소프트웨어 시스템을 객체 모델을 기반으로 모델링하고 개발하는 방법론이며, 다음과 같은 장점이 있다. • 첫째로, 요구사항 변경에 유연하게 대처할 수 있다. 소프트웨어 시스템 개발 과정은 고객의 요구사항이 계속 변할 수밖에 없다는 특성을 가지고 있다. 그러 므로 개발 과정에서 요구사항 변경을 유연하게 수용할 수 있어야 한다.

객체지

향 개발 방법론이 이러한 유연성을 제공할 수 있다. • 둘째로, 기존 방식의 문제점을 극복할 수 있다. 기존의 개발 방식에서는 데이터 와 행위가 분리되어 개발이 복잡하고 통합하기 어려웠다. 객체지향 개발 방법은 데이터와 행위를 객체로 통합하기 때문에 이러한 문제점을 극복할 수 있다.

참고로, 객체지향 개발 과정이란 - 객체 중심으로 바라보면 - 데이터와 행위를 하나로 묶어 객체로 정의하고, 객체를 클래스로 설계하며, 클래스를 개발 및 구현해 가는 과 정이라고 할 수 있다.

10


제1장 객체지향

1960년대에 시뮬레이션을 위한 언어인 Simula에서 객체지향 개념을 사용한 이후, SmallTalk을 거쳐, C++와 자바, 그리고 C# 등의 객체지향 언어가 등장했다.

1980년대 후반부터 객체지향 방법론이 제시되었다. Shlaer/Mellor의 Shlaer, Booch의 Booch Method, Rumbaugh의 OMT 그리고 Jacobson의 OOSE, Coad/Youdon의 Yoad 등의 방법론이 등장했다. 1990년대 중반에 Booch, OMT 방법론이 통합되었고, 이어서 Jacobson의 OMT 방법 론도 통합되었다.

주요 방법론의 특징을 살펴보자.

41616#RPW+Remhfw#Prgholqj#Whfkqltxh,#ᬄ᭰᜻#

Rumbaugh가 GE 프로젝트들의 경험을 토대로 개발한 방법론이며, 1991년『 Object-

Oriented Modeling and Design』이라는 책을 통해 알려졌다. OMT 방법론은 시스템을 다음과 같이 다양한 모델로 표현한다. • 객체 모델(Object Model) • 동적 모델(Dynamic Model) • 기능 모델(Functional Model) λ 객체 모델(Object Model) 시스템의 객체들을 규명하고 객체들에 대한 정적 구조와 객체들의 관계를 나타낸 다. 객체 모델은 클래스 다이어그램과 서브 시스템 다이어그램, 객체 다이어그램으 로 서술된다. λ 동적 모델(Dynamic Model) 시스템 객체들의 상호작용을 표현한다. 즉, 시간의 변화에 따른 시스템의 변화를

11

CHAPTER 1

41615#૸⮏⢛㒀#⒓⒏┛#ᬄ᭰᜻#


UML기반 분석/설계

설명하며, 시스템의 제어적 측면을 표현한다. 동적 모델은 상태전이(State Transition) 다이어그램과 이벤트 추적(Event Trace) 다 이어그램으로 표현한다. λ 기능 모델(Functional Model) 시스템이 어떠한 기능을 수행해야 하는지를 나타낸다. 기능 모델은 객체 메시지(Object Message) 다이어그램, 데이터 흐름(Data Flow) 다이어그램으로 서술한다.

41617#ᱛⴳ+Errfk,#ᬄ᭰᜻#

국방, 상업 등 대규모 시스템 구축 경험을 기반으로 하여 부치가 제시한 방법론이다.

부치(Booch) 방법론의 특징은 다음과 같다. • 시스템 아키텍처에 초점을 둔다. • 시스템을 다양한 관점에서 분석하게 한다. • 반복적이고 점증적으로 개발하게 하는 프로세스이다.

41618#RRVH#ᬄ᭰᜻#

OOSE(Object-Oriented Software Engineering)는 야콥슨이 제안한 방법론이며, 통신 금융 업계에서 적용한 방법론이다.

OOSE의 특징은 유스케이스를 중심으로 하여 개발 과정을 진행한다는 것이다. 참고로 유스케이스는 분석/설계를 거쳐 실체화되고, 개발 과정에서 구현되며, 테스트 를 통해 검증되는 ‘시스템의 중요한 단위’이다.

12


제1장 객체지향

2.1

CHAPTER 1

2

객체지향 기본 개념

캡슐화(Encapsulation)

51414#⵼Ⅻ㔯ᙛB#Hqfdsvxodwlrq#

객체지향에서 캡슐화라는 개념은 클래스 내부에 여러 속성과 여러 오퍼레이션을 함께 묶음을 의미한다. 그리고 캡슐화는 클래스 내부의 속성이나 오퍼레이션을 외부에 노출 하지 않고 보호하는 것을 의미한다. 이렇게 캡슐화는 묶는 것과 보호하는 것을 생각할 수 있다. 좀 더 상세하게 생각해 보 면, 여러 속성과 여러 오퍼레이션을 함께 묶어 클래스로 취급하는 것과 클래스 내부를 외부에서 접근하지 못하도록 보호하는 것이 바로 캡슐화이다. 다음 [그림 1-1]을 보자.

-

LectureRoom id : String name : String capa : int insRunning : boolean floor : int

+ setId(id : String) + getId() : String + setName(name : String) + getName() : String + setCapa(capa : int) + getCapa() : int + setInsRunning(insRunning : boolean) + getInsRunning() : boolean + setFloor(floor : int) + getFloor() : int

[그림 1-1] LectureRoom 클래스

13


UML기반 분석/설계

[그림 1-1]은 LectureRoom(강의실)이라는 클래스를 나타내는 다이어그램이다. 그림 에서 사각형의 영역에서 가운데에 표현된 것을 속성(멤버변수라 이라고 한다)이라고 하며, 영역 아래에 괄호(())를 붙여 표현한 것을 오퍼레이션이라고 한다. 이렇게 속성과 오퍼레이션을 하나의 클래스로 패킹한 것이 바로 캡슐화라는 개념이다.

[그림 1-1]에서 속성은 마이너스 기호가 붙여져 있음을 볼 수 있으며, 이렇게 마이너 스로 표현되어 있기에 외부(다른 클래스를 의미함)에서 참조할 수 없다. 그리고 오퍼레이션에는 플러스 기호가 붙여져 있음을 볼 수 있다. 오퍼레이션은 플러 스 기호가 붙여져 표현되어 있기에 외부에서 참조할 수 있고 사용할 수 있다. 이렇게 외부로부터 내부를 감싸 숨기는 것을 캡슐화라고 한다.

『객체기술 사전』(Firesmith, Eykholt, 1995)에서는 캡슐화를 다음과 같이 정의하고 있다. ‘캡슐화란 공개적인 인터페이스 뒤로, 구현을 숨기기 위해 블랙박스 안으로 특성들을

위치시키는 것이다.’ 말하자면, 캡슐화로 인해 내부 구현이 외부에 노출되지 않고 숨겨지는 것이다. 왜 숨겨야 하는 것일까!

51415#⵼Ⅻ㔯ᡗ#┷#㑏⑗#㐳ᅯ૛B#

캡슐화를 통해 묶고 숨김을 생각해 보았다. 그런데, 왜 묶어야 하고 숨겨야 하는 것일까? 먼저, 묶음으로 인해 프로그램을 바라보는 단위가 커진다. 이전의 프로그래밍 언어인 C 언어는 프로그램을 함수 단위로 구조화할 수 있으나, 프로그램 소스가 커지면 이해 하기 어렵고 관리가 힘들어 질 수 있었다. 그러나 객체지향 프로그램에서는 프로그램 소스를 클래스 단위로 바라보게 됨으로써 좀더 복잡하고 커다란 소스 코드도 쉽게 이 해하게 되었다. 왜냐하면 클래스 내부에 여러 함수를 내포할 수 있기 때문에 프로그램 소스 코드를

14


제1장 객체지향

CHAPTER 1

바라보는 단위가 커졌으며, 그로 인해 프로그램 관리가 좀 더 수월해진 것이다.

두 번째로, 내부를 숨김으로써 내부를 좀더 자유롭게 변경할 수 있게 되었다. 이전의 함수 중심적인 구조적 프로그래밍 언어에서는 프로그램 내부에서 데이터가 어 디서 어떻게 변경되는지 파악하기 어려웠고, 그로 인해 유지 보수가 힘들었기 때문에 자료를 중심으로 함수가 종속되는 구조가 되기도 하였다. 객체 지향에서는 클래스 내부의 데이터를 외부에서 참조하지 못하도록 차단하여 이러 한 폐단을 없앨 수 있다. 이렇게 내부의 데이터나 함수를 외부에서 참조하지 못하도록 차단하는 개념을 정보 은닉(Information Hiding)이라고 하며, 이것이 바로 캡슐화라는 개념이다.

2.2

추상화(Abstraction)

추상화란 무엇일까? Abstraction 객체지향에서 추상화라는 개념은 ‘객체에서 공통된 속성과 행위를 추출하는 것’을 의 미한다. 예를 들어 홍길동 교수, 이순신 교수, 강감찬 교수가 있다고 하자. 이 교수들을 객체로 보고 공통된 속성과 오퍼레이션으로 ‘교수’라는 클래스를 정의한 다고 해 보자. 공통된 속성으로, 이름, 주민등록번호, 강의 분야, 주소, 전화번호를 추출하고, 공통된 행위로써 ‘강의하다’, ‘채점하다’, ‘과정 등록하다’를 추출했다고 하면, 다음과 같은 클 래스가 생성된다.

15


UML기반 분석/설계

-

교수 이름 : String 주소 : String 주민번호 : String 강의분야 : String 전화번호 : String

+ 강의하다() + 채점하다() + 과정등록하다() [그림 1-2] 교수 클래스

바로 이렇게 실제의 객체를 클래스로 정의하는 것이 추상화가 된다.

이번에는『객체기술 사전』에 정의된 내용을 보자. 『객체기술 사전』에 따르면, 추상화란 ‘중요하지 않거나, 주 관심 대상이 아닌 자세한

부분은 감추거나 무시하고, 가장 중요하고, 근간이 되고, 다른 대상들과 구분될 수 있 는 면만을 포함하고 있는 모델이며, 공통점을 강조하기 위해 차이점을 제거한 결과물’ 이라고 정의하고 있다. 실제로 객체의 속성과 행위 중에서 관심 대상이 아닌 부분은 드러낼 필요가 없는 것 이 추상화이다.

그러니까, 추상화는 다른 객체들과 구분되는 핵심적인 특징들에만 집중함으로써, 복잡 도를 관리할 수 있도록 한다. 주의할 점은 추상화는 문제 영역과 관점에 의존적이라는 것이다. 그래서 어떤 영역에서 중요한 것이 다른 영역에서는 그렇지 않을 수도 있다. 예를 들어 학생이라는 클래스를 생각해 보면, 대학교의 학사 관리 시스템에서 모델링 되는 학생이란 클래스와 멀티캠퍼스와 같은 단기 과정을 수강하는 곳의 시스템 내부 에서 모델링되는 학생이란 클래스는 내부의 속성과 오퍼레이션이 서로 많이 다를 것 이다. 따라서, 하나의 대상에 대하여 목적이나 원하는 기능에 따라 여러 추상화 모델이 생성 될 수 있다.

16


제1장 객체지향

CHAPTER 1

2.3

상속(Inheritance)

51614#ᾜ⁨♏ᙛB Inheritance#

상속의 사전적 의미는 자신이 가지고 있는 것을 하위에게 물려주거나, 하위에서 물려 받는 것이다. 객체지향에서 상속도 마찬가지 의미이며, 클래스의 속성과 오퍼레이션을 하위 클래스에 물려주거나, 상위 클래스에서 물려받는 것을 지칭한다.

예를 들어, 자바 API에서 최상위 클래스인 Object 클래스를 생각해 보자. Object 클래스 내부에는 다음과 같은 메소드가 존재한다.

protected void finalize() Class getClass() int hashCode() void notify() void notifyAll() String toString() void wait() void wait(long timeout) void wait(long timeout, int nanos)

자바의 모든 클래스는 Object 클래스의 하위 클래스가 되므로 어떤 클래스에서든 Object 클래스에 정의된 위와 같은 메소드를 사용할 수 있다. (위와 같은 메소드 중 일부는 필요에 따라 Overriding되어 활용됨을 잊지 말자.) 이와 같이 상속이란 하위에게 사용할 수 있도록 물려주는 것이다.

17


UML기반 분석/설계

51615#ᾜ⁨☟#ᾇ▄㐳Ⓡ#❦␟⢛ᅯ#୞☛B#

상속의 개념이 적용되어 좋아지는 것은 무엇일까?

먼저, 재사용으로 인해 코드가 줄어든다. 하위 클래스에서 속성이나 오퍼레이션을 다시 정의하지 않고 상속받아서 사용함으로 써 코드가 줄어든다. 그리고, 좀 더 범용성 있게 사용할 수 있다. 다음의 소스코드를 보자.

import java.util.Vector; public class InheritanceTest { public static void main(String[] args) { Vector v= new Vector(); v.add(new String("sample test")); v.add(new Integer(1000)); } }

소스코드에서 Vector 클래스의 add() 메소드가 사용되고 있음을 볼 수 있다. Vector 클래스의 add() 메소드 Operation Signature(시그너처라는 것은 메소드의 리 턴 타입과 매개변수를 의미한다)를 보면, “public boolean add(Object o)”라고 되어 있 음을 볼 수 있다. 오퍼레이션의 시그너처에 따라 매개변수의 타입이 Object 타입이어야 하는데, 위의 소스코드에서는 String 타입의 객체가 매개변수로 전달되었음을 볼 수 있다. 하지만 에러가 발생되지 않는 이유는 String 클래스가 Object클래스의 하위이기 때문이다. 마 찬가지로, Object 타입의 객체가 필요한 곳에 Integer 타입의 객체가 쓰여져도 문제되 지 않는다. Integer 역시도 Object 클래스의 하위이기 때문이다. 이러한 상황을 “어떤 객체가 필요한 곳에 그 객체의 하위타입의 객체가 사용될 수 있

18


제1장 객체지향

관련 있다. 이렇듯, 상속의 개념은 클래스를 좀 더 범용적으로 사용할 수 있게 한다.

참고로 하위 클래스는 상위 클래스가 가���고 있는 모든 자료와 메소드를 물려받아 자 유롭게 사용할 수 있지만, 또한 자신만의 자료와 메소드를 추가적으로 덧붙임으로써 새로운 형태의 클래스로 발전하게 된다는 것도 잊지 말자.

51616#ᾜ◟#⽏ᙳⅿ┛#㐳◟#⽏ᙳⅿ☳#Ᾰ‌♫#

생성자라는 것은 일종의 오퍼레이션이며, 클래스가 객체화될 때 실행된다. 그런데 하 위 클래스의 생성자를 호출할 경우, 자동적으로 상위의 생성자가 호출됨을 반드시 기 억해야 한다. 하위의 생성자가 호출될 때 묵시적으로 상위의 생성자를 자동으로 호출 하는 것이다.

2.4

다형성(Polymorphism)

51714#ᆿ㓰‌+Sro|prusklvp,♏ᙛB#

객체지향 개념에서 가장 중요한 것이 바로 다형성이다. 다형성이라는 개념은 객체 지 향 개념의 꽃이라고 할 수 있을 정도로 중요하고 근사한 개념이다.

웹 사전(www.webopedia.com)에 따르면, 다형성의 일반적인 의미는 ‘다양한 형태로

나타날 수 있는 능력’이라고 한다. 또 다른 웹 사전(en.wikipedia.org)을 보면, 객체지향에서의 다형성은 ‘여러 클래스들

이 동일한 이름의 오퍼레이션을 서비스하도록 하는 것’이라고 한다.

19

CHAPTER 1

다”라고 표현한다. 이러한 개념은 객체지향 설계 원칙 중에서 리스코프 치환의 원칙과


UML기반 분석/설계

이러한 다형성은 실제의 코드에서는 ‘하나의 클래스 내부에 같은 이름의 오퍼레이션을 여럿 정의하거나, 상위 클래스의 오퍼레이션을 하위 클래스에서 다시 정의함’으로써 구현한다.

자바 API에서 다형성을 사용한 예를 생각해 보자.

Object + Object() - registerNatives() + getClass() + hashCode() + equals() # clone() + toString() + notify() + notifyAll() + wait() + wait() + wait() # finalize()

String String() + length() + charAt() + getChars() + equals() + trim() + toString() + valueOf() + intern()

Date (from util)

+ Date() + setSeconds() + getTime() - getTimeImpl() + setTime() + equals() + hashCode() + toString()

[그림 1-3] String 클래스와 Date 클래스

20


제1장 객체지향

equals() 메소드가 존재하지만, 하위 클래스인 String과 Date 클래스에서도 toString(), equals() 메소드가 존재함을 볼 수 있다. 이렇게 상위 클래스에 있고 상속받았으나 하 위 클래스에서 다시 정의하는 것을 메소드 오버라이딩(Method Overriding)이라고 하 며, 메소드 오버라이딩이 다형성이다.

또, [그림 1-4]의 PrintStream의 클래스를 살펴보자.

PrintStream - autoFlush : boolean - trouble : boolean - closing : boolean + PrintStream(arg0 : OutputStream, arg1 : boolean, arg2 : String) + PrintStream(arg0 : OutputStream, arg1 : boolean) - PrintStream(arg0 : boolean, arg1 : OutputStream) + PrintStream(arg0 : OutputStream) + write(arg0 : int) : void + write(arg0 : byte[], arg1 : int, arg2 : int) : void - write(arg0 : char[]) : void - write(arg0 : String) : void + print(arg0 : boolean) : void + print(arg0 : char) : void + print(arg0 : int) : void + print(arg0 : long) : void + print(arg0 : float) : void + print(arg0 : double) : void + print(arg0 : char[]) : void + print(arg0 : String) : void + print(arg0 : Object) : void + println() : void + println(arg0 : boolean) : void + println(arg0 : char) : void + println(arg0 : int) : void + println(arg0 : long) : void + println(arg0 : float) : void + println(arg0 : double) : void + println(arg0 : char[]) : void + println(arg0 : String) : void + println(arg0 : Object) : void

[그림 1-4] PrintStream 클래스

21

CHAPTER 1

[그림 1-3]의 클래스 다이어그램에서 상위 클래스인 Object 클래스에 toString(),


UML기반 분석/설계

클래스 내부를 들여다보면, 동일한 이름의 오퍼레이션이 여러 개 정의되어 있음을 볼 수 있다. 단지, 매개변수의 타입에 따라 서로 구분되고 있음을 알 수 있다. 이렇게 클래스 내부에 동일한 이름의 오퍼레이션을 여럿 정의하는 것이 바로 메소드 오버로딩(Method Overloading)이라고 하는 다형성이다.

51715#ᆿ㓰‌☟#ᾇ▄㐳Ⓡ#⒖☟#⃳#♣ᅯ#୞B#

다형성을 사용함으로써 얻을 수 있는 것은 무엇일까? 첫째, 실제 실행될 오퍼레이션이 실행(런 타임)시에 결정될 수 있도록 한다. 이러한 개념으로 인해, 좀더 유연한 프로그램이 될 수 있다. 이렇게 실행 시에 결정되는 것을 ‘Late Binding’ 또는 ‘Dynamic Binding’이라고 한다.

둘째, 새로운 타입의 클래스를 추가하는 것이 자연스럽고 쉬워진다. 개발이 완료된 시스템에 새롭게 기능을 추가하거나, 기존의 기능을 개선하고자 할 때, 기존의 소스 코드를 변경하지 않는 것이 바람직하다. 기존 코드를 수정했을 경우, 어 떠한 문제가 발생될지를 보장할 수 없기 때문이다. 그런데 이렇게 기존 코드를 수정하 지 않은 채로 시스템의 기능을 확장할 수 있게 하는 개념이 바로 다형성이다.

정리해 보면, 다형성은 상위 클래스의 오퍼레이션을 하위 클래스에서 재정의(이것을 Overriding이라고 한다)하여 구현하거나, 같은 클래스 내부에 동일한 이름의 오퍼레이 션을 여럿 정의하여(이것을 Overloading이라고 한다) 구현한다.

그러면, 재정의(Overriding)와 중복정의(Overloading)에 대해 좀더 알아보자.

51716#᤯⁧Ꮇ#⓿᭟᜷ᐄ+Phwkrg#Ryhuordglqj,#

메소드 오버로딩이란 하나의 클래스 안에서 동일한 이름의 메소드를 여럿 정의하는 것을 의미한다.

22


제1장 객체지향

이다.

boolean equals(Object obj) void println(boolean x) void println(char x) void println(char[] x) void println(double x) void println(float x) void println(int x) void println(long x) void println(Object x) void println(String x)

위의 println() 메소드는 동일한 이름이지만, 호출될 때 전달되는 매개변수의 타입에 따라, 그 매개변수를 처리하는 해당 println() 메소드가 실행된다.

프로그래밍 단위가 함수인 구조적 프로그래밍 언어에서는 동일한 이름의 함수(메소드) 를 여럿 정의할 수 없었으나, 객체 지향 언어에서는 비록 같은 이름의 함수라고 할지 라도 서로 다른 클래스에 존재할 경우 문제되지 않는다. 게다가 같은 이름의 함수라고 할지라도 같은 클래스 내에 여럿 있을 수 있도록 개념 이 추가되었다. 그러나 매개변수의 개수가 다르거나, 타입이 달라서 서로 구별될 수 있어야 한다. 이러한 특징은 클래스 설계를 매우 유연하게 할 수 있게 한다. 위의 클래스에서와 같은 경우에서, 매개변수의 타입에 따라 오퍼레이션의 이름을 달리 한다면 얼마나 많은 오퍼레이션을 만들어야 할까?

23

CHAPTER 1

다음은 java.io.PrintStream 클래스의 println()이란 메소드 중에서 일부를 나열한 것


UML기반 분석/설계

51717#᤯⁧Ꮇ#⓿᭟ᙗ♏ᐄ+Ryhuulglqj,#

오버라이딩(Overriding)은 상속으로 물려받은 자료나 메소드를 사용하지 않고 자신이 새로 만들어 사용하는 방법이다.

메소드의 오버라이딩은 하위 클래스에서 동일한 이름을 지니는 메소드를 재정의하여 사용하는 것으로 상위의 메소드를 빌려 쓰지 않고 자신의 메소드를 사용한다. 오버라 이딩은 오버로딩과는 달리 모든 것이 같아야 한다. 즉 오버로딩에서는 메소드의 이름 은 같지만 인자의 리스트가 달라서 구분이 가능해야만 했다. 그러나 오버라이딩에서는 메소드의 이름뿐만 아니라 인자의 리스트도 완전히 똑같아야 한다. 또 하나의 다른 점 은 오버로딩은 한 클래스의 내부에서 생각하는 것이고 오버라이딩은 상속 관계가 맺 어진 두 클래스에서 생각하는 것이라는 점이다.

24


제1장 객체지향

CHAPTER 1

3

객체지향 설계 원칙

객체 지향으로 시스템을 개발할 때 다음과 같은 설계 원칙을 지켜야 한다. • 단일 책임의 원칙(SRP : The Single Responsibility Principle) • 개방-폐쇄의 원칙(OCP : The Open-Closed Principle) • 인터페이스 분리의 원칙(ISP : Interface Segregation Principle) • 리스코프 치환의 원칙(LSP : Liskov Substitution Principle) • 관계 역전의 원칙(DIP : Dependency Inversion Principle)

이러한 원칙을 잘 지켜 설계된 시스템은 이해하기 쉽고, 변경이 용이하며, 재사용성이 높아진다. 반면에 이러한 설계 원칙을 제대로 지키지 않은 시스템은 클래스 하나를 변경했을 때 그로 인해 변경되어야 하는 클래스가 많아지며, 다른 시스템에 재사용하기가 힘들어진 다.

객체지향 설계 원칙을 자세히 알아보자.

3.1

단일 책임의 원칙(SRP : The Single Responsibility Principle)

단일 책임의 원칙이란 ‘클래스에는 한 가지 종류의 책임만을 두어야 한다’는 원칙이다. SRP:The Single Responsibility Principle 하나의 클래스에 여러 종류의 책임을 두지 말라는 것이다.

25


UML기반 분석/설계

[그림 1-5]의 클래스 다이어그램을 보자.

[그림1- 5] Shopping 클래스

[그림 1-5]를 보면, Shopping이라는 클래스 내부에 상품을 등록하기 위한 오퍼레이션 registerProduct()이 있으며, 회원으로 가입하기 위한 오퍼레이션 registerMember() 도 있다. getProduct()는 상품정보를 조회하는 오퍼레이션이다. 이렇게, 하나의 클래스 에 상품에 대한 오퍼레이션과 회원에 대한 오퍼레이션이 함께 있음을 알 수 있다. 말 하자면 성격이 다른 오퍼레이션이 뒤섞여 있는 것이다.

이러한 설계는 변경에 매우 취약한 구조가 되게 한다. 왜냐하면 상품과 관련된 클래스 를 변경하거나, 회원과 관련된 클래스를 변경할 때 이 클래스를 변경해야 할 수도 있 기 때문이다. 그리고 Shopping클래스를 변경하면 회원관리와 상품관리 클래스를 모두 변경해야만 한다.

그래서 [그림 1-5]을 ‘단일 책임의 원칙(SRP)’을 적용하여 다음과 같이 분리하여 설 계한다.

26


제1장 객체지향

CHAPTER 1

[그림 1- 6] 분리된 Shopping클래스

이제, 회원이나 상품에 대한 변경이 있을 때, 함께 수정해야 하는 클래스가 줄어들게 되었다.

3.2

개방-폐쇄의 원칙(OCP : The Open-Closed Principle)

개방-폐쇄의 원칙은 ‘확장에 대해서는 개방되어야 하지만, 변경에 대해서는 폐쇄되어 야 하는 원칙’을 의미한다. OCP : The Open-Closed Principle

[그림 1-7] Strategy 패턴 클래스 다이어그램

27


UML기반 분석/설계

[그림 1-7]은 Strategy 패턴을 나타내는 클래스 다이어그램이다. 다이어그램에서 Strategy 인터페이스의 하위 클래스로 ProbStrategy와 WinningStrategy클래스를 볼 수 있다. 그리고 Player 클래스와 Strategy 인터페이스가 ‘Aggregation’으로 연결되어 있기 때 문에, Player클래스에서 멤버 변수로서 Strategy인터페이스를 소유하고 있음을 알 수 있다.

이러한 상황에서 새로운 Strategy클래스를 추가하여 기능을 확장하는 것은 무척 자연 스럽다. 왜냐하면 실행 시 Player의 멤버 변수를 변경하는 일은 Player 생성자를 실행할 때, 실제 필요한 Strategy객체를 생성하여 매개변수로 전달하면 되기 때문이다.

[그림 1-7]에서 새로운 Strategy를 추가한 사례는 [그림1-8]과 같다.

[그림 1-8] RandomStrategy를 추가한 Strategy 패턴 클래스 다이어그램

이러한 구조는 ‘인터페이스의 변경은 닫혀 있으나 인터페이스의 구현은 열려 있다’라 고 할 수 있으며, 이것이 바로 개방-폐쇄 원칙이다.

이러한 원칙을 통해 얻고자 하는 것은 기능을 확장했을 때, 기존 클래스의 변경을 최

28


제1장 객체지향

3.3

인터페이스 분리의 원칙(ISP : Interface Segregation Principle)

인터페이스 분리의 원칙이란 ‘클라이언트는 자신이 사용하지 않는 메소드와 의존 관계 를 갖지 않도록 해야 한다’는 원칙이다. ISP : Interface Segregation Principle

[그림 1- 9] 분리되지 않은 시스템

[그림 1-9]는 ISP를 적용하기 전의 모습이다. IManager인터페이스가 변경되면 관련 된 A, B, 그리고 C 클래스를 모두 변경해야 한다. 왜냐하면 A, B 그리고 C 클래스에 서 IManager를 참조하고 있기 때문이다.

이러한 시스템에 ISP를 적용하여 클라이언트에게 꼭 필요한 메소드만을 제공하도록 변경하면, IManager의 변경에 따른 변화를 최소화할 수 있다. [그림 1-10]은 이렇게 ISP를 적용하여 변경한 모습이다.

29

CHAPTER 1

소화할 수 있다는 점이다. 이러한 장점은 디자인 패턴을 적용하는 이유이기도 하다.


UML기반 분석/설계

[그림 1-10] ISP적용하여 변경한 시스템

3.4

리스코프 치환의 원칙(LSP : Liskov Substitution Principle)

리스코프 치환의 원칙은 ‘서브타입은 언제나 기반타입으로 대체할 수 있어야 한다’는 원칙이다. LSP : Liskov Substitution Principle

[그림 1-11] 자바 컬렉션 API

30


제1장 객체지향

<<interface>>라는 스테레오 타입으로 표시된 것들이 인터페이스이다. 이러한 컬렉션을 활용하는 소스가 다음과 같이 있다고 하자.

Utility.java 1

class Utility {

2

void add(Vector v) {

3

v.add();

4

//

5

//

6 7

} }

이러한 유틸리티 클래스는 Vector 클래스만을 사용한다면 문제가 되지 않겠지만, 수 행 속도를 높이기 위해 ArrayList나 LinkedList를 사용해야 한다면 다른 유틸리티 클 래스가 필요해진다. 그래서, ArrayList나 LinkedList 형태를 사용하기 위해서는 다음과 같이 변경하는 것 이 바람직하다.

Utility.java(개선된 소스) 1

class Utility {

2

void add(Collection collection) {

3

collection.add();

4

//

5

//

6 7

} }

이렇게 개선된 유틸리티 클래스는 Vector와 ArrayList, 그리고 LinkedList 모두를 사

31

CHAPTER 1

[그림 1-11]은 자바 컬렉션 API이다. 아래 진하게 표시된 것들은 클래스이며, 위쪽의


UML기반 분석/설계

용할 수 있는 구조로 변경되었다. 이것이 리스코프 치환의 원칙(LCP)을 활용한 것이 라고 할 수 있다.

3.5

의존 관계 역전의 원칙(DIP : Dependency Inversion Principle)

의존 관계 역전의 원칙은 ‘고차원 모듈은 저차원 모듈에 의존하면 안 된다’라는 원칙 이다. DIP : Dependency Inversion Principle 말하자면, 의존 관계가 뒤바뀌면 안 된다는 것인데, 자주 변경되는 클래스에 의존하지 말고 추상 클래스나 인터페이스에 의존해야 한다는 뜻이다.

일반적으로 추상 클래스와 인터페이스를 변경하기보다는 콘크리트 클래스(Concrete Class)를 변경해야 되는 경우가 더 많기 때문에, 콘크리트 클래스에 의존하면 그 클래 스에 의존하는 클래스를 수정해야 하는 경우가 더 많이 있다.

의존 관계 역전의 원칙(DIP원칙)은 자주 변경될 콘크리트 클래스나 변경될 가능성이 높은 ‘비즈니스 로직을 담은 클래스’에 의존하지 말고, 인터페이스나 추상 클래스에 의존할 것을 권고하는 원칙이다.

32


Chapter

02

UML 개요

4 ⛣#XPO ☳#☳᫓ 5 ⛣#XPO ☳#㆔⢰ 6 ⛣#XPO#㌷⟛☳#ే‌ 7 ⛣#FDVH#ኟే

㐴←ᦄ㌷# Φ UML의 의미와 특징을 학습한다. Φ UML 2.0의 표준 구성에 대해 살펴본다. Φ UML을 지원하는 CASE 도구의 기본적인 기능을 학습하고 대표적인 CASE 도구를 살펴본다.


UML은 소프트웨어 시스템을 개발할 때 팀원 간 아이디어를 도출하거 나, 개발할 시스템의 구조와 시스템의 동적인 관점을 표현할 때 사용하 는 모델링 언어이다. 이러한 UML은 OMG에서 표준으로 채택했고, 현재 버전 2.0이다.

장에서

UML의

의미와

특징을

학습하고,

UML

2.0

명세

(Specification)의 구성에 대해 살펴본다.

또한, UML을 지원하는 CASE 도구에는 어떠한 것들이 있는지 알아보 고, CASE 도구의 기본 기능을 학습한다.


제2장 UML 개요

1.1

CHAPTER 2

1

UML의 의미

‘Unified’의 의미

UML은 ‘Unified Modeling Language’의 약자이며, ‘통합된 모델링 언어’라고 할 수 있다. 무엇을 통합했기에 ‘Unified’라는 단어를 갖게 되었을까? [그림 2-1]을 보자.

[그림 2-1] 객체지향 방법론 표기법 통합

35


UML기반 분석/설계

[그림 2-1]의 아래 부분에서 볼 수 있는 Booch'91과 OMT-1, 그리고 OOSE라는 것 은 객체지향 방법론이다. 이러한 방법론들이 산재해 있다가(Fragmentation), 통합 (Unification)되었음을 알 수 있다. UML은 이러한 방법론들에서 사용하던 표기법을 통합하여 표준(Standardization)으로 채택한 모델링 언어이다. 이렇듯 여러 방법론에서 사용하던 표기법을 통합하여 생성했기에 ‘Unified’라고 표현 한 것이다.

UML의 U는 통합되었음을 의미한다면, UML의 ML은 어떠한 의미일까? UML의 ‘ML’은 모델링 언어(Modeling Language)라는 의미이다. 모델링이란 시스템 을 추상화하는 것이며, UML은 이렇게 시스템을 추상화하는 과정에서 사용하기에 모 델링 언어라고 한다.

UML이 언어라는 의미 속에는 모델링 과정에서 사용하지만 방법론은 아니라는 뜻이 내재되어 있다. 혹, UML을 ‘시스템을 모델링하는 과정에서 사용하는 방법론’으로 오 해할까 봐 언어라고 칭했다고 보면 된다.

정리해 보면, UML은 시스템 모델링에 사용하는 통합된 모델링 언어이다.

1.2

UML의 히스토리(History)

[그림 2-2]의 UML의 히스토리를 보자. UML의 히스토리(History)

36


제2장 UML 개요

CHAPTER 2

[그림 2-2] UML의 히스토리

[그림 2-2]의 아래 부분에서 볼 수 있듯이, UML은 여러 방법론에서 사용하던 표기법 들을 통합하여 표준으로 채택했는데, UML의 표기법을 상세하게 들여다보면, 클래스와 객체에 대한 표기에서는 OMT의 영향을 받았다는 것을 알 수 있다. 클래스에 대한 UML 표기법은 제 3장에 소개되어 있다. 그리고 UML 표기법에 유스케이스라는 개념 이 있는데, 이것은 ‘OOSE 방법론’에서 사용하던 개념과 표기법이다.

이러한 UML은 OMG(Object Modeling Group)라고 하는 표준화 단체에서 1997년 표 준으로 채택한 이래 꾸준히 개정해 왔다. UML의 주요 버전은 1.3과 1.5이고, UML의 현재 버전은 2.0이다.

37


UML기반 분석/설계

2

UML의 특징

UML의 특징을 알아보자. 먼저, UML 표준에, 기술된 ‘UML에 대한 정의’를 보면, “UML은 시스템의 아티팩트

(Artifacts: 시스템 모델, 산출물, 소스 코드 등등을 의미함)를 가시화하고, 명세화하며, 구축하고, 문서화하는 비주얼 언어이다. 객체지향 방법론과 CBD방법론에서 UML을 사용할 수 있으며, 애플리케이션 도메인(예를 들어 금융, 통신, 항공분야 등)에 적용할 수 있고, 구현 플랫폼(예를 들어 .NET이나 J2EE)에 사용할 수 있다”라고 되어 있다.

조금 어렵지 않은가? 더 나아가 ‘가시화’, ‘명세화’, ‘구축’, 그리고 ‘문서화’에 대해 좀 더 살펴보자. [그림 2-3]을 보자.

[그림 2-3] UML의 특징

38


제2장 UML 개요

CHAPTER 2

2.1

UML은 가시화 언어

UML은 시스템의 모델링 결과를 가시적으로 나타내게 하는 모델링 언어이다.가시화 UML은 모델링 결과를 여러 그래픽 심벌로서 구성된 다이어그램으로 표현할 수 있게 하기 때문에 UML을 사용하면 시스템을 가시적으로 나타낼 수 있다. UML의 그래픽 심 벌들은 정확한 의미를 가지고 있으므로, UML 그래픽 심벌로 작성된 다이어그램은 보는 이로 하여금 동일하게 해석하게 한다. 그러므로 동일한 의미를 공유할 수 있게 된다.

2.2

UML은 명세화 언어

UML을 이용하여 시스템을 명세화 할 수 있다. 명세화란 정확하고, 완전하게 모델링하는 것을 의미한다. UML은 분석, 설계, 구현에서 모든 중요한 결정에 대해 명세서를 취급할 수 있게 한다.

2.3

UML은 구축 언어

UML은 시스템을 구축할 수 있게 한다. UML로 작성된 다이어그램을 이용하여, 특정 프로그래밍 언어로 소스 코드를 생성할 수 있다. 이러한 기능을 순공학(Forward Engineering)이라고 한다. 반대로, 이미 생성된 소스 코드를 이용하여 UML 다이어그램을 작성할 수 있다. Rational

Rose나

Together와

같은

‘UML을 지원하는

CASE(Computer

Aided

Software Engineering) 도구’들은 이러한 기능을 제공 한다. CASE 도구의 기능을 이 용하여 ‘이미 작성되어 있는 소스 코드’를 읽어서 다이어그램을 생성하는 것이다. 이 러한 기능을 역공학(Reverse Engineering)이라고 한다. 이렇듯 UML은 시스템을 구 축할 수 있게 한다.

39


UML기반 분석/설계

2.4

UML은 문서화 언어

UML은 시스템을 문서화하는 데 사용할 수 있다. UML의 다이어그램은 시스템의 분석설계 결과물로 활용할 수 있다. 사용자의 요구사 항은 UML의 유스케이스 다이어그램을 사용하여 표현할 수 있으며, 시스템의 구조는 클래스 다이어그램으로 표현할 수 있다. 이외에도 시스템의 하드웨어 구조는 배치 다 이어그램으로 나타낼 수 있다. 그리고 시스템의 기능 수행 메커니즘과 과정을 시퀀스 다이어그램으로 표현할 수 있다. 이렇게 UML은 시스템을 문서화하기 위해 사용할 수 있다.

2.5

UML ‘통합(Unified)’의 의미

UML의 U는 ‘Unified’를 의미한다는 것은 이미 살펴본 사실이다. 이러한 ‘Unified’에 좀더 의미를 부여해 보자. • UML은 여러 방법론에서 사용되는 기호와 규칙을 통합(Unified)했다. • UML은 시스템 개발 사이클 전체(분석/설계/개발/구현-Unified)에 적용할 수 있다. • UML은 소프트웨어 개발 외에 다른 분야에도 적용할 수 있다. • UML은 특정 프로그래밍 언어에 종속적이지 않다. • UML은 특정 개발 방법론에만 적용되는 언어가 아니다. • UML은 특정 도구만을 사용해야 하는 것은 아니다.

40


제2장 UML 개요

3.1

CHAPTER 2

3

UML 표준의 구성

UML 2.0 표준의 구조

UML 2.0 표준은 다음과 같은 네 개의 파트로 구성되어 있다. • UML 2.0 Superstructure : 상부구조 • UML 2.0 Infrastructure : 하부구조 • UML 2.0 OCL(Object Constraint Language) : 객체제약 언어 • UML 2.0 Diagram Exchange : 다이어그램 교환

상부구조(Superstructrue)는 2004년 10월에 OMG에서 공식적으로 채택하여 발표되 었으나, 나머지 세 파트는 2006년 2월 현재까지 아직 공식 버전이 발표되지 않았다. 그러나 세 파트에 대한 ‘현재 유효한 명세(Specification)’를 OMG사이트(www.uml. org)에서 다운로드 할 수 있다.

상부구조 파트는 13개의 다이어그램과 그 다이어그램에 나타나는 요소들에 대한 명세 (Specification)이다. 하부구조 파트는 상부구조에 대한 기본이 정의되어 있으며, OCL은 객체 제약언어이고, Diagram Exchange는 UML 도구들이 다이어그램을 교환하기 위해 필요한 명세 (Specification)를 정의한 파트이다.

네 개의 UML명세를 제대로 파악하는 일은 매우 어렵다. 메타모델로 작성되어 있기에 이해하기 어렵고, 개념이 까다롭기 때문이다.

41


UML기반 분석/설계

UML로 작성된 산출물을 이해하거나 UML로 산출물을 작성하려 할 때, 이러한 네 개 의 파트 명세를 모두 이해하고 파악해야 하는 것은 아니다. UML로 작성된 산출물을 이해하거나 UML을 이용하여 산출물을 작성하기 위해서는, 상부구조의 각종 다이어그 램의 요소를 파악하고 다이어그램을 이해하는 정도로 충분하다. 결코 네 개의 명세를 살펴보아야 하는 것은 아니다.

3.2

하부 구조(Infrastructure)와 상부 구조(Superstructure)의 관계

하부구조와 상부구조에 대해 생각해 보자. 상부 구조에 정의된 것 중에서 클래스 다이어그램(Class Diagram)이라고 있는데, 이 러한 클래스 다이어그램 내부에 연관 관계(Association Relationship)라는 관계가 있 다. Infrastructure 연관 관계는 상부 구조에 다음과 같이 정의되어 있다.

[그림 2- 4] 상부 구조 명세에 정의된 연관관계

[그림 2-4]에서 Association이라고 표기된 사각형이 연관관계를 나타내는 기호이다.

42


제2장 UML 개요

(Generalization이라 하며 상하 관계를 부여할 때 사용한다)’으로 연결되어 있기에 Relationship의 하위임을 알 수 있다. 그런데 연관관계의 상위인 Relationship에 대한 명세는 바로 하부 구조에 정의되어 있다. 이렇듯 상부 구조에 기술된 요소들의 뿌리는 하부 구조에 있기 때문에 상부 구조의 근원이 하부 구조가 되는 것이다.

그렇다면, 하부 구조에는 Relationship이 어떻게 정의되어 있을까? 다음 그림을 보자.

[그림 2- 5] 하부 구조에 정의된 Relationship

하부 구조에 정의된 Relationship은 이탤릭체로 표현되어 있기에 추상 개념이 된다. 그리고 Relationship의 상위로 ‘Element’가 있음을 볼 수 있다. 여기서 밝히고자 하는 점은 상부 구조에 정의된 요소의 상위 개념이 하부 구조에 있다는 것이다.

다시 한 번 강조하지만, UML 표기법을 이용하여 모델링하거나 다이어그램을 만들고 자 할 때, UML 명세를 상세하게 알아야 하는 것은 절대 아니다. 단지, 어떠한 다이어

43

CHAPTER 2

이러한 연관관계는 Relationship이라는 기호와 ‘속이 비어 있는 삼각형 화살표와 실선


UML기반 분석/설계

그램이 있으며, 각 다이어그램이 나타내고자 하는 것이 무엇이고, 다이어그램 내부에 사용된 기호의 의미는 무엇인지를 파악하는 정도면 충분하다. 게다가 UML의 모든 다이어그램을 모두 알아야 하는 것도 아니다. 자신이 관여하고 있는 분야에 필요한 다이어그램을 파악하는 정도면 족하다.

3.3

상부구조

상부 구조는 13개의 다이어그램과 다이어그램에 등장하는 각 요소에 대한 파트이다. 13개의 다이어그램은 다음과 같이 구성되어 있다.

[그림 2-6] UML 상부구조의 다이어그램

UML 2.0에는 모두 13가지의 다이어그램이 있으며, 여섯 개의 구조 다이어그램을 이 용하여 시스템의 구조적인 관점을 나타내며, 일곱 개의 행위 다이어그램을 이용하여

44


제2장 UML 개요

UML 2.0에서 이전 버전의 UML과 달라진 다이어그램과 추가된 다이어그램에 대한 사항은 제5장에서 살펴볼 예정이다.

3.4

UML 다이어그램과 상부 구조와의 관계

UML 다이어그램은 여러 그래픽 기호로 표현한다. 이러한 그래픽 기호는 UML 상부 구조에 어떻게 정의되어 있을까? 그리고 UML 다이어그램과 상부 구조는 어떠한 관계 일까?

UML다이어그램 중에서 유스케이스 다이어그램을 이용하여 생각해 보자. 다음과 같은 UML 유스케이스 다이어그램이 있다고 하자.

[그림 2-7] 유스케이스 다이어그램의 사례

이러한 유스케이스 다이어그램은 시스템의 기능과 사용자를 나타내는데, 타원으로 표 현된 기호를 유스케이스(UseCase)라고 하며 막대 인간으로 표현된 기호를 액터

45

CHAPTER 2

시스템의 동적인 관점을 나타낸다.


UML기반 분석/설계

(Actor)라고 한다. 그리고 실선과 화살표로 표현된 기호를 연관 관계라고 한다.

유스케이스 다이어그램에 등장하는 유스케이스에 대한 상부 구조에 정의된 명세는 다 음과 같다.

유스케이스는 시스템이 수행하는 기능의 집합 또는 일련의 작업을 의미한다.

유스케이스 다이어그램에 기술하는 그래픽 기호들의 관계는 상부 구조 명세에 다음 그림과 같이 정의되어 있다.

46


제2장 UML 개요

CHAPTER 2

[그림 2-8] UML 상부 구조에 명시된 유스케이스 명세

[그림

2-8]에서

굵은

사각형으로

표시된

것이

유스케이스이며,

유스케이스는

‘BehavioredClassifer’와 상속의 관계로 연결되어 있기 때문에, ‘BehavioredClassifer’ 의 하위임을 알 수 있다. 그리고 유스케이스는 ‘Extend’와 ‘Include’와 ‘다이아몬드가 있는 실선’으로 연결되어 있기 때문에 ‘Extend’와 ‘Include’를 소유할 수 있는 것으로 이해한다. 이렇게 명세를 보며 유스케이스와 연관된 개념들을 이해할 수도 있겠으나, 실제 다이어그램 사례를 보며 이해하는 편이 훨씬 빠르다. 다이어그램과 다이어그램 내부 요소에 대한 설명은 제5장과 6장에서 상세하게 살펴볼 예정이다.

명세를 살펴보는 일은 쉽지 않다. 명세에 기술된 설명을 이해하기 쉽지 않기 때문이다. CASE 도구를 개발하려면 UML 명세를 자세하게 이해해야 하겠지만, UML을 이용하 여 시스템을 모델링하거나 UML로 작성된 다이어그램을 이해하려는 정도인 경우에는

47


UML기반 분석/설계

UML명세(Specification)를 볼 필요 없으며, 다이어그램이 설명된 책을 보는 것으로도 충분하다.

48


제2장 UML 개요

4.1

CHAPTER 2

4

CASE 도구

CASE 도구란?

소프트웨어 시스템의 프로그램을 코딩하고 디버깅할 때, 이클립스나 비주얼 스튜디오 등의 개발 도구를 사용한다. 이렇듯, 프로그래밍을 할 때 사용하는 개발 도구도 있지 만, 소프트웨어 시스템을 분석하고 설계할 때도 사용하는 도구가 있다. 이것이 바로 CASE 도구이다.

CASE는 Computer Aided Software Engineering의 약자이다. 컴퓨터를 이용한 소프 트웨어 공학이란 의미이다. 말하자면 소프트웨어 시스템을 개발하기 위한 활동에 컴퓨 터를 이용하는 것을 의미한다.

‘컴퓨터를 이용한다’의 의미를 생각해 보자. 소프트웨어 시스템을 개발할 때, 각 단계별 모델링 결과를 여러 다이어그램으로 표현 하게 된다. 이러한 여러 다이어그램을 CASE도구를 이용하여 작성하는 것이다. 그러나 CASE도구는 다이어그램을 작성할 때만 사용하는 것은 아니다. CASE도구를 이용하면 소스 코드를 생성할 수도 있으며, 반대로 소스 코드를 이용하여 다이어그램을 생성할 수도 있다. 하지만, 소스 코드를 생성할 수 있는 기능은 그다지 매력적이지 않다. 왜 냐하면 생성된 소스 코드가 개발 단계에 별로 도움이 되지 않기 때문이다.

이제 CASE 도구에 대해 알아보자. CASE 도구 중에서 UML을 지원하는 제품의 목록은 다음과 같다.

49


UML기반 분석/설계

제품명

회사

URL

Umodel2005

Altova

http://www.altova.com

Artisan Studio

Artisan Software

http://www.artisansw.com

Together

Borland

http://www.borland.com

Embarcadero

http://www.embarcadero.com/ software/rational

Embarcadero Describe Technologies

http://www-306.ibm.com/ Rational Software

IBM software/rational

Rhapsody

I-Logix

http://www.ilogix.com

MetaBase Modeler

MetaMatrix

http://www.metamatrix.com

MagicDraw

No Magic

http://www.magicdraw.com

EclipseUML

Omondo

http://www.omondo.com

PathMATE

Pathfinder Solution

http://www.pathfindermda.com

StarUML

Plastic Software

http://www.staruml.com

Pattern Weaver

Technologic Arts

http://www.tech-arts.co.jp

Telelogic System Architect

Telelogic

http://www.telelogic.com

이러한 CASE 도구 중에는 비상용과 널리 사용되는 제품도 있는데, 대표적인 것에는 Rational Rose와 Together, System Architect, 그리고 Enterprise Architect가 있다.

4.2

CASE 도구의 기능

CASE도구에서 보편적으로 지원하는 기능을 살펴보자.

71514#FDVH#ኟేᅯ#XPO#ᦃቓᢜ☟#⢛▫㐷ᆿ#

CASE 도구는 UML 모델링을 지원한다.

50


제2장 UML 개요

할 수 있다. 그러니까 유스케이스 다이어그램, 클래스 다이어그램, 시퀀스 다이어그램 등을 작성할 수 있는 것이다.

CASE도구를 이용하면, 경우에 따라 데이터 모델링이 가능하다. Rational Rose와 Together, 그리고 SA는 이러한 기능을 사용할 수 있다.

CASE도구는 UML 다이어그램의 오류를 검증할 수도 있다. 예를 들어 시퀀스 다이어 그램에서 사용된 객체가 클래스 다이어그램에 존재하는지를 바로 체크할 수 있게 한 다.

71515#FDVH#ኟేᅯ#⃷ௐ㐴 ഋᆀௗ#Ⓢௐ㐴#ഋᆀ☟#⢛▫㐷ᆿ#

순공학은 모델링의 결과를 이용하여 소스 코드를 생성하는 것을 의미한다. CASE 도 구들은 이러한 순공학 기능을 제공한다. 역공학은 소스 코드를 이용하여 모델링을 작 성하는 것을 의미한다. 모델링을 하고 난 후, 소스 코드를 생성하는 것이 보통의 순서 이지만 반대로 진행하는 것이기에 역공학이라고 하는 것이다. CASE 도구들은 이러한 기능을 제공한다.

71516#XPO#ᦃቓᢜ#஋ௗᡗ#ᨓῷ᜷#Ᾰ‌㐻#⃳#♣ᅯ#ഋᆀ☟#⢛▫㐷ᆿ#

CASE 도구들은 모델링 결과를 문서로 생성하는 기능을 지원한다. 문서의 대표적인 형식은 MS 워드와 웹 문서이다. 소프트웨어 시스템을 분석하고 설계할 때, 분석설계 결과를 문서로 작성해야 할 경우가 대부분이다. CASE 도구들은 모델링의 결과를 활 용하여 문서를 자동 생성하는 기능을 가지고 있다.

51

CHAPTER 2

CASE 도구를 이용하면 소프트웨어 시스템의 분석 단계와 설계 단계의 산출물을 작성


UML기반 분석/설계

4.3

Rational Rose란?

Rational Rose라는 CASE 도구는 Rational 사에서 개발했는데, Rational 사는 2003년 에 IBM에 합병되었다.

71614#Udwlrqdo#Urvh ☳#㆔⢰#

다음은 Rational Rose의 기능이다.

λ UML 모델링 기능 지원 Rational Rose에는 UML의 다이어그램을 생성할 수 있는 기능과 데이터 모델링 다이 어그램을 작성할 수 있는 기능이 있다.

λ 순공학 기능 지원 Rational Rose는 모델링의 결과를 이용하여 소스 코드를 생성할 수 있는 기능이 있다. Java, VB, C++ 등 다양한 언어로 소스 코드를 생성할 수 있으며, DBMS에 대한 DDL을 자동으로 생성하는 기능도 있다.

λ 역공학 기능 지원 Rational Rose는 소스 코드를 활용하여 다이어그램을 생성하는 기능을 지원한다. Java, VB, C++ 등의 언어로 작성된 소스 코드를 반대로 다이어그램으로 생성할 수 있게 한다. 그리고 DDL로 작성된 스크립트를 활용하여 데이터 모델을 자동으로 생성하는 기능도 지원한다.

λ 다른 툴과의 연동 기능 Rational Rose는 Rational ClearSafe나 Microsoft의 SourceSafe와 같은 툴과 연동된 다.

52


제2장 UML 개요

Rational Rose는 Web Publisher 기능을 이용하여 모델링의 결과를 HTML 파일로 생 성할 수 있다.

λ Web Page 역공학 기능 JSP나 ASP와 같은 웹 페이지를 역공학으로 분석하여 다이어그램으로 생성할 수 있는 기능이 있다.

71615#⯣ഋ#㔯᥏ௗ#㔯᥏#῿ᥠ#

다음은 Rational Rose의 초기 화면이다.

[그림 2-9] Rational Rose의 초기화면

53

CHAPTER 2

λ Web Publishing 기능


UML기반 분석/설계

• 다이어그램:다이어그램이 출력되는 윈도이다. • 브라우저:다이어그램과 다이어그램의 구성 요소들이 트리 구조로 구성되어 나 타나는 윈도이다. • 표준 툴바:모든 다이어그램에서 공통으로 사용할 수 있는 아이콘으로 구성되어 있다. • 다이어그램 툴바:다이어그램에 따라 사용할 수 있는 아이콘으로 구성되어 있다. • 문서 윈도:모델 구성요소에 대한 참고 설명이 출력되는 윈도이다. • 로그 윈도:실행 결과나 오류가 출력되는 윈도이다.

71616#┐″#῿⛰#㔯᥏#

Rational Rose의 환경 설정 화면은 다음과 같다.

[그림 2-10] Rational Rose의 환경 설정 화면

54


제2장 UML 개요

CHAPTER 2

4.4

Together란?

Together는 TogetherSoft 사에서 개발한 CASE 도구이다. TogetherSoft는 2003년 에 볼랜드에 인수되면서 Borland Together란 이름으로 판매되고 있다.

Together는 Rose와는 달리, 모델링과 소스 코드를 동기화할 수 있다. 가령 다이어그 램을 수정하면 소스 코드가 동시에 수정되며, 소스 코드를 수정하면 다이어그램이 수 정되는 것이다.

71714#Wrjhwkhu ☳#㆔⢰#

λ UML 모델링 지원 Together에는 UML의 여러 다이어그램을 생성할 수 있는 기능이 있다. 그리고 Entity Relationship 다이어그램, 웹 애플리케이션 다이어그램 등이 추가로 지원된다.

λ 순공학 기능과 역공학 기능 지원 Together에는 Java, C++, VB, C# 등의 언어에 대한 순공학 기능과 역공학 기능이 있다.

λ 다이어그램과 소스 코드의 동기화 기능 지원 Together의 다이어그램을 수정하면, 동시에 소스 코드도 수정된다. 소스 코드를 수정 하면 동시에 다이어그램도 수정된다. 이렇듯 다이어그램과 소스 코드가 동기화되어 있 다.

λ J2EE 개발 지원 Together는 Java의 J2EE에 대해 개발 환경도 지원한다. 즉 J2EE 애플리케이션에 대 해 컴파일, 빌드, 디버깅 기능이 지원되는 것이다. 그리고 jar, war, ear 컴포넌트의 빌

55


UML기반 분석/설계

드와 배치를 자동으로 수행한다. 컴포넌트의 배치 디스크립터를 생성하는 기능과 J2EE 서버에 배포하는 기능도 제공한다.

λ 문서화 기능 지원 Together는 모델링 결과를 활용하여 문서를 생성하는 기능을 제공한다.

λ Refactoring 기능과 JUnit 연동 기능 지원 Together는 Refactoring 기능을 제공한다. Refactoring 기능을 이용하여 소스 코드를 보다 바람직한 방향으로 수정할 수 있게 된다. 그리고 Together는 JUnit과의 연동 기 능을 제공한다. JUnit은 소스 코드를 테스트할 때 사용하는 테스트 프레임워크이며 API이다.

71715#⯣ഋ#㔯᥏ௗ#㔯᥏#ే‌#

[그림 2-11] Together의 초기 화면

56


제2장 UML 개요

CHAPTER 2

71716#┐″#῿⛰#㔯᥏#

Together의 옵션은 Tools/Options 메뉴로 설정한다. Together의 옵션은 다음과 같이 세 가지 수준으로 분류한다.

• 기본 수준(Default Level):설정 사항은 모든 프로젝트에 공통으로 적용된다. • 프로젝트 수준(Project Level):설정 사항은 현재 프로젝트에만 적용된다. • 다이어그램 수준(Diagram Level):설정 사항은 현재 다이어그램에만 적용된다. 다음은 옵션 설정 화면이다.

[그림 2-12] Together의 환경 설정 화면

옵션 대화 창의 왼쪽 리스트에서 General, Diagram, View Management 등은 확장되 어 상세 화면이 나타난다.

57


UML기반 분석/설계

4.5

SA란?

SA(System Architect)는 미국 Popkin Software 사에서 개발한 모델링 도구이다. SA 는 하나의 도구를 이용하여 비즈니스 모델링과 데이터 모델링, 그리고 객체 지향 및 컴포넌트 모델링을 수행할 수 있다. 그리고 SA는 구조적 분석설계의 모델링도 지원한 다. 참고로 SA는 Telelogic사에 합병되었다.

71814#㆔⢰#

λ 여러 방법론의 표기법 지원 SA는 여러 방법론을 지원한다. 예를 들어 Catalyst, OMT, Yourdon, Booch 등의 방법 론의 결과를 표기할 수 있는 기능이 있다.

λ 순공학과 역공학 기능 지원 SA는 SQL DDL 언어로 작성된 스크립트를 자동으로 생성하는 기능뿐만 아니라, COBOL, C++, Java, VB, Delphi, Power Builder 등의 언어로 소스 코드를 생성할 수 있는 기능을 가지고 있다. 또한, 역공학을 지원하는 기능도 있다.

λ 모델링 결과 문서화 지원 SA는 MS 워드나 HTML로 모델링 결과를 저장할 수 있는 기능이 있다.

λ 모델링 결과가 여러 파일이 있는 폴더로 생성됨 SA는 새로운 프로젝트를 생성하여 모델링을 수행한다. 모델링 내의 여러 다이어그램 들은 하나의 폴더 내에 여러 파일로 저장된다. Rational Rose는 모델링 결과가 하나의 파일로 저장되지만, SA는 하나의 폴더 내의 여러 파일로 저장된다.

58


제2장 UML 개요

CHAPTER 2

71815#VD ☳#⯣ഋ#㔯᥏ௗ#㔯᥏#῿ᥠ#

SA의 초기 화면은 다음과 같다.

[그림 2-13] SA의 초기 화면

SA 초기화면에는 여러 툴바(그리기, 메인, 편집, 다이어그램)가 있으며, 다이어그램 윈 도를 통해 다이어그램의 상세를 나타낸다.

71816#VD ☳#㔳஘#῿⛰#

[그림 2-14]는 SA의 환경을 설정하기 위한 화면이다.

59


UML기반 분석/설계

[그림2-14] SA의 환경 설정 화면

[그림 2-14]에서 설정하는 사항은 다음과 같다. • Data Modeling:데이터 모델링의 종류를 선택한다. • Business Modeling:비즈니스 모델링의 타입을 선택한다. • Structured A/D:구조적 분석설계의 종류를 선택한다. • Object Modeling:객체 지향 모델링의 종류를 선택한다. • Other Useful Diagrams:사용할 다이어그램을 추가한다. • Target Database:사용할 DBMS를 선택한다. • Target Language:사용할 프로그래밍 언어를 선택한다.

60


Chapter

03

클래스

1 절 클래스 개요 2 절 클래스 속성과 오퍼레이션 3 절 클래스 설계 실습

학습목표 Φ UML의 주요 요소 중 하나인 클래스에 대해 알아본다. Φ 클래스 내부의 속성과 오퍼레이션을 학습한다. Φ 클래스 설계를 실습한다.


클래스는 객체지향 방법론과 CBD 방법론에서 무척 중요한 요소이다. CBD 방법론에 따라 컴포넌트의 내부를 설계할 때 클래스를 사용하며, 객체지향 방법론에서도 클래스를 중심으로 시스템을 분석하고 설계한 다. 이 장에서는 클래스에 대한 UML 표기법을 살펴보며, 클래스 내부 요소 인 속성과 오퍼레이션을 학습한다.


제3장 클래스

1.1

CHAPTER 3

1

클래스 개요

UML의 클래스 표기법

클래스는 ‘공통의 속성, 오퍼레이션 및 관계를 갖는 객체들의 집합’이라고 할 수 있다. UML에서의 표기법을 살펴보자.

[그림 3-1] UML의 클래스 표기법

UML에서는 클래스를 사각형으로 표현하며, [그림 3-1]과 같이 사각형을 세 부분으로 분할하여 첫째 칸에는 이름을 기술하고, 가운데 영역에는 속성을, 그리고 제일 아래 부분에는 오퍼레이션을 표시한다.

1.2

클래스란?

클래스는 UML User’s Guide에 다음과 같이 정의되어 있다. ‘클래스는 공통의 속성, 오퍼레이션, 관계 및 의미를 갖는 객체들의 집합이다.’ 말하자면 객체들의 공통된 속성과 오퍼레이션을 정의한 것이 바로 클래스이다. 예를 들어, 어느 회사에 홍길동이라는 이름의 사원과 황진이라는 이름의 사원이 있다

63


UML기반 분석/설계

고 하자. 그리고 그 회사에서 사용하는 시스템에서 두 사람을 클래스로 표현한다고 할 때, 두 사원의 공통된 속성과 오퍼레이션을 모아서 다음과 같이 사원 클래스로 정의할 수 있다.

[그림 3-2] 사원 클래스

클래스의 속성과 오퍼레이션은 시스템에서 관리하는 데이터에 따라서 달라지며, 실행 하는 오퍼레이션에 따라 달라진다. 그래서 동일한 클래스라고 할지라도 시스템에 따라 달리 정의될 수 있다. 속성을 일반적인 데이터라고 생각해 볼 때, 실제 세계에서의 ‘사원’은 훨씬 더 많은 속성(어트리뷰트)을 가지고 있다고 보아야 할 것이다. 예를 들어 실제 세계에서의 사 원은 사번이나 주소와 같은 속성뿐만 아니라 키나 몸무게, 그리고 혈액형 등의 속성도 가지고 있지만, 클래스로 표현할 경우에는 시스템 내부에서 다루어지는 데이터와 의미 있는 데이터만을 속성으로 표현해야 한다.

1.3

클래스 표기에 대한 UML 권고안

클래스 표기법에 대한 UML 스펙에 기술된 권고안을 살펴보자. 이 권고안은 반드시

64


제3장 클래스

결과를 이해하기 쉬워진다. • 클래스의 이름은 명사로 표기하며, 대문자로 시작하도록 한다. • 속성과 오퍼레이션은 첫 글자를 소문자로 표현한다. • 오퍼레이션은 동사로 시작하도록 표현한다. • 패키지와 함께 표현할 때 다음과 같이 표현한다. package_name :: ClassName • 클래스가 추상 클래스이면 클래스 이름을 이탤릭체로 표현한다(오페레이션도 추 상 오퍼레이션일 경우 이탤릭체로 표현한다). • 속성과 오퍼레이션은 꼭 필요한 경우에는 모두 표현하지만, 나타낼 필요가 없을 경우에는 보이지 않도록 한다.

65

CHAPTER 3

지켜야 하지는 않지만, 지켜서 작성했을 경우에는 가독성을 높일 수 있으므로 모델링


UML기반 분석/설계

2 2.1

클래스 속성과 오퍼레이션

클래스 속성(Attribute)이란?

속성은 클래스의 특성이다. 속성(특성)은 클래스가 객체화되었을 때 객체의 상태를 나 타내는 값을 보유하게 된다. Attribute 예를 들어, 사원이란 클래스가 있고, 사원 클래스 내부에 이름이란 속성이 있다고 하 자. 이러한 사원클래스가 객체화되어 이름이란 속성에 ‘홍길동’이나 ‘황진이’라는 값을 가 질 수 있는 것이다.

『UML User’s Guide』에는 속성에 대해 다음과 같이 정의되어 있다. ‘속성이란 클래스의 구조적 특성에 이름을 부여한 것으로서 클래스의 객체가 보유할 수 있는 값의 범위를 기술할 수 있다.’

속성이 여러 속성을 가질 때 또 다른 클래스로 정의된다. 예를 들어, 사원클래스에 부양가족이라는 속성을 고려했다고 하자. 그러나 부양가족이 라는 속성이 이름과 주민등록번호 등과 같이 여러 속성을 가지면 또 다른 클래스로 정의한다. 속성과 클래스를 구별하는 방법은 클래스의 경우 여러 가지 속성을 가질 수 있으나, 속성은 단순한 값으로 표현된다는 것이다.

66


제3장 클래스

CHAPTER 3

2.2

속성 표기법

표기법은 다음과 같다.

[가시성] 속성 이름[:타입][다중성][=기본값][{특성 문자열}]

표기법에서 대괄호([])로 표현된 항목은 생략할 수 있다. 그래서 속성 이름을 제외하 고 나머지는 기술하지 않아도 된다. 표기법에 따라 속성은 기본값으로 초기화될 수 있 다.

이러한 표기법에 따른 예제는 다음과 같다. color

→ 속성 이름만 기술되었다.

color : Color

→ 속성 이름과 속성의 타입이 기술되었다.

color : Colr= “red”

→ 기본값으로 초기화되었다.

points : Point[]

→ 배열로 표현되었다.

+id

→ 가시성(Visibility)도 표현되었다.

:

Integer

속성 중에서 클래스 영역 변수는 다음과 같이 밑줄을 그어 표현한다. +black : Color

2.3

클래스 오퍼레이션(Operation)

오퍼레이션은 객체가 수행하는 서비스를 의미한다. UML User’s Guide에 다음과 같이 정의되어 있다. Operation ‘오퍼레이션이란 클래스의 행위적 특성이며, 이러한 오퍼레이션은 오퍼레이션 이름, 리턴 타입, 선행 조건과 후행 조건과 같은 제약사항을 가질 수 있다.’

67


UML기반 분석/설계

2.4

오퍼레이션 표기법

오퍼레이션의 표기법은 다음과 같다.

[가시성] 오퍼레이션 이름([매개변수 리스트])[:리턴타입[다수성]][{특성문자열}]

이러한 표기법에 따른 사례를 살펴보자. display() : Location + hide() - create() attachWindow(xwin:Xwindow)

2.5

가시성(Visibility)

Visibility 가시성은 클래스의 속성과 오퍼레이션에 부여할 수 있는 특성이며, 클래스 외부에서 참조할 수 있는 정도를 의미한다. 가시성의 종류는 다음과 같다. λ public • 외부 클래스에서도 사용할 수 있다. public으로 지정된 속성과 오퍼레이션은 클 래스 외부에서도 참조할 수 있고 사용할 수 있다. λ protected • 하위 클래스와 해당 클래스 내에서만 사용할 수 있다. protected로 지정된 속성 과 오퍼레이션은 하위 클래스와 해당 클래스 내에서만 사용할 수 있다. λ private • 해당 클래스에서만 사용할 수 있다. private으로 표현된 속성과 오퍼레이션은 해 당 클래스에서만 사용할 수 있다.

68


제3장 클래스

CHAPTER 3

가시성에 대한 표기법은 다음과 같다. + : public # : protected - : private

2.6

추상 클래스(abstract Class)

추상클래스는 다음 그림과 같이 이름을 이탤릭체로 표기한다. abstract Class

Shape

Rectangle

Triangle

[그림 3-3] 추상클래스의 표현

2.7

인터페이스(interface)

인터페이스는 객체가 수행하는 서비스의 집합이다. 이러한 인터페이스는 구현을 갖지 않는다. interface 인터페이스의 표기법을 생각해 보면, 다음과 같이 아이콘으로 표현하거나 클래스 타입 으로 나타낸다.

69


UML기반 분석/설계

[그림 3-4] 인터페이스 표기법

2.8

클래스와 소스 코드

다음과 같은 클래스가 있다고 할 때 그 클래스와 소스 코드를 연계시켜 생각하여 보 자.

LectureRoom +id: String +name: String +floor: int +capa: int +isRunning: boolean +getId(): String +setId(id: String): void

[그림 3-5] LecureRoom 클래스

LectureRoom.java(자바언어) 1

public class LectureRoom {

2

public String id;

3

public String name;

4

public int floor;

5

public int capa;

6

public boolean isRunning;

7

public String getId() {

8

}

70


제3장 클래스

public void setId(String id) {

10 11

CHAPTER 3

9

} }

12 13 14

LectureRoom.cs(C# 언어) 1

public class LectureRoom {

2

public string id;

3

public string name ;

4

public int floor ;

5

public int capa ;

6

public bool isRunning ;

7

public string getId(){

8

}

9

public void setId(string id){

10 11

} }

12

LectureRoom.h(C++ 언어) 1

#if !defined(_LECTUREROOM_H)

2

#define _LECTUREROOM_H

3

class LectureRoom {

4

public:

5

CString id;

6

CString name;

7

int floor;

8

int capa;

71


UML기반 분석/설계

9

bool isRunning;

10

CString getId();

11

void setId(CString id);

12

};

13

#endif //_LECTUREROOM_H

LectureRoom.cpp(C++ 언어) 1

#include "LectureRoom.h"

2

CString LectureRoom::getId() {

3

}

4

void LectureRoom::setId(CString id) {

5

}

72


제3장 클래스

CHAPTER 3

3

클래스 설계 실습

다음의 객체를 각각 클래스로 설계하여 속성과 오퍼레이션을 정의해 보자. • 냉장고 • 선풍기 • 빔 프로젝터 • 학생

클래스는 객체들의 공통 속성과 오퍼레이션을 정의한 것임을 기억하며, 클래스로 생성 해 보자. 속성과 오퍼레이션을 대략 다섯 가지 정도 기술해 보자. 속성은 타입도 정해 보자. 명심해야 할 사항은 클래스의 속성과 오퍼레이션은 설계 관점에 따라 달라진다는 것 이다.

73


Chapter

04

관계

1 절 일반화 관계 2 절 연관 관계 3 절 의존 관계 4 절 인터페이스 실체화 관계 5 절 관계 실습

학습목표 Φ 일반화 관계, 연관 관계, 의존 관계, 인터페이스 실체화 관계에 대해 학습 한다. Φ 관계를 실습한다.


이번 장에서 일반화 관계, 연관 관계, 의존 관계 및 인터페이스 실체화 관계를 학습한다.

관계를 나타내는 기호와 의미는 서로 다르다. 이번 장에서 각 관계를 표현할 때 사용하는 기호는 무엇이며 어떠한 의 미인지, 그리고 관계의 차이는 무엇인지를 학습한다.

1절1부터 4절까지 관계를 학습한 후, 마지막 절인 5절에서 관계를 실 습한다.


제4장 관계

1.1

CHAPTER 4

1

일반화 관계

일반화(Generalization)란?

일반화(Generalization) 관계는 [그림 4-1]과 같이 상위와 하위관계를 의미한다.

동물

고양이

[그림 4-1] 일반화 관계

[그림 4-1]에서 새와 동물이 ‘속이 비어 있는 화살표와 실선’으로 연결되어 있음을 볼 수 있다. 이러한 그래픽 기호(속이 비어 있는 화살표와 실선)가 일반화를 의미한다. 화살표가 가리키는 측이 상위이며, 반대 측이 하위이다.

상위와 하위는 어떠한 관계일까? 일단 ‘모든 하위는 상위이다’로 해석할 수 있다. 위의 그림에서 ‘모든 새(하위)는 동물 (상위)이다’로 이해할 수 있다. 그러나 반대는 성립하지 않는다. ‘모든 동물은 새다’라 는 사실은 거짓이 되기 때문이다. 상위와 하위가 일반화 관계를 가질 때, 하위들의 일 반적인 공통점을 상위에서 보유하고 있으며, 하위는 상위의 공통점을 상속받아서 가지

77


UML기반 분석/설계

고 있게 된다.

공통점을 상위에서 가지고 있다는 개념을 좀더 상세하게 생각해 보자. 일반화 관계의 결과로써 두 클래스가 상위와 하위로 연결되지만, 일반화라는 것은 여 러 클래스에서 동일한 속성과 오퍼레이션을 추출하여 상위 클래스로 정의하는 것, 즉 추상화 수준을 높이는 것을 의미한다. 다음과 같은 객체가 있다고 하자.

나비 :고양이

야옹이 :고양이

이름 : 나비 나이 : 2세 품종 : 터키시앙고라 몸무게 : 1.5kg

이름 : 야옹이 나이 : 1세 품종 : 참고양이 몸무게 : 1kg

[그림 4-2] 나비와 고양이 객체

이러한 객체의 공통된 속성을 모아 다음과 같이 클래스로 정의할 수 있다.

-

고양이 이름 나이 품종 몸무게

[그림 4-3] 고양이 클래스

마찬가지로 다음과 같은 객체가 있다고 하자.

78


제4장 관계

CHAPTER 4

삼식이 :개

삼순이 :개

이름 : 삼식이 나이 : 1년 품종 : 핏불테리어 몸무게 : 5kg

이름 : 삼순이 나이 : 8개월 품종 : 진돗개 몸무게 : 3kg

[그림 4-4] 삼순이 객체와 삼식이 객체

이러한 객체들의 공통 속성을 모아 다음과 같이 ‘개’ 클래스로 정의할 수 있다.

-

개 이름 나이 품종 몸무게

[그림 4-5] 개 클래스

그래서 개와 고양이 클래스의 공통점을 추출하여 상위 클래스를 다음과 같이 생성한 다면, 바로 일반화를 적용하는 것이다.

[그림 4-6] 개와 고양이를 일반화한 동물 클래스

79


UML기반 분석/설계

일반화에서 하위는 상위의 구조적 특징과 행위적 특징을 모두 물려받게 된다. [그림 4-6]에서 고양이와 개의 관점에서 보면, 고양이와 개는 동물의 구조적 특징과 행위적 특징을 모두 상속받는 것이다.

1.2

일반화는 ‘is a kind of’ 관계

일반화 관계를 ‘is a 관계’ 또는 ‘is a kind of’ 관계라고도 한다. 예를 들어 ‘고양이는 동물의 한 종류이다’라는 일반화 관계를 ‘고양이는 동물이다’라고 표현해도 된다는 것이다. 모든 고양이는 동물이기 때문이다.

80


제4장 관계

2.1

CHAPTER 4

2

연관 관계

연관 관계(Association Relationship)란?

연관 관계는 구조적 관계를 의미한다. Association Relationship

[그림 4-7] 연관 관계

위 그림에서 사람과 회사가 ‘화살표가 있는 실선’으로 연결되어 있음을 볼 수 있다. 이러한 ‘화살표가 있는 실선’을 연관 관계라고 한다. 두 클래스가 연관 관계로 연결되 어 있으면, 한 쪽에서 다른 쪽을 사용하거나 참조할 수 있음을 의미한다. 그래서 위의 ‘일한다’라는 연관 관계의 의미는 다음과 같다. 사람은 회사와 ‘일한다’라는 관계를 갖는다.

2.2

역할(Role Name)

연관 관계로 연결된 클래스는 다음 그림처럼 역할(Role Name)을 가질 수 있다.

[그림 4-8] 역할이 표현된 연관 관계

81


UML기반 분석/설계

위의 그림에서 역할 명이 없는 경우에는 ‘사람이 회사에서 일한다’로 해석하지만, 역 할 명이 있는 경우에는 ‘사람이 직원이라는 역할로서 직장에서 일한다’로 해석한다.

2.3

다중성(Multiplicity)

연관 관계는 다중성(Multiplicity)을 가질 수 있다.

[그림 4-9] 다중성

다중성은 숫자로 표현한다. 위의 그림에서 사람 클래스에 ‘1..*’로 표현되어 있는 것의 의미는 직원이라는 역할로서 회사와 관계를 갖는데, 한 사람 이상의 사람들이 회사와 직원이란 이름으로 ‘일한다’라는 관계를 가질 수 있음을 나타낸다. 마찬가지로 회사 클래스는 ‘1’이라는 다중성으로 표현되어 있는데, 이것은 사람이 회 사와 일한다라는 관계를 가질 때 반드시 하나의 회사와만 관계를 가질 수 있음을 의 미한다.

다중성은 다음과 같이 여러 가지로 표현될 수 있다.

2,3

*

1..*

82


제4장 관계

CHAPTER 4

2.4

재귀적 연관 관계(Recursive Association)

동일한 클래스로 생성된 인스턴스 사이에 연관 관계가 있을 경우 재귀적 연관 관계로 표현한다. Recursive Association

[그림 4-10] 재귀적 연관 관계

[그림 4-10]은 관리자와 사원 모두 직원클래스의 인스턴스이며, 관리자 인스턴스가 사원 인스턴스를 관리함을 나타내고 있다.

2.5

연관 관계와 소스 코드

이러한 연관 관계를 소스 코드와 연계시켜 생각해 보자.

Person.java & Company.java(java 언어) 1

class Person {

2 3

Company company; }

4 5

class Company {

6

}

83


UML기반 분석/설계

Person.cs & Company.cs(C# 언어) 1

public class Person {

2

public Company company;

3

}

4

public class Company {

5

}

Person.h & Company.h(C++ 언어) 1

//Company.h

2

class Company {

3

};

4

//end of Company.h

5

//Person.h

6

class Person {

7

Company* pCompany;

8

};

9

//end of Person.h

2.6

집합 연관(Aggregation)

집합 연관은 연관 관계의 특수한 경우에 해당한다. Aggregation 다음 그림을 보자.

부서

1..*

회사

[그림 4-11] 집합 연관

그림에서 부서와 회사 사이에 있는 ‘다이아몬드와 실선’이 바로 집합 연관이다.

84


제4장 관계

는 측이 전체이며 반대 측이 부분이다. 그래서, [그림 4-11]에서 회사를 전체로, 그리 고 부서를 부분으로 해석한다.

집합 연관은 연관 관계의 특수한 경우이며, 소스 코드를 생성했을 때 연관 관계의 결 과와 동일하다.

이러한 집합 연관 관계를 나타내는 기호는 UML 2.0에서 사용하지 않으며, 2.7절의 합 성 집합 연관 표기법만을 사용한다.

2.7

합성 집합 연관(Composition Aggregation Relationship)

Composition Aggregation Relationship 합성 집합 연관도 집합 연관과 마찬가지로 연관의 특수한 형태이다. 그리고 합성 집합 연관은 집합 연관의 특수한 경우가 된다.

합성 집합 연관의 표기법은 [그림 4-12]와 같이 속이 채워져 있는 마름모 형태의 심 벌로 표현한다.

[그림 4-12] 합성 연관

합성 집합 연관은 집합 연관과 마찬가지로 전체와 부분의 관계를 의미하지만, 전체가 소멸될 때 부분에 해당하는 요소도 함께 소멸된다. 부분이 전체와 생성·소멸을 함께 하는 것이다.

85

CHAPTER 4

집합 연관은 전체와 부분의 관계(Whole-Part Relationship)이다. 다이아몬드가 놓여지


UML기반 분석/설계

2.8

연관 클래스(Association Class)

Association Class 연관 자체가 여러 속성을 가질 때 그 속성을 간직할 연관 클래스를 두게 된다. 주로 두 클래스가 ‘다대다’의 관계로 맺어질 때, 연관 클래스가 생성된다. 회원

상품 0..*

0..*

주문

[그림 4-13] 연관 클래스

[그림 4-13]에서 주문 클래스가 연관 클래스이며, 상품과 회원의 관계에서 정의되기 에 상품과 회원의 관계와 연결되어 있음을 볼 수 있다.

[그림 4-13]에서 상품 클래스와 회원 클래스의 관계를 보면, 상품 클래스 쪽에 ‘0..*’ 이라는 다중성이 적용되었음을 볼 수 있다. 이러한 다중성은 회원이 상품을 여럿 주문 할 수도 있고 하나도 주문하지 않을 수도 있음을 의미한다. 회원 클래스에도 ‘0..*’라는 다중성이 있음을 볼 수 있으며, 동일한 의미를 갖는다.

[그림 4-13]의 상품 클래스와 회원 클래스의 관계에서, 발생하는 데이터가 여럿 있을 수 있다. 그러니까, 주문 수량이나 주문일, 그리고 배송지 주소 등의 데이터가 생길 수 있는 것이다. 이러한 정보들이 주문이라는 클래스의 속성으로 저장된다고 할 수 있다.

이렇게 두 클래스 간의 관계가 여러 데이터로 표현되어야 할 때, 연관 클래스로 만들 어진다고 보면 된다.

86


제4장 관계

3.1

CHAPTER 4

3

의존 관계

의존 관계(Dependency Relationship)

의존 관계에 대해 UML 2.0 명세에 다음과 같이 기술되어 있다. ‘의존 관계는 하나 이상의 모델 요소의 명세나 구현이, 다른 모델 요소를 필요로 하는 관계를 의미한다.’ Dependency Relationship 그러니까 어느 모델 요소가 다른 모델 요소를 필요로 할 경우 서로 의존 관계로 연결 하는 것이다.

이러한 의존 관계는 다음과 같이 표기한다.

Client

Supplier [그림 4-14] 의존 관계

[그림 4-14]에서 Client와 Supplier 사이의 ‘점선의 화살표’가 의존 관계를 나타내는 기호이다. [그림 4-14]는 ‘Client는 Supplier에게 의존함’을 나타내고 있다.

의존 관계에서 의존되는 모델 요소가 변경되면, 의존하는 모델 요소도 영향을 받는다. 서로 의존 관계에 있기 때문이다.

의존 관계는 상황에 따라, 사용(Usage), 추상(Abstraction), 허용(Permission), 실체화 (Realization) 등으로 구분된다.

87


UML기반 분석/설계

이미 존재하는 소스 코드를 이용하여 역공학으로 모델을 생성할 경우, 어느 클래스에 서 오퍼레이션의 매개 변수나 리턴 타입으로 다른 클래스를 사용한다면 서로 의존 관 계로 연결한다.

일반적으로 오퍼레이션의 매개 변수나 리턴 타입으로 사용되면 의존 관계로 표현하며, 지속적으로 참조하면 연관 관계로 표현한다. 일시적으로 객체를 생성하여 오퍼레이션 을 수행한 이후에는 사용하지 않는다면, 속성으로 계속 유지할 필요가 없기 때문이다.

88


제4장 관계

4.1

CHAPTER 4

4

인터페이스 실체화 관계

인터페이스 실체화 관계(Interface Realization Relationship)

인터페이스 실체화 관계는 인터페이스와 그 인터페이스를 구현한 클래스 사이의 관계 를 의미한다. Interface Realization Relationship

<<Interface>> MyInterface

ImplClass

[그림 4-15] 인터페이스 실체화 관계

위 그림은 ImplClass 클래스가 MyInterface라는 인터페이스를 구현하고 있다.

인터페이스는 내부에 오퍼레이션을 가질 수 있지만, 그 오퍼레이션은 선언만 할 수 있 다. 그래서 인터페이스는 객체화되지 않는다.

89


UML기반 분석/설계

5

관계 실습

다음과 같은 문��� 속에서 객체를 도출하여 클래스로 정의하고, 클래스 간의 관계를 정 의해 보자. • 강의실에는 의자와 책상들이 있다. • 강사가 수강생들을 가르친다. • 학생은 시험으로 평가된다. • 컴퓨터는 메인보드, 하드디스크, 메모리, CPU로 이루어져 있다. • 웨이터는 직원이다. • 컴퓨터는 USB방식을 지원한다. • 객체지향 과목은 UML의 선수과목이다. • 부서에는 사원이 있다. • 회사와 프리랜서는 비즈니스로 이루어진 관계이다. • 컴퓨터는 책상 위에 있다.

각 문장 속에서 객체는 무엇이며, 그리고 객체 간에는 어떠한 관계가 있는 것일까?

90


Chapter

05

다이어그램-Structural

1 절 다이어그램 개요 2 절 클래스 다이어그램 3 절 컴포넌트 다이어그램 4 절 디플로이먼트 다이어그램 5 절 컴포지트 스트럭처 다이어그램 6 절 패키지 다이어그램 7 절 다이어그램 실습

학습목표 Φ UML 명세에 어떠한 다이어그램이 있는지 살펴보고, 이전버전과 2.0버전의 차이점을 학습한다. Φ UML의 13개의 다이어그램 중에서 구조적 성격의 다이어그램 여섯 가지를 학습한다.


UML 2.0 명세에는 13개의 다이어그램이 존재하며, 이 다이어그램들을 구조적인 것들과 행위적인 것들로 분류할 수 있다. 이 장에서는 이러한 UML 다이어그램을 살펴보고, UML2.0과 이전 버전 의 차이점을 학습한다. 그리고, 구조적인 다이어그램들과 다이어그램 내부에 존재하는 요소를 살펴본다.


제5장 다이어그램-Structural

1.1

CHAPTER 5

1

다이어그램 개요

UML 2.0 다이어그램들

[그림 5-1]은 UML 2.0의 다이어그램들을 구조적으로 나타낸 것이다.

[그림 5-1] UML 2.0의 다이어그램

[그림 5-1]에서 이탤릭체로 표현된 ‘Diagram’, ‘Structure Diagram’, ‘Behavior Diagram’, ‘Interaction Diagram’은 실제로 존재하는 다이어그램이 아니라 여러 다이 어그램의 상위로 표현된 것이다. 따라서 이탤릭체로 표현된 것들을 제외한 나머지 13개 다이어그램이 실제로 존재하는 다이어그램이다.

93


UML기반 분석/설계

[그림 5-1]에서 이탤릭체로 표현된 다이어그램의 이름을 통해 다이어그램들의 특성을 파악해 볼 수 있다. 바로, 구조적인 것과 동적인 것이다. 즉 13개의 다이어그램을 구 조적인 관점을 표현하는 여섯 개의 다이어그램과 동적인 관점을 나타내는 일곱 개의 다이어그램으로 분류할 수 있다. 그리고, 동적인 관점을 나타내는 일곱 개의 다이어그 램 중에서 네 개의 다이어그램(시퀀스, 인터렉션 오버뷰, 커뮤니케이션, 타이밍)이 인 터렉션의 하위로 표현되어 있음을 볼 수 있다. UML의 이러한 다이어그램들을 이용하여 소프트웨어 시스템의 구조적인 관점과 동적 인 관점, 그리고 물리적인 관점을 표현하는 것이다.

1.2

UML 2.0과 UML 1.3의 다이어그램 비교

UML 2.0 버전의 다이어그램과 UML 1.3 버전의 다이어그램을 비교해 보자. 버전 1.3에서의 다이어그램은 다음의 [그림 5-2]와 같이 구성되어 있다.

[그림 5-2] UML1.3의 다이어그램들

94


제5장 다이어그램-Structural

다이어그램이 있으므로 UML 2.0에서 네 개의 다이어그램이 추가되었음을 알 수 있다.

[그림 5-3] UML 2.0에서 추가되거나 달라진 다이어그램들

[그림 5-3]에서 사각형으로 표현된 다이어그램들(Composite Structure Diagram, Package Diagram, Interaction Overview Diagram, Timing Diagram)이 추가된 것이 며, 타원으로 표현된 것 중에서 ‘Communication Diagram’은 이전 버전의 다이어그램 중에서 ‘Collaboration Diagram’이라는 다이어그램이 변경된 것이다. 타원으로 표현된 State Machine Diagram은 이전 버전의 Statechart Diagram의 이름이 변경된 것이다.

1.3

다이어그램의 실제 사용 사례

이러한 다이어그램을 이용하여 시스템의 여러 관점을 나타내는데, 실제로 사용되는 예 를 생각해 보자. 다음은 CBD방법론을 간략히 적용한 시스템 개발 단계를 표현한 표이다.

95

CHAPTER 5

비교해 보면, UML 1.3에서는 아홉 개의 다이어그램이 있으나, UML 2.0에서는 13개의


UML기반 분석/설계

[표 5-1] 간단한 CBD 방법론 공정표 단계

활동

작업 비즈니스 프로세스 모델링

비즈니스 모델링

UML 적용 기법 액티비티 다이어그램 클래스 다이어그램(도메인

비즈니스 개념 모델링 모델링) 요구정의 요구사항 정의 요구사항 정의

유스케이스 모델링

유스케이스 다이어그램

이터레이션 계획 유스케이스 정의서, 유스케이스 상세화

유스케이스 상세화 액티비티 다이어그램 클래스 다이어그램(객체 유스케이스 정적 분석 모델링)

분석

커뮤니케이션 다이어그램,

유스케이스 분석

시퀀스 다이어그램, 유스케이스 동적 분석 스테이트 머신 다이어그램 (상태 모델링) UI 설계

UI 설계 컴포넌트 식별

컴포넌트 다이어그램

컴포넌트 상호작용 정의

시퀀스 다이어그램

컴포넌트 정적 설계

클래스 다이어그램

컴포넌트 정의

시퀀스 다이어그램, 설계

컴포넌트 설계

스테이트 머신 다이어그램 컴포넌트 동적 설계 (상태 모델링), 오퍼레이션 명세 논리적 DB 설계

DB 설계 물리적 DB 설계 배치 설계

배치 설계

개발

개발

구현

단위 테스트 테스트 통합 테스트

96

디플로이먼트 다이어그램


제5장 다이어그램-Structural

어 있는 것들이 바로 UML 다이어그램이다. 이렇듯, 시스템 개발 각 단계에서 UML 다이어그램을 이용하여 결과를 표현한다.

참고로, 위의 절차는 하나의 참고에 지나지 않는다. 실제 프로젝트 수행 시에는 프로젝트 성격과 특성 등 여러 요인에 따라 프로젝트 수 행 절차를 결정하기 때문에 매 프로젝트마다 절차는 달라진다.

97

CHAPTER 5

[표 5-1]에서 ‘UML 적용 기법’이란 컬럼에 표기된 내용 중에서 다이어그램이라고 되


UML기반 분석/설계

2 2.1

클래스 다이어그램

클래스 다이어그램이란?

클래스 다이어그램(Class Diagram)은 시스템의 정적인 관점을 나타낸다. 시스템 내부 에 존재하는 클래스가 무엇이며, 그 클래스의 속성과 오퍼레이션이 무엇인지를 표현한 다. 그리고 클래스 간에 존재하는 관계를 나타내는 것이 클래스 다이어그램이다.

[그림 5-4] 클래스 다이어그램

클래스 다이어그램을 통해서 시스템 내부에 어떠한 클래스가 존재하는지 알 수 있다. 그리고 그 클래스들이 어떤 클래스를 상속받았는지, 그 클래스 내부의 오퍼레이션이 실행될 때 어떤 클래스의 도움을 받아야 하는지 등을 파악할 수 있다.

98


제5장 다이어그램-Structural

CHAPTER 5

2.2

구성요소

클래스다이어그램의 구성요소는 다음과 같다.

2.2.1 클래스

사각형으로 표현하며, 자세한 내용은 제3장 ‘클래스’에서 학습한 바와 같다.

2.2.2 관계(Relationships)

연관(집합 연관, 복합 연관, 재귀적 연관, 연관 클래스), 상속, 의존, 인터페이스 실체 화 등이 있으며, 자세한 내용은 제4장 ‘관계’를 참조한다.

2.2.3 인터페이스(Interface)

객체가 수행하는 서비스를 나타내며, 자세한 내용은 제3장 2절 ‘클래스 속성과 오퍼레 이션’을 참조한다.

2.3

사례

클래스다이어그램의 몇 가지 사례를 보자.

2.2.1 계약 컴포넌트 내부 클래스 다이어그램

[그림 5-4]는 계약관리시스템의 계약 컴포넌트 내부의 클래스들을 표현하고 있는 클 래스 다이어그램이다.

99


UML기반 분석/설계

[그림 5-5] 계약 컴포넌트의 클래스 다이어그램

클래스 다이어그램을 통해 컴포넌트 내부에 존재하는 클래스와 클래스 간의 관계를 알 수 있다.

2.2.2 세미나 관리 시스템의 클래스 다이어그램

[그림 5-5]는 세미나 관리 시스템의 클래스 다이어그램이다.

100


제5장 다이어그램-Structural

CHAPTER 5

<<entity>>

SeminarInfoEty (from seminar) + getInstance() - SeminarInfoEty() + add() + make() + show() + list() + setRecord() + modify() + remove() + result() + getNextSeminarID()

+ # + + + + + +

<<entity>>

<<ValueObject>>

Board (from main)

SeminarInfoVO (from seminar)

Board() finalize() add() make() show() list() modify() remove()

-si

-sie -$instance

- seminarID : int - subject : String - hostEmpID : String - hostEmpName : String - instructorEmpID : String - instructorEmpName : String - descript : String - planStartDate : String - planEndDate : String - rsltStartDate : String - rsltEndDate : String - roomID : String - roomName : String - processSw : String - inputDate : String - chgDate : String

-sia[ ] SeminarInfoServlet (from seminar) main.jsp show.jsp list.jsp [그림 5-6] 세미나 관리 시스템의 클래스 다이어그램

[그림 5-6]에서 바운더리 클래스는 아이콘으로 표현되어 있으며, 엔티티 클래스는 클 래스를 나타내는 사각형 기호 내부에 스테레오 타입으로 엔티티 타입임을 표현하고 있음을 볼 수 있다.

2.2.3 C++ 노트패드 프로그램 클래스 다이어그램

다음은 C++로 작성한 노트패드 프로그램의 클래스 다이어그램이다.

101


UML기반 분석/설계

CWinApp CMyNotepadApp CMyClass + +

-m_me

CMyClass() ~CMyClass() CFrameWnd

-

m_me: CMyClass

+ + + +

CMyNotepadApp() InitInstance() : BOOL OnAppAbout() : void OnHelpAbout() : void

CMainFrame # #

m_wndStatusBar: CStatusBar m_wndToolBar: CToolBar

+ # + + # +

AssertValid() : void CMainFrame() ~CMainFrame() Dump(CDumpContext&) : void OnCreate(LPCREATESTRUCT) : int PreCreateWindow(CREATESTRUCT&) : BOOL

CDialog CAboutDlg + #

CAboutDlg() DoDataExchange(CDataExchange*) : void

CDocument CMyNotepadDoc + # + + + +

CEditView

AssertValid() : void CMyNotepadDoc() ~CMyNotepadDoc() Dump(CDumpContext&) : void OnNewDocument() : BOOL Serialize(CArchive&) : void

CMyNotepadView

CDialog MyTestDialog # +

DoDataExchange(CDataExchange*) : void MyTestDialog(CWnd*)

+ # + + + # + # # +

AssertValid() : void CMyNotepadView() ~CMyNotepadView() Dump(CDumpContext&) : void GetDocument() : CMyNotepadDoc* OnBeginPrinting(CDC*, CPrintInfo*) : void OnDraw(CDC*) : void OnEndPrinting(CDC*, CPrintInfo*) : void OnPreparePrinting(CPrintInfo*) : BOOL PreCreateWindow(CREATESTRUCT&) : BOOL

[그림 5-7] 노트패드 프로그램의 클래스 다이어그램

102


제5장 다이어그램-Structural

3.1

CHAPTER 5

3

컴포넌트 다이어그램

컴포넌트 다이어그램(Class Diagram)이란?

컴포넌트 다이어그램은 시스템 내부에 어떠한 컴포넌트가 존재하는지를 알리고, 컴포 넌트 간의 관계를 나타내는 다이어그램이다. Class Diagram

[그림 5-8] 컴포넌트 다이어그램

[그림 5-8]에서 컴포넌트 하나와 인터페이스 둘을 볼 수 있다. 여기서 ‘Order’가 컴 포넌트이며, ‘OrderEntry’는 ‘컴포넌트가 제공하는 오퍼레이션’을 알리는 인터페이 스—실체화 관계로 연결되어 있기 때문에—이고, ‘Person’은 ‘Order 컴포넌트가 사용 하는 인터페이스’—의존 관계로 연결되어 있기 때문에—이다.

[그림 5-9]은 컴포넌트들이 서로서로 의존하고 있는 관계를 다이어그램으로 나타낸 것이다.

103


UML기반 분석/설계

[그림 5-9] 컴포넌트 의존 관계를 나타내는 다이어그램

[그림 5-10]는 컴포넌트를 또 다른 형태로 표현한 다이어그램이다.

ItemAllocation <<realize>>

<<component>> Order

Tracking <<realize>>

Person

Invoice

OrderableItem [그림 5-10] 제공 인터페이스와 요구 인터페이스가 표현된 컴포넌트 다이어그램

Order 컴포넌트가 제공하는 오퍼레이션을 알리는 인터페이스는 ItemAllocation과 Tracking이며, 반원으로 표시된 Person과 Invoice 및 OrderableItem은 Order 컴포 넌트에서 사용하는 인터페이스이다. 이렇게 컴포넌트가 제공하는 인터페이스는 원으로 표시하며, 컴포넌트가 사용하는 인터페이스는 반원으로 표시한다.

[그림 5-11]는 컴포넌트를 클래스 형식으로 표현한 것이다.

104


제5장 다이어그램-Structural

CHAPTER 5

<<component>> Order <<provided interface>> Billing: OrderEntry: <<required interface>> Invoice:

[그림 5-11] 클래스 형식으로 표현한 컴포넌트

컴포넌트에서 구현하여 제공할 오퍼레이션과 컴포넌트에서 사용할 오퍼레이션을 ‘클래 스의 오퍼레이션’ 형식으로 표현하고 있다.

[그림 5-12]은 컴포넌트 내부 클래스를 함께 표현한 다이어그램이다. <<component>> Order Order::OrderHeader OrderEntry

+order +item

*

1

Person

Order::LineItem

[그림 5-12] 내부를 표현한 컴포넌트 다이어그램

Order 컴포넌트 내부에 OrderHeader 클래스와 LineItem클래스가 존재하며, 그들이 서로 Composite Aggregation 관계로 연결됨을 나타내고 있다.

105


UML기반 분석/설계

[그림 5-13]은 컴포넌트 내부에 또 다른 컴포넌트가 표현된 사례이다.

Store <<delegate>> OrderEntry OrderEntry

<<component>> :Order

Person

<<component>> :Customer <<delegate>>

OrderableItem

Account

<<component>> :Product

Account

[그림 5-13] 컴포넌트 내부에 컴포넌트를 포함하는 컴포넌트 다이어그램

‘Store 컴포넌트’ 내부에 Order 컴포넌트와 Customer 컴포넌트 및 Product 컴포넌트 가 있음을 나타낸다. 각 컴포넌트에서 제공하는 오퍼레이션을 인터페이스로 알리고 있 음을 볼 수 있다. 또한, Store 컴포넌트가 ‘외부에 제공하는 인터페이스(OrderEntry)’ 와 ‘사용할 필요가 있는 인터페이스(Account)’로도 표현되어 있다.

3.2

컴포넌트 다이어그램 구성요소

3.2.1 컴포넌트(Component)

[그림 5-14]와 같이 ‘스테레오 타입이 있는 클래스 타입’으로 표시하거나, 아이콘 형 태로 나타낸다.

[그림 5-14] 컴포넌트

106


제5장 다이어그램-Structural

컴포넌트가 제공하는 오퍼레이션을 알리는 역할을 한다. 이러한 인터페이스를 컴포넌 트가 실체화하고 있다. [그림 5-15]와 같이 작은 동그라미를 컴포넌트와 연결하여 표 현한다.

OrderEntry

<<component>> :Order

[그림 5-15] 제공 인터페이스

3.2.3 요구 인터페이스(Required Interface)

컴포넌트가 의존하고 있는 인터페이스를 나타내기 위해 사용한다. [그림 5-16]처럼 반원을 사용하여 표현한다.

[그림 5-16] 요구 인터페이스

107

CHAPTER 5

3.2.2 제공 인터페이스(Provided Interface)


UML기반 분석/설계

3.2.4 포트(Port)

컴포넌트 외곽에 작은 사각형으로 표현하며, ‘제공 인터페이스(Provided Interface)’나 ‘요구 인터페이스(Required Interface)’를 표현할 수 있다.

[그림 5-17] 포트

3.2.5 조립 커넥터(Assembly Connector)

[그림 5-82]과 같이 ‘볼 소켓(Ball and Socket)’ 형태로 표시하며, ‘제공 인터페이스 (Provided Interface)’와 ‘요구 인터페이스(Required Interface)’의 연결을 의미한다.

[그림 5-18] 조립 커넥터

108


제5장 다이어그램-Structural

CHAPTER 5

4

디플로이먼트 다이어그램

Deployment Diagram

디플로이먼트 다이어그램(Deployment Diagram)이란?

4.1

디플로이먼트 다이어그램은 전체 시스템을 구성하는 하드웨어와 하드웨어의 연결 관 계를 표현하는 다이어그램이다. 그리고 각 하드웨어와 하드웨어에 배치되는 아티팩트 (시스템에 존재하는 소스 코드, 산출물과 같이 물리적으로 존재하는 정보)를 표현한다. AppServer

DBServer *

<<deploy>> <<artifac t>> Order.jar

1

<<deploy>> <<artifac t>> RequestHandler.jar

[그림 5-19] 디플로이먼트 다이어그램

[그림 5-19]에서 육면체로 표현된 기호는 하드웨어를 의미하며, 사각형 기호는 아티 팩트이다. AppServer1 <<artifact>> ShoppingCart.jar

<<artifact>> Order.jar

[그림 5-20] 노드 내부에 아티팩트를 표현한 다이어그램

109


UML기반 분석/설계

[그림 5-20]는 노드 내부에 아티팩트를 표현한 다이어그램이다.

디플로이먼트 다이어그램은 시스템의 실행 아키텍처(Execution Architecture)를 표현 한다. 실행 아키텍처는 노드(Node)에 아티팩트(Artifacts)를 어떻게 배치하는지를 나 타낸다. 배치란 아티팩트를 노드에 할당함을 의미한다.

디플로이먼트 다이어그램은 하드웨어 사양과 하드웨어 연결 관계를 표현한다.

4.2

디플로이먼트 다이어그램 구성 요소

4.2.1 노드(node)

『 UML User’s Guide 』에는 ‘노드란 실행 시간에 존재하고 컴퓨터 자원(Computing Resource)을 나타내는 물리적인 요소이다. 일반적으로 노드는 컴포넌트가 배치되는 컴퓨터나 장치를 의미한다”라고 정의되어 있다. 노드는 물리적인 요소이며, 시스템이 실행될 때 존재하며 어느 정도의 메모리와 처리 능력을 갖춘 전산 자원이다.

AppServer1

[그림 5-21] 노드

노드는 [그림 5-21]처럼 육면체로 표현한다.

110


제5장 다이어그램-Structural

아티팩트는 물리적인 형태의 모든 정보를 의미한다. 즉 모델 파일, 소스 코드, 산출물, 실행 파일 등등이 아티팩트이다. 아티팩트는 [그림 5-22]처럼 “<<artifact>>’라는 스 테레오 타입으로 표현한다.

<<artifact>> ShoppingCart.jar

[그림 5-22] 아티펙트

4.2.3) 연관 관계

연관 관계를 의미한다. 디플로이먼트 다이어그램에서 연관 관계는 물리적인 연결을 의 미한다.

[그림 5-23] 연관 관계

4.2.4 의존 관계

의존하고 있는 관계를 의미한다. 디플로이먼트 다이어그램에서 의존 관계는 아티팩트 와 아티팩트가 배치되는 노드 사이를 나타내기 위해 사용한다.

[그림 5-24] 의존 관계

111

CHAPTER 5

4.2.2 아티팩트(Artifact)


UML기반 분석/설계

5 5.1

컴포지트 스트럭처 다이어그램

컴포지트 스트럭처 다이어그램(Composite Structure Diagram)

컴포지트 스트럭처 다이어그램은 이름에서 알 수 있듯이, 복합 구조를 표현하는 다이 어그램이다. Composite Structure Diagram

Stock

BookStock:Book

barcode

records:Computer

[그림 5-25] 컴포지트 스트럭처 다이어그램 – 프로퍼티

[그림 5-25]는 Stock 클래스의 프로퍼티를 컴포지트 스트럭처 다이어그램으로 표현 한 것이다. 다이어그램에서 Stock클래스 내부에 Book타입의 BookStock 파트와 Computer타입의 records 파트가 있음과 Book클래스와 Computer클래스가 관계를 갖고 있음을 알 수 있다.

[그림 5-25]를 커넥터(Connector)를 이용하여 표현한 다이어그램은 [그림 5-26]과 같다.

112


제5장 다이어그램-Structural

CHAPTER 5

Stock

records

BookStock

Books

Computer

barCode

[그림 5-26] 컴포지트 스트럭처 다이어그램2

컴포지트 스트럭처 다이어그램은 콜래버레이션의 사용처도 표현할 수 있다. BrokeredSale

Broker

buyer <<role binding>> seller

<<role binding>> seller

WholeSale: Sale

<<role binding>>

Publisher Retail: Sale

buyer <<role binding>>

Consumer

[그림 5-27] BrokeredSale 컴포지트 스트럭처 다이어그램

113


UML기반 분석/설계

[그림 5-27]는 콜래버레이션이 표현된 컴포지트 스트럭처 다이어그램이다. 내부에 콜 래버레이션의 사례와 객체를 볼 수 있다.

5.2

컴포지트 스트럭처 다이어그램 구성요소

5.2.1 파트(Part)

파트는 클래스나 인터페이스의 실행 사례(Runtime Instance)라고 할 수 있다. 조립품 내부에 어떠한 부품이 있는지를 나타내기 위해 컴포지트 스트럭처 다이어그램 을 사용할 수 있다. 이렇듯 조립품 내부를 표현할 때, 내부에 존재할 수 있는 부품이 바로 파트가 된다. [그림 5-28]처럼 ‘파트이름 : 클래스이름’과 같이 표현한다.

BookStock:Book

[그림 5-28] 파트

5.2.2 프로퍼티(Property)

프로퍼티는 클래스나 인터페이스의 내부 구조를 의미한다.

114


제5장 다이어그램-Structural

CHAPTER 5

[그림 5-29] 프로퍼티

[그림 5-29]에서 libBooks와 records는 파트(Part)이며, 두 파트가 barcode라는 관 계로 연결되어 있음을 볼 수 있다. 이러한 두 파트와 관계를 합한 것이 Library 클래 스의 프로퍼티이다.

프로퍼티를 보유하는 클래스에 속하지 않는 파트는 [그림 5-29]처럼 점선으로 표현 한다.

[그림 5-29] 프로퍼티

115


UML기반 분석/설계

5.2.3 콜래버레이션(Collaboration)

콜래버레이션은 ‘역할(Role)과 연결(Connector)의 집합’이다. 콜래버레이션은 [그림 5-30]와 같이 타원으로 표현한다.

[그림 5-30] 콜래버레이션

콜래버레이션은 특정한 기능을 수행하기 위해 필요한 속성과 역할만을 지정해야 한다.

[그림 5-31] 콜래버레이션 다이어그램

[그림 5-31]은 install이라는 콜래버레이션을 나타내고 있는 콜래버레이션 다이어그램 이다.

116


제5장 다이어그램-Structural

콜레버레이션유즈는 콜래버레이션의 사용사례를 의미하며, [그림 5-32]처럼 나타낸다.

[그림 5-32] 콜레버레이션유즈

[그림 5-33] 콜래버레이션유즈의 사례

[그림 5-33]는 ‘Sale’이라는 콜래버레이션의 사례인 ‘BrokeredSale’을 나타낸다. 그림에서 ‘BrokeredSale’이 콜래버레이션유즈가 되는 것이다.

117

CHAPTER 5

5.2.4 콜래버레이션유즈(CollaborationUse)


UML기반 분석/설계

6 6.1

패키지 다이어그램

패키지 다이어그램(Package Diagram)

Package Diagram 패키지 다이어그램은 패키지들과 패키지 내부의 요소를 표현하는 다이어그램이다.

[그림 5-34] 패키지 다이어그램

[그림 5-34]에서 사각형과 사각형 왼쪽 위에 직사각형으로 표현된 기호가 패키지이 다. 패키지 다이어그램은 <<import>>와 <<merge>> 관계를 통해, 패키지에서 다른 패키 지 내부의 요소를 사용하는 관계를 나타낸다.

118


제5장 다이어그램-Structural

CHAPTER 5

6.2

패키지 다이어그램 구성 요소

6.2.1 패키지(Package)

패키지는 ‘내부에 다른 요소를 포함하는 요소’이며 네임스페이스(Namespace)의 역할 도 수행하는 요소이다. 즉, 패키지 내부에 다른 요소를 넣을 수 있으므로, 여러 클래 스를 하나의 패키지 내부의 요소로 표현할 수 있다. 그리고 네임스페이스의 역할도 수 행하므로, 패키지 내부의 클래스를 패키지 이름과 함께 지칭할 수 있다. 예를 들어 [그림 5-34]에서 ‘GenApply’ 패키지 내부의 Loader 클래스를 지칭할 때에는 ‘GenApply::Loader’와 같은 형태로 표현한다.

패키지는 [그림 5-35]와 같이 좌측 상단에 작은 사각형 기호가 있는 사각형 기호를 사용하여 표현한다. 패키지를 나타내는 이러한 기호를 ‘탭(Tab)이 달린 폴더’라 한다. myPackage

[그림 5-35] 패키지

패키지는 [그림 5-36]처럼 세가지로 표현할 수 있다.

[그림 5-36] 패키지 세가지 표현방법

119


UML기반 분석/설계

첫 번째는 패키지 이름만 표현하는 방식이며, 두 번째는 패키지 내부를 함께 나타내는 타입이다. 마지막 세 번째는 ‘○’기호를 사용하여 패키지 내부 중 일부를 함께 나타내 는 방식이다.

패키지는 또 다른 패키지의 요소가 될 수도 있다. 패키지 내부에 또 다른 패키지가 있 을 수 있는 것이다.

패키지를 이용하면, 요소를 네임스페이스로 표현할 수 있다. 이렇게 패키지를 이용하여 요소를 표현할 경우엔 다음과 같은 표기법을 사용한다.

패키지이름::패키지이름::요소이름

예를 들어, analysis 패키지의 Member라는 클래스를 패키지 네임스페이스를 이용하 여 나타내면, ‘analysis::Member’라고 나타내게 된다. 이렇듯 패키지와 패키지 내부 요소는 ‘::’로 구분하여 표현한다.

6.2.2 패키지 임포트 관계(PackageImport 관계)

패키지임포트 관계는 다른 패키지의 요소를 자신의 요소처럼 사용하는 관계이다. 패키지 임포트 관계는 [그림 5-37]처럼 ‘점선과 화살표’로 표현한다.

[그림 5-37] 패키지 임포트 관계

120


제5장 다이어그램-Structural

면,

ShoppingCart

패키지와

Auxiliary

Types는

서로

‘<<import>>’

‘<<access>>’로 연결되어 있음을 볼 수 있다. 이렇게 패키지 임포트 관계로 연결되어 있기 때문에 ShoppingCart에서 ‘Types’와 ‘Auxiliary’ 패키지 내부를 참조할 수 있다. 그러나, WebShop에서는 Types 패키지 내부는 접근할 수 있으나, Auxiliary 내부는 접근할 수 없다. 왜냐하면 Auxiliary와 ShoppingCart는 ‘<<access>>’로 연결되어 있 기 때문이다. 그래서, ShoppingCart 패키지에서는 Auxiliary를 접근할 수 있으나, WebShop에서는 Auxiliary를 접근할 수 없다. 하지만, WebShop에서 Auxiliary 패키 지이름과 함께 사용할 경우에는 Auxiliary 내부 요소를 접근할 수 있다.

6.2.3 패키지 머지 관계(PackageMerge 관계)

패키지 머지 관계는 패키지를 병합하여 새로운 패키지를 구성하는 관계이다. 패키지 머지 관계는 [그림 5-38]처럼 스테레오 타입을 이용하여 ‘<<merge>>’라고 표현한다.

[그림 5-38] 패키지 머지 관계

패키지 머지 관계는 두 개 이상의 패키지 내부의 멤버들을 합쳐서 새로운 패키지를 구성할 때 사용한다.

121

CHAPTER 5

패키지 임포트 관계는 ‘import’와 ‘access’, 두 가지 타입이 있다. [그림 5-37]을 보


UML기반 분석/설계

[그림 5-39] 패키지 머지 관계 설명

[그림 5-39]에서 패키지 A와 패키지 B가 ‘패키지 머지’ 관계로 연결되어 있음을 볼 수 있다. 이것은 패키지 A와 패키지 B가 합쳐져서 새로운 패키지가 생성되는 것이다.

122


제5장 다이어그램-Structural

7.1

CHAPTER 5

7

다이어그램 실습

컴포넌트 다이어그램 실습

웹에서 주사위 게임을 할 수 있는 시스템에서 시스템을 구성하는 컴포넌트들을 다이 어그램을 이용하여 표현하여 본다.

웹페이지 파일은 Crap.html이며, 애플릿 소스코드는 Crap.java, 애플릿의 컴파일된 바 이트코드파일은 Crap.class이다. Die(주사위)클래스의 소스코드는 Die.java이며, 이것의 컴파일된 바이트소스코드는 Die.class이다. 이 다섯개의 파일은 모두 같은 디렉토리에 들어있으며 디렉토리의 이름은 crapshoot 이다. Crap.html은 Crap.class와 Die.class에 의존하여 작동한다. 각각의 .class파일은 컴포넌트이며 클래스를 구현하는 것이다. Crap.java는

애플릿이기에

java.applet패키지의

Applet을

상속받아야

하며

ActionListener 인터페이스를 구현하여야 한다.

7.2

디플로이먼트 다이어그램 실습

교육장의 PC 환경을 디플로이먼트 다이어그램으로 표현해 본다.

교육장의 PC의 하드웨어를 체크하여 다음과 같은 작업에 필요한 하드웨어들을 다이

123


UML기반 분석/설계

어그램에 표현해 본다. • 멀티미디어작업 • 인터넷접속 • 모니터나 마우스와 키보드 등의 I/O관련 하드웨어 • OS나 웹브라우저들은 컴포넌트로 표현한다.

하드웨어의 종류와 메이커나 모델명 등을 표현하여 본다. 교육장PC의 사용환경은 “설정/제어판/시스템/하드웨어/장치관리자”에서 참조할 수 있 다.

124


Chapter

06

다이어그램-Behavioral

1 절 유스케이스 다이어그램 2 절 시퀀스 다이어그램 3 절 커뮤니케이션 다이어그램 4 절 인터렉션 오버뷰 다이어그램 5 절 타이밍 다이어그램 6 절 액티비티 다이어그램 7 절 스테이트머신 다이어그램 8 절 다이어그램 실습

학습목표 Φ UML의 다이어그램 중에서 동적인 다이어그램 여섯 가지를 학습한다.


6장에서는 UML의 동적인 다이어그램들을 학습한다. UML에서 동적인 다이어그램은 다음과 같이 일곱 가지가 있다. •

유스케이스 다이어그램(Usecase Diagram)

시퀀스 다이어그램(Sequence Diagram)

커뮤니케이션 다이어그램(Communication Diagram)

인터렉션 오버뷰 다이어그램(Interaction Overview Diagram)

타이밍 다이어그램(Timing Diagram)

액티비티 다이어그램(Activity Diagram)

스테이트 머신 다이어그램(Statemachine Diagram)


제6장 다이어그램-Behavioral

1.1

CHAPTER 6

1

유스케이스 다이어그램

유스케이스 다이어그램(UseCase Diagram)이란?

유스케이스 다이어그램은 시스템이 제공하는 기능과 시스템을 사용하는 사용자(또는 타 시스템)를 표현하는 다이어그램이다. UseCase Diagram

Use Case3 <<extend>> Use Case1 <<extend>>

Actor1

Use Case4

<<inc lude>>

Use Case2

<<inc lude>>

Use Case5

Actor2

Use Case6

Use Case7

[그림 6-1] 유스케이스 다이어그램

[그림 6-1]에서 타원으로 표현되어 있는 기호를 ‘유스케이스’라 하는데, 유스케이스는 시스템의 기능을 의미한다. 막대인간(Stick Man)으로 표현된 심벌을 액터(Actor)라고 하며, 액터는 시스템의 사용자를 나타낸다. 이렇듯 유스케이스 다이어그램은 시스템 내부에 어떠한 액터가 있으며, 그것이 시스템 의 어떤 기능을 사용하는지를 나타낸다.

127


UML기반 분석/설계

이러한 유스케이스 다이어그램은 시스템의 요건을 명시하기 위해 사용한다. 개발 주기 초기에 주로 사용자의 기능적 요구사항을 기술하는 데 사용한다.

유스케이스 다이어그램 작성시 사용자의 관점에서 작성하는 것이 필요하다. 시스템 개 발 초기에 사용자가 원하는 기능을 제대로 도출해 내고, 개발 기간 내내 불충분한 요 구사항으로 인한 변경 작업을 줄이기 위해서도 그렇게 해야 한다.

1.2

유스케이스 다이어그램 구성요소

유스케이스 다이어그램과 관련된 주요 개념에는 유스케이스, 액터, 그리고 관계(연관, 포함, 확장, 일반화)가 있다.

1.2.1 액터(Actor)

액터는 시스템과 상호작용하는 사용자 또는 타 시스템을 의미한다. 액터의 이름은 대체로 시스템을 사용하는 사용자의 역할로 표현한다. 여러 역할을 수 행하는 사용자는 여러 액터로 표현될 수 있다. 동일한 역할을 수행하는 사용자는 하나 의 액터로 표현한다.

예를 들어 게시판 시스템에서 게시자와 조회자, 그리고 관리자 등이 게시판 시스템의 사용자로서 액터가 되는 것이다. 그리고 게시판 시스템이 다른 시스템과 상호작용한다 면, 그 시스템도 게시판 시스템의 액터로 표현해야 한다. 그러나 DBMS와 같이 데이터 입·출력 용도로 다른 시스템과 상호작용할 경우에는 액 터로 표현하지 않는다.

이러한 액터는 다음과 같은 기호로 표현한다.

128


제6장 다이어그램-Behavioral

CHAPTER 6

게시자 [그림 6-2] 액터(Actor)

[그림 6-2]는 표준 아이콘으로 표현한 것이며, ‘<<Actor>>’라는 이름의 표준 스테레 오타입으로 표현하면 다음과 같다.

<<Actor>>

게시자

[그림 6-3] 표준 스테레오 타입으로 표현한 액터

참고로 액터는 시스템 바운더리에 포함되지 않는다. 따라서 시스템 구축 대상이 아니 다.

1.2.2 유스케이스(UseCase)

유스케이스는 시스템의 기능을 의미하며, 다음과 같이 타원으로 나타낸다.

객실예약 [그림 6-4] 유스케이스

유스케이스의 이름은 ‘목적어+행위’ 형태로 표기한다. 이렇게 이름 뒷부분에 행위를 의미하는 단어로 표현하는 이유는 유스케이스가 시스템의 기능을 의미함을 분명하게 나타내는 것이 바람직하기 때문이다.

129


UML기반 분석/설계

유스케이스는 일련의 작업을 의미하기에 작은 단위로 생성하지 않아야 한다. 다음과 같은 경우를 생각해 보자.

[그림 6-5] 유스케이스를 잘못 도출한 사례

[그림 6-5]의 경우에는 너무 작은 단위로 유스케이스를 생성한 경우이다. 유스케이스 가 작은 단위로 도출되었는지 잘 되었는지를 판단하려면 그 유스케이스가 왜 필요한 지를 생각해 보면 된다.

[그림 6-5] 에서 ‘객실선택’이란 기능이 왜 필요한지를 반문해 보면 ‘객실을 예약하기 위함’이란 것을 생각할 수 있다. 따라서 [그림 6-5]의 경우에 ‘객실선택’, ‘객실 예약 수량 입력’, ‘예약일 선택’, ‘투숙자 정보 입력’ 등은 ‘객실 예약’이라는 유스케이스 내 부의 한 절차에 불과하므로 유스케이스로는 적절치 않음을 알 수 있다. 그해서 모두 삭제하고 ‘객실 예약’이라는 유스케이스로 통합하여 표현한다.

130


제6장 다이어그램-Behavioral

유스케이스 다이어그램에서 연관 관계는 유스케이스와 액터 사이에만 표현될 수 있다. 유스케이스와 유스케이스 간에는 부여될 수 없는 관계이다.

연관 관계는 [그림 6-6]와 같이 ‘실선의 화살표’로 표현한다

사용자관리 관리자 [그림 6-6] 연관 관계

연관 관계는 액터가 유스케이스를 사용하거나, 유스케이스와 상호 작용함을 의미한다.

1.2.4 포함 관계(Include Relationship)

포함 관계는 유스케이스와 유스케이스 간에 있을 수 있으며, 반드시 포함되어 함께 수 행되는 기능을 의미한다. 포함 관계는 의존 관계를 의미하는 ‘점선의 화살표’ 기호와 ‘<<include>>’라는 스테레 오 타입으로 표현한다.

[그림 6-7] 유스케이스의 포함 관계

131

CHAPTER 6

1.2.3 연관 관계(Association Relationship)


UML기반 분석/설계

[그림 6-7]에서 ‘카드확인’이라는 유스케이스는 ‘인출’이라는 유스케이스에 반드시 포 함되어 수행됨을 의미한다.

1.2.5 확장 관계(Extend Relationship)

확장 관계는 조건에 따라 기능이 수행될 수도 있음을 의미한다.

[그림 6-8] 유스케이스의 확장 관계

[그림 6-8]에서 ‘ATM트랜잭션 수행’이라는 유스케이스는 ‘헬프 선택’이라는 확장 포 인트를 가지고 있으며, 사용자가 ‘ATM 트랜잭션 수행’이라는 유스케이스를 사용하는 도중에 헬프를 선택하면 ‘온라인 헬프’라는 유스케이스의 절차가 실행된다.

이렇듯 확장 관계는 반드시 확장되는 관계가 아니라 조건에 따라 확장될 수 있는 관 계를 의미한다.

1.2.6 일반화 관계(Generalization Relationship)

일반화 관계는 유스케이스와 유스케이스 간 및 액터와 액터 간에 있을 수 있다. 이렇게 일반화 관계로 설정된 경우에는 일반화의 의미처럼 상위의 기능을 하위에서 모두 상속받아 사용할 수 있고, 하위 나름대로 기능을 더 추가하여 사용할 수 있음을 의미한다.

[그림 6-1]은 보면, Actor2가 Actor1을 상속받고 있음을 볼 수 있다. 이것은 Actor2 가 Actor1이 사용할 수 있는 기능인 ‘UseCase1’을 사용할 수 있을 뿐만 아니라,

132


제6장 다이어그램-Behavioral

유스케이스와 유스케이스 간에도 일반화 관계가 설정될 수 있는데, 개념적으로 성격이 유사한 유스케이스들의 상위 유스케이스를 표현한 것이다.

1.2.7 유스케이스 다이어그램의 사례

[그림 6-9]는 계약 관리 시스템의 유스케이스 다이어그램이다.

[그림 6-9] 계약 관리 시스템의 유스케이스 다이어그램

다음 [그림 6-10]은 사용자 관리 시스템의 유스케이스 다이어그램이다.

133

CHAPTER 6

‘UseCase2’도 사용할 수 있음을 의미한다.


UML기반 분석/설계

[그림 6-10] 사용자 관리 시스템의 유스케이스 다이어그램

1.2.8 유스케이스 정의서(UserCase specification)

‘유스케이스 정의서’란 유스케이스의 절차를 기술한 것이다. 말하자면 각 유스케이스 의 상세한 절차 수행 과정을 기술한 문서이며, 모든 유스케이스에 대해 작성하는 것은 아니지만, 대부분의 유스케이스에 대해 작성해야 한다.

유스케이스 정의서 내에 기술하는 ‘상세 절차 흐름’은 다음과 같이 주요 흐름(Main Flow), 분기 흐름(Alternative Flow), 예외 흐름(Exception Flow)이 있다.

134


제6장 다이어그램-Behavioral

CHAPTER 6

[그림 6-11] 유스케이스 정의서에 기술하는 세 가지 흐름

‘Main Flow’는 유스케이스 절차의 주요 흐름이며, ‘Alternative Flow’는 대체 흐름이 나 분기 흐름을 의미하며, ‘Exception Flow’는 예외 흐름이다.

유스케이스 정의서는 방법론과 조직에 따라 명칭과 포맷이 다를 수 있다. [그림 6-12]은 본 과정에서 제시하는 유스케이스 정의서의 포맷이다.

135


UML기반 분석/설계

[그림 6-12] 유스케이스 정의서 포맷

유스케이스 정의서 내부의 항목은 다음과 같다.

136


제6장 다이어그램-Behavioral

CHAPTER 6

λ 유스케이스 명 : 관련된 유스케이스 이름을 기술한다. λ 유스케이스 ID : 유스케이스의 ID를 기술한다. λ 개요 : 유스케이스의 목적과 간략한 개요를 기술한다. λ Relationships •

Initiators : 참여 액터를 기술한다.

PreCondition : 선행 조건을 기술한다.

PostCondition : 완료 조건을 기술한다.

λ Flows of Events •

Basic Flow : 기본 흐름을 기술한다.

Alternatives Flows : 대체 흐름을 기술한다.

Exceptions Flows : 예외 흐름을 기술한다.

λ Special Requirements : 특별한 요건이 있다면 기술한다. λ Extension Points : 확장 점을 기술한다. λ Note : 노트를 기술한다. λ 시나리오 : 필요하다면 시나리오를 기술한다.

유스케이스가 흐름을 갖지 않을 때에는 유스케이스 정의서를 생략할 수 있다. 예를 들 어 일반화로 추상화된 유스케이스의 경우에는 유스케이스의 설명 항목에 간략히 절차 를 기술하고, 상세한 절차는 기술하지 않아도 된다.

137


UML기반 분석/설계

2 2.1

시퀀스 다이어그램

시퀀스 다이어그램(Sequence Diagram)이란?

시퀀스 다이어그램은 인터랙션 다이어그램의 가장 일반적인 형태이며, 객체 간에 송· 수신하는 메시지를 시간의 흐름에 따라 나열한 다이어그램이다. Sequence Diagram sd

P55

Frame

[그림 6-13] 시퀀스 다이어그램

[그림 6-13]에서 ‘classA’와 ‘classB’는 클래스의 이름이며, ‘obj1’과 ‘obj2’는 객체의 이름이다. 그리고 수평으로 표현되어 있는 화살표를 메시지라고 한다.

138


제6장 다이어그램-Behavioral

하는 메시지를 표현하는 용도로 사용한다.

2.2

시퀀스 다이어그램 요소

시퀀스 다이어그램에는 인터렉션, 객체, 생명선, 메시지, 제어 초점, ref, 인터렉션 연 산자 등이 있다.

2.2.1 인터랙션(Interaction)

인터랙션은 ‘특정 목적을 달성하기 위한 행위로서 메시지의 집합’이다. 예를 들어, 유 스케이스를 시퀀스 다이어그램으로 표현했을 때, 그 시퀀스 다이어그램에 표현된 메시 지의 집합이 인터랙션이 된다. 말하자면 ‘특정 목적’이 유스케이스가 되며, ‘메시지의 집합’이 시퀀스 다이어그램에 표시된 메시지들이 되는 것이며 메시지의 집합이 인터렉 션이다. 이러한 인터랙션은 다음 [그림 6-14]와 같이 표현한다.

[그림 6-14] 인터랙션

사각형 틀을 만들고, 사각형 틀 왼쪽 상단에 인터랙션 정보를 기술한다. 인터랙션 정 보를 기술하는 왼쪽 상단에는 ‘sd’라는 키워드와 인터랙션의 행위를 나타내는 단어를 기술한다.

139

CHAPTER 6

이러한 시퀀스 다이어그램은 유스케이스의 흐름(절차) 속에서 객체들이 서로 송·수신


UML기반 분석/설계

2.2.2 객체(Object)

시퀀스 다이어그램에 참여하는 객체를 의미하며, 다음과 같이 표현한다.

객체 명 : 클래스 명

객체 명이나 클래스 명 둘 중 하나는 생략할 수 있다.

2.2.3 생명선(Lifeline)

생명선은 객체가 살아 있는 정도를 나타내며, 해당 객체 아래에 수직 점선으로 표현한 다. 객체가 소멸됨을 표현할 때에는 ‘x’ 표시를 한다.

[그림 6-15] 생명선

2.2.4 메시지(Message)

객체 사이에 송·수신하는 메시지이다. 메시지가 발생하는 순서에 따라 위에서 아래로 표현한다. 화살표의 형태로 동기화 종류를 나타낸다.

140


제6장 다이어그램-Behavioral

CHAPTER 6

동기 메시지

비 동기 메시지

응답 메시지

[그림 6-16] 메시지의 종류

2.2.5 제어 초점(focus of Control)

제어 초점은 객체가 활성화된 상태를 의미한다. 제어 초점은 수직으로 좁다란 사각형 으로 표현한다.

[그림 6-17] 제어 초점

141


UML기반 분석/설계

2.2.6 ref(Reference)

ref는 인터렉션에서 다른 인터렉션을 참조함을 의미한다.

[그림 6-18] ref

인터랙션의 일부를 다른 인터랙션에서 참조할 경우에 ref를 사용한다. 이렇게 ref를 활용하면 인터랙션을 공유할 수 있다.

2.2.7 인터랙션 연산자(Interaction Operator)

이전 버전의 시퀀스 다이어그램은 반복, 조건 선택, 병행 처리 등을 표현할 수 없었다. 그리고 주로 시스템 개발 초기에 오퍼레이션을 찾기 위한 방법으로 사용했었다.

시퀀스 다이어그램은 UML 2.0에서 반복, 조건 선택, 병행 처리를 표현할 수 있도록 변경되었다. 이러한 반복이나 조건 선택을 인터랙션 연산자(Interaction Operator)로 표현한다.

142


제6장 다이어그램-Behavioral

CHAPTER 6

예를 들어 조건의 경우 다음과 같이 표현한다.

alt

[그림 6-19] 연산자 alt

alt라는 연산자가 사용된 예는 다음과 같다.

[그림 6-20] 연산자 alt 사용 사례

그림에서 alt라고 표기된 곳이 바로 인터랙션 연산자를 사용한 부분이다. x값이 0보다 클 경우와 그렇지 않을 경우를 alt라는 인터랙션 연산자를 사용하여 표

143


UML기반 분석/설계

기하고 있다.

이러한 인터랙션 연산자에는 다음과 같은 것들이 있다. • Alt

: Alternative이며 조건에 따른 선택이 다수인 경우에 사용한다.

• opt

: Optional이며, 조건에 따른 선택이 하나인 경우에 사용한다.

• break

: 프로그래밍 언어에서 break문처럼 반복을 벗어날 경우 사용한다.

• loop

: 일정한 횟수나 조건에 따른 반복을 나타낼 때 사용한다.

• par

: parallel이며 병렬로 수행해도 됨을 의미한다.

• seq

: sequence이며 메시지 전달 순서가 엄격하지 않은 경우 사용한다.

• strict

: 메시지 전달 순서가 엄격하게 적용되어야 하는 곳에 사용한다.

• neg

: negative이며 절대 발생해서는 안 될 상황을 표현할 때 사용한다.

• critical

: 여러 병행 작업이 존재할 때 우선적으로 처리해야 하는 부분에 사

용한다. • ignore

: 특정 메시지를 무시해도 되거나 무시하고자 할 때 사용한다.

• consider

: 특정 메시지를 중요하게 고려해야 할 때 사용한다.

인터랙션 연산자에서 몇 가지 예를 보자. 다음은 병렬 처리와 우선 처리를 표현한 사례이다.

144


제6장 다이어그램-Behavioral

CHAPTER 6

[그림 6-21] 연산자 par과 critical

[그림 6-21]을 살펴보자. 전화 교환원(Operator)은 발신자의 전화를 처리할 때, ‘par’로 표현되어 있기 때문에 100번을 요청하는 전화와 101번을 요청하는 전화를 병렬로 처리한다. 그러나 발신자 가 911로 전화했을 때에는 ‘critical’로 표현된 인터렉션이므로 다른 요청과 병렬로 처 리하지 않고 우선적으로 처리한다.

145


UML기반 분석/설계

2.2.8 사례

[그림 6-22] 시퀀스 다이어그램 사례

[그림 6-22]는 급여 관리 시스템에서 계약 조회 기능 수행 과정을 표현하는 시퀀스 다이어그램이다.

146


제6장 다이어그램-Behavioral

3.1

CHAPTER 6

3

커뮤니케이션 다이어그램

커뮤니케이션 다이어그램(Communication Diagram)이란?

:L

1: print()

2: write()

b1 :B

2.1: print()

b2 :B

[그림 6-23] 커뮤니케이션 다이어그램

커뮤니케이션 다이어그램은 이전 버전의 콜래버레이션 다이어그램이며, 구성요소 간의 관계와 요소 간에 주고받는 메시지를 표현한 다이어그램이다. 메시지의 순서는 알 수 없기 때문에 메시지 순서를 나타내려면 메시지 전송 순서를 알 수 있도록 숫자를 이 용하여 표현해야 한다. Communication Diagram

147


UML기반 분석/설계

3.2

커뮤니케이션 다이어그램(State Chart Diagram)의 구성요소

커뮤니케이션 다이어그램의 구성 요소에는 객체, 관계, 메시지 등이 있다.

3.2.1 객체(Object)

객체는 커뮤니케이션에 참여하는 요소이며, 사각형 기호로 표현한다.

b2 :B

[그림 6-24] 객체

3.2.2 메시지(Message)

객체 간에 송·수신하는 메시지이다. 메시지가 발생하는 순서에 따라 위에서 아래로 표 현한다. 화살표의 형태로 동기화 종류를 나타낸다.

148


제6장 다이어그램-Behavioral

CHAPTER 6

동기 메시지

비 동기 메시지

응답 메시지 [그림 6-25] 메시지 종류

149


UML기반 분석/설계

3.2.3 사례 6: 예약등록 1: 예약가능조회

:Actor1

<<boundary>> ReservationUI

10: 예약확인

<<entity>> Room

5: 예약가능정보 2: getReservationAvail() 7: registerReservation()

4: getAvailRoom()

<<control>> ReservationControl

8: registerReservation()

<<entity>> Reservation

3: getReservationAvail()

9: registerCustomerInfo()

<<entity>> Customer

[그림 6-26] 호텔 예약 시스템의 호텔 예약 기능 커뮤니케이션 다이어그램

[그림 6-26]은 호텔 예약 시스템의 호텔 예약 기능에 대한 커뮤니케이션 다이어그램 이다.

150


제6장 다이어그램-Behavioral

4.1

CHAPTER 6

4

인터랙션 오버뷰 다이어그램

인터랙션 오버뷰 다이어그램(Interaction Overview Diagram)

인터랙션 오버뷰 다이어그램은 인터랙션들의 흐름을 나타내는 다이어그램이다. Interaction Overview Diagram

[그림 6- 27] 인터랙션 오버뷰 다이어그램

151


UML기반 분석/설계

[그림 6-27]에서 동그라미와 다이아몬드, 그리고 화살표 기호는 각각 시작과 조건 및 전이를 의미하는데, 이러한 기호들은 액티비티 다이어그램에 존재한다. 이렇듯, 인터랙션 오버뷰 다이어그램 내부의 기호 중에서는 액티비티 다이어그램에 존 재하는 것들이 상당수 있으며, 따라서 인터랙션 오버뷰 다이어그램은 액티비티 다이어 그램의 변종이라고 할 수 있다.

4.2

인터랙션 오버뷰 다이어그램의 요소

인터랙션 오버뷰 다이어그램 내부에 등장하는 기호 중에서 액티비티 다이어그램과 중 ���되는 것들은 액티비티 다이어그램을 참조하기를 바란다.

4.2.1 프레임(Frame)

다이어그램을 둘러싼 전체 사각형 프레임을 의미하며, 다음과 같이 표현한다.

[그림 6-28] 프레임

4.2.2 인터랙션(Interaction)

인터렉션은 ‘특정 목적을 달성하기 위한 행위로서 메시지의 집합’이다. 이러한 인터랙션은 다음과 같이 표현한다.

152


제6장 다이어그램-Behavioral

CHAPTER 6

[그림 6-29] 인터랙션

4.2.3 인터랙션 참조(ref)

ref는 인터랙션에서 다른 인터랙션을 참조할 수 있게 한다. 인터랙션의 일부를 다른 인터랙션에서 참조하고자 할 경우가 더러 있다. 이럴 때 ref 를 사용하여 인터랙션을 공유한다.

[그림 6-30] 인터랙션 참조

153


UML기반 분석/설계

5

타이밍 다이어그램

타이밍 다이어그램(Timing Diagram)이란?

5.1

타이밍 다이어그램은 시간의 흐름에 따른 상태를 나타낸다. 가로 축에 시간을 표현하 고 세로 축에 상태를 나타내어 시간이 지나감에 따른 상태 변화를 표현하는 다이어그 램이다. Timing Diagram

td Timing Diagram

event

Switch

on off

event

Switch

off

0

on

off

event

event

5

10

15

[그림 6-31] 타이밍 다이어그램

154

20

25

30


제6장 다이어그램-Behavioral

CHAPTER 6

5.2

타이밍 다이어그램 요소

타이밍 다이어그램에 등장하는 요소는 프레임, 생명선(Lifeline), 상태, 메시지, 이벤트 등이 있다.

5.2.1 프레임(Frame)

다이어그램을 둘러싼 전체 사각형 프레임을 의미하며, 다음과 같이 표현한다.

td EventOccurance

[그림 6-33] 프레임

5.2.2 메시지(Message)

객체 간에 송·수신하는 메시지이다. 메시지가 발생하는 순서에 따라 위에서 아래로 표 현한다.

5.2.3 메시지 레이블(Message Label)

메시지 레이블은 메시지를 레이블로 나타낼 경우에 사용한다. 타이밍 다이어그램에서 메시지들이 많이 있으면 어떤 화살표가 어떤 메시지에 대한 것인지를 파악하기 어렵다. 이럴 경우 메시지 레이블을 사용한다.

155


UML기반 분석/설계

[그림 6-34] 메시지 레이블

5.2.4 상태(State)

객체나 속성, 또는 조건에 대한 상태를 의미한다.

[그림 6-35] 상태

5.2.5 요소 값(General Value)

상태에 적용된 값을 나타낸다. 값을 문자로 표시하며, ‘꺾임표시(Crossing)’로 ‘값을 변경하게 만드는 이벤트’를 나타낸다.

[그림 6-36] 요소 값

156


제6장 다이어그램-Behavioral

CHAPTER 6

5.2.6 생명선(Lifeline)

생명선은 다이어그램에 참여하는 요소를 의미한다.

[그림 6-37] 생명선

5.2.7 사례

[그림 6-38]은 전화기의 ‘시간의 흐름에 따른 상태 변화’를 모델링 한 것이다.

[그림 6-38] 타이밍 다이어그램 사례

157


UML기반 분석/설계

6 6.1

액티비티 다이어그램

액티비티 다이어그램(Activity Diagram)이란?

액티비티 다이어그램은 시스템의 동적인 관점을 표현하는 다이어그램이다. Activity Diagram od Business Process Model

Actor1

s:State

Actor2

Do C

Do A Ac tivityFinal

Actor3

Ac tivityInitial

[a=1]

Do B

[그림 6-39] 액티비티 다이어그램

158


제6장 다이어그램-Behavioral

역할이 ‘Do A’라는 업무를 수행하고 나서, ‘Actor1’ 역할이 ‘Do C’를 수행하며, 그리 고 ‘Actor3’이라는 역할이 ‘Do B’를 수행한다. 그런데, ‘Do C’와 ‘Do B’는 포크(Fork) 로 표현되어 있기 때문에 순서 없이 수행해도 된다. 그리고,

‘Do B’는 ‘의사결정’으로

표현되어 있으므로 조건에 따라 수행하기도 하고 수행하지 않기도 한다.

6.2

액티비티 다이어그램의 대상

Activity Diagram은 시스템의 동적인 측면을 모델링하는 것으로, 대체로 전체 시스템 이나 서브 시스템을 대상으로 생성하지만, 함수나 클래스를 대상으로 사용할 수도 있 다. 그리고 유스케이스를 대상으로 작성할 수도 있다.

액티비티 다이어그램은 대체로 다음과 같은 두 가지 방법으로 이용한다.

6.2.1 업무 흐름 모델링

시스템을 사용하는 액터 관점에서 활동에 초점을 둔다. 시스템에 있는 업무 공정을 가 시화, 명세화하는 용도로 사용하며, 이런 용도로 사용할 경우에는 객체 흐름(Object Flow)을 표현하는 것이 필요하다.

6.2.2 자료 흐름 모델링

DFD처럼 사용하여 자료 흐름을 모델링한다. 이런 용도로 사용할 경우에는 프로세스 를 액션으로 표현하고, 자료 흐름을 객체 흐름(Object Flow)으로 표현한다.

159

CHAPTER 6

[그림 6-39]는 역할별 업무를 액티비티 다이어그램으로 표현한 것이다. ‘Actor2’라는


UML기반 분석/설계

6.3

액티비티 다이어그램의 구성요소

6.3.1 액션(Action)

액션은 더 이상 분해되지 않는 작업을 의미한다. [그림 6-40]처럼 모서리가 둥근 사 각형을 사용하여 표현한다.

Do A

[그림 6-40] 액션

업무 흐름을 모델링 할 경우에는 액션은 액터의 업무가 될 것이며, 클래스 내부를 모 델링 할 경우에는 액션은 오퍼레이션이 될 것이다.

6.3.2 액티비티(Activity)

액티비티는 또 다른 액티비티나 액션으로 분해될 수 있는 작업을 의미한다. 액티비티 를 표현하는 기호는 액션과 동일하다.

Do C

[그림 6-41] 액티비티

액티비티는 또 다른 액티비티 다이어그램으로 상세화될 수도 있다.

160


제6장 다이어그램-Behavioral

CHAPTER 6

6.3.3 액티비티파티션(ActivityPartition)

Actor3

액티비티 다이어그램에서 액티비티나 액션을 수행하는 주체의 구역을 의미한다.

[그림 6-42] 액티비티파티션

6.3.4 시작 점(Initial Node)

액티비티나 액션의 시작을 의미한다.

[그림 6-43] 시작 점

시작점은 [그림 6-43]처럼 까만 점으로 표현한다. 액티비티 다이어그램은 하나의 시 작점을 갖는다.

6.3.5 종료 점(ActivityFinal)

액티비티의 종료를 의미한다. 여러 종료 점을 가질 수도 있다.

161


UML기반 분석/설계

[그림 6-44] 종료 점

6.3.6 의사결정(Decision Node)

조건에 따라 여러 가지 흐름 중 하나로 분기됨을 의미한다.

[그림 6-45] 의사결정

[그림 6-45]처럼 다이아몬드 형상의 기호를 사용하여 표현한다. 분기된 흐름에는 조 건을 표시한다.

6.3.7 포크(ForkNode)와 조인(JoinNode)

동시에 진행이 가능한 작업이나, 순서를 지키지 않아도 되는 작업을 표현할 때 사용한 다. <그림 6-46>처럼 얇은 막대로 표현한다.

[그림 6-46] 동기화

6.3.8 제어흐름 종료 점(FlowFinal)

해당 제어 흐름의 종료를 의미한다. 다음과 같은 기호를 사용한다.

162


제6장 다이어그램-Behavioral

CHAPTER 6

[그림 6-47] 제어 흐름 종료 점

6.3.9 사례

[no more components to be installed] install component Build component FlowFinal

[more components to be built]

[no more components to be buit]

deliver Application [more components to be installed]

FlowFinal

[그림 6-48] 컴포넌트 빌드와 배포에 대한 액티비티 다이어그램

[그림 6-48]을 이해해 보자. 포크(fork)로 표현되어 있기에 ‘Install Component’와 또 다른 컴포넌트에 대한 ‘Build Component’ 작업을 병행한다. 의사결정(Decision Node)으로 표현되어 있기에 ‘More components to be built’ 조건 이 충족되면 ‘Build Component’ 작업을 수행하고 ‘No more components to be built’ 조건이 충족되면 해당 제어 흐름을 종료한다.

[그림 6-49]는 고객의 주문을 접수하여 처리하는 과정을 액티비티 다이어그램으로 표현한 것이다.

163


UML기반 분석/설계

주문 처리 부서

경리 부서

고객

주문접수

주문처리 송장

주문선적

송장송부

지불처리

대금지불

주문처리 종료

[그림 6-49] 고객 주문 처리 액티비티 다이어그램

[그림 6-50]는 급여지급 절차를 나타내는 액티비티 다이어그램이다. 참고로 [그림 6-50]은 이전 버전 표기로 작성된 다이어그램이다.

164


제6장 다이어그램-Behavioral

CHAPTER 6

[그림 6-50] 급여 지급 절차 액티비티 다이어그램

[그림 6-50]에서 급여 지급 파일은 ‘급여 지금 파일 생성’ 액션을 통해 생성된 다큐 먼트이다.

165


UML기반 분석/설계

7 7.1

스테이트머신 다이어그램

스테이트머신 다이어그램(StateMachine Diagram)에 대해

스테이트머신 다이어그램(StateMachine Diagram)은 클래스나 전체 시스템을 대상으 로 하여, ‘이벤트에 따른 객체의 상태 변화’를 나타내는 다이어그램이다. 스테이트머신 다이어그램에는 상태와 전이 그리고 이벤트 등이 표현되며, 상태가 전이 되기 위한 이벤트, 조건, 액션도 표현된다. verifyCard Initial

readAmount outOfService

Initial

selectAmount

Final

verifyTransaction

[그림 6-51] 스테이트머신 다이어그램

166

releaseCard


제6장 다이어그램-Behavioral

CHAPTER 6

7.2

상태 다이어그램 구성요소

7.2.1 시작 상태(Initial Pseudo State)

상태 다이어그램의 시작 상태를 의미한다. 다음과 같이 속이 채워져 있는 동그라미를 사용하여 표현한다.

[그림 6-52] 시작 상태

7.2.2 종료 상태(Final State)

상태 다이어그램의 종료를 의미한다. 다음과 같이 내부에 까만 점이 있는 동그라미로 표현한다.

[그림 6-53] 종료 상태

7.2.3 상태(State)

객체나 시스템이 가질 수 있는 상태를 의미한다. 네 귀퉁이가 둥근 사각형을 사용하여 표현한다.

[그림 6-54] 상태

167


UML기반 분석/설계

7.2.4 복합 상태(Composite State)

내부에 여러 상태를 포함하는 복합적인 상태이다.

[그림 6-55] 복합 상태

7.2.5 선택 의사(擬似) 상태(choice pseudo state)

의사 상태(pseudo state)라는 것은 상태는 아니지만 상태처럼 사용하는 요소를 의미 한다. 선택 의사 상태는 액티비티의 ‘의사결정’처럼 선택 지점을 의미한다.

[그림 6-56] 선택 의사 상태

7.2.6 전이(Transition)

상태가 다른 상태로 전환되는 것을 의미한다. 다음과 같이 화살표로 표현한다.

168


제6장 다이어그램-Behavioral

condition), 활동(Action)을 표현할 수 있다.

[그림 6-57] 전이

7.2.7 하위 스테이트머신(Submachine State)

하위 스테이트머신은 스테이트머신의 하위로 존재하는 스테이트머신이다.

[그림 6-58] 하위 상태

<그림 6-59>는 하위 스테이트머신의 사례이다.

[그림 6-59] ‘ReadAmountSM’ 하위 스테이트머신 다이어그램

169

CHAPTER 6

전이를 표현하는 화살표 위에 전이가 일어날 수 있는 이벤트(Event), 조건(Guard


UML기반 분석/설계

[그림 6-60] ‘ATM’ 스테이트 머신 다이어그램

7.2.8 분할(fork)과 합류(join)

상태의 전이가 여러 흐름으로 분할(Fork)되거나 여러 흐름이 합류(Join)됨을 의미한다. [그림 6-61]처럼 굵은 선을 사용하여 표현한다.

[그림 6-61] 분할과 합류 사례

7.2.9 진입 점(Entry Point)

진입 점은 스테이트머신이나 복합 상태로 진입함을 의미한다. 작은 동그라미를 스테이 트머신이나 복합상태 경계선에 두어서 표현한다.

170


제6장 다이어그램-Behavioral

CHAPTER 6

[그림 6-62] 진입 점

다음은 진입 점과 탈출 점의 사례이다.

[그림 6-63] 진입점과 탈출점

7.2.10 탈출 점(Exit Point)

스테이트 머신이나 복합 상태를 벗어남을 의미한다. 다음과 같이 작은 동그라미 속에 ‘X’ 표시를 넣어서 표현한다.

[그림 6-64] 탈출 점

7.2.11 사례

171


UML기반 분석/설계

[그림 6-65]은 주문이라는 클래스가 객체화되어 가질 수 있는 상태를 간략히 모델링 한 사례이다.

[그림 6-65] 주문 클래스의 스테이트머신 다이어그램

172


제6장 다이어그램-Behavioral

8.1

CHAPTER 6

8

다이어그램 실습

스테이트머신 다이어그램 실습(냉난방기)

어느 건물의 냉난방기의 상태를 다이어그램으로 표현해 본다.

가동조건은 다음과 같다. •

현재의 실내온도가 정해진 온도보다 높으면 쿨링을 시작한다.

냉방기가 가동되면, 컴프레셔를 기동하여 준비시키고 팬을 구동하여 냉방을 시 작한다.

실내온도가 정해진 온도보다 낮으면 히팅을 시작한다.

난방기는 히터를 구동시키고 난방기가 구동을 멈출 때엔 히터를 가동 중지 한 다.

냉난방기가 구동 중에 문제가 발생할 경우엔 로그를 남겨야 하며 로그를 남긴 후엔 휴지상태로 전환되어야 한다.

냉방상태는 복합상태로 표시해 본다.

8.2

스테이트머신 다이어그램 실습(엘리베이터)

어느 건물의 엘리베이터의 운행조건을 스테이트머신 다이어그램으로 표현해 본다.

173


UML기반 분석/설계

엘리베이터의 운행조건은 다음과 같다. 다음의 상황을 스테이트머신 다이어그램을 통 해 표현해본다. •

저녁11시 이후와 오전 6시 이전에는 운행을 중지하며 1층으로 복귀한다.

엘리베이터가 어느 층에 있든지 운행이 되지 않은 시간이 20초가 지나면 1층으 로 복귀한다.

문이 열린 후 5초가 지나면 자동으로 문이 닫히게 된다.

탑승자나 탑승을 원하는 자의 요청이 있는 층으로 운행(Move up or Move down)한다.

상태가 전이되기 위한 조건을 표현한다.

8.3

액티비티 다이어그램 실습(컨설팅 업무)

컨설팅회사에서 고객에게 제안서를 제출하는 과정을 액티비티 다이어그램으로 표현하 여본다. 고객에게 제안서를 제출하는 프로세스는 다음과 같다.

영업사원이 고객과 약속을 잡는다.

약속장소가 컨설팅회사 내부이면 회사 내 전문가가 프리젠테이션을 준비하고 컨퍼런스 룸을 준비한다.

약속장소가 컨설팅회사외부이면 컨설턴트가 자신의 노트북을 이용하여 프리젠 테이션을 준비한다.

영업사원이 컨설턴트와 협의하여 고객과 만날 시간과 장소를 정한다.

영업사원이 고객에게 서신을 발송한다.

미팅 후 문제점이 정리되면 컨설턴트는 제안서를 작성하여 고객에게 발송한다.

컨설턴트와 사내 전문가는 동일인이 아니며, 처음의 ‘영업사원이 고객과 약속을 잡는

174


제6장 다이어그램-Behavioral

은 공문을 발송하기 위해 정확한 장소와 시간을 결정하는 일이 된다.

8.4

액티비티 다이어그램 실습(커피메이커)

사무실에서 음료수를 찾아서 마시는 과정까지를 액티비티 다이어그램으로 표현해본다. 일단, 커피를 마시려 하며, 커피가 없을 경우 콜라를 마시려 한다. 다음은 과정을 설 명한 것이다.

일단, 커피메이커가 있는지를 살펴본다. 커피메이커가 없으면, 콜라가 있는지를 보고 콜라가 있으면, 컵을 찾아서 컵에 부어서 마신다.

커피메이커가 있으면 커피메이커에 마실 커피가 남아 있는지를 살펴본다. 만일 커피가 남아 있다면 컵을 찾아서 커피를 부어 마신다.

만일, 커피가 만들어져 있지 않으면, 커피필터에 커피를 넣고 필터를 커피메이 커에 장착하고, 저수조에 물을 부어 넣은 후, 커피를 끓인다. 그리고, 컵을 찾아 서 컵에 부어 마신다.

공통으로 해도 될 일—커피쪽과 콜라를 마시는 절차에서—과 병렬로 해도 될 일을 찾 아서 표현해 본다.

175

CHAPTER 6

일’은 개략적으로 약속을 정하는 과정이고, 그 다음의 ‘만날 시간과 장소를 정하는 일’


Chapter

07

확장메커니즘과 프로파일

1 절 스테레오 타입 2 절 제약조건 3 절 프로파일

학습목표 Φ UML의 확장 메커니즘 중에서 스테레오 타입과 제약조건을 학습한다. Φ UML의 프로파일을 살펴본다.


UML 명세에 있는 확장 메커니즘을 사용하면, 통제된 방법으로 UML을 확장할 수 있다. 7장에서는 확장 메커니즘 중에서 스테레오 타입과 제약 조건을 학습한 다. 또한 7장에서는 프로파일을 학습할 예정인데, 프로파일은 UML 요소를 확장하여 패키지로 묶어서 정의한 것이다.


제7장 확장메커니즘과 프로파일

1.1

CHAPTER 7

1

스테레오 타입

스테레오 타입(Stereo Type)

스테레오 타입이라는 것은 UML 요소에 ‘《 》’표시를 붙여서 사용하는 것을 의미한 다. 다음의 [그림 7-1]을 보자.

<<entity>> Company

<<entity>> Person

+hire()

+getSalary()

[그림7-1] 스테레오 타입

[그림 7-1]에서 ‘《entity》’로 표현된 부분이 바로 스테레오 타입이다. 참고로 ‘《 》’기호는 길러멧(guillemet)이라 하며, 프랑스 사람 기욤이 만들었고 프랑 스어와 러시아어에서 인용부호로 사용된다고 한다.

스테레오 타입은 UML의미를 확장하여 새로운 종류의 구성 요소를 생성할 수 있게 한 다. [그림 7-1]의 스테레오 타입은 클래스에 적용된 것으로써, Company 클래스와 Person클래스가 ‘엔티티라는 타입의 클래스임’을 알리고 있는 것이다. 이렇듯, 스테레 오 타입을 클래스에 적용하면, 클래스의 목적과 특성을 새로 생성할 수 있게 된다.

스테레오 타입은 문자열로 표시할 수도 있으며, 아이콘이나 이미지로도 표현할 수 있다.

177


UML기반 분석/설계

1.2

스테레오 타입을 아이콘으로 표시하기

스테레오 타입에는 UML에 이미 정의되어서 널리 사용되고 있는 것들도 있다. 그 중에서 ‘《boundary》’, ‘《entity》’,’《control》’은 이미 널리 사용되고 있으며, 아이콘표시도 다음과 같은 형상으로 정해져 있다.

MainView

ListView

MainCtrl

DocumentEty

DetailView [그림7-2] Boundary, Control, Entity 스테레오 타입

[그림 7-1]를 [그림 7-2]에 따라 아이콘으로 표현한 다이어그램은 다음과 같다.

178


제7장 확장메커니즘과 프로파일

CHAPTER 7

Company

Person

+hire()

+getSalary()

[그림 7-3] [그림 7-1]을 아이콘으로 표현한 다이어그램

스테레오 타입이 사용된 또 다른 예를 보자.

Home

Remote

<<instantiate>>

Hello <<EJBRemoteMethod>> + gree()

HelloHome <<EJBCreateMethod>> + create()

<<EJBRealizeRemote>>

<<EJBRealizeHome>> S

HelloEJB <<EJBRemoteMethod>> + gree() + HelloEJB() <<EJBCreateMethod>> + ejbCreate() + ejbRemove() + ejbActivate() + ejbPassivate() + setSessionContext()

[그림 7-4] HelloEJB의 클래스 다이어그램

[그림 7-4]는 클래스 다이어그램이다. 클래스 다이어그램 내부에서Hello 클래스와 HelloHome, 그리고 HelloEJB라는 이름의 클래스를 볼 수 있으며, 각 클래스 내에 여 러 오퍼레이션들이 정의되어 있음을 알 수 있다. 그런데, 오퍼레이션의 이름 앞에 ‘《 》’기호로 표현되어 있는 것들을 볼 수 있으며, 바로 이렇게 ‘《 》’기호를 이용하여 나타낸 것이 스테레오 타입이다. 이렇게 스테레 오 타입은 클래스뿐만 아니라 여러 요소에 사용할 수 있다.

179


UML기반 분석/설계

1.3

스테레오 타입 정의하기

스테레오 타입을 정의하여 사용할 수 있다. [그림 7-5]는 ‘StopWatch’라 하는 컴포넌트를 나타내고 있는데, 컴포넌트 상단에 ‘<<Clock>>’이라는 스테레오 타입을 볼 수 있다.

[그림 7-5] StopWatch 컴포넌트

[그림 7-5]에 사용된 ‘Clock’이라는 스테레오 타입은 다음과 같이 정의될 수 있다.

[그림 7-6] Clock 스테레오 타입

[그림 7-6]에서 Clock은 컴포넌트를 확장한 스테레오 타입임을 알 수 있다.

180


제7장 확장메커니즘과 프로파일

2.1

CHAPTER 7

2

제약 조건(Constraint)

제약 조건(Constraint)에 대해

제약 조건(Constraint)이란 UML 요소에 지정된 조건이나 제약을 의미한다. 제약 조건 은 [그림 7-7]와 같이 ‘{ }’ (중괄호(brace)) 내부에 문자를 두어 표현한다.

Stack -

size: Integer

constraints {size>=0}

[그림 7-7] 제약 조건

[그림 7-7]는 클래스 내부의 어트리뷰트에 부여한 제약 조건이다. size라는 이름의 어 트리뷰트는 Integer타입이며 ‘0보다는 커야한다’는 제약 조건이 있음을 알 수 있다.

이렇게 부여된 제약 조건은 시스템을 개발할 때 충족되어야 한다.

2.2

제약 조건을 노트로 표기하기

제약 조건은 노트 내부에 문자로 표현하고 조건이 부여될 요소와 점선으로 연결하여

181


UML기반 분석/설계

나타내기도 한다.

+boss 0..1 Person

+employee

+employer

*

Company

0..1

{self.employer=self.boss.employer}

[그림 7-8] 노트로 표현된 제약 조건

2.3

‘{xor}’ 제약 조건

UML에 이미 존재하는 제약 조건이 있으며 그 중에 하나가 {xor}이다.

Person

Account

{xor}

Corporation

[그림 7-9] xor 제약 조건

‘{xor}’는 원래의 xor가 둘 중 하나가 참일 때 참인 것처럼, 둘 중 하나와 관계를 가 짐을 의미하는 제약 조건이다.

182


제7장 확장메커니즘과 프로파일

3.1

CHAPTER 7

3

프로파일(Profile)

프로파일(Profile)에 대해

프로파일은 UML을 확장하여 사용하는 방법 중 하나이며, [그림 7-10]처럼 패키지 기호로 표현한다. Profile

<<profile>> EJB

[그림 7-10] 프로파일 표기법

프로파일은 UML을 확장하여 사용하는 방법 중 하나이다. UML 버전1.1에서는 스테레오 타입과 태그 값을 이용하여 문자열 기반으로 확장 메커 니즘을 사용하였지만, 그 이후 버전에서는 프로파일 메커니즘이 도입되어서 좀 더 정 확하고 좀 더 구조적으로 확장할 수 있게 되었다.

특정 플랫폼(J2EE 또는 닷넷 등등)이나 특정 도메인(리얼 타임 시스템이나 비즈니스 프로세스 모델링 등등) 환경의 시스템을 UML로 표현할 때 프로파일을 사용하면 좀 더 이해하기가 쉬워진다. [그림 7-11]를 보자.

183


UML기반 분석/설계

[그림 7-11] EJB 프로파일

[그림 7-11]는 EJB프로파일이다. 패키지 기호와 스테레오 타입을 이용하여 EJB라는 프로파일을 나타낸 것이다. EJB는 자바 플랫폼인 J2EE(Java 2 Enterprise Edition)의 요소 기술 중 하나이며, 나름대로의 구조적 메커니즘을 갖는다.

그림에서 ‘Bean’이라는 것은 ‘Bean이란 스테레오 타입’을 정의한 것이다. 그리고, Bean은

‘Component’와

‘{required}’로

연결되어

있음을

있다.

이렇게

‘{required}’로 연결되어 있기 때문에, ‘Bean’의 하위 인 Entity나 Session의 인스턴 스가 ‘component’ 인스턴스와 연결되어야 한다. 그리고, ‘Bean’은 Entity와 Session 의 상위이기에 때문에 이탤릭체로 표현되어 있다.

이렇게 패키지 내부에 여러 요소들을 표현한 것이 프로파일이다. [그림 7-11]는 프로파일을 이용하여 EJB라는 요소 기술의 내부 구조를 표현한 것이 다.

[그림 7-11]에서 ‘실선의 속이 채워져 있는 화살표’로 되어 있는 생소한 기호를 볼

184


제7장 확장메커니즘과 프로파일

장은 프로파일 내부에서 사용하는 개념이다.

이렇게, 프로파일은 패키지와 스테레오 타입 및 메타모델 요소, 그리고 확장이라는 관 계로 표현한다.

3.2

프로파일의 확장 관계(Extension Relationship)

확장 관계는 일종의 연관 관계(Association Relationship)이며, [그림 7-12]와 같이 표현한다. 프로파일의 확장 관계(Extension Relationship)

[그림 7-12] 프로파일의 확장 관계

[그림 7-13] 확장 관계의 사례

[그림 7-13]에서, ‘Home’은 ‘Interface’를 확장한 스테레오 타입임을 알리고 있는 것 이다. 그러니까, ‘Home’은 일종의 인터페이스이며 스테레오 타입으로 사용할 수 있는 것이다.

185

CHAPTER 7

수 있는데, 이다. ‘실선의 속이 채워져 있는 화살표’를 확장(Extension)이라 한다. 확


Chapter

08

CBD

1 절 컴포넌트 개요 2 절 CBD 정의와 특징 3 절 CBD 프로세스 4 절 UML 모델링 적용 방법

학습목표 Φ CBD에서 말하는 컴포넌트가 무엇인지 학습한다. Φ CBD가 무엇이며, CBD의 특징이 무엇인지 학습한다. Φ CBD 방법론 및 프로세스에 대해 학습한다. Φ CBD상에서 수행하는 UML 모델링에 대해 학습한다. Φ UML을 CBD에 적용하는 방법에 대해 학습한다.


CBD(Component-Based Development)는 소프트웨어 개발 기술 만의 변화가 아닌 소프트웨어 산업 및 시장 전반에 걸친 구조적 변화이다. 이미 CBD는 우리가 생각하는 것보다 빠르게 소프트웨어 산업 전반에 스며들고 있다. 또한, CBD 기술 자체도 앞으로 상당 기간 계속 변화하 고 진화할 것이다. UML은 CBD를 수행하기 위해 훌륭한 도구로써의 역할을 수행한다. CBD 프로세스 상의 다양한 활동에 따른 작업들은 UML 모델링을 통해 서 수월하게 진행될 수 있다. 이 장에서는 CBD에 대한 이해와 고찰을 통해, 다음 장에서부터 본격적 으로 다룰 UML 적용 기법과 CBD의 각각의 모델링에 대한 이해를 돕 는다. 또한, CBD를 수행하는 과정에서 필요한 UML 적용 기법이 무엇 인지 개략적으로 소개한다.


제8장 CBD

CHAPTER 8

1

컴포넌트 개요

CBD를 설명하기 전에, 컴포넌트에 대해 짚고 넘어가야 하는 것이 인지상정이다. 컴포 넌트는 소프트웨어를 구성하는 독립적인 단위 기능 모듈이라고 볼 수 있다. 다음은 컴 포넌트에 대한 다양한 정의이다. •

독립적으로 실행 가능하며 표준 인터페이스를 갖추고 소프트웨어의 대체 가능 성, 재사용성, 기능적 독립성을 갖춘 소프트웨어 집합이다.

소프트웨어 컴포넌트란 하나 이상의 기능을 갖는 독립적인 소프트웨어이며, 조 립을 통해 응용 프로그램을 작성할 수 있는 부품 형태의 소프트웨어를 말한다. 미리 작성되어 있는 소프트웨어의 조립을 통해 새로운 응용 프로그램을 작성할 것이라는 생각에서 시작되었다.

소프트웨어 컴포넌트란 정의된 컨텍스트(Context)와 계약된 상세 인터페이스를 통한 조합만이 가능한 단위를 말한다. 소프트웨어 컴포넌트는 서드파티(Third Party)들이 조합의 목적으로 독립적으로 배포할 수 있다.

컴포넌트란 소프트웨어 시스템에서 함수, 모듈, 클래스 같이 재사용 가능하고 구별할 수 있는 일부분이다.

특정한 기능을 수행하기 위해 독립적으로 개발되고, 잘 정의된 인터페이스를 가 지며, 다른 부품과 조립되어 시스템을 구축하기 위해 사용되는 소프트웨어 부품 (단위)이다.

컴포넌트는 다음과 같은 특징이 있다. •

컴포넌트는 재사용(Reuse)할 수 있어야 한다. 이때 컴포넌트의 크기가 함께 고

189


UML기반 분석/설계

민되어야 하는데, 컴포넌트의 크기가 작아질수록 재사용될 가능성이 높아지지만 재사용으로 얻어지는 이익은 감소한다. 반대로, 컴포넌트의 크기가 커질수록 재 사용될 가능성은 낮아지지만 재사용으로 얻어지는 이익은 커진다. •

컴포넌트는 기능 독립적(Independent)이다. 이를 위해 다음의 두 가지를 만족 시켜야 한다. − 컴포넌트는 결합도(coupling)가 낮아야 한다. 즉, 다른 컴포넌트에 적게 의존 해야 한다. − 컴포넌트는 응집도(cohesion)가 높아야 한다. 즉, 하나의 컴포넌트를 구성하 고 있는 구성요소들 간에는 밀접한 연관성이 있어야 한다.

컴포넌트는 식별(Identification)이 가능해야 한다. 컴포넌트들은 다른 컴포넌트 와 명확히 구분이 가능해야 한다.

컴포넌트들은 상세한 기능들을 수행 또는 기술한다. 즉, 컴포넌트들은 명확하고 상세한 기능들을 이행 및 기술해야 한다.

컴포넌트들은 명확한 인터페이스들(Interfaces)을 가지고 있어야 하며, 재사용 을 위해서는 내부를 숨기고 있어야 한다. 컴포넌트 인터페이스는 재사용 방법과, 다른 컴포넌트와 연결 여부를 정의하고 있다. 인터페이스는 컴포넌트가 가능한 동작 또는 동작의 집합을 정의하고 있다. 대부분의 프로그래밍 언어는 명확한 컴포넌트 인터페이스의 문서를 요구하며, 클래스와 모듈은 명확하게 분리된 인 터페이스와 구현으로 구성되어 있다.

컴포넌트 인터페이스에 대한 명세(Specification)는 재사용을 위해서 필수적이 다. 대부분의 좋은 컴포넌트들은 적당한 명세화 내지 문서화되어 있어 재사용에 적합하다.

컴포넌트들은

재사용을

제공하도록

유지되어야

한다.

재사용

상태(Reuse

Status)는 컴포넌트의 주인, 유지보수의 권한, 보안, 컴포넌트의 품질 등의 정보 를 가지고 있어야 한다. •

컴포넌트는 조합(Assemble)이 가능하다. 컴포넌트는 기본적으로 제3자가 조립 할 수 있도록 설계되어야 한다.

190

컴포넌트는 설정(Configurable)이 가능하다. 조립하는 사람 및 최종 사용자가


제8장 CBD

컴포넌트는 주변에 의존도(Dependency)가 적어야 한다. 독립적으로 수행 가능 한 단위여야 하고, 의존성 부분은 명확히 표현되어야 한다. UML 2.0에서부터는 컴포넌트의 의존성을 표현할 수 있도록, 컴포넌트에 요구되는 인터페이스 (Required Interface)라는 것을 명시할 수 있다.

컴포넌트는 쉽게 배포될 수 있어야 한다.

컴포넌트는 쉽게 대체될 수 있어야 한다.

개발할 컴포넌트가 앞의 모든 특징을 모두 다 가지고 있어야 하는 것은 아니다. 컴포 넌트 설계 시에 필요한 특징을 잘 선별하여 컴포넌트를 식별하고 찾아내는 것이 중요 하다.

위에서 살펴보았던 컴포넌트 개념이나 특징을 살펴보면, 낯익은 용어들을 많이 접할 수 있을 것이다. 왜냐하면, 컴포넌트라는 것은 기존의 객체지향 기술이 진화한 형태이 기 때문이다. 그러나 이처럼 컴포넌트가 객체지향 기술 분야의 용어를 자주 빌려 쓴다 곤 하지만, 컴포넌트와 객체지향이 결코 같은 것은 아니다.

현재 널리 적용되는 컴포넌트 개발 기술로는 J2EE의 EJB와 COM+ 기술을 이용 한 .NET의 ServicedComponent가 존재한다. 그렇다고 해서 꼭 J2EE나 .NET 에서만 컴포넌트를 개발할 수 있는 것은 아니다. 기존 메인 프레임에서 사용하는 COBOL의 루틴도 컴포넌트의 정의와 여러 특징들을 잘 적용한다면, 충분히 컴포넌트라고 말할 수 있다.

다음 [그림 8-1]은 업무 지원 형태에 따라 컴포넌트 유형을 분류해 본 것이다.

191

CHAPTER 8

설정할 수 있도록 한다.


UML기반 분석/설계

[그림 8-1] 업무 지원 형태에 따른 컴포넌트 유형

192


제8장 CBD

CHAPTER 8

2

CBD 정의와 특징

CBD(Component-Based Development)는 소프트웨어를 개발하는 과정에서, 독립적인 업무 또는 기능을 수행하는 소프트웨어 모듈인 컴포넌트를 조립하여 완제품을 만드는 방식이다. CBD는 한때의 유행이 아닌 장기간에 걸쳐 발전된 소프트웨어 산업의 한 진 화 형태이고, 전혀 새로운 것이 아니다.

1970년대부터 작게는 컴퓨터 프로그램의 코딩, 크게는 SW 시스템의 구축에 대한 방 법론이 정립되어 왔고 구조적 분석, 설계 및 프로그래밍 방법론에서 강조되던 것이 모 듈화(Modularization)이며 복잡한 프로그램이나 시스템은 Divide & Conquer, 즉 Top-Down Decomposition에 따라 분석, 설계, 구현되어야 한다는 것이었다. 그 후 1980년대에는 객체지향적 분석, 설계 및 프로그래밍이 주장되었고 정보시스템 구축 방법론의 주류를 이루었던 정보공학(Information Engineering)이 등장했다. 1990년 후 반에는 구조적 및 객체지향적 방법론과 정보공학에서 강조하는 모든 개념을 그대로 이어받아 오늘의 CBD가 탄생되었다.

CBD 전부터 해 왔던 모듈화 프로그래밍은 큰 맥락에서 보면 CBD에서 추구하고자 하 는 가치 명제와 같다. 큰 시스템을 관리하기 편한 조각으로 나누고, 함께 사용되는 서 비스 별로 인터페이스를 명확히 갖는 모듈로 구현한다. 그리고 각각의 조각에 대해 정 의된 형식으로 명세하거나 별도의 문서로 정확히 나타내어, 소프트웨어 빌딩 블록으로 포장할 수 있다. 개발자들은 이 빌딩 블록을 조립하여 새로운 어플리케이션을 개발할 수 있다. 이와 같은 모듈화 개념은 분명 새로운 것은 아니지만, CBD에서는 이 모듈화 이점을 대규모로 확장할 수 있게 했다.

193


UML기반 분석/설계

컴포넌트는 자신의 내부의 구현을 숨기고 자신이 제공하고자 하는 서비스를 인터페이 스를 통해 외부에 노출시킨다. 이는 바로 객체지향의 캡슐화(Encapsulation) 개념과 같은 것이고, 이 캡슐화 개념을 극대화한 것이 바로 CBD에서 컴포넌트가 추구하는 바이며, CBD의 근본을 이루는 개념이다. 컴포넌트는 Black-Box라고 하여, 실제 컴포 넌트 내부에서 동작하는 객체에 대해 접근을 불허한다. 이에 따라, 컴포넌트에 접근하 여 기능을 사용할 수 있는 방법은 오로지 정의된 인터페이스를 통하는 것뿐이다. 객체 지향에서는 모든 객체에 직접 접근할 수 있는 것에 반해 사뭇 다른 점이다. 그리고 이 폐쇄 경계(Closed Boundary) 개념은 CBD가 객체지향 기술과는 다른 길을 가도록 하 는 결정적인 이유이다.

컴포넌트의 조립을 통한 시스템이나 소프트웨어의 구축이 가능하도록 지원하는 컴포 넌트 기반 소프트웨어 개발은 높은 재사용성과 유지보수성 등의 다양한 장점을 제공 한다. 이에 따른 CBD의 특징을 살펴보면 다음과 같다. •

개발된 시스템을 재사용 가능하게 한다.

시스템을 독립적으로 서비스할 수 있는 의미 있는 컴포넌트 단위로 나누어 개 발했기 때문에, 각각의 컴포넌트들은 다른 시스템에서 재사용할 수 있으며, 반 대로 시스템 변경이 요구될 때, 그에 영향을 받는 컴포넌트만을 바꾸어 다른 것 으로 교체하여 나머지 기존 시스템을 재사용하게 해 준다.

시스템의 복잡성을 통제한다.

컴포넌트 단위로 개발을 수행하므로, 컴포넌트 단위 별로 프로젝트를 통제할 수 있고, 시스템 개발에 대한 위험을 덜 수 있고 조절 가능하다.

병렬 개발을 지원한다.

프로젝트 경계는 안정적인 컴포넌트 정의를 통해 외주 개발을 촉진시킨다. 유지 보수의 외주도 컴포넌트 작성자의 재판매 또는 유지보수로 해결된다.

안정적인 컴포넌트 정의는 유연성을 향상시킨다.

특정한 요구를 만족시키는 컴포넌트가 존재하거나 새로운 요구에 직면했을 때 다른 컴포넌트로 교체가 가능하다.

194


제8장 CBD

단위 테스트 및 통합 테스트가 자연스럽게 촉진된다.

컴포넌트 별로 단위 테스트를 촉진시키고, 진보된 구축 테스트를 지원한다. 또 한, 각 컴포넌트들을 서로 조립하기 위한 통합 테스트도 촉진된다.

캡슐화된 컴포넌트는 변화에 방화벽 같은 역할을 한다.

컴포넌트 외부에 노출한 서비스의 수정을 최소화하고 제한하기 때문에, 컴포넌 트 변경에 따른 유지보수는 쉬워지고 비용도 적게 든다.

이밖에 CBD의 특징을 구조적인 부분에서도 살펴보면, 다음과 같다. CBD의 구조적 특 징은 계층적 아키텍처(Tiered Architecture 또는 Layered Architecture)를 전제로 한 다는 것이다. Client/Server의 2-Tier 아키텍처를 지나 인터넷이 등장하면서, SW 구 축 패러다임은 3-Tier나 n-Tier라고 불리는 계층적 아키텍처가 주류가 되었고, CBD 는 이를 기반으로 시스템 구축이 가능한 개발 방법을 제시하고 있다.

195

CHAPTER 8


UML기반 분석/설계

3

CBD 프로세스

CBD를 프로젝트에서 수행하기 위해서는 CBD를 수행하기 위한 절차나 방법에 대해 정의한 일련의 방법론이나 프로세스가 필요하다. 현재 다양한 CBD 방법론이나 프로 세스가 존재하며, 각 CBD 프로세스가 추구하는 바는 크게 다르지 않으나, 각각의 세 부 사항은 사뭇 다르게 표현하고 있다.

다음은 각종 CBD 방법론을 설명하고 있다. λ Catalysis 1992년 Desmond D ’ Souza와 Allan Wills가 개발한 CBD 방법론이다. UML과 UML 확장 메커니즘을 적용하여 모델을 표현한다. 이론적인 접근법을 제시하고 있 으나 학문적이어서 쉽게 적용하기 어려운 면이 있고, 프로세스에 대한 정립이 필요 하다. 1998년에 『Objects, Components, and Frameworks with UML』에 정리되 어 출간된 바 있다. λ Advisor(CBD96) John Dodd가 Catalysis를 채택하여 제공한 CBD 방법론이다. 컴포넌트를 명세 (specification)와 구현(implementation), 패키지(package)로 분리하는 개념을 적용 하여 UML과 UML 확장 메커니즘으로 표현한다. Advisor는 개발 프로세스의 트윈 트랙을 정의한다. 즉 어플리케이션 개발 트랙과 컴포넌트 공급 트랙으로 분리하여 컴포넌트를 조립하여 어플리케이션을 개발하는 프로세스와 컴포넌트를 개발하는 프로세스를 별도로 정의한다. λ Select Perspective Stuart Frost와 Paul Allen이 제안한 CBD 방법론이다. 컴포넌트 모델은 UML로 표

196


제8장 CBD

의하고 있다. LUCID 기법을 통해 실용적이고 실질적인 프로세스를 제공한다. λ RUP Booch, Rumbaugh, Jacobson이 제안한 방법론으로 초기에는 객체지향 개발 방법 론으로 소개되어 지금은 컴포넌트 개발 방법론으로 진화했다. 여타 방법론과 같이 UML로 모델을 표현하도록 하며, 개발 프로세스와 관리 프로세스를 통합하여 프로 세스를 정의하고 있다. 반복적·점진적인 개발을 강조하여, 각 반복을 계획하고 수행 하는 지침들까지 포함하고 있다. λ UML Component 2000년 John Cheesman과 John Daniels가 컴포넌트 시스템의 아키텍처와 의존성 을 명세화하는 기법을 제시했다. UML을 이용하여 컴포넌트를 모델링하는 기법이 구체적으로 소개되어 있어 실질적인 컴포넌트 모델링 기법을 제시한다. λ Korbra Atkinson 외의 다수의 연구진이 컴포넌트 기반의 Product-Line Engineering을 실 현하는 방법과 기법, 도구 등을 정의했다. 역시 UML로 컴포넌트 모델을 표현하며, Product-Line 개념을 적용하여 컴포넌트를 작성하고 유지하며, 배치하는 전략을 소개한다.

이와 같이 다양한 CBD 방법론들이 있지만, 지금 사용되는 대부분의 방법론들은 서로 좋은 점은 취하고 나쁜 점은 버리면서 거의 비슷한 모습을 띠고 있다. 특히, Agile 프 로세스나 XP(eXtreme Programming)와 같은 light-weight한 방법론에도 많은 영향을 받아,

TDD(Test-Driven

Development)나

Small

Iteration

&

Release,

CTIP(Continuous Test & Integration Process) 등이 대부분의 CBD 방법론에 수용되 고 있다.

CBD 프로세스에서의 단계는 다음과 같이 크게 네 가지로 나누어 볼 수 있다. λ 요구정의 단계

197

CHAPTER 8

현하며, 정렬/설계/조립의 기본 단계를 반복적·점진적으로 수행하는 프로세스를 정


UML기반 분석/설계

고객의 요구사항 도출 및 정의

개발할 시스템의 비즈니스 도메인에 대한 이해

이터레이션 계획 수립

λ 분석 단계 •

해당 이터레이션에 대한 상세 계획 수립

개발할 시스템에서 제공해야 할 기능을 고객 관점에서 정의

핵심 기능에 대한 UI 프로토타이핑을 통해 고객에게서 검증

시스템의 기능을 구현할 내부 객체 식별 및 정의

시스템 내부 객체와 사용자와 시스템 간의 상호작용 체계를 정의하고 이들의 일관성 검증

λ 설계 단계 •

시스템에 구현될 화면 레이아웃 및 화면 간의 네비게이션(Navigation) 정의

데이터 모델링을 통한 DB 설계

컴포넌트 식별 기법을 사용한 컴포넌트 식별, 컴포넌트 간 상호작용 관계를 정 의

컴포넌트 내부 클래스 및 시퀀스 다이어그램 작성을 통해 객체의 속성 및 오퍼 레이션과 객체 간 메시지 전달 흐름을 설계

λ 구현 단계 •

컴포넌트 프로그래밍

컴포넌트 테스트

컴포넌트 배포 및 운영

다음 [표 8-1]은 대부분의 CBD 프로세스의 일반적인 공정표이다.

[표 8-1] CBD 공정표 단계 요구정의

활동 비즈니스 모델링

작업

설명 BPM, 업무 프로세스 정의

비즈니스 프로세스 모델링 및 개선

198


제8장 CBD

도메인 모델

요구사항 정의

고객의 요구사항 정의

유스케이스 모델링

기능적 요구사항 분석

CHAPTER 8

요구사항 정의

비즈니스 개념 모델링

우선 순위에 따른 이터레이션 계획 이터레이션 계획 수립 유스케이스 상세화 분석

유스케이스 상세화

유스케이스 정의서 작성

유스케이스 정적 분석

유스케이스 정적 실체화

유스케이스 동적 분석

유스케이스 동적 실체화

UI 설계

화면 및 네비게이션 설계

유스케이스 분석 UI 설계

전체 컴포넌트 식별 및 컴포넌트 식별 인터페이스 정의 컴포넌트 정의 컴포넌트들 간 상호작용 컴포넌트 상호작용 정의 정의 설계

컴포넌트 정적 설계 컴포넌트 설계

컴포넌트 내부 관계 정의 컴포넌트 내부 상호작용

컴포넌트 동적 설계 정의 및 오퍼레이션 명세 논리적 DB 설계

논리 ER 모델 정의

물리적 DB 설계

물리 ER 모델 정의

배치 설계

배치 설계

물리적인 배치 정의

개발

개발

컴포넌트 개발

단위 테스트

컴포넌트 테스트

통합 테스트

컴포넌트들 간 연계 테스트

DB 설계

구현 테스트

199


UML기반 분석/설계

4

UML 모델링 적용 방법

앞장에서 살펴본 CBD 프로세스에서 UML을 적용하여 수행할 수 있는 활동(Activity) 에 대해 정의해 보기로 한다. 그리고, 여기서 정의된 UML 모델링 기법을 다음 장(제 9장~15장)부터 순서에 따라 상세하게 배워 보도록 하겠다.

다음은 CBD 프로세스에 UML 모델링을 매핑한 표이다.

[표 8-2] CBD 프로세스에 따른 UML 모델링 매핑표 단계

활동

작업 비즈니스 프로세스 모델링

비즈니스 모델링

UML 적용 기법 액티비티 다이어그램 클래스 다이어그램 (도메인

비즈니스 개념 모델링 모델링) 요구정의 요구사항 정의 요구사항 정의

유스케이스 모델링

유스케이스 다이어그램

이터레이션 계획 유스케이스 정의서, 액티비 유스케이스 상세화

유스케이스 상세화 티 다이어그램 클래스 다이어그램(객체 모 유스케이스 정적 분석 델링)

분석

커뮤니케이션

유스케이스 분석

다이어그램,

시퀀스 다이어그램, 스테이 유스케이스 동적 분석 트

머신

모델링) 설계

200

UI 설계

UI 설계

다이어그램(상태


제8장 CBD

컴포넌트 다이어그램

컴포넌트 상호작용 정의

시퀀스 다이어그램

컴포넌트 정적 설계

클래스 다이어그램

CHAPTER 8

컴포넌트 식별 컴포넌트 정의

시퀀스 다이어그램, 스테이

컴포넌트 설계 컴포넌트 동적 설계

머신

다이어그램(상태

모델링), 오퍼레이션 명세 논리적 DB 설계 DB 설계 물리적 DB 설계 배치 설계

배치 설계

개발

개발

구현

디플로이먼트 다이어그램

단위 테스트 테스트 통합 테스트

위 [표 8-2]의 UML 적용 기법 중에 액티비티 다이어그램과 클래스 다이어그램(도메 인 모델링)은 본 과정에서 다루지 않는다. 왜냐하면 비즈니스 모델링은 요구사항 정의 전에 해당 도메인을 보다 정확히 이해하고자 하는 측면이 강하기 때문에, 굳이 수행하 지 않아도 된다. 또한, 일반 시스템 구축 프로젝트에서는 비즈니스 모델링을 수행하더 라도 그 절차와 방법이 까다롭고, 그 결과물을 만들어 활용하기 쉽지 않다. 물론, 비 즈니스 모델링 자체가 목적인 프로젝트에서는 매우 중요하다.

모델링 간의 관계를 살펴 보면 다음 [그림 8-3]과 같다.

201


UML기반 분석/설계

[그림 8-3] 모델링 간의 관계

λ UseCase Modeling ⎜⎝ Structural Modeling •

각 유스케이스에 참여하는 개념적 객체는 클래스 다이어그램에 반영된다.

요구사항의 데이터 및 데이터와의 관계는 클래스 다이어그램에 반영된다.

요구사항의 개체 속성은 클래스의 속성에 반영된다.

λ UseCase Modeling ⎜⎝ Behavioral Modeling •

요구사항에 나타난 업무 처리 흐름은 액티비티 다이어그램에 반영된다.

액터와 시스템 간의 상호작용이 커뮤니케이션 다이어그램과 시퀀스 다이어그램 의 전반부에 반영된다.

각 유스케이스에 참여하는 객체 간의 처리 흐름은 커뮤니케이션 다이어그램과 시퀀스 다이어그램에 반영된다.

λ Domain Modeling ⎜⎝ Component Modeling •

202

도메인 객체들이 비즈니스 컴포넌트로 그룹핑되어 컴포넌트 다이어그램에 반영


제8장 CBD

CHAPTER 8

된다. λ Domain Modeling ⎜⎝ Structural Modeling •

도메인 객체가 분석 객체로 변환되어 클래스 다이어그램에 반영된다.

λ Component Modeling ⎜⎝ UseCase Modeling •

유스케이스와 액터 간의 상호작용 관계가 어플리케이션 컴포넌트로 식별되어 컴포넌트 다이어그램에 반영된다.

유스케이스 별 컴포넌트들 간의 처리 흐름이 시퀀스 다이어그램에 반영된다.

λ Component Modeling ⎜⎝ Structural Modeling •

컴포넌트들 간의 협력, 의존 관계가 컴포넌트 다이어그램에 반영된다.

컴포넌트 외부의 인터페이스와 내부의 클래스들 간의 관계가 클래스 다이어그 램에 반영된다.

컴포넌트가 수행할 기능을 구현하기 위한 클래스들이 클래스 다이어그램에 반 영된다.

λ Component Modeling ⎜⎝ Behavioral Modeling •

컴포넌트들 간의 처리 흐름이 시퀀스 다이어그램에 반영된다.

컴포넌트 인터페이스의 오퍼레이션 기능을 수행하기 위한 컴포넌트 내부 클래 스들 간의 처리 흐름이 시퀀스 다이어그램에 반영된다.

λ Structural Modeling ⎜⎝ Behavioral Modeling •

Behavioral Modeling에 나타나는 모든 객체가 클래스 다이어그램에 반영된다.

Structural Modeling에 나타나는 모든 클래스가 커뮤니케이션 다이어그램이나 시퀀스 다이어그램에 반영된다.

Behavioral Modeling의 메시지 흐름, 업무 흐름이 클래스 다이어그램의 연관 관계를 통해 네비게이션(Navigation)된다.

Behavioral Modeling의 액션(Action)이나 활동(Activity)이 클래스의 오퍼레이 션으로 반영된다.

Behavioral Modeling에서 도출된 상태가 클래스의 속성으로 반영된다.

λ Component Modeling ⎜⎝ Deployment Modeling •

컴포넌트가 물리적인 단위로 구현되는 형태와 설치될 위치가 디플로이먼트 다

203


UML기반 분석/설계

이어그램에 반영된다.

이제 다음 장에서부터 본격적으로 UML 적용 기법에 대해 살펴보기로 하겠다.

204


Chapter

09

UseCase Modeling

1 절 요구사항 정의 2 절 유스케이스 모델링 3 절 유스케이스 상세화 4 절 Case Study

학습목표 Φ 요구사항을 정형화하는 방법을 학습한다. Φ 액터와 유스케이스를 식별하는 방법을 학습한다. Φ 유스케이스 모델링을 수행하여 시스템 개발을 시작하는 방법에 대해 학습 한다. Φ 유스케이스 정의서를 작성하여 유스케이스 모델을 상세화하는 방법에 대하 여 학습한다.


시스템 또는 소프트웨어 개발은 고객이나 사용자의 필요에 의해서 이루 어지는 행위이다. 따라서, 시스템에 대한 정확한 요구사항을 정의하는 것이 시스템 개발을 성공으로 이끌기 위한 첫 번째 중요한 임무이고, 유스케이스 모델링을 통해 이러한 요구사항을 잘 정의할 수 있다. 이 장에서는 고객이나 사용자의 요구사항을 잘 담아 내기 위해, 유스케 이스가 무엇이며, 유스케이스 모델링은 어떻게 하는지 등을 포함한, UML을 사용한 전반적인 유스케이스 모델링 기법에 대해 배워 본다.


제9장 UseCase Modeling

CHAPTER 9

1

요구사항 정의

시스템을 개발 시 가장 중요하게 생각해야 하는 점은, 해당 시스템이 사용자가 원하는 것을 제공해 줄 수 있느냐이다. 이는 시스템이나 소프트웨어를 개발하는 과정에서 항 상 달성하기 위해 노력하고 고민해야 하는 중요한 문제이다.

이와 같이 사용자가 필요로 하고 원하는 사항에 대해 시스템 개발 관점에서 정제한 것을 요구사항(Requirements)이라고 부른다. 『IEEE Std 610.12-1990』에서는 요구 사항을 다음과 같이 정의하고 있다.

1.

사용자가 문제를 해결하거나 목적을 달성하는 데 필요한 조건이나 역량

2.

시스템 또는 시스템 컴포넌트가 계약, 표준, 명세, 공식적으로 요구된 문서를 만족시키기 위해서 반드시 갖추어야 하는 조건이나 역량

3.

1 과 2 와 같은 조건과 역량을 기술한 문서

사용자의 요구사항을 정확하게 정의하고, 그에 따라 시스템을 개발하는 것은 어찌 보 면 쉬운 일일 수도 있지만, 결코 쉽지 않은 것이 현실이다.

일반적으로 시스템이나 소프트웨어를 개발할 때, 먼저 우리는 고객이나 사용자에게서 요구사항을 수집하여 정리하고 정의한다. 그리고 요구사항에 대한 확인이 끝나면, 이 를 바탕으로 설계를 수행한다. 그러나 시스템을 개발하다 보면 대부분의 경우 요구사 항이 변경되거나 새로운 요구사항이 나오게 마련이고, 그때마다 고객과 신경전을 벌이 고 심지어는 싸우기까지 한다. 이러한 요구사항의 변경 및 수용은 시스템 전반에 걸친 위험 요소가 될 수도 있고, 시스템 개발이 끝날 때까지 지속적으로 겪어 나아가야 하

207


UML기반 분석/설계

는 문제이다. 이처럼 한 시스템이나 소프트웨어의 개발은 끊임없는 요구사항 반영의 산물이고, 요구사항에 대한 명확한 정의와 그 변경에 대한 관리는 그 프로젝트의 성패 와 직결된다.

우리가 시스템이나 소프트웨어를 개발하면서 요구사항과 관련해 겪게 되는 가장 심각 한 점은 동일한 요구사항에 대해 서로 잘못 이해하여 발생하는 문제이다. 이는 자신에 게 필요한 것이 무엇인지 제대로 알지 못하는 사용자나 고객의 문제일 수도 있고, 요 구사항을 원한 사용자와 그 요구사항을 잘못 이해한 개발자 사이의 문제일 수도 있고, 아니면 동일한 요구사항에 대해 서로 다르게 이해한 설계자와 개발자 사이의 문제일 수도 있다. 이와 같이 요구사항에 대해 서로 이해가 어긋나는 문제는, 요구사항을 정 의하고 상호간에 이해하기 위한 장치의 부재로 인해 발생하는 경우가 많다.

다음 [표 9-1]은 요구사항 정의서 예제이다.

[표 9-1] 요구사항 정의서 예제

208


제9장 UseCase Modeling

동떨어지므로, 그 요구사항이 시스템 개발 시에 제대로 반영되기 어렵다. 또한, 문서 에 기록된 요구사항은 너무 모호하거나 추상적일 수 있다. 따라서 이를 극복하기 위해 요구사항을 적극적으로 시스템에 반영할 수 있는 무엇인가가 필요하고, 우리는 UML 로부터 유스케이스라는 선물을 얻을 수 있다. 유스케이스는 사용자가 시스템 또는 소 프트웨어에 바라는 요구를 담아 내는 것으로, 시스템이 사용자의 요구사항 중심으로 개발되도록 많은 도움을 준다.

[그림 9-1] 요구(Needs)와 요구사항(Requirements), 그리고 유스케이스(UseCase)

위 [그림 9-1]은 사용자의 요구(Needs)와 요구사항(Requirements), 유스케이스 (UseCase) 간의 관계를 나타내고 있다. 유스케이스는 시스템에 대한 요구사항 중 기 능적 요구사항에 대해 정의하고 명세화할 수 있도록 한다. 요구사항은 크게 기능적 요 구사항과 비기능적 요구사항으로 나눌 수 있고, 다음과 같이 각각 정의된다. •

기능적 요구사항: 시스템이 사용자에게 제공해 주었으면 하는 기능 또는 일에 대한 요구사항

209

CHAPTER 9

요구사항을 구두상으로만 전달하거나 문서에만 기록하는 것은 실제 시스템 개발과는


UML기반 분석/설계

비기능적 요구사항: 시스템이 사용자에게 해당 기능을 어떻게(how) 제공해 주 어야 하는 지에 대한 요구사항 (품질 속성)

이처럼 유스케이스를 통해 고객이나 사용자의 요구사항에 대해 정의하는 일련의 행위 를 유스케이스 모델링이라고 한다. 우리는 유스케이스 모델링을 통해서, 요구사항을 정형화하고 효율적으로 관리할 수 있는 토대를 마련할 수 있고, 이는 프로젝트 전반에 걸쳐 요구사항에 대한 이해도를 높이는 데 크게 공헌한다.

210


제9장 UseCase Modeling

CHAPTER 9

2

유스케이스 모델링

유스케이스 모델은 요구사항을 기록하는 UML의 가장 대표적인 모델이며, 액터와 시 스템 사이의 관계를 시각적으로 표현하는 유스케이스 다이어그램과 유스케이스 각각 의 내용을 상세히 기술하는 유스케이스 정의서로 이루어진다. 유스케이스 모델은 요구 사항, 즉 구현해야 하는 기능이 ‘무엇’인지를 정의하며, 그것을 ‘어떻게’ 제시할 지는 기술하지 않는다. 유스케이스 다이어그램은 ‘사용자의 시각에서 시스템이나 소프트웨 어의 범위와 기능을 쉽게 설명하고 정의한 모델’이고, 또한 ‘시스템이나 소프트웨어의 기능적 요구사항에 대한 베이스라인’이다. 일반적으로 유스케이스는 기능적 요구사항 을 나타내지만, 유스케이스 정의서에는 해당 유스케이스와 관련된 비기능적 요구사항 을 함께 기록할 수도 있다.

유스케이스 모델링은 시스템과 사용자의 상호작용을 파악하여 사용자가 시스템을 통 해 수행하고자 하는 시스템의 기능적 요구사항을 식별하여 정형화하는 데 그 목적이 있다. 즉, 유스케이스 모델링은 시스템의 밖에서 시스템을 바라보는 관점으로, 개발할 시스템이 시스템 바깥에 있는 사용자나 외부 시스템에게 제공할 기능에 대해 표현하 고, 시스템을 사용하는 액터와 역할을 수행하는 시스템 간의 상호작용을 표현한다.

프로젝트 수행의 전체적인 입장에서 보았을 때, 유스케이스는 무엇을 개발해야 하며, 어디서부터 개발을 시작해야 하는지, 그리고 개발을 위한 클래스와 객체는 어떻게 추 출해야 하는지 등을 전혀 모르는 상태에서도 이들 작업을 수행할 수 있는 단초를 제 공한다. 그리고 사용자와 개발자, 설계자와 개발자 사이에 올바른 대화를 진행할 수 있도록, 프로젝트 구성원 모두가 잘 이해할 수 있는 시각적인 모델을 제공한다. 특히,

211


UML기반 분석/설계

UP(Unified Process)에서는 유스케이스를 매우 비중 있게 다루는데, UP에서 모든 작 업의 기준은 유스케이스이다. UP 프로젝트에서 유스케이스는 다음과 같은 기준을 제 공한다.

1. 전체적인 시스템의 개발 범위를 결정하는 기준이 된다. 2. 이터레이션(Iteration) 계획을 수립하는 기준이 된다. 3. 업무 진행률을 파악하는 기준이 된다. 4. 테스트를 위한 테스트의 수행 기준이 된다.

유스케이스 모델링 작업은 시스템 분석 및 설계에서 아주 중요한 과정으로, 특히 객체 지향 분석설계의 주요 뼈대가 되는 과정이라고 말할 수 있다. 그리고 유스케이스 모델 은 사용자와 개발자 상호간의 의사소통 수단으로 이용되며, 개발하는 시스템과 사용자 사이의 관계를 이해하는데 많은 도움을 준다.

본 과정에서 유스케이스 모델링의 절차는 [표 9-2]의 일반적인 절차에 따라 진행될 것이다. [표 9-2]는 일반적인 유스케이스 모델링 절차를 『 Writing Effective Use

Cases 』에서 앨리스테어 코번(Alistair Cockburn)이 제시한 12단계 절차와 비교하고 있다.

코번의 12 단계 일반적인 유스케이스 모델링 절차 (Writing Effective Use Cases - Alistair Cockburn) ① 시스템의 범위와 경계 설정 ② 시스템에 관계된 모든 액터 찾기 ① 시스템 범위 설정 ③ 사용자가 시스템을 통해 얻으려고 하는 것(use ② 액터 정의 Case)들 찾기 ③ 유스케이스 정의 ④ 각 액터에 대한 최 외각 유스케이스(summary ④ 관계 설정 UseCase) 설정 ⑤ 유스케이스 정의서 작성 ⑤ 최 외각 유스케이스들에 대한 정제 작업(시스템 범위의 재확인)

212


제9장 UseCase Modeling

⑦ 이해관계자와 그들의 이익, 선행조건, 후행조건 등을 뽑아냄 ⑧ 주 성공 흐름 작성 ⑨ 대안 흐름과 예외 흐름 찾기 ⑩ 대안 흐름과 예외 흐름 작성 ⑪ 복잡한 스텝을 하위 유스케이스로, 자잘한 스텝 들은 모아서 하나로 ⑫ 유스케이스 조절 작업(읽기는 쉬운지, 구색은 갖 추었는지, 이해관계자는 만족하는지) [표 9-2] 유스케이스 모델링 절차 비교

코번의 12단계 절차도 앞으로 설명할 작업 절차와 그리 큰 차이는 보이지 않는다. 단 지 중요한 것은 반복·점진적으로 유스케이스 모델을 완성해 나간다는 점이다. 이 밖에 도 『Advanced Use Case Modeling』에서는 다음 [그림 9-2]와 같이 유스케이스 모 델링 절차를 설명하고 있다.

[그림 9-2] Advanced UseCase Modeling의 Major UseCase Activity Groups

유스케이스 모델링은 먼저 시스템의 범위를 정하고 시스템에서 의미 있는 액터를 도 출한 후, 유스케이스를 정의하는 순서로 수행한다. 또한, 유스케이스들 간의 관계와 유스케이스와 액터 간의 관계를 부여하고 유스케이스 정의서를 작성하여 유스케이스 를 상세화한다. 그리고 이 모든 과정은 상세화와 세분화를 고려하여 반복·점진적으로 반복된다.

213

CHAPTER 9

⑥ 상세 작업을 할 유스케이스 선택


UML기반 분석/설계

2.1

시스템 범위(System Boundary) 설정

유스케이스 모델링의 첫 번째 단계는 시스템의 범위를 설정하는 것이다. 구현할 소프 트웨어나 시스템의 범위를 어떻게 설정하느냐에 따라, 유스케이스가 달라지겠지만, 더 욱 중요한 사실은 분석할 액터도 달라진다는 것이다.

예를 들어, 그룹웨어 시스템 전체를 시스템 범위로 설정하면, 전자결재 기능을 사용하 는 상신자와 전자메일 기능의 사용자인 전자메일 발신자도 액터로 표현되어야 한다. 그러나, 전자결재 시스템만을 시스템 범위로 설정하면, 상신자와 결재자만이 액터로 표현된다. 다음 [그림 9-3]은 시스템 범위 설정에 따라 액터가 어떻게 다르게 선정될 수 있는지 보여준다.

[그림 9-3] 시스템 범위 설정에 따른 액터의 변화

214


제9장 UseCase Modeling

환경적인 변수(비용, 기간, 정치적 요인 등등)로 인해 몇몇 요구사항은 시스템 개발에 수용되지 않거나 변경될 수 있다. 이와 같이 시스템 범위를 명확히 하는 것은 유스케 이스 모델링의 시작이자, 수용할 요구사항에 대한 마지노선이 된다.

2.2

액터(Actor) 정의

유스케이스 모델링에서 유스케이스는 시스템 밖에서 시스템을 바라보는 관점으로 시 스템이 수행해야 할 기능을 표현한 것이라면, 액터는 개발할 시스템이나 소프트웨어의 바깥에 위치하는 사용자나 다른 시스템을 나타낸다. 액터는 보통 특정 작업을 완수할 목적으로 개발할 시스템과 상호작용하는 사람이나 다른 시스템이라고 보면 된다.

이중 사람에 해당하는 액터는 현업 조직 구성과 수행 업무를 참조하여 도출할 수 있 다. 이때, 사람이나 직책이 아니라 역할(Role)을 중심으로 액터를 도출할 수 있도록 한다. 즉, 역할에 따라 여러 사람이 한 가지 역할을 수행하는 액터로 정의될 수 있고, 한 사람이 여러 역할을 수행하여 여러 액터로 정의될 수도 있다. 예를 들어 전자결재 시스템에서 결재하는 사람이 액터로 식별되었다면, 그 이름은 팀장이 아닌, 결재하는 사람의 역할로서 결재자가 액터 명이 되어야 하고, 그 팀장이 자신의 상급자에게 결재 를 상신한다면, 팀장은 결재자이면서 상신자 액터로 표현되어야 한다.

그리고 시스템에 해당하는 액터는 개발할 시스템과 정보를 주고받는 타 시스템이나 외부기기를 대상으로 도출하도록 한다. 타 시스템은 기존 레가시(Legacy) 시스템이나 다른 회사의 외부 시스템이 될 수 있고, 외부기기는 외부 센서나 외부 입·출력 장치가 될 수 있다. 예를 들어 전자 상거래 시스템에서 신용카드인증회사와 연계되어야 한다 면 신용카드 인증회사는 액터로 표현된다.

이 밖에도, 시스템의 상태를 감시하고 상태에 따라 기능을 수행하는 모니터링 프로세

215

CHAPTER 9

시스템 범위 설정은 고객이나 사용자가 요구한 요구사항과 밀접하게 연관된다. 다양한


UML기반 분석/설계

스나, 적정 시점에 자동으로 수행되는 유스케이스를 기동시키는 이벤트 혹은 타이머도 액터로 추출할 수 있다. 또한, 다른 액터와 시스템 간의 상호 작용을 돕는 프락시 (Proxy) 역할의 액터도 표현할 수 있는데, 이는 비즈니스 유스케이스와 같은 상위 레 벨의 유스케이스 모델에 더욱 적합한 액터 추출 방법이다.

다음 [그림 9-4]는 개발할 새로운 시스템을 중심으로 주변에 존재하는 다양한 액터의 유형을 나타낸다.

[그림 9-4] 새로운 시스템 주변에 존재하는 다양한 액터의 유형

액터는 다양한 기준에 따라 분류될 수 있지만, 가장 일반적인 방법은, 유스케이스의 창시자인 이바 야콥슨(Ivar Jacobson)이 제안한 것이다. 그는 액터를 주요(Primary) 액터와 보조(Secondary) 액터 두 가지로 분류하여, 액터가 유스케이스에 얼마나 영향

216


제9장 UseCase Modeling

구하는 능동적인 입장의 액터로 유스케이스를 기동하는 역할을 수행하고, 보조 (Secondary) 액터는 시스템의 요청에 따라 수동적으로 어떤 작업을 해 주는 액터로서 유스케이스로부터 어떠한 요청이나 메시지를 전달받거나 주는 액터를 말한다. 보조 (Secondary) 액터를 코번의 『 Writing Effective Use Cases 』 에서는

보조

(Supporting) 액터라고도 표현한다.

성격에 따라 액터를 분류할 수도 있다. 『Advanced Use Case Modeling』에서는 다 음 [표 9-3]과 같이 분류하고 있다.

성격 유형 (Personality Type)

행위 (Behavior)

Initiator

유스케이스를 기동시킨다.

External Server

유스케이스가 있는 시스템에 서비스를 제공한다.

Receiver

유스케이스로부터 정보를 수신한다.

Facilitator (Proxy)

다른 액터와 시스템 간의 상호작용을 돕는다. [표 9-3] 액터 성격에 따른 분류

경우에 따라 도출된 액터에 대한 간단한 설명을 기술하면, 해당 액터를 더욱 명확히 정의할 수 있다. 설명에는 다음과 같은 내용이 기술된다. •

무엇을 하는가? 즉, 어떤 역할을 담당하는가?

왜 필요한가?

시스템의 어떤 기능들을 사용하는가 또는 사용할 수 있는가?

지금까지 설명한 것처럼 개발할 시스템에 대한 다양한 유형의 액터를 정의함으로써, 우리는 본격적으로 유스케이스를 정의할 수 있는 토대를 마련하게 된다. 그리고 부가 적으로 얻을 수 있는 이득은, 앞에서 이야기한 시스템 범위와 경계를 더욱 확실히 할 수 있다는 것이다.

217

CHAPTER 9

을 미치냐에 따라 구분한다. 주요(Primary) 액터는 시스템에 어떤 작업의 실행을 요


UML기반 분석/설계

2.3

유스케이스(Usecase) 정의

앞 절에서 요구사항에 대해 이야기를 할 때 이미 유스케이스에 대해 알아 보았다. 다 시 생각해 보면, 유스케이스는 기능적인 요구사항에 대해 정의할 수 있는 하나의 도구 였다. 다른 관점에서 본다면, 유스케이스는 시스템이나 소프트웨어가 액터에게 의미 있는 결과를 제공하는 일련의 작업들이다. 따라서, 하나의 유스케이스에 속하는 일련 의 작업은 경우에 따라 다른 순서로 진행될 수도 있으나 같은 의미를 액터에게 제공 해야 한다.

그래디 부치(Grady Booch)는 유스케이스를 다음과 같이 정의한다. •

시스템이 액터에게 주목할 만한 결과를 내놓기 위해 수행하는 여러 작업들의 집합

유스케이스를 도출하는 기본적인 방법은, 액터가 시스템에게 무엇을 요구하는지를 고 려하여, 시스템이 수행하는 특정 기능에 대해서 그 기능의 수행을 지원하는 액터와 시 스템 간의 상호작용과 시스템 내부에서 발생하는 모든 가능한 사항을 기술하는 것이 다. 다음은 일반적으로 유스케이스를 도출할 때 사용되는 유스케이스 도출 기준이다. •

독립적이고, 완결적인 수행 단위이다. 수행 흐름 중간에 중단되어서는 안 된다 (Exception 처리 경우는 제외). 중단되면 데이터가 불안정한 상태가 되며 사용 자는 의미 있는 결과를 얻을 수 없다.

각 액터가 시스템에 요구하는 기능이 무엇인지를 중심으로 고려한다.

액터의 업무 수행 단위를 중심으로 도출하며 데이터 관리 측면에서의 접근 방 식을 배제한다.

시스템에 대한 요구 사항 중 기능 요구사항과 타 시스템 인터페이스 요구사항 에 중점을 두어 작성한다.

다음은 유스케이스에 대한 작성 지침이다.

218


제9장 UseCase Modeling

유스케이스의 주요 목적은 시스템의 기능적 요구사항을 찾는 것이다. 일반적으 로 성능에 대한 요구사항을 비롯해 기능적 요구사항이 아닌 것은 유스케이스에 포함시키지 않는다.

한 유스케이스 다이어그램에 표현되는 유스케이스의 개수는 적을수록 좋으며, 개수가 많아져 유스케이스 다이어그램이 복잡해질 경우에는 패키지를 이용하여 논리적으로 연관된 유스케이스끼리 묶어 여러 개의 유스케이스 다이어그램을 생성한다.

유스케이스에 레벨에 따라 상위 유스케이스와 하위 유스케이스로 분리할 수도 있다. 상위 유스케이스일수록 좀더 비즈니스 케이스와 가깝고 유스케이스의 추 상화 수준이 높다. 상위 유스케이스를 여러 개의 작은 단위의 하위 유스케이스 로 나눌 수 있다. 가급적이면, 한 유스케이스 다이어그램에 표현되는 유스케이 스는 같은 상세화 정도를 갖도록 한다.

유스케이스의 이름은 사용자 관점에서 사용자의 용어를 사용하여 현재 시제와 능동태로 기술한다.

유스케이스를 처음 찾을 때는 먼저 액터와 연결된 유스케이스를 찾는다.

위 작성 지침에서 이야기한 내용 중에 가장 어려운 사항은 유스케이스의 레벨에 관한 것이다. 왜냐하면 UML에 정의되어 있는 유스케이스의 표준에는 유스케이스에 대한 레벨이나 범위에 대한 개념이 없기 때문이다. 일반적으로, 레벨이 높은 유스케이스가 넓은 범위의 내용을 광범위하게 다루고, 레벨이 낮은 유스케이스가 보다 적은 범위의 내용을 상세히 다룬다. 다음 [그림 9-5]는 유스케이스의 레벨에 대한 개념을 예제와 함께 보여준다.

219

CHAPTER 9


UML기반 분석/설계

[그림 9-5] 『Writing Effective Use Cases』의 유스케이스 레벨

보통 유스케이스의 레벨은 그 유스케이스를 필요로 하는 사람에 따라 다르게 구성된 다. 전체 시스템을 개괄적으로 보기를 원하는 매니저나 관리자, 고객들은 보다 높은 레벨로 구성된 유스케이스를 필요로 한다. 이들에게는 어떻게 유스케이스가 수행되는 가는 주 관심 분야가 아니고, 보다 높은 레벨의 관점으로 시스템 전반적인 모습을 바 라보고 싶어 한다. 반면, 요구사항 분석을 통해 실제 작동하는 시스템을 구성해야 하 는 분석 설계자들은 보다 세부적으로 어떠한 기능을 수행하는지를 볼 수 있는 수준이 필요하다. 또한, 개발자들은 요구하는 기능을 실제로 구현할 수 있는 CRUD 수준의 유스케이스를 필요로 한다.

이와 같이, 유스케이스를 통해 요구사항에 대한 의사소통을 하는 사람의 역할이 무엇 이냐에 따라 유스케이스는 다른 레벨의 형태를 띠게 된다. 가장 자연스러운 것은, 비 즈니스나 요구사항 모델링과 같은 시스템 구축 초반에는 상위 수준의 유스케이스를 추출하고, 시스템 구축이 설계, 개발로 구체화됨에 따라 하위 기능 레벨 유스케이스까 지 자연스럽게 추출되는 것이다.

또한, 유스케이스를 작성하는 과정에서 전형적으로 등장하는 좋지 않은 예 중의 하나

220


제9장 UseCase Modeling

유스케이스는 비슷한 정도의 범위를 비슷한 상세화 정도로 기술해야 한다.

위 [그림 9-5]에 따르면, 유스케이스 레벨은 크게 요약 목적(Summary Goal), 사용자 목적(User Goal), 하위 기능(Subfunction)으로 나눌 수 있다. 이 중에서 사용자 목적 레벨이 요구사항을 분석하는 데 가장 적절한 수준이다. 사용자 목적 레벨에서 왜 (Why)라는 질문을 통해 내용을 정리하면 요약 레벨의 유스케이스가 되고, 어떻게 (How)라는 질문을 통해 내용을 상세화하면 하위 기능 유스케이스가 된다. 사용자 목 적 레벨의 유스케이스를 판단할 때 다음과 같은 기준을 사용한다. •

한 사람이 한자리에 앉아서 한 번(2~20분)에 끝낼 수 있는 정도

종료되었을 때 액터가 자리를 뜨는 데 어려움이 없는 정도

지금까지 살펴본 바와 같이, 유스케이스는 요구사항(특히, 기능적인 요구사항)을 뽑아 내고 정의하는 수단이며, 시스템의 범위를 정하는 것을 돕는다. 또한, 최종 사용자, 고 객, 분석 설계자 및 개발자를 포함한 여러 프로젝트 구성원들 간의 의사소통을 원활히 하는 역할을 수행한다. 유스케이스 정의를 완전하게 하기 위해서는 유스케이스 정의서 를 작성해야 하는데, 이는 유스케이스 상세화에서 다루도록 한다.

2.4

관계(Relationships) 설정

액터와 유스케이스 찾기가 끝나면 이들 간의 관계를 설정하면서, 유스케이스 다이어그 램을 작성한다.

서로 관계가 있는 액터와 유스케이스를 연관(Association) 관계로 표현하고, 유스케이 스와

유스케이스

(Generalization)

사이의 관계로

관계를 표현한다.

포함(Include), 또한,

액터와

확장(Extend), 액터

사이의

그리고

일반화

관계도

일반화

(Generalization)와 연관(Association) 관계로 표현할 수 있다.

221

CHAPTER 9

가 같은 레벨의 유스케이스 간에 상세화 정도의 차이가 생기는 것이다. 같은 레벨의


UML기반 분석/설계

관계 중 가장 중요한 것은 액터와 유스케이스 간의 관계이다. 액터와 유스케이스 간의 관계를 표현할 때는 연관(Association) 관계를 사용하는데, 화살표를 사용해 나름의 의미를 부여할 수도 있다. 다음은 화살표를 사용하는 경우들이고, [그림 9-6]은 이를 표현하고 있다. •

주요 액터가 유스케이스를 기동하는 경우에만 액터에서 유스케이스 쪽으로 화 살표 머리를 사용한다.

주요 액터가 유스케이스를 기동하거나 유스케이스가 보조 액터를 기동하는 경 우 기동하는 쪽으로 화살표 머리를 사용한다.

기대되는 응답이 없는 단 방향 커뮤니케이션에만 화살표 머리를 사용한다. 예를 들어 프린터로 명령을 보내는 경우나 타 시스템에 내용을 통보하는 경우 등이 그렇다.

유스케이스 기동

[그림 9-6] Directed Association 사용

유스케이스 다이어그램에서 화살표를 사용할 때에는 데이터의 흐름이 아니라 커뮤니 케이션의 기동 방향을 보여 주는 데 사용하는 것이 좋다. 데이터는 보통 액터와 유스 케이스 사이에 양방향으로 흐르는 것이 일반적이기 때문에 데이터의 흐름으로 화살표 를 사용하면 양방향 화살표가 되게 되고, 이것은 다이어그램을 어지럽히는 원인이 된 다.

222


제9장 UseCase Modeling

사용하며, 특히 포함(Include) 관계가 사용 빈도가 가장 높다. 유스케이스와 유스케이 스 사이에서 일반화(Generalization) 관계는 잘 사용되지 않는다. 다음 [표 9-4]는 유 스케이스들 사이에서 사용되는 관계들을 다시 한 번 정리하여 보여 준다.

[표 9-4] 유스케이스들 간의 관계 요약 관계 (Relationship)

설명 (Description) 하나의 유스케이스가 유스케이스 내의 작업 흐름의 과정 안에 다른 유스케이스의 처리 흐름을 포함하게 하는 관계를 표현한 다.

포함(Include)

UseCase A

UseCase B

<<include>>

<<include>>

Included UseCase

하나의 유스케이스의 처리 흐름 중 특정 지점에서 다른 유스 케이스의 처리 흐름으로 확장하는 관계를 표현한다.

확장(Extend)

<<extend>>

Extending UseCase A

Base UseCase <<extend>>

Extending UseCase B

객체 지향 개념에서의 상속 관계와 유사하게, 자식 유스케이스 가 부모 유스케이스가 가지고 있는 속성, 처리 흐름, 확장 지 일반화(Generalization) 점, 그리고 다른 유스케이스와의 관계 등을 모두 상속받는다는 것을 의미한다.

223

CHAPTER 9

유스케이스와 유스케이스의 관계는 일반적으로 포함(Include)과 확장(Extend)을 많이


UML기반 분석/설계

General UseCase

Specific UseCase A

Specific UseCase B

유스케이스와 유스케이스 사의의 관계를 너무 세밀하게 하여 포함(Include)이나 확장 (Extend) 등의 관계가 너무 많이 정의되는 것은, 오히려 유스케이스의 독립성을 훼손 시키고 유스케이스의 가독성 내지 이해성을 떨어뜨릴 수 있다. 따라서, 불필요한 유스 케이스들 간의 관계 설정은 오히려 지양되어야 한다.

액터와 액터 간의 관계를 정의하는 것은 액터들 사이에서 액터의 역할과 책임을 더욱 분명히 할 수 있게 해 준다. 또한, 개발할 시스템 외부에 있는 액터들의 관계를 파악 함으로써, 액터들 간의 이해관계에 따른 시스템에 미치는 영향도를 고려할 수 있다.

일반적으로 액터들 간의 관계는 일반화(Generalization)를 사용하며, 앞의 액터 정의 에서 이야기한 프락시(Proxy) 액터를 표현할 경우 연관(Association) 관계를 사용한 다. 다음 [그림 9-7]은 이를 잘 표현하고 있다.

[그림 9-7] 프락시(Proxy) 액터와의 연관(Association) 관계

액터와 유스케이스, 유스케이스와 유스케이스, 그리고 액터와 액터 간의 일차적인 관 계 설정이 끝나면, 상세 작업을 할 몇몇 유스케이스를 선택하여 유스케이스 상세화 작

224


제9장 UseCase Modeling

상세화될 수 있다. 실제로, 유스케이스와 유스케이스 간의 관계 설정은 이 상세화 작 업을 통해 더욱 많이 정의된다.

다음 [그림 9-8]은 유스케이스 다이어그램의 예제이다.

[그림 9-8] 유스케이스 다이어그램 예제

2.5

유스케이스 정의서(Usecase Specification) 작성

유스케이스 정의서 작성은 유스케이스 상세화의 첫 번째 작업이자, 좀 과장해서 말하 면, 전부이다. 자세한 내용은 다음 절에서 다루도록 한다.

225

CHAPTER 9

업을 수행한다. 이 상세화 작업을 통해, 지금까지 이야기했던 다양한 관계들은 더욱


UML기반 분석/설계

3

유스케이스 상세화

유스케이스 상세화는 초기 유스케이스에 대해 액터와의 상호작용에 따라 내부 처리 흐름을 상세화하여 유스케이스의 타당성을 확인한다. 이때, 미처 발견하지 못한 유스 케이스를 새로 추가하거나, 기존의 유스케이스들을 합치거나 나눌 수도 있고, 액터와 유스케이스와의 연관 관계를 새롭게 파악할 수도 있다. 이와 같은 상세화 작업을 반복 하여 유스케이스 모델을 정제하고 완성한다.

유스케이스 상세화는 일반적으로 다음과 같은 순서로 진행된다.

1. 초기 유스케이스 모델에 대해 액터와의 상호작용을 위한 기본 처리 흐름 (Basic Flow)을 상세히 정의한다. 2. 유스케이스 처리 흐름 중 사용자의 의사결정 부분에 대해 선택 흐름 (Alternative Flow) 또는 예외 흐름(Exceptional Flow)을 기술한다. 3. 유스케이스의 상세화 과정을 통해 신규 도출되는 유스케이스를 유스케이스 다이어그램에 추가하며, 유스케이스의 크기(Granularity)를 조정하여 유스케 이스 모델을 정제한다.

이와 같은 작업을 수행하기 위한 유스케이스 상세화의 핵심은 유스케이스 정의서를 작성하는 것이다. 『Advanced Use Case Modeling 』에서는 유스케이스의 구조를 유 스케이스 이름과 유스케이스 몸통으로 나누고, 이벤트 흐름(Flow of events), 액터 (Actors), 선행 조건(Precondition), 완료 조건(Postcondition)을 기본으로 포함한 유 스케이스 정의서를 유스케이스의 몸통이라고 정의할 만큼, 유스케이스 정의서의 비중

226


제9장 UseCase Modeling

지 않고, 유스케이스 정의서와 함께할 때야 비로소 진정한 유스케이스 모델이 되는 것 이다.

유스케이스 정의서는 유스케이스 다이어그램에서 정의된 유스케이스 별로 액터로부터 시작하여 시스템 범위 내에 있는 특정 기능(functionality)을 수행하는 일련의 작업 흐 름(일련의 사건) 또는 비즈니스 관점의 트랜잭션의 순차적인 흐름을 기술한다. 또한, 유스케이스 정의서는 향후 개발할 기능에 대한 정의서(specification)를 작성하는 시발 점이 된다. 다음은 유스케이스 정의서를 통해 우리가 얻을 수 있는 것들이다. •

원활한 의사소통의 지원

향상된 모델 작성 지원(일관성의 향상)

체계적인 S/W문서 작성 기법을 제공

테스트의 기준을 제공

재사용성을 제공

그러나, UML에서는 액터나 유스케이스, 유스케이스들 간의 관계와 같은 구성요소와 그것들이 서로 어떻게 연계되어 전체적인 모습을 보여 주는 지에 대해서만 정의하고 있을 뿐, 유스케이스를 상세히 기술하는 방법에 대해서는 언급하고 있지 않다. 즉, 유 스케이스의 또 다른 반쪽인 유스케이스 정의서에 대해서는 표준이 정의되어 있지 않 다. 다양한 방법론이나 서적에는 유스케이스 정의서를 어떠한 형태로 어떻게 작성해야 하는지를 제시하고 있고, 그래서 다양한 형태의 유스케이스 정의서가 정의되어 사용되 고 있다. 그러면서 업계 표준이라고 불릴 수 있을 만한 베스트 프랙틱스(BP: Best Practice)가 정립되어 있는 것이 현 상황이다.

다음 [그림 9-9]는 일반적으로 우리가 사용하는 유스케이스 정의서의 모습이다. 유스 케이스 정의서에는 유스케이스명, 개요, 처리 흐름, 액터(Initiator와 Supporters), 선 행 조건, 완료 조건을 반드시 기술해야 한다.

227

CHAPTER 9

을 높게 하고 있다. 즉, 유스케이스 만으로는 진정한 유스케이스 모델의 반쪽밖에 되


UML기반 분석/설계

[그림 9-9] 유스케이스 정의서 양식

프로젝트의 규모가 작아 산출물 작성의 형식에 그리 큰 비중을 두지 않는 경우나 혹 은 기민한(Agile) 방법론을 채택해서 산출물의 신속한 작성과 변경이 요구되는 경우에 는 유스케이스 정의서의 형식을 간략하게 사용하는 것이 좋다. [그림 9-10]은 이에

228


제9장 UseCase Modeling

의서 양식은 초기에 유스케이스에 대해 간략히 기술할 때 사용하여, 실제 [그림 9-9] 와 같은 유스케이스 정의서를 작성하기 위한 초안으로 활용할 수 있다.

[그림 9-10] 간략한 유스케이스 정의서 양식

유스케이스에서 나타나는 항목들을 살펴보면 다음과 같다. λ 유스케이스명: 유스케이스 이름을 기술한다. λ 유스케이스 ID: 시스템 내에서 유일한 이름을 부여하는 것이 원칙이지만, 보다 명 확히 하기 위해 유스케이스 ID를 활용할 수 있다. 관리 측면에서 사용한다. λ 개요: 유스케이스가 수행하는 기능을 간략하게 기술한다. λ Relationships: 유스케이스와 관련된 사항들에 대해 기술한다. •

Initiator: 유스케이스를 기동시키는 액터를 기술한다.

Supporters: 유스케이스의 수행에 참여하는 액터들을 나열한다.

Precondition: 유스케이스가 수행되기 위한 선행 조건을 기술한다.

Postcondition: 유스케이스가 성공적으로 수행되었음을 보증하는 완료 조건을 기술한다.

λ Flow of Events: 유스케이스를 수행하는 상세한 흐름을 기술한다. 이 흐름은 성격 에 따라 다음과 같이 세 가지로 분리된다. [그림 9-11]은 세 가지 처리 흐름에 대 해서 액티비티 다이어그램 형태로 표현한 모습이다.

229

CHAPTER 9

따른 간략화한 양식의 유스케이스 정의서의 모습이다. 또한, 이 간략한 유스케이스 정


UML기반 분석/설계

Basic Flow: 유스케이스에 해당하는 기능의 목적을 성공적으로 달성하기 위한 기본적인 처리 흐름을 기술한다. 유스케이스에 하나만 존재한다.

Alternative Flows: 액터의 선택에 따라 기본적인 처리 흐름에서 벗어나 분기되 는 처리 흐름을 기술하지만, 유스케이스에 해당하는 기능의 목적을 성공적으로 달성한다. 액터의 선택에 따라 여러 개가 존재할 수 있다.

Exception Flows: 유스케이스 수행을 처리하던 중 오류가 발생하여 정상적으로 유스케이스를 수행할 수 없을 때, 예외 처리 흐름을 기술한다. 액터의 재입력을 요구하여 정상적인 흐름을 진행하도록 하거나 유스케이스 수행을 종료시킨다.

Basic Flow

[그림 9-11] Flow of Events에 대한 액티비티 다이어그램

λ Special Requirements: 유스케이스에 대한 기능 외적인 요구사항을 명시할 수 있 다.

230


제9장 UseCase Modeling

때, 그 조건이 발생하는 지점에 대해 기술한다. λ Note: 유스케이스에 대한 이해에 도움이 되는 고려사항이나 참조사항을 기술한다. λ 시나리오: 해당 유스케이스에 대한 실제 사례를 기술한다. 이는 나중에 테스트 시 나리오를 작성하는 데 큰 도움을 준다.

유스케이스 정의서의 내용 중 가장 중요한 점은 누가 뭐래도 처리 흐름을 기술하는 것이다. 처리 흐름은 일반적으로 다음과 같은 것을 고려하여 기술한다. •

고객이 이해할 수 있는 용어로, 용어사전에 정의된 용어를 사용하여 작성하도록 한다.

애매한 표현은 삼간다. (예를 들면, 기타, 정보 등)

이해를 쉽게 하기 위해 그림을 삽입할 수 있다.

문장은 간결하고 명확하게 기록한다.

해당 유스케이스의 범위에 속하는 것들을 기술한다.

그러나 유스케이스의 처리 흐름을 반드시 작성해야 하는 것만은 아니다. 다음과 같은 경우에는 이를 생략할 수 있다. 특정한 흐름이 없는 유스케이스, 일반화에 의해 추상 화된 유스케이스, 또는 다른 유스케이스에 포함되는 작은 기능 단위인 유스케이스 등 이 그렇다. 단, 흐름에 대한 기술을 생략할 때에는 설명 부분에 간략한 흐름을 자유로 운 문장으로 기술하는 것이 좋다.

다음 [그림 9-12]는 유스케이스 정의서의 예제이다.

231

CHAPTER 9

λ Extension Points: 해당 유스케이스가 특정 조건에 따라 다른 유스케이스를 확장할


UML기반 분석/설계

[그림 9-12] 유스케이스 정의서 예제

유스케이스 처리 흐름을 기술하면서, 다음과 같이 유스케이스 모델을 정제할 수 있다. 다음은 유스케이스 모델의 정제를 위한 가이드라인이다. •

여러 유스케이스 정의서를 작성하면서 반복적으로 기술되었고, 여러 유스케이스 정의서에 중복되어 나타난 처리 흐름에 대해서는 별도의 유스케이스로 도출하 고, 기존 유스케이스와는 포함 관계로 설정한다.

코번의 『Writing Effective Use Cases』에서는 하나의 유스케이스는 사건 흐 름에 보통 3~9 스텝 정도를 밟는 것이 좋다고 가이드한다. 즉, 2 스텝으로 끝 나버린다거나 10 스텝 이상으로 길어지는 것은 유스케이스를 이해하는 데 별로

232


제9장 UseCase Modeling

거나 다른 유스케이스로 통합할 수 있다. 또한, 10 스텝 이상의 유스케이스는 여러 개의 유스케이스로 나누는 것을 고려해야 한다. •

복잡한 프로세스를 처리하는 유스케이스의 경우, 그 처리 흐름을 액터와 시스템 간에 실제로 상호작용하는 이벤트에 따라 보다 세부적으로 분리할 수 있다. 그 에 따라 미처 파악하지 못한 유스케이스를 새롭게 도출할 수 있다.

유스케이스 상세화 중 액터와 유스케이스 및 유스케이스와 유스케이스 간의 연 관 관계 정의를 통해 도출되는 공통 부분, 일반화 부분을 별도의 유스케이스로 정의한다.

유스케이스 정의서를 작성하면서, 사용자가 요구하는 시스템의 기능 개발을 위 해 추가되어야 할 기능을 발견할 수 있고, 이를 유스케이스로 도출하여 유스케 이스 모델에 반영한다. 예를 들어, 사용자 또는 고객이 시스템의 기능으로 직접 요구하지는 않았으나 ‘사용자 관리’ 기능을 유스케이스로 도출하여 추가할 수 있다.

이와 같이 유스케이스 정의서를 작성하면서, 우리는 기존 유스케이스 모델을 더욱 살 찌우고 다양한 개선 사항을 발견해 낼 수 있다. 유스케이스 상세화 작업은 한 번 하고 끝나는 그런 일이 아니고, 반복적으로 계속되면서 유스케이스 모델을 완성시켜 나가게 한다. 따라서, 최초에 식별된 액터, 유스케이스 목록이 마지막 단계까지 동일한 상태 로 유지되는 경우는 드물다. 유스케이스 상세화를 통해, 액터 및 유스케이스의 목록을 반복적으로 정제하고 유스케이스 모델의 완전성을 향상시킨다.

233

CHAPTER 9

좋지 않다. 따라서 2 스텝 이하의 유스케이스는 처리 흐름을 아예 기술하지 않


UML기반 분석/설계

4

Case Study

사내에서 사용할 전자결재 시스템에 대해 다음과 같은 요구사항이 있다.

R-1.

상신자는 상신할 문서의 제목과 본문을 작성하고 결재자를 지정한 후, 결 재자에게 상신한다. 필요할 경우 문서를 첨부한다.

R-2.

상신된 문서는 상신자의 상신함에 보관된다.

R-3.

상신자는 상신 문서의 진행 상황을 조회할 수 있다. 결재자 별 결재 상태 와 결재 시간, 그리고 결재 의견을 조회할 수 있다.

R-4.

결재자는 미결함에서 결재할 서류의 목록을 조회하고, 결재할 문서의 상세 내용을 조회한다. 첨부 파일이 있는 경우 첨부 파일을 조회한다. 결재 의 견을 기입한 후 결재(승인 또는 반려)한다.

R-5.

결재 문서의 결재 시간은 자동으로 기록되며, 결재 문서는 결재자의 기결 함에 저장된다.

R-6.

결재자가 승인할 경우 상신 문서는 다음 결재자에게 통보된다. 최종 결재 자가 승인할 경우 상신자에게 통보된다.

R-7.

결재자가 반려할 경우 상신자에게 반려되었음을 알린다.

R-8.

상신자가 문서를 상신할 때, 통보를 문자 메시지로 받게끔 선택했다면, 추 가적으로 SMS 를 이용하여 문자 메시지를 상신자에게 보낸다.

R-9.

결재자와 상신자는 결재된 문서를 상신자 또는 부서 이름으로 검색하고 상 세 정보를 조회할 수 있다.

위와 같이 주어진 요구사항에 따라 유스케이스 모델링을 앞에서 배운 절차와 방법으

234


제9장 UseCase Modeling

CHAPTER 9

로 수행해 보도록 한다.

4.1

요구사항 정의

위에서 나타난 요구사항에 대해 정형화된 형태로 표현할 수 있다. 다음 [표 9-5]는 요구사항 정의서 양식으로 전자결재 시스템의 요구사항을 표현하고 있다.

[표 9-5] 요구사항 정의서

4.2

시스템 범위(System Boundary) 설정

사내 시스템 중에 전자결재 시스템만을 우리가 구축해야 하는 것을 상기하여, 시스템

235


UML기반 분석/설계

범위를 설정한다.

4.3

액터(Actor) 정의

주어진 요구사항에서 행위자를 식별해 낸다. 이때, 실제로 시스템을 사용하는 사원이 나 관리자 등으로 액터 이름을 정할 수도 있으나, 시스템을 사용하는 역할을 고려하여 상신자와 결재자로 액터 이름을 정하는 것이 바람직하다.

우리는 다음과 같이 두 개의 액터를 식별해 낼 수 있고, 각각의 액터에게 제공되어야 하는 기능을 요구사항으로부터 나열해 보았다. •

상신자

상신문서 작성, 상신문서 상신, 문서 조회, 문서 검색

결재자

문서결재, 문서조회

SMS

문자 메시지 전송

4.4

유스케이스(Usecase) 정의

주어진 요구사항에서 유스케이스를 식별해 낸다. 이는 요구사항 중에 기능적 요구사항 을 도출하여 유스케이스로 정의하는 것이다.

위 요구사항 정의서와 앞에서 정의한 액터에 따라 유스케이스를 식별하면 다음과 같 다.

236


제9장 UseCase Modeling

문서 상신: R-1에서 상신자가 시스템을 이용하여 문서를 상신하는 것을 설명하 고 있다.

상신문서 조회: R-3에서 문서를 조회하는 기능이 필요함을 알 수 있다.

결재문서 검색: R-9에서 문서 검색 기능을 사용함을 알 수 있다.

λ 결재자 •

결재문서 조회: R-4에서 결재자 역시 문서를 조회하는 기능을 사용함을 설명하 고 있다.

문서 결재: R-4, 5, 6, 7에서 결재자는 결재 기능을 사용함을 설명하고 있다.

결재문서 검색: R-9에서 결재자도 검색 기능을 사용함을 알 수 있다.

4.5

관계(Relationships) 설정

액터와 유스케이스 찾기가 끝나면, 이들 간의 관계를 설정한다. 이 단계에서 유스케이 스 다이어그램을 직접 작성한다.

서로 관계가 있는 액터와 유스케이스를 연관 관계로 설정하여, 다음 [그림 9-13]과 같이 유스케이스 다이어그램을 작성한다.

237

CHAPTER 9

λ 상신자


UML기반 분석/설계

전자결재시스템

System

문서 상신

상신문서 조회

상신자 결재문서 조회 결재자

문서 결재

결재문서 검색

SMS

[그림 9-13] 초기 유스케이스 다이어그램

4.6

유스케이스 정의서(Usecase Specification) 작성

유스케이스 다이어그램 작성이 끝나면, 유스케이스 상세화 작업을 위해 각각의 유스케 이스에 대해서 유스케이스 정의서를 작성한다.

다음은 ‘문서 상신’ 유스케이스 정의서 중 처리 흐름에 대한 부분만 발췌한 것이다.

238


제9장 UseCase Modeling

CHAPTER 9

--중략--

3. Flows of Events 3.1

Basic Flow 1.

2.

3.

3.2

문서 작성 1.1

상신자는 문서 상신을 위한 문서 작성을 요청한다.

1.2

시스템은 상신하기 위한 화면을 제공한다.

1.3

상신자는 상신할 문서의 제목 및 내용을 작성한다.

1.4

상신자는 필요할 경우 첨부 파일을 첨부한다.

결재자 지정 2.1

상신자는 결재자로 추가할 사람의 이름을 입력하고 요청한다.

2.2

시스템은 해당 이름으로 조회하여, 해당 결재자 정보를 가져온다. (A-1)

2.3

시스템은 결재자를 추가하여 화면에 보여 준다.

2.4

결재자를 추가할 경우, {2.1~2.3}을 반복한다.

문서 상신 3.1

상신자는 문서를 상신한다.

3.2

시스템은 상신 의견과 문자 메시지 전송 여부를 추가로 요구한다.

3.3

상신자는 상신 의견과 문자 메시지 전송 여부를 기입하고, 최종 상신한다.

3.4

시스템은 상신 문서를 저장한다.

Alternative Flows A-1.

3.3

동명이인이 존재할 경우 1.

시스템은 동명이인 목록을 보여 준다.

2.

상신자는 해당 결재자를 선택한다.

3.

2.3 을 수행한다.

Exceptional Flows

--중략--

기본 흐름(Basic Flow)을 작성하다가 어떤 선택에 따라 대안 흐름(Alternative Flows)

239


UML기반 분석/설계

이 발생한다면, 해당 스텝 뒤에 (A-1)과 같이 소괄호 안에 Alternative를 상징하는 A 로 번호를 붙여 기술한다. 위 예의 기본 흐름 2.2는 이를 잘 보여준다.

마찬가지로 예외적인 흐름(Exceptional Flows)가 발생할 경우에는 해당 스텝 뒤에 (E-1)과 같이 E로 번호를 붙여 기술한다.

대안 흐름이나 예외적인 흐름에 대해서는 별도로 기본 흐름 밑에 기술하는데, A-1이 나 E-1과 같이 번호를 붙여 해당 흐름에 대해 기술한다.

반복을 표현할 경우에는 중괄호를 이용한다. 위 예의 2.4는 반복을 표현하고 있다.

4.7

유스케이스 다이어그램 재작성

위와 같이 유스케이스 정의서를 작성하다 보면, 여러 유스케이스 정의서에서 반복적으 로 나타나는 부분에 대해서 별도의 유스케이스로 식별하거나, 복잡한 유스케이스 정의 서를 두 개의 유스케이스로 나누거나 하는 등 유스케이스를 상세화하면서 유스케이스 를 정제할 수 있다.

다음 [그림 9-14]는 최종적으로 작성된 유스케이스 다이어그램의 모습이다.

240


제9장 UseCase Modeling

CHAPTER 9

ud 최종 유스케이스 다이어그램 전자결재시스템

문서 상신

«include»

사용자 검색 통합사용자시스템

상신자 상신문서 조회

결재된문서 검색

문서 조회

직원

결재문서 조회

결재자 문서 결재 SMS

[그림 9-14] 최종 유스케이스 다이어그램

위에서 ‘문서 상신’ 유스케이스 정의서를 작성하면서, 결재자 선택을 위해 ‘사용자 검 색’이 필요함을 알게 되었다. 이를 위해, 사용자 정보를 조회해 올 ‘통합사용자시스템’ 액터를 레가시 시스템으로 새롭게 식별했고, 그 기능을 담당할 ‘사용자 검색’ 유스케 이스를 새롭게 식별했다. 그리고 ‘사용자 검색’ 유스케이스를 기존 ‘문서 상신’ 유스케 이스에 포함(Include) 관계로 설정했다.

‘상신문서 조회’와 ‘결재문서 조회’ 유스케이스 정의서를 작성하다 보면, 동일한 스텝 이 많이 나타남을 알 수 있을 것이다. 대부분의 처리 흐름이 동일하나 세부적인 내용 이 달라질 뿐이다. 따라서, 이 두 유스케이스를 일반화(Generalization)하여 ‘문서 조 회’ 유스케이스를 새롭게 식별하였다. 그리고 이 ‘문서 조회’ 유스케이스를 ‘상신문서

241


UML기반 분석/설계

조회’와 ‘결재문서 조회’ 유스케이스에서 일반화 관계로 설정했다.

마지막으로 ‘상신자’와 ‘결재자’가 같이 사용하는 ‘결재된 문서 검색’ 유스케이스를 위 해 ‘직원’이라는 액터를 일반화하여 식별했다. 그리고 유스케이스를 두고 왼쪽에는 사 용자 액터를, 오른쪽에는 외부 시스템 액터를 표현하여, 유스케이스 다이어그램의 가 독성을 향상시켰다. 사용자 액터 왼쪽, 외부 시스템 액터 오른쪽은 대부분의 유스케이 스 작성자들이 지키는 일종의 관습과도 같은 것이다.

242


Chapter

10

Structural Modeling - Analysis

1 절 객체 모델링 2 절 유스케이스 정적 분석 3 절 Case Study

학습목표 Φ 객체 모델링에 대해 학습한다. Φ 객체 모델링을 기반으로 유스케이스를 정적으로 분석하는 방법을 학습한 다. Φ 유스케이스 정적 분석을 통해, 클래스 다이어그램을 작성하는 방법을 학습 한다.


분석 단계의 구조적 모델링에서는 유스케이스 정적 분석 작업을 수행한 다. 유스케이스 정적 분석을 통해, 유스케이스 수행을 담당할 클래스를 도출하고 클래스의 속성과 상관 관계를 정의한다. 이 장에서는 먼저 구조적 모델링의 기본인 객체 모델링에 대해서 살펴 본 다음, 시스템에서 실제로 유스케이스 기능을 제공하기 위한 클래스 들을 어떻게 도출하고 관계를 정의하는지, UML을 사용한 전반적인 구 조적 모델링 기법에 대해 배워 본다.


제10장 Structural Modeling - Analysis

CHAPTER 10

1

객체 모델링

본격적으로 유스케이스 정적 분석을 이야기하기 전에, 객체 모델링(Object Modeling) 에 대해 알아보기로 하겠다. 이를 통해 유스케이스 정적 분석을 좀더 쉽게 이해할 수 있을 것이다.

객체 모델링은 다음과 같은 세 가지 주요한 작업으로 이루어진다.

1.

Object Name: 가장 먼저 개발할 소프트웨어나 시스템을 구성할 후보 객체들 을 찾아야 한다.

2.

Object Responsibilities: 이렇게 찾아진 후보 객체들에게 책임을 할당하여 후 보 객체들을 정제하고 역할을 분명히 할 수 있다.

3.

Object Collaborators: 마지막으로 그에 따른 객체들 간의 협력 관계를 찾아 서 정의한다.

CRC(Candidates, Responsibilities, Collaborators) 카드 기법을 통해, 이와 같은 객체 모델링을 간단하면서도 별다른 도구 없이 쉽게 할 수 있다. CRC 카드 기법은 1989년 에 OOPSLA’89에서 켄트 벡(Kent Beck)과 워드 커닝험(Ward Cunningham)이 소개하 여, 객체지향 설계에서 가시적으로 객체를 설계하는 방법으로 널리 사용하고 있다. 다 음 [그림 10-1]은 CRC 카드의 모습이고, CRC 카드는 빈 종이나 포스트잇으로 사용 할 수 있다(포스트잇이 가장 널리 사용된다).

245


UML기반 분석/설계

[그림 10-1] CRC 카드

한 CRC 카드는 하나의 객체에 대한 내용으로 이루어져 있고, 그 한 객체의 이름과 책임, 협력 관계를 표현한다.

『Object Design』에서는 [그림 10-1]의 CRC 카드를 확장하여 설명하고 있다. 카드 의 앞면에는 후보 객체의 이름과 설명(목적, 역할, 특징 등)을 기술하고, 뒷면에는 그 객체의 책임과 협력 객체를 나열한다. 즉, 앞면에는 간략한 정보만 표현되고, 뒷면에 는 좀더 자세한 정보가 표현되는 것이다. 여기서 말하는 CRC 카드 기법의 작업 순서 는 다음과 같다. 먼저, 객체의 이름과 설명을 앞면에 작성하여 의논하면서 후보 객체 들을 선별해 내고, 그렇게 선별된 후보 객체들의 카드 뒷면에 그 객체의 책임과 그 책 임에 따른 협력 객체들을 할당하면서 다시 한 번 객체의 타당성을 검증한다. 이렇게 카드가 객체를 식별하는 장소에서 여러 번 돌고 난 다음에는 최종 후보 객체들이 나 타날 것이다.

이렇게 CRC 카드 기법을 통해 객체들의 이름과 책임, 협력 관계들이 모두 정의되면, UML을 이용하여 객체 또는 클래스 다이어그램을 작성할 수 있다. 다이어그램이 작성 된 후부터는 더 이상의 CRC 카드를 만들지 않아도 된다. 다음 [그림 10-2]는 CRC 카드를 객체 또는 클래스 다이어그램으로 전환하는 모습이다.

246


제10장 Structural Modeling - Analysis

CHAPTER 10

[그림 10-2] CRC 카드의 클래스 다이어그램으로의 전환

객체는 크게 두 가지 종류, 도메인 객체(Domain Object)와 어플리케이션 특화된 객체 (Application-Specific Object)로 구분할 수 있다. 이 중 도메인 객체는 해당 비즈니스 분야에 대한 실 세계를 반영한 산물이고, 이 도메인 객체를 정의함으로써, 해당 시스 템이 비즈니스를 정확히 반영하게 하고, 해당 시스템에 대한 고객의 이해력을 높일 수 있다. 도메인 객체는 해당 비즈니스 분야에 존재하는 정보(Information)와 서비스 (Service)를 표현한다. 그리고 어플리케이션에 특화된 객체는 이와 같은 도메인 객체 가 시스템 측면에서 구현될 수 있도록 돕는다. 즉, 도메인 객체가 사용자 요청에 응답 하고, 시스템 실행을 컨트롤하고, 외부 시스템과 연결할 수 있도록 돕는다.

도메인 객체만을 정확히 정의하기 위해, 별도의 객체 모델링 작업을 수행할 수 있는데, 이를 ‘도메인 모델링’이라고 부른다. 도메인 모델링은 일반적으로 유스케이스 모델링 전에 수행된다. 왜냐하면 이를 통해 생성되는 도메인 모델은 전반적인 비즈니스의 상 황을 파악하고 이해하고 유스케이스를 작성하는 데 도움을 줄 수 있기 때문이다. 도메 인에 대한 보다 많은 이해는 유스케이스를 통한 요구사항의 정의를 보다 쉽게 하고, 프로젝트 전반적인 공감대를 형성할 수 있게 한다. 특히, 규모가 큰 엔터프라이즈 환 경에서 개발하는 시스템일수록, 해당 비즈니스에 대한 도메인 객체를 식별하는 것은 더욱 중요한 의미를 지닌다.

247


UML기반 분석/설계

어플리케이션에 한정된 객체는 일반적으로 유스케이스 분석 시에 최초로 정의된다. 우 리는 다음 절에서 이에 대해 자세히 알아 볼 것이다.

객체 모델링은 모든 구조적 모델링의 기본이다. 우리는 이를 바탕으로 앞으로의 모든 구조적 모델링을 수행할 것이다.

248


제10장 Structural Modeling - Analysis

CHAPTER 10

2

유스케이스 정적 분석

유스케이스 분석은 유스케이스 모델을 분석하여, 유스케이스를 시스템에서 구현하기 위해 필요한 내부 구성요소들을 찾아내어 정의한다. 유스케이스 분석은 정적 분석과 동적 분석으로 나눌 수 있는데, 이 장에서는 먼저 유스케이스 정적 분석에 대해 살펴 보겠다.

유스케이스 정적 분석은 객체, 객체들 간의 관계, 객체의 속성(Attribute), 객체의 오 퍼레이션(Operation)과 같은 시스템을 구성하고 있는 객체들의 구조를 기술하는 것이 다. 이를 통해 유스케이스 수행을 담당할 클래스를 도출하고, 클래스의 속성과 오퍼레 이션 및 상관관계를 정의할 수 있다.

일반적으로 유스케이스 정적 분석은 다음과 같은 절차에 따라 수행된다.

1.

객체/클래스 찾기

2.

클래스들 간의 관계(Relationships) 찾기

3.

속성(Attribute) 및 오퍼레이션(Operation) 찾기

4.

패키지(Package)로 묶기

위의 절차에 따라 수행하는 것도 중요하지만, 각각의 작업들이 동시에 진행되거나 순 서가 뒤바뀌어 진행되기도 한다. 중요한 사실은 순서가 어찌됐든 이와 같은 작업들을 유스케이스 정적 분석 시에 수행해야 된다는 것이고, 이를 반복적으로 수행함으로써 모델을 정제하고 상세화할 수 있다는 것이다.

249


UML기반 분석/설계

최종적으로 분석 단계에서의 클래스는 유스케이스 수행에 참여하는 역할에 따라 UML 표준에서 제시하는 <<Boundary>>, <<Control>>, <<Entity>> 세 가지 스테레오 타입 (Stereo Type)을 사용하여 작성한다. 이는 역할에 따라 Model, View, Controller 클 래스를 구분하는 MVC 모델과도 깊은 관련이 있다. 그러나 최초에 클래스를 도출할 때는, 먼저 <<Entity>>에 해당하는 클래스를 도출하는 것이 일반적인 순서이고, 이 절에서는 이를 중점적으로 다루기로 한다.

2.1

객체/클래스 찾기

일반적으로 유스케이스 정적 분석에서는 요구사항 정의서, 유스케이스 정의서와 도메 인 모델(클래스 다이어그램) 등을 토대로 분석 클래스를 도출하고 속성을 정의한다. 본 과정에서는 도메인 모델링을 다루지 않으므로, 도메인 모델을 제외한 다른 산출물 로부터 분석 클래스를 도출할 수 있다. 다음 [그림 10-3]은 유스케이스 정적 분석에 서 객체를 찾는 모습을 형상화하고 있다.

[그림 10-3] 유스케이스 정적 분석에서의 클래스 식별

250


제10장 Structural Modeling - Analysis

지식과 같은 경험을 필요로 한다는 것을 알 수 있다. 이 작업은 Brain Storming이나 Brain Writing 기법을 이용하여 수행할 수 있다. 앞 절에서 배운 CRC 카드 기법을 이 용하면, 더욱 명확히 후보 클래스를 식별할 수 있다. 다음은 객체를 찾는 방법들이다. •

객체를 식별하기 전까지 작성했던 각종 문서들(요구사항 정의서, 유스케이스 정 의서 등등)로부터 명사에 해당하는 단어들을 추출하여, 후보 클래스로 식별한다. 명사에 해당하는 단어들은 객체 또는 클래스가 될 확률이 높다.

각종 문서만을 참조해서는 필요한 객체를 모두 찾을 수는 없으므로, 사용자 면 담이나 업무 지식과 경험 등을 바탕으로 새로운 후보 클래스를 식별할 수 있다. 이처럼 업무 지식을 바탕으로 객체나 클래스를 찾는 것은 매우 중요하다.

이때 앞에서 이야기한 것처럼, 클래스의 역할(Roles)에 따라 클래스를 Model, View, Controller 세 가지로 구분하여 식별할 수 있다. 이를 줄여서 MVC 모델이라고 부르 며, 분석 단계의 클래스 다이어그램은 최종적으로 이 MVC 모델을 반영해야 한다. 그 러나 유스케이스 정적 분석의 처음부터 이를 반영할 수는 없으며, 유스케이스 동적 분 석을 진행하고 반복적으로 정적 분석과 동적 분석을 수행함으로써, MVC 모델을 반영 할 수 있을 것이다. 이에 대한 자세한 내용은 다음 장에서 다루고, 여기서는 주로 Model에 해당하는 클래스를 찾는 것을 목적으로 한다. Model에 해당하는 클래스는 앞에서 이야기한 <<Entity>>의 스테레오 타입을 갖는 클래스와 일맥상통한다.

어차피 <<Entity>> 클래스만 존재하기 때문에, 찾아진 클래스에 굳이 스테레오 타입 을 부여하지 않아도 되고, 역할(Roles) 혹은 MVC 모델에 따라 클래스를 추출하려고 굳이 노력할 필요도 없다.

이렇게 Model에 해당하는 후보 클래스들에 대해서만 추출하면 된다. 이때, 너무 완벽 한 클래스들을 찾기 위해, 너무 많은 시간을 소비하는 것은 지양한다. 처음부터 너무 상세히 하기보다는 직관적으로 클래스가 될 만한 것을 빨리 찾아내 반복을 통해 정제 하고 상세화하는 것이 중요하다. 그리고 도출된 후보 클래스들을 대상으로 다음과 같

251

CHAPTER 10

위 그림을 보면, 객체를 찾기 위해서는 자료 분석뿐만 아니라 사용자 면담이나 업무


UML기반 분석/설계

은 기준으로 불필요한 클래스를 제거한다. λ 중복(Redundant) 클래스 제거 같은 의미를 지니는 클래스는 하나로 합친다. 클래스의 이름은 여러 개 중 클래스 의 성격에 가장 적합한 이름으로 한다. 경우에 따라서는 성격에 맞는 새로운 이름 을 부여할 수도 있다. 예를 들어 공항 예약 시스템에서 ‘고객’이라는 단어보다는 ‘승객’이라는 단어가 좀 더 어울릴 수 있다. λ 부적절한(Irrelevant) 클래스 제거 문제와 관련이 없는 클래스, 즉 시스템 범위 밖의 클래스는 제거한다. 해당 클래스 가 시스템 범위에 해당하는지는 사용자와의 면담을 통해 결정하는 경우도 있다. λ 모호한(Vague) 클래스 제거 클래스는 목적이 뚜렷해야 한다. 목적이 불분명하거나 광범위한 클래스는 제거한다. λ 속성(Attributes) 제거 특정 객체에 대한 설명에 사용된 이름들은 클래스가 아니라 해당 객체의 속성이 된다. 만약 특정 속성이 여러 속성을 갖는다면 이것은 속성이 아니라 클래스로 구 분해야 한다. λ 오퍼레이션(Operations) 제거 특정 객체에서 행해지는 행위를 기술하는 것은 클래스가 아니라 오퍼레이션이 된 다. 예를 들어, 일반적인 ‘전화 걸기’는 행위에 대한 것이므로 오퍼레이션이 된다. 그러나 오퍼레이션이 자신만의 속성을 가지고 있으면 클래스로 구분해야 한다. 예 를 들어 전화국 시스템의 ‘전화 걸기’는 그에 해당하는 시간, 번호, 요금 등 속성을 지니게 된다면 클래스가 되어야 한다. λ 역할(Roles) 제거 클래스는 그 자체의 본질적인 속성을 반영하는 것이지 연관 관계에서 어떤 역할을 하는 것이 아니다. 또한, 객체의 역할은 클래스가 객체화되었을 때 갖는 이름이기 도 하므로, 역할도 제거의 대상이 ���다. λ 구현 방법((Implementation Constructs) 제거 실 세계와 관계 없는 클래스는 분석 단계에서 제외한다. 또한 linked list, array,

252


제10장 Structural Modeling - Analysis

래스들이며 이러한 것들은 설계 단계 이후에 나타나게 한다.

위와 같은 기준으로 불필요한 클래스를 제거하고 나면, 최종 후보 클래스들만 남는다.

2.2

클래스들 간의 관계(Relationships) 찾기

이제, 이 클래스들을 가지고 클래스와 클래스 간의 관계를 정의한다. 이를 통해 새로 운 클래스를 식별할 수도 있다.

여기서 한 가지 짚고 넘어가야 하는 점이 있다. 이는 객체를 찾는다고 하면서 최종적 으로 클래스를 식별하는 등, 객체와 클래스를 혼동하여 사용하고 있다는 것이다. 분명 히 객체와 클래스는 다르다. 그러나 객체는 클래스를 인스턴스화한 것이므로 객체를 찾아냄으로써 클래스를 찾아낼 수 있고, 더 나아가 대표 객체를 찾아냄으로써 클래스 를 식별할 수 있다. 어찌 보면, 객체를 찾는다고 하는 것은 시스템 개발의 입장에서는 클래스를 찾는다는 것이 더욱 정확한 표현일 수도 있겠다.

특히, 관계(Relationships)를 말 할 때는 더욱 클래스들 간의 관계라고 이야기하는 것 이 옳다. 왜냐하면 관계는 있었다 없었다 하는 동적인 것이 아니라, 있거나 없는 정적 인 것이기 때문이다. 객체는 클래스를 인스턴스화한 순간적인 것이므로, 객체들 간의 상호작용은 결국 클래스의 정적인 관계를 통해서 발생한다.

클래스들 간의 관계(Relationships)는 클래스들 간의 순간적이고 이벤트성 관계라기보 다는 지속적이고 정적인 관계이다. 이와 같은 관계를 찾기 위해, 각종 문서들(요구사 항 정의서, 유스케이스 정의서 등등)로부터 동사나 동사구에 해당하는 단어를 중심으 로 추출한다. 다음은 클래스들 간의 관계를 찾는 방법들이다.

253

CHAPTER 10

tree, table 등과 같이 자료 구조나 알고리즘과 관련된 것은 구현 방법과 관련된 클


UML기반 분석/설계

한 클래스가 다른 클래스를 참조(Reference)하면, 두 클래스 간에 관계가 있다.

클래스의 속성이 복합 정보를 가져야 할 경우, 별도의 클래스로 식별한 뒤 두 클래스 간을 관계 짓는다.

클래스 간에 정보의 교환(Communication)이 있다면, 두 클래스 간에 관계가 있다.

클래스가 다른 클래스를 소유하는 것도 두 클래스 간의 관계가 된다.

클래스가 다른 클래스의 특정 조건을 만족시키는 경우에도 두 클래스 간의 관 계가 된다.

위 방법으로 클래스 간의 다양한 관계를 정의할 수 있다. 다음 [표 10-1]은 클래스들 간의 관계들을 다시 한 번 정리하여 보여준다.

[표 10-1] 클래스들 간의 관계 요약 관계(Relationship)

설명(Description) 의미상 연결되는 클래스들 간의 구조적 관계를 표현한다.

연관(Association)

Person

1..*

Work

+Employee

0..1

Company

+Employer

연관(Association) 관계의 일종으로, 한 클래스가 다른 클래스에 속하거나 포함되는 전체(whole)와 부분(part) 간의 구조적 관계 를 표현한다. Car

집합(Aggregation)

Chassis

Engine

Wheel

집합(Aggregation) 관계보다 강한 전체(whole)와 부분(part) 간 결합(Composition)

의 구조적 관계를 표현한다. 전체가 부분을 소유하는 의미를 가 지고 있고, 부분의 생명 주기가 전체의 생명 주기를 따른다(즉,

254


제10장 Structural Modeling - Analysis

CHAPTER 10

전체가 사라지는 경우 모든 부분도 사라진다). Report

Header

Body

Footer

객체지향의 특징적인 개념 중 하나인 상속(Inheritance)을 표현 한다. 고객

일반화(Generalization)

주고객

정의와

구현

부고객

관계를

표현한다.

일반적으로

인터페이스

(Interface)와 이를 구현하는 클래스를 연결할 때 사용한다.

실체화(Realization)

<<interface>> Interface

Implementaion Class

Implementaion Class Interface

지속적이지 않은 일시적인 상태를 표현하는 매우 약한 관계이다. 즉, 한 클래스가 다른 클래스를 필요로 할 때 일시적으로 사용하 고, 다 쓰고 나면 버린다는 것으로서, 클래스의 구조에는 영향을 의존(Dependency)

주지 않고 기능 수행에만 영향을 준다. Contorol

연관 클래스

Model

연관 자체가 속성을 가질 때 연관 클래스로 표현한다.

255


UML기반 분석/설계

(Association Class) Person

1..*

0..1

+Employee

Company

+Employer

Job +Salary

같은 클래스 내에서 생성된 객체들 사이에서 형성되는 관계를 의미한다. 재귀 연관 (Reflexive Association)

관리한다 +관리자

직원 +사원

이렇게 해 다양한 클래스들 간의 관계를 찾을 수 있다. 마찬가지로 이때, 너무 완벽하 게 클래스들 간의 관계를 찾기 위해, 너무 많은 시간을 소비하는 것은 지양한다. 처음 부터 너무 상세히 하기 보다는 직관적으로 관계가 될 만한 것을 빨리 찾아내, 이를 반 복을 통해 정제하고 상세화하는 것이 중요하다. 그리고 도출된 관계들을 대상으로 다 음과 같은 기준으로 불필요한 관계를 제거한다. λ 제거된 클래스와의 관계 찾아진 동사구가 이미 제거된 클래스와의 관계를 표현할 경우에 제거된 클래스가 다른 이름으로 표현되면 그 클래스와 연결하고 그렇지 않으면 제거한다. λ 부적절하거나 구현에 해당하는 것 찾아진 관계가 문제 영역의 범위를 벗어나거나, 구현에 필요한 조건인 경우에는 분 석 단계에서는 제외하고 설계 이후 단계에서 반영한다. λ 행위 또는 기능 연관 관계는 업무 영역의 구조적 특성을 반영하여, 클래스의 정적 구조를 표현하는 것이다. 일시적인 사건이나 행위에 해당하는 표현은 제거한다. 이 관계를 반드시 표현하는 것이 전반적인 모델의 가독성을 높일 경우, 의존(Dependency) 관계로 표

256


제10장 Structural Modeling - Analysis

λ 삼진(Ternary) 또는 그 이상의 연관 관계 대부분의 세 개 이상의 클래스 간의 연관 관계는 두 개의 이진 연관 관계로 분해 하거나 한정 연관(Qualified Association) 관계로 표현할 수 있다. 즉, 이러한 형태 의 연관 관계를 표현하는 문장은 두 개의 문장으로 분리하여 기술함으로써, 삼진 연관(Ternary Association) 관계를 제거하도록 한다. λ 파생된 연관(Derived Association) 관계 다른 연관 관계의 의미로 정의할 수 있는 연관 관계는 제거한다. 왜냐하면 중복되 기 때문이다. 파생된 연관 관계라도 관계수(Multiplicity)가 중요하면 제거하지 않는 다. 또한, 객체의 속성으로부터 계산해 낼 수 있는 연관 관계도 제거한다. 파생된 연관 관계는 객체 모델링에 정보를 추가하지는 않지만 설계 및 구현 단계에서는 성능을 위해 파생된 연관 관계를 사용하기도 한다. 클래스들 간의 관계에 대한 정제 작업이 완료되면, 클래스 다이어그램을 최초로 작성 하고, 연관 관계를 상세하게 정의한다. 다음은 연관 관계를 상세하게 정의하기 위해 고려해야 할 사항들이다. λ 연관 관계 이름: 각각의 연관 관계에 이름을 지어 의미를 부여한다. 연관 관계의 이름은 해당 연관 관계가 무엇인가(What it is)를 표현한다. 어떻게(How) 또는 왜 (Why)를 기술하는 것은 아니다. λ 연관 관계의 양쪽 끝 이름: 역할(Role) 이름이라고도 한다. 이는 한 클래스가 다른 클래스에 대해 어떤 역할을 수행하는 지를 표현한다. ‘클래스 A가 클래스 B를 ~ 한다’ 형태로 될 때 ‘~’에 해당하는 것이 주로 그 이름이 된다. 두 클래스가 하나 의 연관 관계만 있고 클래스 이름으로도 충분히 역할을 유추할 수 있는 경우에는 생략할 수 있다. λ 한정 연관(Qualified Association): 일반적으로 특정 상황에서 객체마다 서로 다른 이름을 가질 수 있지만 모든 객체가 유일한 이름을 가지고 있지는 않다. 여러 개의 객체 중 유일한 객체를 찾기 위한 조건이 필요할 때 한정자(Qualifier)를 사용하고, 일반적으로 복잡한 관계에 사용한다.

257

CHAPTER 10

현할 수도 있다.


UML기반 분석/설계

λ 관계수(Multiplicity): 관계되어 있는 두 클래스 간에 한 클래스의 객체와 관계를 가질 수 있는 다른 클래스의 객체 개수를 표현한다. 즉, 관계에 참여하는 두 클래 스들의 객체 개수를 나타낸다. 만약, 어떤 클래스 간에 m : n 관계가 형성되었다면, 두 클래스 간에 별도의 관계 클래스를 생성하고 그 관계 클래스와 두 개의 1 : n 관계로 전환시키는 것이 좋다. λ 항해성(Navigability): 관계되어 있는 두 클래스 간에 한 클래스만이 다른 클래스의 존재를 알 경우, 클래스를 참조할 수 있는 방향으로 단방향 연관 관계로 표현한다. λ 파악하지 못한 연관 관계: 업무 지식을 바탕으로 각종 산출물에서 찾을 수 없었던 연관 관계를 찾아서 연결한다. 이제 클래스들 간의 관계까지 정제되어 반영된 초기 클래스 다이어그램이 나타날 것 이다. 경우에 따라서는, 여기까지 작업한 클래스 다이어그램을 최종 분석 클래스로 사 용해도 된다. 그만큼, 향후에 작업할 속성(Attribute) 및 오퍼레이션(Operation) 찾기 와 패키지(Package)로 묶기는 분석 클래스 다이어그램을 작성하는 과정에서 중요하지 않다는 것이다.

2.3

속성(Attribute) 및 오퍼레이션(Operation) 찾기

일차적으로 완성된 클래스 다이어그램에, 클래스를 찾을 때 나열된 명사 중에서 속성 (Attribute)과 오퍼레이션(Operation)으로 분류된 명사들을 각 클래스의 멤버로 소속 시킨다. 이때, 속성과 오퍼레이션을 위치시킬 마땅한 클래스가 없다면, 별도의 클래스 를 식별하여 위치시킬 수도 있다.

분석 단계에서는 클래스가 지니는 모든 속성과 오퍼레이션을 도출하려고 노력할 필요 가 없다. 속성과 오퍼레이션은 다음 절에서 배울 동적 분석이나 설계 단계에서 자연스 럽게 필요에 따라 도출될 것이다.

258


제10장 Structural Modeling - Analysis

CHAPTER 10

다음 [그림 10-4]는 여기까지 완성된 클래스 다이어그램의 예제이다.

[그림 10-4] 클래스 다이어그램 예제

2.4

패키지(Package)로 묶기

마지막으로 할 일은 찾아진 클래스들을 논리적으로 긴밀하게 연관된 것들끼리 분류하 여 패키지(Package)로 묶는 것이다. 이는 복잡한 시스템의 경우 클래스가 많이 존재하기 때문에, 관리하기 어려워 지거나 이해하기 어려워 지는 것을 방지하기 위해서이다.

클래스 분류 방법은 서브시스템, 레이어, 업무, 기능 등 여러 단위로 분류할 수 있지 만, 분석 단계에서는 시스템이나 업무에 따라 분류하는 것이 적합하다.

259


UML기반 분석/설계

일반적으로 클래스 분류의 최상위 단계에서는 서브시스템 또는 레이어 단위로 나누고, 클래스 분류의 두 번째 단계에서는 업무 단위로 밀접한 관계가 있는 클래스들로 나눈 다. 또한, 공통적으로 사용되는 클래스들은 따로 분류한다. 물론 이는 시스템 전반적 인 소프트웨어 아키텍처와 연관되는 정의되어야 하는 사항이므로, 반드시 이렇게 해야 만 하는 것은 아니다. 다만, 클래스 분류 시 적용할 수 있는 일반적인 방법으로 이해 하면 될 것이다.

클래스를 패키지로 묶어, 패키지 안의 클래스들 모습까지 함께 보여주어야 할 경우에 는 클래스 다이어그램을 이용한다. 그러나 패키지들 간의 관계만을 표현할 경우에는 UML 2.0부터 제공되는 패키지 다이어그램을 이용할 수 있다.

260


제10장 Structural Modeling - Analysis

CHAPTER 10

3

Case Study

9장의 Case Study에서 주어진 전자결재 시스템을 이어서 분석한다.

3.1

객체/클래스 찾기

주어진 요구사항과 앞 장에서 작성한 유스케이스 정의서에서 명사를 찾아 정리하면, 다음 [그림 10-5]와 같다.

[그림 10-5] 요구사항에서 명사 추출

앞에서 배운 불필요한 클래스 제거에 따라 위 후보 클래스들을 제거한다. 다음 [그림 10-6]은 항목별로 제거해야 하는 클래스들에 대해 보여 준다.

261


UML기반 분석/설계

[그림 10-6] 후보 클래스들 중 제거 대상

이렇게 하여, 최종적으로 남은 클래스들은 다음과 같다. •

결재자

상신자

상신문서

결재경로

첨부파일

결재

문자메시지

3.2

클래스들 간의 관계(Relationships) 찾기

주어진 요구사항과 앞 장에서 작성한 유스케이스 정의서에서 동사를 찾은 다음에, 앞 에서 배운 불필요한 관계 제거에 따라 다음과 같은 관계들을 제거한다.

262


제10장 Structural Modeling - Analysis

CHAPTER 10

λ 제거된 클래스와의 연관 관계거나 구현에 해당하는 관계 •

상신된 문서는 상신함에 보관된다.

상신된 문서는 결재자에게 전달된다.

시스템은 결재 완료를 상신자에게 알린다.

시스템은 결재 문서를 기결함에 보관한다.

결재 문서는 다음 결재자에게 전달된다.

문자 메시지를 수신하도록 선택한다.

SMS를 이용한다.

λ 행위 또는 기능에 해당하는 관계 •

결재자는 결재 의견을 기록한다.

결재자는 결재를 실행한다.

이렇게 하여, 최종적으로 남은 관계들은 다음과 같다. λ 정제된 연관 관계 •

상신자는 상신할 문서를 작성한다.

상신자는 문서를 상신한다.

결재자는 상신된 문서를 결재한다.

상신자와 결재자는 결재된 문서를 검색한다.

여기까지 식별된 클래스와 관계를 토대로, 처음으로 클래스 다이어그램을 작성하면 다 음 [그림 10-7]과 같다.

263


UML기반 분석/설계

결재경로

첨부파일 문자메시지

상신자

상신문서

결재

결재자

[그림 10-7] 초기 클래스 다이어그램

이제, 작성된 클래스 다이어그램을 놓고, 관계수나 관계 이름 등을 붙여 가면서 각 클 래스들 간의 관계를 좀더 자세히 정의할 수 있다.

3.3

속성(Attribute) 및 오퍼레이션(Operation) 찾기

클래스들 간의 관계를 상세하게 정의한 뒤, 앞의 [그림 10-6]에서 제거된 후보 클래 스들에서 속성과 오퍼레이션에 해당하는 것들을 추출한다. 이 속성과 오퍼레이션들을 각 클래스에 추가하면, 최종적인 클래스 다이어그램이 다음 [그림 10-8]과 같이 작성 된다.

264


제10장 Structural Modeling - Analysis

CHAPTER 10

[그림 10-8] 최종 클래스 다이어그램

위의 다이어그램을 보면 ‘직원’ 클래스가 새롭게 도출된 것을 알 수 있다. 이는, ‘상신 자’와 ‘결재자’ 클래스에 속성들을 추가하다 보니, 성명, 주민번호, 부서 등처럼 서로 같은 속성들이 많이 나타났고, 두 클래스 간의 공통점을 찾아 ‘직원’이라는 부모 클래 스를 새롭게 도출하고, ‘상신자’와 ‘결재자’ 클래스와 ‘직원’ 클래스 간에 일반화 관계 를 맺었다. 물론, ‘직원’과 같은 클래스를 도출하는 과정에서, 이와 같이 속성이나 오 퍼레이션의 유사성을 보고 리팩토링할 수도 있지만, 업무 지식과 경험에 의해 직관적 ���로 도출할 수 있다.

3.4

패키지(Package)로 묶기

현 전자결재 시스템 예제와 같이 복잡하지 않고 작은 규모의 시스템일 경우에는, 굳이 패키지로 묶을 필요가 없으므로, 생략한다.

265


UML기반 분석/설계

지금까지 작업한 [그림 10-8]의 클래스 다이어그램은 분석 단계에 있어서 완결된 클 래스 다이어그램은 아니다. 앞에서 잠깐 언급했듯이, 유스케이스 동적 분석을 수행하 여 MVC 모델을 반영해야만, 비로소 분석 클래스 다이어그램이 완성된다. [그림 108]의 클래스 다이어그램에는 MVC 모델 관점에서 주로 Model에 해당하는 클래스들 만이 표현되어 있다.

266


Chapter

11

Behavioral Modeling - Analysis

1 절 유스케이스 동적 분석 2 절 상태 모델링 3 절 Case Study

학습목표 Φ 유스케이스에 참여하는 객체를 MVC 모델에 따라 역할과 책임을 부여하는 방법을 학습한다. Φ 유스케이스를 동적으로 분석하는 방법을 학습한다. Φ 특정 객체에 대한 상태 모델링을 하는 방법을 학습한다. Φ 유스케이스 동적 분석을 통해, 커뮤니케이션 다이어그램을 작성하는 방법 을 학습한다.


분석 단계의 행위적 모델링에서는 유스케이스 동적 분석 작업을 수행한 다. 유스케이스 동적 분석을 통해, 유스케이스 별로 정의서에 기술된 처리 흐름을 객체 간의 동적 메시지 흐름으로 분석하여, 분석 클래스를 상세화한다. 이 장에서는 먼저 분석 모델의 기본인 MVC 모델에 따라 클래스의 역 할이 어떻게 구분되는지 살펴본 다음에, MVC 클래스들이 유스케이스 정의서에 기술된 처리 흐름을 어떻게 표현하는지, UML을 사용한 전반 적인 행위적 모델링 기법에 대해 배워 본다.


제11장 Behavioral Modeling - Analysis

CHAPTER 11

1

유스케이스 동적 분석

유스케이스 동적 분석은 시스템의 동적인 부분을 모델링하는 것으로, 유스케이스의 처 리 흐름이 수행되기 위해 역할(Roles)에 따라 구분된 클래스들 간에 전달되어야 하는 메시지를 순차적으로 분석한다. 이를 커뮤니케이션 다이어그램이나 시퀀스 다이어그램 으로 표현하며, 복잡하거나 주요한 객체에 대해서는 그 상태를 자세히 살펴보기 위해 스테이트 머신 다이어그램을 이용할 수 있다. 또한, 유스케이스의 처리 흐름을 유스케 이스 정의서로 기술할 수도 있지만, 액티비티 다이어그램을 이용하여 보다 정형화된 액티비티로 표현할 수도 있다.

유스케이스 동적 분석의 결과는 유스케이스 정적 분석에서 도출된 클래스들에 지대한 영향을 미치게 되며, 이를 통해 완전한 분석 단계의 클래스 다이어그램이 작성될 수 있다. 또한, 유스케이스 동적 분석과 정적 분석은 서로 불일치되지 않도록 모델의 일 관성을 확보하는 쌍방의 상호작용이다. 즉, 유스케이스 동적 분석과 정적 분석은 서로 상호보완하는 관계이고, 결코 분석 단계에서 따로 떼 놓고 생각할 수 없는 관계이다.

본격적으로, 유스케이스 동적 분석에 들어가기에 앞서, 지금까지 미뤄 온 MVC 모델 에 대해 짚고 넘어가야 한다. 왜냐하면 새로운 클래스나 속성, 오퍼레이션, 관계 등을 추가하고 정제하려면, 책임(Responsibilities)을 고려해야만 하고, MVC 모델은 그러한 객체에 책임을 부여하기 위한 가장 일반적이고 직관적이고 쉬운 방법을 제시하기 때 문이다. 다음 [그림 11-1]은 MVC 모델에 대해 설명하고 있다.

269


UML을 이용한 객체지향 분석설계

[그림 11-1] 역할(Roles)에 따른 MVC 모델

UML 표준에서는 <<Boundary>>, <<Control>>, <<Entity>> 세 가지 스테레오 타입 (Stereo Type)을 사용함으로써, MVC 모델에 따라 클래스의 역할을 구분할 수 있다. Model은 <<Entity>> 클래스로, View는 <<Boundary>> 클래스로, Controller는 <<Control>>

클래스로

나타내면

되고,

MVC

모델에

따라

<<Boundary>>,

<<Control>>, <<Entity>> 클래스들의 책임(Responsibilities)에 대해 정리하면 다음과 같다. λ <<Boundary>> 클래스 – View 시스템 외부와 내부의 상호작용을 표현하는 데 사용되는 클래스이다. 사용자와 시 스템 간의 상호작용을 사용자에게 보여지는 사용자 인터페이스로 분석할 때 <<Boundary>> 클래스로 정의된다. 이는 개발 시에 윈도우, 웹 클라이언트 페이지 등으로 구현된다. 혹은 외부 시스템과 내부 시스템의 상호작용을 정의할 때 시스템 인터페이스를 정의하기 위해 <<Boundary>> 클래스를 활용할 수도 있다. 이때, 레 가시 시스템과의 인터페이스를 위한 API 등이 <<Boundary>> 클래스 단위가 된다. 분석 단계에서 <<Boundary>> 클래스는 세부적인 화면을 모두 고려할 수 없으므

270


제11장 Behavioral Modeling - Analysis

λ <<Control>> 클래스 – Controller 유스케이스 내의 처리 흐름을 제어, 조정하거나 트랜잭션을 관리하는 데 사용되는 클래스이다. <<Control>> 클래스를 정의하면 시스템이 제공하는 주요 기능 흐름을 정의하게 되므로 시스템을 이해하는 데 도움이 되고, <<Boundary>> 클래스와 <<Entity>> 클래스를 독립적으로 구현하는 조정 역할을 함으로써 변경에 안정적인 이점이 있다. 대개 하나의 유스케이스에는 하나의 <<Control>> 클래스를 정의하지 만 절대적인 룰이 있는 것은 아니다. 하나의 유스케이스가 복잡한 업무를 처리하는 단위라면 여러 개의 <<Control>> 클래스를 사용하게 된다. 하나의 유스케이스가 단순히 하나의 <<Entity>> 클래스를 제어하는 수준이면, 굳이 <<Control>> 클래 스를 정의하지 않을 수도 있다. 여러 개의 유스케이스가 연관성이 강하면, 하나의 <<Control>> 클래스를 공유할 수 있다. 이 경우 유스케이스의 통합을 고려해 볼 수도 있다. λ <<Entity>> 클래스 – Model 기본적으로 UML에서 말하는 <<Entity>> 클래스는 유스케이스 처리 흐름이 수행 되는 과정에서 기억 장치에 저장되어야 할 정보를 표현하는 클래스이다. 그러나 MVC의 Model은 단순히 저장되어야 하는 정보만을 의미하지는 않는다. Model은 현 도메인에 대한 비즈니스 로직을 수행하고 정보를 관리하는 모든 어플리케이션 의 실 기능을 담당하는 역할을 수행한다. 따라서, 도메인 모델링에서 정의된 클래 스는 대부분 <<Entity>> 클래스로 정의될 수 있다. 물론, 시스템화 범위 이외의 클 래스는 제거된다.

이제 MVC 모델에 대해서 살펴 보았으니, 본격적으로 유스케이스 동적 분석을 수행하 도록 하겠다. UML 2.0에서부터는 시퀀스 다이어그램 또는 커뮤니케이션 다이어그램으 로 유스케이스 동적 분석 작업을 수행한다. 여기서는 커뮤니케이션 다이어그램으로 유 스케이스 동적 분석을 진행할 것이다. 왜냐하면 메시지의 전달을 순차적인 로직으로 표현하는 시퀀스 다이어그램보다 객체들 간의 협력 관계에 더욱 집중하여 표현하는 커뮤니케이션 다이어그램이 유스케이스 동적 분석에 더 적절하기 때문이다. 또한, 커

271

CHAPTER 11

로, 단위 유스케이스 수행을 대표하는 화면 단위로 정의해도 문제없다.


UML을 이용한 객체지향 분석설계

뮤니케이션 다이어그램이 보다 작성하기 쉬우며, 모델의 가독성 및 이해도가 높다. 더 구나 커뮤니케이션 다이어그램을 작성하면, 하나의 유스케이스에 참여하는 클래스들을 표현하는 VOPC(View Of Participating Classes)에 대한 클래스 다이어그램을 별도로 작성할 필요도 없다. 왜냐하면 커뮤니케이션 다이어그램은 객체 간의 동적 상호작용에 대한 구조적 측면을 중시하기 때문에, 이것만으로도 VOPC 클래스 다이어그램에서 표 현하려는 것을 대부분 다 나타낼 수 있다.

일반적으로 유스케이스 동적 분석은 유스케이스 각각에 대해서 동적 분석 작업이 수 행된다. 다음은 커뮤니케이션 다이어그램을 작성하는 절차이다.

1. 커뮤니케이션 다이어그램을 작성할 대상 유스케이스를 선정한다. 2. 커뮤니케이션 다이어그램에 참여하는 객체를 선정하고, 없다면 MVC 모델에 따라 도출한다. 3. 유스케이스 정의서를 바탕으로, 객체 간에 주고받는 메시지를 분석하고 찾아 내어 시간의 흐름에 따라 객체 간의 링크로 표현한다. 4. 최종 분석 클래스 모델을 완성한다.

다음

[그림

11-2]는

유스케이스

동적

분석에

참여하는

객체들의

모습이다.

<<Boundary>>, <<Control>>, <<Entity>> 세가지 스테레오 타입에 따른 클래스들의 아이콘 모습과 액터 아이콘 모습을 보여주고 있다. 이와 같은 총 네 가지 종류의 객체 가 유스케이스 동적 분석에 참여한다.

272


제11장 Behavioral Modeling - Analysis

CHAPTER 11

[그림 11-2] 유스케이스 분석에 참여하는 객체의 종류

이제 유스케이스 동적 분석 절차에 따라, 분석 모델을 정제하고 완성하는 방법을 살펴 보기로 한다.

1.1

대상 유스케이스 선정

일반적으로 요구사항 정의가 끝난 뒤에, 우선순위와 이터레이션 계획에 따라 어떤 유 스케이스들을 먼저 분석하고 설계할지 결정한다. 따라서, 자연스럽게 이에 따라 선정 되는 유스케이스를 가지고 유스케이스 동적 분석을 수행하면 된다.

1.2

MVC 모델에 따른 클래스 정의

앞의 유스케이스 정적 분석을 통해, Model에 해당하는 클래스들에 대해서는 이미 정 의했다. 따라서, 이미 완성되어 있는 클래스 다이어그램의 분석 클래스들은 대부분 <<Entity>> 스테레오 타입으로 선언하면 된다. 이번 유스케이스 동적 분석은 이미 정 의되어 있는 Model 중심의 클래스들에 View와 Controller에 해당하는 클래스들을 새

273


UML을 이용한 객체지향 분석설계

롭게 추가하여 작업할 것이다.

다음 [그림 11-3]은 기존에 작성된 유스케이스 모델로부터 View와 Controller 클래 스들을 도출하는 모습을 표현하고 있다.

[그림 11-3] 유스케이스 모델로부터 MVC 클래스 도출

[그림 11-3]을 보면, 한 유스케이스로부터 기본적으로 하나의 <<Control>> 클래스를 식별한다는 것을 알 수 있다. 또한, View 클래스는 유스케이스와 상호작용하는 액터 와의 관계에 따라 식별할 수 있는데, 사용자 액터에 대해서는 UI(User Interface)에 해당하는 <<Boundary>> 클래스들을 식별하고, 시스템 액터에 대해서는 SI(System Interface)에 해당하는 <<Boundary>> 클래스들을 식별한다. 이때, 유스케이스 정의서

274


제11장 Behavioral Modeling - Analysis

표현된

액터와

시스템이

상호작용하는

여러

스텝에

따라

하나

이상의

<<Boundary>> 클래스가 식별될 수 있다.

또한, 유스케이스 처리 흐름을 쫓아가면서, 유스케이스 정적 분석에서 미처 식별하지 못한 <<Entity>> 클래스를 식별할 수도 있다.

1.3

커뮤니케이션(Communication) 다이어그램 작성

이제 유스케이스 동적 분석을 하기 위한 모든 클래스들이 도출되었고, 지금까지 도출 된 MVC 클래스들을 가지고 유스케이스 별로 실질적인 동적 분석을 수행할 수 있다.

일반적으로 유스케이스 하나당 하나의 커뮤니케이션 다이어그램을 작성하는데, 유스케 이스 정의서에 나타난 처리 흐름에 따라 작성하면 된다. 이때 메시지의 흐름은 액터에 서 시작되도록 작성한다. 커뮤니케이션 다이어그램에서, 다음과 같은 순서를 고려하여 객체들 간의 상호작용을 찾는다.

1. 액터와 유스케이스의 상호작용에서, 액터와 <<Boundary>> 클래스 간의 이벤 트를 찾는다. 2. 액터의 이벤트를 <<Boundary>> 클래스가 받아 <<Control>> 클래스로 전달 하는 메시지를 오퍼레이션으로 표현한다. 3. <<Control>> 클래스가 <<Entity>> 클래스에 전달하는 메시지를 오퍼레이션 으로 표현한다.

위의 1번과 2번에 해당하는 액터와 <<Boundary>> 클래스 간이나 <<Boundary>> 클래스와 <<Control>> 클래스 간의 상호작용은 유스케이스 정의서의 처리 흐름에서 식별 가능하다. 또한 둘 다 거의 같은 상호작용 메시지로 표현될 것이다. 다만, 액터 와 <<Boundary>> 클래스 간의 메시지는 일반 설명 형태로 기술하고, <<Boundary>>

275

CHAPTER 11


UML을 이용한 객체지향 분석설계

클래스와 <<Control>> 클래스 간의 메시지는 클래스의 오퍼레이션을 사용하여 기술 해야 한다. 예를 들어, 액터에서 <<Boundary>> 클래스로 ‘문서 상신 신청’이라는 메 시지로 표현했다면, <<Boundary>> 클래스에서 <<Control>> 클래스로 ‘문서상신신청 ()’이라는 오퍼레이션으로 표현할 수 있다. 이때, 이 ‘문서상신신청()’ 오퍼레이션은 <<Control>> 클래스에 할당될 것이다.

그리고 위 3번에서 <<Control>> 클래스와 <<Entity>> 클래스 간의 상호작용은 유스 케이스 정의서에 나타나지 않는다. 따라서, <<Control>> 클래스와 <<Entity>> 클래스 간의 상호작용의 식별은 업무 지식과 개발 경험을 필요로 하고, 이 과정에서 새로운 클래스나

클래스의

오퍼레이션이

찾아지기도

한다.

<<Control>>

클래스와

<<Entity>> 클래스 간의 메시지는 클래스의 오퍼레이션을 사용하여 기술해야 한다.

지금까지 살펴본 바와 같이, <<Boundary>> 클래스와 <<Control>> 클래스 사이 및 <<Control>> 클래스와 <<Entity>> 클래스 사이의 상호작용 메시지를 표현할 때는, 클래스에 오퍼레이션을 추가하여 표현했다. 왜냐하면, 이렇게 함으로써 설계 단계에서 별도로 오퍼레이션을 추가해야 하는 부담을 덜게 되고, 분석 모델과 설계 모델의 연속 성을 보장할 수 있기 때문이다.

유스케이스 정의서의 처리 흐름에 따라 커뮤니케이션 다이어그램을 작성하는데, 일반 적으로 기본 흐름(Basic Flow)을 먼저 표현하고, 대안 흐름(Alternative Flows)을 그 다음에, 예외적인 흐름(Exceptional Flows)을 가장 나중에 표현한다. 대안 흐름과 예 외적인 흐름은 부득이한 경우에 생략할 수 있으며, 기본 흐름만을 커뮤니케이션 다이 어그램에 표현할 수 있다.

또한, 커뮤니케이션 다이어그램 안에 유스케이스에 참여하는 객체들을 위치시킬 때, 역할과 책임에 따라 Actor-Boundary-Control-Entity 순으로 객체들을 나열하여 표 현하는 것이 보다 모델의 가독성 및 통일성에 유익하다.

276


제11장 Behavioral Modeling - Analysis

할 수도 있다. UML 2.0에서부터는 시퀀스 다이어그램을 통해, 좀더 세밀한 내용을 표 현할 수 있다.

다음 [그림 11-4]는 커뮤니케이션 다이어그램으로 표현한 예제이다.

[그림 11-4] 커뮤니케이션 다이어그램 예제

다음 [그림 11-5]는 위의 커뮤니케이션 다이어그램을 시퀀스 다이어그램으로 표현한 예제이다.

277

CHAPTER 11

그러나 앞에서도 말했듯이, 커뮤니케이션 다이어그램 대신 시퀀스 다이어그램을 이용


UML을 이용한 객체지향 분석설계

[그림 11-5] 시퀀스 다이어그램 예제

유스케이스 동적 분석 시에는 복잡한 로직이 표현되는 것이 아니기 때문에, 대부분 위 와 같이 간단한 다이어그램이 작성될 것이다. 이처럼 유스케이스 동적 분석 시에는 시 퀀스 다이어그램의 세밀한 기능을 사용하기 힘들기 때문에, 굳이 직관성이 떨어지는 시퀀스 다이어그램을 고집할 이유가 없다. 따라서, 커뮤니케이션 다이어그램을 통해 유스케이스 동적 분석을 진행하도록 권장한다.

이렇게 하여 유스케이스 별로 커뮤니케이션 다이어그램 작성을 완료한다.

1.4

분석 클래스 모델 완성

모든 유스케이스에 대해서 MVC 클래스들을 도출하고 동적 분석을 수행하고 나면, 각 유스케이스 별로 참여했던 VOPC 클래스들이 나타난다(유스케이스에 참여한 클래스들 을 표현하는 VOPC 클래스 다이어그램을 별도로 작성할 수도 있다). 이 VOPC 클래

278


제11장 Behavioral Modeling - Analysis

이 완성된다.

도메인 모델은 전체 업무 도메인을 나타내기 위해 중요한 Model에 해당하는 도메인 객체나 비즈니스 엔티티를 표현한 반면, 분석 클래스 모델은 시스템에서 사용해야 하 는 구체화된 비즈니스 정보를 유스케이스 단위로 분석하여 MVC 전체에 해당하는 클 래스들을 표현한다. 또한, 분석 동적 모델링에서 객체 간의 메시지 흐름을 분석하여 오퍼레이션을 분석 클래스에 정의하고, 이에 따라 추가적인 속성과 클래스 간의 관계 를 정의할 수 있다.

분석 단계에서는 정적 분석과 동적 분석의 긴밀한 상호보완 관계에 따라 분석 모델을 반복·점진적으로 완성해 나간다. 정적 분석과 동적 분석의 반복 작업을 통해, 정적 분 석 모델과 동적 분석 모델은 서로 일관성을 유지하려고 발전할 것이고, 이는 결과적으 로 유스케이스를 실현하기 위해 시스템이 무엇을 제공해야 하는지 정확히 파악할 수 있게 한다.

또한, 유스케이스 정의서를 작성하면서 도출된 데이터들과 분석 클래스들의 타입, 속 성과는 일관성이 유지되어야 한다. 분석 클래스 다이어그램을 확정할 때는 반드시 유 스케이스 정의서와의 일관성을 확인하도록 한다. 필요 시 일관성 유지를 위해 유스케 이스 정의서를 수정하거나 보완할 수도 있다.

분석 단계에서 나타난 클래스나 오퍼레이션은 어디까지나 고객의 요구사항을 시스템 측면에서 최초로 모델링한 결과물이지, 실질적으로 구현 가능한 모델은 아니다. 설계 단계에서는 이 분석 모델을 가지고 소프트웨어 아키텍처와 개발 플랫폼 및 기술 환경 을 반영하여 실제 구현 가능한 모델을 만들기 위해 설계 모델링을 수행할 것이다.

279

CHAPTER 11

스들을 모두 모아 하나의 클래스 다이어그램에 뭉쳐 놓고 정제하면, 분석 클래스 모델


UML을 이용한 객체지향 분석설계

2

상태 모델링

객체는 행위와 상태를 가지고 있다. 달리 말하면, 객체는 무언가를 할 수도 있으며, 무언가를 가지고 있을 수도 있다. 유스케이스 동적 분석에서 수행한 모델링이 객체가 할 수 있는 것에 초점을 맞춘 행위적 모델링이라면, 상태 모델링(State Modeling)은 객체가 가지고 있는 것의 변화에 초점을 맞춘 행위적 모델링이다.

어떤 객체는 다른 객체보다 복잡하여 이해하기가 쉽지 않을 수 있고, 또한 이와 같은 객체들은 유스케이스 동적 분석을 통해서도 명확히 분석되지 않을 수 있다. 이처럼 복 잡한 객체는 상태의 변화에 의존하는 다른 방법으로 분석해 볼 필요가 있고, 우리는 UML의 스테이트 머신 다이어그램을 통해 객체의 상태 모델링을 수행할 수 있다.

상태 모델링을 수행하는 목적을 세부적으로 살펴보면 다음과 같다. λ 객체의 상태 변화를 파악한다. 객체의 라이프사이클에 따라, 객체가 생성되어 소멸하기까지의 기간 중에 다양하게 가질 수 있는 상태를 분석한다. 정보 시스템에서 대부분의 객체는 생성되어 소멸될 때까지 간단한 상태를 가지지만, 일부는 매우 복잡한 상태로 변화하면서 존재할 수 있다. 상태 모델링을 통해, 이렇게 객체의 동적 상태 변화를 정의하고 분석할 수 있다. λ 이벤트를 통한 객체의 반응을 파악한다. 객체의 상태 변화를 유발하는 이벤트를 찾아서 정의한다. 객체의 상태는 내부나 외 부에서 발생하는 이벤트에 따라 변화하는데, 이러한 객체의 상태 변화를 유발하는 이벤트를 식별하고 상세히 정의한다.

280


제11장 Behavioral Modeling - Analysis

상태 모델링을 통해, 유스케이스 정적 분석과 동적 분석에서 나온 모델을 상호 검 증할 수 있다. 지엽적으로 본다면, 객체가 지니는 속성과 오퍼레이션을 검증할 수 있다. 분석대상인 객체의 상태는 속성의 값으로 정의되고, 이벤트는 대부분 객체의 오퍼레이션으로 정의된다. 그래서 또한 클래스 다이어그램에 정의된 클래스의 속성 과 오퍼레이션의 적합성을 검증할 수 있다. 어떤 객체의 상태 변화를 찾기 위해서는, 먼저 객체의 상태를 변화시키는 이벤트를 찾 아야만 한다. 스테이트 머신 다이어그램에서 사용하는 이벤트의 대상으로는 시그널 (Signal), 인터럽트(Interrupt), 사용자 입력(User Input) 등이 있을 수 있다. 이와 같이 객체가 작업을 수행하도록 하고 그 결과가 객체의 상태를 변화시키는 것은 모두 이벤 트 대상이 된다. 특히, 객체 간의 상호작용은 대부분 이벤트 대상이 된다.

우리는 또한, 스테이트 머신 다이어그램에 사용할 이벤트(Event), 상태(State), 전이 (Transition) 등을 다음 [그림 11-6]과 같이 시퀀스 다이어그램을 참조하여 찾을 수 있다.

[그림 11-6] 시퀀스 다이어그램을 통한 스테이트 머신 다이어그램의 요소 식별하기

281

CHAPTER 11

λ 모델을 검증한다.


UML을 이용한 객체지향 분석설계

위 시퀀스 다이어그램은 객체 간의 상호작용을 나타내기 위한 용도로 사용되지만, 그 밖에도 유용한 정보를 담고 있다. 시퀀스 다이어그램에 참여하는 특정 객체 하나에 대 한 객체 생명선(Life Line)을 살펴보면, 객체로 들어오는 메시지가 있으며 이것이 객체 와 관련된 입력 이벤트(Input Event)가 된다. 객체의 상태는 이벤트가 들어오기 전에 는 변경되지 않는다. 그러므로 입력 이벤트들 사이가 객체의 상태(State)에 해당되고, 객체 생명선에서 인접한 두 상태들 간에는 전이(Transition)가 발생함을 알 수 있다. 객체에서 다른 객체로 보내는 이벤트, 즉 출력 이벤트(Output Event)는 해당 상태의 액티비티(Activity)이며, 상태 안의 Do Action을 나타낸다. 다음은 스테이트 머신 다이어그램 작성시에 주의해야 할 사항들이다. •

모든 객체에 대해 스테이트 머신 다이어그램을 작성할 필요가 없다. 여러 유스케이스에 걸쳐 있는 객체와 주요하거나 복잡한 객체에 대해서만 스테 이트 머신 다이어그램을 작성한다.

스테이트 머신 다이어그램은 혼자만으로는 의미가 없다. 스테이트 머신 다이어그램은 다른 다이어그램들과의 결합하여 더욱 유용하다. 따라서, 유스케이스 동적 분석 시에 주로 사용하는 다이어그램은 커뮤니케이션 다이어그램이나 시퀀스 다이어그램이고, 스테이트 머신 다이어그램은 단지 부가 적으로 사용되어 모델의 완성도 및 이해도를 높인다.

블랙홀 상태를 주의한다. 모든 상태는 들어오는 전이(Transition)와 나가는 전이가 모두 정의되어야 한다. 만약 들어오는 전이만 있고, 나가는 전이가 없을 경우, 그 상태는 블랙홀이 된 다. 이와 같은 블랙홀 상태는 객체를 종료 상태에 이르지 못하게 하고 무한 루 프를 수행하도록 하여, 오류가 발생시킨다. 항상 모델을 확인하면서, 블랙홀 상 태가 있는지 검증해야 한다.

클래스 다이어그램 및 커뮤니케이션 다이어그램과의 일관성에 유의한다. 스테이트 머신 다이어그램을 작성 완료한 후 새롭게 정의된 오퍼레이션과 속성 은 클래스 다이어그램과 커뮤니케이션 다이어그램에 반영되어 일관성을 유지해 야 한다. 그런 작업을 하지 않을 경우, 그 모델은 전체적으로 신뢰할 수 없게

282


제11장 Behavioral Modeling - Analysis

검증하는 모습을 보여 주고 있다.

[그림 11-7] 스테이트 머신 다이어그램을 통한 모델 검증

대부분의 정보 시스템, 즉 비즈니스 어플리케이션에서는 상태 모델링을 할 정도의 다 양한 상태를 지니는 복잡한 객체가 거의 존재하지 않는다. 따라서, 실질적으로 객체의 상태 변화 추이를 살펴보기 위한 상태 모델링은 전체 클래스의 약 5%만이 해당되고, 나머지는 다 산출물들 간의 검증을 위하거나 이해를 돕기 위한 보조 용도로 수행된다. 또한, 프레임웍의 핵심 엔진을 개발한다든지, 핵심 알고리즘을 개발하기 위해서 상태 모델링을 사용할 수 있다.

반면에, 실시간 시스템이나 임베디드 소프트웨어 등에서는 훨씬 더 중요하게 사용되는 것이 스테이트 머신 다이어그램을 통한 상태 모델링이다. 왜냐하면, 이와 같은 시스템 은 해당 정보를 DB 중심으로 관리하는 것이 아니라, 적은 메모리를 사용하여 얼마나 효율적으로 처리할지를 고민하기 때문이다.

283

CHAPTER 11

된다. 다음 [그림 11-7]은 스테이트 머신 다이어그램을 통해 두 다이어그램을


UML을 이용한 객체지향 분석설계

3

Case Study

10장의 Case Study에 이어서 전자결재 시스템을 동적 분석하도록 한다.

3.1

대상 유스케이스 선정

‘문서상신’과 ‘사용자 검색’ 유스케이스를 대상 유스케이스로 선정하여, 유스케이스 동 적 분석을 수행하도록 한다.

단, 주의해야 할 것은, ‘사용자 검색’은 굳이 별도의 유스케이스로 식별하지 않아도 될 만큼 작은 크기(‘문서상신’ 유스케이스 처리 흐름의 2스텝 정도)이고 ‘문서상신’ 외에 다른 유스케이스에서는 포함 관계를 맺지 않으므로, 굳이 별도로 유스케이스를 나누지 않아도 된다는 것이다. 따라서, ‘사용자 검색’ 유스케이스에 대해 별도로 유스케이스 동적 분석을 수행하지 않고, ‘문서상신’ 유스케이스 동적 분석에서 함께 수행하도록 할 것이다.

3.2

MVC 모델에 따른 클래스 정의

9장 4절의 ‘문서상신’ 유스케이스에 대한 유스케이스 정의서를 보면서, 유스케이스의 참여 객체를 종류 별로 식별하면 다음과 같다. 액터와 Model에 해당하는 <<Entity>> 클래스는 이미 식별되어 있기 때문에, View와 Control에 해당하는 클래스만 식별하면 된다.

284


제11장 Behavioral Modeling - Analysis

CHAPTER 11

λ 액터 •

상신자

통합사용자시스템

λ Boundary •

상신문서작성화면

동명이인선택화면

통합사용자관리인터페이스

λ Control •

문서상신컨트롤

λ Entity •

상신문서

결재경로

첨부파일

‘문서상신’ 유스케이스에서 하나의 Controller 클래스를 식별하여 ‘문서상신컨트롤’ 클 래스를 추가했다. 또한, ‘문서상신’ 유스케이스 정의서에서 시스템이 ‘상신자’와 ‘통합 사용자시스템’ 액터와 상호작용하는 처리 흐름의 각 스텝을 파악하여, View 클래스를 위와 같이 식별했다. 이렇게 유스케이스의 동적 분석에 참여할 객체의 클래스들을 선 정하거나 새롭게 추가했고. ‘문서상신’ 유스케이스에 대해 액터를 포함하여 총 8개의 객체가 식별되었다.

3.3

커뮤니케이션(Communication) 다이어그램 작성

유스케이스 정의서에 나타난 처리 흐름에 따라, 앞에서 식별한 객체들 간의 동적인 협 력 관계를 정의하기 위해 커뮤니케이션 다이어그램을 작성한다.

먼저, 커뮤니케이션 다이어그램에 8개의 객체를 표현하고 객체들 간의 연관 관계를

285


UML을 이용한 객체지향 분석설계

정의한다. 다음 [그림 11-8]은 객체와 그 관계만을 표현한 초기 커뮤니케이션 다이어 그램의 모습이다. 이는 흡사 VOPC 클래스 다이어그램과 유사하게 보인다.

: 상신문서작성화면

: 문서상신컨트롤

: 상신자

: 상신문서

: 통합사용자관리인터페이스

: 통합사용자시스템

: 동명이인선택화면

: 결재경로

: 첨부파일

[그림 11-8] 객체와 그 관계에 대한 커뮤니케이션 다이어그램

이제 위 커뮤니케이션 다이어그램에 유스케이스의 처리 흐름을 표현하면, [그림 119]와 같이 표현될 것이다. 객체들 간(<<Boundary>>와 <<Control>>, <Control>>과 <<Entity>> 객체 간) 처리 흐름의 메시지를 표현할 때, 반드시 오퍼레이션으로 추가 하는 것을 잊지 말아야 한다.

286


제11장 Behavioral Modeling - Analysis

CHAPTER 11

[그림 11-9] 객체와 그 관계에 대한 커뮤니케이션 다이어그램

3.4

분석 클래스 모델 완성

모든 유스케이스에 대해 동적 분석을 모두 수행하고 나면, 그때서야 비로소 전체 시스 템을 커버할 수 있는 분석 클래스 모델이 완성되었다고 간주할 수 있다.

다음 [그림 11-10]은 MVC 모델이 반영된 최종 분석 클래스 다이어그램의 모습이다. ‘상신문서’와 ‘결재자’ 간의 m : n 관계를 1 : n 관계로 분리한 것을 볼 수 있다. 반복 적으로 유스케이스 정적 모델과 동적 모델을 상호 검증하여 모델의 완전성을 향상시 켜야 한다.

287


UML을 이용한 객체지향 분석설계

[그림 11-10] 최종 분석 클래스 다이어그램

위와 같이 MVC에 해당하는 클래스를 모두 표현하여 최종 분석 클래스 다이어그램을 작성할 수도 있지만, <<Boundary>> 클래스들은 생략하여 작성하는 것이 더 적합할 수 있다. 왜냐하면, <<Boundary>> 클래스들 중 UI에 해당하는 클래스들은 실제 클래 스로 개발되는 것이 아니라 화면으로 개발되어야 할 것이기 때문이다. 대부분의 <<Boundary>> 클래스들은 설계 단계의 화면 설계에서 별도로 작업될 것이다.

또한, 이처럼 최종 분석 클래스 다이어그램이 작성될 때는, 모든 클래스들의 속성을 도출하는 것이 바람직하다. 다음 [그림 11-11]은 이를 반영한 Model에 해당하는 클 래스 위주의 최종 분석 클래스 다이어그램이다.

288


제11장 Behavioral Modeling - Analysis

CHAPTER 11

[그림 11-11] 속성을 추가한 최종 분석 클래스 다이어그램

3.5

상태(State) 모델링

상태 모델링은 주로 복잡하여 이해하기 어려운 객체에 대해서 스테이트 머신 다이어 그램을 이용하여, 이벤트에 따른 객체의 상태 변화를 지켜보는 것이다. 전자결재 시스 템에서는 딱히 복잡한 객체가 존재하지는 않지만, 그나마 제일 복잡하고 중요한 “상신 문서” 클래스에 대한 상태 모델링을 수행해 보도록 하겠다.

다음 [그림 11-12]는 ‘상신문서’ 객체의 라이프사이클을 표현한 간단한 예제이다.

289


UML을 이용한 객체지향 분석설계

s m 상신문서 작성중 생성()

+ + + + +

On Entry / 내용작성시작 Do Action / 내용작성 On Event / 결재자추가 On Event / 첨부추가 On Exit / 작성완료

상신()

결재중 +

결재 [결재자=최종결재자]

결재완료

On Entry / 결재자통보

결재 [결재자<>최종결재자]

[그림 11-12] ‘상신문서’에 대한 스테이트 머신 다이어그램

‘상신문서’의 상태는 ‘작성중’, ‘결재중’, ‘결재완료’의 총 세 가지 상태로 이루어져 있 다. 이를 다음 [그림 11-13]처럼 복합 상태(Composite State)를 이용하여 ‘상신문서’ 객체의 라이프사이클을 보다 세밀하게 표현했다. UML 2.0에서부터는 서브머신 상태 (Submachine State)로 복합 상태를 표현한다.

290


제11장 Behavioral Modeling - Analysis

CHAPTER 11

s m 상신문서_복합상태 작성중 + + + + +

On Entry / 내용작성시작 Do Action / 내용작성 On Event / 결재자추가 On Event / 첨부추가 On Exit / 작성완료

생성() 빠진내용추가 빈문서

문서완성 미완성 문서 상신

미완성 표현

상신() 결재중 +

On Entry / 결재자통보

결재완료 결재 [결재자=최종결재자]

결재 [결재자<>최종결재자]

[그림 11-13] 서브머신(Submachine) 상태를 이용한 ‘상신문서’의 상태 표현

‘작성중’ 상태를 복합 상태로 표현하여, 그 내부 상태로 ‘빈문서’와 ‘문서완성’ 상태를 추가했다. 또한, 문서가 미완성된 상태에서 상신되었을 것을 대비하여 “미완성 표현” 이라는 상태를 추가했고, ‘작성중’ 상태에 별도의 Exit Point와 Entry Point를 두어 ‘미 완성 표현’ 상태와의 전이(Transition)를 표현했다. 위 그림에서 Exit Point와 Entry Point는 복합 상태의 비정상적인 상태 종료 및 시작을 표현했고, 정상적인 것에 대해 서는 별도로 Exit Point와 Entry Point를 표현하지 않았다. 그러나 이는 어디까지나 표현하고자 하는 사람의 자유이며, 다음 [그림 11-14]와 같이 한 복합 상태의 종료 및 시작을 모두 Exit Point와 Entry Point로 표현하는 것이 일관성 있게 보일 수 있다.

291


UML을 이용한 객체지향 분석설계

s m 상신문서_복합상태 작성중 + + + + +

On Entry / 내용작성시작 Do Action / 내용작성 On Event / 결재자추가 On Event / 첨부추가 On Exit / 작성완료

신규작성 생성()

빠진내용추가 빈문서

문서완성 미완성 문서 상신

미완성 표현

완성 문서 상신 문서상신 결재중 +

On Entry / 결재자통보

결재완료 결재 [결재자=최종결재자]

결재 [결재자<>최종결재자]

[그림 11-14] Exit Point와 Entry Point를 모두 적용한 ‘상신문서’의 상태 표현

292


Chapter

12

Component Modeling

1 절 소프트웨어 아키텍처 정의 2 절 컴포넌트 식별 3 절 컴포넌트 상호작용 정의 4 절 Case Study

학습목표 Φ 컴포넌트 모델링을 위한 소프트웨어 아키텍처가 무엇인지 학습한다. Φ 컴포넌트를 식별하는 방법을 학습한다. Φ 컴포넌트들 간의 상호작용 정의를 통해, 컴포넌트의 기능을 정의하고 컴포 넌트를 정제하는 방법에 대해 학습한다.


시스템 또는 소프트웨어가 실제로 작동하기 위해서는, 그 내부를 구성 하는 원칙인 소프트웨어 아키텍처가 필요하며, 그 아키텍처에 따라 컴 포넌트를 도출하고 정의해야 한다. 컴포넌트 모델링은 주어진 소프트웨 어 아키텍처에 따라 해당 시스템이나 소프트웨어를 구성하고 있는 컴포 넌트를 찾아내고 정제하여, 구현 가능하도록 컴포넌트를 설계하는 작업 이다. 이 장에서는 실제로 비즈니스 기능을 제공할 수 있도록 시스템을 구성 하는 컴포넌트들을 식별하고 컴포넌트들 간의 상호작용은 어떻게 정의 하는지, UML을 사용한 전반적인 컴포넌트 모델링 기법에 대해 배워 본 다.


제12장 Component Modeling

CHAPTER 12

1

소프트웨어 아키텍처 정의

시스템을 개발할 때, 전체 시스템의 큰 그림을 그려 놓고 그것을 서로 공감함으로써 시스템 분석, 설계, 개발을 일관성 있게 진행할 수 있다. 우리는 이와 같은 것을 시스 템 아키텍처라고 부른다. 즉, 시스템의 전반적인 골격과 구조를 일관성 있게 정의하여, 전체 시스템을 이해하기 쉽게 하며, 시스템의 토대를 마련해 준다.

이 시스템 아키텍처는 일반적으로 소프트웨어 아키텍처와 기술 아키텍처로 나누어 볼 수 있다. 소프트웨어 아키텍처는 구성하는 소프트웨어 구성요소를 식별하고, 소프트웨 어 내부적으로 적용될 표준 아키텍처 스타일을 정의하는 것인 반면에, 기술 아키텍처 정의는 프로젝트 특성에 부합하는 기술 아키텍처를 정의함으로써, 시스템의 하드웨어, 소프트웨어, 네트워크 구성을 전체적으로 파악할 수 있다.

UML을 가지고 모델링하는 과정에서 보다 관심 있게 봐야 할 것은 소프트웨어 아키텍 처이다. 왜냐하면 UML은 시스템 내부의 구성요소들을 분석하고 설계하기 위한 언어 이고, 소프트웨어 아키텍처는 바로 그 시스템 내부의 구성요소들의 표준을 정의하는 것이기 때문이다. 즉, 소프트웨어 아키텍처에 따라 그 내부의 분석이나 설계, 특히 설 계에 많은 영향을 미친다.

소프트웨어 아키텍처에 대한 정의는 일반적으로 다음과 같다. •

구축할 시스템의 (비)기능적 요구사항과 시스템의 규모, 복잡도를 고려하여 적 합한 아키텍처를 검토하며, 이를 토대로 계층 분할 기준을 정의하고, 플랫폼 특 성을 고려한 표준 아키텍처 스타일을 정의한다.

295


UML을 이용한 객체지향 분석설계

설계를 위한 주요한 구조적인 패턴이나 메커니즘이 존재할 경우 이를 아키텍처 에 정의하고, 소프트웨어 구성요소를 정의한다.

기존 시스템과의 인터페이스를 반영하여 통합한 아키텍처로 정의한다.

소프트웨어 아키텍처 스타일은 소프트웨어 아키텍처의 근간이 되는 소프트웨어 내부의 계층 관계 및 상호연관 관계를 개념적으로 정의하는 것을 의미한다.

소프트웨어 아키텍처 스타일은 재사용성과 유지 보수성을 고려하여 기본적으로 MVC (Model, View, Controller)의 3계층 분할 구조(Layered 아키텍처)를 갖도 록 정의한다.

또한, UP(Unified Process)에서는 소프트웨어 아키텍처를 다음과 같이 정의하고 있다. •

소프트웨어 아키텍처의 역할은 빌딩 건설에서 아키텍처가 수행하는 역할과 본 질적으로 유사하다. 빌딩은 다양한 시각에서 조망된다. 구조, 서비스, 열 전달, 배관, 전기 배선 등등. 이는 만드는 이에게 건축이 시작되기 전에 완전한 그림 을 보게 한다. 이와 유사하게 소프트웨어 시스템의 아키텍처는 시스템이 만들어 지는 다양한 관점에서 기술된다.

아키텍처는 소프트웨어 시스템 구성에 관한 중요한 판단 기준이 된다. 소프트웨 어 아키텍처는 요소들 간의 협력하는 명세에 따라, 시스템이 각 행위들을 구성 하도록 하기 위해, 시스템의 구성 및 요소들의 협력체를 반영한다. 이렇듯 아키 텍처는 구조와 행위뿐만 아니라 사용성, 기능성, 성능, 탄력성, 재사용 및 포용 성, 그리고 경제적이고 기술적인 제약과 그 반대 급부 및 심미적 이슈를 포함한 다.

아키텍처는 상세한 것들에 집중하기보다는, 시스템의 중요한 성질들에 더욱 집 중하여 나타내는, 전체 디자인에 대한 조망(View)이다. 또한, 무엇이 중요한가 는 경험에서 우러나는 판단에 속한 것이기 때문에, 아키텍처의 가치는 업무에 할당된 사람들에 의존한다.

소프트웨어 아키텍처는 다양한 관점(View)을 가질 수 있는데, 앞으로 살펴볼 컴포넌 트 모델링(Component Modeling) 관점에서는 모든 소프트웨어 아키텍처의 관점에 대

296


제12장 Component Modeling

링에 필요한 컴포넌트 레이어 구성과 각 컴포넌트에 적용되는 디자인 패턴(Design Patterns)에 대해서만 소프트웨어 아키텍처를 정의하고, 이에 따라 다음 절부터 본격 적인 컴포넌트 모델에 들어가도록 한다.

먼저 컴포넌트 레이어에 대해 살펴보기로 한다. 일반적으로 컴포넌트 레이어를 다음 [그림 12-1]과 같이 구분한다.

[그림 12-1] 컴포넌트 레이어(Component Layer) 구성

컴포넌트 레이어 위에 존재하는 UI 레이어는 사용자와 직접 상호작용하는 레이어이고, 프레젠테이션 레이어(Presentation Layer)라고도 할 수 있다. 컴포넌트 레이어에는 해 당 비즈니스 서비스를 제공하는 서버 로직을 가지고 있어 UI 레이어에 필요한 서비스 를 제공해 준다. 컴포넌트 레이어를 이루는 컴포넌트는 컴포넌트가 제공하는 서비스의

297

CHAPTER 12

해 알 필요도 없고, 이 과정에서 다루고자 하는 바도 아니다. 따라서, 컴포넌트 모델


UML을 이용한 객체지향 분석설계

범용성 및 재사용성 그리고 서비스 범위 특징 등에 따라 다음과 같이 구분한다. λ 어플리케이션 컴포넌트(Application Component): 특정 시스템에만 의미가 있는 기 능을 제공한다. 보통 UI 레이어에서 제공되는 화면은 특정 시스템이나 그 시스템을 사용하는 사용자 또는 회사에 특화되어 있고, 이 UI 레이어에서 요청하는 서비스는 마찬가지로 특정 시스템이나 그 시스템을 사용하는 사용자 또는 회사에 특화된 서 비스이다. 어플리케이션 컴포넌트는 이와 같은 서비스를 제공하기 위해, 비즈니스 컴포넌트를 사용하여 특화된 서비스를 재생산해 낸다. 따라서 어플리케이션 컴포넌 트는 비즈니스 컴포넌트에 비해 상대적으로 범용성과 재사용성이 떨어진다. λ 비즈니스 컴포넌트(Business Component): 여러 시스템에서 일반적이고 공통적으로 사용될 수 있고, 특정 비즈니스 도메인에서 범용적인 비즈니스 기능을 제공한다. 따라서 비즈니스 컴포넌트는 재사용성이 높고, 비즈니스 컴포넌트를 설계할 때는 공용성과 가변성 등을 고려해야 한다. λ 기반 컴포넌트(infrastructure Component): 특정 비즈니스 도메인이 아닌 어떤 비 즈니스 도메인에서도 사용 가능한 시스템 기반 기능을 제공한다. 일반적으로 각종 프레임웍이 제공하는 공통 유틸리티성 컴포넌트나, 어플리케이션 서버 벤더에서 제 공하는 보안, 트랜잭션, 권한, 네이밍 서비스 등의 기반 기술 컴포넌트가 이에 속한 다. 대규모 시스템을 구축하는 프로젝트에서 일반적으로 만들어야 하는 컴포넌트는 어플 리케이션 컴포넌트와 비즈니스 컴포넌트이다. 물론 기반 컴포넌트를 만들어야 할 수도 있지만, 이는 어플리케이션 컴포넌트나 비즈니스 컴포넌트를 만드는 것과는 다른 방법 으로 만들어진다. 기반 컴포넌트를 만들기 위해서는 비즈니스나 고객의 요구사항에 대 한 이해보다는 해당 기반 컴포넌트가 제공해야 하는 기능 자체에 초점을 맞추어 개발 하면 된다. 해당 기반 컴포넌트가 제공해야 하는 기능에 대해 명확히 인터페이스를 정 의하고, 컴포넌트 내부에 적용되는 디자인 패턴을 정의하여 컴포넌트 설계를 수행한다. 또한, 컴포넌트 설계 전에 기반 컴포넌트가 위치하는 프레임웍 전반에 대한 아키텍처 를 명확히 정의하는 것은 마찬가지로 반드시 필요하다.

298


제12장 Component Modeling

를 모델링하는 것에 초점을 맞출 것이다. 다음 [그림 12-2]는 각 어플리케이션 컴포 넌트와 비즈니스 컴포넌트에 적용되는 디자인 패턴 및 설계 전략을 컴포넌트 다이어 그램으로 표현하고 있다.

[그림 12-2] 어플리케이션 컴포넌트와 비즈니스 컴포넌트의 구성요소

[그림 12-2]를 보면, 어플리케이션 컴포넌트는 RemoteFaçade와 DTO로 구성되어 있고, 비즈니스 컴포넌트는 Facade와 DAO, 그리고 DO로 구성되어 있음을 알 수 있 다. 각각의 디자인 패턴에 대해 살펴보면 다음과 같다. λ RemoteFaçade: 원격 클라이언트가 요청하는 서비스를 제공하기 위한 객체이다. 원격 클라이언트가 무분별하게 컴포넌트 내부 객체들(비즈니스 컴포넌트 포함)에게 서비스를 요청하지 못하게 하고, RemoteFaçade 객체가 비즈니스 컴포넌트의 모든 서비스를 외부에 제공하는 역할을 수행한다. 이를 통해, 외부 클라이언트에게 간단 한 인터페이스를 제공할 수 있으며, 비즈니스 컴포넌트들 간의 복잡한 상호작용을 감추어 외부 시스템과의 커플링(Coupling)을 최소화한다. 또한, 원격 클라이언트에 게 데이터를 전송할 때 네트워크 부하를 줄이기 위해, 필요한 정보만을 추출하여

299

CHAPTER 12

우리는 이 과정의 컴포넌트 모델링에서 어플리케이션 컴포넌트와 비즈니스 컴포넌트


UML을 이용한 객체지향 분석설계

보내는 역할도 수행한다. 만약, 어플리케이션 컴포넌트를 호출하는 클라이언트가 원격 클라이언트가 아니라면, RemoteFaçade일 필요가 없고 Façade이면 충분하다. λ DTO(Data Transfer Object): 원격 클라이언트에게 네트워크를 통해 데이터를 전송 해야 할 때, 필요한 데이터만을 보낼 수 있게 만들어진 구조체이다. 이를 통해 시 스템 성능이 향상될 수 있다. 또한, 굳이 원격 클라이언트에게 보낼 필요가 없더라 도, 화면에 표현해야 하는 정보에 맞춰 평평하게 정의된 구조체의 역할도 가지고 있다. λ Façade: 비즈니스 컴포넌트 내부의 도메인 로직을 숨기는 역할을 한다. 원격 클라 이언트에게 서비스를 제공하지 않는다는 것만 빼면 위의 RemoteFaçade와 같은 역 할을 수행한다. λ DAO(Data Access Object): 모든 데이터 소스에 접근하는 부분을 추상화(Abstract) 하고 캡슐화(Encapsulate)하고, 데이터 소스와의 접근, 정보를 얻고 저장하는 부분 을 관리한다. 즉, DB에 접근하여 모든 데이터의 영속성을 관리하는 역할을 수행한 다. λ DO(Domain Object): 주로 분석 단계에서 식별한 Model에 해당하는 클래스들이다. 해당 비즈니스 도메인의 정보를 관리하는 역할을 수행한다. 여기서 적용할 DO는, 마틴 파울러(Martin Fowler)가 도메인 로직을 구성하는 방법 중의 하나로 이야기 하는 도메인 모델(Domain Model)에 나타나는 DO는 아니다. 우리는 DO를 단순히 비즈니스 컴포넌트 별로 다루는 데이터에 대한 구조체로서 사용할 것이다. 마치 DTO처럼 말이다. 우리가 앞으로 설계할 어플리케이션 컴포넌트와 비즈니스 컴포넌트를 모델링할 때, 위 의 구성요소 스타일을 준수하여 설계할 것이고, 이는 다음 장의 컴포넌트 정적 설계 및 동적 설계에도 영향을 미칠 것이다.

300


제12장 Component Modeling

CHAPTER 12

2

컴포넌트 식별

개발할 시스템이나 소프트웨어에 대해 소프트웨어 아키텍처를 포함한 아키텍처가 정 의되고 나면, 그 아키텍처를 준수하여 설계 작업을 진행할 수 있다. 마찬가지로 컴포 넌트 모델링(Component Modeling) 작업도 아키텍처를 준수하여 진행된다.

컴포넌트 모델링은 개발할 시스템의 내부를 재사용 가능하고 조합할 수 있는 컴포넌 트들로 구성하여, 사용자가 원하는 기능을 제공하도록 설계하는 것이다. 컴포넌트 모 델링은 크게 컴포넌트를 식별하고 정의하는 부분과 각 개별 컴포넌트의 내부를 설계 하는 두 부분으로 나누어 볼 수 있다. 다음은 컴포넌트 모델링의 2단계에 대해 설명 하고 있다. λ 컴포넌트 정의 컴포넌트 추출 기준을 참조하여 컴포넌트를 정의한다. 컴포넌트가 제공할 서비스를 인터페이스의 오퍼레이션으로 정의하고, 유스케이스를 실체화하여 컴포넌트 간의 상호작용으로 구체화한다. λ 컴포넌트 설계 각 개별 컴포넌트의 내부를 설계한다. 컴포넌트에서 제공하는 서비스, 즉 인터페이 스의 오퍼레이션을 컴포넌트 내부의 클래스와 그들의 상호작용으로 구체화한다. 위에서 살펴본 바와 같이, 컴포넌트를 식별하고 정의하는 작업이 먼저 수행되어야 하 고, 이번 장에서는 바로 이 컴포넌트 정의에 대해 다룰 것이다. 그리고 각 개별 컴포 넌트의 내부를 설계하는 작업은 제13장과 제14장에 걸쳐 설명하도록 하겠다. 이 장 제목이 Component Modeling이지만, 제13장과 제14장까지도 Component Modeling에

301


UML을 이용한 객체지향 분석설계

포함되는 모델링 작업임을 잊지 말아야 한다.

컴포넌트 정의는 다음과 같은 순서대로 진행된다.

1.

컴포넌트 식별

2.

컴포넌트 상호작용 정의

먼저 컴포넌트 식별에 대해 알아보기로 한다. 컴포넌트 식별은 과학보다는 예술에 가 깝다고 할 만큼 분석설계자의 경험과 직관이 많이 요구되는 것이 사실이다. 따라서 컴 포넌트를 식별하기 위한 모법 답안은 존재하지 않는다. 단지, 컴포넌트 식별을 위해 사용되었던 다양한 기법들과 베스트 프랙틱스(BP)만이 존재할 뿐이다. 그렇다고 해서, 한 시스템을 개발하는 데 있어 각기 다른 컴포넌트 식별 기준이 적용되어서는 안될 것이고, 개별 소프트웨어 개발 프로젝트에서는 컴포넌트 식별에 대한 어느 정도의 명 확한 기준을 수립하여 수행하는 것이 바람직하다. 또한, 컴포넌트 식별은 단 한 번의 분석 설계자의 결정에 따라 종료되는 프로세스가 아니며, 상호작용과 설계를 거쳐 정 제의 과정을 통해 보다 나은 컴포넌트 식별이 될 수 있도록 하는 것이 중요하다.

여기서는 컴포넌트를 식별하기 위해, 2가지 방법을 사용한다. 다음은 우리가 컴포넌트 식별에 활용할 두 가지 컴포넌트 식별 기법이다. λ Core Type 식별을 통한 컴포넌트 식별 『 UML Components 』에 소개되어 가장 많이 활용되는 방식이다. 보통 도메인 모 델링에서 도출된 클래스 다이어그램을 이용하여 컴포넌트를 식별하지만, 여기서는 분석 클래스 다이어그램을 이용하여, 특히 분석 클래스들 중에 Model에 해당하는 <<Entity>> 클래스만을 활용하여, 컴포넌트를 식별한다. 클래스 중 해당 비즈니스 모델에서 중요하고 핵심적인 역할과 책임을 가지는 Core Type에 해당하는 클래스 를 찾아내고, 이 Core Type 클래스를 중심으로 응집성(Cohesion)이 높은 클래스 들은 그룹핑하고 그렇지 않은 클래스들은 결합성(Coupling)을 최소화하여 분리한다.

302


제12장 Component Modeling

즈니스 컴포넌트를 식별하는 데 사용한다. 다음 [그림 12-3]은 Core Type 식별을 통한 컴포넌트 식별 기법의 예제이다.

[그림 12-3] Core Type 식별을 통한 컴포넌트 식별 예제

λ 유스케이스를 통한 컴포넌트 식별(External Viewpoints방식) 컴포넌트는 외부와의 상호작용을 파악해 봄으로써 도출이 될 수 있다. 유스케이스 다이어그램을 통해 사용자와 시스템 간의 상호작용을 분석하면서 컴포넌트의 경계 를 선택할 수 있다. 액터 별로 한 액터가 상호작용하는 유스케이스들을 묶어 하나 의 컴포넌트로 식별하거나, 액터들이 비슷하게 상호작용하는 유스케이스들을 묶어 하나의 컴포넌트로 식별(이때 액터 별로 인터페이스는 분리)할 수 있다. 또한, 유스 케이스들 간의 관계(포함, 확장, 일반화 관계)에 따라 컴포넌트를 식별할 수도 있다. 이를 가변성이 높고 재사용성이 낮은 어플리케이션 컴포넌트를 식별하는 데 주로 사용한다. 다음 [그림 12-4]는 유스케이스를 통한 컴포넌트 식별 기법의 예제이다.

303

CHAPTER 12

이와 같은 작업을 반복함으로써 컴포넌트를 식별할 수 있다. 우리는 이를 주로 비


UML을 이용한 객체지향 분석설계

[그림 12-4] 유스케이스를 통한 컴포넌트 식별 예제

위 두 가지 기법은 어디까지나 기법일 뿐이지, 컴포넌트를 식별하는 원칙이 되어서는 안 된다. 식별된 컴포넌트는 다음과 같은 조건을 만족하는지 끊임없이 확인하여 컴포 넌트를 정제해야 한다.

λ 컴포넌트의 재사용이 용이한가? •

다른 컴포넌트에 최소한의 의존성을 가져야 한다.

상위 레벨에서 이해할 수 있는 정도의 역할이 부여되어야 한다.

λ 한 비즈니스 컴포넌트가 여러 비즈니스 도메인을 갖는가? •

컴포넌트를 구성하는 객체들이 도메인에 대해 응집성을 가져야 한다.

하나의 컴포넌트가 너무 많은 서비스를 제공하지 않도록 한다.

일반적으로 기술적 컴포넌트는 도메인에 독립적일 수 있으나 비즈니스 컴포넌 트가 도메인에 독립적이 되기는 어렵다.

독립적이게 만들면 많은 제약과 예외사항을 반영해야 하므로 너무 복잡해진다.

λ 컴포넌트는 내부를 캡슐화하고 있나? •

컴포넌트의 내부는 변경될 수 있으나, 그 변경으로 인한 외부의 변화는 최소화 되어야 한다.

304

인터페이스가 제공하고자 하는 기능을 명확히 표현해야 한다.


제12장 Component Modeling

터페이스로 표현해야 한다. 그리고 컴포넌트와 자신의 인터페이스를 다음 [그림 125]와 같이 표현한다.

[그림 12-5] 컴포넌트와 인터페이스의 실체화(Realization) 관계 세 가지

UML 2.0에서부터는 컴포넌트를 표현하는 모습이 달라졌고, 컴포넌트 다이어그램의 의미를 재정의했다. UML 1.x까지의 컴포넌트 다이어그램에서는 실행 가능한 코드, 라 이브러리, 소스코드 등과 같은 소프트웨어의 물리적인 구현 부분으로서만 컴포넌트를 정의했지만, UML 2.0에서부터는 CBD에서 컴포넌트를 모델링하고 컴포넌트를 설계할 수 있도록 소프트웨어의 논리적이고 추상적인 부분까지 표현할 수 있게 정의하고 있 다. 또한, UML 2.0의 컴포넌트는, 제공되는 인터페이스(Provided Interface)와 요구되 는 인터페이스(Required Interface)를 가질 수 있는데, 제공되는 인터페이스는 우리가 기존에 사용하던 인터페이스(컴포넌트가 서비스를 제공하기 위한 인터페이스)와 같다 고 보면 된다. 다른 점은 제공되는 인터페이스는 오퍼레이션을 가질 수 없으므로, 간

305

CHAPTER 12

이렇게 식별된 컴포넌트는, 컴포넌트 자신이 제공할 서비스 단위를 정의하고 이를 인


UML을 이용한 객체지향 분석설계

략히 컴포넌트의 인터페이스만을 표현할 때 적합하다. UML 2.0에서부터 처음 도입된 요구되는 인터페이스는 해당 컴포넌트가 필요로 하는 컴포넌트가 무엇인지 표현하는 것으로, 컴포넌트의 의존 관계를 보다 명확히 파악할 수 있게 해 준다.

다음 [그림 12-6]은 UML 2.0 스타일 컴포넌트를 적용한 컴포넌트 아키텍처 다이어 그램의 예제이다.

[그림 12-6] 컴포넌트 아키텍처 다이어그램 예제

그 다음에 여러 컴포넌트들 간의 의존(Dependency) 관계를 정의해야 하는데, 이는 컴포넌트 상호작용 정의를 통해 더욱 정확히 정의될 수 있다. 그리고 이와 같은 컴포 넌트 간의 의존도를 컴포넌트 아키텍처 다이어그램을 이용하여 표현한다. 이 컴포넌트 아키텍처 다이어그램을 통해 식별된 전체 컴포넌트들과 그 관계를 한눈에 살펴볼 수

306


제12장 Component Modeling

처의 한 축을 담당하기도 한다. 다음 3절에서 다룰 컴포넌트 상호작용 정의를 통해, 식별된 컴포넌트를 정제할 수 있고 새로운 컴포넌트를 식별할 수도 있다. 이와 같은 정제 작업을 통해, 컴포넌트 아키텍처 다이어그램이 최종적으로 완성될 것이다.

307

CHAPTER 12

있다. 또한, 전체 시스템을 가장 간단하면서도 완벽하게 표현하여, 소프트웨어 아키텍


UML을 이용한 객체지향 분석설계

3

컴포넌트 상호작용 정의

컴포넌트 식별이 끝나면, 유스케이스 단위로 유스케이스를 실체화하여 컴포넌트 상호 작용(Component Interaction) 정의를 수행한다.

컴포넌트 상호작용 정의는 시스템 내부적으로 요청되는 컴포넌트 간의 협력, 의존성을 분석함으로써 컴포넌트의 재사용성을 높이기 위해서 반드시 필요한 작업이다. 이를 통 해 컴포넌트와 컴포넌트 간에 제공해야 하는 서비스를 정의하고 정제하여, 인터페이스 를 정제할 수 있다. 즉, 인터페이스에 오퍼레이션이 추가되고 정제될 것이다.

컴포넌트 상호작용 정의는 시퀀스 다이어그램을 사용하여 작업을 수행하고, 유스케이 스 동적 분석과 마찬가지로 유스케이스 단위로 컴포넌트 상호작용 다이어그램이 작성 될 것이다. 컴포넌트 상호작용 다이어그램(시퀀스 다이어그램)을 작성할 때는, 다음과 같은 사항을 고려해야 한다. •

유스케이스 단위로, 유스케이스를 중심으로 작성되므로, 해당 시퀀스 다이어그 램은 [그림 12-7]과 같이 사용자 액터에서 시작하여, UI 레이어에 해당하는 컴 포넌트, 어플리케이션 컴포넌트, 비즈니스 컴포넌트, 외부 시스템 액터 순으로 나열하여 작성되어야 한다. 그러나, 일반적으로는 어플리케이션 컴포넌트와 비 즈니스 컴포넌트의 표현에 중점을 두어, [그림 12-8]과 같이 어플리케이션 컴 포넌트의 클라이언트, 어플리케이션 컴포넌트, 비즈니스 컴포넌트, 외부 시스템 액터 순으로 나열되어 작성된다.

308


제12장 Component Modeling

CHAPTER 12

[그림 12-7] 컴포넌트 상호작용 다이어그램에 참여하는 객체들 순서 표현

[그림 12-8] 일반적인 객체들 순서 표현

컴포넌트를 시퀀스 다이어그램에 나타낼 때는, 컴포넌트의 인터페이스 객체를 사용한다. UML 2.0에서부터는 컴포넌트에 직접적으로 오퍼레이션을 추가할 수 있지만, 인터페이스를 통해 오퍼레이션을 표현하는 것이 그 서비스를 사용하는 입장에서 바람직하다. 왜냐하면 컴포넌트에게 서비스를 요청하고자 하는 클라이 언트는 직접적으로 컴포넌트에 서비스를 요청하는 것이 아니라, 그 컴포넌트의 인터페이스를 통해 서비스를 요청하기 때문이다. 이렇게 하는 것이 컴포넌트의 구현으로부터 외부에 제공하는 서비스를 분리하여, 컴포넌트의 내부 구현의 변 경에 따른 서비스 변경을 최소화한다.

컴포넌트들 간에 메시지를 표현할 때는, 해당 컴포넌트 인터페이스의 오퍼레이 션으로 추가하여 표현하도록 한다. 이렇게 함으로써, 해당 컴포넌트가 제공해야

309


UML을 이용한 객체지향 분석설계

하는 서비스가 정의될 수 있다. •

오퍼레이션의 입·출력 데이터를 분명히 정의해야 한다. 이를 통해 어플리케이션 컴포넌트라면 DTO가, 비즈니스 컴포넌트라면 DO가 의미 있는 데이터 단위로 식별된다.

다음 [그림 12-9]는 이를 준수하는 컴포넌트 상호작용 다이어그램의 예제이다.

[그림 12-9] 컴포넌트 상호작용 다이어그램 예제

모든 유스케이스 별로 위와 같이 컴포넌트 상호작용 다이어그램을 완성하고 나면, 비 로소 모든 컴포넌트 인터페이스의 오퍼레이션이 정의되고, 그에 따라 컴포넌트들 간의 의존 관계도 명확히 정의될 것이다. 이 컴포넌트 상호작용 정의를 통해 앞 절에서 논 의했던 컴포넌트 아키텍처 다이어그램을 최종적으로 완성할 수 있다. 다음 [그림 1210]은 이를 잘 보여 준다. 컴포넌트 식별과 컴포넌트 상호작용 정의의 반복을 통해

310


제12장 Component Modeling

CHAPTER 12

모든 컴포넌트 정의는 더욱 상세화될 것이다.

[그림 12-10] 컴포넌트 상호작용 정의를 통한 컴포넌트 의존성 분석

시스템이나 소프트웨어를 이루는 컴포넌트들을 정의하는 데도, 정적 설계와 동적 설계 가 함께 진행되어야만 정확한 컴포넌트 아키텍처를 수립할 수 있다.

311


UML을 이용한 객체지향 분석설계

4

Case Study

제9장부터 제11장까지 진행하여 작성된 유스케이스 모델과 분석 모델을 바탕으로, 전 자결재 시스템을 컴포넌트 모델링하도록 한다. 이 장의 1절에서 컴포넌트에 대한 소 프트웨어 아키텍처를 정의한 바에 따라, 컴포넌트를 정의하겠다.

지금까지 배운 절차와 방법에 따라, 컴포넌트를 정의해 보면 다음과 같다.

4.1

컴포넌트(Component) 식별

앞에서 살펴본 두 가지 컴포넌트 식별 기법을 통해 컴포넌트를 식별한다.

먼저, Core Type 식별을 통해 컴포넌트를 식별해 본다. 기존의 분석 클래스 다이어그 램 중에 Model에 해당하는 클래스를 가지고 Core Type 클래스를 식별한다. 다음 [그림 12-11]은 Core Type을 식별한 클래스 다이어그램의 모습이다.

312


제12장 Component Modeling

CHAPTER 12

[그림 12-11] Core Type 식별

‘직원’ 클래스는 꼭 전자결재 시스템이 아니더라도 존재할 수 있는 클래스이고, 그 자 체로도 중요한 의미를 가지기 때문에 Core Type으로 식별했다. ‘상신문서’ 클래스는 전자결재 시스템에서 중요한 역할을 담당하는 클래스이고, 이 클래스를 중심으로 모든 관계가 형성되고 있기 때문에 Core Type으로 식별했다. 이제 Core Type 클래스를 기준으로 클래스들의 응집성을 높이고 결합성은 낮추는 방향으로 컴포넌트를 식별하 도록 한다. 다음 [그림 12-12]는 비즈니스 컴포넌트를 식별한 모습이다.

313


UML을 이용한 객체지향 분석설계

문서결재 컴포넌트

[그림 12-12] Core Type을 통한 컴포넌트 식별

‘직원’ 클래스는 다른 클래스들과 결합성을 낮추기 위해 별도의 컴포넌트로 식별했다. ‘상신문서’ 클래스는 자신을 중심으로 응집성이 높은 나머지 클래스들을 그룹핑 하여 컴포넌트로 식별했다. 이렇게 하여 비즈니스 컴포넌트의 후보로 ‘문서결재’ 및 ‘직원’ 컴포넌트가 도출되었다.

이제 유스케이스를 통해 컴포넌트를 식별하도록 한다. 다음 [그림 12-13]은 유스케이 스 다이어그램의 사용자 액터를 중심으로 유스케이스를 그룹핑하는 모습이다.

314


제12장 Component Modeling

CHAPTER 12

ud 최종 유스케이스 다이어그램 전자결재시스템

문서 상신

«include»

사용자 검색 통합사용자시스템

문서관리 컴포넌트

상신자 상신문서 조회

문서 조회

결재된문서 검색 직원

결재문서 조회

결재관리 컴포넌트 결재자 문서 결재

«extend»

문자메시지 전송 SMS

[그림 12-13] 유스케이스를 통한 External Viewpoints 방식으로 컴포넌트 식별

위 그림을 보면, ‘직원’ 액터와 ‘상신자’ 액터를 하나로 묶은 것을 볼 수 있다. 이렇게 한 이유는, ‘직원’ 액터를 ‘상신자’ 액터와 거의 같은 권한을 가진 것으로 분석했기 때 문이다. 즉, 모든 직원은 상신을 할 수 있지만, 몇몇 직원만이 결재를 할 수 있을 것 이다. 이에 따라서 ‘직원’ 액터와 ‘상신자’ 액터를 하나로 묶어 유스케이스를 그룹핑했 다.

두 개의 액터 그룹으로 인해 ‘문서관리’와 ‘결재관리’ 컴포넌트가 도출되었다. 이 컴포 넌트들은 어플리케이션 컴포넌트의 후보가 된다.

지금까지 두 가지 기법으로 인해 식별된 컴포넌트들을 컴포넌트 아키텍처 다이어그램

315


UML을 이용한 객체지향 분석설계

으로 나타내 보면 다음 [그림 12-14]와 같다. 이 컴포넌트 아키텍처 다이어그램은 최 종이 아니고, 다음의 컴포넌트 상호작용 정의를 수행한 뒤에 최종 컴포넌트 아키텍처 다이어그램이 작성될 수 있다.

id 초기 컴포넌트 아키텍처 다이어그램

I문서관리

«Application» 문서관리

I결재관리

«Application» 결재

IBiz I문서결재 «Business» 문서결재

«Business» 직원

[그림 12-14] 초기 컴포넌트 아키텍처 다이어그램

위 컴포넌트 아키텍처 다이어그램은 앞에서 식별한 네 개의 컴포넌트들을 가지고 의 존 관계를 파악하여 작성했다. 어플리케이션 컴포넌트와 비즈니스 컴포넌트를 각각 스 테레오 타입을 이용하여 표현하고, 어플리케이션 컴포넌트에서 비즈니스 컴포넌트를 호출하는 부분을 명시적으로 표현할 수 있게 UML 2.0에서부터 제공하는 요구되는 인 터페이스(Required Interface)를 이용하여 표현했다.

4.2

컴포넌트 상호작용(Component Interaction) 정의

유스케이스를 작성 단위로 하여, 컴포넌트 상호작용 다이어그램을 작성한다. 컴포넌트

316


제12장 Component Modeling

하고, 컴포넌트의 오퍼레이션을 새롭게 식별할 수 있다.

다음 [그림 12-15]는 ‘문서 상신’ 유스케이스에 대한 컴포넌트 상호작용 다이어그램 이고, 어플리케이션의 클라이언트에서부터 상호작용이 시작하도록 한다. s d 문서상신 컴포넌트 상호작용 정의 Client

«interface» :문서관리App

«interface» :문서결재Biz

«interface» :직원Biz 외부 시스템 액터

requestDocument(userID) create(userID) loop 결재자추가 registerApproved(employeeName) addApproved(employeeName) inquireEmployee(employeeName) inquireEmployee [동명이인 비존재]: 결재자 정보 [동명이인이 존재]: 동명이인 목록

[결재자가 동명이인일 경우]: chooseApproved(employee) addApproved(employee)

attachFile(file) addFile(document)

reportDocument(document) report(document)

[그림 12-15] 컴포넌트 상호작용 다이어그램

위 시퀀스 다이어그램을 보면, ‘문서관리’ 어플리케이션 컴포넌트와 ‘문서결재’ 및 ‘직 원’ 비즈니스 컴포넌트가 참여하여 컴포넌트 상호작용을 정의하고 있음을 알 수 있다.

317

CHAPTER 12

상호작용 정의를 통해 한 유스케이스에 참여하는 컴포넌트들을 간의 의존성 분석을


UML을 이용한 객체지향 분석설계

또한, 시퀀스 다이어그램의 중간쯤에 나타나 있는 loop 프래그먼트(Fragment)를 통해 반복적으로 작업이 이루어 지는 부분을 표현하고 있다. UML 2.0에서부터는 각종 프래 그먼트를 지원하여, 보다 정확하고 효과적인 시퀀스 다이어그램을 작성하도록 지원한 다.

이 컴포넌트 상호작용 다이어그램을 작성하면서 잊지 말아야 할 것은, 컴포넌트의 오 퍼레이션으로 메시지를 추가해야 한다는 것이다. 또한, DTO나 DO를 식별하여, 각 오 퍼레이션의 입·출력 데이터를 명확히 정의하는 것도 필요하다.

다음 [그림 12-16]은 모든 유스케이스 별로 컴포넌트 상호작용 정의를 수행한 후, 오 퍼레이션이 정의된 각 인터페이스를 컴포넌트가 구현하여 표현한 최종 컴포넌트 아키 텍처 다이어그램이다. 여기서는 제공되는 인터페이스(Provided Interface)와 요구되는 인터페이스(Required Interface)를 사용하지 않고, 컴포넌트 상호작용 정의에서 사용 한 인터페이스를 이용하여 표현했다.

id 최종 컴포넌트 아키텍처 다이어그램 «Application» 문서관리 «realize» + + + + +

I문서관리App

«Application» 결재

requestDocument(String) : DocumentDTO registerApproved(String) chooseApproved(EmployeeDTO) reportDocument(DocumentDTO) attachFile(AttachedFileDTO)

I결재

«realize» + + + +

«Business» 문서결재 «realize» + + I문서결재Biz + + +

create(String) addApproved(String) addApproved(Employee) report(Document) addFile(Document)

«Business» 직원

≪realize≫

I직원Biz

approve(String) : void reject(String) : void getApprovalDocumentList(String) : List getApprovalDocument(String) : DocumentDTO

+

inquireEmployee(String)

[그림 12-16] 인터페이스를 구현한 최종 컴포넌트 상호작용 다이어그램

컴포넌트 정의가 모두 끝나면, 이제 각 컴포넌트 별로 그 컴포넌트를 이루는 구성요소

318


제12장 Component Modeling

이는 다음 장에서 순서대로 배우도록 한다.

319

CHAPTER 12

들을 찾아내고, 소프트웨어 아키텍처에 정해진 디자인 패턴을 참조하여 설계해야 한다.


Chapter

13

Structural Modeling - Design

1 절 컴포넌트 정적 설계 2 절 Case Study

학습목표 Φ 컴포넌트의 내부 구성요소를 정적으로 설계하는 방법을 학습한다. Φ 컴포넌트 정적 설계를 통해 클래스 다이어그램을 작성하는 방법을 학습한 다.


설계 단계의 구조적 모델링에서는 컴포넌트 내부 구성요소들에 대한 정 적 설계 작업을 수행한다. 컴포넌트 정적 설계를 통해, 컴포넌트가 인 터페이스를 통해 제공하고자 하는 서비스와 기능을 내부적으로 구현할 클래스들을 도출하고 클래스들의 속성과 상관 관계를 정의한다. 이 장에서는 컴포넌트의 내부 클래스들을 소프트웨어 아키텍처에 따라 식별하고 그 클래스들 간의 협력 관계를 어떻게 정의하는지, UML을 사 용한 컴포넌트 모델링의 정적 설계 기법에 대해 배워 본다.


제13장 Structural Modeling - Design

CHAPTER 13

1

컴포넌트 정적 설계

컴포넌트 모델링은 앞장에서 다루었던 컴포넌트 식별과 컴포넌트 상호작용 정의만이 전부가 아니다. 앞장에서 설명했던 컴포넌트 정의는 시스템이나 소프트웨어를 구성하 는 컴포넌트를 찾아내고 컴포넌트들 간의 관계로 이를 표현했던 것이라면, 지금부터 다룰 내용은 각 개별 컴포넌트의 내부를 설계하는 것이다.

컴포넌트 설계는 유스케이스 분석과 마찬가지로, 정적 설계 부분과 동적 설계 부분으 로 나눌 수 있다. 이 장에서는 먼저 컴포넌트 정적 설계에 대해 살펴보기로 한다.

컴포넌트 정적 설계에서는 유스케이스 분석 모델을 바탕으로 서버 로직을 구현할 클 래스를 설계한다. 컴포넌트의 인터페이스에서 제공하는 서비스를 컴포넌트 내부 클래 스의 오퍼레이션으로 상세히 정의하고 클래스 간 상호 관계를 정의한다. 컴포넌트 정 적 설계는 컴포넌트 별로 클래스 다이어그램을 작성하는 것이 일반적이지만, 서로 연 관이 깊은 컴포넌트에 대해서는 같은 클래스 다이어그램에 표현해도 무방하다. 다음은 컴포넌트 정적 설계를 진행하는 일반적인 순서이다.

1.

분석 클래스들을 설계 클래스로 확정한다. 이때, 클래스명이나 속성명, 오퍼레이션명 등이 영문으로 전환되어 있지 않았 으면, 모두 전환하도록 한다. 왜냐하면 설계 단계에서부터는 개발을 고려해야 하고, 개발을 하기 위한 대부분의 기술 환경(프로그래밍 언어, DB, 각종 설정 파일 등)이 영어로 되어 있기 때문에, 설계 클래스부터는 영문화하여 작업하 는 것이 바람직하기 때문이다.

323


UML을 이용한 객체지향 분석설계

2.

확정된 분석 클래스들을 나누어, 각각의 컴포넌트로 할당한다. 이때, Controller 클래스들은 주로 어플리케이션 컴포넌트로, Model 클래스들 은 주로 비즈니스 컴포넌트로 할당된다.

3.

소프트웨어 아키텍처에 따라 컴포넌트 내부의 클래스들을 식별하고 클래스들 간의 정적인 상관 관계를 정의한다. 분석 단계에서 넘어온 분석 클래스들은 소프트웨어 아키텍처에 정의된 디자 인 패턴에 따라 책임과 역할을 가진 클래스들로 변환된다. 또한, 컴포넌트는 자신의 인터페이스를 구현할 내부 구현 클래스를 하나 이상 식별해야 하는데, 분석 클래스들 중에 Controller 클래스는 이 역할에 적합하다.

이와 같이 컴포넌트 정적 설계가 끝나면, 컴포넌트의 내부 클래스들을 볼 수 있는 클 래스 다이어그램이 완성된다. 다음 [그림 13-1]은 컴포넌트 경계와 함께 내부 클래스 들을 표현한 클래스 다이어그램이다.

[그림 13-1] 컴포넌트 내부 클래스 다이어그램

324


제13장 Structural Modeling - Design

현할 수 있어, 컴포넌트의 White-Box View를 공식적으로 가능하게 해 준다. 위 클래 스 다이어그램은 이 포트를 컴포넌트와 함께 표현하여, 컴포넌트 내부 클래스가 포트 를 통해 컴포넌트 인터페이스를 구현하도록 표현할 수 있다. 또한, 포트는 앞장에서 살펴보았던

제공되는

인터페이스(Provided

Interface)와

요구되는

인터페이스

(Required Interface)를 가질 수 있어, 컴포넌트가 다양한 인터페이스를 표현할 수 있 게 했다.

다음 [그림 13-2]는 컴포넌트 내부 클래스 다이어그램 예제이다. 이 예제는 컴포넌트 경계를 표현하지 않았다. 컴포넌트 경계를 반드시 표현할 필요는 없지만, 컴포넌트 경 계를 표현함으로써, 요구되는 인터페이스를 통해, 해당 컴포넌트가 의존하는 컴포넌트 가 무엇이지 알 수 있다. 이는 아래와 같은 기존의 예제에서는 찾아볼 수 없는 것이다. 또한, 여러 컴포넌트를 한 클래스 다이어그램에 나타내야 할 경우, 컴포넌트 경계를 표현하는 것이 유용하다.

[그림 13-2] 예전 컴포넌트 내부 클래스 다이어그램 예제

325

CHAPTER 13

UML 2.0에서부터는 포트(Port)를 통해 컴포넌트 내부와 외부를 연결하는 지점을 표


UML을 이용한 객체지향 분석설계

다음 [그림 13-3]은 위의 클래스 다이어그램을 컴포넌트 경계를 표현한 UML 2.0 스 타일로 변경한 클래스 다이어그램이다.

[그림 13-3] 컴포넌트 경계를 표현한 컴포넌트 내부 다이어그램 예제

컴포넌트 설계 막바지에는 컴포넌트 및 컴포넌트를 구성하는 각 클래스들을 기술 플 랫폼에 맞게 상세 설계하는 것이 필요하다. 그래야만, 컴포넌트와 클래스가 실제 개발 시에 사용될 수 있기 때문이다. 그러나 UML 2.0이 나오면서, MDA 기반의 소프트웨 어 개발 방식이 구체화되고, 플랫폼 독립적인 모델(PIM: Platform Independent Model)을 플랫폼 종속적인 모델(PSM: Platform Specific Model)로 변환하고 소스 코

326


제13장 Structural Modeling - Design

모델을 굳이 기술 플랫폼에 맞추어 변환하지 않아도 될 날이 올지도 모르겠다. 여하튼 이에 대한 연구가 한참이기 때문에, 조만간 희소식이 날아올지도 모르겠다.

327

CHAPTER 13

드까지 자동으로 생성해 주는 자동화 툴들이 속속 나오고 있기 때문에, 컴포넌트 설계


UML을 이용한 객체지향 분석설계

2

Case Study

제12장의 Case Study에서 주어진 컴포넌트 모델에 이어서 정적 설계를 하도록 한다.

2.1

분석 클래스의 설계 클래스로의 변환

기존의 분석 클래스들을 설계 클래스로 변환하기 위해, 기존의 분석 클래스들을 영문 화하고, 해당 클래스가 구현 가능한지를 판단하여, 설계 클래스로 변환한다. 다음 [그 림 13-4]는 기존 분석 클래스들을 설계 클래스로 변환한 클래스 다이어그램의 모습 이다.

328


제13장 Structural Modeling - Design

CHAPTER 13

cd 설계 클래스로의 변환 AttachedFile

Appr ovalPath -

-

ApprovedID: Order: 1..* 참조한다

ID: Name: Path: Size: 0..*

첨부한다

1

S hor tMes s age

1

-

«core» Document + 상신한다 + 0..* + + + +

Contents: ReporterPhonNumber:

Title: Contents: ReportDate: ReportNote: Get() Save() Search() Report() Approve() Reject()

Appr oval 결재하다 1

1..*

-

Status: ApprovalDate:

+ +

Search() Get()

+상신자 1

1..*

«core» Employee -

Name: SSN: DepartmentCode: Position: +상신자

+결재자 1

결재하다

+결재자

결재요청

[그림 13-4] 분석 클래스의 설계 클래스로의 변환

[그림 13-4]의 클래스 다이어그램을 보면 대부분은 단순히 영문으로 이름이 바뀌기 만 했는데, ‘Employee’ 클래스에 대해서만은 기존의 ‘상신자’, ‘결재자’, ‘직원’의 세 개 클래스들을 ‘Employee’ 클래스 하나로 합쳤다. 그리고 기존 ‘상신자’와 ‘결재자’ 클래 스의 역할은 각각의 ‘상신한다’와 ‘결재한다’의 연관 관계에 ‘상신자’와 ‘결재자’라는 ‘Employee’ 클래스의 역할로 표현되었다. 이렇게 한 이유는 기존의 ‘상신자’와 ‘결재 자’ 클래스에 ‘직원’과 다른 추가적인 속성이나 기능이 없었고 단순히 역할만 표현하 는 클래스이기 때문이다. 또한, ‘직원’ 클래스 하나가 해당 비즈니스 기능과 정보를 좀 더 구현가능하도록 한다.

329


UML을 이용한 객체지향 분석설계

2.2

각 컴포넌트로 클래스 할당

설계 클래스로 변환된 분석 클래스들을 각 컴포넌트에 할당한다. 제12장에서 Core Type을 이용하여 컴포넌트를 식별할 때, 어느 정도는 각 클래스들이 어느 컴포넌트로 할당되어야 하는지 결정하였다. 따라서, 그에 따라 클래스들을 각 컴포넌트에 할당하 면 될 것이다.

Model 클래스들은 이 Core Type을 이용한 컴포넌트 식별 기법에 따라 할당되어야 할 컴포넌트가 결정되었지만, Control이나 View에 해당하는 클래스들은 새로 할당해 주어야 한다. 일반적으로 Control 클래스는 어플리케이션 컴포넌트에 할당하면 된다. 또한, View클래스 중 UI에 해당하는 클래스는 컴포넌트에 할당할 필요가 없고, SI에 해당하는 클래스는 응집성이 높은 비즈니스 컴포넌트에 할당하면 된다. 만약, 적당한 비즈니스 컴포넌트를 찾지 못한다면, 새로 식별해도 된다. 다음 [그림 13-5]는 각 컴 포넌트에 할당된 클래스들의 모습이다.

330


제13장 Structural Modeling - Design

CHAPTER 13

[그림 13-5] 컴포넌트 아키텍처 다이어그램에 분석 클래스 할당

331


UML을 이용한 객체지향 분석설계

2.3

소프트웨어 아키텍처에 따른 컴포넌트 내부 정적 설계

각 컴포넌트로 분석 클래스들이 할당되었으면, 이제 정의된 소프트웨어 아키텍처에 따 라 컴포넌트 내부 정적 설계를 수행한다. 소프트웨어 아키텍처에 정의된 디자인 패턴 에 따라 컴포넌트 내부 클래스들에게 책임과 역할을 위임하고, 그러한 역할을 수행할 클래스가 없다면 새로 식별한다. 그리고 각 클래스들 간의 정적 관계를 정의한다. 다 음 [그림 13-6]은 최종적으로 완성한 ‘문서결재’ 컴포넌트의 클래스 다이어그램이다.

[그��� 13-6] 문서결재 컴포넌트의 클래스 다이어그램

332


제13장 Structural Modeling - Design

스가 새롭게 도출된 것을 알 수 있다. 이는 소프트웨어 아키텍처에 정의된 Façade와 DAO 디자인 패턴을 책임질 클래스가 없기 때문에, ‘DocumentApprovalFacade’와 ‘DocumentApprovalDAO’ 클래스를 새로 식별하여 정의한 것이다. 만약 컴포넌트 설 계 시에 새로운 디자인 패턴을 사용해도 상관없다. 이때는 해당 컴포넌트에 어떠한 이 유로 새로운 디자인 패턴을 적용했는지 명확한 근거를 제시해야 한다.

333

CHAPTER 13

위 다이어그램을 보면 ‘DocumentApprovalFacade’와 ‘DocumentApprovalDAO’ 클래


Chapter

14

Behavioral Modeling - Design

1 절 컴포넌트 동적 설계 2 절 Case Study

학습목표 Φ 컴포넌트의 내부 구성요소를 동적으로 설계하는 방법을 학습한다. Φ 컴포넌트 동적 설계를 통해 시퀀스 다이어그램을 작성하는 방법을 학습한 다.


설계 단계의 행위적 모델링에서는 컴포넌트 내부 구성요소들에 대한 동 적 설계 작업을 수행한다. 컴포넌트 동적 설계를 통해, 컴포넌트가 서 비스를 제공할 수 있도록 내부 클래스들의 순차적인 상호작용 관계를 정의한다. 이 장에서는 컴포넌트 인터페이스의 오퍼레이션에 따라 내부 클래스들 간의 상호작용 관계를 어떻게 정의하는지, UML을 사용한 컴포넌트 모 델링의 동적 설계 기법에 대해 배워 본다.


제14장 Behavioral Modeling - Design

CHAPTER 14

1

컴포넌트 동적 설계

컴포넌트 동적 설계는 컴포넌트 인터페이스의 오퍼레이션에 따라 내부 클래스 간의 상호작용을 순차적으로 정의하고, 그에 따라 컴포넌트의 내부 구조를 정제한다. 컴포 넌트를 동적 설계하는 데 가장 중요한 점은, 컴포넌트가 제공하는 서비스를 구현하는 데 필요한 내부 클래스들이 무엇이며, 그들 간의 상호작용 관계가 무엇인지 파악할 수 있다는 것이다. 여기서 말하는 컴포넌트가 제공해야 하는 서비스란, 컴포넌트가 구현 할 인터페이스에 정의된 오퍼레이션을 말한다.

컴포넌트를 동적 설계하기 위해 UML의 시퀀스 다이어그램을 사용하고, 이 시퀀스 다 이어그램은 컴포넌트 별로 작성한다. 만약 인터페이스의 특정 오퍼레이션이 복잡하거 나 상대적으로 중요하여 자세히 살펴보아야 할 경우, 별도의 시퀀스 다이어그램을 사 용하여 작성할 수도 있다. 또한, 시퀀스 다이어그램을 작성하면서 내부 클래스가 가져 야 할 오퍼레이션이 무엇인지 찾아낼 수 있다.

이 컴포넌트 동적 설계의 시퀀스 다이어그램은 앞장의 컴포넌트 상호작용 정의에서 작성했던 시퀀스 다이어그램과 연결된다. 즉, 컴포넌트 상호작용 정의에서는 컴포넌트 수준의 상호작용을 상위 수준으로 정의했다면, 컴포넌트 동적 설계에서는 각 컴포넌트 인터페이스의 오퍼레이션 내부의 복잡한 상호작용 관계를 정의한다. UML 2.0에서부터 는 다양한 분해(Decomposition) 기법(Composite 요소로 선언, 외부 Fragment를 사 용 등)을 다이어그램 작성 시에 사용하여 이를 다양한 방법으로 표현할 수 있다. 다음 [그림 14-1]은 컴포넌트 상호작용 다이어그램과 컴포넌트 설계 시퀀스 다이어그램의 관계를 나타내고 있다.

337


UML을 이용한 객체지향 분석설계

[그림 14-1] 컴포넌트 모델링에서의 두 가지 시퀀스 다이어그램

대규모의 복잡한 시스템의 경우라면, 위와 같이 컴포넌트 상호작용 정의 후에, 각각의 컴포넌트 별로 세부적으로 동적 설계를 수행할 수 있다. 그러나 작은 규모의 시스템이 나 간단한 소프트웨어일 경우에는 이 두 가지 시퀀스 다이어그램을 하나로 합쳐서 작 성해도 무방하다.

설계 단계의 시퀀스 다이어그램을 작성할 때는, 다음과 같은 사항을 고려해야 한다. •

컴포넌트 단위로 시퀀스 다이어그램을 작성할 때는, [그림 14-2]와 같이 컴포 넌트 인터페이스에서부터 시작하여, 인터페이스의 구현 클래스, 각종 내부 클래 스들 순으로 나열하여 작성하는 것이 좋다.

338


제14장 Behavioral Modeling - Design

CHAPTER 14

[그림 14-2] 시퀀스 다이어그램에 참여하는 객체들 순서 표현

실행 시점에 객체가 새로 생성되는 것에 대해서도 시퀀스 다이어그램에 명확히 표현해야 한다. 특히, 분석 단계에서 입·출력 데이터로만 표현하고 말았던 DTO 와 DO 객체에 대해서 객체가 생성되는 시점을 명확히 표현해 주어야 한다.

클래스들 간에 메시지를 표현할 때는, 해당 클래스의 오퍼레이션으로 추가하여 표현한다. 이렇게 함으로써, 해당 클래스가 제공해야 하는 기능에 따른 오퍼레 이션이 정의될 수 있다.

설계 수준의 시퀀스 다이어그램에서의 오퍼레이션은 입력값(Input Parameters) 과 결과값(Return Type)을 반드시 정의해야 한다.

시퀀스 다이어그램만으로 오퍼레이션이 제공하는 기능 및 서비스를 표현하기 어려울 경우나 상대적으로 중요할 경우에는, 이 오퍼레이션에 대한 추가적인 명 세서를 작성할 수 있다. 다음 [그림 14-3]은 오퍼레이션에 추가할 수 있는 명 세서에 대해 보여 주고 있다.

339


UML을 이용한 객체지향 분석설계

[그림 14-3] 오퍼레이션에 대한 Pre-Condition과 Post-Condition의 명세

[그림 14-3]의 예제는 『 UML Components 』 에서 소개된 컴포넌트 명세하는 부분 중 하나이다. 특히, 위의 Pre-Condition과 Post-Condition은 오퍼레이션에 대해 명세 하는 방법을 보여 준다. 먼저, 오퍼레이션에 대한 전체 시그니처를 그림의 맨 위 (context로 시작하는 부분)와 같이 기술한다. 이 시그니처에는 인터페이스명과 오퍼레 이션명, 입력값, 결과값이 모두 표현된다. 그 다음으로, Pre-Condition은 해당 오퍼레 이션이 실행되기 위한 조건이면서 Post-Condition이 보장되기 위한 조건을 정의한다. 그리고 Post-Condition은 해당 오퍼레이션이 종료되기 위해 수행되어야 할 조건을 정 의하며, 따라서 오퍼레이션의 결과를 정의한다. 즉, 오퍼레이션이 결과값을 만들기 위 한 모든 로직이 표현된다. 이와 같은 Pre-Condition과 Post-Condition은 일반 자유 로운 문장이나 OCL(Object Constraint Language)로 작성될 수 있으나, 위의 예와 같 이 UML 표준인 OCL을 사용하여 작성하는 것이 보다 명세의 일관성과 명확성을 향 상시킬 수 있다.

다음 [그림 14-4]는 컴포넌트 동적 설계의 시퀀스 다이어그램 예제이다.

340


제14장 Behavioral Modeling - Design

CHAPTER 14

[그림 14-4] 컴포넌트 설계 시퀀스 다이어그램 예제

[그림 14-4]의 시퀀스 다이어그램과 같이 컴포넌트 별로 컴포넌트 동적 설계가 완성 되고 나면, 모든 컴포넌트의 내부 클래스들까지도 완전하게 동적 설계가 끝난 것이다. 이에 따라, 앞장에서 작성했던 컴포넌트 정적 설계 모델을 정제할 수 있다. 이렇게 정 제된 최종 클래스 다이어그램을 통해 빠진 클래스나 클래스의 속성 또는 오퍼레이션 이 없는지 재점검한다.

설계 단계에서는 정적 설계와 동적 설계의 긴밀한 상호보완 관계를 통해 컴포넌트 설 계 모델을 반복·점진적으로 완성해 나간다. 정적 설계와 동적 설계의 반복 작업을 통 해, 정적 설계 모델과 동적 설계 모델은 서로 일관성을 유지하려고 발전할 것이고, 이 는 결과적으로 컴포넌트 모델 전체와 소프트웨어 아키텍처를 한층 향상시킬 것이다.

341


UML을 이용한 객체지향 분석설계

2

Case Study

제13장의 Case Study에서 주어진 컴포넌트 모델에 이어서 동적 설계하도록 한다.

앞 장에서 컴포넌트 정적 설계를 했던 ‘문서결재’ 컴포넌트를 가지고, 컴포넌트 동적 설계를 수행한다. 다음 [그림 14-5]는 ‘문서결재’ 컴포넌트의 시퀀스 다이어그램이다.

[그림 14-5] 문서결재 컴포넌트의 시퀀스 다이어그램

342


제14장 Behavioral Modeling - Design

의된다. 클래스 간의 메시지를 표현할 때는 오퍼레이션으로 정의하여 표현하는 것을 잊지 말아야 하며, 각 오퍼레이션을 정의할 때는 입·출력값을 함께 정의하는 것도 잊 지 말아야 한다. 또한 Façade 클래스 같은 경우에는 인터페이스를 구현하므로, 자동 으로 인터페이스의 오퍼레이션을 갖게 된다. 즉, 추가적으로 오퍼레이션을 식별하지 않아도 된다. 대신 DAO나 그 밖의 DO 클래스들은 추가적으로 오퍼레이션을 식별하 여 정의해야 한다.

시퀀스 다이어그램의 중간에 보면 loop 프래그먼트(Fragment)를 볼 수 있을 것이다. ‘결재가 추가’ loop 프래그먼트 안에 존재하는 메시지 처리 흐름은 결재자가 최종 결 재자일 때까지 반복될 것이다. 또한 ‘파일 추가’ loop 프래그먼트도 마찬가지로 파일이 마지막 파일일 때가지 반복될 것이다. 이와 같이 조건(Condition)을 표현할 수 있다.

시퀀스 다이어그램의 가장 마지막 메시지를 보면, ‘*₩getter₩’라고 되어 있음을 알 수 있다. 앞의 ‘*’는 한 메시지 자체에 대한 반복을 표현한다.

343

CHAPTER 14

위 시퀀스 다이어그램을 작성하면서, 각종 내부 클래스들의 오퍼레이션들이 추가로 정


Chapter

15

Deployment Modeling - Design

1 절 디플로이먼트 모델링 2 절 Case Study

학습목표 Φ 시스템의 내부 구성요소를 물리적으로 모델링하는 방법을 학습한다. Φ 시스템을 물리적으로 모델링하기 위해, 디플로이먼트 다이어그램을 작성하 는 방법을 학습한다.


디플로이먼트 모델링은 시스템을 물리적인 관점으로 모델링하는 것으 로, 각종 하드웨어들과 소프트웨어들을 배치하고 그들 간의 관계를 정 의한다. 이 장에서는 시스템이 각종 하드웨어와 소프트웨어들로 어떻게 구성되 어 있는지, UML을 사용한 디플로이먼트 모델링 기법에 대해 배워 본다.


제15장 Deployment Modeling - Design

CHAPTER 15

1

디플로이먼트 모델링

디플로이먼트 모델링(Deployment Modeling)은 물리적으로 존재하는 구성요소들을 가 지고 시스템 내부를 모델링하는 것이다. 따라서, 디플로이먼트 모델링을 물리적 모델 링이라고 불러도 무방하다.

시스템 설계와 개발이 끝나면, 실제 개발된 시스템을 물리적인 관점에서 표현해 볼 필 요가 있다. 또한, 기술 아키텍처를 작성할 때나 컴포넌트 설계 후에 컴포넌트를 서버 에 배치할 때, 물리적인 관점의 모델링을 수행한다. 여기서는 설계나 개발 후에, 실제 컴포넌트들의 배치를 물리적으로 모델링하는 방법에 대해 살펴본다. 이를 위해 UML 의 디플로이먼트 다이어그램을 사용할 것이다.

다음은 이를 위한 물리적 모델링의 절차이다.

1.

노드(Node) 식별

2.

노드(Node) 간의 관계 정의

3.

아티팩트(Artifact) 식별

4.

아티팩트 배치(Deployment)

이제 위의 절차에 따라 물리적 모델링을 세부적으로 살펴 보기로 한다.

347


UML을 이용한 객체지향 분석설계

1.1

노드(Node) 식별

먼저, 노드(Node)의 대상을 찾아 보도록 하겠다. 노드의 대상이 될 수 있는 것은 시 스템을 구성하는 하드웨어로서, 시스템에 온라인 또는 오프라인으로 연결되어 필요한 기능을 수행하거나 자원을 관리하는 하드웨어들이다. 구현하고자 하는 시스템에 따라 하드웨어에 연결된 장치 또는 센서들도 노드의 대상이 되기도 한다. 예를 들어, 자동 항법 시스템을 개발하고자 할 때 GPS는 시스템의 주요 구성품 중의 하나에 해당하는 센서이며 노드가 된다.

다음은 노드를 식별할 때 주의해야 할 사항이다. •

노드는 개념적으로 의미가 있는 하드웨어 단위로 찾는다. 예를 들어, 은행 창구 가 여러 개 있을 때 노드를 은행 창구의 개수만큼 찾을 필요는 없다. 단지 ‘은 행 창구 컴퓨터’라는 개념으로 노드를 찾으면 된다.

노드를 너무 세분화하여 노드 자체적으로는 기능을 수행하지 못하는 형태로 찾 지 않는다. 예를 들어, 은행 창구에서 사용하는 컴퓨터는 실제로 본체, 모니터, 키보드, 마우스 등으로 구성되지만, 각각의 구성품은 자체만으로는 의미가 없고 서로 합쳐져야 의미가 있으므로 세분화하지 않는다. 그러나 프린터, CD Writer(백업 장치) 등과 같이 구성품이라도 의미가 있는 것은 별도의 노드로 식 별할 수 있다.

1.2

노드 간의 관계 정의

노드 간의 관계 정의는 노드 간의 커뮤니케이션 경로(Communication Path)를 정의하 는 것이다. 노드 간의 연결 관계는 실제 물리적으로 연결된 것을 대상으로 한다.

또한, 실제 물리적으로 연결되어 있다고 하더라도 시스템 구현과 직접적인 관련이 없

348


제15장 Deployment Modeling - Design

되어 있는 컴퓨터들을 연결하기 위해 실제로 랜카드, 허브 등 여러 종류의 하드웨어가 컴퓨터들 간에 연결되어 있다. 그러나 구현 범위에 네트워크 설치가 포함되어 있지 않 다면, 이를 표현할 필요 없이 관련 연결이 필요한 컴퓨터들을 직접 연결하여 표현해야 한다. 때에 따라서 네트워크를 설치하는 데 사용되는 장비의 종류나 연결 방법이 중요 하다면 이에 대한 별도의 디플로이먼트 다이어그램을 작성할 수 있다.

다음 [그림 15-1]은 노드 간의 관계를 정의한 디플로이먼트 다이어그램의 예를 보여 준다.

dd 노드(Node) 간의 관계 정의 Application Ser ver

DB Ser ver <<TCP/IP>> *

1

[그림 15-1] 노드(Node) 간의 관계 정의

위 다이어그램을 보면, ‘Application Server’와 ‘DB Server’를 노드로 표현했고, 그들 간의 관계에 대한 통신 프로토콜은 <<TCP/IP>>로, 관계수는 n : 1로 표현했다.

1.3

아티팩트(Artifact) 식별

노드와 연결을 찾은 다음 디플로이먼트 다이어그램을 작성한 후, 노드를 구성하는 아 티팩트(Artifact)를 식별한다.

아티팩트는 UML 2.0에서부터 도입된 개념으로, 시스템을 구성하는 물리적인 파일 또 는 조각이다. 아티팩트를 통해 시스템에 필요한 하나의 DLL이나 사용자 매뉴얼, 실행 파일들을 나타낼 수 있다. 아티팩트는 기존 UML 1.x의 컴포넌트의 개념을 대체한다

349

CHAPTER 15

는 경우에는 개념적으로 연결할 수도 있다. 예를 들면 다음과 같다. 네트워크로 연결


UML을 이용한 객체지향 분석설계

(UML 2.0에서부터는 컴포넌트가 더 이상 물리적인 것을 의미하지 않고, 이를 아티팩 트로 대체했다).

일반적으로 식별할 수 있는 아티팩트의 종류는 다음과 같다. λ 설치 파일 exe, dll 등과 같이 직접적으로 실행에 관여하는 파일, 그리고 hlp와 같은 온라인 도움말 파일 등이 이에 해당한다. λ 산출물 소스 코드나 문서 파일, 자료 파일과 같이 개발 결과로 작성되었으나 실행에 직접 참여하지 않는 파일들이 이에 해당한다. λ DB 스키마 DB 서버에 설치되어야 할 각종 DB 스키마 관련 스크립트가 이에 해당한다.

1.4

아티팩트(Artifact) 배치

이렇게 식별된 아티팩트들을 적절한 노드에 배치한다. 노드와 아티팩트의 배치 관계를 표현할 경우 디플로이먼트 다이어그램이 복잡해진다. 이런 경우 노드 별로 별도의 디 플로이먼트 다이어그램을 작성하는 것도 좋은 방법이다. 다음 [그림 15-2]는 노드에 아티팩트를 배치하는 다양한 표현의 예들을 보여 준다.

350


제15장 Deployment Modeling - Design

CHAPTER 15

dd 노드(Node)와 아티팩트(Ar tifact) 간의 관계 정의 DB Ser ver

Application Ser ver

<<TCP/IP>> *

«deploy» «deploy»

«artifact» HotelMgr.jar

«artifact» StayMgr.jar

1

«deploy»

«artifact» Hotel DB Schema

[그림 15-2] 노드(Node)와 아티팩트(Artifact) 간의 관계 정의

351


UML을 이용한 객체지향 분석설계

2

Case Study

지금까지 작업했던 Case Study를 이어서 디플로이먼트 모델링을 수행한다. 다음 [그림 15-3]은 전자결재 시스템에 대해서 디플로이먼트 다이어그램으로 표현한 모습이다.

[그림 15-3] 전자결재 시스템의 디플로이먼트 다이어그램

352


제15장 Deployment Modeling - Design

자체는 어플리케이션 서버와 DB 서버로 나누어 노드로 표현했고, 외부 시스템 액터로 존재했던 통합 사용자 시스템과 SMS도 별도의 노드로 표현했다.

그리고 제12장 컴포넌트 모델링에서 식별했던 네 개의 컴포넌트를 각기 하나의 jar 파일로 만들어 ‘전재결재 어플리케이션 서버’에 배치했다.

353

CHAPTER 15

위 디플로이먼트 다이어그램을 통해 다음과 같은 사항을 알 수 있다. 전자결재 시스템


UML을 이용한 CBD 모델링(UML 2.0) 실습 사례 해설

1. 개요 2. 실습도메인 설명 3. Problem Statement 4. UseCase Modeling 5. Structural Modeling – 유스케이스 정적 분석 6. Behavioral Modeling – 유스케이스 동적 분석 7. Component Modeling – 컴포넌트 아키텍처 정의 8. Component Modeling – 컴포넌트 상호작용 정의 9. Component Modeling – 컴포넌트 정적 설계 10. Component Modeling – 컴포넌트 동적 설계


제15장 Deployment Modeling - Design

CHAPTER 15

1

개요

본 해답집은 UML을 이용한 CBD 모델링(UML 2.0) 과정의 실습 도메인인 전자상거 래 시스템에 대한 단계별 산출물을 정리한 것이다.

교육생은 우선 팀 별 실습을 통해 모델링을 수행하고 산출물을 작성한 후, 팀 별 산출 물과 비교해 볼 것을 권장한다.

각 팀 별 모델링의 결과가 반드시 본 해답집에 수록된 산출물과 같아야 하는 것은 아 니다. 왜냐하면 모델링이란 시스템을 특정관점에서 간략히 하는 것이기에 관점에 따라, 강조하고자 하는 내용에 따라 모델링의 결과는 다소 차이가 있을 수 있을 수 있기 때 문이다. 그러나 모델링의 결과는 시스템의 핵심을 담고 있어야 한다. 단순하지만 시스 템의 핵심을 담고 있고, 이해하기 쉽고 모호함이 없는 모델이 바람직한 모델이라고 할 수 있다.

381


UML을 이용한 객체지향 분석설계

2

실습 도메인 설명

iShop 사는 인터넷으로 자사의 상품을 판매하기로 결정했다. 그에 따라 인터넷기반의 전자상거래 시스템을 개발하기로 하고, 이 시스템을 통해 자사의 상품인 PC에 대한 영업과 판매를 자동화하기를 기대하고 있다. 개발될 시스템에 대한 기능을 요약하면 다음과 같다.

누구나 상품을 조회하고 검색할 수 있으나, 인증된 회원만이 구매 가능하다. 결제 수 단은 온라인 입금과 신용카드가 가능해야 하며, 온라인 입금은 관리자가 타 시스템을 통해 입금 여부를 확인한 후 결제 처리한다. 신용카드 결제는 곧바로 처리 가능해야 한다. 고가 상품은 판매 후의 사후 관리를 위해 시리얼 번호 등을 추가로 관리한다. 회원은 주문된 상품의 진행 상태를 조회할 수 있어야 한다.

382


제15장 Deployment Modeling - Design

CHAPTER 15

3

Problem Statement

1. 인터넷을 기반으로 회원이 PC 상품을 검색하고 구매할 수 있는 시스템을 개발 구 축한다. 2. 누구나 제품에 대한 조회 및 검색을 할 수 있어야 한다. 3. 인증 과정을 거친 회원만이 상품 구매를 할 수 있다. 4. 결제 수단은 온라인 입금과 신용카드 결제가 가능해야 한다. 5. 온라인 입금은 관리자가 다른 시스템을 통해 입금 여부를 확인한 후 결제 처리하 지만, 신용카드 결제는 즉시 처리가 가능하도록 한다. 6. 고가 상품은 사후 관리를 위해 시리얼 번호 정보를 추가 관리한다. 7. 상품 관리(등록, 조회, 수정, 삭제)를 할 수 있어야 한다. 8. 회원 관리(등록, 조회, 수정, 삭제)를 할 수 있어야 한다. 9. 회원은 주문에 대한 진행 상태를 확인할 수 있어야 한다.

383


UML을 이용한 객체지향 분석설계

4 4.1

UseCase Modeling

액터 정의

4.1.1 고객 •

Actor 명: 고객

설명: 인터넷으로 전자상거래 시스템에 접속하여 상품을 검색하고 조회한다.

4.1.2 회원 •

Actor 명: 회원

설명:

전자상거래 시스템에 회원으로 가입되어 있으며, 상품을 검색, 조회, 주

문할 수 있다.

4.1.3 관리자 •

Actor 명: 관리자

설명: 상품을 관리하고, 회원을 관리한다.

4.1.4 신용카드 인증회사 •

Actor 명: 신용카드 인증회사

설명: 신용카드를 인증하고 거래를 승인한다.

384


제15장 Deployment Modeling - Design

CHAPTER 15

4.2

유스케이스 정의

4.2.1 유스케이스 후보 선정 시스템을 개발 구축한다.

상품을 조회한다.

상품을 검색한다.

인증과정을 거친다.

상품을 주문한다.

상품을 구매한다.

쇼핑 카트에 담는다.

주문에 대해 결제한다.

고객에게 배달된다.

온라인 입금 한다.

입금여부를 확인한다.

신용카드로 결제한다.

결제방법에는 온라인결제가 허용된다.

결제 처리한다.

고가상품을 추가 관리한다.

신용카드 결제는 즉시 처리 가능하도록 한다.

상품을 관리한다.

회원을 관리한다.

주문상태를 확인한다.

4.2.2 제거 대상 유스케이스 후보 선정 제거 대상 유스케이스 후보

시스템을 개발 구축한다.

광범위

상품을 구매한다.

중복(상품을 주문한다)

쇼핑카트에 담는다.

중복(상품을 주문한다)

온라인 입금한다.

범위를 벗어남

고객에게 배달된다.

범위를 벗어남

결제방법에는 온라인결제가 허용된다.

중복(결제처리한다)

신용카드로 결제한다.

중복(결제처리한다)

신용카드결제는 즉시 처리가능 하도록 한다.

중복(결제처리한다)

385


UML을 이용한 객체지향 분석설계

4.2.3 정제된 유스케이스 정리 - UC 1. 상품 조회

- UC 2. 상품 검색

- UC 3. 회원 가입

- UC 4. 사용자 인증

- UC 5. 상품 주문

- UC 6. 주문 결제

- UC 7. 사후 관리

- UC 8. 상품 관리

- UC 9. 회원 관리

- UC 10. 주문 조회

- UC 11. 온라인입금 처리

4.3

요구사항 추적 표 작성

요구사항 ID

유스케이스

Req 1

전체

Req 2

UC1, UC2

Req 3

UC3, UC4, UC5

Req 4

UC6

Req 5

UC6, UC11

Req 6

UC7

Req 7

UC8

Req 8

UC9

Req 9

UC10

4.4

비 고

유스케이스 유형 정의

유스케이스 ID

유스케이스명

유형

UC 1

상품 조회

선 순위

UC 2

상품 검색

선 순위

386


제15장 Deployment Modeling - Design

회원 가입

선 순위

UC 4

사용자 인증

선 순위

UC 5

상품 주문

선 순위

UC 6

주문 결제

선 순위

UC 7

사후 관리

선 순위

UC 8

상품 관리

선 순위

UC 9

회원 관리

선 순위

UC 10

주문 조회

선 순위

UC 11

온라인입금 처리

선 순위

4.5

CHAPTER 15

UC 3

유스케이스 다이어그램 작성

ud Us e Ca s e Model iShop 전자상거래 시스템

온라인입금처리

회원가입

상품관리 상품조회 고객 사후관리 상품검색

사용자인증 관리자

상품주문

회원관리

회원

주문결제 주문조회

신용카드인증회사

387


UML을 이용한 객체지향 분석설계

유스케이스 정의서 작성

4.6

4.6.1 상품 조회 유스케이스 정의서 유스케이스명

상품 조회

유스케이스ID

UC 1

작성자

조인수

작성일

2006.2.8

1. 개 요 고객은 시스템을 통해 상품의 목록을 조회하고, 상세정보를 조회한다.

2. Relationships - Initiators: 고객 - Supporters: - Pre-Condition: - Post-Condition:

3. Flow of Events 번호 M01

Actor

System

상품 조회 기능을 요청한다. 상품의 카테고리 목록과 상품 목록을 출력

M02 한다. [조회할

상품

카테고리를

선택한

M03 다](A01) 상품 목록에서 조회할 상품을 선택한 M04 다. 상품의 상세 정보(모델명, 상품명, 분류, 가 M05 격, 재고수량, 색상, 이미지)를 출력한다. [서브 카테고리가 있는 경우]카테고리 목 A0101 록을 출력한다. (M02)

388


제15장 Deployment Modeling - Design

상품명, 분류, 가격)을 출력한다. (M02)

4. Special Requirements

5. Note

6. 시나리오

4.6.2 상품 검색 유스케이스 정의서 유스케이스명

상품 검색

유스케이스ID

UC 2

작성자

조인수

작성일

2006.2.8

1. 개 요 고객은 원하는 상품을 검색조건을 통해 검색한다.

2. Relationships - Initiators: 고객 - Supporters: - Pre-Condition: - Post-Condition:

3. Flow of Events 번호 M01

Actor

System

상품 검색 기능을 요청한다.

M02

상품의 검색 입력화면 출력한다. 검색조건(상품명)을

입력하고

검색을

M03 요청한다 M04

검색 결과(상품 목록)를 출력한다.

389

CHAPTER 15

선택된 상품 카테고리의 상품 목록(모델명, A0102


UML을 이용한 객체지향 분석설계

4. Special Requirements

5. Note

6. 시나리오

4.6.3 회원 가입 유스케이스 정의서 유스케이스명

회원 가입

유스케이스ID

UC 3

작성자

조인수

작성일

2006.2.8

1. 개 요 고객은 전자상거래를 하기 위해 회원 가입한다.

2. Relationships - Initiators: 고객 - Supporters: - Pre-Condition: - Post-Condition:

3. Flow of Events 번호 M01

Actor

System

회원가입 기능을 요청한다.

M02

회원가입 화면을 출력한다.

M03

회원 정보를 입력한다.

M04

회원 가입을 요청한다.

M05

[필수 사항 미입력](E01)

M06

[사용자 이미 존재](E02)

390


제15장 Deployment Modeling - Design

출력한다. 필수사항이 미입력 되었음을 알린다. E01 (M02) E02

사용자가 이미 존재함을 알린다. (M02)

4. Special Requirements

5. Note

6. 시나리오

4.6.4 사용자 인증 유스케이스 정의서 유스케이스명

사용자 인증

유스케이스ID

UC 4

작성자

조인수

작성일

2006.2.8

1. 개 요 회원과 관리자는 전자상거래 시스템을 이용하기 위해 사용자 인증을 한다.

2. Relationships - Initiators: 회원, 관리자 - Supporters: - Pre-Condition: - Post-Condition:

3. Flow of Events 번호 M01 M02

Actor

System

사용자 인증 기능을 요청한다. 인증 화면(ID, 패스워드)을 출력한다.

391

CHAPTER 15

회원 가입되었음을 알리고 메인 화면을 M07


UML을 이용한 객체지향 분석설계

M03

[ID와 패스워드를 입력한다.] (A01)

M04

사용자 인증을 요청한다. [인증 성공] 메인 화면을 출력한다. (E01,

M05 E02, E03) [관리자일 경우] 사번과 패스워드를 A01 입력한다. (M04) [패스워드 오류] 패스워드가 잘못되었음을 E01 알리고 인증 화면을 출력한다. (M02) [회원ID 오류] 회원ID가 존재하지 않음을 E02 알리고 인증 화면을 출력한다. (M02) [사번 오류] 사번이 존재하지 않음을 알리 E03 고 인증 화면을 출력한다. (M02)

4. Special Requirements

5. Note

6. 시나리오

4.6.5. 상품 주문 유스케이스 정의서 유스케이스명

상품 주문

유스케이스ID

UC 5

작성자

조인수

작성일

2006.2.8

1. 개 요 회원은 상품 목록이 출력된 상태나 상세 조회된 상태에서 상품을 주문한다. 상품 주문 시에 수량을 입력 한 후 장바구니에 상품을 담는다.

392


제15장 Deployment Modeling - Design

CHAPTER 15

2. Relationships - Initiators: 회원 - Supporters: - Pre-Condition: 상품의 상세정보가 조회된 상태여야 한다. 회원으로 로그인 되어 있어야 한다. - Post-Condition: 장바구니에 해당 상품에 대한 주문정보가 생성된다.

3. Flow of Events 번호 M01

Actor

System

상품 주문 기능을 요청한다. 장바구니 화면(상품상세 정보, 주문 수량, 가

M02 격)을 출력한다. M03

주문 수량을 입력한다. 주문 금액에 대한 계산을 요청한

M04 다. (A01, A02) 선택된 상품을 장바구니에 담고, 장바구니 내 M05 용(총액 포함)과 상품 목록을 출력한다. M06

주문 신청 기능을 요청한다. 장바구니 상품주문 정보 및 배송정보를 포함

M07 한 상품주문 화면을 출력한다. 배송정보(배송지 주소, 연락처, 수 M08 령인)를 입력한다. M09

주문을 요청한다. 주문정보를 저장하고 주문이 처리되었음을 알

M10 린다. [수량을 수정하고 수정을 요청한 A0101 다] 수량이 수정된 장바구니 목록 및 변경된 총액 A0102 을 출력한다. (M06)

393


UML을 이용한 객체지향 분석설계

[삭제할 상품을 선택하고 삭제를 A0201 요청한다] 삭제 요청된 상품이 제거된 장바구니 목록 및 A0202 변경된 총액을 출력한다. (M06)

4. Special Requirements

5. Note

6. 시나리오

4.6.6 주문 결제 유스케이스 정의서 유스케이스명

주문 결제

유스케이스ID

UC 6

작성자

조인수

작성일

2006.2.8

1. 개 요 회원은 결제 기능을 요청하여 장바구니 목록을 확인한다. 그리고, 신용카드로 결제하거나 온 라인 입금으로 결제한다.

2. Relationships - Initiators: 회원 - Supporters: 신용카드인증회사 - Pre-Condition: 장바구니에 주문된 상품이 있어야 한다. 회원으로 로그인 되어 있어야 한다. - Post-Condition: 주문의 상태가 주문완료로 바뀐다. 해당 주문에 대한 결제정보가 생성된다.

3. Flow of Events 번호

394

Actor

System


제15장 Deployment Modeling - Design

결제기능을 요청한다. 장바구니에 담긴 상품의 목록(제품명, 메이커, 수량, 전체금액), 배송지 정보(수령인 성명, 주

M02 소, 전화번호), 결제방식 목록(신용카드 결제, 온라인 결제)을 출력한다. M03

[온라인 결제를 선택한다] (A01)

M04

신용카드 결제를 선택한다. 신용카드 결제정보 입력 화면(카드 종류, 카드

M05 번호, 유효 기간, 비밀 번호)을 출력한다. M06

결제 카드 정보를 입력한다.

M07

결제를 요청한다.

M08

신용카드 인증시스템에 승인을 요청한다. {신용카드인증회사액터}

M09

신용카드에 대한 결제를 승인한다. (E01, E02, E03)

M10 A0101

결제가 승인되었음을 알린다. 온라인입금을 선택한다. 입금가능 은행과 계좌 목록 및 입금정보 입력

A0102 화면과 결제 확인 요청을 출력한다. A0103

결제 확인을 선택한다.

A0104

주문이 결제되었음을 출력한다. <<신용카드인증회사액터>>

E0101 카드번호 오류를 알린다. [카드번호 오류] 카드 번호가 잘못되었음을 알 E0102

리고

신용카드

정보입력

화면을

출력한다.

(M05) <<신용카드인증회사액터>> E0201 카드 유효기간 오류를 알린다.

395

CHAPTER 15

M01


UML을 이용한 객체지향 분석설계

[카드 유효기간 오류] 카드 유효기간이 잘못 E0202

입력되었음을 알리고 신용카드 정보입력 화면 을 출력한다. (M05) <<신용카드인증회사액터>>

E0301 카드사용한도 오류를 알린다. [카드사용한도 오류] 카드 사용 한도에 오류가 E0302

있음을 알리고 신용카드 정보입력 화면을 출력 한다. (M05)

4. Special Requirements

5. Note

6. 시나리오

4.6.7 사후 관리 유스케이스 정의서 유스케이스명

사후 관리

유스케이스ID

UC 7

작성자

조인수

작성일

2006.2.8

1. 개 요 관리자는 고가 상품에 대해 사후 관리 기능을 요청하고, 사후 관리해야 할 주문을 선택하여 주문의 상세정보를 확인한 후 시리얼번호를 입력한다.

2. Relationships - Initiators: 관리자 - Supporters: - Pre-Condition: 관리자로 로그인 되어 있어야 한다. - Post-Condition: 해당 고가 상품의 주문항목에 대한 시리얼번호가 생성된다.

396


제15장 Deployment Modeling - Design

CHAPTER 15

3. Flow of Events 번호 M01

Actor

System

사후 관리 기능을 요청한다. 사후 관리해야 할 주문 목록을 출력한

M02 다. M03

사후 관리할 주문을 선택한다.

M04

주문의 상세 정보를 출력한다.

M05

시리얼 번호를 입력한다.

M06

사후 관리를 요청한다.

M07

사후 관리되었음을 알린다.

4. Special Requirements

5. Note

6. 시나리오

4.6.8 상품 관리 유스케이스 정의서 유스케이스명

상품 관리

유스케이스ID

UC 8

작성자

조인수

작성일

2006.2.8

1. 개 요 관리자는 상품을 등록하고 상품 정보를 수정하고 삭제한다. 삭제 기능은 Main Flow이며 등 록 및 상품정보 수정은 Alternative Flow이다.

2. Relationships - Initiators: 관리자 - Supporters:

397


UML을 이용한 객체지향 분석설계

- Pre-Condition: 관리자로 로그인 되어 있어야 한다. - Post-Condition: 상품이 새로 등록되거나 삭제된다. 아니면 상품정보가 수정된다.

3. Flow of Events 번호 M01

Actor

System

상품관리 기능을 요청한다.

M02

상품의 카테고리와 상품 목록을 출력한다.

M03

[카테고리를 선택한다](A01)

M04

[상품을 선택한다](A02)

M05

[상품등록 기능을 요청한다](A03)

M06

삭제할 상품을 선택한다.

M07

삭제를 요청한다. 선택된 상품이 삭제된 상품 목록을 출력한

M08 다. [하위 카테고리가 있는 경우]카테고리목록 A0102 과 상품을 출력한다. [하위 카테고리가 없는 경우]상품 목록을 A0102 출력한다. A0201

선택된 상품의 상세 정보를 출력한다.

A0202

상품의 정보를 수정한다.

A0203

상품 정보 저장을 요청한다. 상품의 정보를 저장하고 상품 목록을 출력

A0204 한다. (M03) A0301

상품정보 등록 화면을 출력한다.

A0302

상품 정보를 입력한다.

A0303

상품 정보 등록을 요청한다. 상품 정보를 등록하고, 상품 목록을 출력한

A0304 다. (M03)

4. Special Requirements

398


제15장 Deployment Modeling - Design

CHAPTER 15

5. Note

6. 시나리오

4.6.9 회원 관리 유스케이스 정의서 유스케이스명

회원 관리

유스케이스ID

UC 9

작성자

조인수

작성일

2006.2.8

1. 개 요 관리자는 회원의 정보를 수정하고 삭제한다.

2. Relationships - Initiators: 관리자 - Supporters: - Pre-Condition: 관리자로 로그인 되어 있어야 한다. - Post-Condition: 회원 정보가 삭제되거나 수정된다.

3. Flow of Events 번호 M01

Actor

System

회원관리 기능을 요청한다.

M02

회원의 목록을 출력한다. [검색할 회원의 ID나 이름을 입력하고 검색을

M03 요청한다.](A01) M04

[목록에서 수정할 회원을 선택한다](A02)

M05

삭제할 회원을 선택하고 삭제를 요청한다. 선택된 회원을 삭제하고 회원의 목

M06 록을 출력한다.

399


UML을 이용한 객체지향 분석설계

검색된 회원의 목록(이름, ID, 주 A01 소)을 출력한다. (M02) 선택된 회원의 상세정보를 출력한 A0201 다. A0202

회원의 정보를 수정하고, 반영을 요청한다. 회원의 정보를 저장하고 회원 목록

A0203 을 출력한다.

4. Special Requirements

5. Note

6. 시나리오

4.6.10 주문 조회 유스케이스 정의서 유스케이스명

주문 조회

유스케이스ID

UC 10

작성자

조인수

작성일

2006.2.8

1. 개 요 회원이 자신의 주문에 대한 주문 내역 및 상태(재고 확보, 배송 완료)를 조회한다.

2. Relationships - Initiators: 회원 - Supporters: - Pre-Condition: 주문한 내역이 존재해야 한다. 회원으로 로그인 되어 있어야 한다. - Post-Condition:

3. Flow of Events

400


제15장 Deployment Modeling - Design

M01

Actor

System

주문조회기능을 요청한다. [주문이 없는 경우]주문이 없음을

M02 알린다. [주문이 있는 경우]주문 목록을 출 M03 력한다. M04

주문을 선택한다.

M05

주문의 상세 정보를 출력한다.

4. Special Requirements

5. Note

6. 시나리오

4.6.11 온라인 입금 처리 유스케이스 정의서 유스케이스명

온라인 입금 처리

유스케이스ID

UC 11

작성자

조인수

작성일

2006.2.8

1. 개 요 관리자가 다른 시스템으로 온라인 결제 주문에 대한 입금 여부를 확인하고, 해당 주문을 결 제 처리한다.

2. Relationships - Initiators: 관리자 - Supporters: - Pre-Condition: 입금되었음을 확인한다. 관리자로 로그인 되어 있어야 한다.

401

CHAPTER 15

번호


UML을 이용한 객체지향 분석설계

- Post-Condition: 해당 주문에 대한 결제 처리 정보를 반영된다.

3. Flow of Events 번호 M01

Actor

System

온라인 입금 결제처리 기능을 요청한다. 온라인 결제된 미 처리 주문 목록을 출

M02 력한다. M03

결제 처리할 주문을 선택한다.

M04 M05

선택된 주문의 상세 정보를 출력한다. “결제되었음”으로 체크하고 반영을 요청한 다. 결제처리하고 미결제 입금 목록을 출력

M06 한다. M07

{M03 - M06반복}

4. Special Requirements

5. Note

6. 시나리오

402


제15장 Deployment Modeling - Design

5.1

Structural Modeling - 유스케이스 정적

객체 찾기

요구사항 목록과 유스케이스 정의서에서 명사를 추출하여 나열한다.

인터넷

회원

상품

검색

구매

인증

배달

쇼핑 카트

결제

시리얼번호

등록

수정

삭제

배송여부

결제목록

결제금액

결제방식

신용카드

온라인입금

은행

계좌목록

입금자

결제카드

카드종류

카드번호

비밀번호

유효일자

승인

ID

패스워드

카테고리

상품명

가격

제품정보

고객ID

상품코드

이미지

재고수량

403

CHAPTER 15

5


UML을 이용한 객체지향 분석설계

약관

이름

주민번호

주소

전화번호

이 메일 주소

필수사항

배송유무

주문일

주문번호

고객

관리자

5.2

제거 대상 객체 선정

제거 대상 객체 후보

인터넷

범위를 벗어남

검색

오퍼레이션임

구매

오퍼레이션임

인증

오퍼레이션임

배달

애매모호함

결제

오퍼레이션임

시리얼번호

속성임

수정

오퍼레이션임

삭제

오퍼레이션임

배송여부

속성임

결제목록

파생됨

결제금액

속성임

결제방식

속성임

신용카드

속성임

온라인입금

오퍼레이션임

은행

속성임

계좌목록

파생됨

입금자

속성임

결제카드

중복됨(신용카드)

404


제15장 Deployment Modeling - Design

속성임

카드번호

속성임

비밀번호

속성임

유효일자

속성임

승인

오퍼레이션임

ID

속성임

패스워드

속성임

카테고리

속성임

상품명

속성임

가격

속성임

제품정보

중복됨(상품정보)

고객ID

속성임

재고수량

속성임

약관

화면임

주소

속성임

주민번호

속성임

이 메일 주소

속성임

전화번호

속성임

배송유무

속성임

필수사항

애매모호함

주문일

속성임

주문번호

속성임

5.3

CHAPTER 15

카드종류

정제된 객체

- 회원

- 관리자

- 주문정보

- 결제정보

- 상품정보

405


UML을 이용한 객체지향 분석설계

5.4

Association 찾기

고객은 상품을 조회한다.

고객은 상품을 검색한다.

회원은 상품을 주문한다.

회원은 상품을 조회한다.

회원은 상품을 검색한다.

회원은 회원정보를 수정한다.

회원은 주문을 조회한다.

회원은 주문을 결제한다.

회원은 회원정보를 입력한다.

회원은 회원정보를 등록한다.

회원은 상품을 쇼핑카트에 담는다.

회원은 주문을 온라인결제 한다.

회원은 주문을 신용카드 결제한다. 관리자는 회원을 관리한다.

관리자는 상품을 조회한다.

관리자는 상품을 검색한다.

관리자는 상품을 관리한다.

관리자는 주문을 조회한다.

관리자는 온라인결제를 확인한다.

관리자는 고가상품을 사후관리 한다.

5.5

Association 정제

제거 대상 Association 후보

- 고객은 상품을 조회한다.

제거된 클래스와의 Association

- 고객은 상품을 검색한다.

제거된 클래스와의 Association

- 회원은 상품을 쇼핑카트에 담는다.

중복됨(회원은 상품을 주문한다)

- 회원은 주문을 온라인 결제한다.

중복됨(회원은 주문을 결제한다)

- 회원은 주문을 신용카드 결제한다.

중복됨(회원은 주문을 결제한다)

- 회원은 회원정보를 입력한다.

오퍼레이션임

406


제15장 Deployment Modeling - Design

CHAPTER 15

5.6

정제된 Association

Association

Association

회원은 상품을 조회한다.

회원은 상품을 검색한다.

회원은 상품을 주문한다.

회원은 주문을 결제한다.

회원은 주문을 조회한다. 관리자는 회원을 관리한다.

관리자는 상품을 관리한다.

관리자는 주문을 조회한다.

관리자는 온라인결제를 확인한다.

관리자는 고가상품을 사후 관리한다.

5.7

Class Diagram작성

cd Logical Model 장바구니

사용자 소유한다 0..*

관리자

회원

상품

카테고리

주문한다 1..*

0..*

1..*

관리한다

결제

결제된다

주문

주문항목 1..*

407


UML을 이용한 객체지향 분석설계

5.8

Attribute와 Operation부여

클래스에서 제거된 후보 중에서 속성과 오퍼레이션을 클래스에 할당한다.

408


제15장 Deployment Modeling - Design

6.1

Behavioral Modeling - 유스케이스 동적 분

Communication Diagram

6.1.1 상품 조회 cd 상품조회 1: *[현재카테고리=말단카테고리]:조회할 상품 카테고리를 선택한다 2: 상품 목록에서 조회할 상품을 선택한다 상품목록조회화면 1.2: [서브 카테고리가 있는 경우]:카테고리 목록을 출력한다. 1.3: 선택된 상품 카테고리의 상품 목록을 출력한다. 1.4: 카테고리조회() 2.2: 상품상세조회()

1.1: 목록조회()

:상품

2.3: 조회()

고객

:상품조회컨트롤 2.4: 상품의 상세 정보를 출력한다 2.1: 하위카테고리조회()

:카테고리

상품상세조회화면

409

CHAPTER 15

6


UML을 이용한 객체지향 분석설계

6.1.2 상품 검색 cd 상품검색 1: 검색조건(상품명)을 입력하고 검색을 요청한다 2: 상품 목록에서 조회할 상품을 선택한다 1.3: 검색 결과(상품 목록)를 출력한다 1.1: 상품검색() 상품검색조회화면

2.1: 상품조회() 1.2: 목록조회()

2.3: 상품의 상세 정보를 출력한다 :상품검색컨트롤

고객

:상품

2.2: 조회()

상품상세조회화면

6.1.3 사용자 인증 cd 사용자인증 1: ID와 패스워드 입력 1.1: 사용자 인증

회원 1.2: 사용자인증()

1.3: 인증()

2.2: 사용자인증()

2.3: 인증()

사용자인증화면

2: 사번 입력 관리자

410

2.1: 사용자 인증

:사용자인증컨트롤

:사용자


제15장 Deployment Modeling - Design

CHAPTER 15

6.1.4 상품 주문 cd 상품주문 1: 주문 수량을 입력한다 1.1: 산주문 금액에 대한 계를 요청한다 2: 수량을 수정하고 수정을 요청한다 3: 삭제할 상품을 선택하고 삭제를 요청한다 장바구니화면 4: 주문 신청 기능을 요청한다 회원

1.2: 상품수량입력()

5: 배송정보(배송지 주소, 연락처, 수령인)를 입력한다 5.1: 주문을 요청한다

2.4: 장바구니 내용과 상품 목록을 출력한다

2.1: 상품수량수정() 3.1: 상품삭제() 4.3: 주문화면요청

주문화면

1.5: 장바구니 내용과 상품 목록을 출력한다

3.4: 장바구니 내용과 상품 목록을 출력한다 1.3: 추가() 1.4: 목록조회()

:장바구니

2.2: 수정() 4.1: 주문 화면을 출력한다 :상품주문컨트롤 2.3: 목록조회() 4.5: 상품주문() 3.2: 삭제() 3.3: 목록조회() 4.2: 목록조회() 4.4: 신청()

:주문

411


UML을 이용한 객체지향 분석설계

6.1.5 주문 결제 cd 주문결제 1: [신용카드]:신용카드 결제를 선택한다 1.3: 결제 카드 정보를 입력한다 1.4: 결제를 요청한다 2: [계좌입금]:온라인 결제를 선택한다 2.2: 결제 확인을 선택한다 결제화면 1.2: 신용카드 결제정보 입력 화면을 출력한다 1.9: [카드번호 오류]:카드 번호가 잘못되었음을 알린다 1.1: 신용카드결제선택() 1.5: 신용카드결제선택()

회원

2.3: 주문결제()

1.11: [카드사용한도 오류]:카드 사용 한도에 오류가 있음을 알린다 1.10: [카드 유효기간 오류]:카드 유효기간이 잘못 입력되었음을 알린다 2.1: 입금가능 은행과 계좌목록 및 입금정보 입력 화면을 출력한다

1.6: 결제()

:주문

1.7: 상신

2.4: 결제() :주문결제컨트롤

신용카드인증회사 2.5: 등록()

1.8: [카드 승인의 정상적 처리]:등록() :결제

412


제15장 Deployment Modeling - Design

CHAPTER 15

6.1.6 사후 관리 cd 사후관리 1: 사후 관리할 주문 목록을 요청한다 1.4: 사후 관리할 주문을 선택한다

1.1: 주문목록조회() 1.3: 사후 관리해야 할 주문 목록을 출력한다

사후관리목록화면

1.5: 주문조회() 1.2: 목록조회()

2: 시리얼 번호를 입력한다

1.6: 조회()

:주문

2.1: 사후 관리를 요청한다 :사후관리컨트롤 관리자

1.7: 목록조회() 2.3: 사후관리요청() :주문항목 2.2: 사후관리요청() 사후관리화면

1.8: 주문의 상세 정보를 출력한다

413


UML을 이용한 객체지향 분석설계

6.1.7 상품 관리 cd 상품관리 1: *[현재카테고리=말단카테고리]:카테고리를 선택한다 2: 상품을 선택한다 3: 상품등록 기능을 요청한다 4: 삭제할 상품을 선택한다 4.1: 삭제를 요청한다

1.1: 카테고리조회() 상품목록조회화면 2.1: 상품조회() 3.1: 상품등록화면요청 4.2: 상품삭제()

1.3: 목록조회() 2.2: 조회() 2.7: 수정()

3.3: 상품 정보를 입력한다

2.8: 목록조회()

3.4: 상품 정보 등록을 요청한다

:상품

3.6: 등록() :상품관리컨트롤 4.3: 삭제()

관리자

4.4: 목록조회() 3.2: 상품등록 화면을 출려한다

:카테고리

3.5: 상품등록() 상품등록화면

1.2: 하위카테고리조회()

2.4: 상품의 정보를 수정한다 2.5: 상품 정보 저장을 요청한다 2.6: 상품저장() 2.3: 상품의 정보를 출력한다 상품수정화면

414


제15장 Deployment Modeling - Design

CHAPTER 15

6.1.8 회원 관리 cd 회원관리 1: 검색할 회원의 ID나 이름을 입력하고 검색을 요청한다 2: 목록에서 수정할 회원을 선택한다 3: 삭제할 회원을 선택하고 삭제를 요청한다 회원목록화면 1.1: 회원검색()

1.3: 검색된 회원의 목록을 출력한다

2.1: 회원조회() 1.2: 검색() 2.2: 조회()

3.1: 회원삭제()

:회원

2.6: 수정() :회원관리컨트롤3.2: 탈퇴()

관리자

2.3: 선택된 회원의 상세정보를 출력한다

2.5: 회원수정()

2.4: 회원의 정보를 수정하고, 반영을 요청한다 회원조회화면

6.1.9 주문 조회 cd 주문조회 1: 주문목록��� 요청한다 2: 목록에서 조회할 주문을 선택한다 1.1: 주문목록조회() 주문목록조회화면 2.1: 주문조회()

1.2: 목록조회()

:주문

2.2: 조회() :주문조회컨트롤

회원

2.3: 주문 상세 정보를 출력한다

주문상세조회화면

415


UML을 이용한 객체지향 분석설계

6.1.10 온라인 입금 처리 cd 온라인입금처리 1: 입금처리할 목록을 요청한다

1.1: 입금처리목록조회()

2: 결제 처리할 주문을 선택한다

2.1: 주문조회()

:결제

입금처리목록화면 2.7: 승인()

1.2: 목록조회() 2.2: 조회() 2.6: 수정()

:주문

:온라인입금처리컨 트롤

관리자

입금처리상세조회 화면 2.4: “결제되었음”으로 체크하고 반영을 요청한다

2.3: 선택된 주문의 상세 정보를 출력한다 2.5: 입금처리()

6.1.11 회원 가입 cd 회원가입 1: 회원 정보를 입력한다 1.1: 회원 가입을 요청한다

회원가입화면 1.3: [필수 사항 미입력]:필수사항이 미입력 되었음을 알린다 1.2: 회원가입() 1.5: [사용자 이미 존재]:사용자가 이미 존재함을 알린다 1.7: 회원 가입되었음을 알린다 1.4: 조회() 1.6: 가입()

고객 :회원가입컨트롤

416

:회원


제15장 Deployment Modeling - Design

7.1

Component Modeling – 컴포넌트 아키텍처 정

Component Diagram

id Component Model Application Layer

쇼핑

쇼핑몰운영

«Application» 쇼핑

상품관리

회원가입인증

상품조회

«Application» 쇼핑몰운영

상품주문

관리자인증

주문관리

회원관리

Business Layer

상품주문

«Business» 주문

상품확인 상품관리

«Business» 상품

주문관리 회원확인

주문결제

결제

사용자인증관리

회원관리

«Business» 사용자

417

CHAPTER 15

7


UML을 이용한 객체지향 분석설계

8 8.1

Component Modeling – 컴포넌트 상호작용 정

Sequence Diagram

8.1.1 상품 조회 s d 상품조회 Client

«Application» :I쇼핑

«Business» :I상품관리

loop [현재카테고리<>말단카테고리] 카테고리조회() 카테고리조회() 상품목록조회() [현재카테고리=말단카테고리] 카테고리조회() 상품목록조회()

상품조회() 상품조회()

418


제15장 Deployment Modeling - Design

CHAPTER 15

8.1.2 상품 검색 s d 상품검색 Clie nt

«Application» :I쇼핑

«Business» :I상품관리

상품검색() 상품검색() 상품조회() 상품조회()

8.1.3 사용자 인증 s d 사용자인증 Clie nt

«Application» :I쇼핑

«Application» :I쇼핑몰운영

«Business» :I사용자인증관 리

a lt [회원일 경우] 회원인증() 인증()

[관리자일 경우] 관리자인증() 인증()

419


UML을 이용한 객체지향 분석설계

8.1.4 상품 주문 s d 상품주문 Client

«Application» :I쇼핑

«Business» :I상품주문

«Business» :I회원관리

alt [장바구니추가] 장바구니추가() 장바구니생성() 장바구니계산()

[장바구니수정] 장바구니수정() 장바구니수정() 장바구니계산()

[장바구니삭제] 장바구니삭제() 장바구니삭제() 장바구니계산()

주문신청() 주문신청() 회원확인() 상품잔고확인() 주문저장()

420

«Business» :I상품관리


제15장 Deployment Modeling - Design

CHAPTER 15

8.1.5 주문 결제 s d 주문결제 Client

«Application» :I쇼핑

«Business» :I상품주문

«Business» :I회원관리 신용카드인증회사

alt [신용카드] 신용카드결제() 주문결제() 회원확인() 승인 결제저장()

[계좌입금] 계좌입금결제() 결제저장()

421


UML을 이용한 객체지향 분석설계

8.1.6 사후 관리 s d 사후관리 Client

«Application» :I쇼핑몰운영

«Business» :I주문관리

고가상품주문목록조회() 주문목록조회() 주문조회() 주문조회() 사후관리요청() 시리얼번호등록()

422


제15장 Deployment Modeling - Design

CHAPTER 15

8.1.7 상품 관리

423


UML을 이용한 객체지향 분석설계

8.1.8 회원 관리 s d 회원관리 Client

«Application» :I쇼핑몰운영

«Business» :I회원관리

회원검색() 회원검색()

회원조회() 회원조회()

alt [회원수정] 회원수정() 회원수정()

[회원삭제] 회원삭제() 회원삭제()

424


제15장 Deployment Modeling - Design

CHAPTER 15

8.1.9 주문 조회

s d 주문조회 Client

«Application» :I쇼핑

«Business» :I상품주문

주문목록조회() 주문목록조회()

주문조회() 주문조회()

425


UML을 이용한 객체지향 분석설계

8.1.10 온라인 입금 처리 s d 온라인입금처리 Clie nt

«Application» :I쇼핑몰운영

«Business» :I주문관리

입금처리목록조회() 주문목록조회() 주문조회() 주문조회()

입금처리() 결제정보변경()

8.1.11 회원 가입 s d 회원가입 Client

«Application» :I쇼핑

«Business» :I사용자인증관 리

회원가입() 회원중복확인() 회원등록()

426


제15장 Deployment Modeling - Design

9.1

Component Modeling – 컴포넌트 정적 설

Class Diagram (White-Box View)

9.1.1 쇼핑 컴포넌트 id 쇼핑Component «Application» 쇼핑 ≪realize≫

ShoppingRemoteFacade

IShopping

+ + + + + + + + + + + + +

≪realize≫

상품검색() : void 회원가입() : void 신용카드결제() : void 카테고리조회() : void 주문신청() : void 회원인증() : void 상품조회() : void 계좌입금결제() : void 장바구니추가() : void 장바구니수정() : void 장바구니삭제() : void 주문목록조회() : void 주문조회() : void

RequiredBiz

IProductMgt IProductOrder IUserAuthentication

«derive»

«derive» «derive» «derive» «derive» «derive»

회원가입컨트롤

상품조회컨트롤 주문조회컨트롤

상품주문컨트롤

ShoppingCar tDTO

Us er DTO

상품검색컨트롤

주문결제컨트롤

Or der DTO

Categor yDTO

Pa ymentDTO

Pr oductDTO

427

CHAPTER 15

9


UML을 이용한 객체지향 분석설계

9.1.2 쇼핑몰운영 컴포넌트 id 쇼핑몰운영Component «Application» 쇼핑몰운영 ≪realize≫ ShoppingMallAdminRemoteFacade

IShoppingMallMgt

+ ≪realize≫ + + + + + + + + + + + + + + +

고가상품주문목록조회() : void 회원검색() : void 입금처리목록조회() : void 회원조회() : void 관리자인증() : void 회원수정() : void 카테고리조회() : void 회원삭제() : void 상품조회() : void 고가상품주문목록조회() : void 사후관리요청() : void 상품수정() : void 상품등록() : void 상품삭제() : void 주문조회() : void 입금처리() : void

«derive» «derive»

사후관리컨트롤

«derive»

IProductMgt ICustomerMgt IOrderMgt IUserAuthentication

«derive»

온라인입금처리컨트롤 상품관리컨트롤

428

RequiredBiz

Or der DTO

Or der ItemDTO

Us erDTO

Pr oductDTO

회원관리컨트롤

PaymentDTO

CategoryDTO


제15장 Deployment Modeling - Design

CHAPTER 15

9.1.3 사용자 컴포넌트

429


UML을 이용한 객체지향 분석설계

9.1.4 상품 컴포넌트 id 상품Component «Business» 상품

≪realize≫

IProductMgt

Pr oductDAO

ç Pr oductFacade ≪realize≫ + + + + + + + +

+ + + + + + + + + +

상품검색() : void 상품잔고확인() : void 카테고리조회() : void 상품목록조회() : void 상품조회() : void 상품수정() : void 상품등록() : void 상품삭제() : void

selectProduct() : void selectProductList() : void updateProduct() : void insertProduct() : void deleteProduct() : void selectCategory() : void selectCategoryList() : void updateCategory() : void insertCategory() : void deleteCategory() : void

Pr oduct

430

-

상품명: int 모델명: int 제조사: int 상품설명: int 가격: int 등록일: int

+ + + + +

등록() : void 목록조회() : void 조회() : void 수정() : void 삭제() : void

Categor y 0..*

-

카테고리명: int

+

하위카테고리조회() : void

JDBC


제15장 Deployment Modeling - Design

CHAPTER 15

9.1.5 주문 컴포넌트 id 주문Component «Business» 주문 ≪realize≫

Or der Facade ç

IProductOrder

≪realize≫

≪realize≫

≪realize≫

IOrderMgt

+ + + + + + + + + + + +

Or der DAO

장바구니생성() : void 주문결제() : void 결제저장() : void 시리얼번호등록() : void 결제정보변경() : void 장바구니수정() : void 장바구니계산() : void 장바구니삭제() : void 주문신청() : void 주문저장() : void 주문목록조회() : void 주문조회() : void

+ + + + +

selectOrder() : void selectOrderList() : void updateOrder() : void insertOrder() : void deleteOrder() : void

-

금액: int 수량: int 시리얼번호: int

+ +

사후관리요청() : void 목록조회() : void

JDBC

Or der Item Or der -

주문일자: int 총액: int 수령인이름: int 주문상태: int 배송지주소: int 배송지연락처: int

+ + + + + +

신청() : void 조회() : void 수정() : void 취소() : void 결제() : void 목록조회() : void

1..*

ShoppingCar t

«delegate»

-

수량: int

+ + + + +

추가() : void 조회() : void 수정() : void 삭제() : void 목록조회() : void

IOrderPayment

결제

≪realize≫

PaymentDAO

ç Pa ymentFacade + + +

savePayment() : void payOrder() : void updatePaymentInfo() : void

+ + + + +

selectPayment() : void selectPaymentList() : void insertPayment() : void updatePayment() : void deletePayment() : void

JDBC

Payment -

결제방식: int 신용카드번호: int 입금확인여부: int 승인번호: int

+ +

등록() : void 승인() : void

431


UML을 이용한 객체지향 분석설계

10

Component Modeling – 컴포넌트 동적 설

모든 컴포넌트 인터페이스의 오퍼레이션 중 중요한 몇 가지에 대해서만 동적 설계를 수행한 것이다.

10.1

Sequence Diagram

10.1.1 사용자 컴포넌트의 인증 s d 인증 «interface» ICus tomer Mgt

Us er Facade ç

Us er DAO

Pr epar edStatement

boolean:= authenticate(id,password) User:= selectUser(id) ₩execute(select)₩ result ₩create₩ String:= getPassword() password2 [password=password2]: true [password<>password2]: false

432

Us er


제15장 Deployment Modeling - Design

CHAPTER 15

10.1.2 사용자 컴포넌트의 회원등록 s d 회원등록 «interface» IUs erAuthentication

ç Us erFacade

Us erDAO

Us er

PreparedStatement

registerUser(user) insertUser(user) *₩getter₩

₩execute(insert)₩

10.1.3 상품 컴포넌트의 상품검색 s d 상품검색 «interface» IProductMgt

ç ProductFacade

ProductDAO

PreparedStatement

List:= searchProducts(name) List:= selectProductList(name) ₩execute(select)₩ results Lis t

₩create₩

loop [results.size] ₩create₩

Product

*₩settet₩ add(product)

433


UML을 이용한 객체지향 분석설계

10.1.4 상품 컴포넌트의 주문신청 s d 주문신청 «interface» IProductOrder

ç OrderFacade

OrderDAO

Order

PreparedStatement

submitOrder(order) insertOrder(order) *₩getter₩ ₩execute(insert)₩

10.1.5 상품 컴포넌트의 주문결제 s d 주문결제 «interface» IProductOrder

ç OrderFacade

OrderDAO

PaymentFacade

PaymentDAO

PreparedStatement

payOrder(payment) updateOrder(status) ₩execute(update)₩ payOrder(payment) insertPayment(payment) ₩execute(insert)₩

434


제15장 Deployment Modeling - Design

CHAPTER 15

10.1.6 상품 컴포넌트의 장바구니생성 s d 장바구니생성 «interface» IPr oductOr der

ç Or der Facade

Ses s ion

createShoppingCart(cart) ₩add(cart)₩

435


test