히앤님의 개발 세상

간단하게 남겨보는 정보처리기사 필기 후기.

과목은 총 5개이다.

1. 소프트웨어설계

2. 소프트웨어개발

3. 데이터베이스구축

4. 프로그래밍언어활용

5. 정보시스템구축관리

2024년 정보처리기사는 서울 지역 기준 수많은 "컴퓨터학원" 등에서 시행된다. 

이전과 같이 종이에 문제를 푸는 식이 아니기 때문에, 컴퓨터용 싸인펜이 필요없고 점수와 합격 여부도 바로 나온다.

물론 이 점수가 확정은 아니다. 문제의 오류 여부에 따라 수정될 가능성이 있긴 하지만....확률은 거의 희박하다.

어쨌든 점수가 바로 나와서 합격 여부를 알 수 있다는 점이 좋다.

개인적으로 수학도 집합부분 열심히 공부했던 사람으로써ㅋㅋㅋㅋ 1과목은 80점대로 높은 점수를 얻어 평균을 올린 점이 합격에 도움을 주지 않았나 싶다. 3,5 과목은 확실히 소홀했던 것 같고... 나머지  2과목의 계산문제(정렬, 트리순회 알고리즘), 4과목의 코딩문제에 힘을 쏟았는데 이 전략이 잘 맞았다 생각한다. 오히려  무조건 맞을 수 있는 문제가 이러한 연산 문제인 것 같음....말장난이 제일 헷갈리고 어려웠다ㅜㅜ

같은 날 친구랑 함께 시험을 봤는데, 시험 이후 문제에 대해 이야기를 나누니 겹치는 문제가 없었다(?)
이말인 즉슨, 컴퓨터로 보기 때문에 시험 문제를 문제은행 식으로 여러 버전을 랜덤으로 보는 것 같음.

처음에는 문제 순서를 바꾼 줄 알았는데 아예 내가 푼 문제를 보지 못했다는 걸 듣고 버전이 여러개 일 수 있겠다는 생각을 했다.

 특히나 4과목이 SQL, Java, Python, C언어 문제 등 여러가지 언어 문제가 있는데, 친구는 대부분 Python 문제로 나왔고, 나는 한개정도만 나오고 대부분 C 아니면 Java 였다... 어떤식으로 나올지 모르니 잘 봐두는게 좋겠다.

나느 5과목이 점수가 잘 안나왔는데 헷갈리는 문제가 너무 많았다. 단어를 영문으로 표기하거나, "안", "못" 이런 글자 하나로 갈리는 문제가 꽤 있어서 풀이하는 데에 오래 걸렸음. 5과목 때문에 끝까지 남아서 풀었다.

시간은 150분으로 넉넉했고, 화면 우측 상단에 남은 시간이 써있어서 좋았다.

화면은 우측에 OMR처럼 체크가 되는 부분이 있고, 좌측에 문제가 나온다. 문제도 격자를 두어 한 페이지에 많이 볼지, 아니면 한문제씩 볼지 등 설정할 수 있고, 글자 크기도 확대 축소 등이 가능하다. 문제푸는 사람에 따라 눈이 나쁠수도 있을텐데 여러모로 고려를 했다는 점이 좋았다.

마지막에 답 제출버튼 클릭하면 "제출하시겠습니까?" 문구가 총 2번 뜬다.

여러번 확인 후 [예] 버튼을 두번 눌러 제출했다.

제출하고 바로 점수가 나와서 그런지 나가시는 분들의 여러모로의 탄성과 한숨을 들을 수 있던 것이 킬포...

이 다음 실기도 준비 잘 해보고도록 해야지.

1. 소프트웨어 생명주기(SDLC)

-> 소프트웨어 설계 및 구축 개발할 때 효율적일 수 있도록 다양한 방법을 사용함.

1) 폭포수모델

- 계속해서 다음단계가 떨어지는 모양새
- 이전단계로 돌아갈 수 없음.
- 각 단계를 그만큼 확실하게 진행하고 검토하고 승인한 뒤 다음단계로 넘어가야함.
- 가장 전통적인 방법(고전적 생명주기 모형)
- 두개 이상의 과정을 병행하지 않고 한번에 하나씩만.
- 순서 : 타당성 검토-계획-요구분석-설계-구현-시험-유지보수(타계요설구시유)
- 선형적 방식일 때, 요구사항이 아주 명확할 때 사용

2) 프로토 타입

