UI 설계를 위한 UML ⭐⭐⭐
UML
1. UML의 개념
- 객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화할 때 사용되는 모델링 기술과 방법론을 통합해서 만든 표준화된 범용 모델링 언어
2. UML의 특징
| 특징 | 설명 |
| 가시화 언어 | · 개념 모델 작성 시 오류가 적고 의사소통이 용이 |
| 구축 언어 | · 다양한 프로그래밍 언어로 실행 시스템의 예층 가능 · UML을 소스 코드로 변환하여 구축 가능, 역 변환하여 역공학 가능 |
| 명세화 언어 | · 정확한 모델 제시, 완전한 모델 작성 가능 |
| 문서화 언어 | · 시스템에 대한 평가 및 의사소통의 문서 |
3. UML의 구성요소 ( 사과한다(사관다~~ ))
| 구성요소 | 내용 |
| 사물(Things) | · 추상적인 개념으로, 주제를 나타내는 요소 · 단어 관점에서 '명사' 또는 '동사'를 의미 |
| 관계(Relationships) | · 사물의 의미를 확장하고 명확히 하는 요소 · 사물과 사물을 연결하여 관계를 표현하는 요소 · 단어 관점에서 '형용사' 또는 '부사'를 의미 |
| 다이어그램(Diagrams) | · 사물과 관계를 모아 그림으로 표현한 형태 · 형식과 목적에 따라 9가지로 정의 |
4. UML 다이어그램
| 구분 | 다이어그램 | 설명 |
| 구조적 다이어그램(Structural) / 정적 다이어그램(Static) |
클래스(Class) | · 객체 지향 모델링 시 클래스의 속성 및 연산과 클래스 간 정적인 관계를 표현 |
| 객체(Object) | · 클래스에 속한 사물(객체)들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현 | |
| 컴포넌트(Component) | · 시스템을 구성하는 물리적인 컴포넌트와 그들 사이의 의존 관계를 나타냄 (구현단계) | |
| 배치(Deployment) | · 컴포넌트 사이의 종속성을 표현하고, 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현 (구현단계) | |
| 복합체 구조(Composite Structure) | · 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현 | |
| 패키지(Package) | · 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현 | |
| 행위적 다이어그램(Behavioral) / 동적 다이어그램(Dynamic) |
유스케이스(Usecase) | · 시스템이 제공하고 있는 기능 및 그와 관련된 외부 요소를 사용자 관점에서 표현 |
| 시퀀스(Sequence) | · 객체 간 동적 상호 작용을 시간적 개념을 중심으로 메시지 흐름을 표현 | |
| 커뮤니케이션(Communication) | · 동작에 참여하는 객체들이 주고 받는 메세지를 표현하고, 메세지뿐만 아니라 객체 간의 연관까지 표현 | |
| 상태(State) | · 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지 표현 | |
| 활동(Activity) | · 시스템이 어떤 기능을 수행하는지를 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서대로 표현 | |
| 타이밍(Timing) | · 객체 상태 변화와 시간 제약을 명시적으로 표현 |
5. UML 확장 모델의 스테레오 타입
- UML 기본적 요소 이외의 새로운 요소를 만들어내기 위한 확장 메커니즘
- 형태는 기존의 UML 요소를 그대로 사용하지만 내부 의미는 다른 목적으로 사용하도록 확장
- '<<>>' 길러멧 기호를 사용하여 표현
- UML 스테레오 타입의 유형
| 유형 | 설명 |
| <<include>> | 하나의 유스케이스가 어떤 시점에 반드시 다른 유스케이스를 실행하는 포함 관계 |
| <<extend>> | 하나의 유스케이스가 어떤 시점에 다른 유스케이스를 실행할 수도 있고 그렇지 않을 수도 있는 확장 관계 |
| <<interface>> | 모든 메서드가 추상 메스드이며 바로 인스턴스를 만들 수 없는 클래스로 추상 메서드와 상수만으로 구성된 클래스 |
| <<entity>> | 일반적으로 정보 또는 오래 지속되는 연관된 행위를 형상화하는 클래스로 유스케이스 처리 흐름이 수행되는 과정에서 기억 장치에 저장되어야 할 정보를 표현하는 클래스 |
| <<boundary>> | 시스템과 외부 액터와의 상호 작용을 담당하는 클래스 |
| <<control>> | 시스템이 제공하는 기능의 로직 및 제어를 담당하는 클래스 |
UML의 유형
1. 클래스 다이어그램
- 클래스 다이어그램의 개념 : 객체 지향 모델링 시 클래스의 속성 및 연산과 클래스 간 정적인 관계를 표현
- 클래스 다이어그램의 구성요소
| 구성요소 | 설명 | |
| 클래스(Class) | · 공통의 속성, 연산(메서드), 관계, 의미를 공유하는 객체들의 집합 | |
| 속성(Attribute) | · 클래스의 구조적 특성에 이름을 붙인 것으로 특성에 해당하는 인스턴스가 보유할 수 있는 값의 범위를 기술 | |
| 연산(Operation), 메서드 |
· 이름, 타입, 매개변화들과 연관된 행위를 호출하는데 요구되는 제약사항들을 명시하는 클래스의 행위적 특징 · 객체에 요청하여 행동에 영향을 줄 수 있는 서비스 |
|
| 접근 제어자 (Access Modifier) |
· 클래스에 접근할 수 있는 정도를 표현 | |
| - | 클래스 내부 접근만 허용 (private) | |
| + | 클래스 외부 접근을 허용 (public) | |
| # | 동일 패키지/파생 클래스에서 접근 가능 (protected) | |
| ~ | 동일 패키지 클래스에서 접근 가능 (default) | |
- 클래스 간의 관계(Relationships)
| 구분 | 설명 |
| 연관관계 (Association) |
· 클래스가 서로 개념적으로 연결된 선 · 2개 이상의 사물이 서로 관련되어 있는 상태 · 사물 사이를 실선으로 연결하여 표현하며, 방향성은 화살표로 표현 · 서로에게 영향을 주는 양방향의 관계일 경우 화살표를 생략하고 실선으로만 연결 · 예) 축구팀과 공격수(1...3), 수비수(1...5), 골키퍼(1...1) |
| 의존관계 (Dependency) |
· 하나의 클래스가 또 다른 클래스를 사용하는 관계 · 다른 클래스의 멤버 함수 사용 · 의존 관계는 사물 사이에 서로 연관은 있으나 필요에 따라 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현 · 하나의 클래스에 있는 멤버 함수의 인자가 변함에 따라 다른 클래스에 영향을 미칠 때의 관계 · 영향을 주는 사물이 영향을 받는 사물 쪽으로 점선 화살표를 연결하여 표현 · 예) 교수와 수업 |
| 일반화관계 (Generalization) |
· 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현 · 일반적인 개념을 부모(상위)라고 하고, 구처적인 개념을 자식(하위)이라 함 · 구체적(하위)인 사물에서 일반적(상위)인 사물 쪽으로 속이 빈 화살표를 연결하여 표현 · 일반화 관계는 다른 의미로 상속관계라고 함 · 예) 차와 자가용, 택시, 버스 |
| 실체화관계 (Realization) |
· 추상 클래스나 인터페이스를 상속받아 자식 클래스가 추상 메서드를 구현할 때 사용 · 사물이 할 수 있거나, 해야 하는 기능(행위,인터페이스)으로 서로를 그룹화할 수 있는 관계를 표현 · 예) abstact class extends, interface implements |
| 포함관계 (Composition) = 복합관계 |
· 영구적이고, 집합 관계보다 더 강한 관계로 구성 · 포함되는 쪽(부분)에서 포함하는 쪽(전체)으로 채워진 마름모를 연결하여 표현 (◆) · 포함관계는 집합관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계를 표현 · 예) 엔진과 피스톤, 플러그 |
| 집합관계 (Aggregation) |
· 하나의 객체에 여러개의 독립적인 객체들이 구성되는 관계 · 집합관계는 하나의 사물이 다른 사물에 포함되어 있는 관계 표현 · 포함되는 쪽(부분)에서 포함하는 쪽(전체)으로 빈 마름모를 연결하여 표현 (◇) · 예) 차와 엔진, 바퀴, 운전대 |
* 연관관계의 다중성
| 다중성 표현 | 의미 |
| 1 | · 한 객체와 연관 · 표시하지 않아도 기본값으로 설정 |
| 0..1 | · 0개 또는 1개의 객체와 연결 |
| 0..* | · 0개 또는 많은 수의 객체가 연관 |
| * | · 0..*와 동일 |
| 1..* | · 1개 이상의 객체와 연관 |
| 1..12 | · 1개에서 12개까지 객체가 연관 |
| 1..2,4,6 | · 1개에서 2개까지 또는 4개 또는 6개의 객체가 연관 |
* 실체화 관계(Realization)에서 추상 클래스와 인터페이스 관계
| 구분 | 설명 |
| 추상 클래스 | · 객체 인스턴스를 생성하지 않고, 단지 유사 클래스들의 공통된 특징을 정의하고, 하나 이상의 추상 메서드와 일반 필드 및 일반 메서드를 포함하는 클래스 · 동일한 부모를 가지는 클래스를 묶는 개념으로 상속을 받아서 기능을 확장시키는 것이 목적 · 이탤릭체로 클래스명을 표시하며, 스테레오타입을 이용하여 <<abstract>>로 표기 |
| 인터페이스 | · 기능(Function)을 모아놓은 클래스로 추상메서드와 상수만을 포함한다. · 구현하는 모든 클래스에 대해 특정한 메서드가 반드시 존재하도록 강제하는 역할 · 이탤릭체로 인터페이스명을 표시하며, 스테레오타입을 이용하여 <<interface>>로 표기 |
2. 유스케이스 다이어그램
- 유스케이스 다이어그램의 개념 : 시스템이 제공하고 있는 기능 및 그와 관련된 외부 요소를 사용자의 관점에서 표현하는 다이어그램
- 유스케이스 다이어그램의 구성요소
| 구성요소 | 설명 |
| 유스케이스 | · 시스템이 제공해야 하는 서비스, 기능 · 액터가 시스템을 동해 수행하는 일련의 행위 |
| 액터 | · 사용자가 시스템에 대해 수행하는 역함 · 시스템과 상호 작용하는 사람 또는 사물 · 이벤트 흐름을 시작하게 하는 객체 |
| 시스템 | · 전체 시스템의 영역을 표현 |
| 시나리오 | · 발생되는 이벤트의 흐름 |
| 이벤트의 흐름 | · 사람, 시스템, 하드웨어, 시간의 흐름에 의해 시작 |
- 유스케이스 다이어그램의 관계
| 관계 | 설명 | 사례 |
|
| 포함관계 (Include) |
· 유스케이스를 수행할 때 다른 유스케이스가 반드시 수행되는 관계 · 여러 유스케이스에서 공통적으로 발견되는 기능 표현 · 2개 이상의 유스케이스 이벤트 흐름에서 중복적인 부분이 발생하는 경우 유스케이스 간 포함 관계를 성정하여 해결 · <<include>>를 사용하여 표현 |
대여 유스케이스 이벤트 흐름 |
반납 유스케이스 이벤트 흐름 |
| 고객확인, 도서번호 입력 필요 | 고객확인, 도서번호 입력 필요 | ||
| 확장관계 (Extend) |
· 포함관계처럼 여러 유스케이스에 걸쳐 중복적으로 사용되지 않고, 특정 조건에서 한 유스케이스로만 확장되는 관계 · 특정 조건이 만족되는 상황에서만 확장 유스케이스의 이벤트 흐름이 수행 · 한 유스케이스에서 추가되거나 확장된 기능을 표현 · <<extend>>를 사용하여 표현 |
금액계산 유스케이스 이벤트 흐름 |
금액표시 유스케이스 이벤트 흐름 |
| · 사용자가 자판기에 동전 투입, 음효수 선택 · 현재 금액에 투입된 동전만큼 액수 추가 · 금액표시 유스케이스 확장 |
· 금액계산 유스케이스로부터 금액 수령 · 받은금액 표시 |
||
| 일반화관계 (Generalization) |
· 추상적인 액터와 좀 더 구체적인 액터 사이에 맺어어주는 관계 · 일반화 관계를 액터에 적용하면 유스케이스 다이어그램에서 사용되는 여러 액터들의 의미를 좀 더 명확하게 하고 다이어그램도 보다 간결하게 작성 · 하위 액터나 유스케이스에서 상위 액터, 유스케이스 쪽으로 속이 빈 삼각형 화살표를 실선으로 연결 |
||
3. 시퀀스 다이어그램
- 시퀀스 다이어그램의 개념
└ 객체 간 상호 작용을 메세지 흐름으로 표현한 다이어그램
└ 객체 간의 동적 상호 작용을 시간적 개념을 중심으로 모델링하는 과정
└ 객체의 오퍼레이션과 속송을 상세히 정의
└ 시퀀스 다이어그램은 유스케이스를 실현(Realization) 한다.
- 시퀀스 다이어그램의 구성요소
| 구성요소 | 설명 |
| 객체 (Object) |
· 객체는 위쪽에 표시되며 아래로 생명선을 가짐 · 객체는 사각형 안에 밑줄 친 이름으로 명시 |
| 생명선 (Lifeline) |
· 객체로부터 뻗어 나가는 점선 · 실제 시간이 흐름에 따라 객체의 생명주기 동안 방생하는 이벤트를 명시 |
| 실행 (Activation) |
· 직사각형은 오퍼레이션(함수)이 실행되는 시간을 의미 · 직사각형이 길어질수록 오퍼레이션 수행시간이 긺 |
| 메세지 (Message) |
· 객체 간의 상호 작용은 메세지 교환으로 이루어짐 · 한 객체에서 다른 객체로의 메세지를 전달하여 전달받은 객체의 오퍼레이션을 수행 |
4. 패키지 다이어그램
- 패키지 다이어그램의 개념 : 시스템의 서로 다른 패키지들 사이의 의존 관계를 표현하기 위한 다이어그램
- 패키지 다이어그램의 구성요소
| 구성요소 | 설명 |
| 패키지 | · 요소들을 그룹으로 조직하기 위한 요소 |
| 의존관계 | · 하나의 패키지가 다른 패키지를 사용하는 관계 · 의존성의 성질을 나타내기 위해 스테레오 타입을 붙일 수 있음 · 스테레오 타입에는 <<import>>, <<access>>가 있음 |
5. 활동 다이어그램
- 활동 다이어그램의 개념
└ 시스템이 어떤 기능을 수행하는지를 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서대로 표현하는 다이어그램
└ 오퍼레이션이나 처리과정이 수행되는 동안 일어나는 일들을 단계적으로 표현한다.
└ 하나의 유스케이스 안이나, 유스케이스 사이에서 발생하는 복잡한 처리의 흐름을 명확하게 표현할 수 있다.
└ 하나의 활동이 처리되면 그다음 활동으로 자동적으로 옮겨지며, 활동 상태의 시작과 종료는 항상 존재한다.
- 활동 다이어그램의 구성요소
| 구성요소 | 설명 |
| 시작점 (Initial Node) |
· 활동의 시작(액션이나 액티비티 시작)을 의미 · 하나의 다이어그램 안에는 하나의 시작점만 존재 · 검은색 동그라미로 표현 (●) |
| 전의 (Transition) |
· 실행의 흐름을 나타냄 · 화살표로 표현 (→) |
| 액션(Action) / 액티비티(Activity) |
· 어떠한 일들의 처리와 실행을 의미 · 액션은 더 이상 분해할 수 없는 단일 작업이고, 액티비티는 몇 개의 액션으로 분리될 수 있는 작업 · 모서리가 둥근 사격형으로 표현하고, 둥근 사각형 안에 액션이나 액티비티 명칭 기술 |
| 종료점 (Final Node) |
· 처리의 종료를 의미 · 하나의 다이어그램 안에는 여러 개의 종료 노드가 있을 수 있음 · 검은색 동그라미를 포함한 원으로 표현 |
| 조건(판단) 노드 (Decision Node) |
· 조건에 따른 제어 흐름의 분리를 표현 · 마름포로 표현하고 들어오는 제어 흐름은 한 개이고, 나가는 제어 흐름은 여러 개로 표현 |
| 병합 노드 (Merge Node) |
· 여러 경로의 흐름이 하나로 합쳐진 것을 표현 · 마름모로 표현하고 들어오는 제어 흐름은 여러 개고, 나가는 제어 흐름은 한 개로 표현 |
| 포크 노드 (Fork Node) |
· 평행적으로 수행되는 흐름을 나누는 노드 · 굵은 가로선으로 표현하고 들어오는 액티비티 흐름은 한 개이고, 나가는 액티비티 흐름은 여러 개 |
| 조인 노드 (Join Node) |
· Fork Node로 나눠진 흐름을 다시 하나로 합치는 노드 · 굵은 가로선으로 표현하고 들어오는 액티비티 흐름은 여러 개이고, 나가는 액티비티 흐름은 한 개 |
| 구획면 (Swim Lane) |
· 액티비티 수행을 담당하는 주체를 구분하는 면 · 가로 또는 세로 실선을 그어 구분 |
6. 상태 다이어그램
- 상태 다이어그램의 개념
└ 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지 표현하는 다이어그램
└ 어떤 이벤트에 의해 객체 자신이 속한 클래스의 상태 변화나 객체 간 상호 작용하는 과정에서의 상태 변화를 표현
└ 객체는 파악된 상태들 이외의 상태는 가질 수 없고, 특정 순간에는 오직 한 상태로만 존재할 수 있다.
└ 객체의 상태란 객체가 갖는 속성값의 변화이다.
- 상태 다이어그램의 구성요소
| 구성요소 | 설명 |
| 상태 | · 객체가 존재할 수 있는 조건 중의 하나 · 둥근 사각형 안에 객체의 상태 기술 |
| 시작 상태 | · 객체의 시작 상태 · 속이 채워진 원으로 표현 |
| 종료 상태 | · 객체의 종료 상태 · 원 안에 속이 채워진 원으로 표현 |
| 전이 | · 객체의 상태가 다른 상태로 변경되는 상태 · 상태 사이의 흐름, 변화 · 이벤트 없이도 상태 전이가 이루어 질 수 있음 · 화살표로 표현 |
| 이벤트 | · 객체의 전이를 유발하는 자극 · 상태의 변화를 주는 현상 · 상태의 전이를 유발하는 이벤트는 전이 위에 이벤트 이름 표시 · 이벤트 : 시간의 흐름, 조건, 외부 신호 등 |
| 전이 조건 | · 특정 조건 만족 시 전이 발생하도록 하기 위해 사용되는 속성값의 Boolean 식 |
7. 커뮤니케이션 다이어그램
- 커뮤니케이션 다이어그램의 개념
└ 동작에 참여하는 객체들이 주고받는 메세지 표현 + 객체 간의 연관 표현 다이어그램
└ 시스템이나 객체들이 메세지를 주고받으며 시간의 흐름에 따라 상호 작용하는 과정을 표현한 다이어그램
- 커뮤니케이션 다이어그램의 구성요소
| 구성요소 | 설명 |
| 액터 | · 시스템으로부터 서비스를 요청하는 외부 요소(사람, 외부 시스템) |
| 객체 | · 메세지를 주고받는 주체 · 콜론(:)을 기준으로 앞쪽은 객체명, 뒤쪽은 클래스명 기술 (객체명:클래스명) |
| 링크 | · 객체들 간의 관계를 표현 · 클래스가 아닌 실제 객체와의 관계를 직접적으로 보여주는 객체들 사이의 링크 · 액터와 객체, 객체 간 실선으로 표현 · 링크에 메세지를 표현 |
| 메세지 | · 객체가 상호 작용을 위해 주고받는 메세지 · 메세지는 상대 객체별로 여러 개의 정의가 이루어지므로, 하나의 동일한 링크에서 여러 개의 메세지를 전달 · 화상표의 방향은 메세지를 받는 쪽으로 향하게 표현 |
8. 컴포넌트 다이어그램
- 컴포넌트 다이어그램의 개념
└ 시스템을 구성하는 물리적인 컴포넌트와 그들 사이의 의존 관계를 나타내는 다이어그램
└ 코드 컴포넌트 기반의 물리적 구조로 표현
└ 실질적 프로그래밍 작업에 사용된다.
- 컴포넌트 다이어그램의 구성요소
| 구성요소 | 설명 |
| 컴포넌트 | · 컴포넌트는 탭이 달린 직사각형으로 표현 · 모든 컴포넌트는 반드시 이름을 가지고 있어야 함 · 컴포넌트가 패키지에 포함되어 있다면 컴포넌트의 이름 앞에 패키지 이름을 붙일 수 있으며, 클래스처럼 컴포넌트에 꼬리표 값을 달아주거나 컴포넌트 내부의 오퍼레이션을 보여줄 수도 있음 (패키지명::컴포넌트명) |
| 인터페이스 | · 인터페이스를 실체화한다는 의미는 실제로 동작하는 컴포넌트에 인터페이스를 적용한다는 뜻 · 컴포넌트와 인터페이스의 의존 관계는 화살표 모양의 점선으로 연결 · 스테레오타입은 <<interface>> |
| 의존 관계 | · 컴포넌트 사이의 의존하는 관계 표현 · 컴포넌트 사이의 의존 관계는 한 컴포넌트에 변경이 발생한 경우, 변경 범위 추적에 유용 |
* UI 흐름 절차
- UI 설계안의 적정성 확인 → 화면에 표현되어야 할 기능 및 비기능적 요구사항 검토 → 화면의 입력 요소를 통한 UI 요구사항 확인 → 유스케이스 설계 → 기능 및 양식 확인
* UI 시나리오 문서 작성 요건
| 작성 요건 | 설명 |
| 완전성 (Complete) |
· UI 시나리오는 누락이 없어야 하고, 최대한 빠짐없이 상세하게 기술 · 시스템 기능보다는 사용자의 태스트에 초점을 맞춰 기술 |
| 일관성 (Consistent) |
· 서비스에 대한 목표, 시스템 및 사용자의 요구사항이 일관성이 있어야 하고, 모든 문서의 UI 스타일(Flow 또는 Layout)을 일관적으로 구성 |
| 이해성 (Understandable) |
· 처음 접하는 사람도 이해하기 쉽도록 구성, 설명 · 추상적 표현이나 이해하기 어려운 용서 사용 X |
| 가독성 (Readable) |
· 문서를 쉽게 읽을 수 있어야 하고(문서 템플릿과 타이포그래피), 표준화된 템플릿을 작성하여 적용 · 버전 넘버링은 v1.0, v2.0 등과 같이 일관성 있게 하고, 시각적인 효과를 위해 하이타이팅은 일관성 있게 활용 |
| 추적 용이성 (Traceable) |
· 쉽게 추적 가능해야 하고, 변경 사항들이 언제, 어디서, 어떤 부분들이, 왜 발생하였는지 추적이 쉬워야 함 |
| 수정 용이성 (Modifiable) |
· 쉽게 변경 가능해야 하고, 수정 사항을 시나리오에 반영하는데 있어 쉽게 적용할 수 있어야 함 · 동일한 수정 사항을 위해 여러 문서를 편집하지 않도록 함 |
TEST → 정답은 드래그!
| 정답 | 문제 |
| UML | 객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화할 때 사용되는 모델링 기술과 방법론을 통합해서 만든 표준화된 범용 모델링 언어이다. |
| 사물 | UML 구성요소 중 추상적인 개념으로, 주제를 나타내는 요소이고 단어 관점에서 '명사' 또는 '동사'를 의미한다. |
| 유스케이스 다이어그램 | 시스템이 제공하고 있는 기능 및 그와 관련된 외부 요소를 사용자의 관점에서 표현하는 다이어그램이다. |
| 관계 | UML 구성요소 중 사물의 의미를 확장하고 명확히 하는 요소로 사물과 사물을 연결하여 관계를 표현하는 요소이고 단어 관점에서 '형용사' 또는 '부사'를 의미한다. |
| 배치 | UML 다이어그램 중 컴포넌트 사이의 종속성을 표현하고, 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현하는 다이어그램이다. |
| 시퀀스 | UML 다이어그램 중 객체 간 동적 상호 작용을 시간적 개념을 중심으로 메시지 흐름으로 표현한 다이어그램이다. |
| 커뮤니케이션 | UML 다이어그램 중 동작에 참여하는 객체들이 주고 받는 메세지를 표현하고, 메세지뿐만 아니라 객체 간의 연관까지 표현하는 다이어그램이다. |
| 상태 | UML 다이어그램 중 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지 표현하는 다이어그램이다. |
| 활동 | UML 다이어그램 중 시스템이 어떤 기능을 수행하는지를 객체의 처리 로직이나 조건에 따른 처리의 흐름으로 순서대로 표현하는 다이어그램이다. |
| 타이밍 | UML 다이어그램 중 객체 상태 변화와 시간제약을 명시적으로 표현하는 다이어그램이다. |
| UML 스테레오 타입 | UML의 기본적 요소 이외의 새로운 요소를 만들어내기 위한 확장 매커니즘으로 '<<>>'기호를 사용하여 표현한다. |
| + | 기호는 클래스 다이어그램의 접근 제어자 중 클래스 외부접근을 허용하는(public)하는 기호이다. |
| - | 기호는 클래스 다이어그램의 접근 제어자 중 클래스 내부접근만 허용하는(private)하는 기호이다. |
| 일반화 관계 | 클래스 간의 관계에서 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지 표현하고, 구체적인 사물에서 일반적인 사물쪽으로 속이 빈 화살표를 연결하여 표현한다. |
| 의존 관계 | 클래스 간의 관계에서 하나의 클래스가 또 다른 클래스를 사용하는 관계로 사물 사이에 서로 관련은 있으나 필요에 따라 서로에게 영향을 주는 짧은 시간 동안만 유지하는 관계를 표현하고, 영향을 주는 사물이 영향을 받는 사물 쪽으로 점선 화살표를 연결하여 표현한다. |
| 액션 | 활동 다이어그램 구성요소 중 어떠한 일들의 처리와 실행을 의미하고, 더 이상 분해할 수 없는 단일 작업이다. |
| 포크 노드 | 활동 다이어그램 구성요소 중 평행적으로 수행되는 흐름을 나누는 노드로 굵은 가로선으로 표현하고 들어오는 액티비티 흐름은 한개이고, 나가는 액티비티 흐름은 여러개이다. |
| 전이 조건 | 상태 다이어그램 구성요소 중 특정 조건 만족 시 전이 발생하도록 하기 위해 사용되는 속성 값의 불리언식이다. |
| UI 흐름 설계 | 업무의 흐름이나 업무 수행과 관련된 일련의 클릭에 의한 화면의 위치와 흐름을 흐름도 형식으로 표현하는 활동이다. |
| UI 설계 구성 | UI 설계서 표지, UI 설계서 개정이력, UI 요구사항 정의, 시스템 구조, 사이트맵, 프로세스 정의, 화면 설계 등으로 이루어진다. |
| UI 상세 설계 프로세스 | UI 요구사항 최종 확인, UI 구조 설계, 사용자 기반 메뉴 구조 설계, 화면 설계, 위 시스템 단위의 내·외부상세화면과 폼 설계 절차로 되어있다. |
| 완전성 | UI 시나리오 문서의 작성 요건 중 UI 시나리오는 누락이 없어야 하고, 최대한 빠짐없이 가능한 한 상세하게 기술해야 한다는 원칙이다. |
| 이해성 | UI 시나리오 문서의 작성 요건 중 처음 접하는 사람도 이해하기 쉽도록 구성하고 설명해야 하고, 이해하지 못하는 추상적인 표현이나 이해하기 어려운 용어는 사용하지 않아야 한다는 원칙이다. |
| 가독성 | UI 시나리오 문서의 작성 요건 중 문서를 쉽게 읽을 수 있어야 하고 표준화된 템플릿을 작성하여 적용해야 한다는 원칙이다. |
| 수정 용이성 | UI 시나리오 문서의 작성 요건 중 쉽게 변경이 가능해야 하고, 수정 또는 개선 사항을 시나리오에 반영하는데 있어 쉽게 적용할 수 있어야 한다는 원칙이다. |
| 행위적(동적) 다이어그램 | 유형에는 유스케이스 / 시퀀스 / 커뮤니케이션 / 상태 / 활동 / 타이밍 다이어그램이 있다. |
| 구조적(정적) 다이어그램 | 유형에는 클래스 / 객체 / 컴포넌트 / 배치 / 복합체 구조 / 패키지 다이어그램이 있다 |
| 실체화 관계 | 추상 클래스나 인터페이스를 상속받아 자식클래스가 추상 메서드를 구현할 때 사용하고, 사물이 할 수 있거나, 해야 하는 기능으로 서로를 그룹화할 수 있는 관계를 표현한다. 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현한다. |
| 포함 관계 | 유스케이스 다이어 그램의 관계 중 유스케이스를 수행할 때 다른 유스케이스가 반드시 수행되는 관계로 여러 유스케이스에서 공통적으로 발견되는 기능을 표현하고, <<include>>로 표현한다. |
| 링크 | 커뮤니케이션 다이어그램 구성요소 중 객체들 간의 관계를 표현하고 클래스가 아닌 실제 객체와의 관계를 직접적으로 보여주는 구성요소로 액터와 객체, 객체 간 실선으로 표현한다. |
| 조인 노드 | Fork Node로 나눠진 흐름을 다시 하나로 합치는 노드로 굵은 가로선으로 표현하고 들어오는 액티비티 흐름은 여러 개이고, 나가는 액티비티 흐름은 한 개이다. |
※ 해당 글은 수제비 2022 도서 참고하였습니다.
수제비- IT 커뮤니티 (정보처리기사... : 네이버 카페
수제비-수험생 입장에서 제대로 쓴 비법서(정보처리기사, 정보처리기능사, 빅데이터 분석기사 등 시리즈)
cafe.naver.com
'정보처리기사' 카테고리의 다른 글
| Ⅲ 데이터 입출력 구현 - 물리 데이터 저장소 설계 (0) | 2023.02.20 |
|---|---|
| Ⅲ 데이터 입출력 구현 - 논리 데이터 저장소 확인 (2) | 2023.02.02 |
| Ⅱ 화면설계 - UI 요구사항 확인 (0) | 2023.01.30 |
| [2023] 정보처리기사 시험 일정 (0) | 2023.01.05 |
| Ⅰ 요구사항 확인 - 분석 모델 확인하기 (0) | 2022.12.02 |