Part 4. 인터페이스 설계 23.01.18(수)

1. 인터페이스 설계 – 인터페이스 요구사항 확인 – 내 · 외부 인터페이스 요구사항

1) 내 · 외부 인터페이스 요구사항의 개념

내 · 외부 인터페이스 요구사항은 조직 내 · 외부에 존재하는 시스템들이 상호 접속을 통하여 특정 기능을 수행하기 위한 접속 방법이나 규칙에 대한 필수적 요구사항이다.

 

2) 내 · 외부 인터페이스 요구사항의 구성

내 · 외부 인터페이스 요구사항을 위해서는 구성요소들을 대상 시스템 및 기관과 사전에 연동 방안에 대한 협의가 필요하다.

 

3) 내 · 외부 인터페이스 요구사항의 분류

(1) 기능적 요구사항

내 · 외부 인터페이스 연계를 통해 수행될 기능과 관련되어 소프트웨어가 가져야 하는 기능적 속성에 대한 요구사항

 

(2) 비기능적 요구사항

내 · 외부 인터페이스 연계 시의 성능, 사용의 용이성, 신뢰도, 보안성, 운용상의 제약, 안정성 등 시스템 전반과 관련된 요구사항

 

2. 인터페이스 설계 – 인터페이스 요구사항 확인 – 요구공학

1) 요구공학의 개념

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

 

2) 요구공학의 목적

이해관계자 사이에 효과적인 의사소통 수단을 제공하고 시스템 개발의 요구사항에 대한 공통된 이해를 설정한다.

요구사항 누락 방지 및 이해 오류로 인한 불필요한 비용을 절감하고 요구사항 변경 추적을 가능하게 한다.

초기 요구사항 관리로 개발 비용과 시간을 절약하고 효과적인 의사소통 수단을 제공한다.

 

3) 요구사항의 분류

(1) 기능적 요구사항

1-개념

시스템이 제공하는 기능, 서비스에 대한 요구사항

 

2-도출 방법

특정 입력에 대해 시스템이 어떻게 반응해야 하는지에 대한 기술

특정 상황에 대해 시스템이 어떻게 동작해야 하는지에 대한 기술

 

3-특성

기능성, 완전성, 일관성

 

4-사례

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

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

 

(2) 비기능적 요구사항

1-개념

시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항

 

2-도출 방법

품질 속성에 관련하여 시스템이 갖춰야할 사항에 관한 기술

시스템이 준수해야 할 제한 조건에 관한 기술

 

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

 

 

4-사례

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

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

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

 

4) 요구공학 프로세스

도출 – 분석 – 명세 – 확인 및 검증

 

*요구사항 확인 및 검증 과정을 통해 모든 요구사항 문제를 발견하기는 어렵다.

 

5) 요구사항 개발 단계 상세

(1) 요구사항 도출 단계

요구사항 도출 단계는 소프트웨어가 해결해야 할 문제를 이해하고, 고객으로부터 제시되는 추상적 요구에 대해 관련 정보를 식별하고 수집 방법 결정, 수집된 요구사항을 구체적으로 표현하는 단계이다.

 

1-요구사항 도출 단계의 주요 기법

[1] 인터뷰(Interview)

이해관계자와 직접 대화를 통해 정보를 구하는 공식적 · 비공식적 정보 수집 방법

 

[2] 브레인스토밍(Brainstorming)

말을 꺼내기 쉬운 분위기로 만들어, 회의 참석자들이 내놓은 아이디어들을 비판 없이 수용할 수 있도록 하는 회의

 

[3] 델파이 기법(Delphi Method)

전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법

 

[4] 롤 플레잉(Role Playing)

현실에 일어나는 장면을 설정하고 여러 사람이 각자가 맡은 역을 연기하여 요구사항을 분석하여 수집하는 방법

 

[5] 워크숍(Workshop)

단기간의 집중적인 노력을 통해 다양하고 전문적인 정보를 획득하고 공유하는 방법

프로젝트에 참여하는 모든 핵심 인물의 참여가 필요

