객체지향 CBD 개발 분석 - Egloospds10.egloos.com/pds/200901/14/88/a0105788_496df5c7e95e9.pdf · 2009-01-14 · Java 또는C#으로설정하였다면 String이아니라int 타입이선언된다

One Step Ahead

객체지향객체지향 분석분석 및및 설계설계대학 정보시스템 개발을 통한 J2EE 이해

김상일

[email protected]

2객체지향 분석 및 설계

- One Step Ahead -

Copyright ⓒ NEXTREE SOFT CO., LTD., 2007, All Rights Reserved.

1. 개요

2. 분석 클래스의 파악

3. 분석 클래스 간의 관계 파악

4. 분석 유스케이스 실현

5. 분석 사례 – 학생관리 유스케이스

6. 분석 사례 – 수강신청 유스케이스

7. 분석 모델의 구성 방법

8. 분석에 대한 고찰

9. 분석 활동의 점검

10. 요약

요구사항요구사항 분석분석

1. 개요


- One Step Ahead -


분석 활동은 설계 활동과 더불어 유스케이스에 의해서 정의된 시스템의 기능을 제공하기 위하여 필요한 시스템 내부의 클래스들과 이들 클래스의 객체들간의 상호작용을 모델링하는 과정이다.

분석 활동에서는 기능적인 요구사항만을 고려하고 플랫폼은 고려되지 않으며, 설계 활동에서는 추가적으로 비기능적인 요구사항과, 개발 언어, 미들웨어, 운영체제, DBMS 등과 같은 플랫폼을 고려한다.

따라서, 클래스/연산/속성 등에 사용되는 이름은 플랫폼에 관련되서는 안 되며, 오직 시스템의 기능적인 측면을 나타내야 한다.

즉, 개발할 시스템의 기능을 정의할 때 사용된 용어를 클래스/연산/속성 등의 이름으로 사용한다.

그러므로, 시스템 사용자들에게 클래스 다이어그램의 의미를 설명해 주면, 클래스 다이어그램에는 기술적인 부분(프로그래밍 언어, 운영체제, DBMS 등)은 표현되지 않았기 때문에 사용자들이 클래스 다이어그램을 해석하여 시스템의 분석 결과를 이해할 수 있을 정도가 되어야 한다.

1. 1. 개요개요


- One Step Ahead -


대부분의 객체지향 및 컴포넌트 기반 개발방법론에서 클래스를 도출하는 체계적인 기법으로 유스케이스 분석기법을 사용한다.

유스케이스 분석 기법은 야곱슨에 의해서 제안된 방법으로 요구사항 정의 활동에서 도출된 유스케이스를 분석함으로써 세 가지 종류의 클래스(경계 클래스, 제어 클래스, 실체 클래스)를 파악한다.

분석 활동에서 파악되는 경계, 제어, 실체 클래스를 설계 활동에서의 클래스와 구분하기 위해서 분석 클래스(analysis class)라고 부른다.

경계 클래스(boundary class)개발될 시스템과 그 외부와의 연결을 담당하는 클래스

사용자 인터페이스 화면 및 외부 시스템과 통신하는 클래스가 해당된다.

제어 클래스(control class)시스템이 제공하는 비즈니스 로직을 구현하는 클래스

유스케이스로 정의된 비즈니스 로직을 다른 클래스들의 객체를 이용하면서 제공하는 역할을 한다.

실체 클래스(entity class)영속성이 있는 데이터에 대한 관리 기능을 제공하는 클래스

즉, 영속성이 있는 데이터를 생성, 조회, 수정, 삭제하는 기능을 제공하는 클래스다.

UML에서는 세 종류의 클래스를 용이하게 구분할 수 있게 각 분석 클래스에 대해서 별도의 스테레오 타입과 아이콘을 정의하고 있다.

분석 클래스의 종류 및 표기 방법

종류 스테레오 타입 아이콘 역할

실체클래스 <<entity>> 영속성이 있는 데이터에 대한 조작을 담당

경계클래스 <<boundary>> 시스템과 외부와의 연결을 담당

제어클래스 <<control>> 비즈니스 로직을 담당

2. 2. 유스케이스유스케이스 분석분석 기법기법


- One Step Ahead -


요구사항 정의 활동에서 작성한 유스케이스 모델과 유스케이스명세서를 바탕으로 유스케이스 분석 기법을 적용한다.

유스케이스 분석 기법을 적용한 결과는 경계클래스, 제어클래스, 실체클래스 등의 분석클래스와 이들 간의 관계로 클래스 다이어그램에 표시되며 이를 분석객체모델이라고부른다.

UML의 시퀀스 다이어그램을 사용하여 도출된 각 분석 객체들 간의 메시지 송수신을통한 각 유스케이스의 실현 과정을 표현한다. 이를 분석유스케이스모델이라고 부른다.

분석객체모델과 분석유스케이스실현모델을 통칭하여 분석모델이라고 부른다.즉, 분석 활동의 산출물은 분석모델이며, 분석모델은 분석객체모델과 분석유스케이스실현모델로 구성된다.

산출물의 명칭

산출물의 이름을 클래스 다이어그램이라고 하지 않고 분석객체모델이라고 하는 이유는

클래스 다이어그램은 분석 뿐만 아니라 설계에서도 사용될 수 있기 때문에, 산출물의 명칭을 클래스 다이어그램이라고 하는 경우, 분석 활동이 산출물인지, 설계 활동의 산출물 인지가 모호할 수있기 때문이다.

산출물 이름은 표기법이 아니라 궁극적으로 산출물이 나타내는 대상 즉, 분석 결과, 설계결과 등이 이름에 표현되어야 한다.

따라서 클래스 다이어그램, 시퀀스 다이어그램 대신에 분석객체모델, 분석유스케이스실현모델이라고 하는 것이 정확한 명칭이다.

3. 3. 분석분석 활동의활동의 산출물산출물 (1)(1)


- One Step Ahead -


요구사항 정의와 분석 활동의 산출물

3. 3. 분석분석 활동의활동의 산출물산출물 (2)(2)

2. 분석클래스의 파악


- One Step Ahead -


경계클래스(Boundary Class)는 개발될 시스템과 그 외부와의 연결을 담당하는 클래스다.

즉, 시스템의 가장 외곽에 존재하여 시스템의 다른 클래스들을 대신해서 시스템 외부와의상호작용을 전담하는 클래스다.

시스템의 외부는 액터를 의미한다.따라서 경계클래스는 시스템 외부에 존재하는 액터와의 상호작용을 제공하는 역할을 한다.

경계클래스의 역할

수업담당자

교수

학생

학사담당자

시스템

b2

b1

b3b4

제어클래스실체클래스

수강료청구서발급시스템

b5

UI 경계클래스 : b1, b2, b3, b4SI 경계클래스 : b5

1. 1. 경계클래스의경계클래스의 파악파악 (1)(1)


- One Step Ahead -


제어클래스와 실체클래스는 시스템 외부의 액터와 직접 연결되어 있지 않다.

경계클래스가 시스템 내에 존재하는 많은 클래스 중에서 시스템 외부의 존재즉 사용자 및 외부시스템을 연결하는 역할을 한다.

즉, 시스템 내의 다른 모든 클래스(제어클래스와 실체클래스)는 사용자 또는 외부 시스템과 직접 연결되지 못하며 반드시 경계클래스를 통해서 사용자 또는 외부 시스템과 연결된다.

액터가 사용자액터와 시스템액터로 분류가 된 것처럼 경계클래스도 액터의 종류에 따라서 UI(User Interface) 경계클래스와 SI(System Interface) 경계클래스로 분류된다.

즉, 사용자액터와의 연결을 담당하는 경계클래스는 UI 경계클래스이고, 외부 시스템액터와의 연결을 담당하는 경계클래스는 SI 경계클래스이다.

1. 1. 경계클래스의경계클래스의 파악파악 (2)(2)


- One Step Ahead -


사용자 액터, 즉 시스템의 사용자는 사용자 인터페이스 화면을 통해서 시스템이 제공하는 기능을 이용한다.

사용자가 시스템을 사용하기 위해서 보는 각각의 화면(또는 윈도우)은 모두 경계클래스에 해당한다.

이러한 종류의 경계클래스를 UI 경계클래스(User interface boundary class)라고 부른다.

UI 경계클래스는 사용자 인터페이스를 위한 각 화면을 뜻하므로 개념적인 용어이다.

UI 경계클래스의 실질적 의미

개발 언어 UI 경게클래스의 대응 요소 개발 언어 UI 경계클래스의 대응 요소

Visual Basic Form VC++/MFC

ASP

Window

JSP JSP 페이지 ASP 페이지

ASP.NET ASP.NET 페이지

2. UI 2. UI 경계클래스경계클래스 (1)(1)


- One Step Ahead -


2.1 UI 경계클래스의 도출UI 경계클래스는 사용자 화면이라고 볼 수 있다.

유스케이스명세서의 ~화면 하나하나가 UI 경계클래스에 해당한다.

로그인 유스케이스의 이벤트 흐름

기본 흐름

1. 사용자는 시스템에 접속한다.

2. 시스템은 로그인 화면을 보여준다.

3. 사용자는 아이디와 암호를 입력하고 로그인을 선택한다.

사용자 아이디 즉, 학번/교수번호/직원번호는 다음과 같은 규칙을 가진다.

■ 학번 : 첫 문자는 ‘S’로 시작하고 이어서 3자리의 숫자가 나온다.

■ 교수번호 : 첫 문자는 ‘P’로 시작하고 이어서 3자리의 숫자가 나온다.

■ 직원번호 : 학사담당자는 ‘H’로 시작하고 이어서 3자리의 숫자가 나온다. 수업담당자는 ‘G’로 시작하고 이어서 3자리의숫자가 나온다.

사용자 암호는 7자리의 영문자 및 숫자로 구성된다.

4. 시스템은 입력된 아이디와 암호의 유효성(A1)과 정확성(A2)을 확인하고 사용자 별 메인 화면을 보여준다. 각 사용자 별 메인 화면은 다음과 같다.

■ 학생 : 학생 메인 화면

■ 교수 : 교수 메인 화면

■ 학사담당자 : 학사 관리 메인 화면

■ 수업담당자 : 수업 관리 메인 화면

대안 흐름

(A1) 유효하지 않은 아이디 또는 암호인 경우

1. 시스템은 입력된 아이디 또는 암호가 허용되지 않는 값임을 알려준다.

2. 사용자는 다시 아이디와 암호를 입력함으로써 로그인을 시도한다.

(A2) 부정확한 아이디와 암호인 경우

1. 시스템은 아이디와 암호가 부정확함을 알려준다.




- One Step Ahead -


로그인 유스케이스의 이벤트 흐름에는 총 5개의 화면(로그인, 학생 메인, 교수 메인, 학사관리 메인, 수업관리 메인)이 기술되었다.

각각의 화면은 사용자(학생, 교수, 학사담당자, 수업담당자)가 시스템에 로그인을 하거나(로그인화면)

로그인 후에 시스템의 기능을 이용할 때 이용(학생메인화면, 교수메인화면, 학사관리메인화면, 수업관리메인화면)되는 화면으로

사용자는 이들 화면에 값을 입력하거나, 버튼을 선택함으로써 시스템에서 제공하는 기능을이용할 것이다.

따라서 각각의 화면은 모두 UI 경계클래스에 해당한다.

로그인 유스케이스의 UI 경계클래스

로그인화면 학생메인화면 교수메인화면 수업관리메인화면 학사관리메인화면



- One Step Ahead -


암호변경 유스케이스의 UI 경계클래스

기본 흐름

1. 사용자는 사용자 별 메인 화면에서 암호변경을 선택한다.

2. 시스템은 암호변경 화면을 보여준다.

3. 사용자는 새 암호를 두 번 입력하고 변경을 선택한다.

4. 시스템은 사용자의 암호를 입력된 새 암호로 변경하고, 암호변경 성공 화면을 보여준다(A1).

대안 흐름

(A1) 입력된 두 암호가 일치하지 않는 경우

1. 시스템은 입력된 두 암호가 일치하지 않음을 알린다.

2. 사용자는 다시 새 암호를 입력해서 암호변경을 시도한다.



- One Step Ahead -


2.2 UI 경계클래스의 속성클래스의 속성은 클래스로부터 생성된 객체의 상태를 저장하는 공간으로, 클래스의 연산들이 공유하는변수라고 볼 수 있다.

UI 경계클래스는 사용자 화면에 해당하며, 각 화면마다 저장되어야 하는 상태는 사용자가 화면에 입력한 값 또는 시스템이 사용자에게 보여주기 위해서 출력한 값에 해당한다.

따라서 UI 경계클래스의 속성에는 화면을 통해서 입 출력되는 정보들이 기술된다.

로그인화면 클래스의 속성

‘대학정보시스템에 오신 것을 환영합니다’, 아이디, 암호

시스템이 화면을 통해서 출력하는 메시지는 시스템이 어떤 기능

(즉, 비즈니스 로직)을 수행하여 그 결과 값을 보여주는 것이 아니라,

단순한 정적인 메시지에 해당하므로 분석 활동에서는 이들을

속성으로 간주하지 않는다.

시스템의 비즈니스 로직의 수행에 따른 결과 값을 메시지로 화면에

표시하는 경우에는 속성으로 간주한다.

대학정보시스템에 오신 것을 환영합니다.

아이디:

암호:

로그인



- One Step Ahead -


속성의 스테레오 타입

