[ 소프트웨어 설계 ]

1장. 요구사항 확인

001 소프트웨어 생명 주기 (Software Life Cycle)

• 소프트웨어 개발 방법론의 바탕이 되는 것.
• 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것.
• 소프트웨어 개발 단계와 각 단계별 주요 활동, 그리고 활동의 결과에 대한 산출물로 표현함.
• 소프트웨어 생명 주기 모형에는 폭포수 모형, 프로토타입 모형, 나선형 모형, 애자일 모형 등.

폭포수 모형(Waterfall Model)

• 한 단계가 완전히 끝나야만 다음 단계로 넘어가는 개발 방법론
• 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론
• 고전적 생명 주기 모형
• 하향식 접근방법을 제공
• 낮은 기술적 위험과 유사 프로젝트 경험이 있는 경우 요구사항의 명확한 정의가 가능
• 계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 유지보수

프로토타입 모형(Prototype Model, 원형 모형)

• 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본(시제)품(Prototype)을 만들어 최종 결과물을 예측하는 모형
• 시스템은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발함.

나선형 모형(Spiral Model, 점진적 모형)

• 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
• 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것. 점진적 모형이라고도 함.
• 위험을 관리하고 최소화하는 것을 목적으로 함.
• 대규모 시스템 개발에 적합
• 계획 및 정의 -> 위험 분석 -> 개발 -> 고객 평가

애자일 모형(Agile Model)

• 애자일은 '민첩한', '기민한' 이라는 의미
• 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발과정을 진행함.
• 애자일 모형은 어느 특정 개발 방법론이 아니라 좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통에 초점을 맞춘 방법론을 통칭함.
• 애자일 모형은 스프린트(Sprint) 또는 이터레이션(Iteration)이라고 불리는 짧은 개발 주기를 반복하며, 반복되는 주기마다 만들어지는 결과물에 대한 고객의 평가와 요구를 적극 수용함.
• 소규모 프로젝트, 고도로 숙련된 개발자, 급변하는 요구사항에 적합함.
• 애자일 모형을 기반으로 하는 소프트웨어 개발 모형에는 스크럼(Scrum), XP(eXtreme Programming), 칸반(Kanban), Lean, 크리스탈(Crystal), ASD(Adaptive Software Development), FDD(Feature Driven Development), DSDM(Dynamic System Development Method), DAD(Disciplined Agile Delivery) 등이 있음.

002 스크럼(Scrum) 기법

• 팀의 중요성을 강조. 팀이 중심이 되어 개발의 효율성을 높인다는 의미가 내포된 용어.

• 스크럼은 팀원 스스로가 스크럼 팀을 구성(self-organizing)해야 하며, 개발 작업에 관한 모든 것을 스스로 해결(cross-functional)할 수 있어야 한다.

• 스크럼 팀은 제품 책임자, 스크럼 마스터, 개발팀으로 구성.

  • 제품 책임자(PO; Product Owner)
  • 스크럼 마스터(SM; Scrum Master)
  • 개발팀(DT; Development Team)

스크럼 개발 프로세스

• 제품 백로그(Product Backlog)
  • 요구사항(User Story)을 우선순위에 따라 나열한 목록
• 스프린트 계획 회의(Sprint Planning Meeting)
• 스프린트(Sprint)
• 일일 스크럼 회의(Daily Scrum Meeting)
  • 남은 작업 시간은 소멸 차트(Burn-down Chart)에 표시함.
• 스프린트 검토 회의(Sprint Review)
• 스프린트 회고(Sprint Retrospective)

003 XP(eXtreme Programming) 기법

• XP는 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법
• XP는 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 함.
• 릴리즈의 시간을 짧게 반복하면서 고객의 요구사항 반영에 대한 가시성을 높임.
• 비교적 소규모 인원의 개발 프로젝트에 효과적
• XP의 5가지 핵심 가치: 의사소통(Communication), 단순성(Simplicity), 용기(Courage), 존중(Respect), 피드백(Feedback)

XP 개발 프로세스

• 사용자 스토리(User story)
• 릴리즈 계획 수립(Release Planning)
• 스파이크(Spike)
  • 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램
  • 처리할 문제 외의 다른 조건은 모두 무시하고 작성함.
• 이터레이션(Iteration)
• 승인 검사(Acceptance Test, 인수 테스트)
• 소규모 릴리즈(Small Release)

XP의 주요 실천 방법(Practice)

• Pair Programming(짝 프로그래밍)
• Test-Driven Development(테스트 주도 개발)
• Whole Team(전체 팀)
• Continuous Integration(계속적인 통합)
• Design Improvement(디자인 개선) 또는 Refactoring(리팩토링)
• Small Releases(소규모 릴리즈)

004 현행 시스템 파악

• 새로 개발하려는 시스템의 개발 범위를 명확히 설정하기 위해 현행 시스템의 구성과 제공 기능, 시스템 간의 전달 정보, 사용되는 기술 요소, 소프트웨어, 하드웨어, 그리고 네트워크의 구성 등을 파악.

현행 시스템 파악 절차

- 1단계 : 시스템 구성 파악 | 시스템 기능 파악 | 시스템 인터페이스 파악
- 2단계 : 아키텍처 구성 파악 | 소프트웨어 구성 파악
- 3단계 : 하드웨어 구성 파악 | 네트워크 구성 파악

시스템 구성 파악

• 현행 시스템의 구성은 조직의 주요 업무를 담당하는 기간 업무와 이를 지원하는 지원 업무로 구분하여 기술함.
• 조직 내에 있는 모든 정보시스템의 현황을 파악할 수 있도록 각 업무에 속하는 단위 업무 정보시스템들의 명칭, 주요 기능들을 명시함.

시스템 기능 파악

• 현행 시스템의 기능은 단위 업무 시스템이 현재 제공하는 기능들을 주요 기능과 하부 기능, 세부 기능으로 구분하여 계층형으로 표시함.

시스템 인터페이스 파악

• 현행 시스템의 인터페이스에는 단위 업무 시스템 간에 주고받는 데이터의 종류, 형식, 프로토콜, 연계 유형, 주기 등을 명시함.

아키텍처 구성 파악

• 현행 시스템의 아키텍처 구성은 기간 업무 수행에 어떠한 기술 요소들이 사용되는지 최상위 수준에서 계층별로 표현한 아키텍처 구성도로 작성함.

소프트웨어 구성 파악

• 소프트웨어 구성에는 단위 업무 시스템별로 업무 처리를 위해 설치되어 있는 소프트웨어들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수 등을 명시함.

하드웨어 구성 파악

• 하드웨어 구성에는 단위 업무 시스템들이 운용되는 서버의 주요 사양과 수량, 그리고 이중화의 적용 여부를 명시함.

네트워크 구성 파악

• 네트워크 구성은 업무 시스템들의 네트워크 구성을 파악할 수 있도록 서버의 위치, 서버 간의 네트워크 연결 방식을 네트워크 구성도로 작성함.

005 개발 기술 환경 파악

• 개발 기술 환경: 개발하고자 하는 소프트웨어와 관련된 운영체제(OS), 데이터베이스 관리 시스템(DBMS), 미들웨어(Middle Ware) 등을 선정할 때 고려해야 할 사항을 기술하고, 오픈 소스 사용 시 주의해야 할 내용을 제시.

운영체제(OS)

데이터베이스 관리 시스템(DBMS)

웹 애플리케이션 서버(WAS)

오픈 소스 사용에 따른 고려사항

• 라이선스의 종류, 사용자 수, 기술의 지속 가능성 등을 고려해야 함.

006 요구사항 정의

• 요구사항: 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건 등을 나타냄.

요구사항 유형

• 일반적으로 기술하는 내용에 따라 기능 요구사항과 비기능 요구사항으로 구분하며,

• 기술 관점과 대상의 범위에 따라 시스템 요구사항과 사용자 요구사항으로 나눔.

• 기능 요구사항(Functional requirements)

  • 시스템이 무엇을 하는지, 어떤 기능을 하는지에 대한 사항

• 비기능 요구사항(Non-functional requirements)

  • 시스템의 장비 구성 요구사항
  • 성능 요구사항
  • 인터페이스 요구사항
  • 데이터 요구사항
  • 테스트 요구사항
  • 보안 요구사항
  • 품질 요구사항
  • 제약사항
  • 프로젝트 관리 요구사항
  • 프로젝트 지원 요구사항

• 시스템 요구사항(System requirements)

  • 사용자 관점에서 본 시스템이 제공해야 할 요구사항

• 사용자 요구사항(User requirements)

  • 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항

요구사항 개발 프로세스

• 개발 대상에 대한 요구사항을 체계적으로 도출하고 이를 분석한 후 분석 결과를 명세서(Specification Document)에 정리한 다음 마지막으로 이를 확인 및 검증하는 일련의 구조화된 활동
• 요구사항 개발 프로세스가 진행되기 전에 개발 프로세스가 비즈니스 목적에 부합되는지, 예산은 적정한지 등에 대한 정보를 수집, 평가한 보고서를 토대로 타당성 조사(Feasibility Study)가 선행되어야 함.
• 요구사항 개발은 요구공학(Requirement Engineering)의 한 요소
• 도출(Elicitation) -> 분석(Analysis) -> 명세(Specification) -> 확인(Validation)

