UML 모델링 언어

UML (Unified Modeling Language)

• 다이어그램을 표현하기 위한 기본 모델 요소(심볼과 심볼의 의미)를 표준적으로 정의

 

소프트웨어 개발 생명주기 단계별 다이어그램

• 분석 단계 
  • 유스 케이스 다이어그램(사용 사례 다이어그램)
  • 클래스 다이어그램
  • 순차 다이어그램
  • 프로파일 다이어그램
  • 오브젝트 다이어그램
  • 액티비티 다이어그램
  • 인터액션 오버뷰 다이어그램
  • 상태 기계 다이어그램
• 설계 단계
  • 패키지 다이어그램
  • 타이밍 다이어그램
  • 순차 다이어그램(메소드 명세)
  • 배치 다이어그램

 

---

기능 모델링 

• 소프트웨어 분석을 위한 첫 번째 활동
• 사용자로부터 도출한 요구 사항을 입력받아 소프트웨어 시스템이 해야 할 기능이 무엇인지를 식별해가는 과정
• UML의 유스 케이스 다이어그램을 이용하여 분석 결과를 표현
• 요구 사항에 대한 충분한 이해가 부족하거나 도메인 지식이 부족한 경우, 비즈니스 프로세스 모델링(BPM, Business Process Modeling)을 액티비티 다이어그램을 이용하여 수행
  • 소프트웨어 구현 범위와 무관하게 비즈니스 프로세스에 대한 흐름을 체계적으로 도식화하고, 업무 수행 활동(액티비티 다이어그램의 활동) 간에 전달되는 정보 혹은 객체를 표현 

 

Use Case Diagram (사용 사례 다이어그램)

• 시스템 최상위 수준에 해당하는 기능은 사용자 관점으로 나타냄
  • 사용자가 시스템을 통해 제공받는 주요 기능을 나타냄
  • 시스템과 사용자 간에 어떤 상호작용이 이루어지는지를 표현  
• 작성 절차
  • 요구 사항 정의 내용 검토
  • 요구 사항을 토대로 시스템의 경계를 결정
  • 경계가 설정된 시스템에 대한 명칭(시스템 명)을 정의
  • 시스템 외부에 존재하는 액터(Actor)를 식별하고, 각 액터의 역할 정의 
  • 각 액터가 시스템에서 사용하는 기능을 식별
  • 식별된 사용자 기능과 액터 간의 관계를 정의
  • 식별된 사용자 기능에 대한 설명서(Use Case Description)를 작성 
• 액터(Actor)
  • 외부에 존재하는 상호작용 대상 시스템, 외부 장치, 연동하는 하드웨어, 타이머 등 개발 대상 시스템과 상호작용하는 모든 개상을 식별
  • 역할을 중심으로 식별
  • 예) James라는 사람이 시스템 사용자이면서 시스템 관리자 역할을 할 때, 액터는 사용자와 관리자의 두 가지로 식별되어야 함
• Use Case 식별을 위한 고려사항
  • 시스템이 제공하는 기능을 나타낼 것
  • 사용자가 한 장소에서 일정한 시간에 수행하는 상호 구별되는 비즈니스 프로세스여야 함
  • 서로 다른 시간대에 수행되는 행위는 분리하여 각각 별도의 Use Case로 식별
  • Use Case는 최초에 액터에 의해 시작되어야 함
  • 다른 것과 관계가 없는 독립된 Use Case는 존재할 수 없음
  • 유스 케이스의 이름은 동사구 형태로 기술되어야 함
  • 하나의 Use Case는 동작 수행의 종료를 포함하도록 정의해야 함
  • 초기 유스 케이스 식별의 실마리는 그룹핑된 요구사항을 하나의 Use Case로 매핑하는 것으로 시작할 수 있음 

 

Use Case 설명서

• Use case에 대한 간단한 식별 정보와 Use Case 내부에서 처리해야 하는 기능의 상세한 흐름을 나타냄
• Use Case 식별부
  • Use Case에 대한 ID, 이름, 간단한 설명, 관련 액터, 다른 유스 케이스와의 관계 등에 대한 정보를 기술   
