Post

Software Engineering

Software Engineering

PART 1. Software 공학

1. SW 정의, 분류, 특성

정의

컴퓨터를 이용, 문제 해결 용이한 컴퓨터 활용 및 운용 기술 (===문제 해결을 위한 컴퓨터 활용 및 운용 기술)

분류

응용 SW, 시스템 SW, 주문형 SW, 패키지 SW, 임베디드 SW

특성

비기시성, 비마모성, 복잡성, 복제성, 변경성, 순응성, 무형성, 개발성

2. SW 개념, SW 유형

SW 개념

사용자로 하여금 컴퓨터를 쉽고 효율적으로 사용하도록 도와주거나, 컴퓨터를 사용하여 주어진 문제를 용이하게 해결하기 위해 사용되는 컴퓨터 활용 및 운용 기술

SW 유형

-

특성

3. SW 위기와 해결방안

SW 위기의 배경

전문가 부족, SW 개발 방식의 비효율성, SW 개발 비용 증가, SW 품질 저하

SW 위기 해결 방안

  • 공학적 접근: 객체지향 방법론, CBD(Component Based Development), 프로젝트 관리 기법
  • 도구(자동화) 활용: CASE, Git
  • 표준화: Data 표준화, Reuse 체제 구축
  • 품질 보증 체제: ISO, CMMI, SPICE

4. SW 공학이란 무엇이며 S/W 공학의 구성요소와 원리에 대해 설명하시오.

정의

소프트웨어의 위기를 극복하기 위한 방안으로 연구한 학문 여러가지 방법론과 도구, 관리 기법들을 통하여 소프트웨어의 품질과 생산성 향상을 목적으로 한다. 과학적 지식(공학, 과학, 수학)을 이용하여 SW를 개발하는 방법론

구성요소

도구: SW 개발에 필요한 도구 언어: 기호, 단어, 문장, Diagram을 구성하는 규칙 기법 원리

SW공학 원리

정형성과 엄격, 관심사의 분리, 모듈화, 추상화, 변화예측, 일반화, 점진화

5. IEEE 산하 SW공학 표준 위원회에서 SW 공학의 근본 지식을 규정한 SWEBOK(Software Engineering Body of Knowledge)

6. SW산업 육성 전략에 대해 설명하시오

국내 SW 산업 육성 방안

R&D 기술 기반 구축, 최고 수준 인재 양성, SW 생태계 개선, 국제 협력 강화, 선택과 집중

SW 산업 육성을 위한 기업의 역할

기술혁신, 투자확대, 협력강화

7. Software 설계 원리 중 모듈화에 대해 설명하시오

개요

소프트웨어의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리 등을 위해 시스템의 기능들을 모듈 단위로 분해하는 것 시스템을 분해하고 추상화를 통해 S/W 제품 성능을 향상시키는 기법

결합도의 종류 (높->낮, 낮을수록 좋음)

내용 결합도: 한 모듈이 다른 모듈 내부 기능 및 그 내부 자료를 직접 참조 공유 결합도: 공통 데이터 영역 (Global 변수 등)을 여러 모듈이 공유 외부 결합도: 모듈이 외부 환경 (파일, DB, 디바이스 등)을 공유 제어 결합도: 모듈 간에 논리적인 흐름을 제어하기 위해 신호나 요소를 전달(flag, bool 등) 스탬프 결합도: 모듈 간에 구조체나 객체 전체를 전달 (일부 필드만 사용해서 데이터 과잉 전달) 자료 결합도: 모듈 간에 순수한 데이터만 전달 (필요한 정보만 명확히 전달)

응집도의 종류 (높->낮, 높을수록 좋음)

기능적: 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 때 순차적: 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동의 입력 데이터로 사용할 때 교환적: 동일한 입력과 출력을 사용하여 다른 기능을 수행하는 구성 요소들이 모였을 때 절차적: 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 때 (순서에 따라 수행되어야 하는 기능들을 묶음) 시간적: 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 때 논리적: 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈을 구성할 때 우연적: 모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성되어 있을 때

결합도와 응집도의 각 단계와 특징

8. Software 설계 원리에서 분할과 정복(Divide and Conquer) 에 대해 설명

개요

문제를 작은 단위로 나누어 해결하는 기법

9. 소프트웨어의 난독화(Obfuscation)에 대하여 설명하시오.

정의

소스코드, 바이너리 코드를 분석하기 어렵게 만드는 소프트웨어 보안 기법

필요성

역공학 방지, 해킹 방지, 국가 자산 보호

역공학이란

어셈블리언어를 디스어셈블러나 디컴파일러를 이용하여 원래 소스코드로 복원하는 과정

난독화 방안

NOP(No Operation) 삽입, 압축, 캡슐화, 암호화 *성능이 저하되거나 디버깅이 어려워질 수 있음

10. SW 재사용(Reuse)의 활용, 목적, 구현방법에 대해 설명하시오.

이미 개발되어 인정받은 소프트웨어를 다른 소프트웨어 개발이나 유지에 사용하는 것 소프트웨어 개발의 품질과 생산성을 높이기 위한 방법. 기존에 개발된 소프트웨어와 경험, 지식 등을 새로운 소프트웨어에 적용 개발관련 자산을 표준화하여 반복사용, 생산성을 향상시키고 품질을 높임

11. SW 관리를 위한 기준선(Baseline)에 대해 설명

소프트웨어 개발 및 관리 과정에서 특정 시점에 공식적으로 승인된 산출물의 스냅샷(고정본)을 의미. 기준선은 소프트웨어 변경을 통제하고 추적 가능하게 만드는 핵심 개념.

12. Module, Component, Service에 대해 각각 설명하고 비교

  • Module: 프로그램의 기능을 논리적으로 분리한 작은 코드 단위로, 재사용성과 유지보수성을 높이기 위한 단위. 일반적으로 하나의 파일이나 클래스, 또는 라이브러리 단위일 수 있음. (ex: Java의 패키지, C의 헤더 파일, Python의 .py 파일, Node.js의 CommonJS/ES6 모듈 등)
  • Component: 컴포넌트는 모듈보다 좀 더 큰 단위의 기능 블록으로, 독립적으로 배포, 업그레이드, 교체가 가능한 소프트웨어 단위. 일반적으로 GUI 컴포넌트, 백엔드 컴포넌트 등 특정 기능을 캡슐화함. (ex: React의 컴포넌트, Java의 EJB, Angular의 컴포넌트 등)
  • Service: 서비스는 특정 비즈니스 기능 또는 작업 단위를 제공하는 독립적인 실행 단위. 서비스는 컴포넌트보다도 높은 수준에서, 네트워크를 통해 호출 가능한 경우도 많다. (ex: 마이크로서비스)