요구사항 도출(Requirement Elicitation, 요구사항 수집)

• 시스템, 사용자, 그리고 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항이 어디에 있는지, 어떻게 수집할 것인지를 식별하고 이해하는 과정

요구사항 분석(Requirement Analysis)

• 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정

요구사항 명세(Requirement Specification)

• 요구사항을 체계적으로 분석한 후 승인될 수 있도록 문서화하는 것.
• 시스템의 모든 동작뿐만 아니라 성능, 보안, 사용성과 같은 품질도 기술되어야 함.

요구사항 확인(Requirement Validation, 요구사항 검증)

• 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 완전하게 작성되었는지를 검토하는 활동

007 요구사항 분석 기법

• 요구사항 분석 기법: 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호한 부분을 걸러내기 위한 방법.
• 요구사항 분석 기법에는 요구사항 분류, 개념 모델링, 요구사항 할당, 요구사항 협상, 정형 분석 등

요구사항 분류(Requirement Classification)

개념 모델링(Conceptual Modeling)

• 개념 모델의 종류에는 유스케이스 다이어그램(Use Case Diagram), 데이터 흐름 모델(Data Flow Model), 상태 모델(State Model), 목표기반 모델(Goal-Based Model), 사용자 인터랙션(User Interactions), 객체 모델(Object Model), 데이터 모델(Data Model) 등.
• 모델링 표기는 주로 UML(Unified Modeling Language)을 사용.

요구사항 할당(Requirement Allocation)

요구사항 협상(Requirement Negotiation)

정형 분석(Formal Analysis)

• 정형 분석은 구문(Syntax)과 의미(Semantics)를 갖는 정형화된 언어를 이용해 요구사항을 수학적 기호로 표현한 후 이를 분석하는 과정
• 정형 분석은 요구사항 분석의 마지막 단계에서 이루어짐.
• 정형 명세(Formal Specification): 정형화된 언어를 이용해 수학적 기호로 기술하는 것

008 요구사항 확인 기법

• 요구사항 확인 기법: 요구사항 개발 과정을 거쳐 문서화된 요구사항 관련 내용을 확인하고 검증하는 방법.
• 요구사항 확인 기법에는 요구사항 검토(Requirement Reviews), 프로토타이핑(Prototyping), 모델 검증(Model Verification), 인수 테스트(Acceptance Tests) 등.

요구사항 검토(Requirement Reviews)

• 문서화된 요구사항을 훑어보면서 확인하는 것으로 가장 일반적인 요구사항 검증 방법
• 검토는 시스템 정의서(System Definition Document), 시스템 사양서(System Specification), 소프트웨어 요구사항 명세서(SRS; Software Requirements Specification Document) 등을 완성한 시점에 이루어짐.

프로토타이핑(Prototyping)

• 초기 도출된 요구사항을 토대로 프로토타입(Prototype)을 만든 후 대상 시스템의 개발이 진행되는 동안 도출되는 요구사항을 반영하면서 지속적으로 프로토타입을 재작성하는 과정

모델 검증(Model Verification)

• 요구사항 분석 단계에서 개발된 모델이 요구사항을 충족시키는지 검증하는 것
• 객체 모델의 경우 객체들 사이에 존재하는 의사소통 경로(Communication Path)를 검증(Verify)하기 위하여 정적 분석(Static Analysis)을 수행하는 것이 유용함.
  • 정적 분석은 실행을 통해서 확인하는 것이 아니라 명세서의 정확성이나 일관성 등을 확인하거나 분석 도구를 사용해 확인하는 방법. 직접 실행을 통해 확인하는 방법은 동적 분석(Dynamic Analysis)이라고 함.

인수 테스트(Acceptance Tests)

• 사용자가 실제로 사용될 환경에서 요구사항들이 모두 충족되는지 사용자 입장에서 확인하는 과정
• 인수 테스트의 종류에는 사용자 인수 테스트, 운영상의 인수 테스트, 계약 인수 테스트, 규정 인수 테스트, 알파 검사, 베타 검사가 있음.

009 UML(Unified Modeling Language)

• UML: 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어.
• UML의 구성 요소에는 사물, 관계, 다이어그램 등이 있음.

사물(Things)

• 모델을 구성하는 가장 중요한 기본 요소. 다이어그램 안에서 관계가 형성될 수 있는 대상들.
  • 구조 사물
  • 행동 사물
  • 그룹 사물
  • 주해 사물(Annotation Things): 부가적인 설명이나 제약조건 등을 표현. 노트(Note).

관계(Relationships)

• 사물과 사물 사이의 연관성을 표현한 것.

연관(Association) 관계

• 2개 이상의 사물이 서로 관련되어 있음을 표현
• 사물 사이를 실선으로 연결하여 표현. 방향성을 화살표로 표현. 양방향일 경우 화살표는 생략.
• 연관에 참여하는 객체의 개수를 의미하는 다중도(Multiplicity)를 선 위에 표기.

집합(Aggregation) 관계

• 하나의 사물이 다른 사물에 포함되어 있는 관계를 표현
• 포함하는 쪽(Whole)과 포함되는 쪽(Part)은 서로 독립적.
• 포함되는 쪽(Part)에서 포함하는 쪽(Whole)으로 속이 빈 마름모를 연결하여 표현

포함(Composition) 관계

• 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계를 표현
• 포함하는 쪽(Whole)과 포함되는 쪽(Part)은 서로 독립될 수 없고 생명주기를 함께함.
• 포함되는 쪽(Part)에서 포함하는 쪽(Whole)으로 속이 채워진 마름모를 연결하여 표현

일반화(Generalization) 관계

• 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현함.
• 보다 일반적인 개념을 상위(부모), 보다 구체적인 개념을 하위(자식)이라고 부름.
• 구체적(하위)인 사물에서 일반적(상위)인 사물 쪽으로 속이 빈 화살표를 연결하여 표현

의존(Dependency) 관계

• 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현
• 하나의 사물과 다른 사물이 소유 관계는 아니지만 사물의 변화가 다른 사물에도 영향을 미치는 관계
• 영향을 주는 사물(이용자)이 영향을 받는 사물(제공자) 쪽으로 점선 화살표를 연결하여 표현

실체화(Realization) 관계