• 정상 시나리오 정의부
  • Use Case의 내부 기능을 단계별로 작성
  • 관찰자 입장에서 표현, 액터와 시스템 간의 상호작용에 초점, 행위 주체를 포함하여 서술 
• 예외 처리 정의부
  • 정상 시나리오의 각 스텝에서 발생 가능한 예외 처리를 작성하는 부분
  • 정상 시나리오의 작성 부분에서 나타나는 식별자와 연결되어 표현
  • 다이어그램에 나타난 모든 유스 케이스에 대해 유스 케이스 설명서를 작성함
  • 하나의 유스 케이스 다이어그램은 직관적인 이해도를 높이기 위해 7~9개의 Use Case를 포함해 작성
  • 하나의 다이어그램에 15개 이상의 사용 사례가 포함된다면, 가능한 이들을 추상화하여 계층적인 사용 사례 다이어그램을 생성
  • 즉, 상위 다이어그램과 상위 다이어그램에 존재하는 사용 사례들을 상세하게 나타낸 하위 다이어그램들로 표현할 수 있음 

 

---

구조 모델링

• 개발 대상 소프트웨어가 어떤 구조적 요소들로 이루어질 수 있는지 분석
• 업무 수행 과정에서 생성되고 사용되어야 할 객체에 어떤 것들이 있는지 식별하고, 그들 간의 관계를 정의
• UML의 클래스 다이어그램으로 표현
• 설계 단계에서 사용
• 분석 과정의 구조 모델에서 정의된 객체들이 어떻게 생성·저장·처리되는지, 파일과 데이터베이스로 어떻게 반영되어야 하는지를 나타냄
• 비즈니스에서 사용되는 용어들을 이용하여 객체들을 정의함으로써, 실세계와 소프트웨어의 의미적 차이를 줄이는 작업

 

객체 식별

• 구조 모델링의 첫 번째 작업
• UML에서 정의하는 클래스
  • <클래스명, 클래스 속성, 클래스 연산> 3요소로 구성
  • 클래스 간에 어떤 상관성이 있는가를 클래스의 관계로 나타냄
• 식별 방식 1 : 문장 분석
  • 유스 케이스 설명서의 정상 시니리오와 예외 처리 시나리오에 나타난 문장들의 구성 요소를 분석
  • 일반 명사는 클래스로, 동사는 클래스의 연산으로, 고유 명사는 클래스의 인스턴스인 객체로, 형용사는 클래스의 속성으로 매핑
  • 존재 동사, 소유 동사는 클래스 간의 관계로, 타동사는 연산으로, 자동사는 클래스에 있는 예외 처리 연산으로, 부사는 연산 또는 관계의 속성으로 매핑
• 식별 방식 2 : 일반 객체 목록
  • 도메인 별로 나타나는 일반적인 용어들을 식별하여 목록화한 후에, 이를 구조 모델의 클래스로 사용한다면 객체 식별이 용이해짐
  • 비즈니스 도메인에서 사용되는 객체 그룹 분류
    • 물리적으로 존재하는 사물 : 책, 의자, 사무실, 장비 등과 같은 객체
    • 사건 : 업무 처리 과정에서 발생하는 이벤트로, 회의, 출장, 성과, 보고 등의 객체
    • 역할 : 문제 영역에 나타나는 역할자로, 의사, 간호사, 환자 등과 같은 객체
    • 상호작용: 업무 수행 과정에서 발생하는 처리에 관한 것으로, 판매 처리, 등록 처리, 갱신 처리 등과 같은 객체
    • 기타 : 장소, 조직, 정책 등과 관련 있는 객체
• 식별 방식 3 : 브레인 스토밍
  • 프로젝트 관련자들의 생각으로부터 객체를 추출하는 방법
  • 요구 사항이나 사용사례 설명서에서 누락될 수 있는 객체들을 식별하는 좋은 기회 제공
  • 유의할 점 : 기능 모델의 산출물,  예를 들면 유스 케이스 설명서 등을 사전에 검토하지 않아야 함