속성 이름 앞의 ‘-’기호는 해당 속성에 대한 접근 권한이 전용(private)임을 나타낸다. UML에서는 전용(-), 보호(#), 공용(+)으로 나타낸다.

암호변경화면 클래스의 속성

속성의 구체적인 코드 예

스테레오 타입 설명

<<in>> 사용자에 의해 값이 입력되는 속성

<<out>> 시스템이 값을 출력하며, 사용자가 그 값을 변경할 수 없는 속성

<<inout>> 시스템이 초기값을 출력하고, 사용자가 그 값을 변경할 수 있는 속성

암호 변경

새 암호:

새 암호 확인:

변경

스테레오 타입 설계에서의 구체화된 속성

<<in>> HTML의 <input type=“text”>

<<out>> HTML의 일반 텍스트

<<inout>> HTML의 <input type=“text” value=“초기값”



- One Step Ahead -


클래스의 속성 추가하기

New | Attribute 항목을 선택하면‘+attribute1:String’ 속성이기본적으로 추가된다.

기본 언어를 Design이 아니라,Java 또는 C#으로 설정하였다면String이 아니라 int 타입이 선언된다.

속성의 타입

분석은 플랫폼에 의존하지 않기 때문에,속성의 이름을 특정 프로그래밍 언어의문법에 맞게 줄 필요가 없다.

산출물의 이해도 면에서 한글로지정하는 것이 바람직하다.

속성의 타입도 특정 언어의 것 보다는일반적으로 사용되는 몇 가지 타입 만을정해서 사용하는 것이 바람직하다.

Together에서는 속성의 타입을지정하지 않고 비워 둘 수는 없다.



- One Step Ahead -


2.3 UI 경계클래스의 연산 (1)클래스의 연산은 클래스로부터 생성된 객체가 외부(또 다른 객체)에 제공할 수 있는 기능에해당한다.

즉, 연산을 호출함으로써(메시지) 객체가 제공하는 기능의 수행이 시작되는 것이다.

UI 경계클래스는 사용자 화면에 해당하므로, 사용자 화면이 제공하는 구체적인 기능의 수행은 화면 상의 메뉴 또는 버튼 등에 의해서 시작된다.

즉, 사용자 화면의 ‘메뉴 항목’을 선택하거나 ‘버튼’을 눌렀을 때 화면은 약속된 기능의 수행을 시작한다.

연산의 이름화면에서 보이는 버튼의 캡션 또는 메뉴 항목의 캡션을 이름으로 하는 연산을 정의한다.

접근 권한UI 경계클래스의 연산은 외부(사용자)에 의해서 호출되는 것이므로 공용 접근 권한을 가지는 것이 적절하다.

연산의 인자UI 경계클래스의 연산에는 아무런 인자가 없는 것이 올바르다.

반환 타입UI 경계클래스의 연산의 반환 타입은 의미가 없으므로 생략한다.


로그인 유스케이스의 경계클래스


- One Step Ahead -


2.3 UI 경계클래스의 연산 (2)암호변경 성공 화면처럼 속성과 연산이 하나도 없으면서 그 의미가 명확한 화면은 유스케이스명세서의 이벤트 흐름에서 간단히 출력할 메시지만 기술하고 별도의 화면을 정의하지 않는 것도 하나의 방법이다.

암호변경 유스케이스의 경계클래스



- One Step Ahead -


UI 경계클래스의 도출 방법

도출 단위 유스케이스명세서의 이벤트 흐름에 기술된 각 화면마다 정의

클래스 이름 유스케이스명세서의 이벤트 흐름에 명시된 화면 명에 해당

해당 화면에서 사용자가 입력하는 항목 및 시스템이 출력하는 항목에 해당

이름 입력/출력되는 데이터 항목의 이름에 해당

접근 권한 전용

스테레오 타입

<<in>> : 입력

<<out>> : 출력

<<inout>> : 입출력

타입Boolean, String, Number, Date 등 일반적인 것을 사용

인자의 이름만으로 명확한 경우에는 생략 가능

해당 화면에서 시스템의 기능 수행을 시작시키기 위하여 선택되는 메뉴 항목 또는 각종 버튼에 해당

이름 화면에 표시되는 메뉴 항목의 캡션 또는 버튼의 캡션

접근 권한 공용

반환 타입 없음

인자 없음

연산

속성

2. UI 2. UI 경계클래스경계클래스 요약요약 (10)(10)


- One Step Ahead -


SI 경계클래스는 경계클래스의 한 종류로써 개발할 시스템과 연동되는 외부시스템과의 연결을 담당하는 클래스다.

즉 유스케이스모델에서 파악된 시스템액터와의 연결을 담당하는 클래스다.

일반적으로 SI 경계클래스는 정의된 프로토콜에 따라서 외부시스템에 데이터를보내거나 받은 역할을 수행한다.

3.1 SI 경계클래스의 도출 방법

외부 시스템 액터마다 하나의 SI 경계클래스를 정의하는 것이 바람직하다.

SI 경계클래스는 대응하는 외부 시스템 액터의 이름에 ‘에이전트’를 추가하여 이름을 줌으로써, SI 경계클래스가 외부의 어떤 시스템과의 연결을 담당하는 지를쉽게 파악할 수 있게 한다.

SI 경계클래스의 예

대학정보시스템에는 수강료청구서발급시스템 시스템 액터가 있다.

이 액터에 해당하는 SI 경계클래스로 ‘수강료청구서발급시스템에이전트’ 클래스를정의하고, 수강료 청구서 발급 시스템과의 모든 연결은 이 클래스가 전담하게 한다.

수강료청구서발급시스템에이전트

3. SI 3. SI 경계클래스경계클래스 (1)(1)


- One Step Ahead -


3.2 SI 경계클래스의 연산 (1)SI 경계클래스는 외부 시스템과의 연결을 담당하므로 외부 시스템에 대한 기능의 수행 요구와 외부 시스템으로부터의 접속에 대한 처리가 연산으로 정의된다.

즉, 구축 중인 시스템의 다른 모든 클래스는 외부 시스템과 연동 시 해당하는 SI 경계클래스 만을통하므로 외부 시스템에 대한 모든 처리 요청과 외부 시스템의 모든 처리 결과에 대한 수신이 연산으로 정의된다.

수강료청구서발급시스템에이전트 클래스의 연산

수강료청구서발급결과수신외부 시스템의 기능 수행의 결과를 수신

외부 시스템의 기능 수행을 요청하는 연산의 이름‘수행될 외부 시스템의 기능’ + ‘요청’

요청 시 외부 시스템에 전송될 데이터학생정보, 수강신청정보처럼 연산의 인자로 전달

외부 시스템에 대한 수행 요청 자체의 성공여부Boolean 타입으로 반환



- One Step Ahead -


3.2 SI 경계클래스의 연산 (2)SI 경계클래스의 연산은 외부 시스템과 접속을 해야 하기 때문에 비동기적으로 수행될 수있다.

즉, 네트워크를 통해서 외부 시스템에 데이터를 전달하면 그 결과를 항상 바로 얻을 수 있는 것이아니며, 또는 외부 시스템의 수행 결과가 반드시 온다고 확신할 수도 없다.

비동기적으로 외부 시스템과 연동하는 경우에 외부 시스템은, 요청 받은 기능을 수행한 후에 그 결과를 시스템에 통신을 통하여 전달한다.

따라서 외부 시스템으로부터의 접속을 수신하고 이를 처리하는 기능도 연산으로 포함되어야 한다.

수강료청구서발급시스템에이전트의 수강료청구서발급결과수신() 연산

외부 시스템의 기능 수행의 결과를 수신하는 연산의 이름

‘수행된 외부 시스템의 기능’ + ‘결과수신’

수신 시 외부시스템에서 전송 받을 데이터

네트워크를 통해서 전송 받은 데이터를 분석할 것이므로, 아무런 인자가 필요 없다.

외부 시스템에 대한 수행 결과 자체의 성공여부

Boolean 타입

만약, 외부 시스템과 비동기적인 방식이 아니라, RPC, RMI, .NET Remoting과 같은 동기적 통신을 한다면 수강료청구서발급결과수신()과 같은 연산은 정의될 필요가 없다.

구축할 시스템에서 외부 시스템에 전달할 데이터의 종류 및 형식과 수신할 결과 데이터의종류 및 형식 등이 명확히 파악되고 정의되어야 한다.



- One Step Ahead -


3.3 클래스 연산의 시그너처 숨기기/보이기

1. Tools | Options | <level>을 선택한다.Diagram Level : 현재 다이어그램에만 적용

Project Level : 현재 프로젝트에 적용

Default Level : 현재 프로젝트를 포함하여 다른 모든 프로젝트에 적용

2. 표시된 Options 대화 상자의 좌측에서 ‘View Management’를 선택한다.이 때 우측의 ‘Diagram detail level’에서 적절한 항목을 선택한다.

Analysis : 이름만 표기

Design : 접근 권한, 이름, 타입 표기

Implementation : 접근 권한, 이름, 타입, 인자, 초기 값 표시

Default : Together 사용자의 현재 역할에 따라서 자동으로 결정된다.Business Modeler : Analysis

Designer 또는 Developer : Design

Programmer : Implementation

현재 사용자의 역할은 Together를 설치할 때 초기에 지정된다. 그리고 설치 후에는 Tools | Options | Default Level을 통하여 표시된 Options 대화 상자 좌측에서 ‘General’을 선택하면 우측의 ‘Role after restart’를 통하여 지정할 수 있다.

연산의 인자까지 표시하는 것은 클래스 다이어그램에서 적지 않은 공간을 차지하므로 특별한 이유가 있지 않으면 연산의 인자는 표시하지 않고 생략하는 것이 좋을 수 있다.

즉, 역할은 Developer, ‘Diagram detail’은 Default로 한다.



- One Step Ahead -


3.4 SI 경계클래스의 속성

SI 경계클래스의 속성은 두 가지 측면에서 정의될 수 있다.접속할 외부 시스템에 전달할 데이터를 저장하기 위해서 속성을 사용

외부 시스템의 수행 결과를 수신하고 이 결과를 저장하기 위해서 속성을 사용

클래스의 여러 연산들 사이에 공유하는 정보가 하나도 없는 경우에는 클래스에속성이 정의될 필요가 없다.

SI 경계클래스의 경우에는 클래스의 연산들은 각각 독립적인 기능을 수행하는 경우가 많으며, 이 연산들이 공유하는 정보가 없는 것이 일반적이다.

즉, ‘수강료청구서발급요청()’ 연산을 호출할 때 필요한 모든 데이터를 이 연산의 인자로 넘겨주며, ‘수강료청구서발급요청()’ 연산과 ‘수강료청구서발급결과수신()’ 연산이 공유할 정보가 없는 경우가 많다.

따라서 SI 경계클래스의 경우에는 속성이 정의되지 않은 경우가 빈번하다.



- One Step Ahead -


SI 경계클래스의 요약

SI 경계클래스의 도출 방법

도출 단위 유스케이스 모델의 각 시스템 액터마다 정의

클래스 이름 시스템 액터 명 + ‘에이전트’

속성 연산들 사이에 공유 될 정보가 없는 경우가 많으므로 대부분의 경우에 속성이 없는 경우가 일반적이다.

외부 시스템의 기능 수행을 요청하거나, 외부 시스템의 기능 수행 결과를 수신하는 역할

이름외부시스템의 기능 + ‘요청’

외부시스템의 기능 + ‘결과수신’

접근 권한 공용

반환 타입‘~요청’ 연산 : Boolean

‘~결과수신’ 연산 : Boolean

인자‘~요청’ 연산의 경우에는 외부 시스템에 전달될 정보가 인자로 정의된다.

‘~결과수신’ 연산의 경우에는 인자가 없는 것이 일반적이다.

연산

3. SI 3. SI 경계클래스경계클래스 요약요약(6)(6)


- One Step Ahead -


실체클래스는 영속적으로 유지되어야 하는 각 정보 항목에 대한 정의 뿐만 아니라, 이 정보에 대한 관리를 담당한다.

즉, 영속성이 있는 정보를 생성하고, 조회하고, 삭제하는 기능을 수행한다.

대부분의 시스템에서 데이터베이스를 통해서 데이터의 영속성은 구현된다.

실체클래스의 역할

수업담당자

교수

학생

학사담당자

시스템

b2

b1

b3

b4

제어클래스

수강료청구서발급시스템b5

UI 경계클래스 : b1, b2, b3, b4SI 경계클래스 : b5 실체클래스 : e1, e2, e3

데이터베이스

e1

e2

e3

4. 4. 실체클래스의실체클래스의 파악파악 (1)(1)


- One Step Ahead -


4.1 실체클래스의 도출 방법 (1)실체클래스는 문제기술서(Problem Statement)에서 명사를 분석하여 클래스를 도출하는 전통적인방법을 통해서 도출될 수 있다.

즉, 구축할 시스템에 대한 요구사항을 기술하고 있는 문제기술서에 등장하는 주요한 용어/개념들이 실체클래스에 대응될 가능성이 높다.

문제기술서 부분 1

문제기술서에 등장하는 명사 모두가 실체클래스에 해당하는 것은 아니므로, 자세하게 분석을 통해서 실체클래스를 정의해야 한다.

문제기술서의 명사가 실체클래스 보다는 속성에 해당하는 경우가 있다.

강좌번호, 강좌이름, 담당학과, 학점 수, 설명은 독자적인 실체클래스라기 보다는 강좌정보라는 실체클래스의 속성으로보는 것이 정확하다.

문제기술서 부분2

문제기술서의 명사가 실체클래스 보다는 연산에 해당하는 경우가 있다.관리, 등록, 수정, 조회, 삭제

문제기술서의 명사가 실체클래스 보다는 액터에 해당하는 경우가 있다.학생, 교수, 수업담당자, 학사담당자, 직원

실체클래스의 이름이 문제기술서에 명시적으로 언급되기 보다는 관련이 있는 속성들을 통합한 개념을 정의하는방식으로 도출될 수 있다.

사용자정보라는 용어는 없지만, 아이디와 암호를 통칭하여 사용자정보라는 이름의 실체클래스를 정의할 수 있다.

학적과의 학사관리담당자는 학생 및 교수 정보를 관리해야 한다. 즉, 새 학생/교수를 등록하거나 수정, 조회, 삭제를 지원해야 한다.

수업담당자는 새로운 강좌를 등록할 수 있다. 강좌에 대해서는 강좌번호, 강좌이름, 담당학과, 학점 수 및 강좌에 대한 간단한 설명이 제공될 수 있어야 한다.



- One Step Ahead -


4.1 실체클래스의 도출 방법 (2)문제기술서 부분3

명사 기반 클래스 도출 방법은 문제기술서 뿐만 아니라, 유스케이스명세서의 이벤트 흐름에도 적용하여 실체클래스를 파악하는 노력도 추가적으로 수행되어야 한다.

실체클래스의 특징은 그 값이 대부분 외부, 즉 사용자에 의해서 입력된다는 것이다.

사용자에 의해서 입력되는 정보에 대응되는 실체클래스를 정의하면 된다.

실체클래스 간에는 연관, 포함, 일반화 등의 관계가 정의될 수 있다.

실체클래스의 예

학생/교수/직원은 등록된 아이디와 암호를 입력하여 시스템에 로그인 할 수 있다.



- One Step Ahead -


4.2 실체클래스의 속성실체클래스의 속성은 실체클래스가 관리할 영속성이 있는 각 정보 항목에 해당한다.

실체클래스의 속성

학생은 시스템 사용자의 일종이므로 대응되는 학생정보 클래스와 사용자정보 클래스 사이에 일반화 관계를 적용할 수 있다.

대학정보시스템에서는 학번을 시스템의 아이디로 사용하며 이에 대한 변경은 불가능하다. 따라서 사용자정보 클래스에 있는 아이디 속성을 학번으로 간주해도 되므로 학생정보 클래스에 학번이 정의되지 않았다.

설계 활동에서 실체클래스는 관계형 DBMS를 이용하는 경우 테이블에 대응되며, 실체클래스의 속성은테이블의 열에 대응된다.

분석에서는 특정 언어와 관련된 타입을 줄 필요는 없다.

날짜, 숫자, 문자열, 화폐 등 정도로 구분하면 되며 명확한 경우 생략도 가능하다.



- One Step Ahead -


4.3 실체클래스의 연산 (1)실체클래스는 영속적인 정보에 대한 관리 기능을 담당한다.

즉, 영속적인 정보의 생성, 검색, 수정, 조회, 삭제 기능을 제공한다.따라서 실체클래스에는 생성, 검색, 삭제 연산 및 실체클래스의 각 속성에 대한 조회와 갱신을 지원하는 연산이 정의된다.



- One Step Ahead -


4.3 실체클래스의 연산 (2)(1) 생성 기능

각 실체클래스는 입력된 정보를 바탕으로 영속성이 있는 객체를 생성하기 위한 연산이 필요하며 다음과 같이 정의된다.

생성(속성1, 속성2, 속성n) : 실체클래스

각 실체클래스의 생성 연산은 실체클래스가 생성할 객체에 대한 각 데이터를 인자에받아서 해당 객체를 반환한다.

예를 들면, 학생정보 클래스의 ‘생성(학번, 학과, 이름, 주민등록번호):학생정보’ 연산은 학번, 학과, 이름, 주민등록번호를 인자로 받아서 새로운 학생정보 객체를 생성하고 생성된 학생정보 객체를 반환한다.

(2) 검색 기능

동일한 클래스로부터 생성된 많은 객체 중에서 주어진 값에 해당되는 객체를 구하는기능이 필요하다.

검색은 각 객체를 고유하게 구분할 수 있는 값을 이용하여 오직 하나의 객체를 구하는기능과 주어진 값에 해당하는 여러 개의 객체를 구하는 기능이 있을 수 있다.

예를 들어, 학생정보 클래스에서 ‘검색(학번):학생정보’ 연산은 학번에 일치되는 하나의 학생정보를 구하는 것이고, ‘검색(학번, 이름):학생정보목록’은 학번과 이름에 해당되는 학생정보의 목록을 구하는 것을 나타낸다.

두 번째 검색 연산에서 학번과 이름은 특정 값이 아니라 와일드 카드가 포함된 패턴으로 주어지는 것을 의미한다.



- One Step Ahead -


4.3 실체클래스의 연산 (3)(3) 삭제 기능

검색된 특정 객체를 삭제하는 기능이 필요하며, ‘삭제():Boolean’의 연산으로 표현된다.

삭제() 연산에 인자가 없는 것은 이미 다른 방법(생성 기능 및 검색 기능)에 의해서 구한 특정 객체를 삭제하는 것을 나타내기 때문이다.

예를 들면, 다음은 학번이 “S123”인 학생정보 객체를 구하여 삭제하는 코드를 보여준다.

(4) 속성 조회 기능

특정 객체의 속성 값을 조회하는 기능이 필요하다.

객체의 속성 값을 개별적으로 구하는 기능과 한번에 여러 개의 속성을 구하는 기능이 있을 수 있다.예를 들어

학생정보 클래스에서 ‘이름조회():이름’, ‘학과조회():학과’ 등의 연산은 학생정보 객체의 이름 속성과 학과 속성을 개별적으로 조회하는 기능을 제공하며,

‘조회():[이름, 학과, 주민등록번호]’ 연산은 학생정보 객체의 이름, 학과, 주민등록번호 속성을 한꺼번에 조회하는 기능을 나타낸다.

이 연산들에 인자가 없는 것은 삭제() 연산처럼 생성 기능 또는 검색 기능으로 구한 객체의 속성을 구하는 것을 가정하기 때문이다.

학생정보1 = 학생정보.검색(“S123”)학생정보1.삭제()

학생정보1 = 학생정보.검색(“S123”)학생정보1.삭제()



- One Step Ahead -


4.3 실체클래스의 연산 (4)(5) 속성 갱신 기능

특정 객체의 속성 값을 갱신하는 기능이 필요하다.객체의 속성 값을 개별적으로 갱신하는 기능과 한번에 여러 개의 속성을 갱신하는 기능이 있을 수있다.

예를 들어

학생정보 클래스에서 “이름갱신(새이름)”, “학과갱신(새학과)” 등의 연산은 학생정보 객체의 이름속성과 학과 속성을 개별적으로 갱신하는 기능을 제공하며,‘갱신(이름, 학과, 주민등록번호)’ 연산은 학생정보 객체의 이름, 학과, 주민등록번호 속성을 한꺼번에 갱신하는 기능을 나타낸다.

실체클래스는 단순히 자신이 관리하는 속성에 대한 조작만을 연산으로 제공해야 한다.예를 들어

사용자 정보 클래스에는 사용자가 입력한 암호의 정확성을 판단하는 연산을 정의해서는 안 된다.암호의 정확성에 대한 판단은 단순한 데이터의 접근이 아니기 때문에 실체클래스의 역할에 해당하지않는다.사용자가 입력한 암호가 정확한 지에 대한 판단은 비즈니스 로직에 해당하므로 실체클래스가 아니라, 제어클래스에서 제공되어야 하는 기능이다.

실체클래스의 행동 즉, 연산은 비즈니스 로직 관점이 아니라, 오직 데이터의 관리 측면에서정의되어야 한다.



- One Step Ahead -


4.4 실체클래스의 간단한 표현

실체클래스는 영속적인 정보에 대한 관리 기능을 제공하므로, 생성, 검색, 삭제, 조회, 갱신 등의 정해진 연산만을 가진다.

이들 연산들은 각 개별적인 실체클래스에 상관없이 모든 실체클래스에 동일하게정의된다.

실체클래스의 속성만 결정되면 연산은 속성으로부터 유추될 수 있다.따라서 실체클래스의 표현을 간소화해서 연산을 생략하고 속성만을 표현하여도 무방하다.



- One Step Ahead -


실체클래스의 도출 요약

실체클래스의 도출 방법

도출 방법 문제기술서와 유스케이스명세서를 바탕으로 분석하여 영속성이 필요한 정보를 추출한다.

클래스 이름 ‘~정보’

속성 영속성을 유지해야 하는 각 정보 항목을 속성으로 정의한다.

객체의 생성, 검색, 삭제 및 각 속성에 대한 조회와 갱신을 지원한다.

생성 생성(속성1, 속성2, …, 속성n): 실체클래스

검색검색(주요 키 속성): 실체클래스

검색(속성1, 속성2, …): 목록

삭제 삭제(): Boolean

조회“속성명” + 조회(): 속성명

조회(): [속성1, 속성2, …, 속성n]

갱신“속성명” + 갱신(새 속성 값)

갱신(속성1, 속성2, …, 속성n)

연산

4. 4. 실체클래스의실체클래스의 도출도출 요약요약 (10)(10)


- One Step Ahead -


제어클래스는 시스템이 제공해야 하는 실질적인 기능, 비즈니스 로직을 제공하는 클래스다.

사용자 인터페이스(UI 경계클래스), 외부시스템 인터페이스(SI 경계클래스), 데이터 접근 로직(실체클래스)을 제외한 모든 부분은 제어클래스의 책임에 해당한다.

수업담당자

교수

학생

학사담당자

시스템

b2

b1

b3

b4

수강료청구서발급시스템b5

UI 경계클래스 : b1, b2, b3, b4SI 경계클래스 : b5 실체클래스 : e1, e2, e3제어클래스 : c1, c2, c3, c4

데이터베이스

e1

e2

e3

c1

c2

c3

c4

5. 5. 제어클래스의제어클래스의 파악파악 (1)(1)


- One Step Ahead -


5.1 제어클래스의 도출 (1)각 유스케이스별로 제어클래스로 정의한다.

유스케이스는 시스템이 제공하는 독립적인 기능 단위이다.따라서 각 유스케이스의 기능을 별도의 제어클래스가 제공하는 것이 바람직하다.

유스케이스 별로 제어클래스가 정의되므로 유스케이스 이름을 그대로 제어클래스의 이름으로 주는 것이 바람직하다.

학생관리

control

강좌관리

control

학생관리

강좌관리



- One Step Ahead -


5.1 제어클래스의 도출 (2)유스케이스는 비교적 작지 않은 기능 단위이므로 유스케이스 당 하나의 제어클래스가 대부분의 경우에 적절하다.

관련성이 높은 작은 규모의 여러 유스케이스에 대해서는 하나의 제어클래스를 정의하고 이를 두 유스케이스들이 공유하는 것이 보다 바람직할 수 있다.

로그인 유스케이스, 암호변경 유스케이스, 로그아웃 유스케이스가 그 예에 해당한다.

각 유스케이스 별로 제어클래스를 정의하는 대신에 세 유스케이스의 기능을 모두포함하는 사용자관리 클래스를 정의하고, 세 유스케이스가 이 하나의 사용자관리제어클래스를 이용하는 것이 바람직하다.

로그인

암호변경로그아웃

사용자관리



- One Step Ahead -


5.2 제어클래스의 연산 (1)제어클래스가 제공하는 유스케이스의 기능, 즉 비즈니스 로직은 제어클래스의 연산으로 정의된다.

UI경계클래스는 관련된 제어클래스의 연산을 호출하면서 사용자가 입력한 값을 인자로 넘겨준다.

다른 유스케이스를 분석하는 과정에서 각 유스케이스에 대응되는 새로운 제어클래스가 도출되기도 하지만, 기존의 제어클래스에 연산이 추가될 수도 있다.

사용자관리 제어클래스의 연산 - 초안

+사용자확인()+암호변경()+접속종료()

+사용자확인(아이디, 암호) : Boolean+암호변경(아이디, 새암호) : Boolean+접속종료(아이디) : Boolean

사용자관리 제어클래스의 연산 - 구체화

+등록(아이디, 암호) : Boolean+삭제(아이디) : Boolean+사용자확인(아이디, 암호) : Boolean+암호변경(아이디, 새암호) : Boolean+접속종료(아이디) : Boolean

사용자관리 제어클래스의 연산 - 완성



- One Step Ahead -


5.2 제어클래스의 연산 (2)제어클래스의 연산에서 해당 유스케이스의 기능을 실제로 제공할 때 영속적인 데이터를 조작하는 부분은 실체클래스의 연산을 호출함으로써 이루어진다.

사용자관리 클래스와 사용자정보 클래스의 연산

사용자관리 제어클래스 사용자정보 실체클래스

등록() 생성()

사용자확인() 암호조회()

암호변경() 암호갱신()

삭제() 삭제()



- One Step Ahead -


5.3 제어클래스의 속성 (1)제어클래스는 UI경계클래스부터 제어클래스의 연산에 필요한 모든 데이터를 인자로 전달 받는다.

따라서 제어클래스 자체가 지속적으로 데이터를 유지하고 이를 제어클래스의 연산이이용하는 경우는 드물다.

클래스의 연산 사이에 공유할 데이터가 있으면 그 공유될 데이터는 클래스의 속성으로 정의될 것이다.그러나 제어클래스의 연산들은 독립적인 유스케이스들의 기능을 각각 구현하고있기 때문에 연산들 사이에 공유할 데이터가 있는 경우는 드물다.

따라서 대부분의 경우에 제어클래스에는 속성이 정의될 필요가 없다.단, 여러 화면에서 입력한 정보를 제어클래스에서 각각 기억했다가 마지막 화면에서비즈니스 로직을 수행하는 경우에는 이전 화면에서 입력한 정보를 제어클래스가 저장할 필요가 있을 수 있다.

예를 들어, 학생정보를 등록할 때 화면1에서는 학번을 입력받고, 다음 화면2에서는 주민등록번호를 입력받고, 다음 화면3에서는 이름과 학과를 입력받고, 다음 화면4에서 ‘등록’ 버튼을 눌러서 학생을 등록하는 상황이 있다고 가정하자

화면4에서 학생정보를 등록하기 위해서는 이전 화면들(화면1, 화면2, 화면3)에서 입력받은 정보(학번, 주민등록번호, 이름, 학과)를 제어클래스에 속성으로 저장했다가화면4에서 저장된 속성 값을 이용해서 학생을 등록할 수 있다.그러나 이 같은 방식의 사용자 인터페이스는 현재 구축되는 시스템에서 일반적으로 채택되지 않는 방식이다.

또한, 저장할 정보가 있다 하더라도 제어클래스에 직접 저장하는 방식보다는 다른 공간(세션변수 또는 자바빈 등)을 이용하는 것이 일반적이다.따라서 제어클래스에서는 속성을 정의하는 경우가 매우 드물다고 볼 수 있다.



- One Step Ahead -


유스케이스를 바탕으로 제어클래스를 도출하는 방법을 요약하면 다음과 같다.

제어클래스의 도출 방법

도출 단위각 유스케이스 마다 별도의 제어클래스 정의

단, 작으면서 관련성이 높은 유스케이스들은 하나의 제어클래스를 공유할 수 있다.

클래스이름 유스케이스와 동일한 이름을 사용한다.

필요한 모든 데이터는 경계클래스로부터 인자를 받고, 제어클래스의 연산들 사이에는 공유할 데이터가 없으므로 속성은 정의되지 않는다.

유스케이스가 나타내는 기능에 대응되며, 경계클래스로부터 호출된다.

이름

접근권한

반환 타입

인자

속성

데이터 관점이 아니라, 사용자 즉 경계클래스의 관점에서 명명해야 한다.

공용

Boolean 등 연산 별로 적절한 타입 사용

사용자가 화면을 통해서 입력한 값이 인자로 들어온다.

연산

5. 5. 제어클래스의제어클래스의 도출도출 요약요약 (7)(7)


- One Step Ahead -


로그인 유스케이스로부터 도출된 경계클래스, 제어클래스, 실체클래스를 클래스다이어그램에 표현하면 다음과 같다.

로그인 유스케이스의 분석 클래스 - Together

5. 5. 로그인로그인 유스케이스의유스케이스의 분석분석 클래스클래스 요약요약 (8)(8)


- One Step Ahead -


하나의 유스케이스가 나타내는 시스템의 기능중에서 외부 시스템과의 연결 로직은 경계클래스, 비즈니스 로직은 제어클래스, 데이터 접근 로직은 실체클래스가 전담한다.

따라서 하나의 유스케이스에 대하여 세 가지 유형의 분석 클래스가 도출된다.

로그인 유스케이스의 분석 클래스 요약

유스케이스 별로 사용자 인터페이스를 위하여 사용되는 각 화면마다 UI 경계클래스를 정의한다.개발하는 시스템과 연결되는 외부 시스템 마다 하나의 SI 경계클래스를 정의한다.

제어클래스는 유스케이스의 비즈니스 로직을 전담하며 유스케이스 마다 별도의 제어클래스를 정의하는 것이 일반적이다.

실체클래스는 영속성이 필요한 정보 마다 정의되며, 논리적인 수준의 개체(entity) 또는 테이블과 유사하다.

일반적으로 유스케이스를 분석할 때 마다 새로운 UI 경계클래스와 제어클래스가 정의된다.각 유스케이스별로 사용되는 화면과 비즈니스 로직이 다르기 때문이다.

반면에, 하나의 영속성이 있는 데이터가 여러 유스케이스에서 이용되거나 조작될 수 있으므로, 실체클래스는 여러 유스케이스에서 공통적으로 이용될 수 있다.

마찬가지로 SI 경계클래스도 여러 개의 유스케이스에서 공통으로 이용될 수 있다.

구분 클래스 이름 설명

로그인 화면

학생메인화면

교수메인화면

학사관리메인화면

수업관리메인화면

제어클래스 사용자관리 사용자 암호 확인 등의 비즈니스 로직을 전담

실체클래스 사용자정보 사용자 정보(아이디, 암호)에 대한 영속성을 전담

시스템 사용자(학생, 교수, 수업담당자, 학사담당자)를 위한

프리젠테이션 로직을 전담경계클래스

5. 5. 로그인로그인 유스케이스의유스케이스의 분석분석 클래스클래스 요약요약 (9)(9)

3. 분석 클래스간의 관계 파악


- One Step Ahead -


UML에서는 클래스 간에 연관, 집합, 일반화, 의존의 네 가지 관계가 정의된다.

분석 수준에서는 이들 중에서 의존을 제외한 연관, 집합, 일반화 관계가 분석클래스들 사이에 정의된다.

1. 1. 개요개요


- One Step Ahead -


연관관계의 의미

연관(Association) 관계는 클래스 사이의 가장 일반적인 관계로 한 클래스가 다른 클래스를 인지(acquaintance)함을 의미한다.

영업담당자 클래스의 계약설명() 연산은 영업담당자가 고객에게 계약 사항에 대한 설명을 하는 행위를나타낸다.

고객 클래스의 서명(계약서) 연산은 고객이 계약서에 서명하는 행위를 나타낸다.

연관 관계의 용도

연관 관계는 상대 클래스의 객체에게 메시지를 전달할 때 사용되는 통로의 역할을 한다.

즉, 연관 관계를 맺고 있는 클래스 사이에 메시지가 전송될 수 있다.

영업담당자

+ 계약설명()

고객

+ 서명(계약서)

영업담당자 클래스와 고객 클래스 간의 연관 관계영업담당자와 고객과의 관계

: 고객: 영업담당자

계약설명()

서명(계약서)

2. 2. 연관연관 관계관계 (1)(1)


- One Step Ahead -


연관 관계의 방향성(navigability)화살표가 없는 실선으로 표현된 연관 관계는 양방향을 가진다.

즉, 두 클래스가 서로 상대 클래스를 인지하는 것이다.

연관 관계의 방향성은 실선의 한쪽 끝에 화살표로 표시된다.

연관의 방향성은 모델링하려고 하는 실제 대상을 그대로 표현하면 된다.실제 생활에서는 영업담당자도 자신의 고객을 알고, 고객도 영업담당자를 알고 있으므로 양방향 연관으로 표현하는 것이 정확하다.

연관 관계의 소스코드

클래스는 Java, C# 과 같은 객체지향 언어에서 직접적으로 지원되므로, 클래스, 속성, 연산 등이 어떻게 Java, C# 언어로 표현되는 지는 쉽게 이해할 수 있다.

클래스 간의 연관 관계는 객체지향 언어에서 직접적으로 지원하는 개념이 아니므로 객체지향 언어가 지원하는 개념으로 변환되어 표현되어야 한다.

클래스 간의 연관 관계는 객체지향 언어에서 상대 클래스를 가리키는 필드로써 구현된다.

2. 2. 연관연관 관계관계 (2)(2)


- One Step Ahead -


연관 관계의 구현 예

영업담당자

+ 계약설명()

고객

+ 서명(계약서)

영업담당자

+ 계약설명()

고객

+ 서명(계약서)

영업담당자

+ 계약설명()

고객

+ 서명(계약서)

(1)class 영업담당자 {

private 고객 the_고객;public 계약설명();

}

class 고객 {public 서명(계약서);

}


public 계약설명();}

