소프트웨어 설계 - 애플리케이션 설계

#애플리케이션 설계 - 공통 모듈 설계 ★★★

재사용(Reuse)

• 개발 시간 및 비용 절감을 위하여 검증된 기능을 파악하고 재구성하여 시스템에 응용하기 위한 최적화 작업
• 기존 소프트웨어 또는 소프트웨어 지식을 활용하여 새로운 소프트웨어를 구축하는 작업

재사용의 유형

1. 함수/객체 재사용
2. 컴포넌트 재사용
3. 애플리케이션 재사용

공통 모듈

①모듈(Module)

• 독립된 하나의 소프트웨어 또는 하드웨어 단위를 지칭하는 용어
• 특징 : 독립성, 다양한 조합, 재사용, 영향 최소화

②공통 모듈

• 특정 기능을 처리할 수 있는 실행코드를 의미
• 자체적으로 컴파일 가능
• 다른 프로그램에서 재사용 가능
• 여러 기능 및 프로그램에서 공통으로 사용할 수 있는 모듈
• Eg. 날짜 처리를 위한 유틸리티 모듈 등이 해당

공통 모듈 원칙

@정명 완일추

• 정확성 (Correctness)
• 명확성 (Clarity)
• 완전성 (Completeness)
• 일관성 (Consistency)
• 추적성 (Traceability)

모듈화

• 효율적으로 관리될 수 있도록 시스템을 분해하고 추상화함으로써 소프트웨어 제품의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지관리를 쉽게 하는 기법
• 기능 단위의 모듈로 분해하는 설계 및 구현기법

모듈의 필요성

• 모듈의 크기가 작아 모듈 개수가 많아지면
  모듈 간 통합 비용이 많이 발생, 상호 교류가 증가하여 과부하 현상이 나타남
• 모듈의 크기가 크면
  통합 비용이 줄어드는 대신 모듈 당 개발 비용이 커짐

모듈 설계 방안

• 독립성과 재 사용성을 높이기 위하여 결합도는 낮추고 응집도는 높임
• 복잡도와 중복성을 줄이고 일관성을 유지
• 예측이 가능해야 함
• 지나치게 제한적이면 안됨
• 적당한 모듈의 크기를 유지해야 함
• 유지보수가 용이해야하고, 이식성을 고려해야 함

모듈 측정 지표

응집도와 결합도

모듈화 유형

■ 응집도 (Cohesion)

• 독립성을 나타내는 개념
• 하나의 모듈은 하나의 기능을 수행함을 의미

- 응집도의 유형

@우논시절 통순기

• 우연적 (Coincidental)
• 논리적 (Logical)
• 시간적 (Temporal)
• 절차적 (Procedural)
• 통신적 (Communication)
• 순차적 (Sequential)
• 기능적 (Functional)

※ 아래로 내려올 수록 응집도가 높음

■ 결합도 (Coupling)

• 외부의 모듈과의 연관도 또는 모듈간의 상호 의존성을 나타내는 정도
• 모듈간의 관련성을 측정하는 척도

- 결합도의 유형

@내공 외제 스자

• 내용 (Content)
• 공통 (Common)
• 외부 (External)
• 제어 (Control)
• 스탬프 (Stamp)
• 자료 (Data)

※ 아래로 내려올 수록 결합도 낮음

팬인 및 팬 아웃

Fan-in	Fan-out
어떤 모듈을 제어하는 모듈의 수	어떤 모듈에 의해 제어되는 모듈의 수
자신을 기준으로 들어옴	자신을 기준으로 나감
재사용 측면에서 설계가 잘 되었지만 단일 장애점 발생 가능	붎ㄹ요한 모듈 호출 여부 검토 필요
관리 비용 및 테스트 비용 증가	단순화 여부 검토 필요

설계 모델링

• 필수 기능들이 구체적인 구현 방법을 명시하는 기법
• 변경이 쉽도록 구조화되어야 함
• 특정 기능을 수행하는데 필요한 자료만 사용하도록 규제
• 독립적이고 기능적인 특성을 지닌 모듈 단위로 분할하여 설계
• 계층적 구조를 가져야 함
• 유형: 구조 모델링, 행위 모델링

설계 유형

■ 상위 설계

• 자료 구조 설계 (Data Structure Design)
• 아키텍처 설계 (Architecture Design)
• 인터페이스 설계 (Interface Design)
• 프로시저 설계 (Procedure Design)
• 협약에 의한 설계 (Design by Contract)

■ 하위 설계

• 모듈 설계

설계 원리

■ 상향식 설계

• 하위 기능들로부터 시작하여 제일 상위에 있는 기능으로 접근
• 기존 컴포넌트들 조합하여 시스템을 개발하는 경우

■ 하향식 설계

• 제일 상위에 있는 기능에서 시작하여 기능을 하위 기능들로 분할해 가면서 설계하는 방식
• 레벨이 낮은 데이터 구조의 세부사항은 설계 초기 단계에서 필요
• 새로 개발하는 작업에 적합

코드 설계

■ 코드 설계 종류