• 사물이 할 수 있거나 해야 하는 기능(행위, 인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현
• 속이 빈 점선 화살표

다이어그램(Diagram)

• 사물과 관계를 도형으로 표현한 것
• 정적 모델링에서는 주로 구조적 다이어그램을 사용하고 동적 모델링에서는 주로 행위 다이어그램을 사용

구조적(Structural) 다이어그램의 종류

• 클래스 다이어그램(Class Diagram)
• 객체 다이어그램(Object Diagram)
• 컴포넌트 다이어그램(Component Diagram)
  • 구현 단계에서 사용되는 다이어그램
• 배치 다이어그램(Deployment Diagram)
  • 구현 단계에서 사용되는 다이어그램
• 복합체 구조 다이어그램(Composite Structure Diagram)
• 패키지 다이어그램(Package Diagram)

행위(Behavioral) 다이어그램의 종류

• 유스케이스 다이어그램(Use Case Diagram)

• 시퀀스 다이어그램(Sequence Diagram)

• 커뮤니케이션 다이어그램(Communication Diagram)

• 상태 다이어그램(State Diagram)

• 활동 다이어그램(Activity Diagram)

• 상호작용 개요 다이어그램(Interaction Overview Diagram)

• 타이밍 다이어그램(Timing Diagram)

• https://m.blog.naver.com/qhanfckwsmsd/221554139159

• https://roynus.tistory.com/1037

• https://morm.tistory.com/88

2장. 화면 설계

010 사용자 인터페이스 (UI, User Interface)

사용자 인터페이스의 세 가지 분야

• 정보 제공과 전달을 위한 물리적 제어에 관한 분야
• 콘텐츠의 상세적인 표현과 전체적인 구성에 관한 분야
• 모든 사용자가 편리하고 간편하게 사용하도록 하는 기능에 관한 분야

사용자 인터페이스의 기본 원칙

• 직관성
• 유효성
• 학습성
• 유연성

사용자 인터페이스의 설계 지침

• 사용자 중심
• 일관성
• 단순성
• 결과 예측 가능
• 가시성
• 표준화
• 접근성
• 명확성
• 오류 발생 해결

011 UI 표준 및 지침

• UI 표준: 전체 시스템에 포함된 모든 UI에 공통적으로 적용될 내용으로, 화면 구성이나 화면 이동 등이 포함됨.
• UI 지침: UI 요구사항, 구현 시 제약사항 등 UI 개발 과정에서 꼭 지켜야 할 공통의 조건을 의미.
• 웹의 3요소
  • 웹 표준(Web Standards)
  • 웹 접근성(Web Accessibility)
  • 웹 호환성(Cross Browsing)

한국형 웹 콘텐츠 접근성 지침(KWCAG; Korean Web Content Accessibility Guidelines)

• 장애인이 비장애인과 동등하게 접근할 수 있는 웹 콘텐츠의 제작 방법을 제시

내비게이션(Navigation)

• 사용자가 사이트에서 원하는 정보를 빠르게 찾을 수 있도록 안내하는 것으로 사용자가 중심이 되어야 함.
• 내비게이션 구조의 요소
  • 메뉴(단추)
  • 링크
  • 이미지 맵
  • 사이트 맵
  • 사이트 메뉴바
  • 내비게이션 바
  • 디렉터리

전자정부 웹 표준 준수 지침

• 정부기관의 홈페이지 구축 시 반영해야 할 최소한의 규약을 정의한 것.
• 모든 사람이 시스템 환경에 구애받지 않고 정부기관의 홈페이지를 이용할 수 있도록 하기 위한 것.

012 UI 설계 도구

• UI 설계 도구: 사용자의 요구사항에 맞게 UI의 화면 구조나 화면 배치 등을 설계할 때 사용하는 도구.
• UI 설계 도구로 작성된 결과물은 사용자의 요구사항이 실제 구현되었을 때 화면은 어떻게 구성되는지, 어떤 방식으로 수행되는지 등을 기획단계에서 미리 보여주기 위한 용도로 사용됨.

와이어프레임(Wireframe)

• 기획 단계의 초기에 제작하는 것.
• 페이지에 대한 개략적인 레이아웃이나 UI 요소 등에 대한 뼈대를 설계하는 단계

목업(Mockup)

• 디자인, 사용 방법 설명, 평가 등을 위해 와이어프레임보다 좀 더 실제 화면과 유사하게 만든 정적인 형태의 모형.
• 시각적으로만 구성 요소를 배치하는 것

스토리보드(Story Board)

• 와이어프레임에 콘텐츠에 대한 설명, 페이지 간 이동 흐름 등을 추가한 문서
• 디자이너와 개발자가 최종적으로 참고하는 작업 지침서
• 디스크립션(Description)을 기입함. 디스크립션은 화면에 대한 설명, 전반적인 로직, 분기처리, 예외처리 등을 작성하는 부분으로, 명확하고 세부적으로 작성해야 함.

프로토타입(Prototype)

• 와이어프레임이나 스토리보드 등에 인터랙션을 적용함으로써 실제 구현된 것처럼 테스트가 가능한 동적인 형태의 모형

유스케이스(Use Case)

• 유스케이스는 사용자 측면에서의 요구사항으로, 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술.

013 UI 요구사항 확인

• UI 요구사항 확인: 새로 개발할 시스템에 적용할 UI 관련 요구사항을 조사해서 작성하는 단계
• UI 요구사항 확인 순서: 목표 정의 -> 활동 사항 정의 -> UI 요구사항 작성

목표 정의

• 목표 정의 단계에서는 사용자들을 대상으로 인터뷰를 진행한 후 사용자들의 의견이 수렴된 비즈니스 요구사항을 정의함.
• 인터뷰 진행 시 유의사항
  • 가능하면 개별적으로 진행
  • 가능한 많이 진행하여 다양한 의견 수렴. But, 개인의 중요한 의견도 놓치지 않아야.
  • 한 시간을 넘지 않도록
  • 인터뷰 진행은 반드시 사용자 리서치를 시작하기 전에 해야 함.

활동 사항 정의

• 활동 사항 정의 단계에서는 조사한 요구사항을 토대로 앞으로 해야 할 활동 사항을 정의

UI 요구사항 작성

• UI 요구사항을 작성할 때는 여러 경로를 통해 수집된 사용자들의 요구사항을 검토하고 분석하여 UI 개발 목적에 맞게 작성해야 함.
• UI 요구사항 작성 순서: 요구사항 요소 확인 -> 정황 시나리오 작성 -> 요구사항 작성

요구사항 요소 확인

• 파악된 요구사항 요소의 종류와 각각의 표현 방식 등을 검토
• 요구사항 요소
  • 데이터 요구
  • 기능 요구
  • 제품/서비스의 품질
  • 제약 사항

정황 시나리오 작성

• 정황 시나리오는 사용자의 어떤 요구사항이 있을 때 이것을 만족하기 위해 사용자가 수행하는 과정을 이야기 형식으로 표현한 것
• 요구사항 정의에 사용되는 초기 시나리오
• 사용자 관점에서 작성

요구사항 작성

• 요구사항은 정황 시나리오를 토대로 작성

014 품질 요구사항

• 소프트웨어의 품질: 소프트웨어의 기능, 성능, 만족도 등 소프트웨어에 대한 요구사항이 얼마나 충족하는가를 나타내는 소프트웨어 특성의 총체.
• ISO/IEC 9126
  • 소프트웨어의 품질 특성과 평가를 위한 표준 지침
  • ISO/IEC 9126에서 제시한 소프트웨어의 품질 특성: 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성 *
• ISO/IEC 25010
  • 2011년 ISO/IEC 9126을 개정하여 만듬. ISO/IEC 9126에 비해 호환성과 보안성 부분이 강화됨.
  • ISO/IEC 25010에서 제시한 소프트웨어의 품질 특성: 신뢰성, 사용성, 이식성, 유지보수성, 기능 적합성, 실행 효율성, 호환성, 보완성

기능성(Functionality)

• 소프트웨어가 사용자의 요구사항을 정확하게 만족하는 기능을 제공하는지 여부
• 적절성/정합성(Suitability)
• 정밀성/정확성(Accuracy)
• 상호 운용성(Interoperability)
• 보안성(Security)
• 호환성(Compliance)

신뢰성(Reliability)

• 소프트웨어가 요구된 기능을 정확하고 일관되게 오류 없이 수행할 수 있는 정도
• 성숙성(Maturity): 결함으로 인한 고장을 피해갈 수 있는 능력
• 고장 허용성(Fault Tolerance)
• 회복성(Recoverability)

사용성(Usability)

• 사용자와 컴퓨터 사이에 발생하는 어떠한 행위에 대하여 사용자가 정확하게 이해하고 사용하며, 향후 다시 사용하고 싶은 정도
• 이해성(Understandability)
• 학습성(Learnability)
• 운용성(Operability)
• 친밀성(Attractiveness)

효율성(Efficiency)

• 사용자가 요구하는 기능을 할당된 시간 동안 한정된 자원으로 얼마나 빨리 처리할 수 있는지 정도
• 시간 효율성(Time Behaviour)
• 자원 효율성(Resource Behaviour)

유지 보수성(Maintainability)

• 환경의 변화 또는 새로운 요구사항이 발생했을 때 소프트웨어를 개선하거나 확장할 수 있는 정도
• 분석성(Analyzability)
• 변경성(Changeability)
• 안정성(Stability)
• 시험성(Testability)

이식성(Portability)

• 소프트웨어가 다른 환경에서도 얼마나 쉽게 적용할 수 있는지 정도
• 적용성(Adaptability)
• 설치성(Installability)
• 대체성(Replaceability)
• 공존성(Co-existence)

015 UI 프로토타입 제작 및 검토

• 프로토타입: 사용자 요구사항을 기반으로 실제 동작하는 것처럼 만든 동적인 형태의 모형으로, 테스트가 가능함.
• 사용자의 요구사항을 개발자가 맞게 해석했는지 검증하기 위한 것. 최대한 간단하게 만들어야.
• 최소한의 기능만을 부분적으로 제공할 수 있음. But 최종 제품의 작동 방식을 이해시키는데 필요한 기능은 반드시 포함돼야 함.
• 사용자의 요구사항이 모두 반영될 때까지 프로토타입을 계속하여 개선하고 보완해야 함.
• 실제 사용자를 대상으로 테스트

UI 프로토타입의 장단점

• 장점
  • 사용자를 설득하고, 이해시키기 쉬움.
  • 요구사항과 기능의 불일치 등으로 인한 혼선 예방
  • 사전에 오류 발견 가능
• 단점
  • 반복적인 개선 및 보완 작업 때문에 작업 시간이 증가, 자원 소모.

프로토타이핑의 종류

• 페이퍼 프로토타입(Paper Prototype)
• 디지털 프로토타입(Digital Prototype)

UI 프로토타입 계획 및 작성 시 고려 사항

UI 프로토타입 제작 단계

016 UI 설계서 작성

• UI 설계서: 사용자의 요구사항을 바탕으로 UI 설계를 구체화하여 작성하는 문서로, 상세 설계 전에 대표적인 화면들을 설계함.

UI 설계서 표지 작성

UI 설계서 개정 이력 작성

UI 요구사항 정의서 작성

시스템 구조 작성

• 시스템 구조는 UI 요구사항과 UI 프로토타입에 기초하여 전체 시스템의 구조를 설계한 것.
• 사용자의 요구사항이 어떻게 시스템에 적용되는지 알 수 있음.

사이트 맵(Site Map) 작성

• 사이트 맵은 시스템 구조를 바탕으로 사이트에 표시할 콘텐츠를 한 눈에 알아 볼 수 있도록 메뉴별로 구분하여 설계한 것.

프로세스(Process) 정의서 작성

• 프로세스 정의서는 사용자 관점에서 사용자가 요구하는 프로세스들을 작업 진행 순서에 맞춰 정리한 것.
• UI의 전체적인 흐름을 파악할 수 있음.

화면 설계

017 유용성 평가

• 유용성(Usability): 사용자가 시스템을 통해 원하는 목표를 얼마나 효과적으로 달성할 수 있는가에 대한 척도
• 유용성 평가: 사용자 측면에서 복잡한 시스템을 얼마나 편리하게 사용할 수 있는지를 평가하는 것으로, 시스템의 문제점을 찾아내고 개선 방향을 제시하기 위한 조사 과정.
• 사용자 모형과 개발자 모형 간의 차이가 발생하는 원인
  • 실행 차: 사용자가 원하는 목적과 실행 기능이 다르기 때문에 발생함.
  • 평가 차: 사용자가 원하는 목적과 실행 결과가 다르기 때문에 발생함.

실행 차를 줄이기 위한 UI 설계 원리 검토

1. 사용 의도 파악
2. 행위 순서 규정
3. 행위의 순서대로 실행

평가 차를 줄이기 위한 UI 설계 원리 검토

1. 수행한 키 조작의 결과를 사용자가 빠르게 지각하도록 유도
2. 키 조작으로 변화된 시스템의 상태를 사용자가 쉽게 인지하도록 유도
3. 사용자가 가진 원래 의도와 시스템 결과 간의 유사 정도를 사용자가 쉽게 파악하도록 유도

018 UI 상세 설계

• UI 상세 설계: UI 설계서를 바탕으로 실제 설계 및 구현을 위해 모든 화면에 대한 자세한 설계를 진행하는 단계로, UI 상세 설계를 할 때는 반드시 시나리오를 작성해야 함.
• UI 시나리오 문서
  • 사용자 인터페이스의 기능 구조, 대표 화면, 화면 간 인터랙션의 흐름, 다양한 상황에서의 예외 처리 등을 문서로 정리한 것.
  • 최종 목표를 달성하기 위한 방법이 순차적으로 묘사되어 있음.

UI 시나리오 문서 작성 원칙

UI 시나리오 문서 작성을 위한 일반 규칙

UI 시나리오 문서의 요건

• 완전성(Complete)
• 일관성(Consistent)
• 이해성(Understandable)
• 가독성(Readable)
• 수정 용이성(Modifiable)
• 추적 용이성(Traceable)

UI 시나리오 문서로 인한 기대 효과

019 HCI/UX/감성공학

• HCI(Human Computer Interation or Interface): 사람이 시스템을 보다 편리하고 안전하게 사용할 수 있도록 연구하고 개발하는 학문으로, 최종 목표는 시스템을 사용하는데 있어 최적의 사용자 경험(UX)을 만드는 것.
• UX(User Experience): 사용자가 시스템이나 서비스를 이용하면서 느끼고 생각하게 되는 총체적인 경험.
  • UX의 특징: 주관성(Subjectivity), 정황성(Contextuality), 총체성(Holistic)
• 감성 공학: 제품이나 작업환경을 사용자의 감성에 알맞도록 설계 및 제작하는 기술로, 인문사회과학, 공학, 의학 등 여러 분야의 학문이 공존하는 종합과학.

3장. 애플리케이션 설계

020 소프트웨어 아키텍처

• 소프트웨어 아키텍처: 소프트웨어의 골격이 되는 기본 구조이자, 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체.
• 소프트웨어 아키텍처 설계의 기본 원리로는 모듈화, 추상화, 단계적 분해, 정보은닉이 있음.

모듈화(Modularity)

• 소프트웨어의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능들을 모듈 단위로 나누는 것.

추상화(Abstraction)

• 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시켜 나가는 것.
• 추상화의 유형
  • 과정 추상화: 자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악할 수 있게 설계하는 방법
  • 데이터 추상화: 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터 구조를 대표할 수 있는 표현으로 대체하는 방법
  • 제어 추상화: 이벤트 발생의 정확한 절차나 방법을 정의하지 않고, 대표할 수 있는 표현으로 대체하는 방법

단계적 분해(Stepwise Refinement)

• 하향식 설계 전략으로, 문제를 상위의 중요 개념으로부터 하위의 개념으로 구체화시키는 분할 기법.

정보 은닉(Information Hiding)

• 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법.

소프트웨어 아키텍처의 품질 속성

• 소프트웨어 아키텍처가 이해 관계자들이 요구하는 수준의 품질을 유지 및 보장할 수 있게 설계되었는지를 확인하기 위해 품질 평가 요소들을 시스템 측면, 비즈니스 측면, 아키텍처 측면으로 구분하여 구체화시켜 놓은 것
  • 시스템 측면 (품질 속성) : 성능, 보안, 가용성, 기능성, 사용성, 변경 용이성, 확장성, 테스트 용이성, 배치성, 안정성 등
  • 비즈니스 측면 (품질 속성) : 시장 적시성, 비용과 혜택, 예상 시스템 수명, 목표 시장, 공개 일정, 기존 시스템과의 통합 등
  • 아키텍처 측면 (품질 속성) : 개념적 무결성, 정확성, 완결성, 구축 가능성, 변경성, 시험성, 적응성, 일치성, 대체성 등

소프트웨어 아키텍처의 설계 과정

1. 설계 목표 설정
2. 시스템 타입 결정
3. 아키텍처 패턴 적용
4. 서브시스템 구체화
5. 검토

시스템 타입

• 대화형 시스템: 사용자의 요구가 발생하면 시스템이 이를 처리하고 반응하는 시스템
  • ex) 온라인 쇼핑몰과 같은 대부분의 웹 애플리케이션
