UML?

- UML: 시스템이 상호작용하는 측면, 시스템 전체 구조 측면, 컴포넌트간의 관계등을 시각적으로 볼 수 있게 나타낸 도면
- 유스케이스 다이어그램을 작성해 실제 프로젝트의 윤곽을 잡을 수 있음
모든 다이어그램을 사용하지는 않고 프로젝트에 맞는 3-5개 정도의 다이어그램을 그리게 됨
유스케이스 다이어그램

- 시스템에서 제공해야하는 기능이나 서비스를 명세하는 단계에 사용하는 다이어그램으로 사용자와 시스템 사이에 상호작용을 보여줄 수 있음
- 유스케이스 다이어그램은 시스템이 제공하는 기능을 나타내는 유스케이스와 기능을 사용하는 액터 사이의 관계로 나타냄
액터
- 시스템의 기능을 사용하는 사용자를 의미하며, 세부적으로 사용자 액터, 시스템 액터, 주요 액터, 보조 액터, 프록시 액터로 나눌 수 있음
사용자 액터(user actor): 시스템을 사용하는 사람으로 액터의 대부분을 차지함
시스템 액터(system actor): 프로젝트의 개발 범위에 바깥에 있는 시스템
주요 액터(primary actor): 시스템에 작업의 실행을 요구하는 능동적 입장의 액터, 그림의 다이어그램에서는 시스템을 사용하는 소비자들이 해당됨
보조 액터(secondary actor): 유스케이스로부터 요청, 메시지를 받아 수동적으로 작업을 하는 액터로 그림에서는 결제서비스, 인증, 정보 제공자 등이 해당됨
프록시 액터(proxy actor): 액터와 시스템의 중간에서 무언가를 대신해주는 액터
- 액터의 이름은 역할을 나타내며, 분명하게 작성해야함. 만약 시스템 액터일 경우는 해당 시스템의 이름을 그대로 사용하는 것이 좋음
유스케이스
- 사용자가 시스템을 통해 사용하고 싶은 기능
- 실제로 코딩할 수 있을 정도의 작은 단위의 기능
- 여러 유스케이스가 모여 하나의 서브시스템을 이루고, 서브시스템이 모여 하나의 개발 시스템이 됨
- 개발자가 유스케이스를 찾지만, 사용자 관점에서 유스케이스를 정의해야 함
- 유스케이스의 이름은 동사형 명사를 사용하고, 사용자가 시스템을 통해 얻으려는 최종 목적이 나타나는 이름을 사용함
- 정상적인 소프트웨어의 흐름인 기본 흐름 이외에도 예외적인 상황을 고려한 대안 흐름이 포함된 이벤트 흐름을 유스케이스 안에 포함해야함
액터와 유스케이스 간의 관계
- 액터와 유스케이스, 또는 액터간의 관계를 나타날 때는 화살표를 통해 나타냄
- 그림에서의 Web Customer처럼 액터 사이에 일반화 관계를 설정해 다이어그램을 단순화할 수 있음
- 유스케이스의 일부 기능은 다른 유스케이스에서도 공통으로 사용되는 경우가 있는데 이 경우에는 점선을 사용해 포함관계를 나타냄, 이 때 스테레오 타입으로
<<include>>
를 표기함
다른 작업을 먼저해야하는 관계인 선행 조건과 혼동하지 않도록 주의
- 특정한 경우에만 다른 유스케이스가 필요한 경우 점선을 사용해 확장관계를 나타냄, 이 때 화살표 방향은 포함관계와 반대방향이며, 스테레오 타입으로
<<extend>>
를 표기함
다이어그램
1. 클래스 다이어그램

