보다 나은 내일, 다이어리

작년에 정보처리기사는 이미 땄다.

근데 왜 다시 공부하는가?

전체적인 Computer Science를 복습하기엔 정보처리기사가 제격이라고 생각했다!

운영체제, 네트워크, 자료구조, 컴퓨터구조, 데이터 베이스 등 CS의 핵심 내용을 다 다루기 때문이다. 

현 상태는 개념들을 대충은 알지만 누군가가 내게 물어본다면 ...? 자신있게 말하지 못할 것 같았다.

Output이 안된다고나 할까. 그래서 이건 내가 요약해서 정리한 것이니까 나중에 봤을 때도 내가 가장 이해하기 쉬울 것이고 기억에 남기도 더 쉬울 것이라고 판단했다.

또한 지금까지 했던 개발에서 디자인 패턴이나 그런 설계들을 의도적으로 고려하진 않았던 것 같은데, 정처기로 관련 개념들을 다시 정리하면서 '내가 개발한 게 이 패턴이었구나~' 하면서 뭔가 좀 재밌게 복기할 수 있을 것 같았다.

그리고 타이핑 공부법이란?

말 그대로 타이핑하면서 공부하는 방법...인데 어디 유튜브에서 본 방법이다. 

Input과 Output 이 필요한 과정에서 Output의 속도를 미친듯이 올려준다.

1. 일단 정처기 핵심요약본을 읽고 이해한다.

2. 내가 머리에 넣을 수 있을 부분까지 타이핑으로 써본다. 

3. 잘 안써지는 부분은 색칠한다.

4. 나중에 다시 해당 부분을 볼 때도 안떠오르는 부분은 다른 색으로 덧칠한다.

...

언제 끝날진 모르지만.....화이팅!

67. 구조패턴 (Structural Pattern)

클래스나 객체를 조합해서 더 큰 구조로 만들 수 있게 해 주는 패턴

총 7개

1. 어댑터, Adapter
   호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환해주는 패턴
   기존 클래스를 이용하고 싶지만 인터페이스가 다를 때 이용
   
   
2. 브리지, Bridge
   구현부에서 추상층을 분리하여 독립하여 확장할 수 있도록 한 패턴.
   기능과 구현을 두 개의 별도 클래스로 구성
   
   
3. 컴포지트, Composite
   객체들을 트리 구조로 구성하여 디렉터리 안에 디렉터리가 있듯이 복합 객체 안에 복합 객체가 포함된 구조 표현할 수 있음
   
   
4. 데코레이터, Decorator
   객체 간 결합을 통해 능동적으로 기능 확장할 수 있는 패턴
   임의의 객체에 부가기능 추가 위해 다른 객체를 덧붙이는 방식으로 구현
   
   
5. 퍼싸트, Facade
   서브 클래스들 사이의 통합 인터페이스를 제공하는 Wrapper 객체가 필요
   복잡한 서브 클래스를 피해 상위에 인터페이스를 구성함으로써 서브 클래스들의 기능을 간편하게 사용할 수 있도록 함
   
   
6. 플라이웨이트, Flyweight
   다수의 유사 객체를 생성할 때 유용
   매번 인스턴스를 생성하는 게 아니라 가능한 한 공유해서 사용함으로써 메모리를 절약
   
   
7. 프록시, Proxy
   접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴
   네트워크 연결, 메모리의 대용량 객체로의 접근 등에 주로 이용

68.  행위 패턴(Behavioral Pattern)

클래스나 객체가 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴
하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배하면서 결합도 최소화에 도움

총 11개

1. 책임 연쇄, Chain of Responsi-bility
   요청을 처리할 수 있는 객체가 chian으로 묶여 있어 요청이 해결될 때까지 책임이 넘어감
   
   
2. 커맨드, Command
   요청을 객체 형태로 캡슐화해서 재사용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴
   요청에 사용되는 각종 명령어들을 추상 클래스로 분리하여 단순화함
   
   
3. 인터프리터, Interpreter
   언어에 문법 표현을 정의하는 패턴
   SQL이나 통신 프로토콜과 같은 것을 개발할 때 사용
   
   
4. 반복자, Iterator
   접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 함, 내부 표현 방법 노출 없이 순차적 접근 가능
   
   
