소프트웨어

• 하드웨어를 동작시켜 사용자가 작업을 편리하게 수행하도록하는 프로그램과 자료구조
• 프로그램 개발, 운용, 유지보수 관련된 모든 문서와 정보를 포함
• 상품성 : 개발된 소프트웨어는 상품화되어 판매된다.
• 견고성 : 일부 수정으로 소프트웨어 전체에 영향을 줄 수 있다.
• 복잡성 : 개발과정이 복잡, 비표준화
• 순응성 : 사용자의 요구나 환경 변화에 적절히 변경
• 비가시성 : 소프트웨어 구조는 외관으로 나타나지 않고 코드로 숨어 있다.
• 비마모성 : 마모되거나 소멸되지 않는다.
• 비제조성 : 하드웨어처럼 제작이 아니라 논리적인 절차에 맞게 개발
• 비과학성 : 과학적이 아니라 조직, 인력, 시간, 절차 등 중심

분류

• 기능에 의한 분류 : 시스템, 응용
• 사용 분야에 의한 분류 : 프로그래밍, 문서, 통신, 분산처리, 멀티미디어, 개발, 인공지능
• 개발 과정 성격에 따른 분류 : 프로토타입, 프로젝트 산출물, 패키지
• 정보처리 방법에 따른 분류 : 일괄처리, 온라인, 실시간

시스템 구성요소

• 입력 : 처리 방법, 처리할 데이터, 조건을 시스템에 투입하는 것
• 처리 : 입력된 데이터를 처리 방법과 조건에 따라 처리하는 것
• 출력 : 처리된 결과를 시스템에서 산출하는 것
• 제어 : 자료를 입력하여 출력될 때까지의 처리 과정이 올바르게 진행되는지 감독하는 것
• 피드백 : 출력된 결과가 예정된 목표를 만족시키지 못할 경우 목표 달성을 위해 반복 처리 하는 것

위기

여러가지 원인해 의해 개발 속도가 하드웨어의 개발속도를 따라가지 못해 소프트웨어에 대한 사용자들의 요구사항을 처리할 수 없는 문제가 발생함을 의미

• 소프트웨어의 특징에 대한 이해 부족 : 물리적이지 않고 논리적인 소프트웨어 특징을 이해하지 못함
• 소프트웨어의 관리 부재 : 소프트웨어에 대한 관리를 소홀히 하여 효율적인 자원 통제가 이루어지지 못했다.
• 프로그래밍에만 치중 : 소프트웨어 품질이나 유지보수는 고려하지 않고, 프로그래밍만 하려하므로 다양하고 복잡해지는 소프트웨어의 요구사항을 처리하지 못함
• 개발 인력 부족과 그로 인한 인건비 상승
• 성능 및 신뢰성 부족
• 개발 기간 지연 및 개발 비용 증가
• 유지보수가 어려워져 비용 증가
• 소프트웨어의 생산성 저하
• 소프트웨어의 품질 저하

소프트웨어 공학

• 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문
• 소프트웨어의 품질과 생산성 향상을 목적
• IEEE 정의 : 소프트웨어의 개발, 운용, 유지보수, 폐기 처분에 대한 체계적인 접근 방안
• Fairley 정의 : 지정된 비용과 기간 내의 소프트웨어를 체계적으로 생산하고 유지보수하는 데 관련된 기술적이고 관리적인 원리
• Boehm 정의 : 과학적인 지식을 소프트웨어 설계와 제작에 응용하는 것이며 이를 개발 운용, 유지보수하는 데 필요한 문서 작성 과정
• 제품을 단지 생산하는 것이 아니라 가장 경제적인 방법으로 양질의 제품을 생산하는 것
• 계층화 기술을 사용한다.

계층화 기술

도구, 방법, 절차가 있다.

• 도구 : Tool 절차와 방법을 자동 또는 반자동으로 처리하는 기능을 제공, 대표적으로 CASE를 사용
• 방법 : Method 소프트웨어를 구축하는 기술적인 방법을 제공
• 절차 : Process
  • 소프트웨어 개발에 사용되는 개발 방법과 도구가 사용되는 순서
  • 계층화 기술들을 결합시켜 합리적이고 적절한 방법으로 소프트웨어를 개발하고 유지

기본 원칙

• 현대적인 프로그래밍 기술을 계속적으로 적용해야한다.
• 개발된 소프트웨어 품질이 유지되도록 지속적으로 검증해야한다.
• 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야한다.

발전 과정

• 1960 : 소프트웨어 공학의 시작, 구조적 프로그래밍
• 1970 : 구조적 분석/설계 개념 도입, 상품화
• 1980 : 하드웨어 가격 하락
• 1985~ : 객체지향 기술 사용, CASE 등의 활용, 재공학

품질과 생산성

품질

• 사용자가 요구하는 대로 동작
• 하드웨어 자원을 효율적으로 이용
• 일정 시간 내에 주어진 조건하에서 원하는 기능을 실행
• 처리 절차에 맞게 수행되어 정확하게 결과가 산출
• 소프트웨어의 개발, 유지보수 등이 초기 예상 비용 이내에서 수행
• 적당한 사용자 인터페이스를 제공해 사용하기가 편리해야한다.
• 유지보수가 용이하고 신뢰성이 높아야한다.
• 에러가 최소화
• 소프트웨어 사용법, 구조의 설명, 성능, 기능이 이해하기 쉬어야한다.
• 실행 속도가 빠르고, 기억 용량을 적게 차지해야 한다.

생산성

투입된 비용, 노력에 대한 생산량을 의미

• 개발자의 능력
• 원활한 의사 전달
• 프로젝트의 복잡도와 성격
• 기술 수준
• 관리 기술

생명 주기

• 소프트웨어 수명 주기
• 소프트웨어 개발 방법론의 바탕
• 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 단계별로 나눈 것
• 프로젝트 비용 산정과 개발 계획을 수립할 수 있는 기본 골격
• 프롲게트 진행 방향을 명확하게 파악
• 용어 및 기술의 표준화를 가능하게 한다.
• 프로젝트 관리를 용이하게 한다.
• 여러 소프트웨어 간 상호 일관성을 유지하게 한다.

단계

정의 단계, 개발단계, 유지보수 단계로 나뉨

정의 단계

• 소프트웨어를 개발할 것인지 정의하는 단계
• 관리자와 사용자가 가장 많이 참여하는 단계
• 타당성 검토단계, 개발 계획단계, 요구사항 분석 단계로 나뉨

개발 단계

• 실제적으로 소프트웨어를 개발하는 단계
• 설계 단계 : 구조, 알고리즘, 자료구조를 작성하는 단계로 에러가 가장 많이 발생
• 구현 단계 : 설계 단계에서 작성된 문서를 기초로 하여 코딩하고 번역하는 단계
• 테스트 단계 : 구현된 소프트웨어에 내재되어 있는 오류를 찾아주는 단계

유지보수 단계

• 소프트웨어를 적응 및 유지시키는 단계
• 소프트웨어 생명 주기 단계 중에서 시간과 비용이 가장 많이 든다.]

정의 : 개발 계획, 요구사항 분석
설계 : 구조, 알고리즘
구현 : 코딩
테스트 : 오류 검출

생명 주기 모형

폭포수 모형

• 소프트웨어 개발이 각 단계를 확실히 매듭짓고 그 결과를 철저히 검토하여 승인한 뒤 다음 단계로 진행
• 이전 단계로 넘어갈 수 없는 방식
• 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형
• 고전적 생명 주기 모형
• 앞 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형
• 제품의 일부가 될 매뉴얼을 작성해야 한다.
• 타당성 검토 => 계획 => 요구 분석 => 설계 => 구현(코딩) => 테스트(검사) => 유지보수
• 모형 적용 경험과 성공 사례가 많다.
• 단계별 정의가 분명하고 전체 공조의 이해가 용이하다.
• 단계별 산출물이 정확하여 개발 공정의 기준점을 잘 제시한다.
• 개발 중 발생하는 새로운 요구나 경험을 반영하기 어려워 처음부터 사용자가 모든 요구사항을 명확하게 제시해야한다.
• 오류 없이 다음 단계로 진행해야 하는데 현실적으로 힘들다.
• 업무에 운용할 때 검출되지 않은 오류가 발생할 수 있다.

프로토타입 모형

• 사용자의 요구사항을 정확하게 파악하기 위해 프로토타입(견본품)을 만들어 최종 결과물을 예측하는 모형
• 시제품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발한다.
• 폭포수 모형의 단점을 보완
• 프로토타입은 요구 분석 단계에서 사용한다.
• 소프트웨어 생명주기에서 유지보수가 없어지고, 개발 단계 안에서 유지 보수가 이뤄지는 것으로 볼 수 있다.
• 요구 수집 => 빠른 설계 => 프로토타입 구축 => 고객 평가 => 프로토타입 조정 => 구현
• 요구사항을 충실히 반영하며 요구사항의 변경이 용이
• 최종 결과물이 만들어지기 전에 의뢰자가 최종 결과물의 일부 또는 모형을 볼 수 있다.
• 프로토타입은 의뢰자나 개발자 모두에게 공동의 참조 모델을 제공한다.
• 미리 제작된 소프트웨어를 사용할 경우 실제 소프트웨어와의 차이가 발생할 수 있다.
• 단기간 제작해야되기 때문에 비효율적 언어나 알고리즘을 사용할 수 있다.

나선형 모형

• Boehm이 제안한 것으로 폭포수와 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
• 여러 번의 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것
• 점진적 모형
• 소프트웨어를 개발하면서 발생하는 위험을 관리하고 최소화하는 것을 목적으로 한다.
• 계획 및 정의 => 위험 분석 => 공학적 개발 => 고객평가의 반복
• Planning => Risk Analysis => Engineering => Customer Evalutation
• 가장 현실적인 모형
• 대규모 프로젝트나 큰 시스템에 적합하다.
• 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 추가할 수 있고, 정밀하며 유지보수가 필요 없다.
• 위험성 평가에 크게 의존하기 때문에 발견하지 못하면 문제가 발생한다.
• 비교적 최신 기법이라 널리 사용되지 않는다.

4GT 모형

• 사용자와 개발자가 쉽게 접근하고 사용할 수 있는 4세대 언어를 이용하여 개발자가 조사한 요구사항 명세서로부터 원시 코드를 자동으로 생성할 수 있게 해주는 모형
• 설계 단계를 축소하고 요구 분석단계에서 코딩단계로 전환할 수 있는 비절차적 모형
• 요구사항 수집 => 설계 전략 => 4세대 언어를 이용한 구현 => 제품화
• 중소형 소프트웨어 개발에는 시간이 감소하지만 대규모에서는 자동화로 인해 분석 설계 단계에서 더 많은 시간이 필요

프로젝트 관리

• 주어진 기간 내에 최소의 비용으로 사용자를 만족시키는 시스템을 개발하기 위한 활동
• 소프트웨어 개발 계획을 세우고 분석, 설계, 구현 등 작업을 통제하는 것
• 소프트웨어 생명 주기의 전 과정에 걸쳐 진행된다.

관리 대상

• 계획관리 : 프로젝트 계획, 비용산정, 일정 계획, 조직 계획
• 품질관리
• 위험관리

3대 요소

• 사람 : People 프로젝트 관리에서 가장 기본이 되는 인적자원
• 문제 : Problem 사용자 입장에서 문제를 분석하여 인식
• 프로세스 : Process 소프트웨어 개발에 필요한 전체적인 작업 계획 및 구조

구성 단계

• 프로젝트 계획 수립
• 프로젝트 가동
• 프로젝트 통제
• 프로젝트 종료

프로젝트 계획 수립

• 프로젝트가 수행되기 전에 소프트웨어 개발 영역 결정, 필요한 자원, 비용, 일정 등을 예측하는 작업
• 관리자가 합리적으로 예측할 수 있도록 프레임워크 제공
• 소프트웨어 개발 과정에서 발생할 수 있는 위험성 최소화
• 계획 수립 후에는 시스템 정의서와 프로젝트 계획서가 산출
• 프로젝트 관리자의 임무

소프트웨어 개발 영역 결정

• 프로젝트 계획 수립의 첫 번째 업무
• 개발될 소프트웨어의 영역을 결정
• 주요 요소 : 처리될 데이터, 소프트웨어에 대한 기능, 성능, 제약 조건, 신뢰도, 인터페이스 등
• 인터페이스
  • 소프트웨어에 의해 간접적으로 제어되는 장치와 소프트웨러를 실행하는 프로세서나 하드웨어
  • 운영체제, 서브루틴 패키지와 같이 새로운 소프트웨어에 연결되어야 하는 소프트웨어
  • 키보드나 기타 I/O 장치를 통해 소프트웨어를 사용하는 사람
  • 순서적인 연산에 의해 소프트웨어를 실행하는 절차

자원 추산

• 소프트웨어 개발에 필요한 자원을 예측하는 것
• 인적자원, 재사용 소프트웨어자원, 환경 자원

소프트웨어 프로젝트 추산

• 프로젝트 수행에 필요한 비용을 예측하는 것

프로젝트 계획 수립시 고려사항

• 프로젝트 복잡도
• 프로젝트 규모
• 구조적 불확실성의 정도
• 과거 정보의 가용성
• 위험성

소프트웨어 프로젝트 추산

• 비용을 예측하는 작업
• 가장 어렵고 오차 발생이 심한 작업

프로젝트 비용 결정 요소

프로젝트 요소

• 제품의 복잡도
• 시스템의 크기
• 요구되는 신뢰도 : 일정한 기간 내에 주어진 조건 하에서 필요한 기능을 수행하는 정도

자원 요소

• 인적 자원 : 관리자, 개발자의 자질
• 하드웨어 자원
• 소프트웨어 자원 : 개발 지원 도구

생산성 요소

• 개발자의 능력
• 개발 기간 : 개발 기간이 길어질수록 개발 비용이 적어짐

비용 산정 기법

하향식

전문가 감정 기법

• 경험이 많은 두 명 이상의 전문가에게 비용 산정 의뢰
• 개인적이고 주관적
• 편리하고 신속하게 비용 산정
• 의뢰자에게 신뢰를 얻을 수 있음

델파이 기법

• 전문가 감정 기법의 주관적 편견을 보완하기 위함
• 많은 전문가의 의견을 종합해 선정하는 방법
• 한 명의 조정자와 여러 명의 전문가

상향식

프로젝트의 세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법

LOC 기법

• 원시 코드 라인수 기법
• 소프트웨어 각 기능의 원시 코드 라인 수와 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법
• 측정이 용이하고 이해하기 쉬워 가장 많이 사용된다.
• 예측치 = (낙관치 + (4 X 기대치) + 비관치) / 6 = (a + 4m + b) / 6
• ManMonth = 개발 기간 X 투입 인원 = LOC / 1인당 월평균 코딩량
• 개발 비용 = ManMonth X 1인 인건비
• 개발 기간 = ManMonth / 투입 인원
• 생산성 = LOC / ManMonth

개발 단계별 인원수 기법

• Effort Per Task
• 각 기능을 구현시키는데 필요한 ManMonth를 생명 주기의 각 단계별로 산정
• LOC보다 정확하다.

수학적 산정 기법

• 상향식 비용 산정 기법
• 경험적 추정 모형 = 실험적 추정 모형
• COCOMO, Putnam, FP 모형

COCOMO 모형

• COnstructive COst MOdel
• Boehm이 제안
• 원시 프로그램 규모인 LOC에 의한 비용 산정 기법
• 개발할 소프트웨어의 규모를 예측한 후 소프트웨어의 종류에 따라 다르게 책정되는 비용 산정 방정식에 대입하여 비용을 구한다.
• 비용 견적의 강도 분석 및 유연성이 높아 널리 사용된다.
• 같은 규모의 프로그램이라도 성격에 따라 비용이 다르게 산정된다.
• 비용 산정 결과는 ManMonth로 나타낸다.

조직형

• Organic Mode
• 중소규모, 5만 라인 이하의 소프트웨어 개발
• 사무처리, 업무, 과학용 응용 소프트웨어 개발에 적합

반분리형

• Semi-Detached Mode
• 30만 라인 이하의 소프트웨어 개발
• 트랜잭션 처리 시스템, 운영체제, DBMS, 컴파일러, 인터프리터 등 유틸리티 개발에 적합

내장형

• Embedded Mode
• 30만 라인 이상의 소프트웨어 개발
• 최대형 규모의 트랜잭션 처리 시스템, 운영체제, 신호기 제어, 미사일 유도, 실시간 처리 등 시스템 프로그램 개발에 적합

종류

• 기본형 : Basic 소프트웨어 크기와 개발 유형만을 이용
• 중간형 : Intermediate 기본 COCOMO를 사용하나 제품, 컴퓨터, 개발요원, 프로젝트 특성에 따라 비용을 산정한다.
• 발전형 : Detail 개발 공정별로 보다 자세하고 정확하게 노력을 산출하여 비용을 산정하는 모형, 소프트웨어 환경과 구성요소가 사전에 정의되어 있어야하고 개발과정 후반부에 주로 적용한다.

Putnam 모형

• Putnam이 제안
• 생명 주기 예측 모형
• 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 한다.
• SLIM : Rayleigh-Norden 곡선과 Putnam 예측 모델을 기초로하여 개발된 자동화 추정 도구

FP 모형

• 기능 점수 = Function Point
• Albrecht이 제안
• 소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여하고 가중치와 영향도를 합하여 기능 점수를 구한 후 비용을 산정하는 기법
• 최근에 유용성과 간편성으로 비용 산정 기법 가운데 최선의 평가를 받고 있다.
• ESTIMACS : FP 모형을 기초로하여 개발된 자동화 추정 도구

프로젝트 일정 계획

• 프로젝트 프로세스를 이루는 소작업의 순서와 일정을 정하는 것
• 소프트웨어 개발 기간의 지연을 방지하고 프로젝트가 계획대로 진행되도록 일정을 계획
• 계획된 일정은 프로젝트의 진행을 관리하는데 기초 자료가 된다.
• 계획된 일정과 프로젝트의 진행도를 비교하여 차질이 있을 경우 조정할 수 있다.
• WBS, PERT/CPM, 간트 차트가 사용된다.

사람-노력 관계

• 소규모 개발 프로젝트에서는 한 사람이 요구사항을 분석하고 설계, 코딩, 테스트까지 수행할 수 있다.
• 프로젝트의 크기가 증가할수록 더 많은 사람들이 참여해야 한다.
• Brooks의 법칙 : 프로젝트 중 새로운 인력을 투입할 경우 작업 적응기간과 부작용으로 인해 일정이 더 지연된다.

노력 분배

• 노력을 개발과정에 분배할 때는 40-20-40 규칙을 권장한다.
• 분석 설계에 40, 코딩에 20, 테스트에 40

WBS

• Work Breakdown Structure = 업무 분류 구조
• 개발 프롲게트를 여러 개의 작은 관리 단위로 분할하여 계층적으로 기술한 업무 구조

PERT/CPM

• 프로젝트 지연을 방지하고 계획대로 진행되게 하기 위한 일정을 계획하는 것
• 초단시간 내 계획 완성을 위한 프로젝트 일정 방법
• 프로젝트 개발 기간을 결정하는 임계 경로를 제공한다.
• 통계적 모델을 적용해 개별 작업에 대한 가장 근접한 시간을 측정하는 기준이 된다.
• 각 작업에 대한 시작 시간을 정의하여 작업들 간의 경계 시간을 계산할 수 있게 한다.
• 가장 빠른 완료시간, 가장 늦은 완료시간, 총 자유시간을 구할 수 있다.

