[2022년 정보처리기사 필기] 1. 소프트웨어설계: Cp3. 애플리케이션 설계

2022년 정보처리기사 필기

(수제비 2021년 필기책 보고 공부하며 요약한 내용입니다.)

http://www.yes24.com/Product/Goods/96051171

 

1. 소프트웨어 설계

Cp3. 애플리케이션 설계

 

 

---

 

 

1. 공통 모듈

: 모듈이란, 크게 독립된 하나의 소프트웨어/하드웨어를 지칭함.

: 모듈화를 통해 분리된 시스템의 기능들로 서브프로그램, 서브루틴, 단위프로그램, 작업 단위 등과 같은 의미로 사용됨

 

1-1. 모듈의 특징

1) 상대적으로 독립성을 가지고 있음

2) 모듈을 하나로 통합하는 수 많은 조합이 존재할 수 있음

3) 단독으로 컴파일할 수 있으며, 재사용할 수 있음

4) 독립성 높은 모듈일 수록 모듈 수정 시에도 타 모듈에 영향을 거의 미치지 않고, 오류 발생 시에도 쉽게 해결할 수 있음

5) 모듈 독립성은 결합도와 응집도에 의해 측정됨. 독립성을 높이려면 모듈 결합도는 약하게, 응집도는 강하게, 모듈 크기는 작게 만들어야 함.

 

1-2. 공통 모듈의 개념

: 전체 프로그램 기능 중 특정 기능을 처리하는 실행코드를 의미함

: 자체적으로 컴파일이 가능하고, 타프로그램에서 재사용이 가능함

 

1-3. 공통모듈의 원칙

1) 정확성: 기능이 필요한 기능인지 아닌지 정확하게 작성

2) 명확성: 일관되게 이해되고 한가지로 해석될 수 있도록 작성

3) 완전성: 시스템이 구현될 때 필요하고 요구되는 모든 것을 기술

4) 일관성: 공통 기능 간 상호충돌이 없도록 작성

5) 추적성: 공통기능에 대한 요구사항 출처와 관련 시스템 등의 유기적 관계에 대한 식별이 가능하도록 작성

 

1-4. 모듈화

: 시스템을 분해하고 추상화함으로써 제품의 성능을 향상시키거나, 시스템의 수정 및 재사용, 유지 관리를 쉽게 하는 기법

: SW 성능 향상, 복잡한 시스템의 수정, 재사용, 유지관리 등이 용이하도록 기능 단위의 모듈로 분해하는 설계 및 구현 기법

모듈화 기법	설명
루틴	SW에서 특정 동작을 수행하는 일련의 코드로 기능을 가진 명령들의 모임
메인 루틴	프로그램의 주요한 부분이며, 전체의 개략적인 동작 절차를 표시하도록 만들어진 루틴 메인 루틴은 서브루틴을 호출
서브 루틴	메인루틴에 의해 필요시 호출됨

 

1-5. 모듈화 필요성

: 모듈 크기가 너무 작아 개수가 많아지면, 모듈 간 통합 비용이 많이 발생함

: 모듈 크기가 너무 크면, 모듈 간 통합 비용이 줄지만, 모듈당 개발 비용이 커짐

--> 모듈의 독립성과 재사용성을 높이기 위해 결합도는 낮추고, 응집도는 높임.

--> 모듈 복잡도와 중복성을 줄이고 일관성을 유지함

--> 모듈 기능은 예측이 가능해야 하며, 지나치게 제한적이어서는 안됨.

--> 적당한 모듈의 크기를 유지해야 함

--> 모듈간 효과적 제어를 위해 설계에서 계층적 자료 조직이 제시되어야 함.

--> 유지보수가 용이해야 함.

 

1-6. 모듈화 유형

1) 응집도: 모듈 내부에서 구성요소 간 밀접한 관계를 맺고 있는 정도. 높을 수록 필요 요소들로 구성되어 있고, 낮을 수록 관련이 적은 요소들로 구성됨

2) 결합도: 모듈과 모듈간에 어느 정도 관련성이 있는지를 나타내는 정도. 관련이 적을 수록 모듈의 독립성이 높아 모듈 간 영향이 적어짐

 

1-7. 팬인(Fan-In) 및 팬아웃(Fan-Out)

: 모듈을 계층적으로 분석하기 위해 활용하며, 시스템의 복잡도를 측정할 수 있음.

: 시스템 복잡도를 최적화 하기 위해서는 Fan-In을 높게, Fan-Out을 낮게 설계해야 함.