• 식별 방식 4 : 패턴 적용
  • 패턴 : 빈번히 발생하는 실세계의 문제를 해결하기 위하여 체계적으로 작성된 클래스와 이들 간의 협업 관계를 정의
  • 소프트웨어 개발에서 재사용 가능한 컴포넌트
  • 객체의 나열과 객체 간의 관계를 미리 정의
  • 패턴에 포함된 객체를 구조 모델의 클래스로 직접 사용 가능 

 

클래스 명세

• CRC 카드 (Class - Responsibility - Collaboration Card)를 이용하여 작성
• 기본 정보 명세
  • CRC 카드의 앞면과 뒷면에 클래스 정보를 명세
  • 앞면에는 대체로 클래스에 대한 기본 정보를 표현, 클래스 이름, 식별자, 클래스 타입, 클래스 설명, 관련된 유스 케이스 식별자, 클래스의 책임, 협업 관계를 표현 
• 클래스 명세를 위한 카드 전면부 예시
  • Type 항목 : 클래스가 구체 클래스인지 추상 클래스인지 구분, 도메인으로부터 추출된 클래스인지, 사용자 인터페이스 클래스 등을 의미하는 응용 클래스인지 구분
  • Associated Use Cases 항목 : 해당 클래스가 도출된 유스 케이스 식별자 ID를 정의
  • Responsibilities 항목 : 클래스의 책임, 즉 클래스가 담당해야 하는 단위 기능
  • Collaborators 항목은 해당 클래스가 상호 작용하는 다른 클래스를 식별하여 정의
• 클래스 명세를 위한 카드 후면부 예시, 속성 및 연산 명세
  • CRC 카드의 뒷면에는 클래스의 속성과 연산을 정의
  • Attributes 항목 : 클래스에 정의하는 멤버 변수, 즉 속성 목록 
  • Relationship 항목 : 클래스에 포함되는 연산, 해당 클래스와 상호 작용하는 다른 클래스들과의 관계

 

클래스 다이어그램 작성

• 식별된 모든 클래스를 CRC 카드에 명세한 후에 클래스 다이어그램 작성
• 소프트웨어의 구조를 나타내는 정적 모델
• 각 클래스가 갖는 속성과 연산을 다시 한 번 점검하고 정제한 후에 클래스 간의 관계 부여
• 기본적인 관계 유형
  • 일반화 관계 : 식별된 클래스들을 추상화하여 보다 보편적인 클래스로 나타냄
  • 집합 관계 : 구성 또는 조합 관계
    • 집합체 클래스와 구성 클래스 간에는 "Part of" 관계 형성
  • 연관 관계 : 두 클래스 간의 관계가 일반화 관계와 집합 관계에 속하지 않는 경우
