정보처리기사 필기 소프트웨어 설계 요약

럼바우(Rumbaugh)

럼바우(Rumbaugh)의 OMT(Object Modeling Technique) 기법에서는 세 가지 주요 모델링이 있습니다:

1. 객체 모델링 – 객체 다이어그램(Object Diagram) 등을 사용하여 시스템의 정적 구조를 표현
2. 동적 모델링 – 상태 다이어그램(State Diagram)을 사용하여 객체의 상태 변화 및 이벤트 응답을 표현
3. 기능 모델링 – 자료 흐름도(Data Flow Diagram)를 사용하여 시스템의 기능과 데이터 흐름을 표현

따라서, 동적 모델링에 활용되는 다이어그램은 상태 다이어그램입니다.

 

CASE(Computer Aided Software Engineering)

CASE (Computer Aided Software Engineering)는 소프트웨어 개발을 보다 효율적으로 수행하기 위해 자동화 도구를 활용하는 것을 의미합니다. 주로 소프트웨어 개발의 생산성과 품질 향상을 목적으로 하며 다음과 같은 기능들을 포함합니다:

CASE의 주요 기능

1. S/W 라이프 사이클 전 단계의 연결
   → 요구분석, 설계, 구현, 테스트, 유지보수 등 전 과정 지원합니다.
2. 그래픽 지원
   → 다이어그램(UML 등) 작성을 위한 시각적 도구 제공이 포함됩니다.
3. 다양한 소프트웨어 개발 모형 지원
   → 폭포수 모델, 프로토타입, 반복적 개발 등 다양한 개발 모형을 지원합니다.

CASE(Computer-Aided Software Engineering) 도구는 소프트웨어 개발 과정을 자동화하거나 지원해주는 도구이며, 상위 CASE 도구(Upper CASE Tool)는 주로 소프트웨어 개발의 분석 및 설계 단계를 지원합니다.

상위 CASE 도구의 주요 기능은 다음과 같습니다:

• 요구사항 분석 및 설계 지원
• 자료 흐름도(DFD) 작성 기능
• 모델 간의 모순 검사
• 모델의 오류 검증

반면,
전체 소스코드 생성 기능은 하위 CASE 도구(Lower CASE Tool)의 역할로, 구현 및 테스트 단계를 지원하는 기능입니다.

따라서, 상위 CASE 도구가 지원하지 않는 기능은 전체 소스코드 생성 기능입니다.

자료흐름도(DFD)

 자료흐름도(DFD, Data Flow Diagram)는 시스템 내 데이터의 흐름과 처리를 시각적으로 표현한 다이어그램입니다. 각 요소의 표기 형태는 다음과 같습니다:

요소의미표기 형태

Process	데이터를 처리하는 기능 또는 작업	원(circle) 또는 둥근 사각형
Data Flow	데이터의 흐름	화살표(→)
Data Store	저장소(파일, DB 등)	두 개의 수평선 또는 열린 직사각형
Terminator	외부 개체(시스템 외부와의 인터페이스)	사각형(rectangle)

🔸 Data Store는 삼각형으로 표기하지 않으며,
→ 삼각형은 DFD에서 사용되지 않는 표기입니다.

따라서, 옳지 않은 연결은 3번: Data Store – 삼각형입니다.

 

DFD(자료흐름도)에서는 삼각형은 사용되지 않는 표기입니다.

 

추가해설:

 

 DFD (Data Flow Diagram)는 데이터의 흐름과 처리 과정을 시각적으로 표현하는 다이어그램입니다.
하지만, DFD는 "시간 흐름(Time flow)"을 표현하지 않습니다.

• 무엇이 처리되고 어떻게 흐르는가를 중점으로 하며,
• 처리 순서나 시간적 흐름은 표현 대상이 아닙니다.

보기설명

1. 자료 흐름 그래프 또는 버블 차트라고도 한다.	맞습니다. (버블 차트라고도 부름)
2. 구조적 분석 기법에 이용된다.	맞습니다. (구조적 시스템 분석 및 설계에 사용)
3. 시간 흐름을 명확하게 표현할 수 있다.	❌ 틀렸습니다. (시간 순서나 흐름은 표현하지 못함)
4. DFD의 요소는 화살표, 원, 사각형, 직선(단선/이중선)으로 표시한다.	맞습니다. (각 요소: 프로세스, 데이터 흐름, 외부 엔티티, 데이터 저장소)

 

미들웨어(Middleware)

미들웨어(Middleware)는 운영체제와 응용 프로그램 사이에서 중개자 역할을 하며, 분산 환경에서 서로 다른 시스템 간의 통신, 데이터 교환 등을 지원하고 연결해주는 소프트웨어 계층입니다.

✅ 미들웨어 솔루션 유형에 포함되는 것들:

