소프트웨어 설계 2024 1회

TIL

소프트웨어 설계 2024 1회

ds3hfj 2025. 4. 30. 10:41

소프트웨어 설계

객체지향 분석 방법론 4가지

Coad와 Yourdon : 객체지향 분석 방법론 중 E-R 다이어그램을 사용하여 객체의 행위를 모델링하여, 객체 식별, 구조 식별, 주체 정의, 속성 및 관계 정의, 서비스 정의 등의 과정으로 구성되는것

Coad & Yourdon 방법

💡 핵심: E-R 다이어그램(개체-관계 모델) 기반으로 객체를 식별하고 모델링

원래 데이터베이스 모델링에서 쓰이던 E-R 다이어그램을 객체지향 분석에 응용한 방법이야.
객체를 **"무엇을 한다"보다는 "어떤 관계가 있는지"**를 중심으로 파악해.
분석 단계는 다음과 같아:

단계설명

객체 식별	이 시스템에서 중요한 객체가 뭐지? 예: 주문, 고객, 상품
구조 식별	이 객체들끼리는 어떤 계층 구조를 이루고 있지?
주체 정의	어떤 객체가 주도적으로 행동(서비스)을 하게 될까?
속성 및 관계 정의	각 객체는 어떤 정보를 갖고 있고, 서로 어떻게 연결되어 있을까?
서비스 정의	객체가 어떤 기능이나 행동을 할 수 있지?

📌 특징: 정적인 구조(데이터 관계) 중심으로 출발

Booch(부치) 방법 : 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용하는 분석 방법으로, 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의

Booch 방법 (부치)

💡 핵심: **큰 흐름(Macro)**과 세부 흐름(Micro) 둘 다 고려하는 정교한 분석법

UML 이전에 객체지향 모델링을 가장 체계화한 대표적인 사람 중 하나가 Grady Booch야.
분석은 다음과 같은 식으로 진행돼:

구분설명

Micro 프로세스	클래스, 속성, 연산 등 세부적인 구성 요소를 정리
Macro 프로세스	시스템 전반의 큰 흐름과 아키텍처 구조를 설계

클래스 식별 → 속성과 연산(메서드) 정의 → 관계 및 객체 간 상호작용 정의

📌 특징: 상세하게 분석하면서도 큰 그림도 함께 보는 방법론

Jacobson 방법 : Use Case를 강조하여 사용하는 분석 방법

Jacobson 방법

💡 핵심: **사용자의 입장(Use Case)**에서 분석을 시작하는 방식

지금은 거의 표준처럼 쓰이는 Use Case (유스케이스) 개념을 처음 체계화한 방법이야.
시스템을 만들 때 이렇게 생각해:

"사용자는 이 시스템에서 어떤 행동을 할까?"

예시:

고객은 "상품을 검색한다", "장바구니에 담는다", "결제한다"

이런 Use Case 하나하나를 중심으로 필요한 객체, 클래스, 흐름을 분석해.

📌 특징: 사용자 중심, 실생활 시나리오 중심의 분석법
→ 특히 UI/UX 흐름 잡을 때 좋음

Wirfs-Brock 방법 : 분석과 설계간의 구분이 없고, 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 기법

Wirfs-Brock 방법

💡 핵심: 분석과 설계를 따로 안 나눔 → 실무적이고 유연함

대부분 분석과 설계를 따로 나누는데, 이 방법은 그걸 연결해서 한 번에 처리함.
고객이 주는 명세서(요구사항)를 읽고 곧바로 설계 단계까지 넘어가.

주요 개념설명

책임 주도 설계	객체가 "무엇을 할 책임이 있는가?" 중심으로 구조 잡음
역할, 협력	객체가 어떤 역할을 맡고, 다른 객체랑 어떤 식으로 협력하는가?

예시:

"고객 객체는 주문을 생성할 책임이 있다"
"주문 객체는 결제 객체와 협력하여 결제를 처리한다"

📌 특징: 실제 동작하는 구조를 빠르게 만들고 싶을 때 적합한 방식

방법론 핵심 아이디어 특징

Coad & Yourdon	E-R 다이어그램 기반	정적인 구조 중심, 단계적으로 분석
Booch	Micro + Macro 프로세스	상세한 분석 + 전체 구조 설계
Jacobson	유스케이스 중심	사용자 시나리오 기반, 실용적
Wirfs-Brock	분석과 설계 통합	책임 기반 설계, 빠른 설계 연계

2. 분산 시스템이나 네트워크 기반 애플리케이션에서 사용되는 미들웨어 기술

1. 분산 시스템 (Distributed System)

여러 대의 컴퓨터가 하나의 시스템처럼 동작하도록 만든 구조

📦 예시:

구글 검색 서버: 수천 대의 컴퓨터가 동시에 돌아가면서 하나의 검색 결과를 보여줌
카카오톡 서버: 메시지를 보내면 여러 서버가 분산돼서 처리함

🧠 핵심 개념:

서버가 여러 대
작업을 나눠서 처리 (분산)
서로 통신하며 협력해서 하나처럼 동작

✅ 특징:

하나의 서버에 문제가 생겨도 전체 시스템은 계속 동작 가능 (장애 허용성)
확장성 좋음 (서버 추가로 성능 향상 가능)

🖧 2. 네트워크 기반 애플리케이션 (Network-based Application)

인터넷이나 네트워크를 통해 작동하는 프로그램

📦 예시:

웹 브라우저 (크롬, 사파리): 인터넷을 통해 웹 서버에 접속
이메일 앱: 메일 서버와 통신해서 메일 주고받음
온라인 게임: 서버랑 연결돼서 실시간 통신함

🧠 핵심 개념:

클라이언트(사용자)와 서버(중앙 시스템) 간의 통신이 필요
네트워크 없이는 제대로 동작하지 않음

✅ 특징:

반드시 인터넷/네트워크 연결이 필요
보통 클라이언트-서버 구조 사용

미들웨어란?

**운영체제(OS)**와 애플리케이션(프로그램) 사이에서 도와주는 역할을 하는 소프트웨어야.

한마디로:

"서로 다른 프로그램이나 컴퓨터끼리 잘 통신하고 일할 수 있게 중간에서 중재해주는 도우미"

