4-1장. 서버 프로그램 구현 1

4-1장. 서버 프로그램 구현 1

---

• 4-1장. 서버 프로그램 구현 1
  • 모듈화 (A)
  • 추상화 (B)
  • 정보 은닉 (B)
  • 파이프-필터 패턴 (B)
  • 모델 - 뷰- 컨트롤러 패턴 (B)
  • 기타 패턴 (B)
  • 객체지향 (C)
  • 객체 (C)
  • 클래스 (B)
  • 메시지 (B)
  • 캡슐화 (B)
  • 상속 (B)
  • 다형성 (C)
  • 객체지향 분석 (B)
  • 럼바우의 분석 기법 (A)
  • 객체지향 설계 원칙(SOLID 원칙) (A)

---

모듈화 (A)

소프트웨어의 성능 향상, 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능들을 모듈 단위로 나누는 것

• 모듈 간 결합도의 최소화와 모듈 내 요소들의 응집도를 최대화하는 것이 목표

추상화 (B)

전체적이고 포괄적인 개념을 설계한 후 구체화시켜나가는 것

정보 은닉 (B)

한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법

• 모듈을 독립적으로 수행 가능하여 수정, 시험, 유지보수 용이

파이프-필터 패턴 (B)

데이터 스트림 절차의 각 단계를 필터로 캡슐화하여 파이프를 통해 전송

• 앞 시스템의 처리 결과물을 파이프를 통해 전달 받아 처리한 후 그 결과물을 다시 파이프를 통해 다음 시스템으로 넘겨주는 패턴을 반복

모델 - 뷰- 컨트롤러 패턴 (B)

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

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

기타 패턴 (B)

• 마스터 슬레이브 패턴
  • 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는 방식으로 작업을 수행

객체지향 (C)

소프트웨어의 각 요소들을 객체로 만든 후 객체들을 조립해서 소프트웨어를 개발

객체 (C)

데이터와 이를 처리하기 위한 함수를 묶어 놓은 소프트웨어 모듈

• 데이터 : 객체가 가지고 있는 정보(속성, 상태, 분류 등)
• 함수
  • 객체가 수행하는 기능으로 객체가 갖는 데이터를 처리하는 알고리즘
  • 메소드, 동작, 연산

클래스 (B)

공통된 속성과 연산을 갖는 객체의 집합

• 각각의 객체들이 갖는 속성과 연산을 정의하고 있는 틀
• 클래스에 속한 각각의 객체를 인스턴스라고 한다

메시지 (B)

객체의 동작이나 연산을 일으키는 외부의 요구 사항

• 메시지를 받는 객체는 대응하는 연산을 수행하여 예상된 결과를 반환

캡슐화 (B)

외부에서의 접근을 제한하기 위해 인터페이스를 제외한 세부 내용을 은닉

• 캡슐화된 개체는 외부 모듈의 변경으로 인한 파급 효과가 적다
• 인터페이스가 단순해지고, 객체 간의 결합도가 낮아진다.

상속 (B)

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

• 하위 클래스는 물려받은 속성과 연산을 다시 정의하지 않아도 즉시 자신의 속성으로 사용할 수 있다.
• 하위 클래스는 상속 받은 속성과 연산 외에 새로운 속성과 연산을 첨가하여 사용 가능

다형성 (C)

각각의 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력

객체지향 분석 (B)

객체, 속성, 연산, 관계 등을 정의하여 모델링

럼바우의 분석 기법 (A)

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

• 객체 모델링 기법이라고도 한다
• 객체모델링 - 동적 모델링 - 기능 모델링 순으로 분석 활동
  • 객체 모델링(정보 모델링) : 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 객체 다이어그램으로 표시하는 모델링
  • 동적 모델링 : 상태 다이어그램을 이용하여 시간의 흐름에 따른 객체들 간의 제어 흐름, 상호 작용, 동작 순서 등의 동적인 행위를 표현한 모델링
  • 기능 모델링 : 자료 흐름도를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현한 모델링

객체지향 설계 원칙(SOLID 원칙) (A)

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