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)

장비관리 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)

장비관리 - 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)

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

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

 

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

Project.다원 Ensemble_설계(3)_장비관리 ER-Diagram 어제 장비관리 프로세스를 작성을 하고, 머릿속에 있는동안 얼른 정리해버리자 해서 ER-Diagram을 작성했습니다. ER-Diagram의 작성은 여느때처럼 PPT를 이�

karzin.tistory.com

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

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

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

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

 


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

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

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

벌써 34장이된 PPT

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

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

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

 

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

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

 

 

버전정보 (v1.0)

 - v1.0 2020.07.15 배포

 

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

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

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

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

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

 

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

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

Project.다원 Ensemble

Karzin

abbeea@naver.com

 


Project.다원 LikeKeyboard_개발내용


옛~~~날 학부시절 자료들을 찾아보니 만들어놓은 자료들이 꽤나 많아서 이것저것 찾아보다가!!!

원격 키보드 틀을 잡아 놓은 적이 있었더라구요.

분명 학부시절 (아마 방학때 였던듯)에도 만들려고 했는데 졸업작품이다 시험이다 여러모로 밀려서..ㅠㅠ

 

그러고보니 이름도 생각을 해놨었더라구요.(학부시절에 나는 시험말고 이런짓만 하고 있었던 것인가...)

 

아마 이름은 지금 보니 그냥저냥 나쁘지 않은 듯 하여 그대로 가볼까 합니다.

Project.다원 원격키보드 : LikeKeyboard (라키)

아마 이렇게 지은 이름은 키보드 같이! 라는 식으로 지은 것 같습니다 ㅋㅋ (맞는지는 그시절 나에게 물어야..)

 

이제야 생각나지만, 아마 이게 Project.다원의 가장 첫번째로 혼자 만든 기획-분석-설계-개발 시스템이었을겁니다. (미완성으로 끝났지만)

만든지도 오래됬고, 그때 이후로 컴퓨터 폴더 구석탱이에만 남아있었으니 (아마 학부시절 폴더들 쫙 까보면 별별거(혼자서 만든 기획, 분석, 설계, 개발 등등) 다 나올겁니다 ㅋㅋㅋㅋㅋ) 간만에 학부시절 아이템(?)들이나 구경해보자 한게 어쩌면 득이되었네요. 오늘도 이렇게 몇년전의 자신을 떠올리며 용기얻고갑니다 ㅋㅋㅋㅋㅋㅋ

 

말이 좀 옆으로 샜지만, 오늘은 많은 걸 다룰건 아니고,

예전버전 기획서를 조~끔 리메이크해서 다시 작성해봤습니다. ㅋ_ㅋ

리메이크 전과 후를 비교해가면서 보시죠. (정말 별 작업은 안했습니다. ㅋㅋ;;)


예전버전의 Project.다원 원격키보드 - LikeKeyboard

예전버전 LikeKeyboard

 

아마 이게 학부시절에 스타트 끊었던 Project.다원이었을겁니다.

학부시절이니까 지금으로부터.. 음... 4년전? 5년전? 쯤? 될겁니다. (상황에 따라 6년 전?)

그때부터 생각해뒀던건데.. 아마 위에서도 언급했다시피 편입하고 모든 과목을 전공으로 꽉 채워서 들어야만했고, 공부도 공부지만 2년 내에 졸업작품을 마무리해야한다는 사명감? 같은게 있어서 정신없어서 틈틈히 만든다는게 그때문에 아마 못했을겁니다.

이 기획서를 조금 잘 만져서 활용하자 싶어서 다시금 만질만질(???)해놨습니다.

 

웃긴건 누가 내 자신 아니랄까봐 그때도 나눔스퀘어Bold체를 사용했다는게... (소름)

 


새로운 버전의 기획서에 들어갈 LikeKeyboard

새로운 LikeKeyboard

바뀐건 별거 없습니다.

'다' 라고 적혀있던 로고는 한글로 '다원'으로 변경이 되었고,

'Project Dawon'에서 'Project.다원'으로 변경되었습니다.

사실 '다원' 부분에 기존에 적혀있던 '다'라는 글자는 다원의 첫글자만 따서 넣어둔거였는데.. 너무 촌스러워서 (...)

Project Dawon의 경우에도 순 우리말로 했으니 그 의미와 본질을 생각해서 'Dawon'이 아닌 '다원'이 맞다고 생각해 변경했습니다.

그리고 중요한 #2

이건 Project.다원의 2번째 개발 시스템이라는 거죠.

원래는 #1인 이유가 학부시절 처음으로 개인 프로젝트를 만들었던거라.. (비공식, Private)

지금은 공식으로 게시글도 올리고, 이제는 #1으로는 ERP Ensemble이 있으니 #2로 변경하였습니다.

 


LikeKeyboard - 개발 내용 v1

LikeKeyboard - 개발 내용 v1

흠.. 보면 아시겠지만 그때도 단색과, 미니멀리즘? 비스무래한 저만의 디자인을 고집했었습니다.

지금도 생각나지만 도대체 저런 PPT양식은 어디서 구해오니? 라고 교수님께 들었을때 제가 직접 만듭니다 라며 패기있게 말을 했었던 생각이 나네요 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

(믿거나말거나 교수님도 굉장히 맘에 들어하셨습니다.)

특히 저는 글자크기를 최대한 키우는걸 좋아하는데, 이유는 의외로 프레젠테이션을 띄워놓으면 안보인다고 하시는 분들이 많아요. 그래서 글자를 최대한 키울 수 있도록 노력합니다.