1. WAS (Web Application Server)
   • 웹 서버와 데이터베이스 사이에서 동적인 웹 콘텐츠를 처리
   • 예: Tomcat, WebLogic, JBoss 등
2. RPC (Remote Procedure Call)
   • 원격에 있는 함수나 프로시저를 로컬처럼 호출할 수 있게 해주는 미들웨어
   • 분산 시스템 통신 기술의 하나
3. ORB (Object Request Broker)
   • 객체지향 기반 분산 시스템에서 객체 간 통신을 중개
   • CORBA(Common Object Request Broker Architecture) 기반 시스템에 사용

 미들웨어(Middleware)는 분산 컴퓨팅 환경에서 응용 프로그램과 운영체제 사이에 위치하여, 서로 다른 시스템 간의 통신과 데이터 교환을 중개하는 소프트웨어입니다.

• 서로 다른 하드웨어, 운영체제, 통신 프로토콜 간의 차이를 중재
• 응용 프로그램이 네트워크 환경에 관계없이 동작할 수 있도록 지원
• 대표적인 예: DB 접속 미들웨어, 메시지 큐(MQ), RPC, CORBA, WebLogic, WebSphere 등

다른 보기 설명 : 

• 하드웨어: 물리적 장치
• 오픈허브웨어: 일반적으로 사용되지 않는 용어
• 그레이웨어(Grayware): 스파이웨어나 애드웨어처럼 사용자를 불편하게 만들지만 명확히 악성은 아닌 소프트웨어

 미들웨어(Middleware)는 서로 다른 운영체제나 네트워크 환경에서 동작하는 응용 프로그램 간의 통신을 지원하고, 소프트웨어 컴포넌트를 효율적으로 연결해주는 중간 소프트웨어입니다.

다시 말해, 미들웨어는 응용 프로그램과 운영 체제 사이에 위치하여 다음과 같은 기능을 수행합니다:

• 플랫폼 독립적 통신 지원
• 다양한 컴포넌트를 1:1, 1:N, N:N 구조로 연결 가능
• 소프트웨어 개발 시 인프라(메시지 큐, RPC 등) 제공
• 투명성 제공: 내부 구현이나 동작 방식을 사용자가 몰라도 사용 가능해야 함
• 미들웨어의 가장 큰 장점 중 하나는 "투명성(Transparency)"입니다.

 

미들웨어(MOM, Message-Oriented Middleware)

 메시지 지향 미들웨어(MOM, Message-Oriented Middleware)는 애플리케이션 간의 비동기 메시지 통신을 지원하는 미들웨어입니다. 주요 특징은 다음과 같습니다:

• 애플리케이션 간의 독립성과 확장성 확보
• 비동기 방식으로 메시지를 송수신하여, 송신측과 수신측이 동시에 동작하지 않아도 됨
• 메시지 큐(Message Queue)를 사용하여 메시지를 저장하고 전달
• 다양한 플랫폼이나 언어 간의 통신을 중재하고 통합

하지만,
🔸 MOM은 즉각적인 응답(실시간성) 보다는 안정성과 신뢰성을 중요시합니다.
→ 주로 비동기 처리가 가능한 백오피스 작업이나 대용량 메시지 처리 등에 적합하며,
→ 즉시 응답이 필요한 온라인 트랜잭션 처리(OLTP) 시스템에는 적합하지 않습니다.

 

 

UML 시퀀스 다이어그램(Sequence Diagram)

UML 시퀀스 다이어그램(Sequence Diagram)은 객체 간의 상호작용을 시간 순서에 따라 표현하는 다이어그램으로, 다음과 같은 구성 요소들로 이루어집니다:

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

1. 생명선 (Lifeline)
   • 객체의 생존 기간을 나타냄
   • 세로로 그려지며, 메시지 전달에 따라 변화
2. 실행 (Activation 또는 Execution Specification)
   • 객체가 메시지를 처리하는 시간
   • 생명선 위에 있는 직사각형으로 표현됨
3. 메시지 (Message)
   • 객체 간 주고받는 호출, 응답, 신호 등을 표현
   • 화살표로 나타남

GoF(Gang of Four) 디자인 패턴

 

소프트웨어 설계에서 자주 발생하는 문제에 대해 검증된 일반적이고 반복적인 해결 방법을 정리해 놓은 것입니다.

주요 특징:

• 객체지향 설계에서 유연하고 재사용 가능한 구조 제공
• 특정한 문제 상황에서 효과적으로 적용 가능한 설계 틀
• 대표적인 디자인 패턴 분류:
  • 생성 패턴 (ex. Singleton, Factory)
  • 구조 패턴 (ex. Adapter, Composite)
  • 행위 패턴 (ex. Observer, Strategy)

