[쉽게 배우는 소프트웨어 공학] Chapter 02 UML

1. UML의 이해

: UML(Unified Modeling Language)

: 프로그램 설계를 표현하기 위해 사용하는, 주로 그림으로 된 표기법을 의미

/ 객체지향 모델링 언어라고 불리기도 한다. (프로그래밍 언어는 아님)

개발될 소프트웨어의 모습을 12개의 다이어그램을 그려봄으로서 전체 윤곽을 파악하기 위함.

=> 실제로 12개를 모두 그리진 X , 3~5개 정도 작성

 

UML의 역할

UML은 시스템이 상호작용하는 측면, 시스템 전체 구조 측면, 컴포넌트 간의 관계 등을 시각적으로 볼 수 있게 나타낸 도면

 

UML 다이어그램 종류
1. 구조 다이어그램(Structure Diagram)
    * 클래스 다이어그램(Class Diagram) 💛
    * 객체 다이어그램 (Object Diagram)

    * 배치 다이어그램 (Deployment Diagram) 💛
    * 컴포넌트 다이어그램 (Component Diagram) 💛

2. 행위 다이어그램(Behavior Diagram)

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

    * 유스케이스 다이어그램(Use Case Diagram) 💛💛

    * 시퀀스 다이어그램(Sequnce Diagram) 💛

 

 

2. 유스케이스 다이어그램 (Use-Case Diagram) 💛💛

: 사용자가 시스템을 통해서 하고자 하는 것이 무엇인지..를 표현 (시스템에 기대하는 것 / 사용자의 요구사항) => 항상 기본이 됨

1. 액터 (Actor) : 사용자

* 사용자 액터 (User Actor)

: 시스템을 사용하는 사람(역할)을 의미

액터와 유스케이스 관계는 화살표(➡)를 사용하여 표현 (note. 실제로는 화살표를 사용하기보단 그냥 실선을 이용)

 

* 시스템 액터 (System Actor) (cf) 액터는 꼭 사람만이 아님)

: 해당 프로젝트의 개발 범위에는 속하지 않지만 데이터를 주고받는 등 서로 연동되는 또 다른 시스템을 의미

 

* 주요 액터 (Primary Actor)

: 시스템에게 작업의 실행을 요구하는 능동적 입장의 액터

 

* 보조 액터 (Secondary Actor)

: 유스케이스로부터 요청을 받거나 메시지를 전달받아 수동적으로 작업하는 액터

 

*프록시 액터 (Proxy Actor)

: 액터와 시스템의 중간 위치에서 무언가를 대신 해주는 액터

 

** 액터 식별 (주로 인터뷰를 이용)

1. 개발 시스템을 사용하는 사람을 찾는다.

2. 시스템에 자료를 등록/수정/삭제/조회하는 사람을 찾는다.

3. 개발 시스템에 연된된 또 다른 시스템을 찾는다.

4. 시스템을 유지 및 관리하는 사람을 찾는다.

5. 유스케이스 기능에 권한은 없지만 대신하는 사람을 찾는다.

 

** 액터 이름

1. 이름만 봐도 액터의 의미를 알 수 있도록 정한다.

2. 역할이 나타내는 단어로 사용자 액터의 이름을 정한다.

3. 시스템 액터는 시스템 이름을 사용해 이름을 정한다.

 

** 액터 목록 : 각 액터에 관한 설명을 붙인 액터 목록을 만들면 그 액터가 시스템을 사용해 어떤 일을 하는지 이해 하는데 도움이 됨

 

2. 유스케이스(Use-Case)

: Actor들이 사용하는 기능을 추출해낸것

/ 사용자가 시스템을 통해 사용하고 싶은 기능

유스케이스는 실제 코딩할 수 있을 만큼 작은 단위 => 유스케이스들이 모여 하나의 서브시스템을 이루고 서브 시스템이 모여 개발 시스템이 된다.

 

** 유스케이스 식별

1. 사용자인 액턱가 시스템에 요구하는 기능을 후보 유스케이스로 선정할 수 있다.