- 사용자의 요구사항에 정확히 맞추기 위해 시제품(prototype)으 만들어서 최종 결과물 예측함.
- 폭포수 모델 단점 보완(폭포수 모델로 개발이 완료되고 오류가 발생한 경우)
- 순서 : 요구 수집-빠른설계-프로토타입 구축-고객평가-조정-구현(요설프고조구)

3) 나선형 모형

- 폭포수+프로토타입+위험분석 기능 추가
- 나선형처럼 여러번 개발 과정을 거쳐서 점진적으로 결과 완성
- 위험 관리 및 최소화 가능
- 추가되는 요구사항 반영 가능.
- 순서 : 계획-위험분석-개발-평가 를 반복함
- 문제는 관리가 어렵다

4) 애자일 모형

- 민첩하게 고객의 요구사항 변화에 대응한다. 일정한 주기를 가지고 반복 개발
- 고객과의 소통
- 스프린트 단위의 개발 주기 반복
- 고객의 우선순위애 따라 개발진행
- 애자일 기반 소프트웨어 개발 모형
  * 스크럼(Scrum) - 팀 중심으로 백로그(backlog)라는 요구사항 우선순위에 따라 계속해서 스프린트끝나면 회고하고 회의하고 함.
  * XP(eXtreame Programming) - 고객이 적극 참여해서 단위별 릴리즈를 하고, 특정 기능을 위한 스파이크 테스트를 하여 조금씩 배포. 

    중요가치 : 의사소통, 단순성, 용기. 존중, 피드백

    방법 : 짝프로그래밍, 공동코드소유, 테스트주도개발. 전체팀, 계속적통합, 디자인개선/리팩토링, 소규모릴리즈)
 

 *칸반(Kanban), Lean, 크리스탈(Crystal), ASD(Adaptive Software Development), FDD(Feature Driven Development),DSDM(Dynamic System Development),DAD(Disciplined Agile Delivery) 등

2. 시스템 파악

-> 시스템의 개발 범위와 개괄적 틀

- 구성(업무 시스템별 기능 및 담당)
- 기능(어떤걸 만들어야하는지)
- 인터페이스(규약-프로토콜, 데이터형식 등)
- 아키텍쳐(구조-주요업무를 기준으로 각시스템 동작원리 및 구성)
- 소프트웨어
- 하드웨어
- 네트워크(구성 및 물리적 위치 구성도 작성하면 유지보수에 활용됨)

3. 개발기술 환경 파악

- OS(운영체제 - 주변기기가 지원되는지?)
- DBMS(DB관리시스템 - 상호호환성)
- WAS(웹 어플리케이션 서버-미들웨어)

선택 시 고려할 점)가성비기오
가용성(가능?), 성능, 기술지원, 비용, 오픈소스

4. 요구사항

원하는 서비스에 대한 설명 및 운영에 필요한 제약조건을 쓴다. 기능은 뭐고, 품질이나 제약사항은 어떻고, 사용자랑 개발자 사이의 합의 내용을 작성

1) 순서

도출-분석-명세-확인
요구사항 수집 후 분석해서 내용정리, 문서화한 뒤 고객한테 검토 요청함
이 때 확인 시 프로토타입을 주기도 하고, 모델을 논리적으로 검증하거나 테스트를 하기도 함.

2) 요구사항 분석

- 자료 흐름도 (DFD: Data Flow Diagram)
요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법

- 자료 사전 (DD: Data Dictionary)
자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것

- 자동화도구 CASE 종류
SADT (Structured Analysis and Design Technique)
SREM (Software Requirements Engineering Methodology) = RSL/REVS
PSL (Problem Statement Language)
PSA (Problem Statement Analyzer)
TAGS (Technology for Automated Generation of Systems)

- 문서화도구 HIPO (Hierarchy Input Process Output)
트리 구조로 된 하양식 계층을 보여주는 도표이다. 
가시적(visual,목차)

총체적(overView,개요)

세부적(detail,내용)

3) 요구사항 검증

- 워크 스루(Walk Through) : 검토회의 전에 요구사항 명세서를 미리 배포하여 사전 검토한 후 짧은 검토 회의를 통해 오류를 조기에 검출하는데 목적을 두는 요구사항 검토 방법
- 인스펙션(Inspection) : 전문가 또는 팀이 검사하여 오류를 찾아내는 검토 방법
- 동료검토(Peer Review) : 2~3명 리뷰

5. UML(Unified Modeling Language)

객체지향 모델링 언어로 시스템 분석, 설계 시 고객과 대화하기 위해 만들어짐. 그림으로 되어있음.