class 고객 {private 영업담당자 the_영업담당자;public 서명(계약서);

}


private 고객 the_고객;public 계약설명();

}

class 고객 {private 영업담당자 the_영업담당자;public 서명(계약서);

}

2. 2. 연관연관 관계관계 (3)(3)


- One Step Ahead -


연관을 나타내는 속성의 이름

Rose‘the+상대 클래스의 이름’을 사용한다.

즉, ‘the고객’, ‘the영업담당자’ 이름을 사용한다.

Together‘lnk+상대 클래스의 이름’을 사용한다.

즉, ‘lnk고객’, ‘lnk영업담당자’ 이름을 사용한다.

연관 관계의 표현(Together)Together에서는 하나의 연관 관계에 양방향성을 부여하지 못하며, 오직 한 방향만을 표현한다.

따라서 양방향의 연관을 표현할 때는 반대 방향의 연관 관계를 추가한다.

2. 2. 연관연관 관계관계 (4)(4)


- One Step Ahead -


1. 로그인 유스케이스 (1)로그인화면 클래스에서 사용자관리 클래스로의 연관

로그인 유스케이스에서 로그인화면 UI 경계클래스에서 사용자가 입력한 아이디와암호를 확인하기 위해서 사용자관리 제어클래스의 사용자확인 연산을 호출한다.

