#000#IT_Knowledge#010#Develop_Knowledge#010.20#Diagram_UML#010.20 a#UML_Diagrams

다이어그램을 쓰는 이유

UML이나 다이어그램에대한 설명은 인터넷에 많이 있다보니 UML다이어그램에 대한 생각, 예시로 글을 진행하겠다.

일단 다이어그램은 시각화를 한다. 컴포넌트 단위, 함수 단위, 한 시스템 단위, 전체 시스템 등등 그 범위와 목적에 따라 시각화를 진행하게된다. 다이어그램을 그리다보면 내가 미쳐생각하지못했던 변수, 로직에 대해 깨닫게된다. 왜냐하면 머릿속에서 어 이러면 될거겉은데 하고 그리다보면 아 여기서 이거 처리를 해줘야되네 같은느낌이다.
또 여러명이서 협업을 할때 꼭필요하다. 서로 어떤 주제와 목적과 제한을 가지고 이 프로그램을 이해하고있는가를 일치시키는 행동이기 때문이다. 이 과저에서 변수명이라던가, 화면구성이라던가, 외부 DB참조등도 이야기를 해서 정하게 될 수 있다. 이래야 나중에 문제가 안 생긴다... 그리고 IT계열뿐만 아니라 위에 보고할때나 그런 자리에서까지도 쓸 수 있는 게 다이어그램이라고 생각한다. 나중에 실제 일을 할때는 IT인들 뿐만아니라 IT를 하나도 모르는 사람들에게 내가 무엇을 하고있고, 무엇이 가능한지를 설명해야되는 순간이 무조건온다. 왜냐하면 사실 같은 IT라도 분야가 다르며 모르는경우도 많기 때문

중요한것...

물론 여러 다이어그램을 아는 것은 중요하지만 개인적으로는 어떤 목적에 어떤 다이어그램을쓰고 어떤 요소를 기준으로 할 것인가?이다.
예시를 들어보자. 우리는 마침 기획단계에서 여러 이해관게자를 설득하기 위한 다이어그램이 필요하다. 처음 만나는 개발자와 IT를 모르는 분들도 이해하기 위한 기획단계의 다이어그램이 필요하다. 어떻게해야할까?

이런 상황에서는 먼저 너무 세부적이면 안된다. 기획은 언제든 바뀔 수있고 토의하는 자리이다. 너무 딱딱하게 시스템을 잡는다면 결국 다시 고칠 것이다. 또한 처음협업하는 개발자와 IT를 모르는 분들을 위해 단어선정, 표현도 너무 어려우면 안된다. 우리는 전체적으로 이런이런느낌의 프로그램입니다가 전해져야하는것이다.
그렇다면 적절한 것은 유스케이스 다이어그램이 될 것이다.

다음은 유스케이스 다이어그램예시이다.
다음과 같이 전체 시스템의 동작뿐만아니라 누구나 쉽게 사용하는 단어로 이해 가능하다.
출처

이 다이어그램을 그리기전에 Actor즉 사용자는 누구인가? 작동하는 동작 유스케이스는 어떤것들이 있는가? 그리고 유스케이스와 유스케이스 또는 액터와 유스케이스의 관계 및 의존성등은? 이런 것들을 생각하고 판단하는게 중요하다

개인적으로 자주 사용하는 것은 상태다이어그램과, 시퀸스 다이어그램이다.
상태다이어그램은 좀더 개발에 딥다이브하여 정확한 상태의 변화를 표현하기위한 다이어그램이다. 우리가 중요시하는 데이터구조를 설정하는데 쓰인다고 할 수 있다.

다음 예시에서는 문이라는 객체가 어떤 동작들에의해 어떤 상태가 되는지 chatgpt로 그린그림이다. 뉘앙스 자체는 우리가 문이라는데이터에대해 어떤 동작(문이열림,닫힘, 버튼)이되는지 기준을 세우고 시각화한다. 즉 여기서도 어떤것을 객체로 둘것인가? 어떤 동작이 있는가? 그래서 해당동작으로 객체의 상태는 무엇에서 무엇으로바뀌는가?를 정의하는게 어렵지 그리는것은 문제가 아니다.

시퀸스 다이어그램

다음과 같이 시간의 흐름에 따라 시스템과 객체의 상호작용흐름을 나타낸 다이어그램이다.
여기서도 어떤시스템이 들어갈까? 객체와 시스템간의 상호작용 순서는? 상호작용은 어떤 것들이 있을까? 이거 빼고 저거 넣어도되나? 등이 정말 고민하고 중요한부분이지. 이후 그리는 것은 쉽다