정보처리기사(정처기) 공부하기

강민경·2026년 1월 18일

소프트웨어 설계

XP (Extreme Programming)

정의

에자일(Agile) 개발방법론의 종류 중 하나이며, 짧은 주기의 개발기간과 개발내용을 반복적으로 수행.
사용자의 요구사항을 한꺼번에 받는 방식이 아닌 반복형 모델의 개발주기를 극단적으로 짧게함으로써 프로그래머가 설계, 구현, 시험 활동을 전체 SW개발기간에 걸쳐 조금씩 자주 실시하도록 하는 개발방법이 XP(Extreme Programming)이다.

특징

짧은 개발주기 반복

프로토타입이 일찍 자주 만들어짐

개발계획이 프로젝트 진행동안 계속 변화됨

XP의 4원칙

원칙	설명	12가지 기본원리
의사소통 (Communication)	고객과 개발자와의 의사소통을 중요시	User Story 카드 Pair Programming On site Customer
단순성 (Simplicity)	지금 해야할 일에 대해서 가장 효율적인 디자인이나 코딩을 하는 것이 좋다.	Simple Design Metaphore
피드백 (Feedback)	즉각적인 피드백을 통해 빠른 의사 결정 그래서 XP는 항상 코드가 실행가능한 상태유지	On Site Customer Small Release Test Refactoring
용기 (Courage)	XP는 개발자들이 자신감있게 변화를 수용 할 수 있도록 그 환경을 만들어준다 Spike, Small Relase 등으로 고객요구사항에 대응하는 용기	Small Release

XP의 12가지 기본원리

구분	기본원리	설명
개발	Pair Programming (페어 프로그래밍)	개발자 2명이 공동 작업을 한다.
	Collective Ownership (공동 책임)	공통소유 - 시스템에 존재하는 코드는 언제 누구든지 수정 가능
	Continuous Integration (지속적 통합)	지속적인 통합 - 작업이 끝날때마다 지속적으로 통합되고 동시에 테스트 된다
관리	Planning Game (게임 계획)	개발계획 수립 - 고객과 다양한 스토리카드를 통한 개발계획 작성
	Small Release (작은 릴리즈)	짧은 배포주기 - 매우 짧은 주기로 모듈 업데이트
	Metaphore (메타포)	의사소통 언어 - 문장형태로 시스템 아키텍쳐 기술 - 공통의 Naming System 개발 - 고객과 개발자간 의사소통 언어
구현	Simple Design (단순한 디자인)	단순설계 - 현재의 비즈니스 가치에 집중 - 내일을 고려하는 디자인은 최대한 배제한다. - Refactoring을 통해 개선
	Test (테스트 주도 개발)	테스트 주도적 개발 - 항상 단위 테스트를 작성한다. - TFD(Test First Development): 테스트 수행 후 검증코드를 작성해 나감 - 실제 코드를 작성하기 전에 먼저 테스트를 작성해 봄으로써 자신이 무엇을 해야하는지 스스로 깨우칠 수 있다.
	Refactoring (리팩토링)	기능 변화없는 코드 수정 - 기능변화 없이 중복제거, 단순화, 유연성 추가 1. Method정의 - 지나치게 긴 Method를 분리, 지나치게 긴 문장을 Method를 사용하여 단순화 2. 위치이동 - Method나 변수 위치를 적절한 Class로 이동 3. 캡슐화 - 맴버변수를 Get/Set 사용하여 캡슐화 4. 조건문 단순화 - 긴 조건을 분할하거나 Method화 하여 단순화 5. 이름변경 - 이해하기 쉬운 이름으로 변경 6. Indentation - 가독성이 있는 Indent로 재포맷
환경	40시간 작업	최대 주 주 40시간 작업
	On-Site Customer (고객 상주)	고객상주 -프로젝트팀에 고객이 상주하여 즉각적인 의사소통과 피드백 - 품질향상의 필수요소
기타	Coding Standard (코딩 표준화)	코드표준을 통한 효과적인 의사소통 - 자신의 코드에 개발자의 이름, 연락처 - 주석

출처
https://it-license.tistory.com/37
https://seing.tistory.com/204
https://ko.wikipedia.org/wiki/%EC%9D%B5%EC%8A%A4%ED%8A%B8%EB%A6%BC_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

