5. QUALCOMM BREW 플랫폼을 위한 설계

1. 5. QUALCOMM BREW 플랫폼을 위한 설계 • 5.1 설계 시작 • 설계는 소프트웨어 개발의 중요한 부분이다. • 설계의 중요성 이해 - 설계 결정 문서화는 팀 정보교환 강화와 응용 구현을 위한 공유 비전을 보증하여 응용의 품질 향상에 도움을 주는 증명된 방법이다. - 무선 응용은 QUALCOMM의 external certification agency와 무선이동통신사를 포함하는 다양한 삼자들에 의해 엄격하게 검토되고 시험될 것이다. • 설계 포착 • - 설계는 다음 정보를 포착해야 한다. • (1) 응용이 스크린 출력, 유효한 데이터 입력, 그리고 실효성 없는 데이터 입력을 포함하는 사용자와 • 어떻게 상호작용 할 것인가. 임베디드 모바일 프로그래밍

2. 5. QUALCOMM BREW 플랫폼을 위한 설계 • (2) 응용이 확장과 후위 망 자원을 포함하는 다른 컴포넌트와 어떻게 상호작용할 것인가. • (3) 응용은 영속 데이터를 어떻게 저장할 것인가. • (4) 모듈들 또는 데이터 저장을 위한 클래스들, 네트워크 I/O, 계산, 그리고 렌더링과 같은 응용의 기본 • 컴포넌트 • (5) 그러한 컴퓨넌트는 상호간에 어떻게 상호작용할 것인가. • 설계에서 기록해야 하는 결정을 만드는 것은 경험, 실험, 그리고 시험과 오류의 결합을 • 요구한다. • 설계의 핵심 구성요소는 응용의 사용자 인터페이스; 사용자가 응용으로부터 무엇을 기대 • 하는가, 사용자는 응용을 어떻게 사용할 것인가, 그리고 사용자에게 응용 자체는 어떻게 • 표현될 것이가 이다. 이것을 하기 위하여, 응용을 사용자 관점, 어려운 전망에서 보아야 • 한다. 임베디드 모바일 프로그래밍

3. 5. QUALCOMM BREW 플랫폼을 위한 설계 • 5.2 사용자 이해 • 모바일 패러다임 이해 • - 모바일 응용을 개발할 때에, 사용자가 움직이고 있다는 것을 항상 염두에 두어야 한다. • - 핸드셋을 사용하면서 이동하는 것은 응용의 겉모양과 응용의 사용 모두에 직접 영향을 • 준다. 분명히 입력은 간단해야 한다. 전화 키패드를 긴 입력용으로 사용하는 것은 지루할 • 뿐만 아니라 이동하면서 한 손가락으로 많은 키를 치는 것은 어렵다. 유사하게, 이동하면 • 서 복잡한 사용자 인터페이스를 정독 할 틈이 없기 때문에 응용 출력은 분명하고 간결해야 • 한다. • - 이러한 요인 때문에, 모바일 응용은 간단하고 사용하기 쉬워야 한다. 더욱이, 응용은 컬러 • 핸드셋의 모든 빛에서 볼 수 있도록 높은 대비 색을 사용하고, 흑백 디스플레이에 선명한 • 브랙앤화이트 텍스트를 사용하고, 그리고 최소 영숫자 입력을 요구하여 장치 자체에 적응 • 해야 한다. 임베디드 모바일 프로그래밍

4. 5. QUALCOMM BREW 플랫폼을 위한 설계 • 사용자가 텍스트 입력 보다 선택할 수 있는 쉬운 방법이 가능하면 숫자 단축아이콘을 • 갖는 메뉴를 사용하는 것이다. • 응용은 QUALCOMM에 의해 제시된 구체적인 인터페이스 기준을 만족해야 한다. 모든 • 응용은 그 응용을 유일하게 식별하는 기술적인 스프레쉬 스크린으로 시작해야 한다. • QUALCOMM은 특정 키에 대한 특정 인터페이스 요구사항을 가진다. 예를 들어, Clear 키 • 는 항상 이전 스크린로 갈 것이고, Select 키는 항상 어떤 엔트리를 선택, 응용에서 다음 • 스크린을 가져 올 것이다. • 사용자 인터페이스 포착 • 설계의 핵심 부분은 응용의 사용자 인터페이스이다. 사용자 인터페이스 설계하는 것은 • 인내, 조직, 그리고 고객 요구의 충분한 이해를 필요로 한다. • 응용의 사용자 인터페이스를 설계하고 포착을 시작하는 좋은 방법은 무슨 개체(actors)를 • 사용하는지를 그림으로 나타내는데 UML(Unified Modeling Language)을 사용하는 use • case analysis를 통하는 것이다. 임베디드 모바일 프로그래밍

