프로그램 설계에 필요한 다이어그램 uml 클래스 다이어그램 erd 시퀀스 다이어그램

다이어그램은 프로그램 설계에 필요하다. 머리 속에서 생각하는 것도 설계에 해당된다. 다이어그램은 가시적으로 파악하고 쉽게 이해할 수 있도록 문서화시킨 것이다. 다이어그램을 그리는 것은 귀찮은 작업이지만, 일단 그려보면 굳이 시스템을 구현하지 않아도 무엇이 필요한지 어떻게 움직이고, 데이터는 어떻게 흘러가는지 파악할 수 있다. 대표적으로 자주 사용되는 것은 uml, class diagram, erd, sequence diagram 정도이다.

프로그램 설계 다이어그램

프로그램 설계에 필요한 다이어그램
UML, 클래스 다이어그램 ( Class Diagram ),
ERD, 시퀀스 다이어그램 ( Sequence Diagram )

프로그램을 만들 때 기획을 하고 설계를 하게 된다.
개발자라는 입장에서 기획자가 작성한 문서를 보고 만들면 그만이긴 하지만, 코드의 양과 규모가 커지면 헷갈리기 시작한다.
다이어그램은 이런 것을 예방하고 기획자가 작성한 업무의 순서나 프로세스를 기억할 수 있도록 한다.
더욱이 잘그린 다이어그램 하나로 업무 분석이 끝나는 경우들도 있다.
단순히 개발을 위한 코딩의 수준을 벗어나는 그런 것이기도 하다.

업무를 이해하면 개발이 편해지는 것도 있다.
언어적인 것들은 자연히 부수적으로 따라온다.
모든 다이어그램을 익히면 좋지만 필수적으로 익히면 좋은 것들이 몇가지 있다.

다이어그램

프로그램 개발에 대해 공부하다보면 산출물 중에 다이어그램을 그려달라는 요청을 받을 수 있다.
순서도 정도로 생각할 수 있는 다이어그램을 굳이 왜 그려야 할까 생각할 수 있지만, 중요하다면 중요하고, 그렇지 않다면 사소한 것이다.
개발자 별 생각의 차이다.
하지만, 본인의 경우 생각은 프로그램을 개발하기 전 다이어그램을 그려보는게 어떨까 한다.
어떤 화면에서 어떤 데이터가 흘러가고, 이어지며, 가공되어, 처음부터 끝까지 프로세스가 이어지는 것을 살펴볼 수 있다.
지금은 기획자들도 학습하는 부분들이기도 하다.
잘 그린 다이어그램 하나라면 굳이 코드를 보지 않아도 프로그램이 흘러가는 것을 파악할 수 있고, 기획자와 개발자간의 대화의 간격이 줄어들 수 있는 것도 사실이다.

알아두면 좋은 필수적인 것들

그렇다고 다이어그램을 모두 익힐 필요는 없다.
본인의 경우 4가지 정도만 익혀두면 괜찮겠다는 생각이며, 이것을 기술한다.
다이어그램을 잘 그리는 것도 좋지만, 관계설정에 목숨은 걸지 말도록 하자.
물론, 정확하게 다이어그램을 그리는 것도 중요하지만, 다이어그램을 그리는 목적은 프로그램을 실행시키고 종료할 때까지의 어떤 업무에 대한 데이터의 흐름을 표현하는 것임을 명심하도록 한다.
틀리면 수정하면 된다.
가볍게 그리도록 하자.
아래는 본인이 회사 또는 개인 프로젝트로 진행할 때 그려보는 다이어그램 4가지이다.

• UML
• Class Diagram
• ERD
• Sequence Diagram

보면 익숙하다.
굳이 저걸 왜 그리나 싶겠지만 어떤 계기가 있었기에 그려보는 일이 생겼을 뿐이고, 그려본 후 업무 프로세스를 이해한 이후 갑돌이와 오붓하고 길고 긴 대화의 장이 수월해진 경험이 있었을 뿐이다.
위의 다이어그램이 어떤 것인지 이미 알고 있지만, 굳이 그려야 할까 란 의문이 든다면 그리지 않아도 된다.

다이어그램 적용이 필요한 시기

굳이 다이어그램을 그릴 필요가 있을까?
다이어그램을 한번 그려보거나 익숙한 사람이라면 굳이 코딩을 하지 않아도 프로그램과 시스템이 어떻게 실행되고 운영되는지 머리속에 그려진다.
그렇다면 다이어그램을 언제 그리면 좋을까?
본인의 주관적인 생각은 개발을 위한 코딩 전에 한번쯤 그려보는 것이 좋겠다는 생각이다.
경력이 길거나 깊은 사람이라면 굳이 그리지 않아도 머리속에 전체적인 부분이 그려지겠지만, 그렇지 않다면 다이어그램을 기록으로 남김으로써 시스템을 이해할 수 있다.
특히, 유지보수나 인수인계시 잘 그려진 다이어그램은 후임자에 좋은 참고자료가 될 수 있다.
또한, 굳이 코딩을 하지 않더라도 머리속에 있는 아이디어를 문서로써 작성하여 추후 프로그램 개발시 필요한 부분과 내가 모르는 부분 등을 검토할 수 있다.

