정보처리기사 실기 UML과 분석 모델

UML은 소프트웨어 구조와 동작을 그림으로 표현하는 표준 모델링 언어다.

정보처리기사 실기에서는 요구사항 확인 영역에서 분석 모델을 이해하기 위해 중요하다.

유스케이스 다이어그램, 클래스 다이어그램, 시퀀스 다이어그램, 활동 다이어그램, 상태 다이어그램을 구분해서 알아야 한다.

1. 정의

1-1. UML이란?

UML은 Unified Modeling Language의 약자다.

한국어로는 통합 모델링 언어라고 한다.

UML은 소프트웨어의 구조와 동작을 그림으로 표현하기 위한 표준 언어다.

여기서 모델링은 복잡한 대상을 이해하기 쉽게 단순화해서 표현하는 작업이다.

소프트웨어는 코드로만 보면 구조를 이해하기 어렵다.

그래서 개발 전에 시스템의 기능, 구조, 흐름을 그림으로 표현한다.

이때 사용하는 대표적인 표기법이 UML이다.

1-2. 분석 모델이란?

분석 모델은 사용자의 요구사항을 분석해서 시스템이 무엇을 해야 하는지 표현한 모델이다.

여기서 모델은 실제 시스템을 이해하기 쉽게 표현한 그림이나 문서다.

분석 모델은 개발자가 바로 코드를 작성하기 전에 요구사항을 구조화하는 데 사용한다.

쉽게 말하면 분석 모델은 “사용자가 원하는 기능을 개발자가 이해할 수 있는 형태로 정리한 결과물”이다.

1-3. UML과 분석 모델의 관계

UML은 분석 모델을 표현하는 도구로 사용할 수 있다.

예를 들어 게시판 시스템을 만든다고 가정한다.

요구사항은 다음과 같을 수 있다.

• 회원은 게시글을 작성할 수 있다.

• 회원은 자신의 게시글을 수정할 수 있다.

• 관리자는 모든 게시글을 삭제할 수 있다.

• 사용자는 게시글을 검색할 수 있다.

이 요구사항을 말로만 정리하면 전체 구조를 파악하기 어렵다.

그래서 UML 다이어그램으로 표현한다.

회원, 관리자, 게시글 작성, 게시글 삭제 같은 관계를 유스케이스 다이어그램으로 나타낼 수 있다.

회원, 게시글, 댓글 같은 데이터 구조는 클래스 다이어그램으로 나타낼 수 있다.

로그인 과정이나 게시글 작성 흐름은 시퀀스 다이어그램으로 나타낼 수 있다.

2. 필요한 이유

2-1. 요구사항을 시각적으로 이해하기 위해 필요하다

요구사항은 문장으로만 작성하면 이해하기 어려울 수 있다.

특히 기능이 많고 사용자 종류가 많으면 더 복잡해진다.

UML을 사용하면 사용자, 기능, 데이터, 동작 흐름을 그림으로 볼 수 있다.

그래서 개발자, 기획자, 사용자, 테스터가 같은 내용을 이해하기 쉬워진다.

2-2. 사용자와 개발자의 이해 차이를 줄이기 위해 필요하다

사용자와 개발자는 같은 요구사항을 다르게 이해할 수 있다.

예를 들어 사용자가 “관리자는 게시글을 관리할 수 있다”고 말했다고 하자.

개발자는 이것을 게시글 삭제 기능만으로 이해할 수 있다.

하지만 사용자는 게시글 수정, 숨김 처리, 신고 확인, 댓글 삭제까지 생각했을 수 있다.

UML로 기능과 관계를 표시하면 이런 이해 차이를 줄일 수 있다.

2-3. 설계와 구현의 기준을 만들기 위해 필요하다

분석 모델은 설계와 구현의 기준이 된다.

분석 모델이 명확하면 개발자는 어떤 기능을 만들어야 하는지 알 수 있다.

테스터는 어떤 기능을 테스트해야 하는지 알 수 있다.

운영자는 시스템 흐름을 이해하기 쉽다.

