정보처리기사 - 소프트웨어 설계

참고 블로그 링크텍스트

정처기 필기

[ 문제 파악 ]
1. 소프트웨어 설계
2. 소프트웨어 개발
3. 데이터베이스 구축
4. 프로그래밍 언어 활용
5. 정보시스템 구축 관ㄹㅣ

소프트웨트웨어 설계

• 폭포수 모형 ( Waterfall Model )
  가장 오래되고 가장 폭넓게 사용된 고전적 생명 주기 모형
  한 단계가 끝나야만 다음 단계로 넘어가는 선형 순차적 모형
  단계별 정의 및 산출물이 명확
  개발 중간에 요구사항의 변경이 용이하지 않음
  타당성 검토 -> 계획 -> 요구 분석 -> 설계 -> 구현 (프로그래밍) -> 테스트
  (검사) -> 유지보수

• 원형 모형 ( Prototype Model )
  견본품(시제품)을 만들어 최종 결과물을 예측하는 모형
  인터페이스에 중점을 두어 개발
  개발 중간에 요구사항 변경이 용이하다

• 나선형 모형 ( Spiral Model ) *
  폭포수 모형과 원형 모형의 장점에 위험 분석 기능을 추가한 모형
  점진적 개발 과정 반복으로 요구사항 추가 가능
  정밀하고 유지보수 과정 필요 없음
  계획 및 정의 -> 위험 분석 -> 공학적 개발 -> 고객 평가

• 애자일 모형 ( Agile Model ) *
  애자일은 민첩함, 기민함을 의미함
  변화에 유연하게 대응 가능
  일정한 주기를 반복하면서 개발 과정 진행
  절차와 도구보다 고객과의 소통에 초점을 맞춤
  ex) XP, 스크럼, 칸반, 크리스탈, 린 => 기능 중심 개발

스크럼기법

: 팀원 스스로가 스크럼 팀 구성
: 개발 작업에 관한 모든 것을 스스로 해결해야함
: 스프린트는 2~4주 정도의 기간으로 진행

1) 제품 책임자 ( Product Owner )

• 요구사항이 담긴 백로그를 작성하는 주체
• 백로그에 대한 우선 순위를 지정, 이해 관계자들의 의견을 종합

2) 스크럼 마스터 ( Scrum Master )

• 일일 스크럼 회의 주관
• 팀원들을 통제하는 것이 목표가 아님

3) 개발팀

• 제품 책임자와 스크럼 마스터를 제외한 모든 팀원
• 최대 인원 5~7명

4) 스크럼 개발 프로세스

• 스프린트 계획 회의 -> 스프린트 -> 일일 스크럼 -> 스크럼 검토 회의 -> 스프린트 회고

XP 기법

1) XP (eXtreme Programming)의 책심 가치 *

• 용기, 단순성, 의사소통, 피드백, 존중

2) XP의 기본 원리

• Whole Team
• Small Release
• Test-Driven Development
• Countinuous Intergration
• Collective Ownership
• Pair Programming
• Design Improvement

개발 기술 환경 파악

1) 운영체제 ( Opertaing System )

• 소프트웨어
• 가용성, 성능, 기술지원, 구축 비용, 주변기 기기

2) 미들웨어

• 운영체제와 응용 프로그램 사이에서 추가적인 서비스를 제공하는 소프트웨어

3) 데이터베이스 관리 시스템

• 사용자와 데이터베이스 사이에서 정보를 생성하고 데이터베이스를 관리하는 소프트웨어
• 데이터베이스의 구성, 접근 방법, 유지관리에 대한 모든 책임을 짐
• JDBC ( Java Database Connectiviry ), ODBC ( Open Database Connectivity )
• Oracle, MySQL, SQLite, MongoDB, Redis ...
• 가용성, 성능, 기술 지원, 구축 비용, 상호 호환성 ( 고려 사항 ) *

4) 웹 어플리케이션 서버 ( Web Application Servise )

