정보처리기사 필기 핵심 요약 | 1과목 : 소프트웨어 설계

✨ 소프트웨어 생명 주기 Software Life Cycle

소프트웨어 개발 단계와 각 단계별 주요 활동, 그리고 활동의 결과에 대한 산출물로 표현한다.

 

✨ 폭포수 모형 Waterfall Model

소프트웨어 개발은 이전 단계로 돌아갈 수 없다.

각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행 (선형 순차적)

전통적, 고전적

 

✨ 나선형 모형 Spiral Model, 점진적 모형

보헴Boehm이 제안한 것

나선을 따라 돌듯이 여러번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발

 

✨ 애자일 모형 Agile Model

고객 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주리를 반복하는 개발과정

좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통에 초점을 맞춘 방법론!

 

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

1. 프로세스와 도구보다는 개인 상호작용에 더 가치를 둔다.

2. 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.

3. 계약 협상보다는 고객과 협업에 더 가치를 둔다.

4. 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둔다.

 

✨ 스크럼

팀이 중심이 되어 개발의 효율성을 높인다

제품 책임자 PO

스크럼 마스터 SM

개발팀 DT

 

✨ XP (eXtreme Programming)

수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상

짧고 반복적은 개발 주기, 단순한 설계, 고객의 적극적인 참여

릴리즈 기간을 짧게 반복

- 핵심 가치 : 용기Courage, 단순성 Simplicity, 의사소통Communication, 피드백Feedback, 존중 Respect

 

✨ 현행 시스템 파악

1단계) 시스템 구성 파악, 시스템 기능 차악, 시스템 인터페이스 파악

2단계) 아키텍처 구성 파악, 소프트웨어 구석 파악

3단계) 하드웨어 구성 파악, 네트워트 구성 파악

 

✨ 운영체제 OS

컴퓨터의 시스템의 자원들을 효율적으로 관리

사용자가 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어

 

✨ 데이터베이스 관리 시스템 DBMS

사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해 주고, 데이터베이스를 관리해주는 소프트웨어

 

✨ 웹 애플리케이션 서버 WAS

사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어 middleware

데이터 접근, 세션 관리, 트랜잭션 관리 등을 위한 라이브러리 제공

- Tomcat, GlassFish, JBoss, Jetty, JEUS, Resin, WebLogic, WebSphere ...

 

✨ 요구사항 정의

- 기능 요구사항 : 시스템이 무엇을 하는지, 어떤 기능을 하는지

- 비기능 요구사항

 

✨ 요구사항 개발 프로세스

1. 도출 : 인터뷰, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스

2. 분석 : DFD, DD

3. 명세 : 소단위 명세서

4. 확인 (검증)

 

✨ 요구사항 명세 기법

- 정형 : 수학적 원리 기반, 모델 기반

- 비정형 : 상태/기능/객체 중심

 

✨ 요구사항 분석의 개요

개발 대상에 대한 사용자의 요구사항을 이해하고 문서화(명세화)하는 활동

- UML(Unified Modeling Language), 자료흐름도(DFD), 자료 사전(DD), 소단위 명세서(Mini-Spec.), 개체 관계도(ERD), 상태 전이도(STD), 제어 명세서 ...

 

✨ 자료 흐름도 DFD

Data Flow Diagram

요구사항 분석에서 자료의 흐름 및 변환 과정과 가능을 도현 중심으로 기술하는 방법

= 자료 흐름 그래프, 버블 차트

- 프로세스Process : 원이나 둥근 사각형

- 자료 흐름Flow : 화살표 위에 자료의 이름을 기입

- 자료 저장소Data Store : 도형 안에 자료 저장소 이름을 기입

- 단말Terminator : 시스템과 교신하는 외부 개체, 입력 데이터가 만들어지고 출력 데이터를 받음, 도형 안에 이름 기입

 

✨ 자료 사전 DD

Data Dictionary

자료 흐름도에 있는 자료를 더 자세히 정의하고 기록