구분	Fan-In	Fan-Out
개념	어떤 모듈을 제어(호출)하는 모듈의 수	어떤모듈에 의해 제어(호출)되는 모듈 수
모듈 숫자 계산	모듈자신을 기준으로 모듈에 들어오면 Fan-In	모듈 자신을 기준으로 모듈에서 나가면 Fan-Out
고려사항	Fan-In이 높으면 재사용설계가 잘된것이지만, 단일 장애점 발생 가능하고, 관리비용과 테스트 비용이 증가함	Fan-Out이 높으면 불필요한 모듈 호출 여부, 단순화 여부 검토가 필요함

https://post.naver.com/viewer/postView.nhn?volumeNo=27424202&memberNo=26040503

 

2. 설계 모델링

: 요구사항 분석 단계에서 규명된 필수 기능들의 구체적인 구현 방법을 명시하는 기법

: 요구 기능과 성능 조건들을 만족하는 소프트웨어의 내부 기능, 구조 및 동적 행위들을 모델링하여 표현, 분석, 검증하는 과정임.

 

2-1. 설계 모델링 원칙

: 변경이 쉽도록 구조화 되어야 함

: 하나의 함수 안에 특정 기능을 수행하는데 필요한 자료만 사용하도록 규제함

: 독립적이고 기능적인 특성을 지닌 모듈 단위로 분할 설계함

: 계층적 구조를 가져야 함

 

2-2. 설계 모델링 유형

설계 모델링 유형	설명	구성요소
구조 모델링	소프트웨어를 구성하는 컴포넌트들의 유형, 인터페이스, 내부 설계 구조 및 이들의 상호 연결구조를 모델링 시스템 구성요소들과 이들 사이 구조적 관계와 특성들을 모델링	프로시저, 데이터구조, 모듈, 파일 구조
행위 모델링	소프트웨어 구성요소들의 기능들과 이들이 언제, 어떤 순서로 수행되는가와 같은 동적인 특성들을 모델링	입출력 데이터, 데이터 흐름, 데이터 변환, 데이터 저장 등

*프로시저: 프로그램을 기능에 따라 여러개의 단위로 분해해 작성하는 것. 서브 프로시저, 함수 프로시저로 구분됨

 

2-3. 소프트웨어 설계 유형

1) 자료구조 설계

: 요구분석 단계에서 생성된 정보를 바탕으로 소프트웨어를 구현하는데 필요한 자료구조로 변환하는 과정

2) 아키텍처 설계

: 예비 설계 또는 상위 수준 설계로, SW 시스템 전체 구조를 기술하며, SW 구성하는 컴포넌트 간의 관계 정의

3) 인터페이스 설계

: SW와 상호작용하는 컴퓨터 시스템, 사용자 등이 어떻게 통신하는지를 기술

4) 프로시저 설계

: 프로그램 아키텍처의 컴포넌트를 소프트웨어 컴포넌트의 프로시저 서술로 변환하는 과정

5) 협약에 의한 설계

: 클래스에 대한 여러 가정을 공유하도록 명세한 설계

: 소프트웨어 컴포넌트에 대한 정확한 인터페이스 명세를 위하여 선행조건, 결과조건, 불변조건을 나타내는 설계 방법

   (1) 선행조건 : 컴포넌트의 오퍼레이션 사용 전에 참이 되어야할 조건

   (2) 결과조건 : 사용 후 만족되어야 할 조건

   (3) 불변조건 : 오퍼레이션이 실행되는 동안 항상 만족되어야할 조건

 

** 자료구조설계, 아키텍처설계, 인터페이스 설계, 프로시저 설계는 상위설계에 속하나, 모듈설계는 하위 설계에 속함.

 

2-4. 코드 설계

: 데이터 분류나 조합을 쉽게 하기 위해 사물을 표현하는 코드를 설계하는 기법

코드의 기능	설명
표준화	정보 종류, 모양, 크기 등 일정기준에 따라 통일적으로 표현
분류	정보들을 동일특성 가진 데이터로 그룹화하여 나눔
식별	다른것과 구별됨
배열	일련의 순서로 나열
간소화	정보 표현을 간소화함
연상	정보를 표현하고자하는 대상체 뜻과 의미가 코드에 내포
암호화	정보의 외부 표현을 감추고자 함
오류 검출	정보입력이나 관리 시 잘못된 정보를 찾아냄

 

2-5. 코드 설계 종류