• 프로젝트, 개발 개발시작 전
• 유지보수시 업무프로세스 이해가 필요할 때
• 인수인계시 시스템 구성을 설명할 때

다이어그램 설명

대충 서두가 길었으니 이번엔 위에서 언급한 4가지 다이어그램인 UML, 클래스 다이어그램 ( Class Diagram ), ERD, 시퀀스 다이어그램 ( Sequence Diagram ) 에 대해 간단히 언급해 본다.
하나씩 익히면 어렵지만 다이어그램도 순서대로 보면 이해가 쉽다.
설명하는 순서는 다음과 같다.

1. UML
2. 클래스 다이어그램 ( Class Diagram )
3. ERD
4. 시퀀스 다이어그램 ( Sequence Diagram )

위의 내용 중 본인의 주관적 생각인 UML 이 가장 중요하다고 본다.
프로그램의 가장 개요같은 부분이며, 프로그램이 어떤 동작을 할 지 대충 그려볼 수 있기 때문이다.
클래스 다이어그램, ERD, 시퀀스 다이어그램은 첫번째인 UML 부터 시작해도 과언이 아니다.
UML 을 그릴 수 있다는 것은 곧, 어떤 프로그램이든 목적에 맞는 업무나 시스템 구성을 이해하고 있는 것이기도 하며, 순서를 확립하고 관계를 형성하는 것을 개략적으로 표현할 수 있기 때문이다.
왜 이런 생각을 가지게 되었는지는 구글에서 UML 이란 단어를 이용하여 이미지 검색을 해보자.
프로그램의 구성과 흐름이 머릿속에 그려진다면 UML 에 대한 어느정도 이해도가 있다는 것이다.
언제나 그렇듯 첫단추를 꾀는 것이 중요하다고 한다.
UML 은 프로그램 설계의 첫단추이기도 하기 때문에 다른 건 몰라도 익혀두면 두고두고 써먹을 때가 많다.
특히, 인수인계를 받는 입장이라면 소스 코드를 보면서 UML 을 그려보자.
프로그램의 흐름이나 방향성, 목적 등이 점차 이해가 될 것이다.

UML

통합 모델링 언어 ( Unified Modeling Language ) 이다.
단어에서 볼 수 있듯 프로그램의 설계, 구현, 문서화까지 시각화할 수 있다.
단순히 순서도를 넘어 프로그램의 주체인 액터 ( Actor ) 의 활동부터 전반적인 시스템의 흐름 등을 쉽게 파악할 수 있다.

Class Diagram / 클래스 다이어그램

UML 에서 사용하는 다이어그램 중 하나이다.
OOP 객체의 관계와 흐름을 구현하기 전에 구조와 흐름을 만들 수 있다.
속성과 메서드를 직관적으로 표현하고 시각화하여 개발단계에서 필요한 정보를 쉽게 파악할 수 있다.
주로 클래스의 속성과 메서드, 관계를 통해 시스템 설계를 수월히 할 수 있다.

ERD

Entity Relation Diagram 의 약자인 ERD 는 주로 데이터의 관계를 표현하는데 사용한다.
그렇기에 보통  DB  ( 데이터베이스 ) 설계시 주로 사용된다.
기획서와 함께 UML의 OOP 클래스의 속성부분과 연관된다.

Sequence Diagram / 시퀀스 다이어그램

UML 에서 사용하는 다이어그램 중 하나이다.
시스템 또는 프로그램의 동작을 표현하고 실제로 어떻게 실행되는지를 시각적으로 표현한다.
클래스 객체간의 흐름을 표현할 수도 있고, 메서드의 구성을 표현할 수도 있으며,
결과적으로 프로그램의 전체 또는 부분적 흐름을 단계적으로 시각적으로 표현하는데 목적이 있다.

얶매이지 말자.

프로그램 설계를 위해 다이어그램을 그려보는 것은 프로그램의 구동과 데이터의 흐름을 시각적으로 표현하여 전체적인 것을 이해하기 위함이다.
이런 다이어그램을 그려보는 것만으로 여러가지를 공부해 보는 기회가 될 수도 있다.
다만, 너무 메뉴얼적인 측면에 얶매이도록 하지 말자.
여러가지 이유가 있겠지만, 하나의 화면에 모든 것을 담기에는 세상의 정보는 너무 많다.
OOP는 객체지향이고, 클래스의 관게와 데이터들의 관계를 표현한다.
다이어그램을 한번 그려보면 OOP를 이해하는데 큰 도움이 된다.
다이어그램을 그려보기 위해 여러가지 툴이 있지만, 메뉴얼적인 측면에 너무 얶매이지 말고, 자유롭게 그려보도록 한다.
다이어그램의 목적은 프로그램의 움직임과 데이터의 흐름을 가시적으로 표현하여 보는 사람을 이해시키는 것에 중심이다.
기능적인 측면보다는 설득하려는 사람을 이해시키기 위한 목적으로 그려보도록 하자.