[정보처리기사 필기] 제1과목: 소프트웨어 설계 | 요람일지

1. 소프트웨어 개발 방법론 ⭐⭐

01. 개발 모델의 종류

폭포수 모형: 각 단계를 확실히 매듭짓고 다음으로 넘어가는 선형 순차적 모델입니다. 결과물 중심의 엄격한 관리가 가능하지만, 요구사항 변경이 어렵습니다.

나선형 모형: 계획 → 위험 분석 → 개발 → 고객 평가의 과정을 반복하며 점진적으로 개발합니다. 위험 분석 단계가 존재한다는 것이 핵심입니다.

애자일 모형: 고객과의 소통과 변화에 대한 유연한 대응을 중시하는 방법론입니다. (XP, Kanban, Scrum 등)

02. XP (Extreme Programming) 5가지 핵심 가치

암기팁: 용·단·의·피·존

용기: 고객의 요구사항 변화에 능동적으로 대응합니다.

단순성: 필요한 설계만 수행하여 복잡성을 최소화합니다.

의사소통: 개발자, 고객, 팀원 간의 원활한 소통을 강조합니다.

피드백: 지속적인 테스트와 리뷰로 잘못된 부분을 바로잡습니다.

존중: 모든 팀원의 기여를 존중합니다.

2. 요구사항 확인 ⭐⭐⭐

01. 요구사항의 유형

기능 요구사항: 시스템이 무엇(What)을 해야 하는지 정의합니다. (기능, 입력, 출력, 저장 등)

비기능 요구사항: 시스템의 품질(Quality)이나 제약사항을 정의합니다. (성능, 보안, 가용성, 신뢰성 등)

02. 요구사항 개발 프로세스

도출: 인터뷰, 설문, 브레인스토밍 등을 통해 요구 수집

분석: 요구사항의 타당성 조사 및 DFD, DD 활용

명세: 요구사항 명세서 작성 (정형/비정형)

확인: 검증 및 승인 단계

03. 요구사항 검토 기법

Inspection: 전문가 팀이 검사하는 가장 공식적인 검토 절차

Walkthrough: 회의 전 자료 배포 후 비형식적으로 결함 발견

Peer Review: 작성자가 설명하고 동료들이 결함 발견

3. UML (Unified Modeling Language) ⭐⭐⭐⭐⭐

UML은 시스템의 구조와 행위를 시각화하는 표준 모델링 언어입니다.

01. 관계 (Relationship)

Generalization: 실선 + 비어있는 화살표 (──▷) | 상속 관계

Realization: 점선 + 비어있는 화살표 (╌╌▷) | 인터페이스 구현

Dependency: 점선 + 화살표 (╌╌>) | 일시적 참조 관계

Association: 실선 (──) | 구조적 관계

Aggregation: 실선 + 비어있는 마름모 (──◇) | 전체와 부분 (독립적)

Composition: 실선 + 채워진 마름모 (──◆) | 전체와 부분 (강한 결합)

02. 구조적 다이어그램 (Structural Diagram) ⭐⭐⭐

시스템의 정적인 구조와 구성 요소 간의 관계를 표현합니다. 주로 설계 단계에서 시스템의 골격을 정의할 때 사용합니다.

클래스 다이어그램 (Class Diagram): 시스템 내 클래스들의 속성, 메서드 및 그들 사이의 관계를 표현합니다. (가장 많이 사용됨)

객체 다이어그램 (Object Diagram): 특정 시점에 존재하는 객체들과 그들 사이의 관계를 스냅샷 형태로 표현합니다. (럼바우 객체 모델링에서 중요)

컴포넌트 다이어그램 (Component Diagram): 소프트웨어의 물리적인 구성 요소(소스 코드, 라이브러리 등)와 그들 간의 의존 관계를 표현합니다.

배치 다이어그램 (Deployment Diagram): 하드웨어 자원(노드)과 그곳에 배치되는 소프트웨어 컴포넌트의 물리적 위치를 표현합니다.

복합체 구조 다이어그램 (Composite Structure Diagram): 클래스나 컴포넌트 내부의 복잡한 구조와 내부 객체 간의 협력 관계를 표현합니다.

패키지 다이어그램 (Package Diagram): 모델 요소들을 그룹화한 패키지 간의 의존 관계를 표현합니다. (폴더 구조와 유사)

03. 행위적 다이어그램 (Behavioral Diagram) ⭐⭐⭐