• 클래스 다이어그램에 표현되는 추가 정보
  • 속성 가시성 : 클래스의 속성으로 정의되는 변수가 갖는 접근 범위, 속성 가시성은 Public 변수(+), Private 변수(-), Protected 변수(#)로 구분
  • 관계 기수성(Multiplicity) : 서로 연관을 맺은 두 클래스 간에 몇 개의 인스턴스, 즉 객체가 몇 개 발생할 수 있는가를 나타내기 위해 사용

 

---

행위 모델링

• 시스템의 내적인 동작을 표현하는 다이어그램
• 객체 간에 어떤 상호작용이 발생하는지를 나타냄
• 객체 지향에서 객체 간의 상호 작용은 메시지 패싱으로 이루어짐, 함수 호출과 동일한 개념, 클래스가 아닌 객체, 즉 클래스의 인스턴스 수준에서 이루어짐
• 클래스가 아닌 객체를 기준으로 작성
• UML의 동적 모델에 해당
• 액티비티 다이어그램, 순차 다이어그램, 통신 다이어그램, 상태 기계 다이어그램 등을 이용하여 시스템의 동적 행위를 모델링

 

순차 다이어그램 구성 요소

• 객체 간의 상호작용, 즉 메시지 패싱에 대한 행위를 시간 축 중심으로 나타냄
• 참여 객체
  • 한 클래스의 객체가 여러 개 존재할 수 있음
  • 참여 객체 간의 상호작용은 일반적으로 왼쪽에서 오른쪽으로 진행하도록 표현
  • 액터도 참여 객체의 한 유형으로 고려될 수 있음
• 시간 축
  • 다이어그램의 세로축
  • 메시지 전달의 순서를 위에서 아래 방향으로 나타내며, 업무의 처리 흐름과 일치해야 함
  • 시간 축은 각 객체가 활성화된 시간을 점선으로 표시, 객체의 라이프 라인이라고 함
• 실행 사건
  • 실행 동작이 발생하는 기간을 길쭉한 사각형의 실행 사건으로 표현
• 메시지 전달
  • 객체 간의 상호작용을 나타내는 기본 요소, 객체 간의 함수 호출을 의미
  • 호출되는 메서드(연산)의 이름과 매개변수가 화살표로 표시됨
• 제어 로직
  • 소프트웨어의 행위를 표현함, 선택, 반복, 병렬 처리 등
  • 결합형 심볼, 반복적, 기본적인 요소인 조각들을 묶어 추상화된 개념의 제어 로직으로 표현
  • 다이어그램의 복잡도를 감소시키며, 이해도를 높이는 역할
• 결합형 심볼 : Alternative(선택)

• 결합형 심볼 : Loop(반복)

• 결합형 심볼 : Parallel(병렬)

 

순차 다이어그램 작성

• 순차 다이어그램 : 기능 모델링의 결과로 식별된 유스 케이스별로 작성
• 유스 케이스의 개수와 순차 다이어그램의 개수는 일반적으로 동일함
• 순차 다이어그램을 작성할 유스 케이스를 검토
  • 유스 케이스의 정상 시나리오 부분의 철저한 분석과 이해 필요
• 참여하는 클래스 나열, 이들의 객체를 생성하여 상단에 나열
  • ABCD 규칙 적용, 왼쪽부터 Actor 객체, Boundary 객체, Control 객체, Data 객체 순으로 나열
• 메시지의 전달은 시간의 흐름을 기준으로 유스 케이스의 시나리오 스텝에 따라 화살표로 표시
  • 화살표는 상호 교차점이 존재하지 않도록 해야함

 

상태기계 다이어그램 작성

• 시스템 상태들의 변화로 모델링하는 수단
• 시스템이 어느 한 상태에 존재하다가 이벤트가 발생하면 다른 상태로 전이하는 동작을 표현
  • 상태 : 시스템을 구성하는 변수들의 특정 값들
  • 이벤트 : 변수들의 값을 변경하는 역할 수행
• 상태 기계 다이어그램 : 객체의 상태 변화 표현
  • 객체가 생성되어 소멸될 때까지의 변화

• 상태 전이를 유발하는 레이블 표현 형식
  • 특정 Event가 주어진 Guard condition 하에서 발생하면 슬래시 다음의 Action을 수행하고 상태를 전이
  • 아무런 표기 없이 단지 슬래시로만 레이블을 구성하는 경우(_/_) : 상태 S1에 도착하면 무조건 상태 S2로 전이

---

분석 산출물 점검

• 일관성 점검 : 설계 과정에 들어가기 전, 분석 결과물에 대한 일관성 점검 실시
• 기능 모델과 구조 모델
  • 기능 모델의 유스 케이스 설명서와 CRC 카드 간의 일관성을 점검
  • 모든 클래스의 이름은 반드시 유스 케이스 설명서의 어딘가에 나타나야 함
• 기능 모델과 행위 모델
  • 기능 모델의 유스 케이스는 각각 하나의 순차 다이어그램으로 표현
  • 유스 케이스 다이어그램의 액터는 순차 다이어그램의 액터로 나타나야 함
• 구조 모델과 행위 모델
  • 상태기계 다이어그램은 클래스의 인스턴스와 매핑
  • 순차 다이어그램에서 객체 간에 전달되는 메시지는 반드시 클래스의 연산으로 정의되어야 함