이는 로그인화면 클래스와 사용자관리 클래스 사이에 연관 관계가 있음을 의미한다.

그리고 사용자관리 클래스가 로그인화면 클래스에 메시지를 보내지는 않는다.

따라서 로그인화면 클래스에서 사용자관리 클래스로 연관은 단방향이다.

경계클래스에서 제어클래스로의 연관

<<boundary>>로그인화면


<<in>> - 아이디<<in>> - 암호

<<in>> - 아이디<<in>> - 암호

+ 로그인()+ 원래대로()


<<control>>사용자관리


+ 등록(아이디, 암호) : Boolean+ 사용자확인(아이디, 암호) : Boolean+ 암호변경(아이디, 새암호) : Boolean+ 삭제(아이디) : Boolean+ 접속종료(아이디) : Boolean


3. 3. 분석클래스분석클래스 간의간의 연관연관 관계관계 도출도출 (1)(1)


- One Step Ahead -


1. 로그인 유스케이스 (2)사용자관리 클래스에서 사용자정보 클래스로의 연관

사용자관리 제어클래스는 아이디에 해당하는 사용자 정보를 구하여 정확한 암호를얻어야 한다.

이는 사용자관리 클래스가 사용자정보 클래스와 연관이 있음을 의미한다.

사용자정보 클래스는 단순히 영속적인 정보(데이터)에 대한 조작만 하므로 사용자관리 클래스의 연산을 호출하지는 않는다.

따라서 사용자관리 클래스로부터 사용자정보 클래스로의 연관은 단방향이다.

제어클래스에서 실체클래스로의 연관



<<in>> - 아이디<<in>> - 암호

<<in>> - 아이디<<in>> - 암호







<<entity>>사용자정보


- 아이디- 암호

- 아이디- 암호

+ 생성(아이디, 암호) : 사용자정보+ 삭제() : Boolean+ 암호조회() : 암호+ 암호갱신(새암호)+ 검색(아이디) : 사용자정보




- One Step Ahead -


1. 로그인 유스케이스 (3)로그인화면 클래스와 사용자별 메인화면 클래스와의 연관

로그인화면 클래스는 사용자관리 클래스를 통해서아이디와 암호가 정확한 것으로 판단되면, 사용자 별 메인 화면을 보여준다.

따라서 로그인화면 클래스에서 각 사용자 별메인 화면으로의 연관이 필요하다.

로그인 유스케이스의 분석클래스 간의 관계



<<in>> - 아이디<<in>> - 암호

<<in>> - 아이디<<in>> - 암호









- 아이디- 암호

- 아이디- 암호





- One Step Ahead -


1. 로그인 유스케이스 (3)로그인화면 클래스와 사용자별 메인화면 클래스와의 연관

로그인화면 클래스와 사용자별 메인화면 클래스 사이의 연관이 양방향인것은 로그인이 성공한 후에 각 메인 화면으로 전화되는 것 뿐만 아니라, 각 메인 화면에서 로그아웃을 하면, 다시 로그인 화면으로 전환되기 때문이다.

그리고 사용자 별 메인 화면에서는 암호변경을 위해서 사용자관리 클래스의 암호변경 연산을 호출할 필요가 있다.

그러므로 학생메인화면, 교수메인화면, 수업관리메인화면, 학사관리메인화면에서 사용자관리 클래스로의 연관이 필요하다.



- One Step Ahead -


2. 암호변경 유스케이스암호변경화면 클래스에서 사용자관리 클래스로의 연관 관계는 사용자관리 클래스의 암호변경() 연산을호출할 때 암호변경화면 객체와 사용자관리 객체 간의 메시지 전달 통로 역할을 한다.

사용자관리 클래스에서 사용자정보 클래스로의 연관은 로그인 유스케이스에서와 마찬가지로 사용자관리 객체가 사용자 정보 객체에게 메시지를 보낼 때 사용된다.

암호변경화면 클래스에서 암호변경결과화면 사이의 연관 관계는 암호변경화면 클래스가 사용자관리 클래스의 암호변경() 연산을 호출한 결과를 보여주기 위해서 사용되는 화면으로의 전환을 나타낸다.

암호변경 유스케이스의 분석클래스 간의 관계





<<boundary>>암호변경화면

<<boundary>>암호변경화면

<<in>> - 새암호1<<in>> - 새암호2

<<in>> - 새암호1<<in>> - 새암호2

+ 변경()+ 변경()



- 아이디- 암호

- 아이디- 암호



<<boundary>>암호변경결과화면

<<boundary>>암호변경결과화면



- One Step Ahead -


분석클래스를 특정 기능을 전문적으로 담당하는 경계클래스, 제어클래스, 실체클래스로 분류함으로 인해서 클래스 간의 연관관계는 일정한 형태로만 발생한다.

예를 들어, 제어클래스에서 실체클래스로의 연관은 가능하지만 반대로 실체클래스에서 제어클래스로의 연관은 허용되지 않는다.

분석클래스 간의 연관관계

A B

A

A

A

B B B

(1) (2) (3)

(4) (5) (6)

(7) (8) (9)

4. 4. 분석클래스분석클래스 간의간의 연관연관 관계관계 요약요약 (1)(1)


- One Step Ahead -


(1) 경계클래스에서 경계클래스로의 연관

경계클래스 A에서 경계클래스 B로의 연관은 경계클래스 A가 표현하는 화면에서 경계클래스 B가 표현하는 화면으로의 전환을 의미한다.

로그인화면 클래스에서 각 메인화면 클래스로의 연관이 이에 해당한다. 암호변경화면 클래스에서 암호변경결과화면 클래스로의 연관도 이에 해당한다.

(2) 경계클래스에서 제어클래스로의 연관

프리젠테이션 로직 만을 전담하는 경계클래스 A가 사용자가 원하는 비즈니스 로직을 제공하기 위하여제어클래스 B를 이용하는 것을 의미한다.

로그인화면 클래스 및 각 메인화면 클래스에서 사용자관리 클래스로의 연관과, 암호변경화면 클래스에서 사용자관리 클래스로의 연관이 이에 해당한다.

(3) 경계클래스에서 실체클래스로의 연관

경계클래스는 항상 제어클래스를 통하여 비즈니스 로직을 제공한다. 따라서 경계클래스는 직접 실체클래스를 이용하여 비즈니스 로직과 관련된 영속적인 데이터를 조작할 수 없다. 그러므로 경계클래스에서실체클래스로의 연관은 존재하지 않는다.

경계클래스에서는 사용자정보 실체클래스와 직접적인 연관을 맺지 않으며, 연관 관계가 있는 사용자관리 제어클래스를 통하여 간접적으로 사용자정보 클래스에 접근한다.

(4) 제어클래스에서 경계클래스로의 연관

비즈니스 로직 만을 전담하는 제어클래스에서는 프리젠테이션 로직을 담당하는 경계클래스에 접근하지않는다.

화면의 전환은 경계클래스 간에만 발생하며, 제어클래스는 경계클래스에 접근하지 않는다.

따라서 제어클래스에서 경계클래스로의 연관은 이용되지 않는다.



- One Step Ahead -


(5) 제어클래스에서 제어클래스로의 연관

제어클래스 사이의 연관은 제어클래스의 기능을 다른 제어클래스에 분산시키고 이를 이용하는 상황을의미한다.

포함 관계에 있는 유스케이스의 비즈니스 로직을 제어클래스로 대응시킬 때 나타날 수 있다.

A유스케이스와 B유스케이스가 C유스케이스를 공통으로 사용하고 있을 때 각 유스케이스에 사용되는A유스케이스, B유스케이스, C유스케이스 제어클래스 간의 연관 관계를 보여준다.

A유스케이스와 B유스케이스가 C유스케이스의 기능을 이용한다.따라서 이 관계가 제어클래스에도 그대로 반영되어 A유스케이스 제어클래스와 B유스케이스 제어클래스에서 C유스케이스 제어클래스로 연관이 정의될 수 있다.

A유스케이스

B유스케이스

C유스케이스

<<include>>

<<include>>

<<control>>A유스케이스

<<control>>B유스케이스

<<control>>C유스케이스



- One Step Ahead -


(6) 제어클래스에서 실체클래스로의 연관

정보시스템에서 제어클래스가 담고 있는 비즈니스 로직에는 영속적인 데이터에 대한 처리가 큰 비중을차지한다.

실체클래스는 영속적인 데이터에 대한 처리를 전담하는 클래스이므로, 제어클래스에서 실체클래스로의연관은 해당 제어클래스가 영속적인 데이터의 처리는 실체클래스가 제공하는 기능을 이용하는 것을 의미한다.

사용자관리 제어클래스에서 사용자정보 실체클래스로의 연관이 이에 해당된다.

(7) 실체클래스에서 경계클래스로의 연관

실체클래스는 제어클래스가 요청할 때 수동적으로 영속적인 데이터에 대한 처리만을 수행한다.데이터베이스에 행을 추가하거나, 주어진 조건에 맞는 행들을 검색하거나 한다.

실체클래스는 경계클래스가 나타내는 프리젠테이션 로직을 언급하지 않으므로, 실체클래스에서 경계클래스로의연관은 사용되지 않는다.

(8) 실체클래스에서 제어클래스로의 연관

실체클래스는 제어클래스가 요청한 데이터 처리만을 수행할 수 있으며, 반대로 제어클래스에게 비즈니스 로직의 수행을 요청하지 않는다.

따라서 실체클래스에서 제어클래스로의 연관은 사용되지 않는다.

(9) 실체클래스에서 실체클래스로의 연관

실체클래스 간에는 연관 관계가 사용될 수 있다.



- One Step Ahead -


1. 연관의 이름과 역할연관 관계는 한 클래스가 다른 클래스를 인지하는 것을 나타내므로 매우 광범위한 의미를 가진다.

그러므로, 두 클래스가 어떤 연관이 있는 지에 대해서 명확한 의미를 알 수 없는 경우가 있을 수 있다.

따라서, 연관 관계의 의미를 보다 명확하게 표현해야 한다.

예를 들어, 아래의 클래스 다이어그램은 사람과 도서의 연관이 두 가지 중에서 어떤 것을 나타내는지를알 수 없다.

사람이 도서를 대출한다. 즉, 사람은 학생 또는 교수 등을 나타낸다.

사람이 도서를 관리한다. 즉, 사서가 도서의 등록/삭제 등을 한다.

연관의 이름은 실선 위에 표시되는 동사 또는 동사구로, 두 클래스 간의 관계를 구체화시키는 방법이다.역할의 이름은 연관 관계를 속성으로 표현할 때 상대 객체에 대한 이름으로 사용된다.

역할이 지정된 ‘-사서’의 ‘-’는 연관이 속성으로 표현될 때 해당 속성에 대한 접근 권한을 지정하는 것이다.

클래스의 속성을 ‘+’, ‘-’, ‘#’으로 표현하여 각각 공용, 전용, 보호임을 나타내는 것과 동일하다.

사람 도서

모호한 연관 관계

사람 도서관리한다 사람 도서사서

(1) 연관 이름의 사용 (2) 역할의 사용

class 사람 {private 도서 the_도서;

}

class 도서 {private 사람 사서;

}

5. 5. 연관연관 관계관계 : : 고급고급 (1)(1)


- One Step Ahead -


2. 복수 연관 (1)복수 연관 관계의 의미

동일한 두 클래스 사이에 두 개 이상의 연관 관계가 맺어지는 것을 복수 연관(multiple association)이라고 한다.

복수 연관은 두 클래스가 명확하게 다른 의미의 관계를 맺는 경우에 사용될 수 있다.

복수 연관 관계의 신중한 적용복수 연관은 사용 시 연관 관계가 정확하게 사용되고 있는 지에 대해서 의문을 가지는 것이 좋다.

적지 않은 경우에 복수 연관 관계를 사용하는 것 보다는 다른 방식으로 모델링하는 것이 보다 바람직한 경우가 있다.

사람 도서

관리한다

대출한다

사람 도서

관리한다

대출한다 대출자

사서

도서

복수 연관 사용의 대안

5. 5. 연관연관 관계관계 : : 고급고급 (2)(2)


- One Step Ahead -


2. 복수 연관 (2)적절한 복수 연관 관계의 사용

