Karzin Lab

Project.다원 Ensemble_설계(10)_공통코드-ER Diagram, Class Diagram

흠.. 어제 장비관리 Class Diagram을 올리면서 생각했지만,

공통코드 부분의 ER Diagram이 어떻게 설계가 되었는지 설명한적이 없는것 같더라구요. (장비관리 ER Diagram)

그래서 공통코드쪽만 설계가 어떻게 되었는지, 그리고 하루밖에 지나지도 않았지만, Class Diagram도 추가된 부분이 있어서 그 부분을 설명해볼까 합니다.

공통코드의 ER Diagram 및 Class Diagram(VO)

음.. Class Diagram이라해봤자 table에 맞춰 변경된 VO(Value Object)정도긴 하지만 조금 추가가 필요할 것 같아서 수정했습니다.

각 컬럼별로 설명을 하자면,

 - 코드 ID : 기본키로 잡았으며, 기본키니만큼 중복을 허용치 않습니다. 기존 size를 5로 잡았는데, 코드를 사용할 게시판의 종류에 따라서 이 키가 길어질 수 있어서 그냥 15로 늘렸습니다. (명쾌ㅋㅋㅋ)

 - 부모 코드 ID : 부모 코드 ID를 입력해줍니다. 코드가 어디에 소속이 되는지를 나타내기 위함입니다.

 - 코드 명 : 사용할 코드의 명칭입니다. 유저에게 보여지는 부분입니다.

 - 언어 ID : 외국어도 지원할 생각이기 때문에 들어갔습니다. 지금 생각으로는 한국어, 영어, 일본어는 지원예정입니다.

 - 사용 여부 : 이는 관리자의 판단으로 사용할 수 있는 부분입니다. 사용을 하지 않는 경우 값을 N(0)으로 변경하면 유저에게는 보여지지 않습니다.

 - 등록일자 : 등록한 날짜가 저장됩니다. 혹시 모를 상황(??)을 생각해서 등록자까지 관리하려했는데.. 괜히 일만 커질것같아 (귀찮아서... 원래 등록일자도 관리하지 않을려했...) 추가하지는 않았습니다. 등록자는 추후 필요하겠다 싶을 경우 넣을 예정입니다. (DB에서 컬럼 빼는건 문제가 되지만 추가하는 정도야 뭐...)

이해가 어려우신 경우 이미지의 좌측 하단 예시를 보시면 조금은 파악이 편할 수 있습니다.

버전정보 (v1.0)

 - v1.0 2020.07.15 배포

* 본 게시글의 이미지에 들어간 글씨체는 네이버 나눔 글씨체인 나눔스퀘어 Bold를 사용했습니다.

* 본 게시글의 이미지는 전부 (이미지 내의 픽토그램 등) 직접 제작했음을 명시합니다.

* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.

* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.

* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.

Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등

모든 부분을 혼자 맡아 진행하는 개인 프로젝트입니다.

Project.다원 Ensemble

Karzin

abbeea@naver.com

Project.다원 Ensemble_설계(9)_장비관리-Class Diagram

휴.. 밥먹고나서 샤워하고 부지런히 만들기시작해서 드디어 끝났습니다! (지금시각 1시 4분)

후반부로 갈수록 졸림이 심해져서;; 겨우겨우 참고 마무리했네요 ㅋㅋㅋ;

오늘은 개발전에 거의 마지막으로 Class Diagram을 작성하였습니다.

음.. Sequence Diagram도 작성을 하면 좋을 것 같은데.. 일단 개발진행하면서 작성을 할까 생각은 하고 있습니다.

아직 워낙 해야할일이 많아서 말이죠;;

설계문서가 일단은 마무리가 된 이상 데이터를 저장하기 위한 DB 구축, 개발 세팅(Spring설치 및 MVC모델 구축 등등) 아직 갈길이 멉니다 ㅋㅋㅋ..

추후 Class Diagram은 변경되는 내용이 많을 것 같아 Reverse Engineering을 통해 어느부분이 변경되었는지 비교해보고 오답을 비교(???)하는 시간을 가져볼까 합니다. (오답이라기보다는 왜 변경되었는지 등등)

Class Diagram은 잘만 설계가 되어있다면 개발자 입장에서는 개발할 시간을 엄청나게 줄여줍니다.

그만큼 설계가 어려운면이 이런 부분이 아닐까 싶네요.

문제는 개발자는 Class Diagram을 참조는 하되, 무조건적인 신뢰를 하면 안된다는 것입니다.

설계자도 사람이니만큼 분명 설계서상으로 개발을 진행하다보면 로직상 구현이 불가능할 수 있는 부분이 있을테니까요.

