유즈 케이스
1. Use Case 정의
- 시스템이나 서비스를 설계할 때 전체적인 사용자 이용 패턴을 문서화한 것이다.
- 일반적으로 “시스템의 하나 이상의 액터 또는 이해관계자에게 관측 가능한 결과를 산출하는 시스템에 의해 수행되는 일련의 활동의 명세”1)로 정의할 수 있다. 조금 더 쉽게 표현하자면 어떤 행위와 관련된 액터 간에 수행되는 활동을 기술한 것이라고 이해할 수 있다.
유즈 케이스를 그려서 설계하려는 시스템이 어떻게 생겼는지를 문서화하고 동료들과 커뮤니케이션할 때 보여준다. 유즈 케이스 방식 외에도 다른 방식으로 보여줄 수도 있다.
대표적인 도구로는 lucid chart가 있는데 lucid chart 무료 버전은 편집할 수 있는 문서 수가 계정 당 3개로 제한되어 있어 적합하지 않다. 보편적으로 널리 알려져 있는 draw.io를 사용할 것이다.
2. draw io 특징
- github와 연동 가능
- lucid chart는 User Case Template이 있지만, draw io에는 User Case Template이 없기 때문에 Blank Diagram을 사용
3. draw io을 활용하여 Use Case 그리기
- Use Case 그리기
- 포함 관계
예시) 인증 기능은 회원 로그인 기능에 포함된다. 즉 로그인을 하면 인증이 들어간다. - 확장 관계
기능을 수행하면서 일어날 수 있는 분기 중에 하나를 의미한다. - 연관 관계
시스템과 Actor, 시스템과 User case는 연관 관계로 실선으로 표현한다.
3.1 문제발생 _ git amend로 commit 메시지 갈림
Commit 메시지를 구체화하는 과정에서 원격 Repo와 Local Repo가 중간에서 갈리는 현상이 만들어졌다. 현재 상태에서 내가 수정한 것으로 반영되려면 시간적 순서가 엉켜버렸기 때문에 그냥 push하면 안된다.
해결방법
POST Commit을 통해 꼬인 Commit을 날려버려야 한다. 이 부분을 잘 이해하고 있다면 Force Push를 해서 의도한대로 만들 수 있지만 이 방법은 협업시 문제가 발생될 수 있다.
- git amend로 인해 발생한 문제
- Force Push를 통해 문제 해결
4. Pull Request
현재 Feature 브랜치 개발이 끝났고 즉 문서 작업 내용이 끝나서 Pull Request 요청을 해야한다.
방법
- 자동으로 만들어지는 Pull Request
- new pull request 버튼을 클릭하여 반영 브랜치(main)을 확인하고 비교 브랜치(feature/#4-usecase)를 선택하는 방법
요약
- Force Push 할 떄 주의해야하는 부작용(git amend로 commit 메세지 갈림 현상)
- remote에 저장된 내용은 amend 하지 않는 것이 좋다.
- amend 하였을 경우 Force Push 하지 않는 것이 좋다.
- merge가 끝나면 feature 브랜치가 remote에 남게 되는데 반드시 삭제해야 한다.
- 브랜치가 사라진다고 작업 노드가 사라지는 것은 아니다.
- feature 브랜치가 많아지면 복잡해질 수 있다.
inkwon Hwang