복수 연관 관계가 항상 부적절한 것은 아니다.

이 클래스 다이어그램은 도서를 등록하는 사서와 도서를 폐기하는 사서에 대한 정보를 별도의 연관 관계로 표현한 것이다.

적절한 복수 연관의 사용

대출자

사서

도서

등록자

폐기자

복수 연관 관계의 속성

class 도서 {private 사서등록자;private 사서폐기자;

}

5. 5. 연관연관 관계관계 : : 고급고급 (3)(3)


- One Step Ahead -


3. 다중성 (1)다중성(multiplicity)은 연관 관계가 있는 두 클래스가 있을 때 실제로 연관을가지는 객체의 수를 나타낸다.

다중성은 연관 관계의 양쪽 끝에 지정된다.

도서 클래스와 대출자 클래스 사이의 연관 관계에서 대출자 클래스 쪽의 0..1은 하나의 도서 객체가 한명의 대출자에게 대출되거나 또는 아직 대출되지 않음을 나타낸다. 그리고 도서 클래스 쪽의 0..*은 한 대출자가 한 권의 도서도 대출하지 않거나, 많은수의 도서를 대출할 수 있음을 나타낸다.

사서 클래스와 도서 클래스 사이의 각 연관 관계에서 도서 클래스 쪽에 0..*로 표시된다중성은 한 명의 사서가 여러 권의 도서를 등록하고 폐기하는 것을 나타낸다.

다중성은 주로 실체클래스들 사이에서 발생하며, 경계클래스와 실체클래스 및 분석클래스 사이에는 발생하지 않는다.

연관의 다중성

대출자

사서

도서

등록자

폐기자

0..*

0..*

0..* 0..1

5. 5. 연관연관 관계관계 : : 고급고급 (4)(4)


- One Step Ahead -


3. 다중성 (2)다중성 표현의 예

다중성은 연관 관계가 있는 클래스의 객체 수에 대한 제약이다.

도서1 객체는 한 명의 대출자(대출자1) 객체와 연관되며, 한 명의 대출자(대출자2) 객체는 두 개의 도서 객체(도서2, 도서3)와 연관된다. 그리고 도서4 객체는 아무 대출자 객체와 연관을 맺지않고 있다.

다중성 표현 의미

1 한 객체가 연관 된다. 표시하지 않아도 되는 기본값이다.

0..1 0개 또는 1개의 객체가 연관된다.

0..* 0개 또는 많은 수의 객체가 연관된다.

* 0..*와 동일

1..* 1개 이상의 객체가 연관된다.

3..5 3에서 5개까지의 객체가 연관된다.

3..5, 7, 9 3개에서 5개까지 또는 7개 또는 9개의 객체가 연관된다.

도서1 : 도서

도서2 : 도서

도서3 : 도서

도서4 : 도서

대출자1 : 대출자

대출자2 : 대출자

5. 5. 연관연관 관계관계 : : 고급고급 (5)(5)


- One Step Ahead -


1. 집합 관계의 표현

집합(aggregation) 관계는 보다 구체적인 의미를 가지는 연관 관계로 ‘한 객체가 다른 객체를 포함하는 것’을 나타낸다.

집합 관계는 ‘전체’와 ‘부분’간의 관계로써 ‘전체’쪽에 마름모의 사각형을 표시한다.

집합 관계는 연관 관계의 일종이므로 연관 관계와 마찬가지로 다중성을 표현할 수 있다.

집합 관계와 포함 관계

컴퓨터

본체 모니터 마우스 키보드 프린터

자동차 바퀴4

집합 관계의 다중성

표현 법

용어 포함(composition 또는 composite aggregation) 집합(aggregation 또는 shared aggregation)

의미 부분 객체는 전체 객체에 전속됨 부분 객체에 여러 전체 객체에 의해서 공유될 수 있음

6. 6. 집합집합 관계관계 (1)(1)


- One Step Ahead -


2. 포함관계, 집합 관계, 연관 관계의 구분 (1)집합 관계는 연관 관계의 일종이므로 때로는 집합 관계를 적용할 지 연관 관계를 적용할 지애매한 경우가 적지 않다.

포함 관계, 집합 관계, 연관 관계

포함 관계 vs 집합 관계 및 연관 관계의 구분

포함 관계의 경우에는 부분 객체가 전체 객체에 완전히 전속되기 때문에 부분 객체가 전체 객체로부터 분리되어 독립적으로 존재하는 것이 불가능하다.

반면에, 집합 관계와 연관 관계의 각 객체는 독립적인 존재가 가능하다.

기준 포함 집합 연관

부분 객체의 독립적인 존재 불가능 가능

부분(part)의 의미 적용 가능 불가능

대칭성 비대칭성 가능

회사

1..*1..*

0..*0..*

부서

직원

사무실

6. 6. 집합집합 관계관계 (2)(2)


- One Step Ahead -


2. 포함관계, 집합 관계, 연관 관계의 구분 (2)포함 관계 및 집합 관계 vs 연관 관계

포함 관계 및 집합 관계는 “한 클래스의 객체가 다른 클래스의 객체의 부분이다” 또는“한 클래스의 객체는 다른 클래스의 객체로 구성된다”의 의미가 적용 가능하다.

연관 관계는 불가능하다.

예를 들어, 회사는 부서로 구성된다.

회사는 사무실을 포함한다.

직원은 부서에 속한다. 또는 부서는 직원으로 구성된다.

반면에, 부서 클래스와 사무실 클래스 사이에는 전체-부분의 의미를 부여하기가 어렵기 때문에, 연관 관계로 표현하는 것이 적절하다.

전체와 부분의 특성상 포함 관계와 집합 관계는 비대칭적(asymmetric)이다. 즉, 한 클래스의 객체가 다른 클래스의 객체의 부분이라면, 그 반대는 불가능하다.

반면에, 연관 관계의 클래스는 양방향의 관계가 가능하다.

예를 들어, 부서가 회사에 속한다면, 회사는 부서에 속할 수 없다.

마찬가지로, 사무실이 회사의 구성 요소라면, 회사는 사무실의 구성요소가 아니다.

그리고 직원은 부서에 속하지만, 부서는 직원에 속하지 않는다.

반면에, 부서는 사무실을 사용하고, 반대로 사무실에는 부서가 배치된다.

즉, 대칭적인 해석이 가능하다.

6. 6. 집합집합 관계관계 (3)(3)


- One Step Ahead -


일반화 관계는 ‘Is A’ 또는 ‘Is Kind Of’ 의미가 있는 두 클래스 사이에 사용한다.

즉, “한 클래스가 다른 클래스다” 또는 “한 클래스가 다른 클래스의 일종이다”라는 명제가 참이 되는 두 클래스 사이에는 일반화 관계가 성립된다.

“대출자는 사람이다” 그리고 “사서는 사람이다” 라는 명제가 성립되므로 세 클래스사이의 일반화 관계는 바람직하다.

이 클래스 다이어그램에서 보다 일반적인 개념을 나타내는 사람 클래스를 상위클래스(superclass)라고 부르며, 보다 구체적인 개념을 나타내는 대출자 클래스와 사서클래스는 사람 클래스의 하위클래스(subclass)라고 부른다.

상위클래스의 각 속성과 연산은 모든 하위클래스에 상속된다.따라서 항상 상위클래스에는 모든 하위클래스에 공통적인 속성과 연산만을 정의해야 한다.

사람

- 이름- 주소- 연락처

대출자

- 총대출도서수

사서

- 담당업무

사람, 대출자, 사서 클래스 간의 일반화 관계

7. 7. 일반화일반화 관계관계

4. 분석 유스케이스의 실현


- One Step Ahead -


분석 활동을 정확하게 수행하여 올바른 분석 클래스를 도출하는 것은 사용자의 요구사항을 충족시킬 수 있는 시스템을 개발하기 위한 필수적인 조건이다.

개발을 더 진행하여 설계 활동을 수행하기 전에 분석 클래스들이 충분하고 정확하게 도출되어 시스템의 기능을 정확하게 제공될 수 있는 지에 대한 확인이필요하다.

즉, 각 유스케이스의 기능을 실현할 수 있는 분석 클래스가 모두 도출되었고, 각분석 클래스의 속성과 연산은 충분히 정의되었는지, 분석 클래스 간의 관계가 모두 정의되었는지에 대한 점검이 필요하다.

분석 객체 모델이 정확하게 작성되었는지를 점검할 수 있는 체계적인 방법으로 유스케이스 실현(use case realization)이 있다.

1. 1. 개요개요


- One Step Ahead -


2. 2. 유스케이스유스케이스 실현실현 (1)(1)유스케이스 실현은 유스케이스로 기술된 시스템의 기능이 어떻게 실현될 수 있는 지를 도출된 클래스들을 바탕으로 정의하는 기법이다.

유스케이스 : 시스템이 제공해야 하는 기능에 대한 명세

분석클래스 : 이 기능을 실제로 제공해야 하는 주체

분석클래스가 제공할 수 있는 기능은 연산으로 정의되어 있다.

따라서 각 분석클래스의 연산을 조합하여 유스케이스의 기능을 제공할 수 있는 지를 파악해야 한다.

세 가지 종류의 분석클래스를 살펴보면, 하나의 유스케이스의 기능을 완료하기 위해서는 세 종류의 분석클래스들이 협력해야 하는 것을 알 수 있다.

하나의 유스케이스에는 사용자 인터페이스, 비즈니스 로직, 데이터 접근과 외부 시스템 접근이 모두 포함되어 있다.

경계클래스 – 사용자 인터페이스 또는 외부 시스템 인터페이스만 전담

제어클래스 – 비즈니스 로직만을 담당

실제클래스 – 데이터에 대한 관리만을 담당

따라서 유스케이스의 기능을 제공하기 위해서는 세 가지 클래스 간의 협력이 필요하다.

협력은, 다른 클래스가 제공하는 기능을 이용하는 것이다.즉, UI 경계클래스는 사용자가 요청한 기능을 제공하기 위해서 제어클래스의 기능을 이용하고, 제어클래스는 데이터 조작을 위해서 실체클래스를 이용한다.

로그인 유스케이스에 대한 분석클래스의 협력 과정1. 로그인화면 클래스는 사용자가 아이디와 암호를 입력할 수 있도록 텍스트 상자와 로그인을 위해서 클릭할 로그인 버튼을 화면에 보여준다.

2. 사용자가 아이디와 암호를 입력하고 로그인 버튼을 누른다.

3. 로그인화면 클래스는 아이디와 암호를 인자로 전달하면서 사용자괸리 클래스의 사용자확인() 연산을 호출한다.

4. 사용자관리 클래스의 사용자확인() 연산은 전달 받은 아이디의 정확한 암호를 사용자정보 클래스의 암호조회() 연산을 이용해서 구한다.

5. 사용자관리 클래스의 사용자확인() 연산은 로그인화면 클래스로부터 전달 받은 암호와 사용자정보 클래스로부터 구한 정확한 암호를 비교하고 그 결과를 로그인화면 클래스에 반환한다.

6. 로그인화면 클래스는 두 암호가 일치하면, 사용자의 종류에 따라서 사용자 별 메인 화면을 보여주고, 그렇지 않으면 아이디/암호가 정확하지 않음을 메시지로보여준다.


- One Step Ahead -


2. 2. 유스케이스유스케이스 실현실현 (2)(2)로그인 유스케이스의 실현 모델

위와 같이 유스케이스의 기능을 실현하기 위하여 필요한 분석 객체들의 상호작용을 시퀀스 다이어그램으로 표현한 산출물을 분석 유스케이스 실현 모델이라고 부른다.


- One Step Ahead -


암호변경 유스케이스의 실현 모델

2. 2. 유스케이스유스케이스 실현실현 (3)(3)


- One Step Ahead -


시퀀스 다이어그램은 UML 다이어그램의 하나로 객체들 간의 메시지 전송을시간적인 순서로 표현하는데 효과적이다.

1. 객체

시퀀스 다이어그램의 상단에서는 객체들이 나열된다. 클래스가 아니라, 객체인점에 주목해야 한다.

즉, 실제로 메시지를 보내거나 받을 수 있는 것은 객체들을 추상화시킨 클래스가 아니라, 실제로 존재하는 실체인 객체이기 때문이다.

유스케이스 기능 수행의 시작은 항상 엑터가 발생시킨 이벤트에 의한다. 따라서 시퀀스 다이어그램이 표현하고 있는 유스케이스의 수행을 시작시킨 액터가 항상 가장 좌측에 배치된다.

각 객체마다 세로 방향으로 그려진 점선은 생명선(lifeline)이라고 불린다.생명선은 해당 객체의 존재 기간을 표시한다.

각 객체가 상단에 행으로 배치되고 시퀀스 다이어그램의 최하단까지 점선이 그려져 있는 것은 이 시퀀스 다이어그램에 표시된 모든 객체가 동일한 시간 동안 존재하는 것을 나타낸다.

시퀀스 다이어그램의 중간에 새롭게 객체가 생성되거나 삭제되는 경우도 있다.

3. 3. 시퀀스시퀀스 다이어그램다이어그램 (1)(1)


- One Step Ahead -


2. 메시지시퀀스 다이어그램에서는 한 객체가 다른 객체에서 제공되는 연산을 호출하는 것을 메시지(message)로 표현한다.

메시지는 전송 객체에서 수신 객체를 향하는 화살표로 표시되며, 호출된 연산이 화살표 위에 표시된다.

예를 들면, 1번 메시지 b1(arg1, arg2)은 A 클래스의 객체가 메시지 전송 객체이며, B 클래스의객체가 수신 객체이고, B 클래스의 객체에게 b1(arg1, arg2) 연산을 호출하는 것을 나타낸다.

c2() 메시지는 다른 객체가 아니라 동일한 객체에게 메시지가 전송되고 있다. 이 메시지와 같이동일 객체로 전송되는 메시지를 반사 메시지(reflexive message)라고 부른다.

시퀀스 다이어그램에서의 메시지 전송



- One Step Ahead -


3. 클래스의 연산 도출

메시지 수신 객체는 해당 메시지에 대응되는 연산을 정의함으로써 수신된 메시지에 대한 적절한 처리를 책임져야 한다.

메시지 수신 객체가 메시지를 수신한 것은 메시지 전송 객체가 수신 객체에게 어떤 기능을 제공해 달라고 요청하는 것이다.

따라서 메시지 수신 객체는 요청 받은 기능을 수행하는 연산을 반드시 정의해야 한다.

예를 들면, B 객체가 b1(arg1, arg2) 메시지를 수신하는 것은 b1(arg1, arg2) 연산이 B 클래스에 있어야 함을 뜻한다.

따라서 메시지에 대응되는 연산이 반드시 메시지 수신 객체에 있어야 한다는 규칙을바탕으로 하면 클래스의 연산을 유추할 수 있다.

시퀀스 다이어그램에서 클래스 B의 객체는 b1(arg1, arg2)메시지와 b2() 메시지를수신한다.

따라서 클래스 B에는 메시지에 대응되는 연산이 각각 정의되어 있어야 한다.

마찬가지로 클래스 C에는 c1() 연산과 c2() 연산이 정의되어 있다.

c2() 메시지는 다른 클래스의 객체로부터 호출되지 않고 객체 자신만이 호출하고 있으므로(즉, 반사 메시지이므로), 전용 연산으로 지정되어 있다.

메시지로 부터 유추된 클래스 정의

B

+b1(arg1, arg2)+b2()

C

+c1()-c2()



- One Step Ahead -