물론, 이런 설계를 자세하고 명확하게 하는 설계자의 설계문서는 신뢰성이 높아지게 되겠지만,

그런 신뢰의 부분은 아무래도 경험과 개개인의 생각의 다름에서 일어나는 문제가 많다보니 문서만을 참조하는 것 보다는 설계자와 개발자간의 커뮤니케이션이 지속적으로 이루어지면서 개발이 진행되어야합니다. 

아래는 이번에 설계된 Class Diagram입니다. 총 3개의 Class Daigram이 나왔습니다.

* Spring MVC 패턴을 기반으로 두고 설계를 진행했습니다.

장비관리 - Class Diagram (1/3)

하나씩 설명을 하겠습니다.

 - EquipmentRestController : 클래스명과 같이 장비관리의 RestController입니다. 여기서 EquipmentService를 통해 장비정보와 장비 상태 Mapper(EquipmentMapper, EquipStatMapper)에 접근을 하여 데이터를 가져오거나 입력합니다. (쉽게 설명하면 버튼의 Event들의 로직)

 - EquipmentController : 장비관리의 Controller입니다.

 - EquipmentService : 장비 관련 Mapper들에 접근하여 DB의 CRUD 작업을 요청합니다.

 - EquipmentMapper : 장비 정보 Mapper입니다. 직접적으로 DB와 연동되어 주로 장비 정보 관련 작업을 진행합니다.

 - EquipStatMapper : 장비 상태 Mapper입니다. 직접적으로 DB와 연동되어 주로 장비 상태 관련 작업을 진행합니다.

 - FileMapper : 파일 관리 Mapper입니다. 파일은 업로드시 서버스토리지에 저장이 되며, 파일명이나 저장위치등의 파일 정보만 DB에 저장이 됩니다. (FTP 방식) Mapper에서는 DB에 연동되어 CRUD만 작업합니다.

 - Callback 객체 : 이건 제가 자주사용하는 요청에 따른 결과 객체입니다. 보통의 데이터도 해당 Callback객체를 이용해 Wrapping하여 결과를 보여줄 예정입니다. (이는 지금은 크게 신경쓰지 않으셔도 될 것 같습니다. 이 부분은 제가 좀 더 커스텀을 하려고 하는데, 이유는 보안적인 요소를 좀 더 강화해볼까 합니다.)

장비관리 - Class Diagram (2/3)

 - MainController : 메인 페이지를 보여주기 위한 Controller입니다. 

 - CommonRestController : 모든 페이지에서 사용가능한 공통적 RestController입니다. 현재 Code, File을 Common형식으로 보고 있습니다.

 - CommonService : 공통적인 Mapper(CodeMapper, FileMapper)들에 접근하여 CRUD를 요청합니다.

 - FileMapper : 파일 관리 Mapper입니다. 파일은 업로드시 서버스토리지에 저장이 되며, 파일명이나 저장위치등의 파일 정보만 DB에 저장이 됩니다. (FTP 방식) Mapper에서는 DB에 연동되어 CRUD만 작업합니다.

 - CodeMapper : 코드 Mapper입니다. DB에 직접적으로 연동되어 코드의 CRUD를 작업합니다.

 - ProjectRestController : 프로젝트 정보를 가져오기 위한 RestController입니다. 여기서는 설계가 마무리되지 않았지만, 개발에 지장이 없도록 projectId및 projectNm을 가져올 수 있도록하여 테스트를 진행할 예정입니다.

 - EmployeeRestController : 사원 정보를 가져오기 위한 RestController입니다. ProjectRestController와 동일하게 userId와 userNm컬럼 정보만 가져와 개발에 지장이 없도록 할 예정입니다.

장비관리 - Class Diagram (3/3)

여기서는 VO(Value Object)의 Class Diagram을 보여줍니다. (해당 Class Diagram이 어렵게 느껴지신다면 이전에 제가 설계한 ER Diagram과 비교하면서 확인해보세요! 전혀 어렵지 않습니다!)

 - File : [파일], 파일테이블의 컬럼을 담을 변수를 가지고 있으며, 각 변수의 getter/setter를 가지고있습니다.

 - Code : [공통코드], 공통코드테이블의 컬럼을 담을 변수를 가지고 있으며, 각 변수의 getter/setter를 가지고있습니다.

 - EquipStatus : [상태 정보], 상태정보테이블의 컬럼을 담을 변수를 가지고 있으며, 각 변수의 getter/setter를 가지고있습니다.

 - Equipment : [장비 정보], 장비정보테이블의 컬럼을 담을 변수를 가지고 있으며, 각 변수의 getter/setter를 가지고있습니다.

