정보처리기사 필기 | 1. 소프트웨어 설계 요약

자격증 정보처리기사 필기의 “Chapter 1. 소프트웨어 설계” 내용을 요약합니다.

1) 요구사항 확인에서는 시스템 분석과 요구사항 확인, 플랫폼 및 운영체제 분석, 네트워크 및 DBMS 분석, UML 및 애자일에 대한 설명을 포함합니다.

2) 화면 설계에서는 CLI, GUI, NUI 등 다양한 유형과 직관성, 일관성, 접근성 등을 고려한 설계 기본 원칙을 소개하며, 사용자 중심의 효과적이고 효율적인 설계를 위한 지침과 도구를 나타냅니다.

3) 애플리케이션 설계에서는 공통 모듈, 모듈화, 결합도와 응집도 등의 원칙부터 소프트웨어 아키텍처, 생명주기, 객체지향 설계, 디자인 패턴까지 다양한 주제를 다룹니다.

4) 인터페이스 설계에서는 내/외부 연동 시스템 간의 상호작용을 위한 명세화와 검증, 오류 처리 방안, 미들웨어 등을 다룹니다.

     

1) 요구사항 확인

현행 시스템 분석

현행 시스템 파악

• 향후 개발하고자 하는 시스템의 개발 범위와 방향성 설정을 위해 기능, 시스템 간 정보, 기술 스택, 소프트웨어, 하드웨어, 네트워크 구성 등을 파악

1. 현행 시스템 구성 현황, 시스템 기능 현황, 시스템 인터페이스 파악
   • 조직의 주요 업무를 업무처리 기간과 지원 업무로 구분 기술하여, 단위 업무 정보시스템들의 정보를 명시 후 현황 파악
   • 단위 업무 시스템에서 제공하는 기능들을 기술하여, 주요 기능과 하부 기능으로 계층형 표시
   • 데이터 형식 및 통신 규약, 연계 유형 등을 고려하여 단위 업무 시스템끼리 주고 받는 데이터의 종류, 형식, 프로토콜, 연계 유형 주기 등을 명시
2. 현행 시스템 아키텍쳐 구성, 소프트웨어 구성도
   • 기간 업무를 수행하기 위해 계층별 기술 요소를 그림으로 표현
   • 단위 업무 시스템의 업무 처리를 위해 설치된 소프트웨어를 명시
3. 하드웨어 구성도, 네트워크 구성도
   • 단위 업무 시스템들의 운용 위치와 주요 사양과 수량, 이중화 적용 여부 명시
   • 업무 처리 시스템들의 네트워크 구성을 표현

     

플랫폼 ^Platform 기능 분석

• 플랫폼: 공급자와 수요자 등 여러 그룹이 참여하여 각각의 그룹이 얻고자 하는 가치와 목적을 공정한 거래를 통해 교환 가능하도록 구축된 환경
• 여러 애플리케이션 끼리의 상호 호환이 쉽게 이루어짐
• 기능
  • 연결 비용 감소, 검색 비용 절약, 커뮤니티 형성에 의한 네트워크 효과

     

운영체제 ^OS 분석

• OS: 하드웨어와 소프트웨어 자원을 관리하고 컴퓨터의 공통 서비스를 제공하는 SW ^{UNIX, Linux, iOS, Android}

• OS 요구사항 식별

  • 신뢰도 고려: 장기간 시스템 운영 시 OS 고유 장애 발생 가능성, OS 버그로 인한 패치 설치 재가동, 메모리 누수
  • 성능: 대규모 및 대량 파일, 동시 사용자 요청 처리, 지원 메모리
  • 기술 지원: 공급업체들의 안정적인 기술 지원
  • 주변 기기 지원 여부
  • 구축 비용: 응용프로그램 라이센스 정책 및 비용, 하드웨어 유지 및 관리 비용

     

네트워크 ^Network 분석

• 네트워크: 서로 통신하기 위해 연결된 동일한 프로토콜을 사용하는 장치들의 집합

• OSI 7계층

  • 1계층, 물리적 계층 ^{Physical Layer} ㅣ 물리적 연결 (랜, 동축, 광케이블) 을 위한 계층, 비트 스트림 데이터 전송
    • 데이터 전송 신호 운반에 요구되는 하드웨어 특성을 정의하여 전압 레벨, 인터페이스 핀의 위치가 정의
    • 기계적 (시스템과 주변장치 사이의 연결), 전기적 (전위 규격과 전위 변화의 타이밍), 기능적 (각 신호에 의미를 부여하여 수행)
    • 프로토콜: RS-232C, V.24, X.21, V.35
  • 2계층, 데이터링크 계층 ^{Data Link Layer} ㅣ 네트워크 개체들 간 데이터 전달 및 흐름제어 담당, 프레임 전송 단위
    • 스위치, 브리지
    • 프로토콜: SDLC, HDLC, SLDP, PPP, SLIP, 이더넷
  • 3계층, 네트워크 계층 ^{Network Layer} ㅣ 라우팅, 흐름 제어, 세그멘테이션, 오류 제어 등을 수행, 패킷 단위
    • 라우터, IP
    • 프로토콜: X-25, IP/ICMP
  • 4계층, 전송 계층 ^{Transport Layer} ㅣ 통신의 양 끝단 사용자들의 신뢰성 있는 전송을 보장, 세그먼트 단위, 음성/데이터 정보를 실제로 교환
    • PSTN, PSDN, ISDN, B-ISDN
    • 프로토콜: TCP/UDP, SCTP
  • 5계층, 세션 계층 ^{Session LayerHTTP/FTP} ㅣ 종단 간의 세션의 연결과 종료에 대한 역할, 데이터/메세지 단위
    • 프로토콜: SSH/TLS
  • 6계층, 표현 계층 ^{Presentation Layer} ㅣ 종단 간의 데이터 변환, 압축, 압축 해제, 암/복호화 담당, 데이터/메세지 단위
    • 프로토콜: JPEG/MPEG, ASN.1, BER
  • 7계층, 응용 계층 ^{Application  Layer} ㅣ 사용자가 네트워크에 접근하여 여러 응용 서비스를 제공, 데이터/메세지 단위
    • 프로토콜: TCP/IP (FTP, SMTP, HTTP, TELNET), OSI (FTAM, CMIP)

• OSI 7 계층 데이터 단위

  • 계층에 상관없이 사용할 때는 통칭하여 PDU (Protocol Data Unit)이라고 부름
  • APDU ^{Application Protocol Data Unit}: 응용 계층에서 사용하는 데이터의 단위
  • PPDU ^{Presentation Protocol Data Unit}: 표현 계층에서 사용하는 데이터의 단위
  • SPDU ^{Session Protocol Data Unit}: 세션 계층에서 사용하는 데이터의 단위
  • TPDU ^{Transport Protocol Data Unit}: 전송 계층에서 사용하는 데이터의 단위, TCP에서는 세그먼트, UDP에서는 데이터 그램
  • NPDU ^{Network Protocol Data Unit}: 네트워크 계층에서 사용하는 데이터의 단위, 패킷
  • DPDU ^{Data Link Protocol Data Unit}: 데이터 링크 계층에서 사용하는 데이터의 단위, 프레임

     

DBMS ^{Data Base Management System} 분석

• DBMS: 사용자와 데이터 베이스 사이에서 사용자의 요구에 따라 정보를 생성, 관리 소프트웨어
• 종류

  • Oracle by Oracle

    대규모, 대량 데이터 안정적 처리

  • MS_SQL by Microsoft

    중소 규모 데이터의 안정적 처리

  • MySQL by MySQL AB, Oracle

    오픈소스 RDBMS

  • SQLite by D.Richard Hipp

    임베디드 DB

  • MongoDB by MongoDB Inc

    오픈 소스 NoSQL 데이터베이스

