게임 클라이언트 프로그래머 직군 면접 준비 (3)

게임 클라이언트 프로그래머 직군 면접 준비 (3)

 

소프트웨어 설계 방법

[객체지향 다섯 가지 설계 원칙]

단일 책임 원칙 (Single Responsibility Principle):

- 각 클래스는 하나의 기능 또는 책임만을 가져야 합니다. 이는 코드의 복잡성을 줄이고, 유지보수를 용이하게 합니다.

개방-폐쇄 원칙 (Open-Closed Principle):

- 소프트웨어 엔티티는 확장에는 열려 있어야 하지만, 수정에는 닫혀 있어야 합니다. 이는 기존 코드를 변경하지 않고도 시스템의 기능을 확장할 수 있도록 합니다.

리스코프 치환 원칙 (Liskov Substitution Principle):

- 파생 클래스는 기반 클래스의 기능을 손상시키지 않으면서 대체 가능해야 합니다.

인터페이스 분리 원칙 (Interface Segregation Principle):

- 클라이언트는 사용하지 않는 메소드에 의존하도록 강제되어서는 안 됩니다. 더 작고 구체적인 인터페이스로 분리하는 것이 바람직합니다.

의존성 역전 원칙 (Dependency Inversion Principle):

- 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 합니다.

 

[결합도]

•모듈 간에 상호 의존하는 정도를 나타낸다.

•독립적인 모듈이 되기 위해서는 각 모듈 간의 결합도가 약해야 하며 의존하는 모듈이 적어야 한다.

•결합도의 종류 : 자료 결합도 < 스탬프 결합도 < 제어 결합도 < 외부 결합도 < 공통 결합도 < 내용 결합도

- 자료 결합도 : 서로 다른 모듈 간에 매개변수 또는 인수를 통해 꼭 필요한 자료만을 교환하는 경우의 결합도

- 스탬프 결합도 : 서로 다른 모듈이 동일한 자료 구조를 참조하는 경우의 결합도

- 내용 결합도 : 한 모듈이 다른 모듈의 내부 자료를 직접적으로 참조하는 경우의 결합도

 

[응집도]

•모듈 안의 요소들이 서로 관련되어 있는 정도를 나타낸다.

•우연적 응집도 < 논리적 응집도 < 시간적 응집도 < 절차적 응집도 < 교환적 응집도 <순차적 응집도 < 기능적 응집도

- 논리적 응집도 : 논리적으로 서로 관련 있는 요소들을 모아 하나의 모듈로 작성한 경우의 응집도

- 절차적 응집도 : 일정한 순서에 의해 처리되어야 할 요소들을 하나의 모듈로 구성한 경우의 응집도로, 전달 데이터와 반환 데이터 사이에 관련이 없음

- 기능적 응집도 : 모듈 내부의 모든 기능 요소가 한 가지의 작업만을 수행하는 경우의 응집도

 

[테스트 기법 - 화이트 박스 테스트]

- 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법이다. 모든 문장을 한 번 이상 실행

 

[테스트 기법 - 블랙 박스 테스트]

- 동치 분할 검사, 경계값 분석, 원인-효과 그래프 검사, 오류 예측 검사, 비교 검사

 

[소프트웨어 생명주기(SDLC; Software Development Life Cycle)]

- 소프트웨어 생명주기는 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차입니다.

- 시스템이 개발될 때부터 운용과 유지보수를 거쳐 생애를 마칠 때까지 어떠한 순서를 밟는지에 대한 작업 프로세스를 모델화한 것입니다.

 

[폭포수 모델(Waterfall Model)]

•이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 다음 단계를 진행하는 개발 방법론이다.

•보헴이 제시한 고전적 생명 주기 모형이다.

•요구사항을 반영하기 어렵다.

 

[프로토타이핑 모델(Prototyping Model)]

고객이 요구한 주요 기능을 프로토타입으로 구현하여, 고객의 피드백을 반영하여 소프트웨어를 만들어가는 모델

 

[나선형 모델(Spiral Model)]

•나선을 따라 돌듯이 점진적으로 완벽한 최종 소프트웨어를 개발하는 것이다.

•‘계획 수립 → 위험 분석 → 개발 및 검증 → 고객 평가’과정이 반복적으로 수행된다.

 

[반복적 모델(Iteration Model)]

구축대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 SDLC 모델

 

[소프트웨어 개발 방법론(Software Development Methodology)]

- 소프트웨어를 하나의 생명체로 간주하고 소프트웨어 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과정을 형상화한 방법론이다

 

[구조적 방법론(Structured Development)]

- 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론(프로세스 중심의 하향식 방법론), 구조적 프로그래밍 표현을 위해 나씨-슈나이더만(Nassi-Shneiderman) 차트 사용

 

[정보공학 방법론(Information Engineering Development)]

- 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론

- 개발주기를 이용해 대형 프로젝트를 수행하는 체계적인 방법론

 

[객체지향 방법론(Object-Oriented Development)]

- 복잡한 현실 세계를 사람이 이해하는 방식으로 시스템에 적용하는 방법론

 

[컴포넌트 기반 방법론(CBD; Component Based Development)]

- 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론

 

[애자일 방법론(Agile Development)]

- 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론

• 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.

• 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.

• 계약 협상보다는 고객과 협업에 더 가치를 둔다.

• 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둔다.

 

[제품 계열 방법론(Product Line Development)]

- 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론