• 정적인 콘텐츠를 처리하는 웹서버와 반대됨
• 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어
• 데이터 접근, 세션 관리, 트랜잭션 관리등을 위한 라이브러리를 제공
• Tomcat, JEUS, WebLogic, JBoss, Resin...
• 가용성, 성능, 기술지원, 구축 비용

5) 오픈 소스

• 누구나 별다른 제한없이 사용할 수 있도록 소스코드를 무료로 사용할 수 있게 공개한 것
• 라이선스의 종류, 사용자 수, 기술의 지속 가능성

요구사항 정의

1) 기능 요구 사항

• 기능, 입력, 출력, 저장, 수행 등등

2) 비기능 요구 사항

• 성능, 품질, 제약사항, 호환성, 보안 등등

3) 요구사항 개발 프로세스 *

• 도출/추출 -> 분석 -> 명세 -> 확인/검증

4) 요구사항 분석 기법 *

• 요구사항 분류
• 개념 모델링 ( UML )
• 요구사항 할당
• 요구사항 협상
• 정형 붕석

5) 요구사항 확인 기법 **

• 요구사항 검토
• 프로토타이핑
• 모델 검증
• 인수 테스트 ( 알파테스트, 베타테스트 )

UML

: Unified Modeling Language

1) UML의 구성요소

• 사물
• 관계
• 다이어그램

1)
-1 구조, 행동, 그룹, 주해
-2 관계 : 연관, 집합, 포함, 일반화, 의존, 실체화
-3 구조적, 정적 다이어그램 : 클래스, 객체, 컴포넌트, 배치, 복합체 구조, 패키지
-4 행위, 동적 다이어그램 : 유스케이스, 시퀀스, 커뮤니케이션, 상태, 활동, 상호작용개요, 타이밍

사용자 인터페이스

1) UI의 구분 *

• CLI ( Command Line Interface ) : 텍스트 형태 ( 키보드 조작, 터미널 환경 )
• GUI ( Graphical User Interface ) : 그래픽 환경의 인터페이스 ( 마우스 조작 가능 )
• NUI ( Natural User Interfase ) : 사용자의 말이나 행동으로 기기를 조작하는 인터페이스
• VUI ( Voice User Interface ) : 사람의 음성으로 기기를 조작하는 인터페이스
• OUI ( Organic User Interface ) : 모든 사물과 사용자간의 상호작용을 위한 인터페이스

2) UI의 기본 원칙 **

• 직관성 : 누구나 쉽게 이해하고 사용 가능해야함
• 유효성 : 사용자의 목적을 정확하고 완벽하게 달성해야함
• 학습성 : 누구나 쉽게 배우고 익힐 수 있어야함
• 유연성 : 사용자의 요구사항을 최대한 수용하고 실수를 최소화해야함

3) 웹의 3요소

• 웹 표준
• 웹 접근성
• 웹 호환성

4) UI 설계 도구

• 와이어프레임 : 레이아웃을 협의하거나 공유하기위해 사용
• 스토리보드 : 최종적으로 참고하는 작업 지침서, 작업 산출물
• 프로토타입 : 인터랙션을 적용해 실제 구현된 것 처럼 테스트가 가능한 동적인 모형
• 목업 : 실제 화면과 유사한 정적인 모형
• 유스케이스 : 사용자 측면 요구사항을 다이어그램 형식으로 묘사 ( 유스케이스 명세서 )

5) UI 프로토타입

• 장점 : 사용자를 설득하고 이해시키기 쉬우며 개발 시간을 줄일 수 있고 사전 오류 발견 가능
• 단점 : 반복적인 개선 및 보완 작업으로 인한 작업 시간 증가 및 자원 소모, 부분적인 프로토타이핑으로 인한 중요한 작업 생략 가능

6) UI 시나리오 문서 요건

• 이해성 : 누구나 쉽게 이해할 수 있도록 설명
• 완전성 : 최대한 상세하게 기술
• 일관성 : 일관성 유지
• 가독성 : 표준화된 템플릿 등을 활용하여 문서를 쉽게 읽을 수 있도록 해야함
• 수정 용이성 : 수정 및 개선이 쉬워야함
• 추적 용이성 : 변경사항에 대해서 쉽게 추적할 수 있어햐 함

