DAY 69. UML - 개념 & 유스케이스 다이어그램

 

Chap 01. UML 개념

 

모델링(Modeling)

모델을 만드는 작업을 뜻한다.

즉, 현실 세계를 단순화 시켜서 표현하는 기법이다.

 

절차지향 모델링 → 한계 도달 → 객체지향 모델링 → 표기법 다양/호환성 문제 → UML 공표

 

UML (Unified Modeling Language)

통합 모델링 언어는 소프트 웨어 공학에서 사용되는 표준화된 범용 모델링 언어이다.

소프트웨어 개념을 다이어그램으로 그리기 위해 사용하는 시각적인 표기법이다.

 

✔️ UML의 필요성

1. 의사소통 하기가 좋다.
2. 대규모 프로젝트 구조의 로드맵을 만들 때 유용하다. (클래스—클래스 의존 관계를 개발자가 빨리 파악할 수 있다.)
3. 개발할 시스템 구축에 대한 기초를 마련할 수 있다.
4. 백엔드 문서용으로 제격이다.

 

✔️ UML 작성 시 주의할 점

1. 핵심적인 기능 위주로 작업할 것(행위를 가장 우선적으로 작업한다.)
2. 반복을 통해 다듬을 것 (구현을 하면서도 발생하는 수정 사항)
3. 코드를 마음 속에서 그릴 수 있는 힘이 중요하다. (다이어그램으로 코드를 대신하는 것이 아니라, 다이어그램을 보고 코드를 직관적으로 연상시킬 수 있도록)

 

UML 다이어그램 종류

• 정적 다이어그램
• 동적 다이어그램

 

---

 

프로세스별 다이어그램

소프트웨어(프로그램) 개발 프로세스

요구사항 → 분석 → 프로그램 설계 → 프로그램 구현 → 테스트/납품 → 유지보수

 

V 프로세스

<블랙박스 분석 : 사용자의 관점> 행위자 : 유스케이스 → 유스케이스 시나리오 → 유스케이스 시나리오의 정보 >> 클래스 다이어그램→ 시퀀스 다이어그램 → 액티비티 다이어그램 : 요구사항 명세서 <화이트박스 분석 : 개발자의 관점>

 

• 기능 모델링 : 유스 케이스 (기능 위주)
• 동적 모델링 : 유스케이스 시나리오 (기능 + 시간의 흐름)
• 정보 모델링 : 유스케이스 시나리오의 정보 ( 이 정보를 가지고 클래스 다이어그램 → 시퀀스 다이어그램을 만든다)
• 액티비티 다이어그램 : 예외 발생했을 때(예외 흐름), 사용자의 선택에 따른 제어 흐름을 나타낸 것 (보통 시퀀스 다이어그램에서 제어 흐름을 나타낸다.)

 

---

 

Chap 02. 유스케이스 다이어그램(in 동적 다이어그램)

 

요구사항

고객 및 소프트웨어 개발에 관계된 사람들이 시스템 개발에 앞서 개발되는 프로그램에 필요한 조건이나 능력을 말한다.

프로젝트 설계 전에 정확, 완전하게 정의하지 않으면 시스템 구축에 큰 문제가 발생, 프로젝트에 영향을 미친다.

 

✔️ 요구사항 유형

<참여자 기준>

• 사용자 요구사항 : 사용자의 관점에서 프로그램에 원하는 사항
• 시스템 요구사항 : 관리나, 설계자 관점에서 하드웨어 및 프로그램이 갖춰야 하는 사항
• 소프트웨어 요구사항 : 개발자의 관점에서 프로그램이 갖춰야 하는 사항

<내용 기준>

• 기능적 요구사항 : 프로그램을 구성하는 기능들이 무엇인지 정의
• 비기능적 요구사항 : 프로그램의 기능들에 대한 조건과 제약사항들이 무엇인지 정의

<주체 기준>

• 비즈니스(업무) 요구사항 : 의뢰한 단체가 작성한 요구

 

<요구사항 프로세스> 1. 요구사항 추출 : 미팅, 인터뷰를 통해 커뮤니케이션을 하며 개발하고자 하는 시스템에 대해 의사소통을 한다. 2. 요구사항 분석 : 소프트웨어 환경 분석, 유스케이스다이어그램 작성 3. 요구사항 명세 : 유스케이스 다이어그램을 통해 각 별로 어떤 사용자가 어떤 기능을 하는지, 예외처리를 어떻게 할 것인지 명세서 작성 4. 요구사항 검증 : 프로그램 요구한 고객사와 함께 검토, 제 3자의 입장도 참고한다. 5. 요구사항 유지보수

 

 

