Chapter 02_ UML
"UML이란?"
- 소프트웨어의 전체를 판단할 수 있도록 제시한 12개의 다이어그램
- 시스템이 상호작용하는 측면, 시스템 전체 구조 측면, 컴포넌트 간의 관계 등을 시각적으로 볼 수 있게 나타낸 도면
{ 액터의 종류 }
- 사용자 액터 : 시스템을 이용하는 사람(역할)
- 시스템 액터 : 해당 프로젝트의 개발 범위에는 속하지 않지만 데이터를 주고받는 등 서로 연동되는 또 다른 시스템
- 주요 액터 : 시스템에게 작업의 실행을 요구하는 능동적 입장의 액터(대부분의 액터가 이에 해당)
- 보조 액터 : 유스케이스로부터 요청을 받거나 메시지를 전달받아 수동적으로 작업을 하는 액터
- 프록시 액터 : 액터와 시스템의 중간 위치에서 무언가를 대신해주는 액터 (시스템에 등록할 수 있도록 접근 권한이 부여된 경우에만)
{ 유스케이스 }
- 사용자가 시스템을 통해 사용하고 싶은 기능
- 유스케이스가 모여 하나의 서브 시스템을 이루고 서브 시스템이 모여 개발 시스템이 됨.
- ( 유스케이스 < 서브 시스템 < 개발 시스템 )
- 전체 시스템은 유스케이스를 모아놓은 것과 같아야 함.
{ 유스케이스 식별 }
- 사용자인 엑터가 시스템에 요구하는 기능을 후보 유스케이스로 선정할 수 있음.
- 사용자의 업무에서 유스케이스를 도출할 수 있음
- 데이터베이스에서 데이터를 등록/수정/삭제/조회하는 기능을 하나의 유스케이스로 선정할 수 있음.
- 개발자는 [사용자 관점]에서 유스케이스를 정의해야 함.
- 처음에는 가능하다고 생각되는 것을 모두 도출해 놓고 하나씩 면밀히 살펴보는 과정을 거쳐 불필요한 것은 삭제하고, 필요시 합치거나 분리해 최종 유스케이스 선정
{ 유스케이스 검증 }
시스템이 아니라 수작업으로 이루어지는 것은 유스케이스에 포함하면 안 됨.
액터가 원하는 최종 결과만 나타내는 유스케이스인지 확인
액터가 수행하는 유스케이스인지 확인
유스케이스 내의 이벤트 흐름 전체를 액터가 사용하는지 확인
{ 유스케이스 이름 }
사용자 관점에서 이해할 수 있는 이름을 사용
명사보다는 동사형 명사를 사용(어떤 기능을 하는지 알 수 있게 하기 위함)
사용자가 시스템을 통해 얻으려는 최종 목적이 나타나는 이름을 사용
{ 관계 }
>> 액터 => 유스케이스 관계
- 액터와 유스케이스는 연관 관계로 방향성을 갖는 실선으로 표현
- 화살표 방향은 데이터가 흘러가는 방향이 아니라 “제어의 흐름”을 나타냄
- 제어하는 주체에서 출발해 제어받는 대상으로 연관 방향이 결정
- 시스템 액터도 유스케이스 제어의 주체가 될 수 있음
- 학생(액터)과 증명서 자동 발급기(시스템 액터) 사이인 액터와 액터 사이에도 연관 관계 존재
>> 유스케이스 => 액터 관계
- 유스케이스의 수행 결과를 액터에게 알려줄 때는 유스케이스에서 액터로 방향성을 갖는 실선으로 표현
- 유스케이스 => 액터 관계에서 주의할 사항은 통보 기능이 시스템 내에서 이루어져야 함.
- 유스케이스 다이어그램에서 화살표로 나타냈다면 그 기능을 개발에 포함해야 함.
>> 유스케이스 => 시스템 액터 관계
>> 액터의 일반화 관계
- 일반화? : 개별적인 것에서 공통적인 특징을 뽑아 이름을 붙인 것 <=> 특수화
- 일반화 개념은 액터 사이에 먼저 적용할 수 있음.
- 간결하게 일반화해 복잡함을 줄이면 이해하기가 쉽고 새로운 액터도 간단하게 추가 가능
>> 포함 관계
- 유스케이스의 일부 기능이 다른 유스케이스에서도 공통으로 필요하다면 이를 별도로 만든 뒤 호출해 사용하는 것
- 피포함 유스케이스 : 공통으로 사용하기 위해 별도 유스케이스로 만들어 놓은 것
- 기본 유스케이스 : 피포함 유스케이스를 호출하는 유스케이스
- 포함 관계는 화살표 방향이 기본 유스케이스에서 피포함 유스케이스로 향함
- 점선을 사용하고 스테레오 타입으로 <<include>>라고 표기
- 포함 관계는 화살표 방향이 기본 유스케이스에서 피포함 유스케이스로 향함
- 피포함 유스케이스는 2개 이상의 유스케이스에서 사용할 수 있는 공통 부분(이벤트 흐름)으로 만들어야 함.
- 다른 유스케이스에서 사용하지 않는 기능이라면 포함 관계를 만들지 않아야 함
- 포함 관계는 선행 조건(유스케이스 명세서 작성 시 필요)과 혼동 주의
>> 확장 관계
- 특정 조건(메일 도착 등)이 발생하면 확장 유스케이스(메일 확인 등)를 수행하고 다시 기준 유스케이스(검색 등)를 수행
- 확장 관계는 점선 화살표로 표기하고 방향은 기준 유스케이스 쪽으로 향함
- <<extend>>라는 스테레오 타입을 사용
- 예외적인 상황이나 어쩌다 한 번 발생하는 것을 확장 관계로 표현하는 것은 적절하지 않음.
{ 클래스 다이어그램 }
- 소프트웨어의 기본 구성 단위인 시스템에서 사용하는 클래스를 정의
- 클래스들이 서로 어떻게 연결되어 있고 어떤 역할을 하는지 다이어그램으로 표현
>> 클래스
- 데이터(속성)와 메서드를 묶어 놓은 것
- 세 칸의 직사각형 모양
- 첫 번째 칸에는 클래스 이름
- 두 번째 칸에는 클래스의 속성
- 마지막 칸은 클래스가 제공하는 기능인 메서드를 나타냄
>> 클래스 이름
- 클래스는 다른 클래스와 구별되는 유일한 이름을 가짐
- 이름에 명사나 명사구를 사용하며 두 단어를 사용할 때는 붙여 쓰되 각 단어의 첫 글자는 대문자로 씀
- 복수형, 소유격, 형용사는 가급적 쓰지 않음
>> 속성
- 클래스가 갖는 정적인 특성
- 속성의 이름은 소문자로 나타내며 두 단어를 사용 할 때는 두 번째 단어의 첫 글자는 대문자로 씀
>> 메서드
- 클래스가 외부의 다른 객체에게 제공할 서비스와 기능
- 외부 클래스는 메서드를 통해 해당 클래스에 접근할 수 있음
- 외부에서 이 기능을 요구하는지에 따라 메서드로 도출할지 판단
>> 가시성
- 속성과 메서드의 접근 권한을 지정하는 방식
{ 순차 다이어그램 }
>> 객체
- 순차 다이어그램에서 객체는 메시지를 보내고 받는 것
- '객체명: 클래스명'으로 나타내며, 한 쪽은 생략 가능
>> 객체 생명선
- 객체의 생존 기간을 나타내며 X 표시는 객체가 소멸하는 시점
- 위에서 아래로 내려가는 점선으로 나타냄
- 생명선을 따라 나타나는 직사각형은 활성 구간으로 객체의 메서드가 실행되고 있음을 나타냄
- 구간의 길이는 메서드의 실행 시간을 나타냄
- 활성 구간은 반드시 존재하는 것은 아니며 생략 가능
>> 메시지
- 객체와 객체의 상호작용을 표현하는 것으로 화살표를 이용
- 화살표 위에는 수신 객체의 함수명을 명기
>> 동기 메시지
- 송신 객체가 수신 객체에 서비스를 요청(메서드를 호출)하면 메서드 실행이 완료될 때까지 기다림
- 실선과 속이 채워진 삼각형 화살표로 나타냄
>> 비동기 메시지
- 송신 객체가 수신 객체에 서비스를 요청(메서드를 호출)할 때 메서드의 실행과 상관 없이 다음 작업을 수행
- 수신 객체로부터의 반환도 기다리지 않음
- 일반 화살표 모양으로 나타냄
>> 재귀 메시지
- 수신 객체가 자신의 메서드를 호출할 때 사용
- ㄷ자 형태의 화살표 모양으로 나타냄
>> 답신 메시지
- 호출 메서드의 결과를 반환할 때 사용
- 점선과 속이 채워진 삼각형 화살표로 나타냄
"순차 다이어그램의 작성 과정"
1. 시나리오 정의
2. 다이어그램과 시나리오의 1:1 대응
3. 시나리오 분할
{ 통신 다이어그램 }
- 객체 간 상호작용 관계에 주목
- 화살표 위에 적힌 번호로 순서를 알 수 있음
>> 링크
- 객체 간에 메시지를 주고받는 관계
- 통신 다이어그램에서는 링크를 사용해 객체 간의 관계를 표현
{ 활동 다이어그램 }
- 흐름도와 비슷하나 객체의 행위를 나타낸다는 점에서 다름
- 상위 수준에서는 업무의 흐름을 표현하고 분석 단계에서는 유스케이스의 구체적인 흐름(이벤트 흐름)을 나타냄
- 설계 단계에서는 클래스 내부 동작에 대한 알고리즘이나 구체적인 로직을 표현
>> 시작/종료 상태, 활동
- 시작점 : 활동의 시작. 속이 채워진 원으로 표기
- 종료점 : 활동의 종료. 이중 원으로 표기
- 활동 : 일의 처리와 실행. 모서리가 둥근 사각형으로 표기
- 전이 : 활동 간의 이동. 화살표로 표기
>> 분기와 병합
- 분기 : 조건에 의해 두 가지 경로로 나뉘는 위치. 마름모로 표기 ((조건문은 마름모 옆에 << 조건문 >> 형식으로 작성
- 병합 : 분기되어 각 활동을 수행하다가 합쳐지는 위치를 나타내며 분기와 같이 마름모를 사용 / 생략이 가능
>> 동기화 막대
- 여러 활동을 병행할 때 사용하는 것. 동시 처리의 시작과 끝을 나타냄.
>> 신호
- 활동 사이의 거래는 제어 신호를 보내는 방식으로 이루어짐
>> 구획면
- 수영장의 레인을 의미하는데 수영 선수가 자신의 레인을 넘어가면 안 되는 것처럼 해당 레인을 책임지는 객체가 있음
{ 상태 다이어그램 }
- 이벤트 발생이나 시간의 흐름에 따라 바뀌는 객체의 상태를 나타냄
>> 상태
- 객체가 존재할 수 있는 조건
- 객체의 존재 가능한 모든 상태가 파악되어야 함
- 상태는 모서리가 둥근 사각형으로 표현
>> 전이
- 객체의 상태가 바뀌는 것을 나타내며 화살표를 사용해 표현
>> 이벤트
- 객체의 상태를 바뀌게 하는 자극
- 화살표로 나타낸 전이 위에 << >> 기호를 사용해 작성
{ 컴포넌트 다이어그램 }
- 구현 관점에서 정적 모델링을 할 때 사용하는 것
- 어떤 실행 모듈이 존재하고 이들이 서로 어떤 연관성이 있는지의 종속 관계를 나타냄
- 사용자에게 논리적 또는 물리적 시스템의 구조를 볼 수 있게 해줌
>> 컴포넌트
- 컴포넌트는 시스템을 구성하는 물리적인 요소로 프로그램 코드를 포함
- <<executable>>: 실행 파일(.exe)
- <<library>>: DLL 같은 정적 또는 동적 객체 라이브러리
- <<table>>: 데이터베이스 테이블
- <<file>>: 원시 코드를 포함하는 파일
>> 인터페이스
- 클래스 모양으로 나타내거나 아이콘을 사용해 간략하게 표현할 수 있음
>> 의존 관계
- 서로 영향을 주고 받는 관계를 말함
- 컴포넌트 간 연결은 점선 화살표로 나타내며 의존하는 쪽으로 화살표가 연결
"컴포넌트 다이어그램의 작성 과정"
1. 컴포넌트 대상 정의
2. 컴포넌트 찾기
3. 컴포넌트 배치
4. 의존 관계 정의
'소프트웨어 공학' 카테고리의 다른 글
| [S/W Engineering] Chapter 03_계획 (0) | 2022.04.27 |
|---|---|
| [S/W Engineering] Chapter 01_소프트웨어 공학과 개발 프로세스 (0) | 2022.04.15 |