2020 정보처리기사 필기 - 1.3 애플리케이션 설계(1)
▶ 020 소프트웨어 아키텍처
소프트웨어 아키텍처의 설계
소프트웨어 아키텍처 : 소프트웨어의 골격이 되는 기본 구조, 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조
- 사용자의 비기능적 요구사항을 반영하고, 기능적 요구사항을 구현하는 방법을 찾는 해결 과정
＊기능적 요구사항 : 시스템이 갖춰야할 필수적인 기능에 대한 요구항목
＊비기능적 요구사항 : 그 외 품질이나 제약사항에 관한 것들
- 기본 원리 : 모듈화, 추상화, 단계적 분해, 정보은닉
1. 모듈화(Modularity)
소프트웨어의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능들을 모듈단위로 나누는 것
- 재사용성 향상
- 모듈의 크기를 너무 작게 나누면 개수가 많아져 모듈간의 통합 비용이 많이 듦
- 모듈의 크기를 너무 크게 나누면 개수가 적어 통합 비용은 적게 들지만 모듈 하나의 개발 비용이 많이 듦
2. 추상화(Abstraction)
불필요한 부분은 생략하고 필요한 부분을 강조해 모델화 하는 것
문제의 전체적이고 포괄적인 개념 설계 후, 차례로 세분화해 구체화 시켜나가는 것
- 추성화의 유형 : 과정 추상화, 데이터 추상화, 제어 추상화
- 과정 추상화 : 자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악할 수 있게 설계
- 데이터 추상화 : 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터 구조를 대표할 수 있는 표현으로 대체
- 제어 추상화 : 이벤트 발생의 정확한 절차나 방법을 정의하지 않고, 대표할 수 있는 표현으로 대체
3. 단계적 분해(Stepwise Refinement)
Niklaus Wirth에 의해 제안된 하향식 설계 전략, 문제를 상위의 중요 개념으로부터 하위의 개념으로 구체화시키는 분할 기법
- 추상화의 반복에 의해 세분화 됨
4. 정보 은닉(Information Hiding)
한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 함
- 모듈을 독립적으로 수행 할 수 있어 수정, 시험, 유지보수가 용이
소프트웨어 아키텍처의 품질 속성
품질 평가 요소들을 시스템 측면, 비즈니스 측면, 아키텍처 측면으로 구분해 구체화 시킨 것
- 시스템 측면 : 성능, 보안, 가용성, 기능성, 사용성, 변경 용이성, 확장성, 용이성, 배치성, 안정성 등
- 비즈니스 측면 : 시장 적시성, 비용과 혜택, 예상 시스템 수명, 목표 시장, 공개 일정 등
- 아키텍처 측면 : 개념적 무결성, 정확성, 완결성, 구축 가능성, 변경성, 적응성, 일치성 등
소프트웨어 아키텍처의 설계 과정
1. 설계 목표 설정
2. 시스템 타입 결정
3. 아키텍처 패턴 적용
＊아키텍처 패턴 : 독립적인 업무 또는 기능을 수행하는 실행코드 기반으로 작성된 모듈
4. 서브시스템 구체화
5. 검토
☞ 시스템 타입
- 대화형 시스템 : 사용자의 요구 발생시 시스템이 이를 처리하고 반응
- 이벤트 중심 시스템 : 외부의 상태 변화에 따라 동작
- 변환형 시스템 : 데이터 입력 시 정해진 작업들을 수행해 결과 출력
- 객체 영속형 시스템 : DB를 사용해 파일을 효과적으로 저장, 검색, 갱신 함
▶ 021 아키텍처 패턴
아키텍처 패턴
아키텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식, 예제
- 아키텍처 패턴의 장점 : 시행착오 출임, 예측 가능, 안정적 개발
- 아키텍처 패턴의 종류 : 레이어 패턴, 클라이언트-서버 패턴, 파이프-필터 패턴, 모델-뷰-컨트롤러 패턴
1. 레이어 패턴(Layers pattern)
시스템 계층으로 구분해 구성하는 고전적인 방법
- 각각의 서브시스템들이 계층 구조를 이룸
ex) OSI 참조 모델
2. 클라이언트-서버 패턴(Client-Sever Pattern)
하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴
＊아키텍처 패턴 : 독립적인 업무 또는 기능을 수행하는 실행코드 기반으로 작성된 모듈
- 서버는 클라이언트의 요청에 대비해 항상 대기 상태 유지
- 클라이언트와 서버는 요청과 응답의 경우를 제외한 서로 독립적
3. 파이프-필터 패턴(Pipe-Filter Pattern)
데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송하는 패턴
- 재사용성 좋음, 추가가 쉬워 확장 용이
- 필터 컴포넌트 재배치 가능
- 변환, 버퍼링, 동기화 등에 주로 사용
ex) UNIX의 쉘(Shell)
4. 모델-뷰-컨트롤러 패턴(Model-View-Controller Pattern)
서브시스템을 3개의 부분으로 구조화하는 패턴
- 모델(Model) : 서브시스템의 핵심 기능과 데이터를 보관
- 뷰(View) : 사용자에게 정보 표시
- 컨트롤러(Controller) : 사용자로부터 받은 입력 처리
- 각 부분은 별도의 컴포넌트로 분리되어 있음, 영향 X
- 대화형 애플리케이션에 적합
5. 기타 패턴
마스터-슬레이브 패턴 : 마스터 컴포넌트에서 슬레이브 컴포넌트로 작업 분할 후, 슬레이브에게 처리된 결과물을 다시 돌려받음
브로커 패턴 : 사용자가 원하는 서비스와 특성을 요청하면 요청에 맞는 컴포넌트와 사용자를 연결해 줌
피어-투-피어 패턴 : 피어=하나의 컴포넌트, 각 피어는 클라이언트가 될 수도 서버가 될 수도 있는 패턴, 멀티스레딩 방식
이벤트-버스 패턴 : 소스가 특정 채널에 이벤트 메시지를 발행하면, 해당 채널을 구독한 리스너들이 메시지를 받아 이벤트를 처리함
블랙보드 패턴 : 컴포넌트들은 검색을 통해 블랙보드에서 원하는 데이터를 찾음
인터프리터 패턴 : 프로그램 코드의 각 라인을 수행하는 방법을 지정하고, 기호마다 클래스를 갖도록 구성
▶ 022 객체지향(Object-Oriented)
객체지향의 개요
객체지향 : 현실 세계의 개체(Entity)를 기계 부품처럼 하나의 객체(Object)로 만들어, 기계적인 부품들을 조립해 제품을 만들 듯이 소프트웨어를 개발할 때에도 객체들을 조립해서 작성할 수 있는 기법
- 소프트웨어의 재사용 및 확장 용이, 유지보수 쉬움
- 복잡한 구조를 단계적 계층적으로 표현
- 객체지향의 구성요소와 개념 : 객체, 클래스, 캡슐화, 상속, 다형성 등
1. 객체(Object)
데이터와 데이터를 처리하는 함수를 묶어 놓은 하나의 소프트웨어 모듈
- 데이터 = 속성, 상태, 변수, 상수, 자료구조
- 함수 = 메소드, 서비스, 동작, 행위
- 독립적으로 식별 가능한 이름을 가짐
- 객체가 가질 수 있는 조건 = 상태(State)
2. 클래스(Class)
공통된 속성과 연산을 갖는 객체의 집합, 객체의 일반적인 타입을 의미
- 각각의 객체들이 갖는 속성과 연산을 정의하고 있는 틀
- 클래스에 속한 각각의 객체 = 인스턴스(Instance)
- 동일한 클래스에 속한 각각의 개체들은 공통된 속성과 행위를 갖음
3. 캡슐화(Encapsulation)
데이터와 데이터를 처리하는 함수를 하나로 묶은 것을 의미
- 불필요한 기능 최소화
- 소프트웨어 개발 비용 절감
- 개발 속도 향상
4. 상속(Inheritance)
상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것
- 다중 상속 : 한 개의 클래스가 두 개 이상의 상위 클래스로부터 속성과 연산을 상속 받는 것
5. 다형성(Polymorphism)
하나의 메시지에 대해 여러 가지 형태의 응답이 있는 것