7) 기타

• HCI ( Human Computer Interaction or Interface ) : 사람과 컴퓨터의 상호작용을 연구해서 사람이 컴퓨터를 편리하게 사용하도록 만드는 학문
• UX ( User Experience ) : 사용자가 시스템이나 서비스를 이용하면서 느끼고 생각하는 총체적인 경험 주관성, 정황성, 총체성을 가짐
• 감성 공학 : 1류 - 인간의 감성 , 2류 - 심리적 기능, 3류 - 공학적 및 수학적 모델, 객관적

품질 요구사항

1) 국재 재품 품질 표준

• ISO/IEC 9126
• ISO/IEC 12119
• ISO/IEC 14598
• ISO/IEC 25000 : SW 품질 평가 통합 모델, SQualRE로도 불리며 위 3개 표준 통함
  품질 관리(2500n), 품질 모델(2501n), 품질 요구(2503n), 품질 평가(2504n)

2) ISO/IEC 9126 **

• 기능성 : 요구사항을 정확하게 만족하는 기능을 제공하는가?
  *적절성, 정확성, 상호 운용성, 보안성, 호환성

• 신뢰성 : 요구된 기능을 정확하고 일련되게 오류없이 수행하는가?
  *성숙성, 결함 허용성, 회복성

• 사용성 : 사용자가 정확하게 이해하고 사용하는가?
  *이해성, 학습성, 운용성, 친밀성

• 효율성 : 할당된 시간동안 한정된 자원으로 얼마나 빨리 처리하는가?
  *시간 효율성, 자원 효율성

• 유지 보수성 : 환경의 변화에 소프트웨어를 쉽게 개선, 확장, 수정할 수 있는가?
  *분석성, 변경성, 안전성, 시험성

• 이식성 : 소프트웨어를 다른 환경에서도 쉽게 적용할 수 있는가?
  *적용성, 설치성, 대체성, 공존성

3) ISO/IEC 14598

• 반복성
• 재현성
• 공정성
• 객관성

4) 국제 프로세스 품질 표준

• ISO/IEC 9001
• ISO/IEC 12207 : 기본 프로세스, 조직 프로세스, 지원 프로세스
• ISO/IEC 15504 : 불완전 -> 수행 -> 관리 -> 확입 -> 예측 -> 최적화
• CMMI (Capability Maturity Model Integration) : 조직차원의 성숙도를 평가하는 단계별 표현과 프로세스 영역별 능력도를 평가하는 연속적 표현이 있음

소프트웨어 아키텍처

: 사용자의 비기능적 요구사항으로 나타난 제약 반영
: 기능적 요구사항을 구현하는 방법을 찾는 해결 과정

1) 모듈화

• 시스템의 기능들을 모듈 단위로 나눠 소프트웨어의 성능 및 재사용성을 향상시키는 것
• 모듈의 크기가 크면 모듈의 개수가 적고, 모듈간 통합 비용은 적으나 모듈 하나의 개발 비용이 큼
• 모듈의 크기가 작으면 모듈의 개수가 많고, 모듈간 통합 비용이 큼

2) 추상화

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

3) 단계적 분해

• 니콜라스 월스에 의해 제안된 하향식 설계 전략
• 추상화의 반복에 의한 세분화
• 소프트웨어 기능에서부터 시작해 절차적으로 구체화
• 상세한 내역은 최대한 후에 진행

4) 정보 은닉

• 한 모듈 내부에 포함된 저라와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
• 정보 은닉을 통한 독립적 모듈 수행 가능
• 모듈 변경 시 영향을 받디 않아 수정, 시험, 유지보수가 용이

아키텍처 패턴

1) 레이어 패턴

• 시스템을 계층으로 구분하여 구성하는 고전적 방법

2) 클라이언트-서버 패턴

