국내 대학생을 위한 통합시간표 제공서비스

연계인터페이스 설계 및 연계시험결과서

2022.5.10

가천대학교 컴퓨터공학과

민정필(201735951)

오제민(201735991)

**
**

목 차

1. 서비스 분석

1.1 통합 시간표 서비스의 구성

1.2 연계 요구조건

1.3 A대학(송신시스템)의 데이터 구성(ERD, 테이블명세서)

1.4 B대학(송신시스템)의 데이터 구성(ERD, 테이블명세서)

1.5 C대학(송신시스템)의 데이터 구성(ERD, 테이블명세서)

1.6 가천정보(수신시스템)의 데이터 구성(ERD, 테이블명세서)

1.7 연계요구사항 분석

2. 연계 데이터 구성하기

2.1 연계항목 추출

2.2 연계코드 매핑테이블

2.3 표준화할 코드테이블 정의

2.4 연계인터페이스의 정의 및 명세

3. 연계 메카니즘 구성

3.1 연계 메카니즘 정의

3.2 인터페이스 파일(테이블)정의

3.3 전송API 정의(REST API)

3.4 오류코드와 로그정보의 정의

3.5 연계 데이터 보안적용

4. 내외부 연계모듈 구현

4.1 개발환경의 설정

4.2 운영환경의 설정

4.3 무결성 침해의 대응방안 설계

4.4 연계 주요소스코드 및 설명

4.5 송수신 현황 모니터링화면 캡쳐

5. 연계 테스트

5.1 테스트개요

5.2 단위 테스트

5.3 연계 테스트

5.4 테스트 환경구축

5.5 연계테스트 수행결과 검증

서비스 분석

통합 시간표 서비스의 구성

㈜가천정보는 대학생들에게 시간표를 무료로 제공하는 서비스를 개발하기로 하였으며, 현재 3개대학(A, B, C)과 계약을 맺어, 각 대학의 학사DB의 일부내용을 제공하기로 합의하였다. 향후에 추가로 통합될 대학들은 이 문서(인터페이스 설계서)에 기술된 연계방식으로 그대로 따를 경우에 연계과정에서의 비용과 노력을 줄일 수 있다.

그러나 연계과정에서 개인정보와 대학행정정보등 보안에 민감한 정보는 제공할 수 없으며, 오로지 시간표생성에만 필요한 최소정보를 제공하도록 설계한다. 이와 같은 시간표 제공서비스를 개발하려면, 3개대학의 데이터구조와 시스템구성을 먼저 살펴보자

[그림 1-1] 시스템 구성도

연계 요구조건

요구사항1) 각 대학의 재학생들에게만 (우측그림처럼) 시간표 UI를 제공한다.

요구사항2) 모든 사용자(학생)가 자신의 시간표를 보려면 반드시 로그인하여야 하며, 아이디와 암호로 인증한다.

요구사항3) 로그인이 성공하면, 대학명,학과명,학생명이 자동으로 출력되도록 한다.

[그림 1-2] 통합시간표(학생view)

요구사항4) 그림1-2 통합시간표 UI에서는 해당요일/교시에 해당과목명, 담당교수명, 강의실호수가 표기되어야 한다.

요구사항5) 수강신청기간이 종료된 직후와 정정기간이 종료된후에만 중계시스템 모니터링운영자가 연계모니터링서버를 수행하면 연계가 실행되도록 한다.

요구사항6) 연계가 실행될때는 반드시 연계관리정보가 DB에 저장되고 관리되어져야 한다.

요구사항7) 각 대학 학사서버에서는 개인정보(예, 이름, 주민번호, 학번, 사번, 암호)가 암호화되어 있으며, ㈜가천정보의 DB에서도 해당 개인정보들은 암호화하여야 한다.

요구사항8) 모든 암호화 알고리즘은 AES192 로 통일하여 사용한다.

요구사항9) 한 개의 대학이라도 코드화가 되어 있는 항목은 수신시스템에서도 코드화가 되어야 한다.

요구사항10) 시간표서비스를 하는데 있어서 꼭 필요한 정보만 연계하고 그 이외의 정보는 보안상 연계하지 않는다.

요구사항11) 설문지로 하는 설문조사는 없다.

요구사항12) 각 대학에서는 각 대학DB의 어떤 항목도 절대로 변경하거나 삭제하지 않는다.

요구사항13) 연계파일형식은 JSON 포맷으로 하며, REST API방식으로 연계한다

요구사항14) 제시한 3개 대학(A, B, C)의 데이터베이스 규격과 내용을 기준으로 한다.

요구사항15) A대학에서는 데이터베이스 테이블로 로그정보와 오류정보를 기록하고 있으며, B대학과 C대학에서는 파일형태로 로그정보와 오류정보를 기록하도록 하여야 한다.