참석자들은 해당 전문 영역별로 팀 협력이 필요하며 사전 준비가 요구

 

[6] 설문조사(Survey)

설문지 또는 여론조사 등을 이용해 간접적으로 정보를 수집

개발될 시스템의 사용자가 다수일 때 의견 수렴에 용이

(2) 요구사항 분석 단계

요구사항 분석 단계는 추출된 요구사항에 대해 충돌, 중복, 누락 등의 분석을 통해 완전성과 일관성을 확보하는 단계이다.

요구사항 분석 단계 기법에는 자료 흐름 지향 분석, 객체 지향 분석이 있다.

다양한 요구사항을 분석하기 위해서 청취 기술, 인터뷰와 질문 기술, 분석 기술, 중재 기술, 관찰 기술, 작성 기술, 조직 기술, 모델작성 기술도 사용한다.

요구사항 분석 단계 기법에는 자료 흐름 지향 분석, 객체 지향 분석이 있다.

 

1-요구사항 분석 단계 기법

[1] 자료 흐름 지향 분석

데이터 흐름도(DFD; Data Flow Diagram) 및 자료 사전(Data Dictionary)으로부터 소프트웨어 구조를 유도하는 방법

 

[2] 객체 지향 분석

시스템의 기능과 데이터를 함께 분석, UML(Unified Modeling Language)로 표준화

 

(3) 요구사항 명세 단계

요구사항 명세 단계는 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 단계이다.

 

1-비정형 명세 기법

사용자의 요구를 표현할 때 자연어를 기반으로 서술하는 기법

사용자와 개발자의 이해가 용이

명확성 및 검증에 문제 발생 가능

ex) FSM, Decision Table, ER 모델링, State Chart(SADT)

 

2-정형 명세 기법

사용자의 요구를 표현할 때 수학적인 원리와 표기법을 이용하는 기법

표현이 간결, 명확성 및 검증이 용이

기법의 이해가 어려움

ex) VDM, Z-스키마, Peri-Nets, CSP 등

 

* Z-스키마

논리를 기반으로 한 수학적 표현을 사용하여 여러 특성을 함축적으로 표현하는 수리적 논리적 명세 언어이다.

* Peri-nets

그래프에 의한 표기법을 제공하고 병렬처리 상태의 표현이 가능한 명세 언어이다.

 

요구사항 명세 단계의 산출물로 요구사항 명세서가 있다.

 

*요구사항 명세서

소프트웨어 개발 프로세스의 시작인 소프트웨어의 요구사항을 분석하고 정의하는 단계에서 작성되는

최종 산출물이다.

 

(4) 요구사항 확인 및 검증 단계

요구사항 확인 및 검증은 요구사항 명세서에 사용자의 요구가 올바르게 기술되었는지에 대한 검토, 베이스라인을 설정하는 활동이다.

요구사항 명세서의 오류가 개발 단계나 운영 중인 상태에서 발견된다며 오류 수정 및 재작업 비용이 많이 소요되므로 요구사항 확인 및 검증은 반드시 필요하다.

요구사항 확인 및 검증단계에서는 정형 기술 검토를 수행한다.

 

* 정형 기술 검토(FRT; Formal Technical Review)

소프트웨어 개발 산출물 대상 요구사항 일치여부 및 결함 발생 여부를 검토하는 정적 분석기법이다.

 

1-정형 기술 검토 기법

[1] 동료 검토(Peer Review)

2~3명이 진행하는 리뷰의 형태

요구사항 명세서 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견하는 형태로 진행하는 검토 방법

 

[2] 워크 스루(Walk Through)

오류를 조기에 검출하는 데 목적이 있는 검토 방법

검토 자료를 회의 전에 배포해서 사전검토한 후 짧은 시간 동안 회의를 진행하는 형태로 리뷰를 통해 오류를 검출하고 문서화하는 비공식적인 검토 방법

 

[3] 인스펙션(Inspection)

소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법

인스펙션 절차는 계획 ->사전교육 -> 준비 -> 인스펙션 회의 -> 수정 -> 후속 조치 순서로 진행

 