1시 4분에 게시글쓰기 시작했는데 벌써 1시 53분이네요 ㅠㅠ;

이미지로 뜨고 올려놓고 설명을 적다보니 틀린부분이 몇몇 보여서 바로 수정하고 다시 업로드하고 그런 반복적인 작업이 있다보니 시간이 걸려버렸습니다. 아무래도 사람이 만들었다보니.. (심지어 졸면서.. 졸음설계?!)

별거 안한거같은데 벌써 정리된 설계문서(PPT)는 34장이네요;;;

이제부터는 본격적으로 개발에 들어가면 될 것 같습니다.

위에서 언급한것처럼 Sequence Diagram의 경우 개발을 진행하면서 작업을 해볼까합니다.

그리고 개발을 진행하면서 발생한 문제나 그 문제를 어떻게 해결했는지 등도 작성을 해볼까합니다.

오늘도 고생많으셨고, 항상 긴 글 읽어주시느라 감사할따름입니다.

편안한 밤 되시기를 바랍니다.

버전정보 (v1.0)

 - v1.0 2020.07.15 배포

* 본 게시글의 이미지에 들어간 글씨체는 네이버 나눔 글씨체인 나눔스퀘어 Bold를 사용했습니다.

* 본 게시글의 이미지는 전부 (이미지 내의 픽토그램 등) 직접 제작했음을 명시합니다.

* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.

* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.

* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.

Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등

모든 부분을 혼자 맡아 진행하는 개인 프로젝트입니다.

Project.다원 Ensemble

Karzin

abbeea@naver.com

Project.다원 Ensemble_설계(3)_장비관리 ER-Diagram

어제 장비관리 프로세스를 작성을 하고, 머릿속에 있는동안 얼른 정리해버리자 해서 ER-Diagram을 작성했습니다.

ER-Diagram의 작성은 여느때처럼 PPT를 이용하였습니다.

미리 말씀드리지만, 개발중에 해당 설계문서는 어떤 사유로든 변경이 될 수 있습니다.

이는 개발하면서 문제가 있을법한 로직을 제거하거나, 조금 더 다듬어 나가면서 생길 수 있는 수정으로 확정이 아님을 미리 말씀드립니다.

설명은 다이어그램이 우선 보여져야할 것 같아 그림을 먼저 보시고 설명을 하겠습니다.

장비 관리 ER-Diagram

공통코드, 사원정보, 프로젝트 정보 테이블의 경우 아직 설계중인 단계이다보니 PK수준으로만 잡아두었습니다.

이 부분의 경우 추후 변경될 가능성이 굉장히 높습니다.

우선 왼쪽부터 오른쪽으로 천천히 훑어 나가겠습니다.

상태 정보

상태 정보는 장비의 상태를 계속해서 업데이트 해나가기 위한 테이블입니다.

해당 테이블은 추후 사용 가능성이 있어 일단 테이블의 PK를 장비 정보 테이블의 관리코드 PK로 통일하지 않았습니다.

또한 상태정보도 계속해서 변경이 가능하며, 상태 정보는 공통코드로 등록된 정보를 토대로 불러올 예정입니다.

(수리, 불용, 사용중 등)

일자는 변경된 일자를 나타냅니다.

추가로 상태정보 테이블에서는 담당자(사용자)가 변경되거나 관리자(유지보수)가 변경이 되어도 변경된 이력은 계속해서 남길 예정입니다.

변경 사유등도 상태정보로 남겨서 왜 변경이 되었는지 남기기 위함입니다.

장비 정보

장비 정보는 기본적인 장비의 정보를 나타냅니다.

장비 명, 모델 명, 제조사, 규격, 사용용도 등..

특히 규격과 사용용도는 TEXT타입으로 두어 규격이 바뀌더라도(예를들어 PC의 경우 램이 바뀐다던가의 업그레이드가 있을 수 있으므로) 수정이 가능하도록 하였고, 사용 용도 또한 어떤 용도로 사용할것인지 길게 작성하도록 TEXT타입으로 했습니다.

특이사항 컬럼은 음.. 그냥 특이사항 있으면 적으면 좋겠다 싶은 생각에 넣어보긴했는데, 굳이 사용은 안할거같으면 추후 제거예정입니다.

프로젝트는 현 장비가 프로젝트에 귀속이 되어있는 경우를 생각했습니다.

