정보처리기사(정처기) 실기 - 1단원 총정리

1단원은 이것만 외우면 끝!

---

 

프레임워크 : 소프트웨어의 특정 부분 설계 및 구현 시 재사용이 가능하도록 클래스 제공

 

소프트웨어 프레임워크의 특징 : 모재확역

- 모듈화(인터페이스에 의한 캡슐화)

- 재사용성(반복적으로 사용하는 컴포넌트를 정의할 수 있게 함)

- 확장성(다형성을 통해 프레임워크의 인터페이스를 넓게 사용)

- 제어의 역흐름(프레임워크 코드가 전체 애플리케이션의 처리 흐름을 제어->제어가 반대로 흐르게 한다)

 

다형성 : 프로그래밍 언어의 요소들이 다양한 자료형에 속하는 것이 허가되는 성질(오버로딩, 오버라이딩)

소프트웨어 생명 주기 모델 종류 : 폭프나반 (폭포수 - 프로토타이밍 - 나선형 - 반복적)
- 폭포수 모델 : 소프트웨어 생명 주기 모델 종류 - 각 단계를 확실히 마무리 지운 후에 다음단계로 넘어가는 모델
- 프로토타이핑 모델 :소프트웨어 생명 주기 모델 종류 - 프로토타입을 구현해, 고객의 피드백을 반영하며 만들어가는 모델
- 나선형 모델 :소프트웨어 생명 주기 모델 종류 - 위험을 최소화하기 위해 점진적으로 개발
- 반복적 모델 :소프트웨어 생명 주기 모델 종류 - 구축 대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발

 

소프트웨어 개발방법론 종류 :구정객 컴애제(구조적 - 정보공학 - 객체지향 - 컴포넌트기반 - 애자일 - 제품계열)
- 구조적 방법론 : 소프트웨어 개발방법론 종류 - 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합한다. 나씨-슈나이더만 차트 사용
- 정보공학 방법론 : 소프트웨어 개발방법론 종류 - 정보시스템 개발에 필요한 관리 절차와 작업 기반을 체계화
- 객체지향 방법론 : 소프트웨어 개발방법론 종류 - ‘객체’라는 기본 단위로 시스템 분석 및 설계
- 컴포넌트 기반 방법론(CBD) : 소프트웨어 개발방법론 종류 - 컴포넌트를 조립해 하나의 새로운 운용 프로그램 작성
- 애자일 방법론 : 소프트웨어 개발방법론 종류 - 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템 개발
- 제품 계열 방법론 : 소프트웨어 개발방법론 종류 - 특정 제품에 적용하고 싶은 공통된 기능을 정의해 개발, 임베디드

애자일 방법론 유형 - 엑스린 (XP - SCRUM - LEAN)
- XP : 애자일 방법론 유형 - 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질 높이기 위한 방법론
- SCRUM : 애자일 방법론 유형 - 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 방법론
- LEAN : 애자일 방법론 유형 - 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해 낭비 요소를 제거하는 방법론

 

객체 지향 분석 : 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 속성과 연산, 관계를 정의하여 모델링하는 기법

- 야콥슨 : 유스케이스에 의한 접근 방법을 유스케이스를 모든 모델의 근간으로 활용하는 방법론(분석, 설계, 구현 단계로 구성) (기능적 요구사항 중심의 시스템)
- 럼바우 : 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링하는 방법론(분석 절차는 객체 모델링 -> 동적 모델링 -> 기능 모델링 순서로 진행)
- 부치 : 설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론(분석과 설계의 분리가 불가능, 분석하는 데 이용된 객체 모델의 설계 시 적용)
- 객체 모델링(정보 모델링이라고도 함) : 시스템에서 요구하는 객체를 찾고 객체들 간의 관계를 정의하여 ER 다이어그램을 만드는 과정까지의 모델링
- 동적 모델링 : 시간의 흐름에 따라 객체들 사이의 제어 흐름, 동작 순서 등의 동적인 행위를 표현하는 모델링
- 기능 모델링 : 프로세스들의 자료 흐름을 중심으로 처리 과정 표현하는 모델링

지속적인 통합(CI)  : XP의 12가지 기본원리 - 매일 여러 번씩 소프트웨어를 통합하고 빌드
메타포어(Metaphor) : XP의 12가지 기본원리 - 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자간의 의사소통을 원활하게 한다.
테스트 기반 개발(TDD) : XP의 12가지 기본원리 - 만들 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다.
리팩토링(Refactoring) : XP의 12가지 기본원리 - 프로그램의 기능은 바꾸지 않고 복잡한 소스코드를 수정/보완하여 가독성/유지보수성 높이는 기법