13. 임베디드(Embedded) Software에 대해 설명하시오

개요

특정 기능을 수행하기 위해 하드웨어에 내장되어 동작하는 소프트웨어

특징

소형/경량, 하드웨어 의존성, 실시간성

패키지 소프트웨어 vs 임베디드 소프트웨어

패키지 소프트웨어는 범용 하드웨어에서 동작하는 반면, 임베디드 소프트웨어는 특정 하드웨어에 맞춰 설계됨

14. 역공학(Reverse Engineering)과 재공학(Reengineering) 에 대해 설명

역공학 vs 재공학

역공학은 기존 시스템을 분석하여 설계 및 구현을 이해하는 과정이며, 재공학은 기존 시스템을 개선하거나 새로운 시스템으로 변환하는 과정


PART 2. Software 개발 모형

15. SDLC(Software Development Life Cycle)에 대해 설명하시오

정의

소프트웨어를 개발하기 위한 설계, 운용, 유지보수 등의 과정을 각 단계별로 나눈 것 소프트웨어 개발을 위한 일련의 단계와 절차를 정의한 모델 (표준화된 프로세스)

SW 생명주기의 구성

요구사항 분석, 설계, 구현, 테스트, 배포, 유지보수

SW 생명주기 대표 모델

폭포수 모델, 프로토타입 모델(원형 모델), 나선형 모델, 진화형 모델(점증적 모델), Agile 모델 등

모델 선정 기준

규모와 성격, 시간과 비용, 방법과 도구, 개발 통제 수단과 산출물 인도

16. 폭포수(Waterfall) 모델에 대해 설명하시오

정의

이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론 (한 단계가 완전히 끝나야만 다음 단계로 넘어가는 개발 방법론) 하향식 단계별 개발 방식, 순차적 접근법

장점

관리(일정, 비용, 산출물)가 용이함 단계별 전체 진행 일정 예측 가능

단점

요구사항 변경에 유연하지 않음
초기 단계에서의 오류 발견이 어려움
후속 단계에서의 오류 수정 비용이 큼

17. 프로토타입(Prototype) 모델을 설명하시오

정의

사용자의 요구사항을 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품을 만들어 최종 결과물을 예측하는 모형 사전 프로토타입 모델을 제작하여 사용자의 피드백을 받아 요구사항을 명확히 하는 방법

절차

요구분석 -> (프로토타입 설계 -> 프로토타입 제작 -> 프로토타입 평가 -> 요구사항 수정) * n -> 요구사항 확정 -> 구현 -> 테스트

장점

사용자와의 의사소통이 용이해 요구사항을 명확히 할 수 있음
초기 단계에서의 오류 발견이 용이함

단점

프로토타입 제작에 시간과 비용이 소요됨
프로토타입이 완전한 시스템으로 오해될 수 있음

18. 나선형(Spiral) 모델에 대해 설명하시오

정의

나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 모형 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형 위험분석 중심의 반복적 개발 모델

절차

“계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객 평가” 의 4단계를 반복함

장점

정확한 요구사항 분석을 통해 위험부담 감소
품질확보가 용이함으로 대규모 시스템 개발에 적합

단점

개발 장기화, 비용 증가 가능성,
위험 관리 능력이 프로젝트 성공에 큰 영향을 미침
프로젝트 관리가 복잡함

19. 증분형(Incremental)과 진화형(Evolutionary) 모델에 대해 설명

정의

증분형: 요구사항 일부분 -> 제품 일부분 -> 반복개발 -> 최종 제품 완성 (병렬 개발이 가능)
진화형: 핵심 기능 개발 -> 각 구성요소 지속적 발전 -> 최종 제품 완성 (프로토타입을 만들고 점진적으로 발전시킴, 요구사항 변경에 유연함)

20. RAD(Rapid Application Development) 모형에 대해 설명하시오

2~3개월의 짧은 개발 주기 동안 SW를 개발하기위한 순차적인 프로세스 모델 (빠른 개발위한 툴과 기법을 사용) 정의 (빠른 개발을 위한 프로토타입 모델)

21. Clean Room 개발 모델의 3가지 Box구조에 대해 설명

Clean Room 의 정의

“결함 없는 소프트웨어 개발”을 목표로 하는 고신뢰성 중심의 개발 모델. 초기 단계부터 정확성을 검증하여, 결함을 사전에 제거하는 것을 목표로 하는 개발 모델

Blax Box 분석 기법

내부 동작은 알지 못하고, 외부에서 입력과 출력만을 분석하여 소프트웨어의 동작을 이해하는 기법

State Box 분석 기법

시스템 내부 상태와 상태 전이만을 분석하여 소프트웨어의 동작을 이해하는 기법

Clear Box 분석 기법 (White Box와 유사)

로직 기반 분석 기법으로, 소프트웨어의 내부 동작을 분석하여 소프트웨어의 동작을 이해하는 기법

22. SDLC 모델 선정기준과 각 모델의 상관관계에 대해 설명하시오

SDLC 모델 선정기준

요구사항의 명확성, 시스템의 규모, 개발팀의 경험, 프로젝트의 위험도, 개발 환경과 도구

SDLC 모델간의 상관관계

폭포수 모델 (요구사항 도출 어려움) -> 프로토타입모델 (반복적 개념 부족) -> 나선형 모델 (정형성 부족) -> 클린룸 모델

23. SDLC(Software Development Life Cycle)과정에서 구현 단계에서의 Action Item(Activity)과 일정 지연이 발생되었을 때 PM(Project Manager)입장에서의 대처방안에 대해 기술하시오.

-

24. SDLC 과정에서 필요한 Review, Inspection, Walkthrough에 대해 설명하시오

Review, Inspection, Walkthrough의 목적

Review: 요구사항 누락, 불일치, 불완전, 모호함등을 팀자하여 제거하는 검토회의
Inspection: 특정 주제에 대하여 세부적으로 검토하는 회의
Walkthrough: 요구사항명세서의 전반적인 면을 검토하는 회의