PERT

• Program Evaluation and Review Technique = 프로그램 평가 및 검토 기술
• 프로젝트에 필요한 전체 작업의 상호 관계를 표시하는 네트워크
• 낙관적인 경우, 가능성이 있는경우, 비관적인 경우로 나누어 각 단계별 종료 시기를 결정하는 방법
• 과거에 경험이 없어 소요 기간 예측이 어려운 소프트웨어에서 사용
• 노드와 간선으로 구성되며 원 노드에는 작업을 화살표 간선에는 낙관치, 기대치, 비관치를 표시한다.
• 결정 경로, 작업에 대한 경계시간, 작업 간의 상호관련성을 알 수 있다.
• 작업 예측치 = (비관치 + (4 X 기대치) + 낙관치) / 6

CPM

• Critical Path Method = 임계 경로 기법
• 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요 기간을 예측하는데 사용하는 기법
• 노드와 간선으로 구성된 네트워크로 노드는 작업을, 간선은 작업사이의 전후 의존 관계를 나타낸다.
• 원형 노드는 작업과 소요기간을 표시하고, 박스 노드는 이정표를 의미하며 예상 완료 시간을 표시한다.
• 전 작업이 완료된 후 다음 작업을 진행할 수 있다.
• 각 작업의 순서와 의존관계, 작업의 동시성을 한 눈에 볼 수 있다.
• 프로젝트 규모 추정 => 단계별 필요작업 분할 => 작업의 상호 의존 관계를 CPM 네트워크로 나타냄 => 일정 계획을 간트 차트로 나타냄

Gantt Chart

• 간트 차트 = 시간선 = Time Line
• 프로젝트의 각 작업들이 언제 시작하고 언제 종료되는지에 대한 작업 일정을 막대 도표를 이용하여 표시하는 프로젝트 일정표
• 중간 목표 미달성시 그 이유와 기간을 예측 가능
• 사용자와의 문제점이나 예산의 초과 지출 등을 관리
• 자원 배치와 인원 계획에 사용 가능
• 다양한 형태로 변경 가능
• 작업 경로를 표시할 수 없다.
• 계획의 변화에 대한 적응성이 약하다.
• 계획 수립 또는 수정 때 주관적 수치에 기울어지기 쉽다.
• 이정표, 작업 일정, 작업 기간, 산출물로 구성

프로젝트 조직 구성 계획

분산형 팀 구성

• 팀원 모두가 의사 결정에 참여하는 비이기적인 구성 방식
• 민주주의식 팀 구성
• 팀 구성원의 참여도와 만족도를 높이고 이직률을 낮게 한다.
• 팀 구성원 각자가 서로의 일을 검토하고 다른 구성원이 일한 결과에 대해 같은 그룹의 일원으로 책임을 진다.
• 여러 사람의 의사를 교류하므로 복잡하고 이해되지 않는 문제가 많은 장기 프로젝트 개발에 적합
• 링 모양의 구조를 가진다.
• 팀 구성 방법 중 가장 많은 의사 소통 경로를 갖는다.

중앙 집중형 팀 구성

• 관리자가 의사 결정을 하고 그 결정에 따르는 구성 방식
• 책임 프로그래머 팀 구성
• 프로젝트 수행에 따른 모든 권한과 책임을 한 명의 관리자에게 위임하고 기술 및 관리 지원을 위해 인력을 투입하는 형태
• 소규모 프로젝트에 적합
• 프로젝트의 성공은 책임 프로그래머의 능력에 달렸다.
• 책임 프로그래머에 따라 의사 결정이 이뤄지기 때문에 의사 결정이 빠르고 의사 교환 경로를 줄일 수 있다.
• 책임 프로그래머 : 요구 분석 및 설계, 기술적 판단, 프로그래머 작업 지시 및 배분
• 프로그래머 : 책임 프로그래머 지시에 따른 코딩, 테스트, 디버깅, 문서 작성
• 프로그램 사서 : 프로그램 리스트, 설계 문서, 테스트 계획 관리
• 보조 프로그래머 : 책임 프로그래머의 업무 지원, 기술적 문제에 대한 자문, 사용자와 품질 보등 담당자 섭외, 책임 프로그래머 감독 하 분석, 설계 구현 담당

계층적 팀 구성

• 분산형과 중앙 집중형을 혼합한 형태로 혼합형 팀 구성
• 초급 프로그래머를 작은 그룹으로 만들어 각 그룹을 고급 프로그래머가 관리
• 경험자와 초보자를 구별
• 기술 인력이 관리를 담당하게 되어 좋은 기술력을 사장시킬 수 있고, 기술 인력이 업무 관리 능력을 갖춰야한다.

소프트웨어 품질 보증

품질 표준

소프트웨어의 운영적인 특성, 소프트웨어의 변경 수용능력, 새로운 환경에 대한 소프트웨어의 적응 능력에 따라 분류

운영특성

• 정확성 : Correctness 사용자의 요구 기능 충족
• 신뢰성 : Reliability 요구된 기능을 오류 없이 수행하는 정도
• 효율성 : Efficiency 소프트웨어가 자원을 쓸데없이 낭비하지 않아야한다.
• 무결성 : Integrity 허용되지 않는 사용이나 자료의 변경을 제어하는 정도
• 사용 용이성 : Usability 소프트웨어는 적절한 UI와 문서를 가지고 있어야한다.

변경 수용 능력

• 유지보수성 : Maintainability 변경 및 오류 사항 교정에 대한 노력을 최소화 하는 정도, 소프트웨어를 진화하는 것이 가능해야 한다.
• 유연성 : Flexibility 소프트웨어를 얼마만큼 쉽게 수정할 수 있는가의 정도
• 시험 역량 : Testability 프로그램을 시험할 수 있는 정도

적응 능력

• 이식성 : Portability 다양한 하드웨어 환경에 운용이 가능하도록 쉽게 수정될 수 있는 정도
• 재사용성 : Reusability 전체나 일부 소프트웨어를 다른 목적으로 사용할 수 있는가의 정도
• 상호 운용성 : Interoperability 다른 소프트웨어와 정보를 교환할 수 있는 정도

품질 보증

• SQA = Software Quality Assurance
• 어떠한 소프트웨어가 이미 설정된 요구사항과 일치하는가를 확인하는 데 필요한 개발 단계 전체에 걸친 계획적이고 체계적인 작업
• 소프트웨어 개발 초기에 소프트웨어 특성과 요구사항을 철저히 파악하여 품질 목표를 설정하고, 개발 단계에서는 정형 기술 검토를 통해 품질 목표의 충족 여부를 점검하며, 개발 후에는 디버깅과 시험 과정을 거친다.

정형 기술 검토

• FTR = Formal Technical Review
• 가장 일반적인 검토 방법으로 소프트웨어 기술자들에 의해 수행되는 소프트웨어 품질 보증 활동
• 검토회의, 검열 등이 있으며 회의 형태로 수행된다.
• 검토중인 소프트웨어가 해당 요구사항과 일치하는지를 검증
• 미리 정해진 표준에 따라 표현되는지를 확인
• 기능과 로직에 오류가 있는지 확인
• 소프트웨어가 균일한 방식으로 개발되도록 한다.
• 프로젝트를 용이하게 관리하도록 한다.

정형 기술 검토 지침사항

• 제품 검토에만 집중
• 의제를 제한하여 진행
• 논쟁과 반박을 제한
• 문제 영역을 명확히 표현
• 해결책이나 개선책에는 논하지 말라
• 참가자의 수를 제한하고 사전 준비를 강요
• 검토될 확률이 있는 각 제품에 대한 체크리스트 개발
• 자원과 시간 일정을 할당
• 모든 검토자들을 위해 훈련
• 사전에 작성한 메모를 공유
• 검토 과정과 결과를 재검토

정형 기술 검토 유형

Walkthrough

• 검토 회의 = 워크스루
• 소프트웨어 개발 각 단계에서 개최하는 기술 평가 회의
• 소프트웨어 구성요소와 같은 작은 단위를 검토하는 것
• 오류의 조기 검출을 목적으로 하며 발견된 오류는 문서화
• 검출된 오류는 회의 후에 해결
• 3~5명이 검토에 참여해야하며 두 시간 이내
• 검토를 위한 자료를 미리 배포하여 검토, 미리 검토하는 시간도 두 시간 이내

Inspections

• 검열 = 심사
• 검토 회의를 발전시킨 형태
• 소프트웨어 개발 단계에서 산출된 결과물의 품질을 평가하며 이를 개선시키는데 사용

기타

• 검증 : Verification 설계의 각 과정이 올바른지, 프로그램이나 하드웨어에 오류가 있는지를 검사
• 확인 : Validation 올바른 제품을 생산할 수 있도록 정의, 분석이 잘 되었는지를 검사
• 인증 : Certification 사용자 또는 전문가가 소프트웨어 품질을 공식적으로 확인
• 소프트웨어 시험 : Test
• 오류 수정 : Debugging

소프트웨어 신뢰성과 가용성

• 신뢰성 : 프로그램이 주어진 환경에서 주어진 시간동안 오류 없이 작동할 확률로 측정과 예측이 가능하다.
• 가용성 : 한 프로그램이 주어진 시점에서 요구사항에 따라 운영되는 확률

측정

• 신뢰성 측정은 MTBF를 이용한다.
• MTBF
  • Mean Time Between Failure
  • 평균 고장 간격
  • 수리가 가능한 시스템이 고장난 후부터 다음 고장이 날 때까지의 평균 시간
  • MTBF = MTTF + MTTR
• MTTF
  • Mean Time To Failure
  • 평균 가동 시간 = 고장 평균 시간
  • 수리 불가능한 시스템의 사용 시점부터 고장이 발생할 때까지의 가동 시간 평균
  • MTTF = (가동중1 + 가동중2 + 가동중3 + … + 가동중 n) / n
• MTTR
  • Mean Time To Repair
  • 평균 수리 시간
  • 시스템 고장이 발생하여 가동하지 못한 시간들의 평균
  • MTTR = (고장중1 + 고장중2 + 고장중3 + … + 고장중 n) / n
• 가용성 측정
  • 시스템의 총 운용 시간 중 정상적으로 가동된 시간의 비율
  • 가용성 = 가동시간 / (가동시간 + 고장시간) = MTBF / (MTBF + MTTR)

위험 관리

• Risk Analysis
• 프로젝트 추진 과정에서 예상되는 각종 돌발 상황을 미리 예상하고 대책을 수립하는 활동
• 위험은 불확실성과 손실을 가지고 있는데, 위험관리로 대비한다.
• 위험 식별 => 위험 분석 및 평가 => 위험 관리 계획 => 위험 감시 및 조치

범주

• 프로젝트 위험 : Project Risk
• 기술 위험 : Technical Risk
• 비즈니스 위험 : Business Risk

종류

• 인력 부족
• 예산 관리
• 일정 관리
• 사용자 요구사항 변경 : 대표적 위험 요소

Charette가 제안한 종류

• 알려진 위험 : 프로젝트 계획서, 기술적 환경, 정보 등에 의해 발견 될 수 있는 위험
• 예측 가능한 위험 : 과거의 경험으로 예측 가능한 위험
• 예측 불가능한 위험 : 사전 예측이 매우 어려운 위험

위험 분석 및 평가

• 프로젝트에 내재한 위험 요소를 인식하고 그 영향을 분석하는 활동
• 위험 추산(Risk Estimation) 작업을 통해 수행된다.
• 가능한 모든 위험 요소와 영향을 분석하여 의사결정에 반영
• 위험표(Risk Table)을 작성하여 활용한다.

위험표

• 위험 내용
• 위험 범주
• 발생 확률
• 영향력
• 위험 감시 및 조치

위험 감시 및 조치

• 위험 회피 : Risk Avoidance 예상하고 회피
• 위험 감시 : Risk Monitoring 위험 요소 징후에 대해 계속적으로 인지하는 것
• 위험 관리 : Risk Management
• 비상 계획 수립 : Contingency Plan 위험 회피 전략이 실패할 경우 위험에 대해 관리하고 대비책과 비상 계획을 수립한다.

소프트웨어 형상 관리

• SCM = Software Configuration Management
• 소프트웨어 변경 사항을 관리하기 위해 개발된 일련의 활동
• 소프트웨어 변경의 원인을 알아내고 제어하며 적절이 변경되고 있는지 확인하여 담당자에게 통보하는 작업
• 형상 관리는 소프트웨어 개발의 전 단계에 적용되는 활동
• 유지보수 단계에서도 수행
• 형상 관리는 소프트웨어 개발의 전체 비용을 줄인다.
• 개발 과정의 여러 방해 요인을 최소화시킨다.
• 형상은 소프트웨어 각 개발 단계의 결과물

형상 항목

• SCI = Software Configuration Item
• 스시템 명세서
• 소프트웨어 프로젝트 계획서
• 소프트웨어 요구사항 명세와 실행가능한 프로토타입
• 예비 사용자 매뉴얼
• 설계 명세서
• 원시 코드 목록
• 테스트 계획, 절차, 시험 사례, 결과
• 운영과 설치에 필요한 매뉴얼
• 실행 프로그램
• DB 기술서 : 스키마, 파일 구조, 초기 내용
• 구축된 사용자 매뉴얼
• 유지보수 문서 : 변경 요청서, 변경 처리 보고서
• 소프트웨어 공학을 위한 표준과 절차

관리 기능

• 형상 식별 : 대상에게 이름과 관리 번호를 부여하고 계층(트리)구조로 구분
• 버전 제어 : 다른 버전과의 형상 항목을 관리하려 특정 절차와 도구를 결합시키는 작업
• 변경 제어 : 형상 항목의 변경 요구를 검토해 현재의 기준선이 잘 반영될 수 있도록 조정
• 형상 감사 : 기준선의 무결성을 평가
• 형상 상태 보고

전통적 소프트웨어 개발 방법

• 고전적 소프트웨어 개발 방법 = 구조적 소프트웨어 개발 방법
• 과거의 많은 소프트웨어 개발 경험을 토대로하여 성공적으로 평가되는 소프트웨어 분석 및 설계 방법들을 집대성하여 하나의 개발 방법으로 정형화한 것

요구사항 분석

• 소프트웨어 개발의 첫 단계
• 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화하는 활동
• 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약 설정
• 사용자 요구를 정확하게 추출하여 목표를 정하고 어떤 방식으로 해결할 것인지 결정
• 요구사항 분석을 통한 결과는 소프트웨어 설계단계에서 필요한 자료가 된다.
• 사용자의 요구사항을 정확하고 일관성있게 분석하여 문서화
• 소프트웨어 분석가에 의해 요구사항 분석이 수행

요구사항 분석작업

• 문제 인식 : 사용자 면담, 설문조사 및 협조, 문서 검토
• 평가와 종합 : 요구사항에 대한 정보를 평가하고 해결책 종합
• 모델 제작 : 내용을 이해하기 쉽도록 모델로 작성
• 문서화와 검토 : 요구사항 분석 명세서 작성

요구사항 분석의 어려움

• 대화 장벽 : 다이어그램 및 프로토타입 이용
• 시스템의 복잡도 : 구조적 분석이나 객체지향 분석 이용
• 요구의 변경 : 수정 요구와 상반된 요구들의 수용 기술 필요
• 요구 명세화의 어려움 : 제도적인 요구 분석 기술 필요

분석가의 자질

• 개발 경험이 많아야한다.
• 사용자의 요구를 정확히 수용하고 환경을 이해해야한다.
• 설계에 필요한 자료를 충분히 제공
• 시간 배정과 계획을 빠른 시간내에 파악
• 하드웨어 소프트웨어를 포함한 컴퓨터 기술에 대한 이해
• 고객 관점에서의 문제 파악

구조적 분석 기법

• 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법
• 도형 중심의 도구를 사용하므로 분석가와 사용자 간의 대화가 용이
• 하향식 방법을 사용해 시스템을 세분화하고 분석의 중복을 배제할 수 있다.
• 자료흐름도, 자료사전, 소단위 명세서, 개체 관계도, 상태 전이도, 제어 명세서

구조적 분석 도구

자료 흐름도

• DFD = Data Flow Diagram = 자료 흐름 그래프 = 버블 차트
• 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법
• 시스템 안의 프로세스와 자료 저장소 사이의 자료 흐름을 나타내는 그래프
• 자료흐름과 처리를 중심으로하는 구조적 분석 기법
• 자료 흐름과 기능을 자세히 표현하기 위해 단계적으로 세분화된다.
• 자료는 처리(프로세스)를 거쳐 변환될 때마다 새로운 이름이 부여된다.
• 처리는 입력 자료가 발생하면 기능을 수행한 후 출력 자료를 산출한다.
• 자료 흐름도를 세분화 할 수 록 소프트웨어 설계와 구현작업이 용이해진다.

자료 흐름도 구성요소

• 프로세스
  • 자료를 변환시키는 시스템의 한 부분을 나타낸다.
  • 처리 = 기능 = 변환 = 버블
  • 원이나 둥근 사각형으로 표시하고 안에 프로세스 이름을 적는다.
• 자료 흐름
  • Data Flow
  • 자료의 흐름이나 연관관계를 나타낸다.
  • 화살표 위에 자료의 이름을 적는다.
• 자료 저장소
  • Data Store
  • 시스템에서의 자료 저장소를 나타낸다.
  • 파일, 데이터베이스
  • 도형 안에 자료 저장소 이름을 적는다.
• 단말
  • Terminator
  • 시스템과 교신하는 외부 개체
  • 입력 데이터가 만들어지고 출력 데이터를 받는다.
  • 정보의 생산자와 소비자
  • 도형 안에 이름을 적는다.

자료 사전

• DD = Data Dictionary = 데이터의 데이터 = Meta Data
• 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것
• 데이터를 설명하는 데이터

자료 사전 기호

• = : 자료의 정의 is composed of
• • : 자료의 연결 and
• ( ) : 자료의 생략 optional
• [ | ] : 자료의 선택 or
• { } : 자료의 반복 Iteration of
• * * : 자료의 설명 comment

소단위 명세서

• Mini Specification = 프로세스 명세서
• 세분화된 자료 흐름도에서 최하위 단계 프로세스의 처리 절차를 기술한 것
• 분석가의 문서
• 자료 흐름도를 지원하기 위해 작성
• 서술 문장, 구조적언어, 의사결정나무, 의사 결정표, 그래프 등을 이용해 기술

개체 관계도

• ERD = Entity Relationship Diagram
• 시스템에서 처리되는 개체와 개체의 구성과 속성, 개체 간의 관계를 표현하여 자료를 모델화하는 데에 사용
• Entity, Attribute, Relationship으로 구성

상태 전이도

• STD = State Transition Diagram
• 시스템에 어떤 일이 발생할 경우 시스템의 상태와 상태 간의 전이를 모델화한 것
• 상태 전이도를 통해 개발자는 시스템의 행위를 정의할 수 있다.

CASE

요구사항 분석을 위한 자동화 도구

• SADT : Structured Analysis and Design Technique
• SREM : Software Requirements Engineering Methodology = RSL/REVS
• PSL/PSA : Problem Statement Language / Problem Statement Analyzer
• TAGS : Technology for Automated Generation of Systems

HIPO

• Hierarchy Input Process Output
• 시스템의 분석 및 설계나 문서화할 때 사용되는 기법
• 기본 시스템 모델은 입력, 처리, 출력으로 구성
• 하향식 소프트웨어 개발을 위한 문서화 도구
• 기호, 도표 등을 사용하므로 이해하기 쉽다.
• 기능과 자료의 의존 관계를 동시에 표현할 수 있다.
• 변경, 유지보수가 쉽다.