요구사항16) 중계시스템에서의 연계모니터링 서버는 로그정보와 오류정보를 각각 파일로 기록한다

요구사항17) A대학, B대학, C대학의 데이터정보는 각각 그림1-3, 그림1-4, 그림1-5에 나와 있다.

요구사항18) 본 양식스타일을 절대로 깨트리면 안되며, 그외에 필요한 경우 요구사항을 각자 정의할 수 있다.

[그림 1-3] A대학 DB정보

[그림 1-4] B대학 DB정보

[그림 1-5] C대학 DB정보

A대학(송신시스템)의 데이터 구성(ERD, 테이블명세서)

ERD

[그림 2-1] A대학 운영DB의 ERD

테이블명세서 및 코드정의

<A대학 테이블 명세서>

※ Student 테이블의 social_security_num 같은 경우는 crypto모듈을 사용해 hex형태로 저장하기에 Char(40)으로 늘렸다.

B대학(송신시스템)의 데이터 구성(ERD, 테이블명세서)

ERD

[그림 2-2] B대학 운영DB의 ERD

테이블명세서 및 코드정의

<B대학 테이블 명세서>

※ Student 테이블의 SS_number같은 경우는 crypto모듈을 사용해 hex형태로 저장하기에 Char(40)으로 늘렸다.

C대학(송신시스템)의 데이터 구성(ERD, 테이블명세서)

ERD

[그림 2-2] C대학 운영DB의 ERD

테이블명세서 및 코드정의

※ Student 테이블의 SS_number같은 경우는 crypto모듈을 사용해 hex형태로 저장하기에 Char(40)으로 늘렸다.

가천정보(수신시스템)의 데이터 구성(ERD, 테이블명세서)

[그림 2-4] 가천정보 운영DB의 ERD

테이블명세서 및 코드정의

연계요구사항 분석

연계 데이터 구성하기

연계항목 추출

연계코드 매핑테이블

<연계 매핑 코드 필요 데이터>

<과목코드 매핑 테이블>

<강의실 코드 매핑 테이블>

<학과코드 매핑 테이블>

표준화할 코드테이블 정의

<과목코드 매핑 테이블>

<강의실 코드 매핑 테이블>

<학과코드 매핑 테이블>

연계인터페이스의 정의 및 명세

<연계 인터페이스 정의서>

<연계 인터페이스 명세서>

연계 메카니즘 구성

연계 메카니즘 정의

[그림 3-1] 연계 메커니즘 구성도

.

인터페이스 파일(테이블)정의

<인터페이스 파일 정의(JSON)>

<파일로 로그 기록 시 결정 사항>

파일로그 기록시 위와 같은 기준으로 작성한다.

<송신 시스템 인터페이스 테이블(파일) 단위 로그(Log) 테이블(파일) 레이아웃(Layout)>

파일 로그에는 다음과 같은 표의 양식으로 작성한다.

전송API 정의(REST API)

<각 대학 API Docs>

<가천정보 API Docs>

오류코드와 로그정보의 정의

<에러 코드 기준 테이블>

연계 데이터 보안적용

Npm을 통해 crypto모듈의 128bit 암호화 알고리즘 사용.

AES192 암호화 알고리즘의 키 생을 위해 developcrypto Seed값과 salt 해싱 값과 IV 랜덤 Seed값을 통해 키를 생성한 후 128bit 블록단위로 암호화를 실행한다. 키 값은 .env에 MYPASSWD값으로 저장하여 관리한다.

이후 암호화된 정보는 데이터 베이스에 저장된다.

가천정보 중계 시스템에서 개인정보 요청 시 각 대학에서는 AES192 암호화 된 개인정보를 .env파일과

함께 보내준다.

내외부 연계모듈 구현

개발환경의 설정

Server : Node.js – Express (Web Framework)

DB : Server – Mysql

IDE : VScode-Server (SSH remote)

운영환경의 설정

<winston.js>
Winston 모듈을 이용한 로그 기록/관리

Winston 모듈을 이용하여 위에서 정의한 로그 파일을 정의 한대로 info 파일과 error 파일에 .log 확장자 형태의 로그파일을 저장한다.

Error 로 지정된 로그인 경우 info 파일과 error 파일에 둘다 저장되며 error파일에서 따로 볼 수 있다.

로그파일은 30일 동안 저장이 되며 그 이후에는 새로 저장된다.

<로그 파일 디렉토리>

<로그파일 예시>

무결성 침해의 대응방안 설계

<crypto.js 파일>

Crypto 에서 사용하는 KEY 값의 경우 .env파일에 따로 저장하여 관리한다.

<회원가입 시 사용된 crypto 모듈 예시>

<로그인 시 사용된 crypto 모듈 예시>

연계 주요소스코드 및 설명

<가천정보 서버 코드>