5. 중재자, Mediator
   수많은 객체들 간의 복잡한 상호작용(Interface)를 캡슐화하여 객체로 정의
   
   
6. 메멘토, Memento
   특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공, Ctrl+Z 같은 되돌리기 기능을 개발할 때 주로 이용
   
   
7. 옵서버, Observer
   한 객체의 상태가 변하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴
   주로 분산된 시스템 간에 이벤트를 생성/발행(Publish)하고, 이를 수신(Subscribe)해야 할 때 이용
   
   
8. 상태, State
   객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용
   
   
9. 전략, Strategy
   동일한 계열의 알고리즘을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴
   클라이언트는 독립적으로 원하는 알고리즘을 선택하여 사용할 수 있으며, 클라이언트에 영향 없이 알고리즘의 변경이 가능
   
   
10. 템플릿 메서드, Template Method
    상위 클래스에서 골격을 정의하고 하위 클래스에서 세부 처리를 구체화하는 구조의 패턴
    유사한 서브 클래스를 묶어 공통된 내용을 상위 클래스에서 정의함으로써 코드 양 줄이고 유지보수 용이하게 함
    
    
11. 방문자, Visitor
    각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴
    분리된 처리 기능은 각 클래스를 방문(Visit)하여 수행함

69. 요구사항 검증 방법

• 요구사항 검토, Requirements Review: 담당자들이 수작업으로 분석
  - 동료검토, Peer Review: 작성자가 직접 설명하고 동료들이 결함을 발견
  - 워크스루, Walk Through: 회의 전 미리 배포하여 사전 검토 후 회의를 통해 결함을 발견
  - 인스펙션, Inspection: 작성자를 제외한 다른 전문가가 결함을 발견
  
  
• 프로토타이핑, Prototyping: 요구사항을 정확히 파악하기 위해 견본품을 만들어 최종 결과물을 예측
  
  
• 테스트 설계 : 테스트 케이스를 생성하여 이후에 요구사항이 현실적으로 테스트 가능한지를 검토함
  
  
• CASE 도구 활용 : 일관성 분석을 통해 요구사항 변경사항의 추적 및 분석, 관리하고 표준 준수여부 확인
  *CASE : Computer Aided Software Engineering
  : 요구사항을 자동으로 분석, 요구사항 명세서를 기술하도록 개발된 요구사항 분석을 위한 자동화 도구

72. 미들웨어 (Middleware)

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

• DB, Datebase: DB를 사용하여 시스템을 구축하는 경우 보통 2-Tier 아키텍쳐라고 함. 클라이언트에서 원격의 데이터베이스와 연결하기 위한 미들웨어
• RPC, Remote Procedure Call : 원격 프로시저 호출, 응용 프로그램을 사용해서 원격 프로시저를 마치 로컬 프로시저처럼 호출
• MOM, Message Oriented Middleware : 메시지 지향 미들웨어, 메시지 기반의 비동기형 메시지를 전달하는 방식의 미들웨어, 온라인 업무보단 이기종 분산 데이터 시스템의 데이터 동기를 위해 사용됨
• TP-Monitor, Transaction Processing Monitor: 트랜젝션 처리 모니터, 항공기나 철도예약업무와 같은 온라인 트랜젝션 업무에서 처리 및 감시하는 미들웨어, 사용자 수가 증가해도 빠른 응답속도를 유지해야 하는 업무에 주로 사용됨
• WAS, Web Application Server: 정적인 컨텐츠를 처리하는 웹 서버와 달리 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어, 클라이언트/서버 환경보다는 웹 환경을 구현하기 위한 미들웨어

화이팅~!!!

🚩 2과목. 소프트웨어 개발

73. 자료구조의 분류

74. 선형 리스트 (Linear List)

• 연속 리스트, Contiguous List
  배열 같이 연속적으로 저장되는 자료구조
  이용효율은 밀도가 1로서 가장 베스트
  중간에 데이터를 삽입하려면 연속된 빈 공간이 있어야 하고, 삽입과 삭제 시 자료 이동이 필요
  
  