2-4. 복잡한 시스템을 구조적으로 표현하기 위해 필요하다

실제 시스템은 여러 기능과 데이터가 서로 연결되어 있다.

게시판만 해도 회원, 게시글, 댓글, 첨부파일, 권한, 신고, 관리자 기능이 연결된다.

이런 구조를 글로만 설명하면 놓치는 부분이 생길 수 있다.

UML은 복잡한 시스템을 구조적으로 표현하는 데 도움을 준다.

2-5. 실제 개발에서 해결하는 문제

• 요구사항을 서로 다르게 이해하는 문제

• 기능 관계를 놓치는 문제

• 객체와 데이터 구조를 잘못 파악하는 문제

• 기능 동작 순서를 잘못 구현하는 문제

• 개발자와 테스터의 기준이 달라지는 문제

• 문서 없이 코드부터 작성해서 구조가 복잡해지는 문제

3. 핵심 개념

3-1. UML 다이어그램

UML 다이어그램은 UML로 표현한 그림이다.

다이어그램은 어떤 구조나 흐름을 그림으로 표현한 것이다.

UML 다이어그램은 크게 구조 다이어그램과 행위 다이어그램으로 나눌 수 있다.

• 구조 다이어그램: 시스템의 정적인 구조를 표현한다.

• 행위 다이어그램: 시스템의 동적인 동작을 표현한다.

정적인 구조는 쉽게 말해 시스템이 어떤 요소로 구성되어 있는지를 뜻한다.

동적인 동작은 기능이 어떤 순서로 실행되는지를 뜻한다.

3-2. 유스케이스 다이어그램

유스케이스 다이어그램은 사용자와 시스템 기능의 관계를 표현하는 UML 다이어그램이다.

유스케이스는 사용자가 시스템을 통해 수행하는 기능이다.

예를 들어 게시판 시스템의 유스케이스는 다음과 같다.

• 로그인

• 게시글 작성

• 게시글 수정

• 게시글 삭제

• 게시글 검색

액터는 시스템과 상호작용하는 외부 대상이다.

예를 들어 회원, 관리자, 외부 결제 시스템이 액터가 될 수 있다.

유스케이스 다이어그램은 요구사항 분석 단계에서 자주 사용된다.

3-3. 클래스 다이어그램

클래스 다이어그램은 시스템의 클래스, 속성, 메서드, 관계를 표현하는 UML 다이어그램이다.

클래스는 객체를 만들기 위한 설계도다.

객체는 실제로 만들어져 사용되는 대상이다.

예를 들어 회원 클래스가 있다면 실제 회원 데이터 하나하나는 객체가 될 수 있다.

클래스에는 속성과 메서드가 있다.

속성은 클래스가 가지는 데이터다.

예를 들어 회원 클래스의 속성은 회원번호, 아이디, 비밀번호, 이름이 될 수 있다.

메서드는 클래스가 수행하는 기능이다.

예를 들어 회원 클래스의 메서드는 로그인, 로그아웃, 정보수정이 될 수 있다.

3-4. 시퀀스 다이어그램

시퀀스 다이어그램은 객체들이 시간 순서에 따라 주고받는 메시지를 표현하는 UML 다이어그램이다.

시퀀스는 순서라는 뜻이다.

메시지는 객체나 시스템 구성 요소 사이에서 주고받는 요청이나 응답이다.

예를 들어 로그인 기능은 다음 순서로 진행될 수 있다.

1. 사용자가 로그인 버튼을 누른다.

2. 화면이 서버에 로그인 요청을 보낸다.

3. 서버가 데이터베이스에서 회원 정보를 조회한다.

4. 서버가 로그인 성공 여부를 판단한다.

5. 화면에 결과를 보여준다.

이런 시간 흐름을 표현할 때 시퀀스 다이어그램을 사용한다.

3-5. 활동 다이어그램

활동 다이어그램은 업무나 기능의 처리 흐름을 표현하는 UML 다이어그램이다.

활동은 처리해야 하는 작업을 뜻한다.

활동 다이어그램은 순서도와 비슷하다.

