부록 a - UML a1

부록 a

UML with StarUML

a2 부록 a - UML

a.1 UML (Unified Modeling Language)계획(planning)-분석(analysis)-설계(design)-구현(implement)-테스트(test)-유지보수

(maintenance)로 시스템 개발절차가 수행되는 시스템개발생명주기(SDLC, System Development Life Cycle)는 어떠한 시스템을 제작하더라도 일반적으로 적용될 수 있는

절차이다.

건축물을 구축하는 절차도 SDLC를 적용한다. 건축계획을 세우고 설계를 한 다음 실제

공사를 진행하는 구현절차가 진행된다. 건축물을 계획하고 분석하며 설계하는 과정에서 설

계도라는 산출물을 만들어 낸다. 건축물의 설계도란 외관을 나타내는 설계도, 평면도, 토목

설계도, 설비설계도, 전기설계도 등의 다양한 설계도면으로 구현하고자 하는 건축물의 형

태를 정의한다.

소프트웨어시스템의 설계도 이와 같다.

객체지향 방법론으로 구현하고자 하는 현실세계의 시스템을 분석하고, 이를 설계도로

나타내는데 일반적으로 통합모델링언어(UML, Unified Modeling Language)를 사용하

여 소프트웨어시스템에 대한 다양한 관점의 설계도를 산출한다.

UML (unified modeling language)UML(unified modeling language)이란 객체지향방법론을 적용하여 개발하는 정보시스템에

대한 SDLC를 적용해나가며 그 결과를 모델 또는 설계도로 나타내기 위한 모델링언어를

말한다.

1980년대 중반부터 활발히 연구되었던 객체지향 방법론은 그래디 부치(Grady Booch), 제임스 럼바(James Rumbaugh), 이바 야콥슨(Ivar Jacobson) 등의 선구자에 의해

OOD/Booch, OMT, OOAD, RDD, GOOD, HOOD, OOSD, OOJD 등과 같은 다양한 방법

론과 표기법이 50여개 이상 존재하였다.

이중에서 Booch의 방법론과 Jacobson의 Objectory 및 Rumbaugh의 OMT가 가장 주목

을 받았으며, 이들의 방법론을 통합하여 현존하는 객체지향 분석 및 설계 방법론을 완성하

고, 이를 Rational Unified Process(RUP) 또는 Unified Software Development Process(USDP)라고 호칭하였다. RUP 등은 1997년에 Object Management Group(OMG, www.omg.org)에 의해 통합되어 UML로 명명되고 version 1.0이 발표되

었고, version 2.0까지 발표되었다.

UML은 객체지향 개념이나 철학 또는 절차를 명시하는 객체지향 방법론이 아닌 단지

객체지향 방법론의 결과로 산출되는 정보시스템을 모델링하는 도구 또는 언어이다. 따라서

인간세상의 언어가 그러하듯 표준화가 상당히 중요한 과제이기에 OMG에 의해 범세계적

인 표준을 유지하고 있다. 또한 백문이 불여일견(百聞이 不如一見)이기에 UML의 표기법

은 그래픽(graphic) 중심으로 나타낸다.

UML은 OMG에 의해 지금도 진화가 되고 있다. 즉, 건축기술이 발달함에 따라 설계도

부록 a - UML a3

<그림 a1-1> StarUML 로고

<그림 a1-2> 모델 탐색기

에 나타내는 표현법이 계속 추가되듯이 소프트웨어시스템의 설계도를 나타내는 UML도 발

전적 진화를 계속하며 변화되고 있다. 현재 OMG에서 발행한 UML 매뉴얼은 거의 600여

페이지가 넘는다. 직업적인 전문가가 되기 이전에 이를 모두 다 습득한다고 하는 것은 어

려운 일이다. 이는 마치 한국어나 영어가 수십만 단어로 구성되어 있지만, 현실세계의 우리

는 수백 또는 수천의 단어로도 훌륭히 의사소통이 가능한 것과 마찬가지이다.

이러한 진화와 변경의 과정에서도 이제까지 제시되었던 핵심적인 개념과 표현법은 변

화되지 않고 다만 추가적인, 세분화된 표현법이 지속적으로 개발되고 추가되고 있다. 따라

서 지엽적인, 보다 세부적인 UML 표현법을 모두 본 교재에서 다루기는 힘들기에 핵심적

이고 본질적인 표현법을 다루기로 한다.