GoF(Gang of Four) 디자인 패턴은 크게 세 가지로 분류됩니다:

1. 생성(Creational) 패턴: 객체 생성 방식에 대한 패턴
2. 구조(Structural) 패턴: 클래스나 객체를 조합하여 더 큰 구조를 만드는 방식
3. 행위(Behavioral) 패턴: 객체 간의 책임 분배와 커뮤니케이션에 중점을 둠

✅ 1. 생성(Creational) 패턴 – "팩추빌프로싱"

🎵 "팩추빌프로싱!"

패턴	이미지 연상	기억 키워드
Factory	공장에서 제품 찍기	객체를 팍팍 생산!
Abstract Factory	여러 공장을 관리하는 본사	팩토리들의 팩토리
Builder	조립식 가구, 햄버거 만들기	조립, 순서대로
Prototype	복제 인간, 클론 양돌이	복사해서 사용
Singleton	단 하나의 사장님	오직 한 명 존재

✅ 2. 구조(Structural) 패턴 – "어브컴데퍼플프"

🎵 "어브컴-데-퍼플프"

패턴	이미지 연상	기억 키워드
Adapter	콘센트 변환기	호환성 맞추기
Bridge	연결다리	구현과 추상 분리
Composite	폴더 트리 구조	전체-부분
Decorator	크리스마스 트리 꾸미기	기능 추가
Facade	호텔 데스크	복잡한 걸 감춰줌
Flyweight	다이어트 제품 공유	공유로 메모리 절약
Proxy	경비원, 대리 처리자	대신 처리, 통제

✅ 3. 행위(Behavioral) 패턴 

패턴	이미지 연상	기억 키워드
Observer	구독자, 유튜브 알림	상태 변화 통보
Strategy	무기 교체 게임	알고리즘 변경
Command	군대 명령서	명령 캡슐화
State	신호등 색 변화	상태에 따라 행동
Template Method	요리 레시피	틀은 고정, 세부는 재정의
Chain of Responsibility	회사 보고 체계	책임을 순차 전달
Visitor	박물관 투어 가이드	기능 방문
Iterator	루프 반복	순차적 접근
Mediator	회의 중재자	객체 간 중재
Memento	세이브 포인트	상태 저장/복원
Interpreter	언어 해석사	문법 분석기

 

🧠 암기요령 문장 만들기!

"책임감 있는 커맨드가 인터프리터를 이끌고, 중재자가 메멘토를 챙기며 옵저버로 상태를 살피고,

전략을 세워 템플릿을 따라 방문한다."

한글로 자연스럽게 외우면서 패턴 이름까지 다 챙길 수 있어!

구조로 보면:

• 책임감 있는 → 책임 연쇄 (Chain of Responsibility)
• 커맨드가 → 커맨드 (Command)
• 인터프리터를 → 인터프리터 (Interpreter)
• 이끌고 → (이어가기)
• 중재자가 → 중재자 (Mediator)
• 메멘토를 챙기며 → 메멘토 (Memento)
• 옵저버로 → 옵저버 (Observer)
• 상태를 살피고 → 상태 (State)
• 전략을 세워 → 전략 (Strategy)
• 템플릿을 따라 → 템플릿 메소드 (Template Method)
• 방문한다 → 방문자 (Visitor)

 

UML의 기본 구성 요소(띵다리)

UML(Unified Modeling Language)의 구성은 다음 3가지 핵심 요소로 나뉩니다:

✅ 1. Things (사물)

• UML에서 모델의 기본 요소
• 예: 클래스(Class), 인터페이스(Interface), 노트(Note), 유스케이스(Use Case) 등

✅ 2. Relationships (관계)

• 사물들 간의 연결, 상호작용
• 예: 연관(Association), 일반화(Generalization), 의존(Dependency), 실체화(Realization)

✅ 3. Diagrams (다이어그램)

• Things와 Relationships를 시각적으로 표현
• 예: 클래스 다이어그램, 시퀀스 다이어그램, 상태 다이어그램 등

 

UML(Unified Modeling Language) 다이어그램

 UML (Unified Modeling Language)은 소프트웨어 시스템을 시각적으로 모델링하는 데 사용되는 표준 언어입니다. UML에서 제공하는 다이어그램은 시스템의 구조, 동작, 상호작용 등을 다양한 관점에서 표현하는 데 활용됩니다. UML 다이어그램은 크게 구조적 다이어그램(Structural Diagrams)과 행위적 다이어그램(Behavioral Diagrams)으로 나뉩니다.

1. 구조적 다이어그램 (Structural Diagrams)

시스템의 정적 구조를 나타내며, 시스템의 객체들 간의 관계나 클래스, 컴포넌트 등을 모델링합니다.

1.1 클래스 다이어그램 (Class Diagram)