- 여러 클래스들간의 관계를 나타내는 다이어그램
- 클래스 이름은 파스칼 케이스로 사용하며, 다른 클래스와 구별되는 유일한 이름을 가짐
- 속성은 클래스가 갖는 정적인 특성을 의미함
- 메서드는 클래스가 외부의 다른 객체에 제공할 서비스와 기능들이며, 외부 클래스는 메서드를 통해 해당 클래스를 통해 해당 클래스에 접근할 수 있음
- 가시성은 속성과 메서드의 접근 권한을 지정하는 방법으로 아래 표와 같은 유형이 있음
가시성 | 설명 |
---|
공개(Public) | 클래스 외부에서 자유롭게 읽고, 수정할 수 있음, 따로 설정하지 않는 경우 기본값 |
은닉(Private) | 해당 클래스의 메서드를 통해서만 접근할 수 있으며, 자바스크립트에서는 #을 붙여 사용가능 |
부분 공개(Protected) | 해당 클래스의 메서드와 클래스를 상속받은 하위 클래스만 접근할 수 있으며, 자바스크립트에서는 타입스크립트를 사용하지 않는 경우 get/set 함수와 언더바를 붙여 암묵적으로 사용함 |
2. 순차 다이어그램

- 실행 시점의 객체들이 어떻게 상호 동작하는지를 메시지 순서에 초점을 맞춰 나타낸 것
- 객체 간 어떠한 작업이 발생하는지를 시간순서에 따라 확인 가능
- 객체 밑의 수직의 점선은 객체 생명선이며, 점선 내부의 직사각형은 활성 구간으로 객체의 메서드가 실행되는 부분임
- 화살표를 이용해 객체와 객체의 상호작용을 나타내는 메시지를 나타내며, 실선에 속이 채워져있는 화살표는 동기 메시지, 실선이지만 속이 채워져있지않는 화살표는 비동기 메시지를 나타냄
- 자기 자신을 가리키는 화살표는 재귀 메시지, 점선으로 나타낸 메시지는 호출 메서드의 결과를 반환하는 답신 메시지를 타나냄
- 하나의 이벤트에 여러 시나리오가 나오면 시나리오마다 각각의 다이어그램으로 표현
3. 통신 다이어그램

- 메시지를 이용해 객체들간의 상호작용 관계를 나타낸 것
- 순차 다이어그램과 유사하나 통신 다이어그램은 객체간 상호작용, 통신 다이어그램은 객체 간 시간 순서에 초점을 맞춤
- 실선으로 표현된 관계는 객체 간에 메시지를 주고받는 관계인 링크를 의미함
4. 활동 다이어그램

- 객체의 행위를 나타내는 다이어그램으로 순서도와 유사한 모양을 지님
- 상위 수준에서는 업무 흐름을 표현하고, 설계 단계에서는 클래스 로직을 표현하는 등 광범위하게 사용함
- 속이 찬 원은 시작점, 이중원은 종료점, 둥근 사각형은 활동, 화살표는 활동간의 이동인 전이(transaction)을 나타냄
- 마름모를 통해 분기와 병합 나타냄 (교재 101쪽 참고)
- 여러 활동을 병행할때는 실선으로 동기화 막대 사용
5. 상태 다이어그램

- 객체의 상태 변화를 나타내는 다이어그램
- 둥근 사각형으로 상태를 표현하고, 화살표로 전이를 표현하며, 화살표 위에 이벤트를 표현하게 됨
6. 컴포넌트 다이어그램

- 구현 관점에서 정적 모델링을 할 때 사용하며 실행 모듈간의 연관성을 보여줌
- 컴포넌트는 시스템을 구성하는 물리적인 요소로 스테레오 타입 (<<>>)으로 나타냄
컴포넌트의 대상은 실행 모듈, 소스 코드등이 될 수 있음
- 인터페이스는 클래스 모양으로 나타내거나, 원형 아이콘으로 간단하게 표현함
- 컴포넌트간 연결은 의존하는 방향으로 점선의 화살표를 사용하며, 화살표 관계를 의존 관계라 함
7. 배치 다이어그램

- 하드웨어 자원을 명시적으로 정의해 시스템의 물리적 요소를 모델링하고, 노드 간의 관계를 나타내는 다이어그램
노드: 시스템을 구성하는 처리장치로 실행 파일 수준의 컴포넌트가 탑재된 하드웨어, 웹서버, 클라이언트등이 해당됨
- 노드를 연결하는 관계는 통신 방식을 의미하게 됨
출처:
쉽게 배우는 소프트웨어 공학 2판, 김치수, 한빛아카데미