HIPO Chart

• 시스템의 기능을 여러 개의 고유 모듈로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것
• 가시적 도표, 총체적 도표, 세부적 도표가 있다.

가시적 도표

• 도식 목차 = Visual Table of Contents
• 시스템 전체적인 기능과 흐름을 보여주는 트리 구조도

총체적 도표

• 총괄 도표 = 개요 도표 = Overview Diagram
• 프로그램을 구성하는 기능을 기술한 것
• 입력, 출력, 처리에 대한 전반적인 정보를 제공

세부적 도표

• 상세 도표 = Detail Diagram
• 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표

설계

• 구조적 분석 기법의 결과물인 자료 흐름도 등으로 소프트웨어 기능과 프로그램 구조, 모듈 설계 전략, 평가 지침, 문서화 도구를 제공하는 체계화된 기법
• 자료 흐름 중심 설계 기법
• 자료 흐름도, 자료 사전, 개체 관계도, 소단위 명세서가 준비된 이후에 설계

설계 모형

• 데이터 설계, 구조 설계, 인터페이스 설계, 프로시저 설계로 구성된다.
• 소프트웨어 품질 평가를 위한 지침

데이터 설계

• Data Design
• 요구사항 분석 단계에서 생성된 정보를 소프트웨어를 구현하는데 필요한 자료 구조로 변환하는 것
• ERD를 이요하여 정의된 개체와 관계, 자료 사전에 정의된 자료의 설명 등이 데이터 설계의 기초가 된다.

구조 설계

• Architectural Design
• 소프트웨어를 구성하는 모듈 간의 관계와 프로그램 구조를 정의하는 것
• DFD, DD, STD 등과 모듈의 상호 작용이 구조 설계의 기초가 된다.

인터페이스 설계

• Interface Design
• 소프트웨어와 상호 작용하는 시스템, 사용자 등과 어떻게 통신하는지를 기술하는 것
• DFD 등이 인터페이스 설계의 기초가 된다.

프로시저 설계

• 절차 설계
• 모듈이 수행할 기능을 절차적 기술로 바꾸는 것
• 소단위 명세서, 상태 전이도의 정보가 절차 설계의 기초가 된다.

기타 분류

• 사용자적 관점
  • 내부 설계 : 시스템 내부 조직과 세부 절차를 개념화하고 명세화
  • 외부 설계 : 시스템 외부 특성 명세화
• 관리적 관점
  • 기본 설계 : 요구사항 분석 단계에서 생성된 정보를 자료 구조와 소프트웨어 구조로 변경
  • 상세 설계 : 기본 설계 사항을 구체적인 자료 구조와 알고리즘으로 표현

설계 기본 원리

모듈화

• Modularity
• 소프트웨어를 모듈 단위로 나누는 것

추상화

• Abstraction = 개념화
• 문제의 세부 사항을 먼저 설계하기 보다는 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시켜 나가는 설계 방법
• 기능 추상화 : 입력 자료를 출력 자료로 변환하는 과정을 추상화하는 방법
• 제어 추상화 : 제어의 정확한 메커니즘을 정의하지 않고 원하는 효과를 정하는 데 이용하는 방법
• 자료 추상화 : 자료와 자료에 적용될 수 있는 기능을 함께 정의함으로써 자료 객체를 구성하는 방법

단계적 정제

• Stepwise Refinement
• 문제를 사윙의 중요 개념으로부터 하위의 개념으로 구체화시키는 분할 기법

정보 은닉

• Information Hiding
• 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
• 모듈을 독립적으로 수행할 수 있고, 하나의 모듈이 변경되더라도 다른 모듈에 영향을 주지 않으므로 수정, 시험, 유지보수가 쉽다.

프로그램 구조

• Program Structure = 제어 계층 구조
• 모듈의 계층적 구성을 나타내는 것
• 일반적으로 트리 구조의 다이어그램으로 표기
• 공유도 : Fan - In 어떤 모듈을 제어(호출)하는 모듈의 수
• 제어도 : Fan - Out 어떤 모듈에 의해 제어(호출)되는 모듈의 수

자료 구조

• 자료 사이의 논리적인 관계를 표현한 것

좋은 설계

• 소프트웨어 구조를 나타내야한다.
• 독립적인 기능적 특성을 가진 요소(모듈)로 구성되어야 한다.
• 특정 기능 또는 부기능을 수행하는 논리적 요소들로 분리되는 구조를 가져야 한다.
• 모듈 간의 효과적인 제어를 위해 설계에서 계층적 자료조직이 제시되어야 한다.
• 자료와 프로시저에 대한 분명하고 분리된 표현을 포함해야 한다.
• 모듈 간과 외부 개체 간의 연결 복잡성을 줄이는 인터페이스를 가져야 한다.
• 요구사항 분석에서 얻어진 정보를 이용하여 반복적인 방법으로 이루어져야 한다.
• 요구사항을 모두 구현해야 하고, 유지보수가 쉬워야한다.
• 모듈의 기능을 예측할 수 있도록 정의한다.
• 적당한 모듈의 크기를 유지한다.
• 모듈 간의 결합도는 낮추고 응집도는 높인다.
• 전체적이고 포괄적인 개념을 설계한 후 차례대로 세분화하여 구체화시켜 나간다.
• 이식성을 고려한다.

모듈

• 모듈화 : 소프트웨어를 각 기능별로 분할하는 것
• 모듈 : 각 기능별로 분할한 것

기능적 독립성

• 모듈의 기능적 독립성은 소프트웨어를 구성하는 각 모듈의 기능이 독립됨을 의미
• 모듈화, 추상화, 정보 은닉의 부산물
• 모듈이 하나의 기능만을 수행하고 다른 모듈과의 과도한 상호작용을 배제
• 독립된 모듈은 특정 기능을 수행하고 다른 모듈과는 간단한 인터페이스만을 가지므로 개발이 쉽고 재사용이 가능
• 독립성이 높은 모듈일 수록 모듈을 수정하더라도 다른 모듈에게는 영향을 미치지 않음
• 오류가 발생해도 쉽게 발견할 수 있고 해결 가능
• 결합도와 응집도에 의해 측정되며 결합도는 약하게, 응집도를 강하게 하고 모듈의 크기를 작게 만들어야한다.
• 결합도와 응집도는 소프트웨어 설계시 평가 지침이 된다.

결합도

• Coupling
• 모듈 간에 상호 의존하는 정도
• 각 모듈 간의 결합도가 약해야 하며 의존하는 모듈이 적어야한다.
• 결합도가 강하면 시스템 구현 및 유지보수 작업이 어렵다.

결합 정도

약함강함

자료 결합도

스탬프 결합도

제어 결합도

외부 결합도

공통 결합도

내용 결합도

자료 결합도

• Data Coupling
• 모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도
• 모듈이 다른 모듈을 호출하면서 매개 변수나 인수로 데이터를 넘겨주고, 호출받은 모듈은 받은 데이터에 대한 처리 결과를 다시 돌려주는 것
• 모듈 간의 내용을 전혀 알 필요가 없는 상태로 한 모듈의 내용을 변경하더라도 다른 모듈에는 전혀 영향을 미치지 않는 가장 좋은 결합도

스탬프 결합도

• Stamp Coupling = 검인 결합도
• 모듈 간의 인터페이스로 배열이나 레코드 등의 자료구조가 전달될 때의 결합도
• 두 모듈이 동일한 자료 구조를 조회하는 경우의 결합도

제어 결합도

• Control Coupling
• 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어신호를 이용하여 통신하거나 제어 요소를 전달하는 결합도
• 상위 모듈이 하위 모듈의 상세한 처리 절차를 알고 있어 이를 통제하는 경우나 처리 기능이 두 모듈에 분리되어 설계된 경우 발생
• 권리 전도현상이 발생

외부 결합도

• External Coupling
• 모듈에서 외부로 선언한 데이터(변수)를 다른 모듈에서 참조할 때의 결합도

공통 결합도

• Common Coupling = 공유 결합도
• 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도
• 공통 데이터 영역이 내용을 변경하면 이를 사용하는 모든 모듈에 영향을 미친다.

내용 결합도

• Content Coupling
• 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때의 결합도
• 모듈에서 다른 모듈로 제어가 이동하는 경우에도 내용 결합도

응집도

• Cohesion
• 정보 은닉 개념을 확장한 것
• 명령어나 호출문 등 모듈의 내부 요소들의 서로 관련되어 있는 정도
• 모듈이 독립적인 기능으로 정의되어 있는 정도
• 독립적인 모듈이 되기 위해서는 각 모듈의 응집도가 강해야한다.

응집 정도

강함약함

기능적 응집도

순차적 응집도

교환적 응집도

절차적 응집도

시간적 응집도

논리적 응집도

우연적 응집도

기능적 응집도

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

순차적 응집도

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

교환적 응집도

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

절차적 응집도

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

시간적 응집도

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

논리적 응집도

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

우연적 응집도

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

효과적인 모듈 설계

• 결합도는 줄이고 응집도는 높여 모듈의 독립성을 높인다.
• 모듈의 제어영역에서 모듈의 영향영역을 유지시킨다.
• 복잡도와 중복성을 줄이고 일관성을 유지시킨다.
• 모듈의 기능은 예측이 가능해야한다.
• 유지보수가 쉬어야한다.
• 모듈 크기는 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 분해한다.
• 하나의 입구와 하나의 출구를 갖도록 한다.

설계 방법

자료설계

• 설계의 첫번째 작업
• 요구사항 분석에서 생성된 여러 모델들을 소프트웨어를 구현하는 데 필욯나 자료 구조로 변환하는 것

구조 설계

• 프로그램 구조를 개발하고 소프트웨어 구성 요소들 간의 관계를 정의하는 것
• 구조 도표 : 소프트웨어 기능을 몇 개의 고유 기능으로 분할하여 블랙 박스로 나타내고 블랙 박스 간의 인터페이스를 계층 구조로 표현하는 것
• 변환 분해 접근법 : DFD를 흐름에 따라 구분하여 프로그램 구조 도표로 변환시키는 방법
• 거래 분해 접근법 : DFD에서 거래에 해당하는 부분을 중심으로 자료 흐름도를 거래 중심 구조 도표로 변환하는 방법

구조적 설계 절차

1. 정보 흐름의 유형을 설정
2. 흐름의 경계를 표시
3. 자료 흐름도를 프로그램 구조로 사상
4. 제어 계층을 분해시켜서 정의
5. 경험적 방법으로 구체화

인터페이스 설계

소프트웨어 상호 작용하는 시스템, 사용자 등과 어떻게 통신하는지를 기술하는 과정

인터페이스 경고 메세지 지침

• 메세지 내용을 이해하기 쉬어야한다.
• 오류 회복을 위한 구체적인 설명이 제공되어야 한다.
• 소리나 색을 이용해 듣거나 보기 쉽도록 의미를 전달해야 한다.
• 오류로 인해 발생될 수 있는 부정적 내용은 절대 사용하면 안 된다.

UI 평가 기준

• 소프트웨어 사용법을 쉽게 배울 수 있고, 특정 기능 수행 속도가 빨라야한다.
• 사용중 오류 발생 빈도가 적어야한다.
• 소프트웨어를 사용하는 사용자의 만족을 충족시켜야 한다.
• 소프트웨어 사용법을 쉽게 기억할 수 있도록 제작되어야 한다.

프로시저 설계

• 절차 설계는 데이터, 아키텍쳐, 인터페이스 설계가 이뤄진 후 수행되는 설계 작업
• 모듈이 수행할 기능을 절차적 기술로 바꾸는 것
• 코드에 가까운 추상화 수준의 모듈 명세서를 작성하는 것
• 그래픽 설계 표기법이나 프로그램 설계 언어 등을 사용해서 나타낸다.

흐름도

• 그래픽 설계 표기법
• Flowchart

N-S 차트

• Nassi-Schneiderman Chart = 박스 다이어그램 = Chapin Chart
• 그래픽 설계 표기법
• 논리의 기술에 중점을 둔 도형을 이용한 표현 방법
• 박스를 기본 요소로 하여 연속, 선택 및 다중 선택, 반복 등의 제어 논리 구조를 표현
• GOTO나 화살표를 사용하지 않는다.
• 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는 데 적합하다.
• 선택과 반복 구조를 시각적으로 표현한다.
• 이해하기 쉽고, 코드 변환이 용이하다.
• 읽기는 쉽지만 작성하기가 어렵다.
• 임의로 제어를 전이하는 게 불가능하다.
• 총체적인 구조 표현과 인터페이스를 나타내기가 어렵다.
• 단일 입구와 단일 출구로 표현한다.

프로그램 설계 언어

• PDL = Program Design Language = 의사 코드 = Pseudo Code = 구조적 영어
• 영어 단어를 이요해 구조적 프로그래밍의 제어 구조를 기술하는 것
• 하향식 접근 방식으로 논리의 전체 흐름을 표현한다.
• 사용자와의 의사소통을 용이하게 한다.
• 현재 프로그래밍 언어와 유사한 서술적 표현에 의해 프로그램, 설계, 시스템 검토, 문서화 기법에 사용된다.

자료 구조 중심 설계

• 자료 구조 중심 분석 기법에서 생성한 요구사항 분석 명세서를 토대로 입력과 출력 자료 구조로부터 프로그램의 구조와 세부 절차를 도출해 내는 방법
• Jackson의 JSD, Warnier-Orr의 DSSD

구현

• 설계 단계에서 생성된 설계 명세서를 컴퓨터가 알 수 있는 모습으로 변환하는 과정
• 프로그래밍 = 코딩
• 각 모듈을 프로그래밍 언어를 사용해 원시 코드로 작성하고 문서화하는 작업
• 설계를 철저히 반영시키고 원시 코드를 간단 명료하게 작성한다.
• 사용할 프로그램이 언어와 코딩 스타일 등을 결정해야한다.

프로그래밍 언어

• 1세대 : 기계어, 어셈블리어
• 2세대 : FORTRAN, ALGOL, COBOL, BASIC
• 3세대 : PL/1, PASCAL, C, Lisp, C++
• 4세대 : 비절차적 언어, 자연언어, 사용자 중심언어, 응용 프로그램 생성기 언어, 프로토타입 언어, SQL, 정보 검색어, 보고서 작성기

구조적 프로그래밍

• Dijkstra에 의해 제안
• 신뢰성 있는 소프트웨어의 생산과 코딩의 표준화 등을 위해 개발
• 순차, 선택, 반복 (Sequence, Selection, Iteration)

검사

Test

검사 사례 설계 고려사항

• 모듈 내의 모든 독립적인 경로가 적어도 한 번은 수행되어야 한다.
• 가능한 복잡한 논리는 배제한다.
• 임의의 조건을 만족시켜야 한다.
• 내부 자료 구조를 사용하여 테스트를 수행한다.

화이트 박스 테스트

• 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 검사하여 검사 사례를 설계하는 방법
• 설계된 절차에 초점을 둔 구조적 테스트
• 프로시저 설계의 제어 구조를 사용하여 검사 사례를 설계한다.
• 테스트 초기에 적용된다.
• 모듈 안 작동을 직접 관찰한다.
• 원시 코드의 모든 문장을 한 번 이상 수행한다.
• 논리 흐름도, 루프 구조, 순환 복잡도에 관한 오류를 찾을 수 있다.
• 기초 경로 검사, 제어 구조 검사 (조건 검사, 루프 검사, 데이터 흐름 검사)

기초 경로 검사

• Basic Path Testing
• Tom McCabe가 제안
• 대표적인 화이트 박스 테스트
• 절차
  1. 흐름도 작성
  2. 논리적 복잡도 측정
  3. 독립 경로들의 기초 집합 결정
  4. 기초 집합의 각 경로를 실행시키는 검사 사례 선정
• 제어 흐름도
  • 제어 흐름을 표현하기 위해 사용되는 그래프
  • 프로그램 그래프 = 흐름 그래프
  • 노드(원) : 절차적 명령문
  • 화살표 : 제어의 흐름
  • 영역 : 화살표와 노드로 둘러싸인 구역, 외부 구역도 하나의 영역에 포함된다.
• 순환 복잡도
  • 한 프로그램의 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도
  • 제어 흐름도 이론에 기초를 둔다.
  • 순환 복잡도는 제어 흐름도의 영역 수와 일치하므로 영역 수를 계산한다.
  • 순환복잡도 = 화살표 수 - 노드 수 + 2

제어 구조 검사

• 조건 검사
  • Condition Testing
  • 모듈 내에 있는 논리적 조건을 검사하는 검사 사례 설계 기법
• 루프 검사
  • Loop Testing
  • 반복 구조에 초점을 맞춰 실시하는 검사 사례 설계 기법
  • 초기화 오류, 인덱싱 증가 오류, 경계값 오류 등을 발견할 수 있다.
• 데이터 흐름 검사
  • Data Flow Testing
  • 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 검사 사례 설계 기법

블랙 박스 테스트

• 소프트웨어가 수행할 특정 기능을 알기 위해 각 기능이 완전히 작동되는 것을 입증하는 검사
• 기능 검사
• 소프트웨어 인터페이스에서 실시되는 검사
• 테스트 과정 후반부에 적용
• 적합한 입력에 대한 출력의 정확성을 점검
• 동치 분할 검사, 경계값 분석, 원인효과 그래프 검사, 오류 예측 검사, 비교 검사

동치 분할 검사

• Equivalence Partitioning Testing = 동등 분할 기법
• 입력 자료에 초점을 맞춰 검사 사례를 만들고 검사하는 방법
• 입력 조건에 타당한 입력 자료와 그렇지 않는 입력 자료의 개수를 균등하게 하여 검사 사례를 정하고, 해당 입력 자료에 맞는 결과가 출력되는지 확인하는 방법

경계값 분석

• Boundary Value Analysis
• 입력 자료에만 치중한 동치 분할 기법을 보완하기 위한 기법
• 입력 조건의 중간 값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용
• 입력 조건의 경계값을 검사 사례로 선정

원인효과 그래프 검사

• Cause-Effect Graphing Testing
• 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석하여 효용성이 높은 검사 사례를 선정하여 검사하는 기법
• 그래프로 표현한다.

오류 예측 검사

• Fault Based Testing = Mutation Testing = 데이터 확인 검사
• 과거의 경험이나 확인자의 감각으로 검사하는 기법
• 보충적 검사 기법

비교 검사

• Comparison Testing
• 여러 버전의 프로그램에 동일한 검사 자료를 제공해 동일한 결과가 출력되는지 검사하는 기법

검사 전략

• 설계된 검사 사례를 수행하는 것
• 단위 검사 : 프로그램의 기본 단위인 모듈 수준에서 시작
• 통합 검사 : 단위 검사 후 모듈을 결합하여 전체 시스템에 대해 검사
• 검증 검사 : 사용자의 요구사항을 충족시키는가를 검사
• 시스템 검사 : 개발된 소프트웨어가 컴퓨터 시스템에서 완벽하게 수행되는지를 검사

단위 검사

• Unit Test
• 코딩이 이뤄진 후 모듈에 초점을 맞춰 검사하는 것
• 화이트 박스 테스트 기법을 사용
• 인터페이스, 외부적 I/O, 자료구조, 독립적 기초 경로, 오류 처리경로, 경계 조건 등을 검사

통합 검사

• Integration Test
• 단위 검사가 완료된 모듈을 결합하여 하나의 시스템으로 완성시키는 과정에서의 검사
• 모듈 간 인터페이스와 연관된 오류를 밝히기 위한 검사 기법