• 하나의 서버 컴포넌트와 다수 클라이언트 컴포넌트로 구성되는 패턴
• 클라이언트나 서버는 요청과 응답을 받기 위해 동기화되는 경우를 제외하고는 서로 독립적
• 컴포넌트 : 독립적인 업무 또는 기능을 수행하는 실행 코드 기반으로 작성된 모듈

3) 파이프-필터 패턴

• 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화해 파이프를 통해 데이터를 전송하는 패턴
• 필터 컴포넌트는 재사용성이 좋고, 추가가 쉬워 확장 용이
• 필터 컴포넌트들을 재배치하여 다양한 파이프라인 구축 가능

4) 모델-뷰-컨트롤러 패턴 **

• 서브시스템을 3개의 부분으로 구조화하는 패턴
• 모델 : 서브시스템의 핵심 기능과 데이터를 보관
• 뷰 : 사용자에게 정보를 표시
• 컨트롤러 : 사용자로부터 받은 입력 처리/ 뷰 제어/ UI 담당
• 각 부분은 별도의 컴포넌트로 분리되어 있으므로 서로 영향을 받지 않고 개발 작업 수행
• 한 개의 모델에 대해 여러개의 뷰를 만들 수 있으므로 대화형 애플리케이션에 적합

5) 마스터-슬레이브 패턴

• 마스터 컴포넌트에서 슬레이브 컴포넌트로 분할한 후, 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는 방식으로 작업을 수행하는 패턴
  *장애 허용 시스템, 병렬 컴퓨팅 시스템

6) 프로커 패턴

• 컴포넌트와 사용자를 연결해주는 패턴
  *분산 환경 시스템

7) 피터-투-피어 시스템

• 피어를 하나의 컴포넌트로 간주하며, 각 피어는 서비스를 호출하는 클라이언트가 될 수도 있고 서비스를 제공하는 서버가 될 수도 있음
  *멀티스레딩 방식 허용

8) 이벤트-버스 패턴

• 소스가 특정 채널에 이벤트 메시지를 발행하면, 해당 채널을 구독한 리서느들이 메시지를 받아 이벤트를 처리하는 방식
• 이벤트를 생성하는 소스, 이벤트를 수행하는 리스너, 이벤트의 통로인 채널, 채널을 관리하는 버스

9) 블랙보드 패턴

• 해결책이 명확하지 않은 문제를 처리하는데 유용한 패턴

10) 인터프리터 패턴

• 특정 언어로 작성된 프로그램 코드를 해석하는 컴포넌트를 설계할 대 사용됨

객체 지향

1) 객체

• 독립적으로 식별 가능한 이른을 가지고 있은
• 객체가 가질 수 있는 조건인 상태는 일반적으로 시간에 따라 변함
• 객체와 객체는 상호연관성에 의한 관계가 형성됨
• 객체가 반응할 수 있는 메시지의 집한을 행위라고 하며, 객체는 행위의 특징을 나타냄
• 객체는 일정한 기억장소를 갖고 있음

2) 클래스 **

• 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현한 것
• 공통된 속성과 연산을 갖는 객체의 집합
• 객체 지향 프로그램에서 데이터를 추상화하는 단위
• 각각의 객체들이 갖는 속성과 연산을 정의하고 있는 틀
• 슈퍼 클래스는 특정 클래스의 상위 클래스
• 서브 클래스는 특정 클래스의 하위 클랙스

3) 인스턴스

• 클래스에 속한 각각의 객체
• 클래스로부터 새로운 객체를 생성하는 것을 인스턴스화라고 함

4) 메서드

• 클래스로부터 생성된 객체를 사용하는 방법
• 전통적 시스템의 함수 또는 프로시저에 해당하는 연산

5) 메시지

• 객체에게 어떤 행위를 하도록 지시하기 위한 방법\

6) 캡슐화 *

• 데이터와 데이터를 처리하는 함수를 하나도 묶는 것
• 인터페이스를 제외한 세부 내용이 은폐되어 외부 접근이 제한됨

7) 상속

• 이미 정의된 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것
• 소프트웨어의 재사용을 높이는 중요한 개념

8) 다중 상속

