Chapter 4. 인터페이스 설계

[1] 인터페이스 요구사항 확인

#. 요구 공학(Requirements Engineering)

- 요구공학은 사용자의 요구가 반영된 시스템을 개발하기 위하여 사용자의 요구 사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동이다.

 

#. 요구 공학의 목적

- 이해관계자 사이에 효과적인 의사소통 수단 제공

- 시스템 개발의 요구사항에 대한 공통된 이해 설정

- 요구사항 누락 방지 및 이해 오류로 인한 불필요한 비용 절감

- 요구사항 변경 추적

- 개발 비용, 시간 절약

 

#. 기능적 요구사항

- 기능성, 완정성, 일관성

예시)

- 온라인 홈페이지에서는 쇼핑카트에 주문하고자 하는 품목을 저장할 수 있는 장바구니 기능을 제공해야한다.

- 상품의 결제 수단은 신용카드, 무통장 입금, 포인트 결제가 가능해야한다.

 

#. 비기능적 요구사항

- 신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성 및 품질 관련 요구사항, 제약사항

예시)

- 특정 함수의 호출 시간은 3초를 넘지 않아야 한다.

- 시스템은 하루 24시간 가동되어야 하며 가동률 99.5%를 만족해야한다.

- 시스템은 운영되는 중에 패치 및 업그레이드를 할 수 있어야 한다.

 

#. 요구사항 개발 절차 (도분명확)

요구사항 도출  → 요구사항 분석 → 요구사항 명세 → 요구사항 확인 및 검증

 

#. 요구사항 명세 원리 및 검증 항목 (명완검 일수 추개)

- 명확성

- 완전성

- 검증 가능성

- 일관성

- 수정 용이성

- 추적 가능성

- 개발 후 이용성

 

#. 비정형 명세 기법과 정형 명세 기법

주요 기법	설명	종류
비정형 명세 기법	- 사용자의 요구를 표현할 때 자연어를 기반으로 서술하는 기법 - 사용자와 개발자의 이해가 용이 - 명확성 검증에 문제 발생 가능	FSM, Decision Table, ER 모델링, State, Chart(SADT)
정형 명세 기법	- 사용자의 요구를 표현할 때 수학적인 원리와 표기법을 이요하는 기법 - 표현이 간결, 명확성 및 검증 용이 - 기법의 이해가 어려움	VDM, Z-스키마, Petri-Nets, CSP

#. 정형 기술 검토 (FTR) 가이드라인

- 제품의 검토에만 집중

- 의제를 제한하여 진행

- 논쟁과 반박을 제한

- 문제 영역을 명확히 표현

- 참가자 수 제한

- 자원과 시간 일정 할당

- 검토 과정과 결과 재검토

정형 기술 검토 활용	동료 검토	- 2~3명이 진행하는 리뷰 형태 - 요구사항 명세서 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견하는 형태
	워크 스루	- 오류를 조기에 검풀하는 것이 목적 - 검토 자료를 회의 전에 배포해서 사전검토한 수 짧은 시간 동안 회의를 진행하는 형태로 리뷰를 통해 오류를 검출하고 문서화
	인스펙션	- 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법

 

[2] 인터페이스 대상 식별

#. 시스템 구성 요소

- 입력 (Input)

- 출력 (Output)

- 처리 (Progress)

- 제어 (Control)

- 피드백 (Feedback)

 

#. 시스템 아키텍처 설계 원칙 (대확 고운보)

- 대규모 트랜잭션 처리 및 온라인 성능 보장

- 시스템 아키텍처 확장성 보장

- 서비스 고가용성 보장

- 운영관리 효율성

- 시스템 보안 강화

 

#. 시스템 아키텍처 물리 설계

1) 1-Tier 아키텍처 (비즈니스 로직 + 데이터)

- AP/DB 서버 1대 이상 구성

- UI 로직 없는 인터페이스 게이트웨이 업무

- 데이터 및 비즈니스 로직이 유출 가능

- 물리적 노드 수가 최소 1개로 구성

- Tier 간 네트워크 트래픽 없음

 

2) 2-Tier 아키텍처 (UI + 비즈니스 로직, 데이터)

- AP 서버, DB 서버 2대 이상 구성

- 일반 OLT 업무

- 비즈니스 로직 유출이 발생할 수 있음

- 물리적 노드 수가 최소 2개 이상

-  AP와 DB 서버 간 네트워크 트래픽 발생

 