• 이벤트 중심 시스템: 외부의 상태 변화에 따라 동작하는 시스템
  • ex) 전화, 비상벨 등의 내장 소프트웨어
• 변환형 시스템: 데이터가 입력되면 정해진 작업들을 수행하여 결과를 출력하는 시스템
  • ex) 컴파일러, 네트워크 프로토콜 등
• 객체 영속성 시스템: 데이터베이스를 사용하여 파일을 효과적으로 저장, 검색, 갱신할 수 있는 시스템

021 아키텍처 패턴

• 아키텍처 패턴: 아키텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제를 의미.
• 아키텍처 스타일 또는 표준 아키텍처라고도 함.
• 아키텍처 패턴의 종류에는 레이어 패턴, 클라이언트-서버 패턴, 파이프-필터 패턴, 모델-뷰-컨트롤러 패턴 등

레이어 패턴(Layers Pattern)

• 시스템을 계층(Layer)으로 구분하여 구성하는 고전적인 방법 중의 하나.
• 각각의 서브시스템들이 계층 구조를 이루며, 상위 계층은 하위 계층에 대한 서비스 제공자가 되고, 하위 계층은 상위 계층의 클라이언트가 됨.
• 서로 마주보는 두 개의 계층 사이에서만 상호작용이 이루어지며, 변경 사항을 적용할 때도 서로 마주보는 두 개의 계층에만 영향을 미치므로 변경 작업이 용이함.
• 특정 계층만을 교체해 시스템을 개선하는 것이 가능함.
• 대표적으로 OSI 참조 모델

클라이언트-서버 패턴(Client-Server Pattern)

• 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴.

파이프-필터 패턴(Pipe-Filter Pattern)

• 데이터 스트림 절차의 각 단계를 필터(Filter) 컴포넌트로 캡슐화하여 파이프(Pipe)를 통해 데이터를 전송하는 패턴
• 필터 컴포넌트는 재상용성이 좋고, 추가가 쉬워 확장이 용이함.
• 필터 컴포넌트들을 재배치하여 다양한 파이프라인을 구축하는 것이 가능함.
• 파이프-필터 패턴은 데이터 변환, 버퍼링, 동기화 등에 주로 사용됨.
• 대표적으로 UNIX의 쉘(Shell)

모델-뷰-컨트롤러 패턴(Model-View-Controller Pattern)

• 서브시스템을 3개의 부분으로 구조화하는 패턴. Model, View, Controller

기타 패턴

마스터-슬레이브 패턴(Master-Slave Pattern)

• 마스터 컴포넌트에서 슬레이브 컴포넌트로 작업을 분할한 후, 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는 방식으로 작업을 수행하는 패턴
• 마스터 컴포넌트는 모든 작업의 주체이고, 슬레이브 컴포넌트는 마스터 컴포넌트의 지시에 따라 작업을 수행하여 결과를 반환함.
• 장애 허용 시스템과 병렬 컴퓨팅 시스템에서 주로 활용됨.

브로커 패턴(Broker Pattern)