1) 전체요소

사물(노드), 관계(선), 다이어그램(도형)

[관계 관련]

연관(사람→집)
집합(컴퓨터◇—프린터)
포함(문◆— 키)
일반화(커피◁— 아메리카노)
의존(등급⇢할인율)
실체화(비행기(…▷날수있는) 수행해!
스트레오타입(<<>>) 추가기능 표현

[다이어그램 관련]

- 구조적 다이어그램(정적모델링) - 클객컴배복패
클래스(클래스 사이의 관계와 속성, 제약조건 표시)
객체(특정 시점의 객체간의 관계 표시)
컴포넌트(기능을 하는 한 컴포넌트간의 관계 표시)
배치(결과물의 위치를 어떻게둘지 표시)
복합체구조(여러개 섞여있으면 내부는 어떤지 표시)
패키지(이 모든 것들을 그룹해서 그들간의 관계 표시)

- 행위 다이어그램(동적모델링) - 유시커상활상타
유스케이스(사용자관점에서 사용 사례를 기준으로 작성한 것, 요구사항 분석 시 사용)
시퀀스/순차(시간의 흐름에 따라 객체들끼리 메시지 주고받는거 표시)
커뮤니케이션(시퀀스가 메시지만 쓴다면 얘는 메시지와 관계까지 포함)
상태(변화에 따라 어떻게 바뀌는지 표시)
활동(시스템이 어떤 기능 수행할 때 조건이나 처리흐름 표시)
상호작용 개요(상호작용할 때 제어 흐름 표시)
타이밍(언제 하는지 시간제약 표시)

 * 럼바우 객체지향 분석 기법(객체, 상태 다이어그램 사용함)
 * E-R다이어그램(개체, 관계, 속성)

6. UI(사용자 인터페이스)

-> 사용자와 시스템 간의 소통을 도와주는 장치

1) 분야

- 제어(정보 제공과 전달을 위한 물리적 제어)
- 구성(콘텐츠의 상세적인 표현과 전체적인 구성)
- 기능(모든 사용자가 편리하고 간편하게 사용하도록 하는 기능)

2) 특징

- 편리하고 가독성 좋고, 시간 단축, 이해도 상승, 오류 줄여줌.

- 하지만 소프트웨어 아키텍쳐를 반드시 숙지해야함.

3) 구분

- CLI(커맨드-텍스트로(cmd 같은거))
- GUI(그래픽)
- NUI(네추럴-말이나 행동으로)
- VUI(보이스)
- OUI(오가닉-상호작용으로 조작 IOT같은거)

4) 기본원칙(직유학유)

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

5) 한국 웹 컨텐츠 접근성 지침(KWCAG)

=> 웹 접근성 : 장애인도 비장애인과 동등하게 접근할 수 있게끔 하는 접근성 지침

- 인식의 용이성 : 대체 텍스트, 멀티미디어 대체 수단, 명료성, 

- 운용의 용이성 : 광과민성 발작 예방(빛조심), 쉬운 내비게이션

- 이해의 용이성 : 가독성

- 견고성 : 문법 준수, 접근성

- 네비게이션 필요(사이트맵, 메뉴바 등)

6) UI 설계 도구

- 와이어프레임(Wireframe) : 화면 단위로 대략적인 레이아웃을 구성 -> 더 실체화되면 그게 목업
- 목업(Mockup) : 실제화면과 유사한 형태로 만드는 단계, 껍데기, 기능 x
- 스토리보드(Story Board) : 와이어프레임에 콘텐츠의 이동경로 작성, 메뉴얼(작업 지침서)
- 프로토타입(Prototype) : 가라 데이터 넣고 테스트
- 유스케이스(Use Case) : 사람 도형 다이어그램에 사용자 요구사항 표시 및 내용 작성

7) 소프트웨어 품질 요구사항(기신사효유이)

- 기능  :  적절한 기능이 정확하게 + 호환, 보안 (적절,정확,호환,상호운용,보안,간결)
- 신뢰  :  고장이 나도 상관없어! (성숙,회복,고장허용)
- 사용  :  얼마나 쉽고 편한지 (이해,학습,운용,친밀)
- 효율  :  한정된 시간, 자원으로 많은 일처리 (시간, 자원)
- 유지보수  :  개선 및 확장에 관계된 부분 (분석,변경,시험,안정)
- 이식 : 서로 다른 환경에서 SW가 정상적으로 작동하는지(적용,설치,대체,공존)