2-정형 기술 검토(FTR)의 지침 사항

제품의 검토에만 집중하라.

의제를 제한하여 진행한다.

논쟁과 반박을 제한한다.

문제 영역을 명확히 표현하라.

해결책이나 개선책에 대해서는 논하지 말라.

참가자의 수를 제한하고 사전 준비를 강요하라.

자원과 시간 일정을 할당하라.

모든 검토자들을 위해 의미있는 훈련을 행하라.

검토자들은 사전에 작성한 메모들을 공유하라.

검토의 과정과 결과를 재검토하라.

 

3. 인터페이스 설계 – 인터페이스 대상 식별 – 시스템 아키텍처

1) 시스템(System) 개념

시스템은 하나의 공통적인 목적을 수행하기 위해 조직화된 요소들의 집합체이다.

 

2) 시스템 구성요소

(1) 입력(Input)

처리 방법, 처리할 데이터, 조건을 시스템에 투입하는 행위

 

(2) 출력(Output)

처리된 결과를 시스템에서 산출하는 행위

 

(3) 처리(Process)

입력된 데이터를 처리 방법과 조건에 따라 처리하는 행위

 

(4) 제어(Control)

자료를 입력하고 출력될 때까지의 처리 과정이 올바르게 진행되는지를 감독하는 행위

 

(5) 피드백(Feedback)

출력 결과가 목표를 만족시키지 못하는 경우 달성을 위해 반복 개선하는 행위

 

3) 시스템 아키텍처(System Architecture) 개념

시스템 아키텍처는 시스템의 구조, 행위, 동작 원리를 설명하는 프레임워크이다.

시스템 아키텍처는 시스템 목적을 달성하기 위해서 시스템 각 컴포넌트가 무엇이며 어떻게 상호 작용하는지, 정보가 어ᄄᅠᇂ게 교환되는 지를 설명한다.

 

4) 시스템 아키텍처의 기본 요구사항

시스템 구성 및 동작 원리를 나타내고 있어야 한다.

시스템 구성요소에 대해 설계 및 구현을 지원하는 수준으로 자세히 기술한다.

구성요소 간의 관계 및 시스템 외부 환경과의 관계를 설명해야 한다.

요구사항 및 시스템의 전체 생명주기를 고려해야 한다.

하드웨어와 소프트웨어를 포함하는 시스템 전체에 대한 논리적인 기능 체계와 시스템을 실현하기 위한 구성 방식, 시스템의 전체적인 최적화를 목표로 해야한다.

 

5) 시스템 아키텍처 설계 원칙 및 아키텍처 설계 방안

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

피크타임 용량 확보, 대용량 배치 처리, 부하 분산 최적화, DB 용량 경량화

 

(2) 시스템 아키텍처 확장성 보장

다계층 아키텍처 구성, 하드웨어 확장성, 아키텍처 확장성

 

(3) 서비스 고가용성 보장

장애 예방, 서비스 중단시간 최소화, 비상 시스템 구성

 

(4) 운영관리 효율성

트랜잭션 관리, 성능 및 장애 관리, 통합 백업 관리

 

(5) 시스템 보안 강화

정보 보호 전략 수립, 네트워크 보안, 시스템 보안

 

6) 시스템 아키텍처 물리 설계 – 책 그림 확인하기

(1) 1-Tier 아키텍처

AP 서버, DB 서버 1대 이상 구성

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

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

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

Tier 간 네트워크 트래픽 없음

 

* AP 서버(Application Server)

분산 네트워크 내의 컴퓨터 내에서 응용 프로그램에 비즈니스 로직을 제공하는 서버 프로그램이다.

* DB 서버(Database Server)

분산 네트워크 내의 컴퓨터 내(복수의 서버, 복수의 클라이언트로 구성되어 있는 시스템)에서 데이터베이스를 처리하기 위한 서버이다.

 

(2) 2-Tier 아키텍처

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

일반 OLTP(Online Transaction Processing) 업무

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

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

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

 

(3) 3-Tier 아키텍처

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

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

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

물리적 노드 수가 최소 3개 이상 필요