조건에 따라 흐름이 나뉘는 경우를 표현하기 좋다.

예를 들어 게시글 작성 흐름은 다음과 같다.

1. 글 작성 화면을 연다.

2. 제목과 내용을 입력한다.

3. 등록 버튼을 누른다.

4. 입력값을 검사한다.

5. 정상이면 저장한다.

6. 비정상이면 오류 메시지를 보여준다.

3-6. 상태 다이어그램

상태 다이어그램은 하나의 객체가 시간에 따라 어떤 상태로 변하는지 표현하는 UML 다이어그램이다.

상태는 어떤 대상이 특정 시점에 가지고 있는 상황이다.

예를 들어 주문 객체는 다음 상태를 가질 수 있다.

• 주문 접수

• 결제 완료

• 배송 준비

• 배송 중

• 배송 완료

• 주문 취소

상태 다이어그램은 객체의 상태 변화가 중요한 시스템에서 사용한다.

3-7. 분석 모델 검증

분석 모델 검증은 작성된 분석 모델이 요구사항을 제대로 반영하는지 확인하는 작업이다.

검증은 맞는지 확인하는 작업이다.

분석 모델에 빠진 기능이 없는지 확인한다.

요구사항과 다르게 표현된 부분이 없는지 확인한다.

다이어그램끼리 내용이 서로 충돌하지 않는지도 확인한다.

4. 주변 기초 개념

4-1. 객체지향

객체지향은 프로그램을 객체 중심으로 구성하는 개발 방식이다.

객체는 데이터와 기능을 함께 가진 대상이다.

예를 들어 회원 객체는 회원 정보라는 데이터와 로그인이라는 기능을 가질 수 있다.

4-2. 객체

객체는 현실 세계의 대상을 소프트웨어 안에서 표현한 것이다.

회원, 게시글, 댓글, 주문, 상품이 객체가 될 수 있다.

4-3. 클래스

클래스는 객체를 만들기 위한 설계도다.

회원 클래스가 있으면 여러 명의 회원 객체를 만들 수 있다.

4-4. 속성

속성은 객체가 가지는 데이터다.

회원 객체의 속성은 아이디, 이름, 이메일, 가입일이 될 수 있다.

4-5. 메서드

메서드는 객체가 수행하는 기능이다.

회원 객체의 메서드는 로그인, 로그아웃, 정보수정이 될 수 있다.

4-6. 관계

관계는 객체나 클래스 사이의 연결을 뜻한다.

예를 들어 회원은 게시글을 작성한다.

이때 회원과 게시글 사이에는 관계가 있다.

4-7. 액터

액터는 시스템과 상호작용하는 외부 대상이다.

사람일 수도 있고 외부 시스템일 수도 있다.

예를 들어 회원, 관리자, 결제 시스템이 액터가 될 수 있다.

4-8. 유스케이스

유스케이스는 액터가 시스템을 통해 수행하는 기능이다.

로그인, 글 작성, 결제하기, 주문 조회가 유스케이스가 될 수 있다.

4-9. 메시지

메시지는 객체나 시스템 구성 요소 사이에서 주고받는 요청이나 응답이다.

예를 들어 화면이 서버에 로그인 요청을 보내는 것도 메시지다.

4-10. 생명선

생명선은 시퀀스 다이어그램에서 객체가 시간 흐름 속에서 존재하는 기간을 나타내는 세로선이다.

객체가 언제 메시지를 받고 언제 응답하는지 표현할 때 사용한다.

4-11. 상태

상태는 객체가 특정 시점에 가지고 있는 상황이다.

예를 들어 주문은 결제대기, 결제완료, 배송중, 배송완료 상태를 가질 수 있다.

4-12. 전이

전이는 객체의 상태가 다른 상태로 바뀌는 것이다.

예를 들어 결제가 완료되면 주문 상태가 결제대기에서 결제완료로 전이된다.

4-13. 모델 검증

모델 검증은 작성한 모델이 요구사항과 맞는지 확인하는 작업이다.

모델에 빠진 기능, 잘못된 관계, 모순된 흐름이 없는지 확인한다.