• 기능
  • 정의 ^Definition: 모든 응용 프로그램들이 요구하는 데이터 구조를 지원하기 위해 DB에 저장될 데이터 유형 및 구조 명시
  • 조작 ^Manipulation: CRUD 등을 체계적으로 처리하기 위해 사용자와 DB사이의 인터페이스 수단 제공
  • 제어 ^Control: 데이터의 정확성 및 안전성 유지 (무결성, 보안, 병행 수행 제어, 회복)
• 고려 사항
  • 성능 측면
    • 가용성: 시스템 장기간 운영 시 장애 발생 가능성, DBMS 버그로 인한 패치 설치 위한 재기동, DBMS 이중화 및 복제 지원
    • 성능: 대량 거래 처리, 비용 기반 최적화 지원, 튜닝 옵션 지원
    • 기술 지원: 공급업체들의 안정적인 기술 지원, 오픈 소스 여부
  • 지원 측면
    • 상호 호환성: 설치 가능한 OS, 다양한 OS에서 지원되는 JDBC, ODBC
    • 구축 비용: 라이선스 정책, 유지 및 관리, 총 소유 비용 (TCO)

     

요구사항 확인

요구분석

• 소프트웨어에 필요한 기능과 기능 수행에 대한 제약사항을 나타냄
• 요구 사항 유형
  • 시스템 요구사항: 시스템 사용자와 다른 시스템에 제공해야 하는 서비스 요구사항
  • 사용자 요구사항: 사용자 관점에서 해당 시스템이 제공해야 할 요구사항, 시나리오 형식
  • 기능 요구사항: 시스템의 특정 목적을 위해 소프트웨어가 갖추어야 하는 기능을 서술
  • 비기능 요구사항: 수행 가능한 환경, 품질, 제약 사항의 솔루션을 제한하기 위한 기능
• 요구사항 개발 프로세스
  1. 도출 ^Elicitation: 해결할 문제를 이해하는 단계
  2. 분석 ^Analysis: 소프트웨어 요구사항을 도출
  3. 명세 ^{Specification}: 체계적인 문서 작성
  4. 확인 ^Validation: 문제 파악을 위한 검증
• 요구 분석 기법 유형
  • 개념 모델링: 문제 도메인의 엔티티와 그들의 관계 및 종속성 반영, UML ^{Unified Modeling Language} 표기법을 사용
  • 요구사항 분류: 기능/비기능 요구사항인지 확인
  • 요구사항 할당: 요구사항 만족을 위한 아키텍처 구성 요소 식별
  • 요구사항 협상
  • 정형 분석: 수학적 기호로 표현 후 분석

     

UML ^{Unified Modeling Language}

• 객체지향 모델링 언어로 시스템 개발 과정에서 개발자와 고객, 상호간의 원활한 의사소통을 위한 표준화 언어
• 특징
  • 가시화: 개념 모델을 그래픽 형태로 작성
  • 구축화: 다양한 OOP 언어로 변환 가능
  • 명세화: 개발 과정마다 필요한 모델을 정확히 명세
  • 문서화: 시스템에 대해 프로젝트 참여자 간 의사소통에 필요한 문서화 가능
• 구성요소
  • 사물: 구조 사물 (시스템 구조 표현), 행동 사물 (시스템 행위를 표현), 그룹 사물 (개념을 그룹화), 주해 사물 (부가적으로 개념 설명)
  • 관계: 의존 관계 (영향 미치는 사물), 일반화 관계 (한 사물이 다른 사물에 비해 더 일반적인지 표현), 연관 관계 (서로 연관), 실체화 관계 (행위로 그룹화)
  • 다이어그램:
    • 구조적 다이어그램: 클래스, 객체, 컴포넌트, 배치, 복합체 구조, 패키지 다이어그램
    • 행위 다이어그램: 유스케이스, 시퀀스, 커뮤니케이션, 상태, 활동, 상호작용 개요, 타이밍 다이어그램

     

애자일 ^Agile

• 꾸준히 고객의 반응을 반영하면서 소프트웨어를 개발하는 방법론
• 반대 개념으로는 소프트웨어 개발 계획을 정해두고 각각 단계별로 개발을 진행하는 폭포수 모델이 있음
• 변화에 대응, 고객과 협업, 실행되는 소프트웨어 중시, 개인과의 상호작용 중시
• SW 원칙
  • 현업과 개발자가 프로젝트 기간에 함께 일함
  • 실행되는 SW가 진척도의 1차 기준
  • 개발 막바지에도 요구사항 변경을 환영
  • 단순화 추구, 지속적인 일정한 속도로 개발
  • 몇 주 단위로 실행되는 SW를 제공
• 유형
  • XP ^{eXtreme Programing}: 고객 협업, 단기간의 개발 기간, 단순 설계, 짝 프로그래밍, 리팩토링, 지속적 통합
  • SCRUM: 개발팀, 스크럼마스터, 제품 팀의 구성으로 스프린트로 진행

     

분석 모델 확인

모델링 기법

• 단계
  1. 요구사항 분석 : 데이터 문제점을 확인하고 개선점 도출
  2. 개념 데이터 모델링: 주제별 분류 가능한 업무를 분석, 핵심 엔티티와 관계를 정의하여 데이터 골격 형성
  3. 논리 데이터 모델링: 핵심 엔티티와 관계를 바탕으로 상세 속정 정의 및 식별자 확정, 정규화
  4. 물리 데이터 모델링: DBMS의 특성 및 구현 환경 등을 감안한 스키마를 일정한 기준과 규칙에 의해 도출, 컬럼의 데이터 타입 및 크기 정의
• 기능
  • 시스템 구조 및 행동 명세화
  • 목표에 따라 구체화된 상세 수준의 표현 방법 제공
  • 시스템 구축하는 구조화된 틀 제공 및 결정 내용 문서화
  • 다양한 영역에 집중하기 위해 다른 영역의 세부 사항은 숨기는 다양한 관점 제공

     

분석 모델의 시스템화 타당성 분석

1. 분석 모델의 기술적 타당성 확인 절차

   a. 성능 및 용량 적정성: 요구되는 시스템 자원을 식별

   b. 시스템 간 상호 운용성: 구체적으로 시스템 간 상호 정보 및 서비스 교환 가능 여부 검토

   c. 시장 성숙도 및 트렌드 부합성

   d. 기술적 위험 분석: 분석모델과 소프트웨어의 부합 여부 확인

2. 요구사항 분석 자동화 도구

   • 요구사항을 자동으로 분석하고 분석 명세서를 기술하도록 개발된 도구

3. 요구사항 분석을 위한 자동화 도구의 종류

   • SADT ^{Structured Analysis and Design Technique} by SoftTech
     • 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위해 널리 이용되어 온 구조적 분석 및 설계 도구
   • SREM ^{Software Requirements Engineering Methodology} by TRW
     • 우주 국방 시스템 그룹에 의해 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록 할 목적으로 개발됨, RSL과 REVS 사용
   • PSL/PSA ^{Problem Statement Language, Problem Statement Analyzer} by 미시간 대학
     • PSL: 문제 기술 언어
     • PSA: PSL로 기술한 요구 사항을 자동으로 분석하여 다양한 보고서를 출력하는 문제 분석기
   • TAGS ^{Technology for Automated Generation of Systems}: 시스템 공학 방법 응용에 대한 자동 접근 방법, 개발 주기의 전 과정에 이용 가능한 통합 자동화 도구

     