1) 연상코드(Mnemonic Code): 코드만 보고 대상을 연성하도록 명칭 일부를 약호함. ex) KR, US

2) 블록코드(=구분코드): 공통성 있는 것끼리 블록으로 구분하고, 블록 내에서 일련번호 부여.  ex) 전화번호( 지역번호 - 국번 - ..)

3) 순차코드: 일정한 기준에 따라 순서대로 일련번호를 부여함. ex) 1번, 2번, 3번.  가나다...

4) 표의 숫자 코드(significant digit code): 물리적인 수치인 길이, 넓이, 용량 등을 표시

5) 십진 코드(decimal code): 10진수 형태로 표현한 코드

6) 그룹분류식 코드: 대분류, 중분류, 소분류로 구분해 번호부여한 코드 ex) 학번(입학연도 -일련번호 조합)

 

2-6. 코드 설계 절차

1) 코드화 항목 선정 

2) 코드화 목적 설정

3) 코드화 대상 확인

4) 코드화 범위 결정

5) 코드 사용 기간 설정

6) 코드화 항목의 특성 분석

7) 코드화 방식 결정

8) 문서화

 

2-7. 코드 오류 종류

1) 사본오류 : 한 자리를 잘못 표기한 경우. 필사오류, 오자오류라고도 함

2) 전위오류: 연속된 두 글자가 서로 바뀌어 표기됨

3) 생략오류: 한글자를 빼먹고 기술함

4) 첨가오류: 한글자가 추가되어 기술함

5) 이중전위오류: 전위오류가 중복발생함

 

2-8. HIPO (Hierarchy Input Process Output)

: 시스템의 분석 및 설계, 문서화에 사용되며, 하향식 소프트웨어 개발을 위한 문서화 도구임.

: 체계적인 문서 관리가 가능함

: 기호, 도표 등을 사용해서 보기가 쉽고 이해가 쉬움.

: 기능과 자료의 의존 관계를 동시에 표현할 수 있음

: 변경, 유지보수가 용이함

: 시스템기능을 고유 모듈들로 분할하여 이들 간 인터페이스를 게층구조로 표현한 것을 HIPO차트 라고 함.

HIPO 차트 종류	설명
가시적 도표	시스템 전체적 기능과 흐름을 보여주는 계층구조도
총체적 도표	입력,처리,출력에 대한 정보를 제공 프로그램을 구성하는 기능을 기술
세부적 도표	총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술

 

 

3. 소프트웨어 아키텍처

: 여러 소프트웨어 구성요소와 그 특성 중에서 외부에 드러나는 특성과 관계를 표현하는 시스템 구조

: 소프트웨어를 설계하고 전개하기 위한 지침과 원칙

: 이해관계자들 간 조율 통한 시스템을 최적화 함

: 기능적 요소도 고려하나, 시스템의 비기능적 요소에 집중하여 만들어짐

 

3-1. 소프트웨어 아키텍처 프레임워크

: 소프트웨어 집약적인 시스템에서 아키텍처가 표현해야하는 내용 및 이들 간의 관계를 제공하는 아키텍처 기술 표준

소프트웨어 아키텍처 프레임워크 구성요소	설명
아키텍처 명세서	아키텍처를 기록하는 산출물 이해관계자의 관심을 관점에 맞추어 작성한 뷰로 표현 개별 뷰, 뷰 개괄 문서, 인터페이스 명세 등
이해관계자	시스템 개발에 관련된 모든 사람과 조직
관심사	이해관계자들의 서로다른 의견과 목표 사용자: 기능, 신뢰성, 보안, 사용성 등의 품질 유지보수자: 유지보수 용이성 개발자: 적은 비용과 인력으로 개발
관점	개별 뷰를 개발할 때 토대가 되는 패턴이나 양식
뷰	관심사들의 집합이라는 관점에서 전체 시스템을 표현 시스템에 대한 아키텍처 설명에는 하나 이상의 뷰로 구성
근거	아키텍처 결정 근거, 회의 결과, 보고 결과
목표	의도하는 시스템의 목적, 사용, 운영방법
환경	개발, 운영 등 외부에서 시스템에 영향을 주는 요인
시스템	각 앱, 서브시스템, 시스템의 집합, 제품군 등의 구현체

 

3-2. 소프트웨어 아키텍처 4+1 뷰

: 요구사항 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법