5. 실제 흐름

5-1. UML을 이용한 분석 모델 작성 흐름

UML을 이용한 분석 모델 작성은 보통 다음 순서로 진행된다.

1. 요구사항을 확인한다.

2. 액터를 식별한다.

3. 유스케이스를 식별한다.

4. 유스케이스 다이어그램을 작성한다.

5. 주요 클래스를 찾는다.

6. 클래스 다이어그램을 작성한다.

7. 주요 기능의 처리 순서를 분석한다.

8. 시퀀스 다이어그램을 작성한다.

9. 업무 흐름이 복잡한 기능은 활동 다이어그램으로 정리한다.

10. 상태 변화가 중요한 객체는 상태 다이어그램으로 정리한다.

11. 작성한 분석 모델이 요구사항과 맞는지 검증한다.

5-2. 1단계: 요구사항 확인

먼저 시스템이 무엇을 해야 하는지 확인한다.

예를 들어 게시판 시스템의 요구사항은 다음과 같다.

• 회원은 로그인할 수 있다.

• 회원은 게시글을 작성할 수 있다.

• 회원은 자신의 게시글을 수정할 수 있다.

• 관리자는 모든 게시글을 삭제할 수 있다.

5-3. 2단계: 액터 식별

시스템과 상호작용하는 외부 대상을 찾는다.

게시판 시스템의 액터는 다음과 같다.

• 회원

• 관리자

• 비회원

5-4. 3단계: 유스케이스 식별

액터가 시스템에서 수행하는 기능을 찾는다.

• 로그인

• 게시글 조회

• 게시글 작성

• 게시글 수정

• 게시글 삭제

• 게시글 검색

5-5. 4단계: 클래스 식별

시스템에서 중요한 데이터와 객체를 찾는다.

게시판 시스템의 주요 클래스는 다음과 같다.

• 회원

• 게시글

• 댓글

• 첨부파일

5-6. 5단계: 기능 처리 순서 분석

특정 기능이 어떤 순서로 동작하는지 정리한다.

예를 들어 게시글 작성 기능은 다음 순서로 동작한다.

1. 회원이 글 작성 화면을 연다.

2. 제목과 내용을 입력한다.

3. 등록 버튼을 누른다.

4. 서버가 로그인 여부를 확인한다.

5. 서버가 입력값을 검사한다.

6. 서버가 게시글을 저장한다.

7. 사용자에게 등록 완료 메시지를 보여준다.

5-7. 6단계: 분석 모델 검증

작성한 다이어그램이 요구사항을 빠짐없이 반영하는지 확인한다.

다음 내용을 확인한다.

• 요구사항에 있는 기능이 유스케이스에 포함되었는가

• 필요한 클래스가 빠지지 않았는가

• 기능 처리 순서가 실제 업무 흐름과 맞는가

• 다이어그램끼리 내용이 서로 충돌하지 않는가

6. 예시

6-1. 게시판 시스템 유스케이스 예시

시스템: 게시판 시스템

액터
- 비회원
- 회원
- 관리자

유스케이스
- 비회원: 게시글 조회, 게시글 검색
- 회원: 로그인, 게시글 작성, 게시글 수정, 게시글 삭제, 댓글 작성
- 관리자: 게시글 관리, 댓글 관리, 회원 관리

6-2. 게시판 시스템 클래스 예시

Class: Member
- memberId
- loginId
- password
- name
+ login()
+ logout()
+ updateProfile()

Class: Post
- postId
- title
- content
- createdAt
+ createPost()
+ updatePost()
+ deletePost()

Class: Comment
- commentId
- content
- createdAt
+ createComment()
+ deleteComment()

6-3. 게시글 작성 시퀀스 예시

1. 회원이 글 작성 화면에서 제목과 내용을 입력한다.
2. 회원이 등록 버튼을 클릭한다.
3. 화면은 서버에 게시글 등록 요청을 보낸다.
4. 서버는 로그인 상태를 확인한다.
5. 서버는 입력값을 검사한다.
6. 서버는 데이터베이스에 게시글을 저장한다.
7. 데이터베이스는 저장 결과를 서버에 응답한다.
8. 서버는 화면에 등록 완료 결과를 응답한다.
9. 화면은 등록 완료 메시지를 보여준다.

