munjji 님의 블로그

[정보처리기사] 1과목. 소프트웨어 설계 본문

CS

[정보처리기사] 1과목. 소프트웨어 설계

munjji 2026. 3. 11. 17:19

소프트웨어 공학의 기본 원칙

  • 현대적인 프로그래밍 기술을 계속으로 적용해야 한다.
  • 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 한다.
  • 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 한다.

폭포수 모형(Waterfall)

  • 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 다음 단계를 진행하는 개발 방법론이다.
  • 보헴이 제시한 고전적 생명 주기 모형이다.
  • 요구사항을 반영하기 어렵다.

나선형 모형(Spiral)

  • 나선을 따라 돌듯이 점진적으로 완벽한 최종 소프트웨어를 개발하는 것이다.
  • 계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객 평가 과정이 반복적으로 수행된다.

애자일 모형의 주요 방법론

  • 스크럼(Scrum)
  • XP(eXtreme Programming)
  • 기능 중심 개발(FDD; Feature Driven Development)
  • 칸반(Kanban)
  • Lean

애자일 개발 4가지 핵심 가치

  • 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.
  • 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.
  • 계약 협상보다는 고객과 협업에 더 가치를 둔다.
  • 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둔다.

XP의 핵심 가치

  • 의사소통
  • 단순성
  • 용기
  • 존중
  • 피드백

주요 비기능 요구사항

  • 성능 요구사항
  • 보안 요구사항
  • 품질 요구사항
  • 제약사항
  • 인터페이스 요구사항

요구사항 개발 프로세스

도출 -> 분석 -> 명세 -> 확인

요구사항 분석

  • 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화하는 활동을 의미한다.
  • 소프트웨어 개발의 실제적인 첫 단계이다.
  • 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정한다.
  • 사용자의 요구를 정확하게 추출하여 목표를 정하고, 해결 방식을 결정한다.

자료 흐름도의 구성 요소

자료 사전의 표기 기호

  • = : 정의
  • + : 연결
  • ( ) : 생략
  • [ | ] : 선택
  • { } : 반복
  • * * : 설명

HIPO

  • 하향식 소프트웨어 개발을 위한 문서화 도구이다.
  • 기호, 도표 등을 사용하므로 보기 쉽고 이해하기도 쉽다.
  • 기능과 자료의 의존 관계를 동시에 표현할 수 있다.

UML (Unified Modeling Language)

  • 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향모델링 언어이다.
  • 구성 요소 : 사물(Things), 관계(Relationships), 다이어그램(Diagram)

UML의 주요 관계

  • 일반화(Generalization) 관계 : 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현
  • 의존(Dependency) 관계 : 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현
  • 실체화(Realization) 관계 : 사물이 할 수 있거나 해야 하는 기능으로 서로를 그룹화 할 수 있는 관계를 표현

구조적(Structural) 다이어그램의 종류

  • 클래스 다이어그램
  • 객체 다이어그램
  • 컴포넌트 다이어그램
  • 배치 다이어그램
  • 복합체 구조 다이어그램
  • 패키지 다이어그램

행위(Behavioral) 다이어그램의 종류

  • 유스케이스 다이어그램
  • 순차 다이어그램
  • 커뮤니케이션 다이어그램
  • 상태 다이어그램
  • 활동 다이어그램
  • 상호작용 개요 다이어그램
  • 타이밍 다이어그램

스테레오 타입

  • UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하기 위해 사용한다.
  • 길러멧이라고 부르는 겹화살괄호 << >> 사이에 표현할 형태를 기술한다.

유스케이스 다이어그램 - 액터(Actor)

행위 다이어그램

  • 시스템과 상호작용을 하는 모든 외부 요소로, 사람이나 외부 시스템을 의미한다.
  • 주액터 : 시스템을 사용함으로써 이득을 얻는 대상으로, 주로 사람이 해당함
  • 부액터: 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부 시스템으로, 조직이나 기관 등이 될 수 있음

순차(Sequence) 다이어그램의 구성 요소

행위 다이어그램

  • 액터
  • 객체
  • 생명선
  • 실행 상자
  • 메시지

사용자 인터페이스의 특징

  • 사용자의 편리성과 가독성을 높여준다.
  • 작업 시간을 단축시킨다.
  • 업무에 대한 이해도를 높여준다.
  • 사용자 중심으로 설계되어 있다.

사용자 인터페이스의 구분

  • CLI(Command Line Interface) : 명령과 출력이 텍스트 형태로 이뤄지는 인터페이스
  • GUI(Graphical User Interface) : 아이콘이나 메뉴를 마우스로 선택하여 작업을 수행하는 그래픽 환경의 인터페이스
  • NUI(Natural User Interface) : 사용자의 말이나 행동으로 기기를 조작하는 인터페이스

