태그 : 프로젝트

파일 업데이트 사용에 대한 고민.

지난 번 DB 이용 방법에 대해서 약간의 고민을 했던 것과 비슷하게 파일 업데이트에 대한 것을 잠시 고민하고자 짧은 글이지만 핵심적인 이야기를 하고자 합니다.

파일을 업데이트 하는 방식 중

첫번째로 서버쪽 파일과 클라이언트 쪽 파일을 비교해서 최종 수정 시간이 언제인가를 확인 한 뒤에 서버 쪽이 더 최신의 수정 시간을 갖고 있을 경우 업데이트를 하는 방식.

두번째로 파일의 크기를 비교해서 서버쪽과 클라이언트 쪽의 파일 크기가 다르다면 업데이트 하는 방식.

마지막으로 클라이언트의 버전 정보를 서버쪽에 전송 받아서 버전이 구 버전인지 확인을 한 뒤 파일을 업데이트 하는 방식.

이렇게 3가지 방식을 두고 고민을 하고 있습니다.


일반적으로 게임에서 많이 볼 수 있는 파일 업데이트 방식은 두번쨰 방식을 주로 이용하는 것으로 알고 있는데 과연 두번째 방법이 좋은 것인지에 대해서는 확실히 알수는 없다고 생각 되는 부분이 존재합니다.

만약 클라이언트 쪽에서 바이너리 편집기를 이용해서 파일의 내용을 수정한다면 파일의 사이즈는 변화가 없기 때문에 서버 입장에서는 전혀 문제가 없다고 판정을 내린다는 점과 이 문제를 해결하고자 클라이언트의 파일들을 서버가 일일이 내용까지 확인한다는 것은 서버 입장으로는 무리수를 두는 시스템이라고 생각되는 부분입니다.

그리고 첫번째 방법은 단순히 파일의 최신 업데이트 날짜 비교가 아니여도 서버쪽에 파일 수정 시각과 클라이언트 쪽에 파일 수정 시각이 다를 경우에 업데이트를 한다고 약간 바꿔서 생각 한다면 편리할 것이라고 생각 되나.. 파일의 수정 시각은 클라이언트 쪽에서 위조가 가능 하다는 것으로 알고 있는 부분입니다.

마지막으로는 클라이언트 쪽에 버전 정보 역시 첫번째 방법과는 크게 다르지는 않을 것으로 보인다는 점.. 쉽게 가는 프로그래밍 이라면 물론 3번이 가장 속 편한 해결책이라 보입니다.

3 가지 방법 그 어느것도 장단점은 존재 한다고 봅니다.
과연 어떤 것을 이용하는 것이 좋을까요?
(이미 마음은 기울어졌지만...-_-;;)

아 그리고 3가지 방법 모두 다 객체스트림을 이용한 방법으로 구현할 계획입니다. ^^;

by 만성피로 | 2008/11/25 00:37 | 정리할 자료들 | 트랙백 | 덧글(2)

DB 사용에 대한 고민.

현재 프로젝트 진행 정도는 DB와 네트워크 부분 수정 문제로 프로젝트가 잠시 중단 된 시점이다.

DB를 사용 하는 방법에는 2가지를 고려 중이다.

1. 클라이언트 쪽에서 DB 서버에 직접 접근을 한다.
2. 네트워크를 통해서 서버에 쿼리메시지를 보내고 서버는 받은 쿼리메시지를 이용해서 DB에 접근하는 방법이다.

그러나 DB에 접근 할 수 있는 계정을 호스트 마다 정할 수 있다는 점에서 약간 주춤 했던 것이 한가지 있다.
계정명@호스트명 이런식으로 정한다면 모든 호스트에 대한 설정이 문제가 됐었다.

이점에 대해서 검색을 해본 결과..

계정명@%

이렇게 하면 그 어떤 호스트에서도 접근이 가능하다. 그럼 1번의 방법을 이용한다면 클라이언트가 DB에 직접 접근이 가능하다.
이렇게 한다면 java.net 패키지 없이 서버 DB에 접근이 가능하다.

그러나 1번을 이용하지는 않으려고 생각중이다. 여러 클라이언트에서 DB에 접근을 시도 한다고 가정 했을 때 문제가 될 소지가 있다고 보기 때문이다.

2번의 방법을 이용한다면 서버쪽에 DB 쿼리 메시지를 처리해줄 프로그래밍만 해주면
클라이언트 <-네트워크이용-> 서버  <-DB이용-> MySQL
위와 같은 구조로 한다면 프로젝트의 질적인 부분에서도 더 좋다고 생각된다.

