참고서적 : 수제비 (2022)
올해는 대학교를 졸업하는 과정에 있다. 휴학을 할 수도 있지만, 왠만하면 올 해 졸업하려고 한다.
졸업을 하기 위해선 다양한 조건이 있는데 그 중 하나가 정보처리기사 자격 취득이다.
오늘 기준으로 6일이 남았기에, 최근에는 다른 개발공부에 집중하지 못하고 기사 자격증에 집중했다.
그래서 개념과 기출문제를 학습한 내용을 바탕으로 노트에 정리 후 암기하면서 블로그에 한번 더 정리해보려고 한다.
(정리한 내용은 기출문제 및 과거에 나왔던 문제들을 기반으로 할 것이다.)
* 플랫폼 성능 특성 측정 항목
= 경과시간, 사용율, 응답시간, 가용성
* 요구사항 분석 기술
-분석절차-1. 요구사항 분류
2. 개념 모델링 및 생성 및 분석
3. 요구사항 할당
4. 요구사항 협상
5. 정형 분석
= 청취기술, 인터뷰와 기술 질문, 분석 기술, 중재기술, 관찰기술, 작성기술, 조직기술, 모델 작성기술
* 요구사항 분석에 사용하는 기능 모델링 기법
1. 데이터 흐름도 (DFD : Data Flow Diagram)
㉮ 개념 : 데이터가 각 프로셀스를 따라 흐르면서 변환되는 모습을 나타낸 그림으로 '자료흐름 그래프' 또는 '버블(bubble)차트 라고도 한다.
㉯ 특징 : 데이터의 흐름에 중심을 두며 제어의 흐름은 중요하지 않다.
㉰ 구성요소 : 처리기(Process)
데이터 흐름(Data Flow)
데이터 저장소(Data Store)
단말(Terminator)
2. 자료 사전(DD : Data Dictonary)
㉮ 개념 : 자료들의 요소, 집합, 흐름, 범위, 단계 등을 구체적으로 명시하는 사전
㉯ 자료사전 기호 // = : 정의로서 '~으로 구성되어 있다'를 나타내는 기호
+ : 자료의 연결을 나타내는 기호
() : 생략가능함을 나타내는 기호
{} : 자료의 반복을 나타내는 기호
[] : 자료의 선택을 나타내는 기호
** : 자료의 설명을 나타내는 기호
* 요구사항 분석이 어려운 경우
1. 개발자와 사용자 간 지식이나 표현의 차이로 인해 상호 이해가 쉽지가 않음
2. 사용자의 요구사항이 불명확함
3. 개발과정 中 요구사항이 계속 변할 수 있음.
4. 사용자 요구는 예외가 많아 열거와 구조화가 어려운 편
* UML
㉮ 개념 : 객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화 할 때 사용되는 모델링 기술과 방법론을 통합해서 만든 표준화 된 범용 모델링 언어
㉯ 구성요소 : 1. 사물(Thing) -- 주제를 나타내는 요소
2. 관계(RelationShip) -- 사물의 의미를 확장하고 명확히 하는 요소
3. 다이어그램(Diagrams) -- 사물과 관계를 모아 그림으로 표현한 형태
㉰ UML 다이어그램 : 구분에 따라 '구조적(정적) 다이어그램'과 '행위적(동적)다이어그램'으로 구분한다.
- 구조적(정적) 다이어그램의 종류에는 클래스, 객체, 컴포넌트, 배치, 복합체 구조, 패키지가 있다.
- 행위적(동적) 다이어그램의 종류에는 유스케이스, 시퀸스. 커뮤니케이션, 상태, 활동, 타이밍이 있다.
㉱ UML 상세
- 클래스 다이어그램 : 클래스와 클래스 즉, 클래스 속성 사이의 관계를 표현한다.
구성요소 : 클래스 이름(Class name) : 클래스 이름
속 성(Attribute) : 클래스 특성에 이름 부여
연 산(Operation) : 클래스에 속하는 객체에 적용될 메서드의 정의
접근제어자(Access modifier) : 클래스에 접근할 수 있는 정도를 표현
<접근 제어자에는 다음과 같은 기호가 존재한다>
- : 내부 접근만 허용(Private)
+ : 외부 접근 허용(Public)
# : 동일 패키지, 파생 클래스에서 접근 가능(Protected)
~ : 동일 패키지에서 접근 가능(Default)
* 유스케이스 다이어그램
㉮ 개념 : 시스템이 제공하고 있는 기능 및 그와 관련된 외부 요소를 사용자의 관점에서 표현하는 다이어그램
㉯ 구성요소 : 유스케이스(usecase) - 시스템이 제공해야 하는 서비스
액 터 (actor) - 사용자가 시스템에 대해 수행하는 사물
시 스 템 (system) - 전체 시스템의 영역을 표현
* UML의 관계(Relationships)
- 연관 관계(Association) => 2개 이상의 사물이 서로 관련된 상태를 표현하며 사물 사이를 실선으로 연결해 표현하며, 화살표로 방향성을 표현한다
- 의존 관계(Dependency) => 사물의 변화가 다른 사물에게도 영향을 미치는 관계로 영향을 주는 사물이 영향 받는 사물 쪽으로 점선 화살표를 연결하여 표현
- 일반화 관계(Generaliztion) => 부모와 자식 관계로 하나의 사물이 다른 사물에 비해 더 일반적인지를 표현
- 실체화 관계(Relaiztion) => 한 객체가 다른 객체가 다른 객체에서 오퍼레이션을 수행하도록 지정하는 관계를 표현하 며 사물에서 기능쪽으로 속이 빈 점선 화살표를 연결
- 포함 관계(Compositon) => 포함하는 사물의 변화가 포함되는 사물에 영향을 미치는 관계를 표현하며, 포함하는 사물 쪽에 속이 찬 검정 화살표를 연결해 사용한다 .
- 집합 관계(Aggregation) => 하나의 사물이 다른 사물에 포함된 관계를 표현하며, 포함되는 쪽에서 포함하는 쪽으로 속이 빈 마름모를 표현한다.
* UML 확장 모델의 스트레오 타입(Stereotype)
- '<< >>' 길러멧 기호를 사용해 표현한다는 점 기억할 것.
* 애자일(Agile)
㉮ 개념 : 소프트웨어 개발 방법론 中 하나로 개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법이며, 문서보 다는 개발과 동작하는 제품에 중점을 두는 방법이다.
㉯ 특징 : 1. 프로젝트의 요구사항은 기능 중심으로 정의한다.
2. 절차와 도구보다 개인과 소통을 중요하게 생각한다.
3. 작업 계획을 짧게 세워 요구 변화에 유연하고 신속하게 대응이 가능하다.
4. 실행에 가치를 둔다.
5. 고객과의 피드백을 중시한다.
㉰ 선언문 ( 실천하기 위한 주요 원칙이다.)
- 공정과 도구보다 개인과 상호작용을 중시.
- 계획을 따르기 보다 변화에 대응하기
- 포괄적인 문서보다 동작하는 소프트웨어에 중점
- 계약 협상보다는 고객과의 협력
㉱ 애자일 방법론 유형(모듈 중심의 정의가 아닌 기능 중심의 정의)
1. XP(eXtrem Programming)
2. 스크럼(Scrum)
3. 린(Lean)
4. 크리스탈(Crystal)
5. ASD(Adaptive soft ware Development)
6. FDD(Feature Driven Development)
* 시퀸스 다이어그램(Sequence Diagram) = 순차 다이어그램이라고도 함.
㉮ 개념 : UML 다이어그램 中 동적 다이어그램에 포함되며, 객체간 상호 작용을 메세지 흐름으로 표현한 다이어그램
㉯ 구성요소 : 객체(Object), 생명선(Lifeline), 실행(Activation), 메세지(Message)
* XP(eXtrem Programming)
㉮ 개념 : XP는 애자일 방법론 中 하나로 extrem programming의 줄인말이다. 의사소통 개선과 즉각적인 피드백으로 소 프트웨어 품질을 높이기 위한 방법론이다.
㉯ 가치 : 용기, 단순성, 의사소통, 피드백, 존중
㉰ 추구하는 원칙 : - 짝 프로그래밍
- 공동 코드 소유
- 지속적인 통합
- 계획 세우기
- 작은 릴리즈
- 메타포어
- 간단한 디자인
- 테스트 기반
- 리펙토링
- 40시간 작업
- 고객 상주
- 코드 표준
* 모델링의 특징
- 개발될 시스템에 대하여 여러 분야의 엔지니어들이 공통된 개념을 공유하는데 도움을 준다.
- 개발팀이 응용문제를 이해하는데 도움을 줄 수 있다.
- 절차적인 프로그램을 위한 자료 흐름도는 프로세스 위주의 모델링 방법이다.
* 분석 자동화 도구
㉮ 개념 : 요구사항을 자동으로 분석하고 요구사항 분석 명세서를 기술하로독 개발된 요구사항 분석을 위한 자동화 도구
㉯ 특징 : 1. 표준화 적용과 문서화를 통한 보고를 통해 품질 개선이 가능함.
2. 변경사항과 변경으로 인한 영향에 대한 추적이 쉬움
3. 명세에 대한 유지보수 비용의 축소가 가능
4. 자동화된 기법을 통해 제품의 품질 향상 가능.
5. 모듈의 재사용성 향상, 유지보수 용이
6. 다양한 기술 사용 ex) 구조적 기법, 프로토타이핑 기술, 자동 프로그래밍, 정보 저장소 기술, 분산 처리 기술
㉰ 도구의 분류 :
- 상위 CASE : 계획수립, 요구분석, 기본설계 단계를 다이어그램으로 표현
(모델 사이의 모순 검사 및 모델의 오류 검증, 일관성 검증 지원, 자료 흐름도, 프로토 타이핑 작성 지원 및 UI 설계지원)
- 하위 CASE : 구문중심 편집 및 정적, 동적 테스트를 지원
(시스템 명세서생성 및 소스코드 생성 지원)
㉱ 분석 자동화 도구 주요 기능(CASE 도구)
1. 그래픽을 지원한다.
2. 소프트웨어 생명주기 전 단계를 연결
3. 다양한 소프트웨어 개발 모형 지원
4. 표준화된 개발 환경 구축 및 문서 자동화 기능 제공
5. 작업과정과 데이터 공유를 통해 작업자 간 커뮤니케이션 증대
* 요구사항 관리 도구의 필요성
1. 비용편익 2. 변경 추적 3. 영향 평가
* CASE의 원천 기술
1. 구조적 기법 2. 프로토타이핑 기술 3. 자동프로그래밍 기술 4. 정보저장소 기술 5. 분산처리 기술
* UI 유형
1. CUL(Command Line Interface)
㉮ 특징 : 정적 테스트 기반 인터페이스
㉯ 설명 : 명령어를 텍스트로 입력해 조작하는 사용자 인터페이스
2. GUI(Graphical User Interface)
㉮ 특징 : 그래픽 반응 기반 인터페이스
㉯ 설명 : 그래픽 환경을 기반으로 한 마우스나 전자펜을 이용한 사용자 인터페이스
3. NUI(Natural User Interface)
㉮ 특징 : 직관적 사용자 반응 인터페이스
㉯ 설명 : 사용자의 경험기반으로 신체부위를 이용하는 사용자 인터페이스
4. OUI(Orangic User Interface)
㉮ 특징 : 유기적 상호 작용 인터페이스
㉯ 설명 : 입력장치가 곧 출력장치가 되고, 현실에 존재하는 모든 사물이 입출력장치로 변화할 수 있는 사용자 인터 페이스
* UI 특징
1. 오류 최소화 - 구현하고자 하는 결과의 오류를 최소화
2. 작업기능 구체화 - 막연한 작업 기능에 대해 구체적인 방법을 제시
3. 상호 작용 - 사용자 중심의 상호 작용이 되도록 함
4. 작업시간 감소 - 사용자의 편의성을 높여 작업시간을 감소시킴
* UI 설계 원칙
1. 직관성 2. 유효성 3. 학습성 4. 유연성
* UI 시스템의 필요성
- 사용자의 입력을 검증한다.
- 에러 처리와 에러 메시지 처리를 한다.
- 도움(help)와 프롬프트(prompt)를 제공한다.
* UI 스타일 가이드 구성
㉮ 기능 정의 : 시스템 요구사항에 대한 개념모델을 논리적 모델로 상세화 한다.
* UI 화면 설계
와이어 프레임 - 협의한 내용을 토대로 서비스의 간략한 흐름을 공유하기 위해 화면단위의 레이아웃을 설계하는 작업
스토리 보드 - 서비스 구축을 위한 모든 정보가 담겨있는 설계 산출물
프로토 타입 - 정적인 화면인 와이어 프레임과 스토리 보드에 동적 효과를 적용함으로서 실제 구현된 것처럼 시뮬레이 션 할 수 있는 모형.
* UI 설계 프로세스 순서
문제정의 - 사용자 모델 정의 - 작업 분석 - 컴ㅍ터 오브젝트 및 기능 정의 - 사용자 인터페이스 정의 - 디자인 평가
* 공통 모듈 원칙
정확성(Correctness), 명확성(Clarity), 완전성(Completeness), 일관성(Consistency), 추적성(Traceabilty)
* 모듈화
㉮ 개념 : 제품이 효율족으로 관리될 수 있도록 시스템을 분해하고 추상화함으로써 제품의 성능 향성과 수정 및 재사용등을 쉽게 하는 기법
㉯ 바람직한 모듈 설계 방안
- 독립성과 재사용성을 높이긴 위해선 결합도는 낮추고 응집도는 높인다.
- 복잡도와 중복성을 줄이고 일관성을 유지한다.
- 모듈의 기능은 예측이 가능해야 하며, 지나치게 제한적이어서는 안된다.
- 적당한 크기의 모듈을 유지해야 한다.
- 유지보수의 용이, 이식성의 고려
- 효과적인 제어를 위한 계층적 자료 조직이 제시되어야 함
* 팬인(fan-in)과 팬아웃(fan-out)
- 팬인 (fan-in)
㉮ 개념 : 어떤 모듈을 제어(호출)하는 모듈의 수로, 자신을 기준으로 모듈에 들어오면 팬인이다.
㉯ 고려사항 : 재사용 측면에서 설계가 잘 되었지만, 단일점 장애가 발생 가능하며, 팬인이 높으면 관리 비용 및 테스트 비용이 증가한다.
- 팬아웃(fan-out)
㉮ 개념 : 어떤 모듈에 의해 제어(호출)되는 모듈의 수로, 자신을 기준으로 나가면 팬아웃이다.
㉯ 고려사항 : 팬아웃이 높을 경우 불필요한 모듈 호출 여부 검토가 필요하며 단순화 여부 검토가 필요하다.
=> 결국 시스템 복잡도를 최적화 하기 위해서는 팬인은 높게, 팬아웃은 낮게 설계해야한다.
* 설계 모델링
㉮ 소프트웨어 설계 유형
- 자료구조 설계(Data Structure Design)
= 요구 분석 단계에서 생성된 정보를 바탕으로 소프트웨어를 구현하는데 필요한 자료구조로 변환하는 과정
- 아키텍쳐 설계(Atchitecture Design)
= 소프트웨어 시스템의 전체 구조를 기술하고 컴포넌트 간 관계를 정의한다.
- 인터페이스 설계(Interface Design)
= 제품과 상호작용하는 시스템으로 사용자가 어떻게 통신하는지 기술한다.
- 프로시저 설계(Procedure Design)
= 아키텍쳐의 컴포넌트를 소프트웨어 컴포넌트의 프로시저로 변환하는 과정
- 협약에 의한 설계(Design by Contract)
= 클래스에 대한 여러 가정을 공유하도록 명확한 설계를 한다.
(협약에 의한 설계는 다음과 같은 조건들이 있다.)
- 선행조건 - 컴포넌트의 오퍼레이션 사용전에 참이 되어야 할 조건.
- 결과 조건 - 사용 후 만족되어야 할 조건
- 불변조건 - 오퍼레이션의 동작이 되는 동안 항상 만족되어야 할 조건
㉯ 소프트웨어 설계 원리
- 모든 것을 새로 개발하면 하양식 설계, 기존의 것들을 조합해 개발하면 상향식 설계
- 모듈설계만 하위 설계, 나머지는 상위 설계
- 상향식 설계 => 하위 기능들로 시작해 제일 상위에 있는 기능에 접근해가는 방식
- 하향식 설계 => 제일 상위에 있는 기능에서 시작하여 기능을 하위 기능들로 분할해 가면서 설계하는 방식
* 코드 설계
㉮ 코드의 기능
표준화, 분류, 식별, 배열, 간소화, 연상, 암호화, 오류 검출
㉯ 코드 설계의 종류
1. 연상 코드(Mnemonic Code)
=> 코드만 보고 대상을 연상할 수 있도록 명칭 일부를 약호 형태로 구성한 코드 ex) 나라이름(한국 :KR)
2. 블록 코드(Block Code)
=> 구분 코드라 불리며, 공통성이 있는 것끼리 블록으로 구분하고, 각 블록내 일련번호를 부여하는 코드
3. 순차 코드(Sequence Code)
=> 일정한 기준에 따라 순서대로 일련번호를 부여한 코드
4. 표의 숫자 코드(Significant Digit Code)
=> 대상의 자료의 물리적인 수치를 표시한 코드
5. 십진 코드(Decimal Code)
=> 10진수 형태로 표현한 코드
6. 그룹 분류식 코드(Group Classification Code)
=> 대상을 기준에 따라 분류해 구분하여 번호를 부여한 코드
* HIPO
㉮ 개념 : 시스템의 분석 및 설계와 문서화를 할 때 사용하며 하향식 소프트웨어 개발을 위한 문서화 도구이다.
㉯ 종류 : - 가시적 도표(visual Table of Contents) - 전체적인 기능과 흐름
- 총체적 도표(Overview Diagram) - 입출력 처리에 대한 정보 제공
- 세부적 도표(Detail Diagram) - 기본 요소들을 상세히 설명
(소프트웨어 아키텍쳐 명세에 관한 국체 표준 = IEE1471)
* 소프트웨어 아키텍쳐 패턴유형
1. 계층화 패턴(Layered Pattern)
- 시스템을 계층으로 구분하여 구성하는 패턴으로 서로 마주보는 두 개의 계층 사이에서만 상호 작용이 이루어진다.
2. 클라이언트 - 서버 패턴 (Client - Server Pattern)
- 사용자는 클라이언트를 통해 서비를 요청하고 서버는 서비스를 제공하는데, 하나의 서버와 다수의 클라이언트로 구성된다.
3. 파이프 - 필터 패턴 (Pipe - Filter Pattern)
- 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 단방향 패턴으로 시스템이 입력 데이터를 받아 처리 하고 결과를 다음 시스템으로 넘겨주는 과정을 반복한다.
4. 브로커 패턴(Broker Pattern)
- 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용되고, 이 컴포넌트 들이 원격 서비스 실행을 통해 상호 작용이 가능한 패턴이다.
5. 모델 - 뷰 - 컨트롤러 패턴(MVC)
- 대화형 애플리케이션을 모델, 뷰, 컨트롤러로 3개의 서브 시스템으로 구조화하는 패턴이다.
6. 마스터 - 슬레이브 패턴 (Master-Slave Pattern)
- 일반적으로 실시간 시스템에서 사용하며, 연산, 통신, 조정을 책임지는 마스터와 제어되고 동기화되는 대상인 슬레이브로 구성되어 있다.
* 객체 지향 구성요소
1. 클래스 ( Class )
- 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현하며, 속성은 변수의 형태로, 행위는 메서드 형태로 선언한다.
2. 객체 ( Oject )
- 클래스에 정의한 것을 토대로 메모리에 할당되며 각각의 상태와 식별성을 가진다.
3. 메서드 ( Method )
- 생성된 객체를 사용하는 방법으로 객체의 구체적인 연산이다.
4. 메세지 (Message)
- 객체간 상호 작용을 하기 위한 수단으로, 행위를 하도록 객체에게 지시하는 방법이며 메세지는 객체에서 객체로 전달
5. 인스턴스 ( Instance)
- 실체로 메모리에 할당되며 객체 지향 기법에서 클래스를 통해 만든 실체의 실형 객체
6. 속성 (Property)
- 한 클래스 내에서 속한 객체들이 가지고 있는 데이터 값들을 단위별로 정의
* 객체 지향 기법
1. 캡슐화 ( Encapsulation )
: 서로 연관된 데이터와 함수를 함께 묶어 외부와 경계를 만들고 필요한 인터페이스만 밖으로 드러내는 기법으로, 결합도가 낮아지고 재사용이 용이하다. 정보 은닉과 관계가 깊으며, 변경 발생 시 오류의 파급 효과가 적다
2. 상속성 ( Inheritance )
: 상위 클래스의 속성과 메서드를 하위 클래스에서 재정없이 물려받아 사용하는 기법
3. 다형성 ( Polmorphrism )
: 예시로 오버라이딩과 오버 로딩이 대표적으로 상속받은 여러 개의 하위 객체들이 다른 형태의 특성을 갖는 객체로 이용될 수 있는 성질이다.
4. 추상화 ( Abstraction )
: 공통 성질을 추출해 추상 클래스를 설정하는 방법
5. 정보 은닉 ( Information Hiding )
: 코드 내부 데이터와 메서드를 숨기고 공개 인터페이스를 통해서만 접근이 가능하도록 하는 코드 보안 기술로, 모듈 사이의 독립성을 유지하는데 도움을 준다.
6. 관계성 ( Relationship )
: 두 개 이상의 엔티티 형에서 데이터를 참조하는 관계를 나타내는 기법
* 객체 지향 분석의 개념
- 객체 지향 분석(OOA)는 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 속성과 연산 관계 등으로 나누어 분석하는 기법으로 데이터와 행위를 하나로 묶어 객체를 정의하고 추상화 시킨다.
* 객체 지향론의 종류
1. OOSE ( object oriented software engineering )
㉮ 만든이 : 야콥슨
㉯ 설명 : 유스케이스에 의한 접근 방법으로 유스케이스를 모든 모델의 근간으로 활용되는 방법론으로 기능적 요구사항 중심의 시스템이다.
2. OMT ( object modeling technology )
㉮ 만든이 : 럼바우
㉯ 설명 : 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링하는 방법으로 객체 모델링 - 동적 모델링 - 기능 모델링 순서로 진행된다.
3. OOD ( object oriented design )
㉮ 만든이 : 부치
㉯ 설명 : 설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론으로 분석과 설계의 분리가 불가능하다.
(추가적으로 coad 와 yourdon 방법론은 E-R 다이어그램을 사용해 객체의 행위를 모델링한다.)
* 내-외부 인터페이스 요구사항의 분류
- 기능적 요구사항 : 소프트웨어가 가저야하는 기능적 속성에 대한 요구사항.
- 비기능적 요구사항 : 시스템 전반과 관련된 요구사항
* 요구 공학 프로세스
요구 개발 단계와 관리 단계로 구분할 수 있으며, 요구사항 개발 절차는 다음과 같다.
요구사항 도출 - 요구사항 분석 - 요구사항 명세 - 요구사항 확인 및 검증
* 요구사항 분석 단계 절차
㉮ 목적 : 완전성과 일관성을 확보하는 단계이다
㉯ 절차 : 요구사항 분류 - 개념 모델링 생성 및 분석 - 요구사항 할당 -요구사항 협상 - 정형분석
㉰ 기법 : 자료 흐름 지향 분석 = 데이터 흐름도(DFD) 및 자료사전으로부터 제품 구조를 유도
객체 지향 분석 = UML로 표준화, 시스템의 기능과 데이터를 함께 분석
* 요구사항 명세 단계
㉮ 목적 : 체계적으로 검토, 평가, 승인 될 수 있는 문서를 작성하는 단계
㉯ 정형 명세 기법과 비정형 명세 기법으로 나눌 수 있다.
1. 비정형 명세 기법
㉮ 설명 : 사용자의 요구를 표현할 때, 자연어를 기반으로 서술하는 기법으로 사용자와 개발자의 이해가 용이하며 명확성 및 검증발생에 문제 발생 가능성이 있음.
㉯ 종류 : FSM, Decision table, ER모델링, State Chart(Table)
2. 정형 명세 기법
㉮ 설명 : 사용자의 요구를 표현할 때 수학적 원리와 표기법을 이용하는 기법으로 표현이 간결하며 명확성 및 검증이 용이하며 기법의 이해가 어렵다.
㉯ 종류 : VDM, Z-스키마, Petri-Nets, CSP 등
* 요구사항 확인 및 검증 절차
요구사항 목록 확인 - 요구사항 정의서 작성 여부 확인 - 비기능적 요구사항의 확인 - 타 시스템 연계 및 인터페이스 요구사항 확인 (요구사항 확인 및 검증단계에서는 정형 기술 검토를 수행한다.)
* 검증 단계의 주요 기법
1. 요구사항 검토
- 정의서 및 사양서, 요구사항 명세서를 완성한 시점에서 검토하며 잘못된 가정, 불명확성을 검토한다.
2. 정형 기술 검토
- 동료 검토 ( Peer Review ) : 2~3명이 진행하는 리뷰 형태로 작성자가 설명하는 요구사항 명세서에 대해 이해 관계자들이 결함을 발견하는 형태
- 워크 스루 ( Walk Through ) : 오류를 조기에 검출하는데 목적이 있으며, 검토 자료를 사전에 배부하고 사전 검토 한 후 리뷰를 통해 오류를 검출하고 문서화.
- 인스펙션 ( Inspection ) : 저작자이외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방식.
3. 프로토 타이핑 활용 : 요구사항이 잘못된 경우 유용한 피드백을 제공하며 제품 일부를 개발해 사용자 대상으로 시연하며 작동하는 모습을 경험할 수 있게하여 요구사항을 확인.
4. 모델 검증 : 분석 단계에서 개발된 모델의 품질 검증이 필요하며 정적 분석에 유용하다.
5. 테스트 케이스 및 테스트를 통한 확인
6. CASE 도구 활용 검증
7. 베이스라인을 통한 검증
8. 요구사항 추적표를 통한 검증
* 요구사항 개발 프로세스의 순서
1. 도출 2. 분석 3. 명세 4. 확인 (EASV)
* 시스템 구성 요소
입력, 출력, 처리, 제어, 피드백
* 인터페이스 시스템 구성
- 송신 시스템 : 연계할 데아터와 DB로부터 애플리케이션으로부터 연계 테이블 또는 파일 형태로 생성하며 송신하는 시스템
- 수신 시스템 : 수신한 데이터를 수신 시스템에서 관리하는 데이터 형식에 맞게 반환하여 DB에 저장하거나 애플리케이션에서 활용할 수 있는 시스템
- 중계 서버 : 송수신 시스템 사이의 데이터를 송수신하고 연계 데이터의 송수신 현황을 모니터링하는 시스템
* 내-외부 송-수신 연계 기술
1. DB 링크
= DB에서 제공하는 DB 링크 객체를 이용하는 기술 ex) 테이블 명@DBLink 명
2. DB 연결
= 수신 시스템의 WAS에서 송신 시스템 DB로 연결하는 DB 커넥션 풀을 생성하고 연계 프로그램에서 해당 DB 커넥션 풀명을 이용하는 기술
3. API/OPEN API
= 송신 시스템의 DB에서 데이터를 읽어서 제공하는 애플리케이션 프로그래밍 인터페이스 프로그램으로 API명과 입출력 파라미터 정보가 필요하다.
4. JDBC
= 수신 시스템의 프로그램에서 JDBC 드라이버를 이용하여 송신 시스템 DB와 연결하는 기술
5. 하이퍼링크
= 웹 애플리케이션에서 하이퍼링크를 이용하는 기술
6. 소켓
= 서버는 통신을 위한 소켓을 생성하고 포트를 할당하며 클라이언트의 통신 요청 시 클라이언트와 연결하고 통신하는 기술
* 미들웨어 솔루션
㉮ 개념 : 컴퓨터 간의 연결을 쉽게, 안전하게 할 수 있도록 해주고 이에 대한 관리를 도와주는 소프트웨아로 DB와 애플리케이션 간 통신을 지원해주며 애플리케이션이 어떤 정보 시스템 환경에서도 동작할 수 있도록 지원해주는 역할
㉯ 유형 : 1. DB 미들웨어 :
- DB 솔루션 업체에서 제공하는 애플리케이션과 DB간에 통신을 원활하게 하는 것을 목적으로 하는 미들웨어
2. 원격 프로시저 함수 ( RPC )
- 응용 프로그램의 프로시저를 사용하여 원격 프로시저를 로컬 프로시저처럼 호출하는 방식의 미들웨어
3. 메세지 지향 미들웨어 ( MOM )
- 메세지 기반의 비동기형 메세지 전달 방식 미들웨어로 서로 다른 이기종 분산 DB 시스템의 데이터 동기를 위하여 주로 사용한다.
4. 트랜잭션 처리 ( TP ) 모니터
- 온라인 업무에서 트랜잭션을 처리, 감시하는 미들웨어로 분산 트랜잭션을 처리하기 위한 미들웨어로 주로 사용자가 많고 안정적이면서도 즉각처리가 필요한 업무 프로그램의 개발에 사용한다.
5. 레거시 웨어
- 기존의 애플리케이션이나 DB기반에 새로운 업데이트된 기능을 덧붙이고자 할 때 사용되는 미들웨어
6. 객체기반(ORB) 미들웨어
- 코바(CORBA) 표준 스펙을 구현한 객체 지향 미들웨어로 다른 기반의 컴퓨터 간의 프로그램과 데이터를 교환, 변환이 편히 이루어질 수 있도록 지원
7. WAS
- 다른 이기종 시스템과의 애플리케이션 연동을 지원하는 미들웨어로 HTTP 세션 처리를 위한 웹 서버 기능뿐만 아니라 민감한 기업 업무까지 구현이 가능하다.
'자격증' 카테고리의 다른 글
| 2022 제 1회 정보처리기사 실기 시험을 끝내며... (0) | 2022.05.10 |
|---|