목표와 배경
- UML의 usecase, class, sequence diagram 예시를 학습한다.
- draw.io 활용능력을 키운다.
나에게 있어 설계란,
개발을 요청하는 사람들이 자신의 생각을 효과적으로 정리할수 있게 해주는 틀
로 우선 정리
게시판과 같이 기능 당 CRUD 가 1대1로 대응하는 세부적인 영역의 경우, 개발자는 큰 고민없이 바로 시작가능함.
하지만, 이보다 더 복잡한 비즈니스 룰에 따르는 기능이라면 고객(또는 담당자)은 자신이 원하는 비즈니스의 영역과 구분을 한번에 말하기 힘들고, 중첩된 영역에 대해선 혼자서 말하기 어려움
즉, UML이라는 건 1명의 담당자와 1명의 개발자가 소통하기 위한 도구보단, 서로 다른 업무 혹은 서로 중첩되는 업무를 담당하는 수십명의 담당자들과 한 명의 개발자가 문제를 정의하고 소통하기 위한 도구에 가깝다고 생각.
설계
(TO ME) 내가 개발하고 싶은 걸 다른 사람도 이해하고, 적용할 수 있게 전달하는 방법
- 최소한 누락은 없어야
- 가능하면 개발을 좀 빠르게 진행하는데 도움
(TO ME) 나에게 개발을 요청하는 사람들이 자신의 생각을 효과적으로 정리할수 있게 해주는 도구
- 누락이 없기 위해서는, 설계 기간 동안 언제나 접근가능하고, 수정가능해야함. 문제가 없다면 상시 공유해도됨
- 개발지식은 지양하고 당사자가 UML에 필수적으로 참여해야함
wikipedia's Design chapter에 의하면,
UML offers a way to visualize a system's architectural blueprints in a diagram
여기서 system이니 blueprints니 하는 것들은 여러 당사자들의, 수많은 업무(job)와 프로세스, 그리고 절차들의 합으로서 한번에 나오는 게 아니라고 판단. 이러한 접근과 설계 UML 예시를 바탕으로 기본 경험을 습득
신기하게도,
처음에는 온전히 개발자의 영역이라고 생각하고 접근하고, '한번에' 누락도 없어야하고, 개발에 직접적으로 도움이 되는 '무언가'를 완성하려고 하니까 손도 못댐.
그리고 하는 것 없이 시간은 시간대로 들고, 막연했음, 확신이 없고, 붕뜬 느낌. 근데 원래 그래왔던 거 같음. 처음의 접근을 바꿨으면 됬지.
UML
- wikipedia's UML = Unified Modeling Language
- wikipedia의 modeling lanaguage overview에 의하면, modeling language = {graphical , textual}이고, UML도 해당
Selected UML
- Behavior
- Usecase Diagram
- Sequence Diagram - Structure
- Class Diagram
한편,
개인적으로 하도 영어문법을 많이 배워서 그런가, language하면 grammer로서 textual만 강하게 떠오름. 회화중심으로 배웠으면 language라는 것에 손짓,몸짓 등 눈으로 보이는 것들도 좀더 쉽게 떠올랐을 것 같음
한국어로 '배운 걸 너의 언어로 표현하라'라고 하면 나는 마인드 맵같은 그림부터 그렸을듯함. 편하니까, 그리고 나만 편한 게 아니니까 UML은 코드가 아닌듯
Usecase Diagram
(TO ME) 시각적 요구사항 정의서
일반적으로 엑셀의 글자형태로 제공되는 요구사항 정의서에 대응하여 diagram으로 표현하는 방식이라고 이해. 이에따라 명세적 요구사항 정의서부터 시작
Requirement Specification
요구사항 정의서, 요구사항 기술서, 명세서와 동급으로 일단 이해
- goto google docs
- 참고 예시들 : RS 예시1, RS 예시2, RS 예시3
기능적/비기능적 요구사항
- Functional Requirements(FR)
- Non-Functional Requirements(NFR)
설명에 따라, FR은 메소드로 구현되어 결과를 리턴하는 기능. NFR의 경우 대체로, 그 회사 비즈니스 룰에 의해 제약되는 조건으로 우선 이해, 가령 반도체회사 제조 공정에서만 요구되는 특정 최소값이라든지
Usecase List and Diagram
상단 요구사항을 유즈케이스 목록로 상세화
추가로, Diagram
- 지속 수정을 고려하여 Actor와 usecase 사이 선은 생략
- 현재는 단일 게시판으로서 '게시판 선택(접근)'의 경우 기본값으로 자동 지정되므로 임의로 점선 표시
- 특정 게시판을 접근했을 때, 해당 게시판의 화면 내에서 게시글이 모두 조회되고, 등록/검색 가능하다고 전제
- 게시글상세 화면에서 수정과 삭제버튼을 배치할 것이므로, 상세 조회 아래 수정/삭제
- draw.io and usecase diagram와 draw.io desktop 활용
- 참고 예시 : usecase 예시1, usecase 예시2
Class Diagram
(나중에 인텔리제이 플러그인으로 그릴예정)
- 현재는 상속 안보임, User와 Member 해서 회원쪽에 sns 로그인관련 상속이 생길수는 있을 것 같지만, 지금은 관련없는듯
- 메소드명은 jpa 메소드명들 우선순위로 할듯, 다만 지금 맵퍼라서 계속 바꿔나갈예정
draw.io and class diagram 참고는 해둠
현재 이클립스의 경우 관련 uml 플러그인활용(object aid을 위해선 추가 설정이 필요함. 추후 인텔리제이에서 관련 플러그인 활용으로 대체)
Sequence Diagram
(나중에 인텔리제이 플러그인으로 그릴예정)
draw.io and sequence diagram 우선 활용
현재 이클립스의 경우 관련 uml 플러그인활용(object aid을 위해선 추가 설정이 필요함. 추후 인텔리제이에서 관련 플러그인 활용으로 대체)