• 한개의 클래스가 두 개 이상의 상위 클래스로부터 속성과 연산을 상속받는 것

9) 다형성

• 하나의 메시지에 대한 각각의 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력

결합도

: 모듈간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계를 의미
: 결합도는 낮을수록 좋다 => 독립적인 모듈

1) 내용 결합도

• 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할때의 결합도

2) 공통 결합도

• 공유되는 공통 데이터 영역을 여러 모듈이 사용할때의 결합도 ( 전역 변수 )

3) 외부 결합도

• 어떤 모듈에서 선언한 데이터를 외부의 다른 모듈에서 참조할 때의 결합도 (순차적)

4) 제어 결합도

• 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기위해 제어 신호를 이용하여 통신하거나 제어 요소를 전달하는 결합도

5) 스탬프 결합도

• 모듈간의 인터페이스로 배열이나 레코드등의 자료구조가 전달될 때의 결합도

6) 자료 결합도

• 어떤 모듈이 다른 모듈을 호출하면서 매개변수나 인수로 데이터를 넘겨주고, 호출받은 모듈은 받은 데이텅 ㅔ대한 처리 결과를 다시 돌려주는 결합도

응집도

: 모듈의 내부 요소들의 서로 관련되어있는 정도
: 응집도는 높을수록 독립적인 모듈이다.

1) 우연적 응집도

• 모듈 내부의 각 구성 요소들이 서로 관련없는 요소로만 구성된 경우의 응집도

2) 논리적 응집도

• 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우의 응집도

3) 시간적 응집도

• 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도

4) 절차적 응집도

• 모듈이 다수의 관련 기능을 가질 때 모듈안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도

5) 통신적 응집도

• 동일한입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우의 응집도

6) 순차적 응집도

• 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동의 입력 데이터로 사용할 경우의 응집도

7) 기능적 응집도

• 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도

공통 모듈

1) 정확성

• 시스템 구현시 해당 기능이 필요하다는 것을 알 수 있도록 정확히 작성

2) 명확성 *

• 해당 기능에 대해 일관되게 이해되고, 한 가지로 해석될 수 있도록 명확하게 작성

3) 완전성

• 시스템 구현을 위해 필요한 모든 것을 기술
  4) 일관성
• 공통 기능들 간에 상호 충돌이 발생하지 않도록 작성

5) 추적성

• 기능에 대한 요구사항의 출처, 관련 시스템등의 관계를 파악할 수 있도록 작성

6) 재사용 규모에 따른 분류 *

• 함수와 객체
• 컴포넌트
• 애플리케이션

코드

: 식별, 분류, 배열, 간소화, 표준화, 연상, 암호화, 오류 검출

1) 순차 코드 *

• 일장 기준에 따라 최초의 자료부터 차례로 일련 번호를 부여하는 방법

2) 블록 코드 *

• 공통성이 있는것끼리 블록으로 구분하고, 각 블록내에서 일련 번호를 부여하는 방법

3) 10진 코드 *

• 0부터 9까지 10진 분할하고, 다시 각각에 대해 10진 분할하는 방법을 필요한 만큼 반복하는 방법

4) 그룹 분류 코드

• 일정 기준에 따라 대분류, 중분류, 소분류등으로 구분하고 , 각 그룹안에서 일련 번호를 부여하는 방법

5) 연상코드

• 명칭이나 약호와 관계있는 숫자나 문자, 기호를 이용하여 코드를 부여하는 방법

6) 표의 숫자 코드 *

• 길이, 넓이, 부피, 지름, 높이등의 물리적 수치를 그대로 코드에 적용시키는 방법

7) 합성 코드

• 2개 이상의 코드를 조합하여 만드는 방법

8) 모드 부여 체계

• 이름만으로 개체의 용도와 적용범위를 알 수 있도록 코드를 부여하는 방식
• 각 개체에 유일한 코드를 부여하여 개체들의 식별 및 추출을 용이하게 함
• 코드를 부여하기 전 각 단위 시스템의 고유한 코드와 개체를 나타내는 코드가 정의되어야 함