CASE(Computer-Aided Software Engineering)

정의

컴퓨터 지원 소프트웨어 공학은 컴퓨터 지원 시스템 공학이라고 하는데, 시스템 개발 방법론들의 자동화를 지원하는 소프트웨어 도구를 제공해 개발자의 반복적인 작업량을 줄이도록 하는 것 이다. 또한 CASE 도구들은 문서의 생성과 개발 팀 간의 협업을 돕는다.

요약
소프트웨어 개발 과정 일부 또는 전체를 자동화하기 위한 도구

CASE의 장점

구조적인 것들을 그대로 활용할 수 있다.

요구 정보를 추출하고 분석하는 것을 도와준다.

원형(Prototype)이나 프로그램의 개발 및 유지가 용이하다.

개발자들이 반복적인 업무에서 벗어나 창의적 업무에서 몰두하게 해 준다.

소프트웨어의 점진적 개발이 가능하다.

소프트웨어의 재활용성을 재고시켜 준다.

모든 것들이 그림으로 표현되어 있기 때문에 개발자들 간에 정보시스템의 공유가 쉽다.

CASE의 분류

상위(Upper) CASE:
- 모델들사이의 모순 검사, 모델의 오류 검증, 자료 흐름도 작성 등 지원
- 전체 단계를 자동화 시키지 못하기 때문에 앞 단계만을 자동화 시켜줄 목적을 가지고 있다.
하위(Lower) CASE:
- 코드의 작성과 테스트, 문서화하는 과정 지원
- 디자인단계에서 Source 코딩단계까지를 자동화 시켜주는 것을 말한다.
통합(Integrate) CASE:
- 소프트웨어 생명 주기 전체 과정 지원

CASE의 원천 기술

구조적 기법

프로토타이핑 기술

자동 프로그래밍 기술

정보 저장소 기술

분산처리 기술

CASE 도구의 기능 및 효과

그래픽 지원

소프트웨어 생명 주기 전 단계의 연결

다양한 소프트웨어 개발 모형 지원

소프트웨어 모듈의 재사용성 향상

소프트웨어 품질 향상

소프트웨어 유지보수 간편하게 수행 가능

요구사항 분석 CASE 종류

SADT(Structured Analysis and Design Technique)
- SoftTech사에서 개발된 것으로, 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구
SREM(Software Requirements Engineering Methodology)
- RSL/REVS
  - TRW가 우주 국방 시스템 그룹에 의해 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술할 목적으로 개발한 도구
PSL/PSA
- 미시간 대학에서 개발한 것으로 PSL과 PSA를 사용한 도구
TAGS(Technology for Automated Generation of Systems)
- 시스템 공학 방법 응용에 대한 자동 접근 방법으로, 개발 주기의 전 과정에서 이용할 수 있는 통합 도구

출처
https://blog.naver.com/gisafirst/222686734081
https://velog.io/@kipsong/정보처리기사-CASEComputer-Aided-Software-Engineering
https://ko.wikipedia.org/wiki/%EC%BB%B4%ED%93%A8%ED%84%B0_%EC%A7%80%EC%9B%90_%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%EA%B3%B5%ED%95%99

객체지향

정의

객체 지향 기법은 현실 세계의 개체를 하나의 기계 부품처럼(객체) 만들어, 부품을 조립하여 제품을 만들 듯 소프트웨어를 개발할 때도 객체들을 조립해서 작성할 수 있도록 하는 기법이다.
단순한 절차에 의해서 동작하는 것이 아니라 객체가 있고, 몇가지 기능이 있고, 이 기능을 호출했을 때 그 객체가 중심되어서 움직인다.

요약
현실의 개체(Entity)를 하나의 객체(Object)로 만들어 소프트웨어를 개발할 때 객체들을 이용해 프로그램을 작성할 수 있도록 하는 기법

객체지향 구성 요소

요약
1. 객체(Object)
2. 클래스(Class)
3. 메서드(method)
4. 메시지(Message)
5. 인스턴스(Instance)
6. 속성(Property)