6-4. 주문 상태 변화 예시

주문접수
→ 결제대기
→ 결제완료
→ 배송준비
→ 배송중
→ 배송완료

7. 코드 또는 설정 설명

7-1. 유스케이스 예시 설명

액터
- 비회원
- 회원
- 관리자

액터는 시스템과 상호작용하는 외부 대상이다.

비회원, 회원, 관리자는 게시판 시스템을 사용하는 대상이므로 액터다.

비회원: 게시글 조회, 게시글 검색

비회원은 로그인하지 않은 사용자다.

비회원은 게시글을 읽고 검색할 수 있지만 글 작성은 할 수 없다고 정리했다.

회원: 로그인, 게시글 작성, 게시글 수정, 게시글 삭제, 댓글 작성

회원은 로그인한 사용자다.

회원은 게시글 작성, 수정, 삭제, 댓글 작성 기능을 사용할 수 있다.

관리자: 게시글 관리, 댓글 관리, 회원 관리

관리자는 시스템을 운영하는 사용자다.

관리자는 일반 회원보다 더 많은 권한을 가진다.

7-2. 클래스 예시 설명

Class: Member

Member는 회원을 표현하는 클래스다.

클래스는 객체를 만들기 위한 설계도다.

- memberId
- loginId
- password
- name

마이너스 기호로 표시한 항목은 속성이다.

속성은 클래스가 가지는 데이터다.

memberId는 회원 번호다.

loginId는 로그인 아이디다.

password는 비밀번호다.

name은 회원 이름이다.

+ login()
+ logout()
+ updateProfile()

플러스 기호로 표시한 항목은 메서드다.

메서드는 클래스가 수행하는 기능이다.

login은 로그인 기능이다.

logout은 로그아웃 기능이다.

updateProfile은 회원 정보 수정 기능이다.

7-3. 시퀀스 예시 설명

화면은 서버에 게시글 등록 요청을 보낸다.

화면은 사용자가 보는 클라이언트 영역이다.

서버는 요청을 처리하는 프로그램이다.

게시글 등록 요청은 화면에서 서버로 보내는 메시지다.

서버는 데이터베이스에 게시글을 저장한다.

데이터베이스는 데이터를 저장하는 공간이다.

서버는 사용자가 입력한 제목과 내용을 데이터베이스에 저장한다.

서버는 화면에 등록 완료 결과를 응답한다.

서버는 저장 결과를 다시 화면에 알려준다.

화면은 그 결과를 사용자에게 보여준다.

7-4. 상태 변화 예시 설명

주문접수 → 결제대기 → 결제완료 → 배송준비 → 배송중 → 배송완료

이 예시는 주문 객체의 상태 변화를 나타낸 것이다.

주문은 처음에 접수된다.

결제를 기다린다.

결제가 끝나면 배송 준비 상태가 된다.

배송이 시작되면 배송중 상태가 된다.

배송이 끝나면 배송완료 상태가 된다.

8. 주의점

8-1. UML은 프로그래밍 언어가 아니다

UML은 코드를 작성하는 언어가 아니다.

UML은 시스템 구조와 동작을 그림으로 표현하는 모델링 언어다.

Java, Python, C 같은 프로그래밍 언어와 구분해야 한다.

8-2. 유스케이스 다이어그램과 시퀀스 다이어그램을 구분해야 한다

유스케이스 다이어그램은 사용자와 기능의 관계를 보여준다.

시퀀스 다이어그램은 기능이 실행되는 시간 순서를 보여준다.

8-3. 클래스와 객체를 구분해야 한다

클래스는 객체를 만들기 위한 설계도다.

객체는 클래스를 바탕으로 실제 만들어진 대상이다.

예를 들어 Member는 클래스다.

회원번호가 1번인 특정 회원은 객체다.