비용 산정 모형 - 하향식 선정방법 : 전문가 판단, 델파이 기법(전문가들의 경험적 지식을 통해 미래 예측)

델파이 기법 : 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법

비용 산정 모형 - 상향식 선정방법 :  LOC, Man/Month, Putnam(개발 주기 단계별 요구+인원 분포), COCOMO(프로그램 규모)
LoC(Line of Code) 모형 : 비용 산정 모형 - 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정해 예측치를 구해 비용을 산정하는 방식
Man Month 모형 : 비용 산정 모형 - 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용 산정하는 방식
COCOMO 모형 : 비용 산정 모형 - 보헴이 제한, 프로그램 규모에 따른 비용 산정
- 조직형(Organic Mode) : COCOMO 모형 - 5만 라인 이하
- 반 분리형(Semi-Detached Mode) : COCOMO 모형 - 30만 라인 이하
- 임베디드형(Embedded Mode) : COCOMO 모형 - 30만 라인 이상
푸트남 모형 : 비용 산정 모형 - 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식, 생명주기 예측 모형, Rayleigh-Norden 곡선
기능점수(FP; Fuction Point) 모형 : 비용 산정 모형 - 요구 기능에 따른 가중치 부여

일정관리 모델 : 일정 기한 내에 적절하게 완료될 수 있도록 관리
- 주 공정(Critical Path) : 프로젝트의 시작에서 종료까지 가장 긴 시간이 걸리는 경로
- 주 공정법(CPM) : 일정관리 모델 - 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정 계산
- PERT : 일정관리 모델 - 일의 순서를 계획적으로 정리하기 위한 수렴 기법, 비관치, 중간치, 낙관치를 이용
- 주 공정 연쇄법(CCPM) : 일정관리 모델 - 자원제약사항을 고려해 일정 작성

소프트웨어 아키텍처 4+1 뷰 : 유논프구배(유스케이스 - 논리 - 프로세스 - 구현 - 배포 뷰)
- 유스케이스 뷰 : 소프트웨어 아키텍처 4+1 뷰 - 다른 뷰를 검증하는데 사용
- 논리 뷰 : 소프트웨어 아키텍처 4+1 뷰 - 시스템의 기능적 요구사항 설명
- 프로세스 뷰 : 소프트웨어 아키텍처 4+1 뷰 - 시스템의 비기능적 요구사항 설명
- 구현 뷰 : 소프트웨어 아키텍처 4+1 뷰 - 모듈의 구성, 컴포넌트 구조, 의존성
- 배포 뷰 : 소프트웨어 아키텍처 4+1 뷰 - 어떻게 배치되는가
- 유스케이스(Usecase) : 시스템 요구사항이자, 사용자의 입장에서 바라본 시스템의 기능

소프트웨어 아키텍처 패턴 종류 : 계클 파브모 (계층화 - 클라이언트/서버 - 파이프/필터 - 브로커 - 모델/뷰/컨트롤러)
- 계층화(Layered) 패턴 : 소프트웨어 아키텍처 패턴 - 시스템을 계층으로 구분해 구성하는 패턴
- 클라이언트-서버 패턴 : 소프트웨어 아키텍처 패턴 - 하나의 서버와 다수의 클라이언트로 구성된 패턴
- 파이프-필터 패턴 : 소프트웨어 아키텍처 패턴 - 데이터 스트림을 생성하고 처리하는 시스템에서 사용
- 브로커(Broker) 패턴 : 소프트웨어 아키텍처 패턴 - 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용, 각 컴포넌트들 원격 서비스 실행을 통해 상호작용 가능
- 모델-뷰-컨트롤러 패턴(MVC) : 소프트웨어 아키텍처 패턴 -
(모델 : 핵심 기능과 데이터 보관 , 뷰 : 사용자에게 정보 표시 , 컨트롤러 : 사용자로부터 요청 입력 받아 처리)

소프트웨어 아키텍처 비용 평가 모델 - SACAA (SAAM - ATAM - CBAM - ADR - ARID) 
SAAM (Software Architecture Analyses Method) : 소프트웨어 아키텍처 비용 평가 모델 - 변경 용이성과 기능성에 집중, 경험이 없는 조직에서도 활용 가능"}
ATAM (Architecture Trade-off Analysis Method) : 소프트웨어 아키텍처 비용 평가 모델 - 아키텍처 품질 속성을 만족시키는지 판단
CBAM (Cost Benefit Analysis Method) : 소프트웨어 아키텍처 비용 평가 모델 - ATAM 바탕의 시스템, 경제적 의사결정에 대한 요구 총족
ADR (Active Design Review) :소프트웨어 아키텍처 비용 평가 모델 - 소프트웨어 아키텍처 구성요소 간 응집도 평가
ARID (Active Reviews for Intermediate Designs) : 소프트웨어 아키텍처 비용 평가 모델 - 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중

