1단원 소프트웨어 설계 개념 요약

1. 소프트웨어 생명주기 (Software Development Life Cycle, SDLC) 모델

소프트웨어를 개발하기 위한 과정을 단계별로 나눈 모델

모델명	주요 특징	핵심 키워드
폭포수 (Waterfall)	선형 순차적 개발, 가장 오래된 고전적/전통적 모임	Step-by-Step, 하향식
HIPO (Hierarchy Input Process Output)	하향식 설계 방식으로 시스템의 기능을 입력-처리-출력으로 표현	가시적/총체적/세부적 도표, 유지보수 간단
프로토타입 (Prototype)	고객의 요구사항(Need) 파악을 위해 견본/시제품 제작	인터페이스 중심, 요구사항 변경 용이
나선형 (Spiral)	폭포수 + 프로토타입 + 위험 분석 기능 추가	위험 관리/최소화, 점진적 반복
애자일 (Agile)	짧은 주기(Sprint/Iteration)를 반복하며 유연한 대응	고객 상호작용 중시, XP/Scrum/Lean

 

나선형 모델의 4단계 순서 

계획 수립 → 위험 분석 → 개발 및 검증 → 고객 평가

 

하향식설계(Top-down) : 절차지향(순차적) / 최상위 컴포넌트 설계 후 하위 기능 부여 → 테스트 초기부터 사용자에게 시스템 구조제시 가능

상향식설계(Bottom-up): 객체지향/ 최하위 모듈 먼저 설계 후 이들을 결합하고 검사 → 기능 추가 어려움

Component : 명백한 역할을 가지며 재사용되는 모든 단위 /  인터페이스 통해 접근 가능

 

2. 애자일(Agile) 방법론 상세

스크럼(Scrum) 기법의 역할

• 제품 책임자(PO): 백로그(Backlog) 작성, 우선순위 지정, 의사결정권자.
• 스크럼 마스터(SM): 가이드 및 조언자, 장애 요소 해결, 객관적 시각 유지.
• 개발팀(DT): 실제 개발 수행 주체. (우선순위 지정 불가)

스크럼개발프로세스

스프린트 계획 회의 → 스프린트(개발 기간 2~4주 단기간 목표) → 일일 스크럼 회의 → 스프린트 검토 회의 → 스프린트 회고

 

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

고객 참여와 신속한 개발을 강조하는 방법론

• 5대 핵심 가치: 용기, 단순성, 의사소통, 피드백, 존중
• 주요 원리: * TDD(테스트 주도 개발): 테스트 코드를 먼저 작성.
  • Pair Programming: 두 명이 짝을 지어 코딩.
  • Refactoring: 기능을 유지하며 코드 구조 개선.
  • Collective Ownership: 코드에 대한 공동 소유권.

 

3. 요구사항 정의 및 분석

시스템이 제공해야 할 서비스와 제약 조건을 정의하는 단계

 

요구사항의 유형

1. 기능적 요구사항: 시스템이 무엇을 하는지 (예: 입금, 출금, 조회 기능)
2. 비기능적 요구사항: 어떻게 동작하는지 (예: 성능, 보안, 가용성, 3초 이내 응답)

요구사항 개발 프로세스 

단계	명칭	주요 활동 및 내용	관련 기법(Ex)
1단계	도출 (Elicitation)	이해관계자로부터 요구사항을 수집하고 식별하는 과정	인터뷰, 설문, 브레인스토밍, 워크숍
2단계	분석 (Analysis)	요구사항의 타당성 조사 및 비용, 일정 등 제약사항 설정	개념 모델링, 할당, 협상, 정형 분석
3단계	명세 (Specification)	분석된 요구사항을 체계적으로 문서화 (요구사항 명세서 작성)	자연어 명세, 정형 명세
4단계	확인/검증 (Validation)	명세서가 정확하고 완전하게 작성되었는지 검토 및 승인	요구사항 검토, 프로토타이핑, 모델 검증

 

요구사항 분석 기법

 

요구사항의 상충 관계를 해결하고 구체화하는 단계에서 사용됨 

• 분류: 요구사항을 기능/비기능, 우선순위 등에 따라 그룹화.
• 개념 모델링: 실세계를 추상화하여 모델(예: UML)로 표현.
• 할당: 요구사항을 충족시키기 위한 구성 요소를 식별.
• 협상: 서로 충돌하는 요구사항이 있을 경우 우선순위를 조절.
• 정형 분석: 구문과 의미가 정의된 언어를 사용하여 수학적으로 분석.

요구사항 확인(검증) 기법 

 

작성된 요구사항 명세서가 사용자 의도와 일치하는지 점검 