*** 국제표준 ISO/IEC 9126 또는 25010 / 테스트절차 포함 ISO/IEC 12119

8) 감성공학

- HCI  :  사람이 더 편하게 시스템을 사용할 수 있게 하는 학문. 최적의 UX(사용자경험)이 목표.

- 감성공학은 인간친화적인 시스템 개발 목표

7. 소프트웨어 아키텍처

->소프트웨어 기본구조 및 구성요소들 간의 관계 표현

1) 기본 원리

- 모듈화 : 부품별

- 추상화 : 각 요소 공통부분을 묶는거   *** 제과자 (제어, 과정, 자료)

- 단계적 분해 : 추상화 반복할수록 뭉탱이로 분해 가능

- 정보은닉 : 캡슐안에 뭐가 있는지 모르는 것처럼 정보 은닉 가능

2) 설계 단계

설계 목표 설정 - 시스템 타입 결정(대화형, 이벤트형 등) - 아키텍처 패턴 적용 - 서브시스템 구체화 - 검토

3) 품질 속성

- 시스템 측면(성능, 보안, 가용성, 기능성, 사용성, 변경용이, 확장성 : 성보가기사변확)

        -> 빠르고, 안전하고, 오류 없이 사용가능하고, 기능 다 있고, 사용하기 쉽고, 다른데에서도 쓸 수 있고, 용량 확장 가능함

- 비지니스 측면(시간적시성, 비용, 수명 : 시비수)

        -> 시간 맞춰서 출시하고, 비용 적게 들고, 오래 쓸 수 있고

- 아키텍쳐 측면(개념적 무결성, 정확성, 구축가능성 : 개정구)

        -> 시스템의 일관성이 있고, 요구사항 충족하고, 잘 쪼개져있어서 시스템 분배해서 유연하게 일정변경 가능함.\

8. 아키텍처 패턴

-> 설계 시 전형적인 해결방식 및 예제, 템플릿. 이거 쓰면 시간 단축, 품질 향상, 검증편리, 유지보수 편함

1) 레이어(계층) 패턴

계층 구분되서 마주보는 상위-하위 두 계층만 상호작용함. 특정 레이어만 교체할 수 있어서 좋음.

ex) OSI 참조모델

2) 클라이언트-서버 패턴

서버 1개에 다수의 클라이언트가 있어서 클라이언트가 서버에 서비스 요청하면 응답해줌. 서버는 계속 대기해야함.

ex) 이메일

3) 마스터 슬레이브 패턴

조별과제 팀장(마스터)이 팀원들한테 똑같은 업무를 나눠서 지시하고 결과 합쳐서 최종본 만드는 것.

몇명 일 안해도 괜춘ㅋㅋ

ex) 장애허용시스템, 컴퓨터 메모리 같은거

4) 파이프 필터 패턴

데이터 스트림(흐름)에 따라 각 필터 단계마다 캡슐화 후 파이프로 데이터 전송함. 필터나 조건 추가 용이

ex) 유닉스의 Shell

5) 브로커 패턴

브로커가 컴포넌트 간의 통신을 조정함. 서버가 기능을 이것저것 제공해주면 브로커가 필요한것만 줌.

ex) 필요한 메시지만 띄우는 시스템, 원격서비스 

6) 피어투피어 패턴

피어(각 컴포넌트)는 클라이언트가 될수도 있고 서버가 될 수도 있음. 즉, 양방향으로 서로 서비스 제공함.

ex) P2P 사이트, 토렌트 등의 파일공유 시스템

7) 이벤트버스 패턴

이벤트 내용(source)을 이벤트 실행도구(bus)를 통해 이벤트 채널(channel)에 발행하면, 각각 채널 구독자(listener)가 구독한 채널의 알람을 받는다.  

ex) 알람서비스

8) 모델뷰컨트롤러 패턴

MVC로 불리며, 뇌(컨트롤러)가 order 하면 기능과 데이터(모델)가 화면(뷰)에 표시되는 것. 정보가 다 분리되고 중요한건 암호화되고, 따로 뇌만 빼서 쓴다던지, 디자인만 빼서 쓴다던지 재사용이 용이함.

ex) 대부분 웹 애플리케이션

9) 블랙보드 패턴

패턴추출 모델같은거임. 블랙보드에 정보(지식소스) 쌓아놓고 원하는 정보를 찾으면 컨트롤러가 빼감.

ex) 음성인식, 차량식별 등의 학습 프로그램들

10) 인터프리터 패턴