5. 5. QUALCOMM BREW 플랫폼을 위한 설계 -Use Case Analysis (1) Define the Actors 시스템과 상호작용하는 사람 혹은 사물을 찾는다. 즉, 시스템을 사용하는 대상(Actor)을 찾는다. 보통, Actor는 시스템과 메시지를 주거나 받는다. 혹은, 정보를 교환한다. e.g.) 사용자, 관리자, 다른 시스템 (2) Develop Use Case List 시스템이 어떤 일을 하는데 사용되는지 알아낸다. 즉, 시스템의 쓰임새(Use Case)를 찾는다. 보통, Actor가 시스템을 사용하는 방식이 Use Case로 나타난다. e.g.) 로그인, 검색, 환경설정 • - Use Case 생성의 이점 • 각 use case를 적어두면, 각 use case의 공통 부분을 식별할 수 있고, 각 use case가 공유하는 사용자 • 인터페이스의 컴포넌트들을 구체화할 수 있다. • - 그러한 use cases로, 설계는 두 가지 별개의 작업: 사용자 인터페이스의 겉모양을 결정하는 것, 응용의 각 • 컴포넌트를 문서화하는 것으로 바꿀 수 있다. 임베디드 모바일 프로그래밍

6. 5. QUALCOMM BREW 플랫폼을 위한 설계 • - 사용자 인터페이스의 실제 겉모양을 결정하는 것은 상식, 경험, 시험과 오류, 그리고 사용 • 자 테스팅에 관한 문제이다. 최소한 잠재적인 사용자들과 다른 주주들에게 인터페이스 • 고안의 초안을 제시하는 것을 계획해야 한다. 가능하면, 핸드셋에서 또는 데스크탑에서 • 실행하는 데모 모형을 구축을 준비해야 한다. • 5.3 RocketMileage 응용 이해 • RocketMileage는 자동차 마일리지와 QUALCOMM BREW를 위한 서비스 추적 애플릿이다. NTSL(National Software Testing Labs)에 의해 인증되었으며, 그것은 Motorola T720과 다른 핸드셋을 위한 Verizon Wireless 네트워크에서 이용할 수 있다. • Use Cases를 RocketMileage 설계에 적용 - RocketMileage의 어떤 특징이 정말로 필요한지를 결정하기 위하여 RocketMileage의 초기설계 동안에 use cases를 생성하였다. 임베디드 모바일 프로그래밍

7. 5. QUALCOMM BREW 플랫폼을 위한 설계 - 첫번째 actor는 마일리지 추적과 자세한 자동차 서비스에 관심이 있는 전형적인 소비자이다. 다른 actor는 직업과 관련된 자동차 비용을 추적하기 위하여 응용을 사용하는 모바일 전문가이다. - RocketMileage를 위한 use cases Track Gas mileage Moterist Track Travel mileage Record service costs Remind For nest service Record Parking place Schedule Next service Provided Through Handset application 임베디드 모바일 프로그래밍

8. 5. QUALCOMM BREW 플랫폼을 위한 설계 - RocketMileage를 위해 선택된 usecases Track gas mileage Moterist Record service costs Record parking place Remind for next service Steering Alignment Oil Change Tire Rotation Tire Replacement Dealer Service 임베디드 모바일 프로그래밍