25. 전통적인 SW 개발 모델과 OSS(Open Source Software) 개발 모델의 차이점에 대해 설명

전통적인 SW 개발: 분석, 설계, 구현, 테스트, 배포의 과정을 순차적으로 접근 (폭포수 모델, 프로토타입 모델 등) OSS 개발: In-House 개발과는 달리, 공개된 소스코드를 기반으로 개발자들이 자발적으로 참여하여 소프트웨어를 개발하는 모델.


PART 3. Software 개발 방법론

26. SW 개발 방법론에 대해 설명하시오 (각 방법론에 대해 상세 비교 하시오)

SW개발 방법론?

소프트웨어 개발, 유지보수 등에 필요한 여러가지 일들의 수행 방법과 이러한 일들을 효율적으로 수행하려는 과정에서 필요한 각종 기법 및 도구를 체계적으로 정리하여 표준화한 것 소프트웨어 개발에 관한 정형화된 방법과 절차, 도구등이 공학적인 기법으로 체계화된 표준이론

SW개발 방법론의 진화

구조적기법 -> 정보공학 -> 객체지향 -> 컴포넌트 기반

SW개발 방법론의 구성요소 및 종류

작업절차, 작업방법, 산출물, 관리, 기법, 도구

개발방법론 비교

  • 구조적: 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리 중심의 방법론
  • 정보공학: 정보 시스템의 개발을 위해 계획, 분석, 설계, 구축에 정형화된 기법들을 상호 연관성 있게 통합 및 적용하는 자료 중심의 방법론
  • 객체지향: 현실 세계의 개체(Entity)를 기계의 부품처럼 하나의 객체(Object)로 만들어, 소프트웨어를 개발할 때 기계의 부품을 조립하듯이 객체들을 조립해서 필요한 소프트웨어를 구현하는 방법론
  • 컴포넌트 기반: 기존의 시스템이나 소프트웨어를 구성하는 컴포넌트를 조합하여 새로운 애플리케이션을 만드는 방법론

27. Agile 방법론에 대해 설명하시오.

정의

애자일은 ‘민첩한’, ‘기민한’이라는 의미로, 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형 절차보다는 사람이 중심이 되는 방식으로, 변화에 유연하고 신속하게 적응하면서 효율적으로 소프트웨어를 개발하는 방법론

특징

변화 적응, 사람 중심, 고객과의 협력, 지속적인 피드백, 짧은 개발 주기, 팀워크 강조

종류

스크럼(Scrum), XP(eXtreme Programming), 칸반(Kanban), Lean, 기능 중심 개발(FDD: Feature Driven Development)

4가지 핵심 가치

개인과 상호작용 (<-> 프로세스와 도구)
작동하는 소프트웨어 (<-> 방대한 문서)
고객과의 협업 (<-> 계약 협상)
변화에 적응 (<-> 계획을 따르기)

28. Agile 방법론의 정의, 특징, 장단점을 설명하시오

정의

절차보다는 사람이 중심이 되는 방식으로, 변화에 유연하고 신속하게 적응하면서 효율적으로 소프트웨어를 개발하는 방법론

특징

변화 적응, 사람 중심, 고객과의 협력, 지속적인 피드백, 짧은 개발 주기, 팀워크 강조

장단점

장점: ROI(Return On Investment, 투자대비효과) 극대화, 고객과의 협력으로 품질 향상, 팀워크와 의사소통 증진
단점: 문서화 부족, 요구사항 변경에 따른 업무량 증가, 감리 대응 어려움, 개발자의 피로감

29. 모바일 앱 개발의 특성과 이슈에 대해 설명하고, 애자일 기반 모바일 앱 개발 프로세스에 대해 설명

정의

모바일 앱 개발은 스마트폰, 태블릿 등 모바일 기기에서 실행되는 애플리케이션을 개발하는 과정

특징

다양한 플랫폼과 기기, 제한된 자원(메모리, 배터리 등), 사용자 경험(UX) 중시, 다양한 네트워크 환경

개발 이슈

플랫폼 호환성, 신규 OS와 기존 개발 환경의 호환성, 잦은 OS 업데이트, App 등록 기간 소요, test 환경 구축 어려움(기기 다양성)

30. TDD(Test Driven Development) 개발 방법론에 대해 설명하시오

정의

test를 먼저 작성하고, 그에 맞춰 테스트를 통과하는 코드를 작성, 리팩토링하며 진화시켜 나가는 개발 방법론

31. SPL(Software Product Line) 개발 방법론에 대해 설명

정의

SW 재사용을 극대화 방안, core asset을 미리 개발하여, 실제 개발 시점에 core asset을 조합하여 제품을 개발하는 방법론

32. XP(eXtreme Programming)에 대해 설명하시오

정의

수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법

특징

고객과의 협력, 짧은 개발 주기, 지속적인 피드백, 팀워크 강조

4가지 핵심 가치

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

12가지 실천 방법

Pair Programming, Test First Programming, Continuous Integration, Refactoring, Simple Design, Collective Code Ownership, Coding Standards, On-Site Customer, Sustainable Pace, 40-Hour Week, Metaphor, Planning Game

33. RUP(Rational Unified Process) 에 대해 설명하시오.

반복적이고 점진적인 개발 방법론

34. XP(eXtreme Programming) vs RUP(Rational Unified Process) 비교

구분RUPXP
개발 접근법반복적, 점진적반복적, 점진적
요구사항명확히 정의고객과의 피드백을 통해 유연하게 수정
문서화문서화 강조문서화 최소화
팀규모대규모 팀에 적합소규모 팀에 적합
프로세스엄격한 단계와 절차유연하고 단순한 접근

35. Scrum 개발 방법론에 대해 설명

개요

팀이 중심이 되어 개발의 효율성을 높이는 기법 Agile 방법론의 일종으로, 팀원 간의 협업과 의사소통을 통해 소프트웨어를 개발하는 방법론

구성 및 역할

제품 책임자(PO), 스크럼 마스터(SM), 개발팀(DT)

스크럼 프로세스

스프린트 계획 회의 -> 스프린트 -> Daily Scrum -> Sprint Review -> Sprint Retrospective (회고)

특징