• 연결 리스트, Linked List
  자료를 반드시 연속적으로 저장하지 않고 임의의 장소에 저장하고 , 노드의 포인터 부분을 이용해서 서로 연결시킨 자료구조
  노드의 삽입과 삭제가 용이
  포인터 부분이 필요하므로 이용효율이 좋진 않다
  연결을 위한 포인터를 찾는 시간이 필요하기 때문에 접근 속도가 느리다.
  
  
  

75. 스택 (Stack)

리스트의 한쪽 끝으로만 삽입과 삭제가 이루어지는 자료구조

후입선출 LIFO, Last In First Out: 가장 나중에 삽입된 자료가 가장 먼저 삭제된다.

응용분야

• 함수 호출의 순서 제어
• 인터럽트의 처리
• 수식 계산 및 수식 표기법
• 컴파일러를 이용한 언어 번역
• 부 프로그램 호출 시 복귀주소 저장
• 서브루틴 호출 및 복귀주소 저장

76. 큐 (Queue)

리스트의 한쪽 끝에서 삽입이 이루어지고 다른 쪽에선 삭제가 이루어지는 자료 구조

선입선출 FIFO, First In First Out: 가장 먼저 삽입된 자료가 가장 먼저 삭제된다.

시작과 끝을 표시하는 두 개의 포인터가 있다.

54. 객체지향 설계 원칙 =SOLID 원칙

• SRP, Single Responsible Principal: 객체는 단 하나의 책임만 져야 한다.
• OCP, Open-Closed Principal: 기능을 추가할 때 기존의 코드를 변경하지 않을 수 있어야 한다.
• LSP, Liskov Substition Principal: 자식 클래스는 최소한 부모 클래스의 행위는 수행할 수 있어야 한다.
• ISP, Interface Segregation Principal: 자신이 사용하지 않는 인터페이스와 의존관계나 영향을 받지 않아야 한다.
• DIP, Dependency Inversion Principal: 각 객체들 간 의존관계가 성립될 때, 구체적인 객체보다 추상화에 의존해야 한다.

*DIP 추가설명!

객체에서 어떤 클래스를 참조해야 할 때, 직접 클래스를 참조하는 것이 아니라 그보다 상위 클래스(추상 클래스 or 인터페이스)를 참조해야 한다. 

55. 결합도 (Coupling)

모듈 간 상호의존하는 정도, 연관관계

약할 수록 품질 높고, 강할 수록 품질 낮다.

결합도가 약함에서 강함 순! 자스제외공내 (자스 제외하고 공부한 나..)

• 자료 결합도, Data Coupling: 모듈 간 인터페이스가 자료 요소로만
• 스탬프 결합도, Stamp Coupling: 모듈 간 인터페이스가 자료 구조(배열, 레코드 등) 전달
• 제어 결합도, Control Coupling: 한 모듈이 다른 모듈의 논리적 흐름 제어하기 위한 제어 요소(switch, flag, function) 전달
• 외부 결합도, External Coupling: 한 모듈에서 선언한 변수를 다른 모듈에서 참조
• 공통 결합도, Common Coupling: 공유되는 공통 데이터 영역을 여러 모듈이 사용
• 내용 결합도, Content Coupling: 한 모듈이 다른 모듈의 내부 기능 및 자료 직접 참조

56. 응집도 (Cohesion)

정보 은닉 개념을 확장한 것

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

약할 수록 품질 낮고, 강할 수록 품질 높다.

응집도가 강함에서 약함 순! 기순통절시논우 (기가 순한 통은 절에서 시를 짓고 논에서 운다...)

• 기능적 응집도, Functional Cohesion: 모듈 내부 모든 기능이 단일 문제와 연관되어 수행
• 순차적 응집도, Sequential Cohesion: 모듈 내 활동으로부터 나온 출력 데이터를 다음 활동의 입력 데이터로 사용
• 통신적 응집도, Communication Cohesion: 동일한 입/출력을 사용해서 서로 다른 기능을 수행하는 구성요소들이 모임
• 절차적 응집도, Procedural Cohesion: 다수의 관련 기능을 가질 때, 순차적으로 기능을 수행함
• 시간적 응집도, Temporal Cohesion: 특정 시간에 처리되는 몇 기능을 모아 하나의 모듈로 작성
• 논리적 응집도, Logical Cohesion: 유사 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성됨
• 우연적 응집도, Coincidental Cohesion: 모듈 내부 각 요소가 서로 관련 없는 요소로만 구성

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

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

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