2) 화면 설계

UI 요구사항 확인

UI 표준

• UI (사용자 인터페이스): 사용자와 시스템 사이 의사소통 및 월활한 작동을 돕는 프로그램의 일부분 (장치, 소프트웨어)
• 유형
  • CLI ^{Command Line Interface}: 명령어를 입력하여 정보를 이용 가능한 인터페이스
  • GUI ^{Graphical User Interface}: 마우스 등을 이용하여 작업을 수행하는 그래픽 환경의 인터페이스
  • NUI ^{Natural User Interface}: 터치 방식과 같이 사용자의 행동 및 동작으로 조작하는 인터페이스
• 분야
  • 물리적 제어 분야: 정보 제공과 기능 전달
  • 기능적 분야: 사용자의 편의성에 맞춰 쉽고 간편하게 사용 가능
  • 구성 분야: 콘텐츠의 상세한 표현과 전체적 구성
• 설계 기본 원칙
  • 직관성: 누구나 쉽게 이해 및 사용 가능
  • 유효성: 사용자의 목적을 달성할 수 있도록 정확하고 완벽
  • 학습성: 사용자 누구나 쉽게 학습
  • 유연성: 사용자의 요구사항을 최대한 수용, 오류를 방지

     

UI 지침

• UI 표준에 따라 개발 과정에서 꼭 지켜야할 UI 요구사항
• 설계 지침
  • 사용자 중심: 실 사용자에 대한 이해를 바탕으로 편리한 환경 제공
  • 결과 예측 가능: 작동시킬 기능만 보고도 쉽게 결과 예측 가능
  • 일관성: 사용자가 조작하는 방법을 쉽게 기억, 빠른 습득 가능
  • 접근성: 사용자의 연령, 성별, 직무와 상관없이 활용
  • 오류 발생 해결: 오류 발생 시 사용자가 정확히 인지 가능
  • 가시성: 주요 기능은 메인 화면에 노출
  • 표준화: 기능과 디자인을 표준화
• 요구 사항 정의
  • 시스템 간, 화면 간, 화면 내 동선 최소화, Work Flow와 일치하는 화면 구성, 정보 우선순위의 시각적 명확화, 팝업 창 및 스크롤 최소화 등의 내용을 중심으로 기술
  • 사용자 인터페이스 주요 작성 항목
    • 이름: 요구사항을 쉽고 간단하게 파악 가능한 의미 있는 이름
    • 관련 APP/기능: 요구사항을 적용해야 하는 애플리케이션 이름 및 대상 기능명 작성
    • 내용: 사용자 편의성, 정보 접근성, 작업 효율성, 정보 유용성 등을 위한 레이아웃 및 디자인 요구사항 작성

     

스토리 보드

• UI 설계를 위해 디자이너와 개발자가 최종적으로 참고하는 문서

• 정책, 프로세스 및 콘텐츠의 구성, 와이어 프레임 (UI, UX), 기능에 대한 정의, 데이터베이스의 연동 등을 구축하는 서비스를 위한 정보가 수록됨

• 스토리 보드 작성 절차
  1. 전체적 스토리 보드 작성: 메뉴의 순서, 구성 단계, 용어 정의
  2. 화면 단위 스토리 보드 상세화: 그래픽 자료 개발 및 제시 방법 결정, 레이아웃이나 글자 모양, 크기, 색상에서의 일관성 유지
  3. 설계, 검토 및 수정: 화면에서 보여지는 여러 시각적 디자인 콘셉트를 설계한 후 설계자, 전문가, 학습자의 검토와 수정이 이루어짐
• 스토리보드 구성 요소
  • 목차: 각 페이지별 제목
  • 업데이트 기록: 언제 어떤 페이지에 어떤 내용이 수정되었고, 해당 수정 이슈의 작업을 진행할 포지션 기재
  • 개요 및 요소별 정의: 기획의 목적을 정의하고, 만들고자 하는 서비스의 운용정책을 기재
  • 사이트 맵: 각 페이지의 메인 메뉴와 하위 메뉴를 시각화
  • 프로세스: 특정 서비스의 기본 흐름도와 세부 흐름도 구분
  • 전체 화면 구성: 만들고자 하는 페이지의 전체화면 레이아웃 정리
  • 영역 별 상세설명: 전체화면 구성 내용을 바탕으로 영역 별 디자인/기술적 상세설명 기재
  • 작업 스케줄 구성: 해당 기획안의 기획부터 개발완료까지의 스케줄 정리
• 스토리 보드 툴
  • 파워포인트, 키노트, 스케치, Axure

     

UI 설계

감성 공학

• 제품 설계에 있어서 최대한 인간의 특성과 감정을 반영시키는 기술
• 인간의 쾌적성을 평가하기 위한 기초자료로 인간의 시각, 청각, 촉각, 후각, 미각 등의 감각 기능을 측정
• 접근 방법
  • 1류 접근 방법
    • 의미 미분법 ^{Semantic differential method} ㅣ 인간 감성 표현하는 어휘를 이용하여 제품에 대한 이미지를 조사하고, 분석을 통한 제품 디자인 요소와 연계
  • 2류 접근 방법
    • 1류와 기본틀은 동일, 감성 어휘 수집의 전 단계에서 평가자들의 생활 양식을 고려
    • 제품에 대한 기호와 수요에 소비자군의 소속 지역, 의식 문화가 많은 영향을 미칠 때
  • 3류 접근 방법
    • 감성 어휘 대신 인간 평가자의 특정시제품을 사용하여 자신의 감각 척도로 감성 표출
    • 대상 제품의 물리적 특성에 대한 객관적 지표와의 연관 분석을 제품 설계에 응용
    • 인간 감각 계측과 이의 활용이 강조된 접근법
• 기술 종류
  • 제품 설계에 활용할 수 있는 인간 특성을 파악하는 기반 기술
    • 인간공학: 인간의 신체적/인지적 특성을 고려하여 물체, 시스템, 환경의 디자인을 과학적인 방법으로 개선
    • 생리학: 생물체의 기능을 연구하는 과학의 한 분야
    • 생체기술: 생물체가 갖고 있는 기능을 인위적으로 모방
    • 인간감각 계측기술: 인간이 가지고 있는 감각을 측정
  • 인간 특성에 알맞도록 인터페이스를 구현하기 위한 구현 기술
    • 센서 및 센싱 기술: 온도/속도 또는 기타 작동 장치의 상태를 계측 제어 등을 검사하며 반응에 의해 자동으로 행동을 결정
    • 액튜에이터 기술: 유체 에너지를 통해 기계적인 작업 수행
    • 센서 퓨전 기술: 측정 대상물로부터 물리량을 검출하고 전기적 신호로 변환하는 센서를 응용
    • 마이크로 머시닝 기술: 집적회로(IC) 제조 기술으로 가동부가 있는 3차원 구조의 센서를 미세 가공
    • 퍼지 뉴럴 네트워크 기술: 인간의 뇌의 기능을 적극적으로 모방
  • 인간에 대한 적합성을 판단하고 새로운 감성을 창출하기 위한 응용 기술
    • 가상 현실 기술: 특정 환경, 상황을 컴퓨터를 이용하여 3차원 그래픽으로 나타냄

     

UI 설계 도구

• 와이어 프레임, 스토리보드, 프로토타입, 목업, 유스케이스 활용

