[2020 정보처리기사 필기 요약] 1과목 - 소프트웨어 설계 요약(애플리케이션 설계)

  -  3  - 애플리케이션 설계

 

 

 

 

 

16. 소프트웨어 아키텍처

 

 

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

소프트웨어의 골격이 되는 기본 구조이자, 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체이다.

• 소프트웨어 개발 시 적용되는 원칙과 지침으로, 이해관계자들의 의사소통 도구다.
• 기본적으로 좋은 품질을 유지하면서 사용자의 비기능적 요구사항(품질이나 제약사항)으로 나타난 제약을 반영하고, 기능적 요구사항(요구항목)을 구현하는 방법을 찾는 해결 과정이다.
• 애플리케이션의 분할 방법과 분할된 모듈에 할당될 기능, 모듈 간의 인터페이스 등을 결정한다.

* 소프트웨어 프로그램의 기둥, 근간이라고 생각하시면 됩니다. 건물을 지으려고 하는데 명확한 건축 설계 원칙이 있어야지 건축가들이 헷갈리지 않겠죠?

 

 

 

2) 모듈화

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

• 자주 사용되는 계산식이나 사용자 인증 같은 기능을 모듈화
• 모듈의 크기를 너무 작게 나누면 모듈 간의 통합 비용이 늘어나고, 모듈의 크기를 너무 크게 나누면 통합 비용은 적게 들지만 모듈 하나의 개발 비용이 증가함.

 

 

 

 

 

3) 추상화

문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화 시켜 나가는 것

인간이 복잡한 문제를 다룰 때 가장 기본적으로 사용하는 방법으로, 완전한 시스템을 구축하기 전에, 그 시스템과 유사한 모델을 만들어서 여러 가지 요인들을 테스트

최소의 비용으로 실제 사항에 대처할 수 있고, 시스템의 구조 및 구성을 개략적으로 파악할 수 있다.

 

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

데이터 추상화 : 데이터 구조를 대표할 수 있는 표현으로 대체

제어 추상화 : 이벤트 발생의 정확한 절차나 방법을 정의하지 않고 대표할 수 있는 표현으로 대체

 

 

 

 

 

4) 단계적 분해

Niklaus Wirth가 제안한 하향식 설계 전략으로, 문제를 상위의 중요 개념에서 하위의 개념으로 구체화 시키는 분할 기법

• 추상화의 반복에 의해 세분화
• 기능에서 부터 시작해 점차적으로 구체화하고, 알고리즘, 자료구조 등 상세한 내역은 뒤로 미루어 진행함.

 

 

 

5) 정보 은닉

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

• 어떤 모듈이 소프트웨어 기능을 수행하기 위해서 정보 은닉된 모듈과 커뮤니케이션할 필요가 있을 때는 필요한 정보만 인터페이스를 통해 주고받음
• 모듈을 독립적으로 수행할 수 있으며, 하나의 모듈이 변경되더라도 다른 모듈에 영향을 주지 않기 때문에 수정, 유지보수가 용이하다.

 

 

 

 

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

소프트웨어 아키텍처가 이해 관계자들이 요구하는 수준의 품질을 유지 및 보장할 수 있게 설계되었는지를 확인하기 위해 품질 평가 요소들을 시스템 측면, 비즈니스 측면, 아키텍처 측면으로 구체화한 것.

 

 

시스템 측면

• 성능 : 적절하게 빠르게 처리
• 보안 : 허용되지 않은 접근을 막음
• 가용성 : 장애 없이 서비스를 제공
• 기능성 : 사용자가 요구한 기능을 만족스럽게 구현
• 사용성 : 명확하고 편리하게 구현
• 변경 용이성 :  다른 플랫폼에서 동작할 수 있게 구현
• 확장성 : 시스템의 용량, 처리 능력을 확장시켰을 때의 활용능력
• 기타속성 : 테스트 용이성, 배치성, 안정성 등

 

비즈니스 측면

• 시장 적시성
• 비용과 혜택
• 예상 시스템 수명
• 기타 속성

 

아키텍처 측면

• 개념적 무결성 : 시스템을 이루는 구성요소 간의 일관성을 유지
• 정확성, 완결성 : 요구사항을 구현하기 위한 제약사항을 충족
• 구축 가능성 : 모듈 단위로 구분된 시스템을 적절하게 분배해 유연하게 일정을 변경
• 기타 속성 : 변경성, 시험성, 적응성, 일치성, 대체성 등

 

 

 

 

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