9. 5. QUALCOMM BREW 플랫폼을 위한 설계 - 다른 use cases 간의 공통 연산을 열거한 더 자세한 use case 분석 Application shows mileage at all times. 1. To update mileage, user: 1a. Choose Gas from menu. 1b. Enter the odometer reading. 1c. Enter the volume purchased. Id. Enter the cost. Track gas mileage Motorist <<uses>> Shared by all numeric entry “ATM-style” numeric entry. 1. To enter number: 1a. Enter most significant digit first. 1b. Continue entering digits. 1c. Decimal point positioned at the left of the last digit entered. Enter decimal value 임베디드 모바일 프로그래밍

10. 5. QUALCOMM BREW 플랫폼을 위한 설계 • RocketMileage 인터페이스 기술 • - 간단한 스크린 샷을 스케치하고 응용 기술 문서를 준비한다. • - 에뮬레이터와 샘플 응용을 사용하여 QUALCOMM BREW 응용에 위한 스크린 샷을 위한 모형을 • 만든다. • - RocketMileage의 초기 설계 단계의 스크린 구상 임베디드 모바일 프로그래밍

11. 5. QUALCOMM BREW 플랫폼을 위한 설계 - 응용을 정제하기 위하여, 응용 설명서를 작성할 수 있다. 이 설명서는 응용이 구현해야 하는 특징을 기술한 기능 명세와 유사하다. - 응용 설명서는 다음 정보를 포함해야 한다. (1) 응용 목적: 응용이 무엇을 실행하는지, 예상 사용자들은 누구인지, 사용자들이 응용을 어떻게 사용하는지를 제시한다. 최종 사용자 마켓팅 특징 명세서를 역시 제공해야 한다. (2) 목록 정보: 응용 이름, 응용의 테그 라인, 그리고 예상 응용 가격을 제시한다. (3) 시스템-단계 정보: 전화 상의 응용 제목을 제시하고, 응용의 아이콘, 회사명, 응용 저작권, 그리고 응용이 요구할 특권을 나타낸다. (4) 응용 사용자-단계 구조 다이어그램: 응용의 상태 기계 다이어그앰, 각 응용 스크린간의 흐름을 문서화를 보여준다. Use case 다이어그램을 구성하는 것으로 시작하고 스크린 원형을 사용하여 use case 다이어그램을 채운다. * Tag line: A slogan or phrase that visually conveys the most important product attribute or benefit that the advertiser wishes to convey. Generally, a theme to a campaign. • RockMileage를 컴포넌트로 분해 - RocketMileage의 use case를 검토함으로써, 분해의 다수의 분명한 부분이 있다. 임베디드 모바일 프로그래밍

12. 5. QUALCOMM BREW 플랫폼을 위한 설계 • (1) 주행기록계 입력 • (2) 금액 입력 • (3) 세부 정보 서비스 • 입력하는 대부분 레코드들은 가스 마일리지 레코드 또는 서비스 레코드이다. 그것들은 모두 5가지 • 공통 컴포넌트를 가진다. • (1) 이벤트 날짜와 시간 • (2) 이벤트가 일어나야 하는 다음 시간과 주행기록계 읽기 • (3) 이벤트 시점에 주행기록계 읽기 • (4) 이벤트의 금액 • (5) 가스 마일리지 레코드와 서비스 레코드 둘 다 부수적인 컴포넌트를 가진다. 가스 마일리지 레코드는 소비된 갤런 • 량을 저장해야 하고, 서비스 레코드들은 다음 서비스를 위해 읽은 주행기록계를 저장해야 한다. • 이 정보를 병합하여, 유형 식별자(가스 마일리지, 오일, 튠업, 타이어 교체, 또는 다른 서비스를 포함 • 하는 서비스 종류), 날짜와 시간, 초기 주행기록계 읽기, 다음 시간과 날짜 그리고 주행기록계 읽기, • 비용, 구입한 가스의 량 이거나 다음 서비스를 위해 주행기록계 읽기 인 두 번째(작은) 수로 구성되는 • 레코드를 갖는다. 임베디드 모바일 프로그래밍

13. 5. QUALCOMM BREW 플랫폼을 위한 설계 - 실제 자료구조 임베디드 모바일 프로그래밍