좋은 설계는 어떤 문제를 놓고 여러 차례 힘들게 반복(iteration)을 거치면서 진화한다.
UML 이란?
통합 모델링 언어(Unified Modeling Language)는 소프트웨어 공학에서 사용되는 표준화된 범용
모델링 언어로 소프트웨어 개념을 다이어그램으로 그리기 위해 사용하는 시각적인 표기법
왜 UML을 사용해야 하는가?
- 다른 사람들과 의사 소통하기
- UML을 통해 설계 아이디어에 초점을 맞추어 의사 소통하게 되며, 의미가 명확하고 코드에 대한 구조가 어떻게
생겼는지 매우 분명하게 보인다.
- UML을 통해 설계 아이디어에 초점을 맞추어 의사 소통하게 되며, 의미가 명확하고 코드에 대한 구조가 어떻게
- 로드맵
- 전체 시스템의 구조에 대한 참조 도표로 사용
- 교육용 도구로도 유용
- 백엔드(back-end) 문서
- 유지보수 & 인수인계를 위한 설계 문서 → 프로젝트 막바지에 팀의 마지막 작업으로 하는 것이 가장 좋다.
다이어그램의 유형
- 정적 다이어그램 (static diagram)
- 클래스, 객체, 데이터 구조와 이것들의 관계를 그림으로 표현해서 소프트웨어 요소에서 변하지 않는 논리적 구조를 보여준다.
- 동적 다이어그램 (dynamic diagram)
- 실행 흐름을 그림으로 그리거나 실체의 상태가 어떻게 바뀌는지 그림으로 표현 → 소프트웨어 안의 실체가 실행 도중
어떻게 변하는지 보여준다.
- 실행 흐름을 그림으로 그리거나 실체의 상태가 어떻게 바뀌는지 그림으로 표현 → 소프트웨어 안의 실체가 실행 도중
- 물리적 다이어그램 (physical diagram)
- 라이브러리, 소스, 바이너리, 데이터 파일 등 물리적 실체와 이것들의 관계들을 표현 → 변하지 않는 물리적 구조
클래스 다이어그램
사용 & 정의
- 시스템 설계를 문서화하고 해당 설계를 이해 관계자에게 전달하기 위해 사용
- 클래스 내부의 정적인 내용이나 클래스 사이의 관계
- 클래스의 멤버 변수(member variable)와 멤버 함수(member function)
- 클래스가 다른 클래스에 상속되었는지, 다른 클래스를 참조하는지 표현
- 소스코드에 나타나는 클래스 사이의 의존 관계
구성 요소
- 클래스 (Class) : 해당 클래스의 객체가 갖게 될 속성(데이터 멤버) 및 메서드(멤버 함수)를 정의하는 객체의 청사진
- 속성 (Attribute) : 이름, ID 또는 상태와 같은 클래스의 데이터 멤버 또는 속성
- 메서드 (Method) : 클래스가 수행할 수 있는 멤버 함수 또는 작업
- 연관 (Association) : "일대일", "일대다" 또는 "다대다"와 같은 둘 이상의 클래스 간의 관계
- 상속 (Inheritance) : 기본 클래스와 파생 클래스 간의 관계
- 인터페이스 (Interface) : 인터페이스 자체가 아닌 인터페이스를 구현하는 클래스에 의해 구현되는 관련 메서드 모음
- 패키지 (Package) : 구성 목적을 위해 함께 그룹화되고 관련되는 클래스 및 기타 요소 그룹
시퀀스 다이어그램
사용 정의
- 개체 또는 구성 요소 간의 제어 및 데이터 흐름을 설명할 때 자주 사용
- 전반적인 시스템 흐름 시각화
- 각 동작에 참여하는 시스템이나 객체들의 수행기간 확인
- 메시지의 명확한 순서
- 특정 행동이 어떠한 순서로 어떤 객체와 상호 작용을 하는지 표현
구성 요소
- 객체 (Object) : 상호 작용에 참여하는 개체 또는 구성 요소의 개별 인스턴스
- 생명선 (Lifeline) : 일련의 상호 작용에 참여하는 개체 또는 구성 요소와 객체의 생성, 소멸, 활성화 상태를 표현
- 활성화 막대 (Activation bars): 메시지 교환 중 개체 또는 구성 요소의 처리 시간
- 메시지 (Message) : 객체 간의 통신 또는 주고받은 데이터로 요청(Request)과 응답(Response)으로 구분
유스케이스 (Use Case)
사용 정의
- 소프트웨어 개발의 초기 단계에서 기능 요구 사항과 사용자의 요구 사항을 캡처하고 문서화하는데 자주 사용
- 시스템의 동작 하나를 기술
- 방금 시스템에 특정한 일을 시킨 사용자의 관점에서 작성
- 사용자가 보낸 자극 '하나'에 대한 반응으로 시스템이 진행하는 '눈에 보이는' 이벤트들의 흐름을 포착
구성 요소
- 행위자 (Actors): 시스템과 상호 작용하는 사용자 또는 외부 시스템
- 사용 사례 (Use cases) : 사용자 또는 이해 관계자의 요구를 충족하기 위해 시스템이 수행하는 특정 작업
- 관계 (Relationships) : 연결, 일반화 및 포함과 같은 행위자와 사용 사례 간의 상호 작용 또는 관계
마치며 (개인적인 생각)
UML, 다이어그램 (Diagram), 유스케이스를 정리하며 업무 또는 개인적인 프로젝트를 진행하면서 문서 작성 경험에 대해 생각해 보았다. 나의 첫 개발 문서는 국비 지원 교육 과정에서 팀원들과 같이 작성했던 ERD 였다. ERD도 초기 기본 모델만 작성했던 걸로 기억한다. 지금 생각해 보면 "도대체 ERD만 가지고 어떻게 팀원들끼리 소통하고, 개발을 했을까?"라는 생각이 들었다.(의문점 투성..) 이 후 지금까지 ERD 뿐만 아니라 위와 같은 다이어그램들을 사용하여 프로젝트를 진행하였다. 나에게 다이어그램은 프로세스에 대한 이해, 프로젝트의 구성 등 말로는 이해되지 않던 것들을 더 빠르게 이해하며 습득할 수 있게 해주는 좋은 도구였으나 동시에 다이어그램을 작성하며 많은 시간을 투자하여 효율성이 떨어지는 경우도 있었으며, 오히려 문서 작성에 몰입하여 개발 시간이 부족한 상황도 겪어보았다. 이러한 경험들을 해보니 UML은 사용하기 나름이며, 효율적으로 사용해야한다고 생각한다.
UML 사용하는 것은 좋을 수도 나쁠 수도 있다.
시간과 에너지를 낭비한다면 작성할 필요가 없으며 꼭 필요할 경우에만 사용하자.