비점진적 통합 방식

• 단계적으로 통합하는 절차 없이 모든 모듈이 미리 결합되어 프로그램 전체를 검사하는 방법
• 전체 프로그램을 대상으로 하므로 오류 발견이 힘들고 수정이 어렵다.

점진적 통합 방식

• 모듈 단위로 단계적으로 통합하면서 검사하는 방식
• 하향식, 상향식, 혼합식 통합 방식이 있다.
• 오류 수정이 용이하고 인터페이스와 연관된 오류를 완전히 검사할 가능성이 높다.

하향식 통합 검사

• Top Down Integration Test
• 프로그램 상위 모듈에서 하위 모듈 방향으로 통합하면서 검사
• 주요 제어 모듈을 드라이버로 사용하고, 주요 제어 모듈의 종속 모듈들은 스터브로 대체한다.
• 스터브 : 일시적으로 필요한 조건만을 가지고 임시로 제공되는 시험용 모듈
• 스터브 사용 이유 : 상위 모듈은 하위 모듈이 모두 결합되어야 정상적으로 검사될 수 있으므로 스터브를 사용해서 검사한다.

상향식 통합 검사

• Bottom Up Integration Test

• 프로그램 하위 모듈에서 상위 모듈 방향으로 통합하면서 검사

• 순서

  1. 하위 모듈을 클러스터로 결합
  2. 검사 사례 입출력을 조정하기 위해 드라이버를 작성
  3. 클러스터 검사
  4. 드라이버를 제거하고 클러스터는 프로그램 구조의 상위로 이동하여 결합

혼합식 통합 검사

• 하위 수준에서는 상향식 통합, 상위 수준에서는 하향식 통합을 사용해 쵲거의 검사를 지원하는 방식
• 샌드위치식 통합 검사 방법

검증 검사

• Validation Test = 확인 검사 = 인수 검사
• 소프트웨어가 사용자의 요구사항을 충족시키는가를 중점으로 검사
• 블랙 박스 테스트를 이용하여 진행
• 형상 검사, 알파 검사, 베타 검사 등이 있다.

형상 검사

• 구성 검토 = 감사
• 소프트웨어 구성요소, 목록, 유지보수를 지원하기 위해 필요한 모든 사항들이 제대로 표현되었는지를 검사

알파 검사

• 개발자의 장소에서 사용자가 개발자 앞에서 행하는 검사 기법
• 통제된 환경에서 행해지며 오류를 사용자와 개발자가 함께 확인하면서 기록한다.

베타 검사

• 선정된 최종 사용자가 여러 명의 사용자 앞에서 행하는 검사 기법
• 실업무를 가지고 사용자가 직접 시험하는 것
• 개발자에 의해 제어되지 않은 상태에서 검사가 행해지며, 오류는 기록 후 개발자에게 주기적으로 보고한다.

시스템 검사

• 개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 검사
• 복구 검사, 보안 검사, 강도 검사, 성능 검사
• 복구 검사 : 실패 후 올바르게 복구되는가
• 보안 검사 : 침투로부터 시스템이 보호되는가
• 강도 검사 : 비정상적인 양, 빈도로 호출시 소프트웨어가 실행되는가
• 성능 검사 : 소프트웨어 실시간 성능을 검사하기 위한 것으로 검사 단계 전 과정에 걸쳐 수행

디버깅

• 검사사례에 의해 오류를 찾은 후 그 오류를 수정하는 과정
• 검사기법은 아니다.
• 맹목적 강요 : 가장 비효율적 방법
• 역추적 : Backtracking 오류가 발견된 위치에서 원인이 발견될 때까지의 코딩 부분을 거슬러 수정하는 일반적인 방법
• 원인 제거 : Cause Elimination 오류 가능성이 있는 원인을 제거해 버그를 분리

단위 검사 : 코드
통합 검사 : 설계
검증 검사 : 요구사항

유지보수

• 소프트웨어 개발 단계 중 가장 많은 노력과 비용이 투입되는 단계
• 시험 용이성, 이해성, 수정 용이성, 이식성이 고려되어야 한다.
• 수리 보수, 적응 보수, 완전화 보수, 예방 보수 활동으로 구분된다.

수정 보수

• Corrective
• 시스템을 운영하면서 검사 단계에서 발견핟지 못한 잠재적인 오류를 찾아 수정하는 활동
• 오류의 수정과 진단을 포함한다.

적응 보수

• Adaptive = 환경 적응 = 조정 보수
• 소프트웨어 수명 기간 중 발생하는 환경의 변화(하드웨어, OS)를 기존 소프트웨어에 반영하기 위해 수행하는 활동
• 프로그래밍 환경의 변화 또는 주변장치, 시스템 요소의 업그레이드시 대처할 수 있는 유지보수 활동

완전화 보수

• Perfective = 기능 개선 = 기능 보수
• 소프트웨어 본래 기능에 새로운 기능을 추가하거나 성능을 개선하기 위해 소프트웨어를 확장시키는 활동
• 유지보수 활동 중 가장 큰 업무 및 비용을 차지한다.

예방 보수

• Preventive = 소프트웨어 재공학
• 소프트웨어의 오류 발생에 대비하여 미리 예방 수단을 강구하는 활동

유지보수 과정

1. 유지보수 요구
2. 현 시스템에 대한 이해
3. 수정 및 시험

유지보수 비용

• 소프트웨어 개발에 필요한 비중 중 약 70%
• Belady, Lehman에 의해 제안된 공식으로 구한다.

유지보수 부작용

• 코딩 부작용 : 코딩 내용 변경으로 발생
• 자료 부작용 : 자료나 자료 구조의 변경으로 발생
• 문서화 부작용 : 자료 코드에 대한 변경이 설계문서나 사용자 매뉴얼에 반영되지 않을 때 발생

외계인 코드

• Alien Code
• 아주 오래 전에 개발되어 유지보수 작업이 매우 어려운 프로그램
• 일반적으로 15년이 더 된 프로그램
• 문서화로 방지할 수 있다.

객체지향 소프트웨어 공학

• 현실 세계의 개체를 기계의 부품처럼 하나의 객체로 만들어 부품을 조립하여 제품을 만들 듯이 소프트웨어를 개발할 때에도 객체들을 조립해서 작성할 수 있도록 하는 기법
• 구조적 기법의 문제점 해결
• 소프트웨어 재사용 및 확장을 용이하게 해서 빠르게 개발이 가능하고 유지보수가 쉽다.
• 복잡한 구조를 단계적, 계층적으로 표현한다.
• 멀티미디어 데이터 및 병령 처리를 지원한다.
• 현실 세계를 모형화하여 사용자와 개발자가 쉽게 이해할 수 있다.

객체

• Object
• 데이터와 데이터를 처리하는 함수를 묶어 놓은 하나의 소프트웨어 모듈
• 데이터
  • 객체가 가지고 있는 정보로 속성이나 상태, 분류를 나타낸다.
  • 속성 = Attribute = 상태 = 변수 = 상수 = 자료 구조
• 함수
  • 객체가 수행하는 기능으로 객체가 갖는 데이터를 처리하는 알고리즘
  • 객체의 상태를 참조하거나 변경하는 수단이 되는 것
  • 메소드 = 서비스 = 동작 = 연산
  • 기존 구조적 기법에서의 함수, 프로시저에 해당하는 연산 기능
• 객체는 상태와행위를 가지고 있다.
• 다른 객체와 구별될 수 있는 이름을 가지고 있다.
• 일정한 기억 장소를 가지고 있다.
• 객체의 메소드는 다른 객체로부터 메세지를 받을 때 수행하게 된다.

클래스

• 공통된 속성과 연산을 갖는 객체의 집합
• 객체의 일반적인 타입을 의미
• 각각의 객체들이 갖는 속성과 연산을 정의하고 있는 틀
• 인스턴스 : 클래스에 속한 각각의 객체
• 인스턴스화 : 클래스로부터 새로운 객체를 생성하는 것
• 최상위 클래스는 상위 클래스를 갖지 않는 유일한 클래스
• 슈퍼클래스는 특정 클래스의 상위 클래스
• 서브클래스는 특정 클래스의 하위 클래스

메세지

• 객체들 간에 상호작용을 하는 데 사용되는 수단
• 객체에게 어떤 행위를 하도록 지시하는 명령 또는 요구사항
• 메세지를 받은 수신 객체는 요구된 메소드를 수행한다.

객체지향 기법의 기본 원칙

캡슐화

• Encapsulation
• 데이터와 데이터를 처리하는 함수를 하나로 묶는 것
• 캡슐화된 객체의 세부내용이 외부에 은폐된다.
• 캡슐화된 객체는 재사용이 용이하다.
• 객체 간의 메세지를 주고받을 때 각 객체의 세부 내용은 알 필요가 없으므로 인터페이스가 단순해지고 객체 간의 결합도가 낮아진다.

정보 은닉

• Information Hiding
• 캡슐화에서 가장 중요한 개념
• 다른 객체에게 자신의 정보를 숨기고 자신의 연산만을 통하여 접근을 허용하는 것
• 각 객체의 수정이 다른 객체에 주는 영향을 최소화하는 기술
• 유지보수와 소프트웨어 확장시 오류를 최소화

추상화

• Abstraction
• 불필요한 부분을 생략하고 객체의 속성 중 가장 중요한 것에만 중점을 두어 모델화하는 것

상속성

• Inheritance
• 이미 정의된 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것
• 다중 상속성 : Multiple Inheritance 한 개의 클래스가 두 개 이상의 상위 클래스로부터 속성과 연산을 상속받는 것

다형성

• Polymorphism
• 객체들은 동일한 메소드명을 사용하며 같은 의미의 응답을 한다.
• 응용 프로그램 상에서 하나의 함수나 연산자가 두 개 이상의 서로 다른 클래스의 인스턴스들을 같은 클래스에 속한 인스턴스처럼 수행할 수 있도록하는 것

객체지향 기법의 생명주기

각 과정이 명확하게 순찾거으로 이루어지지는 않는다.

1. 계획 및 분석
2. 설계
3. 구현
4. 테스트 및 검증

객체지향 분석

• OOA = Object Oriented Analysis
• 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스, 연관된 속성과 연산, 관계 등을 정의하여 모델링 하는 작업
• 소프트웨어를 개발하기 위한 비즈니스를 객체와 속성, 클래스와 멤버, 전체와 부분 등으로 나눠서 분석한다.
• 분석가에게 주요한 모델링 구성요소인 클래스, 속성, 연선달을 표현해서 문제를 모형화할 수 있게 해준다.
• 객체는 클래스로부터 인스턴스화되고, 클래스를 식별하는 것이 객체지향 분석의 주요한 목적이다.

객체지향 분석 방법론

Rumbaugh 방법

• 럼바우 방법
• 가장 일반적으로 사용되는 방법
• 분석 활동을 객체 모델, 동적 모델, 기능 모델로 나누어 수행

Booch 방법

• 부치 방법
• 미시적Micro 개발 프로세스와 거시적Macro 개발 프로세스 모두를 사용하는 분석 방법
• 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의한다.

jacobson 방법

• Use Case를 강조하여 사용하는 분석 방법이다.

Coad와 Yourdon 방법

• E-R 다이어그램을 사용하여 객체의 행위를 모델링한다.

Wirfs-Brock 방법

• 분석과 설계 간의 구분이 없고 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 기법

Rumbaugh 분석 기법

• 모든 소프트웨어 구성요소를 그래픽 표기법을 이용하여 모델링하는 기법
• 객체 모델링 기법 = OMT = Object Modeling Technique
• 객체 모델링, 동적 모델링, 기능 모델링을 통해 이뤄진다.

객체 모델링

• Object Modeling = 정보 모델링
• 관계를 규정하여 객체 다이어그램으로 표시하는 것
• 분석 활동의 모델 중 가장 중요하며 선행되어야 할 모델링
• 순서
  1. 객체와 클래스를 식별
  2. 클래스에 대한 자료 사전 작성
  3. 클래스 간의 관계를 정의
  4. 객체 속성 및 연결 관계 정의
  5. 클래스를 계층화하고 모듈로 정의
  6. 생성된 모형을 반복적으로 검증

동적 모델링

• Dynamic Modeling
• 상태 다이어그램(상태도)을 이용하여 객체들 간의 제어 흐름, 상호 작용, 동작 순서 등의 동적인 행위를 표현하는 모델링
• 객체나 클래스의 상태, 사건을 중심으로 다룬다.
• 사건 : 하나의 객체로부터 다른 객체에 자극을 주어 객체의 상태를 변화시키는 것
• 상태 : 특정 시점의 객체에 대한 속성값
• 순서
  1. 시나리오 작성
  2. 사건 추적도 작성
  3. 사건 흐름도 작성
  4. 상태도 작성

기능 모델링

• Functional Modeling
• 자료 흐름도를 이용해 다수의 프로세스 간의 자료 흐름을 중심으로 처리과정을 표현한 모델
• 순서
  1. 입출력 자료를 정의
  2. 자료 흐름도를 상세화
  3. 기능 명세서 작성
  4. 제약 조건 파악
  5. 최적화 기준 명세

객체 모델링 : 객체
동적 모델링 : 객체의 흐름, 상태, 행위
기능 모델링 : 자료 흐름, 처리 과정

객체지향 설계

• Object Oriented Design
• 객체지향 분석을 사용해서 생성한 여러 가지 분석 모델을 설계 모델로 변환하는 작업
• 시스템 설계와 객체 설계를 수행한다.
• 사용자 중심, 대화식 프로그램 개발에 적합하다.
• 시스템을 구성하는 객체와 속성, 연산을 인식하는 것이 중요한 문제
• 추상화, 정보 은닉, 기능 독립성, 모듈화, 상속성을 바탕으로 하며 모듈화가 가장 중요하다.
• 문제 정의 => 요구 명세화 => 객체 연산자 정의 => 객체 인터페이스 결정 => 객체 구현

럼바우의 객체지향 설계

• 가장 많이 사용된다.
• 시스템 설계 : 전체적인 시스템 구조를 설계하는 것으로 분석 단계의 분석 모델을 서브시스템으로 분할하고, 시스템의 계층을 정의하며 분할 과정 중에서 성능의 최적 방안, 문제 해결 전략, 자원 분해 등을 확정하는 것이다.
• 객체 설계 : 분석 단계에서 만들어진 클래스, 속성, 관계, 메세지를 이용한 통신들을 설계 모델로 제작하고 상세화하여 구체적인 자료 구조와 알고리즘을 정의한다.

부치의 객체지향 설계

• 자료 흐름도를 사용해서 객체를 분해하고 객체 간의 인터페이스를 찾아 Ada 프로그램으로 변환시키는 기법

윌리엄 로렌슨의 객체 지향 설계

• 추상화, 상속성, 메세지, 그리고 다른 OOD 개념들을 직접 지원해주는 기능으 갖추고 있는 Smalltalk과 같은 프로그래밍 언어로 소프트웨어를 개발하기 위한 기법

객체지향 구현

• 구현은 설계 단계에서 생성된 설계 모델과 명세서를 근거로 하여 코딩하는 단계이다.
• 객체지향 프로그래밍을 이용하면 용이하게 구현할 수 있다.
• 객체는 순차적으로 또는 동시적으로 구현될 수 있다.

객체지향 프로그래밍

• Object Oriented Programming
• 객체 기반 언어 : 객체의 개념만을 지원하는 언어
• 클래스 기반 언어 : 객체와 클래스의 개념을 지원하는 언어
• 객체 지향성 언어 : 객체, 클래스, 상속의 개념을 모두 지원하는 언어 (Simula, Smalltalk, C++, Objective C)

객체지향 테스트

• 클래스 테스트 : 캡슐화 된 클래스나 객체를 검사하는 것
• 통합 테스트 : 객체 몇개를 결합하여 하나의 시스템으로 완성시키는 과정에서의 검사
  • 스레드 기반 테스트
  • 사용 기반 테스트
• 확인 테스트 : 사용자 요구사항에 대한 만족 여부를 검사
• 시스템 테스트 : 모든 요소들이 적합하게 통합되고 올바른 기능을 수행하는지 검사

UML

• Unified Modeling Language
• Rumbaugh, Booch, Jacobson 등의 객체지향 방법론의 장점을 통합한 객체지향 모델의 표준 표현 방법
• 객체지향 분석과 설계를 위한 모델링 언어로 객체 기술에 관한 국제 표준화 기구인 Object Management Group에서 UML을 표준으로 지정했다.
• 어플리케이션을 개발할 때 이해를 도와주는 사용 사례 다이어그램, 순서 다이어그램, 상태 다이어그램, 활동 다이어그램 등 여러 형태의 다이어 그램을 제공
• 사용 사례 다이어그램
  • Use Case
  • 사용자와 사용사례로 구성
  • 사용 사례 간에는 여러 형태의 관계로 이루어진다.
  • 기능 모델링 작업에 사용된다.
• 클래스 다이어그램 : 객체 모델링 작업에 사용
• 순서 다이어그램 : 동적 모델링 작업에 사용
• 상태 다이어그램 : 동적 모델링 작업에 사용
• 활동 다이어그램 : 동적 모델링 작업에 사용

소프트웨어 재사용

• 이미 개발되어 인정받은 소프트웨어의 전체 혹은 일부분을 다른 소프트웨어 개발이나 유지에 사용하는 것
• 클래스, 객체 등의 소프트웨어 요소는 소프트웨어 재사용성을 크게 향상시켰다.
• 소프트웨어 재사용에 가장 많이 이용되는 것은 소스코드이다.
• 모듈의 크기가 작고 일반적인 설계일수록 재사용률이 높다.

재사용의 이점

• 개발 시간과 비용의 단축
• 소프트웨어 품질 향상
• 개발 생산성 향상
• 프로젝트 실패 위험 감소
• 시스템 구축 방법에 대한 지식 공유
• 시스템 명세, 설계, 코드 등 문서를 공유

재사용의 문제점

• 새로운 개발방법론 도입이 어려움
• 프로그램 표준화가 부족
• 프로그램 언어가 종속적
• 소프트웨어 요소 내부 뿐아니라 인터페이스 요구사항의 이해가 필요하다.

재사용 방법

합성 중심 방법

• Composition Based = 블록 구성 방법
• 모듈을 만들어 조립하며 소프트웨어를 완성시키는 방법

생성 중심

• Generation Based = 패턴 구성 방법
• 추상화 형태로 쓰여진 명세를 구체화하여 소프트웨어를 완성시키는 방법

소프트웨어 재공학

• Software Reengineering
• 새로운 요구에 맞도록 기존 시스템을 이용하여 보다 나은 시스템을 구축
• 새로운 기능을 추가하여 소프트웨어 성능을 향상
• 유지보수 생산성 향상을 통해 소프트웨어 위기를 해결
• 기존 소프트웨어의 기능을 개조하거나 개선하므로 예방 유지보수 측면
• 자동화된 도구를 사용하여 소프트웨어를 분석하고 수정하는 과정을 포함
• 소프트웨어 수명이 연장되고 기술이 향상
• 오류가 줄어들고 비용이 절감
• 예방 유지보수

재공학의 목표

• 복잡한 시스템을 다루는 방법 구현 : 자동화 도구 사용
• 다른 뷰의 생성 : 기존 시스템 개발 관점 외에 다른 방향의 관점을 생성
• 잃어 버린 정보의 복구 및 제거
• 부작용의 발견
• 고수준의 추상 : 추상화된 어려운 내용을 여러 형태로 추출해 이해
• 재사용 용이