UML의 작성절차UML의 작성과정은 객체지향 방법론이 그러하듯 밀러의 법칙(Miller's law)에 기반을 둔

반복과 점증(iterative and increment)의 원칙을 따른다.

UML의 작성은 처음부터 완벽한 버전을 만들려고 하기 보다는 초기버전은 시스템에

대한 최초 인식을 바탕으로 최적의 UML을 생성한 후, 실세계에 대한 좀 더 세밀한 분석을

통해 더 많은 지식을 추출하고, 이를 바탕으로 좀 더 정확하고(accurate, iteration) 확장된

(extend, increment) 버전을 만들어 간다.

즉, 모든 것을 한 번에, 동시에 생각하는 것보다 밀러의 법칙에 기초하여 한 번에 예닐

곱 개(magic number seven plus minus two)의 영역(chunk)으로 문제를 구분하고 분석하여

UML을 작성한 다음, 다음 단계에서 각 각의 영역에 대한 분석을 통해 더 많은 지식을 습

득하고 이를 UML에 반영하여 수정하는 단계별 세분화(stepwise refinement)과정으로

진행하는 것이 UML 개발을 쉽게 할 수 있는 방법이다.

StarUML본 교재에서는 UML의 작성 도구로서 소스가 공개된

StartUML(www.starUML.com)을 사용한다. StartUML은

Win32 플랫폼에서 운영되는 공개된 무료 패키지로서, OMG의 UML 2.0을 지원하는 UML/MDA(Model Driven Architecture) 플랫폼을 지원하여 UML을 보다 쉽게 작성할 수 있는 도구이다.

StartUML의 통합개발환경(IDE, integrated development environment)은 <그림 a1-2>의

모델 탐색기에서 나타낸 바와 같이 객체지향

방법론에 의한 정보시스템 개발 제 단계에서

나타내는 각종 모델을 지원한다.

객체지향 소프트웨어는 사용사례지향

(use-case driven) 또는 모델지향구조(model driven architecture)이기에 StarUML도 이들의

절차를 지원한다.

즉, 사용자가 인식 또는 기대하는 시스템의

a4 부록 a - UML

<그림 a1-3> 다이어그램 탐색기

서비스를 파악하는 <<use case model>>의 작성을 시작으로, <<analysis model>>, <<design model>> 및 <<implementation model>>을 작성하여 시스템을 설계 및 구현하고, 이를 서버

에 배포하여 실현하는 <<deployment model>>의 작성을 지원한다.

이를 다시 StartUML을 이용하여 객체지향분석과 설계절차에서 산출되는 다이어그램을

다이어그램 탐색기로 구분하면 <그림 a1-3>과 같다.

객체지향 요구분석 모델 (object-oriented requirement analysis model)정보시스템으로 구축하고자 하는 문제영역(problem domain)에 대한 객체지향 방법론의 관

점은 실세계를 ‘협업하는 객체들이 지원하는 사용사례의 집합(a set of use cases that are supported by a set of collaborating objects)’으로 정의된

다.

이를 개념화 하면 <그림 a1-4>와 같다. 좌측은 복잡한

제품의 생산 프로세스를 나타내는 그림이며, 이를 객체지

향방법론에서는 중앙의 그림과 같이 상호 협력하는 객체

들로 나타낸다. UML 모델이란 <그림 a1-4>의 우측 그림

처럼 협업하는 객체들을 객체들의 구조적인 면(object structure)과 객체들의 행위적인 면(object behavior)으로

설계하되, 기업모델링(enterprise modeling)-비즈니스영역

분석(business area analysis)-시스템디자인(system design)-구축(construction) 등으로 하향식(topdwon)으로 세분화하

는 것이라 할 수 있다.

<그림 a1-4> 객체지향 요구분석 모델 개념도

<그림 a1-3>에서 예시된 각 각의 다양한 다이어그램이 <그림 a1-4>의 개념도와 같이

정보시스템의 구조와 행위를 체계적으로 나타내도록 활용되는 관계는 <그림 a1-5>와 같다.

부록 a - UML a5

<그림 a1-5> UML 산출물의 관계도

객체지향요구분석 모델(object-orient requirement analysis model)은 구축하고

자 하는 문제영역(problem area), 즉 실세계(real world)에 대해 기능적 모델(function model), 구조적 모델(structural model) 및 행위 모델(behavioral model) 등과 같이 3가지 관점에서 모델링 한다.

개발될 시스템에 대한 사용자가 기대 또는 요구하는 기능을 나타내는 기능적 모델은 사용사례 다이어그램(use case diagram)로 나타내며, 이는 외부의 사용자에 의해 발생되

는 이벤트(event)에 기반을 둔다.

문제영역에서 발견되는 클래스들의 정적인 구조(static structure of classes)를 나타내는

구조적 모델은 클래스 다이어그램(class diagram)으로 나타낸다.

기능모델과 구조모델을 기반으로 세분화하여 구현을 위한 행위모델을 개발한다. 행위모

델이란 사용사례를 지원하기 위한 클래스들의 동적인 행위와 오퍼레이션(dynamic behavior and operation)을 나타내는 상호작용 다이어그램(interaction diagram) 또는 순서 다이어그램(sequence diagram)로 모델링한다.

이들 다이어그램 간의 관계가 <그림 a1-5>에 예시되어 있다.

이벤트(events)로부터 개발한 사용사례 다이어그램과 사물(things)에서부터 출발한 클래

스다이어그램은 프로그램 코드를 개발할 수 있는 기반인 순서도를 개발하기 위해 필요한

보조적 다이어그램을 개발한다.

다이어그램를 구체화하기 위해 각 다이어그램에 대한 구체적인 수행절차를 개발하기

위해 사용사례기술서(use case description) 또는 활동 다이어그램(activity diagram)를 개발한다. 또한 주요한 클래스의 상태변화를 살펴보기 위해 상태 다이어그램(statechart diagram 또는 state machine diagram)을 작성한다. 이들 보조 다이어그

램들은 순서 다이어그램을 개발하기 위해 중간단계로 개발하는 것이다.

a6 부록 a - UML

<그림 a2-1> ATM에 대한 사용사례도의 예

a.2 사용사례 다이어그램 (use case diagram)개발될 시스템에 대한 사용자의 기대 또는 요구하는 기능을 나타내는 사용사례 다이어그램(use case diagram)은 정보시스템의 기능적 모델을 나타낸다.

행위자(actor)와 사용사례(use case)가 주요 구성요소인 사용사례 다이어그램은 다음과

같은 두 가지 관점을 나타낸다.

o 사람이 관여하고(person involved)o 그 사람이 시스템을 사용한다(the person uses the system).

즉, 사용사례 다이어그램은 사용자의 다양한 역할과 역할에 따라 시스템을 어떻게 사용할

것인가를 나타낸다. 달리 설명하면 시스템이 어떻게 사용될 것인지를 규명하고, 이를 모델

링하는 것이다.복잡한 시스템은 사용사례 다이어그램을 하나로 구성할 수 없다. 이 경우, 행위자별로 또는

하위시스템(subsystem)별로 사용사례 다이어그램을 별도로 작성한다.

사용사례도의 기본 구성사용사례 다이어그램은 정보시스템과 정보시스템을 이용하는 사용자(users) 간의 상호작용

(interaction)을 나타낸다.

사용사례 다이어그램의 최소한의 기본 구성은 <그림 a2-1>과 같이 행위자(actor), 사용

사례(use case) 및 관계(association)를 나타내는 그래픽 개체로 나타낸다.

<그림 a2-1>은 현금인출기(ATM, automatic teller machine)에 대한 사용사

례도의 예이다. 즉, 시스템을 사용하는

외부 행위자인 고객(customer)은 ATM에 대해 거래내역확인

(retrieveAccountDetails), 출금

(withdrawCash), 입금(depositCash) 및

송금(transferCash)을 행할 수 있기를 기

대하며, ATM은 이러한 요구사항을 충

족할 수 있는 기능을 보유한 시스템으

로 제작되어야 함을 나타낸다.

n 행위자 (actor)행위자(actor)는 시스템 외부 존재하는 개체로서 사용자(user) 또는 시스템을 시작시키

는 발기인(initiator)의 역할(role)을 담당하며, 다음과 같은 역할을 한다.

- 행위자는 시스템에 대해 한 가지 이상의 역할을 담당할 수 있다.

<그림 a2-2>은 고객 입장에서 바라본 은행(bank)에 대한 사용사례도의 예이다. 이 경우,

부록 a - UML a7

<그림 a2-2> 은행의 사용사례도의 예

은행의 고객(customer)은 예금자(depositor)의 역할도 하며 또한 대출자(borrower)의 역할도

담당한다.

- 행위자는 복수개의 사용사

례와 상호작용할 수 있다.

즉, 고객은 거래내역확인 사

용사례(retrieveAccountDetails use case)부터 이자납입

(payInterestOnLoad use case)에

대해 상호작용한다.

- 행위자는 항상 사람일 필

요는 없다.

해당 시스템의 서비스를 사

용하는 다른 시스템이 될 수도

있다.

- 행위자는 일반화(generalization)될 수 있다.

<그림 a2-2>에서 예금자(depositor)와 대출자(borrower)는 모두 은행에 대한 고객이기에

보다 일반화된 개념인 고객(customer)으로 일반화될 수 있다.

실세계의 은행시스템이 <그림 a2-2>와 같이 단순하지 않고 수백, 수천가지의 서비스를

제공해야하는 것은 고객만이 행위자가 아니라 은행에 대한 모든 이해관계자(stakeholder)를

역할별로 구분하여 그들이 요구하는 모든 서비스를 제공해야 하기 때문이다.

n 사용사례 (use case)사용사례(use case)는 시스템의 행위를 나타내는 것으로서 타원에 행위를 나타내는

사용사례 이름과 함께 표현된다.

각 각의 사용사례는 서로 독립적인 한 가지 사례를 나타내기에 사용사례 이름을 구체적

인 행위를 나타내는 동사(verb)와 그 행위가 행해질 구체적인 대상체(object)를 나타낼 수

있도록 ‘verb+object’로 나타내야 한다.

n 관계 (association)사용사례 다이어그램을 구성하는 행위자(actor)는 다른 행위자와 관계(association)가

있을 수 있으며, 사용사례(use case)는 다른 사용사례와 관계가 있을 수 있다. 또한 행위자

와 사용사례 사이에도 관계가 있을 수 있다.

관계는 보다 직접적으로 유도관계(directed association)와 일반화(generalization)로 구체화할 수 있다.

<그림 a2-2>에서 예금자와 대출자는 고객과 일반화관계를 형성하고 있다.

사용사례의 확장가장 기본적인 사용사례 다이어그램(use case diagram)은 행위자(actor)와 그 행위자와 직접

a8 부록 a - UML

관련 있는 사용사례(use case)를 추출하는 것이다.

이러한 사용사례 다이어그램은 문제영역에 대한 이해를 심층적으로 함에 따라 기본적

으로 추출된 사용사례와 관계가 있는 추가적인 사용사례를 <그림 a2-3>과 같이 추출할 수

있다.

기본적인 사용사례가 항상 사용하는 사용사례는 포함관계(include association)에 있다고

하며, 기본적인 사용사례가 선택적으로 사용하는 사용사례는 확장관계(extend association)에 있다고 한다.

<그림 a2-3> 사용사례에 대한 포함 및 확장 관계의 예

n <<include>> 관계포함관계(include association)는 하나의 사용사례가 다른 사용사례의 서비스를 활용

할 때 표현된다. 즉, 어떤 사용사례가 다른 사용사례의 행위를 포함할 때 이들 두 사용사례

간에는 포함관계가 형성되며, 도구상자의 로 나타낸다.

일반적으로 포함관계에 있는 사용사례는 복수개의 사용사례에 의해 공통으로 재사용되

는 경우가 많다.

<그림 a2-3>에서 사용자(customer)가 주문을 하거나(createOrder), 주문을 수정할 때

(updateOrder) 항상 고객을 확인하고(validateCustomerAccount) 재고를 확인하는

(checkItemAvailability) 서비스가 필요하다. 그러나 주문을 조회할 때에는(inquireOrder) 고객확인 서비스만 필요할 것이다.

이 경우 checkItemAvailability 및 validateCustomerAccount는 이들의 서비스를 사용하는

사용사례에 대해 포함관계에 있다고 한다.

n <<extend>> 관계확장관계(extend association)는 어떤 사용사례가 추가적인 행위가 필요할 경우 두

사용사례 간에는 확장관계가 형성되며, 도구상자의 을 이용하여 나타낸다.

일반적으로 확장관계는 어떤 특정 조건에 의해 수행되는 선택적 행위를 나타낼 때 활용

된다.

부록 a - UML a9

<그림 a2-3>의 예에서 고객이 주문을 행할 때(createOrder) 기존 고객을 확인하고

(validateCustomerAccount), 만약 등록 안 된 고객일 경우 신규고객 등록

(createNewCustomer) 서비스를 이용하여 고객등록을 행하여야 할 것이다. 이 경우, 신규고

객 등록(createNewCustomer) 서비스는 주문(createOrder) 서비스에 대해 확장관계에 있다고

한다.

a10 부록 a - UML

<그림 a3-1> 활동 다이어그램의 예

a.3 활동 다이어그램 (activity diagram)활동 다이어그램(activity diagram)은 각 각의 사용사례(use case) 또는 사용사례기술서

(use case description 또는 use case scenario)에 대한 비즈니스 프로세스 워크플로우(workflow of business process)를 문서화하는데 활용되는 표준 UML2.0 다이어그램

이다.

활동 다이어그램은 분석단계에서 하나의 사용사례에 대한 구체적인 처리 흐름을 표현

하기 위해 사용된다. 설계단계에서 클래스의 내부 오퍼레이션을 나타내는 메서드의 알고리

즘이나 구체적인 로직을 나타내는데도 활용된다. 또한 활동 다이어그램은 분석가 또는 디

자이너가 업무의 흐름을 분석하거나 화면의 흐름을 디자인할 때 유용이 활용된다.

정보시스템이란 인간이 행하는 행동 또는 기업이나 조직이 행하는 비즈니스 활동을 모

델링하여 소프트웨어시스템으로 개발하는 것이라고 간략히 정의할 수 있다. 이 경우, 활동(activity)이란 일련의 구체적인 활동 또는 행위(action)들로 세분화가 될 수 있는 절차를

말한다. 행위(action)란 더 이상 분할될 수 없는(non-decomposable) 원자성(atomic)을 나타

내는 절차로 정의된다.

따라서 활동 다이어그램이란 인간의 행동 또는 기업이나 조직의 비즈니스 활동을 행위

로 세분화하는데 활용되는 도구라 할 수 있다.

활동과 전이 (activity/action and transition)<그림 a3-1>은 가장 기본적인 활동 다이어그램의 구조를 예시한 것이다. 모든 처리절차에

는 시작과 끝이 존재한다. 시작은 시작점(initialState, )으로 나타내고 끝은 종료

점(finalState, )으로 나타낸다.

시작과 종료 사이에 각 각의 처리절차를 나타내는 활동

(activity, )를 표시한다. 만약 선택적인 활동이 있다

면 선택(decision, )을 이용하여 표시한다.

<그림 a3-3>은 ‘Activity1을 수행한 다음 만약 특정조건이

true이면 Activity2를, false이면 Activity4를 수행한다. 마지막으

로 Activity4를 수행한다.’라고 해석된다.

활동들의 수행되는 순서는 전이(transition, )로 표

시한다.

활동 다이어그램의 확장과 세분화밀러의 법칙이란 인간이 한 순간에 생각할 수 있는 인지의 범위가 약 예닐곱 개라는 것이

다. 기본적으로 활동 다이어그램은 사용사례 다이어그램의 한 가지 사용사례를 구체적으로

나타내는 기능을 담당하지만 사용사례의 한 가지 사용사례라는 것 자체가 상당히 추상적

인 개념이다.

부록 a - UML a11

활동 다이어그램을 개발하는 대상이 포괄적인 사용사례라면 수십 또는 수백 가지의 활

동으로 세분화될 것이고, 그 대상이 구체적인 사용사례라면 몇 개의 활동으로 표현할 수

있을 것이다.

따라서 반복과 점증의 원칙에 따라 활동 다이어그램도 단계별 세분화(stepwise refinement) 방식으로 개발되어야 한다. 즉, 초기 버전의 활동 다이어그램은 각 ActionState가 활동(Activity)을 표현하면서 시작점부터 종료점까지의 전체적 흐름을 먼저 개발한 이후, 각 각의 활동을 세분화하여 더 이상 분할(decomposition)할 수 없는 행위(Action)로 표현하

는 것이 행위 다이어그램을 개발하는 올바른 절차이다.

활동 다이어그램은 개발하고자 하는 대상이 얼마나 포괄적이냐에 따라 물리적인 크기

가 달라져 몇 페이지로 개발될 수도 있으며, 일반적인 처리절차가 그러하듯 반복적인 루프

(loop)도 나타날 수 있다. 이 경우, 을 이용하여 페이지를 연결하거나, 반복점을

표현 할 수 있다. 또한 수영경기장의 레인을 구분하듯이 특정 흐름에 대해 구분하는 것이

필요하다면 을 이용하여 구획면을 표시하기도 한다.

어떤 ActionState가 내장된 주요한 하위 행위를 포함하고 있다면 이를

을 이용하여 나타낸다. 또한 조건에 맞을 때까지 자신의 행위를 반복적으로 수행할 경우는

을 이용하여 표시한다. 또한 동시에 수행할 ActionState가 있다면 즉, 동기화는

으로 나타낸다.

프로세스가 외부로부터 입력장치를 통해 입력을 받아야 한다면 으로

표현하고, 반대로 외부로 신호를 보내는 절차는 으로 나타낸다.

활동 다이어그램의 사례<그림 a3-2>는 현금인출기(ATM)의 입금(deposit) 사용사례에 대한 활동 다이어그램의 예

를 예시한 것이다.

<그림 a3-2> ATM의 입금(deposit) 사용사례에 대한 활동 다이어그램의 예

a12 부록 a - UML

<그림 a1-2> 속성과 메서드의 추가

a.2 순서도 (sequence diagram)

클래스 다이어그램(class diagram)은 객체지향 애플리케이션의 구조(structure)를 나타낸

다. 즉, 애플리케이션 영역에서 발견되는 클래스들과 이들 간의 관계(association)를 표현한

다.

a.1 클래스 다이어그램 (class diagram)

클래스 다이어그램(class diagram)은 객체지향 애플리케이션을 형성하고 있는 클래스들

의 구조(structure)를 나타낸다. 즉, 애플리케이션 영역에서 발견되는 클래스들과 이들 간의

관계(association)를 표현한다.

클래스 (class)클래스(class)는 ‘class 도구상자’의 을 이용하여 <그림 a1-1>과 같이

사각형으로 표현한다.

추상적인 것에서부터 시작하여 구체화 해가는 하향식(top-dwon) 원칙에 따라 최초에는

가)와 같이 클래스 이름만 파악하여 기술한다. 애플리케이션 영역의 분석과 디자인이 좀더