58. N-S 차트 (Nassi-Schneiderman Chart)

논리의 기술에 중점을 둔 도형을 이용한 표현, 박스 다이어그램

연속, 선택 및 다중 선택, 반복 등 제어 논리 구조를 표현

화살표x

참고 

60. 재사용

재사용되는 대상은 결합도는 낮고 응집도는 높아야 한다.

비용과 개발 시간을 절약하기 위해 이미 개발된 기능들을 재구성하여 새로운 기능을 사용하기 적합하도록 최적화

규모에 따른 분류

• 함수와 객체: 클래스나 메서드 단위 소스 코드 재사용
• 컴포넌트: 독립적인 기능을 수행하는 실행코드 기반으로
• 애플리케이션: 공통 기능을 제공하는 애플리케이션을 공유하는 방식

61. 효과적인 모듈 설계 방안

기능은 예측가능해야 하며 지나치게 제한적이면 안된다

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

복잡도와 중복을 줄이고 일관성을 지킨다.

64. 디자인 패턴(Design Pattern)의 개요

• 각 모듈의 세분화된 역할이나 모듈들 간 인터페이스 같은 코드를 작성하는 수준의 세분적인 구현 방안을 설계 시  참조할 수 있는 전형적인 해결방식 또는 예제.
• 구성: 문제 및 배경, 실제 적용된 사례, 재사용 가능한 샘플 코드 등,,,
• Don't reinvent the wheel, 바퀴를 다시 발명하지 마라 : 개발 중 문제가 발생하면 새로운 해결책을 구상하는 것보다 문제에 해당하는 디자인 패턴을 참고해서 적용하는 것이 더 효율적!!
• GoF의 디자인 패턴은 유형에 따라 생성 패턴 5개, 구조 패턴 7개, 행위 패턴 11개 총 23개의 패턴으로 구성됨

65. 디자인 패턴 사용의 장/단점

범용적인 코딩 스타일로 인해 구조 파악 용이

객체지향 설계 및 구현의 생산성 높임

검증된 구조의 재사용으로 시간과 비용 절약

설계 변경 요청에 대한 유연한 대처 가능

의사소통 원활

초기 투자 비용 부담

객체지향 기반이므로 다른 기반의 애플리케이션 개발에는 적합하지 않다.

66. 생성 패턴 (Creational Pattern)

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

총 5가지 추싱팩프빌 (추석에 팩하는 프로 보디빌더..)

1. 추상 팩토리, Abstract Factory:
   구체적인 클래스에 의존하지 않고 인터페이스를 통해 연관 의존하는 객체들의 그룹으로 생성하여 추상적으로 표현
   연관된 서브 클래스를 묶어 한 번에 교체 가능 -> DIP가 떠오른다!!
   
   
2. 싱글톤, Singleton:
   하나의 객체를 생성하면 생성된 객체를 어디서든 참조할 수 있지만 여러 프로세스가 동시에 참조할 순 없음
   클래스 내 인스턴스가 하나뿐임을 보장하며, 불필요한 메모리 낭비를 최소화
   
   
3. 팩토리 메소드, Factory Method
   =가상 생성자 패턴, Virtual Constructor
   객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴
   상위 클래스에서 인터페이스만 정의하고 실제 생성은 서브 클래스가 담당
   
   
4. 프로토타입, Prototype
   원본 객체를 복제하는 방법으로 객체를 생성하는 패턴
   일반적인 방법으로 객체를 생성하며, 비용이 큰 경우 주로 이용함
   
   
5. 빌더, Builder
   작게 분리된 인스턴스를 건축하듯이 조합하여 객체를 생성
   객체의 생성 과정과 표현 방법을 분리하고 있어서 동일한 객체 생성에서도 서로 다른 결과를 만들어낼 수 있음
   
   

30. 사용자 인터페이스(UI)의 특징

사용자의 만족도에 가장 큰 영향을 미치는 요소, 변경이 많음

사용자 중심으로 설계되어 사용자 중심 상호작용이 되도록 함

수행 결과의 오류를 줄임

사용자의 막연한 작업에 대해 구체적 방법 제시

31. UI 의 구분

