객체지향이라는 종교에 가까운 프로그래밍 방법론에 대해서는 이게 정답이냐 하는 논쟁거리는 뒤로 하고(https://samse.tistory.com/entry/Goodbye-OOP 참고) 일반적으로 어떤 기능 또는 자연계의 현상을 컴퓨터가 이해할 수 있도록 사례를 분석하고 일반화하고 그에 따라 컴퓨터와 통하는 언어로 표현하는 방법에 대해서 지금까지 내가 책을 통해서 배우고 실무를 통해서 실제로 사용해 왔던 나만의 사례를 기술해보고자 한다.
사용자의 스마트폰에 앱을 설치하여 위치정보를 관제센터에서 실시간으로 모니터링하고자 하는 고객이 있었다.
고객의 요구사항은 대체로 이러하다.
1. 위치정보를 주기적으로 수집하여 서버에 전송해야 한다.
2. 앱을 사용중이 아닐때에도 동작하여야 한다.
위와 같은 요구사항을 기반으로 제일먼저 진행해야 하는 작업은 요구사항의 구체화이다.
모바일단말에서 동작하므로 모바일환경에서 가능한 방법과 만일 불가한 경우 이를 보완할 방법등이 있는지를 검토하고 고객과 논의하여 최종 요구사항을 확정지어야 한다.
대게의 고객은 "이거 다 되어야 하는거 아니에요?", "요구사항에 있잖아요?"
이런 반응을 나타내는 경우가 왕왕 있다.
위 사례의 경우는 몇가지 짚고 넘어가야 하는 케이스가 있다.
1. 위치정보는 개인정보에 해당하므로 위치정보 서비스 사업자 등록을 해야 한다.
2. 위치정보를 사용하기 위해 사용자로부터 권한을 획득해야 하며 획득하지 못하면 해당 기능을 사용할수 없다.
3. 앱 사용중이 아닌 경우 백그라운드로 동작하려면 안드로이드의 경우 상태바에 알림박스가 떠야 한다.
이정도는 미리 짚어주면 좋겠다.
다음으로 해야 할 작업은 브레인스토밍이다. 일명 마인드맵이다(여러가지 마인드맵 앱이 있지만 적당한것을 찾지 못하였다. 결국 그냥 노트에 그리게 되었다.)
마인드맵은 머리속의 생각을 구체적으로 표현할 수 있고 이를 통해 분석해나가기 아주 좋은 툴이다.
위 요구사항을 기반으로 생각나는데로 계속 표현해 나간다.
위치권한 획득
위치정보데이터 모델 -> 서버 API기반으로 필요한 정보를 정의
위치추적 작업 스레드 -> 권한체크 후 시작 -> 권한 없으면 실패 콜백 -> 실패원이 화면에 표시
위치정보 저장 및 서버 전송 -> 바로 전송하지 않음. ->네트웍 상태에 따라 지연이 발생할 수 있음
저장 및 전송은 별개의 스레드로 동작해야 함.
저장은 DB로 -> SQLite? Realm?
서버 API -> 서버팀에 요청
…
글로 적었지만 위 내용은 마인드맵 규칙에 따라 계층적으로 생각의 흐름대로 표현해 나간다.
그리고 멀찍히 서서 그림을 본다.
그러다 보면 마치 매직아이처럼 몇가지 그룹으로 끼리 끼리 군집을 이룰 수 있는것을 발견하게 된다. 이 부분은 순전히 경험에 기인하는 면이 있지만 유사한것들 끼리 또는 구별이 되는것들을 나누어 보는것은 누구나 할 수 있을 것이다.
1. 백그라운드 위치추적 서비스
2. 위치정보 저장소
3. 위치정보 서버전송
4. 수집정보 데이터 모델
5. 권한 체크
6. 서버전송 네트웍 관리자
대충 느끼겠지만 위에 나열한것들은 클래스에 해당하게 된다.
1. TrackingService
2. TrackingDataStorage
3. TrackingSyncService
4. TrackingData
5. PermissionHelper
6. NetworkHelper
각 클래스별로 해야하는 작업은 다음과 같다.
1. TrackingService
- 위치권한확인
- 위치추적 시작, 중지
- 백그라운드에서 동작
- 추적된 정보를 저장소에 저장 및 서버 전송
2. TrackingDataStorage
- 위치정보를 DB에 set, get, remove
3. TrackingSyncService
- 저장소의 데이터를 읽어서 전송
- 전송된 데이터는 삭제
4. TrackingData
- 수집된 위치정보 데이터 클래스
- GPS위치정보(위도, 경도, 고도)와 사용자정보나 수집시간등 필요한 정보를 추가
5. PermissionHelper
- 위치권한 체크
- 위치권한 요청
6. NetworkHelper
- 저장소에서 데이터 읽어서 전송 후 삭제
절반정도 설계가 완료되었다.
댓글 없음:
댓글 쓰기