4. 클래스 간의 관계 도출 (1)시퀀스 다이어그램에서 A 클래스의 객체가 B 클래스의 객체에게 메시지를 전송하는 것은 두 객체의 클래스 사이에 어떤 관계가 있어야 가능하다.

아무 관계가 없는 클래스의 객체 사이에는 메시지가 전송될 수 없기 때문이다.

UML에서 클래스 간의 관계 4가지일반화 관계

유사성을 바탕으로 클래스들을 조직화하는 역할을 함

포함 관계두 클래스 간의 물리적인 또는 논리적인 전체/부분의 의미를 표현하는데 사용

의존 관계한 클래스의 변경이 다른 클래스에 영향을 주는 관계

연관 관계한 클래스가 다른 클래스를 인지하는 상황을 나타냄

메시지 전송 측면에서의 고찰연관 관계와 의존 관계

두 객체 간의 메시지 전송의 경로 역할을 담당

즉, 클래스 A가 클래스 B와 연관 관계 또는 의존 관계가 있으면, 클래스 A의 객체는 클래스 B의 객체에게 메시지를 전송할 수 있다.집합 관계도 연관 관계의 일종이므로 전체를 나타내는 객체가 부분 객체에게 메시지를전송할 수 있다.시퀀스 다이어그램에서 클래스 A의 객체가 클래스 B의 객체에게 메시지를 전송한다면, 클래스 A와 클래스 B사이에는 연관 관계 또는 의존 관계가 있는 것을 뜻한다.



- One Step Ahead -


4. 클래스 간의 관계 도출 (2)클래스 간의 관계 유추 (연관 관계)

클래스 A에서 클래스 B로의 연관은 시퀀스 다이어그램에서 클래스 A의 객체가 클래스 B의 객체에게 b1() 메시지와 b2() 메시지를 전송하기 위하여 필요한 관계이고, 클래스 B에서 클래스 C로의 연관은 클래스 B의 객체가 클래스 C의 객체에게 c1() 메시지를 전송하기 위하여 필요한 관계이다.

연관 관계와 의존 관계

메시지의 전송으로 클래스 간의 관계가 연관(집합) 관계인지 또는 의존 관계인지를판단하기 어려울 수 있다.

메시지의 전송이 연관 관계에 의한 것인지 의존 관계에 의한 것인지를 판단하기 위해서는 해당 연산의 소스 코드 분석이 요구될 수 있다.

만약,

메시지 수신 객체가 메시지 전송 객체에 필드로 선언되었다면, 연관 관계를 의미하고

메시지 수신 객체가 메시지 수신 객체의 메소드에서 인자로 선언되거나, 지역 변수로선언된 경우에는 의존 관계에 해당한다.

B

+b1(arg1, arg2)+b2()

C

+c1()-c2()

A



- One Step Ahead -


3. 3. 시퀀스시퀀스 다이어그램다이어그램 (6)(6)5. 연산의 알고리즘 도출 (1)

시퀀스 다이어그램의 메시지로부터 해당 클래스의 연산을 유추할 수 있을 뿐만 아니라, 연산의 내부 구현에 대해서도 어느 정도 유추할 수 있다.

‘시퀀스 다이어그램에서의 메시지 전송’ 그림에서

클래스 B의 객체는 b2() 메시지를 수신하면 클래스 C의 객체에게 c1() 메시지를 전송한다.

이는 클래스 B에 정의된 연산 b2()에서 클래스 C의 c1() 연산을 호출하는 것을 뜻한다.

클래스 C의 객체는 클래스 B의 필드이거나, b2() 연산의 지역변수 일 수 있다.시퀀스 다이어그램 만으로는 클래스 C의 객체가 클래스 B의 필드로 선언된 변수 인지 또는 연산b2()의 지역 변수인지는 판단할 수 없으며, 클래스 다이어그램에서 클래스 B와 클래스 C사이에어떤 관계가 있는 지를 알아야 한다.

클래스 B의 소스 코드 예시