디자인 패턴

: 아키텍처 패턴이 디자인 패턴보다 상위 수준의 설계에 사용됨
: 서브시스템에 속하는 컴포넌트들과 그 관계를 설계하기 위한 참조 모델

1) 생성 패턴 *

• 추상 팩토리 : 서로 연관, 의존하는 객체들을 그룹으로 생성해 추상적으로 표현
• 빌더 : 객체의 생성 과정과 표현 방법 분리 -> 동일한 객체 생성에도 서로 다른 결과
• 팩토리 메소드 : 객체를 생성하기 위한 인터페이스를 정의하여, 어떤 클래스가 인슽ㄴ스화 될 것인지는 서브클래스가 결정하도록 하는 것
• 프로토타입 : 원본 객체를 복제하는 방법
• 싱글톤 : 하나의 객체를 여러 프로세스가 동시에 참조할 수 없음

2) 구조 패턴

• 어댑터 : 호환성이 없는 클래스 인터페이스를 이용할 수 있도록 변환해주는 패턴
• 브리지 : 구현부에서 추상층을 분리하여, 독립적으로 확장 및 다양성을 가지는 패턴
• 컴포지트 : 여러 객체를 가진 복합, 단일 객체를 구분없이 다룰 때 사용하는 패턴
• 데코레이터 : 상속ㅇ들 사용하지 않고도 객체의 기능을 동적으로 확장해주는 패턴
• 퍼싸드 : 서브 클래스들의 기능을 간편하게 사용할 수 있도록 하는 패턴
• 플라이웨이트 : 공유해서 사용함으로써 메모리를 적약하는 패턴
• 프록시 : 접근이 어려운 객체를 연결해주는 인터페이스 역할을 수행하는 패턴

3) 행위 패턴

• 책임 연쇄 : 한 객체가 처리하지 못하면 다음 객체로 넘어가는 패턴
• 커맨드 : 요청에 사용되는 각종 명령어들을 추상, 구체 클래스로 분리하여 단순화함
• 인터프리터 : 언어에 문법 표현을 정의하는 패턴
• 반복자 : 동일한 인터페이스를ㅇ 사용하도록 하는 패턴
• 중재자 : 서로의 존재를 모르는 상태에서도 협력할 수 있게 하는 패턴
• 메멘토 : 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴
• 옵서버 : 관찰 대상의 변화를 탐지하는 패턴
• 상태 : 객체의 상태에 따라 동일한 동작을 다르게 처리해야할 떄 사용하는 패턴
• 전략 : 클라이언트에 영향을 받지 않는 독립적인 알고리즘을 선택하는 패턴
  템플릿 메소드 : 유사한 서브 클래스를 묶어 공통된 내용을 상위 클래스에 정의하는 패턴
  방문자 : 필요할 떄 마다 해당 클래스에 방문해서 처리하는 패턴

인터페이스 요구사항 검증

1) 요구사항 검증

• 인터페이스 요구사항 검토 계획 수립 -< 검토 및 오류 수정 -> 베이스라인 설정

2) 요구사항 검증 방법 **

• 동료 검토 : 요구사항 명세서 작성자가 내용을 직접 설명하고 동료들이 이를 들으면서 결함을 발견하는 검토 방법
• 워크 스루 : 검토 회의 전에 요구사항 명세서를 미리 배포하여 서ㅏ전 검토한 후, 짧은 검토 회의를 통해 결함을 발견하는 검토 방법
• 인스펙션 : 요구사항 명세서 작성자를 제외한 다른 검토 전문가들이 확인하면서 결함을 발견하는 검토 방법

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

• 기능성
• 완전성
• 일관성
• 명확성
• 검증 가능성
• 추적 가능성
• 변경 용이성

인터페이스

1) 인터페이스 식별

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

2) 인터페이스 시스템 식별

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

3) 인터페이스 표준 항목

• 시스템 공통부 : 시스템 간 연동 시 필요한 공통 정보
  인터페이스 아이디, 전송 시스템 정보, 서비스 코드 정보, 응답 결과 정보, 장애 정보