기법명	설명
요구사항 검토	문서화된 요구사항을 훑어보며 오류를 찾는 가장 일반적인 방법
프로토타이핑	시제품을 제작하여 사용자 피드백을 통해 요구사항을 지속 보완
모델 검증	분석 단계에서 개발된 모델이 요구사항을 충족하는지 논리적 검증
인수 테스트	사용자가 실제 환경에서 요구사항이 충족되는지 직접 확인

 

4. UML (Unified Modeling Language)

객체지향 모델링을 위한 표준화된 그래픽 언어 

다이어그램 종류

• 구조적(정적) 다이어그램: 클래스, 객체, 컴포넌트, 배치, 복합체, 패키지
• 행위(동적) 다이어그램:
  • 유스케이스(Use Case): 사용자 관점의 요구 분석.
  • 시퀀스(Sequence): 객체 간 주고받는 메시지 흐름(시간 순서).
  • 상태(State): 객체의 상태 변화 표현.
  • 활동(Activity): 처리 흐름을 순서대로 표현.
• 액터 (Actor): 시스템과 상호작용하는 사람이나 다른 시스템의 역할 
  • 사용자 액터: 기능을 요구하거나 수행 결과를 통보받는 사용자 
  • 시스템 액터: 본 시스템과 데이터를 주고받는 연동 시스템 

5. UI (User Interface) 설계

UI 설계 원칙

• 직관성: 누구나 쉽게 이해.
• 유효성: 정확하고 완벽하게 목표 달성.
• 학습성: 쉽게 배우고 사용.
• 유연성: 사용자의 인터랙션을 최대한 수용.

UI 설계 도구

• 와이어프레임(Wireframe): 초기 레이아웃 설계 (정적).
• 스토리보드(Story Board): 와이어프레임에 설명과 프로세스 추가.
• 목업(Mockup): 실제 화면과 유사하게 만든 정적 모형.
• 프로토타입(Prototype): 동적인 상호작용이 가능한 시제품.

 

6. 설계 방식: 하향식 vs 상향식

• 하향식 설계(Top-down): 최상위 기능에서 하위 기능으로 구체화. 절차지향적이며 구조 파악이 용이함.
• 상향식 설계(Bottom-up): 최하위 모듈을 먼저 만든 후 결합. 객체지향적이며 기능 추가가 어려울 수 있음.

 

7. 소프트웨어 아키텍처의 기본 원리

아키텍처 설계의 4대 핵심 요소

1. 모듈화(Modularity): 성능 향상 및 재사용을 위해 시스템을 분리. (모듈 개수가 너무 많아지면 통합 비용이 증가함)
2. 추상화(Abstraction): 불필요한 부분은 생략하고 핵심 위주로 모델화. (과정, 데이터, 제어 추상화)
3. 단계적 분해(Stepwise Refinement): 문제를 하향식으로 세분화하여 구체화함.
4. 정보 은닉(Information Hiding): 모듈 내부의 자료를 숨겨 다른 모듈의 접근을 제한함. (독립성 향상)

소프트웨어 아키텍처 설계 과정

설계 목표 설정 → 시스템 타입 결정 →  아키텍처 패턴 적용 → 서브 시스템 구체화 → 검토

 

소프트웨어 아키텍처의 품질 속성

성능 /  보안 / 가용성 / 기능성 / 변경 용이성 / 확장성 / 배치성 / 안정성

 

8. 주요 아키텍처 패턴 (Architecture Patterns)

시스템 전체의 구조를 정의하는 전형적인 설계 방식

패턴명	주요 특징 및 내용
계층화 (Layered)	시스템을 계층으로 구분(예: OSI 7계층). 하위 계층은 상위 계층의 서비스 제공자가 됨.
Client-server	요청하는 Client와 응답하는 Server로 구성되며, 서로 독립적임.
Pipe-Filter	데이터 스트림을 필터로 캡슐화하여 한 방향으로 전송. 재사용 및 확장이 용이하나 오버헤드 발생 가능(ex. UNIX 쉘).
MVC 패턴	Model(데이터), View(화면), Controller(제어)로 분리하여 각 요소의 독립성 유지.
Master-slave	마스터가 작업을 분할/배포하고 슬레이브가 처리 결과를 반환(병렬 컴퓨팅).
Broker	컴포넌트와 사용자를 연결하여 분산 환경 시스템에 적합한 구조 제공.
Peer-to-peer	각 피어(Peer)가 클라이언트이자 서버가 될 수 있는 멀티스레딩 방식.
Event-bus	소스가 특정 채널에 메시지를 발행하면 구독 중인 리스너들이 이벤트를 처리.
Blackboard	컴포넌트들이 공동 데이터 저장소(Blackboard)에서 원하는 데이터를 찾음.
Interpreter	특정 언어로 작성된 프로그램 코드를 해석하는 컴포넌트 설계.

 