디자인 패턴 (생성 패턴) : 생빌프로 팩앱싱 (생성 - 빌더, 프로토타입, 팩토리메서드, 앱스트랙트 팩토리, 싱글톤)
- Builder : 디자인 패턴 (생성 패턴) - 복잡한 인스턴스를 조립해 만드는 구조, 복합 객체 생성 시 방법 분리, 서로 다른 표현 결과 만들 수 있음
- Prototype : 디자인 패턴 (생성 패턴) - 처음부터 일반적인 원형을 만들어 놓고, 그것을 복사한 후 필요한 부분만 수정해 사용하는 패턴
 - Factory Method : 디자인 패턴 (생성 패턴) - 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식
- Abstract Factory(추상 팩토리) : 디자인 패턴 (생성 패턴) - 구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스 제공하는 패턴
- Singleton : 디자인 패턴 (생성 패턴) - 전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 디자인 패턴

 

디자인 패턴 (구조패턴) 
- Bridge : 디자인 패턴 (구조 패턴) - 기능의 클래스 계층과 구현의 클래스 계층을 연결, 구현부에서 추상 계층 분리
- Decorator : 디자인 패턴 (구조 패턴) - 기존에 구현되어 있는 클래스에 필요한 기능 추가해 나감
- Facade : 디자인 패턴 (구조 패턴) - 복잡한 시스템에 대해 단순한 인터페이스 제공, 시스템 구조에 대한 파악 쉽게
- Flyweight : 디자인 패턴 (구조 패턴) - 메모리 절약, ‘클래스의 경량화’ 목적
- Proxy : 디자인 패턴 (구조 패턴) - 실체 객체에 대한 대리 객체, 실체 객체를 드러나지 않게 해 정보은닉
- Composite : 디자인 패턴 (구조 패턴) - 객체들의 관계를 트리 구조로 구성, 부분-전체 계층 표현
- Adapter : 디자인 패턴 (구조 패턴) - 기존에 생성된 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할 , 이기종 간을 연결하는 EAI의 핵심 장치

 

디자인 패턴 (행위 패턴) 
- Mediator : 디자인 패턴 (행위 패턴) - 중간에 통제, 중재자
- Interpreter : 디자인 패턴 (행위 패턴) - 언어의 다양한 해석, 구문의 해석을 맡는 클래스 각각 작성
- Iterator : 디자인 패턴 (행위 패턴) - 컬렉션 구현 방법 노출시키지 않으면서도 그 집합체 안에 들어있는 모든 항목에 접근할 방법을 제공
- Template Method : 디자인 패턴 (행위 패턴) - 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화, 상위 클래스-추상, 하위 클래스-구체
- Observer : 디자인 패턴 (행위 패턴) - 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에 연락
- State : 디자인 패턴 (행위 패턴) - 상태에 따라 다르게 처리할 수 있도록 행위 내용 변경
- Visitor : 디자인 패턴 (행위 패턴) - 클래스의 메서드가 각 클래스를 돌아다니며 특정 작업 수행
- Command : 디자인 패턴 (행위 패턴) - 명령이 들어오면 그에 맞는 서브 클래스 선택되어 실행
- Strategy : 디자인 패턴 (행위 패턴) - 알고리즘 군 정의, 행위를 클래스로 캡슐화해 동적으로 행위 자유롭게 변환
- Memento : 디자인 패턴 (행위 패턴) - Undo 기능 개발 , Ctrl + z 
- Chain of Responsibility : 디자인 패턴 (행위 패턴) - 정적으로 어떤 기능에 대한 처리의 연결이 하드 코딩 되어 있을 때, 이를 동적으로 연결되어 있는 경우에 따라 다르게 처리될 수 있도록 연결한 디자인

정형 기술 검토 : 동워인 (동료 검토 - 워크 스루 - 인스펙션)
- 동료 검토(Peer Review) : 정형 기술 검토 - 2~3명이 진행, 요구사항 명세서 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견
- 워크 스루(Walk Through) : 정형 기술 검토 - 회의 전에 검토 자료를 배포해서 사전 검토한 후 짧은 시간 동안 회의를 진행하는 형태
- 인스펙션(Inspection) : 정형 기술 검토 - 원시 코드 등을 저작자 외의 다른 전문가 또는 팀이 검사해 오류를 찾아내는 공식적 검토 방법

기능적 요구사항 : 시스템이 제공하는 기능, 서비스에 대한 요구사항
비기능적 요구사항 : 시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항