목적: 서비스 기획 단계에 있어 UML이란 무엇인지 이해하고,
직접 가상의 모델링을 실습해보자
TODO: Activity Diagram을 만들어보세요

수업

왜 UML?

텍스트가 주는 파워는 강하지만 직관적이지 못하다. 하나의 서비스는 덩어리가 너무 크지만, 이런 서비스를 알리는데에 순수 텍스트로만 접근을 한다면 접근성이 매우 떨어질 것이다. 직관적으로 서비스를 잘 이해하려면 UML이 필수적이다.

복잡한 설명서를 1쪽부터 100쪽까지 읽을 것인가, 시스템의 흐름을 적절한 글과 그림으로 풀어낸 한장짜리 설계도를 볼 것인가?

그래서 UML이 무엇?

• Unified Modeling Language
• 복잡한 사람들의 사고와 생각을 표현하는 도구 혹은 방법론이라고 이해할 수 있다.

어떻게 개발할 것인지를 나열하는 것이 아닌, 이 시스템의 산출물의 역할을 시각화하여 규정하는 것이다.(말 그대로 시스템을 이해하는 것이지, 시스템을 어떻게 만들지에 대한 설명서가 아니다)

이런 과정을 통해 꼭 필요한 행위를 기반으로 한 객체 지향 모델링이 가능해진다

💡 모델링을 할 때 단순화, 일반화, 추상화를 통해 모델링을 해야한다.
예를 들어, 유저의 구구절절한 유입 시나리오나 300포인트를 쓰냐 안쓰냐등의 코어하지 않은 부분은 고려하지 않는다.

무턱대고 모델링을 하지 않고 정제를 통한 모델링을 하므로 내부 구조나 동작의 표현의 자유가 있고, 시스템의 요소들간에 관계를 보기 쉬우며, 설계와 구현간의 일관성을 유지할 수 있다. 무엇이 더 코어한 흐름인지를 나타내는 레벨화도 가능하다.

Usecase Diagram

• 우리 서비스는 ‘무엇’을 제공할 것이고, 그 ‘무엇’을 정의하는 다이어그램이다.

인문학적인 소양이 떨어지다보니 이해하기에는 어렵지만, 행동을 하는 Actor들을 기준으로 그들이 하는 행동(단순, 일반, 추상)들과 Actor들간에 관계를 알 수 있다.(오히려 말보다는 그림이 이해하기 쉽다)

Activity Diagram

• 서비스 흐름에서 가장 코어한 부분만 처음부터 끝까지 일종의 시나리오를 만드는 것

개발자와 UML에 대한 고찰

그래서 UML을 학습해서 우리는 어떤 개발자가 되어야 하냐고 묻는다면,

• (유저 혹은 관리자)액션, 관계에 대한 설계도를 도식화해서 이런구조로 형성이 되어있다라고 설명할 수 있는
• 혹은 그런 서비스를 이해한채로 개발하는 개발자가 되어야한다고 생각한다

그리고 기획, UML 설계를 무조건적인 수용을 할 것인가? 위험하다. 설계도를 바탕으로 우리도 물음표를 던질 수 있어야한다. 공동의 책임이 있다

더 나아가서는?!

상세한 기획에 있어서는 앞선 도표를 바탕으로 스토리보드를 제작하게 된다. 이 때 우리 서비스의 유저의 상당수가 이러할 것이다라는 기준을 잡은 가상인물인 페르소나가 등장한다. 그들의 공통적인 니즈를 설계해두고, 이를 바탕으로 스토리보드를 제작하게 된다.

과제

어떻게?

여러가지 행동 흐름(액터별, 상황별)이 나올 수 있겠지만, 프로젝트나 스터디의 멘토링을 받는다는 가장 거대한 스토리 흐름을 다이어그램에 담아보려고 한다.

결과는?

---

본 후기는 유데미-스나이퍼팩토리 10주 완성 프로젝트캠프 학습 일지 후기로 작성 되었습니다.