EAI(Enterprise Application Integration) : 기업 응용 프로그램을 하나로 통합

FEP (Front-End Processor) : 입력 데이터를 프로세스가 처리하기 전에 미리 처리하여 프로세스 처리 시간을 줄여주는 프로그램

 

9. 객체지향(Object-Oriented) 설계 및 원칙

객체지향의 주요 개념

• 캡슐화(Encapsulation): 데이터와 함수를 하나로 묶고 정보 은닉.
• 상속(Inheritance): 상위 클래스의 속성을 하위 클래스가 물려받음.
• 다형성(Polymorphism): 하나의 메시지가 객체에 따라 다르게 반응. (오버라이딩 vs 오버로딩)

다형성 핵심 개념

• 오버라이딩 (Overriding): 상속받은 메서드를 하위 클래스에서 재정의 (이름/매개변수/반환타입 동일)
• 오버로딩 (Overloading): 메서드 이름은 같으나 매개변수 개수나 타입을 다르게 지정

객체지향 분석 방법론

• Booch (부치): 미시적, 거시적 개발 프로세스 모두 사용
• Jacobson (제이콥슨): 유스케이스(Use case)를 사용한 분석
• Coad-Yourdon: E-R 다이어그램 사용, 객체 행위 모델링
• Rumbaugh (럼바우): 객체 모델링(객체 다이어그램) → 동적 모델링(상태 다이어그램) → 기능 모델링(자료 흐름도) 순서 중요!

데이터 흐름도 (DFD) 구성요소

구조적 분석 기법에 사용되며 '버블 차트'라고도 불립니다.

• 프로세스 (Process): 원
• 자료 흐름 (Flow): 화살표
• 자료 저장소 (Data store): 평행선
• 단말 (Terminator): 사각형

객체지향 설계 5대 원칙 (SOLID)

• S (Single Responsibility): 단일 책임 원칙 (하나의 클래스는 하나의 책임만).
• O (Open-Closed): 개방 폐쇄 원칙 (확장에는 열려 있고, 수정에는 닫혀 있어야 함).
• L (Liskov Substitution): 리스코프 교체 원칙 (자식 클래스는 언제나 부모 클래스를 대체 가능해야 함).
• I (Interface Segregation): 인터페이스 분리 원칙 (자신이 사용하지 않는 메서드에 의존 강요 금지).
• D (Dependency Inversion): 의존성 역전 원칙 (구체적인 것보다 추상적인 것에 의존).

10. GoF(Gang of Four) 디자인 패턴

디자인 패턴은 크게 생성, 구조, 행위 3가지로 분류된다. 

 

1) 생성 패턴 (5개) - 객체 생성 방식 결정

추빌팩프싱 : 추상 팩토리, 빌더, 팩토리 메서드, 프로토타입, 싱글톤

 

2) 구조 패턴 (7개) - 객체를 조합하여 더 큰 구조 형성

• Adapter: 호환되지 않는 인터페이스를 연결.
• Proxy: 실제 객체에 대한 접근을 제어하는 대리자 역할.
• Decorator: 객체에 동적으로 기능을 추가.

3) 행위 패턴 (11개) - 객체 간의 상호작용 및 책임 분담

• Observer: 한 객체의 상태 변화를 구독자들에게 알림.
• Strategy: 알고리즘을 캡슐화하여 필요에 따라 교체 사용.
• State: 객체 상태에 따라 동작을 다르게 처리.

 

11. 설계 검토 및 분석 기법

요구사항 검증 기법

1. 동료 검토(Peer Review): 작성자가 설명하고 동료들이 결함 발견.
2. 워크스루(Walk-through): 회의 전 자료 배포 후 짧은 검토 회의.
3. 인스펙션(Inspection): 작성자 외 전문 검토 그룹이 결함 확인.

팬인(Fan-In) & 팬아웃(Fan-Out)

• Fan-In: 나를 호출하는 모듈의 수 (높을수록 재사용성 좋으나, 장애 시 파급력 큼).
• Fan-Out: 내가 호출하는 모듈의 수 (높을수록 로직이 복잡하므로 단순화 필요).

 

12. 미들웨어 (Middleware) 종류

애플리케이션과 OS 사이에서 통신을 돕는 소프트웨어 

• RPC (Remote Procedure Call): 원격 프로시저를 로컬처럼 호출.
• MOM (Message Oriented Middleware): 메시지 큐 기반 비동기 전달.
• WAS (Web Application Server): 동적 콘텐츠 처리를 위한 서버 (Tomcat, JEUS).
• TP-Monitor: 트랜잭션 처리를 감시하고 제어.