끝으로 현재 까지 진행 상황은
로그인, 계정 생성, 계정 삭제, 암호변경, 계정찾기 까지 모두 완료 된 상태이다.

by 만성피로 | 2008/11/16 20:08 | 정리할 자료들 | 트랙백 | 덧글(2)

로그인 인터페이스.

지난번에 구성한 클래스 다이어그램을 토대로 현재 코딩 중이다.

가장 먼저 로그인 인터페이스를 1차 완성을 했다.

뭔가 이쁘지는 않지만 나름대로 완성을 했으니 2차 3차 수정을 하면 상당히 이뻐지지 않을까 하는 생각을 한다.

개인적으로는 단순 노가다 작업 느낌이라서 이 부분은 정말 지루하다 -_-;













이 창에서 계정 생성과 찾기 버튼을 누를 경우 아래의 챙들이 뜨게 된다.







































이제 DB와 연동하는 부분만 코딩해주면 대부분의 기본 작업은 끝이 난다.

그러나 DB와 연동이 그리 쉽지는 않을지도 모르겠다.

현재 구성한 클래스 다이어그램이 다시 작업하면서 일부 변경된 부분도 있고 생각 했던 것 외에 문제가 하나 둘씩 나타나기 시작하기 때문이다.





by 만성피로 | 2008/10/05 16:09 | 정리할 자료들 | 트랙백 | 덧글(1)

로그인 시스템.

이번 프로젝트에서 구현해야 할 클래스 중 계정 생성, 계정 찾기, 로그인 시스템을 설계에 대한 이야기를 시작하겠다.

지난 글에서 구체적인 클래스에 대한 설계와 클래스 다이어그램을 올리겠다고 했었다.

열심히 머리로 굴려본 결과 대충 설계도가 나오긴 했는데 잘 구성 했는지에 대한 여부는 짜보지 않아서 모르겠다.

일단 이야기 해보도록 하자.
가장 먼저 DB를 활용한다는 점이 특징이다.

프로그램이 동작 되는 동안 해당 유저가 꼭 가지고 있어야 할 클래스가 필요하다고 판단됐다.
바로 Data 클래스이다. Data 클래스는 DB에 User 테이블의 6개의 필드와 같은 형태로 구성돼야 한다.

DB에 있는 User 테이블에는
아이디/비밀번호/생년월일/쉬운난이도점수/보통난이도점수/어려운난이도점수
이렇게 6개의 필드를 갖는다.

그러므로 Data 클래스 또한 이와 같이 구성한다.

Data

-String id

-String passwd

-String birth

-int score_easy

-int score_normal

-int score_hard

+void:setID(String id)

+void:setPasswd(String passwd)

+void:setBirth(String birth)

+void:setEScore(int score_easy)

+void:setNScore(int score_normal)

+void:setHScore(int score_hard)

+String:setID()

+String:setPasswd()

+String:setBirth()

+int:setEScore()

+int:setNScore()

+int:setHScore()

왜? 이렇게 해야 할까? 본인 판단은 다음과 같다. 데이터가 필요할 때마다 계속 DB를 활용해서 불러오고 저장하고 업데이트 한다는 것이 매우 불편하다고 생각 되기 때문에 한번 가져온 DB 데이터들을 프로그램이 동작 하는 동안 기억해 줘야 할 공간이 필요하다고 판단되기 때문이다. 그 것을 Data 클래스가 대신해 줄 것이다.

그리고 Data 클래스를 통해서 DB에 데이터를 삽입,변경,삭제를 할 클래스에게 객체를 전달하고 DB를 객체로 전달 받아야 하기 때문에 중계 역할을 위해서 필수적으로 필요한 것이다.

그럼 바로 DB 클래스 구성에 대해 이야기 하자.

DB<interface>

+void:dbInput(String query)

UserDB

+void:dbInput(String query)

+Data:dbOutput(String query)

## DB에 내용을 넣을 때와 DB에 내용을 검색하는 것에는 차이가 있다. 검색의 경우는 명령어 입력 후에 결과가 출력된다. 자바에서 검색 기능을 이용하려면 반환형이 필요하다.

반대로 내용을 추가, 수정, 삭제의 경우에는 반환형이 없다.

+void:dbInput(String query)

DB에 쿼리를 덜질 내용을 인수로 받아서 질의한다. 추가, 삭제, 수정의 경우 이 메소드를 이용할 것이다.

+Data:dbOutput(String query)

검색의 결과를 반환해야 한다.