가천정보 서버의 주요 기능으로 회원가입, 로그인, 암호변경, 로그출력이 있다.

각 대학별 주요 기능으로는 연계데이터 전송하는 Send와 가천정보에서 회원가입 시 대학인증을 하는 identify, 그리고 대학내 코드 매핑하는 Mapping이 있다.

1. 회원가입

<회원가입 화면>

<입력란 미입력시>

입력란 미입력시 Javascript로 데이터 전송이 불가하게 하였으며 특정란을 입력하라고 경고문을 띄운뒤 해당 칸이 focus된다.

<비밀번호 체크란 오류 시>

또한 비밀번호가 일치하지 않으면 데이터 전송이 불가하며 비밀번호 체크란에 focus된다.

<회원가입 과정>

사용자가 입력한 아이디의 @를 split하여 각 대학에 identify를 요청한다. 요청받은 대학은 학생여부를 판단 후 학생의 기본 정보(학번, 이름, 학과)를 가천정보 서버로 보내준다.

<대학의 identify 코드>

대학으로부터 받은 학생의 기본정보(학번, 이름, 학과)를 데이터베이스에 저장 후 회원가입을 완료한다.

1. 로그인

<로그인 화면>

사용자가 로그인 시 세션에 아이디 정보와 학생의 학번을 세션에 저장한다.

또한 사용자의 대학에 시간표 데이터를 연계하여 메인 화면에 띄운다.

1. 메인

<메인화면>

로그인에 성공하면 메인화면에는 사용자 이름과 대학, 학과 정보가 표시되고, 해당 사용자의 시간표를 보여준다. 시간표는 Javascript로 randomColor라는 함수를 만들어 시각적인 변화를 볼 수 있게 작성하였다.

<특정 관리자 사용자 로그인>

특정 관리자 회원이 로그인 시 세션 구분을 통해 화면 상단의 navbar에 기존사용자에는 없던 연계 데이터 모니터링 메뉴가 생성되며 연계 데이터 모니터링, 대학 데이터 연동 기능을 사용할 수 있다.

1. 대학 데이터 연동

<대학 데이터 연동 페이지>

각 대학 데이터 연동 버튼을 누르게 되면 각 대학의 변경된 시간표 정보를 받아와서 저장한다.

시간표의 경우 가천정보 데이터베이스에 데이터 검증을 진행하는데 기존의 시간표 데이터와 연계데이터와 비교하여 데이터를 업데이트 하거나 그대로 두어서 리소스 값을 줄인다.

<시간표 데이터 관리 모듈 scheduleValidation>

<시간표 데이터 검증 함수사용 및 세션 예시>

모듈 사용시 해당 함수의 콜백이 늦어지기 때문에 함수를 Promise 패턴을 적용하여 비동기를 유지하였고 함수 사용에 있어 async 과 await를 사용해서 해당 코드가 비동기를 유지하면서 동기적인 모습의 코드스타일을 적용할 수 있게 하였다.

1. 로그아웃

로그아웃은 navbar의 로그아웃 버튼을 통해서 Session Destroy 기능을 통해 손쉽게 로그아웃 할 수 있게 만들었다.

<로그아웃 코드>

송수신 현황 모니터링화면 캡쳐

<연계 데이터 모니터링 화면>

특정 관리자로 로그인한 경우 연계 데이터 모니터링 기능을 사용할 수 있다.

연계 데이터 모니터링 시스템은 winston 모듈로 시스템의 로그를 .log 형태의 파일로 저장한 파일을 읽어서 페이지에 보여준다.

날짜 및 시간, 상태, I/F명, 처리코드, 처리건수, 성공건수, 실패건수를 보여주며 JQuery를 이용하여 시간, 상태, I/F명, 처리코드를 검색할 수 있게 하였다.

또한 Log List를 누르면 현재 존재하는 로그파일을 찾아볼 수 있으며, 해당 로그를 선택하면 해당 내용이 화면에 출력된다.

<처리코드 검색한 결과>

<Log 목록 버튼>

<연계 데이터 송수신 현황 에러 모니터링 페이지>

연계 데이터 에러 모니터링 페이지 또한 위의 모니터링 페이지와 기능은 같으며, 연계 데이터 에러 모니터링 페이지는 날짜 및 시간, 상태, I/F명, 처리코드, 에러코드, 에러 위치를 볼 수 있다.

연계 테스트

테스트개요

<단계별 테스트의 테스트 구간 및 범위>

단위 테스트 구간으로 A대학, B대학, C대학, 가천정보를 각 서버 별 연계 데이터 로드 및 데이터 송수신 테스트를 진행한다.

1. A대학 단위 테스트 범위

• Identify (A대학 학생 판별) [연계 테스트]
• Send aunivdata (A대학 학생 정보 송신) [연계 테스트]
• Mapping (송신 데이터 매핑)

1. B대학 단위 테스트 범위

