[정처기필기] 소프트웨어 설계

플랫폼 분석	-애플리케이션을 구동시키는데 필요한 소프트웨어의 환경 -싱글 사이드 플랫폼: 소비자와 공급자 연결  -투 사이드 플랫폼:두 그룹을 중개하고 모두에게 개방 -멀티 사이드 플랫폼: 다양한 이해관꼐 그룹을 연결 -플랫폼 환경을 통해 소프트웨어 개발과 운영비용이 감소하고 생산성이 향상, 커뮤니티를 형성하고 네트워크 효과 유발 -플랫폼 성능 특성 분석: 사용자의 서비스 이용시 속도의 적정성 확인 사용자인터뷰, 성능테스트(부하테스트 결과서, 성능테스트), 산출물 점검(벤치마킹 결과서) <플랫폼 성능 측정 항목> 경과시간, 사용률, 응답시간, 가용성
운영체제 분석	-운영체제는 하드웨어 및 소프트웨어 자원을 효율적으로 관리하며 공통된 기능을 제공하는 소프트웨어 <운영체제 현행 시스템 분석시 고려사항> 운영체제 분석은 신성기주구 품질 측면: 신뢰도, 성능(배치작업/지원 가능한 메모리32비트,64비트)  지원 측면: 기술 지원, 주변 기기, 구축 비용 **배치 작업은 별다른 이상 없을 시 사용자 개입 없이 묶어서 "일괄 처리"
네트워크 분석	백본망, 라우터, 스위치, 게이트웨이, 방화벽 등을 대상으로 분석
DBMS 분석	-DBMS는 데이터베이스라는 데이터의 집합을 만들고, 저장 및 관리할 수 있는 기능을 제공하는 응용 프로그램 <DBMS 현행 시스템 분석시 고려사항> DBMS 분석은 가성호기구 성능 측면: 가용성, 성능, 상호 호환성 지원 측면: 기술 지원, 구축 비용
요구공학 프로세스	요구 사항 개발 단계 : 도출-분석-명세-확인 및 검증(Validation&Verification) 요구 사항 관리 단계 : 협상-기준선관리-변경관리-확인 및 검증
요구분석	-도출된 요구사항 간 상충을 해결하고 소프트웨어의 범위를 파악하여 외부 환경과의 상호 작용을 분석하는 과정 -소프트웨어 개발의 실제적인 첫 단계, 사용자의 요구에 대해 이해 -분석 결과의 문서화하여 향후 유지보수에 유용, 보다 구체적인 명세를 위해 소단위 명세서 활용 -개발 비용이 가장 많이 소요되지 않음! -요구분석은 기능적/비기능적 요구사항 기능적 요구사항은 소프트웨어가 가져야하는 기능적 속성에 대한 요구사항 비기능적 요구사항은 보안, 성능, 품질, 안정 등에 대한 요구사항 -요구분석 기법으로는 요구사항 분류, 개념 모델링, 요구사항 할당, 요구사항 협상, 정형분석(수학적 기호로 표현) 요구분석은 자료 흐름 분석(데이터 흐름도)과 객체 지향 분석(UML다이어그램-정적,동적)
데이터 흐름도(DFD)	-데이터가 각 프로세스를 따라 흐르면서 변환되는 모습을 나타낸 그림(다이어그램) (=자료 흐름 그래프, 버블 차트) -구조적 분석에 이용 -데이터의 흐름에 중심을 두는 분석용 도구 -제어의 흐름은 중요치 않고, 시간 흐름을 명확하게 표현할 수 없다 처리기(process), 데이터 흐름(data flow), 데이터 저장소(data store), 단말(teminator)
자료사전(DD)	데이터에 대한 데이터들을 구체적으로 명시하는 사전 자료 흐름도(데이터 흐름도)에 나타나는 어떤 자료의 흐름도 자료사전에 정의되어 있어야 한다 자료의 의미 기술, 자료 구성항목의 기술, 동의어 규정 준수, 자료 정의의 중복 제거
UML	-객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화 할때 사용되는 모델링 기술과 방법론을 통합해서 만든 표준화된 모델링 언어(Unifide Modeling Language) -UML은 가시화 언어, 구축언어,명세화 언어, 문서화 언어(객체 지향 언어X) -사물(things), 관계(relationships), 다이어그램(diagrams)으로 구성 => "UML다이어그램" 다이어그램은 정적(구조적)다이어그램과 동적(행위적)다이어그램으로 구분
정적(구조적)다이어그램	클객 컴배 복패 클래스(Class) 객체(object) 컴포넌트(component) 배치(deployment) 복합체 구조(composit structure) 패키지(package)
동적(행위적)다이어그램	유시커 상활타 유스케이스(Usecase) 시퀀스(Sequence) 커뮤니케이션(Communication) 상태(state) 활동(activity) 타이밍(timing)
클래스 다이어그램	-객체 지향 모델링에서 정적(구조적) 관계 표현, 클래스와 클래스, 클래스의 속성 사이의 관계 표현 • 클래스 이름 • 속성 • 연산 • 접근제어자 private(-) < default (~) < protected (#) < public(+)
유스케이스 다이어그램	- 시스템이 제공하는 기능 및 외부 요소를 사용자의 관점에서 표현 • 유스케이스(시스템이 제공해야 하는 서비스, 액터가 수행하는 행위) • 액터(사용자가 시스템에 대해 수행하는 역할, 시스템과 상호작용하는 사람 또는 사물) • 시스템
시퀀스 다이어그램	-객체 간 상호작용을 메시지 흐름으로 표현(메시지 교환) 객체, 생명선, 실행, 메시지
State diagram	-동적(행위적) 다이어그램, 하나의 객체가 가진 상태와 그 상태의 변화에 의한 동작 순서
UML의 관계	-사물과 사물 사이의 연관성 연관관계, 의존관계, 일반화 관계(상속관계-클래스), 실체화 관계(상속관계-인터페이스), 포함 관계(합성 관계), 집합 관계(집약 관계)
스테레오 타입 (UML 확장모델)	-UML의 기본적 요소 이외에 새로운 요소를 만들어 내기 위한 확장 메커니즘 (기존 요소를 그대로 사용하지만 내부 의미는 다른 목적으로 사용하도록 확장) << >> (길러멧:Guillemet)기호 사용
애자일 방법론	-개발과 함꼐 즉시 피드백을 받아서 유동적으로 개발 -요구사항을 기능 중심으로 정의(모듈 중심X) -절차와 도구보다 개인과 소통이 중요, 고객과의 피드백을 중요시 -계획을 짧게 세워 요구 변화에 유연하고 신속하게 대응 -소프트웨어가 잘 실행되는데 가치 -애자일 방법론에는 XP, 린, 스크럼 등 ✓ XP 의사소통 개선과 즉각적 피드백으로 품질 향상을 위한 방법, 실용성 강조 1~3주의 반복(Interation)개발주기, 5개의 가치(용단의 피존) 와 12개의 실천항목 ✓ 스크럼 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론 ✓ 린 도요타의 린 시스템 품질기법을 적용해 낭비요소를 제거하여 품질을 향상(린의 7가지 원칙)  ✓ 크리스탈, ASD(Adaptive Software Development), FDD(Feature Driven Development)
애자일 선언문	• (공정과 도구보다) 개인과 상호작용 • (계획을 따르기보다) 변화에 대응 • (포괄적인 문서보다) 동작하는 소프트웨어  • (계약 협상보다는) 고객과의 협력
모델링	설계의 핵심, 실세계 물리현상을 특정한 목적에 대응하여 이용하기 쉬운 형식으로 표현한 기법 -여러 분야 엔지니어들이 공통된 개념 공유가능, 응용문제를 이해하는데 도움 -절차적인 프로그램을 위한 자료흐름도는 프로세스 위주의 모델링 -개념모델링은 대부분 UML로 구성
CASE도구	-요구사항을 자동으로 분석하고 요구사항 분석 명세서를 기술하도록 개발된 자동화 도구 -SW생명주기의 전체 단계를 연결하여 자동화해주는 분석 자동화도구-> 소프트웨어를 개발하는 환경 조성 -표준화 적용과 문서화를 통한 보고로 품질 개선 가능 -변경사항과 변경으로 인한 영향에 대한 추적 용이 -명세에 대한 유지보수 비용 축소 -자동화된 기법으로 품질 향상, 모듈의 재사용성 향상, 유지보수 용이 -범용성과 이식성 -CASE의 원천 기술로는 구조적 기법, 프로토타이핑 기술, 자동프로그래밍기술, 정보 저장소 기술, 분산 처리 기술 사용 ✓ 상위케이스(Upper CASE) 다이어그램으로 표현. 모순검사, 오류검증, 일관성 검증, 자료흐름도 프로타이핑 작성 지원 및 UI설계 지원 ✓ 하위케이스(Lower CASE) 시스템 명세서 생성 및 소스코드 생성 지원, 구문 중심 편집 및 정적/동적 테스트 지원 ✓ 통합케이스(Interated CASE) SW 개발 주기 전체를 지원하는 통합케이스
요구사항 관리도구	-비용 편익 분석, 변경에 따른 추적, 변경에 따른 영향 평가  -요구사항 관리도구는 프로젝트 생성, 요구사항 작성, 요구사항 불러오기/내보내기, 요구사항 이력 관리, 요구사항 베이스라인, 요구사항 추적성, 협업 환경, 외부 인터페이스, 확장성 **요구사항 숨김 기능은 없쥬 -상용제품: 헬릭스, 지라, 오르카노스, 리큐테스트 -오픈소스: 레드마인, 테스트링크

UI	사용자 인터페이스, 사용자와 시스템 사이에서 의사소통가능한 물리적, 가상의 매개체(좁은 개념으로는 화면) -> CLI(정적 텍스트), GUI(그래픽 반응), NUI(직관적 사용자반응-터치,음성 등), OUI(유기적 상호 작용) -특징: 오류 최소화, 작업기능 구체화, 상화작용, 작업시간 감소  < UI설계 원칙 > • 직관성(쉬운 검색, 쉬운 사용성, 일관성) • 유효성(쉬운 오류 처리 및 복구) • 학습성(쉽게 학습, 쉬운 접근, 쉽게 기억) • 유연성(오류 예방, 실수 포용, 오류 감지) <UI 설계 프로세스> 문제 정의 → 사용자 모델 정의 → 작업 분석 → 컴퓨터 오브젝트 및 기능 정의 → 사용자 인터페이스 정의 → 디자인 평가 -UI 시스템의 필요 기능 사용자의 입력 검증, 에러 처리와 에러 메시지 처리, 도움과 프롬프트(지시메시지) 제공
인터랙션	입출력 장치를 매개로 디지털 시스템과 사람이 주고받는 일련의 의사소통 과정
UI 표준(큰 그림)	디자인 철학과 원칙 기반하에 전체 시스템에 공통으로 적용되는 화면 간 이동, 화면 구성 등에 관한 규약 <UI화면 구성요소-버튼/컨트롤 타입> 콤보 박스: 하나의 입력박스가 있는 상태에서 박스를 클릭하면 선택 가능한 목록이 길게 나타나는 요소 토글 버튼: 두 가지 상태 중 하나로 토글 텍스트 박스(텍스트 필드): 텍스트 한줄 또는 여러 줄 입력 라디오 버튼: 여러 개 옵션 중 1개의 옵션 선택 체크 박스: 여러 개 옵션 중 1개 이상의 옵션 선택(다중선택)
UI 지침(세부 가이드)	UI표준에 따라 사용자 인터페이스 설계, 개발 시 지켜야할 세부사항
UI 개발 기법	• 3C분석 • SWOT분석 • 시나리오 플래닝 • 사용성 테스트 • 워크숍
리서치	이미 존재하던 지식의 발견, 해석, 정정, 재확인에 초점을 맞추는 체계적인 조사
사용자 요구사항 도출	• 페르소나 정의 • 콘셉트 모델 정의-브레인 스토밍활용 • 사용자 요구사항 정의-요구사항 매트릭스와 정황 시나리오 • UI컨셉션
UI시나리오	완전성, 일관성, 이해성, 가독성, 추적 용이성, 수정 용이성
스토리보드	UI화면 설계를 위해 디자이너와 개발자가 참고하는 산출 문서 (구축하는 서비스를 위한 대부분의 정보가 수록된 문서)
와이어 프레임	스토리보드 안에 포함, 화면 단위의 레이아웃 설계
프로토타입	와이어 프레임이나 스토리보드에 동적 효과를 적용하여 실제 구현되는 것처럼 시뮬레이션
감성공학	-인간의 감성을 정성적/정량적으로 측정 및 평가하고 과학적으로 분석, 이를 구체적인 제품 설계로 실행해내는 공학 • 1류 접근 방법: 인간의 감성을 표현하는 어휘 이용, 제품 이미지를 조사하여 제품 디자인 요소에 연계 • 2류 접근 방법: 개인의 연령, 성별 등 개별적 특성과 감성적의 심리적 특성을 강조한 접근 • 3류 접근 방법: 기존의 감상적 어휘 대신 공학적 방법으로 수학적 모델을 구축하여 활용 -감성공학 기반으로 인터페이스를 구현하기 위한 기술에는 센서 및 센싱기술, 디스플레이 기술, 엑츄에이터 기술, 센서 퓨전 기술, 마이크로 머시닝 기술, 퍼지 뉴럴 네트워크 기술, 산업 디자인 기술 등

모듈	- 크게 독립된 하나의 소프트웨어 분해한 기능 단위 - 독립성, 다양한 조합, 재사용, 영향 최소화
공통 모듈	-전체 프로그램 기능 중 특정 기능을 처리할 수 있는 실행 코드 -자체적으로 컴파일 가능, 다른 프로그램에서 재사용 가능 -여러 기능 및 프로그램에서 공통으로 사용할 수 있는 모듈 <공통 모듈 원칙>정확성, 명확성, 완전성, 일관성, 추적성
모듈화	-시스템 프로그램의 효율성 향상을 위해 시스템을 분해하고 추상화 함으로써 제품의 성능 향상, 시스템의 수정 및 재사용, 유지 관리를 쉽게 하는 기법 -루틴, 메인루틴, 서브루틴
설계 모델링	• 구조 모델링 • 행위 모델링
SW 설계	<SW 설계 유형> • 자료 구조 설계 • 아키텍처 설계 • 인터페이스 설계 • 프로시저 설계 • 협약에 의한 설계-선행조건, 불변조건, 결과조건 <SW 설계 원리> • 상향식 설계 • 하향식 설계
코드설계	-사물을 표현하는 코드를 설계 표준화, 분류, 식별, 배열, 간소화, 연상, 암호화, 오류 검출 <코드 설계 종류> • 연상 코드(=기호코드): 코드만 보고 연상 가능한 형태로 구성 • 블록 코드(=구분코드): 공통성 있는 그룹을 지어 블록으로 구분하여 블록 내에서 코드 부여 • 순차 코드: 일정한 일련번호, 일정한 기준에 따라 순서대로 • 표의 숫자 코드: 물리적(유효한) 수치인 길이, 넓이, 용량등을 표시 • 십진 코드: 10진수 형태로 표현 • 그룹 분류식 코드: 대상을 기준에 따라 대/중/소로 구분하여 번호 부여 <코드 오류 종류> • 사본 오류(=필사 오류, 오자 오류, Transcription): 한 자리 잘못 표기 • 전위 오류(Transposition): 연속된 두 글자의 위치가 바뀌어 표기 • 생략 오류(Omission): 한 글자 빼먹고 기술 • 첨가 오류:한 글자 추가로 기술 • 이중 전위 오류: 전위 오류 중복 발생
HIPO(하이포)	-하향식 소프트웨어 개발을 위한 문서화 도구(분석 및 설계, 문서화 사용) -체계적인 문서 관리 가능 -기호, 도표 등을 사용해 보기 쉽고 이해가 쉬움 -기능과 자료의 의존 관계를 동시에 표현 -변경, 유지 보수가 용이 <HIPO차트> • 가시적 도표:시스템의 전체적인 기능과 흐름 • 총체적 도표:프로그램을 구성하는 기능, 입력/처리/출력에 대한 정보를 제공 • 세부적 도표:총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술
소프트웨어 아키텍쳐	-소프트웨어 아키텍처는 여러 가지 소프트웨어의 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 구성 요소 간의 관계를 표현하는 시스템 구조=> 설계도 -IEEE1471 국제표준의 소프트웨어 아키텍처 프레임워크 <소프트웨어 아키텍처 프레임워크 구성요소> 아키텍처 명세서, 이해관계자, 관심사, 관점, 뷰, 근거, 목표, 환경, 시스템 <소프트웨어 아키텍쳐 4+1 뷰> • 유스케이스 뷰 • 논리 뷰 • 프로세스 뷰 • 구현 뷰 • 배포 뷰(배치 뷰)
아키텍처 비용 평가 모델	-아키텍처 접근법이 품질 속성에 미치는 영향을 판단하고 아키텍처의 적합성을 평가하는 모델 <아키텍처 비용 평가 모델 종류> • SAAM: 초창기 모델, 경험이 없는 조직에서도 쉽게 활용 가능 • ATAM: 아키텍처 품질 속성(트레이드 오프 관계) • CBAM: ATAM 바탕의 코스트 기반 • ADR: 구성요소 간 응집도를 평가 • ARID: 전체가 아닌 특정부분에 대한 품질요소에 집중
아키텍처 패턴	• 계층화 패턴: 계층으로 구분 • 클라이언트-서버 패턴: 하나의 서버와 다수의 클라이언트 • 파이프-필터 패턴: 단방향 패턴. 필터에서 처리하고, 파이프를 통해 전달 • 브로커 패턴: 브로커가 컴포넌트 간의 통신을 조정하는 역할 • 모델-뷰-컨트롤러 패턴(MVC) • 마스터-슬레이브 패턴: 마스터와 슬레이브로 구성, 주로 실시간 시스템

객체 지향

- 실세계의 개체를 속성과 메서드가 결합한 형태의 객체로 표현하는 기법 <객체 지향 구성요소> • 클래스: 특정 객체 내에 있는 변수와 메서드 정의, 데이터를 추상화하는 단위 • 객체: 클래스에서 정의한 것을 토대로 메모리에 할당. 식별 가능한 대상으로 각각의 상태와 식별성을 가짐 • 메서드: 클래스로부터 생성된 객체를 사용하는 방법, 객체의 구체적인 연산, 함수 또는 프로시저 • 메시지: 객체에게 메서드를 지시(명령), 객체에서 객체로 전달 • 인스턴스: 실제로 메모리상에 할당되는 실제의 실형 객체 • 속성: 클래스 내에 속한 객체들이 가지고 있는 데이터 값들의 표현 값 <객체 지향 기법> • 캡슐화(Encapsulation): 서로 연관된 데이터와 함수를 묶어 외부와 경계를 만들고 필요한 것만 드러냄 • 상속성(Inheritance): 상위 클래스의 속성과 메서드를 하위 클래스에서 재정의 없이 사용 • 다형성(Polymorphism): 하나의 메시지에 대해 각각의 객체가 가지고 있는 고유한 방법으로 응답가능 • 추상화(Abstraction): 공통 성질을 추출하여 클래스를 설정( 불필요한 부분은 생략하고 개략화 ) • 정보은닉(Information Hiding): 특정 모듈의 세부 내용을 은폐하여 고려되지 않은 영향을 최소화 • 관계성(Relationship): 연관화, 집단화, 분류화, 일반화, 특수화 <SOLID원칙 = 객체 지향 설계 원칙>  • 단일 책임의 원칙: 하나의 클래스는 하나의 목적을 위해 생성되며 하나의 책임을 수행하는데 집중(SRP) • 개방 폐쇄 원칙: 구성요소들은 확장에는 열려있고, 변경에는 닫혀있어야 함(OCP) • 리스코프 치환의 원칙: 서브타입(하위클래스)은 자신의 기반 타입인 상위클래스로 교체가능 해야함(LSP) • 인터페이스 분리의 원칙: 한 클래스는 자신이 사요ㅇ하지 않은 인터페이스는 구현하지 말아야 함(ISP) • 의존성 역전의 원칙: 실제 사용관계는 바뀌지 않으며, 관계를 느슨하게 만드는 원칙(DIP) <객체 지향 방법론> • 야콥슨 OOSE: 유스케이스에 의한 접근 방법으로 모든 모델의 근간으로 유스케이스 사용 • 럼바우 OMT: "그래픽 표기법"이용 객체 모델링(객체 다이어그램-객체를 찾아 객체 들 간의 관계 정의) →동적 모델링(상태 다이어그램-시간의 흐름에 따라 제어흐름, 동작순서 등의 동적인 행위 표현) →기능 모델링(자료흐름도-자료 흐름을 중심으로 처리과정을 표현) • 부치 OOD: 설계 문서화 강조하여 다이어그램 중심으로 개발, 미시적/거시적 개발 프로세스 모두 사용 • Coad와 Yourdon: E-R다이어그램 사용하여 객체의 행위를 모델링. 객체 식별, 구조식별, 주체 정의, 속성 및 관계 정의, 서비스 정의 등의 과정으로 구성되는 객체 지향 분석 방법 • Wirfs-Brock: 분석과 설계 간의 구분이 없고 고객 명세서를 평가해 설계 작업까지 연속적으로 수행

디자인 패턴

-공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴 패턴의 이름, 문제 및 배경, 솔루션, 사례, 결과, 샘플코드로 구성 <디자인 패턴 유형에 따른 종류> "목적"에 따라 생성, 구조, 행위, "범위"에 따라 클래스, 객체 -생성패턴 생성(빌더/프로토타입/팩토리메서드/앱스트랙팩토리/싱글톤) 생빌 프로 팩앱싱 -구조패턴 구조(브릿지/데코레이터/퍼사이드/플라이웨이트/프록시/컴포지트/어댑터 ) 구 브데 퍼플 프록 컴 어 -행위패턴 생성, 구조에 안들어가면 행위^^ <디자인 패턴의 장단점> 장점- 재사용을 통한 개발 시간 단축, SW구조파악 용이, 품질과 생산성 향상 등 단점- 객체 지향 설계/구현 위조로 사용, 초기 투자 비용의 부담

기능적/비기능적 요구사항	-기능적 요구사항은 소프트웨어가 가져야하는 기능적 속성에 대한 요구사항 -비기능적 요구사항은 성능, 사용의 용의성, 실뢰도, 보안성, 운용상의 제약, 안전성 등 시스템 전반과 관련
요구공학	-사용자의 요구사항에 대한 도출, 분석, 명세, 확인과 검증하는 구조화 된 활동(도분명확) -효과적인 의사소통 수단을 제공하고, 시스템 개발의 요구사항에 대한 공통된 이해를 설정 -요구사항 누락 방지 및 이해 오류로 인한 불필요한 비용 절감, 요구사항 변경 추적 가능 <요구사항 명세 원리 및 검증 항목> 명확성, 완전성, 검증가능성, 일관성, 수정 용이성, 추적 가능성, 개발 후 이용성
요구사항 도출	인터뷰, 브레인스토밍, 델파이기법, 롤플레잉, 워크숍, 설문조사 등
요구사항 분석	<분석의 단계> 요구사항 분류→개념모델링생성→요구사항 할당→요구사항 협상→정형분석 **정형분석이란 구문과 의미를 갖는 정형화된 언어를 사용하여 수학적 기호로 표현
요구사항 명세	• 비정형 명세 기법 • 정형 명세 기법 => 요구사항 명세 단계의 산출물로 요구사항 명세서(최종 산출물)
요구사항 확인 및 검증	<확인 및 검증 단계>요구사항 목록 확인→요구사항 정의서 작성 여부 확인→비기능적 요구사항의 확인→타 시스템 연계 및 인터페이스 요구사항 확인 <요구사항 확인 및 검증 단계 주요 기법> -요구사항 검토: 시스템 정의서, 사양서, 요구사항 명세서를 완성한 시점에서 검토 -정형 기술 검토(FTR): 동료 검토, 워크스루(비공식/비형식), 인스펙션(공식/형식) -프로토타이핑 활용, 모델검증, 테스트 케이스 및 테스트를 통한 확인, CASE도구 활용 검증, 베이스 라인을 통한 검증, 요구사항 추적표(RTM)
시스템	-시스템은 하나의 공통적인 목적을 수행하기 위해 조직화된 요소들의 집합체 -입력, 출력, 처리, 제어, 피드백
시스템 아키텍처	<시스템 아키텍처 물리 설계> • 1-Tier • 2-Tier • 3-Tier
내외부 송수신 연계방식	-직접 연계방식 & 간접 연계방식 <내외부 송수신 연계방식의 기술> • DB 링크: DB 링크를 직접 참조(수신시스템에서 생성한 DB 링크) • DB 연결: DB 커넥션 풀을 생성해 연결 • API/Open API: API명, 입출력 파라미터 정보 필요 • JDBC: JDBC드라이버 이용 • 하이퍼링크: 웹 애플리케이션에서 하이퍼링크 이용 • 소켓: 서버에서 통신을 위한 소켓을 생성해 포트를 할당 <내외부 송수신 통신유형> • 단방향: 상대 시스템의 응답이 필요 없는 업무에 사용 • 양방향: 시스템 간에 상호 요청 • 동기: 거래 요청을 하고 응답까지 "대기"하는 방식 • 비동기: 요청을 보내고 다른 작업을 하다가 데이터가 준비되었다는 신호를 받으면 다시 처리 • 지연처리: 비동기 / 단방향과 유사, 순차 처리 및 지연 처리가 필요한 업무  => 단방향, 양방향, 동기, 비동기, 지연처리는 실시간 통신 • DB/FILE거래(배치 통신): 정해진 시간에 통신을 수행
인터페이스 오류 유형	• 연계 서버 오류: 연계 서버 장애나 오류, 연계 서버 다운이나 송수신 시스템 접속 오류 등 • 송신 시스템 연계 오류: 접근 권한이나 예외 상황 미처리 등으로 인한 오류, 미등록 코드로 코드 맵핑 오류 • 연계 데이터 오류: 연계 데이터 값이 유효하지 않음으로 인해 발생하는 오류 • 수신 시스템 연계 오류: 접근 권한이나 예외 상황 미처리 등으로 인한 오류, 데이터 등록/갱신오류 <인터페이스 오류코드> 오류코드와 오류 내용
인터페이스 설계	-인터페이스 목록과 인터페이스 정의서를 통해 구현 <인터페이스 정의서 주요항목>  인터페이스 ID, 최대 처리 횟수, 데이터 크기(평균/최대), 시스템 정보, 데이터 정보
미들웨어	-미들웨어는 클라이언트와 서버 간의 통신을 담당하는 SW (컴퓨터와 컴퓨터 간의 연결을 쉽고 안전하게 관리) <미들웨어 솔루션 유형> • DB미들웨어 • 원격 프로시저 호출(RPC) • 메시지 지향 미들웨어(MOM) • 트랜잭션 처리 모니터(TP모니터) • 레거시웨어: 기존의 시스템에 새로 업데이트된 기능을 덧붙이고자 할때 사용되는 미들웨어 • 객체 기반 미들웨어(ORB): 코바 표준 스펙 구현 • WAS: 서버계층에서 애플리케이션이 동작할 수 있는 환경 제공, 안정적인 트랜잭션 처리와 관리, 다른 이기종 시스템과의 애플리케이션 연동을 지원하는 미들웨어
EAI&ESB