2. 사용자의 업무에서 유스케이스를 도출할 수 있다.

3. 데이터베이스에서 데이터를 등록/수정/삭제/조회하는 기능을 하나의 유스케이스로 선정할 수 있다.

이와 같은 방법으로 찾은 유스케이스 후보는 여러번의 정련 과정(반복)을 통해 최적화된 유스케이스로 결정된다.

 

** 유스케이스 검증 💗

1. 시스템이 아니라 수작업으로 이루어지는 것은 유스케이스에 포함하지 않는다. (코딩으로 구현할 수 있는 작은 단위 : 유스케이스)

2. 액터가 원하는 최종 결과만 나타내는 유스케이스인지 확인한다.

3. 액터가 수행하는 유스케이스인지 확인한다.

4. 유스케이스 내의 이벤트 흐름 전체를 액터가 사용하는지 확인한다.

 

** 유스케이스 이름 💗

1. 사용자 관점에서 이해할 수 있는 이름을 사용한다.

2. 명사보다는 어떤 기능을 하는지 알 수 있는 동사형 명사를 사용한다.

3. 사용자가 시스템을 통해 얻으려는 최종 목적이 나타나는 이름을 사용한다.

 

** 유스케이스 목록

: 각 유스케이스에 간단한 설명을 붙인 유스케이스 목록을 만들면 사용자나 개발자가 유스케이스 기능을 이해하는 데 도움이 될 것이다.

 

3. 관계

** 액터 ➡ 유스케이스 관계

액터와 유스케이스는 연관(association)관계로 방향성을 갖는 실선으로 표현

화살표 방향은 데이터가 흘러가는 방향이 아니라 제어의 흐름을 나타냄 (화살표 대신 보통 실선으로 표시)

cf) 액터와 시스템 액터 사이에도 연관관계가 존재 할 수 있음.

 

** 유스케이스 ➡ 액터 관계

액터 ➡ 유스케이스에서도 화살표를 사용하지 않고 실선을 이용하니 거의 구분할 필요 X

 

** 유스케이스 ➡  시스템 액터 관계

이것도 위와 같은 이유

 

** 액터의 일반화 관계 (상속관계)

일반화 : '개별적인 것이나 특수한 것이 일반적인 것으로 됨' (사전적의미)

EX) 학생 ,  교수 , 임직원 , 조교 등의 시스템 사용자가 공통으로 모두 사용하는 유스케이스에 대해서 액터들을 "사용자"로 통일해버리는 것

cf) 보통 복잡하게 사용하지 않으며, 꼭 필요한 경우에만 한해서 사용

 

** 액터 간의 연관 관계

: 액터 간의 연관 관계는 액터가 또 다른 액터를 통해 유스케이스를 이용하는 것을 말한다.

 

** include(포함관계) & extend(확장관계)  💗 💗 💗 💗

포함 관계(Include)는 하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때 형성되는 관계이다.

include : 한 유스케이스의 일부 기능 (이벤트 흐름)이 다른 유스케이스에서도 공통으로 필요하다면 이를 별도 유스케이스로 만든 뒤 호출해 사용하는 것을 말한다.

공통으로 사용하기 위해 별도 유스케이스로 만들어 놓은 것 : 피포함 유스케이스

피포함 유스케이스를 호출하는 유스케이스 : 기본 유스케이스

<<include>>

이 처럼 여러 유스케이스에 공통으로 들어가는 부분을 떼어내어 하나의 유스케이스로 만들고 포함관계를 나타낸다.

반드시 해야하는 유스케이스 쪽으로 화살표!

피포함 유스케이스는  2개 이상의 유스케이스에서 사용할 수 있는 공통 부분(이벤트 흐름)으로 만들어야 하며, 다른 유스케이스에서 사용하지 않는 기능이라면 포함 관계를 만들지 않아야 한다.

 

cf) 포함관계와 선행조건 