RPC (Remote Procedure Call)
- 내 프로그램에서 다른 컴퓨터의 함수를 마치 내 로컬 함수처럼 호출할 수 있게 해주는 기술
- 예: A 컴퓨터에서 getUserInfo() 함수를 호출하면, 실제로는 B 서버에서 실행됨
- 트랜잭션 관리보다는 함수 호출을 네트워크로 보내는 기능에 초점
✅ 용도: 분산 시스템에서 서비스 간 통신 📞 "다른 컴퓨터에 있는 함수(프로시저)를 내 것처럼 호출"
ORB (Object Request Broker)
- 객체 지향 환경에서 네트워크를 통해 객체를 호출할 수 있게 해주는 중개자
- 예: 자바 객체가 다른 서버의 C++ 객체를 사용할 수 있음
- RPC보다 더 객체지향적인 통신을 제공
✅ 용도: 객체 간 원격 통신 (특히 이기종 환경) 🧩 "원격 객체 호출을 가능하게 해주는 미들웨어"
대표 예: CORBA
✅ TP Monitor (Transaction Processing Monitor)
- 여러 작업이 모여 있는 트랜잭션이 올바르게 처리되도록 감시, 관리, 복구하는 역할
- 예: 은행 시스템에서 입금과 이체를 하나의 트랜잭션으로 처리하고, 문제가 생기면 전부 취소(rollback)
특징:
- 트랜잭션 상태 감시
- 실패 시 rollback, 성공 시 commit
- 동시 사용자 요청 처리 (부하 분산)
✅ 정답: 너가 말한 “트랜잭션이 올바르게 처리되고 있는지 감시하고 제어하는 미들웨어”는 TP Monitor야💼 "트랜잭션 처리를 감시하고 제어하는 미들웨어"
HUB
- TCP/IP에서 여러 장비를 물리적으로 연결하는 장치
- 데이터를 받으면 모든 포트에 똑같이 보내는 단순한 구조
- 요즘은 허브 대신 스위치를 많이 써
❌ 이건 미들웨어가 아니라 하드웨어에 가까운 개념 📡 "네트워크 장비의 한 종류로, 단순히 신호를 보내주는 장치"

3. 자료 흐름도(Data Flow Diagram)

자료 흐름도란?

시스템에서 데이터가 어떻게 흐르는지를 그림으로 나타낸 것이야.

즉,

"누가 데이터를 보내고, 그 데이터가 어디로 가서, 무엇을 처리해서, 어디에 저장되는지"를 보여주는 그림 도구야.

왜 쓰는 거야?

프로그램 만들기 전에 데이터 흐름을 먼저 이해하기 위해 사용
분석가나 기획자가 시스템 전체 구조를 쉽게 설명할 수 있어

🧱 자료 흐름도의 4가지 기본 요소

기호이름설명

⬜	프로세스(Process)	데이터를 처리하는 작업 (예: 주문 처리)
📤📥 화살표	데이터 흐름(Data Flow)	데이터가 어디에서 어디로 이동하는지 표시
🟦	자료 저장소(Data Store)	데이터를 임시로 저장하는 장소 (예: DB, 파일)
⭕	외부 개체(단말)(Terminator)	시스템 바깥에서 데이터를 주고받는 대상 (예: 사용자, 다른 시스템)

예시로 이해해보자

"사용자가 상품을 주문하면, 시스템이 주문 정보를 저장한다"

자료 흐름도로 그리면 이렇게 돼:

[사용자] ⟶ (주문 처리) ⟶ [주문 DB]

⭕ 사용자: 외부 개체
➡ 주문 정보: 데이터 흐름
🔲 주문 처리: 프로세스
🟦 주문 DB: 자료 저장소

4. 객체지향에서 정보 은닉과 가장 밀접한 관계가 있는것은?

객체지향 핵심 개념

용어 설명

캡슐화 (Encapsulation)	- 데이터(속성)와 메서드(기능)를 하나의 단위(객체)로 묶는 것- 자료 은닉(정보 은폐)과 밀접한 관련이 있음👉 외부에서 직접 접근하지 못하게 하고, 인터페이스로만 접근 가능하게 함
클래스 (Class)	- 객체를 생성하기 위한 설계도 또는 틀- 유사한 객체들을 하나로 묶어, 공통 속성과 동작을 정의함
객체 (Object)	- 클래스에서 생성된 구체적인 실체- 클래스에 정의된 속성과 메서드를 실제로 가지고 있음
인스턴스 (Instance)	- 특정 클래스에서 생성된 개별 객체👉 즉, "객체 = 인스턴스", 같은 의미지만 문맥상 '클래스에서 만들어졌음'을 강조할 때 인스턴스라는 용어 사용
메서드 (Method)	- 클래스에 정의된 동작 또는 함수- 객체가 메시지를 받았을 때 수행할 구체적인 연산👉 객체의 상태(속성)를 조회하거나 변경하는 수단

5. 자료 사전(Data Dictionary)에서 선택의 의미를 나타내는 것

[]	선택 (Optional)	자료가 있을 수도 있고, 없을 수도 있음예: [우편번호]
{}	반복 (Repetition)	0회 이상 반복됨 (배열처럼)예: {상품} = 여러 개의 상품
=	정의 (Definition)	자료 구성을 설명할 때 사용예: 주소 = 도로명 + 건물번호
+	연결 (Concatenation)	자료가 순서대로 이어짐예: 이름 = 성 + 이름
()	그룹 (Grouping)	괄호 안을 하나의 그룹으로 묶음예: {(상품명 + 가격)}
`	`	선택 항목 (Or)
' ' 또는 " "	리터럴/고정값	고정된 문자값 표현예: 'Y', 'N'
/* 설명 */	주석	설명을 달 때 사용

6. 소프트웨어 개발단계에서 요구 분석 과정에 대한 설명으로 거리가 먼것

분석 결과의 문서화를 통해 향후 유지보수에 유용하게 활용 할 수 있다
개발 비용이 가장 많이 소요되는 단게이다
자료흐름도, 자료 사전 등이 효과적으로 이용될 수 있다
보다 구체적인 명세를 위해 소단위 명세서(Mini-Spec)가 활용 될 수 있다