데이터를 설명하는 데이터 = 데이터의 데이터 = 메타 데이터 Meta Data

- = : 자료의 정의

- + : 자료의 연결

- ( ) : 자료의 생략

- [ | ] : 자료의 선택

- { } : 자료의 반복

- * * : 자료의 설명

 

✨ 요구사항 분석을 위한 CASE (자동화 도구)

요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구

- SADT, SREM, PSL/PSA, TAGS

 

✨ HIPO

Hierarchy Input Process Output

시스템 분석 및 설계나 문서화할 때 사용되는 기법

- 기호, 도표 등을 사용하므로 보기 쉽고 이해하기로 쉽다.

- 기능과 자료의 의존 관계를 동시에 표현할 수 있다.

 

✨ UML

Unified Modeling Language

시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 언어

- 사물Things, 관계Relationships, 다이어그램Diagram

 

✨ 관계 Relationships

사물과 사물 사이의 연관성을 표현

- 연관Association 관계 : 2개 이상의 사물이 서로 관련됨

- 집합Aggregation 관계 : 하나의 사물이 다른 사물에 포함됨

- 포함Composition 관계 : 포함하는 사물의 변화가 포함되는 사물에게 영향을 미침

- 일반화Generalization 관계 : 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지

- 의존Dependency 관계 : 사물 사이에 연관은 있으나 서로에게 영향을 주는 짧은 시간동안만 연관을 유지함

- 실체화Realization 관계 : 사물이 할 수 있거나 해야하는 기능으로 서로를 그룹화할 수 있는 관계

 

✨ 다이어그램

사물과 관계를 도형으로 표현

- 정적 모델링 : 구조적 다이어그램 (클래스, 객체 다이어그램 ...)

- 동적 모델링 : 행위 다이어그램 (유스케이스, 상태 다이어그램 ...)

 

✨ 스테레오 타입

UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하기 위해 사용

- 길러멧Guilemet이라고 부르는 겹화살괄호(<< >>) 사이에 표현할 형태를 기술

- ex) <<include>>, <<extend>> ...

 

✨ 유스케이스Use Case 다이어그램

개발될 시스템과 관련된 외부 요소들, 즉 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점View에서 표현한 것

- 시스템, 액터, 유스케이스, 관계

 

✨ 클래스Class 다이어그램

구성 요소 : 클래스, 제약조건, 관계

 

✨ 순차Sequence 다이어그램

시스템이나 객체들이 메시지를 주고받으며 시간의 흐름에 따라 상호 작용하는 과정을 액터, 객체, 메세지 등의 요소를 사용하여 그림으로 표현

구성 요소 : 액터, 객체, 생명선, 실행 상자, 메시지

 

✨ 사용자 인터페이스 UI

- CLI : Command

- GUI : Graphical

- NUI : Natural

- OUI : Organic

 

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

- 직관성

- 유효성 : 사용자의 목적을 정확하고 완벽하게 달성

- 학습성

- 유연성 : 요구사항을 최대한 수용, 실수 최소화

 

✨ 사용자 인터페이스 설계 지침

- 사용자 중심

- 사용성

- 심미성

- 오류 발생 해결 : 오류가 발생하면 사용자가 쉽게 인지할 수 있도록 설계해야 함

 

✨ UI 설계 도구

- 와이어프레임 : 기획 단계 초기, 뼈대 설계, 개발자나 디자이너 등이 레이어웃을 협의/현재 진행 상태 공유 (손그림)

- 목업 : 와이어프레임보다 좀 더 실제 화면과 유사하게 만든 정적인 형태의 모형

- 스토리보드 : 콘텐츠에 대한 설명, 페이지 간 이동 흐름 (파워포인트)

- 프로토타입 : 실제 구현된 것 처럼 테스트 가능한 동적인 형태

- 유스케이스 : 사용자 측면에서의 요구사항

 

✨ 품질 요구사항

기능성, 신뢰성, 사용성, 효율성, 유지 보수성, 이식성

 

✨ 상위 설계와 하위 설계