• 거래 공통부 : ㅣ스템들이 연동된 후 송, 수신되는 데이터를 처리할 떄 필요한 정보
  직원 정보, 승인자 정보, 기기 정보, 매체 정보

인터페이스 방법 명세화

1) 시스템 연계 기술 **

• 직접 연계 방식
  -- DB 연결 : 수신 시스템의 WAS에서 송신 시스템 DB로 연결하는 DB 커넥션 풀을 생성하고 연계 프로그램에서 해당 DB 커넥션 폴명을 이용
  -- API/Open API : 송신 시스템의 DB에서 데이터를 읽어와 제공하는 애플리케이션 프로그래밍 인터페이스 프로그램
  -- JDBC : 수신 시스템의 프로그램에서 JDBC 드라이버를 이용하여 송신 시스템의 DBㅘ 연결
  -- 하이퍼 링크 : 웹 애플리케이션에서 하이퍼링크 이용
  -- 연계 솔루션 : EAI 서버와 송, 수신 시스템에 설치되는 클라이언트를 이용하는 방식

• 간접 연계 방식

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

-- 웹 서비스 : 웹 서비으에서 WSDL, UDDI, SOAP 프로토콜을 이용해 연계하는 서비스

• WSDL : 웹 서비스와 관련된 서식이나 프로토콜등을 표준적인 방법으로 기술하고 게시하기 위한 언어
• UDDI : 인터넷에서 전 세계의 비즈니스 업체 목록에 자신의 목록을 등록하기 위한 확장성 생성 언어 기반의 규격
• SOAP : 웹 서비스를 실제로 이이ㅛㅇ하기 위한 객체간의 통신 규약
• ESB : 개방형 표준인 웹 서비스를 이용하며 메시징과 웹 서비스, 데이터 변형, 인텔리전트 라우팅을 결합하여 다양한 애플리케이션간의 연결과 상호작용을 지원하는 표준기반의 미들웨어 플랫폼

2) 인터페이스 통신 유형

• 단방향 : 시스템에서 거래 요청만 하고 응답은 없는 방식
• 동기 : 시스템에서 거래 요청 후 응답이 올 때 까지 대기하는 방식
• 비동기 : 시스템에서 거래 요청 후 다른 작업을 수행하닥 응답이 오면 처리하는 방식

3) 인터페이스 처리 유형

• 실시간 방식 : 사용자가 요청한 내용을 바로 처리해야 할 때
• 지연 처리 방식 : 매건 단위 처리로 비용이 많이 발생할 때 사용하는 방식
• 배치 방식 : 대량의 데이터를 처리할 떄

4) 인터페이스 발생 주기

• 매일, 수시, 주 1회 등..

미들웨어 솔루션 명세

: 운영체계와 해당 운영체제에서 실행되는 응용 프로그램 사이에서 운영체제가 제공하는 서비스 이외에 추가적인 서비스를 제공하는 소프트웨어

1) DB

• 클라이언트에서 원격의 데이터베이스와 연결하기 위한 미들웨어

2) RPC

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

3) MOM

• 메시지 기반의 비동기형 메시지를 전달하는 방식

4) TP-Monitor

• 항공기나 철도 예약 업무등과 같은 온라인 트랙잭션 업무에서 트랜잭션을 처리 및 감시하는 미들웨어
• 사용자수가 증가해도 빠른 응답 속도를 유지해야하는 업무에 주로 사용됨

5) Legacyware

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

6)ORB

• 객체 지향 미들웨어로 코바 표준 스펙을 구현한 미들웨어
• 코바 : 네트워크에서 분산 프로그램 객체를 생성, 배포 , 관리하기위한 규격을 의미

7) WAS

• 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기위해 사용되는 미들웨어
• 클라이언트/ 서버 환경보다는 웹 환경을 구현하기 위한 미들웨어
• HTTP 세션 처리를 위한 웹서버 기능뿐 아니라 미션-크리티컬한 기업 업무까지 자바, EJB 컴포넌트 기반으로 구현이 가능