구성요소	설명
클래스	- 특정 객체 내에 있는 변수와 메서드를 정의하는 일종의 틀 - 객체 지향 프로그래밍에서 데이터를 추상화하는 단위 - 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특징을 설명 - 속성은 변수의 형태로, 행위는 메서드 형태로 선언
객체	- 클래스, 추상화로 추출된 다른 것을 실제 기능하는 대상 - 클래스에서 추상화한 것을 토대로 메모리에 할당된 객체마다 각각의 상태와 실제값을 가짐
메서드	- 클래스로부터 상속된 객체들을 사용하는 방법 - 객체가 메시지를 받아 실행해야 할 객체의 구체적인 연산을 정의 - 전통적인 시스템의 함수(Function) 또는 프로시저(Procedure)에 해당하는 업무 기능
메시지	- 객체 간 상호 작용을 하기 위한 수단 - 객체에게 어떤 행위를 하도록 지시하는 방법 - 객체 간의 상호 작용은 메시지를 통해 이루어짐 - 메시지는 객체에서 객체로 전달됨
인스턴스	- 객체 지향 개발에서 클래스를 통해 만든 실체의 실현 객체 - 클래스에 속한 각각의 객체 - 실제로 메모리상에 할당
속성	- 한 클래스 내에 속한 객체들이 가지고 있는 데이터 값을 담아내는 정의 - 성질, 분류, 식별, 수량, 현재 상태 등에 대한 특징이나 값

객체지향 기법

캡슐화(Enacapsulation)
- 자료 부분과 연산(또는 함수) 부분 등 정보처리에 필요한 기능을 한 테두리로 묶은 것
- 연관된 데이터와 함수를 함께 묶어 외부와 경계를 만들고 필요한 인터페이스만을 밖으로 드러내는 과정
- 결합도가 낮아진다. 즉, 프로그램 변경에 대한 오류의 파급효과가 적다.
- 재사용이 용이하다.
- 인터페이스를 단순화 시킬 수 있다.
정보 은닉(Information Hiding)
- 객체가 다른 객체로부터 자신의 자료를 숨기고 자신의 연산만을 통하여 접근을 허용하는 것
- 정보 은닉의 가장 근본적인 목적은 고려되지 않은 영향(Side Effect)들을 최소화 하는 것
- JAVA에서 정보은닉(Information Hiding)을 표기 할 때 public의 의미는 공개
추상화(Abstraction)
- 주어진 문제나 시스템 중에서 중요하고 관계있는 부분만을 분리하여 간결하고 이해하기 쉽게 만드는 것
상속(Ingeritance)
- 상위 클래스의 속성과 메서드를 하위 클래스가 물려받는 것
- 클래스와 객체를 재사용 가능
다향성(Polymorphism)
- 많은 상이한 클래스들이 동일한 메서드명을 이용하는 능력
- 일반화된 객체는 어떤 특정 객체를 지칭할 수 있기 때문에 같은 동작을 하지만 다른 성질을 가질 수 없음
관계성(Relationship)
- 두 개 이상의 엔터디 형에서 데이터를 참조하는 관계를 나타내는 기법
- 종류로는 연관화, 분류화, 집단화, 일반화, 특수화
- 연관화
  - is-member-of 관계
  - 클래스와 객체의 현실 및 이용관계
  - 같은 계층에 속하는 클래스들 사이의 상호 인증을 보여주는 비계층적 관계들을 나타냄
- 집단화
  - is-part-of 관계, part-whole 관계
  - 사물 간에 있는 여러 개의 관계를 표현
  - 한 개의 사물 관계를 만드는 특징이 있음
  - 일반화와 달리 상위 클래스의 성질들이 하위 클래스로 상속되지는 않음
- 분류화
  - is-instance-of 관계
  - 공통된 성질에 의해 정의된 객체 클래스들의 인스턴스
- 일반화
  - is-a 관계
  - 클래스 간의 계층적인 관계 관리
  - 상위 클래스의 특성을 하위 클래스가 상속받음
- 특수화
  - is-a 관계
  - 상위 클래스의 특성들을 상속 받으면서 하위 클래스에서 나름대로 증명을 가하고 자기 자신의 고유한 특성을 갖는 관계

출처
https://y-oni.tistory.com/27
https://dongdd.tistory.com/119
https://itwiki.kr/w/%EA%B0%9D%EC%B2%B4%EC%A7%80%ED%96%A5_%EA%B8%B0%EB%B2%95

UML(Unified Modeling language)

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

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

정의

클래스의 속성, 함수, 변수타입들로 구성된 다이어그램