class B {public b1(arg1, arg2) { // b1 연산에 대한 구현 }public b2() {//…클래스 c의 객체.c1();// …}

}

클래스 B의 소스 코드 예시 – 연관 관계인 경우

class B {private C objc;public b1(arg1, arg2) { // b1 연산에 대한 구현 }public b2() {//…objc.c1();// …}

}


- One Step Ahead -


3. 3. 시퀀스시퀀스 다이어그램다이어그램 (7)(7)5. 연산의 알고리즘 도출 (2)

클래스 B와 클래스 C 사이에 의존 관계가 있다면 클래스 C의 객체가 클래스 B의연산 b2() 내에서 지역변수로 정의된 것을 의미한다.

의존 관계는 대상 클래스가 메소드의 인자로 사용되거나, 지역 변수에서 사용되는 경우인데, 연산 b2()에서는 클래스 C가 인자로 사용되지 않고 있기 때문에, 클래스 C가 연산 b2()의 지역변수로 사용된다고 추정할 수 있다.

클래스 C의 객체는 시퀀스 다이어그램에서 c1() 메시지를 수신하면 자신에게c2() 메시지를 전송한다.

클래스 B의 소스 코드 예시 – 의존 관계인 경우

class B {public b1(arg1, arg2) { // b1 연산에 대한 구현 }public b2() {//…C objc = new C();objc.c1();// …}

}

클래스 C의 소스 코드 예시

class C {private c2() { // c2 연산에 대한 구현 }public c1() {//…c2(); // 동일 객체의 c2() 연산의 호출

// …}

}


- One Step Ahead -


3. 3. 시퀀스시퀀스 다이어그램다이어그램 (8)(8)6. 메시지 번호

시퀀스 다이어그램에서 메시지 이름 앞부분에 표시된 숫자는 해당 메시지의 번호를 나타낸다.

메시지 번호는 전송되는 각 메시지에 대한 일련번호로 각 메시지의 전송 순서를나타낸다.

즉, 낮은 번호의 메시지가 높은 번호의 메시지 보다 먼저 전송되어 처리된다.


- One Step Ahead -


3. 3. 시퀀스시퀀스 다이어그램다이어그램 (9)(9)7. 메시지 결과 (1)

반환 메시지(return message)를 이용하여 전송된 메시지에 대한 수행 결과를 시퀀스 다이어그램에 명시적으로 표현할 수 있다.

즉, 반환 메시지는 원래 메시지를 수신한 객체가 해당 메시지에 대한 처리 결과를 메시지 전송 객체에게 알려 주는 역할을 한다.


- One Step Ahead -


3. 3. 시퀀스시퀀스 다이어그램다이어그램 (10)(10)7. 메시지 결과 (2)

반환 메시지는 일반 메시지와 달리 점선으로 표시되며, 반환값을 메시지의 이름부분에 기술한다.반환 메시지는 수신한 메시지에 대한 수행결과에 해당하므로 반환 메시지를 수신한 객체가 반환 메시지에 대응되는 연산을 가질 필요는 없다.반환 메시지를 과도하게 사용하는 경우, 시퀀스 다이어그램이 복잡해 지므로 반드시 필요한 경우가 아니면 반환 메시지를 사용하지 않는 것이 바람직하다.

즉, 일반 메시지를 통해서 메시지의 수행결과를 유추하기 어려운 상황인 경우에 명시적으로 메시지의 결과를 표현하고 그 외의 경우에는 생략하여도 무방하다.

동기(synchronous) 메시지메시지 전송 객체는 메시지를 전송한 후에 메시지 수신 객체에 해당 메시지에 대한 처리를 완료할 때 까지 수행을 멈추고 기다린다.메시지 수신 객체가 결과를 반환할 때까지 전송 객체의 수행이 지연되므로, 메시지 수행의 결과 반환 시기가 명확하고 그 결과도 쉽게 유추할 수 있다.

비동기(asynchronous) 메시지메시지를 전송 한 후에 메시지 수신 객체의 수행과 관계 없이 메시지 전송 객체가 계속해서 수행을 진행하는 메시지이다.메시지를 전송한 후에 메시지 전송 객체가 독자적으로 수행을 계속 진행하므로 메시지 수행 결과의 반환 시기와 반환 결과를 명시할 필요가 있다.비동기 메시지의 경우에 반환 메시지가 사용될 가능성이 높다.


- One Step Ahead -


3. 3. 시퀀스시퀀스 다이어그램다이어그램 (11)(11)8. 제어 초점의 연속성 (1)

시퀀스 다이어그램에서 제어 초점은 해당 객체가 활성화되어 수행되고 있는 시간이라고 볼 수 있다.

따라서 시퀀스 다이어그램에서 동일한 객체에 대하여 두 개의 제어 초점으로 분리되어 표현되는 경우와 하나의 제어 초점으로 표시되는 경우는 의미상 차이를 가진다.

연속적인 하나의 제어 초점의 예

그림1 그림2


- One Step Ahead -


3. 3. 시퀀스시퀀스 다이어그램다이어그램 (12)(12)8. 제어 초점의 연속성 (2)

그림 1b1() 메시지와 b2() 메시지가 별도의 제어 초점으로 표현되어 있다.

따라서 이 경우에는 b1() 메시지가 전송된 후에 반드시 b2() 메시지의 전송이 발생하는 것을의미하지는 않는다.

즉, b1() 메시지만 전송되고 b2() 메시지는 전송되지 않을 수도 있다.

그림 2제어 초점은 해당 객체가 활성화된 제어 쓰레드를 가지고 있는 시간을 의미하므로 하나의 동일한 제어 초점에서 b1() 메시지와 b2() 메시지가 전송되는 것은 두 메시지의전송이 분할되어 발생하지 않고, 항상 b1() 메시지 전송 후에 b2()의 메시지 전송이이어서 발생하는 것을 의미한다.

73쪽, ‘로그인 유스케이스의 실현 모델’일반적으로 화면에서 필요한 데이터를 입력하는 행위와 처리를 요구하기 위하여 버튼을 누르는 행위는 분리된 행위이므로 시퀀스 다이어그램에서 별도의 제어 초점으로 표현하는 것이 타당하다.

반면에, 사용자관리 객체는 로그인화면 객체로부터 사용자확인() 메시지를 수신한경우에는 2.1.1 검색(), 2.1.2 암호조회(), 2.1.3 두 암호의 비교가 연이어 전송된다.

이 세 메시지는 오류없이 정상적으로 수행되는 경우에 항상 연속적으로 수행된다.

따라서 하나의 제어 초점에 세 메시지의 전송이 표현되는 것이 타당하다.


- One Step Ahead -


로그인 유스케이스의 실현 모델<<redirect>> 스테레오 타입은 로그인화면에서 사용자별 메인화면으로의 전환과 같이UI 경계클래스에서 다른 UI 경계클래스로의 전환을 의미한다.

4. 4. 유스케이스유스케이스 실현실현 모델모델 작성작성 방법방법 (1)(1)


- One Step Ahead -


암호변경 유스케이스의 실현 모델

4. 4. 유스케이스유스케이스 실현실현 모델모델 작성작성 방법방법 (2)(2)


- One Step Ahead -


협력(collaboration) 다이어그램은 UML에서 시퀀스 다이어그램과 더불어 상호작용(interaction) 다이어그램으로 불린다.

즉, 협력 다이어그램도 객체 간의 상호작용(메지시 전송)을 표현할 때 사용될 수 있다.

그러므로, 협력 다이어그램도 시퀀스 다이어그램과 마찬가지로 유스케이스의 실현을 기술하기 위하여사용될 수 있다.

로그인 유스케이스의 협력 다이어그램

5. 5. 협력협력 다이어그램다이어그램 (1)(1)


- One Step Ahead -


협력 다이어그램에는 사용자 액터, 로그인화면 객체, 사용자관리 객체, 사용자정보 객체, 사용자별 메인화면 객체가 있다.그리고 각 객체들 사이의 실선은 해당 객체들 간의 링크를 나타낸다.링크 위의 화살표는 이 링크를 통하여 전송되는 메시지를 나타낸다.

즉, 링크는 메시지 전송의 통로 역할을 한다.

협력 다이어그램에서는 클래스 다이어그램처럼 객체들이 임의의 위치에 배치될 수 있으므로, 객체의 위치와 메시지의 전송 순서를 관련시킬 수 없다.또한, 두 객체 사이에 존재하는 하나의 링크를 통해서 두 개 이상의 메시지가 전송될 수 있다.

그러므로 협력 다이어그램에서는 전송되는 메시지에 반드시 메시지 번호를 붙여야 메시지 간의 시간적인 관계를 파악할 수 있다.

협력 다이어그램의 표현력은 시퀀스 다이어그램과 동일하다.즉, 시퀀스 다이어그램으로 표현되는 모든 상황은 협력 다이어그램으로도 표현이 가능하고, 반대로 협력다이어그램으로 표현되는 모든 상황은 시퀀스 다이어그램으로로 표현이 가능하다.

협력 다이어그램은 객체들 간의 관계가 링크로 표현된다.따라서 메시지를 전달하고 수신하는 객체들간의 관계를 쉽게 파악할 수 있는 이점이 있다.반면에, 객체가 협력 다이어그램의 임의의 위치에 배치될 수가 있기 때문에, 메시지의 위치에 따른 전송순서를 가정할 수 없다.

시퀀스 다이어그램은 메시지의 상/하 배치 위치가 메시지의 전송 순서를 정의하므로 객체들 간에주고 받는 메시지의 순서를 파악할 때 매우 효과적이다.

반면에, 메시지를 주고 받는 객체들 간의 관계는 표현되지 않는다.즉, 두 객체가 연관 관계가 있어서 메시지를 전송할 수 있는 것인지 아니면, 두 객체가 의존 관계가 있어서 메시지를 전송할 수 있는 지를 알 수가 없다.

협력 다이어그램의 사용보다는 시퀀스 다이어그램의 사용이 권장된다.



- One Step Ahead -


상호작용 다이어그램 간의 자동 변환

단축 메뉴 또는 Together의 ‘Selection’ 메뉴에서 ‘Show as Collaboration’ 또는 ‘Show as Sequence’를 선택한다.



- One Step Ahead -


분석 유스케이스의 실현 요약유스케이스 실현은 유스케이스로 기술된 시스템의 기능이 어떻게 실현될 수 있는 지를 도출된 클래스들을 바탕으로 정의하는 기법이다.분석 유스케이스의 실현에서는 도출된 분석 클래스의 객체들 간의 상호작용 즉, 메시지 전달을 통하여각 유스케이스의 기능이 실현되는 지를 확인한다.유스케이스의 실현은 UML의 시퀀스 다이어그램으로 표현하며 이를 분석 유스케이스 실현 모델이라고부른다.유스케이스 실현 모델을 표현하기 위하여 사용되는 시퀀스 다이어그램의 상단에는 해당 유스케이스와관련된 액터들과 도출된 분석 클래스의 객체가 배치된다.시퀀스 다이어그램에서는 각 메시지들이 상단에서 하단으로 시간적인 순서를 가진다.UI 경계클래스는 액터가 버튼/메뉴를 선택하면 요청된 기능을 수행하기 위하여 해당 유스케이스를 담당하는 제어클래스에 적절한 메시지를 보낸다.제어클래스는 UI 경계클래스가 요청한 기능을 수행하는 과정에서 영속성이 있는 정보를 조작(생성/삭제/조회/갱신/검색)하기 위하여 적절한 실체클래스에게 메시지를 보낸다.액터와 세 종류의 분석 객체들의 메시지 흐름은 항상 액터 UI 경계클래스 제어클래스 실체클래스의 방향으로 나타난다.

따라서 시퀀스 다이어그램을 보다 직관적으로 이해할 수 있게 상단에 액터와 객체를 배치할 때도 이 메시지의 흐름방향을 반영하여 액터, UI 경계 객체, 제어 객체, 실체 객체의 순으로 하는 것이 바람직하다.

협력 다이어그램은 시퀀스 다이어그램과 더불어 상호작용 다이어그램으로 불린다.메시지의 전달 순서에 초점을 두는 시퀀스 다이어그램과 달리 협력 다이어그램에서는 객체들 간의 관계에 초점을 둔다.협력 다이어그램과 시퀀스 다이어그램은 동일한 정보를 표현할 수 있으므로 두 다이어그램 간의 자동적인 변환이 가능하다.시스템을 개발할 때는 메시지의 전달 순서를 직관적으로 쉽게 파악할 수 있는 시퀀스 다이어그램의 사용이 선호된다.

SummarySummary

8. 분석에 대한 고찰


- One Step Ahead -


UML의 클래스 간의 네 가지 관계 중에서 의존은 설계 활동에서 등장하므로 분석 활동에서는 대상이 아니다.

따라서 의존 관계를 제외한 연관, 포함, 일반화 관계가 분석 클래스 간에 정의될 수 있다.

유스케이스 분석 기법에서는 분석 활동에서 파악되는 클래스들을 그 목적에 따라서 세 가지로 분류하고 있기 때문에 클래스 간에 세가지 종류의 관계가 모두 정의되지 않으며, 분석 클래스 간의관계에는 어떤 패턴이 존재하게 된다.

분석 클래스 간의 관계 요약

프리젠테이션 레이어 비즈니스 로직 레이어 데이터 접근 레이어

1. 1. 분석분석 클래스클래스 간의간의 관계관계 요약요약 (1)(1)


- One Step Ahead -


1. 1. 분석분석 클래스클래스 간의간의 관계관계 요약요약 (2)(2)종류가 다른 클래스 간에는 연관 관계 만이 존재할 수 있다.

즉, 서로 다른 종류의 클래스 간에는 포함 관계 또는 일반화 관계가 정의되지 않는다.

예를 들면, UI 경계클래스가 SI 경계클래스, 실체클래스 또는 제어클래스를 포함하거나 이들 클래스로부터 계승 받아서 정의될 수는 없다.

또한, 이들 간의 연관 관계는 항상 경계클래스(UI 경계클래스)에서 제어클래스로 그리고 제어클래스에서 실체클래스로의 방향만이 가능하며 그 반대 방향으로의 연관은 경계클래스, 제어클래스, 실체클래스의 의미에 비추어 볼 때 부적절하다.

동일한 종류의 클래스들 사이에는 세 가지 종류의 연관이 모두 사용될 수 있다.경계클래스와 제어클래스보다는 실체클래스들 사이에 포함, 일반화, 연관 관계가 많이 사용된다.


- One Step Ahead -


1. 1. 분석분석 클래스클래스 간의간의 관계관계 요약요약 (3)(3)1. UI 경계클래스 기준

UI 경계클래스를 기준으로 하여 다른 UI 경계클래스, 실체클래스, 제어클래스 및 SI 경계클래스와의 관계를 요약하면 다음과 같다.

UI 경계클래스

A

A B UI 경계클래스 A에서 UI 경계클래스 B로의 연관은 화면 A에서 화면 B로의 전환을 의미한다.

A B 화면 A가 화면 B를 포함하는 것을 의미한다.

A B 일반적으로 UI 경계클래스 사이에서는 일반화를 사용하지 않는다.

A BUI 경계클래스 A에서 제어클래스 B로의 연관은 UI 경계클래스 A가 화면에서 사용자가 요청한 기능을 제어클래스 B의 연산을 호출함으로써 사용자에게 제공하는 것을 의미한다.

A B

A B상이한 종류의 클래스 사이에 포함과 일반화는 적용되지 않는다.

A B경계클래스는 항상 제어클래스를 통해서 데이터를 조작한다. 따라서 UI 경계클래스 A에서실체클래스 B로의 연관은 존재하지 않는다.

A B


A B경계클래스는 항상 제어클래스를 통해서 외부 시스템에 접근한다. 따라서 UI 경계클래스 A에서 SI 경계클래스 B로의 연관은 존재하지 않는다.

A B


SI 경계클래스 B

실체클래스 B

제어클래스 B

UI 경계클래스 B

AB


- One Step Ahead -


1. 1. 분석분석 클래스클래스 간의간의 관계관계 요약요약 (4)(4)2. 제어클래스 기준

제어클래스를 기준으로 하여 UI 경계클래스, 실체클래스, 다른 제어클래스 및 SI 경계클래스와의 관계를 요약하면 다음과 같다.

제어클래스 A

A B 제어클래스가 UI 경계클래스 B에서 접근하지는 않는다.

A B


A B

제어클래스 A가 다른 제어클래스 B의 기능을 이용하는 경우로써, 제어클래스 B는 여러 제어클래스에서 사용되는 공통 클래스일 가능성이 높다.

즉, 여러 제어클래스에서 공통적으로 사용될 수 있는 기능은 이처럼 별도의 제어클래스를 정의하여공유하는 것이 바람직하다.

A B

제어클래스 A가 자신에게 포함된 제어클래스 B의 기능을 이용하는 것을 의미한다. 제어클래스 A가크고 복잡한 경우에는 그 기능의 일부분을 처리하는 다른 제어클래스 B를 정의하고 이를 활용할 수있다. 위의 연관과 다른 점은 이때 제어클래스 B는 다른 유스케이스를 위한 공통적인 기능이 아니라제어클래스 A만을 위한 기능을 제공한다는 것이다.

만약, 전속 포함이 아니라 공유 포함이 더 적합하다고 판단된다면, 포함 보다는 연관을 적용하는 것이보다 바람직하다.

A B 제어클래스 A가 기존의 다른 제어클래스 B를 계승 받아서 정의되는 경우다.

A B 제어클래스 A가 데이터 접근을 위해서 실체클래스 B를 이용하는 것을 의미한다.

A B


A B 제어클래스 A가 외부 시스템을 접속하기 위하여 SI 경계클래스 B를 이용하는 것을 의미한다.

A B



실체클래스 B

제어클래스 B


AB


- One Step Ahead -


1. 1. 분석분석 클래스클래스 간의간의 관계관계 요약요약 (5)(5)3. 실체클래스 기준

실체클래스를 기준으로 하여 다른 경계클래스, 다른 실체클래스, 제어클래스 및 SI 경계클래스와의 관계를 요약하면 다음과 같다.

실체클래스

A

A B실체클래스는 데이터에 대한 관리만을 하며, 사용자 화면을 직접 접근하지는 않는다. 따라서이러한 종류의 연관은 발생하지 않는다.

A B


A B실체클래스는 제어클래스가 요청한 데이터 조작 기능만을 수행할 수 있으며, 반대로 제어클래스에 접근할 수는 없다. 따라서 이러한 종류의 연관은 발생하지 않는다.

A B


A B

A B

A B

A B실체클래스는 제어클래스가 요청한 데이터 조작 기능 만을 수행하며 외부 시스템에 접근하지 않는다. 따라서 이러한 종류의 연관은 발생하지 않는다.

A B



실체클래스들 사이의 연관, 포함, 일반화가 사용될 수 있다.실체클래스 B

제어클래스 B


AB


- One Step Ahead -


1. 1. 분석분석 클래스클래스 간의간의 관계관계 요약요약 (6)(6)4. SI 경계클래스 기준

SI 경계클래스를 기준으로 하여 UI 경계클래스, 실체클래스, 제어클래스 및 다른 SI 경계클래스와의 관계를 요약하면 다음과 같다.

SI 경계클래스 A

A B SI 경계클래스가 사용자 화면을 직접 접근하지는 못한다. 따라서 이러한 종류의 연관은 발생하지 않는다.

A B


A BSI 경계클래스가 제어클래스에 접근하는 것으로서, SI 경계클래스가 외부시스템의 수행결과를 처리한후에 이를 제어클래스에 전달하여 또 다른 처리를 요구하는 것을 의미한다.

A BSI 경계클래스 A가 다른 SI 경계클래스 B의 기능을 이용하는 경우로, SI 경계클래스 B는 여러 SI 경계클래스에서 공통적으로 사용되는 공통 클래스일 가능성이 높다. 즉, 여러 SI 경계클래스에서 공통적으로사용될 수 있는 기능은 이처럼 별도의 제어클래스를 정의하여 공유하는 것이 바람직하다.

A B제어클래스 B


A BSI 경계클래스가 영속적인 데이터에 대한 조작을 직접하기 위해서 실체클래스에 접근하지 못한다. SI 경계클래스는 직접 실체클래스에 접근 하는 대신에 제어클래스를 이용한다. 따라서 이러한 종류의 연관은발생하지 않는다.

A B


A B

SI 경계클래스 A가 자신에게 포함된 SI 경계클래스 B의 기능을 이용하는 것을 의미한다. SI 경계클래스A가 크고 복잡한 경우에는 그 기능의 일부분을 처리하는 다른 SI 경계클래스 B를 정의하고 이를 활용할수 있다. 위의 연관과 다른 점은 이때 SI 경계클래스 B는 다른 SI 경계클래스를 위한 공통적인 기능이 아니라 SI 경계클래스 A만을 위한 기능을 제공한다는 것이다. 만약, 전속 포함이 아니라 공유 포함이 더 적합하다고 판단된다면, 포함 보다는 연관을 적용하는 것이 바람직하다.

A B SI 경계클래스 A가 기존의 다른 SI 경계클래스 B를 계승 받아서 정의되는 경우다.


실체클래스 B


AB


- One Step Ahead -


2. 2. 경계경계//제어제어//실체실체 클래스의클래스의 구분구분 배경배경 (1)(1)경계클래스, 제어클래스, 실체클래스는 하나의 애플리케이션 로직을 프리젠테이션 로직, 비즈니스 로직, 데이터 접근 로직으로 분담하고 있다.

그러므로 시스템이 제공하는 하나의 완전한 기능인 유스케이스는 각 로직을 담당하는 세종류의 분석 클래스 객체 간의 협력으로 실현된다.

세 가지 종류의 분석 클래스로 애플리케이션 로직을 분류하여 시스템을 분석하는 방식은시스템에 대한 이해도, 유지보수성, 개발 생산성을 높이는데 기여할 수 있다.

프리젠테이션 로직, 비즈니스 로직, 데이터 접근 로직은 각각 초점을 두고 있는 분야가다르다.

즉, 프리젠테이션 로직은 사용자 인터페이스에 관심을 두고, 비즈니스 로직은 시스템이 제공해야 할 업무 기능에 초점을 둔다.

그리고 데이터 접근 로직은 비즈니스 로직이 필요로 하는 영속적인 데이터에 관심을 둔다.

따라서 복잡한 하나의 애플리케이션 로직을 한꺼번에 분석하는 것이 아니라 세 부분의 각로직으로 우선 분류하고 각 로직 별로 자세히 분석함으로써 보다 효율적으로 시스템에 대한 분석을 수행할 수 있다.

프리젠테이션 로직, 비즈니스 로직, 데이터 접근 로직 각각은 초점을 두고 있는 분야가다르므로, 가능한 각 로직 간의 의존성은 최소화될 수 있다.

즉, 시스템을 구성하는 각 로직을 별도의 단위로 분석하기 때문에 특정 로직에서 발생한 변경이 다른 부분으로 전파되는 것을 어느 정도 막을 수 있다.


- One Step Ahead -


2. 2. 경계경계//제어제어//실체실체 클래스의클래스의 구분구분 배경배경 (2)(2)분석 클래스에 의한 변경의 파급 범위 최소화

분석클래스는 각 로직을 전담하고 있으므로, 하나의 분석클래스에서 발생한 변경사항은 클래스의 외부로 전파되지 않고 해당 클래스 내로 한정될 수 있다.

예를 들면, 화면의 구성과 같은 프리젠테이션 로직에 대한 변경이 필요한 경우 해당 경계클래스만 수정하면 되며, 제어클래스와 실체클래스를 변경할 필요는 없다.

시스템이 구축되어 운영되는 과정 뿐만 아니라, 시스템을 구축하는 과정에서도 여러 가지 이유에 의해서 작성된모델 및 소스코드가 수정되는 경우는 빈번하다.

예를 들어, 개발 도중에 사용자가 화면 구성을 변경해 달라고 요청할 수도 있고, 시스템에 대한 설계에 문제점이 발생되어소스 코드를 수정할 필요도 발생할 수 있다.예들 들어, 특정 화면에 대한 변경 요청이 있는 경우 해당 화면을 제공하는 경계클래스의 수정은 불가피하다. 그러나 해당경계클래스의 수정이 다른 분석클래스의 수정을 유발해서는 안된다. 시스템의 한 부분의 수정이 다른 부분의 수정을 유발하고 다시 이 수정이 또 다른 부분의 수정을 연쇄적으로 유발하는 현상을 연쇄작용(ripple effect)이라고 하며 가장 경계해야 할 현상이다.

분석 활동에서 시스템을 경계클래스, 제어클래스, 실체클래스로 분류하는 것은 각 종류의 클래스에서 발생할 수있는 변경 사항을 해당 클래스로 국지화(localization) 시킬 수 있는 효과를 얻을 수 있으므로 개발 생산성과유지보수성 측면에서 중요한 역할을 한다.프로젝트를 수행할 때는 분석클래스의 종류 마다 담당자가 다를 수 있다.

즉, 하나의 유스케이스를 개발할 때 한 명의 개발자가 경계/제어/실체 클래스를 개발하지 않고, 경계클래스, 제어클래스, 실체클래스 별로 다른 개발자가 담당할 수 있다.이런 경우 한 개발자가 시스템을 수정한 경우 가능한 한 그 변경이 다른 부분으로 전파되는 것을 최소화 함으로써 다른 개발자에게 미치는 영향을 줄이는 것이 바람직하다.

분석 클래스 담당 로직 가능한 변경 사항

경계클래스 프리젠테이션 로직 화면 구성(예, 화면 구성 요소의 위치, 속성(크기, 글꼴, 색상))

제어클래스 비즈니스 로직 업무 흐름, 업무 규칙

실체클래스 데이터 접근 로직 데이터 접근 방법, DBMS의 종류 등

9. 분석 활동의 점검


- One Step Ahead -


1. 1. 개요개요분석은 요구사항 정의 활동에서 도출된 각 유스케이스를 분석하여 다음을 작성하는 활동이다.

세 종류의 클래스와 그들 간의 관계를 클래스 다이어그램에 표시한 분석 객체 모델

파악된 분석 클래스의 객체들 간의 상호작용으로 어떻게 유스케이스가 실현될 수 있는 지를 시퀀스 다이어그램에 표시한 분석 유스케이스 실현 모델

작성된 분석 객체 모델과 분석 유스케이스 실현 모델의 정확성을 점검하기 위하여 설계로 진행하기 전에 반드시 분석 모델을 검토해야 한다. 분석 모델의 검토는 두 가지 측면에서 논의될 수 있다.

(1) 분석 객체 모델과 분석 유스케이스 실현 모델 간의 일관성 검토

객체 모델과 유스케이스 실현 모델은 각각 클래스 다이어그램과 시퀀스 다이어그램으로 표현된다.

객체 모델은 정적인 측면으로 시스템에 존재하는 클래스와 그들 간의 관계를 기술한다.

유스케이스 실현 모델은 시스템의 동적인 측면에 해당하며, 도출된 클래스의 객체 간의 상호작용에 의한 유스케이스의 실현 방법을 기술한다.

유스케이스 실현 모델은 도출된 클래스의 객체들 간의 상호작용이므로 시퀀스 다이어그램의 상단에 배치되는 객체에 대응되는 클래스가 객체 모델의 클래스 다이어그램에 반드시 존재해야 한다.

(2) 분석 모델과 유스케이스 모델 간의 일관성 검토

분석 활동은 요구사항 정의의 산출물인 유스케이스 모델을 바탕으로 수행된다. 즉, 유스케이스 별로 분석을 통하여 분석 클래스들이 도출된다.

따라서, 요구사항 정의 활동을 통해서 작성된 유스케이스 모델을 바탕으로 올바르게 분석 활동을 수행하여분석 산출물(분석 객체 모델과 분석 유스케이스 실현 모델)을 작성하였는 지에 대한 점검이 필요하다.

즉, 유스케이스 모델에 명시된 요구사항이 분석 활동의 산출물에 올바르게 반영되고 있는 지에 대한 점검이필요하다.


- One Step Ahead -


2. 2. 분석분석 객체객체 모델과모델과 분석분석 유스케이스유스케이스 실현실현 모델모델 사이의사이의 일관성일관성 검토검토 (1)(1)분석 객체 모델과 분석 유스케이스 실현 모델은 각각 클래스 다이어그램과 시퀀스 다이어그램으로 표현되지만 동일한 하나의 시스템을 모델링하는 것이므로 서로 만족해야할 몇 가지 조건이 있다.

객체 모델의 클래스와 유스케이스 실현 모델의 객체 사이의 일관성

객체 모델의 연산과 유스케이스 실현 모델의 메시지 사이의 일관성

객체 모델의 연관과 유스케이스 실현 모델의 메시지 사이의 일관성

Rose는 Together에 비하여 모델에 대한 점검 기능을 제공한다.

Together는 소스 코드의 작성 및 점검에 대한 기능은 풍부하지만, 모델에 대한 검토기능은 직접적으로 제공하지 않는다.


- One Step Ahead -


2. 2. 분석분석 객체객체 모델과모델과 분석분석 유스케이스유스케이스 실현실현 모델모델 사이의사이의 일관성일관성 검토검토 (2)(2)1. 클래스/객체 사이의 일관성 점검

클래스 다이어그램에 표시된 클래스와 시퀀스 다이어그램에 표시된 객체사이에는 다음과 같은 항목을 점검할 수 있다.

점검항목클래스 다이어그램의 모든 클래스는 적어도 하나 이상의 시퀀스 다이어그램에서 객체로 사용되어야 한다.

시퀀스 다이어그램에서 객체로 사용되지 않는 클래스는 시스템이 제공하는 기능인 유스케이스를 실현할 때 사용되지 않는 클래스라고 볼 수 있다.

따라서 시퀀스 다이어그램에서 객체로 사용되지 않는 클래스는 정의할 필요가없는 클래스다. 즉, 개발할 필요가 없는 클래스라고 볼 수 있다.

시퀀스 다이어그램 객체의 클래스는 반드시 클래스 다이어그램에 정의되어있어야 한다.

특별한 경우(사용자 별 메인화면 객체)를 제외하면 시퀀스 다이어그램의 모든객체에 대해서는 대응되는 클래스가 클래스 다이어그램에 정의되어 있어야 한다.

클래스가 지정되지 않은 객체가 있는 경우, 그 객체에 해당하는 클래스를 추가하는 것을 고려해 본다.

시퀀스 다이어그램에서는 객체를 표시할 때 객체의 명세 창에서 클래스를 선택할 수 있다. 따라서 객체의 명세 창에서 클래스 이름이 지정되어 있지 않고(unspecified)라고 지정된 객체가 있는 지를 조사하면 된다.


- One Step Ahead -


2. 2. 분석분석 객체객체 모델과모델과 분석분석 유스케이스유스케이스 실현실현 모델모델 사이의사이의 일관성일관성 검토검토 (3)(3)2. 연산/메시지 사이의 일관성 점검

클래스 다이어그램에 표시된 클래스의 연산과 시퀀스 다이어그램의 객체간의 메시지 사이에는 다음과 같은 항목을 점검할 수 있다.

점검항목클래스 다이어그램에 정의된 각 클래스의 모든 연산은 적어도 한번 이상 시퀀스 다이어그램에서 수신 메시지로 표시되어야 한다.

시퀀스 다이어그램에서 나타나지 않는 연산은 시스템의 기능인 유스케이스를 실현하는 데 사용되지 않은 것이다.

따라서 하나의 시퀀스 다이어그램에서도 메시지로 사용되지 않은 연산은 불필요한 연산이라고 판단할 수 있다.

시퀀스 다이어그램의 메시지에 대응되는 연산이 클래스 다이어그램에 정의되어 있어야 한다.

시퀀스 다이어그램에서 클래스 A의 객체 a가 m() 이라는 메시지를 수신하면, A 클래스에는 m()이라는 연산이 정의되어 있어야 한다.

클래스의 연산으로 정의되어 있지 않은 메시지를 보낼 수 없기 때문이다.


- One Step Ahead -


2. 2. 분석분석 객체객체 모델과모델과 분석분석 유스케이스유스케이스 실현실현 모델모델 사이의사이의 일관성일관성 검토검토 (4)(4)3. 연관/메시지 사이의 일관성 점검

클래스 다이어그램에 표시된 클래스 사이의 연관 관계와 시퀀스 다이어그램의 객체 간의 메시지 사이에는 다음과 같은 점검 항목이 있다.

점검항목클래스 다이어그램의 연관이 있는 경우 시퀀스 다이어그램에는 두 클래스의객체 사이에 메시지가 전송되어야 한다.

두 클래스 사이의 연관 관계는 상대 클래스에 대한 메시지 전송의 수단으로 사용된다.

따라서 클래스 다이어그램에서 A와 B 클래스 사이에 연관이 있다면, 하나 이상의 시퀀스 다이어그램에서 A의 객체 a에서 B의 객체 b로 메시지가 전달되어야한다.

따라서 만약 연관을 통해서 전달되는 메시지가 없는 경우 해당 연관은 불필요하다고 판단될 수 있다.

시퀀스 다이어그램에서 메시지가 전송되는 객체에 대하여 클래스 다이어그램에는 해당 클래스 사이에 연관이 있어야 한다.

시퀀스 다이어그램에서 A의 객체 a에서 B의 객체 b로 메시지가 전달된 경우 클래스 다이어그램에서 클래스 A에서 클래스 B로 연관이 있어야 한다.

즉, 클래스 간의 연관은 객체 사이에 메시지를 전달하기 위한 통로이므로 연관관계가 없는 클래스의 객체 사이에는 메시지를 전달할 수 없다.


- One Step Ahead -


3. 3. 유스케이스유스케이스 모델과의모델과의 일관성일관성 검토검토 (1)(1)분석 모델은 이미 정의된 유스케이스 모델을 분석하여 도출된 분석 객체 모델과 분석유스케이스 실현 모델로 구성된다.

분석 모델은 유스케이스 모델로 주어진 요구사항을 플랫폼에 독립적이면서 기능적인요구사항만을 고려하여 작성된 시스템에 대한 모델이다.

따라서 분석 모델은 유스케이스 모델에 일치해야 한다.즉, 유스케이스 모델에 정의된 시스템의 기능이 분석 모델로 표현된 시스템에서 실제로 제공될 수있어야 한다.

이러한 특성을 분석 모델과 유스케이스 모델 간의 일관성이라고 하며, 정확한 분석 모델의 작성을 확인하기 위해서는 반드시 유스케이스 모델과의 일관성을 확인해야 한다.

1. 일반적인 질문

유스케이스 기반 분석 기법의 방법을 바탕으로 요구사항 정의 산출물을 기준으로 분석 산출물의 일관성을 확인할 수 있는 가장 기본적인 질문은 다음과 같다.

유스케이스 모델의 시스템 액터마다 SI 경계클래스가 정의되었는가?

유스케이스명세서의 이벤트 흐름에 기술된 각 화면마다 UI 경계클래스가 정의되었는가?

각 유스케이스마다 제어클래스가 정의 되었는가?

문제기술서와 유스케이스명세서의 이벤트 흐름에 언급된 주요 데이터가 실체클래스로 대응될 수있는가?

유스케이스 이벤트 흐름에 기술된 시스템의 기능이 분석클래스의 연산으로 대응되고 있는가?


- One Step Ahead -


3. 3. 유스케이스유스케이스 모델과의모델과의 일관성일관성 검토검토 (2)(2)2. 유스케이스 이벤트 흐름과 유스케이스 실현 모델의 비교 (1)

유스케이스 이벤트 흐름에는 액터의 행동을 포함하여 시스템이 액터에게 제공해야 하는 기능이 이벤트형태로 기술되어 있다.

그리고 유스케이스 실현 모델의 각 메시지는 시스템의 기능을 제공하는 단위인 분석 클래스들의 기능이메시지 형태로 표현되었다.

따라서 유스케이스의 이벤트 흐름이 유스케이스 실현 모델의 메시지 흐름에 정확하게 반영되고 있는 지를 확인함으로써 분석 모델과 유스케이스 모델간의 일관성을 점검할 수 있다.

로그인 유스케이스를 예로 들어, 로그인 유스케이스의 기능이 적절하게 분석 모델로 발전되고 있는 지를확인하는 방법을 알아 본다.

기본 흐름

1. 사용자는 시스템에 접속한다.

2. 시스템은 로그인 화면을 보여준다.

3. 사용자는 아이디와 암호를 입력하고 로그인을 선택한다.

4. 시스템은 입력된 아이디와 암호의 정확성을 확인하고 사용자 별 메인화면을 보여준다(A1). 각 사용자 별 메인화면은 다음과 같다.

학생 : 학생 메인화면

교수 : 교수 메인화면

학사담당자 : 학사관리 메인화면

수업담당자 : 수강관리 메인화면

대안 흐름

(A1) 부정확한 아이디와 암호인 경우

1. 시스템은 아이디와 암호가 부정확함을 알려준다.



- One Step Ahead -



1. 사용자는 시스템에 접속한다.이 이벤트 문장이 나타내는 것은 시스템이 아니라 사용자가 수행하는 역할에 해당되므로 분석클래스로 대응시킬 필요가 없다.

2. 시스템은 로그인 화면을 보여준다.이 이벤트 문장은 시스템의 기능을 나타낸다.

따라서 적절하게 분석클래스로 대응되어야 한다.따라서 분석 객체 모델에 로그인 화면에 대응될 수 있는 UI 경계클래스가 있는 지를 확인해야 한다.

분석결과를 보면(18쪽 ‘로그인 유스케이스의 경계클래스’) 로그인화면 경계클래스가 사용자 로그인을 위한 화면을 정의함을 알 수 있다.

3. 사용자는 아이디와 암호를 입력하고 로그인을 선택한다.이 이벤트 문장은 사용자가 로그인화면에 아이디와 암호를 입력하고 로그인 버튼을누르는 것을 의미하므로, 시스템의 범위가 아니다.

따라서 분석 모델로 대응시킬 필요가 없다.그러나 이 이벤트 문장에 따르면, 로그인화면 경계클래스에는 사용자가 입력할 아이디와 암호를 위한 속성이 정의되어야하고, 로그인 버튼이 연산으로 정의되어야 함을 추정할 수 있다.

따라서 로그인화면 경계클래스에 아이디와 암호가 속성으로 선언되어 있고, 로그인이 연산으로 선언되어 있는 지를 확인해야 한다.


- One Step Ahead -



4. 시스템은 입력된 아이디와 암호의 정확성을 확인하고 사용자 별 메인화면을보여준다.

입력된 아이디와 암호의 정확성을 시스템이 확인한다.그리고 이 기능을 비즈니스 로직에 해당되므로 제어클래스가 적절하게 이 기능을 제공하는지를 확인해야 한다.

실제로 사용자관리 제어클래스의 사용자확인() 연산이 주어진 아이디와 암호의 정확성을 확인하는 기능을 제공하고 있다.

그리고 사용자 별로 보여줄 메인화면을 나타내는 UI 경계클래스가 있어야 한다.

실제로 학생 메인화면, 교수 메인화면, 학사관리 메인화면, 수강관리 메인화면이 UI 경계클래스로써 정의되어 있으므로 적절하다.(A1) 대안 흐름의 1. 시스템은 아이디와 암호가 부정확함을 알려준다.

부정확한 아이디 및 암호인 경우 시스템이 보여주어야 하는 기능도 적절히 표현되어야 한다.

(A2) 대안 흐름의2. 사용자는 다시 아이디와 암호를 입력함으로써 로그인을 시도한다.

이 이벤트 문장은 사용자의 행위를 나타낸다.그러나 사용자가 다시 아이디와 암호를 입력하기 위해서는 처음에 로그인 화면을 볼 수 있어야 한다.

3. 스크립트를 이용한 이벤트 흐름의 표기유스케이스의 이벤트 흐름과 시퀀스 다이어그램의 메시지 흐름을 효과적으로 비교할 수 있게 유스케이스 이벤트 흐름의 문장을 시퀀스 다이어그램에 스크립트의형태로 표현하는 방법도 사용할 수 있다.

10. 요약


- One Step Ahead -


요구사항요구사항 분석분석 -- SummarySummary분석 활동에서는 요구사항 정의 활동의 산출물인 유스케이스 모델과 각 유스케이스에 대한 유스케이스명세서를 분석하여 경계클래스, 제어클래스, 실체클래스를 도출한다.

그리고 도출된 각 분석클래스의 객체 간의 메시지를 송수신함으로써 유스케이스명세서에 정의된 시스템의 기능을 실현한다.

경계클래스는 유스케이스의 프리젠테이션 로직을 전담하는 클래스이고, 비즈니스 로직은 제어클래스가 담당한다. 그리고 실체클래스는 영속적인 데이터에 대한 접근 및 조작을 전담한다. 도출된 분석클래스들과 분석클래스 간의 관계는 클래스 다이어그램에 표현되며 이를 분석 객체 모델이라고 부른다.

시퀀스 다이어그램을 이용하여 표현되는 유스케이스 실현 모델은 각 유스케이스에 대하여 유스케이스의 전체기능이 도출된 경계클래스, 제어클래스, 실체클래스 객체들의 상호작용을 통하여 실현되는 과정을 나타낸다.

산출물 명 다이어그램 명 예

분석 객체 모델 클래스 다이어그램

분석 유스케이스 실현 모델 시퀀스 다이어그램

b1

b2

c1

e1

e2


- One Step Ahead -


[ 1 ] 송태국, RUP 기반의 J2EE 애플리케이션 개발, 피어슨에듀케이션코리아, 2003.

[ 2 ] 채흥석, 객체지향 CBD 개발 Bible, 한빛미디어, 2003.

[ 3 ] 전병선, 객체지향 CBD개발 방법론, 영진닷컴, 2004.

[ 4 ] 컴포넌트비전, 실전 CBD Project, 영진닷컴, 2004.

[ 5 ] 조창현, RUP Development Solution, 영진닷컴, 2004.

참고문헌참고문헌

Documents

객체지향 CBD 개발 분석 - Egloospds10.egloos.com/pds/200901/14/88/a0105788_496df5c7e95e9.pdf · 2009-01-14 · Java 또는C#으로설정하였다면 String이아니라int 타입이선언된다