짧은 개발 주기(Sprint), 스크럼 미팅, 역할 분담(스크럼 마스터, 제품 책임자, 팀원), 백로그 관리, 지속적인 피드백 스프린트 회고, 스프린트 리뷰 스프린트 계획 회의, Daily Scrum

36. MDD(Model Driven Development) 방법에 대해 설명하시오.

시스템의 설계와 구현을 모델을 통해 추상화하고, 그 모델로부터 자동으로 코드를 생성하는 것을 목표으로 하는 개발 방법론

37. MDA(Model Driven Architecture) 방법에 대해 설명하시오.

모델 중심 아키텍처로, MDD의 발전된 형태. 소프트웨어 아키텍처와 모델링을 강조하는 방법론으로, 모델을 사용해 애플리케이션 아키텍처를 설계하고, 자동으로 다양한 플랫폼에 맞는 코드를 생성하는 것을 목표로 함.
MDA는 모델을 플랫폼 독립적인 형식으로 정의하고, 이 모델에서 플랫폼 특화된 코드로 변환하는 방식.

38. DevOps (Development + Operations) 개발 방법론에 대해 설명하시오.

개발과 운영을 통합하여 소프트웨어 개발과 운영의 효율성을 높이는 방법론

39. Kanban SW 개발 방법론에 대해 설명하시오. (스크럼과 비교하시오)

작업을 시각화하고, 진행 상태를 추적하며, 팀의 작업 흐름을 최적화하는 데 초점을 맞추는 프로세스 관리 기법

vs Scrum

작업 흐름:
칸반은 지속적인 작업 흐름에 초점을 맞추며, 각 작업 항목을 시각적으로 추적. 작업 항목이 끝날 때마다 새로운 작업을 시작함.
스크럼은 스프린트라는 고정된 주기 내에서 작업을 끝내는 것을 목표로 하고, 그 안에서 계획과 실행을 반복함.

유연성:
칸반은 작업 항목을 계속 추가할 수 있어 변화에 빠르게 대응할 수 있다.
스크럼은 정해진 기간 동안 작업을 끝내는 고정된 스프린트가 있으므로, 변화에 대응하기 위한 재조정이 필요할 수 있다.

팀 회의:
칸반은 정기적인 회의가 없고, 필요 시 회고와 개선이 이루어진다.
스크럼은 다양한 정기 회의(일일 스크럼, 스프린트 계획 회의 등)를 통해 팀의 진척 상황을 공유하고 피드백을 받는다.

40. CASE(Computer Aided Software Engineering)에 대해 설명하시오

개요

소프트웨어 개발의 모든 과정—요구 사항 분석, 설계, 개발, 테스트, 유지 보수 등을 지원하고 자동화하는 도구들을 통칭하는 개념

목적

생산성 향상, 품질 향상, 유지 보수 용이성, 문서화 자동화

Case의 유형

Upper CASE: 요구사항 분석, 설계 단계에서 사용되는 도구들 (ex: UML, DFD, ERD 작업 도구) Lower CASE: 구현, 테스트, 유지 보수 단계에서 사용되는 도구들 (ex: IDE, 디버거, 테스트 도구) Integrated CASE: 상기 모든 단계를 지원하는 도구들 (ex: Eclipse, Visual Studio (종합 개발 환경))

41. 린(Lean) SW 개발 방법론에 대해 설명하시오

효율성과 가치 창출에 중점을 두고 불필요한 낭비를 최소화하며 소프트웨어 개발을 최적화하려는 접근 방식 (필요한 것만 만들고, 필요한 만큼만 만드는 것)


PART 4. UML(Unified Modeling Language)

42. Modeling을 정의하고 목적과 Software에서 Modeling이 필요한 이유에 대해 설명하시오

Model의 정의

현실의 단순화 및 가시화를 통해 개발 시스템의 계획/구상을 표현한 것

Modeling의 정의

Model을 만드는 모든 과정으로, 시스템의 구조와 동작을 시각적으로 표현하는 것

Modeling의 목적

복잡한 시스템을 이해하고 설계하는 데 도움을 줌 시스템의 구조와 동작을 명확히 이해하고, 의사소통을 원활하게 하며, 문서화하여 유지보수와 확장을 용이하게 함

43. UML(Unified Modeling Language)에 대해 정의하고 특징과 개발방법론과의 관계를 설명하시오.

개요

시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어

구성요소

사물(Things), 관계(Relationships), 다이어그램(Diagrams)

특징

플랫폼 독립적, 다양한 다이어그램 제공, 객체지향 개념을 기반으로 함 다양한 이해 당사자(개발자, 분석가, 관리자 등) 간의 의사소통을 지원함 시스템의 구조와 동작을 명확히 표현할 수 있음 표준화된 기법으로, 다양한 도구와 호환성이 높음 UML은 객체지향 개발 방법론과 밀접한 관계가 있으며, 객체지향 설계 및 분석을 지원하는 데 유용함 UML은 다양한 개발 방법론과 함께 사용될 수 있으며, 특히 객체지향 방법론과의 관계가 깊음 UML은 객체지향 설계 및 분석을 지원하는 데 유용함

개발 방법론과의 관계

UML은 객체지향 개발 방법론과 밀접한 관계가 있으며, 객체지향 설계 및 분석을 지원하는 데 유용함

44. SW공학에서 모델링의 개념과 UML이 필요한 이필

모델링의 개념

시스템의 구조와 동작을 시각적으로 표현하는 과정으로, 복잡한 시스템을 이해하고 설계하는 데 도움을 줌

UML이 필요한 이유

시스템의 구조와 동작을 명확히 이해하고, 의사소통을 원활하게 하며, 문서화하여 유지보수와 확장을 용이하게 함

45. UML(Unified Modeling Language)에 대해 설명하시오 (구성요소에 대해 상세히 설명하시오)

시스템 개발 과정에서 상호(고객과 개발자 또는 개발자 간)에 의사소통이 원할하게 이루어지도록 표준화된 대표적인 객체지향 모델링 언어 UML의 구성요소: 사물, 관계, 다이어그램

사물의 종류 (사물: 다이어그램 안에서 관계가 형성될 수 있는 대상)

다이어그램 안에서 관계가 형성될 수 있는 대상, 모델을 구성하는 기본 요소

  • 구조 사물(Structure Things), 행동 사물(Behavioral Things), 그룹 사물(Grouping Things), 주해 사물(Annotation Things)