공통적으로 필요한 기능이지만 유스케이스 기능 중 일부분이 아니라 두 유스케이스를 수행하려면 꼭 먼저 해야 하는 기능 => 선행 조건

이러한 기능은 굳이 포함관계로 하는 것 보다 선행조건으로 두는 것이 적합하다.

 

<<extend>>

extend : 확장 관계(Extend)는 확장 기능 유스케이스와 확장 대상 유스케이스 사이에 형성 되는 관계이다.

확장 대상 유스케이스를 수행 할 때 특정 조건에 따라 확장 기능 유스케이스를 수행하는 경우에 적용한다.

확장 기능 유스케이스에서 확장 대상 유스케이스 방향으로 화살표를 점선으로 연결하고 <<extend>>라고 표기한다.

 

3. 클래스 다이어그램 (Class Diagram)

Class Diagram : 소프트웨어의 기본 구성 단위인 시스템에서 사용하는 클래스를 정의하고 클래스들이 서로 어떻게 연결되어 있고 어떤 역할을 하는지 다이어그램으로 표현

프로그램은 멈춰 있는 정적인 상태를 나타낸다.

클래스는 데이터(속성)와 메서드(method)를 묶어 놓은 것으로 세칸의 직사각형 모양이다.

클래스 이름

- 변수 이름1 - 변수 이름2 - 변수 이름3 (field)

+ 함수 이름1 + 함수 이름2 + 함수 이름3 + 함수 이름4 (method)

** 클래스 이름

클래스는 다른 클래스와 구별되는 유일한 이름을 갖는다.

이름에 명사나 명사구를 사용하며 두 단어를 사용할 때는 붙여 쓰되 각 단어의 첫 글자는 대문자로 쓴다.

 

** 속성

속성은 클래스가 갖는 정적인 특성이다.

속성의 이름은 소문자로 나타내며 두 단어를 사용할 때는 두 번째 단어의 첫 글자는 대문자로 쓴다.

 

** 메서드

메서드는 클래스가 외부의 다른 객체에게 제공할 서비스와 기능이며 외부 클래스는 메서드를 통해 해당 클래스에 접근할 수 있다.

외부에서 이 기능을 요구하는지에 따라 메서드로 도출할지 판단한다.

 

** 가시성

가시성은 속성과 메서드의 접근 권한을 지정하는 방법

4. 순차(시퀀스) 다이어그램 (Sequence Diagram)

Sequence Diagram은 실행 시점에 객체들이 어떻게 상호 동작하는지를 메시지 순서에 초점을 맞춰 나타낸 것으로 어떠한 작업이 객체 간에 발생하는지를 시간 순서에 따라 쉽게 파악할 수 있다.

 

** 객체

순차 다이어그램에서 객체는 메시지를 보내고 받는 것

'객체명 : 클래스명'으로 나타내며 한쪽은 생략 가능

 

** 객체 생명선

객체 생명선은 객체의 생존 기간을 나타내며 X 표시는 객체가 소멸하는 시점

객체 생명선은 위에서 아래로 내려가는 점선으로 나타낸다.

생명선은 따라 나타나는 직사각형은 활성 구간으로 객체의 메서드가 실행되고 있음을 나타내며 구간의 길이는 메서드의 실행 시간을 나타낸다.

 

** 메시지

메시지는 객체와 객체의 상호작용을 표현하는 것으로 화살표를 이용

화살표 위에는 수신 객체의 함수명을 명기

 

-중략-

 

시퀀스 다이어그램 : 객체간의 상호작용을 시간의 흐름에 따라서 정리한 다이어그램  (유용!)

유스케이스 / 시퀀스 다이어그램을 사용하면 대부분 해결 가능

5. 통신 다이어그램 (Communication Diagram)

순차 다이어그램과 마찬가지로 통신 다이어그램도 메시지를 이용해 객체 간 상호작용을 나타낸다.

차이는 순차 다이어그램은 객체 간 시간 순서에 초점을 맞추고 통신 다이어그램은 객체간 상호작용 관계에 주목한다는 점이다.