• UI 설계서 구성에 따른 작성법 _구성요소

  • UI 설계서 표지: 프로젝트 이름, 시스템 이름 포함
  • UI 설계서 개정 이력: 첫번째 항목으로 초안 작성을 포함시키고 그에 해당하는 초기 버전을 1.0으로 설정
    • 수정 및 보완이 이루어진 경우 버전을 x.0으로 바꾸어 설정
  • UI 요구사항 정의
  • 시스템 구조: UI 프로토 타입을 재확인하고, UI 요구사항들과 프로토타입에 기초하여 UI 시스템 구조를 설계
  • 사이트 맵: 사이트 맵 상세 내용을 표 형태로 작성
  • 프로세스: 사용자 관점에서 요구되는 프로세스들을 진행 순서 따라 정리
  • 화면 설계: UI 프로토 타입 및 프로세서 정의를 참고하여 각 페이지 별 필요 화면 설계
    • 화면 별 고유 ID 부여, 별도의 표지 페이지를 작성
    • 각 화면 별 필요 화면 내용 설계

• 와이어 프레임 ^Wireframe

  • 각 페이지와 기능 간의 관계와 구조를 제안하고 시각화 함
  • 화면 구성요소의 배치와 속성, 기능, 네비게이션 등과 관련한 동작들을 간단한 선과 사각형으로 그려놓은 도면
    • 가벼운 스케치와 인터랙티브 프로토타입 사이에 위치
    • 콘텐츠 요소의 그룹핑, 배열, 우선 순위 등을 결정하며 화면 설계 작업을 진행
    • 파워포인트, 포토샵, 일러스트, 스케치, 손그림
• 유스케이스 ^{Use Case}
  • 사용자 관점에서의 요구사항으로 시스템의 기능을 기술
  • UML에서 시스템에 제공되는 고유 기능 단위이며, 행위자를 통해 시스템이 수행하는 일의 목표
    • 시스템이 제공하는 기능, 서비스 등을 정의, 개발 과정을 계획, 시스템의 범위를 결정
    • 타원으로 표시 후 유스케이스 명을 기술
    • 유스케이스 다이어그램 작성 순서
      • 액터 식별 🠊 Use Case 식별 🠊 관계 정의 단계
• 프로토타입
  • 사용자 요구사항을 기반으로 실제 동작하는 것처럼 만든 동적인 형태의 모형
  • 손으로 직접 작성하는 페이퍼 프로토타입, 프로그램으로 작성하는 디지털 프로토타입
  • HTML/CSS, 카카오 오븐
• 목업 ^Mockup
  • 와이어프레임보다 더 실제품에 가깝도록 디자인, 사용 방법 설명, 데모 시연, 평가를 위한 정적인 모형, 최소한의 기능을 부분적으로 제공
  • 파워 목업, 발사믹 목업

     

3) 애플리케이션 설계

공통 모듈 설계

공통 모듈

• 모듈
  • 전체 프로그램의 기능 중 특정 기능을 처리하는 코드가 모여있는 덩어리
  • 하나 이상의 루틴을 포함할 수 있음
  • 자체 컴파일, 재사용 가능
• 공통 모듈
  • 여러 기능과 프로그램에서 공통적으로 사용할 수 있는 모듈 ㅣ ex. 날짜 처리를 위한 유틸리티 모듈
• 공통 모듈 원칙
  • 정확성 ^Correctness: 해당 기능이 실제 시스템을 구현 시 필요 여부를 알수 있도록 정확히 작성
  • 명확성 ^Clarity: 해당 기능을 일관되게 이해하고 한가지로 해석되도록 작성
  • 추적성 ^Traceavility: 공통 기능에 대한 요구사항 출처와 관련 시스템 등의 유기적 관계에 대한 식별이 가능하도록 작성
  • 완전성 ^Completeness: 시스템이 구현될 때 필요하고 요구되는 모든 것을 기술
  • 일관성 ^Consistency: 공통 기능들 간에 상호 충돌이 없도록 작성

• 모듈화 ^Modularity

  • 프로그램이 효율적으로 관리될 수 있도록 프로그램을 분석, 추상화
  • 특징
    • 비용과 모듈 관계: 모듈 수 증가 🠊 인터페이스 비용 증가
    • 정보 은폐: 어렵거나 변경 가능성이 있으면 다른 모듈로 부터 자신을 은폐
    • 자료 추상화: 자료구조 액세스 함수 내 자료구조 표현 내역 은폐
    • 모듈 독립성: 낮은 결합도와 높은 응집도
  • 필요성
    • 관리 측면: 프로그램의 효율적인 관리 및 성능향상
    • 개발 측면: 복잡도 감소로 프로그램 개발의 용이성, 시험, 통합 용이성 요구
    • 유지보수 측면: 프로그램 재사용을 통한 유지보수 용이성 요구
    • 성능/비용 측면: 오류 파급효과 최소화 요구, 단위 당 프로그램 개발 노력, 비용 최소화 요구
  • 유형
    • 결합도, 응집도

• 결합도 ^Coupling

  • 모듈 간 관련성을 나타냄, 관련이 적을 수록 모듈의 독립성이 높아 모듈 간 영향이 적음
  • 유형
    • 자료 결합도 ^{Data Coupling}: 모듈 간 인터페이스로 전달되는 파라미터를 통해서만 모듈 간의 상호 작용이 일어남
    • 제어 결합도 ^{Control Coupling}: 단순 처리할 대상인 값만 전달되는게 아닌, 어떻게 처리를 해야한다는 제어 요소가 함께 전달
    • 내용 결합도 ^{Content Coupling}: 다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우의 결합도
    • 공통 결합도 ^{Common Coupling}: 파라미터가 아닌 모듈 밖에 선언되어 있는 전역 변수를 참조하고, 전역 변수를 갱신
    • 스탬프 결합도 ^{Stamp Coupling}: 모듈 간의 인터페이스로 배열이나 오브젝트, 스트럭쳐 등이 전달
    • 외부 결합도 ^{External Coupling}: 모듈이 다수의 관련 기능을 가질 때, 모듈 내 구성 요소들이 그 기능을 순차적으로 수행
  • 품질

    • 결합도 높음 (낮은 품질) ㅣ

      내용 결합도 🠊 공통 결합도 🠊 외부 결합도 🠊 제어 결합도 🠊 스탬프 결합도 🠊 자료 결합도

      ㅣ 결합도 낮음 (좋은 품질)

• 응집도 ^Cohesion
  • 모듈 내부에서 구성 요소 간에 밀접한 관계를 맺고 있는 정도
  • 유형
    • 기능적 응집도 ^{Functional Cohesion}: 모듈 내부의 모든 기능이 단일한 목적을 위해 수행됨
    • 우연적 응집도 ^{Coincidental Cohesion}: 연관된 기능보다는 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리하는 경우
    • 순차적 응집도 ^{Sequential Cohesion}: 모듈 내에서 한 활동으로부터 나온 출력값을 다른 활동이 사용할 경우
    • 통신적 응집도 ^{Communication Cohesion}: 동일한 입출력을 사용하여 다른 기능을 수행하는 활동들이 모임
    • 절차적 응집도 ^{Procedural Cohesion}: 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요수들이 그 기능을 순차적으로 수행
  • 응집도와 품질
    • 기능적 응집도가 가장 높고, 우연적 응집도가 가장 낮음

    • 응집도 낮음 (나쁜 품질) ㅣ

      우연적 응집도 🠊 논리적 🠊 시간적 🠊 절차적 🠊 통신적 🠊 순차적 🠊 기능적 응집도

      ㅣ 응집도 높음 (좋은 품질)

     