- 상위 설계 : 아키텍처 설계, 예비 설계 / 시스템 전체적인 구조 / 구조, DB, 인터페이스

- 하위 설계 : 모듈 설계, 상세 설계 / 시스템의 내부 구조 및 행위 / 컴포넌트, 자료 구조, 알고리즘

 

✨ 소프트웨어 아키텍쳐 설계의 기본 원리

모듈화, 추상화, 단계적 분해(하향식 설계 전략, 문제를 상위의 중요 개념으로부터 하위의 개념으로 구체화), 정보 은닉

 

✨ 파이프-필터 패턴 Pipe-Filter Pattern

데이터 스트림 절차의 각 단계를 필터Filter 컴포넌트로 캡슐화하여 파이프Pipe를 통해 데이터를 전송하는 패턴

- 필터 컴포넌트는 재사용성이 좋고, 추가가 쉬워 확장이 용이하다.

- 필터 텀포넌트들을 재배치하여 다양한 파이프라인을 구축하는 것이 가능하다.

- 파이프-필터 패턴은 데이터 변환, 버퍼링, 동기화 등에 주로 사용된다.

- 대표적으로 UNIX의 쉘(Shell)

 

✨ Model-View-Controller Pattern

서브시스템을 3개의 부분으로 구조화하는 패턴

- 모델 : 서브시스템의 핵심 기능과 데이터를 보관

- 뷰 : 사용자에게 정보를 표시

- 컨트롤러 : 사용자로부터 입력된 변경 요청을 처리하기 위해 모델에게 명령을 보냄

 

✨ 객체 Object

데이터와 데이터를 처리하는 함수를 묶어 놓은(캡슐화한) 하나의 소프트웨어 모듈

- 독립적으로 식별 가능한 이름을 가지고 있다.

- 객체가 가질 수 있는 조건 = 상태 State → 상태는 시간에 따라 변한다.

- 객체와 객체는 상호 연관성에 의한 관계가 형성된다.

- 객체가 반응할 수 있는 메시지Message의 집합을 행위라고 하며, 객체는 행위의 특징을 나타낼 수 있다.

- 일정한 기억 장소를 가지고 있다.

 

✨ 클래스 Class

공통된 속성과 연산(행위)을 갖는 객체의 집합으로, 객체의 일반적인 타입Type을 의미

- 각각의 객체들이 갖는 속성과 연산을 정의하고 있는 틀

- 객체지향 프로그램에서 데이터를 추상화하는 단위

- 클래스에 속한 각각의 객체를 인스턴스라고 하며, 클래스로부터 새로운 객체를 생성하는 것을 인스턴스화라고 한다.

 

✨ 캡슐화 Encapsulation

데이터(속성)와 데이터를 처리하는 함수를 하나로 묶는 것을 의미

- 캡슐화된 객체는 인터페이스를 제외한 세부 내용이 은폐(정보 은닉)되어 외부에서의 접근이 제한적이기 때문에 외부 모듈의 변경으로 인한 파급 효과가 적다.

- 캡슐화된 객체들은 재사용이 가능하다.

- 객체들 간의 메시지를 주고받을 때 상대 객체의 세부 내용은 알 필요가 없으므로 인터페이스가 단순해지고 객체 간의 결합도가 낮아진다.

 

✨ 상속 Inheritance

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

 

✨ 다형성 Polymorphism

메시지에 의해 객체(클래스)가 연산을 수행하게 될 때 하나의 메시지에 대해 각각의 객체(클래스)가 가지고 있는 고유한 방법(특성)으로 응답할 수 있는 능력을 의미

- 객체(클래스)들은 동일한 메소드명을 사용하며 같은 의미의 응답을 한다.

- 응용 프로그램 상에서 하나의 함수나 연산자가 두 개 이상의 서로 다른 클래스의 인스턴스들을 같은 클래스에 속한 인스턴스처럼 수행할 수 있도록 하는 것이다.