사용자 인터페이스의 기본 원칙

  • 직관성 : 누구나 쉽게 이해하고 사용할 수 있어야 한다.
  • 유효성 : 사용자의 목적을 정확하고 완벽하게 달성해야 한다.
  • 학습성 : 누구나 쉽게 배우고 익힐 수 있어야 한다.
  • 유연성 : 사용자의 요구사항을 최대한 수용하고 실수를 최소화해야 한다.

목업

  • 와이어프레임보다 좀 더 실제 화면과 유사하게 만든 정적인 형태의 모형이다.
  • 시각적으로만 구성 요소를 배치하는 것으로 실제로 구현되지는 않는다. 

ISO/IEC 9126의 품질 특성

  • 기능성(Functionality) : 요구사항을 정확하게 만족하는 기능을 제공하는지 여부를 나타냄
  • 신뢰성(Reliability) : 요구된 기능을 오류 없이 수행할 수 있는 정도를 나타냄
  • 사용성(Usability) : 사용자가 쉽게 배우고 사용할 수 있는 정도를 나타냄
  • 이식성(Portability) : 다른 환경에서도 얼마나 쉽게 적용할 수 있는지 정도를 나타냄

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

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

모듈화

  • 기능의 분리가 가능하여 인터페이스가 단순해진다.
  • 프로그램의 효율적인 관리가 가능하다.
  • 오류의 파급 효과를 최소화할 수 있다.
  • 모듈의 크기를 너무 작게 나누면 개수가 많아져 모듈간의 통합 비용이 많이 들고,
    너무 크게 나누면 개수가 적어 통합 비용은 적게 들지만 모듈 하나의 개발 비용이 많이 든다.

추상화의 유형

  • 과정 추상화
  • 데이터(자료) 추상화
  • 제어 추상화

정보 은닉

  • 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법이다.
  • 모듈을 독립적으로 수행할 수 있다.
  • 수정, 시험, 유지보수가 용이하다.
  • 정보 은닉을 표기할 때 private은 의미는 은닉이다.

파이프 - 필터 패턴

  • 시스템의 처리 결과물을 파이프를 통해 전달받아 처리한 후 그 결과물을 다시 파이프를 통해 다음 시스템으로 넘겨주는 패턴이다.
  • 데이터 변환으로 인한 오버헤드가 발생한다.

MVC(Model-View-Control) 패턴

  • 모델(Model) : 서브시스템의 핵심 기능과 데이터를 보관함
  • 뷰(View) : 사용자에게 정보를 표시함
  • 컨트롤러(Controller) : 사용자로부터 입력된 변경 요청을 처리하기 위해 모델에게 명령을 보냄

메시지(Message)

  • 객체에게 어떤 행위를 하도록 지시하는 명령 또는 요구사항이다.
  • 객체들 간에 상호 작용을 하는 데 사용되는 수단이다.

클래스(Class)

  • 공통된 속성과 연산(행위)을 갖는 객체의 집합이다.
  • 클래스에 속한 각각의 객체를 인스턴스라한다.
  • 객체지향 프로그램에서 데이터를 추상화하는 단위이다.

캡슐화(Encapsulation)

  • 데이터와 데이터를 처리하는 함수를 하나로 묶는 것을 의미한다.
  • 외부 모듈의 변경으로 인한 파급 효과가 적다.
  • 인터페이스가 단순화된다.
  • 재사용이 용이하다.

상속(Inheritance)

상위 클래스(부모 클래스)의 모든 속성과 연산을 하위 클래스(자식 클래스)가 물려받는 것이다.

다형성(Polymorphism)

  • 오버로딩(Overloading) : 메소드의 이름은 같지만 인수를 받는 자료형과 개수를 달리하여 여러 기능을 정의할 수 있음
  • 오버라이딩(Overriding) : 메소드의 이름은 같지만 메소드 안의 실행코드를 달리하여 자식 클래스에서 재정의해서 사용할 수 있음

객체지향 분석 방법론 - Coad와 Yourdon 방법

  • E-R 다이어그램을 사용하여 객체의 행위를 모델링한다.
  • 객체 식별, 구조 식별, 주제 정의, 속성과 인스턴스 연결 정의, 연산과 메시지 연결 정의 등의 과정으로 구성하는 기법이다.

럼바우(Rumbaugh)의 분석 기법

  • 객체 모델링 : 정보 모델링이라고도 하며, 객체들 간의 관계를 규정하여 객체 다이어그램으로 표시하는 것
  • 동적 모델링 : 상태 다이어그램을 이용하여 객체들 간의 동적인 행위를 표현하는 모델링
  • 기능 모델링 : 자료 흐름도를 이용하여 자료 흐름을 표현한 모델링