소프트웨어 개발은 체계적인 절차에 따라 진행되는데, 그 과정을 **"소프트웨어 개발 생명주기(SDLC: Software Development Life Cycle)라고함

1️⃣ 요구 분석 (Requirement Analysis)

무엇을 만들 것인지 정하는 단계

고객(사용자)의 요구사항을 수집하고 정리
시스템이 어떤 기능을 가져야 하고, 어떤 제약이 있는지를 명확히 문서화

✅ 특징:

사용자 인터뷰, 회의, 관찰 등을 통해 정보 수집
자료 흐름도(DFD), 자료 사전, Mini-spec 등을 이용해 요구 명세
결과물: 요구사항 명세서(SRS)

2️⃣ 설계 (Design)

무엇을 어떻게 만들지 구조를 짜는 단계

요구사항을 바탕으로 시스템의 **전체 구조(아키텍처)**를 설계
UI, DB 설계, 모듈 간 인터페이스, 클래스 구조 등 정의

✅ 특징:

논리 설계와 물리 설계로 나눔
결과물: 설계서, 다이어그램(UML, ERD 등)

3️⃣ 구현 (Implementation / Coding)

실제로 코드를 작성하는 단계

설계서를 바탕으로 프로그래머들이 실제 소스코드를 작성
팀 단위로 모듈을 나눠서 병렬 개발도 가능

✅ 특징:

IDE, 프로그래밍 언어, 라이브러리 등 활용
결과물: 소스코드, 빌드된 실행 파일

4️⃣ 테스트 (Testing)

제대로 동작하는지 확인하는 단계

구현된 소프트웨어가 요구사항에 맞게 동작하는지 검증
유닛 테스트, 통합 테스트, 시스템 테스트, 사용자 테스트 등 수행

✅ 특징:

버그 발견, 요구사항 누락 확인
결과물: 테스트 보고서, 결함 목록

5️⃣ 배포 및 운영 (Deployment & Operation)

사용자 환경에 배포하고 실제로 사용하는 단계

사용자 환경에 설치하거나 배포하여 실제 서비스 시작
클라우드, 온프레미스, 앱스토어 등 다양한 방식 가능

✅ 특징:

설치, 초기화 작업, 사용자 교육 등 수행
결과물: 운영 환경 구축 완료, 사용자 피드백 수집

6️⃣ 유지보수 (Maintenance)

문제 수정 또는 기능 개선하는 단계

실제 운영 중 생기는 버그 수정, 기능 추가, 성능 개선
사용자 요구나 환경 변화에 맞춰 지속적으로 수정

✅ 특징:

가장 비용이 많이 드는 단계
예방 보수, 수정 보수, 적응 보수 등 유형 존재

전체 흐름 요약

단계 주요 질문 핵심 활동 결과물

요구 분석	무엇을 만들까?	요구사항 수집/정리	요구사항 명세서
설계	어떻게 만들까?	구조/DB/UI 설계	설계서, 다이어그램
구현	실제로 만들기	소스코드 작성	코드, 바이너리
테스트	잘 작동하나?	오류 검증	테스트 보고서
배포	사용자에게 주기	설치 및 환경 세팅	운영 시작
유지보수	계속 쓸 수 있게	버그 수정, 개선	패치, 업데이트

1. Object Modeling (객체 모델링)

시스템 안에 **무슨 객체(사물/개념)**들이 있고, 어떻게 관계되어 있는지를 그리는 것

예시:

“학생”, “강의”, “교수” 같은 객체
학생은 강의를 수강하고, 교수는 강의를 진행함

핵심:

객체(클래스), 속성, 관계(연관, 상속 등)
UML 클래스 다이어그램이 대표 예

🔁 2. Dynamic Modeling (동적 모델링)

시간 흐름이나 이벤트 발생에 따라 시스템이 어떻게 바뀌는지 나타내는 것

예시:

사용자가 “로그인 버튼 클릭” → “로그인 성공” → “메인 화면으로 이동”

핵심:

상태(state), 이벤트, 상태 전이
대표 다이어그램: 상태도(State Diagram), 시퀀스 다이어그램(Sequence Diagram)

⚙️ 3. Functional Modeling (기능 모델링)

시스템이 어떤 기능을 제공하는지, 입력과 출력이 어떻게 되는지를 표현하는 것

예시:

"사용자가 주문하면 → 주문 처리 → 재고 확인 → 결제 요청"

핵심:

데이터가 어떻게 흐르는지, 어떤 처리 단계를 거치는지
대표 도구: 자료 흐름도(DFD)

🧊 4. Static Modeling (정적 모델링)

시스템의 구조적 측면에 집중한 모델링
(= 보통 Object Modeling과 거의 같은 의미로 쓰임)

예시:

어떤 클래스가 있고, 그 클래스가 어떤 속성과 메서드를 가지고 있으며, 어떤 관계로 연결되어 있는지

핵심:

클래스, 속성, 관계, 구조
클래스 다이어그램, 객체 다이어그램 등

📌 즉, Object Modeling ⊆ Static Modeling으로 볼 수 있어

but

럼바우(Rumbaugh) 분석기법이란?

**객체(Object), 동작(Dynamic), 기능(Function)**을 각각 따로 분석해서 시스템을 설계하는 객체지향 분석 기법이야.

즉, 복잡한 시스템을 세 가지 관점에서 나눠서 분석하고 이해하자는 거지.

🧱 3가지 주요 모델

모델설명대표 다이어그램

객체 모델(Object Model)	시스템에 존재하는 객체들, 그들의 속성과 관계를 표현	클래스 다이어그램
동적 모델(Dynamic Model)	시스템이 시간의 흐름이나 이벤트에 따라 어떻게 변하는지 표현	상태도(State Diagram), 시퀀스 다이어그램
기능 모델(Functional Model)	시스템이 무슨 기능을 수행하고, 데이터는 어떻게 흐르는지 표현	자료 흐름도(DFD)

왜 쓰는 거야?