• 사용자가 원하는 서비스와 특성을 브로커 컴포넌트에 요청하면 브로커 컴포넌트가 요청에 맞는 컴포넌트와 사용자를 연결해줌.
• 원격 서비스 호출에 응답하는 컴포넌트들이 여러 개 있을 때 적합한 패턴
• 분산 환경 시스템에서 주로 활용됨.

피어-투-피어 패턴(Peer-To-Peer Pattern)

• 피어(Peer)를 하나의 컴포넌트로 간주하며, 각 피어는 서비스를 호출하는 클라이언트가 될 수도, 서비스를 제공하는 서버가 될 수도 있는 패턴
• 피어-투-피어 패턴에서 클라이언트와 서버는 전형적인 멀티스레딩 방식을 사용함.

이벤트-버스 패턴(Event-Bus Pattern)

• 소스가 특정 채널에 이벤트 메시지를 발행(Publish)하면, 해당 채널을 구독(Subscribe)한 리스너들이 메시지를 받아 이벤트를 처리하는 방식
• 4가지 주요 컴포넌트
  • 이벤트를 생성하는 소스(Source)
  • 이벤트를 수행하는 리스너(Listener)
  • 이벤트의 통로인 채널(Channel)
  • 채널들을 관리하는 버스(Bus)

블랙보드 패턴(Blackboard Pattern)

• 모든 컴포넌트들이 공유 데이터 저장소와 블랙보드 컴포넌트에 접근이 가능한 형태로, 컴포넌트들은 검색을 통해 블랙보드에서 원하는 데이터를 찾을 수 있음.
• 해결책이 명확하지 않은 문제를 처리하는데 유용한 패턴
• 음성 인식, 차량 식별, 신호 해석 등에 주로 활용됨.

인터프리터 패턴(Interpreter Pattern)

• 프로그램 코드의 각 라인을 수행하는 방법을 지정하고, 기호마다 클래스를 갖도록 구성됨.
• 특정 언어로 작성된 프로그램 코드를 해석하는 컴포넌트를 설계할 때 사용됨.

022 객체지향(Object-Oriented)

• 객체지향의 주요 구성 요소와 개념에는 객체(Object), 클래스(Class), 캡슐화(Encapsulation), 상속(Inheritance), 다형성(Polymorphism)이 있음.
• // 정보은닉, 추상화도
  (생략)

023 모듈 (Module)

• 모듈화를 통해 분리된 시스템의 각 기능들로, 서브루틴, 서브시스템, 소프트웨어 내의 프로그램, 작업 단위 등과 같은 의미로 사용됨.
• 모듈은 단독으로 컴파일이 가능. 재사용 가능.
• 모듈의 기능적 독립성은 소프트웨어를 구성하는 각 모듈의 기능이 서로 독립됨을 의미하는 것으로, 모듈이 하나의 기능만을 수행하고 다른 모듈과의 과도한 상호작용을 배제함으로써 이루어짐.
• 독립성이 높은 모듈일수록 모듈을 수정하더라도 다른 모듈들에게는 거의 영향을 미치지 않으며, 오류가 발생해도 쉽게 발견하고 해결 가능.
• 모듈의 독립성은 결합도와 응집도에 의해 측정.
• 독립성을 높이려면 모듈의 결합도는 약하게, 응집도는 강하게, 모듈의 크기는 작게 만들어야 한다.

결합도 (Coupling)

• 모듈 간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계
• 결합도가 약할수록 품질이 높고, 강할수록 품질이 낮음.
• 결합도가 강하면 시스템 구현 및 유지보수 작업이 어려움.
• 결합도의 종류 (뒤로 갈수록 결합도가 강해짐)
  • 자료 결합도 (Data Coupling)
    • 모듈 간의 인터페이스 자료 요소로만 구성될 때의 결합도
    • 어떤 모듈이 다른 모듈을 호출하면서 매개 변수나 인수로 데이터를 넘겨주고, 호출 받은 모듈은 받은 데이터에 대한 처리 결과를 다시 돌려주는 방식
    • 모듈 간의 내용을 전혀 알 필요가 없는 상태로서 한 모듈의 내용을 변경하더라도 다른 모듈에는 전혀 영향을 미치지 않는 가장 바람직한 결합도
  • 스탬프(검인) 결합도 (Stamp Coupling)
    • 모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달될 때의 결합도
    • 두 모듈이 동일한 자료 구조를 조회하는 경우의 결합도이며, 자료 구조의 어떠한 변화, 즉 포맷이나 구조의 변화는 그것을 조회하는 모든 모듈 및 변화되는 필드를 실제로 조회하지 않는 모듈에까지도 영향을 미치게 됨.
  • 제어 결합도 (Control Coupling)
    • 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호를 이용하여 통신하거나 제어 요소(Function Code, Switch, Tag, Flag)를 전달하는 결합도
    • 한 모듈이 다른 모듈의 상세한 처리 절차를 알고 있어 이를 통제하는 경우나 처리 기능이 두 모듈에 분리되어 설계된 경우에 발생함.
    • 하위 모듈에서 상위 모듈로 제어 신호가 이동하여 하위 모듈이 상위 모듈에게 처리 명령을 내리는 권리 전도현상이 발생함.
  • 외부 결합도 (External Coupling)
    • 어떤 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조할 때의 결합도
    • 참조되는 데이터의 범위를 각 모듈에서 제한할 수 있음.
  • 공통(공유) 결합도 (Common coupling)
    • 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도
    • 공통 데이터 영역의 내용을 조금만 변경하더라도 이를 사용하는 모든 모듈에 영향을 미치므로 모듈의 독립성을 약하게 만듬.
  • 내용 결합도 (Content Coupling)
    • 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때의 결합도
    • 한 모듈에서 다른 모듈의 내부로 제어가 이동하는 경우에도 내용 결합도에 해당함.

응집도 (Cohesion)

• 정보 은닉 개념을 확장한 것. 명령어나 호출문 등 모듈의 내부 요소들의 서로 관련되어 있는 정도, 즉 모듈이 독립적인 기능으로 정의되어 있는 정도를 의미
• 응집도가 강할수록 품질이 높고, 약할수록 품질이 낮음.
• 응집도의 종류 (뒤로 갈수록 응집도가 약해짐)
  • 기능적 응집도 (Functional Cohesion)
    • 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도
  • 순차적 응집도 (Sequential Cohesion)
    • 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동의 입력 데이터로 사용할 경우의 응집도
  • 교환(통신)적 응집도 (Communication Cohesion)
    • 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우의 응집도
  • 절차적 응집도 (Procedural Cohesion)
    • 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도
  • 시간적 응집도 (Temporal Cohesion)
    • 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도
  • 논리적 응집도 (Logical Cohesion)
    • 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우의 응집도
  • 우연적 응집도 (Coincidental Cohesion)
    • 모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우의 응집도

팬인(Fan-In) / 팬아웃(Fan-Out)

• 팬인: 어떤 모듈을 제어(호출)하는 모듈의 수
• 팬아웃: 어떤 모듈에 의해 제어(호출)되는 모듈의 수
• 팬인과 팬아웃을 분석하여 시스템의 복잡도를 알 수 있음.
• 팬인이 높다는 것은 재사용 측면에서 설계가 잘 되어있다고 볼 수 있으나, 단일 장애점이 발생할 수 있으므로 중점적인 관리 및 테스트가 필요함.
• 팬아웃이 높은 경우 불필요하게 다른 모듈을 호출하고 있는지 검토하고, 단순화시킬 수 있는지 여부에 대한 검토가 필요함.
• 시스템의 복잡도를 최적화하려면 팬인은 높게, 팬아웃은 낮게 설계해야 함.

024 공통 모듈

• 여러 프로그램에서 공통적으로 사용할 수 있는 모듈
• 모듈의 재사용성 확보와 중복 개발 회피를 위해 설계 과정에서 공통 부분을 식별하고 명세를 작성할 필요가 있음.
• 다른 개발자들이 해당 기능을 명확히 이해할 수 있도록 다음의 명세 기법을 준수해야 함.
  • 정확성(Correctness): 시스템 구현 시 해당 기능이 필요하다는 것을 알 수 있도록 정확히 작성
  • 명확성(Clarity): 해당 기능을 이해할 때 중의적으로 해석되지 않도록 명확하게 작성
  • 완전성(Completeness): 시스템 구현을 위해 필요한 모든 것을 기술
  • 일관성(Consistency): 공통 기능들 간 상호 충돌이 발생하지 않도록 작성
  • 추적성(Traceability): 기능에 대한 요구사항의 출처, 관련 시스템 등의 관계를 파악할 수 있도록 작성

재사용 (Reuse)

• 재사용 규모에 따른 분류
  • 함수와 객체 : 클래스나 메소드 단위의 소스 코드를 재사용
  • 컴포넌트 : 컴포넌트 자체에 대한 수정 없이 인터페이스를 통해 통신하는 방식으로 재사용
  • 애플리케이션 : 공통된 기능들을 제공하는 애플리케이션을 공유하는 방식으로 재사용

효과적인 모듈 설계 방안