: 4개의 구조가 충돌하지 않는지, 요구사항을 충족시키는지 증명하기 위해 체크방법으로 유스케이스를 사용함.

  4: 논리뷰, 구현뷰, 프로세스뷰, 배포 뷰,  1: 유스케이스 뷰

https://simuing.tistory.com/entry/2021-%EC%A0%95%EB%B3%B4%EC%B2%98%EB%A6%AC%EA%B8%B0%EC%82%AC-%ED%95%84%EA%B8%B0%EC%9A%94%EC%95%BD-%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98-%EC%84%A4%EA%B3%84

 

1) 유스케이스뷰: 유스케이스 또는 아키텍처를 도출하고 설계하며, 다른 뷰를 검증하는데 사용. 사용자, 설계자, 개발자, 테스트 관점

2) 논리뷰: 요구사항이 어떻게 제공되는지 설명해주는 뷰. 설계자, 개발자 관점

3) 프로세스뷰: 시스템의 비기능적 속성으로, 자원의 효율적 사용, 병행실행, 비동기, 이벤트 처리 등을 표현한 뷰.  개발자, 시스템 통합자 관점

4) 구현뷰: 개발환경 내에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰. 컴포넌트 구조와 의존성을 보여주고, 컴포넌트에 관한 부가정보 정의

5) 배포뷰: 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰

 

3-3. 소프트웨어 아키텍처 비용 평가 모델

: 아키텍처 접근법이 품질 속성에 미치는 영향을 판단하고, 아키텍처의 적합성을 평가하는 모델

 

http://blog.skby.net/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%ED%8F%89%EA%B0%80-%EB%AA%A8%EB%8D%B8-atam-cbam/

 

1) SAAM (SW Architecture analysis method)

: 변경 용이성, 기능성에 집중, 평가가 용이하여 경험없는 조직에서도 활용 가능한 비용평가모델

2) ATAM (Architecture Trade-off analysis method)

: 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상충관계까지 평가하는 모델

3) CBAM (Cost Benefit analysis method)

: ATAM 바탕의 시스템 아키텍처 분석 중심으로 경제적 의사결정에 대한 요구를 충족하는 비용 평가 모델

4) ADR ( Active design review)

: 소프트웨어 아키텍처 구성요소 간 응집도를 평가하는 모델

5) ARID (Active reviews for intermediate designs)

: 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중하는 비용평가 모델

 

3-4. 소프트웨어 아키텍처 패턴

: 소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결방식

: 소프트웨어 아키텍처에서 일반적으로 발생하는 문제에 대한 일반화되고 재사용 가능한 솔루션

: 고객과 의사소통 통해 고객 요구사항 만족시키고, 개발 생산성과 품질 확보가 가능함

: 개발 시행착오를 줄여 개발시간 단축하고, 높은 품질의 소프트웨어 생산이 가능함

 이미 검증된 구조로 개발하기에 안정적임

: 시스템 특성을 개발 전에 예측이 가능함

 

3-5. 소프트웨어 아키텍처 패턴 유형

유형	설명
계층화 패턴	시스템을 계층(레이어)으로 구분해 구성 하위모듈은 특정 수준의 추상화를 제공하고, 각 계층은 다음 상위 계층에 서비스를 제공 서로 마주보는 두 계층 사이에서만 상호 작용이 이루어짐
클라이언트-서버 패턴	한 서버와 다수의 클라이언트로 구성
파이프-필터 패턴	데이터 스트림을 생성하고 처리하는 시스템에서 사용 서브시스템이 입력데이터를 받아 처리하고, 결과를 다음 서브시스템으로 넘겨주는 과정을 반복함. 필터 컴포넌트는 재사용이 좋고 추가가 쉽기에 확장 용이
브로커 패턴	부닐된 컴포넌트들로 이루어진 분산 시스템에서 사용 컴포넌트들은 원격서비스 실행을 통해 상호작용함. 브로커 컴포넌트는 컴포넌트 간 통신을 조정함. 서버는 자신의 기능들을 브로커에 넘겨주며, 클라이언트가 브로커에 서비스를 요청하면, 브로커는 클라이언트를 자신의 레지스트리에 있는 적합한 서비스로 리다이렉션함.
모델-뷰-컨트롤러 패턴(MVC 패턴)	대화형 애플리케이션을 모델, 뷰, 컨트롤 뷰 3개의 서브시스템으로 구조화하는 패턴 모델: 핵심 기능과 데이터 보관 뷰: 사용자에게 정보 표시 컨트롤러: 사용자로부터 요청 입력받아 처리