소프트웨어 아키텍처

• 소프트웨어의 사전 작업을 통해 구성요소와의 관계를 정의한 시스템 구조
• 소프트웨어 요소 간의 관계 정보를 가짐
• 하나 이상의 아키텍쳐 요소와 한 가지 이상의 연관 관계로 구성
• 시스템의 공통성을 추상화 시켜 다양한 행동, 개념, 패턴, 접근 방법, 결과 등을 나타냄

• 외부에 드러나는 시스템 요소의 행위는 다른 시스템 요소와의 상호 작용 방법을 제시

• 네트워크 소프트웨어 아키텍처에 영향을 미치는 요인
  • 이해 당사자: 고객, 사용자, 개발자, 프로젝트 관리자 등 각자 시스템에 대한 다양한 요구사항을 제시하는 사람/조직
  • 개발 조직: 개발 조직의 특성이나 구조, 개발자 숙련도, 개발 일정 등의 요인은 아키텍쳐에 큰 영향을 줌
  • 기술적 환경: 아키텍처를 수립하는 단계에서 당시의 기술적 환경은 아키텍트 기술/경험에 영향을 줌
  • 배경과 경험: 아키텍트의 교육과 연습, 자주 사용되느 ㄴ아키텍처 패턴, 시스템에 적용해본 경험
• 소프트웨어 아키텍처 4+1 View Model
  • 4는 논리 뷰, 프로세스 뷰, 구현 뷰, 배포/배치 뷰
    • 논리 뷰 (최종 소비자)
      • 시스템이 최종 사용자를 위해 해야만 하는 시스템의 기능적인 요구사항, 설계 모델의 추상화, 주요 설계 패키지와 서브시스템/클래스 식별
    • 프로세스 뷰 (시스템 통합자)
      • 런타임 시의 시스템이 동시적인 면, 태스크나 스레드, 프로세스와 이들 사이의 상호작용 관계
    • 구현 뷰 (프로그래머)
      • 개발 환경 안에서 정적인 소프트웨어 모듈, 개발자 관점에서 소프트웨어의 구현과 관리적인 측면을 컴포넌트 다이어그램으로 표현
    • 배포 뷰 (시스템 엔지니어)
      • 소프트웨어가 하드웨어와 통신 요소에 할당된 내용, 가용성, 신뢰성, 성능, 확장성 등의 시스템의 비기능적인 요구사항 고려
      • 소프트웨어 아키텍처 구조에서 할당 뷰타입 중 배포 스타일에 속함, 물리적인 뷰
  • 1은 유스케이스 뷰
    • 유스케이스 뷰 (사용자 기능)

     

소프트웨어 생명주기 ^{Software Life Cycle}

• 소프트웨어 제품의 형성 부터 운용, 유지 보수에 이르기 까지 소프트웨어 생명주기를 표현하는 형태의 전 과정
• 일반적으로 소프트웨어 아키텍처 작업은 애자일 또는 반복 점진적인 생명주기를 적용해야함
• 폭포수 모델 ^{Waterfall Model}
  • 소프트웨어 개발을 단계적으로 수행하는 방법, 각 단계별 요구 결과물 문서화, 필요시 이전 단계로 되돌아갈 수 있음
  • 가장 오래된 방법, 다양한 적용 사례, 전체 과정에 대한 이해가 쉬움, 문서/산출물 관리가 쉬움, 두개 이상의 작업을 병행 수행 불가능
  • 불명확한 요구사항 발생 시 부적합, 고전적 생명 주기 모형
• 나선형 모델 ^{Spiral Model}
  • 소프트웨어 개발 시 위험 최소화를 위해 점진적으로 개발하는 모형, 시제품화 모델을 이용한 위험요소 확인/평가
  • 목표 설정 🠊 위험분석 🠊 구현 🠊 테스트 🠊 고객평가 및 다음단계 수립
  • 실현 불가능 및 어려운 위험 해결 시 적합
  • 긴 프로젝트 기간, 반복 단계가 길어질수록 관리가 어려움

     

객체지향 설계

객체지향 ^OOP

• 프로그래밍에서 필요한 데이터를 추상화하여 상태와 행위를 가진 객체를 만들고, 그 객체들 간의 유기적인 상호작용을 통해 로직을 구성
• 구성요소
  • 클래스 ^Class: 공통 집단에 속하는 속성 (변수)와 행위 (메소드)를 정의한 것, 기본적인 사용자 정의 데이터형
  • 객체 ^Object: 클래스의 인스턴스, 자신의 고유 속성을 가지며 클래스에서 정의한 행위를 수행
  • 메서드 ^Method: 클래스로부터 생성된 객체를 사용하는 방법, 객체의 속성을 조작하는 데 사용
  • 속성 ^Property: 한 클래스 내에 속한 객체들이 지니고 있는 데이터 값들을 단위별로 정의
• 기법
  • 캡슐화: 외부로부터의 객체 데이터에 직접적인 접근을 막고, 오직 함수를 통해서만 조작이 가능케함
  • 추상화: 객체들이 가진 공통의 특성들을 파악하여 불필요한 특성들을 제거하는 과정
  • 다형성: 상속을 받은 기능을 변경하거나 확장하는 기법, 오버라이딩과 오버로딩
  • 상속성: 부모클래스가 지닌 속성 (프로퍼티, 메서드)를 자식 클래스가 물려 받아 재사용하는 기법
• OOP 설계 5원칙 (SOLID)
  • 단일 책임의 원칙 ^{Single Responsibility Principle}
    • 하나의 클래스는 하나의 목적을 위해 생성, 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는데 집중
  • 개방폐쇄의 원칙 ^{Open Close Principle}
    • 소프트웨어 엔티티 (패키지, 클래스, 함수, 모듈) 는 확장에 대해서는 개방되어야 하지만 변경에 대해서는 폐쇄
  • 리스코브 치환의 원칙 ^{The Liskov Substitution}
    • 자식 클래스 (서브 타입)은 언제나 자신의 부모 클래스 (기반 타입)을 대체할 수 있어야 함
  • 인터페이스 분리의 원칙 ^{Interface Segregation Principle}
    • 클라이언트는 자신이 사용하지 않는 메소드에 의존 관계를 맺으면 안됨
  • 의존성 역전의 원칙 ^{Dependency Inversion Principle}
    • 실제 사용 관계는 불변, 고차원 모듈은 저차원 모듈에 의존하면 안됨, 각각 다른 추상화된 것에 의존해야 함
    • 추상화된 것은 구체적인 것에 의존하면 안됨, 구체적인 것이 추상화된 것에 의존해야 함

     

디자인 패턴

• 소프트웨어를 설계할 때 특정 맥락에서 반복적으로 나타나는 문제점들에 대해 재 발생 시 참조할 수 있는 해결방안 제시
• 구성 요소
  • 콘텍스트 ^Context: 패턴이 적용될 수 있는 상황
  • 문제 ^Problem: 해결될 필요가 있는 여러 디자인 이슈를 기술
  • 해결 ^Solution: 문제를 해결하도록 설계를 구성하는 요소들과 그 관계, 책임, 협력 관계 기술
  • 결과 ^Result: 패턴을 적용하여 얻은 결과 및 장단점 기술