시스템의 동적인 행위와 객체 간의 상호작용, 시간의 흐름에 따른 변화를 표현합니다.

유스케이스 다이어그램 (Use Case Diagram): 사용자(액터) 관점에서 시스템이 제공하는 기능과 그들 간의 관계를 표현합니다. (요구사항 정의 단계)

시퀀스 다이어그램 (Sequence Diagram): 객체 간 주고받는 메시지를 시간의 흐름에 따라 순차적으로 표현합니다.

커뮤니케이션 다이어그램 (Communication Diagram): 객체 간의 메시지 흐름과 함께 객체들 사이의 연관 관계를 강조하여 표현합니다.

상태 다이어그램 (State Diagram): 하나의 객체가 이벤트에 따라 어떻게 상태 변화를 일으키는지 표현합니다.

활동 다이어그램 (Activity Diagram): 시스템 내 로직의 처리 흐름이나 업무 프로세스를 순서도(Flowchart)와 유사하게 표현합니다.

상호작용 개요 다이어그램 (Interaction Overview Diagram): 활동 다이어그램 내에 여러 상호작용 다이어그램을 포함하여 전체적인 제어 흐름을 표현합니다.

타이밍 다이어그램 (Timing Diagram): 객체 상태 변화와 시간 제약을 구체적인 시간 선상에서 표현합니다.

4. 소프트웨어 아키텍처 ⭐⭐⭐

01. 아키텍처 패턴

MVC 패턴: 모델(데이터), 뷰(UI), 컨트롤러(로직)로 역할을 분리하여 유지보수성을 높입니다.

파이프-필터: 데이터 스트림을 순차적으로 처리합니다. (UNIX 쉘의 파이프라인 구조)

마스터-슬레이브: 작업을 분할하여 병렬 처리하며, 장애 허용 시스템에 유리합니다.

02. 소프트웨어 품질 특성 (ISO/IEC 9126)

암기팁: 기·신·사·효·유·이

기능성: 요구된 목적을 정확히 수행하는 정도

신뢰성: 고장 없이 서비스를 유지하는 정도

사용성: 사용자가 배우고 사용하기 쉬운 정도

효율성: 자원을 얼마나 적절히 활용하는지

유지보수성: 환경 변화나 오류 수정의 용이성

이식성: 다른 환경으로 옮기기 쉬운 정도

5. GoF 디자인 패턴 ⭐⭐⭐⭐⭐ (최다 빈출)

디자인 패턴은 총 23개이며, 크게 세 가지 범주로 나뉩니다.

01. 생성 패턴 (Creational) - 객체 생성 로직 캡슐화

Singleton: 클래스의 인스턴스가 단 하나임을 보장

Abstract Factory: 구체적 클래스에 의존하지 않고 연관된 객체 군 생성

Factory Method: 객체 생성을 서브 클래스에서 결정하도록 위임

Builder: 복잡한 객체 생성 과정을 단계별로 분리

Prototype: 원본 객체를 복사하여 새로운 객체 생성

02. 구조 패턴 (Structural) - 클래스와 객체의 구성

Adapter: 호환되지 않는 인터페이스를 변환하여 함께 사용

Bridge: 구현부와 추상층을 분리하여 독립적으로 확장

Composite: 트리 구조를 사용하여 부분-전체 계층 구조 표현

Decorator: 객체에 기능을 동적으로 추가

Facade: 복잡한 서브시스템에 대해 단순한 통합 인터페이스 제공

Flyweight: 다수의 유사 객체를 공유하여 메모리 절약

Proxy: 실제 객체에 대한 접근 제어 및 대리자 역할

03. 행위 패턴 (Behavioral) - 객체 간의 상호작용 및 책임 분배

Observer: 한 객체의 상태 변화를 다른 객체들에게 알림

Strategy: 알고리즘을 캡슐화하여 상호 교환 가능하게 함

Template Method: 알고리즘의 골격을 정의하고 하위에서 세부 구현

State: 객체의 내부 상태에 따라 스스로 행동을 변경

Command: 요청 자체를 객체로 캡슐화하여 기록 및 취소 기능 지원

6. 사용자 인터페이스 (UI) ⭐⭐

UI 설계 원칙: Intuitiveness(직관성), Efficiency(유효성), Learnability(학습성), Flexibility(유연성)

UI 구분: CLI(텍스트), GUI(그래픽), NUI(신체/음성), OUI(유기적 상호작용)