• 설명: 클래스와 그 클래스들 간의 관계를 나타냅니다. 클래스의 속성, 메서드, 그리고 클래스 간의 연관, 상속, 집합 등을 시각적으로 표현합니다.
• 사용 목적: 시스템의 데이터 구조와 객체 간 관계를 이해하는 데 유용합니다.
• 클래스 다이어그램(Class Diagram)은 UML에서 시스템의 정적 구조(Static Structure)를 표현하는 다이어그램으로, 다음과 같은 정보를 나타냅니다:
  • 클래스(Class)의 속성(Attributes)과 연산(Operations)
  • 클래스 간의 관계 (연관, 집합, 포함, 일반화 등)
  • 클래스와 객체 간의 상속, 의존, 구현 관계

1.2 컴포넌트 다이어그램 (Component Diagram)

• 설명: 시스템을 구성하는 소프트웨어 컴포넌트 간의 관계를 보여줍니다. 컴포넌트가 어떻게 서로 연결되고 의존하는지 설명합니다.
• 사용 목적: 시스템을 구성하는 소프트웨어 모듈의 설계와 의존성 모델링에 사용됩니다.

1.3 객체 다이어그램 (Object Diagram)

• 설명: 클래스 다이어그램의 특정 인스턴스를 나타내며, 시스템의 객체 상태를 보여줍니다.
• 사용 목적: 시스템이 실행 중일 때 객체 간의 관계와 상태를 시각적으로 나타냅니다.

1.4 패키지 다이어그램 (Package Diagram)

• 설명: 시스템을 여러 패키지로 나누어, 각 패키지 간의 의존성 관계를 표현합니다.
• 사용 목적: 시스템의 구조적 모듈화와 의존성 관계를 이해하는 데 유용합니다.

1.5 배치 다이어그램 (Deployment Diagram)

• 설명: 시스템의 물리적 구성과 하드웨어 간의 관계를 나타냅니다. 각 노드에 배치된 소프트웨어 컴포넌트들을 보여줍니다.
• 사용 목적: 시스템의 배치 환경을 모델링하고, 각 시스템이 어떤 하드웨어 자원을 사용하는지 표현합니다.

1.6 컴포넌트 다이어그램 (Component Diagram)

• 설명: 시스템 내에서 소프트웨어 구성 요소들의 관계를 보여주는 다이어그램으로, 컴포넌트들이 어떻게 연결되는지를 나타냅니다.
• 사용 목적: 모듈화된 시스템에서 각 컴포넌트의 상호작용과 의존성을 분석하는 데 유용합니다.

2. 행위적 다이어그램 (Behavioral Diagrams)

시스템의 동적 행위와 객체 간 상호작용을 나타내며, 시스템의 동작을 시간 흐름에 따라 모델링합니다.

2.1 유스케이스 다이어그램 (Use Case Diagram)

• 설명: 시스템의 기능과 사용자의 상호작용을 나타냅니다. 유스케이스(기능)와 그에 대한 액터(사용자 또는 다른 시스템) 간의 관계를 보여줍니다.
• 사용 목적: 사용자 요구 사항을 분석하고 시스템의 기능을 정의하는 데 유용합니다.
• UML 유스케이스 다이어그램에서 확장(Extend) 관계는 기본 유스케이스(Base Use Case)의 흐름 중, 특정 조건이 만족될 때 추가적으로 실행되는 유스케이스를 나타냅니다.

다른 보기 설명:

• 연관(Association): 액터와 유스케이스 사이의 단순 연결 관계
• 선택(Selection): UML 공식 용어 아님
• 특화(Specialization): 일반화(Generalization)와 유사, 유스케이스를 상속받는 개념

 

2.2 시퀀스 다이어그램 (Sequence Diagram)

• 설명: 객체들 간의 메시지 전달 순서를 시간 순으로 표현한 다이어그램입니다.
• 사용 목적: 객체들 간의 상호작용 순서와 프로세스 흐름을 명확히 이해할 수 있습니다.

2.3 활동 다이어그램 (Activity Diagram)

• 설명: 시스템의 흐름을 나타내며, 특히 작업 흐름과 프로세스의 단계들을 표현합니다. 조건 분기, 병렬 처리 등을 나타낼 수 있습니다.
• 사용 목적: 시스템의 업무 흐름이나 프로세스 로직을 이해하고 모델링하는 데 유용합니다.
• 활동의 흐름, 제어 흐름을 표현하는 다이어그램 (절차적/동적 측면)

2.4 상태 다이어그램 (State Diagram)

• 설명: 객체나 시스템의 상태 변화와 상태 간 전이를 나타냅니다. 상태가 바뀔 때 발생하는 이벤트나 조건을 정의합니다.
• 사용 목적: 시스템의 상태 변화와 상태 전이를 추적하는 데 유용합니다.
• 객체의 상태 변화와 이벤트 간의 관계를 표현 (동적 모델링)