시스템을 여러 측면에서 나눠서 보기 때문에 더 정확하게 이해 가능
분석 → 설계 → 구현까지 객체 기반으로 연결되기 쉬움
복잡한 시스템도 잘게 나눠서 설명 가능

📌 예를 들어보자: “온라인 쇼핑몰”

모델예시

객체 모델	회원, 상품, 주문 같은 클래스와 관계 (회원은 주문을 한다 등)
동적 모델	회원이 로그인 → 장바구니 담기 → 결제처럼 이벤트에 따른 상태 변화
기능 모델	주문을 처리하기 위해 재고 확인 → 결제 요청 → 배송 지시 같은 기능 흐름 표현

✅ 특징 요약

James Rumbaugh가 만든 대표적 객체지향 분석 기법
**OMT (Object Modeling Technique)**라고도 함
객체 중심이지만, **정적(구조), 동적(행동), 기능(처리)**을 모두 분석함

8. UML(Unified Modeling Language)에 대한 설명 중 틀린것은?

**UML (Unified Modeling Language)**는
소프트웨어 시스템을 시각적으로 표현하는 표준화된 그림 언어야.

쉽게 말하면,

"개발자들이 **그림(다이어그램)**으로 시스템 구조나 동작을 같은 방식으로 표현하기 위해 만든 공통 언어"

💡 왜 필요한데?

말로 설명하면 사람마다 다르게 이해할 수 있어.
UML은 "그림"으로 정확하게 표현하니까 팀원들끼리 오해 없이 소통 가능!
객체지향 시스템을 설계할 때 클래스, 관계, 동작, 흐름 등을 표준화된 기호로 표현함.

🧱 UML로 그릴 수 있는 대표적인 다이어그램

분류다이어그램설명

구조(정적)	클래스 다이어그램	클래스, 속성, 메서드, 관계
	객체 다이어그램	실제 객체들의 상태 예시
	컴포넌트 다이어그램	소프트웨어 구성 요소 (모듈) 간 연결
	배치 다이어그램	시스템의 실제 물리적 배치 (서버, DB 등)
행동(동적)	시퀀스 다이어그램	객체들 간 메시지 주고받는 순서
	상태 다이어그램	객체의 상태 변화 표현
	활동 다이어그램	작업 흐름도처럼 로직 흐름 표현
	유스케이스 다이어그램	사용자가 시스템을 어떻게 사용하는지

UML에서 기능적 모델로 쓰이는 대표 다이어그램

유스케이스 다이어그램 (Use Case Diagram)	사용자가 시스템을 어떻게 사용하는지 기능 단위로 표현	"무슨 기능이 있는가?"를 한눈에 파악 가능
활동 다이어그램 (Activity Diagram)	기능의 실행 흐름을 순서대로 표현	"기능이 어떤 순서로 동작하는가?"를 흐름도처럼 표현
상호작용 다이어그램 (Sequence Diagram 등)	객체들 간 메시지 흐름을 시간 순으로 표현	기능 수행 시 어떤 객체가 어떤 역할을 하는지 보여줌

🔄 다른 객체지향 분석 방법들과의 관계

방법론주요 특징

럼바우(OMT)	세 가지 모델(객체, 동적, 기능)로 나눠 분석
Booch 방법	클래스/객체의 구조 및 동작 강조, 미시/거시 설계
Jacobson 방법	유스케이스 기반 분석에 특화
Coad & Yourdon	객체 간 관계 분석에 중점

📌 나중에 이 모든 방법이 통합되어 지금의 UML 표준이 탄생했어.
그중 럼바우는 UML의 핵심 설계자 3인방 중 한 명이기도 해 (Booch, Jacobson, Rumbaugh).

9. 사용자 인터페이스(UI)의 특징으로 틀린것은?

구현하고자 하는 결과의 오류를 최소화
사용자의 편의성을 높임으로써 작업시간을 증가시킴
막연한 작업 기능에 대해 구체적인 방법을 제시
사용자 중심의 상호작용이 되도록 함

사용자 인터페이스(UI)란?

사람(사용자)과 시스템(컴퓨터, 웹, 앱 등)이 서로 소통하는 방식을 말해.

📱 UI의 예

웹사이트의 버튼, 입력창, 메뉴
스마트폰 앱의 화면 구성
ATM 기기의 화면 + 버튼 조작

✅ UI의 주요 특징

특징설명

편의성	사용자가 쉽게 배울 수 있고, 실수 없이 사용할 수 있도록 함
직관성	처음 보는 사람도 무엇을 해야 하는지 직관적으로 이해 가능
일관성	동일한 패턴과 흐름을 유지해 혼란을 줄임
피드백 제공	사용자의 행동에 대해 시스템이 반응을 보여줌 (예: 클릭 시 색이 바뀜)
작업 시간 단축	사용자가 더 빠르게 원하는 작업을 할 수 있게 함

📌 정리

틀린 보기: 사용자의 편의성을 높이면 작업 시간은 줄어들어야지, 늘어나면 안 됨.
**사용자 인터페이스(UI)**는 시스템과 사람이 상호작용하는 접점이고,
이를 더 쉽고 빠르게 만들기 위한 기술/디자인 요소야.

UI vs UX 차이 한눈에 보기

항목UI (User Interface)UX (User Experience)

뜻	사용자 인터페이스	사용자 경험
중심 내용	화면, 버튼, 디자인 요소	느낌, 편리함, 전체 경험
예시	버튼 색, 폰트, 메뉴 배치	사용자가 앱을 얼마나 쉽게 사용하고 만족했는가
관점	보이는 것에 집중	겪는 것에 집중
목표	보기 쉽고 누르기 쉬운 화면 만들기	사용자가 기분 좋고 편하게 작업하도록 만들기

🔍 쉽게 말하면?

UI는 **"문을 어떻게 생기게 만들었냐"**에 해당해.
예: 손잡이는 누르기 쉽게? 버튼은 색이 눈에 띄게?
UX는 **"그 문을 여는 경험이 어땠냐"**야.
예: 문을 열었는데 뻑뻑해서 짜증났어 vs 부드럽게 잘 열렸어!

📱 실제 앱에서 예시

🟥 UI:

버튼 색깔은 눈에 띄게 되어 있어?
메뉴가 보기 좋게 정렬돼 있어?
폰트가 읽기 쉬워?

🟩 UX:

회원가입은 복잡하지 않았어?
앱이 너무 느려서 짜증나진 않았어?
원하는 기능을 찾기 쉽고 빠르게 했어?

✅ 요약 한 줄

🔹 UI = 사용자가 보는 화면과 조작 요소
🔸 UX = 사용자가 느끼는 전체적인 만족감

10. Gof(Gangs of Four) 디자인 패턴에 대한 설명으로 틀린것은?

Factory Method Pattern은 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위클래스에서 인스턴스를 생성하도록하는 방식
Prototype Pattern은 Prototype을 먼저 생성하고 인스턴스를 복제하여 사용하는 구조
Bridge Pattern은 기존에 구현되어 있는 클래스에 기능 발생 시 기존 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할
Mediator Pattern은 객체간의 통제와 지시의 역할을 하는 중재자를 두오 객체지향의 목표를 달성하게 해줌

GoF 디자인 패턴이란?

**GoF(Gang of Four)**는 4명의 컴퓨터 과학자 (Gamma, Helm, Johnson, Vlissides)가 쓴
『Design Patterns: Elements of Reusable Object-Oriented Software』 책에서 나온 23가지 디자인 패턴을 말해.

이 패턴들은 객체지향 프로그래밍에서 재사용 가능한 코드 구조를 설계하기 위한 표준적인 해법이야.

🎯 GoF 디자인 패턴 3분류

분류설명대표 예시

생성(Creational)	객체를 어떻게 생성할 것인가에 대한 패턴	Factory Method, Singleton, Prototype
구조(Structural)	클래스나 객체를 어떻게 구성할 것인가	Adapter, Bridge, Composite
행위(Behavioral)	객체 간의 상호작용 방식을 정의	Observer, Mediator, Strategy

🧠 보기별 검토

보기설명맞는지 여부

✅ Factory Method Pattern	상위 클래스는 객체 생성 인터페이스만 정의, 실제 생성은 하위 클래스가 처리	✔ 맞음
✅ Prototype Pattern	복제(clone) 기반 객체 생성. 원형(프로토타입)을 만들어 복사함	✔ 맞음
❌ Bridge Pattern	기능과 구현을 분리하여 독립적으로 확장할 수 있게 함 → 중간에서 맞춰주는 역할은 Adapter임	❌ 틀림
✅ Mediator Pattern	객체 간 직접 통신 대신 중재자(Mediator)를 통해 통제/조율 → 결합도 낮춤	✔ 맞음

✅ 정리

항목설명

정답	❌ "Bridge Pattern은 기존 클래스에 맞춰주는 역할"
올바른 Bridge 개념	추상과 구현을 분리하여 독립적으로 변경/확장 가능
GoF란?	객체지향 설계에서 자주 쓰이는 23가지 디자인 패턴 모음집

📘 GoF 디자인 패턴 23가지 정리표

🔨 1. 생성(Creational) 패턴

객체를 어떻게 만들고 생성 과정을 캡슐화할지에 중점

패턴목적한 줄 설명

Singleton	단 하나의 인스턴스만 존재	전역에서 하나만 생성되도록 보장
Factory Method	객체 생성 책임을 하위 클래스에 위임	객체 생성을 서브클래스에게 맡김
Abstract Factory	관련 객체를 묶어서 생성	서로 관련된 객체들을 일관되게 생성
Builder	복잡한 객체를 단계적으로 생성	동일한 생성 절차로 다양한 객체 생성
Prototype	기존 객체를 복제	원형을 복제하여 객체를 생성 (clone)

🧱 2. 구조(Structural) 패턴

클래스나 객체 구성을 유연하고 확장 가능하게 만들기

패턴목적한 줄 설명

Adapter	인터페이스 호환	기존 클래스를 클라이언트 요구에 맞게 변환
Bridge	추상과 구현 분리	기능과 구현을 독립적으로 확장
Composite	트리 구조 표현	전체-부분 관계를 트리처럼 표현
Decorator	기능 추가	기존 객체에 기능을 동적으로 추가
Facade	단순한 인터페이스 제공	복잡한 시스템에 단순한 인터페이스 제공
Flyweight	메모리 절약	공유 객체로 메모리 사용 최적화
Proxy	대리 객체 제공	접근 제어나 지연 로딩을 위한 대리 객체

🔁 3. 행위(Behavioral) 패턴

객체 간의 상호작용, 책임 분배에 중점

패턴목적한 줄 설명

Observer	이벤트 알림	한 객체 상태 변화 → 여러 객체에 알림
Strategy	알고리즘 교체	알고리즘을 런타임에 변경 가능
Template Method	공통 알고리즘 골격 정의	특정 단계는 하위 클래스에서 구현
Command	요청을 객체로 캡슐화	요청을 나중에 실행하거나 저장 가능
State	상태에 따른 동작 변경	객체 상태에 따라 동작이 달라짐
Visitor	구조는 그대로, 기능만 추가	구조 변경 없이 새로운 연산 추가
Mediator	객체 간 복잡한 관계 조정	중재자 객체를 통해 간접 소통
Iterator	순차적 접근	내부 구조를 노출하지 않고 순회
Chain of Responsibility	요청 처리 책임 분산	처리 객체를 체인처럼 연결
Interpreter	언어 해석	문법 규칙을 해석하고 실행
Memento	상태 저장/복원	객체의 이전 상태를 보관하고 복원

11. 익스트림 프로그래밍(XP)에 대한 설명으로 틀린 것은?

빠른 개발을 위해 테스트를 수행하지 않는다
사용자의 요구사항은 언제든지 변할 수 있다
고객과 직접 대면하며 요구사항을 이야기하기 위해 사용자스토리(User Story)를 활용할 수 있다
기존의 방법론에 비해 실용성(Pragmatism)을 강조한 것이라고 볼 수 있다

익스트림 프로그래밍(XP)이란?

**"변화에 유연하게 대응"하고,
"고객과의 소통을 강화"하면서,
**"짧은 주기로 빠르게 소프트웨어를 개발"**하는
애자일(Agile) 개발 방법론 중 하나야.