* 오버로딩 Overloading : 메소드Method의 이름은 같지만 인수를 받는 자료형과 개수를 달리하여 여러 기능을 정의할 수 있다.

* 오버라이딩 Overriding (메소드 재정의) : 상위 클래스에서 정의한 메소드와 이름은 같지만 메소드 안의 실행 코드를 달리하여 자식 클래스에서 재정의해서 사용할 수 있다.

 

✨ 연관성 Relationship

- is member of : 연관화

- is instance of : 분류화

- is part of : 집단화

- is a : 일반화(공통적인 성질들로 추상화한 상위 객체를 구성), 특수화/상세화(상위 객체를 구체화하여 하위 객체를 구성)

 

✨ 객체지향 분석의 방법론

- 럼바우 Rumbaugh : 가장 일반적, 분석 활동을 객체 모델/동적 모델/기능 모델로 나누어 수행하는 방법

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

- Jacobson : Use Case 갖오하여 사용

- Coad와 Yourdon : E-R 다이어그램 사용하여 객체의 행위를 모델링

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

 

✨ 럼바우 Rumbaugh 분석 기법

모든 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 기법 = 객체 모델링 기법 OMT

(1) 객체 모델링 = 정보 모델링 : 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 객체 다이어그램으로 표시하는 것

(2) 동적 모델링 : 상태 다이어그램응 이용하여 시간의 흐름에 따른 객체들 간의 제어 흐름, 상호 작용, 동작 순서 등의 동적인 행위를 표현

(3) 기능 모델링 : 자료 흐름도 DFD를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현

 

✨ 객체지향 설계 원칙 SOLID

- S 단일 책임 원칙 : 객체는 단 하나의 책임만!

- O 개방-폐쇄 원칙 : 기존의 코드를 변경하지 않고 기능을 추가할 수 있도록 설계

- L 리스코프 치환 원칙 : 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다!

- I 인터페이스 분리 원칙 : 자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야 한다!

- D 의존 역전 원칙 : 각 객체들간의 의존 관계가 성립될 때, 추상성이 낮은 클래스보다 추상성이 높은 클래스와 의존 관계를 맺어야 한다!

 

✨ 결합도 Coupling

모듈 간에 상호 의존하는 정도

두 모듈 사이의 연관 관계

- 결합도가 약할수록 품질이 높고, 강할수록 품질이 낮다.

- 결합도의 종류

(약함, 좋음) 자료 결합도 : 모듈 간의 인터페이스가 자료 요소로만 구성 될 때

↓

스탬프(검인) 결합도 : 모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달될 때

↓

제어 결합도 : 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호를 이용하여 통신하거나 제어 요소를 전달

↓

외부 결합도 : 어떤 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조할 때

↓

공통 결합도 : 공유되는 공통 데이터·영역을 여러 모듈이 사용할 때

↓

(강함, 나쁨) 내용 결합도 : 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때

 

✨ 응집도 Cohesion

정보 은닉 개념을 확장한 것

명령어나 호출문 등 모듈의 내부 요소들의 서로 관련되어 있는 정도

모듈이 독립적인 기능으로 정의되어 있는 정도

- 응집도가 강할수록 품질이 좋고, 약할수록 품질이 낮다.

- 응집도의 종류

(강함, 좋음) 기능적 응집도 : 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우

↓

순차적 응집도 : 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동의 입력 데이터로 사용할 경우

↓

교환(통신)적 응집도 : 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우

↓

절차적 응집도 : 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우

↓

시간적 응집도 : 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우

↓

논리적 응집도 : 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우

↓

(약함, 나쁨) 우연적 응집도 : 모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우

 

✨ 팬인 Fan-In / 팬아웃 Fan-Out

- 팬인 : 어떤 모듈을 제어(호출)하는 모듈의 수

- 팬아웃 : 어떤 모듈에 의해 제어(호출)되는 모듈의 수

→ 팬인 : A는 0 / B,C,D,E,G는 1 / F,H,I는 2

→ 팬아웃 : H,I는 0 / C,E,F,G는 1 / B,D는 2 / A는 3

 