• CLI(Command Line Interface): 명령, 출력이 텍스트 형태
• GUI(Graphic User Interface): 아이콘이나 메뉴를 마우스로 클릭하여 작업 수행 형태
• NUI(Natural User Interface): 사용자의 말이나 행동으로 조작 형태
• VUI(Voice User Interface): 사람의 음성을 기기 조작 형태
• OUI(Organic User Interface): 모든 사물과 사용자 간의 상호작용-> 사물인터넷, 가상현실, 증강현실, 혼합현실 등과 함께 대두되고 있음

32. UI 의 기본 원칙

유유학직!!ㅎㅎ

• 유연성: 요구사항 최대한 수용, 실수 최소화
• 유효성: 목적 정확하고 완벽하게 달성
• 학습성: 누구나 쉽게 익힘
• 직관성: 누구나 쉽게 이해

33. UI 의 설계 지침

• 사용자 중심: 사용자 편의 위해 실사용자에 대한 이해가 바탕이 되어야 함
• 사용성: 얼마나 빠르고 쉽게 이해
• 심미성: 그래픽적 완성도
• 오류 발생 해결: 오류 발생 쉽게 인지

35. UI 설계 도구

UI 설계 도구? 화면 구조나 배치 등을 설계 시 사용하는 도구

종류

• 와이어프레임(Wireframe): 기획 단계의 초기에 제작, 개발자나 디자이너 간 진행 상태 공유 위함-> 손그림, PPT, 일러스트, 포토샵 등
• 목업(Mockup): 와이어프레임보다 좀 더 실제 화면과 유사하게 만듬. 실제로 구현은 x -> 발사믹 목업 등
• 스토리보드(StoryBoard): 와이어프레임에 콘텐츠 설명, 페이지 간 이동흐름 등을 추가 -> Axure 등
• 프로토타입(Prototype): 실제 구현된 것처럼 테스트 가능 동적 모형
• 유스케이스(Usecase): 사용자 측면에서의 요구사항 기술

36. 품질 요구사항

소프트웨어의 기능, 성능, 만족도 등 요구사항이 얼마나 충족되는가를 나타냄

ISO/IEC? International Organization for Standardization(국제 표준화 기구)/International Electrotechnical Commission(국제 전기 기술 위원회)

ISO/IEC 9126: SW 품질 특성과 평가를 위한 표준 지침

ISO/IEC 25010: 9126을 개정해서 만듬

ISO/IEC 12119: 9126을 준수한 품질 표준, 테스트 절차 포함

ISO/IEC 14598: 개발자, 구매자, 평가자 별로 제품 평가 활동을 규정

이기신사유효..ㅎ (이기적인 신사가 유효해..)