특정 언어로 작성된걸 해석하는 컴포넌트 설계할 때 사용.

ex) SQL 같은 DB쿼리 언어, 통신 프로토콜 정의 언어

9. 객체지향(OOP)

-> 각 객체를 조립해서 사용함. 빠르고 재사용성 좋고 유지보수 편하다. 하지만 절차형에 비해 속도는 느림

1) 기법

- 객체 = 이름, 상태, 관계에 따라 하나로 묶는거(데이터 + 함수)

- 클래스 = 객체의 집합, 공통속성끼리 묶고 인스턴스화 라고 부름

- 캡슐화(정보은닉, 관련된거 묶음)

- 다형성(각각 일하는게 아니라 통합객체에 다양한 타입이 모여서 각자응답함, 오버라이딩, 오버로딩)

- 상속성(부모-자식 형태로 자식이 부모꺼 다 갖다씀)

- 연관성(상호참조해서 씀/연관화, 분류화, 집단화, 일반화, 특수화)

2) 방법론

- Rumbaugh (럼바우) 방법론 : 객체(다이어그램)-동적(상태표시)-기능(자료흐름도 DFD) 로 나누어서 수행(객동기)

   이게 바로 객체 모델링 기법(OMT)

- 부치(Booch) 방법론 : 미시적-거시적 프로세스 모두 사용

- 자콥슨(Jacobson)방법론 : 유스케이스 강조해서 사용자 중심으로

- 코드와 여돈(coad & yourdon)방법론 : E-R 다이어그램 사용해서 객체의 행위를 모델링

- 와프스브록(Wirfs-Brocks) 방법론 : 분석 설계를 함께 연속적으로 한다. 고객 명세의 평가로 시작해서 설계로 끝난다.

3) 객체지향 설계원칙

- 단일 책임의 원칙 (SRP) (Single Responsibility Principle) - 하나의 클래스는 하나의 목적만을 위해 생성(1객체 1책임, 응집up 결합 down)

- 개방 폐쇄 원칙 (OCP) (Open Close Principle) - 확장 열려있고 변경은 닫혀있다(기능추가가능,하지만 캡슐화)

- 리스코프 치환의 원칙 (LSP) (Liskov Subsitution) - 상속 가능

- 인터페이스 분리의 원칙 (ISP) (Interface Segregation Principle) - 사용 안하는 메서드와 관계 없어야함.(독립성)

- 의존성 역전의 원칙 (DIP) (Dependency Inversion Principle) - 추상화에 의존해야지 구체화에 의존하면 안됨. 고수준 모듈이 저수준 모듈에 영향을 많이 받으면 안됨. 저수준 모듈은 빈번히 바뀌니까.

10. 모듈

-> 기능별로 쪼갬. 재사용, 유지보수 가능함. 독립성이 강해야함.

1) 품질을 높이려면

독립성 ↑ = 결합도↓ + 응집도↑

- 결합도 : 상호의존의 정도 / 약해야 품질이 좋아짐(자스제외공내)

자료 → 스탬프 → 제어 → 외부 → 공유 → 내용 (약한순 ~ 강한순)

- 응집도 : 강할수록 품질이 좋아짐(기순교절시논우)

기능 → 순차 → 통신 → 절차 → 시간 → 논리 → 우연 (강한순 ~ 약한순)

2) 제어신호

시스템 복잡도 ↓ =   인↑  + 아웃↓ 

- 팬-인 : 내가 제어(모듈로 들어오는 신호, 화살표가 들어옴)

- 팬-아웃 : 제어당함(모듈로 나가는 신호, 화살표가 나감)

복잡도를 낮추려면 다 나한테 들어와서 내가 관리하는게 낫지.

3) 공통모듈

-> 로그인 기능처럼 자주쓰는 것들

- 명세기법) 정확성(필요), 명확성, 완전성, 일관성(충돌방지), 추적성(출처)

11. 코드

-> 모듈이나 컴포넌트 식별 기능

- 기본기능 :  식별, 분류, 배열(나열), 표준화, 간소화

- 종류 : 순차(차례대로), 블록(조직도처럼), 10진(도서관처럼), 그룹분류(책 일련번호처럼), 연상(Mac_Air12), 표의숫자(가구치수(1200x600)처럼)

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

-> 설계 후 세부 구현 방안의 전형적인 예제. 비용을 줄일 수 있고, 객체지향에만 적합함.

- 생성(추빌백프싱) / 구조(어브컴데플프)  / 행동(메스체커인이메옵스템비)