즉,

“요구사항이 자주 바뀌는 환경에서 개발을 잘 해보자!”
는 현실적인 철학을 담고 있는 방법이야.

🎯 XP의 핵심 목표

빠른 피드백
변화 수용
고객과 긴밀한 협력
지속 가능한 개발 속도 유지

🧱 XP의 주요 특징 (12가지 실천 항목 중 핵심만)

특징설명

반복 개발 (Iterative)	1~2주 단위로 소프트웨어를 자주 릴리즈
고객 참여 (On-site Customer)	고객이 팀에 항상 상주, 요구 변경을 즉시 반영
테스트 우선 (Test-First / TDD)	코딩 전에 테스트 코드를 먼저 작성함 (Test Driven Development)
페어 프로그래밍 (Pair Programming)	두 명이 짝을 이뤄 하나의 코드 작성: 한 명은 코딩, 한 명은 감시/설계
지속적 통합 (CI)	코드를 자주 합치고, 문제를 즉시 해결
단순한 설계	현재 요구만 반영한 가장 단순한 설계 추구 (YAGNI: You Aren’t Gonna Need It)
리팩토링 (Refactoring)	기능은 유지하면서 코드를 더 깔끔하게 정리

XP의 12가지 실천 항목 (12 Practices of XP)

번호항목설명

1️⃣	소규모 릴리즈 (Small Releases)	자주 릴리즈해서 고객이 자주 피드백을 줄 수 있도록 함. 보통 1~2주 단위로 반복
2️⃣	짝 프로그래밍 (Pair Programming)	두 명이 짝을 지어 하나의 컴퓨터에서 함께 코딩: 한 명은 작성, 다른 한 명은 감시 및 설계 검토
3️⃣	테스트 우선 개발 (Test-First Programming / TDD)	코드를 작성하기 전에 테스트 코드를 먼저 작성. 테스트를 통해 코드 품질 확보
4️⃣	지속적인 통합 (Continuous Integration)	여러 개발자가 자주 코드를 병합하고, 통합 시마다 자동으로 테스트 실행
5️⃣	리팩토링 (Refactoring)	기능은 그대로 유지하면서 코드를 더 깔끔하고 단순하게 개선
6️⃣	전체 팀 (Whole Team / On-Site Customer)	고객이 개발 팀에 상주하거나 자주 협력하여 빠르게 피드백 주고 요구사항을 조율
7️⃣	메타포(Metaphor)	시스템 전체 구조를 직관적인 비유로 설명함 (예: "이 시스템은 우체국처럼 작동한다")
8️⃣	단순한 설계 (Simple Design)	현재 요구에 필요한 최소한의 설계만 적용 (과잉 설계 지양)
9️⃣	코딩 표준 (Coding Standards)	팀 전체가 통일된 코딩 스타일과 규칙을 사용해 협업 효율 향상
🔟	공유 코드 (Collective Code Ownership)	모든 팀원이 모든 코드에 접근, 수정 가능 → 내 코드/네 코드 구분 없음
1️⃣1️⃣	지속 가능한 속도 (Sustainable Pace / 40-Hour Week)	과로 없이 지속 가능한 개발 속도 유지 (주 40시간 근무 권장)
1️⃣2️⃣	고객의 수용 테스트 (Customer Acceptance Tests)	고객이 직접 요구사항 기반 테스트를 정의하고 확인 → 요구 충족 여부 검증

📦 예시로 보면

예: 2주짜리 개발 스프린트를 반복하면서

고객이 옆에서 계속 피드백 주고

테스트를 먼저 작성해서 버그를 줄이고

둘이 짝지어서 코딩하고

매일 아침 짧게 회의하며 상황 공유

이게 바로 XP 방식이야.

✅ XP의 장점

고객 요구가 바뀌어도 유연하게 대처 가능
테스트 중심으로 품질이 높고 안정적
짧은 반복 주기로 빠른 결과물을 확인 가능
개발자끼리 협업도 강화

❗주의할 점

고객 참여가 현실에서 어렵다면 효과 떨어짐
짝 프로그래밍이나 테스트 선 작성은 팀 문화가 따라줘야 효과 있음

📌 한줄 요약

**익스트림 프로그래밍(XP)**은
"작게 만들고, 자주 테스트하고, 고객과 항상 소통하며, 빠르게 개선하는"
실용적이고 유연한 개발 방법론이야.

12. 대표적으로 DOS 및 Unix 등의 운영체제에서 조작을 위해 사용하던 것으로 정해진 명령 문자열을 입력하여 시스템을 조작하는 사용자 인터페이스(User Interface)는?

용어 풀네임 설명 예시

GUI	Graphical User Interface	마우스와 아이콘 등 그래픽으로 조작	윈도우, macOS, 안드로이드
CLI	Command Line Interface	명령어를 직접 입력해서 조작	DOS, Linux 터미널, CMD
CUI	Character User Interface(또는 Console UI)	문자 기반 메뉴로 조작CLI와 혼용되기도 함	텍스트 메뉴 기반 설치 프로그램, ncurses 앱
MUI	Multilingual User Interface	하나의 프로그램에 다국어 지원 UI 포함	윈도우에서 언어 설정 바꾸면 UI도 언어 변경됨

추가로

NUI란?

**NUI (Natural User Interface)**는
사용자가 자연스럽게 행동하는 것만으로
시스템을 조작할 수 있는 인터페이스야.

즉,

"말하거나 손짓하거나 만지는 것만으로 컴퓨터가 알아서 인식하고 반응하는 방식"이야.

13. UML 다이어그램 중 정적 다이어그램이 아닌 것은?

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

다이어그램설명

클래스 다이어그램 (Class Diagram)	클래스 간 관계, 속성, 메서드 표현
객체 다이어그램 (Object Diagram)	특정 시점의 객체 상태와 관계 표현
컴포넌트 다이어그램 (Component Diagram)	모듈 단위 구성 요소들의 구조 표현
배치 다이어그램 (Deployment Diagram)	실제 하드웨어와 소프트웨어 배치 구조 표현
패키지 다이어그램 (Package Diagram)	클래스나 컴포넌트를 그룹으로 묶어서 표현
프로파일 다이어그램 (Profile Diagram)	UML 확장을 위한 메타 정보 표현 (특수 목적)
복합 구조 다이어그램 (Composite Structure Diagram)	클래스 내부 구조 표현 (내부 파트 간 상호작용)

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

