2021 정보처리기사 실기 - 4. 서버 프로그램 구현(1)

소프트웨어 아키텍처

소프트웨어 아키텍처의 설계

- 소프트웨어의 골격이 되는 기본 구조

- 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체

- 좋은 품질을 유지하면서 사용자의 비기능적 요구사항으로 나타난 제약을 반영하고, 기능적 요구사항을 구현하는 방법을 찾는 해결 과정

- 애플리케이션의 분할 방법과 분할된 모듈에 할당될 기능, 모듈 간의 인터페이스 등을 결정

 

모듈화

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

- 모듈의 크기와 개수는 반비례관계 개수와 통합 비용은 비례 관계

 

추상화

- 문제의 전체를 설계 후 세분화하여 구체화하는 과정

- 완전한 시스템을 구축하기 전에 그 시스템과 유사한 모델을 만들어 여러 가지 요인들을 테스트할 수 있음

- 최소 비용으로 실제 상황에 대처할 수 있고 시스템의 구조 및 구성을 대략적으로 파악할 수 있음

- 추상화 유형

    -> 과정 추상화 : 전반적인 흐름만 파악

    -> 데이터 추상화 : 데이터의 세부사항은 정의하지 않고 구조를 대표할 수 있는 표현으로 대체

    -> 제어 추상화 : 이벤트의 발생의 세부사항은 정의하지 않고 구조를 대표할 수 있는 표현으로 대체

 

단계적 분해

- 문제를 상위 중요 개념으로부터 하위의 개념으로 구체화하는 분할 기법

- 추상화의 반복으로 세분화

 

정보 은닉

- 한 모듈 내부에 포함된 정보들을 감추어 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법

- 다른 모듈과 커뮤니케이션을 할 때는 필요한 정보만 인터페이스를 통해 주고받음

- 모듈을 독립적으로 수행하기 때문에 다른 모듈에 영향을 주지 않아 수정, 시험, 유지보수가 용이

 

소프트웨어 아키텍처의 품질 속성

- 소프트웨어 아키텍처가 이해 관계자들이 요구하는 수준의 품질을 유지하고 보장할 수 있게 설계되었는지를 확인하기 위해 품질 요소들을 구체화시켜 놓은 것

소프트웨어 아키텍처의 설계 과정

 

아키텍처 패턴

아키텍처 패턴의 개요

- 아키텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제

- 시스템의 구조를 구성하기 위한 기본적인 틀을 제공

- 서브시스템과 그 역할이 정의되어 있어 서브시스템 사이 관계와 규칙, 지침 등이 포함되어 있음

- 아키텍처 패턴의 장점

    -> 개발 시간을 단축시킴

    -> 고품질의 소프트웨어 생산 가능

    -> 검증된 구조로 작업을 하여 안정적인 개발 가능

    -> 시스템 구조를 이해하기 쉬워 개발에 참여하지 않아도 유지보수가 쉬움

 

레이어 패턴

- 시스템을 계층으로 구분하여 구성

- 각각의 서브 시스템이 계층 구조를 이룸

- 상위 계층은 하위 계층에 대한 서비스 제공자가 되고 하위 계층은 상위 계층의 클라이언트가 됨

- 마주 보는 두 계층 사이에만 상호 작용이 이루어짐

- 특정 계층만을 교체해 시스템을 개선하는 것이 가능

클라이언트-서버 패턴

- 하나의 서버와 다수의 클라이언트로 구성

- 사용자는 클라이언트를 통해 서버에 요청하고 응답을 받아 사용자에게 제공

- 서버는 클라이언트의 요청에 대비해 항상 대기 상태 유지

- 요청을 위하여 동기화되는 경우를 제외하고는 서로 독립적임

파이프-필터 패턴

- 데이터 스트림(데이터가 송수신되거나 처리되는 흐름) 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송

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

- 필터 컴포넌트를 재배치하여 다양한 파이프라인 구축 가능

- 데이터 변환, 버퍼링, 동기화 등에 사용

모델-뷰-컨트롤러 패턴

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

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

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

- 컨트롤러 : 사용자로부터 받은 입력 처리

- 각 부분은 별도로 분리되어 있어 서로 영향을 받지 않고 독립적인 개발 작업 수행

- 여러 개의 뷰를 만들 수 있어 한 개의 모델에 여러 개의 뷰를 필요로 하는 대화형 애플리케이션에 적합

 

기타 패턴

- 마스터-슬레이브 패턴 : 마스터 컴포넌트에서 슬레이브 컴포넌트로 작업을 분할한 후 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는 방식