3) 3-Tier 아키텍처 (UI 로직, 비즈니스 로직, 데이터)

- 프레젠테이션 서버, AP 서버, DB 서버 3대 이상으로 구성

- 대용량 온라인 트랜젝션 처리 업무

- 데이터 및 비즈니스 로직 유출 방지 용이

- Tier 간 네트워크 트래픽 발생

 

#. 인터페이스 시스템 구성

- 송신 시스템

- 수신 시스템

- 중계 서버

 

#. 인터페이스 시스템의 데이터 표준 (공개종)- 공통부- 개별부- 종료부

 

[3] 인터페이스 상세 설계

#. 내·외부 송·수신 연계 기술 (링커 에제 하소)

연계 기술	설명
DB 링크 (DB Link)	· 데이터베이스에서 제공하는 DB 링크 객체를 이용하는 기술 · 수신 시스템에서 DB 링크를 생성하고 송신 시스템에서 해당 DB 링크를 직접 참조하는 방식
DB 연결 (DB Connection)	· 수신 시스템의 WAS에서 송신 시스템 DB로 연결하는 DB 커넥션 풀을 생성하고 연계 프로그램에서 해당 DB 커넥션 풀명을 이용하는 방식
API/Open API	· 송신 시스템의 DB에서 데이터를 읽어서 제공하는 애플리케이션 프로그래밍 인터페이스 프로그램 · API 명, 입출력 파라미터 정보가 필요함
JDBC	· 수신 시스템의 프로그램에서 JDBC 드라이버를 이용하여 송신 시스템 DB와 연결하는 기술 · DBMS 유형, DBMS 서버 IP와 Port, DB 인스턴스 정보가 필요
하이퍼 링크 (Hyper Link)	· 웹 어플리케이션에서 하이퍼링크 이용하는 기술
소켓 (Socket)	· 서버는 통신을 위한 소켓을 생성하여 포트를 할당하고 클라이언트와 통신 요청 시 클라이언트와 연결하고 통신하는 기술

 

#. 내/외부 송·수신 통신 유형

1)  동기(Sync)

- 데이터를 이용하고자 하는 시스템에서 거래 요청을 하고 응답이 올때까지 대기(Request-Reply)하는 방식

- 업무 특성상 응답을 바로 처리해야 하는 거래나 거래량이 적고, 상대 시스템의 응답 속도가 빠를 경우 사용

 

2) 비동기(Async)

- 데이터를 이용하고자 하는 시스템에서 거래를 요청하는 서비스와 응답을 받아 처리하는 서비스가 분리되는 구조

- 요청을 보내고 다른 작업을 하다가 데이터가 준비되었다는 신호를 받으면 다시 처리하는 방식

- 주문 업무와 같이 거래량이 많거나 데이터를 전송하는 시스템의 처리가 오래 걸리는 업무에 사용

 

#. 미들웨어(Middleware)

- 미들웨어는 컴퓨터와 컴퓨터 간의 연결을 쉽고 안전하게 할 수 있도록 해주고 이에 대한 관리를 도와주는 소프트웨어이다.

 

#. 미들웨어 솔루션 유형 (디원메트 레객와)

- DB 미들웨어 : DB 간에 통신

- 원격 프로시저 호출 (RPC) : 응용프로그램의 프로시저를 이용하여 호출

- 메시지 지향 미들웨어 (MOM) : 서로 다른 이기종 분산 DB 시스템의 데이터 동기를 위해 사용

- 트랜잭션 처리 (TP) : 온라인 업무에서 트랜잭션을 처리, 감시

- 레거시웨어 (Legacyware) : 업데이트된 기능을 덧붙임

- 객체 기반 미들웨어 (ORB) : 교환 및 변환, 코바 표준 스펙

- WAS : 서버계층에서 애플리케이션이 동작할 수 있는 환경을 제공, 안정적인 트랜잭션 처리와 관리, 다른 이기종 시스템과의 애플리케이션 연동 지원

 

#. EAI 와 ESB 특징 비교

1) EAI

- 기업 내부의 이기종 응용 모듈 간 통합

- 허브 앤 스포크 방식의 집중형 토폴로지 구성

- 애플리케이션 간의 단단한 통합

- 기업 내부망에 적용

 

2) ESB

- 기업 간의 서비스 교환을 위해 표준 API로 통합

- ESB의 분산형 토폴로지 구성

- 서비스 간의 느슨한 통합

- 기업 외부 채널망에 적용