[AA Role] 프로젝트 정의단계 / 산정/ 인터페이스 설계
분석기술
- 유즈케이스는 중요한 분석 도구
- 프로토타이핑
- 프로젝트 영역 식별
- 비기능요구사항: 기능요구사항은 어플리케이션이 수행해야 하는 것 정의, 비기능요구사항은 기능적인 요구사항을 어플리케이션이
성취하는 방법에 대한 제약사항 명시
범위정의와 산정
- 업무측에 유즈케이스에 대한 동의를 얻는다
- 프로젝트 범위를 결정하는데 사용된 가정을 문서화한다
- 팀에서 가장 늦은 자원을 기준으로 산정한다
외부 어플리케이션 인터페이스 설계
- 인터페이스 방법 선택(ex: 직접 외부 어플리케이션 DB 활용, 웹 서비스, 메시징, EJB, REST 서비스 등)
(1) 외부 어플리케이션 DB 직접 읽기
: 구현이 가장 쉽고, 비용이 적게 듬
: 외부 어플리케이션 팀의 개입이 거의 필요 없음
: 항상 최신의 데이터 제공
: 외부 어플리케이션의 변화에 역으로 영향 받을 리스크 존재
: 오라클은 예외지만 대부분의 데이터베이스는 읽을 때 로크가 걸림(성능에 영향 줄 수 있음)
(2) 웹 서비스
: 웹 서비스는 다른 인터페이스 메서드에 비교하여 개발하고 유지, 보수하기 어렵다
: 웹 서비스는 대량의 데이터를 가져오는 데 최적화되어 있지 않다
: 필요할 때 웹 서비스를 사용하지 못할 수 도 있다. 대처 전략 필요
: 플랫폼 중립적
: 웹 서비스는 자유롭게 리팩토링 및 재설계 가능(해당 어플리케이션에는 아무런 영향을 미치지 않음)
(3) RESTful 서비스
: RESTful 웹 서비스는 구조화된 URL을 사용하여 정보 요청 명세를 커뮤니케이션 한다.
: 플랫폼 중립적
: 웹 서비스보다 소비하기 쉽다
: 필요할 때 사용할 수 없을 수도 있다. 대처 전략 필요.
: 웹 서비스의 WSDL 자체가 서비스를 설명하는 문서로 제공되는 반면에 RESTful 서비스는 이러한 내장된 문서화 전략을 제공하지 않음
(4) 메시징 서비스 활용
: 비동기적인 커뮤니케이션 방법. 요청이 전달되지만 응답이 즉시 이루어지지 않을 수 있음
: JMS
: 전달을 보장한다
: 플랫폼 중립적
: Java EE 컨테이너 지원을 받음
: 내장된 문서화 전략을 제공하지 않음
- 데이터 구조
(1) 외부 어플리케이션에 전달되는 모든 데이터 문서화
- 컨텐츠 교환 트리거 이벤트
- 에러 처리 프로시저와 책임
(1) 모든 외부 어플리케이션 인터페이스는 에러 알림 프로시저를 가져야 한다
(2) 자동으로 에러를 알려주는 방식을 사용
(3) 에러를 로깅할 때 상세한 설명을 포함시키는 것이 좋다
- AA는 인터페이스 설계 논의를 중재해야 한다
(1) 외부 어플리케이션에 전송하고 요청하는 모든 사항을 기록한다
(2) 에러 처리 로직 적절하게 테스트
[출처] JAVA EE 아키텍트 핸드북 2판