다이어그램설명

유스케이스 다이어그램 (Use Case Diagram)	사용자가 시스템을 사용하는 기능 중심 표현
시퀀스 다이어그램 (Sequence Diagram)	객체 간 메시지 교환 순서 표현
커뮤니케이션 다이어그램 (Communication Diagram)	객체 간 상호작용을 네트워크형 구조로 표현
상태 다이어그램 (State Diagram)	객체 상태 변화 표현 (동적 상태 모델링)
활동 다이어그램 (Activity Diagram)	작업 흐름 표현 (업무/프로세스 흐름도)
타이밍 다이어그램 (Timing Diagram)	시간 축을 중심으로 상태 변화 표현 (실시간 시스템에 유용)

14. 다음에서 설명하는 UI 설계 도구는?

디자인, 사용 방법 설명, 평가 등을 위해 실제 화면과 유사하게 만든 정적인 형태의 모형

시각적으로만 구성 요소를 배치하는 것으로 일반적으로 실제로 구현되지는 않음

항목

와이어프레임(Wireframe)

목업(Mockup)

프로토타입(Prototype)

스토리보드(Storyboard)

유스케이스(Use Case)

정의	UI 요소 배치만 간단히 표현한 뼈대 스케치	실제 디자인처럼 보이는 정적 시안	실제 동작처럼 구현된 인터랙션 모델	화면 흐름을 순서대로 설명한 시나리오	사용자의 목표와 시스템 간 상호작용 정의
기능 구현 여부	❌ 없음	❌ 없음	✅ 있음 (제한적)	❌ 없음	❌ 없음
디자인 완성도	낮음 (선, 사각형 등 단순)	높음 (실제처럼 생김)	매우 높음 (실제 앱처럼 작동)	중간 (흐름 중심)	낮음 (기능 중심 문서)
주요 목적	레이아웃 구성, 정보 구조 정의	시각적 디자인 미리보기	사용자 흐름 테스트, 피드백 수집	UI 동선 설명, 관계자 공유	시스템 요구사항 모델링
사용 시점	기획 초기	기획 중반~후반	구현 전 검증	기획 초기~중반	요구사항 분석 초기
사용자 테스트 가능 여부	❌	❌	✅	△ 흐름 파악은 가능	❌

15. 요구사항 분석에서 비기능적(Nonfunctional) 요구에 대한 설명으로 옳은 것은

시스템의 처리량(Throughput), 반응 시간 등의 성능 요구나 품질 요구는 비기능적 요구에 해당하지 않는다
차량 대여 시스템이 제공하는 모든 화면이 3초 이내에 사용자에게 보여야한다는 비기능적 요구이다
시스템 구축과 관련된 안전, 보안에 대한 요구사항들은 비기능적 요구에 해당하지 않는다
금융 시스템은 조회 인출 입금 송금의 기능이 있어야 한다는 비기능적 요구이다

보기 해설 옳고 그름

① 시스템의 처리량, 반응 시간 등의 성능 요구는 비기능적 요구가 아니다	❌ 성능(처리량, 응답 시간)은 대표적인 비기능적 요구임
② 차량 대여 시스템이 제공하는 모든 화면이 3초 이내에 사용자에게 보여야 한다	✅ 응답 시간은 전형적인 비기능적 요구사항
③ 안전, 보안에 대한 요구사항들은 비기능적 요구가 아니다	❌ 보안, 안전 역시 비기능적 요구에 해당
④ 금융 시스템은 조회, 인출, 입금, 송금의 기능이 있어야 한다	❌ 이건 기능적 요구다 (무슨 기능을 제공해야 하는가)

📘 비기능적 요구사항 (Nonfunctional Requirements)란?

시스템이 어떻게 동작해야 하는지에 대한 요구
→ 즉, 품질, 성능, 보안, 사용성 등과 관련된 요구사항

📌 기능적 요구 vs 비기능적 요구

구분설명예시

기능적 요구	시스템이 무엇을 해야 하는지	로그인 기능, 송금 기능
비기능적 요구	시스템이 어떻게 동작해야 하는지	3초 이내 응답, 99.9% 가용성, 보안 등

✅ 비기능 요구 예시

성능: 응답 시간은 2초 이내여야 함
보안: 로그인은 2단계 인증을 거쳐야 함
사용성: 모바일 환경에서도 사용 가능해야 함
신뢰성: 연속 운영 가능 시간 99.9%
확장성: 사용자 수 증가에 따라 시스템이 확장 가능해야 함

16. 명백한 역할을 가지고 독립적으로 존재할 수 있는 시스템의 부분으로 넓은 의미에서는 재사용되는 모든 단위라고 볼 수 있으며, 인터페이스를 통해서만 접근할 수 있는것은?

Model
Sheet
Component
Cell

Component(컴포넌트)란?

독립적인 기능을 수행하는 소프트웨어의 모듈/단위로,
외부에서는 오직 인터페이스를 통해서만 접근할 수 있으며,
재사용 가능하고, 유지보수에 유리한 구조를 가진 요소

컴포넌트의 핵심 특징

특징설명

독립성	컴포넌트는 다른 컴포넌트와 결합 없이 단독 동작 가능
인터페이스 접근	내부 구현은 숨기고, 정해진 인터페이스를 통해서만 접근 가능
재사용성	여러 프로젝트에서 재사용 가능
모듈화	유지보수, 테스트, 배포가 쉬움
은닉화	내부 로직은 외부에서 보이지 않음 (캡슐화)

용어 설명 주로 쓰이는 분야