• 생성 ^Creational 패턴: 객체 인스턴스 생성에 관여
  • 추상 팩토리 ^{Abstract Factory}: 여러개의 Concrete Product를 추상화
  • 빌더 ^Builder: 생성과 표기를 분리해 복잡한 객체 생성
  • 팩토리 메서드 ^{Factory Method}: 서브 클래스에 의해 인스턴스를 결정하고 책임을 위임하는 패턴
  • 프로토타입 ^Prototype: 원본 객체를 복제함으로써 객체를 생성
  • 싱글턴 ^Singleton: 한 클래스에 한 객체만 인스턴스를 보장
• 구조 ^Structural 패턴: 클래스나 객체를 조합해 더 큰 구조를 만드는 패턴
  • 어댑터 ^Adapter: 인터페이스가 호환되지 않는 클래스들을 함께 사용할 수 있도록 타 클래스의 인터페이스를 변환
  • 브리지 ^Bridge: 클래스 계층과 구현의 클래스 계층을 연결, 구현부에서 추상 계층을 분리하여 독립적으로 변형할 수 있도록 도움
  • 컴퍼지트 ^Composite: 사용자가 단일 객체와 복합 객체 모두 동일하게 구분없이 다룸
  • 데코레이터 ^Decorator: 기존 구현 클래스에 필요 기능을 능동적으로 확장
  • 퍼사드 ^Facade: 복잡한 클래스 관계나 사용방법을 편리하게 사용하게끔 단순 인터페이스 제공
  • 플라이 웨이트 ^Flyweight: 인스턴스가 동일한 것은 가능한 공유하여 객체 생성을 줄임 🠊 메모리 사용량 감소
  • 프록시 ^Proxy: 접근이 어려운 객체와 이어지는 인터페이스의 역할
• 행위 ^Behavioral 패턴: 객체나 클래스 사이의 알고리즘 및 책임 분배 관련
  • 책임 연쇄 ^{Chain of Responsibility}: 한 요청에 대한 처리가 한 객체가 아닌 여러 객체에서 이루어짐, 객체들 간의 결합도를 없애기 위함
  • 커맨드 ^Command: 요청 자체를 캡슐화하여 파라미터로 넘기는 패턴
  • 이터레이터 ^Iterator: 객체를 모아 놓은 다양한 자료구조에 들어있는 모든 항목에 접근 가능
  • 미디에이터 ^Mediator: 객체 사이에 상호작용이 필요할 때, 상호 작용을 제어하고 조화를 이루는 역할을 부여
  • 메멘토 ^Memento: 객체의 상태를 기억 후 다시 복구
  • 옵서버 ^Observer: 데이터 변경이 필요할 때 상대 클래스나 객체에 의존하지 않으면서 데이터 변경을 통보
  • 상태 ^State: 객체에 따른 다양한 동작을 객체화
  • 스트래티지 ^Strategy: 동일한 행동을 캡슐화하여 다르게 처리할 수 있는 패턴
  • 템플릿 메서드 ^{Template Method}: 부모 클래스에서 정형화한 처리 과정을 정의, 자식 클래스에서 세부 처리를 구현하는 구조
  • 비지터 ^Visitor: 로직을 객체 구조에서 분리시키는 패턴, 비슷한 종류의 객체 그룹에서 작업을 수행할 때 주로 사용

     

4) 인터페이스 설계

인터페이스 요구사항 확인

내/외부 인터페이스 요구사항

• 시스템 인터페이스 요구사항
  • 서로 독립적인 시스템이 연동을 통해 서로 상호작용하기 위한 접속 방법 및 규칙
  • 네트워크로 조직 내/외부에 존재하는 시스템 간의 접속을 통해 업무를 수행하기 위해서는 시스템 인터페이스 설계 및 개발이 필수
  • 구성
    • 인터페이스 이름, 연계 대상 시스템, 연계 범위 및 내용, 연계 방식, 송신 데이터, 인터페이스 주기, 기타 고려 사항 명시
    • 내/외부 인터페이스 대상 시스템 및 기관과 시스템 연동 방안 사전 협의 필요
  • 분류
    • 기능적 요구사항: 수행될 기능과 관련된 입/출력 및 처리과정, 목표 제품 구현을 위하여 소프트웨어가 가져야할 기능적 속성
    • 비기능적 요구사항: 제품의 품질 기준을 만족시키기 위하여 소프트웨어가 가져야하는 성능
      • 제품 요구사항: 사용성 요구사항, 효율성 요구사항 (성능, 공간, 신뢰성), 이식성 요구사항
      • 조직 요구사항: 배표 요구사항, 구현 요구사항, 표준 요구사항
      • 외부 요구사항: 상호운용성 요구사항, 물리적 요구사항, 법적 요구사항 (사생활, 안정성)
  • 분석
    • 요구사항 정의 단계에서 정의한 기능과 비기능 인터페이스 요구사항을 자세히 이해하고, 분류 및 조직화 하여 요구사항 명세를 구체화함

     

인터페이스 요구사항 검증 ^{Requirements Verification}

• 사용자의 요구가 요구사항 명세서에 올바르게 기술되었는지 검토하고 베이스라인을 설정

1. 요구사항 검토 계획 수립
   • 품질 관리자 또는 프로젝트 관리자와 같이 품질 관리 담당자가 요구사항 검토 계획 수립
2. 요구사항 명세서 검토 및 오류 수정
   • 요구사항 검토 계획 수립 시 선정한 검토 방법 및 검토 기준에 따라 요구사항 명세서 검토/피드백
3. 요구사항 베이스라인 설정
   • 요구사항을 공식적으로 승인하고 SW 설계와 구현이 가능하도록 요구사항 명세서의 베이스라인을 설정

• 방법
  • 요구사항 검토 ^{Requirements Review}: 명세서를 수작업으로 분석하여 명세서 오류, 표준 준수 여부 등을 검토
    • 동료 검토 ^{Peer Review}: 명세서 작성자가 요구사항 명세서를 설명하고 이해 관계자들이 결함을 발견하는 형태
    • 워크 스루 ^{Walk Through}: 일정한 운영 방법에 따라 여러 시점에 여러 목적으로 실시
    • 인스펙션 ^Inspection: 표준이나 명세서에 대한 편차 및 에러를 포함한 결함을 발견하고 식별하기 위해 작업 산출물에 대해 수행함
  • 프로토타이밍 ^Prototyping: 시연을 통해 최종 사용자나 고객을 대상으로 시스템을 경험하고 요구사항을 확인
  • 테스트 설계: 테스트 케이스를 생성하여 현실적으로 테스트 가능 여부를 검토
  • CASE ^{Computer Aided Software Engineering} 도구 활용: 요구사항 변경 사항 추적 분석 및 관리, 표준 준수 여부 확인
• 요구사항 품질 평가 항목
  • 완전성

    • 기능 완전성 측정 방법

      X = (도출된 기능 요구사항의 수) / (전체 사용자 기능 요구사항의 수)

    • 품질 완전성 측정 방법

      X = (도출된 비기능 요구사항의 수) / (전체 사용자 비기능 요구사항의 수)

  • 정확성

    • 기능 정확성 측정 방법

      X = (논리적으로 정확하게 기술한 기능 요구사항의 수) / (도출된 세부 기능 요구사항의 수)

    • 품질 정확성 측정 방법

      X = (논리적으로 정확하게 기술한 비기능 요구사항의 수) / (도출된 세부 비기능 요구사항의 수)

  • 일관성

    • 요구사항 일관성 측정 방법

      X = 1 - (연관된 요구사항 간 충돌 건수) / (도출된 요구사항 내 연관 건수)

  • 검증 가능성, 수정 용이성, 추적 가능성, 개발 후 이용성

     

인터페이스 대상 식별

인터페이스 시스템