예를들어 장비를 한 프로젝트를 위해서만 구입을 했고, 프로젝트가 끝나면 불용처리를 해야하는 등의 특수한 경우라던가, 그냥 평범하게 프로젝트에서 쓸거다 싶은경우만으로도 프로젝트를 연결하여 어떤 프로젝트를 위한 장비인가를 나타내기 위함입니다.

파일의 경우 1:다로써 하나의 장비에 사진이 10장이든 20장이든 100장이든(그런경우는 드물겠지만) 등록을 할 수 있도록 하였습니다.

장비 정보에 등록되는 상태 정보는 항상 1:다로써 Log형식으로 쌓여나갈 것입니다.

그리고 구입 정보를 나눠 둔 이유는 다른쪽 문서에서 사용될 가능성이 있어 빼두었습니다. (구매 증빙자료등의 자료를 활용하기 위함)

구분과 분류는 장비의 카테고리를 나타낸다 보시면 될 것 같습니다.

구분은 하드웨어인지, 소프트웨어인지 기타인지를 나타낼 것이며

분류는 장비를 나누기 위한 대 분류라고 보시면 될 것 같습니다. (예로 모니터, 데스크탑, 서버, 워크스테이션 등)

구입정보

위에서 언급했다시피 구입정보는 추후 다른 문서에서 사용될 가능성이 높아 빼두었습니다.

구입년도를 빼 둔 이유는 구입년도로 필터링을 조금 더 빠르게 해볼까 해서 빼두었..(어려운건 아닌데 java나 javascript상에서 년도만 나눠서 보여주기 귀찮았습..(ㅡ,.ㅡ) )

구입일자, 구입처, 가격, 수량 이 모든 컬럼들은 기본적인 구입정보를 나타내며,

특이사항으로 구매증빙자료 = 파일 ID를 나타냅니다.

구매 증빙자료는 PDF, 이미지, HWP, DOC 등등 어떠한 구매 자료를 저장이 가능하도록 대응할 예정입니다.

(추후 실험적 요소로써 웹상에서도 PDF, HWP 등을 바로 열어 볼 수 있도록 할까 합니다. - 물론 괜찮은 opensource가 있다면..)

추가로 결제정보 ID는 나중에 결제된 문서의 ID를 연동할 예정입니다. (현재는 설계 시작도 못해둔 상태)

파일

해당 테이블은 공통적인 요소로 여러 부분에서 사용할 예정입니다.

공통코드등의 테이블은 뒷전인데 왜 파일테이블은 설계가 되었냐고 물어보신다면,

파일은 당장 사용할 예정이고, 공통코드는 text형식으로 입력을 해두고 추후에 컬럼타입을 바꾼다던가 하는 방식을 취해도 되기 때문입니다. (결코 귀찮은게 아니라 다 생각이 있어서 그렇게 한겁니...)

이름, 위치, 크기, 확장자, 등록일자는 크게 설명할 부분은 없을 것 같고,

한가지 특이사항이라면 사용유무입니다.

사용유무는 삭제를 했는지, 아니면 기본 저장상태인지를 나타낼 예정입니다.

유저가 삭제를 한 경우 DB에서는 이력으로 남지만, 스토리지에서는 해당 데이터는 제거됩니다.

이는 세팅에 따라 제거도 하지 않을 수 있기도 하구요. 혹은 15일등 특정 기간을 걸어 삭제 후 15일이 지나면 스토리지에서는 제거가 된다던가의 형식을 취할겁니다.

이렇게 한 이유는 가끔씩 잘못 삭제를 해놓고 "이전 파일이 필요한데.." 싶은 분들이 간혹 있더라구요. 

물리적으로 제거가 된다면 나중가서는 복구하기는 어려우니 말이죠.

이 글 작성한다고 11시가 좀 안되서 시작한거같은데.. 벌써 11시 53분이네요;;

(사실 작성은 한 11시 40분쯤 끝났는데, 작성된 게시글을 한번 더 보고 수정할거 수정하고 배포하려고 시간이 걸렸습니다..ㅎ...)

이제 ER-Diagram이 나왔으니 다음 시간은 Wireframe차례입니다!

그리고 그 다음은 바로 개발이 될지 Class-Diagram을 작성할지 모르겠네요.

버전정보 (v1.0)

 - v1.0 2020.07.05 배포

* 본 게시글의 이미지에 들어간 글씨체는 네이버 나눔 글씨체인 나눔스퀘어 Bold를 사용했습니다.

* 본 게시글의 이미지는 전부 (이미지 내의 픽토그램 등) 직접 제작했음을 명시합니다.

* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.

* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.

* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.

Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등

모든 부분을 혼자 맡아 진행하는 개인 프로젝트입니다.

Project.다원 Ensemble

Karzin

abbeea@naver.com