Post

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

📕 자격증 정보처리기사 필기의 "Chapter 1. 소프트웨어 설계" 내용을 정리했습니다.

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

KEYWORDS
정보처리기사, 소프트웨어 설계, 요구사항 확인, 화면 설계, 애플리케이션 설계, 인터페이스 설계


     

Introduction

  • 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 Pattern): 객체 인스턴스 생성에 관여
    • 추상 팩토리 Abstract Factory ㅣ 여러개의 Concrete Product를 추상화
    • 빌더 Builder ㅣ 생성과 표기를 분리해 복잡한 객체 생성
    • 팩토리 메서드 Factory Method ㅣ 서브 클래스에 의해 인스턴스를 결정하고 책임을 위임하는 패턴
    • 프로토타입 Prototype ㅣ 원본 객체를 복제함으로써 객체를 생성
    • 싱글턴 Singleton ㅣ 한 클래스에 한 객체만 인스턴스를 보장
  • 구조 패턴(Structural Pattern): 클래스나 객체를 조합해 더 큰 구조를 만드는 패턴
    • 어댑터(Adapter) ㅣ 인터페이스가 호환되지 않는 클래스들을 함께 사용할 수 있도록 타 클래스의 인터페이스를 변환
    • 브리지(Bridge) ㅣ 클래스 계층과 구현의 클래스 계층을 연결, 구현부에서 추상 계층을 분리하여 독립적으로 변형할 수 있도록 도움
    • 컴퍼지트(Composite) ㅣ 사용자가 단일 객체와 복합 객체 모두 동일하게 구분없이 다룸
    • 데코레이터(Decorator) ㅣ 기존 구현 클래스에 필요 기능을 능동적으로 확장
    • 퍼사드(Facade) ㅣ 복잡한 클래스 관계나 사용방법을 편리하게 사용하게끔 단순 인터페이스 제공
    • 플라이 웨이트(Flyweight) ㅣ 인스턴스가 동일한 것은 가능한 공유하여 객체 생성을 줄임 🠊 메모리 사용량 감소
    • 프록시(Proxy) ㅣ 접근이 어려운 객체와 이어지는 인터페이스의 역할
  • 행위 패턴(Behavioral Pattern): 객체나 클래스 사이의 알고리즘 및 책임 분배 관련
    • 책임 연쇄(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) ㅣ 메시지 기반으로 느슨한 결합 형태의 표준 인터페이스 통신 지원
This post is licensed under CC BY 4.0 by the author.