구체화되면서 나)와 같이 메서드가 추가되고 다)와 같이 속성이 추가된다.

<그림 a1-1> 클래스의 3 가지 표현의 예

클래스에 다음의 3가지 정보를 정의한다.

o 클래스 이름

o 클래스의 속성(attribute) 또는 데이터 멤버(data member)o 클래스의 행동을 나타내는 메서드(method)

클래스에 속성 또는 메서드를 추가하려면 해당 클래스를

선택하고 오른쪽 마우스를 클릭하면 팝업 메뉴가 나타난다. add→attribute 또는 add→operation을 선택하여 속성 또는 메서드를 클래스에 추가한다.

부록 a - UML a13

<그림 a1-3> Model Explorer 창UML 모델에 구성되어 있는 클래스 등의 자원

에 대한 상세 내역을 조회하려면 <그림 a1-3>과

같이 ‘Model Explorer’의 <<design model>>을 확

장하면 확인할 수 있다.

클래스, 속성 및 메서드의 상세 내역을 설정하

거나 조회하려면 <그림 a1-4>와 같이 ‘Properties’ 창을 이용하면 된다.

<그림 a1-4> Class, Operation 및 Attribute의 상세 내역을 설정하는 Properties 창

접근 한정자 (access modifier)클래스는 캡슐화한다. 즉, 자바 실행환경(runtime environment)은 프로그래머가 달리 지