✨ N-S 차트

Nassi-Schneiderman Chart

논리의 기술에 중점을 둔 도형을 이용한 표현 방법

= 박스 다이어그램 = Chapin Chart

 

✨ 공통 모듈

여러 프로그램에서 공통적으로 사용할 수 있는 모듈

공통 모듈을 구현할 때는 다른 개발자들이 해당 기능을 명확히 이해할 수 있도록 5가지 명세 기법을 준수해야 한다.

(1) 정확성

(2) 명확성

(3) 완전성

(4) 일관성

(5) 추적성 : 기능에 대한 요구사항의 출처, 관련 시스템 등의 관계를 파악할 수 있도록 작성

 

✨ 효과적인 모듈 설계 방안

- 결합도는 줄이고 응집도는 높여서 모듈의 독립성과 재사용성을 높인다.

- 모듈의 제어 영역 안에서 그 모듈의 영향 영역을 유지

- 복잡도와 중복성을 줄이고 일관성을 유지

- 모듈 크기는 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 분해

- 효과적인 제어를 위해 모듈 간의 계층적 관계를 정의하는 자료가 제시되어야 한다. 

 

✨ 디자인 패턴 Design Pattern

각 모듈의 세분화된 역할이나 모듈들 간의 인터페이스와 같은 코드를 작성하는 수준의 세부적인 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제

- 문제 및 배경, 실제 적용된 사례, 재사용이 가능한 샘플 코드 등으로 구성되어 있다.

- 개발 과정 중에 문제가 발생하면 새로 해결책을 구상하는 것보다 문제에 해당하는 디자인 패턴을 참고하여 적용하는 것이 더 효율적!

- GoF의 디자인 패턴은 유형에 따라 생성 패턴 5개, 구조 패턴 7개, 행위 패턴 11개 총 23개의 패턴으로 구성

- 객체지향을 기반으로 한 설계와 구현을 다루므로 다른 기반의 애플리케이션 개발에는 적합하지 않다.

 

✨ 생성 패턴 Creational Pattern

객체의 생성과 관련된 패턴, 총 5개

객체의 생성과 참조 과정을 캡슐화 하여 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 하여 프로그램에 유연성을 더해준다.

- 추상 팩토리 : 구체적인 클래스에 의존하지 않고, 인터페이스를 통해 서로 연관·의존하는 객체들의 그룹으로 생성하여 추상적으로 표현, 연관된 서브 클래스를 묶어 한 번에 교체하는 것이 가능

- 빌더 : 작게 분리된 인스턴스를 건축 하듯이 조합하려 객체를 생성, 객체를 생성 과정과 표현 방법을 분리하고 있어, 동일한 객체 생성에서도 서로 다른 결과를 만들어 낼 수 있음

- 팩토리 메소드 : 객체 생성을 서브 클래스에서 커리하도록 분리하여 캡슐화한 패턴, 상위 클래스에서 인터페이스만 정의하고 실제 생성은 서브 클래스가 담당함, 가상 생성자 패턴이라고도 함

- 프로토타입 : 원본 객체를 복제하는 방법으로 객체를 생성하는 패턴, 일반적인 방법으로 객체를 생성하며, 비죵이 큰 경우 주로 이용

- 싱글톤 : 하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만, 여러 프로세스가 동시에 참조할 수는 없음, 클래스 내에서 인스턴스가 하나뿐임을 보장하며, 불필요한 메모리 낭비를 최소화 할 수 있음

 

✨ 구조 패턴 Structual Pattern

클래스나 객체들을 조합하여 더 큰 구조로 만들 수 있게 해주는 패턴, 총 7개

구조가 복잡한 시스템을 개발하기 쉽게 도와준다

- 어댑터 : 기존의 클래스를 이용하고 싶지만 인터페이스가 일치하지 않을 때

- 브리지 : 구현부에서 추상층을 분리하여, 서로가 독립적으로 확장할 수 있도록 구성한 패턴, 기능과 구현을 두개의 별도 클래스로 구현