관계의 종류 (관계: 사물과 사물 사이의 연관성)

사물과 사물 사이의 연관성을 표현하는 것

  • 연관(Association), 집합(Aggregation), 포함(Composition), 일반화(Generalization), 의존(Dependency), 실체화(Realization)

다이어그램의 종류

UML에서 시스템을 표현하기 위해 사용하는 다양한 시각적 표현

  • 구조 다이어그램(Structure Diagrams): 시스템의 정적 구조를 표현 (ex: 클래스 다이어그램, 컴포넌트 다이어그램, 패키지 다이어그램 등)
  • 행동 다이어그램(Behavioral Diagrams): 시스템의 동적 행동을 표현 (ex: 유스케이스 다이어그램, 활동 다ㅣㅇ어그램, 시퀀스 다이어그램, 커뮤니케이션 다이어그램, 상태 다이어그램 등)

46. UML의의 각 구성요소들에 대해 세부적으로 설명하시오

사물의 세부내용

다이어그램 안에서 관계가 형성될 수 있는 대상, 모델을 구성하는 기본 요소

  • 구조 사물(Structure Things): 시스템의 개념적 물리적 요소를 표현 (ex: 클래스, 유스케이스, 컴포넌트, 노드 등)
  • 행동 사물(Behavioral Things): 시간과 공간에 따른 요소들의 행위를 표현 (ex: 상호작용(Interaction), 상태머신(State Machine) 등)
  • 그룹 사물(Grouping Things): 요소들을 그룹으로 묶어서 표현 (ex: 패키지(Package))
  • 주해 사물(Annotation Things): 부가적인 설명이나 제약조건 등을 표현 (ex: 노트(Note))

관계의 세부내용

사물과 사물 사이의 연관성을 표현하는 것

  • 연관(Association): 2개 이상의 사물 간의 관계를 표현, 실선으로 연결 (방향성을 화살표로 표현하되, 양방향일 경우 화살표를 생략, 다중도를 선위에 표기)
  • 집합(Aggergation): 하나의 사물이 다른 사물에 포함되어 있는 관계 (서로 독립적), 빈 마름모로 표현
  • 포함(Composition): 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계, 채워진 마름모로 표현
  • 일반화(Generalization): 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계, 빈 삼각형으로 표현
  • 의존(Dependency): 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계, 점선 화살표로 표현 (영향을 주는 쪽으로 화살표를 그린다)
  • 실체화(Realization): 인터페이스와 구현 클래스 간의 관계, 점선 + 빈 삼각형으로 표현 (인터페이스 쪽에 빈 삼각형을 그린다)

다이어그램의 세부내용

사물의 관계를 도형으로 표현한 것

구조적(Structure) 다이어그램

  • 클래스 다이어그램(Class Diagram): 클래스와 클래스가 가지는 속성, 클래스 간의 관계를 표현
  • 객체 다이어그램(Object Diagram): 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현
  • 컴포넌트 다이어그램(Component Diagram): 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현
  • 배치 다이어그램(Deployment Diagram): 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현
  • 복합 다이어그램(Composite Structure Diagram): 클래스나 컴포넌트가 복합 구조를 가질 때, 그 내부 구조를 표현

행위(Behavior) 다이어그램

  • 유스케이스 다이어그램(Use Case Diagram): 시스템의 요구를 분석하는 것으로, 기능 모델링 작업에 사용함
  • 시퀀스 다이어그램(Sequence Diagram): 상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현
  • 커뮤니케이션 다이어그램(Communication Diagram): 동작에 참여하는 객체들이 주고받는 메시지와 객체들 간의 연관 관계를 표현
  • 상태 다이어그램(State Diagram): 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현
  • 활동 다이어그램(Activity Diagram): 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현

47. 모델링과 프로그래밍을 비교하고 개발과정에서 사용되는 UML Diagram의 종류를 나열하시오.

모델링은 시스템의 구조와 동작을 시각적으로 표현하는 과정으로, 복잡한 시스템을 이해하고 설계하는 데 도움을 줌 프로그래밍은 모델링을 바탕으로 실제 코드를 작성하여 시스템을 구현하는 과정

48. UML의 4+1 모형과 각 요소에 대해 상세히 설명하시오

4+1 모형

고객의 요구사항을 중심으로 분석가/설계자, 프로그래머, 시스템 통합자, 시스템 엔지니어 관점에서 sw아키텍처를 구축하는 설계방법
모델링 대상인 아키텍처를 여러관점(view)에서 표현하기 위한 UML다이어그램 표현 기술 SDLC 각 단계별 적용가능한 Diagram 배치 기술

Use Case View (사용자 관점, SDLC 전 과정에 적용)

4가지 관점에 사용되는 다이어 그램의 근간을 이루는 관점으로 분석과 및 설계의 전과정에 사용, 요구 사항 분석을 통한 시스템 기능 명세
정적표현: 유스케이스 다이어그램 / 동적표현: 상태, 시퀀스, 액티비티 다이어그램 등

Logical / Design View (분석가, 설계자 관점 - 클래스나 컴포넌트의 종류와 관계)

시스템 내부를 들여보는 것으로 시스템 기능의 제공하기 위해 필요한 클래스와 컴포넌트의 종류 이들의 상호작용 관계에 초점을 둔 설계가 관점로 전체적인 구성 측면
정적표현: 클래스 다이어그램, 객체 다이어그램 / 동적표현: 상태, 시퀀스, 액티비티 다이어그램 등

Implementation View (개발자 관점 - 서브시스템의 모듈 구조와 관계)

물리적 시스템에서 사용하는 소프트웨어 서브시스템의 모듈(원시코드, 데이터 파일, 컴포넌트, 실행파일등)이 어떻게 구조화되어 구현되는지 관점, 즉 모듈간의 의존관계를 구현
정적표현: 컴포넌트 다이어그램, 패키지 다이어그램 / 동적표현: 상태, 시퀀스, 액티비티 다이어그램 등

Process View (시스템 통합자 관점 - 시스템의 성능, 확장성, 효율성)

실제 구동 환경을 살펴봄으로써 논리적 관점과 시스템 내부 구조 즉 클래스 간의 관계, 클래스의 행동, 클래스간의 상호작용 등을 중점으로 보는 관점, 모든 클래스가 아닌 독자적인 스레드를 가지고 있는 클래스에 초점
동적표현: 상태, 시퀀스, 액티비티 다이어그램 등