2.5 커뮤니케이션 다이어그램 (Communication Diagram)

• 설명: 객체들 간의 메시지 전달과 상호작용을 나타냅니다. 시퀀스 다이어그램과 유사하지만, 객체들 간의 관계를 강조합니다.
• 사용 목적: 객체들 간의 메시지 교환 구조를 명확히 할 때 유용합니다.

2.6 타이밍 다이어그램 (Timing Diagram)

• 설명: 객체들의 시간적 관계를 나타내며, 시스템의 시간에 따른 상태 변화와 메시지 전달을 보여줍니다.
• 사용 목적: 시간에 민감한 시스템의 상태 변화를 분석할 때 유용합니다.

2.7 인터랙션 오버뷰 다이어그램 (Interaction Overview Diagram)

• 설명: 복잡한 시스템의 상호작용을 다루며, 여러 시퀀스 다이어그램이나 커뮤니케이션 다이어그램을 연결하여 보여줍니다.
• 사용 목적: 복잡한 상호작용을 한눈에 파악하고 싶을 때 유용합니다.

📌 UML 다이어그램 전체 분류

UML 다이어그램은 크게 구조적(Structural) 과 행위적(Behavioral) 다이어그램으로 나뉩니다.

Structural Diagram (구조적 다이어그램)	Class Diagram	클래스와 관계(연관, 상속 등)를 표현
	Object Diagram	객체 인스턴스들과 그 관계를 표현
	Component Diagram	소프트웨어 구성요소(컴포넌트) 구조 표현
	Deployment Diagram	하드웨어 노드와 소프트웨어 배포 관계 표현
	Package Diagram	패키지 간의 관계 표현
	Composite Structure Diagram	클래스 내부 구조나 역할과 협력 표현
	Profile Diagram	UML 모델 확장(프로파일) 표현
Behavioral Diagram (행위적 다이어그램)	Use Case Diagram	사용자(액터)와 시스템 기능(유스케이스) 관계 표현
	Activity Diagram	작업 흐름(비즈니스 프로세스나 로직 흐름) 표현
	State Machine Diagram	객체의 상태 변화 표현
	Sequence Diagram	객체 간 메시지 교환 순서 표현
	Communication Diagram	객체 간 메시지 교환 구조(순서보다 구조 중심) 표현
	Interaction Overview Diagram	복잡한 흐름을 시각적으로 표현 (Activity+Sequence 통합형)
	Timing Diagram	시간에 따른 객체 상태 변화 표현

✏️ 요약 포인트

• 구조적 다이어그램 → 정적인 구조(무엇이 존재하는가) 중심
• 행위적 다이어그램 → 동적인 행위(어떻게 동작하는가) 중심

 

UML 다이어그램을 활용하는 목적

• 시스템 설계: 소프트웨어 시스템을 설계하는 데 필요한 모델을 제공
• 문서화: 시스템을 명확하게 문서화하고 의사소통을 원활하게 함
• 요구사항 분석: 사용자 요구사항을 효과적으로 표현하고 분석
• 디버깅 및 유지보수: 시스템의 동작을 분석하여 오류를 추적하고, 시스템을 유지보수하는 데 도움을 줍니다.

결론:

UML 다이어그램은 소프트웨어 설계와 개발 과정에서 매우 중요한 역할을 합니다. 다이어그램은 시스템의 구조와 동작을 시각적으로 표현하여 모델링, 분석, 설계, 유지보수 단계에서 시스템을 더 잘 이해하고 효과적으로 관리할 수 있도록 도와줍니다.

 

UML 모델

• Association(연관): 클래스 간의 구조적 관계 (예: "학생은 수업을 듣는다"), 두 클래스 간의 관계를 나타내며, 상호작용을 하는 관계일 수 있지만, 변경이 다른 클래스에 영향을 주는 관계는 아닙니다.
• Generalization(일반화): 상속 관계 (부모-자식 클래스), 이는 클래스 간의 상속 관계로, 부모 클래스가 자식 클래스에게 공통된 특성을 전달하는 관계입니다.
• Realization(실현): 인터페이스와 그것을 구현하는 클래스 간의 관계, 이는 인터페이스와 이를 구현하는 클래스 간의 관계로, 의존성과는 다른 개념입니다.
• Dependency(의존관계):한 요소가 다른 요소에 의존하고 있을 때 사용되는 관계입니다.
  즉, 어떤 클래스(A)가 다른 클래스(B)의 기능, 타입, 매개변수 등을 사용할 때 A는 B에 의존한다고 합니다.
  • 명세가 바뀌면 다른 사물에 영향을 주는 관계
  • 일시적으로 사용하는 관계 (예: 메서드의 매개변수로 다른 클래스가 사용될 때)
  • UML에서는 점선 화살표(→) 로 표현
  • 한 클래스가 다른 클래스를 오퍼레이션의 매개변수로 사용하는 경우는 Dependency 관계입니다.

 