- 컴포지트 : 여러 객체를 가진 복합 객체와 단일 객체를 구분없이 다루고자 할 때 사용하는 패턴

- 데코레이터 : 객체 간의 결합을 통해 능동적으로 기능들을 확장할 수 있는 패턴

- 퍼싸드 Facade : 복잡한 서브 클래스들을 피해 더 사우이 인터페이스를 구성함으로써 서브 클래스들의 기능을 간편하게 사용할 수 있도록 하는 패턴, 서브 클래스들 사이의 통합 인터페이스를 제공하는 Wrapper 객체가 필요하다.

- 플라이웨이트 : 인스턴스가 필요할 때마다 매번 생성하는 것이 아니고 가능한 한 공유해서 사용함으로써 메모리를 절약하는 패턴

- 프록시 Proxy : 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴

 

✨ 행위 패턴 Behavioral Pattern

클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴, 총 11개

하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배하면서 결합도를 최소화 할 수 있도록 도와준다.

- 책임 연쇄

- 커맨드 : 요청을 객체의 형태로 캡슐화하여 재이용하거나 최소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴

- 인터프리터 : 언어에 문법 표현을 정의하는 패턴, SQL이나 통신 프로토콜과 같은 것을 개발할 때 사용

- 반복자 : 자료 구조와 같이 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴

- 중재자 : 수많은 객체들 간의 복잡한 상호작용을 맵슈로하하여 객체로 정의하는 패턴

- 메멘토 : Ctrl+Z 같은 되돌리기 기능

- 옵서버 : 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴

- 상태 : 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용

- 전략 : 동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴

- 템플릿 메소드 : 상위 클래스에서 골격을 정의하고, 하위 클래스에서 세부 처리를 구체화하는 구조의 패턴

- 방문자 : 각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴, 분리된 처리 기능은 각 클래스를 방문하여 수행한다.

 

✨ 요구사항 검증 방법

- 요구사항 검토 : 요구사항 명세서의 오류 확인 및 표준 준수 여부 등의 결함 여부를 컴토 담당자들이 수작업으로 분석

(1) 동료검토 : 명세서 작성자가 명세서 내용을 직접 설명하고 동료들이 이를 들으면서 결함을 발견

(2) 워크스루 : 검토 회의 전에 명세서를 미리 배포하여 사전 검토한 후, 짧은 검토회의를 통해 결함을 발견

(3) 인스펙션 : 명세서 작성자를 제외한 다른 검토 전문가들이 요구사항 명세서를 확인하면서 결함을 발견

- 프로토타이핑 : 실제 개발될 소프트웨어에 대한 견본품(Prototype)을 만들어 최종 결과물 예측

- 테스트 설계 : 테스트 케이스를 생성하여 이후에 요구사항이 현실적으로 테스트 가능한지 검토

- CASE 도구 활용 : 일관성 분석을 통해 변경사항의 추적 및 분석, 관리하고, 표준 준수 여부 확인

 

✨ 미들웨어 Middleware

Middle + Software

운영체제와 응용 프로그램, 또는 서버와 클라이언트 사이에서 다양한 서비스를 제공하는 소프트웨어

- DB : DB를 사용하여 시스템을 구축하는 경우 보통 2-Tier 아키텍처라고 함

- RPC : Remote Procedure Call 원격 프로시저 호출

- MOM : 메세지 지향 미들웨어, 온라인 업무보다는 이기종 분산 데이터 시스템의 데이터 동기를 위해 많이 사용

- TP-Monitor : 트랜잭션 처리 모니터, 사용자 수가 증가해도 빠른 응답 속도를 유지해야하는 업무에 주로 사용 (항공기나 철도 예약 업무)

- ORB : 객체 요청 브로커, 갹체 지향 미들웨어로 코바(CORBA) 표준 스펙을 구현한 미들웨어

- WAS : 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용, 클라이언트/서버 환경보다는 웹 환경을 구현하기 위한 미들웨어