- 보로커 패턴 : 사용자가 원하는 서비스와 특성을 브로커 컴포넌트에 요청하면 브로커 컴포넌트가 요청에 맞는 컴포넌트를 연결

- 피어-투-피어 패턴 : 피어를 하나의 컴포넌트로 간주하여 각 피어는 클라이언트 또는 서버가 될 수도 있음

- 이벤트-버스 패턴 : 소스가 특정 채널에 이벤트 메시지를 발행하면 해당 채널을 구독한 리스너들이 메시지를 받아 이벤트를 처리하는 방식

- 블랙보드 패턴 : 모든 컴포넌트들이 공유 데이터 저장소와 블랙보드 컴포넌트에 접근이 가능하여 검색을 통해 블랙보드에서 원하는 데이터를 찾을 수 있음

- 인터프리터 패턴 : 프로그램 코드의 각 라인을 수행하는 방법을 지정하고 기호마다 클래스를 갖도록 구성

 

객체지향(Object-Oriented)

객체지향의 개요

- 현실 세계의 개체를 기계의 부품처럼 하나의 객체(Object)로 만들어 소프트웨어를 개발할 때 객체를 조립하여 작성할 수 있는 기법

- 구조적 기법의 문제점을 해결하기 위해 사용

- 소프트웨어의 재사용 및 확장이 용이하여 고품질의 소프트웨어를 빠르게 개발할 수 있어 유지보수가 쉬움

- 복잡한 구조를 단계적이고 계층적이게 표현

- 멀티미디어 데이터 및 병렬 처리 지원

- 구성 요소 : 객체, 클래스, 캡슐화, 상속, 다형성

 

객체

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

- 데이터 : 객체가 가지고 있는 정보

- 함수 : 객체가 수행하는 기능으로 데이터를 처리하는 알고리즘

- 객체의 특성

    -> 객체는 독립적으로 식별 가능한 이름을 가지고 있음

    -> 객체의 상태는 시간에 따라 변함

    -> 객체 간의 상호 연관성에 의해 관계 형성

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

    -> 객체는 일정한 기억 장소를 가지고 있음

 

클래스

- 공통된 속성과 연산을 갖는 객체의 집합으로 객체의 일반적인 타입을 의미

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

- 인스턴스 : 클래스에 속한 각각의 객체

- 인스턴스화 : 클래스로부터 새로운 객체를 생성하는 것

- 슈퍼 클래스 : 특정 클래스의 부모(상위) 클래스

- 서브 클래스 : 특정 클래스의 자식(하위) 클래스

 

캡슐화

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

- 인터페이스를 제외한 세부 내용이 은폐되어 외부에서 접근이 제한적이기 때문에 외부에서 변경하기 어려움

 

상속

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

- 하위 클래스는 부모 클래스의 모든 속성과 연산을 다시 정의하지 않고 사용할 수 있음

- 하위 클래스는 상속받은 속성 외에 새로운 속성과 연산을 첨가하여 사용할 수 있음

- 객체와 클래스의 재사용을 높이는 중요한 개념

- 다중 상속 : 한 개의 클래스가 두 개 이상의 상위 클래스로부터 상속받는 것

 

다형성

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

 

객체지향 분석 및 설계

객체지향 분석

- 사용자의 요구사항과 관련된 객체, 속성, 연산, 관계 등을 정의하여 모델링하는 작업

 

객체지향 분석의 방법론

- 럼바우 방법

    -> 분석 활동을 객체, 동적, 기능 모델로 나누어 수행

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

    -> 객체 모델링 → 동적 모델링 → 기능 모델링

- 부치 방법

    -> 미시적 개발 프로세스와 거시적 개발 프로세스를 사용

    -> 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의

- 제이콥슨 방법

    -> 유스케이스를 강조하여 사용

- 코드와 유드롱 방법

    -> E-R 다이어 그램을 사용하여 객체의 행위를 모델링

- 워프스 브록 방법

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

 

객체지향 설계 원칙

- 변경이나 확장에 유연한 시스템을 설계하기 위해 지켜야할 원칙

- 객체지향 설계 원칙의 종류

    -> 단일 책임 원칙 : 객체는 단 하나의 책임만을 가져야 함

    -> 개방 폐쇄 원칙 : 기존의 코드는 변경하지 않고 기능을 추가할 수 있어야 함

    -> 리스코프 치환 원칙 : 자식 클래스는 부모 클래스의 기능은 수행할 수 있어야 함

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

    -> 의존 역전 원칙 : 의존 관계 성립 시 추상성이 높은 클래스와 의존 관계를 맺어야 한다는 원칙

실기 정리

2021 정보처리기사 실기 정리