Model	- 시스템의 데이터와 비즈니스 로직을 표현하는 구조- 예: 사용자의 정보, 계좌 정보, 계산 로직 등- 보통 MVC(Model-View-Controller) 패턴에서 사용됨	웹/모바일 개발 (MVC), 소프트웨어 설계
Sheet	- UI 구성 단위로 사용되며, 엑셀이나 문서에서의 작업 페이지(시트)- 또는 iOS 등에서는 전체 화면을 덮는 화면 레이어(Modal Sheet)로도 사용됨	엑셀, UI 디자인(iOS 등)
Cell	- 표나 그리드의 가장 작은 단위 (예: 엑셀 셀)- 또는 메모리 구조에서의 기본 저장 단위- 또는 테이블 뷰에서 하나의 행을 의미하기도 함	엑셀, 메모리 구조, iOS 테이블 UI 등
Component	- 독립적인 기능 단위, 재사용 가능, 인터페이스로 접근- UI, 서비스, 라이브러리 등으로 구성됨	웹, 앱, 마이크로서비스, 설계

17. 다음 중 SOLID 원칙이라고 불리는 객체지향 설계 원칙에 속하지 않는 것은

약어 이름 한 줄 요약 쉽게 설명

S	단일 책임 원칙 (Single Responsibility Principle)	클래스는 하나의 책임(기능)만 가져야 한다	하나의 클래스는 딱 한 가지 이유로만 변경돼야 함📌 예: Order는 주문 처리만, Invoice는 청구서 발급만
O	개방-폐쇄 원칙 (Open/Closed Principle)	확장에는 열려 있고, 수정에는 닫혀 있어야 한다	기능을 추가할 수는 있어야 하지만, 기존 코드는 건드리지 말아야 함📌 예: 새로운 결제 방식 추가할 때 기존 코드 수정 없이 확장
L	리스코프 치환 원칙 (Liskov Substitution Principle)	자식 클래스는 부모 클래스를 대체할 수 있어야 한다	부모 타입으로 선언된 객체에 자식 객체를 넣어도 문제 없이 동작해야 함📌 예: Bird 대신 Penguin을 넣었더니 fly() 호출하면 에러 나면 위반
I	인터페이스 분리 원칙 (Interface Segregation Principle)	필요한 기능만 인터페이스로 제공해야 한다	사용하지 않을 기능까지 포함된 인터페이스는 안 됨📌 예: 사자는 수영() 필요 없음 → 동물 인터페이스는 쪼개야 함
D	의존 역전 원칙 (Dependency Inversion Principle)	상위 모듈이 하위 모듈에 의존하지 않아야 한다	구현이 아닌 인터페이스에 의존해야 변경에 유연함📌 예: 클래스가 MySQL 직접 쓰지 말고 Database 인터페이스를 쓰도록

18. UML 확장 모델에서 스테레오 타입 객체를 표현할 때 사용하는 기호로 맞는 것은?

<<>>
(())
{{}}
[[]]

UML 확장 모델에서 스테레오타입 기호는?

UML에서 **스테레오타입(Stereotype)**은
기존 UML 요소에 의미를 추가하거나 커스터마이징할 때 사용하는 확장 메커니즘이야.

👉 이 스테레오타입은 UML 다이어그램에서 다음처럼 << >> 꺾쇠 괄호로 감싸서 표기

보기 사용 여부 설명

<<>>	✅ UML에서 스테레오타입 표기 기호
(( ))	❌ 사용하지 않음. UML과 무관
{{ }}	❌ 사용하지 않음. 일반적으로 템플릿 문법 등에서 사용됨
[[ ]]	❌ 사용하지 않음. 마크다운, 위키 문법 등에 사용됨

19. CASE(Computer-Aided Software Engineering)의 원천 기술이 아닌 것은?

구조적 기법
프로토타이핑 기술
정보 저장소 기술
일괄 처리 기술

**CASE (Computer-Aided Software Engineering)**는

소프트웨어 개발 전 과정을 자동화·지원하기 위한 도구와 기술을 말해.

📌 분석, 설계, 구현, 테스트, 문서화 등 모든 개발 단계를 지원하는 툴 기반 개발 환경이야.

✅ CASE의 원천 기술 (핵심 기반 기술)

기술설명

구조적 기법	DFD, ERD 등 구조화된 분석·설계 기법으로 CASE 툴에 적용됨
프로토타이핑 기술	빠른 시제품 개발을 통해 사용자 요구를 반복적으로 반영
정보 저장소 기술 (Repository)	설계 정보, 코드, 테스트 결과 등을 저장하고 관리하는 기술 (중앙 저장소 역할)

❌ 일괄 처리 기술 (Batch Processing)

이는 운영체제에서 일정 작업을 자동으로 처리하는 방식으로,
CASE 도구의 기반 기술이라기보다는 운영 효율성을 위한 실행 방식이야.
소프트웨어 개발 지원과 직접적 관련성은 떨어짐.

20. 다음 중 상태 다이어그램에서 객체 전이의 요인이 되는 요소는?

event
state
message
transition

해설

상태 다이어그램(State Diagram)이란?

객체가 시간의 흐름이나 이벤트 발생에 따라
**상태(state)**가 어떻게 **변화(전이, transition)**하는지를 표현하는 UML 다이어그램이야.

🔑 정답 요소 설명

용어설명

✅ event (이벤트)	상태를 변화시키는 원인, 즉 전이의 직접적인 트리거(Trigger) 예: 버튼 클릭, 타이머 만료, 입력 도착 등
❌ state (상태)	객체가 어떤 조건이나 상황에 있는지 나타냄 (전이의 결과 또는 시작점)
❌ message (메시지)	객체 간 통신 수단이지만, UML에서는 주로 시퀀스 다이어그램에서 사용됨
❌ transition (전이)	이벤트에 의해 상태가 바뀌는 과정 자체 (원인 아님)

'TIL' 카테고리의 다른 글

프로그래밍 언어 활용 - 2024 1회 (0)	2025.04.30
데이터베이스 구축 - 2024 1회 (1)	2025.04.30
소프트 웨어 개발 - 2024 1회 (0)	2025.04.30
사전캠프 24일차 (1)	2024.11.21
사전캠프 23일차 (0)	2024.11.21

현재글소프트웨어 설계 2024 1회

ds3hfj 님의 블로그

ds3hfj 님의 블로그 입니다.

중꺾마, 화이팅 박종관,

Today :
Yesterday :

« 2026/05 »
일	월	화	수	목	금	토
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31