• 연계 시스템: 시스템 인터페이스를 구성하는 시스템은 송신 시스템, 수신 시스템, 연계 방식에 따라 중계 서버로 구성
  • 송신 시스템: 연계할 데이터를 DB와 애플리케이션으로 연계 테이블 및 파일 형태로 생성/송신/발송
  • 수신 시스템: 수신한 연계 테이블 또는 파일을 데이터 형식에 맞게 변환하여 DB에 저장/제공
  • 중계 서버: 송신 시스템과 수신 시스템 사이세서 데이터를 송수신 및 모니터링
    • 중간 매개체 없이 송신 시스템과 수신 시스템이 직접 연계하는 방식과 연계 솔루션과 같이 중간 매개체를 활용하여 연계하는 방식으로 나뉨
• 연계 시스템 분류 체계와 식별 정보
  • 시스템 분류 체계: 기업 내부에서 사용하는 시스템 분류 체계를 기반으로 대내외 인터페이스 시스템의 식별자를 정의
    • 상위 시스템과 하위 시스템으로 구분
    • 시스템 수준을 구분할 필요가 없을 경우 업무 분류 체계상의 대분류를 기준으로 시스템을 식별 후 업무 대분류명을 시스템으로 사용
  • 연계 시스템 식별 정보: 대내외 연계를 위한 송신 시스템과 수신 시스템에 대한 상세 식별 정보가 필요
    • 대내외 구분 정보, 기관명, 시스템 ID, 한글명, 영문명, 시스템 설명, 시스템 위치 (노드 정보), 네트워크 특성, 전용 회선 정보, IP/URL, Port, Login 정보, DB 정보, 담당자 정보

     

송수신 데이터 식별

• 식별 대상 데이터
  • 인터페이스 표준 항목 (공통 항목): 대내외 연계의 수행을 위해 필요한 표준 송수신 메세지 길이, 시스템 정보, 전송 관리에 필요한 공통 정보
    • 시스템 공통부: 시스템 간 연동 시 필요 공통 정보 (인터페이스 ID와 전송 시스템 정보, 서비스 코드 정보, 응답 결과, 장애 정보)
    • 거래 공통부: 연동 처리시 필요한 직원/승인자 정보, 기기 정보, 매체 정보, 테스트 정보
  • 송/수신 데이터 항목 (개별 항목): 송/수신 시스템이 업무를 수행할 때 사용하는 데이터
    • 인터페이스 연계 데이터 항목과 매핑 정의, SQL문 설계
  • 공통 코드
    • 시스템에서 공통으로 사용하는 코드
    • 연계 시스템 또는 연계 소프트웨어에서 사용하는 상태, 오류 코드와 같은 항목에 대한 코드값, 코드명, 코드 성명

     

EAI ^{Enterprise Application Integration}

• 기업에서 운용하는 서로 다른 응용 소프트웨어를 네트워크 프로토콜, 운영체제와 상관없이 비즈니스 프로세스 차원에서 통합하는 전사적 애플리케이션 통합 솔루션
• 데이터 전송 모델
  • Hub & Spoke: 애플리케이션 사이에 중앙 집중식 미들웨어 (Hub) 를 구성
    • 모든 데이터 전송 보장, 확장/유지보수 용이, 허브 장애시 전체 영향
  • Message Bus: 애플리케이션 사이 미들웨어를 두어 처리
    • 뛰어난 확장성, 대용량 처리
  • Point to Point: 미들웨어를 두지 않고 각 애플리케이션 간 Point to Point 형태로 연결
    • 솔루션 구매 없이 통합, 상대적으로 저렴함, 변경/재사용이 어려움
  • Hybrid: 그룹 Hub & Spoke 방식에 그룹 간 메시징 버스 방식을 사용
    • 표준 통합 기술, 데이터 병목 현상 최소화

     

ESB ^{Enterprise Service Bus}

• SOA ^{Service Oriented Architecture}를 지원하는 서비스와 애플리케이션 컴포넌트 간의 연결을 지원하는 미들웨어 플랫폼
• 분산된 서비스 컴포넌트를 쉽게 통합 연동 가능, 신뢰성있는 메시지 통신
• 특징
  • 다양한 시스템과 연동을 위한 멀티 프로토콜 지원, 느슨한 결합
  • 서비스를 조립하는 BPM 지원, 이벤트 지향적, 표준 지향적, 플랫폼 독립적

     

EAI vs ESB

• EAI
  • Application 통합, 벤더 종속적 기술, 기업 내부의 이기종 응용 모듈간 통합, 시스템 사이의 연계 중심
  • 어댑터, 브로커, 메시지 큐, 기업 내부 통합 범위
• ESB
  • Process 통합, 표준 기술 (XML), 기업 간의 서비스 교환을 위해 표준 API로 통합, 서비스 중심으로 프로세스 진행
  • 웹서비스, 지능형 라우터, 포맷변화, 개방형 표준, 기업 내/외부 통합 범위

     

인터페이스 상계 설계

내/외부 송수신

• 연계 방식
  • 직접 연계 방식: 중계 서버나 솔루션 없이 송신 시스템과 수신 시스템이 직접 인터페이스 하는 방식
    • 장점: 연계 처리속도가 빠르고 구현이 단순, 개발 비용과 기간이 짧음
    • 단점: 송신 시스템과 수신 시스템 간의 높은 결합도로 시스템 변경에 민감, 암/복호화 처리와 비즈니스 로직 구현을 인터페이스 별로 작성해야함, 전사 시스템 인터페이스에 대한 통합 환경 구축이 어려움
  • 간접 연계 방식: 연계 솔루션에서 제공하는 송수신 엔진과 어댑터를 활용하여 인터페이스 하는 방식
    • 장점: 다양한 환경을 갖는 시스템들을 연계 가능, 인터페이스 변경 시 유연한 대처 가능, 보안 및 업무 처리 로직 반영에 용이
    • 단점: 인터페이스 아키텍쳐와 연계 절차가 복잡, 연계 서버로 인한 성능 저하, 긴 개발 및 테스트 기간
• 연계 기술
  • DB Link: DB에서 제공
  • DB Connection: 수신 시스템의 WAS에서 송신 시스템 DB로 연결하는 DB 커넥션 풀을 생성하고 연계 프로그램에서 해당 커넥션 풀 명을 이용
  • API/OpenAPI: 송신 시스템의 DB에서 데이터를 읽어 제공하는 애플리케이션 프로그래밍 인터페이스 프로그램
  • JDBC: 수신 시스템의 프로그램에서 JDBC 드라이버를 이용하여 송신 시스템 DB와 연결
  • Hyper Link: 웹 애플리케이션에서 하이퍼링크를 이용
  • Socket: 서버는 통신을 위한 소켓을 생성하여 포트를 할당하고 클라이언트의 통신 요청 시 연결/통신
  • Web Service: 웹 서비스에서 WSDL, UDDI, SOAP 프로토콜을 이용하여 연계