• 결합도는 줄이고 응집도는 높여서 모듈의 독립성과 재사용성을 높임.
• 모듈의 제어 영역 안에서 그 모듈의 영향 영역을 유지시킴.
• 복잡도와 중복성을 줄이고 일관성을 유지시킴.
• 모듈의 기능이 예측이 가능해야 하며 지나치게 제한적이어서는 안됨.
• 유지보수가 용이해야 함.
• 모듈 크기는 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 분해함.
• 하나의 입구와 하나의 출구를 갖도록 해야 함.
• 인덱스 번호나 기능 코드들이 전반적인 처리 논리 구조에 예기치 못한 영향을 끼치지 않도록 모듈 인터페이스를 설계해야 함.

025 코드

• 코드(Code): 컴퓨터를 이용하여 자료를 처리하는 과정에서 분류, 조합 및 집계를 용이하게 하고, 특정 자료의 추출을 쉽게 하기 위해서 사용하는 기호.
• 코드의 주요 기능
  • 식별 기능
  • 분류 기능
  • 배열 기능

코드의 종류

• 순차 코드(Sequence Code)
  • 자료의 발생 순서, 크기 순서 등 일정 기준에 따라서 최초의 자료부터 차례로 일련번호를 부여하는 방법
  • 순서 코드 또는 일련 번호 코드라고도 함.
• 블록 코드(Block Code)
  • 코드화 대상 항목 중에서 공통성이 있는 것끼리 블록으로 구분하고, 각 블록 내에서 일련번호를 부여하는 방법
  • 구분 코드라고도 함.
• 10진 코드(Decimal Code)
  • 코드화 대상 항목을 0~9까지 10진 분할하고, 다시 그 각각에 대하여 10진 분할하는 방법을 필요한 만큼 반복하는 방법
  • 도서 분류식 코드라고도 함.
• 그룹 분류 코드(Group Classification Code)
  • 코드화 대상 항목을 일정 기준에 따라 대분류, 중분류, 소분류 등으로 구분하고, 각 그룹 안에서 일련번호를 부여하는 방법
• 연상 코드(Mnemonic Code)
  • 코드화 대상 항목의 명칭이나 약호와 관계있는 숫자나 문자, 기호를 이용하여 코드를 부여하는 방법
• 표의 숫자 코드(Significant Digit Code)
  • 코드화 대상 항목의 성질, 즉 길이, 넓이, 부피, 지름, 높이 등의 물리적 수치를 그대로 코드에 적용시키는 방법
  • 유효 숫자 코드라고도 함.
• 합성 코드(Combined Code)
  • 필요한 기능을 하나의 코드로 수행하기 어려운 경우 2개 이상의 코드를 조합하여 만드는 방법

코드 부여 체계

• 이름만으로 개체의 용도와 적용 범위를 알 수 있도록 코드를 부여하는 방식

026 디자인 패턴 (Design Pattern)

• 각 모듈의 세분화된 역할이나 모듈들 간의 인터페이스와 같은 코드를 작성하는 수준의 세부적인 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제

생성 패턴(Creational Pattern)

• 객체의 생성과 관련된 패턴

• 생성 패턴은 객체의 생성과 참조 과정을 캡슐화하여 객체가 생성되거나 변경되어도 프로그램의 구조에 영향을 크게 받지 않도록 하여 프로그램에 유연성을 더해줌.

• 추상 팩토리 (Abstract Factory)

  • 구체적인 클래스에 의존하지 않고, 인터페이스를 통해 서로 연관·의존하는 객체들의 그룹으로 생성하여 추상적으로 표현함.
  • 연관된 서브 클래스를 묶어 한 번에 교체하는 것이 가능함.

• 빌더 (Builder)

• 팩토리 메소드 (Factory Method)

  • 객체 생성을 서브 클래스에게 처리하도록 분리하여 캡슐화한 패턴
  • 상위 클래스에서 인터페이스만 정의하고 실제 생성은 서브 클래스가 담당함.

• 프로토타입 (Prototype)

  • 원본 객체를 복제하는 방법으로 객체를 생성하는 패턴

• 싱글톤 (Singleton)

• 추상 팩토리는 서로 다른 부품을 조립만 하는 조립 공장(Factory)

• 팩토리 메소드는 부품부터 완성품까지 통째로 찍어내는 공장(Factory)

• 프로토타입은 원형(Prototype)을 두고 복제품을 만드는 것

• 싱글톤은 식당에서 누구나 사용할 수 있지만 하나뿐(Singleton)인 정수기

구조 패턴(Structural Pattern)

• 클래스나 객체들을 조합하여 더 큰 구조로 만들 수 있게 해주는 패턴

• 구조 패턴은 구조가 복잡한 시스템을 개발하기 쉽게 도와줌.

• 어댑터 (Adapter)

  • 호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환해주는 패턴
  • 기존의 클래스를 이용하고 싶지만 인터페이스가 일치하지 않을 때 이용함.

• 브리지 (Bridge)

  • 구현부에서 추상층을 분리하여, 서로가 독립적으로 확장할 수 있도록 구성한 패턴
  • 기능과 구현을 두 개의 별도 클래스로 구현함.

• 컴포지트 (Composite)

  • 여러 객체를 가진 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용하는 패턴
  • 객체들을 트리 구조로 구성하여 디렉터리 안에 디렉터리가 있듯이 복합 객체 안에 복합 객체가 포함되는 구조를 구현할 수 있음.

• 데코레이터 (Decorator)

  • 객체 간의 결합을 통해 능동적으로 기능을 확장할 수 있는 패턴
  • 임의의 객체에 부가적인 기능을 추가하기 위해 다른 객체들을 덧붙이는 방식으로 구현함.

• 퍼싸드 (Facade)

  • 복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구성함으로써 서브 클래스들의 기능을 간편하게 사용할 수 있도록 하는 패턴
  • 서브 클래스들 사이에 통합 인터페이스를 제공하는 Wrapper 객체가 필요함.

• 플라이웨이트 (Flyweight)

  • 인스턴스가 필요할 때마다 매번 생성하는 것이 아니고 가능한 한 공유해서 사용함으로써 메모리를 절약하는 패턴
  • 다수의 유사 객체를 생성하거나 조작할 때 유용하게 사용할 수 있음.

• 프록시 (Proxy)

  • 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴
  • 네트워크 연결, 메모리의 대용량 객체로의 접근 등에 주로 이용함.

• 어댑터는 전압을 맞춰주는 변압기(Adapter)

• 브리지는 두 섬을 연결하는 다리(Bridge)

• 컴포지트는 폴더와 파일을 합성(Composite)한 것

• 데코레이터는 온갖 것으로 장식된(Decorator) 눈사람

• 퍼싸드는 외부(Facade)의 리모컨 버튼만으로 복잡한 명령들을 간편하게 수행하는 것

• 플라이웨이트는 부담을 가볍게(Flyweight) 하기 위해 물품을 공유하는 것

• 프록시는 내가 하기 어려운 법률업무를 대리(Proxy)해서 처리해주는 변호사

행위 패턴(Behavioral Pattern)

• 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴

• 행위 패턴은 하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배하면서 결합도를 최소화할 수 있도록 도와줌.

• 책임 연쇄 (Chain of Responsibility)

  • 요청을 처리할 수 있는 객체가 둘 이상 존재하여 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태의 패턴
  • 요청을 처리할 수 있는 각 객체들이 고리(Chain)로 묶여 있어 요청이 해결될 때까지 고리를 따라 책임이 넘어감.

• 커맨드 (Command)

  • 요청을 객체의 형태로 캡슐화하여 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴
  • 요청에 사용되는 각종 명령어들을 추상 클래스와 구체 클래스로 분리하여 단순화함.

• 인터프리터 (Interpreter)

• 반복자 (Iterator)

• 중재자 (Mediator)

  • 수많은 객체들 간의 복잡한 상호작용(Interface)을 캡슐화하여 객체로 정의하는 패턴
  • 객체 사이의 의존성을 줄여 결합도를 감소시킬 수 있음.

• 메멘토 (Memento)

  • 특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴
  • 'Ctrl+z'와 같은 되돌리기 기능을 개발할 때 주료 이용함.

• 옵저버 (Observer)

  • 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴
  • 주로 분산된 시스템 간에 이벤트를 생성·발행(Publish)하고, 이를 수신(Subscribe)해야 할 때 이용함.

• 상태 (State)

  • 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용하는 패턴
  • 객체 상태를 캡슐화하고 이를 참조하는 방식으로 처리함.

• 전략 (Strategy)

  • 동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴
  • 클라이언트는 독립적으로 원하는 알고리즘을 선택하여 사용할 수 있으며, 클라이언트에 영향 없이 알고리즘의 변경이 가능함.

• 템플릿 메소드 (Template Method)

  • 상위 클래스에서 골격을 정의하고, 하위 클래스에서 세부 처리를 구체화하는 구조의 패턴
  • 유사한 서브 클래스를 묶어 공통된 내용을 상위 클래스에서 정의함으로써 코드의 양을 줄이고 유지보수를 용이하게 해줌.