• 설계 목표 설정 : 시스템의 개발 방향을 명확히 하기 위해 설계에 영향을 주는 비즈니스 목표, 우선순위 등의 요구사항을 분석하여 전체 시스템의 설계목표를 설정
• 시스템 타입 결정 : 시스템과 서브시스템의 타입을 결정하고, 설계 목표와 함께 고려하여 아키텍처 패턴을 선택
• 아키텍처 패턴 적용 : 아키텍처 패턴을 참조하여 시스템의 표준 아키텍처를 설계
• 서브시스템 구체화 : 서브시스템의 기능 및 서브시스템 간의 상호작용을 위한 동작과 인터페이스를 정의
• 검토 : 아키텍처가 설계 목표에 부합하는지, 요구사항이 잘 반영되었는지, 기본 원리를 만족하는 지를 검토

*시스템 타입 : 대화형 시스템, 이벤트 중심 시스템, 변환형 시스템, 객체 영속성 시스템

 

 

 

 

 

 

 

 

 

 

 

 

17. 아키텍처 패턴

 

1) 아키텍터 패턴의 개요

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

- 소프트웨어 시스템의 구조를 구성하기 위한 기본적인 윤곽을 제시

- 서브시스템들과 그 역할이 정의되어 있음. 서브시스템 사이의 관계와 규칙이 포함됨.

 

아키텍처 패턴의 장점

• 시행 착오를 줄여 개발시간을 단축시키고 고품질의 소프트웨어를 생산할 수 있다.
• 검증된 구조로 공통된 아키텍처를 공유해 의사소통이 간편하다
• 시스템 구조의 이해가 쉬어 유지보수가 쉽다
• 시스템 특성을 예측할 수 있다.

 

 

 

2) 레이어 패턴

시스템을 계층으로 구분하여 구성하는 고전적 방법

• 각각의 서브시스템이 계층 구조를 이루며, 상위 계층은 하위 계층에 대한 서비스 제공자가 되고, 하위 계층은 상위 계층의 클라이언트가 된다.
• 서로 마주보는 두 개의 계층사이에서만 상호작용이 이루어진다.
• 변경사항을 적용할 때도 두 개의 계층 사이에서만 영향이 미치므로 변경 작업에 용이하다
• 특정 계층만을 교체해 시스템을 개선하는 것이 가능하다.
• 대표적으로 OSI 참조 모델이 있다

 

 

 

 

 

 

 

 

 

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

하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴이다.

• 사용자는 클라이언트와만 의사소통을 한다. 즉 사용자가 클라이언트를 통해 서버에 요청하고 클라이언트가 응답을 받아 사용자에게 제공하는 방식으로 서비스를 제공한다.
• 서버는 클라이언트 요청에 대비해 항상 대기 상태를 유지한다.
• 서버와 클라이언트는 동기화 되는 경우를 제외하고 서로 독립적이다.

 

 

 

4) 파이프-필터 패턴

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

• 필터 컴포넌트는 재사용성이 좋고 추가가 쉽고 확장이 용이하다
• 필터 컴포넌트를 재배치하여 다양한 파이프라인을 구축하는 것이 가능하다
• 하나의 컴포넌트에서 처리가 끝나면 다음 컴포넌트가 결과물을 받아 작업을 진행한다.
• 데이터 변환, 버퍼링, 동기화 등에 사용된다.
• 대표적으로 UNIX의 쉘이 있다.

* 데이터 스트림이 나오면 파이프-필터 패턴이에요!

 

 

 

 

5) 모델-뷰-컨트롤러 패턴

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

• 모델 : 서브시스템의 핵심 기능과 데이터를 보관
• 뷰 : 정보를 표시
• 컨트롤러 : 입력을 처리
• 각 부분은 별도의 컴포넌트로 분리되어 있으므로 서로 영향을 받지 않고 개발 작업을 수행할 수 있다.
• 여러 개의 뷰를 만들 수 있으므로 대화형 어플리케이션에 적합하다.

 

 

 

6) 기타 패턴

마스터 슬레이브 패턴

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

장애 허용시스템과 병렬 컴퓨팅 시스템에서 주로 사용된다

 

 

브로커 패턴

사용자가 원하는 서비스와 특성을 브로커 컴포넌트에 요청하면 브로커 컴포넌트가 요청에 맞는 컴포넌트와 사용자를 연결해준다.