주요활동

분석

• Analysis
• 기존 소프트웨어의 명세서를 확인하여 소프트웨어의 동작을 이해하고 재공학 대상을 선정하는 것

개조

• Restructuring = 재구조 - 재구성
• 상대적으로 같은 추상적 수준에서 하나의 표현을 다른 표현 형태로 바꾸는 것
• 기존 소프트웨어의 구조를 향상시키기 위해 코드를 재구성 하는 것
• 소프트웨어의 기능과 외적인 동작은 바뀌지 않는다.
• IF ELSE를 SWITCH CASE로 변경하듯이

역공학

• Reverse Engineering
• 기존 소프트웨어를 분석하여 소프트웨어 개발 과정과 데이터 처리 과정을 설명하는 분석 및 설계 정보를 재발견하거나 다시 만들어 내는 작업
• 기존 코드를 복구하는 방법
• 대상 소프트웨어가 가능하다.
• 코드 역공학 : 코드 => 흐름도 => 자료 구조도 => 자료 흐름도
• 데이터 역공학 : 코드 => 자료 사전 => 개체 관계도
• 재문서화 : Redocumentation 역공학의 가장 간단하고 오래된 형태

이식

• Migration
• 기존 소프트웨어를 다른 운영체제나 하드웨어 환경에서 사용할 수 있도록 변환하는 작업

Client/Server 시스템

• 분산 시스템의 가장 대표적인 모델
• 정보를 제공하는 서버와 정보를 요구하는 클라이언트로 구성
• 클라이언트와 서버가 하나의 작업을 분산 협동 처리한다.

요소

• 애플리케이션 요소 : 응용 프로그램에 의해 정의된 요구사항을 구현
• 데이터베이스 요소
• 프리젠테이션/상호작용 요소 : GUI와 관련된 모든 기능

미들웨어

• 클라이언트와 서버 사이에 존재해서 데이터 전송 과정을 효율적으로 수행하도록 도와주는 소프트웨어
• 통신 미들웨어 : NOS(Network Operating System)
• 데이터베이스 미들웨어 : ODBC
• 분산 객체 미들웨어 : CORBA, DCOM

객체 요청 브로커

• ORB = Object Request Broker
• 분산 객체 미들웨어의 일종
• 클라이언트의 객체가 서버 객체의 캡슐화된 메소드에게 메세지를 보낼 수 있게 하는 것

CORBA

• Common Object Request Broker Architecture
• 가장 많이 사용되는 객체 요청 브로커의 표준
• OMG(Obejct Management Group)라는 개발자 연합에서 인가
• IDL : Interface Description Language CORBA가 클라이언트/서버 시스템에서 구현될 때 필요한 인터페이스 언어

CASE

• Computer Aided Software Engineering
• 소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화하는 것
• 소프트웨어 개발 도구와 방법론이 결합된 것
• 정형화된 구조 및 방법을 소프트웨어 개발에 적용하여 생산성 향상을 구현하는 공학 기법
• 자동화 도구를 지원하고 개발자는 소프트웨어 개발의 표준화를 지향하며 자동화의 이점을 얻을 수 있다.
• 소프트웨어 생명주기 전 단계의 연결, 다양한 소프트웨어 개발 모형 지원, 그래픽 지원

사용 이점

• 소프트웨어 개발 기간 단축하고 개발 비용 절감
• 자동화된 기법을 통해 소프트웨어 품질 향상
• 유지보수 간편하게 수행
• 생산성 향상
• 운용 활동 효과적으로 관리 및 통제
• 품질과 일관성을 효과적으로 제어
• 소프트웨어 개발 모든 단계에 걸친 표준 확립
• 모듈의 재사용성 향상
• 개발 기법의 실용화, 문서화가 쉬움

분류

상위 CASE

• Upper CASE
• 소프트웨어 생명 주기 전반부에서 사용
• 문제를 기술하고 계획하며 요구 분석과 설계 단계를 지원
• 여러가지 명세와 문서를 작성하는데 사용
• SREM, PSL/PSA, SERA, FOUNDATION

하위 CASE

• Lower CASE
• 소프트웨어 생명 주기 하반부에서 사용
• 코드의 작성과 테스트, 문서화하는 과정을 지원
• 구문 중십 편집기, 코드 생성기

통합 CASE

• Integrate CASE
• 소프트웨어 생명 주기 포함되는 전체 과정을 지원
• 공통의 정보 저장 장소와 통일된 사용자 인터페이스를 사용하여 도구를 통합
• IEF, POWERTOOLS, TAGS/IORL, TEAMWORK

정보 저장소

• 소프트웨어를 개발하는 과정 동안 모아진 정보를 보관하여 관리하는 곳
• CASE 정보 저장소 = CASE 데이터베이스 = 요구사항 사전 = 저장소
• 초기에는 사람이 정보 저장소, 오늘은 DB가 정보 저장소
• 도구들의 통합, 소프트웨어 시스템의 표준화, 소프트웨어 시스템의 정보 공유, 소프트웨어 재사용성의 기본
• 시스템의 정보 공유 활성화
• 유지보수성 향상
• CASE 도구간 정보를 쉽게 교환, 사용자가 새로운 도구를 쉽게 추가
• 중복된 공통정보를 통합해 불필요한 정보 제거
• 생명 주기 정보를 재사용
• 소프트웨어 시스템의 이삭과 변환을 용이하게 함

IP에 대해 설명하시오.

 

브리지, 허브, 스위치 및 라우터에 대해 설명하시오.

 

패킷에 대해 설명하시오.

 

다음 통신 오류 검출 방식에 대해 설명하시오.

 

1) 패리티 비트 검사

 

2) 블록 합 검사

 

3) 순환 중복 검사

 

유니캐스트, 브로드캐스트, 멀티캐스트, 애니캐스트에 대해 설명하시오.

 

동기식통신과 비동기식통신의 차이점에 대해서 설명하시오.

 

HTTP와 프로토콜에 대해 설명하시오.

 

HTTP와 HTTPS의 차이에 대해 설명하시오.

 

HTTP Request 방식 중 GET과 POST의 차이에 대해 설명하시오.

 

GET방식의 URL을 통해서 데이터를 전달 시 보안성 취약 해결방법은 무엇인가?

 

OSI 7 Layer와 각 계층에 대해 설명하시오.

 

TCP/IP 프로토콜 스택 4계층으로 구분짓고 설명하시오.

 

TCP에 대해 설명하시오.

 

UDP에 대해 설명하시오.

 

3-Way-Handshaking에 대해 설명하시오.

 

4-Way-Handshaking에 대해 설명하시오.

 

도메인(Domain)에 대해 설명하시오.

 

IP Address와 MAC Address에 대해 설명하시오.

 

ARP(Address Resolution Protocol)와 RARP에 대해 설명하시오.

 

Restful API에 대해 설명하시오.

 

Restful API에서의 URL과 일반적인 HTTP에서의 URL의 차이에 대해 설명하시오.

 

HTTP 1.0과 HTTP 1.1의 차이점을 설명하시오.

 

SSL에 대해 설명하시오.

 

대칭키와 공개키에 대해 설명하시오.

배열(array)에 대해 설명하시오.

 

가장 기본적인 자료구조인 Array 자료구조는, 논리적 저장 순서와 물리적 저장 순서가 일치한다. 따라서 인덱스(index)로 해당 원소(element)에 접근할 수 있다. 그렇기 때문에 찾고자 하는 원소의 인덱스 값을 알고 있으면 Big-O(1)에 해당 원소로 접근할 수 있다. 즉 random access 가 가능하다는 장점이 있는 것이다.

하지만 삭제 또는 삽입의 과정에서는 해당 원소에 접근하여 작업을 완료한 뒤(O(1)), 또 한 가지의 작업을 추가적으로 해줘야 하기 때문에, 시간이 더 걸린다. 만약 배열의 원소 중 어느 원소를 삭제했다고 했을 때, 배열의 연속적인 특징이 깨지게 된다. 즉 빈 공간이 생기는 것이다. 따라서 삭제한 원소보다 큰 인덱스를 갖는 원소들을 shift해줘야 하는 비용(cost)이 발생하고 이 경우의 시간 복잡도는 O(n)가 된다. 그렇기 때문에 Array 자료구조에서 삭제 기능에 대한 time complexity 의 worst case 는 O(n)이 된다.

삽입의 경우도 마찬가지이다. 만약 첫번째 자리에 새로운 원소를 추가하고자 한다면 모든 원소들의 인덱스를 1 씩 shift 해줘야 하므로 이 경우도 O(n)의 시간을 요구하게 된다.

 

연결 리스트(linked list)에 대해 설명하시오.

 

이 부분에 대한 문제점을 해결하기 위한 자료구조가 linked list 이다. 각각의 원소들은 자기 자신 다음에 어떤 원소인지만을 기억하고 있다. 따라서 이 부분만 다른 값으로 바꿔주면 삭제와 삽입을 O(1) 만에 해결할 수 있는 것이다.

하지만 LinkedList 역시 한 가지 문제가 있다. 원하는 위치에 삽입을 하고자 하면 원하는 위치를 Search 과정에 있어서 첫번째 원소부터 다 확인해봐야 한다는 것이다. Array 와는 달리 논리적 저장 순서와 물리적 저장 순서가 일치하지 않기 때문이다. 이것은 일단 삽입하고 정렬하는 것과 마찬가지이다. 이 과정 때문에, 어떠한 원소를 삭제 또는 추가하고자 했을 때, 그 원소를 찾기 위해서 O(n)의 시간이 추가적으로 발생하게 된다.

결국 linked list 자료구조는 search 에도 O(n)의 time complexity 를 갖고, 삽입, 삭제에 대해서도 O(n)의 time complexity 를 갖는다. 그렇다고 해서 아주 쓸모없는 자료구조는 아니기에, 우리가 학습하는 것이다. 이 Linked List 는 Tree 구조의 근간이 되는 자료구조이며, Tree 에서 사용되었을 때 그 유용성이 드러난다.

 

포인터(pointer)에 대해 설명하시오.

 

주소값의 이해

데이터의 주소값이란 해당 데이터가 저장된 메모리의 시작 주소를 의미합니다.

C언어에서는 이러한 주소값을 1바이트 크기의 메모리 공간으로 나누어 표현합니다.

예를 들어, int형 데이터는 4바이트의 크기를 가지지만, int형 데이터의 주소값은 시작 주소 1바이트만을 가리킵니다.

 

포인터란?

C언어에서 포인터(pointer)란 메모리의 주소값을 저장하는 변수이며, 포인터 변수라고도 부릅니다.

char형 변수가 문자를 저장하고, int형 변수가 정수를 저장하는 것처럼 포인터는 주소값을 저장합니다

 

Call by value와 Call by reference에 대해 설명하시오.

 

call-by-value (값에 의한 호출)

• 함수가 호출될 때, 메모리 공간 안에서는 함수를 위한 별도의 임시 공간이 생성된다. (c++의 경우 stack frame) 함수가 종료되면 해당 공간은 사라진다.

• 스택 프레임(Stack Frame) : 함수 호출시 할당되는 메모리 블록(지역변수의 선언으로 인해 할당되는 메모리 블록)

• call-by-value 값에 의한 호출방식은 함수 호출시 전달되는 변수의 값을 복사하여 함수의 인자로 전달한다.

• 복사된 인자는 함수 안에서 지역적으로 사용되는 local value의 특성을 가진다.

• 따라서 함수 안에서 인자의 값이 변경되어도, 외부의 변수의 값은 변경되지 않는다.

• Java의 경우 함수에 전달되는 인자의 데이터 타입에 따라서 (원시자료형 / 참조자료형) 함수 호출 방식이 달라진다.

  • 원시 자료형 (primitive type) : call-by-value 로 동작 (int, short, long, float, double, char, boolean )

  • 참조 자료형 (reference type): call-by-reference 로 동작 (Array, Class Instance)

call-by-reference (참조에 의한 호출)

• 함수가 호출될 때, 메모리 공간 안에서는 함수를 위한 별도의 임시 공간이 생성된다. (예: stack frame) 함수가 종료되면 해당 공간은 사라진다.

• call-by-reference 참조에 의한 호출방식은 함수 호출시 인자로 전달되는 변수의 레퍼런스를 전달한다. (해당 변수를 가르킨다.)