• 생성 패턴

  추상 팩토리 (Abstract Factory)	상위 클래스의 객체 생성코드를 하위클래스가 상속받는다 (상위변경 = 하위자동변경)
  빌더 (Builder)	분리된 인스턴스를 조합하여 객체 생성. 같은 객체를 생성해도 다른 결과를 도출할 수 있음
  팩토리 메소드 (Factory Method)	상위 클래스는 객체를 생성하는 인터페이스만 제공하고, 하위 클래스에서 인스턴스 생성
  프로토타입 (Prototype)	Prototype 먼저 생성하고, 인스턴스를 복제하여 사용, 비용 저렴
  플라이웨이트	다수의 유사 객체 생성이 필요할 때 최대한 공유해서 사용, 메모리 절약
  싱글톤 (Singleton)	클래스 내 생성되는 인스턴스가 하나만 필요할 때 사용(동시참조X)

• 구조 패턴

  어댑터(Adapter)	일치하지 않는 인터페이스 변환(전류 어댑터와 같은 역할) 기존에 구현되어 있는 클래스에 기능 발생 시 기존 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할
  브릿지(Bridge)	추상층(기능)과 구현층(구체화)을 분리하여 서로 독립적 확장 가능
  합성(Composite)	단일/복합 객체를 하나로 다루기 위해  트리구조로 구성
  데코레이터(Decorator)	클래스에 기능을 추가하기 위해 다른 객체를 덧붙이는 형태
  프록시(Proxy)	접근이 어려운 객체에 접근할 수 있도록 인터페이스 역할 수행

• 행동 패턴

  중재자(Mediator)	객체간의 통제와 지시의 역할을 하는 중재자를 두어 객체지향 목표 달성하게 해줌 (상호작용을 캡슐화하여 결합도를 낮추기위해 사용)
  상태(State)	이벤트를 객체 상태에 따라 다르게 처리해야할 때 사용. 카톡 알림설정 같은 느낌
  책임 연쇄(Chain of Responsibility)	요청을 처리할 수 있는 객체가 둘 이상 존재하여 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태의 패턴. 각 객체들이 고리(Chain)으로 묶여있어 요청이 해결될 때까지 고리를 따라 책임이 넘어간다.
  커맨드(Command)	명령어를 캡슐화하여 재사용하거나 취소할 수 있도록 필요한 정보를 로그에 남기는 형태
  인터프리터(Interpreter)	언어에 문법 표현을 정의하는 패턴
  반복자(Iterator)	접근이 잦은 객체는 동일한 인터페이스를 사용하도록 하는 패턴
  메멘토(Memento)	특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴이다. Ctrl+Z 기능이 이 패턴의 대표적 기능
  옵저버(Observer)	이벤트 발행과 구독, 상태 변화 전달. 한 객체의 상태가 변화하면 객체에 상속되어있는 다른 객체들에게 변화된 상태를 전달하는 패턴. 카톡의 읽음표시 같은 느낌
  전략(Strategy)	동일 계열 알고리즘 상호 교환, 독립적 사용
  템플릿 메소드(Template Method)	상위에서 인터페이스를 정의하고 하위에서 구체화시킴 (유지보수 쉬워짐)
  방문자(Visitor)	처리 기능을 별도의 클래스로 구성. 분리된 처리 기능은 각 클래스를 방문(Visit)하여 수행한다.

13. 시스템 인터페이스

-> 독립적으로 떨어져있는 시스템 간의 상호작용에 대한 접속방법이나 규칙을 의미.

1) 요구사항 분석 절차

선별 - 자료준비 - 분류 - 분석 및 명세서 구체화 - 검토

2) 요구사항 검증 방법

- 동료검토(peer Review) : 내가 설명해볼께! 태클 ㄱㄱ

- 워크스루(work Through) : 미리 배포할테니 봐보셈ㅇㅇ

- 인스펙션(Inspection) : 전문가님, 좀 봐주셈

- CASE 도구 활용(Computer Aided Software Engineering) : 일관성 분석을 통해 확인

3) 미들웨어

- 하드웨어, 프로토콜, 통신 환경 등을 연결하는 중간연결 소프트웨어

- 위치 투명성을 제공(시스템의 논리적인 명칭만으로 access가능)

종류) DB(데이터베이스:ODBC), REC(프로시저), MOM(메시지), TP-Monitor(트랜잭션, 빠른 속도 감시), ORB(브로커, 코바(CORBA) 표준), WAS(동적인 웹 구현)