UserDB 클래스는 DB 인터페이스를 구현 하도록 한다. UserDB는 DB에 던질 쿼리를 인수로 받아서 DB에 쿼리를 던지고 또한 반환값이 있는 질의를 던질 때는 반환받은 값을 Data형 객체로 반환하게 했다. 이 부분에서 조금의 오류가 있을 수도 있다고 판단이 된다. 반환형을 오브젝트 혹은 벡터형으로 설정을 한다면 인터페이스 자체에서 모두 추상 메소드를 갖고 각각 DB 활용이 필요한 클래스에서 구현하는 형태를 취하는 쪽이 어떨까 하는 생각이 들기 떄문이다. 일단은 이부분에 대해서는 조금 더 생각을 해야 할 것 같다.
그럼 다음으로 넘어가자.

로그인 클래스.

Login

-Data data

-JButton btn_login

-JButton btn_search

-JButton btn_creat

-JTextField tf_login

-JTextField tf_passwd

+Login(String title)

+void:search()

+void:creatID()

+Data:successLogin()

## 로그인을 성공하면 DB에서 데이터를 가져와 리턴 한다.

## 검색과 생성 버튼을 누르면 각각의 클래스로 연결 이벤트

## 로그인 다이얼로그에서 시스템 메뉴에 닫기를 누르면 프로그램 종료

## 스윙에 경우에는 닫기 버튼을 누르면 이벤트 설정을 하지 않아도 폼이 없어진다.

+Login(String title)

생성자를 통해서 인터페이스를 구성한다.(키워드 interface와는 관련없다.)

+void:search()

Search 다이얼로그를 불러온다.

+void:creatID()

Create 다이얼로그를 불러온다.

+Data:successLogin()

로그인을 성공하면 Data형 객체를 반환한다.


로그인 클래스는 질의문장을 완성해서 UserDB클래스에게 전달해 로그인 성공 여부를 확인하게 된다.
지금 이 부분에서 빠진 부분이 한가지 있다면 로그인 성공 여부를 어떻게 확인 할 것인가이다. 이 부분은 추가적으로 boolean형을 반환하는 메소드를 적당한 클래스에 넣어줘야 할 것이라 생각 된다.

그럼 다음으로 ~

검색 클래스

Search

-JLabel id_label

-JLabel passwd_label

-JTextField id_tf

-Choice yy

-Choice mm

-Choice dd

-JButton btn_id

-JButton btn_passwd

-JButton btn_search

+Search(String title)

+String:searchID(String id)

+String:searchPasswd(String id, String yy, String mm, String dd)

+Data:getSearch(String query)

+String:getID(Data data)

+String:getPasswd(Data data)

## 다이얼로그 하나에 ID 찾기와 패스워드 찾기가 구성된 형태 카드레이아웃으로 구성해야 할 것이다.

## 메소드에서 아이디 찾기와 비밀번호 찾기 명령어를 완성하고 메소드를 전달 후 결과물은 Data형 객체로 받는다.

+Search(String title)

생성자를 통해서 인터페이스를 구성한다.(키워드 interface와는 관련없다.)

+String:getID(Data data)

Data형 객체를 인수로 받아 id필드를 반환한다.

+String:getPasswd(Data data)

Data형 객체를 인수로 받아 passwd필드를 반환한다.

+String:searchID(String yy,String mm,String dd)

id를 검색하기 위해 DB에 쿼리를 던질 생년월일을 인수로 받아 쿼리를 완성하고 반환한다.

+String:searchPasswd(String id, String yy, String mm, String dd)

password를 검색하기 위해 DB에 쿼리를 던질 아이디와 생년월일을 인수로 받아 쿼리를 완성하고 반환한다.

+Data:getSearch(String query)

완성된 쿼리를 인수로 받아 DBconnect형 객체에 Data형 객체를 반환형으로 갖는 메소드에 쿼리를 인수로 전달 하고 Data형 객체를 반환한다.

이 부분에서도 일부 오류가 발견된다.(미리 짜둔거라 다시 보니 설계도가 엉망이네 -_-..)
DB에 질문을 던지고 그 결과를 가져다 주는 메소드는 이미 UserDB에 존재하고 이 클래스에서 해야 할 일인지 의문이다. 본격적으로 구현 할 때는 이런 점을 개선하도록 하자.

다음!!

계정생성 클래스

Create

+JTextField id_tf

+JTextField passwd_tf

+JTextField passwd2_tf

+Choice yy

+Choice mm

+Choice dd

+JButton btn_create

+Create(String title)

+boolean:qualification(String str)

+void:createQuery(String id, String passwd, String yy, String mm, String dd)

## 사용자 계정을 생성한다.

+Create(String title)

생성자를 통해서 인터페이스를 구성한다.(키워드 interface와는 관련없다.)

+boolean:qualification(String str)

계정을 생성 할 때 id 최소 문자열, 비밀번호와 비밀번호확인 부분에 대한 제한조건이 성립하는 여부를 반환한다.