요구 사항 명세기법

 요구사항 명세기법은 시스템이 해야 할 일을 명확하게 정의하기 위해 사용됩니다. 이를 비정형 명세기법과 정형 명세기법으로 나눌 수 있습니다.

✅ 1. 비정형 명세기법

• 자연어 기반으로 작성 (예: 한글, 영어 등)
• 비전문가도 이해하기 쉬움
• 정형화되지 않은 방식으로 서술
• 문서화가 간편하지만 모호함이나 중복이 발생하기 쉬움

✅ 2. 정형 명세기법

• 수학적인 이론(논리식, 상태 기계 등)을 기반으로 함
• 명확하고 일관된 명세 가능
• 예: Z, VDM, B-method, Petri Nets

정형 기술 검토(FTR, Formal Technical Review)

정형 기술 검토(FTR, Formal Technical Review)는 소프트웨어 품질을 향상시키기 위해 공식적인 절차를 따라 문서, 코드 등을 검토하는 활동입니다. 지침 사항은 다음과 같습니다:

• 의제를 제한한다: 검토의 범위와 논의 주제를 명확히 정해야 합니다.
• 논쟁과 반박을 제한한다: 검토는 품질 향상이 목적이지, 토론이나 논쟁이 목적이 아닙니다.
• 문제 영역을 명확히 표현한다: 어떤 문제를 다루는지 명확히 해야 효율적인 검토가 가능합니다.
• 참가자의 수를 제한한다: 참가자는 적정 인원(보통 3~5명)으로 제한하는 것이 효과적입니다. (문제 지문에서는 "제한하지 않는다"라고 했으므로 틀림)

요구 사항 분석 단계

 요구 분석 단계는 소프트웨어 개발의 초기 단계로, 사용자 요구를 정확하게 파악하고 이를 문서화하여 이후 설계와 구현의 기초로 삼는 중요한 과정입니다. 하지만 개발 비용 측면에서는 가장 많은 비용이 들어가는 단계는 아닙니다.

각 보기별 설명:

✅ 1. 분석 결과의 문서화를 통해 향후 유지보수에 유용하게 활용할 수 있다.

• 정확한 설명입니다.
• 요구 분석 문서화는 시스템 유지보수, 변경, 확장 시 매우 중요합니다.

✅ 3. 자료흐름도, 자료 사전 등이 효과적으로 이용될 수 있다.

• 요구 분석 단계에서 DFD(Data Flow Diagram), 자료사전(Data Dictionary), ERD(Entity Relationship Diagram) 등 다양한 분석 도구가 활용됩니다.

✅ 4. 보다 구체적인 명세를 위해 소단위 명세서(Mini-Spec)가 활용될 수 있다.

• 맞는 설명입니다.
• Mini-Spec은 DFD의 프로세스를 구체적으로 기술할 때 사용되는 세부 명세서입니다.

 

객체지향 설계 원칙(SOILD)

🔷 SOLID 원칙 요약

약어	이름	설명
S	SRP (Single Responsibility Principle) 단일 책임 원칙	클래스는 하나의 책임만 가져야 하며, 변경 이유도 하나뿐이어야 한다.
O	OCP (Open/Closed Principle) 개방-폐쇄 원칙	확장에는 열려 있고, 변경에는 닫혀 있어야 한다. 즉, 기존 코드를 수정하지 않고 기능을 확장할 수 있어야 한다.
L	LSP (Liskov Substitution Principle) 리스코프 치환 원칙	자식 클래스는 부모 클래스로 대체 가능해야 한다. 즉, 하위 타입은 상위 타입을 완전히 대체할 수 있어야 한다.
I	ISP (Interface Segregation Principle) 인터페이스 분리 원칙	작고 구체적인 인터페이스 여러 개가 하나의 일반적인 인터페이스보다 낫다. 클라이언트는 자신이 사용하지 않는 메서드에 의존하지 않아야 한다. 클라이언트는 자신이 사용하지 않는 메서드와 의존관계를 맺으면 안된다. 클라이언트가 사용하지 않는 인터페이스 때문에 영향을 받아서는 안된다.
D	DIP (Dependency Inversion Principle) 의존 역전 원칙	고수준 모듈(정책)은 저수준 모듈(세부사항)에 의존하면 안 되며, 둘 다 추상화에 의존해야 한다.

 

객체지향 분석 기법

 객체지향 분석(Object-Oriented Analysis, OOA)은 데이터(속성)와 행위(메서드)를 함께 묶은 객체 단위로 시스템을 분석하는 방법입니다. 주요 특징은 다음과 같습니다:

• 시스템을 객체 중심으로 파악함
• 동적 모델링이 가능하며, 상태 다이어그램 등을 통해 객체의 상태 변화와 이벤트 흐름을 표현
• 추상화, 캡슐화, 상속, 다형성 등의 개념 활용
• 코드 재사용과 유지보수 용이성, 변경에 대한 유연성을 제공

추가 해설 :

 객체지향 분석 기법

1. 동적 모델링

2. 상향식

 

객체지향 개념

1. Inheritance (상속): 기존 클래스를 확장하여 새로운 클래스를 만드는 개념
2. Class (클래스): 객체를 정의하기 위한 설계도
3. Association (연관): 클래스 간의 관계를 나타냄
4. Encapsulation(캡슐화):  클래스 내부에 묶어서 외부에서 직접 접근하지 못하도록 감추는 것을 의미.

 

 

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

 요구사항 검토는 소프트웨어 품질 향상을 위해 요구사항 명세서를 검토하여 결함, 누락, 모순 등을 사전에 발견하는 과정입니다. 대표적인 검토 기법은 다음과 같습니다.

1. 동료 검토 (Peer Review)

• 설명: 요구사항 작성자가 내용을 설명하고, 동료나 이해관계자가 설명을 들으며 결함을 비공식적으로 발견하는 방식
• 특징: 비교적 간단하며 자주 활용됨

2. 인스펙션 (Inspection)

• 인스펙션은 전문가 집단이 명세서를 형식적으로 검토하는 정형적 절차입니다.

3. 워크스루 (Walkthrough)

• 요구사항 명세서, 설계서 등의 문서를 검토회의 전에 미리 배포하고, 참가자들이 사전 검토한 뒤 짧고 간단한 회의를 통해 오류나 개선점을 조기에 발견하는 방법입니다.

주요 특징:

• 사전 준비가 필요 (문서 배포 및 개인별 검토)
• 진행자는 작성자 본인이거나 팀원 중 한 명이 맡을 수 있음
• 형식적 절차보다는 자유롭고 비공식적인 리뷰
• 오류를 빠르게 찾아 수정 비용을 줄이는 데 초점

 

시스템의 5대 구성 요소

 시스템의 구성 요소는 일반적으로 다음과 같은 다섯 가지로 정의됩니다:

• 입력(Input): 시스템에 주어지는 자원 또는 정보
• 처리(Process): 입력을 변환하여 출력을 생성하는 작업
• 출력(Output): 처리 결과로 산출되는 정보
• 피드백(Feedback): 출력 결과를 평가하여 시스템에 다시 반영하는 정보
• 제어(Control): 시스템의 목표 달성을 위해 과정 전체를 조정하고 제어하는 요소

이 다섯 가지는 시스템 이론의 핵심 구성 요소이며, 서로 상호작용하면서 시스템의 기능을 수행합니다.

 

애자일(Agile) 개발 방법론

 애자일(Agile) 개발 방법론은 빠르게 변화하는 요구사항에 유연하게 대응하고, 고객과의 지속적인 소통을 통해 짧은 주기의 반복적 개발을 지향하는 방법론입니다. 대표적인 애자일 개발 방법론은 다음과 같습니다:

• 스크럼(Scrum): 정해진 역할과 짧은 스프린트 주기를 통해 개발 진행
• 익스트림 프로그래밍(XP): 짝 프로그래밍, 지속적인 통합, 테스트 주도 개발 등 강조
• 기능 주도 개발(FDD): 기능 단위로 반복 개발하는 모델 

 

자료사전(Data Dictionary)

자료사전(Data Dictionary)은 자료 흐름도(DFD) 등에서 사용하는 데이터 항목을 정의하는 곳입니다.
이때 사용되는 주요 기호는 각각 의미가 정해져 있습니다:

=	정의(Definition)	항목의 정의를 나타냄 (왼쪽 항목은 오른쪽으로 정의됨)
+	결합(AND)	여러 요소를 모두 포함해야 함 (AND 관계)
[]	선택(Option)	선택적으로 포함될 수 있음 (있어도 되고 없어도 됨)
{}	반복(Iteration)	0번 이상 반복될 수 있음
()	그룹(Grouping)	여러 요소를 하나의 그룹으로 묶을 때 사용
**	**	선택 OR (Exclusive OR)
*	주석(Comment)	설명을 추가할 때 사용 (주로 비공식 문서화용)

즉, 선택(Option) 의미는 [ ] 입니다.
(예를 들어 [중간이름] 이라면, 중간이름은 있어도 되고 없어도 된다는 뜻)

 

 

HIPO(Hierarchy Input Process Output)