Tier 간 네트워크 트래픽 발생

 

4. 인터페이스 설계 – 인터페이스 대상 식별 – 인터페이스 시스템

1) 인터페이스 시스템(Interface System) 개념

인터페이스 시스템은 서로 다른 두 시스템 · 장치 · 소프트웨어를 서로 이어주는 접속 및 중계 시스템이다.

 

2) 인터페이스 시스템 구성

(1) 송신 시스템

연계할 데이터를 데이터베이스와 애플리케이션으로부터 연계 테이블 또는 파일 형태로 생성하여 송신하는 시스템

 

(2) 수신 시스템

수신한 연계 테이블 또는 파일의 데이터를 수신 시스템에서 관리하는 데이터 형식에 맞게 변환하여 데이터베이스에 저장하거나 애플리케이션에서 활용할 수 있도록 제공하는 시스템

 

(3) 중계 서버

송신 시스템과 수신 시스템 사이에서 데이터를 송수신하고 연계 데이터의 송수신 현황을 모니터링하는 시스템

연계 데이터의 보안 강화 및 다중 플랫폼 지원 등이 가능

 

5. 인터페이스 설계 – 인터페이스 상세 설계 – 내 · 외부 송 · 수진

1) 내 · 외부 송 · 수신 연계 방식

(1) 직접 연계 방식

중계 서버나 솔루션을 사용하지 않고 송신 시스템과 수신 시스템이 직접 인터페이스 하는 방식

 

(2) 간접 연계 방식

연계 솔루션에서 제공하는 송수신 엔진과 어댑터를 활용하여 인터페이스 하는 방식

송 · 수신 처리 및 현황을 모니터링하고 통제하는 연계 서버를 활용하는 방식

 

2) 내 · 외부 송 · 수신 연계 방식 장단점

(1) 직접 연계 방식

1-장점

중간 매개체가 없어 연계 처리속도가 빠르고 구현이 단순

개발 비용과 기간이 짧음

 

2-단점

송신 시스템과 수신 시스템 간의 결합도가 높아서 시스템 변경시 민감

보안을 위한 암/복호화 처리와 비즈니스 로직 구현을 인터페이스별로 작성

전사 시스템 인터페이스에 대한 통합 환경 구축이 어려움‘

 

(2) 간접 연계 방식

1-장점

송 · 수신 처리 및 현황을 모니터링하고 통제하는 연계 서버를 활용하는 방식

서로 다른 네트워크와 프로토콜 등 다양한 환경을 갖는 시스템들을 연계하고 통합관리할 수 있음

인터페이스 변경 시에도 유연하게 대처가 가능

 

2-단점

인터페이스가 아키텍처와 연계 절차가 복잡하고 연계 서버로 인한 성능 저하

개발 및 테스트 기간이 직접 연계 방식보다 오래 걸림

 

3) 내 · 외부 송 · 수신 연계 기술

(1) DB 링크(DB Link)

데이터베이스에서 제공하는 DB 링크 객체를 이용하는 기술

수신 시스템에서 DB 링크를 생성하고 송신 시스템에서 해당 DB 링크를 직접 참조하는 방식

 

(2) DB 연결(DB Connection)

수신 시스템의 WAS에서 송신 시스템 DB로 연결하는 DB 커넥션 풀(DB Connection Pool)을 생성하고 연계 프로그램에서 해당 DB 커넥션 풀명을 이용하는 기술

 

(3) API / Open API

송신 시스템의 DB에서 데이터를 읽어서 제공하는 애플리케이션 프로그래밍 인터페이스 프로그램

API 명, 입출력 파라미터 정보가 필요함

 

(4) JDBC

수신 시스템의 프로그램에서 JDBC 드라이버를 이용하여 송신 시스템 DB와 연결하는 기술

DBMS 유형, DBMS 서버 IP와 Port, DB 인스턴스(Instance) 정보가 필요

 

(5) 하이퍼 링크(Hyper Ling)

- 웹 애플리케이션에서 하이퍼링크 이용하는 기술

 

(6) 소켓(Socket)