구조

요약
1. 클래스
2. 스테레오 타입
3. 추상 클래스

1. 클래스

첫 번째 블럭 :
- 클래스의 이름
- 첫 글자는 대문자이며 중앙정렬이고 두꺼운 폰트를 사용
두 번째 블럭 :
- 클래스의 속성들
세 번째 블럭 :
- 클래스의 실행할 수 있는 작업을 표시

2. 스테레오 타입

인터페이스나 추상 클래스와 같은 요소를 표기하기 위해 << >>와 같은 문법을 사용하는데, 이를 길러멧(guillemet)이라 부른다.
길러멧(guillemet)
- 클래스명 위에 작은 글씨로 작성
- 인터페이스, enum, 추상 클래스 등에서 사용되지만 사용자의 확장 클래스를 의미하는데에도 사용

3. 추상 클래스

표기법
- 이탤릭체(기울어진 글씨)
- 클래스 명 {abstract}
- 길러멧(guillmet)

관계

클래스 간 관계를 정확하게 하는 것이 클래스 다이어그램을 그리는 주된 목적입니다. 이러한 관계를 나타내는 표현은 아래와 같습니다.

요약
1. Association(연관)
2. Ingeritance(상속)
3. Realization / Implementation(실체 / 구현)
4. Dependency(의존)
5. Aggregation(집합)
6. Composition(합성)

1. 연관(Association)
다른 객체의 참조를 가지고 있을 때 이러한 관계를 나타냅니다. 여기서 위 처럼 방향이 있는 실선과 방향이 없는 실선 두 가지로 연관 관계를 나타낼 수 있습니다.

A → B와 같이 방향이 있는 실선의 경우, A가 B를 참조한다는 의미입니다.
A ─ B는 A가 B를, B가 A를 참조할 수도 있고, 둘 다 참조 이거나 둘 다 참조가 아니거나 라는 의미입니다.

아래는 방향성 있는 연관관계에 대한 예시입니다. 해당 예시는 동일한 코드를 표현하는 예시들 입니다.

2. 상속(Inheritance)
상속 관계를 나타냅니다. Generalization - 일반화라고도 많이 부릅니다. 부모 클래스와 자식 클래스 간의 상속 관계를 나타낼 때 사용합니다.

3. 실체화(Realization)
인터페이스를 상속하여 클래스에서 실제 기능을 실현화 할 때 사용합니다. 실체화는 아래와 같이 두 가지로 표시가 가능합니다.

4. 의존(Dependency)
클래스간 참조 관계를 나타낼 때 사용합니다. Association과 차이점으로는 Association은 변수로 다른 클래스와 연관이 있을 때 사용하고, Dependency는 메소드의 파라미터나 반환에 사용되는 클래스 관계를 나탈 때 사용합니다.

즉, Association 관계는 해당 클래스의 멤버 변수로 할당할 때 사용하고, Dependency 관계는 로컬 변수, 파라미터, 반환 값으로 호출되는 메소드가 실행되는 동안에만 유지가 될 때 사용합니다.

5. Aggregation(집합)
A 클래스가 B를 소유하고 있거나, A 클래스가 B의 부모라거나 하는 것을 가리키는 것이 아니다. A 클래스의 인스턴스는 B 클래스의 인스턴스와 베타적이지(독립적이지) 않다는 것을 강조하기 위한것이다.

위 다이어그램에서 Engine과 Wheel은 Car와 집합관계이지만 차가 없어진다고 해서 Engine과 Wheel이 삭제된다고 보진 않았다. 물론 이 설계는 프로그램 설계 특성에 따라 변경 될 수 있을 것이다.

6. Composition(합성)
만약 둘 사이의 강력한 의존관계가 있어서 하나가 삭제 되었을 때 다른 하나가 존재할 수 없다면, 이는 Composition 관계이다. Composition은 포함관계로 설명되기도 한다. 방은 집에 포함되어있다(belongs-to)고 얘기할 수도 있고, 집은 방을 가지고 있다(has-a)고 얘기할 수도 있다.

출처

https://brownbears.tistory.com/577
https://ocwokocw.tistory.com/14

2. 객체 다이어그램(Object Diagram)

정의

클래스의 인스턴스, 값이 매겨진 행동을 가지고 있는 독립된 객체정보를 표현하는 다이어그램