• 방문자 (Visitor)

  • 각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴
  • 분리된 처리 기능은 각 클래스를 방문(Visit)하여 수행함.

• 책임 연쇄는 위에서 쏟아지는 물을 여러 물받이가 연속(Chain)해서 나눠 받는(Responsibility) 물레방아

• 커맨드는 각종 명령어(Command)를 하나로 합쳐둔 것

• 인터프리터는 언어 번역가(Interpreter)

• 반복자는 음악파일의 다음 곡 재생처럼 같은 명령의 반복(Iterator)

• 중재자는 물품 매매를 중개해주는(Mediator) 인터넷 사이트

• 메멘토는 기억 속의 그 때(Memento)로 돌아가는 것

• 옵저버는 변화를 지켜보고(Observer) 알려주는 것

• 상태는 환자의 상태(State)에 따라 치료방법이 다른 것

• 전략은 여러 전략들을 a, b, c 등으로 정하고 필요할 때 원하는 전략(Strategy)을 선택하여 쓰는 것

• 템플릿 메소드는 세모, 네모, 동그라미를 그리는 방법(Method)들을 도형이라는 하나의 큰 틀(Template)로 묶는 것

• 방문자는 책을 만들기 위해 저자, 편집자, 홍보팀을 번갈아가며 방문(Visitor)하는 것

4장. 인터페이스 설계

027 시스템 인터페이스 요구사항 분석

시스템 인터페이스 요구사항 구성

• 시스템 인터페이스: 독립적으로 떨어져 있는 시스템들끼리 서로 연동하여 상호 작용하기 위한 접속 방법이나 규칙을 의미
• 시스템 인터페이스 요구사항: 개발을 목표로 하는 시스템과 외부 시스템을 연동하는데 필요한 시스템 인터페이스에 대한 요구사항을 기술한 것
• 시스템 인터페이스 요구사항 명세서: 인터페이스 이름, 연계 대상 시스템, 연계 범위 및 내용, 연계 방식, 송신 데이터, 인터페이스 주기, 기타 고려사항 등이 포함되어야 함. // 수신 데이터는 아님!
• 요구사항 명세서는 프로젝트 개발 시 기업이나 업체가 요구하는 사항들을 구체화하여 명세화한 문서로, 시스템 기능, 데이터, 인터페이스, 품질 등의 요구사항 단위별로 작성함.

시스템 인터페이스 요구사항 분석

• 요구사항 명세서에서 요구사항을 기능적 요구사항과 비기능적 요구사항으로 분류하고 조직화하여 요구사항 명세를 구체화하고 이를 이해관계자에게 전달하는 일련의 과정

시스템 인터페이스 요구사항 분석 절차

• 요구사항 선별 -> 요구사항 관련 자료 준비 -> 요구사항 분류 -> 요구사항 분석 및 명세서 구체화 -> 요구사항 명세서 공유

028 인터페이스 요구사항 검증

요구사항 검증(Requirements Verification)

• 인터페이스의 설계 및 구현 전에 사용자들의 요구사항이 요구사항 명세서에 정확하고 완전하게 기술되었는지 검토하고 개발 범위의 기준인 베이스라인을 설정하는 것
• 인터페이스 요구사항 검증은 요구사항 검토 계획 수립 -> 검토 및 오류 수정 -> 베이스라인 설정 순으로 수행함.

1. 인터페이스 요구사항 검토 계획 수립

• 프로젝트 이해관계자들이 프로젝트 품질 관리 계획을 참조하여 다음과 같이 인터페이스 요구사항 검토 계획을 수립함.
  • 검토 기준 및 방법
  • 참여자
  • 체크리스트
  • 관련 자료
  • 일정

2. 인터페이스 요구사항 검토 및 오류 수정

• 인터페이스 요구사항 검토: 검토 체크리스트의 항목에 따라 인터페이스 요구사항 명세서를 검토하는 것

3. 인터페이스 요구사항 베이스라인 설정

• 인터페이스 요구사항 검토를 통해 검증된 인터페이스 요구사항은 프로젝트 관리자와 주요 의사 결정자에게 공식적으로 승인 받음.
• 소프트웨어 설계 및 구현을 위해 요구사항 명세서의 베이스라인을 설정함.
• 베이스라인을 설정한 후 인터페이스 요구사항의 변경은 공식적인 변경 통제 절차로만 가능함.

요구사항 검증 방법

• 요구사항 검토(Requirements Review): 요구사항 명세서의 오류 확인 및 표준 준수 여부 등의 결함 여부를 검토 담당자들이 수작업으로 분석하는 방법
  • 동료검토(Peer Review): 요구사항 명세서 작성자가 명세서 내용을 직접 설명하고 동료들이 이를 들으면서 결함을 발견하는 형태의 검토 방법
  • 워크스루(Walk Through): 검토 회의 전에 요구사항 명세서를 미리 배포하여 사전 검토한 후에 짧은 검토 회의를 통해 결함을 발견하는 형태의 검토 방법
  • 인스펙션(Inspection): 요구사항 명세서 작성자를 제외한 다른 검토 전문가들이 요구사항 명세서를 확인하면서 결함을 발견하는 형태의 검토 방법
• 프로토타이핑(Prototyping): 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품(Prototype)을 만들어 최종 결과물을 예측함.
• 테스트 설계: 요구사항은 테스트할 수 있도록 작성되어야 하며, 이를 위해 테스트 케이스(Test Case)를 생성하여 이후에 요구사항이 현실적으로 테스트 가능한지를 검토함.
• CASE(Computer Aided Software Engineering) 도구 활용: 일관성 분석(Consistency Analysis)을 통해 요구사항 변경사항의 추적 및 분석, 관리하고, 표준 준수 여부를 확인함.

인터페이스 요구사항 검증의 주요 항목

• 완전성(Completeness) : 사용자의 모든 요구사항이 누락되지 않고 완전하게 반영되어 있는가?
• 일관성(Consistency) : 요구사항이 모순되거나 충돌되는 점 없이 일관성을 유지하고 있는가?
• 명확성(Unambiguity) : 모든 참여자가 요구사항을 명확히 이해할 수 있는가?
• 기능성(Functionality) : 요구사항이 '어떻게(How to)' 보다 '무엇을(What)'에 중점을 두고 있는가?
• 검증 가능성(Verifiability) : 요구사항이 사용자의 요구를 모두 만족하고, 개발된 소프트웨어가 사용자의 요구 내용과 일치하는지를 검증할 수 있는가?
• 추적 가능성(Traceability) : 요구사항 명세서와 설계서를 추적할 수 있는가?
• 변경 용이성(Easily Changeable) : 요구사항 명세서의 변경이 쉽도록 작성되었는가?

029 인터페이스 시스템 식별

• 개발 시스템 식별: 개발 시스템을 식별하는 것은 인터페이스 관련 자료들을 기반으로 개발하고자 하는 시스템의 상세 식별 정보를 정의하고 목록을 작성하는 것

내·외부 시스템 식별

• 내·외부 시스템을 식별하는 것은 인터페이스 관련 자료들을 기반으로 개발할 시스템과 연계할 내·외부 시스템들의 상세 식별 정보를 정의하고 목록을 작성하는 것

내·외부 시스템 환경 및 관리 주체 식별

• 내·외부 시스템 환경: 연계할 시스템 접속에 필요한 IP 또는 URL, Port 정보 등 시스템의 실제 운용 환경을 의미
• 내·외부 시스템 관리 주체: 하드웨어를 실제적으로 관리하는 담당자를 의미
• 인터페이스 관련 자료들을 기반으로 내·외부 시스템의 실제 운용 환경과 하드웨어 관리 주체를 확인함.

내·외부 시스템 네트워크 연결 정보 식별

• 내·외부 시스템 네트워크 연결 정보는 시스템 로그인 및 DB 정보를 의미함.

인터페이스 식별

• 인터페이스를 식별하는 것은 인터페이스 요구사항 명세서와 인터페이스 요구사항 목록을 기반으로 개발할 시스템과 이와 연계할 내·외부 시스템 사이의 인터페이스를 식별하고 인터페이스 목록을 작성하는 것

인터페이스 시스템 식별

• 인터페이스 시스템을 식별하는 것은 인터페이스별로 인터페이스에 참여하는 시스템들을 송신 시스템과 수신 시스템으로 구분하여 작성하는 것

030 송·수신 데이터 식별

식별 대상 데이터

• 송·수신 시스템 사이에서 교환되는 데이터로, 규격화된 표준 형식에 따라 전송됨.

• 교환되는 데이터의 종류

• 인터페이스 표준 항목

  • 송·수신 시스템을 연계하는데 표준적으로 필요한 데이터를 의미
  • 시스템 공통부와 거래 공통부로 나뉨.
  • 시스템 공통부
    • 시스템 간 연동 시 필요한 공통 정보
    • 구성 정보에는 인터페이스 ID, 전송 시스템 정보, 서비스 코드 정보, 응답 결과 정보, 장애 정보 등이 있음.
  • 거래 공통부
    • 시스템들이 연동된 후 송·수신 되는 데이터를 처리할 때 필요한 정보
    • 구성 정보에는 직원 정보, 승인자 정보, 기기 정보, 매체 정보 등이 있음.