• 이식성(Portability): 다른 환경에서도 얼마나 쉽게 적용할 수 있는지?
• 기능성(Functionality): 요구사항을 정확하게 만족하는지?
• 신뢰성(Reliability): 일관되게 기능을 오류 없이 수행할 수 있는지?
• 사용성(Usability): 컴퓨터 상 발생하는 행위에 대해 사용자가 정확하게 이해하고 다시 사용하고 싶은지?
• 유지보수성( Maintainability): 개선하거나 확장할 수 있는지?
• 효율성(Efficiency(: 사용자 요구하는 기능을 할당된 시간동안 한정된 자원으로 얼마나 빨리 처리?

37. UI 요소

체크박스: 여러 선택지 중 1개 이상 선택

라디오버튼: 하나만 선택

텍스트박스: 사용자가 직접 입력

콤보박스: 이미 지정된 목록 상자에 사용자가 직접 입력 가능

목록상자: 목록 표시하지만 입력x

38. 상위 설계와 하위 설계

상위 설계

=아키텍쳐 설계, 예비 설계

시스템의 전체적인 구조

구조, DB, 인터페이스

하위 설계

=모듈 설계, 상세 설계

시스템의 내부 구조 및 행위

컴포넌트, 자료 구조, 알고리즘

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

• 모듈화(Modularity): 성능을 향상시키거나 재사용, 유지보수가 용이하도록 기능들을 모듈단위로 나눔
• 추상화(Abstraction): 전체적이고 포괄적인 개념을 세분화하여 구체화 -> 과정 추상화, 데이터 추상화, 제어 추상화
• 단계적 분해(Stepwise Refinement): 하향식 설계 전략
• 정보 은닉(Information Hiding): 한 모듈 내부에 포함된 절차와 자료가 숨겨져서 다른 모듈이 접근하지 못하도록 함

43. 파이프-필터 패턴

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

*데이터 스트림? 정해진 포맷 사용하여 한 장치에서 다른 장치로 보내지는 데이터의 흐름

*필터 컴포넌트: 재사용성, 확장 용이, 재배치하여 다양한 파이프라인 구축 가능

데이터 변환, 버퍼링, 동기화 등에 주로 사용됨, 주로 UNIX의 쉘(Shell)

44. 모델-뷰-컨트롤러 패턴

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

• 모델(Model): 핵심기능과 데이터 저장
• 뷰(View): 사용자에게 정보를 표시
• 컨트롤러(Controller): 요청 명령을 보냄

45. 기타 패턴

• 마스터-슬레이브 패턴: 마스터에서 슬레이브로 분할, 슬레이브의 결과물을 다시 돌려받음-> 병렬 컴퓨팅 시스템
• 브로커 패턴: 사용자가 원하는 정보를 브로커에 요청하면 연결해줌-> 분산 컴퓨팅 환경
• 피어-투-피어 패턴: 피어를 하나의 컴포넌트로 간주, 피어는 사용자가 될 수도, 정보를 제공하는 서버가 될 수도
• 이벤트-버스 패턴: 소스가 특정 채널에 이벤트를 발생하면 해당 채널의 구독자에게 메시지 줌
• 블랙보드 패턴: 모든 컴포넌트들이 블랙보드에 접근가능, 검색을 통해 블랙보드에서 원하는 정보 찾음. 결정가능한 해결전략이 없을 때 유용, -> 음성인식, 차량식별, 신호 해석 등 활용
• 인터프리터 패턴: 코드의 각 라인을 수행하는 방법을 지정

46. 객체

데이터와 함수를 캡슐화한 하나의 소프트웨어 모듈

데이터= 속성(Attribute), 상태, 변수, 상수, 자료 구조

함수= 메소드(Method), 서비스, 동작(Operation), 연산

* 객체의 특성

독립적으로 식별가능 이름 가짐

상태는 시간에 따라 변함

객체 간 상호연관성에 의한 관계 형성

객체가 반응할 수 있는 메시지의 집합= 행위

47. 클래스

공통된 속성과 연산을 갖는 객체를 하나로 묶음. 객체의 타입을 의미

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

각각의 객체를 인스턴스-> 클래스로부터 새로운 객체를 생성하는 것을 인스턴스화(Instantiation)

48. 캡슐화 (Encapsulation)

데이터와 함수를 하나로 묶는 것

캡슐화된 객체는 인터페이스를 제외하고 정보 은닉됨

: 접근 제한적, 외부 모듈 변경으로 인한 파급효과 적음-> 객체 간 결합도 낮아져, 재사용 용이

49. 상속 (Inheritance)

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

하위클래스는 그에 더해서 첨가해서 사용가능

50. 다형성(Polymorphism)

메시지에 의해 객체가 연산을 수행하게 될 때, 하나의 메시지에 대해 객체가 할 수 있는 고유한 특성으로 응답하는 능력

하나의 함수나 연산자가 다른 클래스에 속한 인스턴스를 같은 인스턴스처럼 수행할 수 있도록 하는 것.

오버로딩: 메소드명은 같지만 인수를 받는 자료형과 개수에 따라 기능 달라져

오버라이딩(=메소드 재정의): 상위클래스에서 정의한 메소드 명은 같지만 하위 클래스에서 실행코드를 달리하여 재정의

 51. 연관성 (Relationship)

두 개 이상의 객체들이 상호 참조하는 관계

종류

• is member of 연관화
• is instance of 분류화
• is part of 집단화
• is a 일반화 + 특수화/상세화

52. 객체지향 분석의 방법론

• 럼바우(Rumbaugh): 객체모델, 동적모델, 기능모델로 나누어 수행
• 부치(Booch): 미시적과 거시적 개발 프로세스를 모두 사용
• Jacobson: Usecase를 강조
• Coad와 Yourdon: E-R 다이어그램 사용
• Wirfs-Brock: 분석과 설계 간 구분이 x, 연속적으로 수행 

53. 럼바우의 분석 기법

=객체 모델링 기법 (OMT, Object Modeling Technique)

객체 모델링 -> 동적 모델링 -> 기능 모델링 순으로

• 객체 모델링: =정보 모델링, 속성과 연산 식별 및 객체 간 관계를 규정해서 다이어그램으로 표시
• 동적 모델링: 상태도를 이용해 시간의 흐름에 따른 동적 행위 표현
• 기능 모델링: DFD를 이용해 프로세스들 간 자료흐름 중심 처리 과정

22. HIPO

Hierarchy Input Process Output

시스템의 분석, 설계, 문서화할 때 사용하는 기법.

HIPO Chart: 기능을 여러개의 고유 모듈들로 분할, 이들 간 인터페이스를 계층구조로 표현한 것

- 종류

가시적 도표(도식목차): 기능 계층 구조도

총체적 도표: 전반적 정보 제공

세부적 도표: 총체적 도표를 구성하는 세부요소

23. UML

Unified Modeling Language

시스템 분석, 설계, 개발 등 개발 과정에서 개발자와 고객 또는 개발자 간의 의사소통이 원활하게 이루어지도록 표준화한 객체지향형 모델링 언어

Rumbaugh, Booch, Jacobson 등의 객체지향 방법론의 장점을 통합

럼바우: 객체, 동적, 기능 모델로 나눠져

Booch: 미시적, 거시적 개발 프로세스 모두 사용, 클래스와 객체들 분석/식별, 클래스의 속성과 연산을 정의

Jacobson: 유스케이스 강조

6개의 구조 다이어그램(정적) + 7개의 행위 다이어그램(동적)

구성요소: 사물(Things), 관계(Relations), 다이어그램(Diagram)

24. 관계(Relations)

1. 연관 관계(Association): 2개 이상의 사물이 서로 관련
2. 집합 관계(Aggregation): 하나의 사물이 다른 사물에 포함 관계
3. 포함 관계(Composition): 집합 관계의 특수 형태, 포함하는 사물의 변화가 포함되는 사물에 영향 줌
4. 일반화 관계(Generalization): 하나의 사물이 다른 사물에 비래 더 일반적인지 구체적인지 표현
5. 의존 관계(Dependency): 한 클래스가 다른 클래스를 연산 매개변수로 사용하는 등 짧은 시간동안만 관계
6. 실체화 관계(Realization): 사물이 기능으로 서로를 그룹화할 수 있는 관계

25. 다이어그램(Diagram)

구조적 다이어그램(Structural) -정적- 6개

1. 클래스 (Class): 클래스 간 속성과 관계 표현
2. 객체 (Object): 클래스에 속한 객체인 인스턴스 간 특정 시점의 관계, 럼바우의 객체모델링에 활용됨
3. 컴포넌트 (Component): 실제 구현 모듈인 컴포넌트 간 관계나 인터페이스 표현
4. 배치 (Deployment): 결과물, 프로세스, 컴포넌트 등 물리적 요소들 위치 표현
5. 복합체 구조 (Composite Structure): 복합 구조 갖는 경우 그 내부 구조 표현
6. 패키지 (Package): 유스케이스나 클래스 등 모델 요소들을 그룹화한 패키지들 관계 표현

행위적 다이어그램(Behavioral) -동적- 7개

1. 유스케이스 (Usecase): 사용자(User)와 사용 사례(Use case)로 구성됨, 요구를 분석하는 것-> 기능 모델링에 활용됨
2. 순차 (Sequence): 상호작용하는 시스템이나 객체들이 주고받는 메시지 표현
3. 커뮤니케이션 (Communication): 순차 다이어그램의 메시지뿐만 아니라 객체들 간 연관까지 표현
4. 상태 (State): 객체가 자신이 속한 클래스의 상태 변화나 상호작용에 따른 상태 변화 표현,럼바우의 동적 모델링에 활용됨
5. 활동 (Activity): 객체의 처리 로직이나 조건의 처리흐름을 순서에 따라 표현
6. 상호작용 개요 (Interaction Overview): 상호작용 다이어그램 간 제어흐름 표현
7. 타이밍 (Timing): 객체 상태 변화와 시간 제약을 명시적으로 표현

26. 스테레오 타입(Stereotype)

UML에서 표현하는 기본 기능 외 추가 기능 표현

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

• <<include>>: 연결된 다른 UML 요소에 대해 포함 관계에 있는 경우
• <<extend>>: 연결된 다른 UML 요소에 대해 확장 관계에 있는 경우
• <<interface>>: 인터페이스 정의
• <<exception>>: 예외 정의
• <<constructor>>: 생성자 역할 정의

27. 유스케이스 다이어그램 (Use Case Diagram)

사용자와 다른 외부 시스템들이, 개발될 시스템을 이용해 수행할 수 있는 기능을

사용자 관점에서 표현한 것

구성요소

• 시스템/시스템 범위: 외부 시스템과 구분하기 위해 시스템 내부 유스케이스를 사각형으로 묶어 범위 표현
• 액터: 시스템과 상호작용하는 모든 외부 요소
• 유스케이스: 사용자 관점에서 시스템이 제공하는 서비스나 기능
• 관계: 액터와 유스케이스, 유스케이스 간 관계-> 연관관계, (포함관계), 확장관계, 일반화관계를 표현할 수 있음

28. 클래스 다이어그램

구성요소

• 클래스: 3개의 구획(Compartment)로 나눠 표기, 이름+속성+오퍼레이션(=동작,연산)을 표기
• 제약조건: 오퍼레이션 수행 전후에 지정해야 할 조건이 있다면
• 관계: 클래스 간 관계 -> 연관관계, (집합관계, 포함관계), 의존관계, 일반화관계가 있음

29. 순차 다이어그램

구성요소

• 액터: 외부 요소 = 사람이나 외부 시스템
• 객체: 메시지 주고받는 주체
• 생명선 (Lifeline): 객체가 메모리에 존재하는 시간
• 실행 상자 (Active Box): 객체가 메시지를 주고받으며 구동되고 있음을 표현
• 메시지: 상호작용을 위해 주고받는 메시지

13. DBMS

사용자와 db 사이에 정보를 생성해주고 db를 구성,접근방법,유지보수,관리하는 소프트웨어

database management system

기존 db의 종속성과 중복성 문제를 해결

여러 응용 프로그램이 db로 접근 쉽게함 = 모든 응용 프로그램이 db를 공용하게 관리

종류? oracle, sqlite, db2, mongodb, redis, sql server...

고려사항? 가용성, 성능, 기술 지원, 상호 호환성, 구축 비용

14. 웹 어플리케이션 서버 (WAS)

정적 콘텐츠를 처리하는 웹서버와 달리, 사용자의 요구에 따른 동적 콘텐츠 처리 위한 서버.

주로 db 서버와 연동

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

종류? tomcat, jetty, resin, jeus, GlassFish

15. 요구사항 유형

기능/비기능 요구사항

16. 요구사항 개발 프로세스

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

Elicitation->Analysis->Specification->Validation

17. 요구사항 명세 기법

정형/비정형

비정형 명세 기법?

자연어 기반. 이해 용이. 일관성 떨어지고 해석 달라질 수 있음.

상태, 기능, 객체 중심!

ER modeling, State Chart, 등

18. 요구사항 분석의 개요

DFD, 자료사전, UML, 소단위 명세서, 개체관계도, 상태 전이도, 제어 명세서 등의 도구 이용

* UML(Unified Modeling Language) : 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하도록 한 객체지향 모델링 언어

19. 자료 흐름도(DFD)

Data Flow Diagram

요구사항 분석 과정 중 자료의 흐름과 변환과정, 기능을 도형 중심으로 기술

=버블 차트

네 가지 기호

프로세스(Process): 자료를 변환시키는 처리 과정, 변환, 버블

자료 흐름(Data Flow): 자료의 연관관계나 이동 .화살표

자료 저장소(Data Store): 데이터베이스나 파일 등 저장소,

단말(Terminator): 교신하는 외부 개체

20. 자료사전(DD)

Data Dictionary

자료흐름도의 자료를 더 상세히 기술 위함.

=데이터의 데이터 또는 메타데이터