+String:createQuery(String id, String passwd, String yy, String mm, String dd)

DB에 들어가야 할 각 필드는

id/passwd/(yy+mm+dd)/score_easy/score_normal/score_hard

이다. 인수로 받지 않은 부분은 0으로 직접 설정한다.

완선된 라인을 이용해 UserDB형 객체를 통해 반환형이 없는 메소드를 실행한다.

여기에서는 계정을 생성하는 것이다. 같은 아이디가 존재하면 계정 생성을 막아야 한다는 것이 생각나서 설계 당시에는 boolean형으로 그 여부를 판단하도록 했으나..DB 자체에서 그 것을 걸러주는 기능이 있지 않나 하는 생각이 든다. 분명 있을것이다. 오라클을 배울 때 그 부분에 대해서 이야기 들은 기억이 있었던 것 같기 때문이다.

그리고 마지막으로 클래스 다이어그램을 그리려다 실패한 것이다.





















클래스 다이어그램을 그리는데 실패한 이유는 아직은 조금 어렵다 -_-; 혼자서 보는 책이 있는데 클래스간 집약관계, 사용, 생성, 전달의 관계를 나타내는 설명은 그림과 더불어 간단히 소개가 돼 있으나 무슨 책이 정말 간단하게 나와 있다 -_-..

그리다가 보니 저번학기 처럼 흐름도 비슷하게 그려진 것 같아서 기분은 별로 좋지 못했다...-ㅛ-!!

아무튼 이런 형식으로 설계를 하면서 진행을 하는 것이 확실히 객체지향적인 사고를 하는데는 도움이 된다. 그리고 재대로 써먹지는 못하겠지만 지금 따로 공부하고 있는 디자인 패턴이 객체지향프로그래밍에 도움이 되고 있다.

by 만성피로 | 2008/10/04 23:01 | 정리할 자료들 | 트랙백 | 덧글(1)

구체적인 프로젝트 구성. -1-

저번 글에서 잠깐 등장 했던 가계부 프로그램은 보조적으로 활용하려는 기능이었다.

지난 프로젝트 때 제작 했던 프로그램이었기에 좀 써먹고 싶었던 욕심이었다.

그러나 이번 프로젝트에는 퀴즈 프로그램을 제작하는 것이 주 목적이었다.

그래서 기획서 제출 기한도 다가오고 해서 노트에 낙서질 했던 것을 일부 정리해서 소개 하겠다.

User 클래스
1. 사용자를 추가 할 수 있어야 한다.(ID와 PASSWORD)
    -> 추가 된 사용자는 DB에 저장 된다.
2. 로그인을 할 수 있어야 한다.(ID와 PASSWORD)
    -> DB로부터 정보를 가져와 일치하는지 확인한다.


Quiz 클래스
1. 퀴즈 데이터는 DB에서 가져온다.(난이도, 문제, 정답, 해설)
2. 선택된 난이도 별로 문제를 출제 한다.
3. 게임의 결과를 DB에 저장한다.(ID, 난이도, 점수)

RankBoard 클래스
1. DB에 저장된 랭크는 난이도 별로 10등 까지 표시해 준다.
2. 난이도 별 초기화, 전체 초기화가 가능해야 한다. 랭크보드 초기화..


Update 클래스
1. 사용자가 추가한 문제를 네트워크로 업데이트가 가능하다.
    ->P2P방식업데이트

Main 클래스
1. 프로그램을 실행 하면 메뉴표시줄은 비활성화 상태
    -> 유일하게 로그인 메뉴만 활성화
2. 로그인을 하면 모든 메뉴가 활성화
3. 원하는 메뉴 선택 시 이벤트 리스너를 통해서 해당 기능들이 동작하는 방식.


많은 부분이 간단하게 적혀 있다. 요즘 패턴을 잠시 공부 중이라 패턴도와 비슷한 구조로 즉! 객체지향적인 프로그래밍을 위해서 클래스 다이어그램을 그려보고 있는 중이다.

클래스 다이어그램이 상당히 중요한 이유는 하나다. 본인 프로그램도 그랬지만 파트너의 프로그램 소스 역시 동작하는 프로그램으로써는 잘 완성 됐지만 너무 복잡한 소스와 기능 위주의 클래스라는 점이 재이용이 어려울 듯 하기 때문이다.

그럼 다음 글은 클래스다이어그램이 될 것이다.
(잘만 된다면 시퀀스 다이어그램도 완성???)

by 만성피로 | 2008/10/02 01:46 | 정리할 자료들 | 트랙백 | 덧글(2)

◀ 이전 페이지다음 페이지 ▶