서버는 통신을 위한 소켓을 생성하여 포트를 할당하고 클라이언트의 통신 요청 시 클라이언트와 연결하고 통신하는 기술

 

4) 내 · 외부 송 · 수신 통신 유형

1-실시간

[1] 단방향

데이터를 이용하고자 하는 시스템에서 거래를 요청하는 방식

데이터를 전송하는 상대 시스템의 응답이 필요 없는 업무에 사용

실시간 File, 실시간 DB 연계에도 사용

 

[2] 양방향

시스템 간에 거래를 상호 요청하는 방식

데이터를 전송하는 상대 시스템의 응답이 필요한 업무에 사용

 

[3] 동기(Sync)

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

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

 

[4] 비동기(Async)

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

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

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

 

[5] 지연 처리(Deferred)

비동기, 단방향 유형과 유사한 방식

순차 처리 및 지연 처리가 필요한 업무에 사용

 

2-배치

[1] DB/File 거래

정해진 시간에 통신을 수행되는 방식

연계 스케줄러에 의해 구동되는 이벤트 방식과 타이머에 의한 방식이 있음

 

6. 인터페이스 설계 – 인터페이스 상세 설계 – 미들웨어 솔루션

1) 미들웨어(Middleware) 개념

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

 

서로 다른 프로토콜이나 시스템 운영체제, 데이터베이스와 애플리케이션 간에 통신을 지원해 주는 소프트웨어를 의미하며, 애플리케이션이 어떤 정보시스템 환경에서도 작동할 수 있도록 지원해 주는 역할을 한다.

 

분산 시스템 관점에서의 미들웨어는 위치 투명성을 제공하고, 여러 컴포넌트가 요구하는 재사용 가능한 서비스의 구현을 제공한다.

 

2) 미들웨어 솔루션 유형

(1) DB 미들웨어

DB 솔루션 업체에서 제공하는 애플리케이션과 DB 간에 통신을 원할하게 하는 것을 목적으로 하는 미들웨어

 

(2) 원격 프로시저 호출(RPC; Remote Procedure Call)

응용 프로그램의 프로시저를 사용하여 원격 프로시저를 로컬 프로시저처럼 호출하는 방식의 미들웨어

 

* 프로시저

특정 동작이나 연산을 위한 명령들을 별도로 마련하여 필요할 때 마다 사용하는 것으로 프로그램에서 이름을 부를 때 마다 실행된다.

이 때 프로시저에서 사용하는 값을 매개변수를 통하여 전달하기도 한다.

 

(3) 메시지 지향 미들웨어(MOM; Message-Oriented Middleware)

메시지 기반의 비동기형 메시지 전달 방식 미들웨어

서로 다른 이기종 분산 DB 시스템의 데이터 동기를 위하여 주로 사용

 

(4) 트랜잭션 처리(TP; Transaction Processing) 모니터

온라인 업무에서 트랜잭션을 처리, 감시하는 미들웨어

분산 환경의 핵심 기술인 분산 트랜잭션을 처리하기 위한 미들웨어

주로 사용자가 많고 안정적이면서도 즉각적인 처리가 필요한 업무 프로그램의 개발에 많이 사용

 

(5) 레거시웨어(Legacyware)

기존의 애플리케이션이나 DB 기반에 새로운 업데이트된 기능을 덧붙이고자 할 때 사용되는 미들웨어

 

(6) 객체기반(ORB; Object Request Brokers) 미들웨어

코바(CORBA) 표준 스펙을 구현한 객체 지향 미들웨어

각기 다양한 기반으로 구축된 컴퓨터 간의 프로그램과 데이터의 교환 및 변환이 편리하게 이루어질 수 있도록 지원

 

(7) WAS(Web Application Server)

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

WAS는 HTTP 세션 처리를 위한 웹 서버 기능{뿐만 아니라 민감한 기업 업무까지 자바, 컴포넌트 기반으로 구현 가능

* WAS(미들웨어)를 사용하면 Web 서버에서는 웹 문서만 처리하도록 하여 Web 서버의 부담을 줄일 수 있다.