8-4. 활동 다이어그램과 상태 다이어그램을 구분해야 한다

활동 다이어그램은 작업 흐름을 표현한다.

상태 다이어그램은 객체의 상태 변화를 표현한다.

8-5. 다이어그램을 예쁘게 그리는 것보다 의미가 중요하다

UML은 그림을 예쁘게 그리기 위한 것이 아니다.

시스템을 정확하게 이해하고 전달하기 위한 것이다.

액터, 기능, 클래스, 메시지, 상태가 요구사항과 맞게 표현되어야 한다.

8-6. 요구사항과 다이어그램이 맞아야 한다

요구사항에 있는 기능이 다이어그램에 빠지면 안 된다.

다이어그램에 있는 기능이 요구사항에 없다면 추가 확인이 필요하다.

분석 모델은 요구사항과 일치해야 한다.

8-7. 다이어그램끼리 내용이 충돌하면 안 된다

유스케이스 다이어그램에서는 회원이 게시글을 삭제할 수 있다고 했는데, 시퀀스 다이어그램에서는 관리자인 경우만 삭제된다고 표현하면 충돌이다.

다이어그램끼리 같은 기준으로 작성해야 한다.

9. 요약

UML은 소프트웨어의 구조와 동작을 그림으로 표현하는 통합 모델링 언어다.

분석 모델은 요구사항을 분석해서 시스템이 무엇을 해야 하는지 정리한 모델이다.

유스케이스 다이어그램은 액터와 기능의 관계를 표현한다.

클래스 다이어그램은 클래스, 속성, 메서드, 관계를 표현한다.

시퀀스 다이어그램은 객체 간 메시지 흐름을 시간 순서대로 표현한다.

활동 다이어그램은 업무나 기능의 처리 흐름을 표현한다.

상태 다이어그램은 객체의 상태 변화를 표현한다.

정보처리기사 실기에서는 각 다이어그램이 무엇을 표현하는지 구분하는 것이 중요하다.

10. 핵심 용어 정리

UML = 소프트웨어 구조와 동작을 그림으로 표현하는 통합 모델링 언어

모델링 = 복잡한 대상을 이해하기 쉽게 단순화해서 표현하는 작업

분석 모델 = 요구사항을 분석해서 시스템이 해야 할 일을 표현한 모델

다이어그램 = 구조나 흐름을 그림으로 표현한 것

구조 다이어그램 = 시스템의 정적인 구조를 표현하는 다이어그램

행위 다이어그램 = 시스템의 동적인 동작을 표현하는 다이어그램

유스케이스 다이어그램 = 액터와 시스템 기능의 관계를 표현하는 다이어그램

유스케이스 = 사용자가 시스템을 통해 수행하는 기능

액터 = 시스템과 상호작용하는 외부 대상

클래스 다이어그램 = 클래스, 속성, 메서드, 관계를 표현하는 다이어그램

클래스 = 객체를 만들기 위한 설계도

객체 = 클래스를 바탕으로 실제 만들어진 대상

속성 = 객체가 가지는 데이터

메서드 = 객체가 수행하는 기능

관계 = 객체나 클래스 사이의 연결

시퀀스 다이어그램 = 객체들이 시간 순서에 따라 주고받는 메시지를 표현하는 다이어그램

메시지 = 객체나 시스템 구성 요소 사이에서 주고받는 요청이나 응답

생명선 = 시퀀스 다이어그램에서 객체가 시간 흐름 속에서 존재하는 기간을 나타내는 선

활동 다이어그램 = 업무나 기능의 처리 흐름을 표현하는 다이어그램

활동 = 처리해야 하는 작업

상태 다이어그램 = 객체의 상태 변화를 표현하는 다이어그램

상태 = 객체가 특정 시점에 가지고 있는 상황

전이 = 객체의 상태가 다른 상태로 바뀌는 것

분석 모델 검증 = 작성한 분석 모델이 요구사항과 맞는지 확인하는 작업

객체지향 = 프로그램을 객체 중심으로 구성하는 개발 방식

요구사항 = 사용자가 시스템에 원하는 기능이나 조건