2024/08/05
데이터베이스 11일 차
오늘은 UML 설계의 4+1 뷰 중 유스케이스 뷰를 알아보고 팀 프로젝트의 요구 사항을 유스케이스 다이어그램으로 표현해 보는 시간을 가졌다.
시스템의 규모가 커지고 복잡해지면서 하나의 소프트웨어에서도 여러 개의 이해관계가 생기게 되었다.
이러한 이해관계들의 역할에 따라 관점을 5개로 나눈 것을 4+1 뷰라고 한다.
이렇게 설계한 모델인 시스템 아키텍처는 점진적인 시스템 개발에 꼭 필요한 중요 요소이다.
유스케이스 뷰는 모든 뷰의 중심 뷰로서 기능적인 부분(요구사항)을 정의하고 명세한다.
유스케이스 뷰를 통해서 시스템이 제공하는 기능이 무엇인지 확인할 수 있다.
2024/08/06
데이터베이스 12일 차
오늘은 클래스 다이어그램의 구성 요소와 표현, 클래스 사이의 관계 구현과 모델링 연습을 해보았다.
어제 만들어둔 유스케이스와 기능 명세로부터 클래스를 추출하고 그 관계를 정의해 보았는데 정말 어려웠다.
WMS 프로그램의 클래스 다이어그램을 보고 분석을 해보았는데 패키지가 엮어있는 복잡한 구조라 이해하기 어려웠다.
특히 아무런 구현도 되어있지 않은 명세만 보고 클래스 다이어그램을 만들기가 까다롭다고 느껴졌다.
어떠한 기능이 들어가고 누가 사용할 것인지에 대한 내용은 명세서와 유즈케이스 다이어그램을 통해 만들어두었지만, 이걸 구현하기 위해 어떤 클래스가 필요하고 어떠한 기능을 메서드로 수행할 것인지에 대한 고민은 없었다.
하나씩 만들면서 확장해 가며 그려봐야겠다고 생각했다.
2024/08/07
데이터베이스 13일 차
오늘은 WMS 프로젝트에서 각자 담당한 기능을 클래스 다이어그램으로 표현하는 시간을 가졌다.
나는 창고와 출고 관리를 맡게 되었는데 클래스 다이어그램을 만들면서 생각하지 못했던 부분이 나왔다.
배경 조사부터 다시 차근히 하게 되면서 각 필드를 정의하고 클래스들 간의 연관 관계를 생각해 볼 수 있었다.
그런데 클래스 간의 데이터가 이동하는 메서드의 경우 코드가 없는 클래스 다이어그램만 보고 만들기가 정말 쉽지 않았다.
그래서 우선 반드시 필요한 CRUD 메서드와 연관 테이블의 필드값을 갖는 생성자들만 만들어 보았다.
이번주까지 클래스 다이어그램을 완성하기로 했는데 점점 업그레이드 해보아야겠다.
공용 필드의 경우, (창고 아이디와 같은) 다른 팀원과 데이터 타입을 맞춰야 하기 때문에 이것도 추후 수정할 예정이다.
2024/08/08
데이터베이스 14일 차
오늘은 저장 프로시저와 저장 함수, 커서, 트리거에 대해 배워보았다.
스토어드 프로시저 (저장 프로시저)는 쿼리문의 집합으로 어떠한 동작을 일괄 처리하기 위한 용도로 사용하는데 쿼리를 모듈화 하여 필요할 때 호출만 하여 편리하게 쿼리문을 실행할 수 있다.
스토어드 프로시저를 사용했을 때 장점은
1) 긴 쿼리가 아니라 짧은 프로시저 내용만 서버로 전송해 네트워크의 부하를 줄이고 MySQL의 성능을 향상할 수 있다.
2) 응용 프로그램에서는 프로시저만 호출하기 때문에 쿼리를 수정하거나 유지보수 할 때 관련 스토어드 프로시저의 내용만 수정하면 되어서 유지관리가 간편해진다.
3) 모듈식 프로그래밍이 가능해져서 언제든지 실행이 가능하고 관리가 수월하다.
4) 사용자 별로 테이블 접근 권한을 주지 않고 스토어드 프로시저에만 접근 권한을 주어 보안을 강화할 수 있다.
스토어드 함수와 스토어드 프로시저의 큰 차이점을 알아보았다.
1) 스토어드 함수는 입력 값만 파라미터로 사용할 수 있고 스토어드 프로시저는 파라미터로 IN, OUT을 모두 사용할 수 있다.
2) 스토어드 함수는 하나의 값을 반환하는데 주로 사용되며 집합 결과를 반환하는 select문을 사용할 수 없다. 반면에 스토어드 프로시저는 여러 쿼리나 숫자 계산 등 다양한 용도로 사용할 수 있고 select문이 가능하다.
3) 스토어드 함수는 본문 안에 return 문을 작성해서 값을 반환하는 반면에 스토어드 프로시저는 별도의 반환하는 구문이 없고 OUT파라미터를 사용해서 반환이 가능하며 call 명령어로 호출한다.
4) 마지막으로 스토어드 함수를 사용하기 위해서는 스토어드 함수 생성 권한을 허용해야 한다.
커서는 스토어드 프로시저 내부에 사용하는 기능으로 쿼리의 집합 결과를 한 행씩 처리한다.
트리거는 테이블에 무슨 일이 일어나면 자동으로 동작을 실행하는 기능으로 DML 이벤트가 발생해야 작동되기 때문에 직접 실행이 불가한 기능이다.
트리거의 종류로는 하나의 테이블에 동일한 트리거가 여러 개 부착되어 있는 것을 뜻하는 다중 트리거가 있고, 트리거가 또 다른 트리거를 작동시키는 중첩 트리거가 있다.
'주간 랩업 > [SSG] JAVA 기반 백엔드 개발 과정' 카테고리의 다른 글
[11주차] 웹 기초 1~3일차 (0) | 2024.08.25 |
---|---|
[10주차] 1차 프로젝트 1일차-4일차 & 회고록 (1) | 2024.08.21 |
[7주차] 데이터베이스 1 - 5일차 (0) | 2024.07.27 |
[6주차] 자바 고급 5 - 9일차 (0) | 2024.07.19 |
[5주차] 자바 고급 1일 - 4일 (0) | 2024.07.12 |