원격 서비스 호출에 응답하는 컴포넌트들이 여러개 있을때 적합한 패턴이다.

분산 환경 시스템에서 사용

* 암시장의 브로커를 생각하시면 되요! 전달자 같은 개념!

 

 

피어-투-피어 패턴

피어를 하나의 컴포넌트로 간주해 피어가 서버가 될 수도, 클라이언트가 될 수도 있는 패턴이다.

전형적인 멀티스레딩 방식을 사용한다.

* 블록체인의 원리를 생각하시면 되요! 아니면 토렌트..?

 

 

이벤트-버스 패턴

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

 

 

블랙보드 패턴

해결책이 명확하지 않은 문제를 처리하는데 유용한 패턴이다.

음성인식, 차량식별, 신호해석

 

 

인터프리터 패턴

특정 언어로 작성된 프로그램 코드를 해석하는 컴포넌트를 설계할 때 사용한다.

 

 

 

 

 

 

 

 

 

 

18. 객체 지향

 

 

1) 객체 지향의 개요

현실세계의 개체를 기계의 부품처럼 하나의 객체로 만들어 기계적인 부품들을 조립하여 제품을 만들 듯이 소프트웨어를 개발할 때 사용하는 기법이다.

- 객체지향은 복잡한 구조를 단계적, 계층적으로 표현하고, 멀티미디어 데이터 및 병렬 처리를 지원한다.

 

 

 

 

2) 객체

데이터와 데이터를 처리하는 함수를 묶어 놓은 하나의 모듈이다.

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

 

 

 

3) 클래스

공통된 속성과 연산(행위)을 갖는 객체의 집합으로, 객체의 일반적인 타입(Type)을 의미한다.

- 클래스에 속한 각각의 객체를 인스턴스(Instance)라고 하며, 클래스로부터 새로운 객체를 생성하는 것을 인스턴스화라고 한다.

 

 

 

4) 캡슐화

데이터(속성)과 데이터를 처리하는 함수를 하나로 묶는 것을 의미한다.

• 캡슐화된 객체는 인터페이스를 제외한 세부 내용이 은폐(정보 은닉)되어 외부에서의 접근이 제한적이기 때문에 외부 모둘의 변경으로 인한 영향이 적다.
• 캡슐화된 객체들은 재사용이 용이하다.
• 캡슐화를 통해 인터페이스가 단순해지고, 객체 간의 결합도가 낮아진다.

 

 

5) 다형성

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

 

 

 

 

 

 

 

 

 

19. 모듈

 

1) 모듈의 개요

모듈은 모듈화를 통해 분리된 시스템의 각 기능들로 서브 루틴(Sub routin), 서브시스템, 소프트웨어 내의 프로그램, 작업 단위 등의 의미로 사용된다.

단독으로 컴파일이 가능하며 재사용이 가능하다.

기능적 독립성은 소프트웨어를 구성하는 각 모듈의 기능이 서로 독립됨을 의미하는 것으로, 모듈이 하나의 기능만을 수행하고 다른 모듈과의 과도한 상호작용을 배제하는 것으로 이루어진다.

독립성이 높은 모듈일 수록 모듈을 수정하더라도 다른 모듈에게는 영향을 미치지 않는다.

모듈의 독립성은 결합도와 응집도에 의해 측정

독립성을 높이려면 결합도를 약하게, 응집도는 강하게, 모듈의 크기는 작게 만들어야 한다.

 

* 모듈의 독립성은 스마트폰을 생각하시면 되요. 유튜브 시청, SNS, 통화 등 다양한 기능이 집약되어있죠?

 

 

 

 

 

 

 

 

2) 결합도

모듈간의 상호 의존하는 정도, 두 모듈 사이의 연관 관계다.

결합도가 약할 수록 품질이 높고, 강할수록 품질이 낮다.

결합도가 강하게 되면 유지보수가 어렵다.

위에서부터 결합도가 약하고 내려갈 수록 결합도가 강해진다.

 

 

종류

• 자료 결합도 : 모듈 간의 인터페이스가 자료 요소로만 구성됨(결합도 약함)
• 스탬프 결합도 : 배열이나 레코드 등의 자료 구조가 전달될 때의 결합도.
• 제어 결합도 :  다른 모듈의 논리적인 흐름을 제어하기 위한 제어 신호와 제어 요소를 사용.
• 외부 결합도 : 데이터를 외부의 다른 모듈에서 참조할 때의 결합도
• 공통 결합도 : 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도
• 내용 결합도 : 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때의 결합도(결합도 강함)

 

 