순서는 화살표 위에 적힌 번호로 알 수 있다.

통신 다이어그램을 작성하려면 객체, 링크, 메시지가 필요하다.

** 링크: 객체 간에 메시지를 주고 받는 관계 ; 링크(link)통신 다이어그램에서는 링크를 사용해 객체 간의 관계를 표현한다.

 

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

; 오퍼레이션이나 처리과정이 수행되는 동안 일어나는 일들을 단계적으로 표현하고자 할때 사용하는 다이어그램

 

Activity Diagram은 흐름도(flow-chart)와 모양이 비슷하다. 차이점은 흐름도가 행위의 작업 흐름을 표현한다면 액티비티 다이어그램은 객체의 행위를 나타낸다는 것이다. 

 

** 시작 / 종료 상태, 활동

* 시작점 (initial state): 활동의 시작을 나타내며 속이 채워진 원으로 표기

* 종료점 (final state): 활동의 종료를 나타내며 이중 원으로 표기

* 활동 (activity): 일의 처리와 실행을 나타내며 모서리가 둥근 사각형으로 표기

* 전이 (transaction): 활동 간의 이동을 나타내며 화살표로 표기

 

** 분기와 병합

* 분기 (decision) : 조건에 의해 두 가지 경로로 나뉘는 위치이며 마름모를 사용

조건문은 마름모 옆에 <<>> 기호로 작성한다.

* 병합 (merge) : 분기되어 각 활동을 수행하다가 합쳐지는 위치를 나타내며 분기와 같이 마름모를 사용한다. 병합은 생략이 가능하다.

** 동기화 막대 (synchronization bar)

: 여러 활동을 병행할 때 사용하는 것으로 동시 처리의 시작과 끝을 나타낸다.

 

 

** 신호

활동 사이의 거래는 제어 신호(signal)를 보내는 방식으로 이루어진다. 여기서 사용되는 신호는 다음과 같다.

-생략-

 

** 구획면 (swim lane)

각 객체의 활동을 파티션을 이용해 구역을 나눔

-생략-

 

7. 상태 다이어그램 (State Diagram)

: 이벤트 발생이나 시간의 흐름에 따라 바뀌는 객체의 상태를 나타냄

객체의 상태는 이벤트 발생이나 시간의 흐름에 따라 바뀌게 된다. 이러한 객체의 상태 변화를 나타낸 것은 상태 다이어그램(state diagram)이다. 

 

** 상태

상태(state)는 객체가 존재할 수 있는 조건

상태 다이어그램을 작성하려면 객체의 존재 가능한 모든 상태가 파악되어야 한다. / 상태는 모서리가 둥근 사각형으로 표현한다.

 

** 전이

전이(transaction)는 객체의 상태가 바뀌는 것을 나타내며 화살표를 사용해 표현한다.

 

** 이벤트

객체의 상태를 바뀌게 하는 자극이 이벤트(event)이다.

이벤트는 화살표로 나타낸 전이 위에 <<>>기호를 사용해 작성한다.

예를 들어 액체 상태인 물이 고체 상태인 얼음으로 바뀌려면 온도 변화가 필요한데 이것이 자극이며 상태의 변화를 일으키는 이벤트가 된다.

 

8. 컴포넌트 다이어그램 (Component Diagram)

컴포넌트 다이어그램은 구현 관점에서 정적 모델링을 할 때 사용하는 것으로 어떤 실행 모듈이 존재하고 이들이 서로 어떤 연관성이 있는지의 종속 관계를 나타낸다. 컴포넌트 다이어그램은 사용자에게 논리적 또는 물리적 시스템의 구조를 볼 수 있게 해준다.

 

-생략- 

9. 배치 다이어그램 (Deployment Diagram)

: 물리적인 하드웨어를 배치하는 다이어그램 (시스템 엔지니어가 함)

배치 다이어그램은 하드웨어 자원을 명시적으로 정의해 시스템의 물리적인 요소를 모델링하고 노드(node)간의 관계를 나타낸다.

-생략-