옛날 이 디자인 그대로 갈까 하다가, 아무래도 정성도 있고하니까 바꾸자해서 바꿨습니다.

(예전의 나의 느낌과는 다른 느낌으로!)

 

** Computer과 Android 픽토그램은 오픈된 이미지 소스를 이용했었습니다. 다만, 해당 소소의 출처가 명확하게 파악이 되질않아 사각도형에 img label로 대처를 하였고, 아래 개발내용v2에서는 변경을 하였습니다.

 


LikeKeyboard - 개발 내용 v2

LikeKeyboard - 개발 내용 v2

 

음.. 그냥 바꿨습니다 많이는 안바꾸고 뭐랄까 템플릿만 쪼오끔 바뀐정도?

 

자, 여기서 개발내용을 잠깐 설명하겠습니다.(갑자기?)

개발 내용을 자세히 보시면 Android폰이 서버 역할을, Computer이 클라이언트 역할을 하도록 잡혀있는데, 이는 오류가 아닌 제대로된 내용이 맞습니다.

왜 이렇게 했느냐? 학부시절의 저는 Android폰으로도 충분히 서버 역할이 가능하다 생각했었고,(지금의 폰성능을 보면 그이상도 가능하지않을까 싶네요) 그렇기에 실험적인 요소로 Android폰을 서버로 돌리려고 했었습니다.

뭐.. 그렇게 중요한건 아니지만, 아마 이 부분은 추후 Android폰에서 제어할 클라이언트들을 관리하려고 하지 않았을까 싶습니다.

그래서 실험적요소도 재밌고 뭔가 또 즐거운게 생길 것 같아서(??? 두근두근 ???????)

그대로 가기로 했습니다. (씬남!!)

 

** v1에서는 학부시절에 찾았던 오픈된 이미지를 사용했었으나, 해당 출처가 명확하지 않아 제거를 하고 변경했습니다. 


마지막으로 그시절 Project.다원의 로고

Project.다원

이건 기획서와는 조금 관련이 없을지도 모르겠지만,

저 학부시절 Project.다원의 로고였습니다 ㅋㅋㅋㅋㅋㅋㅋㅋ

지금도 어디선가 사용했었고, 나쁘지 않아서 그대로 긁어왔네요 ㅋㅋㅋㅋ

저 디자인이 그때거였구나 ㅋㅋㅋ 재밌네요 ㅋㅋㅋㅋㅋㅋㅋ

 

아마 특별히 문제되지 않는 이상은 이대로 진행될 것 같습니다.

 


아무래도 학부시절 저의 폴더들은 노다지인 것 같습니다.

언제 한번 기회봐서 제가 작업한 졸업작품이나 과제하면서 만들었던 설계서 같은 것도 보여드리면 좋겠는데, 다음기회를 노려보도록 하죠. (언젠가는..)

 

 

버전정보 (v1.0)

 - v1.0 2020.07.13 배포

 

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

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

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

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

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

 

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

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

Project.다원 Ensemble

Karzin

abbeea@naver.com

 

 


Project.다원 Ensemble_분석(3)

결재 프로세스 정의(기안-검토-결재)


이번에는 기안-검토-결재 프로세스를 정의해보았습니다.

 

이는 그룹웨어에 따라 많이들 다른 것 같기는 한데, 

저의 경우 제가 쓸때 이런식이면 편하겠다 하는 경우를 상정해서 만든거라 많은 부분이 변칙적일 수 있습니다.

(이레귤러성, 실험적요소)

 

다만, 이런 변칙적인 요소들은 실제 서비스 및 테스트를 진행하면서 바뀔 수 있는 부분으로 추가적인 수정이 이루어질 수 있습니다.

 

 - 결재 프로세스 정의서

Ensemble 결재 프로세스 정의서

** 그림에 사용된 글자체는 네이버 나눔글꼴의 나눔스퀘어 Bold입니다.

** 상단 그림은 제가(Karzin) 직접 만들었으며, 필요한 픽토그램등의 작업도 직접 만든것임을 명시합니다.

** 상단 그림의 저작권은 Karzin에게 있음을 명시합니다.

 

 

1. 기안자는 양식을 선택하고 작성한 후 검토(참조)자, 결재자를 선택합니다.

2. 작성이 완료된 문서는 검토자에게 확인 요청을 보냅니다. (기안자와 검토자 모두 검토 대기 상태)

  2.1. 참조자(타 부서 협조)가 있는 경우 검토자와 함께 확인 요청이 들어갑니다.

  2.2. 검토자나 참조자 중 한명이라도 문서의 반려를 한다면 기안자는 반려사유를 확인 후 내용을 다시 작성해야 합니다.

  2.3. 검토자와 참조자가 확인을 하면 참조자가 있는 경우 우선 참조(타 부서 협조) 결재자에게 넘어갑니다.

  2.4. 참조 결재자가 문서의 반려를 한다면 기안자는 반려사유를 확인 후 내용을 다시 작성해야 합니다.

3. 검토, 참조, 참조결재가 전부 완료라면 마지막으로 결재자가 확인을 합니다.

  3.1. 결재가가 문서의 반려를 한다면 기안자는 반려사유를 확인 후 내용을 다시 작성해야 합니다.

 

 

버전정보 (v1.0)

 - v1.0 2020.06.25 배포

 

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

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

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

 

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

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

Project.다원 Ensemble

Karzin

abbeea@naver.com




 

+ Recent posts