정하지 않는 한 클래스 내부 구조를 외부에 노출되지 않는 것을 보장한다.

따라서 프로그래머는 클래스의 속성 또는 메서드에 접근할 수 있는 권한을 다음과 같은

접근 제한자(access modifier)를 이용하여 알맞게 설정하여야 한다.

o public: (+) 기호로 표시된다. ‘누구든지 접근 가능’모든 객체가 접근 가능하도록 하려면 속성, 데이터 또는 메서드를 public으로 선언한

다. public으로 선언한다는 것은 캡슐 밖으로 노출시켜 어떤 객체라도 자유롭게 사용

하도록 만든다는 의미이다.o private: (-) 기호로 표시된다. ‘이 클래스로부터 만들어진 객체들만 접근 가능’

속성, 데이터 또는 메서드를 private으로 선언하면 캡슐내로 은닉한다는 의미이다. 즉, private으로 선언되면 오직 이 클래스로부터 생성된 객체들만 접근할 수 있음을 의미

한다. 정보은닉(information hiding) 원칙에 따라 노출해야만 하는 메서드만 public으로 선언하고 그 이외는 private으로 선언해야 한다.

o protected: (#) 기호로 표시된다. ‘이 클래스의 객체들과 파생 클래스들만이 접근 가

능’protect로 선언되는 속성, 데이터 및 메서드는 오직 이 클래스와 이 클래스로부터 파

생된 클래스들의 객체 즉, 동일 상속체계에 있는 후손 객체들만 접근 가능하다는 의

미이다.

a14 부록 a - UML

<그림 a-5> 접근 제한자

<그림 a1-6 연관 관계>

클래스의 해당 데이터나 메서드를 더블클릭하면 <그림

a-5>와 같이 접근 한정자를 선택하여 설정할 수 있다.

관계 (association)객체지향 세상이란 관련 또는 연관(association) 있는 객체들이

상호작용(interact) 또는 협업(collaboration)하는 애플리케이션

공간이다. 클래스 다이어그램은 애플리케이션 공간에 존재하

는 클래스를 나타낼 뿐만 아니라 서로 관련이 있는 클래스들

을 파악하여 이들의 관계를 나타낸다.

관계(relation)란 서로 다른 두 개의 클래스가 서로 관련이 있을 경우 ‘두 클래스는 상호

간에 관계가 있다’라고 한다. 수십억 인구가 살아가는 현실세계에서 ‘나’와 전혀 관계없는

사람들도 있지만 ‘나’와 가족관계, 선후배관계, 동호회회원관계 등의 직접적인 연관이 있거

나, 같은 한국 사람으로서 동일한 국적관계, 같은 성별로서 동일한 성별관계 등의 훨씬 더

포괄적이고 추상적인 관계까지도 있다.

그러나 객체지향 모델에서는 포괄적, 추상적 관계는 배제하고 직접적인 관련 또는 연관

관계만을 모델링한다. 또한 모든 관계는 양방향이다. ‘나’와 가족관계이거나 선후배관계이

거나 또는 동호회회원관계에 있는 클래스는 그 클래스에서 ‘나’는 가족관계이거나 선후배

관계이거나 또는 동호회회원관계이다.

그러나 클래스 다이어그램에서는 관계를 양방향으로 표현하지 않고 주요 관심사인 클

래스를 중심으로 한 방향으로 나타내는 것이 일반적이다.

연관관계(association relation)는 2개의 클래스가 상호 관련 있을 경우 ‘class 도구상자 ’ 의 을 이용하여 표현한다.

연관관계는 업무영역에 대한 분석이 진행됨에 따라 구체적인 연관관계인 상속관계, 복합연관관계, 집합연관관계, 의존관계 등으로 세

분화 또는 구체화된다.

<그림 a1-6>은 4개의 클래스로 구성된 클래

스들의 연관관계를 나타낸 사례이다. 교수

(Professor) 클래스와 학생(Student) 클래스는 서

로 지도하고 지도 받는 관계이며, 학생과 그 행

생의 아버지(FatherOfStudent)는 부모-자식 관계이다. 또한 학생은 등․하교를 스쿠터를 이

용하기에 학생과 스쿠터(Scooter) 클래스는 의존관계이다.

이렇듯 연관관계는 항상 상호적으로 양방향에서 나타난다. 필요할 경우 관계 이름

(name)을 화살표에 표기하기도 한다. 교수와 학생의 관계는 강의담당교수와 수강생의 관계

또는 지도교수와 지도학생과의 관계 등 다양하기에 <그림 a1-6>에서는 지도교수와 지도학

생의 관계를 이름짓고, 표기하였다.

상속관계는 항상 부모-자식관계이기에 관계이름의 명기를 일반적으로 생략한다. 그러나

학생과 스쿠터 관계는 학생이 스쿠터를 이용하고, 스쿠터는 학생에게 이용당하지만, 이용

하는 관계가 중요하기에 Student 클래스에서 Scooter 클래스의 일방향으로만 관계를 명시

부록 a - UML a15

<그림 a1-7> 상속 관계

<그림 a1-8> 집합연관 관계

한다.

상속 (inheritance, IsA) 관계클래스 간의 상속 관계는 ‘class 도구상자’의 을 이용하여 표현한다.

공통 관점으로 분류될 수 있는 클래스는 일반화하여 계층구조로 표현한다. 원(Circle), 삼각형(Triangle) 및 사각형(Square)은 도형(shape)으로 일반화할 수 있기에 <그림 a1-7>과

같이 상속 관계(inherit relation)로 나타낸다.

상속관계는 ‘IsA' 관계라고도 한다. 즉, ‘~이다’로 설명되는 관계로서 ‘사각형은 도형

이다’라는 설명이 참(true)이면 shape 클래스와 상속 관계가 성립하는 것이다. 상속 관계는

일반화(generalization) 관계라고도 한다.

상속관계의 상위클래스(super class)는 추상 클래스(abstract class)이며, 하위클래스(sub class)는

구상 클래스(concrete class)라고 한다. <그림

a1-7>에서 Shape 클래스는 상위클래스이다. 따라서

Shape 클래스는 객체를 직접 생성할 수 없는 추상

클래스이며, 기울임 글자체로 추상클래스임을 나타

낸다.

원, 삼각형 및 사각형의 길이를 구하는 getWidth() 메서드는 모든 도형에 동일하게 적용

될 수 있기에 Shape 클래스에 구현코드가 작성되는 구상 메서드(concrete method)로 나

타냈다. 그러나 도형을 출력하는 display() 메서드는 원, 삼각형 및 사각형이 각 각 다른 모

양으로 출력해야 하기 때문에 Shape 클래스의 display() 메서드는 구현할 수가 없다. 다만

Shape 클래스에서 각 하위 클래스인 Circle, Triangle 및 Square 클래스의 출력 행동 통일

(메서드 이름 통일)을 위해 구현 코드가 없이 메서드 헤더만 정의하는 추상 메서드(abstract method)로 표현하였고 기울임 글자체로 표시된다. 그리고 Shape 클래스에 정

의된 display() 메서드의 각 각의 행위(출력 모양)를 구현하기 위해 각 하위 클래스에 구상

메서드인 display()를 표현하였다.

집합연관 (aggregation, HasA) 관계 클래스 간의 집합연관 관계는 ‘class 도구상자’의 을 이용하여 표현한다.

집합연관 관계(aggregate relation)는 두 객체 간의 관계로 ‘~에 있다’ 또는 ‘~를 가

지고 있다’라고 표현되기에 ‘HasA' 관계라고도 한다.

‘공항(AirPort)에는 비행기(Aircraft)가 있다’라는

의미의 클래스간의 관계는 집합연관 관계로 <그림

a1-8>과 같이 표현한다. 여객기와 헬리콥터는 일종의

비행기이기에 Aircraft 클래스의 하위클래스로 구성하

여 상속관계를 나타내었다.

복합연관 (composition, APartOf) 관계

a16 부록 a - UML

<그림 a1-9> 복합연관 관계

복합연관 관계는 ‘class 도구상자’의 을 이용하여 표현한다.

복합연관 관계(composite relation)는 두 객체 간의 관계가 ‘~으로 구성되어 있다’로

설명되어질 때 존재하며 이를 ‘APartOF’ 관계라고도 한다.

‘자동차(Car)는 타이어(Tire)와 엔진(Engine)으로 구성되어 있다’라는 의미의 복합연관

관계가 <그림 a1-9>에 예시되어 있다.

복합연관관계는 그 관계를 해지할 때 각 각의 클래스 단독으로는 애플리케이션에서 의

미가 없는 경우에 표현된다.

이와 반하여 집합연관관계는 <그림 a1-8>의 사례와

같이 공항이 아닌 곳에서도 여객기와 헬리콥터는 독립적

으로 충분히 의미가 있는 경우에 표현된다.

의존 또는 사용 (dependency 또는 use) 관계 의존 또는 사용 관계는 ‘class 도구상자’의 을 이용하여 표현한다.

클래스 또는 객체는 상호 협업(collaboration) 또는 작용(interaction)을 한다. 즉, 서비스

를 요청하는 클래스 또는 객체는 서비스를 제공하는 클래스 또는 객체에 의존관계(dependent relation) 또는 사용관계(use relation)에 있다고 말한다.

의존관계 또는 사용관계는 ‘~을 이용한다.’ 또는 ‘~의 서비스에 의존한다.’라는 의미를

가진다. <그림 a1-9>에서 운전자인 Driver 클래스는 자동차인 Car 클래스를 이용하고 있음

을 나타낸다.

애플리케이션이 실제 객체지향언어로 구현될 때 의존관계는 해당 객체의 메서드를 호

출하여 제공하는 서비스를 이용하는 형태로 나타난다.

a.2 협업도 (sequence diagram)

클래스 다이어그램(class diagram)은 객체지향 애플리케이션의 구조(structure)를 나타낸

다. 즉, 애플리케이션 영역에서 발견되는 클래스들과 이들 간의 관계(association)를 표현한

다.

a.2 순서도 (sequence diagram)

클래스 다이어그램(class diagram)은 객체지향 애플리케이션의 구조(structure)를 나타낸

다. 즉, 애플리케이션 영역에서 발견되는 클래스들과 이들 간의 관계(association)를 표현한

다.

부록 a - UML a17

클래스 (class)클래스(class)는 ‘class 도구상자’의 을 이용하여 <그림 a-1>과 같이

사각