• 송·수신 데이터 항목

  • 송·수신 데이터 항목은 송·수신 시스템이 업무를 수행하는 데 사용하는 데이터

• 공통 코드

  • 시스템들에서 공통적으로 사용하는 코드

정보 흐름 식별

• 개발할 시스템과 내·외부 시스템 사이에서 전송되는 정보들의 방향성을 식별하는 것.

송·수신 데이터 식별

• 개발할 시스템과 연계할 내·외부 시스템 사이의 정보 흐름과 데이터베이스 산출물을 기반으로 송·수신 데이터를 식별함.
• 송·수신 데이터의 종류
  • 인터페이스 표준 항목과 송·수신 데이터 항목 식별
    • 송·수신 시스템 사이의 교환 범위를 확인하고 인터페이스 표준 항목에 대해 송·수신 데이터 항목을 식별함.
  • 코드성 데이터 항목 식별
    • 코드성 데이터 항목에 대해 코드, 코드명, 코드 설명 등의 코드 정보를 식별함.
    • 송신 시스템에서 사용하는 코드 정보와 수신 시스템에서 사용하는 코드 정보가 동일한 경우 공통 코드 정보를 확보하고, 다른 경우 매핑 필요 대상으로 분류하여 양쪽 시스템에서 사용하는 코드 정보를 확보

031 인터페이스 방법 명세화

• 내·외부 시스템이 연계하여 작동할 때 인터페이스별 송·수신 방법, 송·수신 데이터, 오류 식별 및 처리 방안에 대한 내용을 문서로 명확하게 정리하는 것.
• 인터페이스 별로 송·수신 방법을 명세화하기 위해서는 시스템 연계 기술, 인터페이스 통신 유형, 처리 유형, 발생 주기 등에 대한 정보가 필요함.

시스템 연계 기술

• 개발할 시스템과 내·외부 시스템을 연계할 때 사용되는 기술을 의미
• DB Link
• API/Open API
• 연계 솔루션: EAI 서버와 송·수신 시스템에 설치되는 클라이언트를 이용하는 방식
• Socket
• Web Service
  • WSDL(Web Services Description Language)
  • UDDI(Universal Description, Discovery and Integration)
  • SOAP(Simple Object Access Protocol)

인터페이스 통신 유형

• 개발할 시스템과 내·외부 시스템 간 데이터를 송·수신하는 형태를 의미
  • 단방향: 시스템에서 거래를 요청만 하고 응답이 없는 방식
  • 동기: 시스템에서 거래를 요청하고 응답이 올 때까지 대기(Request-Reply)하는 방식
  • 비동기: 시스템에서 거래를 요청하고 다른 작업을 수행하다 응답이 오면 처리하는 방식(Send-Receive, Send-Receive-Acknowledge, Publish-Subscribe)

인터페이스 처리 유형

• 송·수신 데이터를 어떤 형태로 처리할 것인지에 대한 방식을 의미
  • 실시간 방식
  • 지연 처리 방식: 데이터를 매건 단위로 처리할 경우 비용이 많이 발생할 때 사용하는 방식
  • 배치 방식: 대량의 데이터를 처리할 때 사용하는 방식

인터페이스 발생 주기

• 개발할 시스템과 내·외부 시스템 간 송·수신 데이터가 전송되어 인터페이스가 사용되는 주기를 의미
• 업무의 성격와 송·수신 데이터 전송량을 고려하여 매일, 수시, 주 1회 등으로 구분

송·수신 방법 명세화

• 내·외부 인터페이스 목록에 있는 각각의 인터페이스에 대해 연계 방식, 통신 및 처리 유형, 발생 주기 등의 송·수신 방법을 정의하고 명세를 작성하는 것
• 연계 방식, 통신 유형, 연계 처리 형태는 시스템 인터페이스 설계 시 작성한 아키텍처 정의서를 기반으로 하여 업무 및 데이터의 성격, 연계 데이터 발생 건수, 연계 시스템의 기술 구조, 시스템 간의 성능 등을 고려하여 작성

송·수신 데이터 명세화

• 내·외부 인터페이스 목록에 있는 각각의 인터페이스에 대해 인터페이스 시 필요한 송·수신 데이터에 대한 명세를 작성하는 것
• 인터페이스별로 테이블 정의서와 파일 레이아웃에서 연계하고자 하는 테이블 또는 파일 단위로 송·수신 데이터에 대한 명세를 작성

오류 식별 및 처리 방안 명세화

• 내·외부 인터페이스 목록에 있는 각각의 인터페이스에 대해 인터페이스 시 발생할 수 있는 오류를 식별하고 오류 처리 방안에 대한 명세를 작성하는 것

032 시스템 인터페이스 설계서 작성

시스템 인터페이스 설계서의 개요

• 시스템 인터페이스 설계서: 시스템의 인터페이스 현황을 확인하기 위해 시스템이 갖는 인터페이스 목록과 각 인터페이스의 상세 데이터 명세를 정의한 문서
• 시스템 인터페이스 설계서는 시스템 인터페이스 목록과 시스템 인터페이스 정의서로 구성
• 시스템 인터페이스 설계서는 인터페이스 송·수신 방법과 인터페이스 송·수신 데이터 명세화 과정에서 작성한 산출물을 기반으로 작성함.

시스템 인터페이스 목록 작성

• 시스템 인터페이스 목록: 업무 시스템과 내·외부 시스템 간 데이터를 주고받는 경우에 사용하는 인터페이스에 대해 기술한 것
• 시스템 인터페이스 목록에는 연계 업무와 연계에 참여하는 송·수신 시스템의 정보, 연계 방식과 통신 유형 등에 대한 정보를 기록함.

시스템 인터페이스 정의서 작성

• 시스템 인터페이스 정의서: 인터페이스별로 시스템 간의 연계를 위해 필요한 데이터 항목 및 구현 요건 등을 기술하는 것
• 시스템 인터페이스 정의에는 데이터 송·수신 시스템 간 데이터 저장소와 속성 등 상세 정보를 기록

033 미들웨어 솔루션 명세

• 미들웨어(Middleware): 미들과 소프트웨어의 합성어로, 운영체제와 해당 운영체제에서 실행되는 응용 프로그램 사이에서 운영체제가 제공하는 서비스 이외에 추가적인 서비스를 제공하는 소프트웨어
• 미들웨어는 표준화된 인터페이스를 제공함으로써 시스템 간의 데이터 교환에 일관성을 보장함.

DB

RPC (Remote Procedure Call)

• RPC(원격 프로시저 호출)은 응용 프로그램의 프로시저를 사용하여 원격 프로시저를 마치 로컬 프로시저처럼 호출하는 방식의 미들웨어

MOM (Message Oriented Middleware)

• MOM(메시지 지향 미들웨어)는 메시지 기반의 비동기형 메시지를 전달하는 방식의 미들웨어
• 온라인 업무보다는 이기종 분산 데이터 시스템의 데이터 동기를 위해 많이 사용됨.
• ex) IBM의 MQ, 오라클의 Message Q, JCP의 JMS 등

TP-Monitor (Transaction Processing Monitor)

• TP-Monitor(트랜잭션 처리 모니터)는 항공기나 철도 예약 업무 등과 같은 온라인 트랜잭션 업무에서 트랜잭션을 처리 및 감시하는 미들웨어
• 사용자 수가 증가해도 빠른 응답 속도를 유지해야 하는 업무에 주로 사용됨.
• ex) 오라클의 tuxedo, 티맥스소프트의 tmax

ORB (Object Request Broker)

• ORB(객체 요청 브로커)는 객체 지향 미들웨어로 코바(CORBA) 표준 스펙을 구현한 미들웨어

• 최근에는 TP-Monitor의 장점인 트랜잭션 처리와 모니터링 등을 추가로 구현한 제품도 있음.

• ex) Micro Focus의 Orbix, OMG의 CORBA 등

• 코바(CORBA; Common Object Request Broker Architecture) : 코바는 네트워크에서 분산 프로그램 객체를 생성, 배포, 관리하기 위한 규격을 의미

WAS (Web Application Server)

• WAS(웹 애플리케이션 서버)는 정적인 콘텐츠를 처리하는 웹 서버와 달리 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어
• 클라이언트/서버 환경보다는 웹 환경을 구현하기 위한 미들웨어

미들웨어 솔루션 식별

• 개발 및 운영 환경에 사용될 미들웨어 솔루션을 확인하고 목록을 작성하는 것

미들웨어 솔루션 명세서 작성

• 미들웨어 솔루션 명세서: 미들웨어 솔루션 목록의 미들웨어 솔루션별로 관련 정보들을 상세하게 기술하는 것
• 솔루션 제약사항 검토