• 인터페이스 통신 유형
  • 실시간
    • 단방향 ^Notify: 데이터를 이용하고자하는 시스템에서 거래를 요청, 실시간 File, 실시간 DB 연계
    • 동기 ^Sync: 데이터를 이용하고자 하는 시스템에서 거래 요청을 하고 응답이 올 때 까지 대기 (Request-Reply)
      • 응답을 바로 처리해야 하거나 거래량이 적고 상대 시스템의 응답 속도가 빠를 경우 사용
      • 필수 작성 항목 ㅣ 인터페이스 ID, 인터페이스명, 처리 유형, 통신 유형, 연계 주기, 최대 처리 횟수, 데이터 크기, 인터페이스 주기, 송수신 시스템 정보, Input 연계 데이터 명세, Ouput 연계 데이터 명세
    • 비동기 ^Async: 데이터를 이용하고자 하는 시스템에서 거래를 요청하는 서비스와 응답을 받아 처리하는 서비스가 분리
      • 거래량이 많거나 데이터를 전송하는 시스템의 처리가 오래 걸리는 업무에 사용
      • 필수 작성항목 ㅣ 인터페이스 ID, 인터페이스명, 처리 유형, 통신 유형, 연계 주기, 최대 처리 횟수, 데이터 크기, 인터페이스 주기, 송수신 시스템 정보, Input 연계 데이터 명세
    • 지연 처리 ^Deferred: 순차 처리 및 지연 처리가 필요한 업무에 사용
  • 배치
    • DB/File 거래: 정해진 시간에 수행
      • 필수 작성 항목 ㅣ 인터페이스 ID, 인터페이스명, 처리 유형, 통신 유형, 연계 주기, 최대 처리 횟수, 데이터 크기, 인터페이스 주기, 송수신 시스템 정보, Input 연계 데이터 명세

     

오류 처리 방안 명세화

• 인터페이스 오류 유형
  • 연계 서버: 연계 서버의 실행 여부, 송수신, 전송 형식 변환, 연계 서버 다운, 송수신 시스템 접속 오류
  • 송신 시스템 연계 프로그램: 연계 데이터 추출을 위한 DB 접근 권한 오류, 데이터 변환 시 예외상황 미처리, 미등록 코드로 인한 코드 매핑 오류
  • 연계 데이터: 연계 데이터값이 유효하지 않음으로 인해 발생하는 오류, 일자 데이터값에 유효하지 않는 일자 값 입력
  • 수신 시스템 연계 프로그램: 수신 받은 데이터를 운영 DB에 반영하는 과정에서 접근 권한 문제, 데이터 변환 시 예외 상황 미처리, 데이터 등록/갱신 오류
• 인터페이스 오류 처리 절차

1. 장애 및 오류 확인 절차
   • 연계 서버와 송수신 시스템의 로그 파일에 오류 코드와 에러 발생에 대한 상세 내용 기록
   • 운영자는 장애 및 오류 현황 모니터링 화면을 통해 오류 원인 및 발생 현황 분석
2. 장애 및 오류 처리 절차
   • 분석 결과에 따른 대응 조치, 장애 및 오류로 인한 미전송과 운영 DB에 반영되지 않은 연계 데이터의 재작업 여부 결정
3. 송수신 시스템의 접속 오류인 경우 담당자를 통해 해결 후 재전송
4. 장애 및 오류 현황 모니터링
   • 송수신 시스템의 연계 응용 프로그램에서 기록하는 장에 로그 테이블을 확인하기 위한 모니터링 화면 구현

• 인터페이스 오류 코드
  • 오류 코드: 오류 발생자와 유형, 일련 번호를 포함한 오류 코드 명명 규칙 정의 후 인터페이스 표준화 지침 문서로 공유
  • 오류 내용: 데이터 에러, 네트워크 에러, 암/복호화 에러 등 오류 발생 원인을 포함 기술

     

인터페이스 설계

• 인터페이스 설계는 인터페이스 정의서와 목록으로 구성

• 인터페이스 정의서
  • 인터페이스 명세는 데이터 송신 시스템과 수신 시스템 간의 데이터 저장소와 속성을 포함
  • 연계 방식에 따라 명세 항목이 다름
  • 주요 항목
    • 인터페이스 ID: 인터페이스 구분을 위한 식별자, 명명 표준에 맞게 부여
    • 최대 처리 횟수: 단위 시간당 처리 될 수 있는 해당 인터페이스 최대 수행 건수
    • 데이터 크기 (평균/최대): 해당 인터페이스 1회 처리 시 소요되는 데이터의 평균 크기와 최대 그키
    • 시스템 정보 (송수신 시스템 각각 작성) ㅣ 시스템명, 업무, 서비스명/프로그램 ID, 연계 방식, 담당자 연락처
    • 데이터 정보 (송수신 시스템 각각 작성) ㅣ 번호, 필드, 식별자 여부, 데이터 타입, 데이터 크기, NULL 허용 여부, 설명, 조건, 매핑 규칙, Total Length, 추출 조건/SQL
• 인터페이스 목록
  • 인터페이스 ID, 인터페이스명, 송신 시스템, 수신 시스템, 대내외 구분, 연계 방식, 통신 유형, 처리 유형, 주기, 데이터 형식, 관련 요구사항 ID
• 인터페이스 설계 작성 순서

1. 인터페이스 설계 가이드 및 인터페이스 설계서 작성 양식 준비
2. 인터페이스 기본 정보 작성
   • 내부 시스템 간 인터페이스일 경우 기관 정보는 당사로 기재
   • 인터페이스가 기업 내부 시스템 사이에서 발생할 경우 대내, 외부 기업 시스템과 연계하여 발생할 경위 대외로 구분
3. 송수신 시스템의 정보 작성
   • 인터페이스 목록 정보를 토대로 기본 정보 작성, 최대 처리 횟수, 데이터 크기 등의 추가 정보 작성
   • 송수신 시스템 각각에 대한 시스템 정보 확인 및 작성
4. 프로그램 명세서 확인 후 보완 및 수성
   • 인터페이스 구현에 필요한 정보 정의 확인 ㅣ 서비스/프로그램 ID, 서비스/프로그램 명, 관련 인터페이스 정보, 입출력 파라미터와 처리 내용
5. 송수신 데이터 항목 상세 작성
   • 송수신 데이터와 필드명, 식별자 여부 정의
   • 데이터 타입, 길이, 필수 입력 여부 (Not Null), 필드 설명, 공통 코드 여부, 암호화 적용 대상 칼럼
6. 코드 매핑 규칙 작성, 코드 매핑 테이블 표시
7. 인터페이스 설계 검토 및 보완

     

미들 웨어

• OS와 SW 애플리케이션 사이에 위치하며, SW 애플리케이션에게 OS가 제공하는 서비스를 추가하거나 확장하여 제공하는 컴퓨터 소트프웨어

• 이점
  • 부하 분산, 표준화된 인터페이스 제공, 다양한 환경 지원, 체계가 다른 업무와 상호 연동 가능, 분산 업무 동시 처리로 자료의 일관성 유지
• 종류
  • 원격 프로시저 호출 ^{RPC, Remote Procedure Call}: 클라이언트가 원격에서 동작하는 프로시저를 호출하는 시스템
  • 메시지 지향 미들웨어 ^{MOM, Message Oriented Middleware}: 클라이언트가 생성한 메시지는 저장소에 요청할 때 저장, 비동기식 미들웨어
  • ORB ^{Object Request Broker}: 객체지향 시스템에서 객체 및 서비스를 요청하고 전송 할 수 있도록 지원
  • DB 접속 미들웨어: 애플리케이션과 데이터베이스 서버를 연결
  • TP 모니터 ^{Transaction Processing Monitor}: 분산 시스템의 애플리케이션을 지원, 사용자가 많고 안정적이며 빠른 처리가 필요한 프로그램 개발에 활용
  • 웹 애플리케이션 서버: 웹 환경을 구현하기 위해 지원
  • 엔터프라이즈 서비스 버스 ^{Enterprise Service Bus}: 메시지 기반으로 느슨한 결합 형태의 표준 인터페이스 통신 지원