2. 순차 다이어그램(Sequence Diagram)

정의

시계열(시간 순서)로 정렬된 객체 상호작용을 보여준다. 시나리오 기능을 수행하는데 필수적인 객체들 간에 교환되는 일련의 메시지들과 시나리오에 수반되는 객체와 클래스를 표현한다.

구성 요소

요약
1. 액터(Actor)
2. 객체(Object)
3. 라이프라인(Lifeline)
4. 활성 상자(Activation Box)
5. 메시지(Message)
6. 객체 소멸
7. 프레임(Frame)

구성요소	설명
액터	시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미한다.
객체	메시지를 주고 받는 주체이다. 콜론(:)을 기준으로 앞쪽에는 객체명을 뒤쪽에는 클래스명을 기술한다.
생명선(라이프라인)	객체가 메모리에 존재하는 기간으로, 객체 아래쪽에 점선을 그어 표현한다. 객체 소멸이 표시된 기간까지 존재한다.
실행 상자(활성 상자)	객체가 메시지를 주고 받으며 구동되고 있음을 표현한다. 라이프라인 상에 겹쳐 직사각형 형태로 표현한다.
메시지	객체가 상호작용을 위해 주고 받는 메시지이다. 화살표 방향은 메시지를 받는 쪽으로 향하게 표현한다.
객체 소멸	라이프라인 상에서 객체 소멸 표시를 만나면 해당 객체는 더 이상 메모리에 존재 하지 않음을 의미한다. 객체 라이프라인 마지막에 X로 표현한다.
프레임	다이어그램의 전체 또는 일부를 묶어 표현한다. 전체, 복합적인 부분, 반복구조, 선택구조 등이 프레임 안에 표현된다. 프레임의 왼쪽 위에 다이어그램의 종류와 제목을 표기한다.

출처

https://kyungi.tistory.com/23

유스케이스 다이어그램(Use-case Diagram, UML)

정의

사용자, 그리고 사용자가 수반한 다른 유스 케이스 간의 관계를 보여주는 사용자-시스템 간 상호작용의 표현이다. 사용자가 시스템 내부에 있는 기능 중에 어떤 기능을 사용 할 수 있는지 나타내며 유스케이스 다이어그램을 사용함으로써 고객과 개발자가 요구사항에 대한 의견을 조율 할 수 있다.

구성요소

요약
1. 시스템(System)
2. 액터(Actor)
3. 유스케이스(Usecase)
4. 관계(Relation)

구성요소	설명	예시
시스템		만들고자 하는 프로그램을 나타낸다
액터		시스템의 외부에 있고 시스템과 상호작용을 하는 사람(시스템의 기능을 사용하는 사람), 시스템(시스템에 정보를 제공하는 또 다른 시스템)을 말한다.
유스케이스		사용자 입장에서 바라본 시스템의 기능 시스템이 액터에게 제공해야하는 기능으로 시스템의 요구사항을 나타낸다
관계		액터와 유스케이스 사이의 의미있는 관계를 나타낸다. 종류는 연관(Association), 의존(Dependency), 일반화(Generalization)이 있으며 의존관계는 포함(Include), 확장(Extend)로 나눠진다.
	연관 관계	유스케이스와 액터간의 상호작용이 있음을 표현한다. 유스케이스와 액터를 실선으로 연결한다.
	포함 관계	하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때 형성되는 관계이다. 포함되는 유스케이스는 포함하는 유스케이스를 실행하기 위해 반드시 실행되어야 하는 경우에 적용한다. 포함하는 유스케이스에서 포함되는 유스케이스 방향으로 화살표를 점선으로 연결하고 <<include>>라고 표기한다.
	확장 관계	확장 기능 유스케이스와 확장 대상 유스케이스 사이에 형성 되는 관계이다. 확장 대상 유스케이스를 수행 할 때 특정 조건에 따라 확장 기능 유스케이스를 수행하는 경우에 적용한다. 확장 기능 유스케이스에서 확장 대상 유스케이스 방향으로 화살표를 점선으로 연결하고 <<extend>>라고 표기한다.
	일반화 관계	구체적인 유스케이스에서 추상적인 유스케이스 방향으로 끝부분이 삼각형으로 표현된 화살표를 실선으로 연결하여 표현한다.