• `따라서 함수 안에서 인자의 값이 변경되면, 아규먼트로 전달된 객체의 값도 함께 변경된다.

Iterative와 Recursion에 대해 설명하시오.

 

재귀 메소드

메소드는 특정한 문제를 해결하기 위해 다른 메소드를 호출할 수 있으며 자신을 직접 호출하는 것을 재귀라고 한다.

재귀적인 방법을 사용함에 있어 주의할 점은 종료하는 지점을 정의하는 것이다.

그렇지 않으면 재귀는 무한 반복되기 때문이다.

 

재귀와 반복

재귀와 반복은 같은 문제를 해결하는 두 가지 방법이지만, 재귀 방법이 적은 코드를 사용해 효율적으로 처리할 수 있다.

 

반복

메소드의 호출은 매개변수 리스트를 보관할 메모리 영역과 (메소드가 static이 아니라면) 메소드를 실행할 수 있는 복사 공간이 필요하다.

반복적인 메소드 호출을 위한 메모리는 한번만 필요하기 때문에 반복 프로그래밍이 성능적인 면에서 유리하다.

 

재귀

세련된 방법. 코드를 이해하고 유지하는 것이 더 중요하다면 재귀 프로그래밍을 고려한다.

메소드가 자신을 호출할 때에 메모리를 위한 비용과 CPU 사용 시간이 더 많이 소요된다.

 

스택(stack)에 대해 설명하시오.

 

선형 자료구조의 일종으로 Last In First Out (LIFO). 즉, 나중에 들어간 원소가 먼저 나온다. 이것은 Stack 의 가장 큰 특징이다. 차곡차곡 쌓이는 구조로 먼저 Stack 에 들어가게 된 원소는 맨 바닥에 깔리게 된다. 그렇기 때문에 늦게 들어간 녀석들은 그 위에 쌓이게 되고 호출 시 가장 위에 있는 녀석이 호출되는 구조이다.

 

큐(queue)에 대해 설명하시오.

 

선형 자료구조의 일종으로 First In First Out (FIFO). 즉, 먼저 들어간 놈이 먼저 나온다. Stack 과는 반대로 먼저 들어간 놈이 맨 앞에서 대기하고 있다가 먼저 나오게 되는 구조이다. 

 

1차원 배열의 선형 큐에서 잘못된 포화 상태 문제를 해결하는 방법을 설명하시오.

 

1차원 배열의 선형 큐는 큐의 처음을 가리키는 front가 자료가 새로 넣어짐에 따라 점차 뒤로 이동하게 되어 있다. 그러한 상황에서 front의 포인터가 배열의 끝가지 가게되면 사용하지 않는 공간이 있음에도 포화 상태를 일으키는 잘못된 포화 상태 문제가 일어난다.

큐의 끝인 rear가 배열의 끝에 도달하면 다시 배열의 처음으로 포인터를 이동시키는 환형큐를 사용해서 앞에 비워지는 front자리를 다시 채워준다.

 

트리(Tree)에 대해 설명하시오.

 

트리는 자료들이 리스트, 스택, 큐와 같은 1:1 관계의 선형구조가 아니라 1:n 관계의 비선형 자료구조이다. 또한 계층 관계로 만들어진 계층형 자료구조이다.

 

사용 예 : 눈에 쉽게 보이는 사용으로는 현재 사용하고 있는 PC나 모바일 핸드폰에서의 파일들을 생각해볼 수가 있다.
각 폴더에 대해 자식 폴더 또는 파일들이 있고, 이 때 자식 폴더는 부모가 되어 자식 폴더 또는 파일들을 가지게 된다.

 

이진 트리(Binary Tree)에 대해 설명하시오.

 

이진 트리는 각각의 노드가 최대 두 개의 자식 노드를 가지는 트리 자료 구조로, 자식 노드를 각각 왼쪽 자식 노드와 오른쪽 자식 노드라고 한다. 루트 노드를 중심으로 두 개의 서브 트리(큰 트리에 속하는 작은 트리)로 나뉘어 진다. 또한 나뉘어진 두 서브 트리도 모두 이진 트리어야 한다. 재귀적인 정의라 맞는듯 하면서도 이해가 쉽지 않을 듯하다. 한 가지 덧붙이자면 공집합도 이진 트리로 포함시켜야 한다. 그래야 재귀적으로 조건을 확인해갔을 때, leaf node 에 다 달았을 때, 정의가 만족되기 때문이다. 자연스럽게 노드가 하나 뿐인 것도 이진 트리 정의에 만족하게 된다.

 

다음 이진 트리의 순회 방법에 대해 설명하시오.

 

1) 전위 순회(Preorder Traversal)

 

전위순회는 현재 노드를 가장 먼저 방문합니다. 그러니 왼쪽 자식과 오른쪽 자식을 현재 자식보다 나중에 방문합니다.

전위 순회 방법을 순환식으로 기술하면 다음과 같다.

 

1. 루트 노드(root node)를 방문한다.

2. 왼편 서브트리(left subtree)를 전위 순회한다.

3. 오른편 서브트리(right subtree)를 전위 순회한다.

 

2) 중위 순회(Inorder Traversal)

 

우선 왼쪽 자식을 방문하고, 현재 노드를 방문합니다. 그리고 나서 오른쪽 자식 노드를 방문하게 됩니다. 현재 노드를 중간에 방문한다고 해서 중위순회가 됩니다.

중위 순회 방법을 순환식으로 기술하면 다음과 같다.

 

1. 왼편 서브트리(left subtree)를 중위 순회한다.

2. 루트 노드(root node)를 방문한다.

3. 오른편 서브트리(right subtree)를 중위 순회한다.

 

3) 후위 순회(Postorder Traversal)

 

현재 노드를 가장 나중에 방문하는 방식의 순회입니다. 그러니 왼쪽 자식, 오른쪽 자식 노드를 우선적으로 방문합니다.

후위 순회 방법을 순환식으로 기술하면 다음과 같다.

 

1. 왼편 서브트리(left subtree)를 후위 순회한다.

2. 오른편 서브트리(right subtree)를 후위 순회한다.

3. 루트 노드(root node)를 방문한다.

 

이진 탐색 트리(Binary Search Tree)에 대해 설명하시오.

 

힙(heap)에 대해 설명하시오. 

 

힙은 최댓값, 최솟값을 찾아내는 연산을 쉽게하기 위해 고안된 자료형이다.

힙은 각 노드의 값이 그 자식 노드의 값보다 작지않거나(최대 힙), 그 자식의 키값보다 크지 않은(최소 힙) 완전 이진 트리이다.

힙의 데이터 삽입 시 시간복잡도는 O(logN)이고 삭제 시 시간복잡도도 O(logN)이다.

 

그래프(Graph)에 대해 설명하시오.

 

그래프는 연결되어 있는 원소 사이의 다:다 관계를 표현하는 자료구조이다.

원소를 노드라고 할 때, 노드(node)와 그 노드를 연결하는 간선(edge)을 하나로 모아 놓은 자료구조라고도 한다.

 

다음 그래프를 구현하는 방법에 대해 설명하시오.

 

1) 인접 행렬(Adjacent Matrix)

 

인접행렬은 인접리스트와 같이 그래프를 저장하고 탐색할 수 있도록 도와주는 하나의 자료구조이다. 보통 배열을 사용해서 그래프의 정보를 저장한다.

 2차원 배열의 특성상 공간복잡도가 O(n2)이므로 정점의 수가 많을 경우 인접행렬을 사용한다면 메모리의 낭비가 문제가 될 수 있다. 더욱이 대부분의 인접행렬의 탐색은 시간복잡도도 O(n2)이므로 사용에 주의를 기울일 필요가 있다.

 

2) 인접 리스트(Adjacent List)

 

인접행렬과 함께 인접리스트는 주로 그래프를 데이터로 저장하고 탐색하기 위해 사용한다.
간단한 구조의 그래프는 인접행렬로 구현이 가능하나 시간복잡도 O(n2)이 걸리기 때문에 그래프의 정점이 많은 경우 O(n)이 걸리는 인접리스트로 구현하는 것이 효율적이다. 그렇기 때문에 복잡하고 어려운 상황의 그래프에서는 인접리스트가 더 효율적으로 그래프를 저장 & 탐색할 수 있도록 해준다.

 

인접행렬 vs 인접 리스트

두 가지 방식은 완전히 정반대의 특성을 가져서, 한 방식의 단점이 바로 다른 방식의 장점이기 때문에
구현하려는 알고리즘의 종류나 그래프의 종류에 따라 적절히 사용해야 합니다.

 

1. 정점 u - v간의 간선 여부 확인

인접 행렬 - 정점 u, v가 주어졌을 때, 단 한 번의 배열의 접근만으로 연결 여부 파악 가능

인접 리스트 - ad[u]의 처음부터 읽어나가면서 각 원소를 일일이 확인해야 함

 

2. 공간 복잡도 

인접 행렬 - V개의 Node를 표현하기 위해선 V*V 개수 만큼의 공간이 필요하므로 공간복잡도는 O(V^2)

인접 리스트 - V개의 리스트에 실제 간선만큼 원소가 들어 있으므로, 공간복잡도는 O(V+E)

만약 간선의 개수가 V^2에 수렴한다면 비슷할 수 있으나, 현실 세계에서는 간선의 수가 훨씬 적은 그래프가 많음

 

3.결론

간선의 수가 V^2에 비해 훨씬 적은 그래프를 희소 그래프 —> 인접 리스트

간선의 수가 V^2에 비례하는 그래프를 밀접 그래프 —> 인접 행렬  

 

깊이 우선 탐색(Depth First Search : DFS)에 대해 설명하시오.

 

그래프 상에 존재하는 임의의 한 정점으로부터 연결되어 있는 한 정점으로만 나아간다라는 방법을 우선으로 탐색한다. 일단 연결된 정점으로 탐색하는 것이다. 연결할 수 있는 정점이 있을 때까지 계속 연결하다가 더이상 연결되지 않은 정점이 없으면 바로 그 전 단계의 정점으로 돌아가서 연결할 수 있는 정점이 있는지 살펴봐야 할 것이다. 갔던 길을 되돌아 오는 상황이 존재하는 미로찾기처럼 구성하면 되는 것이다. 어떤 자료구조를 사용해야할까? 바로 Stack 이다. 

Time Complexity : O(V+E) : vertex 개수 + edge 개수

 

너비 우선 탐색(Breadth First Search : BFS)에 대해 설명하시오.

 

그래프 상에 존재하는 임의의 한 정점으로부터 연결되어 있는 모든 정점으로 나아간다. Tree 에서의 Level Order Traversal 형식으로 진행되는 것이다. BFS 에서는 자료구조로 Queue 를 사용한다. 연락을 취할 정점의 순서를 기록하기 위한 것이다. 우선, 탐색을 시작하는 정점을 Queue 에 넣는다.(enqueue) 그리고 dequeue 를 하면서 dequeue 하는 정점과 간선으로 연결되어 있는 정점들을 enqueue 한다. 즉 vertex 들을 방문한 순서대로 queue 에 저장하는 방법을 사용하는 것이다. 

Time Complexity : O(V+E) … vertex 개수 + edge 개수 ! BFS 로 구한 경로는 최단 경로이다.

 

MST(Minimal Spanning Tree)에 대해 설명하시오.

 

크루스칼 알고리즘(Kruskal Algorithm)에 대해 설명하시오.

 

프림 알고리즘(Prim Algorithm)에 대해 설명하시오.

 

다익스트라 알고리즘(Dijkstra Algorithm)에 대해 설명하시오.

 

플로이드 알고리즘(Floyd Algorithm)에 대해 설명하시오.

 

다음 정렬 기법에 대해 설명하시오.

 

1) 선택 정렬(Selection Sort)

 

2) 버블 정렬(Bubble Sort)

 

3) 퀵 정렬(Quick Sort)

 

4) 삽입 정렬(Insertion Sort)

 

5) 병합 정렬(Merge Sort)

 

6) 힙 정렬(Heap Sort)

 

해싱에 대해 설명하시오.

 

Collision에 대해 설명하시오.

 

Synonym에 대해 설명하시오.

 

이진검색에 대해 설명하시오. 

프로세스에 대해 설명하시오.

 

프로세스는 실행 중인 프로그램으로 디스크로부터 메모리에 적재되어 CPU 의 할당을 받을 수 있는 것을 말한다. 운영체제로부터 주소 공간, 파일, 메모리 등을 할당받으며 이것들을 총칭하여 프로세스라고 한다. 구체적으로 살펴보면 프로세스는 함수의 매개변수, 복귀 주소와 로컬 변수와 같은 임시 자료를 갖는 프로세스 스택과 전역 변수들을 수록하는 데이터 섹션을 포함한다. 또한 프로세스는 프로세스 실행 중에 동적으로 할당되는 메모리인 힙을 포함한다.

 

스레드에 대해 설명하시오.

 

스레드는 프로세스의 실행 단위라고 할 수 있다. 한 프로세스 내에서 동작되는 여러 실행 흐름으로 프로세스 내의 주소 공간이나 자원을 공유할 수 있다. 스레드는 스레드 ID, 프로그램 카운터, 레지스터 집합, 그리고 스택으로 구성된다. 같은 프로세스에 속한 다른 스레드와 코드, 데이터 섹션, 그리고 열린 파일이나 신호와 같은 운영체제 자원들을 공유한다. 하나의 프로세스를 다수의 실행 단위로 구분하여 자원을 공유하고 자원의 생성과 관리의 중복성을 최소화하여 수행 능력을 향상시키는 것을 멀티스레딩이라고 한다. 이 경우 각각의 스레드는 독립적인 작업을 수행해야 하기 때문에 각자의 스택과 PC 레지스터 값을 갖고 있다.

 

스택을 스레드마다 독립적으로 할당하는 이유는?

 

스택은 함수 호출 시 전달되는 인자, 되돌아갈 주소값 및 함수 내에서 선언하는 변수 등을 저장하기 위해 사용되는 메모리 공간이므로 스택 메모리 공간이 독립적이라는 것은 독립적인 함수 호출이 가능하다는 것이고 이는 독립적인 실행 흐름이 추가되는 것이다. 따라서 스레드의 정의에 따라 독립적인 실행 흐름을 추가하기 위한 최소 조건으로 독립된 스택을 할당한다.

 

PC Register를 스레드마다 독립적으로 할당하는 이유는?

 

PC 값은 스레드가 명령어의 어디까지 수행하였는지를 나타나게 된다. 스레드는 CPU 를 할당받았다가 스케줄러에 의해 다시 선점당한다. 그렇기 때문에 명령어가 연속적으로 수행되지 못하고 어느 부분까지 수행했는지 기억할 필요가 있다. 따라서 PC 레지스터를 독립적으로 할당한다.

 

프로세스 제어 블록에 대해 설명하시오,

 

PCB 는 특정 프로세스에 대한 중요한 정보를 저장 하고 있는 운영체제의 자료구조이다. 운영체제는 프로세스를 관리하기 위해 프로세스의 생성과 동시에 고유한 PCB 를 생성 한다. 프로세스는 CPU 를 할당받아 작업을 처리하다가도 프로세스 전환이 발생하면 진행하던 작업을 저장하고 CPU 를 반환해야 하는데, 이때 작업의 진행 상황을 모두 PCB 에 저장하게 된다. 그리고 다시 CPU 를 할당받게 되면 PCB 에 저장되어있던 내용을 불러와 이전에 종료됐던 시점부터 다시 작업을 수행한다.

 

PCB 에 저장되는 정보

 

프로세스 식별자(Process ID, PID) : 프로세스 식별번호

프로세스 상태 : new, ready, running, waiting, terminated 등의 상태를 저장

프로그램 카운터 : 프로세스가 다음에 실행할 명령어의 주소

CPU 레지스터

CPU 스케쥴링 정보 : 프로세스의 우선순위, 스케줄 큐에 대한 포인터 등

메모리 관리 정보 : 페이지 테이블 또는 세그먼트 테이블 등과 같은 정보를 포함

입출력 상태 정보 : 프로세스에 할당된 입출력 장치들과 열린 파일 목록

어카운팅 정보 : 사용된 CPU 시간, 시간제한, 계정번호 등

 

사용자 수준 스레드와 커널 수준 스레드의 차이를 설명하시오.

 

커널 레벨 스레드

- 커널 스레드는 가장 가벼운 커널 스케쥴링 단위다. 

- 하나의 프로세스는 적어도 하나의 커널 스레드를 가지게 된다. 

- 커널 영역에서 스레드 연산을 수행하게 된다.

- 커널이 스레드를 관리하기 때문에 커널에 종속적이다.

- 프로그래머 요청에 따라 스레드를 생성하고 스케줄링하는 주체가 커널이면 커널 레벨(Kernel Level) 스레드라고 한다.

 

커널 레벨 스레드 장점

- 프로세스의 스레드들을 몇몇 프로세서에 한꺼번에 디스패치 할 수 있기 때문에 멀티프로세서 환경에서 매우 빠르게 동작한다.

- 다른 스레드가 입출력 작업이 다 끝날 때까지 다른 스레드를 사용해 다른 작업을 진행할 수 있다. 

- 커널이 각 스레드를 개별적으로 관리할 수 있다. 

- 커널이 직접 스레드를 제공해 주기 때문에 안정성과 다양한 기능이 제공된다.

 

커널 레벨 스레드 단점

- 스케줄링과 동기화를 위해 커널을 호출하는데 무겁고 오래걸린다.(저장한 내용을 다시 불러오는 과정이 필요)

- 즉, 사용자 모드에서 커널 모드로의 전환이 빈번하게 이뤄져 성능 저하가 발생한다.

- 사용자가 프로그래밍할 때 구현하기 어렵고 자원을 더 많이 소비하는 경향이 있다.

 

사용자 레벨 스레드

- 사용자 영역에서 스레드 연산을 수행한다. 

- 사용자 영역에서 스레드 연산을 수행하기 때문에 운영체제에 투명하다. 

- 커널에 의존적이지 않은 형태로 스레드의 기능을 제공하는 라이브러리를 활용하는 방식이 사용자 레벨(User Level) 스레드다.

 

사용자 레벨 스레드 장점

- 운영체제에서 스레드를 지원할 필요가 없다. 

- 스케줄링 결정이나 동기화를 위해 커널을 호출하지 않기 때문에 인터럽트가 발생할 때 커널 레벨 스레드보다 오버헤드가 적다.

- 즉, 위의 말은 사용자 영역 스레드에서 행동을 하기에 OS Scheduler의 context switch가 없다(유저레벨 스레드 스케줄러를 이용).

- 커널은 사용자 레벨 스레드의 존재조차 모르기 때문에 모드 간의 전환이 없고 성능 이득이 발생한다

 

사용자 레벨 스레드 단점

- 시스템 전반에 걸친 스케줄링 우선순위를 지원하지 않는다. (무슨 스레드가 먼저 동작할 지 모른다.)

- 프로세스에 속한 스레드 중 I/O 작업등에 의해 하나라도 블록이 걸린다면 전체 스레드가 블록된다.

 

문맥교환(context switching)에 대해 설명하시오.

 

멀티프로세스 환경에서 CPU가 어떤 하나의 프로세스를 실행하고 있는 상태에서 인터럽트 요청에 의해 다음 우선 순위의 프로세스가 실행되어야 할 때 기존의 프로세스의 상태 또는 레지스터 값(Context)을 저장하고 CPU가 다음 프로세스를 수행하도록 새로운 프로세스의 상태 또는 레지스터 값(Context)를 교체하는 작업을 Context Switch(Context Switching)라고 한다.

질문에 대한 답변은 이정도로 하고 좀 더 명확하게 이해해본다.

* Context Switching을 문맥 교환으로 번역하지 말자.

Context는 무엇인가?

사용자와 다른 사용자, 사용자와 시스템 또는 디바이스간의 상호작용에 영향을 미치는 사람, 장소, 개체등의 현재 상황(상태)을 규정하는 정보들을 말한다.

android나 servlet등에서도 context가 있지만 OS에서 Context는 CPU가 해당 프로세스를 실행하기 위한 해당 프로세스의 정보들이다.

이 Context는 프로세스의 PCB(Process Control Block)에 저장된다.

그래서 Context Switching 때 PCB의 정보를 읽어(적재) CPU가 전에 프로세스가 일을 하던거에 이어서 수행이 가능한 것이다.

PCB의 저장정보

- 프로세스 상태 : 생성, 준비, 수행, 대기, 중지

- 프로그램 카운터 : 프로세스가 다음에 실행할 명령어 주소

- 레지스터 : 누산기, 스택, 색인 레지스터

- 프로세스 번호

* 참고로 Context Switching 때 해당 CPU는 아무런 일을 하지 못한다. 따라서 컨텍스트 스위칭이 잦아지면 오히려 오버헤드가 발생해 효율(성능)이 떨어진다.

Context가 뭔지 알았고 멀티프로세싱하기 위해 CPU를 나눠서 사용하기 위해 Context를 교체하는 것이 Context Switching임을 알았다. 그리고 PCB에 Context가 저장됨도 알았다.

남은 것은 인터럽트 요청이 뭐고 어떤 종류가 있는지 + 서브로 우선 순위에 대한 이야기다.

Context Switching - 인터럽트(Interrupt)

인터럽트는 CPU가 프로그램을 실행하고 있을 때 실행중인 프로그램 밖에서 예외 상황이 발생하여 처리가 필요한 경우 CPU에게 알려 예외 상황을 처리할 수 있도록 하는 것을 말한다.

어떤 인터럽트 요청이 와야 Context Switching이 일어날까?

1. I/O request (입출력 요청할 때)

2. time slice expired (CPU 사용시간이 만료 되었을 때)

3. fork a child (자식 프로세스를 만들 때)

4. wait for an interrupt (인터럽트 처리를 기다릴 때)

+ 더 있겠지만 자세한 것은 생략.

* 우선 순위는 해당 OS의 스케줄러가 우선 순위 알고리즘에 의해 정해지고 수행하게 되어있다.

라운드로빈 스케줄링(Round Robin Scheduling)은 시분할 시스템을 위해 설계된 선점형 스케줄링의 하나다.

쉽게 설명하면 순서대로 시간단위(Time Quantum)을 CPU에 할당하는 방식이다.

꽤 효율적인 스케줄링 알고리즘이지만 이 시간단위를 작게 설정하면 CPU가 조금 일하고 Context Switching을 반복하므로 아까 말했듯이 효율이 떨어진다.

* Context Switch를 하는 주체 = OS 스케줄러

 

멀티 스레딩의 장단점을 설명하시오.

 

장점

프로세스를 이용하여 동시에 처리하던 일을 스레드로 구현할 경우 메모리 공간과 시스템 자원 소모가 줄어들게 된다. 스레드 간의 통신이 필요한 경우에도 별도의 자원을 이용하는 것이 아니라 전역 변수의 공간 또는 동적으로 할당된 공간인 Heap 영역을 이용하여 데이터를 주고받을 수 있다. 그렇기 때문에 프로세스 간 통신 방법에 비해 스레드 간의 통신 방법이 훨씬 간단하다. 심지어 스레드의 context switch 는 프로세스 context switch 와는 달리 캐시 메모리를 비울 필요가 없기 때문에 더 빠르다. 따라서 시스템의 throughtput 이 향상되고 자원 소모가 줄어들며 자연스럽게 프로그램의 응답 시간이 단축된다. 이러한 장점 때문에 여러 프로세스로 할 수 있는 작업들을 하나의 프로세스에서 스레드로 나눠 수행하는 것이다.

 

단점

멀티 프로세스 기반으로 프로그래밍할 때는 프로세스 간 공유하는 자원이 없기 때문에 동일한 자원에 동시에 접근하는 일이 없었지만 멀티 스레딩을 기반으로 프로그래밍할 때는 이 부분을 신경써줘야 한다. 서로 다른 스레드가 데이터와 힙 영역을 공유하기 때문에 어떤 스레드가 다른 스레드에서 사용중인 변수나 자료구조에 접근하여 엉뚱한 값을 읽어오거나 수정할 수 있다.

그렇기 때문에 멀티스레딩 환경에서는 동기화 작업이 필요하다. 동기화를 통해 작업 처리 순서를 컨트롤 하고 공유 자원에 대한 접근을 컨트롤 하는 것이다. 하지만 이로 인해 병목현상이 발생하여 성능이 저하될 가능성이 높다. 그러므로 과도한 락으로 인한 병목현상을 줄여야 한다.

 

멀티 프로세스와 멀티 스레드의 차이를 설명하시오.

 

멀티 스레드는 멀티 프로세스보다 적은 메모리 공간을 차지하고 문맥 전환이 빠르다는 장점이 있지만, 오류로 인해 하나의 스레드가 종료되면 전체 스레드가 종료될 수 있다는 점과 동기화 문제를 안고 있다. 반면 멀티 프로세스 방식은 하나의 프로세스가 죽더라도 다른 프로세스에는 영향을 끼치지 않고 정상적으로 수행된다는 장점이 있지만, 멀티 스레드보다 많은 메모리 공간과 CPU 시간을 차지한다는 단점이 존재한다. 이 두 가지는 동시에 여러 작업을 수행한다는 점에서 같지만 적용해야 하는 시스템에 따라 적합/부적합이 구분된다. 따라서 대상 시스템의 특징에 따라 적합한 동작 방식을 선택하고 적용해야 한다.

 

상호배제(mutual exclusion)란?

 

상호배제는 병행 프로세스에서 프로세스 하나가 공유 자원을 사용할 때 다른 프로세스들이 동일한 일을 할 수 없도록 하는 방법이다. 즉, 공유 자원에 있는 데이터에 접근하는 다른 프로세스를 이미 사용중인 프로세스 하나가 해당 데이터에 접근할 수 없게 하는 것을 상호배제(Mutual exclustion,Mutex)라고 한다. 물론 읽기 연산은 공유 데이터에 동시에 접근해도 문제가 발생하지 않지만, 변수나 파일은 프로세스 별로 하나씩 차례로 읽거나 쓰도록 해야한다. 예를 들면 하나의 프로세스가 순차적으로 파일을 읽는 작업을 하는 도중에 다른 프로세스가 파일의 내용을 변경해버리면 읽어오는 값이 예상과 다를 수 있기에 이러한 상황을 제어하는 동기화 작업이 필요한 것이다.

 

동기화(synchronization)란?

 

시스템의 자원은 한정적인데 이 한정적인 자원에 여러 스레드가 동시에 접근해서 사용하려하면 문제가 발생할 수도 있습니다. 이런 문제를 방지하기 위해 스레드들에게 하나의 자원에 대한 처리 권한을 주거나 순서를 조정해주는 기법입니다.

임계영역(critical section)이란?

 

임계구역은 다중 프로그래밍 운영체제에서 여러개의 프로세스가 공유하는 데이터 및 자원에 대하여 어느 한 시점에서는 하나의 프로세스만 자원 또는 데이터를 사용하도록 지정된 공유 자원을 의미합니다.

 

임계영역이 만족해야 하는 세 가지 조건을 설명하시오.

 

1) 상호배제 : 어떤 프로세스가 임계 영역에서 작업 중이면 다른 프로세스는 임계 영역으로 들어 갈 수 없다.

 

2) 진행 : 임계 영역에 프로세스가 없는 상태에서 여러 프로세스가 들어가려고 할 때는 어떤 프로세스가 들어갈지 적절히 결정해야 한다.

 

3) 한정 대기 : 다른 프로세스가 임계 영역을 무한정 기다리는 상황을 방지하려면 임계 영역에 한 번 들어갔던 프로세스는 다음에 임계 영역에 다시 들어갈 때 제한을 둔다.

 

세마포어와 뮤텍스란 무엇인지 설명하시오.

 

여러 쓰레드들은 자원을 공유하고, 프로세스간 메시지를 전송하면서 간혹 문제가 발생할 수 있습니다.

즉, 공유된 자원에 여러 프로세스 , 쓰레드가 동시에 접근하면서 문제가 발생합니다. 

공유된 자원 속 하나의 데이터는 한번에 하나의 프로세스만 접근할 수 있도록 제한해 두어야 할 필요성이 있는데

이를 위해 고안된 것이 Semaphore(세마포어)입니다.

 

유명한 화장실 예제로 쉽게 설명해보겠습니다.

공중 화장실은 한번에 1명만 사용할 수 있다고 가정하겠습니다.

어떤 사람이 사용하고 있는데 다른 누군가가 갑자기 들어와서 같이 쓰자고 하면... 생각만해도 이상하지요..?

이를 막기 위해 화장실 열쇠를 만들 수 있습니다.

열쇠를 가지고 있는 한 사람만 화장실을 이용하고, 열쇠가 없는 사람은 밖에서 대기를 하죠.

여기서 열쇠는 세마포어와 같은 역할을 한다고 할 수 있습니다.

 

그럼 세마포터와 뮤텍스 각각 어떤 의미를 가지고 있을까요?

 

Semaphore(세마포어)

 

공유된 자원의 데이터를 여러 프로세스가 접근하는 것을 막는 것!

그리고 세마포어는 리소스의 상태를 나타내는 간단한 카운터라고 할 수 있습니다.

일반적으로 비교적 긴 시간을 확보하는 리소스에 대해 이용하게 되며, 유닉스 시스템의 프로그래밍에서 세마포어는 운영체제의 리소스를 경쟁적으로 사용하는

다중 프로세스에서 행동을 조정하거나 또는 동기화 시키는 기술입니다.

위 화장실 예제로 다시 살펴보면, 세마포어는 1개 이상의 열쇠라고 할 수 있습니다.

만약 화장실 칸이 4개이고 열쇠가 4개라면, 4명까지는 대기없이 바로 사용할 수 있고 

그 다음 부터는 대기를 해야하죠. 이것이 바로 세마포어입니다.

그러므로 몇개의 세마포어로 구성해서 운영체제의 리소스를 경쟁적으로 사용할지는 꽤 중요한 이슈입니다.

그림으로 표현하면 아래와 같습니다.

 

 

Mutex(뮤텍스, 상호배제)

공유된 자원의 데이터를 여러 쓰레드가 접근하는 것을 막는 것!

즉, *Critical Section을 가진 쓰레드들의 Running tme이 서로 겹치지 않게 각각 단독으로 실행되게 하는 기술입니다. 

다중 프로세스들이 공유 리소스에 대한 접근을 조율하기 위해 locking과 unlocking을 사용합니다.

간단히 말해, Mutex객체를 두 쓰레드가 동시에 사용할 수 없다는 말입니다.

위 화장실 예제로 다시 살펴보면, 뮤텍스는 무조건 1개의 열쇠만 가질 수 있습니다!

그림으로 표현하면 아래와 같습니다.

세마포어와 뮤텍스의 차이?

 

세마포어는 뮤텍스가 될수 있지만, 뮤텍스는 세마포어가 될 수 없습니다.

뮤텍스는 항상 열쇠 1개이고, 세마포어는 여러개 가질 수 있기 때문에 

세마포어의 열쇠가 1개라면 뮤텍스와 같습니다.

 

세마포어는 파일시스템 상 파일형태로 존재, 뮤텍스는 프로세스 범위입니다.

즉, 프로세스가 사라질 때 뮤텍스는 clean up 됩니다.

세마포어는 소유할 수 없는 반면, 뮤텍스는 소유할 수 있습니다.

 

뮤텍스의 경우, 뮤텍스를 소유하고 있는 쓰레드가 이 뮤텍스를 해제할 수 있습니다.

반면, 세마포어의 경우, 세마포어를 소유하고 있지 않은 쓰레드도 이 세마포어를 해제할 수 있습니다.

 

모니터란 무엇인지 설명하시오.

 

동기화 문제를 해결하기 위해서 우리는 세마포라는 도구를 사용하였다. 하지만 동기화 문제를 해결하는데 세마포만이 사용되지는 않는다. 사실 세마포의 경우 오래된 동기화 도구라고 할 수 있다. 현재 사용되는 도구 중 하나가 모니터이다. 특히 자바 프로그램에서는 모니터에 대한 활용이 높다. 세마포가 어셈블리 언어에 적합한 도구라면 모니터는 그보다 고수준인 언어의 도구라고 할 수 있다.

 

공유자원과 공유자원에 대한 접근함수가 존재한다. 이러한 구역을 임계구역이라고 한다. 모니터의 경우 두 개의 queue가 있는데 각각 배타동기와 조건동기의 역할을 한다. 배타동기의 queue는 하나의 쓰레드만 공유자원에 접근할 수 있게 하는 작용을 하는 공간이다. 특정 쓰레드가 공유자원을 사용하는 함수를 사용하고 있으면 다른 쓰레드는 접근을 할 수 없고 대기해야 한다. 조건 동기의 queue는 진입 쓰레드가 블록되면서 새 쓰레드가 진입가능하게 하는 공간이다. 새 쓰레드는 조건동기로 블록된 쓰레드를 깨울 수 있다. 깨워진 쓰레드는 현재 쓰레드가 나가면 재진입할 수 있다.

 

교착 상태(deadlock)이란 무엇인지 설명하시오.

 

교착상태(Dead Lock)은 상호 배제에 의해 나타나는 문제점으로, 둘 이상의 프로세스들이 자원을 점유한 상태에서 서로 다른 프로세스가 점유하고 있는 자원을 요구하며 무한정 기다리는 현상을 의미합니다.

 

교착 상태의 발생 조건을 설명하시오.

 

교착상태가 발생하기 위해서는 다음의 네가지 조건이 충족되어야 하는데, 이 네가지 조건중 하나라도 충족되지 않으면 교착상태가 발생하지 않습니다.

 

상호배제(Mutual Exclusion)

한번에 한개의 프로세스만이 공유 자원을 사용할 수 있어야 합니다. 

 

점유와 대기(Hold and Wait) 

최소한 하나의 자원을 점유하고 있으면서 다른 프로세스에 할당되어 사용되고 있는 자원을 추가로 점유하기 이해 대기하는 프로세스가 있어야 합니다.

 

비선점(Non-preemption)

다른 프로세스에 할당된 자원은 사용이 끝날 때까지 강제로 빼앗을 수 없어야합니다.

 

환형 대기(Circular Wiat) 

공유자원과 공유자원을 사용하기 위해 대기하는 프로세스들이 원형으로 구성되어 있어 자신에게 할당된 자원을 점유하면서 앞이나 뒤에 있는 프로세스의 자원을 요구해야 합니다.

 

다음 스케줄링 알고리즘을 설명하시오

 

1) FCFS (First In First Out)

 

먼저 온 고객을 먼저 서비스해주는 방식, 즉 먼저 온 순서대로 처리.

비선점형(Non-Preemptive) 스케줄링
일단 CPU 를 잡으면 CPU burst 가 완료될 때까지 CPU 를 반환하지 않는다. 할당되었던 CPU 가 반환될 때만 스케줄링이 이루어진다.

 

문제점

convoy effect
소요시간이 긴 프로세스가 먼저 도달하여 효율성을 낮추는 현상이 발생한다.

 

2) SJF (Shortest Job First)

 

다른 프로세스가 먼저 도착했어도 CPU burst time 이 짧은 프로세스에게 선 할당

비선점형(Non-Preemptive) 스케줄링

 

문제점

starvation
효율성을 추구하는게 가장 중요하지만 특정 프로세스가 지나치게 차별받으면 안되는 것이다. 이 스케줄링은 극단적으로 CPU 사용이 짧은 job 을 선호한다. 그래서 사용 시간이 긴 프로세스는 거의 영원히 CPU 를 할당받을 수 없다.

 

3) SRT (Shortest Remaining time First)

 

새로운 프로세스가 도착할 때마다 새로운 스케줄링이 이루어진다.

선점형 (Preemptive) 스케줄링
현재 수행중인 프로세스의 남은 burst time 보다 더 짧은 CPU burst time 을 가지는 새로운 프로세스가 도착하면 CPU 를 뺏긴다.

 

문제점

starvation

새로운 프로세스가 도달할 때마다 스케줄링을 다시하기 때문에 CPU burst time(CPU 사용시간)을 측정할 수가 없다.

 

4) Priority Scheduling

 

우선순위가 가장 높은 프로세스에게 CPU 를 할당하겠다. 우선순위란 정수로 표현하게 되고 작은 숫자가 우선순위가 높다.

선점형 스케줄링(Preemptive) 방식
더 높은 우선순위의 프로세스가 도착하면 실행중인 프로세스를 멈추고 CPU 를 선점한다.

비선점형 스케줄링(Non-Preemptive) 방식
더 높은 우선순위의 프로세스가 도착하면 Ready Queue 의 Head 에 넣는다.

 

문제점

starvation

무기한 봉쇄(Indefinite blocking)
실행 준비는 되어있으나 CPU 를 사용못하는 프로세스를 CPU 가 무기한 대기하는 상태

 

해결책

aging

아무리 우선순위가 낮은 프로세스라도 오래 기다리면 우선순위를 높여주자.

 

5) Round Robin

 

현대적인 CPU 스케줄링

각 프로세스는 동일한 크기의 할당 시간(time quantum)을 갖게 된다.

할당 시간이 지나면 프로세스는 선점당하고 ready queue 의 제일 뒤에 가서 다시 줄을 선다.

RR은 CPU 사용시간이 랜덤한 프로세스들이 섞여있을 경우에 효율적

RR이 가능한 이유는 프로세스의 context 를 save 할 수 있기 때문이다.

 

장점

Response time이 빨라진다.
n 개의 프로세스가 ready queue 에 있고 할당시간이 q(time quantum)인 경우 각 프로세스는 q 단위로 CPU 시간의 1/n 을 얻는다. 즉, 어떤 프로세스도 (n-1)q time unit 이상 기다리지 않는다.

프로세스가 기다리는 시간이 CPU 를 사용할 만큼 증가한다.
공정한 스케줄링이라고 할 수 있다.

 

주의할 점

설정한 time quantum이 너무 커지면 FCFS와 같아진다. 또 너무 작아지면 스케줄링 알고리즘의 목적에는 이상적이지만 잦은 context switch 로 overhead 가 발생한다. 그렇기 때문에 적당한 time quantum을 설정하는 것이 중요하다.

 

단기 스케줄링, 중기 스케줄링, 장기 스케줄링의 차이를 설명하시오.

 

장기 스케줄링(Long-term scheduler) : 메모리와 디스크 사이의 스케줄링을 담당.

실행할 작업을 준비 큐(입력 큐)에서 꺼내 메인 메모리에 적재함. 디스크에서 메모리로 적재될 프로그램을 선정한다. 쉽게 말하면 메모리 문지기 역할이다. (작업 스케줄러 라고도 불린다)
단순히 문을 열고 닫는 문지기 역할에서 그치는게 아니라 메인 메모리에 있는 프로세스의 양을 판단하고 결정하는 역할도 한다. 
만약 메인 메모리에 적재된 프로세스들이 너무 많아 실행이 빈번하게 발생되고 메인 메모리에 프로세스들이 넘쳐나면 더 이상 프로세스들을 메인 메모리에 적재 시키지 않는다. - 멀티프로그래밍의 정도를 결정

 

프로세스의 상태
new -> ready(in memory)

 

중기 스케줄링(Mid-term scheduler) : 현 시스템에서 메모리에 너무 많은 프로그램이 동시에 올라가는 것을 조절하는 스케줄러. cpu를 할당받고 프로그램이 실행중 일 때 멀티 프로그래밍 정도에 따라 프로그램들을 관리해 주는 역할을 한다. (= swapper)

여유 공간 마련을 위해 프로세스를 통째로 메모리에서 디스크로 쫓아냄. (swapping)
프로세스들이 CPU를 서로 차지하려고 할 때 프로세스를 기억장소(메인 메모리)에서 잠시 빼내고 다시 메인 메모리에 들여보내 실행시킬 수 있는 교체(Swapping)기법을 사용한다.

 

프로세스의 상태
ready -> suspended

단기 스케줄링(Short-term scheduler) : CPU 와 메모리 사이의 스케줄링을 담당. 메인 메모리의 준비 상태에 있는 작업 중 실행할 작업을 선택하여 CPU를 할당. (프로세서 스케줄러 라고도 불린다)
하지만 CPU는 프로그램을 실행 시키기 전에 먼저 실행 시키기 위한 데이터 확보가 필요하다.
CPU에게 그 필요한 데이터를 확보 시켜주고 CPU를 할당하는 역할을 이 단기 스케줄링이 한다.
그리고 준비 큐에 있는 프로그램들(프로세스)중 먼저 도착한 프로세스에게 CPU를 할당 시켜준다. = 디스패쳐

프로세스의 상태
ready -> running -> waiting -> ready

 

장기 스케줄링과 중기 스케줄링, 단기 스케줄링의 차이?
먼저 장기 스케줄링과 단기 스케줄링의 차이는 실행 빈도이다.
단기 스케줄링은 실행할 프로세스를 수시로 선택해야 해서 실행시간이 100만 분의 수초 정도이다.
반대로 장기 스케줄링은 시스템에 새로운 작업이 들어오는 것은 분 단위이므로 단기 스케줄링에 비해 상대적으로 덜 수행하는 것이다.
그 때문인지 작업이 시스템에 들어오는 정도가 일정하다면 작업의 도착 정도와 작업의 끝냄 정도가 비슷하다. 
장기 스케줄러의 실행은 작업이 시스템을 나갈 때만 실행되기 때문에 실행 간격이 상대적으로 길다 그래서 실행시간이 좀 길어도 영향을 적게 받는다.
중기 스케줄링은 장기 스케줄러의 비중이 적거나 아예 없는 시스템에서 중기 스케줄러를 추가하여 사용하는데 가상 메모리체제나 시분할 기법을 사용하는 시스템이 그 (예)이다. 중기 스케줄러는 프로세스들이 CPU를 서로 차지하려고 할 때, 프로세스를 기억장소(메인 메모리)에서 빼고 다시 넣을 수 있어서 다중 프로그래밍의 정도를 줄일 수 있다.

 

선점 스케줄링과 비선점 스케줄링의 차이점을 설명하시오. 엄격한 비선점식 스케줄링을 사용하지 않는 이유도 설명하시오.

 

선점스케줄링은 높은 우선순위의 프로세스가 들어올 경우 현재 프로세스를 중지시키고, 높은 우선순위의 프로세스를 처리.

비선점 스케줄링은 한번 할당하면 끝날때가지 다른 프로세스가 들어오지 못하는 스케줄링.

엄격한 비선점식 스케줄링을 사용하지 않는 이유는 짧은 프로세서가 오랫동안 대기하게 될 경우 비효율적이고, 기아상태가 발생할 수 있다.

 

논리적 주소와 물리적 주소 차이를 설명하시오.

 

논리적 주소

주소 프로그램이 실행되는 동안 CPU에 의해 생성 된 것을 논리적 주소 라고합니다. 논리 주소는 물리적으로 존재하지 않으므로 가상 주소입니다. 따라서 가상 주소 라고도합니다. 이 주소는 실제 메모리 위치를 액세스하기위한 참조로 사용됩니다. 프로그램 관점에서 생성 된 모든 논리 주소 집합을 논리 주소 공간 이라고합니다.

논리 주소는 메모리 관리 장치라는 하드웨어 장치에 의해 해당 물리적 ​​주소에 매핑됩니다. MMU에서 사용되는 주소 바인딩 방법은 컴파일 타임 및 로드 시간 동안 동일한 논리 및 실제 주소를 생성 합니다 . 그러나 실행 시간 동안 주소 바인딩 방법은 다른 논리 및 실제 주소를 생성합니다.

 

물리적 주소

물리적 주소 는 메모리의 물리적 위치를 식별합니다. MMU ( Memory-Management Unit) 는 해당 논리 주소의 실제 주소를 계산합니다. MMU는 논리 주소 계산 물리 주소를 사용합니다. 사용자는 실제 주소를 결코 취급하지 않습니다. 대신, 물리적 주소는 사용자에 의해 해당 논리 주소에 의해 액세스됩니다. 사용자 프로그램은 논리 주소를 생성하고 프로그램이이 논리 주소에서 실행되고 있다고 생각합니다. 그러나이 프로그램은 실행을위한 물리적 메모리가 필요합니다. 따라서 논리 주소는 사용되기 전에 실제 주소에 매핑되어야합니다.

논리 주소는 메모리 관리 장치 라는 하드웨어를 사용하여 실제 주소에 매핑됩니다. 논리적 주소 공간에서 논리적 주소에 해당하는 모든 물리적 주소 세트를 물리적 주소 공간 이라고합니다.

 

논리 주소와 실제 주소의 주요 차이점

 

1. 논리 주소와 실제 주소의 기본적인 차이점은 프로그램의 관점에서 CPU가 논리 주소를 생성한다는 것입니다. 한편, 물리 어드레스는 메모리 유닛에 존재하는 위치이다.

 

2. 프로그램에 대해 CPU에 의해 생성 된 모든 논리 주소 집합을 논리 주소 공간이라고합니다. 그러나 해당 논리 주소에 매핑 된 모든 물리 주소 집합을 실제 주소 공간이라고합니다.

 

3. 논리 주소는 메모리 장치에 물리적으로 존재하지 않으므로 논리 주소는 가상 주소라고도합니다. 물리적 주소는 물리적으로 액세스 할 수있는 메모리 장치의 위치입니다.

 

4. 동일한 논리 주소 및 실제 주소는 컴파일 타임 및로드 시간 주소 바인딩 방법에 의해 생성됩니다.

 

5. 런타임 주소 바인딩 방법이 서로 다른 동안 생성 된 논리 및 실제 주소입니다.

 

6. 논리 주소는 프로그램이 실행되는 동안 CPU에 의해 생성되는 반면 물리적 주소는 MMU (Memory Management Unit)에 의해 계산됩니다.

 

다음 메모리 할당 알고리즘을 설명하시오.

 

1) 최초 적합

가용공간 중 수용가능한 첫번째 기억공간을 할당하는 방법

사용 가능한 공간을 검색하여 첫 번째로 찾아낸 곳을 할당하는 방식

맨앞(또는 지난번 탐색이 끝난 곳)에서부터 수용가능한 첫번째 공간을 선택

장점: 가용공간 정렬 불필요

단점: 큰 공간을 쪼개어 사용하게 될 수 있음

 

2) 최적 적합

모든 공간 중에서 수용가능한 가장 작은 곳을 선택

사용가능한 공간들 중에서 가장 작은 것을 선택하는 방식

가용공간을 정렬하여 필요한 크기 이상의 공간 중 가장 작은 것을 할당하는 방법

장점: 큰 공간을 쪼개어 쓰는 일이 적음

단점: 정렬 필요. 작은 틈새 공간이 많이 발생

 

3) 최악 적합

모든 공간 중에서 수용가능한 가장 큰 곳을 선택

사용 가능한 공간들 중에서 가장 큰 것을 선택하는 방식

가용공간을 정렬하여 수용가능한 공간 중 가장 큰 곳을 할당하는 방법

장점: 남은 공간이 큼직큼직함. 1순위에 할당하므로 선택이 빠름

단점: 기억공간 정렬 필요, 공간 낭비 발생

 

공간효율성: 최적적합 > 최초적합 ≫ 최악적합

시간효율성: 최초적합 > 최적적합 ≒ 최악적합

최악적합은 잘 사용되지 않음

 

내부 단편화와 외부 단편화의 차이를 설명하시오.

 

단편화 (Fragmentation) : 프로세스들이 메모리에 적재되고 제거되는 일이 반복되다보면, 프로세스들이 차지하는 메모리 틈 사이에 사용 하지 못할 만큼의 작은 자유공간들이 늘어나게 되는데, 이것이 단편화 이다.

 

외부단편화 : 프로그램을 할당하고 난 다음 아주 작은 크기로 남은 조각들이 생겨 사용할 수 없는 작은 공간들이 많이 생길 수 있습니다. 이 공간들을 합치면 요구되는 공간을 할달할 수 있음에도 불구하고 연속적인 공간이 아니라서 할당하지 못하는 상황을 외부 단편화라고 합니다.

 

내부 단편화: 프로세스가 사용하는 메모리 공간 에 포함된 남는 부분. 예를들어 메모리 분할 자유 공간이 10,000B 있고 Process A 가 9,998B 사용하게되면 2B 라는 차이 가 존재하고, 이 현상을 내부 단편화라 칭한다.

 

압축 : 외부 단편화를 해소하기 위해 프로세스가 사용하는 공간들을 한쪽으로 몰아, 자유공간을 확보하는 방법론 이지만, 작업효율이 좋지 않다.

 

페이징과 세그먼테이션에 대해 설명하시오.

 

Paging(페이징)

 

물리메모리를 사용할 때, 페이지를 고정크기의 프레임단위로 나눕니다.

논리메모리도 같은 프레임단위인 페이지로 나누어 프레임과 페이지를 대응하게 하여

연속적인 물리메모리가 아니더라도 원하는 크기의 프레임을 사용할 수 있도록 하는 기능입니다. 

 

프레임(Frame) : 물리 메모리를 일정한 크기로 나눈 블록

페이지(Page) : 가상 메모리를 일정한 크기로 나눈 블록

 

물리메모리(프레임)와 가상메모리(페이지)를 대응하기 위해 page mapping 과정이 필요합니다. 

이를 위해 Paging table을 설정해야 합니다.

페이징 기법을 사용하면 연속적이지 않은 공간도 활용할 수 있기 때문에 외부단편화(External fragmentation)을 해결할 수 있고, 코드를 쉽게 공유할 수 있다는 장점이 있습니다. 

그리고 페이지 단위를 작게하면 내부 단편화(Internal fragmentation) 역시 해결할 수 있지만

(페이지에 공간을 할당한 후, 남는 공간이 적어지기 때문에) 그 만큼, page mapping 과정이 증가하므로 서로  trade off 관계에 있습니다.

 

Segmentation(세그멘테이션)

 

페이징 기법에서는 가상메모리를 같은 크기의 단위로 분할했으나 

세크멘테이션 기법에서는 가상메모리를 서로 크기가 다른 논리적 단위인 세그먼트(Segment)로 분할하고 

메모리를 할당하며 주소 변환을 하게 됩니다. 

(각각의 세그먼트들은 연속적인 공간에 저장되어있습니다)

 

세그먼트들의 크기가 서로 다르기 때문에 메모리를 페이징 기법처럼 미리 분할해 둘 수 없고,

메모리에 적재될 때 빈 공간을 찾아 할당하는 사용자 관점의 가상메모리 관리 기법입니다.

 

페이징기법과 마찬가지로 mapping을 위해 세그먼트 테이블을 필요로 합니다.

이 기법은 하나의 세그먼트 단위로 통제가 가능한 장점이 있습니다.

즉 내부단편화가 발생하지 않습니다.

그러나 서로 다른 크기의 세그먼트들에 대해 필요시에 메모리에 올리고 필요없을 경우

내리는 작업을 반복하다보면 외부 단편화가 생기는 문제점이 있습니다.

 

페이징 시스템에서 페이지 테이블이 어떤 기능을 하는지 설명하시오.

 

특정 프로세스의 페이지 테이블은 메모리의 특정 페이지 번호에 대응하는 물리적 메모리에 있는 페이지의 번호를 포함한다. 논리 주소를 물리 주소로 변환하는 메모리 관리 장치로 사용된다.

 

가상 메모리와 요구 페이징(Demand Paging)이란 무엇인지 설명하시오.

 

지금까지의 메모리 관리 기법 방식은 

프로세스 전체가 실행되기 전에 메모리로 올라와야 한다는 것을 전제로 하고 있다. 

프로세스 전체가 메모리 내에 올라오지 않더라도 실행이 가능하도록 하는 기법을 가상메모리라 한다.

가상 메모리는 물리 메모리로부터 사용자 관점의 논리 메모리를 분리시켜 주 메모리를 균일한 크기의 저장 공간으로 구성된 엄청나게 큰 배열로 추상화 시켜 준다. 

따라서 작은 메모리를 가지고도 큰 가상 주소 공간을 제공한다.

 

장 점 

 - 사용자 프로그램이 물리 메모리보다 커져도 된다는 점이다. 
   즉, 메모리 크기의 제약으로부터 자유로워진다.

 - 각 사용자 프로그램이 더 작은 메모리를 차지하므로 더 많은 프로그램을 동시에 수행할 수 있다. 
   이에 따라 응답시간은 늘어나지 않으면서 CPU 이용률과 처리율이 높아진다.

 - 프로그램을 메모리에 올리고 스왑(swap)하는데 필요한 입/출력 횟수가 줄어든다.
   따라서 프로그램들이 보다 빨리 실행된다.

 - 가상메모리 파일의 공유를 쉽게 해주고 공유 메모리 구현을 가능하게 한다.

 - 프로세스 생성을 효율적으로 처리할 수 있는 메커니즘도 제공한다.

 

단 점

 - 구현이 어렵고, 잘못 사용 시 성능이 현저히 저하 될 수 있다.

 

 요구 페이징 (Demand Paging)

 - 실행 프로그램을 디스크에서 메모리로 적재할 때 프로그램 전부를 물리메모리에 적재한다고 하면,
   프로그램 전체를 메모리에 둘 필요가 있을까?? 
   가상 메모리 시스템에서 많이 사용하는 요구 페이징 기법을 알아보자 
   요구 페이징이란 초기에 필요한 것들만 적재하고, 페이지들이 실행 과정에서 실제로 필요할 때 적재하는 기법이다. 
   즉, 한번도 접근되지 않는 페이지는 물리 메모리에 전혀 적재되지 않는다.

 

장 점

- 실제 필요한 페이지들만 메모리로 읽어오므로 사용되지 않는 페이지를 메모리로 가져오지 않음으로써
  시간 낭비와 메모리 공간 낭비를 줄일 수 있다.

- 프로세스가 메모리에 존재하는 페이지들만 접근하는 한 실행은 정상적으로 진행된다. 

  하지만 프로세스가 메모리에 올라와 있지 않는 페이지를 접근하려고 하면 어떤 일이 발생할까?
   -> 페이지 테이블 항목이 무효로 설정되어 있으므로 페이지 부재 트랩(page-fault trap)을 발생시킨다.

 

페이지 부재를 처리하는 과정

1. 프로세스에 대한 내부 테이블을 검사해서 그 메모리 참조가 유효(valid)/무효(invalid) 인지를 알아낸다.

2. 만약 무효한 페이지에 대한 참조라면 그 프로세스는 중단된다.
    만약 유효한 참조인데 페이지가 아직 메모리에 올라오지 않았다면, 그것을 디스크로부터 가져와야 한다.

3. 빈 공간 즉, 자유 프레임을 찾는다. (예를 들면, 페이지 프레임 리스트에서 하나 가져옴)

4. 디스크에 새로이 할당된 프레임으로 해당 페이지를 읽어 들이도록 요청한다.

5. 디스크 읽기가 끝나면, 이 페이지가 이제는 메모리에 있다는 것을 알리기 위해 페이지 테이블을 갱신하며,
   프로세스가 유지하고 있는 내부 테이블을 수정한다.

6. 트랩에 의해 중단되었던 명령을 다시 수행한다.
    이제 프로세스는 마치 그 페이지가 항상  메모리에 있었던 것처럼 해당 페이지를 접근할 수 있다.

 

페이지 부재(Page Fault)란 무엇인지 설명하시오.

 

페이지 부재란 프로세스(프로그램)가 메인 메모리(RAM)에 저장되지 않은 페이지를 사용하려는 현상입니다. 즉, 프로세스가 사용하려고 하는 페이지가 메인 메모리에 없는 경우를 맙합니다. 

 

페이지 교체란 무엇인지 설명하시오.

 

페이지 교체는 페이지 부재가 발생하면 메인 메모리에 있으면서 사용하지 않는 페이지를 디스크로 내보내고 새로운 페이지로 바꾸는 과정이다. 내보낼 페이지를 고를 때는 시스템의 효율성에 영향을 주므로 페이지 부재 비율이 가장 낮은 알고리즘을 선택한다.

 

다음 페이지 교체 알고리즘을 설명하시오.

 

1) FIFO (First In First Out)

 

가장 간단한 페이지 교체 알고리즘으로 FIFO(first-in first-out)의 흐름을 가진다. 즉, 먼저 물리 메모리에 들어온 페이지 순서대로 페이지 교체 시점에 먼저 나가게 된다는 것이다.

 

장점

- 이해하기도 쉽고, 프로그램하기도 쉽다.

 

단점

- 오래된 페이지가 항상 불필요하지 않은 정보를 포함하지 않을 수 있다(초기 변수 등)

- 처음부터 활발하게 사용되는 페이지를 교체해서 페이지 부재율을 높이는 부작용을 초래할 수 있다.

- Belady의 모순: 페이지를 저장할 수 있는 페이지 프레임의 갯수를 늘려도 되려 페이지 부재가 더 많이 발생하는 모순이 존재한다.

2) OPT (Optimal)

 

Belady의 모순을 확인한 이후 최적 교체 알고리즘에 대한 탐구가 진행되었고, 모든 알고리즘보다 낮은 페이지 부재율을 보이며 Belady의 모순이 발생하지 않는다. 이 알고리즘의 핵심은 앞으로 가장 오랫동안 사용되지 않을 페이지를 찾아 교체하는 것이다. 주로 비교 연구 목적을 위해 사용한다.

 

장점

- 알고리즘 중 가장 낮은 페이지 부재율을 보장한다.

 

단점

- 구현의 어려움이 있다. 모든 프로세스의 메모리 참조의 계획을 미리 파악할 방법이 없기 때문이다.

 

3) LRU (Least Recently Used)

 

최적 알고리즘의 근사 알고리즘으로, 가장 오랫동안 사용되지 않은 페이지를 선택하여 교체한다.

 

특징

-대체적으로 FIFO 알고리즘보다 우수하고, OPT알고리즘보다는 그렇지 못한 모습을 보인다.

4) LFU (Least Frequently Used) 

 

참조 횟수가 가장 적은 페이지를 교체하는 방법이다. 활발하게 사용되는 페이지는 참조 횟수가 많아질 거라는 가정에서 만들어진 알고리즘이다.

 

특징

- 어떤 프로세스가 특정 페이지를 집중적으로 사용하다, 다른 기능을 사용하게되면 더 이상 사용하지 않아도 계속 메모리에 머물게 되어 초기 가정에 어긋나는 시점이 발생할 수 있다

- 최적(OPT) 페이지 교체를 제대로 근사하지 못하기 때문에, 잘 쓰이지 않는다.

5) MFU (Most Frequently Used)

 

MFU: Most Frequently Used
참조 회수가 가장 작은 페이지가 최근에 메모리에 올라왔고, 앞으로 계속 사용될 것이라는 가정에 기반한다.

 

특징

- 최적(OPT) 페이지 교체를 제대로 근사하지 못하기 때문에, 잘 쓰이지 않는다.

 

스래싱이란 무엇인지 설명하시오.

 

1. 스래싱이란?

페이지 부재율이 높은 것을 의미 

스레싱은 심각한 성능 저하를 초래 

충분한 프레임을 할당 받지 못한 프로세스에 대해 생각해보자

 

활발하게 사용되는 페이지 집합을 지원해 줄 만큼 프레임이 충분히 할당 받지 못한 프로세스는  
페이지 부재가 발생하게 된다.

 

이때 페이지 교체가 필요하지만 이미 활발하게 사용되는  페이지들만으로 이루어져 있으므로

어떤 페이지가 교체되든지 바로 다시 페이지 교체가 필요 하게 될 것이다.

 

결과적으로 바로 바로 반복해서 페이지 부재가 발생하며 교체된 페이지는 다시 얼마 지나지 않아

읽어올 필요가 생긴다.

이러한 과도한 페이징 작업을 쓰레싱 이라 한다.

 

 

2. 쓰레싱의 원인

- 다중 프로그래밍 정도가 높아짐에 따라 CPU 이용률이 높아진다. 

CPU이용률이 최대값에 도달하였을때, 다중 프로그래밍의 정도가 그 이상으로 더 커지면

쓰레싱이 일어나게 되고 CPU 이용률은 급격히 떨어진다.

- 운영체제는 CPU 이용률을 감시하면서, CPU 이용률이 너무 낮아지면 새로운 프로세스를 시스템에 더 추가해서 

다중 프로그래밍의 정도를 높인다.  이 때 전역 페이지 교체 알고리즘을 사용하여 어떤 프로세스의 페이지인지에 대한 고려 없이 교체를 수행한다.

 

이제 어떤 프로세스가 새로운 실행 단계로 진입하여 더 많은 프레임을 필요로 한다고 가정하자.

페이지 부재가 발생하면서 다른 프로세스로부터 프레임들을 가져오게 될 것이다.

그런데 교체된 페이지들이 해당 프로세스에서 필요로 하는 것이었다면,

그 프로세스 역시 페이지 부재를 발생시키고  또 다른 프로세스에서 프레임을 가져온다.

이러한 프로세스들이 페이지 스왑 인, 스왑 아웃을 위해 페이징 장치를 사용해야 한다.

페이징 장치에 대한 큐잉이 진행되면서 준비 완료 큐는 비게 된다.

프로세스들이 페이징 장치를 기다리는 동안 CPU이용률은 떨어진다.

CPU 스케줄러는 이용률이 떨어지는 것을 보고, 이용률을 높이기 위하여 새로운 프로세스를  추가하여 

다중 프로그래밍의 정도를 더 높인다.

새로 시작하는 프로세스는 실행중인 프로세스들로부터 프레임을 가져오고자 하며 

더 많은 페이지 부재와 더 긴 페이징 장치 대기 시간을 야기한다.

 

결과적으로 CPU 이용률은 더욱 떨어지고, CPU스케줄러는 다중프로그래밍 정도를 더욱 높이려고 한다. 

결국 쓰레싱이 일어나게 되어 시스템의 처리율은 대단히 낮아지고 페이지 부재는 상당히 늘어난다. 

실질 메모리 접근 시간은 증가하고 프로세스들은 페이징 하는데 시간을 다 소비 하게 되어 아무런 일도 

할 수 없게 된다. 

 

3. 쓰레싱은 지역교환 알고리즘이나 우선순위 교환 알고리즘을 사용하여 제한할 수 있음

지역교환 알고리즘 하에서는 한 프로세스가 쓰레싱을 유발하더라도 다른 프로세스로부터 프레임을 뺏어 올 수

없으므로,  다른 프로세스는 쓰레싱으로 부터 자유로울 수 있다.

 

4. 쓰레싱 현상을 방지하기 위해서?

각 프로세스가 필요로하는 최소한의 프레임 개수를 보장해주어야 한다.

지역성이란 무엇인지 설명하시오.

 

지역성은 실행 중인 프로세스에서 나타나는 특성이다. 동일한 값이나 관련 저장 위치를 자주 액세스하는 현상, 즉 한번 참조한 데이터(동일한 값)를 짧은 시간 안에 다시 참조하거나 한번 참조한 데이터의 근처(관련 저장 위치)에 있는 데이터를 짧은 시간 안에 참조하는 현상을 의미한다. 다시 말해, 프로세스는 어느 실행 단계 동안 메모리의 정보를 균일하게 액세스하는 것이 아니라 선호하는 특정 페이지만 집중적으로 참조하느 현상으로 국부성이라고도 한다.

 

시간 지역성

시간 지역성은 특정 자원들을 상대적으로 짧은 시간안에 재사용한다는 것을 의미한다. 한 순간 한 지점에서 특정 메모리 위치를 참조할 때 동일한 위치에서 가까운 미래에 다시 참조할 가능성이 높다. 즉, 최근에 액세스한 항목은 오래지 않아 다시 액세스할 가능성이 있다는 것이다. 순환(루프), 서브 프로그램, 스택, 계산이나 합계에 사용하는 변수는 시간 지역성에 적용하는 예이다.

 

공간 지역성

공간 지역성은 프로세스가 메모리의 어떤 위치를 참조하면 그 근처를 이후에도 계속 참조할 가능성이 높다는 것이다. 상대적으로 가까운 위치에서 데이터 요소를 사용한다는 것을 의미한다. 메모리의 특정 위치를 특정 시간에 참조할 때 가까운 미래에 가까운 메모리 위치를 참조할 가능성이 높다. 데이터 정렬과 1차원 배열의 요소 탐색과 같이 선형 액세스할 때를 순차적 지역성이라고 한다. 이는 공간 지역성의 특수한 경우이다. 배열 검색(순회), 순차적 코드의 실행, 근처의 관련 변수 선언 등이 공간 지역성을 적용하는 예이다.

 

캐시의 지역성 원리

캐시 메모리는 속도가 빠른 장치와 느린 장치간의 속도차에 따른 병목 현상을 줄이기 위한 범용 메모리이다. 이러한 역할을 수행하기 위해서는 CPU 가 어떤 데이터를 원할 것인가를 어느 정도 예측할 수 있어야 한다. 캐시의 성능은 작은 용량의 캐시 메모리에 CPU 가 이후에 참조할, 쓸모 있는 정보가 어느 정도 들어있느냐에 따라 좌우되기 때문이다.

이 때 적중율(Hit rate)을 극대화 시키기 위해 데이터 지역성(Locality)의 원리를 사용한다. 지역성의 전제조건으로 프로그램은 모든 코드나 데이터를 균등하게 Access 하지 않는다는 특성을 기본으로 한다. 즉, Locality란 기억 장치 내의 정보를 균일하게 Access 하는 것이 아닌 어느 한 순간에 특정 부분을 집중적으로 참조하는 특성인 것이다.