* 공통 모듈
☞ 날짜 처리 위한 유틸리티 모듈 등과 같이 전체 프로그램 기능 중 공통적으로 사용 가능한 모듈 의미
◎ 모듈화
- SW 성능 향상시키거나 시스템 수정 및 재사용, 유지 관리 용이케 하여 프로그램 효율적으로 관리 가능토록 시스템 분해하고 추상화하는 기법 의미
- 모듈 크기가 과도하게 작은 경우 모듈 개수가 많아져 모듈 간 통합 비용 과다 발생
- 모듈 크기가 과도하게 큰 경우 모듈 간 통합 비용 상대적으로 감소하는 대신 하나의 모듈 개발하는 데 소용되는 비용 커짐
1. 응집도
- 모듈 내부 구성 요소 간 관계 밀접 정도
- 응집도 높을수록 필요한 요소들로 구성되어 짐
- 응집도 낮을수록 요소들 간 관련성 적은 요소들로 구성되어 짐
- 품질 측면에서 가장 높은 품질은 기능적 응집도이며, 가장 낮은 품질은 우연적 응집도
▶ 응집도 유형
▷ 기능적 응집도 (Functional Cohesion)
- 모듈 내부 모든 기능이 단일한 목적 위해 수행되는 경우
▷ 순차적 응집도 (Sequential Cohesion)
- 모듈 내에서 한 활동으로부터 나온 출력 값을 다른 활동이 사용할 경우
▷ 통신적 응집도 (Communication Cohesion)
- 동일 입출력 사용하여 다른 기능 수행하는 활동들이 모여 있을 경우
▷ 절차적 응집도 (Procedural Cohesion)
- 모듈이 다수 관련 기능 가질 때 모듈 안 구성 요소들이 그 기능을 순차적으로 수행할 경우
▷ 시간적 응집도 (Temporal Cohesion)
- 연관된 기능이라기 보단 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리할 경우
▷ 논리적 응집도 (Logical Cohesion)
- 유사 성격 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우
▷ 우연적 응집도 (Coincidental Cohesion)
- 모듈 내부 각 구성 요소들이 연관 없을 경우
2. 결합도
- 모듈과 모듈 사이 관련성이 어느정도인가를 나타냄
- 관련성 적을수록 모듈 독립성이 높아 모듈 간 영향 작아지게 됨
- 품질 측면에서 가장 높은 품질은 자료 결합이며, 내용 결합이 가장 낮음
▶ 결합도 유형
▷ 자료 결합도 (Data Coupling)
- 모듈 간 인터페이스로 전달되는 파라미터 통해서만 모듈 간 상호작용 일어나는 경우
▷ 스탬프 결합도 (Stamp Coupling)
- 모듈 간 인터페이스로 배열이나 오브젝트, 스트럭처 등이 전달되는 경우
▷ 제어 결합도 (Control Coupling)
- 단순 처리 대상인 값만 전달되는게 아닌 어떻게 처리 해야 한다는 제어 요소가 전달되는 경우
▷ 외부 결합도 (External Coupling)
- 모듈에서 외부로 선언한 데이터를 다른 모듈에서 참조할 때의 경우
- 외부에서 도입된 데이터 포맷, 통신 프로토콜, 또는 디바이스 인터페이스 공유할 때 주로 발생
▷ 공통 결합도 (Common Coupling)
- 파라미터가 아닌 모듈 밖에 선언되어 있는 전역 변수 참조하고 전역 변수 갱신하는 식으로 상호 작용하는 경우
▷ 내용 결합도 (Content Coupling)
- 다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우
◎ 팬인(Fan-in), 팬아웃(Fan-out)
- 구조적 설계에서 모듈 입/출력 관계를 트리 구조로 표현하여 프로그램 구조 표기 가능
- 프로그램 복잡도 최적화 위해서는 Fan-in 높게, Fan-out 낮게 설계하는 것이 좋음
1. Fan-in(공유도)
- 얼마나 많은 모듈이 현재 모듈을 호출하는가. 해당 모듈로 들어오는 상위 모듈 수
2. Fan-out(제어도)
- 어떤 모델에 의해 호출되는가. 해당 모듈에서 나가는 하위 모듈 수
* 설계 모델링
☞ SW 설계는 요구사항 분석 단계에서 규명된 필수 기능들의 구체적인 구현 방법 명시하는 단계
☞ 장치, 프로세스, 시스템을 명확하고 상세하게 정의하며 실현 가능하도록 관련 변형된 기술과 원칙 적용하는 과정
☞ SW에 요구되는 기능과 성능 조건들 만족하는 SW 내부 기능 외에 구조 및 동적 행위들 모델링하여 표현, 분석, 검증하는 과정
▶ 설계 모델의 구성
▶ 설계 모듈 요소
| 유형 | 정적(Static) 요소 | 동적(Dynamic) 요소 |
| 구조 모델 | - 구성 요소 유형 및 유형 계통 - 구성 요소들 배열, 결합 관계 - 구성 요소들 인터페이스 - 구성 요소들 상호 작용 채널 |
- 동적 생성 및 소멸 - 동적 결합/연결 - 위치 이동, 복제 |
| 행위 모델 | - 입/출력 데이터 - 입/출력 맵핑 - 데이터 흐름 채널 |
- 제어 - 상호작용 프로토콜 - 상호 작용 실행 경로 - 상태 전이 - 처리 순서, 입/출력 순서, 알고리즘 |
▶ 구조(Structure) 모델링
- SW 구성하는 컴포넌트들의 유형, 인터페이스, 내부 설계 구조 및 이들의 상호 연결 구조 모델링
▷ 개요
- 시스템 구성 요소들과 이들 사이의 구조적인 관계와 특성들 모델링
▷ 내용
- 구성요소 : 프로시저, 데이터구조, 모듈, 파일 구조
- 시스템 구조 : 구성 요소들 연결 구조, 포함 관계
▶ 설계 모듈 요소
▷ 개요
- 시스템 각 구성 요소들 기능적 특성들에 대한 모델링
- 시스템 구성 요소들이 언제 어떠한 순서로 수행되는가와 같은 동적 특성들 모델링
▷ 내용
- 입/출력 데이터, 데이터 흐름, 데이터 변환, 데이터 저장 등
- 상태 전이, 데이터 흐름 경로, 사건 발생 순서, 실행 경로 등
* 소프트웨어 아키텍처
☞ SW 시스템 구조를 비롯한 시스템 개발에 중요한 영향 미치는 결정들로, SW 시스템 개발에서 특정 시스템에 대해 요구되는 기능과 품질 확보하고 또한 SW 시스템 구축 및 지속적인 개선 용이하도록 하는 역할
☞ 요구사항 분석 활동에 의해 도출된 요구사항 모두 충족시킬 수 있는 시스템이 만들어 질 수 있도록 하기 위한 설계 활동으로서 설계 및 구현 위한 구조적/비구조적 틀 제공
☞ 틀 : 아키텍처 설계 결과물로서 실행을 요구하는 결정 또는 모델 의미
☞ 구조적 틀 : 시스템 개발을 위해 결정된 컴포넌트 구조 모델
☞ 비구조적 틀 : 이 구조모델 이외의 다른 아키텍처 설계 결정들
▶ 아키텍처 설계 입/출력
- 아키텍처 설계는 아키텍처에 관련된 대표적인 요구사항들만이 주된 관심의 대상이 됨.
- 이와 같은 특별한 요구사항들을 아키텍처 드라이버라고 함
- 설계 결과는 아키텍처 문서화한 아키텍처 문서가 주된 출력물
- 이에 대한 추가적인 관련 사항을 정리한 아키텍처 가이드 라인이 2차적인 출력물
▶ 아키텍처 설계 절차와 적용 원리
① 아키텍처 드라이버
- 시스템 요구사항 중 아키텍처에 영향 주는 요구사항
- 아키텍처 설계에 더 집중 위해 아키텍처 드라이버 먼저 식별한 후 아키텍처 설계에 효과적으로 반영해야 함
- 품질 속성, 검증 가능성, 품질 속성 시나리오 : 아키텍처 드라이버들 먼저 검증할 수 있는 형태로 바꿔 놓은 것
- 문제 분석 : 요구사항들이 어떠한 문제 해결을 요청하는 것인지 분석
② 컴포넌트
- 처리(Processing), 저장(Storage), 전달(Transfer) 수행하는 SW 시스템 구성 요소
③ 커넥터
- 컴포넌트 연결하는 연결자(Connection Element)
④ 아키텍처 스타일
- 아키텍처의 유형. 적잘한 아키텍처 스타일 선택은 대상 시스템 개발을 효율적이고 효과적으로 만들 수 있음
⑤ 소프트웨어 아키텍처를 보는 관점 체계
- 아키텍처 스타일에 따라 적합한 관점 체계가 서로 다를 수 있음
- J2EE 기반의 응용, BPMS 기반의 SOA 응용 등 아키텍처 스타일에 적절한 관점 체계가 모두 동일하지 않음
⑥ 설계 일반 원리
- 소프트웨어 아키텍처에 적용되는 보편적인 원칙
⑦ 아키텍처 설계 절차
- 아키텍처 결장하는 요구사항들로부터 먼저 어떤 아키텍처적인 설계 선택들이 있는가를 판단
⑧ 아키텍처 패턴
- 반복적으로 발생하는 문제에 대해 미리 만들어진 솔루션
ㄱ. 아키텍처 패턴 특징
- 특정 설계 상황에서 반복적으로 발생하는 설계 문제 제기하면 그 문제에 대한 해법 제시하여 기존에 이미 그 효과가 입증된 설계 경험 정리한 것
- 설계 원칙에 대한 공통 어휘와 공감대 형성시켜줌
- 컴포넌트, 단일 클래스, 객체 같은 수준보다 높은 단계 추상 레벨에서 발견되고 정의됨
- SW 아키텍처 문서로 정리하는 방법 제공
- 고유 특성 제공해야 하는 SW 개발할 수 있도록 도와줌
- 복잡한 SW 아키텍처 구축하는 데 도움을 주면 SW 복잡성 관리하는 데 유용
ㄴ. 아키텍처 패턴 사례
a. 계층화 패턴 (Layered patteren)
- N-티어 아키텍처 패턴
- 하위 모듈들 그룹으로 나눌 수 있는 구조화된 프로그램에서 사용 가능
- 각 하위 모듈들은 특정 수준 추상화 제공하며, 각 계층은 다음 상위 계층에 서비스 제공
- 활용 사례 : OSI 7 Layer, 일반적인 데스크톱 애플리케이션, E-commerce 웹 애플리케이션
□ 일반적인 정보 시스템에서 공통적으로 볼 수 있는 계층 4가지
- 프레젠테이션 계층 (Presentation Layer) - UI 계층 (UI Layer)
- 애플리케이션 계층 (Application Layer) - 서비스 계층 (Service Layer)
- 비즈니스 논리 계층 (Business Logic Layer) - 도메인 계층 (Domain Layer)
- 데이터 접근 계층 (Data Access Layer) - 영속 계층 (Persistence Layer)
b. 클라이언트-서버 패턴 (Client-server patteren)
- 하나의 서버와 다수의 클라이언트, 두 부분으로 구성됨
- 서버 컴포넌트는 다수 클라이언트 컴포넌트로 서비스 제공
- 클라이언트가 서버에 서비스 요청하면 클라이언트에게 적절한 서비스 제공하며 서버는 계속 클라이언트로부터 요청 대기
- 활용 사례 : 이메일, 문서 공유 및 은행 등 온라인 애플리케이션
c. 마스터-슬레이브 패턴 (Mater-slave patteren)
- 마스터와 슬레이브, 두 부분으로 구성됨
- 마스터 컴포넌트는 동등한 구조를 지닌 슬레이브 컴포넌트들로 작업 분산하고, 슬레이브가 반환한 결과 값으로부터 최종 결과 값 계산
- 활용 사례 : DB 복제의 마스터DB와 슬레이브DB, 컴퓨터 시스템에서 버스와 연결된 주변장치
d. 파이프-필터 패턴 (Pipe-filter patteren)
- 데이터 스트림 생성하고 처리하는 시스템에서 사용 가능
- 각 처리 과정은 필터 컴포넌트에서 이루어지며, 처리되는 데이터는 파이프 통해 흐름
- 이 파이프는 버퍼링 또는 동기화 목적으로 사용될 수 있음
- 활용 사례 : 컴파일러 - 연속한 필터들은 어휘 분석, 파싱, 의미 분석 그리고 코드 생성 수행
e. 브로커 패턴 (Broker patteren)
- 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용
- 분리된 컴포넌트들은 원격 서비스 실행 통해 서로 상호 작용 가능
- 컴포넌트 간 통신 조정하는 역할
- 서버는 자신 기능들을 브로커에 넘겨주고(publish), 클라이언트가 브로커에 서비스 요청하면 브로커는 클라이언트를 자기 레지스트리에 있는 적합한 서비스로 리디렉션
- 활용 사례 : Apache, ActiveMQ, Apache Kafka, RabbitMQ, JBoss Messaging과 같은 메시지 브로커 SW
f. 피어 투 피어 패턴 (Peer-to-peer patteren)
- 각 컴포넌트를 피어라고 부름
- 피어는 클라이언트로서 피어에게 서비스 요청할 수도 있고, 서버로서 각 피어에게 서비스 제공 가능
- 피어는 클라이언트 또는 서버 혹은 둘 모두로서 동작 가능, 시간 지남에 따라 역할이 유동적 변경 가능
- 활용 사례 : Gnutella, G2와 같은 파일 공유 네트워크, P2PTV, PDTP와 같은 멀티 미디어 프로토콜, Spotify와 같은 독점적 멀티미디어 애플리케이션
g. 이벤트-버스 패턴 (Event-bus patteren)
- 주로 이벤트 처리
- 이벤트 소스, 이벤트 리스너, 채널, 이벤트 버스 4가지 주요 컴포넌트들 가짐
- 소스는 이벤트 버스 통해 특정 채널로 메시지 발행 (publish)
- 리스너는 특정 채널에서 메시지 구독 (Subscribe)
- 리스너는 이전에 구독한 채널에 발행된 메시지에 대해 알림 받음
- 활용 사례 : 안드로이드 개발, 알림 서비스
h. 모델-뷰-컨트롤러 패턴 (Model-view-controller patteren)
- MVC 패턴
- 모델 : 핵심 기능과 데이터 포함
- 뷰 : 사용자에게 정보 표시 (하나 이상의 뷰가 정의될 수 있음)
- 컨트롤러 : 사용자로부터 입력 처리
- 정보가 사용자에게 제공되는 방식과 사용자로부터 받아들여지는 방식에서 정보 내부적인 표현 분리 위해 나뉘며, 이는 컴포넌트 분리하며 코드 효율적인 재사용 가능케 함
- 활용 사례 : 일반적인 웹 애플리케이션 설계 아키텍처, Django나 Rails와 같은 웹 프레임워크
⑨ 품질 속성 설계 전술
- 단일 품질속성 응답 제어하는데 영향력 있는 설계 결정
⑩ 아키텍처 분석
- 주어진 아키텍처가 적절한지 판단 위한 분석
⑪ 아키텍처 평가
- 평가는 완결된 설계를 대안과 비교함으로써 그 결과에 따라 설계라는 큰 과정을 다시 수행할 것을 요구할 수도 있는 활동
▶ 소프트웨어 아키텍처 프레임워크 (ISO/IEC/IEEE 42010)
- IEEE 1471 : 소프트웨어 구조에 대한 기술 규정한 IEEE 표준
- IEEE 42010 : 시스템 및 SW 엔지니어링 아키텍처 기술과 관련된 용어와 개념 정의한 국제 표준
▶ SW 아키텍처 4+1 View 개요
- 시스템 여러 가지 측면 고려하기 위한 다양한 관점 바탕으로 정의
- UML 4+1 View가 표준
- 고객 요구사항 중심으로 4가지 관점으로 SW 아키텍처 설계하는 기법
■ SW 아키텍처 4+1 View 구성
□ 사용 사례 관점 (Use Case View)
- 시스템 외부 사용자 관점에서 사용 사례들 간 관계 정의
□ 논리 관점 (Logical View)
- 상위 수준에서 시스템 논리적인 구조/행위를 클래스 인터페이스, 협력 관계로 정의
□ 구현 관점 (Implementation View)
- 독립적으로 실행되는 컴포넌트와 이들 간 관계 정의
□ 프로세스 관점 (Process View)
- 시스템 병렬 처리 및 동기화 처리 위한 스레드와 프로세스 정의
□ 배치 관점 (Deployment view)
- 실행되는 시스템 하드웨어와 소프트웨어 관계 정의
* 코드
☞ 데이터 사용 목적에 따라 식별, 분류, 배열하기 위해 사용하는 숫자, 문자 혹은 기호
☞ 대량 자료 식별하고 비슷한 유형 그룹으로 분류하여 순서대로 나열할 수 있고 자료 조회하거나 특정 조건 자료 추출 쉽게 할 수 있어 자료 시스템을 체계적으로 관리 가능
▶ 코드 기능
▷ 표준화
- 다양한 종류 데이터를 일정 기준으로 통일하여 관리
▷ 간소화
- 데이터를 간략하게 표현 가능
▷ 분류
- 데이터 분류 쉽게 가능
▷ 식별
- 대량 데이터들에서 서로 구분할 수 있고 쉽게 식별 가능
▷ 배열
- 데이터 정의한 순서대로 나열 가능
▷ 연상
- 정보를 표현하고자 하는 데이터 뜻과 의미가 코드에 내포되게 표현 가능
▷ 암호화
- 데이터 외부 표현 감추고자 암호화 가능
▷ 오류 검출
- 데이터 입/출력 시 잘못된 정보 검출 가능
'정보처리기사 > 필기' 카테고리의 다른 글
| [정보처리기사] Part01-04-1. 인터페이스 요구사항 확인 (0) | 2022.02.25 |
|---|---|
| [정보처리기사] Part01-03-2. 객체 지향 설계 (0) | 2022.02.25 |
| [정보처리기사] Part01-02-2. UI 설계 (0) | 2022.02.24 |
| [정보처리기사] Part01-02-1. UI 요구사항 확인 (0) | 2022.02.24 |
| [정보처리기사] Part01-01-3. 분석모델 확인 (2) (0) | 2022.02.24 |
댓글