객체지향 설계 원칙(SOLID)

  • 단일 책임 원칙(SRP; Single Responsibility Principle)
    객체는 단 하나의 책임만 가져야 한다는 원칙
  • 개방-폐쇄 원칙(OCP; Open-Closed Principle)
    기존의 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야 한다는 원칙
  • 리스코프 치환 원칙(LSP; Liskov Substitution Principle)
    자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다는 설계 원칙
  • 인터페이스 분리 원칙(ISP; Interface Segregation Principle)
    자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야 한다는 원칙
  • 의존 역전 원칙(DIP; Dependency Inversion Principle)
    각 객체들 간의 의존 관계가 성립될 때, 추상성이 낮은 클래스보다 추상성이 높은 클래스와 의존 관계를 맺어야 한다는 원칙

모듈(Module)

  • 모듈화를 통해 분리된 시스템의 각 기능들이다.
  • 단독으로 컴파일이 가능하다.
  • 재사용 할 수 있다.
  • 다른 모듈에서의 접근이 가능하다.

결합도의 정도 (약함 -> 강함)

자료 결합도 -> 스탬프 결합도 -> 제어 결합도 -> 외부 결합도 -> 공통 결합도 -> 내용 결합도 (자스제외공내)

결합도의 종류

  • 자료 결합도 : 모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도
  • 스탬프 결합도 : 배열이나 레코드 등의 자료 구조가 전달될 때의 결합도
  • 제어 결합도 : 제어 신호를 이용하여 통신하거나 제어 요소를 전달하는 결합도
  • 외부 결합도 : 데이터(변수)를 외부의 다른 모듈에서 참조할 때의 결합도
  • 공통 결합도 : 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도
  • 내용 결합도 : 다른 모듈의 내부 자료를 직접 참조하거나 수정할 때의 결합도

응집도의 정도 (약함 -> 강함)

우연적 응집도 -> 논리적 응집도 -> 시간적 응집도 -> 절차적 응집도 -> 교환적 응집도 -> 순차적 응집도 -> 기능적 응집도 (우논시절교순기)

주요 응집도

  • 절차적 응집도 : 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도
  • 시간적 응집도 : 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도
  • 우연적 응집도 : 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우의 응집도

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

  • 팬인 : 어떤 모듈을 제어(호출)하는 모듈의 수
  • 팬아웃 : 어떤 모듈에 의해 제어(호출)되는 모듈의 수

NS 차트

  • 논리의 기술에 중점을 둔 도형을 이용한 표현 방법이다.
  • 연속, 선택 및 다중 선택, 반복 등의 제어 논리 구조를 표현한다.
  • GOTO나 화살표를 사용하지 않는다.
  • 시각적으로 명확히 식별하는 데 적합하다.
  • 이해하기 쉽고, 코드 변환이 용이하다.

재사용(Reuse)

  • 이미 개발된 기능을 새로운 시스템이나 기능 개발에 사용할 수 있는 정도를 의미한다.
  • 재사용 규모에 따른 분류 : 함수와 객체, 컴포넌트, 애플리케이션

효과적인 모듈 설계 방안

  • 결합도는 줄이고 응집도는 높인다.
  • 복잡도와 중복성을 줄인다.
  • 일관성을 유지시킨다.
  • 모듈의 기능은 지나치게 제한적이어서는 안 된다.
  • 유지보수가 용이해야 한다.

주요 코드

  • 순차 코드 : 일정 기준에 따라서 차례로 일련번호를 부여하는 방법
  • 표의 숫자 코드 : 코드화 대상 항목의 중량, 면적, 용량 등의 물리적 수치를 적용시키는 방법

디자인 패턴

  • 세부적인 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제를 의미한다.
  • 디자인 패턴 유형 : 생성 패턴, 구조 패턴, 행위 패턴

생성 패턴(Creational Pattern) - 5개

구조 패턴(Structural Pattern) - 7개

행위 패턴(Behavioral Pattern) - 11개

 

요구사항 검증 방법

  • 동료검토 : 작성자가 명세서 내용을 직접 설명하면서 결함을 발견함
  • 워크스루 : 미리 배포한 명세서를 사전 검토한 후 결함을 발견함
  • 인스펙션 : 작성자를 제외한 다른 검토 전문가들이 발견함
  • 동료검토와 워크스루가 비공식적인 검토 방법
  • 인스펙션은 공식적인 검토 방법

미들웨어(Middleware)

  • 분산 컴퓨팅 환경에서 서로 다른 기종 간을 연결한다.
  • 운영체제와 응용 프로그램 사이에서 다양한 서비스를 제공한다.
  • 위치 투명성을 제공한다.
  • 사용자가 미들웨어의 내부 동작을 확인하려면 별도의 응용 소프트웨어를 사용해야 한다.

미들웨어의 종류

  • DB(DataBase)
  • RPC(Remote Procedure Call)
  • MOM(Message Oriented Middleware)
  • TP(Transaction Processing)-Monitor
  • ORB(Object Request Broker)
  • WAS(Web Application Server)