✔️ 요구사항 조건

1. 명확성 : 기술된 요구사항은 항상 동일한 의미로 해석되어야 한다. → 모호해서는 안된다.
2. 완전성 : 사용자가 기대하는 모든 요구사항이 기술되어야 한다. → 누락되어서는 안된다.
3. 일관성 : 서로 상충되는 요구사항이 있어서는 안된다.
4. 검증 가능성 : 객관적 검증이 가능하도록 구체적이어야 한다.

 

 

유스케이스 모델링

- 이벤트 및 반응 방식 시스템 개발에 효율적인 모델링 방법이다. (기능 모델링) - 시스템 기능을 사용하는 사용자와 시스템 간의 교류를 표현한 것이다. - 사용자 관점에서 시스템의 요구 사항(행동)을 설계하는 것 - 초기 요구 사항 분석부터 마지막 시험, 배치 등 전 공정에서 사용 가능한 수단이다. - 시스템이 해야 할 일(Use Case)과 그 행동을 하는 사용자(Actor)을 함께 표현한 모델이다. - 액터와 유스케이스, 관계로 구성된다.

 

** 모델링에는 정답은 없지만, 공통된 규칙은 반드시 지켜야 한다. 또한, 유스케이스 모델링 작성시에 팀원들 간에 합의된 의견 일치가 있어야 한다.

 

 

유스케이스 다이어그램

동적(행위) 다이어그램으로 시스템 내의 활동들의 흐름을 보여준다.

여러 업무 프로세스를 설명하는 데 좋다.

 

✔️ 액터

시스템과 상호작용을 하는 시스템 외부의 존재로써 (시스템 바운더리 밖에 위치해야한다, 시스템 바운더리를 반드시 그려야 한다.) 개발 대상에 따라 달라질 수 있다.

여러 개의 액터가 존재할 수 있다.

시스템 관점에서 바라본 사용자의 역할을 뜻해야 한다.

 

✔️ 유스케이스

개발 대상이 되는 시스템이 제공하는 개별적인 기능을 뜻한다.

시스템 동작 하나의 기술이다.

사용자가 인지할 수 있는 하나의 기능 단위 (눈에 보이는 것만 그리고 사용자가 인지할 수 없는 것은 그리지 말아라.)

유스케이스 — 유스케이스 간의 관계도 화살표로 표시할 수 있다. (방향성이 존재한다.)

 

✔️ 유스케이스 다이어그램 관계 종류

** 포함 관계 : 기본 유스케이스쪽에서 → 반드시 해야 하는 관계(포함 유스케이스)를 향해 관계 방향을 그린다.

** 포함 유스케이스가 어딘가에서 재사용된다면 그 가치는 올라가게 된다. = <<include>>

** 확장 관계 : 포함 유스케이스에서 → 기본 유스케이스 방향으로 관계 방향이 그려져야 한다.

** 확장 관계는 선택적으로 할 수 있는 관계이다.

** 일반화 관계 : 상속과도 같은 관계이다. 추상화된 유스케이스와 그에 따른 구체화된 유스케이스를 그룹핑해 놓은 관계

 

유스케이스 다이어그램 작업 과정

1. 액터 식별 - 기술서를 보고 액터를 먼저 도출하고 그 역할을 정의한다. 2. 유스케이스 식별 - 사용자가 시스템을 통해 얻으려고 하는 기능을 유스케이스 단위로 도출한다. 3. 유스케이스 다이어그램 작성 - 도출한 액터, 유스케이스 무작위 단순 배치 - 중복 의미의 유스케이스 제거 및 불필요한 유스케이스 제거, 그룹핑 작업 - 액터, 유스케이스 간 관계 설정

 

 

이벤트 흐름

기본 흐름

아무 것도 잘 못 되지 않았다는 가정 하에, 사용자의 자극에 시스템이 어떻게 반응하는지 기술한다.

 

대안 흐름

세부 상황 중 일부가 잘 못 되었을 경우를 고려한 흐름이다.

• 선택 흐름 : 사용자 혹은 시스템에 의해 선택적으로 수행되는 흐름
• 예외 흐름 : 시스템에서 발생하는 에러 등을 처리하기 위해 수행되는 흐름