• Identify (B대학 학생 판별) [연계 테스트]
• Send bunivdata (B대학 학생 정보 송신) [연계 테스트]
• Mapping (송신 데이터 매핑)

1. C대학 단위 테스트 범위

• Identify (C대학 학생 판별) [연계 테스트]
• Send cunivdata (C대학 학생 정보 송신) [연계 테스트]
• Mapping (송신 데이터 매핑)

1. 가천정보 단위 테스트 범위

• Signin (로그인) [연계 테스트]
• Signup (회원가입) [연계 테스트]
• Pw_change (암호 변경)
• Crypto (암호화 / 복호화)
• Logsearch (로그 기록 관리)
• Schedule (학생 시간표 관리) [연계 테스트]

단위 테스트

<A대학 단위테스트>

A대학에 정의된 코드를 바탕으로 중계서버에서 사용할 코드를 매핑한다.

사용된 Mapping으로 MapDepartment_code, MapSubject_code, MapClassroom, MapSubject_Professor, MapProfessor_code로 5가지를 사용하였다.

테스트 결과 = 합격

<B대학 단위테스트>

B대학에 정의된 코드를 바탕으로 중계서버에서 사용할 코드를 매핑한다.

사용된 Mapping으로 MapSubject_code 1개를 사용하였다.

테스트 결과 = 합격

<C대학 단위테스트>

C대학에 정의된 코드를 바탕으로 중계서버에서 사용할 코드를 매핑한다.

사용된 Mapping으로 MapSubejct_code, MapDepartment_code 2개를 사용하였다.

테스트 결과 = 합격

<가천정보 단위 테스트>

가천 정보에서 회원의 비밀번호를 변경할 때 crypto.js를 이용하여 복호화 한다음에 새로운 비밀번호로 암호화하여 저장한다.

테스트 결과 = 합격

연계 테스트

연계 테스트 범위

• A대학 -> 가천정보 중계서버
• B대학 -> 가천정보 중계서버
• C대학 -> 가천정보 중계서버
• 가천정보 중계서버 -> 가천정보 클라이언트

<A대학 연계 테스트>

테스트 결과 = 합격

<B대학 연계 테스트>

테스트 결과 = 합격

<C대학 연계 테스트>

테스트 결과 = 합격

<가천 정보 연계 테스트>

테스트 결과 = 합격

테스트 환경구축

테스트 환경 구축을 위하여 맨처음으로 연계를 위해 Adapter 설치 및 설정하고 송수신 시스템과 연계 사용할 IP 및 포트 허용, 및 외부 모듈 설치 및 경로 디렉토리 설정을 했다.

그 다음으로는 수신 기관과 연계할 IP및 포트 허용 신청 및 Mapping 코드 데이터 설정을 해였고 운영할 때 필요한 DB 구축을했다.

구축한 DB를 토대로 학생정보, 학생 시간표, 과목 강의실, 학교 교수, 학교 과목 정보 데이터를 구축하였고 중계 서버와 연계 시 서로 다른 코드들을 Mapping 하여 코드들을 맞추었다.

그렇게 준비된 데이터와 코드들을 이용하여 중계 서버와 데이터를 송수신 할 수 있도록 각 대학들과 중계 쪽 코드 구현을 했다.

다음으로는 각 대학들과 연계하여 데이터를 가져올 수 있도록 중계서버에 엔진 설치 및 시스템 설정 및 데이터 송수신시 남는 로그들을 저장 할 수 있는 로그 기록용 폴더 생성 및 권한을 부여하고 ejs 엔진 설치 및 경로 디렉토리를 설정했다.

다음으로는 데이터의 송수신 시 로그 파일 및 데이터가 저장되도록 했고 오류 로그 파일을 설정하여 에러 발생시 에러 로그를 만들어 저장하고 에러 위치를 알 수 있도록 했다.

마지막으로 연계하여 가져온 데이터들을 이용하여 미리 설치해 놓은 ejs 엔진으로 웹 페이지를 구성하고 시간표 데이터들을 가져와 시간표를 한눈에 볼 수 있도록 했다.

연계테스트 수행결과 검증

연계 테스트 케이스의 시험 항목 및 처리 절차 순서에 따라

테스트를 진행하면서 수행한 테스트 결과가 예상한 정상적인 결과인지를 확인하기 위해 검증을 수행하였다.

테스트 결과를 검증하는 방법으로는 위에 표와 같이 운영 DB 테이블에서 데이터 추출 건수를 확인, 코드 매핑 및 변환 , 연계 테이블 생성과 송신 여부 및 수신 여부를 확인했고 수신으로는 유효한 데이터 타입, 길이 및 운영 DB의 테이블에 반영 건수를 통해서 검증했다.

테스트 결과 테스트 예상한 값과 같이 나와 테스트에 통과하였다.