- UML 이란, 개발자간 원활한 의사소통을 위해 소프트웨어 공학에서 사용되는 표준화된 범용 모델링 언어입니다.
소프트웨어 개발시 무엇을 만들어야 하는지에 대한 요구사항을 분석하는 과정에서 간단하게 만들고 간단하게 수정해 나가며 구체화 할 때 사용하면 좋은 모델링 방식이기에,
작성 및 수정이 쉽고 직관적이어서 누구나 이해하기 쉬운 것이 특징입니다.
- 아래 정리글로 인하여 UML 을 작성하여 소프트웨어 개발 요구사항을 시각적으로 모델링 하는 방법을 알아보겠습니다.
참고로 실제 개발에 UML 을 적용할 때에는 draw.io 라는 무료 다이어그램 제작 툴을 사용하는 것을 추천합니다.
[UML 설명]
1. 사물
다이어그램 안에서 관계가 형성 될 수 있는 대상입니다.
아래와 같은 종류의 사물이 있습니다.
구조 사물 : 개념적, 물리적 요소(Class Interface, Usecase, Node, ...)
행동 사물 : 각 요소들의 행위, 상호작용
그룹 사물 : UML 요소들의 그룹
주해 사물 : 부가적 설명, 주석
2. 관계
사물과 사물 간의 연관성을 표현한 것입니다.
자세한 내용은 아래에 기술합니다.
3. 다이어그램
사물과 관계를 정형화된 도형으로 표현한 것입니다.
만약 다이어그램으로 표현하지 않는다면 사물과 관계를 글로 서술해야 하는데,
다이어그램으로 시각적으로 표현한다면 보다 알기 쉽고 적합하고 효율적이고 의사소통에 도움이 되는 장점이 있습니다.
다이어그램은 6개의 구조적(정적) 다이어그램과 7개의 행위(동적) 다이어그램이 있습니다.
자세한 내용은 아래에 기술합니다.
4. 스테레오 타입
위와 같은 UML 기본 요소 이외에 추가적인 의미나 역할을 부여하기 위해 사용되는 확장 메커니즘입니다.
마치 태그처럼 UML 요소가 어떤 특정한 역할이나 성격을 가지는지를 추가적으로 표시해줍니다.
<<>> 기호를 사용하여 표현하며, 특별한 규칙은 없지만 일반적으로 사용되는 종류가 아래와 같습니다.
1. <<include>> : 관계 요소에 표시되며, 관계된 유스케이스를 반드시 실행해야 하는 포함 관계를 나타냄
2. <<extend>> : 관계 요소에 표시되며, 관계된 유스케이스를 선택적으로 실행하는 확장 관계를 나타냄
3. <<interface>> : 클래스 요소에 표시되며, 추상 메소드만으로 이루어진 상태를 나타냄
4. <<entity>> : 처리 과정에서 기억 장치에 저장될 정보들을 나타냄 (DB 테이블, 객체 모델에 표시)
5. <<boundary>> : 사용자와 시스템 간의 경계를 나타냄
6. <<control>> : 시스템의 기능 및 제어를 담당함을 나타냄
[UML 관계 설명]
- UML 의 관계의 종류는 연관, 집합, 포함, 일반화, 의존, 실체화 관계가 있습니다.
(연관(Association) 관계)
- 둘 이상의 사물이 서로 어떠한 참조 관계로 연결되어 있음을 나타냅니다.
사물간의 관계가 지속적으로 유지되는 관계입니다.
단방향 관계라면 실선 화살표로 표현하고,
양방향 관계일 경우에는 실선으로만 표현하며,
연관 사물의 다중도는 사물 관계의 양 끝단에 표기합니다.
- 사물의 다중도란,
1 대 1 관계, 1 대 n 관계와 같이 한 사물에 연결된 다른 사물이 여러개가 될 수 있는지 어떤지를 말하는 것입니다.
예를들어 학습 관리 서비스에서 학습자라는 하나의 사물과 '수강한다' 라는 관계로 연결된 강의라는 사물은,
학습자가 1, 강의가 n 의 관계를 가지고 있는 것과 같습니다.
UML 에서 다중도의 표시법으로는,
* 는 없거나 다수라는 의미,
n 은 n개라는 의미,
n..m 은 최소 n개에서 최대 m개라는 의미,
n..* 은 n개 이상이라는 의미입니다.
모든 관계는 다중도를 표현할 수 있으므로 아래부터는 생략합니다.
- 연관 관계의 예시는 아래와 같습니다.
도서 대여 서비스에서 한 고객이 여러 도서를 대여할 수 있고,
한 도서가 여러 고객에게 대여될 수 있으므로 위와 같이 상호 * 로 표현하고,
블로그 관리 시스템에서 블로그 관리자 한명이 관리할 수 있는 블로그는 최소 1개에서 3개까지이지만, 블로그는 한명의 관리자에 의해 관리된다는 것을 의미합니다.
객체 지향 프로그래밍적으로 설명하자면,
블로그 관리자라는 하나의 클래스 안에 블로그 리스트가 존재하고, 이 안에는 1개에서 3개 까지의 블로그를 입력할 수 있는 것입니다.
class Blog {
private String title;
private String author;
}
class BlogAdmin {
// Blog 객체 1개에서 3개 입력 가능(1개는 생성자에서 무조건 생성하도록 처리)
private List<Blog> blogList;
...
}
(의존(Dependency) 관계)
- 의존 관계란, 연관관계와 비슷하지만 관계가 지속되지 않는다는 차이점이 있습니다.
연관관계 예시에서 블로그 관리자는 블로그를 참조하고 있지요?
이는 꼭 관리한다는 기능뿐 아니라 글을 쓴다, 글을 본다 등의 기능에도 사용되며, 사물을 '소유'하고 있는 것과 같습니다.
쉽게 이해하기 위해 프로그래밍 코드로 보자면,
Class BlogAdmin{
private Blog blog;
public void writeBlog(String content){
blog.write(content);
}
public String readBlog(){
return blog.read();
}
}
위와 같이 블로그 관리자가 블로그를 소유한 상태에서 여러 메소드에서 이를 이용하는 것을 볼 수 있습니다.
하지만 의존 관계는 일시적으로만 참조가 일어나며,
예를 들자면, '축제'라는 이름의 사물이 작년 '오프닝 이벤트'와 이번 년도에 하는 '오프닝 이벤트'가 다를 수 있습니다.
즉, 축제라는 사물에 있어 오프닝 이벤트를 실행하는 시점에 따라 이벤트가 달라질 수 있다는 것이죠.
이 역시 쉽게 이해하기 위해 프로그래밍 코드를 보자면,
public class Festival{
public void doOpeningEvent(OpeningEvent event){
event.do();
}
}위와 같이 페스티발 사물이 오프닝 이벤트를 수행하는 시점에만 오프닝 이벤트 사물이 결정되고 사용되는 것을 확인 할 수 있습니다.
즉, 오프닝 이벤트가 실행되는 일시적 시점에서만 축제 사물과 오프닝 이벤트 사물간 관계가 성립한다는 것입니다.
의존 관계의 표현 방법은,
사물의 변화(= 입력받는 event 의 변화)에 영향을 받는 사물(= 페스티발)에서 영향을 주는 사물(= OpeningEvent) 쪽으로 점선 화살표로 표현합니다.
(집합(Aggregation) 관계)
- 집합 관계란, 사물이 다른 사물에 포함되어 있다는 것을 표현합니다.
전체(whole) 와 부문(part)으로 나뉘며,
집합 관계는 전체도 부분도 상호간 독립성을 가집니다. (부분 사물이 없어도 전체 사물이 성립하고, 전체 사물이 없어도 부분 사물이 성립됨. 예를들면 책과 책갈피의 관계가 있습니다.)
전체 사물 쪽에 속이 빈 마름모를 붙인 실선으로 표현합니다.
객체지향 프로그래밍으로 설명하자면,
집합 관계는 Nullable 변수가 포함된 상태입니다.
책갈피를 참조하는 책 클래스는 책갈피가 없어도 성립합니다.
// 부분 클래스
class Bookmark {
private int pageNumber;
private String note;
}
// 전체 클래스 (Aggregation: has-a 관계)
class Book {
private String title;
private List<Bookmark> bookmarks;
}
(포함(Composition) 관계)
- 집합 관계와 비슷하게 한 사물이 다른 사물에 포함되어 있는 것을 표현하는 것은 마찬가지이지만,
전체와 부분이 종속성을 가진 것이 다릅니다. (예를들면 자동차와 타이어의 관계와 같습니다.)
전체 사물 쪽에 속이 찬 마름모를 붙인 실선으로 표현합니다.
객체지향 프로그래밍으로 설명하자면,
포함 관계는 필수 객체로, 상위 클래스의 생성자 실행 시점에 준비되어 있어야만 성립되는 것입니다.
class Tire {
private String position;
}
class Car {
private List<Tire> tires;
public Car(List<Tire> tires) {
if (tires == null || tires.size() != 4) {
throw new IllegalArgumentException("자동차에는 정확히 4개의 타이어가 필요합니다.");
}
this.tires = tires;
System.out.println("🚗 자동차가 생성되었습니다. (4개의 타이어 포함)");
}
}
(일반화(Generalization) 관계)
일반화 관계는, 하나의 사물이 다른 사물들에 대해 상하위 관계를 가지는 것을 표현한 것입니다.
상위 사물은 하위 사물들의 공통적인 속성을 가진 사물을 의미하며,
하위 사물은 상위 사물에 대한 구체적 속성을 가진 사물들의 집합입니다.
"하위 사물 a 는 상위 사물 A의 일종이다"
라는 문장이 성립되어야 합니다. (상위 사물은 하위 사물들을 일반화 합니다.)
예를들어 상위 사물이 스마트폰이고, 하위 사물이 갤럭시, 아이폰, 샤오미 라면,
갤럭시는 스마트폰의 일종이다.
라는 문장이 성립되죠.
표현법은,
하위 사물에서 상위 사물 쪽으로 속이 빈 삼각형의 실선 화살표로 나타냅니다.
객체지향 프로그래밍으로 설명하자면,
일반화 관계는 클래스나 추상 클래스를 상위 클래스로 두고, 하위 클래스에서 이를 상속받아 정의하는 것입니다.
class Smartphone {
private String brand;
public Smartphone(String brand) {
this.brand = brand;
}
public void call(String number) {
System.out.println(brand + "에서 " + number + "로 전화를 겁니다.");
}
public void browseInternet() {
System.out.println(brand + "로 인터넷을 검색합니다.");
}
}
class GalaxyS100 extends Smartphone {
public GalaxyS100() {
super("Samsung Galaxy S100"); // 상위 클래스 생성자 호출
}
// GalaxyS100만의 기능
public void useSpen() {
System.out.println("S펜을 사용하여 필기합니다.");
}
}
(실체화(Realization) 관계)
실체화 관계는 일반화 관계와 유사하지만, 상위 사물이 실체가 없다는 것이 다릅니다.
일반화 관계의 상위 사물은 스마트폰, 자동차, 컴퓨터와 같이 하위 사물이 '되려고 하는(to be)' 사물을 의미하는데,
실체화 관계는, 상위 사물이 '복제 가능(Clonable)', '움직여짐(Movable)', '판매 가능(Sellable)' 과 같이 사물의 속성을 의미하고, 하위 사물들에서 이를 구체적으로 실체화 한 개념입니다.
"하위 사물은 상위 사물을 할 수 있다"
라는 문장이 성립되어야 하며,
예를들어 구매 가능(Buyable) 사물에 대해선 Buyable book, Buyable Tools 등 상위 사물의 속성이 하위 사물과 결합하여 실체화 된 것입니다.
표현법은,
하위 사물에서 상위 사물쪽으로 속이 빈 삼각형의 점선 화살표로 나타냅니다.
객체지향 프로그래밍으로 설명하면,
실체화 관계는 완전히 추상적인 interface 를 하위 클래스에서 상속받아 구현하는 것을 의미합니다.
// 완전한 추상적 인터페이스: 구매 가능
interface Purchasable {
void purchase(String buyer);
double getPrice();
}
// 장난감 클래스가 인터페이스를 실체화 (구현)
class Toy implements Purchasable {
private String name;
private double price;
public Toy(String name, double price) {
this.name = name;
this.price = price;
}
@Override
public void purchase(String buyer) {
System.out.println(buyer + "님이 \"" + name + "\" 장난감을 구매하였습니다.");
}
@Override
public double getPrice() {
return price;
}
public void play() {
System.out.println(name + " 장난감으로 재미있게 놀아요!");
}
}
[UML 구조적(Structural) 다이어그램 설명]
- 구조적 다이어그램은 정적 다이어그램이라고도 하며,
설계의 뼈대, 구조, 구성요소들 간의 연결관계를 중심으로 다룹니다.
'어떤 것이 있는가?'를 보여줍니다.
(클래스(Class) 다이어그램)
- 클래스 다이어그램의 클래스는, 객체지향 프로그래밍에서의 클래스와 같습니다.
고로 객체 지향 프로그래밍 방식으로 개발을 진행할 때 이해하기도 쉽고 구현하기도 수월한 설계 형태입니다.
클래스란, 현실 세계의 객체를 나타내는 설계도입니다.
예를들어 자동차라는 실체를 분해하자면, 자동차 프레임, 기어, 타이어, 와이퍼, 엔진 등의 자동차에 소속된 부속들과,
기어 변경, 가속, 감속, 핸드브레이크, 창문 열기, 창문 닫기 와 같은 자동차가 수행하는 기능들로 이루어집니다.
이를 클래스로 표현하자면,
부속들은 클래스에 소속된 변수, 즉 멤버변수가 되고,
기능들은 클래스에 정의된 함수, 즉 메소드가 됩니다.
class Car{
public Tire tire;
public Window window;
private Gear gear;
private Engine engine;
....
protected void engineStart(){
....
}
protected void engineStop(){
....
}
public int goLeft(int angle){
....
}
....
}
위와 같이 변수와 메소드로 표현되는 클래스를 확인할 수 있고,
이러한 클래스를 다이어그램으로 나타내고 클래스 다이어그램간 관계를 표현하는 것이라고 이해하면 됩니다.
클래스 다이어그램을 작성하면 시스템의 구조와 문제점의 파악이 가능해집니다.
- 클래스 접근 제어자
객체지향 프로그래밍의 특징 중 하나는 정보 은닉입니다.
클래스 단위로 묶은 변수나 함수를 외부에서 접근 못하게 막아 해당 변수나 함수가 조작될 수 있는 범위를 줄여서 디버그가 용이하게 해줍니다. (만약 관련된 위치에 에러가 발생하면 해당 부분에 접근 가능한 곳만 확인하면 되고, 조작 불가능한 곳은 고려하지 않아도 됩니다.)
누가 해당 변수나 함수를 사용할 수 있을지를 제한하는 것을 접근 제어자라고 하며,
private(-) : 클래스 내부에서만 접근 허용
public(+) : 클래스 외부에서도 접근 허용
protected(#) : 동일 패키지 및 자식 클래스에서만 접근 허용
default(~) : 동일 패키지 클래스에서의 접근만 허용
위와 같은 종류가 있습니다. (다이어그램에서 표현시 괄호 안의 기호 사용)
예시 다이어그램 도표는 위와 같고,
관계 표시는 위에서 설명한 대로 표시하면 됩니다.
(객체(Object) 다이어그램)
- 객체 다이어그램은, 인스턴스간의 관계를 나타내는데 사용되며, 특정 시점의 시스템 구조를 파악하는 데에 사용되는 다이어그램입니다.
인스턴스란, 클래스를 기반으로 만들어진 객체를 의미합니다.
흔히 객체지향 프로그래밍을 설명할 때, 클래스는 붕어빵의 틀이고, 인스턴스는 붕어빵이라고 표현합니다.
위 클래스 다이어그램에서 본 것처럼, 해당 클래스를 구성하는 변수들과 함수들을 정의하였다면, 이를 기반으로 만들어진 것이 인스턴스죠.
코드상으로 보면 더 이해가 편합니다.
class Car{
public Tire tire;
public Window window;
private Gear gear;
private Engine engine;
....
protected void engineStart(){
....
}
protected void engineStop(){
....
}
public int goLeft(int angle){
....
}
....
}
위 클래스가 있을 때, 이를 인스턴스로 만든다는 것은,
public Car car1 = new Car();
public Car car2 = new Car();
위의 예시와 같이 new 를 사용하여 클래스를 객체 변수로 할당하는 것이 인스턴스화라고 말합니다.
같은 클래스를 기반으로 인스턴스를 몇개든 여러개 만들 수 있죠.
- 보통의 경우 클래스 다이어그램만으로 충분합니다.
하지만 객체 다이어그램은 클래스 다이어그램만으로는 표현할 수 없는 유형의 정보를 표현할 때 사용하는 부가적인 방법으로 쓰이는 것이 일반적입니다.
- 객체 다이어그램 요소
객체 : 사각형 안에 객체명:클래스명 형식으로 표현합니다.(ex : kim:Person)
객체명을 입력하지 않으면 익명 객체입니다.(ex : :Person)
속성 값 : 사각 인스턴스를 이름만으로 표현하는 것이 부족하다면 속성값을 추가 표시할 수 있습니다.
(ex : name = "Kildong", age = 30)
링크 : 인스턴스간의 관계는 사각형간에 실선을 연결하여 자유롭게 관계를 설명합니다.(ex : 소유한다, 관리한다)
인스턴스 관계에 1:1, 1:n, n:n 과 같은 다중도를 표현할 수도 있습니다.
일반적 UML 관계를 표현할 수도 있습니다.
- 객체 다이어그램 예시
객체 다이어그램의 예시는 위와 같습니다.
가장 위와 같은 Car 클래스는 클래스 다이어그램에 대한 예시이고,
이를 기반으로 만든 Car 객체는 여러개가 될 수 있습니다.
위 예시에선 이에 myCar 라는 이름을 붙인 것입니다.
kim 이라는 Person 객체가 myCar 객체와 '소유하다'라는 관계를 가지고 있다고 표현하였습니다.
(컴포넌트(Component) 다이어그램)
- 컴포넌트는 객체 지향 프로그래밍에서 객체를 정보화한 클래스와 유사하다고 볼 수 있는데,
앞서 이해한 클래스와의 차이점으로 컴포넌트를 파악하면 보다 쉽게 이해가 가능할 것입니다.
클래스는 객체에 대한 논리적 단위이며, 데이터와 기능을 묶는 추상화 수단이며, 실행되거나 배포되는 단위가 아니지만,
컴포넌트란 실제 실행 가능한 단위입니다. (클래스를 기반으로 설명하자면, 컴포넌트 하나를 구현하기 위해 클래스가 여러개 포함되어 있을 수 있습니다.)
위 링크의 설명에서 React 에서 컴포넌트를 어떻게 정의하였는지를 프로그래밍적으로 볼 수 있는데,
HTML 기반의 웹 화면이 있다면, HTML, JavaScript, CSS 를 하나로 묶어서 분리한 개념으로서, 컴포넌트 하나만 가지고 해당 컴포넌트의 HTML 과 그에 연관된 리소스들을 실행시키기만 하면 '한 화면'에 대하여 실제로 구동이 가능하다는 것이 특징이며,
설계상 컴포넌트의 개념은 클래스, 인터페이스, 리소스 등을 실제 실행 가능한 최소 단위로 묶어서 분리해둔 개념이라 생각하면 됩니다.
- 컴포넌트 다이어그램의 작성 방법을 예시로 보겠습니다.
위 다이어그램은 ID 정책 관리자 서비스의 컴포넌트를 표현한 것입니다.
우측 상단에 아이콘(모듈을 의미)이 붙은 사각형으로 표현되는 것이 각 컴포넌트로,
보다시피 컴포넌트 상단 중앙에는 컴포넌트 이름을 적을 수 있고, 컴포넌트 안에는 해당 컴포넌트를 구성하는 하위 컴포넌트도 존재할 수 있습니다.
일반적인 연관관계나 스테레오타입은 위에서 설명한대로 작성이 가능한데,
다른점으로, 위에서 표시된, 컴포넌트 끝자락의 작은 사각형은 포트로, 컴포넌트와 컴포넌트간 정보 교류의 입/출구 역할을 합니다.
또한 -( 이렇게 생긴 부분은 인터페이스 요청 부분으로, 이러한 기능을 요구한다는 의미입니다.
예를들어 주문 컴포넌트가 있을 때, 추적 상태 조회에 대한 정보가 외부에서 주어져야 한다면 이를 표시합니다.
반대로, -O 이렇게 생긴 부분은, 인터페이스 제공 부분으로, 이러한 기능을 제공한다는 의미입니다.
예를 들면 앞서 주문 컴포넌트가 요청하는 추적 상태 조회 기능을 제공하는 배송 추적 컴포넌트가 있다고 할 때 이를 표시하며,
두 인터페이스가 합쳐지면,
[주문 컴포넌트]--(O--[배송 추적 컴포넌트]
이렇게 연결됩니다.
(배치(Deployment) 다이어그램)
- 소프트웨어 시스템이 실제 하드웨어 환경에서 어떻게 배치(deploy) 되는지를 나타내는 다이어그램입니다.
즉,
어떤 소프트웨어 요소(컴포넌트, 애플리케이션 등)가,
어떤 하드웨어 노드(서버, 클라이언트, 디바이스 등)에,
어떻게 배치되고 연결되는지를 시각적으로 보여줍니다.
- 배치 다이어그램의 주요 요소는 아래와 같습니다.
| 요소 | 설명 | UML 기호 |
| 노드(Node) | 물리적 장치 (서버, PC, 모바일 등) 또는 실행 환경 (JVM 등) | 큼직한 3D 상자 |
| 아티팩트(Artifact) | 배치되는 실제 산출물 (예: .jar, .war, 실행파일 등) | 작은 네모 |
| 컴포넌트(Component) | 아티팩트를 포함한 논리적 기능 단위 | UML 컴포넌트 기호 |
| 연결(Association) | 노드 간의 통신 경로 | 선(—) 또는 화살표 |
| 노드 내 포함 관계 | 노드 내부에 아티팩트 또는 컴포넌트를 배치 | 노드 박스 안에 포함시켜 표현 |
위와 같이 직관적이고 간단히 노드, 아티펙트와 그에 대한 연결 관계를 표시합니다.
(복합체 구조(Composite Structure) 다이어그램)
- 클래스나 컴포넌트의 내부 구조를 보다 세밀하게 표현할 때 사용하는 다이어그램입니다.
특히나 앞서 컴포넌트 다이어그램 설명에서 컴포넌트는 내부에 여러개의 컴포넌트나 여러개의 클래스가 포함되어 있을 수 있다고 했는데, 이를 표현할 때 유용합니다.
- 다이어그램 구성요소는 아래와 같습니다.
| 개념 | 설명 | UML 기호 |
| Classifier | 복합 구조를 정의하는 상위 클래스 (예: 시스템, 컴포넌트 등) | 사각형 박스 |
| Part | 전체의 일부가 되는 구성 요소. 보통 속성과 연결됨 (컴포넌트, 서브클래스 등) | 내부에 이름 붙은 사각형 |
| Port | 외부와 통신하는 인터페이스 지점 | 작은 사각형(◻︎) |
| Connector | 파트들 간 연결 | 선 또는 라인 |
| Interface / Role | 해당 파트가 수행하는 역할이나 제공/요구하는 인터페이스 | 포트 옆 <<interface>> 형태 |
예를 들자면,
위와 같은 컴포넌트 다이어그램이 있을 때,
위 컴포넌트 내부의 상세 정보를 표현하기 위하여 복합체 구조 다이어그램을 작성하면,
이처럼 보다 상세한 내부 정보를 표현할 수 있습니다.
(패키지(Package) 다이어그램)
- 클래스, 컴포넌트, 인터페이스 등을 논리적 단위인 패키지로 그룹화하고,
그들간의 의존관계를 시각적으로 표현하는 다이어그램입니다.
쉽게 말하자면,
클래스/모듈들이 어떤 그룹에 속하는지 묶어내고,
어떤 패키지에 의존하는지를 보여주는 구조도입니다.
- 다이어그램 예시는 아래와 같습니다.
위와 같이 기존 클래스나 컴포넌트 다이어그램을 감싸는 역할을 하며, 패키지 안에 서브 패키지로 그루핑 할 수 있습니다.
관계 표시도 앞서 설명한대로 하면 됩니다.
[UML 행위적(Behavioral) 다이어그램 설명]
- 행위적 다이어그램은 동적 다이어그램이라고도 하며,
시스템이 어떻게 작동하는지에 대한 행동과 상호작용을 표현합니다.
사용자의 행동, 이벤트 처리, 객체 간 메시지 교환, 상태 변화 등을 보여주며,
'무엇을 하는가?'를 보여줍니다.
(유스케이스(Use case) 다이어그램)
- UML 다이어그램중 가장 직관적이기에 초기 분석 단계에서 자주 사용하는 다이어그램입니다.
시스템이 사용자 또는 외부 시스템과 어떤 방식으로 상호작용하는지를 도표로 보여줍니다.
한마디로,
누가 무엇을 할 수 있는지를 한눈에 보여주는 다이어그램입니다.
- 다이어그램 구성요소
| 요소 | 설명 | UML 기호 |
| 액터(Actor) | 시스템과 상호작용하는 외부 주체 (사람, 다른 시스템 등) | 사람 아이콘 혹은 이름 |
| 유스케이스(Usecase) | 시스템이 액터에게 제공하는 기능/서비스(~을 한다 와 같은 동사로 표) | 타원영 안에 기능 이름 |
| 시스템 경계(System Boundary) | 시스템이 제공하는 기능의 범위 | 사각형 박스 |
| 관계(Relationship) | 액터와 유스케이스, 유스케이스 간 연결 | 실선, 점선, 화살표 등 |
간단히 위와 같은 예시로 한꺼번에 설명이 가능합니다.
사용자(사람 모양 아이콘)는 시스템(사각형 영역) 바깥에서 시스템을 바라보고 있고,
시스템 안에는 해당 시스템을 사용할 수 있는 여러 사용 케이스(usecase) 들이 존재합니다.
사용자는 사용케이스를 사용한다는 의미로 실선으로 연결합니다.(사용자가 예약 상품 조회와 예약 신청을 조작)
유스케이스끼리는 특별한 관계 표현이 가능합니다.
실선 삼각형 화살표는 하위 유스케이스로 상위 유스케이스를 구체화 한 의미입니다.
위에서는 단순히 예약 상품을 조회한다는 기능인데, 이는 상품명으로 검색해서 조회하거나 판매자로 검색해서 조회하는 기능을 제공합니다.
예약한다에서 이어지는 <<include>> 점선 화살표는, 포함관계로, 시작 유스케이스를 실행하기 위해선 도착 유스케이스가 선행되어야 한다는 의미입니다.(예약을 하려면 로그인을 먼저 해야함)
마지막으로 예약한다로 이어지는 <<extend>> 점선 화살표는 확장관계로, 도착 유스케이스의 기능에 대해 Optional 한 추가 기능이 붙는 것을 의미합니다.(그냥 예약을 할 수도 있고, 추가 서비스를 선택할 수도 있음)
(절차(Sequence) 다이어그램)
(통신(Communication) 다이어그램)
(상태(State) 다이어그램)
(활동(Activity) 다이어그램)
(상호작용(Interaction Overview) 다이어그램)
(타이밍(Timing) 다이어그램)
'Study > Computer Science' 카테고리의 다른 글
| [정보 처리] 6. 공학적 응용 소프트웨어 설계 방식 (0) | 2025.04.10 |
|---|---|
| [정보 처리] 5. 공학적 화면 설계 방식 (0) | 2025.04.09 |
| [정보 처리] 3. 소프트웨어 개발 요구사항 분석기법 (0) | 2025.04.05 |
| [정보 처리] 2. 소프트웨어 개발 모델 최적화 (0) | 2025.04.03 |
| [정보 처리] 1. 소프트웨어 개발 방법론 (0) | 2025.04.03 |