11. 소프트웨어 설계 모델링
1) 소프트웨어의 설계
기본 원리는 분할과 정복, 추상화, 모듈화 (단계적 통합 X)
상위 설계와 하위 설계로 나뉨
상위 설계는 아키텍처 설계, 예비 설계라고 함 (전체적인 구조)
하위 설계는 모듈 설계, 상세 설계라고 함 (구성 요소의 구체적인 정의) -> 절차 기반, 자료 위주, 객체 지향 설계 방법
소프트웨어 설계 대상은 구조 모델링과 행위 모델링으로 나뉨
구조 모델링: 컴포넌트(모듈)와 같이 구조적인 것. 어떻게 연결할지
행위 모델링: 언제, 어떻게 기능들이 수행되는지
소프트웨어 설계 방법은 구조적 설계와 자료 중심 설계로 나뉨
구조적 설계: 기능적 관점, 알고리즘 등으로 설계 (cf. Coad/Yourdon)
자료 중심 설계: I/O 구조를 파악해 설계 (cf. Jackson Warner-Orr)
객체지향 설계: 추상화하는 개념 (cf. Yourdon, Rumbaugh)
Fan-in이 높은 경우: 재사용 잘됨. 일부가 동작 안 하면 시스템이 중단되는 '단일 장애 발생' 가능성 있음. 중점 관리 필요
Fan-out이 높은 경우: 불필요한 타 모듈의 호출 여부를 확인함. 더 단순하게 할 순 없는지 검토
=> 복잡도 최적화를 위해 Fan-in을 높이고 Fan-out은 낮추도록 한다.
2) 코드 설계의 개요
코드의 기본적 기능: 표준화/간소화
코드의 3대 기능: 분류/식별/배열
코드의 부가적 기능: 연상/암호화/오류 검출
3) 코드 종류
순차 코드: 일정한 배열로 일련번호를 배당하는 코드
(확장성 좋음. 이해하기 쉬움. 공간 낭비 적음 vs 중간 삽입 어려움. 융통성 낮음)
블록 코드(구분 코드): 공통의 특성에 따라 임의의 크기를 블록으로 구분해 블록 안에서 일련번호를 배정하는 코드
(기계 처리 어려움. 코드 추가 쉬움 vs 코드 추가가 쉬운 만큼 낭비의 요인이 됨)
그룹 분류식 코드: 기준에 따라 대분류, 중분류, 소분류로 구분해 순서대로 번호를 부여하는 코드
(이용도 높고 기계 처리에 적합 vs 자릿수가 길어질 수 있음)
10진 분류 코드: 도서 분류 코드 같은 거
표의 숫자 코드(유효 숫자 코드): 코드화 대상 항목의 뭔가(물리적)를 나타내는 것을 코드로 사용하는 코드
(코드의 추가, 삭제가 쉬우며 코드를 반복해 오류가 적음. ex. 127-890: 두께 127mm, 폭 890mm처럼)
연상 코드(기호 코드): 품목 명칭 일부를 약호 형태로 넣음 (ex. TV-39-C: TV 39인치 컬러)
4) 구조적 개발 방법론
자료의 흐름, 처리를 중심으로 한 요구분석 방법
정형화된 절차에 따라 요구사항 파악, 자료 흐름도, 자료 사전, 명세 사용
자료 흐름도(Data Flow Diagram): 다차원적, 자료 흐름 그래프 또는 버블 차트라고 함
하향식 분할 원리. 이름으로 정의를 쉽게 찾음.
소단위 명세서: 잘게 쪼갠 자료 흐름도에서 최하위 단계 프로세스 처리 절차를 설명 (프로세스 명세서라고도 함)
DFD를 지원하기 위해 작성함.
구조적 언어, 의사 결정 나무, 의사 결정표
자료 사전(Data Dictionary)
역할: 자료 흐름도에 기술된 모든 자료의 정의를 기술한 문서
12. 모듈
1) 모듈과 결합도, 응집도
모듈: 하나의 기능을 수행하는 실행 코드
재사용 가능. 자체적 컴파일 가능. 모듈의 독립성은 결합도와 응집도에 의해 측정됨
서브루틴 = 서브 시스템 = 작업 단위
모듈은 상속해서 쓸 수 있음. 기능적 독립성(다른 모듈과 과도한 상호작용 회피)
결합도(Coupling)
서로 다른 모듈 간의 상호 의존도. 기능적인 연관 정도.
결합도가 낮은 게 좋음 (독립성 확보. 유지보수 용이)
결합도가 낮은 순서 (1부터 가장 낮음)
1. 데이터 결합도: 설계 품질이 가장 좋음. 모듈끼리 영향 1도 없음
2. 스탬프 결합도: 같은 자료 구조 조회 (배열, 레코드)
3. 제어 결합도: 어떤 모듈이 다른 모듈의 내부 논리 조작을 제어하기 위해 통신
4. 외부 결합도: 어떤 모듈에서 외부로 선언한 변수를 다른 모듈에서 참조하는 경우
5. 공통 결합도: 여러 모듈이 공통 자료 영역을 씀
6. 내용 결합도: 결합도가 가장 강함. 한 모듈이 다른 모듈 제어, 이동, 조회, 변경, 공유됨
응집도(Cohension)
모듈 안의 요소들이 서로 관련된 정도, 모듈이 얼마나 독립적인지
응집도는 높은 게 좋음
응집도가 강한 순서 (1이 가장 높음)
1. 기능적 응집도: 모듈 내부의 모든 기능이 한 문제와 연관됨
2. 순차적 응집도: 한 모듈 내부의 한 기능 요소에 의한 출력 자료가 다음 기능 요소의 입력 자료가 됨
3. 교환적 응집도: 같은 입출력을 사용하는 소작업이 모임
4. 절차적 응집도: 모듈이 다수의 관련 기능을 가질 때 그 기능을 순차적으로 수행
5. 시간적 응집도: 특정 시간에 처리되는 여러 기능을 모아 한 개의 모듈로 작성한 경우
6. 논리적 응집도: 유사한 성격, 특정 형태로 분류되는 처리 요소들로 하나의 모듈 형성
7. 우연적 응집도: 서로 관련 없는 요소들로만 구성
설계 시 결합도는 약하고, 응집도는 높게 해 모듈의 독립성을 확보해야 함
모듈의 크기가 작으면 모듈 개수가 증가해 모듈 간 통합 비용이 증가함
모듈의 크기가 크면 단위 모듈 개발 시 비용과 시간이 많이 소요됨
2) 모듈과 컴포넌트
모듈: 자신만으로 동작 가능. 구현된 단위. 정의하지 않는 이상 바로 재활용 X
컴포넌트: 인터페이스로 연결됨. 독립적인 업무/기능을 수행하는 모듈로 교체가 가능함.
모듈 분할 시 영향을 주는 설계 형태
추상화, 모듈화, 정보 은폐, 복잡도, 시스템 구조
3) 재사용과 공통 모듈
재사용 규모에 따른 구분
함수와 객체: 클래스, 메소드 단위의 코드를 재사용
애플리케이션: 공통 업무 처리를 위해 구현된 애플리케이션을 공유하여 재사용
컴포넌트: 컴포넌트 자체의 수정 없이 인터페이스를 통해 컴포넌트 단위로 재사용
공통 모듈
- 서브 시스템에서 공통으로 사용하는 기능들을 묶어 하나의 공통된 모듈로 개발함
- 명세 기법: 정확성, 명확성, 완전성, 일관성, 추적성
모듈 명세화 도구
흐름도, N-S 도표, 의사 코드, 의사 결정도, 상태 전이도 등등...
N-S 도표는 구조적 프로그램의 순차, 선택, 반복의 구조를 사각형으로 도식화한 표현 방법
13. 소프트웨어 아키텍처
1) 소프트웨어 아키텍처
structure frame: 시스템 개발을 위해 결정된 컴포넌트 구조 모델
non structure frame: 해당 구조 모델 이외 다른 아키텍처 설계 결정
소프트웨어 아키텍처 품질 속성
성능, 사용 용이성, 보안성, 시험 용이성, 가용성, 변경 용이성, 사용성
특징
간략성, 추상화, 가시성, 복잡도 관리 종류(과정 추상화, 데이터 추상화, 제어 추상화)
아키텍처 프레임워크 구성 요소
프레임워크: 복잡한 SW 문제 해결 및 서술하는데 필요한 기본 구조 제공 (재사용 가능)
요소: AD(아키텍쳐 설명), 이해관계자, 관심사, 관점, 뷰
소프트웨어 아키텍처 4+1 view model
UML이 정의되면서 4+1이 됨
logical view, implementation view, process view, deployment view, use case view
설계 원리
단순성, 효율성, 분할/계층화, 추상화, 모듈화
평가 방법론 종류
SAAM, ATAM, CBAM, ARID
14. 소프트웨어 아키텍처 패턴
종류: Layered, Client-Server, Master-Slave, MVC 등등등...
장점: 개발 시간 단축, 유지보수, 고품질/안정적 개발
아키텍처 패턴 = 아키텍처 스타일 = 표준 아키텍처
Layered 패턴
SW를 계층 단위(unit)로 분할 (=N-tier 아키텍처 패턴)
계층적으로 조직화하는 서비스에 유리함. 내부 응집도를 높임
MVC패턴
모델: 핵심 기능 + 데이터
뷰: 사용자에게 정보를 표시함 (다수 뷰가 정의될 수 있음)
컨트롤러: 사용자로부터 입력을 처리함
장점: 동일 모델에서 다수의 뷰 생성. 실행 시간에 동적으로 연결 및 해제
단점: 유저 행동에 대한 불필요 업데이트 발생 가능성. 복잡성.
활용: 일반적인 웹 애플리케이션 설계 아키텍처, Django나 Rails 같은 웹 프레임워크
클라이언트 서버 패턴
하나의 서버와 다수 클라이언트로 구성
서버는 응답을 위해 항상 대기중
여러 컴포넌트에 걸쳐 데이터-데이터 처리 시 유리
장점: 데이터 분산, 위치 투명성
단점: 서비스와 서버 이름을 관리하는 레지스터가 없어 이용 가능한 서비스 시간에 불편함
활용: 은행, 이메일, 문서공유 등
파이프 필터
데이터 흐름을 생성/처리하는 구조
필터: 파이프를 통해 받은 데이터를 변경, 그 결과를 파이프로 전송
각 처리 과정은 필터 컴포넌트에서 이뤄짐
처리된 데이터는 파이프를 통해 흐르며 파이프는 버퍼링, 동기화 목적으로 사용됨
컴파일러, 연속한 필터들은 어휘 분석, 파싱, 의미 분석 등을 수행함
장점: 높은 유연성
단점: 상태정보 공유를 위한 비용, 데이터 변환에서 과부하
활용: 컴파일러, 어휘 분석, 구문 분석 등
Peer To Peer: 클라이언트/서버 스타일에 대칭적 특징 추가 (상황에 따라 바뀜. 분산 컴퓨팅 구축 시 사용)
브로커: 컴포넌트가 사용자-컴퓨터를 연결해주는 역할로 요청에 응답하는 컴포넌트들이 여러 개 존재할 때 사용 (아파치 카프카, 래빗엠큐 등 메세지 브로커 소프트웨어에 활용)
블랙 보드: 결정적 해결 전략이 없는 문제에 사용. 음성 인식 및 신호 해석에 활용
이벤트 버스: 소스 이벤트가 메세지 발행, 해당 채널 구독자가 메세지 수신 후 이벤트를 처리함
인터프리터: 특정 언어로 쓰인 프로그램을 해석하는 컴포넌트를 설계할 때 사용
15. 객체지향 설계
1) 구조적, 절차적 프로그래밍과 객체지향
구조적 프로그래밍
이해가 쉽고 디버깅 작업이 쉬움. 하나의 입력과 하나의 출력 구조로 분기문 사용 X
순차, 선택, 반복 구조
절차적 프로그래밍
순서대로 일련의 명령어를 나열함
함수 기반의 프로그래밍. 규모가 커질 수록 함수가 늘어남
객체지향 분석
엔티티를 속성과 메소드로 결합해 객체로 표현함
SW 개발 대상이 개체이며 개체 간의 상호 관계를 모델링하는 방식
객체지향 프로그래밍 (OOP)
SW 내의 객체는 서로 메세지를 주고 받음
구성 요소: 객체, 클래스, 메세지
객체: 데이터와 함수를 묶여 캡슐화하는 대상. 클래스에 속한 인스턴스
클래스: 유사한 객체를 정의한 집합 (상위/하위 클래스로 나뉨)
2) 객체지향 특징
캡슐화: 서로 관련성 높은 데이터와 기능을 묶는 기법. 결합도가 낮아짐. 재사용성 높아짐
정보 은닉: 객체 내부 속성/메소드를 숨김. 예기치 못한 부작용 줄임
다형성: 객체가 다양한 모양을 가지는 성질. 오버로딩/오버라이딩
상속: 상속 받음(상위 -> 하위)
추상화: 공통 성질을 추출한 뒤 추상 클래스를 설정하는 기법(기능 추상화, 제어 추상화, 자료 추상화)
오버로딩: 한 클래스 내에서 같은 이름의 메소드를 사용하는 것
동명의 메소드를 여러 개 정의하면서 매개 변수의 유형과 개수가 달라지게 함
오버라이딩: 상속 관계의 두 클래스의 상위 클래스에서 정의한 메소드를 하위 클래스에서 재정의 하는 것
Java에서 static 메소드의 오버라이딩을 허용하지 않음
하위 객체의 매개 변수 개수와 타입은 상위 객체와 같아야 함
객체지향 설계 원칙(SOLID)
단일 책임의 원칙: 모든 클래스는 단일 목적으로 생성. 하나의 책임만 가짐
개방-폐쇄의 원칙: 확장에는 개방적이나 수정에는 폐쇄적이어야 함
리스코프치환 원칙: 부모 클래스 자리에 자식 클래스를 대체해도 잘 동작해야 함(상속)
인터페이스 분리 원칙: 사용하지 않는 메소드와 의존 관계 맺으면 안됨, 영향 받아서도 안됨
의존 역전 원칙: 의존 관계를 맺으면 변하기 어렵고 변화 빈도가 낮은 것에 의존한다.
OOD, OOSE, OMT, Coad와 Your-don(E-R 다이어그램)
클래스 인터페이스: 클래스 구현, 클래스 사용, 클래스 확장
협약에 의한 설계 3타입: 선행조건, 결과조건, 불변조건
16. 디자인 패턴
자주 사용하는 설계 형태를 정형화해 유형별로 템플릿을 만드는 방법
Gof(Gang of Four) 분류가 가장 많이 사용된다.
장점: 의사소통 원활, 구조 파악 쉬움, 유지보수 및 개발 시간 단축 등등
단점: 객체지향 설계 위주로 사용, 초기 투자 비용이 부담
디자인 패턴의 구성 요소
필수 4가지: 패턴의 이름, 문제 및 배경, 해법, 결과
추가 요소: 알려진 사례, 샘플 코드, 원리, 정당성, 근거 등등...
GoF 디자인 패턴 (4명이 제안함)
객체지향 설계 단계 중 재사용에 관한 유용한 설계를 디자인 패턴화함
생성 패턴, 구조 패턴, 행위 패턴으로 분류함
생성 패턴: 객체를 생성하는 것과 관련. 생성과 참조 과정을 추상화함
구조 패턴: 어떻게 구조할 것인지
행위 패턴: 반복적으로 사용되는 객체들의 상호작용을 패턴화한 것
디자인 패턴 vs 아키텍처 패턴
아키텍처가 상위 설계에 이용
아키텍처 패턴: 시스템 전체 구조를 설계하는 참조 모델
디자인 패턴: 서브 시스템 내 컴포넌트와 그 관계를 구성하는 참조 모델
17. 인터페이스 요구사항 확인
1) 인터페이스 요구사항
기능적 요구사항/비기능적 요구사항
2) 인터페이스 요구사항 검증 방법
프로토타이핑: 시제품
테스트 설계: Test Case 설계 해서 테스트 가능한지 검토
CASE: 일관성 분석을 통해 요구사항 변경의 추적, 분석함
요구사항 검토: 동료 검토, 워크 스루(검토회의 전 명세서 배포 후 짧은 검토 회의로 결함 찾기), 인스펙션(공식적 검토방법)
18. 인터페이스 대상 식별
인터페이스 시스템의 구성
송신 시스템/중계 시스템/수신 시스템
인터페이스 데이터 표준
공통부/개별부/종료부로 구성됨
내외부 송수신 방법 (중계 서버 또는 솔루션의 유무)
직접 연계
간접 연계
19. 미들웨어 솔루션
클라이언트-서버 간 통신을 담당하는 시스템 소프트웨어
시스템 간의 표준화된 연결을 도와주는 소프트웨어
일관성, 중개 매개 역할을 함
출처: https://www.youtube.com/watch?v=uRbUh7ypnyg&list=PL6i7rGeEmTvqEjTJF3PJR4a1N9KTPpfw0&index=2
'✏️ 정보처리기사' 카테고리의 다른 글
| [정보처리기사: 필기] 2. 소프트웨어 개발 문제 풀이 (0) | 2024.01.26 |
|---|---|
| [정보처리기사: 필기] 2. 소프트웨어 개발 (1) | 2024.01.26 |
| [정보처리기사: 필기] 1. 소프트웨어 설계 문제 풀이 (2) (2) | 2024.01.25 |
| [정보처리기사: 필기] 1. 소프트웨어 설계 문제 풀이 (1) | 2024.01.24 |
| [정보처리기사: 필기] 1. 소프트웨어 설계 (1) (1) | 2024.01.23 |