HIPO(Hierarchy Input Process Output)는 소프트웨어 개발 과정에서 시스템의 논리적 구조를 문서화하고
개발자와 사용자 간의 의사소통을 원활하게 하기 위해 사용하는 도구입니다.

• HIPO는 하향식(Top-Down) 접근 방법을 사용합니다.
  (큰 기능을 점차 세분화하는 방식)
• HIPO 차트에는
  • 총체적 도표 (Overview Diagram)
  • 세부적 도표 (Detail Diagram)
  • 가시적 도표 (Visual Table of Contents)
    등이 있습니다.
• 기능과 데이터의 관계를 시각적으로 표현할 수 있습니다.
• 보기 쉽고 이해하기 쉬운 특징을 가집니다.

파이프 필터(Pipe-Filter)

📝 설명

• 파이프 필터(Pipe-Filter) 아키텍처는
  여러 개의 서브시스템이 입력 데이터를 받아 처리하고, 그 결과를 다음 서브시스템으로 넘겨주는 방식으로 동작합니다.
  각 서브시스템은 데이터를 필터처럼 처리하며, 그 결과는 파이프를 통해 전달됩니다.
• 구성
  • 데이터는 파이프(Pipe)를 통해 이동하고, 각 필터(Filter)는 데이터를 처리합니다.
  • 각 필터는 독립적으로 기능을 수행하며, 그 결과를 다음 필터로 전달합니다

🏗️ 파이프 필터 아키텍처의 예시

1. 텍스트 파일 처리 시스템

• 입력: 텍스트 파일
• 필터:
  • 필터 1: 파일에서 텍스트를 읽어들임.
  • 필터 2: 텍스트를 특정 형식으로 변환.
  • 필터 3: 변환된 텍스트를 출력 파일로 저장.
• 출력: 변환된 텍스트 파일

각 필터가 독립적으로 기능을 수행하고, 그 결과는 파이프를 통해 전달됩니다. 예를 들어, 한 필터가 텍스트를 읽고, 다음 필터가 해당 텍스트를 처리하는 방식입니다.

2. 오디오 프로세싱 시스템

• 입력: 오디오 데이터 (음성 파일)
• 필터:
  • 필터 1: 오디오 파일을 로드하고, 데이터 추출.
  • 필터 2: 오디오 데이터를 필터링하여 잡음 제거.
  • 필터 3: 데이터를 압축하여 저장.
• 출력: 처리된 오디오 파일

오디오 파일도 마찬가지로 각 필터가 데이터를 처리한 후, 파이프를 통해 결과를 전달합니다.

 

현행시스템 파악 절차

- 1단계(시스템 구성 파악 – 시스템 기능 파악 – 시스템인터페이스 현황 파악)
- 2단계(아키텍처 파악- 소프트웨어 구성 파악)
- 3단계(시스템 하드웨어 현황 파악 – 네트워크 구성 파악)

 

마스터-슬레이브 구조

마스터-슬레이브(Master-Slave) 구조는 분산 시스템이나 데이터베이스, 네트워크, 하드웨어 등 다양한 분야에서 사용되는 아키텍처 구조 중 하나입니다. 이 구조의 핵심 개념은 하나의 마스터가 여러 슬레이브를 제어하거나 명령을 전달하며, 슬레이브는 명령을 따르는 역할을 수행한다는 것입니다.

🔧 주요 특징

항목설명

역할 분리	마스터: 제어 및 관리, 슬레이브: 수행 및 응답
데이터 흐름	대부분 마스터 → 슬레이브 방향으로 일방향 통신
확장성	슬레이브를 추가하여 읽기 성능 등을 수평 확장 가능
단점	마스터 장애 시 전체 시스템 중단 위험 (단일 장애점)

💡 예시

1. 데이터베이스
   • 마스터: 쓰기 작업 수행 (INSERT, UPDATE 등)
   • 슬레이브: 읽기 전용 (SELECT 등), 마스터로부터 복제됨
   • 예: MySQL Replication
2. Redis
   • Redis Sentinel 또는 Cluster 모드에서 Master-Slave 구조 활용
3. 하드웨어
   • 하나의 컨트롤러(Master)가 여러 디바이스(Slave)를 제어하는 통신 구조 (예: I²C, SPI)
4. 멀티스레딩 시스템
   • 마스터 스레드가 작업을 분산하고 슬레이브 스레드들이 실행

✅ 장점

• 읽기 작업 분산 가능 → 성능 향상
• 단순한 구조 → 관리 용이
• 특정 슬레이브에 장애가 생겨도 전체 시스템에 영향이 적음

❌ 단점

• 마스터 장애 시 전체 시스템 장애
• 데이터 동기화 지연 가능성 (특히 데이터베이스 복제 시)
• 쓰기 작업은 분산이 어려움