• 연상 코드
• 블록 코드
• 순차 코드
• 표의 숫자 코드
• 십진 코드
• 그룹 분류식 코드

■ 코드 설계 절차

1. 코드화 항목 선정
2. 코드화 목적 설정
3. 코드화 대상 확인
4. 코드화 범위 결정
5. 코드 사용 기간 설정
6. 코드화 항목의 특성 분석
7. 코드화 방식 결정
8. 문서화

■ 코드 오류 종류

• 사본 오류(Transcription Error): 한자리 잘못 표기
• 전위 오류(Transposition Error): 연속된 두글자의 순서가 바뀌어 표기
• 생략 오류(Omission Error): 한 글자를 빼먹고 기술
• 첨가 오류(Addition Error): 한 글자를 추가하여 기술
• 이중 전위 오류(Double Transposition Error): 전위 오류가 중복하여 발생

HIPO (Hierarchy Input Process Output)

• 하향식 소프트웨어 개발을 위한 문서화 도구
• 체계적인 문서 관리가 가능
• 기호, 도표 등을 사용해서 보기가 쉽고 이해가 쉬움
• 기능과 자료의 의존관계를 동시에 표현할 수 있음
• 변경/유지보수 용이

HIPO 차트 종류

• 가시적 도표
• 총체적 도표
• 세부적 도표

소프트웨어 아키텍처 (Software Architecture)

• 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조
• 설계하고 전개하기 위한 지침과 원칙

소프트웨어 아키텍처 4+1뷰

• 시나리오를 4개의 관점에서 바라노는 소프트웨어적인 접근방법
• 구성요소:
  • 4: 논리뷰, 구현뷰, 프로세스 뷰, 배포 뷰
  • 1: 유스케이스 뷰

@유논프구배

■ 유스케이스 뷰

• 행위자에 의해 인식되는 시스템의 기능 요구사항 보여주는데 초점
• 관점: 사용자, 설계자, 개발자, 테스트

■ 논리 뷰

• 시스템의 기능적인 요구사항이 어떻게 제공되는지 보여주는 뷰
• 관점: 설계자, 개발자

■ 프로세스 뷰

• 시스템의 비기능적인 속성
• 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현
• 관점: 개발자, 시스템 통합자

■ 구현 뷰

• 컴포넌트 구조와 의존성을 보여주고 컴포넌트에 관한 부가적인 정보 정의

■ 배포 뷰

• 컴포넌트가 물리적인 어떻게 배치되는가를 매핑해서 보여주는 뷰

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

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

종류

@SACAA (사카)

■ SAAM (Software Architecture Analysis Method)

• 변경 용이성과 기능성에 집중

■ ATAM (Architecture Trade-off Analysis Method)

• 아키텍처 품질 속성을 만족시키는지 판단

■ CBAM (Cost Benefit Analysis Method)

• 경제적 의사결정에 대한 요구를 충족하는 비용 평가

■ ADR (Active Design Review)

• 아키텍처 구성요소 간 응집도를 평가

■ ARID (Active Reviews for Intermediate Designs)

• 특정 부분에 대한 품질 요소에 집중하는 비용 평가

소프트웨어 아키텍처 패턴

• 외부에서 인식할 수 있는 특성이 담긴 소프트웨어의 골격이 되는 기본 구조
• 소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결 방법

패턴 유형

■ 계층화 패턴 (Layered Pattern)

• 시스템을 계층으로 구분하여 구성
• 하위 모듈들은 특정한 수준의 추상화를 제공하고, 각 계층은 다음 상위 계층에 서비스 제공

■ 클라이언트-서버 패턴 (Client-Server Pattern)

• 하나의 서버와 다수의 클라이언트로 구성
• 클라이언트를 통해서 서버에 서비스를 요청하면 서버는 클라이언트에게 서비스를 제공

■ 파이프-필터 패턴 (Pipe-Filter Pattern)

• 단방향 패턴
• 서비 시스템이 입력 데이터를 받아 처리하고, 결과를 다음 서브 시스템으로 넘겨주는 과정을 반복
• 재사용성이 좋고, 추가가 쉽기 때문에 확장이 용이

■ 브로커 패턴 (Broker Pattern)

• 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용
• 컴포넌트 간의 통신을 조정하는 역할

■ 모델-뷰-컨트롤러 패턴 (MVC; Model-View-Control Pattern)

• 모델, 뷰, 컨트롤 뷰 3개의 서브시스템으로 구조화
• 각 부분이 별도의 컴포넌트로 분리되어 있어서 서로의 영향을 받지 않고 개발 작업 수행 가능
• 여러개 뷰가 있어야 하는 대화형 애플리케이션 구축에 적합
• 모델: 핵심 기능과 데이터 보관
• 뷰: 사용자에게 정보 표시
• 컨트롤러: 모델과 뷰 사이에서 전달자 역할을 수행

■ 마스터-슬레이브 패턴 (Master-Slave Pattern)

• 실시간 시스템에서 사용
• 마스터: 연산, 통신, 조정을 책임
• 슬레이브: 제어되고 동기화 되는 대상, 데이터 수집 기능 수행