Deployment View (시스템 엔지니어 관점 - 시스템의 구성)

시스템을 구성하는 처리장치간의 물리적 배치에 초점을 둔 관점 / 물리적 노드 프로세스의 분산 및 배치 상태를 나타냄 ​/ 시스템의 동시성과 동기화에 관심
정적표현: 배치 다이어그램 / 동적표현: 상태, 시퀀스, 액티비티 다이어그램 등

참조: [https://m.blog.naver.com/kji9653/222021554040]

49. 4+1 모형이 SDLC(Software Development Life Cycle) 과정에 어떻게 적용되는지 설명하시오

50. UML에서 관계표시는 4가지(연관, 의존, 집합, 일반화, 실체화)로 표시된다. 각각 설명하고 실생활에서 사용되는 예를 Notation하여 설명하시오. (집합연관과 합성연관도 설명하시오)

-

51. 다음의 Class Diagram을 자바 Code로 작성하고 정보은닉에 사용된 접근제어자에 대해 설명하시오

접근 제어자UML 기호의미 (Java 기준)
public+어디서나 접근 가능
private-해당 클래스 내부에서만 접근 가능
protected#같은 패키지 또는 서브클래스에서 접근 가능
(package)~같은 패키지에서만 접근 가능 (default)

52. Class Diagram -> Java Code 변환 문제

-

53. Sequence Diagram -> Java Code 변환 문제

정의

시스템이나 객체들이 메시지를 주고받으며 상호 작용하는 과정을 그림으로 표현한 것

-

54. 시퀀스 다이어그램 그리기

-

55. 클래스 다이어그램 그리기

-

56. UML2.0에 대해 설명하시오 (4계층 구조와 4가지 영역에 대해)

UML 2.0은 UML의 최신 버전으로, UML 1.x에서의 문제점을 보완하고 새로운 기능을 추가한 버전

구분4계층 구조4가지 구성 영역
목적메타모델 계층 구조 이해UML 정의 및 구현의 구성 요소 분류
항목M3, M2, M1, M0하부구조, 상부구조, OCL, Diagram Interchange

4계층 구조

  • M3: UML이라는 문법 자체 (예: “클래스란 이런 걸 뜻해”)
  • M2: 클래스, 속성, 연관 등 UML 요소 정의
  • M1: User, Order 같은 실제 클래스 다이어그램
  • M0: user1:User, order1:Order 같은 실제 인스턴스

4가지 구성 영역

  • 다이어그램 호환: CASE 도구 벤더들 간의 모델 호환을 위한 정의
  • OCL: 모델요소에서 제어와 제약을 위한 간략한 규약을 정의, 특정 도메인에 대한 제한을 명시화하기 위해 사용됨
  • 하부구조: 메타모델을 정의하는데 활용될 수 있는 메타언어 규약
  • 상부구조: 메타모델을 정의하는데 활용될 수 있는 메타언어 규약

참조: [http://jidum.com/jidums/view.do?jidumId=961]

57. -

58. Java -> Class Diagram 변환 문제

59. UML 의 확장 메커니즘에 대해 설명하시오 (Stereotype 사용예를 드시오)

60. UML의 스테레오 타입을 Java로 코딩하기, 자주 사용되는 스테레오 타입을 설명하시오

«interface»: 인터페이스를 정의할 때 사용 «include»: 유스케이스 다이어그램에서 포함 관계를 정의할 때 사용 «extend»: 유스케이스 다이어그램에서 확장 관계를 정의할 때 사용 «entity», «control», «boundary»: MVC 패턴에서 사용되는 스테레오 타입

61. State Machine Diagram에 대해 설명하시오

62. UML 연관(Association) 관계와 방향성이 있는 연관(Directed Association) 에 대해 설명하시오

63. UML 일반화 관계에 대해 예시와 함께 설명하시오

정의

하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계

64. UML 실제화 관계에 대해 예시와 함께 설명하시오

정의

인터페이스와 구현 클래스 간의 관계로, 인터페이스를 구현하는 클래스를 정의하는 것 사물이 할 수 있거나 해야 하는 기능으로, 서로를 그룹화 할 수 있는 관계

65. UML 의존 관계에 대해 예시와 함께 설명하시오

정의

연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계


PART 5. 디자인 패턴(Design Pattern)

66. 디자인 패턴(Design Pattern)에 대해 설명하시오

개요

모듈 간의 관계 및 인터페이스를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제

유형

생성패턴, 구조패턴, 행위패턴으로 나눌 수 있음

적용지침

객체지향 설계 5대 원칙(SOLID)을 준수: 개방폐쇄(OCP), 인터페이스 분리(ISP), 의존성 역전(DIP), 리스코프 치환(LSP), 단일 책임(SRP) - Open Closed Principle, Interface Segregation Principle, Dependency Inversion Principle, Liskov Substitution Principle, Single Responsibility Principle 결합도 최소, 상속보다는 위임, 인터페이스를 기준으로 사용

67. 디자인 패턴의 종류를 기술하고 각 패턴의 간단한 설명과 활용 예를 제시하시오

생성패턴

클래스나 객체의 생성과 참조 과정을 정의하는 패턴 추상 팩토리, 빌더, 팩토리 메소드, 프로토타입, 싱글톤

구조패턴

클래스나 객체를 조합하여 더 큰 구조로 만드는 패턴 어댑터, 브리지, 컴포지트, 데코레이터, 파싸드, 플라이웨이트, 프록시

행위패턴

클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴 책임 연쇄, 커맨드, 인터프리터, 반복자, 중재자, 메멘토, 옵서버, 상태, 전략, 템플릿 메소드, 방문자

68. Prototype 패턴에 대해 설명하시오

원본 객체를 복제하는 방법으로 새로운 객체를 생성하는 패턴

  • 개념, class diagram, 예시

69. Singleton 패턴에 대해 설명하시오

  • 개념, class diagram, 예시

70. 객체 지향 개념에서 추상화(Abstract)에 대해 정의하고 추상 Class로 Code 구현한 후 설명하시오.

  • 추상화의 정의
  • 구체화의 정의
  • 추상 class 사용한 코드 작성

71. Abstract Factory 패턴에 대해 설명하고 아래 코드를 Class Diagram으로 표현한 후 Abstract Factory 패턴을 사용해 코딩하시오.

개념

구체적인 클래스에 의존하지 않고, 인터페이스를 통해 서로 연관-의존하는 객체들의 그룹으로 생성하여 추상적으로 표현하는 패턴

  • 개념, class diagram, 예시

72. Iterator 패턴에 대해 설명하고 Java에 적용된 예제를 기술하시오.

개념

자료 구조와 같이 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴

  • 개념, 예시

73. Iterator 패턴을 사용해 Factory Method 패턴을 구현하시오

-

74. 아래 Class Diagram에서 Textview class를 Adapter 패턴을 사용해 구현하시오

-


PART 6. 객체 지향 언어

75. 객체지향 개념과 구성요소, 객체, 클래스, 메시지, 속성에 대해 각각 설명하시오

개념

소프트웨어의 각 요소들을 객체(Object)로 만든 후, 객체들을 조립해서 소프트웨어를 개발하는 기법

구성요소

객체(Object), 클래스(Class), 메시지(Message)

특징

캡슐화(Encapsulation), 상속(Inheritance), 다형성(Polymorphism), 연관성(Relationship)

객체(Object), 클래스(Class), 기능(Method, Message), 속성(Attribute)의 개념

  • 객체(Object): 데이터와 이를 처리하기 위한 함수를 묶어놓은 소프트웨어 모듈
  • 클래스(Class): 공통된 속성과 연산을 갖는 객체의 집합
  • 메시지(Message): 객체들 간의 상호작용에 사용되는 수단으로, 객체의 동작이나 연산을 일으키는 외부의 요구사항
  • 속성(Attribute): class가 가지는 속성

76. 상속 (Inheritance)에 대한 정의하고 상속방법과 실제 Code로 구현하여 설명하시오.

정의

상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것

상속 방법

-

77. 추상화 (Abstraction)에 대해 정의하고 예를 들어 설명하시오.

정의

현실 세계의 복잡한 사물이나 개념에서 속성과 기능을 추출하여 코드로 표현하는 것 방법론적 관점에서의 추상화: 포괄적인 개념을 설계한 후 차랴로 세분화하여 구체화시켜 나가는 것)

78. JAVA 언어

특징

객체지향 언어, 플랫폼 독립적, 메모리 관리 자동화, 멀티스레드 지원, 강력한 보안 기능 제공

79. JAVA 주요 구현 분야와 개발 환경에 대해 설명하시오

주요 구현 분야

  • APP 개발: Swing, AWT
  • 웹 개발: Servlet, Applet, JSP
  • 컴보넌트 개발: EJB
  • 미들웨어: WSA, Tomcat

개발 환경

J2SE, J2EE, J2ME 등

80. Java 언어의 특징과 Java 프로그램 실행 순서를 설명하시오

Java 언어의 특징

객체지향 언어, 플랫폼 독립적, 메모리 관리 자동화, 멀티스레드 지원, 강력한 보안 기능 제공

Java 프로그램의 실행순서

Java 소스코드(.java) -> 컴파일러에 의해 바이트코드(.class)로 변환 -> JVM(Java Virtual Machine)에 의해 실행

81. JVM(Java Virtual Machine) 구조에 대해 설명하시오

정의

Java 프로그램을 실행하기 위한 가상 머신으로, Java 바이트코드를 실행하는 환경을 제공 (Java Runtime Environment, JRE)

구성 요소

Class Loader(클래스로더), Runtime Data Areas(메모리 영역), Execution Engine(실행 엔진), Native Method Interface(JNI), Native Method Libraries

클래서로더

Java 바이트코드를 메모리에 로드하고, 클래스의 링크(Linking) 작업을 수행하는 부분

메모리 영역

메소드 영역(Method Area), 힙(Heap), 스택(Stack), PC 레지스터(Program Counter Register), 네이티브 메소드 스택(Native Method Stack) 등으로 구성됨 | 영역 | 설명 | |—|—| | Method Area | 클래스 정보, 메서드 코드 등이 저장됨. 모든 쓰레드 공유. | | Heap Area | 객체 인스턴스가 저장되는 공간. GC(가비지 컬렉션) 대상. 모든 쓰레드 공유. | | Stack | 매개변수, 지역 변수, 임시 데이터 저장. 각 쓰레드마다 존재. 메서드 호출 시마다 프레임 생성. | | PC Register | JVM이 현재 수행할 명령어의 주소를 저장. | | Native Method Stack | 자바가 아닌 네이티브(C/C++) 메서드 호출 시 사용되는 스택. |

실행 엔진

Java 바이트코드를 실행하는 부분으로, 인터프리터(Interpreter)와 JIT(Just-In-Time) 컴파일러로 구성됨

  • 인터프리터: 바이트코드를 한 줄씩 읽어 실행하는 방식으로, 빠른 실행 속도를 제공
  • JIT 컴파일러: 자주 사용되는 바이트코드를 미리 컴파일하여 기계어로 변환 후 실행하는 방식으로, 성능을 향상시킴

JNI

Java Native Interface로, Java와 네이티브 코드(C/C++) 간의 상호작용을 위한 인터페이스 Java에서 네이티브 메서드를 호출하거나, 네이티브 라이브러리를 사용할 수 있도록 지원

Native Method Libraries

네이티브 메서드가 사용하는 라이브러리로, C/C++로 작성된 코드와 Java 간의 상호작용을 지원 Java Native Interface(JNI)를 통해 Java와 네이티브 메서드 간의 상호작용을 지원

82. API(Application Programming Interface)와 JAPI(Java API)에 대해 설명하시오

  • API 정의, 특징
  • JAPI 정의, 특징
  • JAPI의 종류

83. 객체지향 설계원칙에 대해 설명하시오 (실 생활의 예시를 드시오)

SRP, OCP, LSP, ISP, DIP

84. 객체지향 언어의 특징과 설계원칙을 기술하고, 구조적 기법과 차별화되는 개념을 설명하시오. 또한, private, public 접근 제어자를 사용하여 외부로부터 데이터를 보호하기 위한 정보 은닉 방법을 실제 객체 지향 언어로 구현하시오.

특징

캡슐화, 상속성, 다형성, 연관성

설계원칙

SRP, OCP, LSP, ISP, DIP

vs 구조적 프로그래밍

구조적 프로그래밍은 절차적 프로그래밍의 일종으로, 프로그램을 함수와 데이터로 나누어 모듈화하여 작성하는 방식 객체지향 프로그래밍은 객체를 중심으로 프로그램을 구성하고, 객체 간의 상호작용을 통해 동작하는 방식 구조적 프로그래밍은 함수와 데이터의 분리를 강조하는 반면, 객체지향 프로그래밍은 객체와 클래스의 개념을 중심으로 설계됨 구조적 프로그래밍은 절차적 흐름을 중시하는 반면, 객체지향 프로그래밍은 객체 간의 상호작용과 메시지 전달을 중시함 | 구분 | 구조적 프로그래밍 | 객체지향 프로그래밍 | |—|—|—| | 중심 | 함수, 절차 | 객체, 클래스 | | 강점 | 단순함, 직관적인 흐름 | 유지보수, 확장성, 재사용성 | | 단점 | 유지보수 어려움, 코드 중복 가능성 | 복잡도 증가 가능성, 설계 필요 |

접근제어자

접근 제어자설명
public클래스 외부에서 접근 가능
private클래스 내부에서만 접근 가능
protected같은 패키지 또는 서브클래스에서 접근 가능
(default)같은 패키지에서만 접근 가능

85. 객체지향언어의 특징에 대해 설명하시오

캡슐화: 외부에서의 접근을 제한하기 위해 인터페이스를 제외한 세부 내용을 은닉하는 것
상속성: 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것
다형성: 하나의 메시지에 대해 각각의 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 것
연관성: 두개 이상의 객체들이 상호 참조하는 관계를 가지는 것

86. 객체지향 언어에서 오버라이딩과 오버로딩에 대해 예를 들어 설명하시오

오버라이딩(Overriding)

상위 클래스에서 정의된 메서드를 하위 클래스에서 재정의하는 것

오버로딩(Overloading)

같은 이름의 메서드를 매개변수의 타입이나 개수에 따라 다르게 정의하는 것

87. -

88. Static Linking과 Dynamic Linking에 대해 설명하시오

Static Linking

컴파일 시 필요한 라이브러리의 코드가 실행 파일에 직접 포함됨, 실행 파일 하나만 있으면 다른 의존성 없이 실행 가능. (장점: 실행 속도 빠름, 단점: 파일 크기 증가)

Dynamic Linking

실행 파일에는 라이브러리의 참조 정보만 포함되고, 실제 라이브러리는 프로그램 실행 시 또는 런타임 중에 로딩됨. (장점: 파일 크기 작음, 단점: 실행 속도 느림)

###j 89. AOP(Aspect Oriented Programming)기법에 대해 설명하시오

요구사항에 대해 핵심 기능과 부가 기능을 분리하여 개발함으로써 모듈화를 극대화하는 프로그래밍 기법 (로깅, 보안, 트랜잭션 처리 등과 같은 공통적인 기능을 모듈화하여 코드의 중복을 줄이고 유지보수를 용이하게 함)


7. 아케텍처 스타일

90. IEEE 1471

  • 개요

91. MVC(Model-View-Controller) 아키텍처 스타일에 대해 설명하시오

개요

서브시스템을 모델, 뷰, 컨트롤러로 구조화하는 패턴

MVC vs MVVM vs MVP

MVC: 모델과 뷰 간의 상호작용을 컨트롤러가 담당, 사용자 인터페이스와 비즈니스 로직을 분리 MVVM: 모델과 뷰 간의 상호작용을 뷰모델이 담당, 데이터 바인딩을 통해 모델과 뷰를 연결하여 상호작용을 처리 MVP: 모델과 뷰 간의 상호작용을 프레젠터가 담당, 뷰는 프레젠터에 의존하고, 프레젠터는 모델에 의존하여 상호작용을 처리

92. 저장소(Repository) 아키텍처

개요

93. 계층형 (Layered) 아키텍처

개요

시스템을 계층으로 구분하여 구성하는 고전적인 방법, 서로 마주보는 두 개의 계층 사이에서만 상호작용 OSI 7 Layer, TCP/IP 4 Layer

94. 파이프 필터 (Pipe and Filter) 아키텍처

개요

데이터 스트림 절차의 각 단계를 필터로 캡슐화하여 파이프를 통해 전송하는 패턴 unix shell의 파이프 필터

95. PHP(Personal Home Page, Hypertext pre-processor)의 개요와 동작원리, 특징, 유사 프로그램(ASP, JSP)과 비교하시오

  • 개요
  • 동작원리
  • 특징
  • vs ASP, JSP

96. P2P(Peer to Peer)

개요

피터(Peer)라 불리는 하나의 컴포넌트가 클라이언트가 될수도, 서버가 될수도 있는 패턴 파일 공유 네트워크

97. P2P(Peer to Peer) System의 운영 형태에 따라 Pure P2P, Super P2P, Hybrid P2P로 분료할 수 있다. 각각에 대해 설명하고 장단점을 기술하시오.

98. -


PART 8. OSS(Open Source Software)와 License의 종류

99. OSS(Open Source Software)의 장/단점에 대해 설명하시오

장점

저비용, Agility 개발, 신뢰도 & 안정성, 네트워킹

단점

지적 재산권, UI/UX, Killer App 부족, 문서 부족, Issue 해결

100. OSS(Open Source Software) 개발 process와 특징에 대해 설명하시오

101. OSS(Open Source Software)에서 Hidden Patent에 대해 설명하시오

102. IP(Intellectual Property) Rights에 대해 설명하시오

103. Open API에 대해 설명하시오

104. Apache License 2.0

105. OSS License에서 LGPL 2.1

106. BSD(Berkeley Software Distribution) License

107. Free Software와 Open Software에 대해 설명하고 Open Source Software의 지적 재산권과 License에 대해 설명하시오

108.


PART 9. Project Management

109. PMBOK의 5단계 Project 관리 프로세스

110. PMBOK에서 제시하는 10개 관리 활동영역

111. Project와 Program, Portfolio

112. Project 생명주기에 따른 관리 업무의 제약사항

PART 10. Process와 Product 검증에 대한 국제 표제

PART 11. 품질관리

PART 12. 기성고 관리

This post is licensed under CC BY 4.0 by the author.