3) 응집도

정보 은닉 개념을 확장한 것으로 명령어나 호출문 등 모듈의 내부 요소들의 서로 관련되어 있는 정도, 즉 모듈이 독립적인 기능으로 정의되어 있는 정도를 의미한다.

응집도가 강할 수록 품질이 높고, 약할 수록 품질이 낮다.

위에서부터 응집도가 강하고, 내려갈수록 응집도가 약해진다.

 

종류

• 기능적 응집도 : 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우(응집도 강함)
• 순차적 응집도 : 하나의 활동으로 부터 나온 출력 데이터를 그 다음 활동의 입력데이터로 사용될 경우
• 교환(통신)적 응집도 : 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소일 경우
• 절차적 응집도 : 모듈이 다수의 관련 기능을 가질 때의 그 기능을 순차적으로 수행할 경우
• 시간적 응집도 : 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우
• 논리적 응집도 : 유사한 성격이거나 특정 형태로 분류될 경우
• 우연적 응집도 : 서로 관련 없는 요소로만 구성될 경우(응집도 약함)

 

 

 

4) 팬인 - 팬아웃

팬인은 어떤 모듈을 제어하는 모듈의 수

팬아웃은 어떤 모듈에 의해 제어되는 모듈의 수

팬인-팬아웃으로 시스템 복잡도를 알 수 있다

팬인이 높다는 것은 재사용 측면에서 설계가 잘되어 있다고 볼 수 있으나, 단일 장애점이 발생할 수 있으므로 중점적 관리가 필요하다.

팬아웃이 높은 경우 불필요하게 다른 모듈을 호출하고 있는지 검토하고 단순화시킬 수 있는지 검토가 필요하다.

시스템 복잡도를 최적화하려면 팬인은 높게, 팬아웃은 낮게 설계한다.

 

 

 

*공통 모듈의 명세기법

정확성(Correctness) : 해당 기능이 필요하다는 것을 알 수 있게

명확성(Clarity) : 중의적으로 해석되지 않도록 명확하게

완전성(Completeness) : 구현을 위해 필요한 모든 것을 기술

일관성(Consistency) : 상호 충돌이 발생하지 않도록

추적성(Traceability) : 출처, 관계를 파악할 수 있게

 

 

 

 

 

 

 

 

20. 코드

 

1) 코드의 개요

자료를 처리하는 과정에서 분류,조합 및 집계를 용이하게 하고 특정 자료의 추출을 쉽게 하기 위한 기호

• 식별 기능 : 데이터 간의 성격에 따라 구분이 가능
• 분류 기능 : 특정 기준이나 동일한 유형에 해당하는 데이터를 그룹화 할 수 있다.
• 배열 기능 : 의미를 부여하여 나열 할 수 있다.

 

 

2) 코드의 종류

• 순차 코드 : 자료의 발생 순서, 크기 순서, 순서 코드 또는 일련 번호 코드라고 한다. ex) 1, 2, 3, 4, ...
• 블록 코드 : 공통성 있는 것끼리 블록으로 구분해 코드를 부여. 구분 코드라고 한다. ex) 1001~1100 = 총무부, 1101~1200 = 영업부
• 10진 코드 : 코드화 대상 항목을 0~9까지 10진 분할한다. 도서분류식 코드라고 한다. ex) 1000 = 공학, 1100 = 소프트웨어 공학, 1110 = 소프트웨어 설계
• 그룹 분류 코드 : 대분류, 중분류, 소분류 등으로 구분한다. ex) 1-01-001 = 본사-총무부-인사계, 2-01-001 = 지사-총무부-인사계
• 연상 코드 : 명칭이나 약호와 관계있는 숫자나 문자, 기호를 이용 ex) TV-40 = 40인치 텔레비전, L-15-220 : 15W 220V의 램프
• 표의 숫자코드 : 길이, 넓이, 부피, 지름, 높이 등의 물리적 수치를 코드에 적용, 유효 숫자 코드라고 한다. ex) 120-720-1500 = 두께 x 폭 x 길이가 120 x 720 x 1500인 강판
• 합성 코드 : 필요한 기능을 하나의 코드로 수행하기 어려운 경우 2개의 코드를 조합함 ex) 연상코드 + 순차코드