[정보처리기사] 소프트웨어 설계부 오답 개념 정리 -6

🔍 요구사항 개발 프로세스

요구사항은 도출 → 분석 → 명세 → 확인의 네 단계로 개발됩니다.

단계 설명 주요 기법

도출	사용자로부터 요구사항을 수집	인터뷰, 설문조사, 브레인스토밍, 인터넷 검색 등
분석	수집한 요구사항을 분류·정제	중재, 관찰, 모델 작성
명세	요구사항을 문서화, 시스템이 수행할 행위 명시	요구사항 정의서 작성
확인	요구사항의 정확성, 일관성 검토	동료 검토, 워크스루, 인스펙션, CASE 도구 활용

✅ 명심: 설계 및 코딩 기술은 요구사항 분석 이후에 사용됩니다.

---

🔎 인터페이스 요구사항 검토 기법

방식 설명

동료 검토	작성자가 PT를 통해 이해관계자들과 직접 검토
워크스루	사전 배포 후 회의 진행, 비공식적 검토
인스펙션	작성자 외 전문가가 결함 검토
CASE 도구	요구사항 관리 도구로 추적성, 일관성 자동 검토

---

🛠 공통 모듈 작성 원칙

항목 설명

정확성	실제로 필요한 기능인지 여부 검토
명확성	동일한 의미로 해석되도록 작성
완전성	필요한 기능이 빠짐없이 포함되도록
일관성	기능 간 충돌 없이 구성
추적성	변경 및 연결이 가능한 형태로 구성

---

🧱 객체지향 설계 핵심 개념

개념 설명

클래스	공통된 속성과 메소드를 가진 객체 집합
메소드	객체가 수행하는 기능
메세지	객체 간 상호작용 수단
캡슐화	속성과 메소드를 하나로 묶음
추상화	공통 속성을 슈퍼클래스로 정의
일반화	A는 B의 일종이다 → 상속 관계
집단화	구조적 집약 관계 (부분과 전체)

---

🧭 UML (Unified Modeling Language)

✅ 시퀀스 다이어그램 구성요소

• 생명선(Lifeline): 객체의 생존 기간
• 실행(Activation): 객체가 메소드 수행 중인 시간
• 메세지(Message): 객체 간 호출
• 액터(Actor): 시스템 외부 사용자
• 객체(Object): 시스템 내 클래스의 인스턴스

✅ UML 일반화 관계

• 일반적인 개념 → 상위 클래스(부모)
• 구체적인 개념 → 하위 클래스(자식)
• 화살표는 하위 → 상위로 표현

✅ UML 구조 vs 행위 다이어그램

• 구조 다이어그램: 클래스, 객체, 컴포넌트, 배치 등 정적인 구조
• 행위 다이어그램: 시퀀스, 상태, 활동 등 동작 흐름
• ❗ Activity Diagram은 구조 다이어그램 ❌ → 행위 다이어그램에 속함

✅ 확장 모델

• <<stereotype>> 형태로 표현 (ex. <<interface>>, <<entity>>)

---

🏭 디자인 패턴 - Factory Pattern

• 객체 생성에 대한 인터페이스는 정의하지만,
  어떤 클래스의 인스턴스를 생성할지는 서브클래스가 결정
• 불필요한 객체 생성을 줄이고 결합도를 낮춘다
• 버추얼 컨스트럭터(Virtual Constructor) 패턴이라고도 불림

---

🔌 미들웨어(Middleware) 유형

유형 설명

WAS (Web Application Server)	웹 기반 서비스 수행
RPC (Remote Procedure Call)	원격 프로시저 호출 방식
ORB (Object Request Broker)	객체 간 메세지 전달
TP Monitor (Transaction Processing Monitor)	트랜잭션 제어 및 처리

---

📊 자료 흐름도(DFD) 구성요소

요소 기호 설명

프로세스	○	처리 절차 또는 기능
자료 흐름	→	데이터 이동
자료 저장소	=	데이터 저장소
단말기(외부 엔티티)	▭	시스템 외부 사용자 또는 시스템

---

📄 HIPO (Hierarchy Input Process Output)

• 하향식 소프트웨어 문서화 도구
• 시스템 전체를 계층적으로 구성
• 입력-처리-출력 중심으로 구성되어 명확하고 구조화된 문서 작성 가능